Skip to main content

Distributed Mobility Management Framework
draft-chan-dmm-framework-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Anthony Chan , Pierrick Seite , Kostas Pentikousis
Last updated 2013-02-25
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chan-dmm-framework-01
DMM                                                              H. Chan
Internet-Draft                                       Huawei Technologies
Intended status: Informational                                  P. Seite
Expires: August 29, 2013                         France Telecom - Orange
                                                          K. Pentikousis
                                                     Huawei Technologies
                                                       February 25, 2013

               Distributed Mobility Management Framework
                      draft-chan-dmm-framework-01

Abstract

   This document introduces a framework for mobility management
   protocols in terms of their key, abstract logical functions.  We
   explain how the framework is capable of presenting a unified view,
   reducing the clutter that prevents a casual reader from understanding
   the commonalities between different approaches in mobility
   management.  A first order application of this framework is to enable
   us to examine previously standardized mobility management protocols,
   such as MIPv6 and PMIPv6 (as well as several of their extensions),
   and describe their core functionality in terms of different
   configurations of the logical functions defined by the framework.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Chan, et al.             Expires August 29, 2013                [Page 1]
Internet-Draft                DMM Framework                February 2013

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
   3.  Mobility Management Logical Functions  . . . . . . . . . . . .  4
   4.  Mobility Protocol Functional Decomposition . . . . . . . . . .  5
     4.1.  Decomposing Mobile IPv6  . . . . . . . . . . . . . . . . .  6
     4.2.  From MIPv6 to PMIPv6 . . . . . . . . . . . . . . . . . . .  6
     4.3.  Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . .  8
     4.4.  Distributing Mobility Anchors  . . . . . . . . . . . . . .  9
     4.5.  Migrating Home Agents  . . . . . . . . . . . . . . . . . . 10
   5.  DMM Functional Decomposition Scenarios . . . . . . . . . . . . 11
     5.1.  Flat Network Scenario  . . . . . . . . . . . . . . . . . . 11
       5.1.1.  Network-based Mobility Management  . . . . . . . . . . 12
       5.1.2.  Client-based Mobility Management . . . . . . . . . . . 13
     5.2.  DMM with Control and Data Plane Separation . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Chan, et al.             Expires August 29, 2013                [Page 2]
Internet-Draft                DMM Framework                February 2013

1.  Introduction

   While there is ongoing research on new protocols for distributed
   mobility management (DMM), it has also been proposed, e.g., in
   [Paper-Distributed.Mobility.PMIP] and in other publications, that a
   DMM architecture can be designed using primarily existing mobility
   management protocols with some extensions.  This is reflected in the
   requirement included in [I-D.ietf-dmm-requirements]: distributed
   mobility management is to first use existing protocols and their
   extensions before considering new protocol designs.  Although this a
   key requirement as we move forward, it does not point to which
   extensions are needed let alone how to devise them.

   Mobile IPv6 [RFC6275], for instance, which is a logically centralized
   mobility management approach addressing primarily hierarchical mobile
   networks, has numerous variants and extensions including, PMIPv6
   [RFC5213], Hierarchical MIPv6 (HMIPv6) [RFC5380], Fast MIPv6 (FMIPv6)
   [RFC5568] [RFC4988], Proxy-based FMIPv6 (PFMIPv6) [RFC5949], just to
   name a few.  These variants or extensions of MIPv6 have been
   developed over the years owing to the different needs that have been
   arising ever since the first MIP specification came into life.  This
   document argues that we can gain much more insight into the design
   space of DMM protocols by abstracting the functionality of existing
   mobility management protocols in terms of logical functions.
   Different variants of existing mobility management protocols can then
   be expressed as different design variations of how these logical
   functions are put together.  The result is a rich framework that can
   express sophisticated functionalities in a more straightforward
   manner.  What is more, this document shows how to reconfigure these
   logical functions towards various distributed mobility management
   designs.

   The rest of this document is organized as follows.  After setting the
   stage with conventions and terminology in the following section,
   Section 3 introduces the framework abstractions, based on common
   functionality we observe in the current crop of mobility management
   protocols.  This includes three logical functions, namely, home
   address allocation, mobility routing and location management.  Such
   functional decomposition will enable us to clearly separate data and
   control plane functionality, and gives us the flexibility in an
   implementation to position said logical functions at their most
   appropriate places in the system design.  Next, Section 4 shows that
   these logical functions can indeed perform the same functions as
   major existing mobility protocols.  These functions therefore become
   the foundation for a unified framework upon which different designs
   of distributed mobility management may be built upon.  Finally,
   Section 5 presents scenarios where the functional aspects of the
   framework are illustrated.

