NETLMM Working Group Rajeev. Koodli Internet-Draft Kuntal. Chowdhury Intended status: Standards Track Starent Networks Expires: April 18, 2010 October 15, 2009 Local Forwarding in Proxy Mobile IPv6 draft-koodli-netext-local-forwarding-01.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 April 18, 2010. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract With bidirectional tunneling in Proxy Mobile IPv6, the communication between any two Mobile Nodes is required to traverse the Local Mobility Anchor (LMA). This is the case even when the communicating Koodli & Chowdhury Expires April 18, 2010 [Page 1] Internet-Draft Local Forwarding October 2009 Mobile Nodes are attached to the same Mobility Anchor Gateway (MAG). This document introduces two messages between the LMA and the MAG enabling local forwarding by the MAG. Such forwarding avoids the delay due to bidirectional forwarding, and reduces the traffic load on the LMA. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Basic LMA-MAG scenario . . . . . . . . . . . . . . . . . . 4 3.2. Inter-MAG Local Forwarding . . . . . . . . . . . . . . . . 5 3.3. Single MAG, multiple LMAs . . . . . . . . . . . . . . . . 6 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Local Forwarding Request (LFRQ) . . . . . . . . . . . . . 6 4.2. Local Forwarding Reply (LFRP) . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Koodli & Chowdhury Expires April 18, 2010 [Page 2] Internet-Draft Local Forwarding October 2009 1. Introduction Proxy Mobile IPv6 [pmipv6] 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 Mobility Anchor 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. This bidirectional tunnel is used even when the communicating MNs are attached to the same MAG, or are attached to two different MAGs in the same access network. This method of forwarding always relies on the transport network (between the MAG and the LMA) which could be the bottleneck in terms of delay and cost. Furthermore, distributing the load to the network periphery whenever feasible could also achieve load balancing within the PMIPv6 network domain. This document provides a pair of messages between the LMA and the MAG to enable local forwarding of traffic without the involvement of LMA. The LMA sends a Local Forwarding Request (LFRQ) message to request a MAG to establish local forwarding for a pair of mobile nodes identified by their MN-Identifiers and Home Network Prefixes. The MAG indicates the resolution of LFRQ message in the Local Forwarding Reply (LFRP) message, confirming local forwarding when it is able to establish Local Forwarding Entries. Similarly, a MAG may also send the LFRQ messages to LMAs (when the two communicating Mobile Nodes are anchored at different LMAs), and initiate local forwarding once it receives LFRP messages from those LMAs. Subsequently, all the traffic matching the HNP is forwarded locally, without traversing the bidirectional tunnel with the LMA. Since HNP is used to identify candidate traffic for local forwarding, the protocol allows the flexibility of choosing a subset of the traffic for local forwarding, while the rest of the traffic is allowed to traverse bidirectional tunneling. 2. 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 RFC 2119 [RFC2119]. The document uses the terminology specified in [pmipv6] and in [rfc3775]. In addition, this document defines the following: Koodli & Chowdhury Expires April 18, 2010 [Page 3] Internet-Draft Local Forwarding October 2009 Local Forwarding: Data forwarding by a MAG without using the bidirectional tunnel with the LMA. Local Forwarding Request (LFRQ): A message sent by a node (such as the LMA) requesting its peer (such as the MAG) to provide local forwarding for a pair of Mobile Nodes. Local Forwarding Reply (LFRP): A reply containing the resolution of the LFRQ message. 3. Protocol 3.1. Basic LMA-MAG scenario In this scenario, the two Mobile Nodes involved in communication are attached to a single MAG and both are anchored at the same LMA. 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 [pmipv6]. Subsequently, a trigger at the LMA identifies a flow between two mobile nodes 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 of a 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 forwarding 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 forwarding. As a response to the trigger, the LMA constructs a Local Forwarding Request (LFRQ) message assuming the local policy is so configured. This Mobility Header message contains the MN-Identifier and the Home Network Prefix (as Mobility Header options) for each of the Mobile Nodes involved. The LMA sends the LFRQ message to the MAG supporting the two MNs. The MAG verifies that the two MNs are indeed attached to itself. It then creates Local Forwarding Entries for each direction of the communication between the two MNs. The exact form of the forwarding entries is implementation (and system) dependent; however, they should contain the HNP corresponding to the destination IP address and a next-hop identifier (such as the layer 2 address of the next- hop which is known to ensure forwarding of packets to the Koodli & Chowdhury Expires April 18, 2010 [Page 4] Internet-Draft Local Forwarding October 2009 destination). These LFEs MUST override the BUL entries for the specific HNPs identified in the LFRQ message. Hence all traffic matching the HNPs is forwarded locally. If a MAG is unable to make forward progress for packets using the LFEs, it is likely that the MN has moved out of its range. Hence, the MAG SHOULD fallback to using the BULE, and the LMA MUST forward the received packets using its BCE. The mechanism used for determining forward progress are implementation-dependent. The MAG MAY use other mechanisms, such as Proxy MIP6 Fast Handovers [pfmip6] to forward packets when there is handover. The local forwarding is not permanent. For instance, the LMA may send a LFRQ message with a request to cancel an existing local forwarding service. Such a message may be generated as a result of termination of a VoIP session. 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 provides a resolution of the LFRQ processing in the Local Forwarding Reply (LFRP) message. This Mobility Header message includes the MN-IDentifier and the HNP for each of the communicating MNs as well as an appropriate Status code disposing the outcome of LFRQ processing. Status code 0 indicates local forwarding is offered by the MAG. Any other value for Status code indicates the reason for not offering the local forwarding service. When Status code is 0, the LMA adds an 'F' flag to the BCE corresponding to the HNPs to record that local forwarding is in progress. The MAG may refresh the lifetime of an existing local forwarding service. For this, it sends an unsolicited LFRP (U-LFRP) message that contains the new lifetime value. The MAG MUST wait for the following LFRQ message from the LMA before it can conclude that the refresh request is granted. 3.2. Inter-MAG Local Forwarding The LMA may choose to support local forwarding to mobile nodes attached to two different MAGs within a single PMIPv6 domain. As earlier, the LMA initiates LFRQ as a response to some trigger mechanism. In this case, however, it sends two separate LFRQ messages to the two MAGs. In addition to the MN-ID and the HNP options, each LFRQ 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 Koodli & Chowdhury Expires April 18, 2010 [Page 5] Internet-Draft Local Forwarding October 2009 means outside the scope of this document. As before, each MAG responds to the LFRQ with an LFRP 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. 3.3. Single MAG, multiple LMAs In this scenario, two Mobile Nodes are attached to the same MAG, but are anchored at two different LMAs. Hence, each LMA has no 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 itself. Hence the local forwarding protocol has to be initiated by the MAG. The MAG sends an LFRQ 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 LFRQ message with an LFRP message. Only when it receives both the LFRP 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. 4. Message Formats 4.1. Local Forwarding Request (LFRQ) The LMA sends an LFRQ 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. Koodli & Chowdhury Expires April 18, 2010 [Page 6] Internet-Draft Local Forwarding October 2009 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|C| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Local Forwarding Request (LFRQ) Message 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 LFRQ message. 'C' flag: When set to 1, indicates a request to cease local forwarding 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 [pmipv6]. 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. The LFRQ message SHOULD be re-transmitted if a corresponding LFRP message is not received within LFRP_WAIT_TIME time units, up to a maximum of LFRQ_RETRIES, each separated by LFRP_WAIT_TIME time units. Koodli & Chowdhury Expires April 18, 2010 [Page 7] Internet-Draft Local Forwarding October 2009 4.2. Local Forwarding Reply (LFRP) A MAG sends an LFRP message to the LMA as a response to the LFRQ message. An LMA may also send this message to a MAG as a response to the LFRQ message 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|U| Reserved | Status | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Local Forwarding Reply (LFRP) Message 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 LFRP message. 'U' flag: When set to 1, the LFRP message is sent unsolicited. The Lifetime field indicates a new requested value. The MAG MUST wait for the regular LFRQ 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, one or more MN bindings do not exist 2: Failure, unable to establish local forwarding with the remote MAG Koodli & Chowdhury Expires April 18, 2010 [Page 8] Internet-Draft Local Forwarding October 2009 Lifetime: The time in seconds for which the local forwarding is supported. Typically copied from the corresponding field in the LFRQ message. Mobility Options: When Status code is 0, MUST contain the [MN-ID, HNP] tuples in the same order as in the LFRQ 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]. 5. Security Considerations The protocol specified in this document uses the same security association between the LMA and the MAG to protect the LFRQ and LFRP messages. No new security risks are identified. Support for integrity protection using IPsec is required, but support for confidentiality is not necessary. 6. IANA Considerations The Local Forwarding Request, described in Section 4.1 and the Local Forwarding Reply, described in Section 4.2 require a single Mobility Header Type from the registry at http://www.iana.org/assignments/mobility-parameters: 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [pmipv6] Gundavelli, S. and al. et, "Proxy Mobile IPv6", RFC 5213, Aug 2008. [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004, . 7.2. Informative References [pfmip6] Yokota, H. and et. al, "Fast Handovers for Proxy Mobile IPv6", Mar 2009, . Authors' Addresses Rajeev Koodli Starent Networks USA Email: rkoodli@starentnetworks.com Kuntal Chowdhury Starent Networks USA Email: kchowdhury@starentnetworks.com Koodli & Chowdhury Expires April 18, 2010 [Page 10]