Network Working Group Y. Tu Internet-Draft W. Luo Intended status: Standards Track ZTE Expires: February 1, 2014 S. Tricci ZTE USA July 31, 2013 Distributed Mobility Management Approach with Mobile IP draft-tu-dmm-with-mip-00 Abstract Based on the analysis of current centralized mobility management approaches, three main functions of current centralized mobility anchor are introduced, which are Mobility Routing (MR), Home Address Allocation (HAA), and Location Management (LM). Based on the proposal of decoupling those functions, this document provides a concept of architecture for Distributed Mobility Management (DMM) with some key approaches for DMM. Requirements Language 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 RFC 2119 [RFC2119]. 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 February 1, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the Tu, et al. Expires February 1, 2014 [Page 1] Internet-Draft dmm-mip July 2013 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 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2.1. Conventions used in this document . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Functional Decomposition . . . . . . . . . . . . . . . . . 4 3.2. An Example of Networking Model . . . . . . . . . . . . . . 4 3.3. Concept Architecture of Distributed Mobility Management . 5 4. Overview of the Distributed Mobility Management Approaches . . 6 4.1. Initial Attachment . . . . . . . . . . . . . . . . . . . . 6 4.2. Dynamic Mobility Management . . . . . . . . . . . . . . . 7 4.3. Distributed Routing . . . . . . . . . . . . . . . . . . . 7 4.4. Handover with Active Session . . . . . . . . . . . . . . . 10 5. Considerations of the Optimized Routing . . . . . . . . . . . 12 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Tu, et al. Expires February 1, 2014 [Page 2] Internet-Draft dmm-mip July 2013 1. Introduction Centralized mobility anchoring has several drawbacks such as single point of failure, routing in a non optimal route and etc, which are discussed in [I-D.ietf-dmm-requirements]. Based on the analysis of current centralized mobility management approaches, three main functions are introduced, including Mobility Routing (MR), Home Address Allocation (HAA), and Location Management (LM). Based on the proposal of decoupling those functions, this draft provides a concept of architecture for Distributed Mobility Management (DMM) with some key approaches for DMM. 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 This draft introduces following terms which are very similar with terms defined in [I-D.ietf-dmm-best-practices-gap-analysis]. Mobility Routing (MR), which is a logical function used for intercepting packets to/from the HoA of a mobile node and forwarding the packets, based on the corresponding location information to perform distributed routing. Home Address Allocation (HAA), which is a logical function used for allocating home network prefix or home address to a mobile node. Location Management (LM), which is a logical function, used for managing and keeping track of the internetwork location information of a mobile node, which includes a mapping of the HoA of the MN to the routing address of the MN (i.e. routing location) or another network element that knows how to forward packets towards the MN. 3. Solution Overview Tu, et al. Expires February 1, 2014 [Page 3] Internet-Draft dmm-mip July 2013 3.1. Functional Decomposition The existing mobility management technology, such as MIP, PMIP and etc., bundles all the mobility management functions into one centralized Home Agent (HA) or Local Mobility Anchor (LMA). Sharing similar view with [I-D.ietf-dmm-best-practices-gap-analysis], this draft decomposes those centralized anchor into the following logical functions to allow a more flexible design to achieve distributed mobility management (DMM): a. Home Address Allocation (HAA) function b. Mobility Routing (MR) function c. Location Management (LM) function Assuming for any given administrative domain, it consists of one or more so called local network (as illustrated in figure 1). Further, each those local networks most likely consists of several routers which are deployed with mobility routing (MR) function, and one home address allocation (HAA) function and one location management (LM) function. The HAA and LM, depended on the operating policy, could be deployed as a combined entity or be deployed separately. 3.2. An Example of Networking Model Figure 1 illustrates a possible deployment of distribute mobility management specified by this draft, which contains 3 local networks. One Administrative Domain ( LM1/HAA1 )( LM2/HAA2 )( LM3 HAA3 ) ( )( )( ) ( )( )( ) ( MR11 MR12 )( MR2 )( MR31 MR32 ) + + | Local Local | Local | Network1 Network2 | Network3 + + MN1 MN2 Figure 1. An example of DMM deployment Both local network 1 and local network 3 contain multiple MRS (e.g. two MRs), while local network 2 includes one MR. The LM and the HAA Tu, et al. Expires February 1, 2014 [Page 4] Internet-Draft dmm-mip July 2013 are co-located as ana signal entity in local network 1 and 2, while are deployed separately in local network 3. It should be noticed that, this figure is only an example. In actual deployment, for one signal local network, multiple LMs and HAAs could also be deployed. Also, it is assuming all local networks belong to a same administrative domain (e.g. one operator). Otherwise, out of the scope of this draft. 3.3. Concept Architecture of Distributed Mobility Management For supporting distributed mobility management, signaling interactions are needed between those MR, LM and HAA. This section tries to illustrate architecture of the DMM approaches. +-------------------------------------+ +--------------------------+ | +---------+ +---------+ | | +---------+ | | | HAA | | LM +<---+--+------->+ LM | | | +---+-----+ +----+----+ | | +----+----+ | | ; /|\ | | /|\ | | /|\ | | | | | | | \|/ | | \|/ | | | +----+----+ | | +----+----+ | | +-------------> | MR +<---+--+------->+ MR | | | +--+---+--+ | | +--+---+--+ | | /|\ /|\ | | /|\ /|\ | | | | | | | | | | |___| | | |___| | | | | | | Home Local Network | | Visited Local Network | +-------------------------------------+ +--------------------------+ Figure 2. Architecture The local network to which the MN is initially attached is known as its home local network. The HAA function of mobile node's home local network is responsible for IP address\prefix (i.e. HoA) assignment for the mobile node. During the movement, the mobile node could leave its home and enter one another local network which is known as visited local network in this draft. Interfaces among HAA, LM and MR are needed, and are described as following a. Interface between HAA and MR, which supports signaling for prefix or IP address assignment, during the attachment of a mobile node to a MR Tu, et al. Expires February 1, 2014 [Page 5] Internet-Draft dmm-mip July 2013 b. Interface between LM and MR, which supports signaling for maintaining the routing location of mobile node, and the set up of an optimized routing for mobile node c. Interface between MR and MR, which supports the signaling for the handover of a mobile node from previous MR (pMR) to new MR (nMR) in control plane, and supports delivering traffic between mobile node and its correspondent node in a distributed manner in data plane. An administrative domain may have a large amount of mobile nodes; therefore the LM may need to maintain a large amount of information (i.e. tracing the routing location of those mobile nodes). It is better for an administrative domain to deploy multiple LMs. Those LMs could be deployed in a form of distributed database, and interfaces between them are necessary for information interactive. 4. Overview of the Distributed Mobility Management Approaches 4.1. Initial Attachment The initial attachment for distributed mobility management is triggered when a mobile node is initialized and attached to an access link on which the mobile node is connected to a MR. When determining that mobile node is authorized for the DMM service, MR interacts with HAA, which is in the same local network, by signaling, over the interface between them, for the purpose of HoA assignment. The HoA assignment mechanism could be based on stateful or stateless mechanism. After configuring HoA for the mobile node, that local network becomes mobile node's home local network. The MR, depends on the local policy, may interact with a LM which is also in mobile node's home local network (i.e. MN's home LM) to update the mobile node's routing location. Updating mobile node's routing location during initial attachment is not a mandatory step. Since the mobile node is currently attached to its home local network and the assigned HoA is anchored at mobile node's currently attached MR. The traffic, which is designated to mobile node's HoA, should be routed to that MR by regular IPv6 routing mechanism automatically. Tu, et al. Expires February 1, 2014 [Page 6] Internet-Draft dmm-mip July 2013 4.2. Dynamic Mobility Management Mobile node may change its point of attachment from pMR to nMR when it moves. The nMR may locate at mobile node's home local network, or may at a different local network (i.e. visited local network). Based on the attachment event, the nMR should try to retrieve mobile node's HoA configuration status first (e.g. from mobile node's HAA in home local network), and update mobile node's LM with its new routing location (e.g. IP address of nMR). Depend on the configuration of the network, new HoA which is anchored at nMR could be assigned to mobile node when the mobile node is attached to the nMR. In this case, both HoAs anchored at pMR and nMR are respectively available for the mobile node. In this case, newly initiated session after the handover is preferred to use new HoA as source IP. Meantime, old session which has already established before handover could still use the old HoA as source IP for the purpose of keeping session continuity. The similar idea is also proposed in [I-D.seite-dmm-dma], [I-D.bernardos-dmm-distributed-anchoring] and [I-D.korhonen-dmm-local-prefix]. But, one should be noted that, in the above configuration, mobile node should have ability to manage multiple HoAs, and should have ability to decide to return which one of those multiple HoAs when applications on the mobile node ask for an IP address to bind. 4.3. Distributed Routing To perform optimized routing, the MRs need the location information which is maintained at the LMs. Use the scenario illustrated in figure 1 as an example. The assumptions are as following: o MN1 and MN2 are currently attached to MR11 and MR 31 respectively o The destination IP address of the traffic (from MN2 to MN1) is set to the HoA of MN1 o The MN1's HoA above is anchor at MR12 (which means the regular IPv6 routing mechanism will deliver any packet whose destination IP address is set to MN1's HoA to MR12), not the MR to which the MN1 is currently attached (i.e. MR11). Then, upon receiving the initial few packets of the traffic, MR31 Tu, et al. Expires February 1, 2014 [Page 7] Internet-Draft dmm-mip July 2013 should determine how to forward the traffic optimally. +-----+ +-------+ +-------+ +--------+ +-----+ | MN2 | | MR31 | | LM | | MR11 | | MN1 | +-----+ +-------+ +-------+ +--------+ +-----+ | | | | | |1.IP Traffic | | | | |===========> | 2. Query | | | | |----------> | | | | | 3. Rsp | | | | |<------ ----| | | | +------------------+ | | | | | 4.Record Location| | | | | | of MN1 Locally | | | | | +------------------+ | | | | | 5. Distributed Routing | | | |========================> | | | | | |6.IP Traffic | | | | |===========> | | | | | | Figure 3. Optimized routing based on location query Figure 3 illustrates one possible behavior the MR31 could take for the purpose of determining how to forward the traffic in an optimized manner. MR31 first determines whether it holds the routing location information of MN1 locally. If not, MR31 will initiate a query to a LM (e.g. MN1's home LM), who holds such information, by sending a query message via the interface between MR and LM. When receiving the response, MR31 should save the queried routing location information of MN1 locally. Based on the routing location information retrieved, MR31 could perform distributed routing for delivering the traffic. o One of distributed routing mechanism: MR31 could set up its endpoint of a tunnel (e.g. IP in IP tunnel) to MR11 based on MN1's routing location, encapsulate all IP packets of the traffic and send those encapsulated IP packets to MR11 in the established tunnel directly. o Another one of distributed routing mechanism: as specified in [I-D.liebsch-mext-dmm-nat-phl], per-host-locator mechanism can be used by MR31 to perform distributed routing, in which, the locator is MN1's routing location. Tu, et al. Expires February 1, 2014 [Page 8] Internet-Draft dmm-mip July 2013 Only two example distributed routing mechanisms are list above. Some better mechanisms can be developed in the future. +-----+ +-------+ +-------+ +--------+ +--------+ +-----+ | MN2 | | MR31 | | LM1 | | MR12 | | MR11 | | MN1 | +-----+ +-------+ +-------+ +--------+ +--------+ +-----+ | | | | | | |1.IP Traffic | | | | | |============>| | | | | | +-------------------+ | | | | | |2.Don't have MN1's | | | | | | | Routing Location | | | | | | +-------------------+ | | | | | | 3. Regular IPv6 Routing | | | | |========================> | | | | | | 4. Query | | | | | |<------------| | | | | | 5. Rsp | 6. Distributed | | | |------------>| Routing | | | 8. Redirect |===========>| | | |<-------------------------| 7.IP Traffic| | | | | |==========>| | | 9. Distributed Routing | | | |======================================>| | | | | | 10.IP Traffic| | | | | |==========>| | | | | | | | | | | | | Figure 4. Another approach for optimized routing multiple mechanisms can be used for setting up optimized routing for DMM. Figure 4 illustrates another possible behavior the MR31 could take for the purpose of determining how to forward the traffic in an optimized manner. MR31 first determine whether it holds the routing location information of MN1 locally. And if MR31 determines it doesn't hold such information, it will forward the traffic received by regular IPv6 routing mechanism. The traffic will be forwarded to MR12, based on the assumption that the destination IP address of the traffic (i.e. HoA of MN1) is anchored at MR12. Upon receiving the traffic, MR12 will determine that the MN1 is not attached to itself. As a result, MR12 will query with LM for MN1's routing location. When MN1's routing location information is determined, MR12 could Tu, et al. Expires February 1, 2014 [Page 9] Internet-Draft dmm-mip July 2013 perform distributed routing for delivering the traffic, as described above, to MR11 to which the MN1 is currently attached and then forwarded to MN1 by MR11. MR12 is further preferred to send another message to MR31 via interface between MRs to inform MR31 with MN1 current routing location to trigger the direction. The MR31, based on the received routing location information, will perform distributed routing for delivering the rest IP packets of traffic, first to MR11, then to MN1, as described above. It should be noted that, for both behaviors described above, when the routing between MN1 and MN2 is established, the routing is optimized: MN2=>MR31=>MR11=>MN1. For the latter behavior, if the MN1 is currently attached to the MR12, the routing for traffic from MN2 to MN1 will be identical with regular IPv6. But, how the MR12 can determine MR31 (i.e. the MR to which the MN2 is attached) is a challenge. 4.4. Handover with Active Session Section 4.2 has already discussed scenarios the mobile node changes its point of attachment, but without discussing how to maintain the continuity of sessions which are initiated before the handover. Tu, et al. Expires February 1, 2014 [Page 10] Internet-Draft dmm-mip July 2013 +---+ +--------+ +--------+ +-------+ +--------+ +---+ |MN1| | MR11 | | MR2 | | LM1 | | MR31 | |MN2| +---+ +--------+ +--------+ +-------+ +--------+ +---+ | | | | | | | | 1. Ongoing traffic | | |<==========>|<==================================>|<========> | | | 2. Context| | | | | | Transfer | | | | | |<---------->| | | 3. IP | | | | | | Traffic | | | 4. Distributed Routing |<========= | | |<===================================| | | |5. Transfer | | | | | |==========> | | | | | 6. IP Traffic | | | | |<======================= | | | | | | | 7. Redirect | | | |----------------------------------> | | | | | | +----------------+ | | | | | | 8. Update | | | | | | | Location of MN1| | | | | | +----------------+ | | | | | | 9. IP | | | | | | Traffic | | | |10. Distributed Routing|<==========| | 11. IP Traffic |<======================| | |<========================| | | | | | | | Figure 5. Handover with Active Session Figure 5 illustrates approaches for handover of MN1 from pMR (MR11) to nMR (MR2). During the handover, the nMR need to update MN1's new routing location to the LM. Context transfer between nMR and pMR is always necessary, e.g. security context. The nMR could inform the pMR with MN1's new routing location information during the context transfer. Based on the received information, pMR sets up mobility context for MN1 locally to at least record MN1's new routing location. It should be noted that, the mobility context for a specific mobile node which is performing handover is just a temporarily information. When the handover is finished, the correspondent mobility context need to be deleted. MR31 to which the MN2 is attached isn't aware of the handover event of MN1. Thus, the traffic from MN2 to MN1 will still be forwarded by Tu, et al. Expires February 1, 2014 [Page 11] Internet-Draft dmm-mip July 2013 MR31 to the pMR (MR11) in a distributed routing manner (which is described in section 4.3 above). For reducing packet loss, the pMR is preferred to establish a directional tunnel to nMR and forward the received packets from MR31 to nMR via the tunnel. The key is that, the pMR needs to send a message to MR31 to update MN1's routing location stored in MR31 locally. Based on the updated routing location information of MN1, MR31 will forward the upcoming traffic from MN2 to MN1 to the nMR directly. 5. Considerations of the Optimized Routing One can note that, the routing between MN and CN is optimized based on the mechanism described in section 4.2. The CN is assumed to be a mobile node. That means CN must be attached to a certain MR, and that MR will keep track of the location of CN and interpreted any packet sent from CN to MN. But, when CN is a fixed node, there may be no such MR which servers the CN. In real world, most of such fixed nodes (CN) are deployed in a centralized manner, e.g. CDN/IDC/Web Servers and etc. Those fixed nodes are generally converged by a couple of access routers, although the topology within those fixed nodes may be very complicating, to access operator's IP bearer network. Figure 6 is an example. __________ / CN \ ,--------. ((CDN\IDC\Web )---Access Router `. ( Server) ) ,--' `' \___________/ \ _ -' '-- MR -----'' | | MN1 Figure 6. CNs are fixed nodes For the scenario described in figure 6, a direct solution is to implement MR function with convergence access router or gateway router (i.e. the access router illustrated in the above figure). Another alternative is to use anycast mechanism described in [I-D.ietf-dmm-best-practices-gap-analysis] and [I-D.wakikawa-mext-global-haha-spec]. Anycast mechanism could guarantee the traffic sent from CN to MN to reach a nearest MR which anycast the HNP aggregation of the mobile node. Tu, et al. Expires February 1, 2014 [Page 12] Internet-Draft dmm-mip July 2013 6. Security Consideration This draft proposes signaling messages interaction over interfaces among MRs, LMs and HAAs for supporting Distributed Mobility Management (figure 2). The security issues should be considered for those messages. Since, this draft assumes all local networks belong to a same administrative domain (e.g. one operator), then signaling interfaces among those MRs, LMs and HAAs can be established directly. Security association mechanism which is used for protecting PB\PB messages defined in [RFC3775] can be reused for protecting signaling messages (such as IP address allocation, routing location information update\query) between MR and LM\HAA. Signaling between MRs (such as signaling for distributed mobility support) in this draft is preferred to be protected by using end-to- end security association(s) offering integrity and data origin authentication. The MR is proposed to implement IPsec [RFC4301] or other equivalents for protecting the messages. E.g. IPsec Encapsulating Security Payload (ESP, [RFC4303]) in transport mode with mandatory integrity protection could be used for protecting those signaling messages. 7. IANA Considerations This document makes no request of IANA. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. Tu, et al. Expires February 1, 2014 [Page 13] Internet-Draft dmm-mip July 2013 8.2. References [I-D.bernardos-dmm-distributed-anchoring] Bernardos , CJ. and JC. Zuniga , "PMIPv6-based distributed anchoring", April 2013. [I-D.ietf-dmm-best-practices-gap-analysis] Liu, D., "Distributed Mobility Management: Current practices and gap analysis", June 2013. [I-D.ietf-dmm-requirements] Chan, H., "Requirements for Distributed Mobility Management", July 2013. [I-D.korhonen-dmm-local-prefix] Korhonen , J. and T. Savolainen , "Local Prefix Lifetime Management for Proxy Mobile IPv6", June 2013. [I-D.liebsch-mext-dmm-nat-phl] Liebsch , M., "Per-Host Locators for Distributed Mobility Management", March 2012. [I-D.seite-dmm-dma] Seite , P. and P. Bertin , "Distributed Mobility Anchoring", July 2012. [I-D.wakikawa-mext-global-haha-spec] Wakikawa , R., "Global HA to HA Protocol Specification", September 2011. Authors' Addresses Yangwei Tu ZTE No.68, Zijinhua RD,Yuhuatai District Nanjing, Jiangsu 210012 China Email: tu.yangwei@zte.com.cn Tu, et al. Expires February 1, 2014 [Page 14] Internet-Draft dmm-mip July 2013 Wen Luo ZTE No.68, Zijinhua RD,Yuhuatai District Nanjing, Jiangsu 210012 China Email: luo.wen@zte.com.cn Tricci So ZTE USA Phone: Fax: Email: tso@zteusa.com URI: Tu, et al. Expires February 1, 2014 [Page 15]