| Network Working Group | H. Chan |
| Internet-Draft | Huawei Technologies |
| Intended status: Informational | July 2012 |
| Expires: December 31, 2012 |
A unified mobility management protocol framework and DMM gap analysis
draft-chan-dmm-framework-gap-analysis-00
This draft proposes a unified framework of mobility management in terms of abstracted logical functions. It is shown that mip, pmip, and several of their extensions can be expressed in terms of different configurations of these logical functions. Such a unified framework provides a convenient view on gap analysis of existing protocols, and also on the needed re-configurations of the logical functions as well as the needed extensions towards distributed mobility management.
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 December 31, 2012.
Copyright (c) 2012 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 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.
While there are research on new protocols for distributed mobility management it has also been proposed, e.g., in [Paper-Distributed.Mobility.PMIP] and in many other publications, that distributed mobility management can be designed using primarily the existing mobility management protocols with extensions. A requirement in distributed mobility management is to first use existing protocols and their extensions before considering new protocol design.
Mobile IP [RFC6275] , which has primarily been deployed in a centralized manner for the hierarchical mobile networks, has numerous variants and extensions including PMIP [RFC5213] , hierarchical MIP (HMIP) [RFC5380] , Fast MIP (FMIP) [RFC4068] [RFC4988] , Proxy-based FMIP (PFMIP) [RFC5949] and more. These different modifications or extensions of MIP have been developed over the years owing to the different needs that are found afterwards.
It is convenient to abstract the functions of existing mobility management protocols in terms of logical functions. Different variants of existing mobility management protocols are then different design variations of how the logical functions are configured. The result is a convenient framework to perform gap analysis of the existing protocols, and to reconfigure these logical functions towards various distributed mobility management design.
Session 3 proposes to decouple the logical functions of a local mobility anchor into that of home address allocation, location management, and mobility routing. Such decoupling enables separation between the data plane and the control plane, and enables flexibility for the implementation to place the logical functions at their most appropriate locations. When using MIP, PMIP, and their extensions, the logical functions are a decomposition or classification of the functions of these existing mobility protocols. Yet it provides a framework upon which different designs of distributed mobility may be constructed.
Session 4 shows how the different existing protocols can be expressed as different design configurations of the generic logical functions. In a distributed architecture, the mobility routing function may be present in many geographical locations to support dynamic mobility management and to route more directly to avoid triangle routing in the data plane. However, the internetwork location management function may be kept only at the network where the mobile node is running a session using the IP address allocated from that network. The individual location management information for a specific mobile node may be acquired whenever needed.
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 the 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]. These terms include mobile node (MN), correspondent node (CN), home agent (HA), local mobility anchor (LMA), and mobile access gateway (MAG).
In addition, this draft introduces the following terms.
The existing mobility management functions of MIP, PMIP, and HMIP may be abstracted into the following logical functions to provide a unified framework of existing mobility management and to allow a more flexible design to achieve DMM. These logical functions are as follows:
MIP and PMIP both employ the same concept of separating session identifier and routing address into the HoA and CoA respectively. Figure 1 compares (a) MIP and (b) PMIP by showing the destination IP address in the network-layer header as a packet traverses from a CN to an MN.
Subsequent packets
(a) MIP:
+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|
| | | |---| |---|
| | | |CoA| ==> |CoA|
+---+ +---+---+ +---+
CN anchor MN
(b) PMIP:
+---+ +---+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|HoA| --> |HoA|
| | | |---| |---| | | |
| | | |C0A| ==> |CoA| | | |
+---+ +---+---+ +---+---+ +---+
CN anchor MAG MN
Figure 1. Network layer in the protocol stack of subsequent packets sent from the CN and tunneled to the MAG showing the destination IP address as the packet traverses from the CN to the MN.
The comparison shows that, as far as the data-plane traffic is concerned, the route from CN to MN in MIP is similar to the route from CN to MAG in PMIP. The difference is only in replacing the MN in MIP with the MAG-MN combination. Therefore, the architecture using MIP can be adapted to the architecture using PMIP by replacing the MN with the MAG-MN combination.
Mobile IP and Proxy mobile IP bundle all these three mobility management functions into the home agent or mobility anchor. When all these logical functions are bundled into one single entity known as the home agent in Mobile IP and as the local mobility anchor in Proxy Mobile IP, having this anchor in only one network results in triangle routing as shown in Figure 2.
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) ( ) ( )
( ) ( ) ( )
v v v v v v v v v
MN CN
Figure 2. Figure showing the triangle routing problem with a MN and a CN in networks which may be close to each other but are far from the anchor points (LMA or HA).
The DMM architecture such as that shown in Figure 6 therefore applies equally well to both host-based and network-based mobility management. The difference in the network-based mobility management is in inserting a proxy function between the MR and the MN, and this function may be located at the access router which then becomes the mobile access gateway as that defined in PMIP.
A method to solve the triangle routing problem is to duplicate the anchor points in many networks (Figure 3) in different geographic locations. In [GHAHA], these anchor points (home agents) announce the same IP prefixes using anycast. The traffic originating from the mobile node will then be served by the nearest anchor point, and the traffic sent from a correspondent node to the mobile node will be intercepted by the anchor point nearest to the correspondent node. Therefore both traffic will use the anchor point nearest to where the traffic originates, so that triangle routing is avoided. These anchor points may possess identical information about the mobile nodes [Paper-Migrating.Home.Agents]. Yet the synchronization of all the home agents will then be a challenge [Paper-SMGI]. In addition, the amount of signaling traffic needed in synchronizing the home agents may become excessive when the number of mobile nodes and the number of home agents both increase.
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) (anchor) (anchor)
( ) ( ) ( )
v v v v v v v v v
MN CN
Figure 3. Figure showing the replication of mobility anchors in multiple networks.
Decoupling the functions of the anchoring point into the logical functions allow more flexibility.
As illustrated in Figure 4, having the mobility routing (MR) function available in multiple networks will solve the triangle routing problem. It is also evident that the network which has allocated the HoA of an MN may also manage the internetwork location information of the MN. Yet pushing this internetwork location management (LM) information to all the other networks may be an overkill, especially when the mobile node does not always actually communicate with any CNs in many other networks. Keeping the location management function at the home network of the HoA will eliminate the need to synchronize the location management information in a timely and scalable manner. Each network may then maintain the location management information of the HoA for which it has allocated the home network prefix. The different such information servers in different networks may work together to constitute a distributed database. That is, the data in each server of the distributed database need not be pushed to all the other servers but the database system only needs to know which data resides in which server.
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( LM(HoA) ) ( ) ( )
( MR ) ( MR ) ( MR )
( ) ( ) ( )
v v v v v v v v v v v v
MN(HoA) CN
Figure 4. Figure showing the mobility routing (MR) function available in many networks, whereas the dynamic internetwork location management (LM) function of an MN using an HoA address resides only in the network that has allocated the network prefix of the HoA.
The fifth DMM requirement is on existing mobility protocols.
REQ5: A DMM solution SHOULD first consider reusing and extending the existing mobility protocols before specifying new protocols.
Abstracting the existing protocol functions into logical functions in this draft is a way to see how one can maximize the use of existing protocols. It remains to be seen whether all the DMM requirements can be met. One needs to check the rest of the requirements to check for gaps.
The second part of the fourth DMM requirement is on compatibility:
REQ4: The DMM solution SHOULD be able to work between trusted administrative domains when allowed by the security measures deployed between these domains. Furthermore, the DMM solution MUST be able to co-exist with existing network deployment and end hosts so that the existing deployment can continue to be supported. For example, depending on the environment in which dmm is deployed, the dmm solutions may need to be compatible with other existing mobility protocols that are deployed in that environment or may need to be interoperable with the network or the mobile hosts/routers that do not support the dmm enabling protocol.
The first DMM requirement is on Distributed deployment IP mobility.
REQ1:network access and routing solutions provided by DMM MUST enable a distributed deployment of mobility management of IP sessions so that the traffic can be routed in an optimal manner without traversing centrally deployed mobility anchors.
Multiple MRs are allowed in MIP by simply having an HA for each home network. It is shown in terms of the logical functions as in Figure 5.
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| | |
| | |
| | |
| | |
| | |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
Figure 5. A distributed architecture of mobility management.
To see how to avoid traversing centralized deployed mobility anchors, let us look at the second requirement on non-optimal routes.
REQ2: The DMM solutions MUST provide transparency above the IP layer when needed. Such transparency is needed, when the mobile hosts or entire mobile networks [RFC3963] change their point of attachment to the Internet, for the application flows that cannot cope with a change of IP address. Otherwise the support to maintain a stable home IP address or prefix during handover may be declined.
In order to avoid traveling long routes after the MN has moved to a new network, such long routes can be avoided by simply using the new network as the home network for new sessions. The sessions that had already started in the previous network would still need to use the original network the session had started as the home network. There may then be different IP sessions using different IP prefixes/addresses in the same MN.
The capability to use different IP addresses for different IP sessions are therefore needed.
The assoication with the HoA of a MN is not sufficient to support the above use of IP for an application. This gap can be overcome by generalization the concept of HoA to that of an application running on the MN rather than the MN as will be discussed in Section 6.1 below.
Using the dynamic mobility management scheme has avoid routing back to the home network when the application does not have such need. There are however application sessions that had originated from a prior network and that also requires mobility support. Longer routes than the natural IP route can be encountered. Route optimization schemes already exist, but one needs to deal with multiple HA's when using multiple HA's.
One generalization in terms of the unified framework is that the LM functions can be considered as a distributed database as will be shown in the next section. There, the MN and the LM has a client-server relationship, with optionally a proxy in between and the proxy can co-locate with an MR. A distributed database may have different servers to store different data. Yet, each client needs to be able to query the database.
The existing functions such as BU and BA can be considered as the database function to update a record. Completing the design of messages of the database functions will enable the distributed database design.
In the unified scheme complete with database function and mobility routing function, numerous route optimizations can be designed as described in Section 7.
The third DMM requirement on IPv6 deployment
REQ3: The DMM solutions SHOULD target IPv6 as primary deployment and SHOULD NOT be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used.
is not an issue with the MIPv6, PMIPv6 and their extensions. Using the unified scheme here based on abstracting these existing protocol functions will meet the DMM requirements.
The first part of the fourth requirement as well as the sixth DMM requirement are on security considerations.
REQ6: The protocol solutions for DMM MUST consider security, for example authentication and authorization mechanisms that allow a legitimate mobile host/router to access to the DMM service, protection of signaling messages of the protocol solutions in terms of authentication, data integrity, and data confidentiality, opti-in or opt-out data confidentiality to signaling messages depending on network environments or user requirements.
are on security. It is preferred that these security requirements be considered as an integral part of the DMM design.
The different use case scenarios of distributed mobility management are described in [I-D.dmm-scenario] as well as in [Paper-Distributed.Mobility.Review]. The architecture described in this draft is mainly on separating the data plane and the control plane.
Fig. 6 shows an architecture of DMM. The figure shows, as an example, three networks. Each network has its own IP prefix allocation function which is not explicitly shown in the figure. 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 signal with each other, and the LM function is a distributed database, with multiple servers, of the mapping of HoA to CoA.
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
Figure 6. A distributed architecture of mobility management.
To perform mobility routing, the MRs need the location information which is maintained at the LMs. The MRs are therefore the clients of the LM servers and may also send location updates to the LM as the MNs perform 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.
This figure shows three MRs (MR1, MR2, and MR3) in three networks. MN11 has moved from the first network supported by MR1 and LM1 to the third network supported by MR3 and LM3. It may use an HoA (HoA11) allocated to it when it was in the first network for those application sessions that had already started when MN11 was attached there and that require session continuity after handover to the third network. When MN11 was in the first network, no location management is needed so that LM1 will not keep an entry of HoA11. After MN11 has performed handover to the third network, the database server LM1 keeps a mapping of HoA11 to MR3. That is, it points to the third network and it is the third network that will keep track of how to reach MN11. Such an hierarchical of mapping can avoid frequent update signaling to LM1 as MN11 performs intra-network handover within the third network. In other words, the concept of hierarchical mobile IP [RFC5380] is applied here but only in location management and not in routing in the data plane.
The above distributed architecture, which has an MR and an HoA allocation function in each network, enables dynamic mobility management.
When new applications are started after moving to a new network, the device can simply use a new IP address allocated by the new network. Dynamic mobility management, i.e., invoking mobility management only when needed, has been proposed in [Paper-Distributed.Dynamic.Mobility].
[I-D.seite-dmm-dma] describes the dynamic mobility management using PMIP. There the MR, LM, and the HoA allocation functions are co-located at the access router in a flattened network.
[Paper-Net.based.DMM], or equivalently the draft [I-D.seite-dmm-dma], also describes dynamic mobility management in which the MR and the HoA allocation function are both co-located at the access router whereas the LM information in each of these access routers are linked together under the hierarchy of a centralized LM server.
[I-D.ma-dmm-armip] again describes dynamic mobility management in which the MR and the HoA allocation function are both co-located at the access router.
The distributed mobility architecture compared with a centralized approach is more convenient to achieve dynamic mobility management. In Fig. 6 above, the LM function and the IP address allocation function may communicate with each other or may co-locate. The device MN11 may simply be using a dynamic IP address which is leased from the network with a finite lifetime of say 24 hours. As MN11 leaves the first network and attaches to the third network, it may or may not have ongoing sessions requiring session continuity. If it does not, there is no need for LM1 to keep the binding. If it does, it may use the existing MIP signaling mechanism so that the LM1 will keep the binding HoA11:MR3. When all the ongoing sessions requiring session continuity have terminated, it is possible for MN11 to deregister with LM1. Yet one may not assume the device will always perform the de-registration. Alternatively the lease of the dynamic IP address HoA11 will expire upon which LM1 will remove the binding.
In the event that the ongoing session outlives the lease of the HoA11, MN11 will need to renew the lease with the IP address allocation function in the first network.
Because a MN may run multiple applications each using a different IP address, there can be multiple HoAs belong to different networks. Therefore the notion of home network may be generalized to that of an application session or the IP address used by that session as an HoA. Then the home network of an application session is simply the network that has allocated the IP address used as the session identifier (HoA) by the application run in an MN.
The distributed architecture has already enabled dynamic mobility management, as is described in [I-D.seite-dmm-dma], even when the routes are not optimized. Route optimization mechanism can be achieved in addition to dynamic mobility.
With the above architecture, there are a number of ways to enable reachability of an MN by packets sent from a CN using the mobility routing function.
The target to avoid unnecessarily long route is the direct route instead of a triangular route. In general, when a packet is sent from a CN in one network to a MN in another network, the direct route consists of the following 3 routing segments (RS):
One may therefore examine the route optimization mechanism in terms of these 3 routing segments. In the first segment RS1:CN-MR(CN), the alternatives are:
In the second segment RS2.MR(CN)-MR(MN), the alternatives are:
In the final segment RS3.MR(MN)-MN, the MR may keep track of the location of MN and route to it using its intra-network mobility management mechanism.
Different designs using the above architecture can be made by taking different combinations of the different designs in the different route segments. For example, the overall design of DMM may be:
TBD
None
This document has benefited from discussions with Frank Xia, Justin Xiang, Hanan Ahmed, and others.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6275] | Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. |
| [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. |
| [RFC5949] | Yokota, H., Chowdhury, K., Koodli, R., Patil, B. and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010. |
| [RFC4068] | Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. |
| [RFC4988] | Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", RFC 4988, October 2007. |
| [I-D.dmm-scenario] | Yokota, H, Seite, P, Demaria, E and Z Cao, "Use case scenarios for Distributed Mobility Management", Internet-Draft draft-yokota-dmm-scenario-00, October 2010. |
| [I-D.distributed-lma] | Chan, H, Xia, F, Xiang, J and H Ahmed, "Distributed Local Mobility Anchors", Internet-Draft draft-chan-netext-distributed-lma-03, March 2010. |
| [I-D.seite-dmm-dma] | Seite, P and P Bertin, "Distributed Mobility Anchoring", Internet-Draft draft-seite-dmm-dma-00, February 2012. |
| [I-D.dmm-nat-phl] | Liebsch, M, "Per-Host Locators for Distributed Mobility Management", Internet-Draft draft-liebsch-mext-dmm-nat-phl-00, October 2011. |
| [I-D.ma-dmm-armip] | Ma, Z and X Zhang, "An AR-level solution support for Distributed Mobility Management", Internet-Draft draft-ma-dmm-armip-00, February 2012. |
| [I-D.liu-dmm-pmip-based-approach] | Liu, D, Song, J and W Luo, "PMIP Based DMM Approaches", Internet-Draft draft-liu-dmm-pmip-based-approach-02, March 2012. |
| [I-D.luo-dmm-pmip-based-dmm-approach] | Luo, W and J Liu, "PMIP Based DMM Approaches", Internet-Draft draft-luo-dmm-pmip-based-dmm-approach-01, March 2012. |
| [I-D.bernardos-dmm-pmip] | Bernardos, C, Oliva, A, Giust, F, Melia, T and R Costa, "A PMIPv6-based solution for Distributed Mobility Management", Internet-Draft draft-bernardos-dmm-pmip-01, March 2012. |
| [I-D.patil-dmm-issues-and-approaches2dmm] | Patil, B, Williams, C and J Korhonen, "Approaches to Distributed mobility management using Mobile IPv6 and its extensions", Internet-Draft draft-patil-dmm-issues-and-approaches2dmm-00, March 2012. |
| [I-D.jikim-dmm-pmip] | Kim, J, Koh, S, Jung, H and Y Han, "Use of Proxy Mobile IPv6 for Distributed Mobility Management", Internet-Draft draft-jikim-dmm-pmip-00, March 2012. |
| [Paper-Distributed.Dynamic.Mobility] | Bertin, P, Bonjour, S and J-M Bonnin, "A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures", Proceedings of 3rd International Conference on New Technologies, Mobility and Security (NTMS), 2008. |
| [Paper-Net.based.DMM] | Giust, F, de la Oliva, A, Bernardos, CJ and RPF Da Costa, "A network-based localized mobility solution for Distributed Mobility Management", Proceedings of 14th International Symposium on Wireless Personal Multimedia Communications (WPMC), October 2011. |
| [Paper-Distributed.Centralized.Mobility] | Bertin, P, Bonjour, S and J-M Bonnin, "Distributed or Centralized Mobility?", Proceedings of Global Communications Conference (GlobeCom), December 2009. |
| [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. |
| [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-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.Management] | Chan, H, "Distributed Mobility Management with Mobile IP", Proceedings of IEEE ICC 2012 Workshop on Telecommunications: from Research to Standards, June 2012. |
| [MHA] | 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, Lisboa, Portugal, December 2006. |
| [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. |