Chan, et al.             Expires August 29, 2013                [Page 3]
Internet-Draft                DMM Framework                February 2013

2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   All general mobility-related terms and their acronyms used in this
   document are to be interpreted as defined in the Mobile IPv6 base
   specification [RFC6275] and in the Proxy Mobile IPv6 specification
   [RFC5213].  This includes terms such as mobile node (MN),
   correspondent node (CN), home agent (HA), home address (HoA), care-
   of-address (CoA), local mobility anchor (LMA), and mobile access
   gateway (MAG).

   In addition, this document uses the following term:

   Home network of an application session (or of an HoA)  is the network
      that has allocated the IP address (HoA) used for the session
      identifier by the application running in an MN.  The MN may be
      attached to more than one home networks.

3.  Mobility Management Logical Functions

   Functional entity (FE) decomposition is an often-used engineering
   approach that enables us to look at the similarities and differences
   of complex systems while keeping track of their important operational
   aspects.  Earlier work, for instance, in the European research
   project Ambient Networks investigated how to create an advanced and
   forward-looking architecture aiming primarily for mobile and wireless
   networks [Book-AN].  A key goal was to design mechanisms that can be
   deployed in a variety of settings (ad-hoc or operator-controlled) and
   scale from small home networks with little human supervision to
   sensor networks deployed over large geographical areas with limited
   resources, to large professionally-managed infrastructure networks.
   The project put forward the concept of the Ambient Control Space
   (ACS) which relies on only three interfaces; interested readers can
   find more details in [Book-AN].

   Within the ACS, novel mobility management mechanisms were developed
   based on the concept of self-containing Functional Entities (FEs)
   which featured well-defined interfaces and interactions with each
   other.  This systematic decomposition enabled the development of
   several mobility management mechanisms which put emphasis on
   different aspects.  Examples of these approaches include the Generic
   Link Layer [Paper-GLL], Multi-radio Resource Management [Paper-MRRM],
   and [Paper-NODEID], which has some similarities with HIP.  Later work
   in this area capitalized on the established FEs within the ACS to

Chan, et al.             Expires August 29, 2013                [Page 4]
Internet-Draft                DMM Framework                February 2013

   define new mechanisms, that were not originally envisioned, such as
   [Paper-ANHASA].

   Following this tradition, this document applies a similar approach to
   logically decomposing mobility management functions.  This way we can
   establish a common framework that will enable us to reason about DMM
   functionality with well-defined and well-understood FEs or logical
   functions.  As a first step, the DMM Framework presented in this
   document demonstrates that the existing mobility management functions
   of MIPv6, PMIPv6, and HMIPv6 can be abstracted into the following
   logical functions:

   1.  Anchoring function: allocation of home network prefix or HoA to
       an MN that registers with the network;

   2.  Mobility Router (MR) function: packets interception and
       forwarding to/from the MN HoA based on the internetwork location
       information, either to the destination or to some other network
       element that knows how to forward the packets to their
       destination;

   3.  Internetwork Location Management (LM) function: managing and
       keeping track of the MN internetwork location, which includes a
       mapping of the HoA to the mobility anchoring point that the MN is
       anchored to;

   4.  Location Update (LU) function: provisioning of MN location
       information to the LM function;

   5.  Routing Control (RC) function: MR function forwarding state
       configuration.

   In addition, the Access Router (AR) logical function provides first-
   hop network access and includes functionality below the network
   layer, e.g. radio communication facilities.  An AR may provide home
   address allocation as well as act as MR.

