Network Working Group Q. Wu Internet-Draft B. Sarikaya Intended status: Standards Track Huawei Expires: August 16, 2010 February 12, 2010 An Extension to Proxy Mobile IPv6 for Local Routing Optimization draft-wu-netext-local-ro-05 Abstract This document extends local routing in Proxy Mobile IPv6 (PMIPv6) and defines a localized routing optimization protocol between Mobility Access Gateways within a single provider domain. The protocol supports operation over IPv4 transport networks, IPv4 home address mobility and handover. The Local mobility anchor initiated and mobile access gateway initiated local routing are allowed to setup local routing path between the mobile and correspondent node by sending messages to the corresponding mobile access gateway or local mobility anchor. If the MN & CN are anchored with two different LMAs then the MN-LMA must discover which LMA the CN is registered with before an optimized local routing path can be established. Mobile Access Gateways create and refresh bindings using proxy binding update and acknowledgement messages. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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. Wu & Sarikaya Expires August 16, 2010 [Page 1] Internet-Draft PMIPv6 Local Routing Optimization February 2010 This Internet-Draft will expire on August 16, 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. Wu & Sarikaya Expires August 16, 2010 [Page 2] Internet-Draft PMIPv6 Local Routing Optimization February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PMIP6 Local Routing OptimizationScenario Analysis . . . . . . 5 4. Local Routing Optimization Protocol Overview . . . . . . . . . 6 4.1. MAG-initiated Local Routing Optimization . . . . . . . . . 7 4.1.1. Handover Considerations . . . . . . . . . . . . . . . 9 4.2. LMA-initiated Local Routing Optimization . . . . . . . . . 10 4.2.1. Handover Considerations . . . . . . . . . . . . . . . 11 5. Processing Considerations . . . . . . . . . . . . . . . . . . 12 5.1. Mobile Access Gateway Considerations . . . . . . . . . . . 12 5.2. Local Mobility Anchor Considerations . . . . . . . . . . . 15 6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. IPv4 HoA Support . . . . . . . . . . . . . . . . . . . . . 17 6.2. IPv4 Transport Support . . . . . . . . . . . . . . . . . . 17 7. Inter-LMA Local Routing Considerations . . . . . . . . . . . . 18 7.1. MAG-initiated Inter-LMA Local Routing . . . . . . . . . . 18 8. Conceptual Data Structure Extensions . . . . . . . . . . . . . 19 8.1. Binding Update List Extensions . . . . . . . . . . . . . . 19 8.2. Binding Cache Entry Extensions . . . . . . . . . . . . . . 20 8.3. Routing Table Entry Extensions . . . . . . . . . . . . . . 20 9. Local Routing Optimization Message Format . . . . . . . . . . 21 9.1. Local Routing Optimization Mobility Option . . . . . . . . 21 9.2. The Local Routing Optimization Request (LROREQ) Message . 22 9.3. Local Routing Optimization Response Message (LRORSP) . . . 23 9.4. MN-CNs Pair Mobility Option . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Future Extension . . . . . . . . . . . . . . . . . . 28 A.1. LMA Route Optimization Start Message . . . . . . . . . . . 28 A.1.1. LMA Route Optimization Start Request Message . . . . . 28 A.1.2. LMA Route Optimization Start Response Message . . . . 29 A.2. LMA Initiated Inter-LMA Local Routing . . . . . . . . . . 30 A.2.1. IPv4 Support Consideration . . . . . . . . . . . . . . 31 A.3. LMA Initiated operation for Inter-LMA Local Routing . . . 31 Appendix B. Change Notes . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Wu & Sarikaya Expires August 16, 2010 [Page 3] Internet-Draft PMIPv6 Local Routing Optimization February 2010 1. Introduction Proxy Mobile IPv6 (PMIP6) [RFC5213] allows the Mobility Access Gateway (MAG) to optimize packet delivery by locally routing packets within one MAG instead of reverse tunneling them to the mobile node's Local Mobility Anchor (LMA). However, it does not address the optimization of routing between two Mobile Access Gateways sharing the same LMA or registered to different Local Mobility Anchors; nor does it define how local routing optimization capability is detected, the entity that initiates local routing optimization, or how to determine whether local routing optimization is permitted. This document defines local routing optimization mobility messages and options for PMIPv6 that are intended to assist the Mobile Access Gateways to negotiate and setup a local routing path between each other. The new local routing optimization mobility options allow the LMA and the MAG to discover whether local routing is allowed and, if som what form it may take. The local routing optimization protocol can be initiated by either of the PMIPv6 managed nodes and provides a flexible negotiation mechanism for local routing. As RFC 5213 [RFC5213] warns, use of local routing may affect accounting and traffic policies relating to the mobile node, LMA routing policies, and security policies. The general aim of the proposals in this document is to provide better manageability of local routing services and local routing service provisioning from the point of view of both operators and service providers within one Provider domain. 2. Terminology The keywords "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 RFC 5213 [RFC5213]and RFC 3775 [RFC3775] In addition, this document defines the following terms: Local routing (LR) When local routing is active, traffic between the MN and the CN does not pass through the LMA and is routed directly between the MAG(s) to which the MN and CN are attached. Local routing may only take place between Mobile Access Gateways within a single provider domain. Wu & Sarikaya Expires August 16, 2010 [Page 4] Internet-Draft PMIPv6 Local Routing Optimization February 2010 Local Routing Optimization Request (LROREQ): A message initiated by the MAG or LMA to which the Mobile Node is attached requesting the MAG or LMA to which the Mobile Node or the Correspondent Node is attached to establish a local routing path between the MN and CN. Local Routing Optimization Response (LRORSP): A reply message from a MAG or LMA confirming the local routing optimization results. 3. PMIP6 Local Routing OptimizationScenario Analysis Figure 1 shows the reference architecture for PMIP6 local routing optimization. In this architecture, local communication between PMIPv6 managed nodes (i.e., MAGs) is constrained within a single Provider domain, as described in [I-D.ietf-netext-pmip6-lr-ps]. In the architecture, LMA1 and LMA2 may be the same LMA. +---------+ ============|LMA1/LMA2|============ // +---------+ \\ || || || || || +-----------+ +-----------+ | IPv4/IPv6 | | IPv4/IPv6 | | Network | | Network | +-----------+ +-----------+ || || || || +-----------+ || +------+ |IPv4/IPv6 | +------+ | MAG1 |=============================| MAG2 | +------+ | Network | +------+ | | +-----------+ | | +-----+ +-----+ +-----+ +-----+ | | | | +----+ +-----+ +-----+ +-----+ | MN | | CN1 | | CN2 | | CN3 | +----+ +-----+ +-----+ +-----+ {IPv4-MN-HoA1} {IPv4-CN1-HoA2} {IPv4-CN2-HoA3} {IPv6-CN3-HoA4} {IPv6-MN-HoA1} {IPv6-CN2-HoA3} Figure 1: Reference Architecture for PMIP6 Local Routing Wu & Sarikaya Expires August 16, 2010 [Page 5] Internet-Draft PMIPv6 Local Routing Optimization February 2010 Depending on how MN and CN are distributed into different provider domains, three typical scenarios need to be considered as follows: Scenario 1: Intra-MAG local routing In this scenario, both the MN and CN are attached to the same MAG and are anchored with the same LMA or different LMAs. Scenario 2: Intra-LMA local routing In this scenario, the MN and CN are attached to different MAGs and are anchored with the same LMA. Scenario 3: Inter-LMA local routing In this scenario, the MN and CN are attached to different MAGs and are anchored with different LMAs. In all three scenarios, the MN is allowed to roam within the domain in which its anchoring LMA is located or move from one domain to another. The CN should stay with the MN in the same domain; e.g., the MN moves to the visited domain to which the CN belongs. Another example is if the MN and CN move to the same visited domain to which MN's LMA or CN's LMA does not belong. 4. Local Routing Optimization Protocol Overview The protocol specified here focuses on intra-MAG local routing and intra-LMA local routing and assumes that o the MAGs are situated in one Provider domain o MN and CN are anchored with the same LMA. o The MAG has the capability to perceive intra-MAG local routing (i.e., the MAG can detect whether the mobile node and correspondent node are attached to the same MAG). o The LMA has the capability to perceive intra-LMA local routing (i.e., the LMA can detect whether the MAGs to which the MN and CN are attached belong to the same or different LMAs). The decision to enable/disable detection of local routing should be based on the policy configured on the MAG or LMA. The trigger for detection of local routing may come from uplink or downlink datagram forwarding or from the application layer. The specific details on Wu & Sarikaya Expires August 16, 2010 [Page 6] Internet-Draft PMIPv6 Local Routing Optimization February 2010 how this is achieved are beyond of the scope of this document. Depending on how local routing is initiated, local routing optimization can be categorized into: o MAG-initiated local routing optimization o LMA-initiated local routing optimization 4.1. MAG-initiated Local Routing Optimization When the MAG is triggered and enabled to detect local routing, the MAG can detect whether the MN and CN are attached to the same MAG by looking at the source and destination address of outgoing packets and checking the binding update list of the MN and CN. If, upon receiving a packet from the MN or the CN, the MAG perceives that the MN and CN are both attached to the same MAG, it can initiate local routing optimization by asking the LMA to check the value of the Intra-MAG LocalRouting flag (defined in Section 8.1). If the MAG detects that the MN and CN are not attached to the same MAG but wants to check whether intra-LMA routing is allowed (i.e., the MN and CN are attached to different MAGs but anchored to the same LMA), it also can initiate LR by sending a message to the LMA. The message may be a Binding Update message which contains the Local Routing Optimization Mobility Option (Section 9.1) and Home Network Prefix Option [RFC5213] for the correspondent node or a newly defined local routing optimization message. It will be used to negotiate with the LMA to verify whether local routing is allowed and determine what local routing optimization is supported between the mobile node and correspondent node. If the LMA can not determine whether local routing optimization is supported, it may ask AAA server to make decision, and the AAA server may be used to authorize the use of localized routing service for the MN. If LR is not authorized, the LMA will respond to the MAG that local routing optimization is not available. Otherwise, the LMA will set the Intra-MAG LocalRouting or Intra-LMA LocalRouting flag on the MAG by sending a successful response message with the Local Routing Optimization Indication (LRI) field of the Local Routing Optimization Mobility Option set appropriately. If the LMA can validate the Correspondent Node's Home Network Prefix (HNP), the LMA may notify the MN's MAG of the MAG address associated with the CN's HNP using the MN-CNs Pair Mobility Option (Section 9.4) in the same response message. In the intra-MAG local routing case, the MN-CNs Pair Mobility Option can be omitted from the response message. The LMA may also set its own LocalRouting flag to indicate local routing is in use and correlate it with the binding cache entries corresponding to the MN and CN. Note that setting the local routing flag is helpful for avoiding duplication of local routing behavior initiated from the MAG and triggering the MAG Wu & Sarikaya Expires August 16, 2010 [Page 7] Internet-Draft PMIPv6 Local Routing Optimization February 2010 to setup a local routing path. Distinguishing between different local routing types on the MAG helps the LMA to build the response message efficiently. For example, when Local Routing Optimization (LRI) field of the Local Routing Optimization Mobility Option is set to the value of one, it means that MAG already knows that the MN and CN are attached to the same MAG by checking binding update list, therefore it is unnecessary to include the CN's MN-CNs Pair Mobility Option; when the LRI field is not set to one, the MN-CNs Pair Mobility Option MUST be included in the response message from LMA, since only the LMA knows the address of the MAG to which the CN is attached. After the successful initiation of local routing optimization, if the MN and CN attach to different MAGs (e.g., MAG1 and MAG2) and the intra-LMA LocalRouting flag on MAG is set to value one, MAG1 may send a PBU message to MAG2 setting the lifetime of the binding of the MN at MAG2. Similarly, if the intra-LMA LocalRouting flag is set to value one on MAG2, MAG2 sends a PBU message to MAG1. This PBU message sets the lifetime of the binding of CN at MAG1. Each PBU MUST be acknowledged with a PBA. With the PBU/PBA exchange, the local data path between MAGs is established and the binding caches associated with MN and CN are set up. A PBU-PBA exchange is repeated to extend the lifetime of the binding. Subsequently the routing table entry can be setup based on the binding caches established on the MAGs. The PBU/PBA signaling is protected using IPsec Encapsulation security payload [RFC4303] in transport mode with mandatory integrity protection. For data traffic, either of the MAGs can lookup the routing table entry associated with the MN or CN and identify the tunnel to the right MAG in terms of the destination address of an outgoing data packet. If MN and CN attach to the same MAG, the traffic from the MN will go directly to the CN via the MAG. If MN and CN attach to different MAGs and register to the same LMA, the traffic from MN will be forwarded directly by the MAG associated with the MN to the MAG associated with the CN. Wu & Sarikaya Expires August 16, 2010 [Page 8] Internet-Draft PMIPv6 Local Routing Optimization February 2010 +--+ +------+ +-----+ +------+ +--+ |MN| | MAG1 | | LMA | | MAG2 | |CN| ++-+ +--+---+ +--+--+ +--+---+ +-++ Attach to MAG1 | |Attach to MAG2 |---------->| | <------------+ | Datagram | PBU'/LROREQ | | | |==========>|(MN-CN Pair) | | | | |------------->| | | | | +---+-----+ | | | | |BCE Check| | | | PBA'/LRORSP +---------+ | | | | [MAG2] | | | | |<------------ | | | | +-------+---------+ | | | | |Enable Intra-LMA/| | | | | |intra-MAG Routing| | | | | +-------+---------+ | | | | Bidirectional PBU/PBA between MAGs | | |<--------------------------->| | | +-------------+ | +-------------+ | | |Setup Binding| | |Setup Binding| | | |and Tunnel | | | and Tunnel | | | +-------------+ | +-------------+ | | Datagram | Datagram | Datagram | |==========>|============================>|===========>| | Datagram | Datagram | Datagram | |<==========|<=============|==============|<===========| | | | | | | | | | | Figure 2: MAG-initiated Local Routing Optimization 4.1.1. Handover Considerations When the MN moves from the old MAG (e.g., pMAG1) in the previous access network to a new MAG (e.g., nMAG1) in the new access network, context information (including the MAG addresses of all the CNs which are communicating with MN) for the MN in pMAG1 may be transferred to nMAG1. The Context Request Option [I-D.ietf-mipshop-pfmipv6] can be reused to carry the context information from pMAG1 to nMAG1. nMAG1 can use this data to send PBU messages to each of the MAGs connected to a CN with which the MN was in communication via the provisional secure data path, updating the binding in each MAG with which the MN was in communication and re-establishing an optimal local routing path between the MN and its CNs. Wu & Sarikaya Expires August 16, 2010 [Page 9] Internet-Draft PMIPv6 Local Routing Optimization February 2010 +-----+ +---------+ +---------+ |pMAG1| |nMAG1(MN)| | MAG2(CN)| +--+--+ +---+-----+ +---+-----+ | | | | HI/HACK | | |<--------------->| | |Predictive/Reactive | | |Bidirectional PBU/PBA| | |<------------------> | | | | | +------+------+ +-----+-------+ | |UpdateBinding| |UpdateBinding| | | and Tunnel | | and Tunnel | | +------+------+ +-----+-------+ | | Datagram | | |<===================>| Figure 3: MAG-initiated Local Routing During Handover 4.2. LMA-initiated Local Routing Optimization When the LMA is triggered and enabled to detect local routing, the LMA can detect whether the MN and CN are registered to the same LMA by looking at the source and destination address of outgoing and incoming packets and checking the binding update list of MN and CN. Upon receiving a packet from the MN or CN and detecting that the MN and CN are registered to the same LMA, it may set its intra-LMA LocalRouting flag, correlating it with the binding cache entries associated with the MN and CN. And then LMA initiates local routing optimization to determine the value of Intra-LMA LocalRouting flag (defined in Section 8.1) on the MAG, i.e., notify or enforce the value of intra-LMA LocalRouting flag on the MAG associated with the MN by means of a LROREQ/LRORSP message exchange. It will be used to help LMA to determine whether the local routing optimization is allowed. If local routing optimization is allowed, then LMA will be responsible for enforcing local optimization on the MAG. The AAA server serving the LMA may be used to authorize the use of localized routing service for the MN. IF LR is not authorized,the LMA will respond to the MAG with failure information indicating that intra-LMA routing optimization is not allowed, otherwise, it will notify the MAG to set the intra-LMA LocalRouting flag. The other procedures are same as those described in Section 4.1. Wu & Sarikaya Expires August 16, 2010 [Page 10] Internet-Draft PMIPv6 Local Routing Optimization February 2010 +--+ +------+ +-----+ +------+ +--+ |MN| | MAG1 | | LMA | | MAG2 | |CN| ++-+ +--+---+ +--+--+ +--+---+ +-++ Attach to MAG1 | |Attach to MAG2 |---------->| +-------+----------+ <------------+ | | | BCE Check | | | | | |Perceive MAG1 and | | | | | |MAG2 register to | | | | | |the same LMA | | | | | +-------+----------+ | | | | LROREQ | | | | | (MAG2) | | | | |<------------ | | | | +-------+---------+ | | | | |Enable Intra-LMA/| | | | | | Routing | | | | | +-------+---------+ | | | | LRORSP | | | | |------------->| | | | Bidirectional PBU/PBA between MAGs | | |<--------------------------->| | | +-------------+ | +-------------+ | | |Setup Binding| | |Setup Binding| | | | and Tunnel | | | and Tunnel | | | +-----+-------+ | +-----+-------+ | | Datagram | Datagram | Datagram | |==========>|============================>|===========>| | Datagram | Datagram | Datagram | |<==========|<============================|<===========| Figure 4: LMA Initiated Local routing optimization 4.2.1. Handover Considerations If the MN moves from the old MAG (e.g., pMAG1) in the previous access network to the new MAG (e.g., nMAG1) in a new access network, nMAG1 may update the binding cache entry associated with MN at the LMA by sending a normal PBU message. At the same time, the LMA may refresh the binding update list associated with the MN and update the binding of each MAG with which MN was in communication via the established local route optimization path by sending a LROREQ message to each MAG. Also pMAG1 can use a procedure similar to that described in Section 4.1.1 to transfer MN's registration entry at pMAG1 to nMAG1. Wu & Sarikaya Expires August 16, 2010 [Page 11] Internet-Draft PMIPv6 Local Routing Optimization February 2010 +-----+ +---------+ +----------+ +---------+ |pMAG1| |nMAG1(MN)| |LMA(MN,CN)| | MAG2(CN)| +--+--+ +---+-----+ +----+-----+ +---+-----+ | | Normal PBU | | | |-------------->| | | | | | | | Normal PBA | | | |<------------- | LROREQ | | | |-------------->| | | | | | | | LRORSP | | | |<------------- | | Bidirectional PBU/PBA between MAGs | |<----------------------------->| | +------+------+ | +-----+-------+ | |UpdateBinding| | |UpdateBinding| | | and Tunnel | | | and Tunnel | | +------+------+ Datagram +-----+-------+ | |<=============================>| | | | | Figure 5: LMA-initiated Local Routing Optimization During Handover 5. Processing Considerations 5.1. Mobile Access Gateway Considerations When the MAG sends a LROREQ or PBU to the LMA, it may include the Routing Optimization Mobility and MN-CNs Pair Mobility Options in a binding update message or create a new routing optimization request message to include these two options: o The Routing Optimization Mobility Option is used to negotiate what kind of local routing optimization is available. If intra-MAG local routing is allowed, the LRI field in the Routing Optimization Mobility Option is set to one (1). If the intra-MAG local routing is not available but the MAG would like to check whether intra-LMA local routing is allowed, the MAG will set the LRI field of the Routing Optimization Mobility Option to value 0 in the PBU or LROREQ message to the LMA, because the mobile node's MAG does not know whether traffic between MN and CN can be locally routed within one LMA. o The MN-CNs Pair Mobility Option is used for the LMA to verify the validity of the local routing optimization path end points (in the intra-MAG local routing scenario) or to request the LMA to determine the proxy CoA-Address of the Crrespondent Node for local Wu & Sarikaya Expires August 16, 2010 [Page 12] Internet-Draft PMIPv6 Local Routing Optimization February 2010 routing optimization (in the intra-LMA local routing scenario). In the case of intra-MAG local routing, MAG should fill the MN-CNs Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP and CN Proxy CoA. In the case of intra-LMA local routing, the MAG only fills MN-CN pairs mobility option with MN's HNP, MN's Proxy CoA and CN's HNP. When the MAG receives a binding acknowledgement message containing the Routing Optimization Mobility Option or routing optimization response message it will check the validity of all the fields, including whether the sequence number value in the acknowledge/ response message is identical to the sequence number value in the corresponding request and whether the MN-CNs Pair Mobility Option is present. If the message is valid, the MAG will extract the LRI field from the Routing Optimization Mobility Option or routing optimization response message and check the value. If the LRI field is zero, it indicates the LMA does not support local routing optimization and the MAG should set the intra-MAG LocalRouting flag to zero in the binding update list extension; if the LRI field is one, it indicates that the LMA allows local routing in one MAG and bypass the LMA and MAG should set intra-MAG LocalRouting flag to value one in the binding update list extension. If the LRI field is two, it indicates LMA has found the Correspondent Node's MAG address in terms of the HNP of the CN. In this case, the MAG should extract the Correspondent Node's MAG address from the initial binding acknowledgement or routing optimization response message and store it in a binding update list extension with the Correspondent Node's HNP and set the intra-LMA LocalRouting flag in the binding update list extension. In LMA-initiated local routing, upon receiving a LROREQ message from the LMA, the MAG extracts MN HNP from MN-CNs Pair Mobility Option and searches the binding update list for a matching IPv6 home network prefix in the list of prefixes it stores for each mobile node that the MAG is serving. If a match is found, the MAG MUST send a PBU message to the MAG of the Correspondent Node. PBU message lifetime is set to the lifetime value in LROREQ message. Destination address is the same as Proxy CoA field in the CN part of MN-CNs Pairs Mobility Option included in LROREQ message. The MAG MUST send a PBU message to the MAG of each Correspondent Node if the LROREQ message contains more than one CN in the MN-CNs Pair Mobility Option. For each PBU message sent to a MAG, a new binding update list entry MUST be created if it has not already been created before, e.g. refresh PBU. The fields in this entry are set as follows: o Mobile Node information fields like MN-Identifier, link-layer identifier, home network prefixes, etc., are copied from the entry that was created during the initial PBU procedure. Wu & Sarikaya Expires August 16, 2010 [Page 13] Internet-Draft PMIPv6 Local Routing Optimization February 2010 o The IPv6 address of the LMA serving the attached mobile node is replaced with the Proxy-CoA of the MAG to which the PBU was sent and Proxy-CoA field in the Correspondent Node part of the MN-CN RO Option is copied to this field. The IP address of the Correspondent Node to which MN is communicating is set to the Home Network Prefix field of the Correspondent Node part of the MN-CNs Pair Mobility Option. If the P bit is set in the MN-CNs Pair Mobility Option, this field is set to the IPv4 HoA field in the Correspondent Node part of MN-CNs Pair Mobility Option. o The initial value of the Binding Lifetime field is set to the Lifetime field in the LROREQ message. o A configuration variable called EnableLMALocalRouting is defined at the MAGs to indicate whether or not the MAG is allowed to enable local routing of the traffic exchanged between a visiting MN that is locally connected to one of the interfaces of the mobile access gateway and a CN that is locally connected to one of the interfaces of another mobile access gateway that is connected to the same LMA. Any LROREQ message received from LMA with lifetime greater than zero enables the local routing at this MAG and the MAG that receives LROREQ first time MUST set EnableLMALocalRouting to 1. When the Intra-MAG LocalRouting flag or Intra-LMA LocalRouting flag are set on the MAGs, one MAG may send a Proxy Binding Update message to another MAG to establish a corresponding binding cache associated with the MN and CN. Upon receiving a Proxy Binding Update message, the MAG checks if the LocalRouting flag is set to value one. If the LocalRouting flag is not set to value one, the MAG MUST reject the request and send a Proxy Binding Acknowledgement message with the status field set to 129 (administratively prohibited). Upon accepting a Proxy Binding Update request, the MAG MUST create a Binding Cache entry. The Source address in the Proxy Binding Update is copied to the Proxy CoA field of the binding cache entry. The Mobile Node data (MN-Identifier, link-layer identifier, link-local address, home network prefixes, etc.) are copied from the corresponding fields of the proxy binding update. Upon accepting a Proxy Binding Update request for the first time from another MAG, the MAG MUST establish a bi-directional tunnel between the two MAGs. The tunnel endpoints are the Proxy-CoA of the receiving Mobile Access Gateway and the Proxy-CoA of the Mobile Access Gateway that sent the PBU, which can be obtained from the source address of the PBU message. This tunnel SHOULD be deleted when there are no Mobile Nodes sharing it or when a Mobile Access Gateway receives a PBU message from another MAG with lifetime set to Wu & Sarikaya Expires August 16, 2010 [Page 14] Internet-Draft PMIPv6 Local Routing Optimization February 2010 zero or when the MAG receives a LROREQ message from the corresponding LMA with the lifetime set to zero. In case of handover or detachment, if the MAG cannot detect the presence of the mobile node on the connected link, the MAG SHOULD terminate the binding of the MN by sending a PBU message to all CN's MAGs that has established bindings. The MAG sends a PBU message to each MAG with lifetime set to zero. Proxy-CoA of the MAG field in each Binding update list entry determines the MAG address. If IPv4 transport is used, IPv4-Proxy-CoA is used. The MAG MUST also remove each Binding Update List entry on all CN's MAGs created for that MN. In order to re-establish the bindings of the MN that is involved in local routing, i.e. with binding update list entries on the new MAG other than the home (local mobility anchor registration), the previous MAG MAY use a context transfer procedure to transfer the local routing state to the new MAG. Each entry in the binding update list for this MN other than the LMA entry can be transferred. After handover is completed, the new MAG MUST send PBU messages to the MAG (Proxy-CoA or IPv4-Proxy-CoA) associated with each Correspondent Node. Another way to re-establish the bindings of the MN is to have the new MAG trigger the LMA to notify all the CN's MAGs to update binding update list on all CN's MAGs created for that MN. For the data traffic between the MN and CN, on receiving a packet from a MN connected to its access link, to a destination (i.e., CN) that is directly connected or not directly connected to the same access link, the MAG will check whether source/destination address pairs in the routing table entry matches the source/destination address in the outgoing data packet and identify the tunnel to the right destination MAG. If the source address and destination address in the packet match one of source/destination address pairs in the routing entry, the packet must be tunneled to the Proxy CoA corresponding to the destination address in the tunnel interface. For the packet from a Mobile Node connected to its access link to a destination that is also directly connected to the same access link, the packet must go directly via the MAG. 5.2. Local Mobility Anchor Considerations In the case of MAG initiating local routing, upon receiving a PBU or routing optimization request message, the LMA will check the LRI field in the Routing Optimization Mobility Option or routing optimization message. If the LRI field is set to value one, the LMA will check whether there exist a binding cache list for the CN and whether the MN's proxy CoA address is same as the CN's proxy CoA address. If LRI field is zero and the Correspondent Node's home network prefix is included, the LMA will check whether there exists a Wu & Sarikaya Expires August 16, 2010 [Page 15] Internet-Draft PMIPv6 Local Routing Optimization February 2010 binding cache list for CN in terms of the correspondent node's home network prefix. If one does, the LMA will fill the MN-CNs Pair Mobility Option with the Proxy CoA and HNP of the CN and respond to the MAG with LRI field set to value two. Otherwise, the LMA will respond to the MAG with the LRI field set to zero to indicate the MAG that local routing optimization is not available. In the case of LMA-initiated local routing, the LMA may be responsible for perceiving intra-LMA routing and correlate MN with CN in the binding update list. Upon perceiving that intra-LMA local routing is allowed between the MN and CN, the LMA fills the MN-CNs Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP, CN Proxy CoA and includes it in the Local Routing Optimization Request message(LROREQ). In the message, the LRI field set to value two. Then the LMA receives routing optimization reply message from the corresponding MAG. The LMA MUST send a LROREQ message to either or both of MAGs where MN and CN are located. If CN (or MN) is not connected to the same LMA, the LROREQ message MUST be sent to only to the MAG that is connected to the LMA. The LROREQ message MUST contain at least one pair of MN- CNs Pair Mobility Options. If the MN is communicating with more than one CN which is regitered with the same LMA, the LMA MUST include more than one CN in the MN-CNs Pair Mobility Option if local routing will be enabled. Before the LROREQ is sent to a MAG, the LMA MUST place the MN address information which is connected to this MAG first in MN-CNs Pair Mobility Option. The LMA MAY set the Lifetime field in the LROREQ message to a non- zero value. Any non-zero lifetime value enables two MAG to start local routing optimization for MN-CN traffic. The lifetime values sent to two MAG MUST be the same. The LMA MAY stop the local routing optimization operation any time it wishes. In that case LMA MUST set the Lifetime field in LROREQ message to zero. After receiving a LRORSP message from the MAG with a matching sequence number field, the LMA-MAG tunnel needs to be re- established separately for each MAG. The LMA sets the sequence number field in LROREQ message to a nonzero integer. This initial sequence number is incremented by one for the next LROREQ message sent. The LMA MUST receive a LRORSP message with the same sequence number as in the corresponding LROREQ message previously sent. This message is acknowledged with a LROREQ message. If no acknowledgement is received, the LMA MUST retransmit the LROREQ message. Wu & Sarikaya Expires August 16, 2010 [Page 16] Internet-Draft PMIPv6 Local Routing Optimization February 2010 6. IPv4 Support IPv4 support is needed in two cases: o The MN is IPv4 enabled and receives an IPv4 home address and o The transport network between the LMA and the MAG is an IPv4 network In both two cases, the encapsulation mode as described in [I-D.ietf-netlmm-pmip6-ipv4-support] is transparent to the MAG concerned before setting up the localized routing path. This may result in data packets being dropped by the egress/ingress tunnel end points, i.e., the MAGs. Therefore local route optimization can be supported only if the encapsulated mode is aware or default configured during setting up the localized routing path. 6.1. IPv4 HoA Support If the MN is IPv4-enabled and receives an IPv4 home address, both the MN and the CN configure global IPv4 home addresses by exchanging PBU/ PBA between the MAG and the LMA as explained in [I-D.ietf-netlmm-pmip6-ipv4-support]. The LMA MUST include the IPv4 IPv4-MN-HoA in local routing optimization messages for both MN and CN. The LMA MAY include the Home Network Prefix in PBA if the MN or CN has been assigned one. Both local routing optimization request and local routing optimization response messages are IPv6 messages and are transported over the LMA-MAG tunnel in the same fashion as the PBU and PBA messages. The PBU and PBA exchanged between the MAGs are IPv6 messages and are transported as unencapsulated IPv6 messages between MAGs. For simplification, we can assume the MAGs in communication are using the default encapsulation mode. Data traffic between the MAGs after local routing is established is transported in the IPv6 inner packet as IPv4 payload. 6.2. IPv4 Transport Support If IPv4 transport is used between the MAG and the LMA, the LROREQ, LRORSP, PBU and PBA messages are transported as IPv6 messages using IPv4 or IPv4-UDP-ESP encapsulation [I-D.ietf-netlmm-pmip6-ipv4-support]. IPv4-UDP and IPv4-UDP-TLV modes are not used because no NAT boxes are supported in this local Wu & Sarikaya Expires August 16, 2010 [Page 17] Internet-Draft PMIPv6 Local Routing Optimization February 2010 routing optimization protocol. IPv4 data packets are transported in an IPv4 packet or encapsulated in IPv4-UDP-ESP encapsulation. 7. Inter-LMA Local Routing Considerations In this section we concentrate on the case where the MN and CN are served by two different LMAs in the same Provider domain, which is not covered by Section 4and Section 5. 7.1. MAG-initiated Inter-LMA Local Routing If the MAG to which the MN and CN are attached is registered to different LMAs, it needs to initiate local routing optimization to the different LMAs respectively. The message exchange for the protocol is shown in Figure 6. LR is triggered at one of the MAGs (e.g., MAG1) when a datagram is received on its upstream interface whose destination address is a CN for which LMA2 has a binding cache entry. MAG1 requests the address of LMA2 from LMA1 by sending a LROREQ message containing the HNP of the CN. LMA1 processes the LROREQ message and looks up the address of LMA2 based on the HNP or HoA of the CN. There is one possible way to achieve this goal: o LMA1 can exchange with a AAA server to retrieve the address of LMA2. LMA1 sends the address of the CN and requests the address of the LMA to which the CN is anchored. The AAA server responds, sending the address of LMA2 to LMA1. See [I-D.wu-dime-pmip6-lr] for further details. Note that LMA2 address discovery is only performed once, i.e., when LMA1 does not know LMA2 address at the first time. If discovery is successful, the address of LMA2 will be correlated with the HNP of the CN in the Mobile Nodes's binding update list for future use. Upon retrieving the address of LMA2, LMA1 then delivers it to MAG1 by means of an LRORSP message. MAG1 then sends LROREQ message containing a MN-CNs Pair Mobility Option (defined in Section 9.4) to LMA2. Note that MN-CNs Pair Mobility Option does not contain the CN Proxy CoA. LMA2 processes the LROREQ message and looks up MAG2 address based on CN HNP or HoA extracted from the message. If the lookup is successful, LMA2 responds to the MAG1 with the address of the MAG to which the CN is attached (i.e., the address of MAG2). MAG1 and MAG2 exchange PBU/PBA messages to establish binding cache list between each other and the direct path between MAG1 and MAG2 will be set up. Wu & Sarikaya Expires August 16, 2010 [Page 18] Internet-Draft PMIPv6 Local Routing Optimization February 2010 +------+ +----------+ +---------+ +------+ | MAG1 | | LMA1(MN) | | LMA2(CN)| | MAG2 | +---+--+ +----+-----+ +----+----+ +---+--+ | |LMA2 Discovery | | | |-----> | | | | | | | LROREQ(CN) | | | |--------------->| | | | | | | | LRORSP(LMA2) | | | |<---------------+ | | | LROREQ(MN,MAG1,CN) | | |------------------------------->| | | LRORSP(CN,MAG2) | | |<-------------------------------| | | | | | |<------------MAGs Exchange PBU/PBA-------------->| | | | | Figure 6: MAG Initiated Inter-LMA Local routing Editor's Note: LMA-initiated Inter-LMA local routing is described in the Appendix for future extension. In LMA-initiated Inter-LMA local routing, the setup of a local routing path depends on LMA-LMA communication. 8. Conceptual Data Structure Extensions 8.1. Binding Update List Extensions Every Mobile Access Gateway maintains a Binding Update List. Each Entry in the Binding Update List represents a mobile node's mobility binding with its Local Mobility Anchor, as described in Section 6.1 of the PMIPv6 specification [RFC5213]. This specification extends the Binding Update List Entry data structure with the following additional fields: Intra-MAG LocalRouting Flag This flag indicates whether media delivery optimization is allowed by locally routing packets within one MAG. The flag is set to the value 1 if local media delivery optimization is allowed and 0 if it is not. Wu & Sarikaya Expires August 16, 2010 [Page 19] Internet-Draft PMIPv6 Local Routing Optimization February 2010 Intra-LMA LocalRouting Flag This flag indicates whether media delivery optimization is allowed by locally routing packets from one MAG to another within one LMA. The flag is set to the value 1 if local media delivery optimization is allowed and 0 if it is not. Inter-LMA LocalRouting Flag This flag indicates whether media delivery optimization is allowed by locally routing packets from a MAG served by one LMA to another MAG served by a different LMA. The flag is set to the value 1 if local media delivery optimization is allowed and 0 if it is not. 8.2. Binding Cache Entry Extensions Every Local Mobility Anchor MUST maintain a Binding Cache Entry for each currently registered mobile node. To support LR, the Binding Cache Entry data structure needs to be extended with the following additional fields: Intra-LMA LocalRouting Flag This flag indicates whether media delivery optimization is allowed by locally routing packets from one MAG to another within one LMA. The flag is set to the value 1 if local media delivery optimization is allowed and 0 if it is not. Inter-LMA LocalRouting Flag This flag indicates whether media delivery optimization is allowed by locally routing packets from a MAG served by one LMA to another MAG served by a different LMA. The flag is set to the value 1 if local media delivery optimization is allowed and 0 if it is not. 8.3. Routing Table Entry Extensions Every mobile access gateway and local mobility anchor MUST maintain a Routing Table entry for each currently registered mobile node: o The Home Address assigned to the Correspondent Node o The Home Address assigned to the Mobile Node o The tunnel interface assigned to the data path between the Mobile Node and the Correspondent Node Wu & Sarikaya Expires August 16, 2010 [Page 20] Internet-Draft PMIPv6 Local Routing Optimization February 2010 9. Local Routing Optimization Message Format 9.1. Local Routing Optimization Mobility Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length | Reserved |LRI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Local Routing Optimization Mobility Option Type: TBD Length: 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to 2. Reserved (R): This 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Local Routing Optimization Indication (LRI): 00: Routing optimization state is unknown or routing optimization is not available. 01: The value of Intra-MAG LocalRouting 10: The value of Intra-LMA LocalRouting 11: The value of Inter-LMA LocalRouting Wu & Sarikaya Expires August 16, 2010 [Page 21] Internet-Draft PMIPv6 Local Routing Optimization February 2010 9.2. The Local Routing Optimization Request (LROREQ) Message The Local Routing Optimization Request message is used by one PMIP6 managed node (LMA or MAG) to negotiate with another PMIP6 managed node (MAG or LMA) whether and what local routing is allowed. 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|LRI|B| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Mobility options ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Local Routing Optimization Request 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, this flag indicates a routing optimization request message. Bulk Localized Routing Flag (B): If the Bulk Localized Routing Flag (B) is set to 1, then the LROREQ message is a message requesting the MAG or LMA to establish local routing optimization paths between the MN and multiple CNs which are communicating with the MN; the MN-CNs Pair Mobility Option will be used to carry one MN and more than one CN. If the bulk localized routing flag is set to 0, then the LROREQ message is a message requesting the MAG or LMA to establish a local routing optimization path between one MN and CN. Local Routing Optimization Indication (LRI): 00: Routing optimization state is unknown or routing optimization is not available Wu & Sarikaya Expires August 16, 2010 [Page 22] Internet-Draft PMIPv6 Local Routing Optimization February 2010 01: The value of Intra-MAG LocalRouting 10: The value of Intra-LMA LocalRouting 11: The value of Inter-LMA LocalRouting Lifetime: The requested period in seconds for which the sender wishes local routing to be active. 9.3. Local Routing Optimization Response Message (LRORSP) The Local Routing Optimization Response message is used to acknowledge the receipt of a Local Routing optimization Request message (described in Section 9.2). 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|LRI|B| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Mobility options ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Local Routing Optimization Response 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 routing optimization request message. Set to 1, indicates it is an routing optimization response message. Wu & Sarikaya Expires August 16, 2010 [Page 23] Internet-Draft PMIPv6 Local Routing Optimization February 2010 Bulk Localized Routing Flag (B): If the Bulk Localized Routing Flag (B) is set to 1, then the LROREQ message is a message requesting the MAG or LMA to establish local routing optimization paths between the MN and multiple CNs which are communicating with the MN; the MN-CNs Pair Mobility Option will be used to carry one MN and more than one CN. If the bulk localized routing flag is set to 0, then the LROREQ message is a message requesting the MAG or LMA to establish a local routing optimization path between one MN and CN. Local Routing Optimization Indication (LRI): 00: Routing optimization state is unknown or routing optimization is not available 01: The value of Intra-MAG LocalRouting 10: The value of Intra-LMA LocalRouting 11: The value of Inter-LMA LocalRouting Lifetime: The requested period in seconds for which the sender wishes local routing to be active. Mobility Options: The Local Routing Optimization Mobility Option described in Section 9.1 and MN-CNs Pair Mobility Option described in Section 9.4 can be included. 9.4. MN-CNs Pair Mobility Option The MN-CNs Pair Mobility Option is defined for use with the Local Route Optimization Request Section 9.2 and Local Route Optimization Response Section 9.3 messages exchanged between the LMA and MAGs. This option is used by the PMIP6 managed node to enable local routing for MN to CNs path from the destination MAG that receives the request Wu & Sarikaya Expires August 16, 2010 [Page 24] Internet-Draft PMIPv6 Local Routing Optimization February 2010 message towards CNs connected a different MAG. The addresses of the target Correspondent Nodes are given in the option. The option MUST be used in pairs including one MN, one or many CNs in communication with MN. The order is important. The LMA places the data for the MN first in the MN-CNs Pair Mobility Option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P| Reserved |Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Proxy CoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 HoA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Proxy CoA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: MN-CNs Pair Mobility Option P Flag: The 'P' flag is set for IPv4 support. When set, the IPv4 HoA and IPv4 Proxy CoA fields MUST be included for the MN or CN. Reserved: This 7-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Prefix Length: 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Wu & Sarikaya Expires August 16, 2010 [Page 25] Internet-Draft PMIPv6 Local Routing Optimization February 2010 Home Network Prefix: A sixteen-byte field containing the mobile or corresponding node's IPv6 Home Network Prefix. Proxy CoA: A sixteen-byte field containing the global address configured on the egress interface of the mobile access gateway to which the mobile or corresponding node is connected. IPv4 HoA: Optional 32-bit field containing the IPv4 home address of the mobile or corresponding node. IPv4 Proxy CoA: Optional 32-bit field containing the IPv4 address that is configured on the egress-interface of the mobile access gateway. 10. Security Considerations The protocol specified in this document can use the security association between the LMA and the MAG to create security associations between MAGs to which MN and CN attach in the intra-LMA local routing scenario. As regarding the intra-MAG local routing scenario, integrity protection can be considered and confidentiality using IPsec is not necessary. In the handover case, the security association between the new MAG and a particular LMA should be pre-established when the MN arrives at the new MAG. A particular LMA can be any LMA serving the MN or CN. MAG initiated inter-LMA local routing may depend on the security association between MN's new MAG and CN's LMA during handover. In order to setup a local routing path, MN's MAG may exchange PBU/PBA with CN's MAG. CN's MAG needs to know that the prefix extracted from the MN-CNs Pair Mobility Option in the PBU is owned by the MN and that the MN's MAG is actually proxying this prefix. Prefix ownership validation may be required during PBU/BPA exchange to ensure that a valid routing state can be created on the CN's MAG. It is the same case when CN's MAG exchanges PBU/PBA with MN's MAG. Wu & Sarikaya Expires August 16, 2010 [Page 26] Internet-Draft PMIPv6 Local Routing Optimization February 2010 11. IANA Considerations TBD. 12. Acknowledgements The authors would like to thank Tom Taylor, Kent Leung, Sri Gundavelli, Jouni Korhonen, Mohana Jeyatharan, for their comments on this draft. Speically thanks to Glen Zorn for providing useful reviews. 13. References 13.1. Normative References [I-D.ietf-mipshop-pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", draft-ietf-mipshop-pfmipv6-12 (work in progress), December 2009. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 (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. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 13.2. Informative 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-02 (work in progress), January 2010. Wu & Sarikaya Expires August 16, 2010 [Page 27] Internet-Draft PMIPv6 Local Routing Optimization February 2010 [I-D.wu-dime-pmip6-lr] Wu, W. and G. Zorn, "AAA Support for PMIP6 mobility entities Locating and Discovery during localized routing", draft-wu-dime-pmip6-lr-01 (work in progress), October 2009. Appendix A. Future Extension A.1. LMA Route Optimization Start Message A.1.1. LMA Route Optimization Start Request Message 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 Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A.1.1. LMA Route Optimization Start Request Message A new MH type should be assigned by IANA. Sequence Number 16-bit unsigned integer. The LMA uses this field to match a returned LMAROStartRsp message. The LMA also uses this field to identify each new pairs of MN-CN to start local routing if the LMA received LMAStartRORsp message. Reserved This field is unused. It SHOULD be initialized to zero by the sender and MUST be ignored by the receiver. Lifetime 16-bit unsigned integer. If non-zero, this fields indicates the initial lifetime of the MN to CN route optimization binding. If there are several MN-CN pairs, the same lifetime applies to each pair. Wu & Sarikaya Expires August 16, 2010 [Page 28] Internet-Draft PMIPv6 Local Routing Optimization February 2010 Mobility Options As defined in section 6.1.7 of RFC 3775 [RFC3775]. This document defines a new mobility option: MN-CN RO option in Section 9.4. The sending LMA sends a pair of MN-RO Options. LMA sets Home Network Prefix value of the first MN-RO Option to HNP for MN and Proxy-CoA value to Proxy-CoA1. The LMA sets Home Network Prefix value of the second MN-RO Option to HNP of CN and Proxy-CoA value to zero. A.1.2. LMA Route Optimization Start Response Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A.1.2. LMA Route Optimization Start Response Message A new MH type should be assigned by IANA. Status An 8-bit unsigned integer indicating the disposition of LMAROStartReq message by the receiving LMA. Values less than 128 indicate that ROStartReq message was accepted by the LMA. Values greater than 128 indicate that LMAROStartReq message was rejected by LMA. Sequence number and Lifetime fields are as defined above for LMAROStartReq message. Mobility Options contain pairs of MN-CN RO Option as defined in Section 9.4. The LMA must copy this field from LMAROStartReq message when status field contains a value indicating success. The LMA MUST search its binding cache for the Home Network Prefix value of CN and find the corresponding MAG address, e.g. Proxy- CoA2. Th LMA MUST replace MAG address field set to zero by the sending LMA with Proxy- CoA2. Wu & Sarikaya Expires August 16, 2010 [Page 29] Internet-Draft PMIPv6 Local Routing Optimization February 2010 A.2. LMA Initiated Inter-LMA Local Routing The message exchange for the protocol is shown in Figure A.2. Inter- LMA Local routing is triggered at one of the LMAs, e.g. LMA1 when a datagram is received on its upstream interface whose destination address is a MN, e.g. MN1 for which LMA1 has a binding cache entry. From the binding cache entry, LMA1 determines the MAG address, e.g. MAG1 (Proxy-CoA1). LMA1 checks the source address to find out if the datagram is coming from a MN located in the same Provider domain and if yes, its MAG address, e.g. MAG2 (Proxy-CoA2). There are several ways for doing this and the exact means is out of scope with the document. Below we will mention two different ways. (a) LMAs in the same Provider domain are configured with a table containing a list of /48, /32, etc. prefixes and the corresponding LMA address for all the LMAs in the domain. LMA1 searches this table doing a longest prefix match based on the prefix part of the source address of MN2 and finds the corresponding LMA2 address. (b) LMA1 can exchange with the AAA server to retrieve LMA2 address. LMA1 sends MN2 address and asks LMA address this MN is attached to. LMA1 receives LMA2 address and MAG address (Proxy-CoA2) from AAA server, e.g.DIAMETER server. LMA1 sends LMAROStartRequest message to LMA2. LMAROStartRequest message contains MN1 and MN2 address and MAG1 address (Proxy-CoA1). MAG2 address is set to zero. LMA2 searches its BCE for MN2 and determines MAG2 address (Proxy-CoA2). LMA2 sends LMAROStartResponse message to LMA1. LMAROStartResponse message contains MN1 and MN2 address and MAG1 address (Proxy-CoA1) and MAG2 address (Proxy-CoA2). LMA1 sends LROREQ message to MAG1 at Proxy-CoA1. LROREQ message contains MN address and Proxy- CoA1 and CN address, e.g. MN2 and Proxy-CoA2. LMA2 sends LROREQ message to MAG2 at Proxy-CoA2. LROREQ message contains CN address, e.g. MN2 and Proxy-CoA2 and MN address, e.g. MN1 and Proxy-CoA1. LROREQ messages enable both MAGs to modify their Binding Update Lists. The two MAGs respond LROREQ with LRORSP messages. The two MAGs, MAG1 and MAG2 exchange PBU/PBAs as described in Section 4. Wu & Sarikaya Expires August 16, 2010 [Page 30] Internet-Draft PMIPv6 Local Routing Optimization February 2010 +------+ +----------+ +---------+ +------+ | MAG1 | | LMA1(MN) | |LMA2(CN) | | MAG2 | +---+--+ +----+-----+ +----+----+ +---+--+ | | | | | | LMAROStartReq | | | |-------------->| | | | | | | | LMARoStartRsp | | | |<------------- | | | LROREQ | | LROREQ | |<---------------| |--------------->| | | | | | LRORSP | | LRORSP | |--------------->| |<-------------- | | | | | |<--------------MAGs exchange PBU/PBA------------>| | | | | | | | | Figure A.2. LMA Initiated Inter-LMA Local routing A.2.1. IPv4 Support Consideration IPv4 support presented in Section 6 also applies here. In addition, we discuss IPv4 support issues related to LMAROStartRequest and LMAStartResponse messages. LMAROStartRequest and LMAStartResponse messages are IPv6 messages. These messages are transported in IPv6 because LMAs support IPv6 and there is IPv6 transport established among LMAs in the same Provider domain. A.3. LMA Initiated operation for Inter-LMA Local Routing Local mobility anchor MUST send LMAROStartReq message to another local mobility anchor in the same Provider domain. LMAROStartReq message MUST contain at least one pair of MN-CN RO Option. Local mobility anchor MUST place the mobile node address information which is connected to this local mobility anchor first in MN-CN RO Option. Local mobility anchor MAY set lifetime field in LMAROStartReq message to a non zero value. Any nonzero lifetime value enables the receiving local mobility anchor to start local routing optimization for MN-CN traffic by sending LROReq message to the mobility access gateway to which CN is connected as the local mobility anchor determines by searching its binding cache. After receiving LRORes from the mobile access gateway, the local mobility anchor MUST send LMAROStartRes to the originating local mobility anchor. LMAROStartRes MUST contain MN-CN Option RO pair in Wu & Sarikaya Expires August 16, 2010 [Page 31] Internet-Draft PMIPv6 Local Routing Optimization February 2010 which the first contains MN and its mobility access gateway address info which is copied from LMAROStartReq message and the second contains CN address which is copies from LMAROStartReq and its mobility access gateway address which this local mobility gateway provides. Local mobility anchor MAY set lifetime field in LMAROStartRes to the same value as LMAROStartReq lifetime field value. Local mobility anchor MAY set lifetime field in LMAROStartRes to a different value. The lifetime field in LMAROStartRes becomes the final value and local mobility anchor MUST set lifetime value in LROReq message that it sends to MN's mobility access gateway. In case the simplified route optimization involves two local mobility gateways, the initiating local mobility anchor MAY stop the route optimization any time it wishes. The initiating local mobility anchor MUST send LMAROStartReq message to the destination local mobility anchor with lifetime field set to zero. The destination local mobility anchor sends LMAROStartRes with lifetime set to zero. Both local mobility anchors send LROReq messages to the corresponding mobility access gateways with lifetime set to zero. Both local mobility anchors reestablish the tunnel with mobility access gateways for MN and CN, respectively. Local mobility anchor sets the sequence number field in LMAROStartReq message to a nonzero integer. This initial sequence number is incremented by one for the next LMAROStartReq message sent. Local mobility anchor MUST receive LMAROStartRes message with the same sequence number as in LMAROStartReq message previously sent. This message acknowledges LMAROStartReq message. If no ack is received local mobility anchor MUST retransmit LMAROStartReq message. In a normal mode of operation local mobility anchor has one outstanding LMAROStartReq messages because they are sent to the other local mobility anchor in the same Provider domain. Appendix B. Change Notes Changes in version 04. o Move LMA Initiated inter-LMA local routing to appendix A o Some Editorial Revision. o Additional text about MAG operation and LMA operation in section 5 and appendix A.3. Wu & Sarikaya Expires August 16, 2010 [Page 32] Internet-Draft PMIPv6 Local Routing Optimization February 2010 o Remove NAT Aspect and private IPv4 aspect in this document. o Additional text about Routing Table extension and Bulk localized routing Flag. Changes in version 05. o Some Editorial changes. o Consistent with I-D.ietf-netext-pmip6-lr-ps on terminology using o Incorporate prefix ownsership validation into the section of "security consideration". Authors' Addresses Qin Wu Huawei Technologies Co.,Ltd Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. Nanjing, Jiangsu 21001 China Phone: +86-25-84565892 Email: Sunseawq@huawei.com Behcet Sarikaya Huawei Technologies Co.,Ltd 1700 Alma Drive, Suite 500 Plano, TX 75075 USA Email: sarikaya@ieee.org Wu & Sarikaya Expires August 16, 2010 [Page 33]