Network Working Group M. Liebsch Internet-Draft NEC Intended status: Informational February 5, 2009 Expires: August 9, 2009 PMIPv6 Localized Routing Problem Statement draft-liebsch-netext-pmip6-ro-ps-00.txt 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 August 9, 2009. Copyright Notice Copyright (c) 2009 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. Liebsch Expires August 9, 2009 [Page 1] Internet-Draft PMIPv6 Localized Routing PS February 2009 Abstract Proxy Mobile IPv6 is the IETF standard for network-based localized 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 support for localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without traversing an LMA, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Problem Statement for Localized Routing in PMIPv6 . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Liebsch Expires August 9, 2009 [Page 2] Internet-Draft PMIPv6 Localized Routing PS February 2009 1. Introduction The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the protocol for network-based localized mobility management (NetLMM), which takes basic operation for registration, de-registration and handover into account. In scope of the base protocol specification is 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 two communicating MNs might be attached to the same MAG or to different MAGs of the same local mobility domain, packets will traverse the MNs' LMA(s). Objectives of designing a solution for localized routing in PMIPv6 are to specify protocol messages and enable associated protocol operation between PMIPv6 components to support the set up of a direct routing path for data packets between the MNs' MAGs without forwarding these packets through the MNs' LMA(s) and to maintain localized routing in case one or both MNs handover to a different MAG. 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' 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 Expires August 9, 2009 [Page 3] Internet-Draft PMIPv6 Localized Routing PS February 2009 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 within a single PMIPv6 domain without traversing the MN's LMA and without traversing the CN's mobility anchor. o Localized Routing States: Information for localized routing on relevant forwarding entities on the optimized data path between an MN and a CN. Such information includes route entries and may include further information about the MN and the CN, such as IDs. Liebsch Expires August 9, 2009 [Page 4] Internet-Draft PMIPv6 Localized Routing PS February 2009 3. Problem Statement for Localized Routing in PMIPv6 The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms for direct communication between a 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 architecture of PMIPv6, rather entities of the network infrastructure are dedicated to perform signaling to set up an optimized route between an MN and a 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). 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. And there are performance benefits in terms of delay and packet loss, especially when the MNs are attached to the same MAG. Even when the MNs are attached to different MAGs, there could be benefits 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. 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 an optimized 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. Liebsch Expires August 9, 2009 [Page 5] Internet-Draft PMIPv6 Localized Routing PS February 2009 o Control in setting up and maintaining (e.g. during handover) the localized routing path. This problem statement focuses on local communication between PMIPv6 managed nodes within a single PMIPv6 domain. The following list analyzes different use cases, which are limited to the communication within a single PMIPv6 domain, but they consider the existence of multiple LMAs. Figure 1 depicts the network of a PMIPv6 domain with two mobility anchors. Internet Backbone : : +------------------+ | | . . . . . . +----+ +----+ ^ |LMA1| |LMA2| | +----+ +----+ | | | | | | |PMIPv6 +----+------------------+-+ |domain | | | +----+ +----+ | |MAG1| |MAG2| v +----+ +----+ . . . . : : : +---+ +---+ +---+ |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: 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. According to [RFC5213], such operation should be enforced by the LMA and signaled in the PBU by means of the EnableMAGLocalRouting flag. Liebsch Expires August 9, 2009 [Page 6] Internet-Draft PMIPv6 Localized Routing PS February 2009 A12: MN and CN (CN1) connect to the same MAG (MAG1) and are registered with different LMAs (LMA1 and LMA2) of the same PMIPv6 domain. The common MAG may forward data packets between the MN and the CN directly without forwarding any packet to the LMAs. Even though [RFC5213] indicates that localized routing should be based on the MAG's policy, potential problems exist in case LMA1 and LMA2 differ in settings of the EnableMAGLocalRouting flag. 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) in the same PMIPv6 domain. 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 MNs 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 within a PMIPv6 domain. 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 an optimized 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 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 MAGs of the MN and the CN, is distributed between these LMAs. This may Liebsch Expires August 9, 2009 [Page 7] Internet-Draft PMIPv6 Localized Routing PS February 2009 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. Liebsch Expires August 9, 2009 [Page 8] Internet-Draft PMIPv6 Localized Routing PS February 2009 4. 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 Expires August 9, 2009 [Page 9] Internet-Draft PMIPv6 Localized Routing PS February 2009 5. 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, 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. Liebsch Expires August 9, 2009 [Page 10] Internet-Draft PMIPv6 Localized Routing PS February 2009 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. Informative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Liebsch Expires August 9, 2009 [Page 11] Internet-Draft PMIPv6 Localized Routing PS February 2009 Author's Address Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@nw.neclab.eu Liebsch Expires August 9, 2009 [Page 12]