Network Working Group H. Chan Internet-Draft Huawei Technologies Intended status: Informational October 16, 2012 Expires: April 19, 2013 A unified mobility management protocol framework and DMM gap analysis draft-chan-dmm-framework-gap-analysis-03 Abstract 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. 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 April 19, 2013. Copyright Notice 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 Chan Expires April 19, 2013 [Page 1] Internet-Draft DMM-framework-gap-analysis October 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2.1. Conventions used in this document . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Logical functions of mobility management . . . . . . . . . . . 6 4. Functional represenation of existing mobility protocols . . . 6 4.1. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. MIP versus PMIP . . . . . . . . . . . . . . . . . . . . . 7 4.3. Hierarchical Mobile IP . . . . . . . . . . . . . . . . . . 9 4.4. Multiple home networks . . . . . . . . . . . . . . . . . . 10 4.5. Migrating home agents . . . . . . . . . . . . . . . . . . 11 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Gap analysis with respect to the requirements . . . . . . 13 5.1.1. Considering existing protocols first . . . . . . . . . 13 5.1.2. Compatibility . . . . . . . . . . . . . . . . . . . . 13 5.1.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . 13 5.1.4. Security considerations . . . . . . . . . . . . . . . 14 5.1.5. Distributed deployment . . . . . . . . . . . . . . . . 14 5.1.6. Transparency to Upper Layers when needed . . . . . . . 15 5.1.7. Route optimization . . . . . . . . . . . . . . . . . . 16 5.2. Gap analysis on the mobility protocols . . . . . . . . . . 16 5.2.1. Gap analysis with the unified framework . . . . . . . 16 5.2.2. Gap analysis with MIPv6 . . . . . . . . . . . . . . . 17 5.2.3. Gap analysis with PMIPv6 . . . . . . . . . . . . . . . 17 5.2.4. Gap analysis with HMIPv6 . . . . . . . . . . . . . . . 17 5.2.5. Gap analysis with Multiple home networks . . . . . . . 18 5.2.6. Gap analysis with HAHA . . . . . . . . . . . . . . . . 18 5.2.7. Gap analysis with Dynamic mobility management . . . . 18 5.2.8. Gap analysis with Multiple MRs and distributed LM database . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.9. Gap analysis with Route optimization mechanisms . . . 19 6. Dynamic mobility management . . . . . . . . . . . . . . . . . 19 6.1. Home network of an application session . . . . . . . . . . 21 7. Multiple MRs and distributed LM database . . . . . . . . . . . 21 8. Route optimization mechanisms . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 Chan Expires April 19, 2013 [Page 2] Internet-Draft DMM-framework-gap-analysis October 2012 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Chan Expires April 19, 2013 [Page 3] Internet-Draft DMM-framework-gap-analysis October 2012 1. Introduction 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 designs. 1.1. Overview Section 3 proposes to abstract the existing mobility management protocols functions into the logical functions of home address allocation, mobility routing, location management, and proxy. 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. Section 4 shows that the logical functions can indeed perform the same functions as the major existing mobility protocols. These functions therefore enables a unified framework upon which different designs of distributed mobility may be constructed. Section 5 presents the gap analysis of the existing protocols by comparing them against the DMM requirements of first taking advantage of existing protocols, compatibility, distributed deployment, dynamically providing mobility support, route optimization, IPv6 deployment, and security considerations. Extensions to overcome the gaps are illustrated in Sections 6-8. Chan Expires April 19, 2013 [Page 4] Internet-Draft DMM-framework-gap-analysis October 2012 With the unified framework, extensions to dynamically provide mobility support is described in Section 6 where the home IP address of an MN is generalized to that of an application session. A distributed database architecture is described in Section 7. Using this distributed architecture, various route optimization can be achieved as is described in Section 8. 2. Conventions and Terminology 2.1. Conventions used in this document 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]. 2.2. Terminology 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. Mobility routing (MR) is the logical function to intercept packets to/from the HoA of a mobile node and to forward the packets, based on the internetwork location information, either to the destination or to some other network element that knows how to forward to the destination. Home address allocation is the logical function to allocate the home network prefix or home address to a mobile node. Location management (LM) is the logical function to manage and keep track of the internetwork location information of a mobile node, which include a mapping of the HoA of the MN to the routing address of the MN or another network element that knows how to forward packets towards the MN. Optionally, one (or more) proxy may exist between LM and MN so that the LM function is maintained in the hierarchy LM-proxy-MN. Then to the LM, the proxy behaves like the MN; to the MN, the proxy behaves like the LM. Chan Expires April 19, 2013 [Page 5] Internet-Draft DMM-framework-gap-analysis October 2012 Home network of an application session (or an HoA IP address) (LM) is the network that has allocated the IP address used as the session identifier (HoA) by the application being run in an MN. Because a MN may run multiple applications each using a different HoA, the notion of the home network may be generalized to that of an application session rather than that of a MN. 3. Logical functions of mobility management 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: 1. allocation of home network prefix or HoA to a MN that registers with the network; 2. mobility routing (MR) function: intercepting packets to/from the HoA of the MN and forwarding the packets, based on the internetwork location information, either to the destination or to some other network element that knows how to forward to the destination. and 3. internetwork location management (LM) function: managing and keeping track of the internetwork location of a MN, which include a mapping of the HoA to the mobility anchoring point that the MN is anchored to; (Optionally, one (or more) proxy may exist between LM and MN so that the LM function is maintained in the hierarchy LM-proxy-MN. Then to the LM, the proxy behaves like the MN; to the MN, the proxy behaves like the LM.) 4. Functional represenation of existing mobility protocols This section shows that the existing mobility management protocols can be expressed as different configurations of the above logical functions in a unified framework. Using the generic functions, we will build up the existing mobility protocols in steps in the following sequence: MIPv6, PMIPv6, HMIPv6, and HAHA. The functions are added and modified a little at a time as we move from one protocol to the next. Chan Expires April 19, 2013 [Page 6] Internet-Draft DMM-framework-gap-analysis October 2012 4.1. Mobile IP Figure 1 shows Mobile IPv6 [RFC6275] in the functional representation. A mobile node MN11 was originally attached to the first network (Network1) and was allocated the IP prefix for HoA11. Now, MN11 has moved to Network3, from which it is allocated a new IP address IP32. LM1 keeps the binding HoA11: IP32 so that packets from CN21 in Network2 destined to HoA11 will be intercepted by MR1, which will then tunnel the packet to IP32. Network1 Network3 Network2 +-----+ | LM1 | +-----+ HoA1 alc IP3 alc IP2 alc | | +-----+ | MR1 | +-----+ . . +----+ +----+ +----+ . |MN31| |MN11| |CN21| . +----+ +----+ +----+ HoA11 IP31 IP32, HoA11 Figure 1. Functional representation of Mobile IP. 4.2. MIP versus PMIP MIP and PMIP both employ the same concept of separating session identifier and routing address into the HoA and CoA respectively. Figure 2 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. Chan Expires April 19, 2013 [Page 7] Internet-Draft DMM-framework-gap-analysis October 2012 (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 2. Network layer in the protocol stack of packets sent from the CN and tunneled (a) to the MN in MIP; and (b) to the MAG in PMIP 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 in PMIP. 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 the three mobility management logical functions: LM1, IP1 prefix allocation, and MR1 into the home agent and local mobility anchor respectively. The functional representation of Proxy mobile IPv6 [RFC5213] is shown in Figure 3. Here MN11 is attached to the access router AR31 which has the IP address IP31 in Network3. LM1 keeps 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 Expires April 19, 2013 [Page 8] Internet-Draft DMM-framework-gap-analysis October 2012 Network1 Network3 Network2 +-----+ | LM1 | +-----+ HoA1 alc IP3 alc IP2 alc | | +-----+ | MR1 | +-----+ . . +----+ +----+ +----+ . |AR31| |MN32| |CN21| . +----+ +----+ +----+ HoA11 IP31 IP32 | | +----+ |MN11| +----+ HoA11 Figure 3. Functional representation of PMIP. 4.3. Hierarchical Mobile IP The functional representation of Hierarchical Mobile IPv6 [RFC5380] is shown in Figure 4. Chan Expires April 19, 2013 [Page 9] Internet-Draft DMM-framework-gap-analysis October 2012 Network1 Network3 Network2 +-----+ | LM1 | +-----+ HoA1 alc IP3 alc IP2 alc | | +-----+ +-----+ | MR1 | | MR3 | +-----+ +-----+ . / \ . / \ . / \ . +----+ +----+ +----+ . |AR31| |MN11| |CN21| . +----+ +----+ +----+ HoA11 IP31 IP32, | HoA11 | +----+ |MN31| +----+ Figure 4. Functional representation of Hierarchical Mobile IP. Besides the logical functions: LM1, MR1, and HoA1 prefix allocation in Network1 as MIP in Figure 2 and PMIP in Figure 3, there is an MR function (MR3) in the visited network (Network3). The MR3 is also a proxy between LM1 and MN11 in the hierchical LM function LM1--MR3-- MN11. That is, LM1 keeps the LM binding HoA11:MR3 and MR3 keeps the LM binding HoA11:IP32. In Figure 4, if MN11 takes the place of MN31 which is attached to AR31, the resulting mobility management becomes network-based. 4.4. Multiple home networks In any of MIPv6, PMIPv6, or HMIPv6, there is no restriction that only one network is the home network. It is possible to repeat the deployment of the home network functions in multiple networks as shown in Figure 5. Chan Expires April 19, 2013 [Page 10] Internet-Draft DMM-framework-gap-analysis October 2012 Network1 Network3 Network2 +-----+ +-----+ +-----+ | LM1 | | LM3 | | LM2 | +-----+ +-----+ +-----+ HoA1 alc HoA3 alc HoA2 alc | | | | | | +-----+ +-----+ +-----+ | MR1 | | MR3 | | MR2 | +-----+ +-----+ +-----+ . / \ . / \ . / \ . +----+ +----+ +----+ . |AR31| |MN11| |CN21| . +----+ +----+ +----+ HoA11 IP31 IP32, | HoA11 | +----+ |MN31| +----+ Figure 5. Functional representation of multiple home networks. 4.5. Migrating home agents 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 when the MN and the CN are in networks close to each other but are far from the anchor points. A method to solve the triangle routing problem is to duplicate the anchor points in many networks in different geographic locations as in [Paper-Migrating.Home.Agents]. A functional representation of Migrating Home Agents is shown in Figure 6. Chan Expires April 19, 2013 [Page 11] Internet-Draft DMM-framework-gap-analysis October 2012 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 representation of Migrating Home Agents. Here, 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 of all the 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 CN, which is MR2. Using the LM information in LM0 MR2 will using the binding HoA11:IP32 to tunnel the packet to MN11. Similarly, traffic originating from MN11 will be served by its nearest MR (MR3). Trianle routing is therefore avoided. 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. As before, if MN11 in Figure 6 takes the place of MN31 which is attached to AR31, the resulting mobility management becomes network- based. Chan Expires April 19, 2013 [Page 12] Internet-Draft DMM-framework-gap-analysis October 2012 5. Gap analysis 5.1. Gap analysis with respect to the requirements 5.1.1. Considering existing protocols first The fourth DMM requirement is on existing mobility protocols. REQ4: A DMM solution SHOULD first consider reusing and extending IETF-standardized 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. 5.1.2. Compatibility The first part of the fifth DMM requirement is on compatibility: REQ5: (first part) The DMM solution MUST be able to co-exist with existing network deployments and end hosts. For example, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols or may need to interoperate with a network or mobile hosts/routers that do not support DMM protocols. Different deployments using the same abstract functions can be compatible with each other if their functions use the same messaging between these functions. 5.1.3. IPv6 deployment The third DMM requirement on IPv6 deployment. REQ3: DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. will not be 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. Chan Expires April 19, 2013 [Page 13] Internet-Draft DMM-framework-gap-analysis October 2012 5.1.4. Security considerations The first part of the fourth requirement as well as the sixth DMM requirement REQ5 (second part): Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. REQ6: DMM protocol solutions MUST consider security aspects, including confidentiality and integrity. Examples of aspects to be considered are authentication and authorization mechanisms that allow a legitimate mobile host/router to use the mobility support provided by the DMM solution; signaling message protection in terms of authentication, encryption, etc.; data integrity and confidentiality; opt-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. 5.1.5. Distributed deployment The first DMM requirement has 2 parts. The first part is on distributed deployment whereas the second part is on avoiding long route. REQ1: (part 1)IP mobility, network access and routing solutions provided by DMM MUST enable distributed deployment for mobility management of IP sessions (part 2) so that traffic does not need to traverse centrally deployed mobility anchors and thus can be routed in an optimal manner. With the first part, multiple MRs will become available in MIP by simply having an HA for each home network. It is illustrated in terms of the logical functions as in Figure 7. With the second part, one can examine dynamic mobility and route optimization to be discussed later. The figure shows, as an example, three networks. Each network has its own IP prefix allocation function. The mobility routing function is distributed to multiple locations at the MRs so that routing can be optimized. Again, the resulting mobility management becomes network-based if MN takes the position of MN31. Chan Expires April 19, 2013 [Page 14] Internet-Draft DMM-framework-gap-analysis October 2012 +-----+ +-----+ +-----+ | LM1 | | LM2 | | LM3 | +-----+ +-----+ +-----+ HoA1 alc HoA3 alc HoA2 alc | | | | | | +-----+ +-----+ +-----+ | MR1 | | MR3 | | MR2 | +-----+ +-----+ +-----+ . / \ . / \ . / \ . +----+ +----+ +----+ . |AR31| |MN11| |CN21| . +----+ +----+ +----+ HoA11 IP31 IP32, | HoA11 | +----+ |MN31| +----+ Figure 7. A distributed architecture of mobility management. 5.1.6. Transparency to Upper Layers when needed To see how to avoid traversing centralized deployed mobility anchors, let us look at the second requirement on non-optimal routes. REQ2: DMM solutions MUST provide transparent mobility support above the IP layer when needed. Such transparency is needed, for example, when, upon change of point of attachment to the Internet, an application flow cannot cope with a change in the IP address. Otherwise, support for maintaining a stable home IP address or prefix during handovers may be declined. In order to avoid traversing long routes after the MN has moved to a new network, the new network can simply be used 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 in which 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 Chan Expires April 19, 2013 [Page 15] Internet-Draft DMM-framework-gap-analysis October 2012 above use of IP for an application. This gap can be overcome by generalizing the concept of the HoA of the MN to the HoA of an application running on the MN as will be discussed in Section 7.1 below. Using the dynamic mobility management scheme has avoided 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. 5.1.7. Route optimization The second part of first requirement is on route optimization. REQ1: (part 1)IP mobility, network access and routing solutions provided by DMM MUST enable distributed deployment for mobility management of IP sessions (part 2) so that traffic does not need to traverse centrally deployed mobility anchors and thus can be routed in an optimal manner. 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 have 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. The data in each server need not be pushed to all the other servers but the database system only needs to know which data resides in which server. In addition, 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 8. 5.2. Gap analysis on the mobility protocols 5.2.1. Gap analysis with the unified framework The user of unified framework meets the following requirements: Chan Expires April 19, 2013 [Page 16] Internet-Draft DMM-framework-gap-analysis October 2012 REQ4: Considering existing protocols first REQ5: (first part) compatibility REQ3: IPv6 deployment The unified framework has separated the HA function into an MR and an LM function. The following is needed in addition: REQ6: Security - Trust between MR and LM is needed when they are not co-located. 5.2.2. Gap analysis with MIPv6 MIPv6 using the unified framework follows the above gap analysis with the unified framework. In addition, the following is needed. REQ6: Security consideration Trust between MN and MR is needed. 5.2.3. Gap analysis with PMIPv6 In terms of the unified framework, PMIPv6 differs from MIPv6 only in the sense that the combination of an AR and the MN in the network- based solution behaves like an MN in the host-based solution. While the gap analysis with MIPv6 applies here, the following change is needed: The trust between MN and MR in MIPv6 is therefore replaced by the trust between AR and MR, and trust between the AR and the MN is needed. REQ6: Security consideration Trust between AR and MR is needed. Trust between MN and MR is needed. 5.2.4. Gap analysis with HMIPv6 In terms of the unified framework, HMIPv6 differs from MIPv6 and PMIPv6 only in the addition that packets are routed in the hierachy MR(home network) -- MR(visited network) -- MN in MIPv6 or AT in PMIPv6. While the gap analysis with MIPv6 and PMIPv6 applies to HMIPv6, the following additional trust relationship is needed between the MR's of different networks. REQ6: Security consideration Chan Expires April 19, 2013 [Page 17] Internet-Draft DMM-framework-gap-analysis October 2012 Trust between MR's in different networks is needed. 5.2.5. Gap analysis with Multiple home networks The scenario of multiple home networks is simply achieved with the implementation of the unified framework in each network of the multiple network. The MR function is then available in different networks. The following requirement of distributed deployment is then met. REQ1: Distributed deployment The unified framework functions can be deployed in each of the multiple networks. Again, besides this additional gap analysis on distributed deployment, the gap analyses for MIPv6, PMIPv6, and HMIPv6 also apply depending on which of these variants of MIP is used in the multiple network deployment. 5.2.6. Gap analysis with HAHA The scenario for Migrating Home Agent can be constructed from that of the multiple home networks by modifying the LM in each network to propagate its data to all the LM servers in all the other networks. Therefore the gap analysis with multiple home networks apply, and in addition, trust between the LM servers are needed. REQ6: Security consideration Trust among the LM servers is needed. 5.2.7. Gap analysis with Dynamic mobility management In Section 6, the unified framework functions are built by extending that of the multiple home entwork senario. Therefore the gap anayses with multiple home networks apply to the dynamic mobility management. In addition, REQ2: Transparency to upper layers when needed. The home network and HoA was previously associated with an MN. By extending the concept to that of an application rather than an MN which have multiple applications, dynamic mobility management can be achieved. Chan Expires April 19, 2013 [Page 18] Internet-Draft DMM-framework-gap-analysis October 2012 5.2.8. Gap analysis with Multiple MRs and distributed LM database In Section 7, an architecture of distributed mobility management is constructed from the unified framework functions and can be seen as an extension of the multiple home network senario with dynamic mobility management support. Therefore the gap analyses for the dynamic mobility management also apply. In addition, the following gap anaylsis apply. REQ1: (part 2) Distributed deployment The LMs may generalize into a distributed database. REQ6: Security considerations Trust between the MR and the LM is needed. 5.2.9. Gap analysis with Route optimization mechanisms In Section 8, different possibilities to optimize the route using the architecture in Section 7 is described. Therefore the gap analyses for the DMM architecture in Section 7 apply. In addition, the following gap anaylses apply. REQ1: (part 2) Distributed deployment MR may cache the LM information when needed. MR function is needed in the CN's network. REQ6: Security considerations Trust between the MR and the LM is needed. 6. Dynamic mobility management 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]. The architecture with multiple mobility routing functions compared Chan Expires April 19, 2013 [Page 19] Internet-Draft DMM-framework-gap-analysis October 2012 with a centralized approach is more convenient to achieve dynamic mobility management. In Figure 6 above, the LM function and the IP address allocation function may co-locate. The device MN11 originally attached to the first network (Network1) may simply be using a dynamic IP address HoA11 which is leased from Network1 with a finite lifetime of say 24 hours. As MN11 leaves the first network and attaches to the third network (Network3), it acquires a new IP address IP33 from Network3. MN11 may or may not have ongoing sessions requiring session continuity. If it does not, there is no need for LM1 to keep a binding for the home address HoA11 of MN11. If it does, it may use the existing MIP signaling mechanism so that the LM1 will keep the binding HoA11:MR3. MR3 in turn will keep the binding HoA11:IP33. Such a hierchy of binding with MR3 acting as the proxy location maintenance function between LM1 and MN11 will also cause MR3 to act as a proxy mobility routing function between MR1 and MN11 so that packets destined to MR1 will be redirected to 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. More details on dynamically providing mobility support are found in [ID.seite-dmm-dma], [ID.liu-dmm-dynamic-anchor-discussion], [ID.bernardos-dmm-pmip], [I-D.ma-dmm-armip], and [ID.sarikaya-dmm- dmipv6]. [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. [ID.sarikaya-dmm-dmipv6] also described dynamic mobility management for a flattened network, with separate data plane and control plane. The needed authentication is also described. [ID.bernardos-dmm-pmip] co-locates the home prefix allocation function and the mobility routing function at the access router, Chan Expires April 19, 2013 [Page 20] Internet-Draft DMM-framework-gap-analysis October 2012 which is then named Mobility Anchor and Access Router (MAAR) in that draft. The LM function is centralized and is named Central Mobility Database (CMD). [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. [ID.liu-dmm-dynamic-anchor-discussion] describes the gaps and extensions needed to accomplish dynamic mobility management. 6.1. Home network of an application session 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. 7. Multiple MRs and distributed LM database 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. Figure 7 shows an architecture of DMM with an example of the same three networks in Figure 6. As is in Figure 6, each network in Figure 7 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 signal with each other. In addition to these features in Figure 6, the LM function in Figure 8 is a distributed database, with multiple servers, of the mapping of HoA to CoA. Chan Expires April 19, 2013 [Page 21] Internet-Draft DMM-framework-gap-analysis October 2012 Network1 Network3 Network2 +-----+ +-----+ +-----+ | LM1 | | LM3 | | LM2 | +-----+ +-----+ +-----+ HoA1 alc HoA3 alc HoA2 alc | \ \ / | \ / / | | \ \ / | \ / / | | \ \/ | \/ / | | \ / \ | / \ / | | \/ \|/ \/ | | /\ /|\ /\ | | / \ / | \ / \ | | / /\ | /\ \ | | / / \ | / \ \ | | / / \ | / \ \ | +-----+ +-----+ +-----+ | MR1 |------| MR3 |------| MR2 | +-----+ +-----+ +-----+ . / \ . / \ . / \ . +----+ +----+ +----+ . |AR31| |MN11| |CN21| . +----+ +----+ +----+ HoA11 IP31 IP32, | HoA11 | +----+ |MN31| +----+ Figure 8. 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 Chan Expires April 19, 2013 [Page 22] Internet-Draft DMM-framework-gap-analysis October 2012 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. 8. Route optimization mechanisms 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): RS1.CN-MR(CN): the route segment from the CN to the nearest MR; RS2.MR(CN)-MR(MN): the route segment from the MR serving (and therefore being closest to) the CN to the MR serving the MN; and RS3.MR(MN)-MN: the route segment from the MR serving the MN to the MN. 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: RS1.CN-MR(CN).anycast: Use anycast to route the packet to the nearest MR function. Here, each MR includes all the HoAs in its route announcement as if each of them is the destination for the HoA. Such route announcements will affect the routing table such that the packet destined to an HoA will be routed to the nearest MR. The use of anycast to reach the nearest HA has been used in [Paper-Migrating.Home.Agents] but with a different distributed architecture of duplicating many HAs. It is again proposed in [Paper-Distributed.Mobility.PMIP]. Chan Expires April 19, 2013 [Page 23] Internet-Draft DMM-framework-gap-analysis October 2012 RS1.CN-MR(CN).gw/ar: Co-locate the MR function at a convenient location to which the packet will always pass. Such locations may be the gateway router or the access router. This approach will be described later. It is noted here that in PMIP design in a hierchical network, generally, the MAG is at the access router but LMA can be in the gateway router of a network. Whether a distributed mobility design enhances the MAG or the LMA may involve quite different mechanisms. Yet when looking at the logical function, it is basically the same MR function whether this function co-locates with the access router or the gateway router. This draft therefore put both approaches together. There is however a difference that the access router needs to perform proxying function when using PMIP. Yet the logical MR functions are the same. It is again noted that in flattened network, the access router and the gatway router may merge together. With they are merged, the needed function is again the same logical MR function. In the second segment RS2.MR(CN)-MR(MN), the alternatives are: RS2.MR(CN)-MR(MN).query: The MR query the LM database and use the result to tunnel the packet to the MR serving the MN. In order words, the MR pulls the needed internetwork location information from the LM server. There will be a delay owing to the time taken to send this query and to receive the reply. Optionally, before receiving the reply, the first packet or the first few packets may be forwarded using mip or pmip. Then the first packet may incur a triangle route rather than to wait for the query reply. After receiving the reply, the packet will be tunneled to the MR(MN). The result may be cached for forwarding subsequent packets. RS2.MR(CN)-MR(MN).push: The MR routes the first packet to the home network using the existing MIP or PMIP mechanism. It will then be intercepted by the MR of the MN which, with the help of LM, knows whether the MN has moved to a different network and use the mapping in LM to tunnel the packet to the MR of the MN. Then the MR of the MN will inform MR of the CN to tunnel the packet directly to the MR of the MN in future. In order words, after MR(CN) has forwarded the first packet to MR(MN), the MR(MN) is triggered to push the location information to MR(CN). The MR of the CN may keep this information in its cache memory for forwarding subsequent packets. 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. Chan Expires April 19, 2013 [Page 24] Internet-Draft DMM-framework-gap-analysis October 2012 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: 1. RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).query: 2. RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).push: An example is [Paper-Distributed.Mobility.PMIP] which is explained for network-based mobile IP but is also applicable to host-based mobile IP. 3. RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).query: An example is in [I-D.luo-dmm-pmip-based-dmm-approach] or [I-D.liu-dmm-pmip-based-dmm-approach] in which the MR function is co-located at the MAG which is usually at the access router. Here, when CN is also a MN using PMIP, the packet sent from it naturally goes to the access router which takes the logical function of MR so that it will query the LM, which resides in the LMA. It then uses the query result to tunnel the packet to the MR(MN), which resides in the AR/MAG of the destination MN. The signaling flow and other details are described in the referenced draft. Another example is in [I-D.jikim-dmm-pmip]. In the signal driven approach, the MR is co-located the access router, which is considered as an extension of MAG. The MR, i.e., the extended MAG, serving the CN queries the LM and cache the result so that it can tunnel packets to the MR serving the destination MN. [I-D.dmm-nat-phl] also colocates the MR at the gateways. The gateway which serves the network of transmitting node and where the MR is colocated is called the Ingress router, whereas that at the network of the MN at the receiving side is called egress router. Instead of tunneling between these 2 gateways, header rewrite using NAT is used to forward the packet through the internetwork route segment. 4. RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).push: Another example is described in [Paper- Distributed.Mobility.Management]. 9. Security Considerations TBD Chan Expires April 19, 2013 [Page 25] Internet-Draft DMM-framework-gap-analysis October 2012 10. IANA Considerations None 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [I-D.bernardos-dmm-pmip] Bernardos, C., Oliva, A., Giust, F., Melia, T., and R. Costa, "A PMIPv6-based solution for Distributed Mobility Management", draft-bernardos-dmm-pmip-01 (work in progress), March 2012. [I-D.distributed-lma] Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed Local Mobility Anchors", draft-chan-netext-distributed-lma-03 (work in progress), March 2010. [I-D.dmm-nat-phl] Liebsch, M., "Per-Host Locators for Distributed Mobility Management", draft-liebsch-mext-dmm-nat-phl-00 (work in progress), October 2011. [I-D.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. [I-D.jikim-dmm-pmip] Kim, J., Koh, S., Jung, H., and Y. Han, "Use of Proxy Mobile IPv6 for Distributed Mobility Management", draft-jikim-dmm-pmip-00 (work in progress), March 2012. [I-D.liu-dmm-dynamic-anchor-discussion] Liu, D., Deng, H., and W. Luo, "DMM Dynamic Anchor Discussion", draft-liu-dmm-dynamic-anchor-discussion-00 (work in progress), March 2012. [I-D.liu-dmm-pmip-based-approach] Chan Expires April 19, 2013 [Page 26] Internet-Draft DMM-framework-gap-analysis October 2012 Liu, D., Song, J., and W. Luo, "PMIP Based DMM Approaches", draft-liu-dmm-pmip-based-approach-02 (work in progress), March 2012. [I-D.luo-dmm-pmip-based-dmm-approach] Luo, W. and J. Liu, "PMIP Based DMM Approaches", draft-luo-dmm-pmip-based-dmm-approach-01 (work in progress), March 2012. [I-D.ma-dmm-armip] Ma, Z. and X. Zhang, "An AR-level solution support for Distributed Mobility Management", draft-ma-dmm-armip-00 (work in progress), February 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", draft-patil-dmm-issues-and-approaches2dmm-00 (work in progress), March 2012. [I-D.sarikaya-dmm-dmipv6] Sarikaya, B., "Distributed Mobile IPv6", draft-sarikaya-dmm-dmipv6-00 (work in progress), February 2012. [I-D.seite-dmm-dma] Seite, P. and P. Bertin, "Distributed Mobility Anchoring", draft-seite-dmm-dma-00 (work in progress), February 2012. [I-D.xue-dmm-routing-optimization] Xue, K., Li, L., Hong, P., and P. McCann, "Routing optimization in DMM", draft-xue-dmm-routing-optimization-00 (work in progress), 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-Distributed.Centralized.Mobility] Bertin, P., Bonjour, S., and J-M. Bonnin, "Distributed or Centralized Mobility?", Proceedings of Global Communications Conference (GlobeCom), December 2009. [Paper-Distributed.Dynamic.Mobility] Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Chan Expires April 19, 2013 [Page 27] Internet-Draft DMM-framework-gap-analysis October 2012 Architectures", Proceedings of 3rd International Conference on New Technologies, Mobility and Security (NTMS), 2008. [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. [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-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-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-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. [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. [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 Chan Expires April 19, 2013 [Page 28] Internet-Draft DMM-framework-gap-analysis October 2012 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. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. Author's Address H Anthony Chan Huawei Technologies 5340 Legacy Dr. Building 3, Plano, TX 75024, USA Email: h.a.chan@ieee.org Chan Expires April 19, 2013 [Page 29]