4.  Mobility Protocol Functional Decomposition

   This section shows that existing mobility management protocols can be
   expressed as different configurations of the logical functions
   introduced in Section 3 above.  Using these generic logical
   functions, we will build up the existing mobility protocols one step
   at a time in the following sequence: MIPv6, PMIPv6, HMIPv6, and HAHA.
   Functions are added and modified as needed in each step.

Chan, et al.             Expires August 29, 2013                [Page 5]
Internet-Draft                DMM Framework                February 2013

4.1.  Decomposing Mobile IPv6

   Fig. 1 illustrates the Mobile IPv6 [RFC6275] functional decomposition
   using the logical functions introduced in Section 3.  The combination
   of the MR, LM and HoA allocation logical functions in Network1
   effectively defines the home agent or the mobility anchor.  In the
   depicted network scenario, the mobile node designated as MN11 was
   originally attached to Network1 and was allocated an IP prefix for
   its home address (HoA11).  At a later stage, MN11 moves to Network3,
   where it is allocated a new prefix to configure the IP address IP32.
   LM1 maintains the binding HoA11:IP32 so that packets from its
   correspondent node CN21 in Network2 destined to HoA11 can be
   intercepted by MR1, which will then tunnel them to IP32.  MN11 must
   perform mobility signaling using the LU function.

    Network1     Network3     Network2
    +-----+
    | LM1 |
    +-----+
   location=IP32
   HoA1 alc      IP3 alc      IP2 alc
       |
       |
    +-----+
    | MR1 |
    +-----+
       .
       .      +----+ +----+    +----+
       .      |MN31| |MN11|    |CN21|
       .      |    | |+LU |    |    |
       .      +----+ +----+    +----+
     HoA11     IP31   IP32,
                      HoA11

   Figure 1.  Functional decomposition of Mobile IPv6

4.2.  From MIPv6 to PMIPv6

   The functional decomposition of Proxy Mobile IPv6 [RFC5213] according
   to the proposed framework is shown in Fig. 2.  In PMIPv6, the
   combination of LM, MR, and HoA allocation effectively defines the
   Local Mobility Anchor (LMA).  The combination of AR and LU together
   with additional signaling with MN comprises the Mobile Access Gateway
   (MAG).  In the figure, MN11 is attached to the access router AR31
   which has the IP address IP31 in Network3.  LM1 maintains the binding
   HoA11:IP31.  The access router AR31 also behaves like a home link to
   MN11 so that MN11 can use its original IP address HoA11.

Chan, et al.             Expires August 29, 2013                [Page 6]
Internet-Draft                DMM Framework                February 2013

    Network1     Network3     Network2
    +-----+
    | LM1 |
    +-----+
   HoA1 alc      IP3 alc      IP2 alc
       |
       |
    +-----+
    | MR1 |
    +-----+
       .
       .      +----+           +----+
       .      |AR31|           |CN21|
       .      |+LU |           |    |
       .      +----+           +----+
     HoA11     IP31
                 |
                 |
              +----+
              |MN11|
              +----+
               HoA11

   Figure 2.  Functional decomposition of PMIPv6

   MIPv6 and PMIPv6 both employ the same concept of separating the
   session identifier (HoA) from the routing address (CoA).  Fig. 3
   contrasts (a) MIPv6 with (b) PMIPv6 by illustrating the destination
   IP address in the network-layer header as a packet traverses the
   network from the CN to the MN.  Note that MIPv6 and PMIPv6 bundle
   three mobility management logical functions, namely, LM1, IP1 prefix
   allocation and MR1 into the home agent (HA) and Local Mobility Anchor
   (LMA), respectively.

   Fig. 3 shows that, as far as data-plane traffic is concerned, routing
   from CN to MN+LU in MIPv6 is similar to the route from CN to AR+LU in
   PMIPv6.  The difference is in that in the former case, the MN with
   the LU function is substituted by the combination of the AR with the
   LU function and the MN.  While additional signaling is needed to
   enable the combination of AR+LU and MN to behave like MN+LU in MIPv6,
   such signaling can be confined between the AR+LU and the MN only.  It
   can therefore be seen under this unified formulation, that a host-
   based mobility management protocol can be translated using this
   substitution into a network-based mobility management protocol and
   vice versa.

