Network Working Group H. Chan Internet-Draft Huawei Technologies Intended status: Informational March 3, 2012 Expires: September 4, 2012 A architecture of distributed mobility management using mip and pmip draft-chan-dmm-architecture-00 Abstract This draft proposes a distributed architecture of mobility management in terms of abstracted logical functions. Mobility management functions are abstracted into different logical functions: (1) allocation of home network prefixes or home addresses to mobile nodes; (2) location management which includes managing the IP addresses and locations of the mobile nodes; and (3) mobility routing which includes intercepting and forwarding packets. A distributed architecture can be contructed by providing the mobility routing functions in multiple networks in the data plane and a distributed database is used to host the location management function. This generalized architecture enables different distributed mobility designs using primarily the existing mobility protocols (MIP and PMIP) and their extensions. Several existing distributed mobility management proposals are briefly reviewed using this framework. It is expected that the different proposals, when expressed in terms of the generalized framework of logical functions, can interwork with each other as well as with the existing hierarchical deployments. 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 September 4, 2012. Copyright Notice Chan Expires September 4, 2012 [Page 1] Internet-Draft DMM-Architecture March 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2.1. Conventions used in this document . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Logical functions of mobility management . . . . . . . . . . . 5 4. A distributed architecture of mobility management . . . . . . 8 4.1. Multiple MRs and distributed LM database . . . . . . . . . 8 4.2. Against the issues of centralized mobility . . . . . . . . 10 4.3. DMM for MIP versus DMM for PMIP . . . . . . . . . . . . . 11 5. Dynamic mobility management . . . . . . . . . . . . . . . . . 12 5.1. Home network of an application session . . . . . . . . . . 13 6. Route optimization mechanisms . . . . . . . . . . . . . . . . 13 7. Co-locating MR at gateway or access router . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Chan Expires September 4, 2012 [Page 2] Internet-Draft DMM-Architecture March 2012 1. Introduction The family of Mobile IP [RFC6275] protocols, including Proxy mobile IP [RFC5213] and various variants of Mobile IP separate session identifier and routing address into a home address and a care-of- address respectively and supports mobility with a mobility anchor or home agent in the home network. By routing via the anchor in the home network, triangle routing is encountered when a mobile node is far from the anchor while being much closer to its correspondent node. Centralized mobility management has naturally been used in existing hierarchical networks, distributed mobility management appears more compatible with the flattened networks. 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. It will then be helpful to be able to use the same distributed mobility management tools in both a distributed and a centralized manner and to achieve distributed mobility in both the hierarchical network and the flattened network. Evolution path and compatibility with different deployments may then be less of a challenge. [I-D.dmm-approaches] has also suggested that a framework using mainly the existing mobility protocols and extensions may provide the needed solutions and expected that architecture work rather than protocol work is needed. This draft proposes such a generic architectural framework to deploy distributed mobility, which also embodies some other proposed designs. If also describes another design of distributed mobility management. 1.1. Overview 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 describes how to put the logical functions into a distributed architecture. In a distributed architecture, the mobility routing function may be present in many geographical Chan Expires September 4, 2012 [Page 3] Internet-Draft DMM-Architecture March 2012 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 (Session 4.1). The architectural framework enables distributed mobility management addressing the issues in centralized mobility management (Session 4.2). It can be used for both client-based and network-based Mobile IP (Session 4.3). Session 5 explains that the distributed architecture in terms of the logical functions enables dynamic mobility management. Several other proposals of dynamic mobility management can be considered as different designs as welll as filling in any protocol gaps when needed. Besides achieving dynamic mobility management, one can also take advantage of the distributed architecture to avoid unnecessarily long routes in the data plane. Such mechanisms are explained in Session 6. Several different route optimization in distributed mobility management are reviewed as different designs in terms of a common framework, even though they may use different terminologies. For example, the extension of MAG at an access router to include mobility anchor function is basically an access router with the logical function of mobility routing. Another draft previously submitted to the netext WG, [I-D.distributed-lma], had discussed route optimization but with a somewhat different mechanism in terms of receiving, sending, handover, and other scenarios. In the 00 version of this draft, the route optimization mechanisms is explained in terms of the reachability of the MN only but can be expanded in future. A route optimization design as well as the above framework is explained in [Paper-Distributed.Mobility.Management]. This design is reproduced in Session 7 of this draft. Part of the contents of this draft are taking from another draft previously submitted to the netext wg but with a different design. It is expected that expressing different designs in terms of the logical functions of a common framework not only provides flexibility but may enable interworking between the different designs as well as with the existing centralized deployment. The other draft [I-D.distributed-lma] explains how the distributed design can interwork with the existing centralized designs of MIP and PMIP. Chan Expires September 4, 2012 [Page 4] Internet-Draft DMM-Architecture March 2012 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. 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 We decouple the mobility management functions into the following logical functions to allow a more flexible design to achieve DMM: 1. allocation of home network prefix or HoA to a MN that registers with the network; Chan Expires September 4, 2012 [Page 5] Internet-Draft DMM-Architecture March 2012 2. 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; and 3. 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. 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 1. Network1 Network2 Network3 ^ ^ ^ ^ ^ ^ ^ ^ ^ ( ) ( ) ( ) (anchor) ( ) ( ) ( ) ( ) ( ) v v v v v v v v v MN CN Figure 1. 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). A method to solve the triangle routing problem is to duplicate the anchor points in many networks (Figure 2) 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. Chan Expires September 4, 2012 [Page 6] Internet-Draft DMM-Architecture March 2012 Network1 Network2 Network3 ^ ^ ^ ^ ^ ^ ^ ^ ^ ( ) ( ) ( ) (anchor) (anchor) (anchor) ( ) ( ) ( ) v v v v v v v v v MN CN Figure 2. 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 3, 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 3. 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 Chan Expires September 4, 2012 [Page 7] Internet-Draft DMM-Architecture March 2012 in the network that has allocated the network prefix of the HoA. 4. A distributed architecture of mobility management 4.1. 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 describes in this draft is mainly on separating the data plane and the control plane. Fig. 4 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. Chan Expires September 4, 2012 [Page 8] Internet-Draft DMM-Architecture March 2012 Network1 Network2 Network3 +-----+ +-----+ +-----+ | LM1 | | LM2 | | LM3 | +-----+ +-----+ +-----+ | \ \ / | \ / / | | \ \ / | \ / / | | \ \/ | \/ / | | \ / \ | / \ / | | \/ \|/ \/ | | /\ /|\ /\ | | / \ / | \ / \ | | / /\ | /\ \ | | / / \ | / \ \ | | / / \ | / \ \ | +-----+ +-----+ +-----+ | MR1 | | MR2 | | MR3 | +-----+ +-----+ +-----+ /|\ / | \ / | \ / | \ / | \ / | \ +----+ +----+ +----+ |MN31| |MN32| |MN11| +----+ +----+ +----+ Figure 4. 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 thereby partly addressing the problem 5 in Session 3 on wasting resources to support MNs not needing mobility support. After MN11 has performed handover to the third network, the database server LM1 keeps a mapping of Chan Expires September 4, 2012 [Page 9] Internet-Draft DMM-Architecture March 2012 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. 4.2. Against the issues of centralized mobility The desired architecture of distributed mobility management should enable solutions to address the issues of centralized mobility management such as those explained in [Paper- Distributed.Mobility.Review]. The distributed architecture is examined against the issues of centralized deployment of mobile IP as follows: 1. Non-optimized routes especially with content delivery network (CDN) servers moved closer to the user: The architecture has multiple MRs so that an MR is available in each network enables avoiding the non-optimal routes in the data plane. 2. Non-optimality in evolved network architecture: These MRs can be implemented in any network so that an MR can be closer to the access network to which an MNs is attached. Such an architecture can support the more flattened networks and the CDN networks. 3. low scalabiltiy of centralized route and mobility context maintenance: The distributed architecture is more scalable than a centralized one, as is discussed in [Paper-Distributed.Centralized.Mobility]. 4. Single point of failure and attack: This problem is mitigated in a distributed database design with multiple servers. In addition, the availability of multiple servers is compatible with a system to use neighboring servers to backup the location information of each other. 5. Wasting resources to support mobile nodes which are not actively needing mobility support. Dynamic mobility management to be discussed in the next session Chan Expires September 4, 2012 [Page 10] Internet-Draft DMM-Architecture March 2012 will avoid providing mobility support when no application is using the HoA. 4.3. DMM for MIP versus DMM for PMIP MIP and PMIP both employ the same concept of separating session identifier and routing address into the HoA and CoA respectively. Figure 5 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 5. 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 distributed architecture using MIP can be adapted to the architecture using PMIP by replacing the MN with the MAG-MN combination. The DMM architecture shown in Figure 4 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. Chan Expires September 4, 2012 [Page 11] Internet-Draft DMM-Architecture March 2012 5. 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]. [I-D.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.dmm-pmip], 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.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. Chan Expires September 4, 2012 [Page 12] Internet-Draft DMM-Architecture March 2012 5.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. 6. Route optimization mechanisms The distributed architecture has already enabled dynamic mobility management, as is described in [I-D.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 September 4, 2012 [Page 13] Internet-Draft DMM-Architecture March 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 September 4, 2012 [Page 14] Internet-Draft DMM-Architecture March 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.dmm-pmip-based] 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 [Paper-PMIP.dmc]. 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 will be described in the next Section. 7. Co-locating MR at gateway or access router The mechanism of co-locating MR at the gateway and routing the first packet to the home network using existing MIP/PMIP mechanism is explained further here. Chan Expires September 4, 2012 [Page 15] Internet-Draft DMM-Architecture March 2012 Figure 6. shows the mapping hierarchy of the location information from LM1 to GW and then to access router (AR). Network1 Network2 Network3 +---+ +---+ +---+ |LM1|Binding |LM3| |LM2| +---+HoA11:GW3 +---+ +---+ |\\ /|\ //| | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \/ | \/ / | | \ / \ | / \ / | | \ / \ | / \ / | | \/ \|/ \/ | | /\ /|\ /\ | | / \ / | \ / \ | | / \ / | \ / \ | | / /\ | /\ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | |// \|/ \\| +---+ +---+ +---+ |MR1| |MR3| |MR2| |GW1| |GW3| |GW2| +---+ +---+ +---+ | /|Binding | | / |HoA11:AR32 | | / | | | / | | | / | | AR11 AR31 AR32 AR21 . | | | . | | | HoA11 MN31 MN11 CN21 Figure 6. Hierarchy of location management information. When the first packet is sent from a correspondent node CN21 to the home address HoA11 of the mobile node MN11, it first arrives at GW2. GW2 does not find any location information of the MN and therefore sends the packet to GW1 in accordance with routing table with the IP prefix of HoA11. If the MN is in the network served by GW1, the packet will be forwarded to MN11. In this case shown in the figure, Chan Expires September 4, 2012 [Page 16] Internet-Draft DMM-Architecture March 2012 MN11 has moved to the network served by GW3, and LM1 contains the binding of HoA11 to the IP address of GW3. GW1 therefore tunnels the packet to GW3. GW3 contains the binding HoA to AR32 and therefore tunnels the packet to AR32 which in turn delivers the packet to MN11. Meanwhile based on the source IP address of the packet, GW1 finds out that the packet had come from GW2. It informs GW2 to cache the binding HoA11 to GW3. When subsequent packets to MN11 reach GW2, GW2 finds out from its cache memory this binding so that it will tunnel these subsequent packets directly to GW3 (Figure 7. ). Chan Expires September 4, 2012 [Page 17] Internet-Draft DMM-Architecture March 2012 Network1 Network2 Network3 +---+ +---+ +---+ |LM1|Binding |LM3| |LM2| +---+HoA11:GW3 +---+ +---+ |\\ /|\ //| | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \/ | \/ / | | \ / \ | / \ / | | \ / \ | / \ / | | \/ \|/ \/ | | /\ /|\ /\ | | / \ / | \ / \ | | / \ / | \ / \ | | / /\ | /\ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | |// \|/ \\| +---+ +---+ +---+ |MR1| |MR3|<=============|MR2| |GW1| |GW3|Binding |GW2|Cache +---+ +---+HoA11:AR32 +---+HoA11:GW3 | /| |\ | / | | \ | / | | \ | / | | \ | / v | \ AR11 AR31 AR32 AR21 AR22 . | | ^ ^ ^ . | | / | | . | v / | | HoA11 MN31 MN11 CN20 CN21 CN22 Figure 7. Subsequent packets destined to HoA11 via GW2. Note that if packets sent to HoA11 from other CNs (CN22 and CN20 in Figure 7) reaches GW2, GW2 will also use this binding in its cache memory to tunnel the packet to GW3. Finally, this cache at GW2 will timeout when no more such packets are reaching GW2. This session has used the colocation at the gateway router as an example, while noting that the colocation can also be at the access router and also that the gateway and the access router may merge in a flattened network. When the MR is colocated at the access router, Chan Expires September 4, 2012 [Page 18] Internet-Draft DMM-Architecture March 2012 Figure 6 is modified as shown in Figure 8. Network1 Network2 Network3 +---+ +---+ +---+ |LM1|Binding |LM3| |LM2| +---+HoA11:AR3 +---+ +---+ |\\ /|\ //| | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \/ | \/ / | | \ / \ | / \ / | | \ / \ | / \ / | | \/ \|/ \/ | | /\ /|\ /\ | | / \ / | \ / \ | | / \ / | \ / \ | | / /\ | /\ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | |// \|/ \\| +---+ +---+ +---+ |MR1| |MR3| |MR2| |AR1| |AR3| |AR2| +---+ +---+ +---+ . /|HoA11:link addr | . / | | . / | | . / | | . / | | HoA11 MN31 MN11 CN21 Figure 8. Location management information. Chan Expires September 4, 2012 [Page 19] Internet-Draft DMM-Architecture March 2012 Network1 Network2 Network3 +---+ +---+ +---+ |LM1|Binding |LM3| |LM2| +---+HoA11:AR3 +---+ +---+ |\\ /|\ //| | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \ / | \ / / | | \ \/ | \/ / | | \ / \ | / \ / | | \ / \ | / \ / | | \/ \|/ \/ | | /\ /|\ /\ | | / \ / | \ / \ | | / \ / | \ / \ | | / /\ | /\ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | | / / \ | / \ \ | |// \|/ \\| +---+ +---+ +---+ |MR1| |MR3|<=============|MR2| |AR1| |AR3| |AR2|Cache +---+ +---+ +---+HoA11:AR3 . / |HoA11:link addr ^ ^ ^ . / | / | \ . / | / | \ . / v / | \ HoA11 MN31 MN11 CN20 CN21 CN22 Figure 9. Subsequent packets destined to HoA11 via AR2. 8. Security Considerations TBD 9. IANA Considerations None 10. Acknowledgments This document has benefited from discussions with Frank Xia, Justin Chan Expires September 4, 2012 [Page 20] Internet-Draft DMM-Architecture March 2012 Xiang, Hanan Ahmed, and others. 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.PMIP-dmc] Koh, S., Kim, J., Jung, H., and Y. Han, "Use of Proxy Mobile IPv6 for Distributed Mobility Control", draft-sjkoh-mext-pmip-dmc-01 (work in progress), March 2011. [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-approaches] Patil, Ed., B., Williams, C., and J. Korhonen, "Approaches to Distributed mobility management using Mobile IPv6 and its extensions", draft-patil-mext-dmm-approaches-02 (work in progress), October 2011. [I-D.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.dmm-dma] Seite, P. and P. Bertin, "Distributed Mobility Anchoring", draft-seite-dmm-dma-00 (work in progress), February 2012. [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-pmip] Bernardos, CJ., de la Oliva, A., Giust, F., and T. Melia, "A PMIPv6-based solution for Distributed Mobility Management", draft-bernardos-dmm-pmip-00 (work in Chan Expires September 4, 2012 [Page 21] Internet-Draft DMM-Architecture March 2012 progress), January 2012. [I-D.dmm-pmip-based] Liu, D., Song, J., and W. Luo, "PMIP Based Distributed Mobility Management Approach", draft-liu-dmm-pmip-based-approach-01 (work in progress), December 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. [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 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 Chan Expires September 4, 2012 [Page 22] Internet-Draft DMM-Architecture March 2012 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 R. 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. [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. [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 September 4, 2012 [Page 23]