Network Working Group Q.Wu B.Sarikaya Internet Draft Huawei Intended status: Standard Track July 8, 2009 Expires: January 2010 Proxy MIP extension for local routing optimization draft-wu-netext-local-ro-02.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 January 8, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents 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. Wu,et al. Expires January 8, 2010 [Page 1] Internet-Draft Proxy MIP Extension for local routing July 2009 Abstract This document extends local routing in proxy Mobile IPv6 and defines a simplified localized routing optimization protocol within one PMIPv6 domain. The protocol supports IPv4 transport network operation, IPv4 home address mobility and handover. The Local mobility anchor/mobile access gateway initiates local routing for the mobile and correspondent node by sending messages to each mobile access gateway/local mobility anchor. In case the correspondent node is connected to another local mobility anchor, the local mobility anchors connected by the correspondent node needs to be discovered firstly so that it can notify its mobile access gateways to the mobile access gateway attached by the mobile node afterwards. Mobile access gateways create and refresh bindings using proxy binding update and acknowledgement messages. Table of Contents 1. Introduction.................................................3 2. Conventions used in this document............................3 3. Scenarios analysis for PMIP6 local routing...................5 4. Local routing optimization protocol overview.................6 4.1. MAG initiated local routing optimization................6 4.1.1. Handover Consideration.............................8 4.2. LMA initiated local routing optimization................9 4.2.1. Handover Consideration............................10 5. Process consideration.......................................11 5.1. Mobile Access Gateway Consideration....................11 5.2. Local Mobility Anchor Consideration....................13 6. IPv4 support................................................13 7. MAG Initiated Inter-LMA Local routing Consideration.........14 8. Conceptual Data Structure Extension.........................16 8.1. Binding Update List Extension..........................16 8.2. Binding Cache Entry Extension..........................17 9. Local routing optimization message format...................17 9.1. Local Routing optimization mobility option.............17 9.2. Local Routing optimization Request message(LROREQ).....18 9.3. Local Routing optimization Response Message(LRORSP)....19 9.4. Context Request Option.................................20 9.5. MN and CN pair mobility option.........................20 10. Security Considerations....................................21 11. IANA Considerations........................................22 12. Acknowledgement............................................22 Wu,et al. Expires January 8, 2010 [Page 2] Internet-Draft Proxy MIP Extension for local routing July 2009 13. References................................................22 13.1. Normative References.................................22 13.2. Informative References...............................22 Appendix A Future Extension..................................23 A.1. LMA Route Optimization Start Message..................23 A.1.1. LMA Route Optimization Start Request Message.....23 A.1.2. LMA Route Optimization Start Response Message....24 A.2. LMA Initiated Inter-LMA Local Routing.................25 A.2.1. IPv4 support Consideration.......................26 1. Introduction Proxy Mobile IPv6 [RFC5213] can allow the Mobility Access Gateway (MAG) to optimize the media delivery by locally routing the packets within one MAG and by not reverse tunneling them to the mobile node's local mobility anchor (LMA). However it does not address the case of routing optimization between two MAGs sharing the same LMA or registering to the different LMA. The capability for local routing optimization provided in [RFC5213] requires the MAG to support the EnableMAGLocalRouting flag and allow the MAG to control local routing optimization behavior. However, [RFC5213] does not define how local routing optimization capability is detected, who initiates local routing optimization and how to negotiate between the MAG and the LMA to determine whether the local routing optimization is allowed. This document defines a local routing optimization mobility messages or options for proxy mobile ipv6 that is intended to assist the MAGs to negotiate and setup local routing path between each other. The new local routing optimization mobility options included in each binding update or local routing optimization messages exchange is used to negotiate between the LMA and the MAG whether and what local routing is allowed. Different from the local forwarding control message described in the [I-D.LocalFwd], the local routing optimization messages can be initiated by either of pmip6 managed node and provide flexible negotiation mechanism for local routing. As [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 mobility services and mobility service provisioning from the point of view of both operators and service providers within one PMIPv6 domain. 2. 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 RFC-2119 Wu,et al. Expires January 8, 2010 [Page 3] Internet-Draft Proxy MIP Extension for local routing July 2009 The document uses the terminology specified in [RFC5213] and in [RFC3775]. In addition, this document defines the following: Local routing: Traffic between MN and CN does not pass through LMA and is locally routed in the same PMIPv6 domain. Local Routing Optimization Request (LROREQ): A message initiated by the MAG or LMA requesting the MAG to establish local routing optimization for a pair of MNs who communicate with each other. Local Routing Optimization Response (LRORSP): A reply message from the MAG or LMA to confirm local routing optimization results. Wu,et al. Expires January 8, 2010 [Page 4] Internet-Draft Proxy MIP Extension for local routing July 2009 3. Scenarios analysis for PMIP6 local routing Figure.1 shows the reference architecture for PMIP6 local routing. In this architecture, the local communication between PMIPv6 managed nodes is constrained within a single PMIPv6 domain. LMA1 and LMA2 which MN and CN are respectively anchored to may be the same LMA or different LMAs in the same PMIPv6 domain. With IPv4 transport support, +---------+ ============|LMA1/LMA2|============ // +---------+ \\ || || +-----+ || | NAT | +-----------+ +--+-----+--+ | IPv4/IPv6 | | IPv4 | | Network | | Network | +-----------+ +-----------+ || || || || +-----------+ || +------+ |IPv4/IPv6 +---+ +------+ | MAG1 |===================|NAT|=====| 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 the NAT may exist between MAG1 and MAG2 or between the LMA1 and LMA2. Depending on how MN and CN are distributed into one PMIP6 domain, three typical scenarios need to be considered as follows: Scenario 1: Intra-MAG local routing In this scenario, MN and CN attach to the same MAG and are anchored with the same LMA or different LMAs. Scenario 2: Intra-LMA local routing In this scenario, MN and CN attach to the different MAGs and are anchored with the same LMA. Wu,et al. Expires January 8, 2010 [Page 5] Internet-Draft Proxy MIP Extension for local routing July 2009 Scenario 3: Inter-LMA local routing In this scenario, MN and CN attach to the different MAGs and are anchored with the different LMAs. In all the above scenarios, although all the PMIP6 managed node are constrained in the same PMIP6 domain, however MN and CN may be roaming user and their subscription may belong to the different operators described in [I-D.wu-netext-pmipv6-ipv4-ro-ps], e.g., roaming user MN moves to the visited network owned by the operator using IPv4 transport where no-roaming CN is located. Another example is roaming user MN and CN move to the same visited network and use the different LMAs within the same PMIP6 domain. 4. Local routing optimization protocol overview The protocol specified here assumes that the MAG and the LMA are situated in one PMIP domain and MN and CN attach to the same MAG or MN and CN are anchored with the same LMA.(i.e., intra-MAG local routing or intra-LMA local routing occurs). The MAG has the capability to perceive intra-MAG local routing (i.e., in the intra- MAG local routing scenario, the MAG can detect whether the mobile node and correspondent node attach to the same MAG by checking binding update list). The LMA has the capability to perceive intra- LMA local routing (i.e., in the intra-LMA local routing scenario, the LMA can detect whether the MAGs to which MN and CN are attach belong to the same or different LMAs by checking its binding cache list). The flag EnableDetectLocalRouting on the MAG and LMA may be used to control this behavior. The decision to enable/disable detection of local routing should be based on the policy configured on the MAG or LMA. The specific details on how this is achieved are beyond of the scope of this document. Subsequently there are two modes in which the local routing optimization protocol operates. 4.1. MAG initiated local routing optimization When the EnableDetectLocalRouting is enabled in the MAG, the MAG can start to detect whether the MN and CN attach to the same MAG by checking binding List of MN and CN. Upon the MAG intercept the packet from the MN and perceives MN and CN attach to the same MAG, it can initiate local routing optimization to determine the value of the intra-MAG localrouting flag (defined in Wu,et al. Expires January 8, 2010 [Page 6] Internet-Draft Proxy MIP Extension for local routing July 2009 section 5) by message exchange between the MAG and LMA (If the MAG attached by the MN and CN register to the different LMAs, it need to initiate local routing optimization to the different LMAs respectively). When the MAG perceives intra-MAG local routing is not possible but want to check whether intra-LMA routing is allowed, it also can initiate the local routing optimization by message exchange between the MAG and LMA. The message may be an binding update message which contains the local routing optimization mobility option and home network prefix option for the correspondent node or a newly defined local routing optimization message. It will be used to negotiate with LMA to determine whether or not the local routing optimization between the mobile node and correspondent node is supported. If the LMA does not allow the MAG bypass traffic from itself, it will respond to the MAG that the local routing optimization is not available. Otherwise it will set the intra-MAG locarouting or intra-LMA localrouting flag on the MAG into value one by sending successful response message. After successful local routing optimization process, if MN and CN attach to the different MAGs, i.e., MAG1, MAG2, the MAG1 to which the MN attaches may send PBU message to the MAG2 which the CN attaches to. The PBU/PBA signaling is protected using IPsec Encapsulation security payload [RFC4303]in transport mode with mandatory integrity protection. This PBU message sets the lifetime of the binding of MN at MAG2. Similarly the MAG2 sends PBU message to the MAG1. This PBU message sets the lifetime of the binding of CN at MAG1. Each PBU MUST be acknowledged with PBAs. With PBU/PBA exchange, the local data path between MAGs is established. Also PBU-PBA exchange is repeated to extend the lifetime of the binding. For the data traffic, either of the MAGs can lookup local routing flag and process traffic in terms of the value of Localrouting flag. If the Intra-MAG Localrouting flag is set to value one, the traffic from MN will go directly to CN via MAG. If the Intra-LMA localrouting flag is set to value one, the traffic from MN will be forwarded directly to the MAG associated with the CN. Wu,et al. Expires January 8, 2010 [Page 7] Internet-Draft Proxy MIP Extension for local routing July 2009 +--+ +------+ +-----+ +------+ +--+ |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| | | | | +-------+---------+ | | | | | 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 Consideration In case of handover when the MN moves from the old MAG (e.g., pMAG1) in the previous access network to the new MAG(e.g., nMAG1) in the new access network, registration entry for MN in pMAG1's Binding update list should be transferred to the nMAG1. The context request option defined in the [I-D.ietf-mipshop-pfmipv6] can be reused here to carry the context information on MAG1. And the new MAG(i.e., nMAG1) sends PBUs to each MAG with which MN was in communication via local route optimization path established. This PBU/PBA exchange updates the binding in each MAG with which MN was in communication and re- establishes optimal local route path between MN and its CNs. Wu,et al. Expires January 8, 2010 [Page 8] Internet-Draft Proxy MIP Extension for local routing July 2009 +-----+ +---------+ +---------+ |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 EnableDetectLocalRouting is enabled in the LMA, the LMA can start to detect whether the MN and CN register to the same LMA by checking binding List of MN and CN. Upon receiving the packet from the CN and perceiving MN and CN register to the same LMA, it can initiate local routing optimization to determine the value of Intra- LMA localrouting flag (defined in section 5) and notify it to the MAG by message exchange between the MAG and LMA. The message could be proxy binding update message which contain local routing optimization Wu,et al. Expires January 8, 2010 [Page 9] Internet-Draft Proxy MIP Extension for local routing July 2009 mobility option or a newly defined routing optimization message. It will be used to help MAG to determine whether or not the local routing optimization is allowed. If the LMA verifies there exists binding cache list of correspondent node and mobile node and allow the MAG bypass traffic between mobile node and correspondent node from itself, it will notify the MAG to set the intra-LMA Localrouting flag into value one, otherwise, it will respond to MAG with failure information which indicate the intra-LMA routing optimization is not supported. The other procedures are same as that of section 4.1. +--+ +------+ +-----+ +------+ +--+ |MN| | MAG1 | | LMA | | MAG2 | |CN| ++-+ +--+---+ +--+--+ +--+---+ +-++ Attach to MAG1 | |Attach to MAG2 |---------->| +-------+----------+ <------------+ | | | BCE Check | | | | | |Perceive MAG1 and | | | | | |MAG2 register to | | | | | |the same LMA | | | | | +-------+----------+ | | | | LROREQ | LROREQ | | | | (MAG2) | (MAG1) | | | |<------------ |------------->| | | +-------+---------+ | +-------+---------+ | | |Enable Intra-LMA/| | |Enable Intra-LMA/| | | | Routing | | | Routing | | | +-------+---------+ | +-------+---------+ | | LRORSP | LRORSP | | | |------------->|<-------------| | | | 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 Consideration In case of handover when the MN moves from the old MAG (e.g., MAG1) in the previous access network to the new MAG(e.g., MAG3) in the new access network, MAG1 may request LMA by sending PBU or LROREQ to Wu,et al. Expires January 8, 2010 [Page 10] Internet-Draft Proxy MIP Extension for local routing July 2009 update binding of each MAG with which MN was in communication via local route optimization path established. Also MAG1 can use the similar procedure described in the section 4.1.1 to transfer MN's registration entry on MAG1 to the new MAG(i.e., MAG3). +-----+ +---------+ +----------+ +---------+ |pMAG1| |nMAG1(MN)| |LMA(MN,CN)| | MAG2(CN)| +--+--+ +---+-----+ +----+-----+ +---+-----+ | | Normal PBU | | | |-------------->| | | | | | | | Normal PBA | | | |<------------- | LRQREQ | | | |-------------->| | | | | | | | LRORSP | | | |<------------- | | | PBU/PBA between MAGs | | |<----------------------------->| | +------+------+ | +-----+-------+ | |UpdateBinding| | |UpdateBinding| | | and Tunnel | | | and Tunnel | | +------+------+ Datagram +-----+-------+ | |<=============================>| | | | | Figure 5. LMA initiated Local routing optimization during handover 5. Process consideration 5.1. Mobile Access Gateway Consideration The MAG may include the routing optimization mobility option and the correspondent node's home network prefix option into binding update message or create a new routing optimization request message in which the above two options are contained. The routing optimization mobility option is used to negotiate which kind of local routing optimization is available. The correspondent node's home network prefix option is used for the LMA to verify the validity of local routing optimization path end points (in the intra-MAG local routing scenario) or to request the LMA to determine proxy CoA-Address of correspondent node for local routing optimization (in the intra-LMA local routing scenario). In the intra-MAG local routing case, LRI field in routing optimization mobility option is set into value 1 while in the intra-LMA local routing case, LRI field in routing optimization mobility option is set into value 0 for mobile node's MAG does not know whether traffic between MN and CN can be locally routed within one LMA. Wu,et al. Expires January 8, 2010 [Page 11] Internet-Draft Proxy MIP Extension for local routing July 2009 If the MAG receives binding acknowledge message with routing optimization mobility option or routing optimization response message, it will extract the LRI field from the routing optimization mobility option or routing optimization response message and check the value of it. If LRI field is 0, it indicates the LMA does not support this local routing optimization and the MAG should set intra-MAG LocalRouting flag to value 0 in the binding update list extension; if LRI field is 1, it indicates the LMA allow local routing in one MAG and bypass the LMA and MAG should set intra-MAG LocalRouting flag to value 1 in the binding update list extension, if LRI field is 2, it indicates LMA has find correspondent node's MAG address in terms of home network prefix of CN and MAG should extract correspondent node's MAG address from initial binding acknowledge message or routing optimization response message and store it in binding update list extension with correspondent node's home network prefix. Upon the intra-MAG Localrouting flag or intra-LMA Localrouting flag setup at the MAGs, one MAG may send the proxy binding update message to another MAG to establish corresponding binding cache associated with the MN and CN. Upon receiving Proxy Binding Update message, the MAG checks if the LocalRouting flag is set to one. If the LocalRouting flag is not set to 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 Proxy Binding Update request, the MAG MUST create a Binding Cache entry. The Source address of Proxy Binding Update is copied to 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 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 this mobile access gateway and the Proxy-CoA of the mobile access gateway that sent Proxy Binding Update as can be obtained from the source address of Proxy Binding Update. This tunnel should be deleted when there are no mobile nodes sharing it or when mobile access gateway receives RORQ message from local mobility anchor with lifetime set to zero. When using IPv4 transport, the endpoints of the bi-directional tunnel are IPv4-Proxy-CoA of the mobile access gateway that sent Proxy Binding Update as can be obtained from the source address of Proxy Binding Update and IPv4-Proxy-CoA of this mobile access gateway with the encapsulation mode as specified in [I-D.ietf-netlmm-pmip6-ipv4- support]. Wu,et al. Expires January 8, 2010 [Page 12] Internet-Draft Proxy MIP Extension for local routing July 2009 For the data traffic between the MN and CN, on receiving a packet from a mobile node connected to its access link, to a destination that is directly connected or not directly connected, the MAG will lookup local routing flag and process traffic in terms of intra-MAG Localrouting flag or intra-LMA Localrouting flag. If the Intra-LMA LocalRouting flag is set to one and the destination address matches one of the home network prefixes in the binding cache, the packet must be forwarded to the Proxy CoA field in the binding cache entry as a tunneled packet. 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, if the intra-MAG Localrouting flag is set to one, the packet must go directly via the MAG. 5.2. Local Mobility Anchor Consideration For the case where the MAG initiates local routing, upon receiving binding update message or routing optimization request message, the LMA will check LRI field in the routing optimization mobility option or routing optimization message. If LRI field is 1, the LMA will check whether there exists binding cache list for CN and whether MN's proxy CoA address is same as CN's proxy CoA address. If LRI field is 0 and correspondent node's home network prefix included, the LMA will check whether there exists binding cache list for CN in terms of the correspondent node's home network prefix. If does, the LMA will respond to the MAG with LRI field set to value 2. Otherwise, the LMA will respond to the MAG with LRI field set to 0 in the routing optimization mobility option to indicate the MAG that the local routing optimization is not available. For the case where the LMA initiates local routing, upon perceiving intra-LMA routing, the LMA sends routing optimization request message with the LRI field set to value 2. And then the LMA receives routing optimization reply message from the corresponding MAG. 6. IPv4 support IPv4 support is needed in two cases: MN is IPv4 enabled and receives IPv4 home address and 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.draft-netlmm-pmip6-ipv4-support] and NAT existing between the MAGs attached by the MN and CN respectively are transparent to the MAG concerned before setting up the localized routing path. This may Wu,et al. Expires January 8, 2010 [Page 13] Internet-Draft Proxy MIP Extension for local routing July 2009 result in data packets are dropped by the NAT between the concerned MAGs or the egress tunnel end point, i.e., the MAG. So local route optimization can be supported only if the encapsulated mode is aware and NAT Box is detected during setting up the localized routing path. In case MN is IPv4 enabled and receives IPv4 home address, both the MN and the CN configure global IPv4 home addresses by exchanging PBU/PBA as explained in [I-D.ietf-netlmm-pmip6-ipv4-support] with the LMA. The LMA MUST include IPv4 IPv4-MN-HoA in local routing optimization messages for both MN and CN. The LMA MAY include Home Network Prefix in PBA if the MN or CN is assigned Home Network Prefix. Both local routing optimization request and local routing optimization response messages are IPv6 messages and are transported over LMA-MAG tunnel as PBU and PBA are transported. The PBU and PBA exchanged between the MAGs are IPv6 messages and are transported as unencapsulated IPv6 messages between MAGs. Various encapsulation modes described in the [I-D.ietf-netlmm-pmip6-ipv4- support] can be used in PBU and PBA and encapsulation mode negotiation between the MAGs is required If the MAGs in communication support different encapsulation mode. 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 are transported in IPv6 inner packet as IPv4 payload. In case IPv4 transport is used between the MAG and the LMA, LROREQ, LRORSP, PBU and PBA messages are transported as IPv6 messages using IPv4 or IPv4-UDP or IPv4-UDP-TLV encapsulation [I-D.ietf-netlmm- pmip6-ipv4-support]. IPv4 data packets are transported in an IPv4 packet or encapsulated in IPv4-UDP/IPv4-UDP-TLV encapsulation. The NAT Detection option defined in [I-D.ietf-mext-nemo-v4traversal] can be used in the PBU and PBA between the MAGs to detect the on-path NAT device. 7. MAG Initiated Inter-LMA Local routing Consideration In this section we concentrate on the local routing case where MN and CN are served by two different LMAs, in the same PMIPv6 domain which is not covered by the section 4 i.e.,Inter-LMA local routing. Wu,et al. Expires January 8, 2010 [Page 14] Internet-Draft Proxy MIP Extension for local routing July 2009 The message exchange for the protocol is shown in Figure 6. Local routing case 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 request LMA2 address from LMA1 by sending LROREQ message contain CN HNP or HoA to LMA1. LMA1 processes LROREQ message and lookup LMA2 address based on CN HNP or HoA. There are two possible ways to achieve this goal. a. LMAs in the same PMIPv6 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 to do a longest prefix match based on the prefix part of the source address of CN and finds the corresponding LMA2 address. b. MAG1 can consult AAA server to retrieve LMA2 address. MAG1 sends CN address and asks the address of LMA2 which CN is anchored to. The AAA server responds LMA2 address to MAG1. Upon retrieving LMA2 address, MAG1 then sends LROREQ message containing MN-CN pairs defined in the section 9.5 to LMA2. LMA2 process LROREQ message and looks up MAG2 address based on CN HNP or HoA extracted from the corresponding message. In successful case, LMA2 responds to the MAG1 with MAG2 address corresponding to CN. MAG1 and MAG2 exchange PBU/PBA to establish binding cache list between each other and direct path between MAG1 and MAG2 is setup. Wu,et al. Expires January 8, 2010 [Page 15] Internet-Draft Proxy MIP Extension for local routing July 2009 +------+ +----------+ +---------+ +------+ | MAG1 | | LMA1(MN) | | LMA2(CN)| | MAG2 | +---+--+ +----+-----+ +----+----+ +---+--+ | | | | | LROREQ(CN) | | | |--------------->| | | | +------+-------+ | | | |LMA2 Discovery| | | | +------+-------+ | | | LRORSP(LMA2) | | | |<---------------| | | | LROREQ(MN,MAG1,CN) | | |------------------------------->| | | LRORSP(CN,MAG2) | | |<-------------------------------| | | | | | |<------------MAGs Exchange PBU/PBA-------------->| | | | | Figure 6. MAG Initiated Inter-LMA Local routing 8. Conceptual Data Structure Extension 8.1. Binding Update List Extension 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 indicating whether the media delivery optimization is allowed by locally routing the packets within one MAG. The flag is set to value 1 for local media delivery optimization is allowed and vice versa. Intra-LMA LocalRouting Flag indicating whether the media delivery optimization is allowed by locally routing the packets from one MAG to another within one LMA. The flag is set to value 1 for local media delivery optimization is allowed and vice versa. Inter-LMA LocalRouting Flag indicating whether the media delivery optimization is allowed by locally routing the packets from one MAG served by one LMA to another MAG served by the different LMA. The flag is set to value 1 for local media delivery optimization is allowed and vice versa. Wu,et al. Expires January 8, 2010 [Page 16] Internet-Draft Proxy MIP Extension for local routing July 2009 Home network prefix assigned to Correspondent Node Proxy Care-of Address assigned to Correspondent Node 8.2. Binding Cache Entry Extension Every local mobility anchor MUST maintain a Binding Cache entry for each currently registered mobile node. For supporting this specification, the Binding Cache Entry data structure needs to be extended with the following additional field: Inra-LMA LocalRouting Flag indicating whether the media delivery optimization is allowed by locally routing the packets from one MAG to another within one LMA. The flag is set to value 1 for local media delivery optimization is allowed and vice versa. Inter-LMA LocalRouting Flag indicating whether the media delivery optimization is allowed by locally routing the packets from one MAG served by one LMA to another MAG served by the different LMA. The flag is set to value 1 for local media delivery optimization is allowed and vice versa. 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) Wu,et al. Expires January 8, 2010 [Page 17] Internet-Draft Proxy MIP Extension for local routing July 2009 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 9.2. Local Routing optimization Request message(LROREQ) The Local Routing optimization Request message is used by one PMIP6 managed node (e.g., LMA or MAG) to negotiate with another PMIP6 managed node(e.g., 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| 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, indicates it is an routing optimization request message. 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 local routing Wu,et al. Expires January 8, 2010 [Page 18] Internet-Draft Proxy MIP Extension for local routing July 2009 Lifetime: The requested time in seconds for which the sender wishes to have local routing. 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| 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. 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 time in seconds for which the sender wishes to have local routing. Wu,et al. Expires January 8, 2010 [Page 19] Internet-Draft Proxy MIP Extension for local routing July 2009 Mobility options: local Routing optimization mobility option described in section 9.1 and MN-CN pair mobility option described in section 9.4 can be included. 9.4. Context Request Option The details is defined in the section 6.2.1 of [I-D.ietf-mipshop- pfmipv6]. 9.5. MN and CN pair mobility option A new option, MN-CN pair mobility option is defined for use with the local Route Optimization Request and local Response messages exchanged between LMA and MAGs. This option is used by the PMIP6 managed node to enable local routing for MN to CN path from the destination MAG that receives the request message towards CN connected a different MAG whose address is given in option. The option MUST be used in pairs, one for MN and one for CN. The order is important. The LMA places the data for MN to which the destination MAG is connected first. 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-CN pair mobility option P Flag Wu,et al. Expires January 8, 2010 [Page 20] Internet-Draft Proxy MIP Extension for local routing July 2009 P flag is set for IPv4 support. When set IPv4 HoA and IPv4 Proxy CoA fields must be included for 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. 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 IPv4 home address of the mobile or corresponding node. IPv4 Proxy CoA Optional 32-bit field containing 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 association between MAGs to which MN and CN attach in the intra-LMA local routing scenario. As regarding intra-MAG local routing scenario, integrity protection can be considered and confidentiality using IPsec is not necessary. Wu,et al. Expires January 8, 2010 [Page 21] Internet-Draft Proxy MIP Extension for local routing July 2009 11. IANA Considerations This document has no actions for IANA. 12. Acknowledgement The authors would like to thank Tom Taylor, Kent Leung, Sri Gundavelli, Jouni Korhonen for their review and comments of this draft and all colleagues who have supported the advancement of this draft effort. 13. References 13.1. Normative References [RFC3775] Johnson, D. and al. et, "Mobility Support in IPv6", RFC3775, June 2004 [RFC5213] Gundavelli, S. and al. et, "Proxy Mobile IPv6", RFC5213, May 2008. [RFC4303] Kent,S.,"IP Encapsulation Security Payload(ESP)",RFC4303, December 2005. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 (work in progress), January 2009. [I-D.ietf-mipshop-pfmipv6] Yokota,H.,Chowdhury,K.,Koodli,R.,Patil,B.,Xia,F.,"Fast handover for Proxy Mobile IPv6",draft-ietf-mipshop-pfmipv6- 05(work in progress),June,2009 13.2. Informative References [I-D.LocalFwd] Koodli,R., Chowdhury,K. "Local Forwarding in Proxy Mobile IPv6", draft-koodli-netlmm-local-forwarding-00, July 2008 [I-D.liebsch-netext-pmip6-ro-ps] Liebsch, M., "PMIPv6 Localized Routing Problem Statement", draft-liebsch-netext-pmip6-ro-ps-00 (work in Wu,et al. Expires January 8, 2010 [Page 22] Internet-Draft Proxy MIP Extension for local routing July 2009 progress),February 2009. [I-D.wu-netext-pmipv6-ipv4-ro-ps] Wu,Q., Korhonen, J.," Problem Statement of IPv4 Support for PMIPv6 Localized Routing", draft-wu-netext-pmipv6-ipv4-ro- ps-01 (work in progress),June 2009. Appendix A Future Extension A.1. LMA Route Optimization Start Message A.1.1. LMA Route Optimization Start Request Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 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 initial lifetime of MN to CN route optimization binding. If there are several MN-CN pairs, the same lifetime applies to each pair. Mobility Options Wu,et al. Expires January 8, 2010 [Page 23] Internet-Draft Proxy MIP Extension for local routing July 2009 As defined in section 6.1.7 in [RFC3775]. This document defines a new mobility option: MN-CN RO option in Section 6.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 6.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,et al. Expires January 8, 2010 [Page 24] Internet-Draft Proxy MIP Extension for local routing July 2009 A.2. LMA Initiated Inter-LMA Local Routing In this section we focus on the local routing case where MN and CN are served by two different LMAs and LMA1 and LMA2 in the same PMIPv6 domain which is not covered by the section 4. This case is referred to as A22 in [I-D.liebsch-netext-pmip6-ro-ps]. The message exchange for the protocol is shown in Figure 10. Local routing for A22 case 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 PMIPv6 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. LMAs in the same PMIPv6 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. LMA1 can consult 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. Wu,et al. Expires January 8, 2010 [Page 25] Internet-Draft Proxy MIP Extension for local routing July 2009 The two MAGs, MAG1 and MAG2 exchange PBU/PBAs as described in Section 4. +------+ +----------+ +---------+ +------+ | MAG1 | |LMA1(MN1) | |LMA2(MN2)| | MAG2 | +---+--+ +----+-----+ +----+----+ +---+--+ | | | | | | LMAROStartReq | | | |-------------->| | | | | | | | LMARoStartRsp | | | |<------------- | | | LROREQ | | LROREQ | |<---------------| |--------------->| | | | | | LRORSP | | LRORSP | |--------------->| |<-------------- | | | | | |<--------------MAGs exchange PBU/PBA------------>| | | | | | | | | Figure A.2. Local routing with Two LMAs involvement A.2.1. IPv4 support Consideration IPv4 support presented in Section 8 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 PMIPv6 domain. Wu,et al. Expires January 8, 2010 [Page 26] Internet-Draft Proxy MIP Extension for local routing July 2009 Authors' Addresses Qin Wu Huawei Technologies Co.,Ltd Site B,Floor 12F,Huihong Mansion,No.91,Baixia Rd. Nanjing 210001 China Email: Sunseawq@huawei.com Behcet Sarikaya Huawei Technologies Co.,Ltd 1700 Alma Dr.Suite 500 Plano, TX 75075 USA Email: sarikaya@ieee.org Wu,et al. Expires January 8, 2010 [Page 27]