Chan, et al.             Expires August 29, 2013                [Page 7]
Internet-Draft                DMM Framework                February 2013

   (a) MIPv6:

   +---+     +---+---+     +---+
   |HoA| --> |HoA|HoA|     |HoA|
   |   |     |   |---|     |---|
   |   |     |   |CoA| ==> |CoA|
   +---+     +---+---+     +---+
    CN          MR         MN+LU

   (b) PMIPv6:
   +---+     +---+---+     +---+---+     +---+
   |HoA| --> |HoA|HoA|     |HoA|HoA| --> |HoA|
   |   |     |   |---|     |---|   |     |   |
   |   |     |   |CoA| ==> |CoA|   |     |   |
   +---+     +---+---+     +---+---+     +---+
    CN          MR           AR+LU         MN

   Figure 3.  Network layer in the protocol stack of packets sent from
   the CN and tunneled (a) to the MN+LU in MIPv6; and (b) to the AR+LU
   in PMIPv6 showing the destination IP address as the packet traverses
   from the CN to the MN.

4.3.  Hierarchical Mobile IPv6

   The functional decomposition of Hierarchical Mobile IPv6 [RFC5380] is
   shown in Fig. 4.  Besides the logical functions LM1, MR1, and HoA1
   prefix allocation in Network1, as we have seen above for MIPv6 and
   PMIPv6, there is an MR function (MR3) in the visited network
   (Network3).  MR3 acts also as a proxy between LM1 and MN11 in the
   hierarchical LM function LM1--MR3--MN11.  That is, LM1 maintains the
   LM binding HoA11:MR3 while MR3 tracks the LM binding HoA11:IP32.  The
   combined function of MR and the LM proxy function is the Mobility
   Anchor Point (MAP).

Chan, et al.             Expires August 29, 2013                [Page 8]
Internet-Draft                DMM Framework                February 2013

    Network1     Network3     Network2
    +-----+
    | LM1 |
    +-----+
   HoA1 alc      IP3 alc      IP2 alc
       |
       |
    +-----+      +-----+
    | MR1 |      | MR3 |
    |     |      |+ LM |
    |     |      |proxy|
    +-----+      +-----+
       .           / \
       .          /   \
       .         /     \
       .      +----+ +----+    +----+
       .      |AR31| |MN11|    |CN21|
       .      |+LU | |+LU |    |    |
       .      +----+ +----+    +----+
     HoA11     IP31   IP32,
                 |    HoA11
                 |
              +----+
              |MN31|
              +----+

   Figure 4.  Functional decomposition of Hierarchical Mobile IPv6

   Note that as depicted in Fig. 4, if MN11 takes the place of MN31
   which is attached to AR31, the resulting mobility management becomes
   network-based.

4.4.  Distributing Mobility Anchors

   As we have seen so far, the framework is sufficiently expressive to
   enable us to decompose the major MIPv6 variants.  It is possible to
   replicate the mobility anchoring function for any of MIPv6, PMIPv6,
   or HMIPv6, in multiple networks as shown in Fig. 5 which illustrates
   such an example with three networks.

Chan, et al.             Expires August 29, 2013                [Page 9]
Internet-Draft                DMM Framework                February 2013

    Network1     Network3     Network2
    +-----+      +-----+      +-----+
    | LM1 |      | LM3 |      | LM2 |
    +-----+      +-----+      +-----+
   HoA1 alc     HoA3 alc     HoA2 alc
       |            |            |
       |            |            |
    +-----+      +-----+      +-----+
    | MR1 |      | MR3 |      | MR2 |
    +-----+      +-----+      +-----+
       .           / \
       .          /   \
       .         /     \
       .      +----+ +----+    +----+
       .      |AR31| |MN11|    |CN21|
       .      |+LU | |+LU |    |    |
       .      +----+ +----+    +----+
     HoA11     IP31   IP32,
                 |    HoA11
                 |
              +----+
              |MN31|
              +----+

   Figure 5.  Distributing mobility anchors using the DMM Framework
   logical functions

