NetExt Working Group M. Liebsch Internet-Draft NEC Intended status: Informational S. Jeong Expires: January 13, 2011 ETRI Q. Wu Huawei July 12, 2010 PMIPv6 Localized Routing Problem Statement draft-ietf-netext-pmip6-lr-ps-03.txt Abstract Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 13, 2011. Copyright Notice Liebsch, et al. Expires January 13, 2011 [Page 1] Internet-Draft PMIPv6 Localized Routing PS July 2010 Copyright (c) 2010 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Problem Statement for Localized Routing in PMIPv6 . . . . . . 5 3.1. General observation . . . . . . . . . . . . . . . . . . . 5 3.2. Analysis of different use cases . . . . . . . . . . . . . 6 3.3. IPv4 consideration . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Localized Routing for communication between IPv4 Home Addresses . . . . . . . . . . . . . . . . . . . . 8 3.3.2. IPv4 Transport Network Considerations . . . . . . . . 9 4. Functional Requirements for Localized Routing . . . . . . . . 10 5. Roaming Considerations . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Change Notes . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Liebsch, et al. Expires January 13, 2011 [Page 2] Internet-Draft PMIPv6 Localized Routing PS July 2010 1. Introduction The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the base protocol for network-based localized mobility management (NetLMM), which takes basic operation for registration, de- registration and handover into account. The scope of the base protocol covers the set up and maintenance of a forwarding tunnel between an MN's Mobility Access Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data packets will always traverse the MN's MAG and its LMA, irrespective of the location of the MN's remote communication endpoint. Even though an MN may be attached to the same or a different MAG as its Correspondent Node (CN) within the same provider domain, packets being associated with their communication will traverse the MN's and the CN's LMA. The NetLMM Extensions (NetExt) Working Group has an objective to design a solution for localized routing in PMIPv6. This includes the specification of protocol messages and associated protocol operation between PMIPv6 components to support the set up of a direct routing path for data packets between the MN's and the CN's MAG. As a result of localized routing, these packets will be forwarded between the two associated MAGs without traversing the MN's and the CN's LMA(s). In case one or both nodes hand over to a different MAG, the localized routing protocol maintains the localized routing path. Relevant protocol interfaces may include the interface between associated MAGs, between a MAG and an LMA as well as between LMAs. This document analyzes and discusses the problem space of using always the default route through two communicating mobile nodes' local mobility anchors. Furthermore, the problem space of enabling localized routing in PMIPv6 is analyzed and described, while different communication and mobility scenarios are taken into account. Liebsch, et al. Expires January 13, 2011 [Page 3] Internet-Draft PMIPv6 Localized Routing PS July 2010 2. Conventions and Terminology 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]. This document uses the terminology of [RFC5213]. The following terms are used in the context of this problem statement: o Mobile Node (MN): Mobile Node without IP mobility support, which is attached to a Mobility Access Gateway (MAG) and registered with a Local Mobility Anchor (LMA) according to the PMIPv6 specification [RFC5213]. o Correspondent Node (CN): Correspondent Node with or without IP mobility support. The CN represents the communication peer of an MN, which is attached to a MAG and registered with an LMA according to the PMIPv6 specification. o Localized Routing: Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN, which are attached to the same provider domain without intervention of the MN's LMA and the CN's LMA in data forwarding. o Localized Routing States: Information for localized routing on relevant forwarding entities on the direct data path between an MN and a CN. Such information includes route entries and tunnel endpoints and may include further information about the MN and the CN, such as the communicating nodes' Mobile Node Identifier and their assigned Home Network Prefix. Liebsch, et al. Expires January 13, 2011 [Page 4] Internet-Draft PMIPv6 Localized Routing PS July 2010 3. Problem Statement for Localized Routing in PMIPv6 3.1. General observation The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms for direct communication between an MN and a CN. Mechanisms for route optimization in MIPv6 cannot be directly applied in PMIPv6, as MNs do not take part in mobility management and associated signaling. Following the paradigm of PMIPv6, MNs are not involved in mobility signaling, hence cannot perform signaling to set up localized routes. Instead, the PMIPv6 functional entities of the LMA and MAG, which are involved in the mobility management of the MN and the CN, must be able to find out whether or not a localized route is to be used and then control the setup and maintenance of localized routing states accordingly without any assistance from the MN and the CN. In case of communication between two nodes, which are attached to the PMIPv6 network infrastructure and each node is registered with an LMA, data packets between these two nodes will always traverse the responsible LMA(s). At least some deployment would benefit from having such communication localized, rather than traverse the core network to the LMA(s). In the context of this document, such localized communication comprises offloading traffic from LMAs and establish an optimized forwarding path between the two communication endpoints. Localized routing is understood in [RFC5213] as optimization of traffic between an MN and a CN under the same access router, whereas the MN connects to the MAG function of this access router and is registered with an LMA, but the CN is a regular IPv6 node without getting PMIPv6 service. In such case, the MAG forwards traffic directly between the MN and the CN, assuming the MAG is enabled to support this feature (setting of the EnableMAGLocalRouting flag on the MAG) and the MN's LMA enforces this optimization. [RFC5213] does not specify how an LMA can enforce optimization for such local communication. Maintaining local forwarding between the MN and the regular IPv6 CN gets more complex in case the MN performs a handover to a different MAG. Such use case is not considered in the specification and out of scope of this problem statement. This document focuses on use cases, where both nodes, the MN and the CN, are each registered with an LMA and both obtain PMIPv6 mobility service. Localized routing is crucial at least for the following two reasons: First, by limiting the communication to the access nodes, the data traffic traversing the MAG - LMA path (network) can be reduced. This is significant considering that the transport network between the access and the core is often the bottleneck in terms of costs and performance. Second, there may be performance benefits for data flows between the MN and the CN in terms of delay and packet loss, Liebsch, et al. Expires January 13, 2011 [Page 5] Internet-Draft PMIPv6 Localized Routing PS July 2010 especially when the MN and the CN are attached to the same MAG and the LMA is topologically far away from that MAG. Even when the MN and the CN are attached to different MAGs, there could be benefit in limiting the communication to the access network only, rather than traversing the transport network to the LMA. Hence, providing the necessary protocol specification to enable localized routing in PMIPv6 is necessary. 3.2. Analysis of different use cases This problem statement focuses on local communication between PMIPv6 managed nodes being attached to the same provider domain. The following list analyzes different use cases, which consider the existence of multiple LMAs. Figure 1 depicts a PMIPv6-based network with two mobility anchors. According to [RFC5213], the MN moves in the PMIPv6 domain being built by its LMA and MAG. The same applies to the CN, which moves in the PMIPv6 domain being build by the CN's LMA and MAG. The analysis takes no assumption on whether the MN and the CN share the same PMIPv6 domain or not. Internet Backbone : : +------------------+ | | +----+ +----+ |LMA1| |LMA2| +----+ +----+ | | | | +----+------------------+----+ | | +----+ +----+ |MAG1| |MAG2| +----+ +----+ : : : +---+ +---+ +---+ |MN | |CN1| |CN2| +---+ +---+ +---+ Figure 1: Reference architecture for localized routing in PMIPv6 All use cases A assume that both the MN and the CN are registered with an LMA according to the PMIPv6 protocol. Whereas MAG1 is always considered as the MN's current pCoA, the CN can be either connected to the same or a different MAG or LMA as the MN. Accordingly, these topological difference are denoted as follows: Liebsch, et al. Expires January 13, 2011 [Page 6] Internet-Draft PMIPv6 Localized Routing PS July 2010 A[number of MAGs][number of LMAs] A11: MN and CN (CN1) connect to the same MAG (MAG1) and are registered with the same LMA (LMA). The common MAG may forward data packets between the MN and the CN directly without forwarding any packet to the LMA. A12: MN and CN (CN1) connect to the same MAG (MAG1) and are registered with different LMAs (LMA1 and LMA2). The common MAG may forward data packets between the MN and the CN directly without forwarding any packet to the LMAs. Following the policy of [RFC5213] and enforcement of the set up of a localized forwarding path, potential problems exist in case LMA1 and LMA2 differ in their policy to control the MAG. A21: The CN (CN2) connects to a different MAG (MAG2) as the MN (MAG1), but MN and CN are registered with the same LMA (LMA1). The result of localized routing should be the existence of routing information at MAG1 and MAG2, which allows direct forwarding of packets between the MN's MAG1 and the CN's MAG2. As LMA1 is the common anchor for MN and CN and maintains location information for both nodes, no major race condition and instability in updating the states for localized routing is expected. A22: The CN (CN2) connects to a different MAG (MAG2) and a different LMA (LMA2) as the MN (MAG1, LMA1). The result of localized routing should be the existence of routing information at MAG1 and MAG2, which allows direct forwarding of packets between the MN's MAG1 and the CN's MAG2. As the location information of the CN and the MN is maintained at different LMAs, both LMAs need to be involved in the procedure to set up localized routing. In case of a handover of the MN and/or the CN to a different MAG, not synchronized control of updating the states for localized routing may result in race conditions, superfluous signaling and packet loss. The following list summarizes general problems with setting up and maintaining localized routing between an MN and a CN. In the context of this problem statement, the MN and the CN are always assumed to be registered at an LMA according to the PMIPv6 protocol [RFC5213]. o MNs do not participate in mobility management, hence cannot perform binding registration at a CN on their own. Rather entities in the network infrastructure must take over the role of MNs to set up and maintain a direct route. Accordingly, a solution for localized routing in PMIPv6 must specify protocol operation between relevant network components, such as between a MAG and an LMA, to enable localized routing for data traffic Liebsch, et al. Expires January 13, 2011 [Page 7] Internet-Draft PMIPv6 Localized Routing PS July 2010 without traversing the MNs' LMA(s) o In case the MN and the CN are both registered with different LMAs according to the PMIPv6 protocol, relevant information for the set up of a localized routing path, such as the current MAG of the MN and the CN, is distributed between these LMAs. This may complicate the set up and stable maintenance of states enabling localized routing. o In case localized routing between an MN and a CN has been successfully set up and both nodes move and attach to a new access router simultaneously, signaling the new location and maintenance of states for localized routing at relevant routers may run into a race condition situation. This can happen in case coordination of signaling for localized routing and provisioning of relevant state information is distributed between different network entities, e.g. different LMAs. In such case, as a result of MN's handover, updated information about the MN's location may arrive at the CN's previous MAG while CN moved already to a new MAG. The same applies to the other direction, where the system may update MN's previous MAG about CN's new location while the MN has moved to a new MAG in the meantime. The protocol solution must deal with such exceptional handover cases efficiently to avoid or resolve such problem. 3.3. IPv4 consideration According to [RFC5844], the basic configuration requirements for supporting IPv4 in PMIPv6 are that LMAs and MAGs are both IPv4 and IPv6 enabled. Also, LMAs and MAGs must have a globally unique IPv6 address configured, irrespective of enabled support for IPv6 routing between these components. This requirement should also apply to configuration requirements of localized routing. Additional issues emerge when localized routing is considered for PMIPv6 with IPv4 support. These can be classified into two general groups, which are issues with localized routing between an MN's and a CN's IPv4 Home Addresses or transport plane issues. The following subsections analyze these two groups. 3.3.1. Localized Routing for communication between IPv4 Home Addresses In case an LMA and a MAG hold a registration to support IPv4 Home Address mobility for an MN, the MAG and the LMA must support appropriate encapsulation of IPv4 packets. To enable localized routing, the MN's MAG must encapsulate and forward routing path optimized packets to the CN's MAG and needs to ensure, that the chosen encapsulation mode is supported by the correspondent MAG. Liebsch, et al. Expires January 13, 2011 [Page 8] Internet-Draft PMIPv6 Localized Routing PS July 2010 Incompatibility in a selected encapsulation mode causes failure in setting up a localized route. When localized routing is used for IPv4 traffic, the conceptual data structures on associated MAGs must be augmented with appropriate parameters for forwarding localized traffic. MAGs may need to maintain a routing state for each MN-CN-pair and make routing decisions for uplink traffic based on the packets' complete IPv4 source and destination address. Hence, conceptual data structures to handle states for localized routes need to comprise this address tuple for unique identification. 3.3.2. IPv4 Transport Network Considerations The transport network between LMA and MAG may be based on IPv6 or IPv4. Deployments may ensure that the same transport mechanism (i.e., IPv6 or IPv4) is used for operational consistency. Similar to the encapsulation requirement stated in the previous section, the IP version used for localized routing is also assumed, by configuration, to be consistent across all MAGs within the associated provider domain . Optional mechanisms for negotiating the IP version to use as well as the encapsulation mode to use are outside the scope of the NetExt WG's solution for localized routing. Liebsch, et al. Expires January 13, 2011 [Page 9] Internet-Draft PMIPv6 Localized Routing PS July 2010 4. Functional Requirements for Localized Routing Several tasks need to be performed by the network infrastructure components before relevant information for such direct communication is discovered and associated states for localized routing can be set up. The following list summarizes some key functions, which need to be performed by the PMIPv6 enabled network infrastructure to substitute mobile nodes in setting up a direct route. o Detection of the possibility to perform localized routing. This function includes looking at data packets' source and destination address. o Initiation of a procedure, which sets up a localized routing path. o Discovery of stateful entities (i.e. the LMA(s) and/or the MAG(s)), which maintain and can provide relevant information needed to set up a localized routing path. Such information may include the routable address of an LMA or MAG, where one or both mobile nodes are connected to and registered with. o Control in setting up and maintaining (e.g. during handover) the localized routing path. Control is also needed to terminate the use of a localized routing path and to delete associated states, whereas a trigger for the termination may come from a non-PMIPv6 related component. Liebsch, et al. Expires January 13, 2011 [Page 10] Internet-Draft PMIPv6 Localized Routing PS July 2010 5. Roaming Considerations Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs, MAGs) tied by MN and CN may be distributed between different provider domains (i.e., domain A, B, C) and MN and/or CN moves from one provider domain to another one. In order to support localized routing when roaming occurs, it is required that MAGs to which MN and CN connect are within the same provider domain and each MAG has a security relationship with the corresponding LMA which maintains the registration of the MN or the CN respectively. According to the roaming model as depicted in Figure 2, MN's PMIPv6 domain is characterized by its MAG (MAG1/MAG1') and its LMA (LMA1), whereas CN's PMIPv6 domain is characterized by CN's MAG (MAG2/MAG2') and its LMA (LMA2). A solution for localized routing cannot take any assumption about whether or not MN and CN share the same PMIPv6 domain, hence MAG1/MAG1' may not share a security association with LMA2/LMA2' and MAG2/MAG2' may not share a security association with LMA1 respectively. It is not required that LMAs, which hold the registration for the MN and the CN respectively, are part of the same provider domain as the MAGs where MN and CN attach. When MN's MAG and MN's LMA belong to different provider domains (A and C), localized routing is subject to policy governing the service level agreements between these domains. The same applies to the provider domains which provide CN's MAG and LMA. Based on the above requirements, four PMIPv6 roaming and non- roaming cases can be taken into account. o Case 1: MN's MAG (MAG1), CN's MAG (MAG2), MN's LMA (LMA1), CN's LMA (LMA2) are located in the same provider domain A. o Case 2: MN's MAG (MAG1), CN's MAG (MAG2), MN's LMA (LMA1) are located in the same domain A while CN's LMA (LMA2') is located in provider domain B. o Case 3: MN's MAG (MAG1'), CN's MAG (MAG2') are located in domain C while MN's LMA (LMA1) and CN's LMA (LMA2) are located in provider domain A o Case 4: MN's MAG (MAG1'), CN's MAG (MAG2') are located in provider domain C while MN's LMA (LMA1) is located in provider domain A, and CN's LMA (LMA2) is located in provider domain B In these roaming cases, MN can be allowed to roam within its domain (e.g, MN's home domain in which MN's LMA is located) or over different domains (e.g., MN moves from its home domain to a visited domain). CN should stay with MN within the same domain. Liebsch, et al. Expires January 13, 2011 [Page 11] Internet-Draft PMIPv6 Localized Routing PS July 2010 | +-----+ +-----+ | +-----+ |LMA1 | |LMA2 | | |LMA2'| +-----+ +-----+ | +-----+ | | | | +-----+ +-----+ | |MAG1 | |MAG2 | | +-----+ +-----+ | | | Provider Domain A | Provider Domain B ------------------------------+------------------------------- Provider Domain C +-----+ +-----+ |MAG1'| |MAG2'| +-----+ +-----+ Figure 2: PMIPv6 roaming cases considered for Localized Routing Liebsch, et al. Expires January 13, 2011 [Page 12] Internet-Draft PMIPv6 Localized Routing PS July 2010 6. Security Considerations Since network entities rather than MNs and CNs perform signaling to set up localized routing, the MIPv6 return routability test [RFC3775] is not suitable to authenticate associated signaling messages in PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate or to provide sufficient defense against possible security threats. When PMIPv6 participants are administered within the same domain, infrastructure-based authorization mechanisms, such as IPsec, may be usable to protect signaling for localized routing. Existing security associations according to [RFC5213] can be re-used to protect signaling for localized routing on the interface between a MAG and an LMA. In case a protocol solution for localized routing in PMIPv6 relies on protocol operation between MAGs, means for protection of signaling between these MAGs must be provided. The same applies for signaling on a possible protocol interface between two LMAs of the same domain. Liebsch, et al. Expires January 13, 2011 [Page 13] Internet-Draft PMIPv6 Localized Routing PS July 2010 7. Acknowledgments Many aspects of the problem space for route optimization in PMIPv6 have been discussed in the context of a PMIPv6 Route Optimization Design Goals document, which has been submitted to the NetLMM WG in November 2007. This group of contributors includes Sangjin Jeong, Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Behcet Sarikaya, Shinta Sugimoto, Long Le, Alice Qinxia and Jaehwoon Lee. Many thanks also to Rajeev Koodli for his comments about the structure and scope of this problem statement. This version of the problem statement reflects the results of the discussion in the NetExt group based on the initial version of the document. Many thanks to Hidetoshi Yokota, Carlos Bernardos, Ashutosh Dutta, Sri Gundavelli, Mohana Jeyatharan, Jouni Korhonen and Glen Zorn for their comments. Liebsch, et al. Expires January 13, 2011 [Page 14] Internet-Draft PMIPv6 Localized Routing PS July 2010 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. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. 8.2. Informative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Liebsch, et al. Expires January 13, 2011 [Page 15] Internet-Draft PMIPv6 Localized Routing PS July 2010 Appendix A. Change Notes Changes in version 01: o Removed text about potential issues with IPv4 address conflict from Section 3.3.1 (out of NetExt scope) o Removed NAT issues from Section 3.3.2 (out of NetExt scope) o Removed text about IP version and encapsulation mode negotiation from 3.3.2 (out of NetExt scope) Changes in version 02: o Consistently refer to communication between MN and CN, not between two MNs o Adopt text to the result of the roaming model discussion and refer to provider domain, not PMIPv6 domain o Revision of Terms section according to comments o Revision of text in Section 3.1 about network entities, which perform signaling for localized routing (clarification) o Revision of text in Section 3.1 to clarify about localized routing benefits o Revision of text in Section 3.2 to clarify about signaling race condition in multi-LMA case o Add more text to Section 5 about the roaming model for localized routing, relevance of the PMIPv6 domain concept and associated issues with localized routing in roaming case o Modified heading of Section 3.3.1 to avoid confusion with localized routing between IPv4 Proxy-CoAs Changes in version 03: o Editorial revision according to received comments o IPv4 support reference updated from draft to RFC status Liebsch, et al. Expires January 13, 2011 [Page 16] Internet-Draft PMIPv6 Localized Routing PS July 2010 Authors' Addresses Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@neclab.eu Sangjin Jeong ETRI 138 Gajeongno, Yuseong Daejeon, 305-700 Korea Phone: +82 42 860 1877 Email: sjjeong@etri.re.kr Qin Wu Huawei Technologies,Co.,Ltd 12F, Huihong Mansion,No.91,Baixia Rd., Nanjing, 210001 China Phone: +86 21 84565892 Email: sunseawq@huawei.com Liebsch, et al. Expires January 13, 2011 [Page 17]