Network Working Group W. Luo Internet-Draft ZTE Intended status: Informational S. Tricci Expires: April 18, 2013 ZTE USA October 15, 2012 Distributed Mobility Management Approaches with IPv6 Prefix Properties draft-luo-dmm-with-ipv6-prefix-properties-00 Abstract This draft extends the existing PMIP-based mobility management protocol to support a more distributed model by introducing two new logical functions to enable distributed anchoring and location management. Given the consideration that, the MN may not always require the mobility support that requires the use of the global prefix and additional network resources, this draft supports the option to leverage the extended properties of IPv6 prefixes source address selection hint (i.e. IPv6 Neighbor Discovery protocol and its Prefix Information Option) to enable the UE's selection of IPv6 prefix according to its service/application's mobility support requirement. When the extended prefix properties feature is supported by the MN, this draft enable the MN to select the appropriate prefix according to the mechanism as described in [I-D.korhonen-dmm-prefix-properties]. Once the IPv6 prefix is determined, the rest of the DMM mechanism is similar to the luo draft [I-D.luo-dmm-pmip-based-dmm-approach]. 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 Luo & Tricci Expires April 18, 2013 [Page 1] Internet-Draft dmm-with--prefix-properties October 2012 material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 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 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. Luo & Tricci Expires April 18, 2013 [Page 2] Internet-Draft dmm-with--prefix-properties October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Detailed Scenarios and Approaches . . . . . . . . . . . . . . 6 3.1. Initial Attach . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Data forwarding . . . . . . . . . . . . . . . . . . . . . 7 3.3. Handoff Scenario . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. References . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Luo & Tricci Expires April 18, 2013 [Page 3] Internet-Draft dmm-with--prefix-properties October 2012 1. Introduction Centralized mobility anchoring imposes some limitations to the system such as single point of congestion and failure, non optimal routing etc. which are discussed in [I-D.liu-mext-distributed-mobile-ip]. With the effect of social media phenomenon and the exponential growth of smart-phone devices (e.g. iPhone) with mobile applications that demand the real-time performance and high bandwidth, mobile and access network providers have trouble to keep up with such demands even with their aggressive deployment of more efficient and higher capacity mobile access networks (e.g. 4G and 802.11n-WLAN). It comes to recognize that the centralized mobility anchoring model is no longer sufficient to handle the new traffic pattern happening in the internet and in private networks. The objective of Distributed Mobility Management (DMM) is intended to mitigate those drawbacks, and the purpose of this draft is to present a PMIP-based extension for DMM support. This draft extends the existing PMIP-based mobility management protocol to support a more distributed model by introducing two new logical functions to enable distributed anchoring and location management. Given the consideration that, the MN may not always require the mobility support that requires the use of the global prefix and additional network resources, this draft supports the option to leverage the extended properties of IPv6 prefixes source address selection hint (i.e. IPv6 Neighbor Discovery protocol and its Prefix Information Option) to enable the UE's selection of IPv6 prefix according to its service/application's mobility support requirement. When the extended prefix properties feature is supported by the MN, this draft enable the MN to select the appropriate prefix according to the mechanism as described in [I-D.korhonen-dmm-prefix-properties]. Once the IPv6 prefix is determined, the rest of the DMM mechanism is similar to the luo draft [I-D.luo-dmm-pmip-based-dmm-approach]. 2. Solution Overview This draft introduces two new logic functions to the existing PMIP- based protocol to support the distributed mobility management: 1. Location Management Function (LMF) is designed to maintain the mappings between IP addresses and location of MNs. 2. Distributed Anchoring Function (DAF) is designed to provide the local anchoring support for the MN at its first hop router as described in luo draft [I-D.luo-dmm-pmip-based-dmm-approach], section 7, which is referred as enhanced LMA (eLMA) with the Luo & Tricci Expires April 18, 2013 [Page 4] Internet-Draft dmm-with--prefix-properties October 2012 similar property of the LMA as described in RFC[5213]. DAF is composed of Distributed Routing sub-Function (DRF) and Distributed Mobility sub-Function (DMF). The DRF operates as the distributed tunnel end-point at the first hop router of the MN to support the optimized routing between two DMM-capable end-points (i.e. MN and its corresponding node, i.e. the CN). DMF is designed to support the mobile node's mobility handover operation, with the intention to minimize the packet loss during the optimized route establishment. During the initial MN attachment, this draft re-uses an option to leverage korhonen draft [I-D.korhonen-dmm-prefix-properties] to deliver source address selection hint of IPv6 prefixes to the MN (i.e. the 'M' flag in Prefix Information Option as defined in this draft). When eLMA detects an initial attachment of a MN, it will send a RA message to that MN. The RA includes IPv6 prefixes, and each prefix is tagged with its properties which includes its mobility management property. According to the mobility management property, the IPv6 prefix is differentiated by the MN based on two categories, i.e. global prefix and local prefix and they are defined as follows: 1. Global Prefix: if an IPv6 address derived from a global prefix is used as source address for a session, this session will be provided with fully mobility support by using the mobility management mechanism specified in this draft. That means, the address always remains valid even the point of attachment is changed. 2. Local Prefix: if an IPv6 address derived from a local prefix is used as source address for a session, no or limited mobility support will be provided for this session. The address may not be valid when the point of attachment is changed. Based on the acquired mobility management property, MN supports its service applications according to these two categories of IPv6 prefix. If application on MN requires mobility support, the MN will derive an IPv6 address from the global prefix by having the application to invoke an appropriate socket API extension. Otherwise, the application on the MN requires no or limited mobility support, the MN will derive IPv6 address from local prefix by invoking another appropriate socket API extension. The network will not provide mobility for those local IPv6 prefixes, which implies when MN changes its point of attachment, i.e. eLMA, the local prefix assigned by previous eLMA will be Luo & Tricci Expires April 18, 2013 [Page 5] Internet-Draft dmm-with--prefix-properties October 2012 deprecated\invalidated. When attached to next eLMA, the new local prefix will be advertised by the new eLMA. eLMA only updates the location information to the LMF for those global prefixes. Section 3.1 provides more detailed description. If the MN does not support the extended prefix property features as described in [I-D.korhonen-dmm-prefix-properties], the MN will derive the IPv6 address based on IPv6 global prefix. If either the MN does not support this extended prefix property or the MN selects the global prefix, the DMM mechanisms as described in [I-D.luo-dmm-pmip-based-dmm-approach] will leverage the global IPv6 prefixes to maintain the mobility support for the MN for data forwarding and handoff operations and they are described as follows: a. Data Forwarding: if the application on the MN requires mobility support (such as VOIP), it will leverages the IPv6 address derived from a global prefix to establish a session based on this global address as its source address with its CN. When eLMA of the correspondent node receives traffic send to that global address, eLMA will query the LMF for the location information of that global address and forward the traffic based on the location information (e.g. IP in IP tunnel). Section 3.2 below provides more detailed descriptions. b. Handoff: when MN changes its point of attachment from previous eLMA to next eLMA, the next eLMA will advertise the same global prefix to the MN over the new link and update new location information for that global prefix to the LMF for the purpose of maintaining the reachability of MN's global prefix. Section 3.3 below provides more detailed descriptions. 3. Detailed Scenarios and Approaches As described above, the distributed anchor in this draft is referred as eLMA as shown in figures below. Note that, although the MAG as defined in RFC[5213] is not shown in the figures below, one should aware that, the MAG could be co-located with the eLMA. 3.1. Initial Attach Luo & Tricci Expires April 18, 2013 [Page 6] Internet-Draft dmm-with--prefix-properties October 2012 Internet | +-----+ | | LMF | Border Router +-----+ | +-----------------+--------- | +---+---+ | eLMA1 | | (DAF) | +--+----+ Global Prefix | |Local Prefix (PreB) | | (PreA) V V +----+ | MN | +----+ IP1: From PreA (Local, without mobility) IP2: From PreB (Global, with mobility) Figure 1. Initial Attach When eLMA1 detects an initial attachment of a mobile node, it sends a RA message to that mobile. The RA includes two categories of prefixes, local prefix (PreA) and global prefix (PreB). The eLMA should set PreA (i.e. local prefix) with high priority and PreB (i.e. global prefix) with low priority as according to [I-D.korhonen-dmm-prefix-properties]. The mobile node will derive its IPv6 addresses based on these two categories of IPv6 prefixes provided by the RA message. The derived IPv6 addresses include local IPv6 address (IP1 in figure 1) and global IPv6 address (IP2 in figure 1). Applications on the mobile node could select an appropriate IPv6 address as its source address as described in section 4 in [I-D.korhonen-dmm-prefix-properties]. Furthermore, the eLMA1 needs to perform the location update for the MN based on the MN's global prefix-to-location mapping info, i.e. {MN's global prefix, eLMA's IPv6 address}, for this particular mobile node to the LMF based on the mechanism introduced in section 7.2 of [I-D.luo-dmm-pmip-based-dmm-approach]. Note that, the distributed anchor performs the location update only for the MN's global prefix. 3.2. Data forwarding Luo & Tricci Expires April 18, 2013 [Page 7] Internet-Draft dmm-with--prefix-properties October 2012 IP1 as destination: common routing | +-------+ +----+ | | eLMA3 |_______| CN | +-----+ +-------------+ (DAF) | +----+ | LMF | | +-------+ +-----+ | IP2 as destination: | Routing based on location --------------+----+ (e.g. IP in IP tunnel) | +---+---+ | eLMA1 | | (DAF) | +--+----+ Global Prefix | |Local Prefix (PreB) | | (PreA) V V +----+ | MN | +----+ IP1: From PreA (Local, without mobility) IP2: From PreB (Global, with mobility) Figure 2.1 Data forwarding mechanism When correspondent node (CN) sends traffic to the mobile node, the traffic will arrive at CN's distributed anchor first (i.e. eLMA3 in figure 2.1). Depending on the category of the destination IPv6 address, eLMA3 will operate accordingly: 1. If the destination IPv6 address with local IPv6 prefix (IP1 in figure 2.1), eLMA3 will route the IP packet by using the generic IPv6 routing mechanism. 2. Otherwise, if the destination IPv6 address with global IPv6 prefix (IP2 in figure 2.1), then eLMA3 will route this IP packet using routing mechanism as specified in section 7.2 of [I-D.luo-dmm-pmip-based-dmm-approach]. Luo & Tricci Expires April 18, 2013 [Page 8] Internet-Draft dmm-with--prefix-properties October 2012 +-------+ +----+ | eLMA3 |<--------------+ CN | | (DAF) | +----+ +-------+ Destination IP (IP2)is Tunneled || global IPv6 address forwarding || configured on MN based on MN's || location || VV +-------+ +----+ | eLMA1 +-------------->| MN | | (DAF) | +----+ +-------+ Figure 2.2 traffic between CN and MN, when destination is global IPv6 address of MN, routing is optimized. As shown in figure 2.2, if the traffic from CN is sent to the mobile node's global IPv6 address (i.e. IP2), the routing will be: CN-->eLMA3==>eLMA1-->MN which is based on optimized route. Note that, the tunnel between eLMA1 and eLMA3 is not per MN-CN pair, rather, it is a single tunnel between two distributed anchor peers. Any traffic between the MNs which are attached to these two peers will be routed over the same tunnel of which the tunnel is over an optimal routing path between the peers. 3.3. Handoff Scenario Luo & Tricci Expires April 18, 2013 [Page 9] Internet-Draft dmm-with--prefix-properties October 2012 IP1 as destination: can not be reachable after handoff Internet IP3 as destination: | common routing | +-------+ +----+ | | | eLMA3 |_______| CN | | +-----+ +------+ (DAF) | +----+ Border Router | LMF | | +-------+ | +-----+ | IP2 as destination: | | Routing based on location +-----+---------------------+--+ | | +---+---+ +---+---+ | eLMA2 | | eLMA1 | | (DAF) | | (DAF) | +-------+ +--+----+ Local Prefix | | Global Prefix | |Local Prefix (PreC) | | (PreB) | | (PreA) V V V V +----+ +----+ | MN | <------------ | MN | +----+ +----+ IP3: From PreC IP1: From PreA (Local, without mobility) (Local, without mobility) IP2:Keep unchanged IP2: From PreB (Global, with mobility) (Global, with mobility) Figure 3.1 Handover Scenario The handover between distributed anchors happens when the mobile node switches to a new distributed anchor, i.e. switching its anchor from eLMA1 to eLMA2 as shown in figure 3.1. Once eLMA2 detects the attachment from the MN, it will send a RA which includes local prefix(es) and global prefix(es) to the mobile node and the handover operation is described as follows: a. MN's local prefix assigned by the previous distributed anchor (PreA in figure 3.1) will be deprecated\invalidated. In this case, the traffic which is sent to IP1 (configured from PreA) from CN will be discarded by the IPv6 routing system automatically; unless, a temporary tunnel between the previous and the next distributed anchors is setup to maintain the reachability to the previous local prefix. Applications which rely on those local prefixes may suffer a change of source IP address. Luo & Tricci Expires April 18, 2013 [Page 10] Internet-Draft dmm-with--prefix-properties October 2012 b. New local prefix(es) (i.e. PreC in figure 3.1) carried in the RA message and is assigned by eLMA2 is now have high priority. The MN will derive a new IPv6 local address (IP3 in figure 3.1) for the PreC. c. The global prefix(es) (i.e.PreB in figure 3.1) in the RA message remain the same global prefix(es) as assigned by eLMA1 which is the distributed anchor of this MN during its initial attachment. The eLMA2 shall perform the location update for the global prefixes of this MN based on the IPv6 address of eLMA2 to LMF to maintain the reachability of those global prefix(es). The details for the handover can be reviewed in section 7.2 of [I-D.luo-dmm-pmip-based-dmm-approach] Thus, after the handover, the mobile node can be reached either via its new local IPv6 address (i.e. IP3) or via its global IPv6 address (i.e. IP2); and if a temporary tunnel is present between eLMA1 and eLMA2, also be researchable via its previous local IPv6 address (i.e.IP1). It is the network policy to decide to maintain the reachability to the previous local prefix via a temporary tunnel between the previous distributed anchor and the next distributed anchor as described in section 4.4.2 of [I-D.korhonen-dmm-local-prefix] (Note that the distributed anchor refers to MAG in [I-D.korhonen-dmm-local-prefix] and eLMA in this draft). Never-the-less, the purpose for such temporary tunnel to support service continuity when employing the local prefix is similar to the tunnel used by the global prefix for the mobility management purpose. +-------+ +----+ | eLMA3 |<--------------+ CN | | (DAF) | +----+ +-------+ Destination IP (IP2) is Tunneled || global IPv6 address forwarding || configured on MN based on MN's || new location || VV +-------+ +----+ | eLMA2 +-------------->| MN | | (DAF) | +----+ +-------+ (New Distributed anchor after handoff) Figure 3.2 traffic between CN and MN after the handover, when destination is global IPv6 address of MN, routing is also optimized. Luo & Tricci Expires April 18, 2013 [Page 11] Internet-Draft dmm-with--prefix-properties October 2012 As shown in figure 3.2, if the traffic from CN is sent to the mobile node's global IPv6 address (i.e. IP2) after the handover, the routing will be: CN-->eLMA3==>eLMA2-->MN. The routing is still optimized. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations TBD 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 6.2. References [I-D.korhonen-dmm-local-prefix] Korhonen, J. and T. Savolainen , "Local Prefix Lifetime Management for Proxy Mobile IPv6", March 2012. [I-D.korhonen-dmm-prefix-properties] Korhonen , J., "IPv6 Prefix Mobility Management Properties", July 2012. [I-D.liu-mext-distributed-mobile-ip] Liu, D., "Distributed Deployment of Mobile IPv6", March 2010. [I-D.luo-dmm-pmip-based-dmm-approach] Luo, W., "PMIP Based DMM Approaches", March 2012. Luo & Tricci Expires April 18, 2013 [Page 12] Internet-Draft dmm-with--prefix-properties October 2012 Authors' Addresses 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: Luo & Tricci Expires April 18, 2013 [Page 13]