4.5.  Migrating Home Agents

   When all logical functions of the Framework are bundled into a single
   entity e.g., a home agent in MIPv6 or a local mobility anchor in
   PMIPv6, in a single network, the result is triangular routing when
   the MN and the CN are in networks close to each other but are far
   from the anchor point.  A method to solve the triangle routing
   problem is to duplicate the anchor points in many networks in
   different geographic locations as advocated in
   [Paper-Migrating.Home.Agents].  A functional decomposition of
   Migrating Home Agents is shown in Fig. 6: the MR function is
   available in each of the three networks Network1, Network2, and
   Network3.  The LM function in each network (LM0) contains the LM
   information for all three networks.  Each MR in each network
   advertises the HoA IP prefixes of all these networks using anycast.
   Traffic from CN21 in Network2 destined to HoA11 will therefore be
   intercepted by the MR nearest to the CN, i.e.  MR2 in the example of
   Fig. 6.  Using the LM information in LM0, MR2 will use the binding
   HoA11:IP32 to tunnel the packets to MN11.

Chan, et al.             Expires August 29, 2013               [Page 10]
Internet-Draft                DMM Framework                February 2013

    Network1     Network3     Network2
    +-----+      +-----+      +-----+
    | LM0 |------| LM0 |------| LM0 |
    +-----+      +-----+      +-----+
   HoA1 alc     HoA3 alc     HoA2 alc
       |            |            |
       |            |            |
    +-----+      +-----+      +-----+
    | MR1 |      | MR3 |      | MR2 |
    +-----+      +-----+      +-----+
       .           / \
       .          /   \
       .         /     \
       .      +----+ +----+    +----+
       .      |AR31| |MN11|    |CN21|
       .      +----+ +----+    +----+
     HoA11     IP31   IP32,
                 |    HoA11
                 |
              +----+
              |MN31|
              +----+

   Figure 6.  Functional decomposition of Migrating Home Agents

   Similarly, traffic originating from MN11 will be served by its
   nearest MR (MR3).  Triangular routing is therefore avoided.  Yet the
   synchronization of all home agents becomes a challenge as discussed
   in [Paper-SMGI].  In addition, the amount of signaling traffic
   necessary for synchronizing the home agents may become excessive when
   both the number of mobile nodes and the number of home agents
   increase.

   As before, if MN11 in Fig. 6 takes the place of MN31 which is
   attached to AR31, the resulting mobility management becomes network-
   based.

5.  DMM Functional Decomposition Scenarios

   This section covers the functional description of DMM.  Basically,
   the scenarios present a way to distribute the logical mobility
   functions.

5.1.  Flat Network Scenario

   In a flat network, the logical functions may all be located at the AR
   as shown in Figs. 7 and 8, respectively.  For example,

Chan, et al.             Expires August 29, 2013               [Page 11]
Internet-Draft                DMM Framework                February 2013

   [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-distributed-anchoring] are
   PMIPv6-based implementations of this scenario.  These two figures
   depict the network- and client-based distributed mobility management
   scenarios, respectively.  AR is expected to support the HoA
   allocation function.  Then, depending on the mobility situation of
   the MN, the AR can run different functions:

   1.  AR can act as a standard IP router;

   2.  AR can provide the MR function (i.e. act as mobility anchor);

   3.  AR can provide the LU function;

   4.  AR can provide both MR and LU functions.

5.1.1.  Network-based Mobility Management

   The functional decomposition of network-based mobility management is
   depicted in Fig. 7.  In case (1), MN1 attaches to AR1.  AR advertises
   the prefix HoA1 to MN1 and then acts as a legacy IP router.  MN1
   initiates a communication with CN11.

   In case (2), MN1 performs a handover from AR1 to AR3 while
   maintaining ongoing IP communication with CN11.  AR1 becomes the
   mobility anchor for the MN1-CN11 IP communication: AR1 runs MR and LM
   functions on behalf of MN1.  AR3 performs LU up to the LM in AR1: AR3
   indicates to AR1 the new location of the MN1.  AR3 allocates a new IP
   prefix (HoA3) for new IP communications.  That is, HoA3 is used for
   all new IP communications, e.g., if MN1 initiates IP communication
   with CN21.  AR3 shall act as a legacy IP router for MN1-CN21
   communication.

   In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP
   communication with CN11 and CN21.  AR1 is the mobility anchor for the
   MN1-CN11 IP communication.  AR3 becomes the mobility anchor for the
   MN1-CN21 IP communication.  Both AR1 and AR3 run MR and LM functions
   for MN1, respectively, anchoring HoA1 and HoA3.  AR2 performs
   location updates up to the LMs in AR1 and AR3 for respectively
   relocate HoA1 and HoA3.

