Netext WG S. Krishnan Internet-Draft Ericsson Intended status: Informational R. Koodli Expires: September 2, 2010 Cisco Systems P. Loureiro NEC D. Oulai Videotron Q. Wu Huawei March 1, 2010 Local Routing for Proxy Mobile IPv6 draft-krishnan-netext-pmip-lr-00 Abstract Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, local routing allows mobile nodes attached to the same or different mobile access gateways to exchange traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes an initiation mechanism for local routing. 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. Krishnan, et al. Expires September 2, 2010 [Page 1] Internet-Draft PMIPv6 Local Routing March 2010 This Internet-Draft will expire on September 2, 2010. Copyright Notice 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. Krishnan, et al. Expires September 2, 2010 [Page 2] Internet-Draft PMIPv6 Local Routing March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3 2. Scenario A11: Two MNs attached to the same MAG and LMA . . . . 4 3. Scenario A21: Two MNs attached to different MAGs but same LMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Scenario A12: Two MNs attached to the same MAG with different LMAs . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Local Routing Initiation (LRI) . . . . . . . . . . . . . . 10 5.2. Local Routing Acknowledgment (LRA) . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Krishnan, et al. Expires September 2, 2010 [Page 3] Internet-Draft PMIPv6 Local Routing March 2010 1. Introduction Proxy Mobile IPv6 [RFC5213] describes the protocol operations to maintain reachability and session persistence for a Mobile Node (MN) without the explicit participation from the MN in signaling operations at the Internet Protocol (IP) layer. In order to facilitate such network-based mobility, the PMIPv6 protocol defines a Mobile Access Gateway (MAG), which acts as a proxy for the Mobile IPv6 [RFC3775] signaling, and the Local Mobility Anchor (LMA) which acts similar to a Home Agent. The LMA and the MAG estalish a bidirectional tunnel for forwarding all data traffic belonging to the Mobile Nodes. In the case where both endpoints are located in the same PMIPv6 domain, this can be suboptimal and results in higher delay and congestion in the network. Moreover, it increases transport costs and traffic load at the LMA. To overcome these issues, local routing can be used to allow nodes attached to the same or different MAGs to directly exchange traffic by using localized forwarding or a direct tunnel between the gateways. [LR-PS] defines the problem statement for PMIPv6 local routing. This document describes a solution for PMIPv6 localized routing. The protocol specified here assumes that both the LMA and the MAG have established bindings for the communicating Mobile Nodes using the PBU and PBA messages specified in [RFC5213]. 1.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]. Krishnan, et al. Expires September 2, 2010 [Page 4] Internet-Draft PMIPv6 Local Routing March 2010 2. Scenario A11: Two MNs attached to the same MAG and LMA In this scenario, the two Mobile Nodes involved in communication are attached to a single MAG and both are anchored at the same LMA. Internet : | | +-----+ | LMA | +-----+ | | | +-----+ | MAG | +-----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ The LMA initiates a local routing session by detecting a flow between two MNs attached to the same MAG. The exact flow identification mechanism is not specified in this document, and is left open for implementations and specific deployments. An example trigger could be that an application-layer signaling entity (such as a SIP Proxy) notifies the LMA about two VoIP flow end-points, and the latter determines that the two end-points are attached to the same MAG. Such a trigger mechanism offers local routing at the granularity of an individual application session, providing flexibility in usage. This and other possible examples serve to illustrate the trigger mechanism for initiating local routing. Krishnan, et al. Expires September 2, 2010 [Page 5] Internet-Draft PMIPv6 Local Routing March 2010 +----+ +----+ +----+ +----+ |MN1 | |MN2 | |MAG | |LMA | +----+ +----+ +----+ +----+ | | | | | data | data | |<--------------------->|<------------->| | | | | | | data | data | | |<--------->|<------------->| | | | LR decision | | | LRI(Opts) | | | |<--------------| | | | | | | | LRA(Opts) | | | |-------------->| | | | | | data | | |<--------------------->| | | | | | | | data | | | |<--------->| | | | | | | | | | After detecting a possibility for local routing, the LMA constructs a Local Routing Initiation (LRI) message that is used to signal the intent to initiate local routing and to convey parameters for the same. This is a Mobility Header message and it contains the MN- Identifier and the Home Network Prefix (as Mobility Header options) for each of the MNs involved. The LMA sends the LRI message to the MAG where the two MNs are attached. The MAG starts by verifying that the two MNs are indeed attached to it. It then creates Local Routing Entries(LREs) for each direction of the communication between the two MNs. The exact form of the forwarding entries is left for the implementations to decide; however, they should contain the HNP corresponding to the destination IP address and a next-hop identifier (e.g. the layer 2 address of the next- hop). These LREs MUST override the BUL entries for the specific HNPs identified in the LRI message. Hence all traffic matching the HNPs is forwarded locally. If a MAG is unable to make deliver packets using the LREs, it is possible that the MN is no longer attached to the MAG. Hence, the MAG SHOULD fall back to using the BUL entry, and the LMA MUST forward the received packets using its BCE. The MAG MAY use other Krishnan, et al. Expires September 2, 2010 [Page 6] Internet-Draft PMIPv6 Local Routing March 2010 mechanisms, such as Proxy MIP6 Fast Handovers [PFMIP6] to forward packets when a handover has taken place. The local forwarding is not permanent. For instance, the LMA may send a LRI message with a request to cancel an existing local forwarding service. The local forwarding also has a default lifetime, upon the expiry of which, the forwarding reverts to bidirectional tunneling. When local forwarding service ceases, the corresponding LFE entries MUST be removed. The MAG completes the processing of the LRI message and responds with a Local Routing Acknowledgment (LRA) message. This Mobility Header message also includes the MN-ID and the HNP for each of the communicating MNs as well as an appropriate Status code indicating the outcome of LRI processing. Status code 0 indicates local routing was successfully offered by the MAG. Any other value for Status code indicates the reason for the failure to offer local routing service. When Status code is 0, the LMA sets a flag in the BCE corresponding to the HNPs to record that local routing is in progress for that HNP. The MAG may refresh the lifetime of an existing local forwarding service. For this, it sends an unsolicited LRA (U-LRA) message that contains the new lifetime value. The MAG MUST wait for the following LRI message from the LMA before it can conclude that the refresh request is granted. Krishnan, et al. Expires September 2, 2010 [Page 7] Internet-Draft PMIPv6 Local Routing March 2010 3. Scenario A21: Two MNs attached to different MAGs but same LMA The LMA may choose to support local forwarding to mobile nodes attached to two different MAGs within a single PMIPv6 domain. Internet : | | +-----+ | LMA | +-----+ | | +----+-----+ | | +----+ +----+ |MAG1| |MAG2| +----+ +----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ As earlier, the LMA initiates LRI as a response to some trigger mechanism. In this case, however, it sends two separate LRI messages to the two MAGs. In addition to the MN-ID and the HNP options, each LRI message contains the IP Address of the counterpart MAG. When the MAG IP Address option is present, each MAG MUST create a local forwarding entry such that the packets for the MN attached to the remote MAG are sent over a tunnel associated with that remote MAG. The tunnel between the MAGs is assumed to be established by means outside the scope of this document. As before, each MAG responds to the LRI with an LRA message. Barring the error cases, all subsequent packets are routed between the MAGs locally, without traversing the LMA. The protocol does not require any synchronization between the MAGs before local forwarding begins. Each MAG begins its local forwarding independent of the other. Krishnan, et al. Expires September 2, 2010 [Page 8] Internet-Draft PMIPv6 Local Routing March 2010 4. Scenario A12: Two MNs attached to the same MAG with different LMAs In this scenario, both the MNs are attached to the same MAG, but are anchored at two different LMAs. Internet : : +------------------+ | | +----+ +----+ |LMA1| |LMA2| +----+ +----+ | | | | +------------------+ | | | +-----+ | MAG | +-----+ : : +---+ +---+ |MN1| |MN2| +---+ +---+ Hence, neither LMA has a means to determine that the two Mobile Nodes are attached to the same MAG. Only the MAG can possibly determine that the two Mobile Nodes involved in communication are attached to it. Hence the local routing has to be initiated by the MAG. The MAG sends an LRI message containing the MN-ID, HNP and the counterpart LMA address to each LMA. Each LMA makes decision to support local forwarding independently, based on, among others, policy configuration for the counterpart LMA. Each LMA MUST respond to the LRI message with an LRA message. Only after it receives both the LRA messages each with Status value set to zero (success) from the two different LMAs, the MAG MUST conclude that it can provide local forwarding support for the two Mobile Nodes. Krishnan, et al. Expires September 2, 2010 [Page 9] Internet-Draft PMIPv6 Local Routing March 2010 +----+ +----+ +----+ +----+ +----+ |MN1 | |MN2 | |MAG | |LMA1| |LMA2| +----+ +----+ +----+ +----+ +----+ | | | | | | data | data | data | |<--------------------->|<--------->|<----------->| | | | | | | | data | data | | |<--------->|<----------------------->| | | | | | | | | | | | | | LRI(Opts) | | | | |---------->| | | | | | | | | | LRI(Opts) | | | |------------------------>| | | | | | | | | LRA(Opts) | | | | |<----------| | | | | | | | | | LRA(Opts) | | | |<------------------------| | | | | | | | | | | | | | | | | data | data | | |<--------------------->|<--------->| | | | | | | | | data | | | | |<--------->| | | | | | | | | | | | | Krishnan, et al. Expires September 2, 2010 [Page 10] Internet-Draft PMIPv6 Local Routing March 2010 5. Message Formats 5.1. Local Routing Initiation (LRI) The LMA sends an LRI message to a MAG to request local forwarding for a pair of MNs. The MAG may also send this message to request the two LMAs for offering local forwarding Section 3.3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Set by a sending node in a request message, and used to match a reply to the request. 'R' flag: Set to 0, indicates it is an LRI message. 'S' flag: When set to 1, indicates a request to stop local routing. Reserved: This field is unused. MUST be set zero. Lifetime: The requested time in seconds for which the sender wishes to have local forwarding. Mobility Options: MUST contain the MN-ID, followed by one or more HNPs for each of the MNs. For instance, for Mobile Nodes MN-1 and MN-2 with identifiers MN-ID1, MN-ID2 and Home Network Prefixes HNP-MN-1 and HNP-MN-2, the following tuple in the following order MUST be present: [MN-ID1, HNP-MN-1], [MN-ID2, HNP-MN-2]. The MN-ID and HNP options are the same as in [RFC5213]. MAY contain the remote MAG IPv6 address option, which is identical to the HNP option except for Prefix Length equal to 128 bits. MAY contain the conterpart LMA IPv6 option, which is identical to the HNP option except for Prefix Length equal to 128 bits. Krishnan, et al. Expires September 2, 2010 [Page 11] Internet-Draft PMIPv6 Local Routing March 2010 The LRI message SHOULD be re-transmitted if a corresponding LRA message is not received within LRA_WAIT_TIME time units, up to a maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units. 5.2. Local Routing Acknowledgment (LRA) A MAG sends an LRA message to the LMA as a response to the LRI message. An LMA may also send this message to a MAG as a response to the LRI message Section 3.3. Krishnan, et al. Expires September 2, 2010 [Page 12] Internet-Draft PMIPv6 Local Routing March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|U| Reserved | Status | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Set by a sending node in a request message, and used to match a reply to the request. 'R' flag: Set to 1, indicates it is an LRA message. 'U' flag: When set to 1, the LRA message is sent unsolicited. The Lifetime field indicates a new requested value. The MAG MUST wait for the regular LRI message to confirm that the request is acceptable to the LMA. Reserved: This field is unused. MUST be set zero. Status: 0: Success 1: Failure Lifetime: The time in seconds for which the local forwarding is supported. Typically copied from the corresponding field in the LRI message. Mobility Options: When Status code is 0, MUST contain the [MN-ID, HNP] tuples in the same order as in the LRI message. When Status code is 1, MUST contain only those [MN-ID, HNP] tuples for which local forwarding is supported. The MN-ID and HNP options are the same as in [pmipv6]. Krishnan, et al. Expires September 2, 2010 [Page 13] Internet-Draft PMIPv6 Local Routing March 2010 6. Security Considerations The protocol specified in this document uses the same security association between the LMA and the MAG to protect the LRI and LRA messages. No new security risks are identified. Support for integrity protection using IPsec is required, but support for confidentiality is not necessary. Krishnan, et al. Expires September 2, 2010 [Page 14] Internet-Draft PMIPv6 Local Routing March 2010 7. IANA Considerations The Local Routing Initiation, described in Section 5.1 and the Local Routing Acknowledgment, described in Section 5.2 require a single Mobility Header Type from the registry at http://www.iana.org/assignments/mobility-parameters Krishnan, et al. Expires September 2, 2010 [Page 15] Internet-Draft PMIPv6 Local Routing March 2010 8. Normative References [I-D.ietf-netext-pmip6-lr-ps] Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized Routing Problem Statement", draft-ietf-netext-pmip6-lr-ps-00 (work in progress), September 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Krishnan, et al. Expires September 2, 2010 [Page 16] Internet-Draft PMIPv6 Local Routing March 2010 Authors' Addresses Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: suresh.krishnan@ericsson.com Rajeev Koodli Cisco Systems Email: rkoodli@cisco.com Paulo Loureiro NEC Email: paulo.loureiro@nw.neclab.eu Desire Oulai Videotron Email: desire.oulai@videotron.com Qin Wu Huawei Email: Sunseawq@huawei.com Krishnan, et al. Expires September 2, 2010 [Page 17]