Chan, et al.             Expires August 29, 2013               [Page 12]
Internet-Draft                DMM Framework                February 2013

            Network1                Network1     Network3
+----+     HoA1 alc     +----+     HoA1 alc      HoA3 al        +----+
|CN11|      +-----+     |CN11|      +-----+      +-----+        |CN21|
|    |------|     |     |    |------| MR1 |------|     |------- |    |
+----+      |     |     +----+      | LM1 |------|LU31 |        +----+
            | AR1 |                 | AR1 |      |AR3  |
            |     |                 |     |      |     |
            +-----+                 +-----+      +-----+
               |                                    |
               |                                    |
               |                                    |
             +----+                               +----+
             |MN1 |                               |MN1 |
             |    |                               |    |
             +----+                               +----+
             HoA11                                HoA11,
                                                  HoA31
       (1)                              (2)

                                                      Network2
                              Network1                HoA2 al
                  +----+     HoA1 alc                 +-----+
                  |CN11|      +-----+                 |     |
                  |    |------| MR1 |-----------------|LU21 |-------+
                  +----+      | LM1 |-----------------|AR2  |       |
                              | AR1 |                 |     |       |
                              |     |      Network3   +-----+       |
                              +-----+      HoA3 al     | |        +----+
                                           +-----+     | |        |MN1 |
                               +----+      |MR3  |------ |        |    |
                               |CN21|      |LM3  |--------        +----+
                               |    |------|     |                HoA11,
                               +----+      |AR3  |                HoA31
                                           +-----+       (3)

   Figure 7.  Network-based DMM architecture for a flat network

5.1.2.  Client-based Mobility Management

   The functional decomposition of client-based mobility management is
   depicted in Fig. 8.  In case (1), MN1 attaches to AR1.  AR advertises
   the prefix HoA1 to MN1 and then acts as a legacy IP router.  MN1
   initiates a communication with CN11.

   In case (2), MN1 performs a handover from AR1 to AR3 while
   maintaining ongoing IP communication with CN11.  AR1 becomes the
   mobility anchor for the MN1-CN11 IP communication: AR1 runs MR and LM
   functions for MN1.  The MN performs LU directly up to the LM in AR1

Chan, et al.             Expires August 29, 2013               [Page 13]
Internet-Draft                DMM Framework                February 2013

   or via AR3; in this case AR3 acts as a proxy locator (pLU) (e.g. as a
   FA in MIPv4).  AR3 allocates a new IP prefix (HoA3) for new IP
   communications.  HoA3 is supposed to be used for new IP
   communications, e.g., if MN1 initiates IP communication with CN21.
   AR3 shall act as a legacy IP router for MN1-CN21 communication.

              Network1                Network1     Network3
  +----+     HoA1 alc     +----+     HoA1 alc                     +----+
  |CN11|      +-----+     |CN  |      +-----+      +-----+        |CN21|
  |    |------|     |     |    |------| MR1 |------|     |------- |    |
  +----+      |     |     +----+      | LM1 |------|pLU31|        +----+
              | AR1 |                 | AR1 |      |AR31 |
              |     |                 |     |      |     |
              +-----+                 +-----+      +-----+
                 |                                    |
                 |                                    |
                 |                                    |
               +----+                               +----+
               |MN1 |                               |MN1 |
               |    |                               |LU31|
               +----+                               +----+
               HoA11                                HoA11,
                                                    IP31

        (1)                              (2)
   Figure 8.  Client-based DMM architecture for a flat network

5.2.  DMM with Control and Data Plane Separation

   This section considers a scenario which involves multiple MRs and a
   distributed LM database.  The different use case scenarios of
   distributed mobility management are described in
   [I-D.yokota-dmm-scenario] as well as in
   [Paper-Distributed.Mobility.Review].  The functional decomposition
   described in this document can be used to understand better the data
   and control plane separation.

   Fig. 9 shows an example DMM topology with the same three networks we
   have been using in Fig. 5.  As in Fig. 5, each network in Fig. 9 has
   its own IP prefix allocation function.  In the data plane, the
   mobility routing function is distributed to multiple locations at the
   MRs so that routing can be optimized.  In the control plane, the MRs
   may exchange information with each other.

   In addition to these features, the LM function in Fig. 9 is a
   distributed database, possibly implemented with multiple virtual or
   physical servers, handling the mapping of HoA to CoA.  To perform

Chan, et al.             Expires August 29, 2013               [Page 14]
Internet-Draft                DMM Framework                February 2013

   mobility routing, the MRs need the location information which is
   maintained at LM1, LM2, and LM3.  The MRs are, therefore, the clients
   of the LM servers and may also send location updates to the LM as the
   MNs perform the handover.  The location information may either be
   pulled from the LM servers by the MR, or pushed to the MR by the LM
   servers.  In addition, the MR may also cache a limited amount of
   location information.

    Network1     Network3     Network2
    +-----+      +-----+      +-----+
    | LM1 |      | LM3 |      | LM2 |
    +-----+      +-----+      +-----+
   HoA1 alc     HoA3 alc     HoA2 alc
       | \ \      / | \      / / |
       |  \  \   /  |  \   /  /  |
       |   \   \/   |   \/   /   |
       |    \  / \  |  / \  /    |
       |     \/    \|/    \/     |
       |     /\    /|\    /\     |
       |    /  \ /  |  \ /  \    |
       |   /   /\   |   /\   \   |
       |  /  /   \  |  /   \  \  |
       | / /      \ | /      \ \ |
    +-----+      +-----+      +-----+
    | MR1 |------| MR3 |------| MR2 |
    +-----+      +-----+      +-----+
       .           / \
       .          /   \
       .         /     \
       .      +----+ +----+    +----+
       .      |AR31| |MN11|    |CN21|
       .      |+LU | |+LU |    |    |
       .      +----+ +----+    +----+
     HoA11     IP31   IP32,
                 |    HoA11
                 |
              +----+
              |MN31|
              +----+

   Figure 9.  DMM with Control and Data Plane Separation

   Fig. 9 illustrates three MRs (MR1, MR2, and MR3) in three networks.
   In this scenario we take that MN11 has moved from Network1 supported
   by MR1 and LM1 to Network3 supported by MR3 and LM3.  MN11 may use
   the homa address (HoA11) allocated to it when it was directly
   connected to the former network for those application sessions that

Chan, et al.             Expires August 29, 2013               [Page 15]
Internet-Draft                DMM Framework                February 2013

   were started when the mobile node was attached there and do require
   session continuity after the handover to the latter network.  When
   MN11 is connected to Network1, no location management is needed; LM1
   will not keep an entry for HoA11.  After MN11 handovers to Network3,
   the LM1 server maintains a mapping of HoA11 to MR3.  That is, LM1
   points to Network3 and it is this network that will keep track of how
   to reach MN11.  Such a hierarchical mapping can prevent frequent
   signaling updates to LM1, as MN11 performs intra-network handover(s)
   within the Network3 domain.  In other words, the concept of
   hierarchical mobile IP [RFC5380] is applied here for location
   management only but not for data plane routing.

6.  Security Considerations

   TBD

7.  IANA Considerations

   This document presents no IANA considerations.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [Book-AN]  Niebert, N., Schieder, A., Zander, J., and R. Hancock
              (Eds.), "Ambient networks: co-operative mobile networking
              for the wireless world.",  Wiley, 2007.

   [I-D.bernardos-dmm-distributed-anchoring]
              Bernardos, CJ. and JC. Zuniga, "PMIPv6-based distributed
              anchoring", draft-bernardos-dmm-distributed-anchoring-01
              (work in progress), September 2012.

   [I-D.ietf-dmm-requirements]
              Chan (Ed.) et al., H., "Requirements for Distributed
              Mobility Management", draft-ietf-dmm-requirements-03 (work
              in progress), December 2012.

   [I-D.seite-dmm-dma]
              Seite, P., Bertin, P., and JH. Lee, "Distributed Mobility

Chan, et al.             Expires August 29, 2013               [Page 16]
Internet-Draft                DMM Framework                February 2013

              Anchoring", draft-seite-dmm-dma-06 (work in progress),
              January 2013.

   [I-D.yokota-dmm-scenario]
              Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
              scenarios for Distributed Mobility Management",
              draft-yokota-dmm-scenario-00 (work in progress),
              October 2010.

   [Paper-ANHASA]
              Pentikousis, K., Aguero, R., Gebert, J., Galache, J.,
              Blume, O., and P. Paakkonen, "The Ambient Networks
              heterogeneous access selection architecture",  Mobility,
              Multiaccess, and Network Management (M2NM) 2007. First
              Ambient Networks Workshop on. Sydney, Australia, October
              2007, pp. 49-54, October 2007.

   [Paper-Distributed.Mobility.PMIP]
              Chan, H., "Proxy Mobile IP with Distributed Mobility
              Anchors",  Proceedings of GlobeCom Workshop on Seamless
              Wireless Mobility, December 2010.

   [Paper-Distributed.Mobility.Review]
              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
              "Distributed and Dynamic Mobility Management in Mobile
              Internet: Current Approaches and Issues", February 2011.

   [Paper-GLL]
              Koudouridis, G., Aguero, R., Alexandri, E., Choque, J.,
              Dimou, K., Karimi, H., Lederer, H., Sachs, J., and R.
              Sigle, "Generic link layer functionality for multi-radio
              access networks",  Proc. IST Mobile and Wireless
              Communication Summit 2005., 2005.

   [Paper-MRRM]
              Berggren, F., Bria, A., Badia, L., Karla, I., Litjens, R.,
              Magnusson, P., Meago, F., Tang, H., and R. Veronesi,
              "Multi-radio resource management for ambient networks",
               Personal, Indoor and Mobile Radio Communications (PIMRC)
              2005. IEEE 16th International Symposium on. Vol. 2, pp.
              942-946, 2005.

   [Paper-Migrating.Home.Agents]
              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
              Agents Towards Internet-scale Mobility Deployments",
               Proceedings of the ACM 2nd CoNEXT Conference on Future
              Networking Technologies, December 2006.

Chan, et al.             Expires August 29, 2013               [Page 17]
Internet-Draft                DMM Framework                February 2013

   [Paper-NODEID]
              Ahlgren, B., Eggert, L., Ohlman, B., and A. Schieder,
              "Ambient networks: Bridging heterogeneous network
              domains",  Personal, Indoor and Mobile Radio
              Communications (PIMRC) 2005. IEEE 16th International
              Symposium on. Vol. 2, pp. 937-941, 2005.

   [Paper-SMGI]
              Zhang, L., Wakikawa, R., and Z. Zhu, "Support Mobility in
              the Global Internet",  Proceedings of ACM Workshop on
              MICNET, MobiCom 2009, Beijing, China, September 2009.

   [RFC4988]  Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
              RFC 4988, October 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.

   [RFC5568]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

   [RFC5949]  Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
              September 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

Authors' Addresses

   H Anthony Chan
   Huawei Technologies
   5340 Legacy Dr. Building 3
   Plano, TX 75024
   USA

   Email: h.a.chan@ieee.org

Chan, et al.             Expires August 29, 2013               [Page 18]
Internet-Draft                DMM Framework                February 2013

   Pierrick Seite
   France Telecom - Orange
   4, rue du Clos Courtel, BP 91226
   Cesson-Sevigne 35512
   France

   Email: pierrick.seite@orange-ftgroup.com

   Kostas Pentikousis
   Huawei Technologies
   Carnotstrasse 4
   10587 Berlin
   Germany

   Email: k.pentikousis@huawei.com

Chan, et al.             Expires August 29, 2013               [Page 19]