NETLMM Working Group A. Muhanna Internet-Draft Nortel Intended status: Standards Track S. Krishnan Expires: August 28, 2008 Ericsson K. Leung Cisco B. Patil Nokia Siemens Networks February 25, 2008 Proxy MIPv6 Support of Transient Registration draft-muhanna-netlmm-pmipv6-support-transient-coa-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract In order for the local mobility anchor to receive and forward uplink traffic for a mobile node, Proxy Mobile IPv6 base protocol mandates the LMA to have an active BCE with a registered proxy CoA that is the Muhanna, et al. Expires August 28, 2008 [Page 1] Internet-Draft PMIPv6 Support Transient Registration February 2008 other end of the tunnel between the LMA and MAG. In some systems and during active inter-MAG handoff with traffic that is sensitive to delay and packet loss, the LMA is required to forward uplink traffic for the mobile node from the target MAG without completely switching the tunnel from the source MAG. This document specifies a mechanism which allows the target MAG to perform transient registration for a new proxy CoA and the LMA to create a transient BCE for the same mobile node for a specified period of time while maintaining the original mobile node's BCE which reference the old pCoA at the source MAG. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. PMIPv6 Transient Registration Overview . . . . . . . . . . . . 5 4. Transient Registration Option . . . . . . . . . . . . . . . . 6 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 8 6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10 7. Transient Binding Cache Entries Update . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Muhanna, et al. Expires August 28, 2008 [Page 2] Internet-Draft PMIPv6 Support Transient Registration February 2008 1. Introduction Proxy Mobile IPv6 is a network-based mobility protocol which provides IP mobility for a mobile node without the involvement of the IPv6 host. Whenever a mobile node is attached to a PMIPv6 domain via a mobility access gateway, it appears to the mobile node as if it is attached to the same home link and thus the mobile node may think that it is not roaming away from home. In the case of mobile node active inter-MAG handoff from the source to the target MAG, the target MAG usually sends a proxy BU message to the mobile node local mobility anchor to update the mobile node BCE with a new pCoA. As soon as the LMA receives and successfully processes the proxy BU from the target MAG, LMA updates the mobile node BCE with the new care of address and switch the tunnel to the target MAG. However, during active inter-MAG handoff scenario, some of the mobile node uplink traffic may still be in transit through the previous MAG. In addition, in some active handoff scenarios, it is necessary to prepare the target MAG prior to completion of link layer handoff procedures. In some systems, the target MAG will be the recipient of uplink traffic prior to the completion of the procedure that would result in the PBU/PBA. Currently and as per PMIPv6 base protocol [1], LMA routes the mobile node's uplink traffic received from a tunnel as long as the source IP address of the mobile node's uplink traffic matches the IP address of the mobile node's registered pCoA in an active BCE. This document specifies an enhancement to Proxy MIPv6 base protocol to support transient registration. This process allows the target mobile access gateway to request the local mobility anchor to create a transient binding cache entry with uplink traffic forwarding capabilities for a specified period of time while still maintaining the active state for the existing BCE, i.e., sending and receiving traffic on both directions. Eventually and after a short lived lifetime, the mobile node transient BCE is updated to regular BCE and the original regular BCE is removed as described in Section 6 This mechanism is critical for reducing handoff latency and will be an important parameter for real-time applications such as VoIP. It is assumed that inter-MAG handoff is carried out with a central entity that is responsible for the mobile node context transfer across the source and target MAGs. Muhanna, et al. Expires August 28, 2008 [Page 3] Internet-Draft PMIPv6 Support Transient Registration February 2008 2. Conventions used in this document 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 RFC2119 [2]. General mobility terminology can be found in [5], [3], and [1]. The following additional or clarified terms are used in this document: Proxy BCE (pBCE): The mobile node BCE that has the same characteristics as the MN BCE in PMIPv6 base protocol [1]. Transient BCE (tBCE): The mobile node BCE that is created by the process described in this document. The tBCE is short lived with a lifetime that is no more than the transient registration lifetime. When LMA creates such transient BCE, it allows uplink traffic from the mobile node while the mobile node is in the process of moving from sMAG to the tMAG. Transient Registration (tReg.) The mechanism which allows the LMA to create a transient BCE for a specific mobile node with uplink traffic forward capability from a care-of address different than the current proxy care-of address that is registered in the mobile node current regular BCE. During the lifetime of the tBCE, the LMA may forward the mobile node uplink traffic from both care-of addresses to the internet while sending the downlink traffic to the source care-of address. Source MAG (sMAG): The mobile access gateway that the mobile node is currently attached to and moving from its area coverage to another MAG. Target MAG (tMAG): The mobile access gateway that the mobile node is moving to its area of coverage and attaches to during an inter-MAG handoff scenario. Muhanna, et al. Expires August 28, 2008 [Page 4] Internet-Draft PMIPv6 Support Transient Registration February 2008 Source proxy Care-of Address (s-pCoA): The mobile node proxy care-of address that is hosted at the sMAG and currently referenced in the mobile node regular BCE before the transient registration starts. Transient proxy Care-of Address (t-pCoA): The mobile node's proxy care-of address that is hosted at tMAG and has been registered by the tMAG during a mobile node transient registration procedure. It is the pCoA in an active tBCE. 3. PMIPv6 Transient Registration Overview Several scenarios have been identified relevant to PMIPv6 support for mobile nodes multihoming where a mobile node is multihomed through different interfaces simultaneously accessing the same PMIPv6 domain. Transient multihoming scenario has been described in [4] where a mobile node is transitionally multihomed using different proxy care-of addresses for a short period of time. This transient multihoming scenario is enabled through PMIPv6 support of transient registration. During active inter-MAG handoff scenario, a transitional period of time requires the LMA in the PMIPv6 domain to accept uplink traffic for the same mobile node but through different MAGs. Context transfer is assumed to provide the needed mobile node information and parameters to enable the target MAG to send a proxy BU message with the same HNP and interface ID, however, with an indication that the current registration is a transient registration with a short lifetime. As soon as the LMA receives a P-BU with transient registration mobility option, the LMA identifies the mobile nodes current pBCE which reflects the s-pCoA and creates a new tBCE with a lifetime as specified in the TRO lifetime field. Additionally, the LMA tags the tBCE as uplink traffic forwarding as per the traffic direction in the TRO. Figure 1 shows a mobile node binding cache entry state during inter-MAG active handoff using a single interface to access the PMIPv6 domain. Muhanna, et al. Expires August 28, 2008 [Page 5] Internet-Draft PMIPv6 Support Transient Registration February 2008 Mobile node's BCE States @ LMA ============================== Before tReg. MN-if1 [prefix1 @ sMAG] [pBCE] During tReg. MN-if1 [prefix1 @ tMAG] [tBCE] MN-if1 [prefix1 @ sMAG] [pBCE] After tReg. MN-if1 [prefix1 @ tMAG] [pBCE] MN-if1 [prefix1 @ sMAG] [removed] +=====+ if1 +------+ +------+ | MN |---------->| | | | +=====+ | tMAG |\ +=================+ | | | | | \ / \ | | ^ +------+ \ / IPv6/IPv4 Transport \ | L | MN +---+ ...... +----| M | Handover +------+ / \ IPv6/IPv4 Transport / | A | ^ | | / \ / | | ...^... if1 | sMAG |/ +=================+ | | | MN |...........| | | | ....... +------+ +------+ |<------------------ PMIPv6 Domain ---------------->| Figure 1: PMIPv6 Transient Multihoming during Inter-MAG handoff Over one Interface. It is assumed that during the active inter-MAG handoff and when the tMAG sends a P-BU for a new transient BCE, the mobile node is homed at the target MAG. However, in order to guarantee safe and on time delivery of the uplink and downlink traffics, a transient BCE with uplink traffic forwarding capability is necessary. During the tBCE lifetime, the LMA continue to send all of the mobile node downlink traffic to the sMAG. It is also assumed that the source MAG is aware of the mobile node's current point of attachment and forward all of the downlink traffic to the mobile node accordingly. 4. Transient Registration Option Transient Registration Option, TRO, is included in the P-BU message Muhanna, et al. Expires August 28, 2008 [Page 6] Internet-Draft PMIPv6 Support Transient Registration February 2008 by the tMAG to indicate to the LMA that it is requesting the registration and creation of a transient BCE with the criterias as defined in the TRO. The source IP address of the P-BU is considered the transient CoA while the lifetime field specifies the transient BCE lifetime in one-tenth of seconds. The transient traffic field specifies the traffic forwarding capability throughout the tBCE lifetime, which in this case is limited to uplink only. The Transient Registration option has an alignment requirement of 4n+2. Its format is as shown in Figure 2 below. 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (R) | Trans. Traffic| Transient BCE Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Transient Registration Option Format Type Length 8-bit unsigned integer indicating the length in octets of this option, excluding the type and length fields. The value of this field must be set to 4. 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. Transient Traffic Direction This 8-bit field is used as a bit-wise field to specify the transient traffic direction. The following values are specified. 00000001 Uplink Traffic Forward Capability All remaining Values are reserved. Transient BCE Lifetime This 16-bit field specify the requested lifetime for the transient BCE in the number one-tenth of a second. Muhanna, et al. Expires August 28, 2008 [Page 7] Internet-Draft PMIPv6 Support Transient Registration February 2008 5. Mobile Access Gateway Operation During the mobile node inter-MAG handoff process, the target MAG gets the current mobile node BCE information through an out of scope context transfer mechanism. It is assumed that the target MAG have access to the mobile node ID, HNP, Interface ID. When the target MAG receives the indication that the mobile node is moving from the source MAG access network area to the target MAG area, the target MAG sends a PBU on behalf of the mobile node. In this PBU, the target MAG specifies the MN-ID, HNP, and the interface ID as per PMIPv6 base protocol. On the other hand, the target MAG sets the HI to 3 and includes the transient registration option to indicate to the LMA that this registration is a transient registration P-BU and the LMA needs to create a tBCE. The tMAG sets the value of the transient lifetime to a value that is dependent on the deployment and operator specific. Additionally, the tMAG indicates that transient traffic forwarding capability is uplink only by setting the transient traffic field to a value 1. After the target MAG receives an indication that the mobile node has completed the inter-MAG handoff process and the data path is ready to move the tunnel completely from the source MAG to the target MAG, the target MAG SHOULD send a PBU to allow the local mobility anchor to update the tBCE to a regular BCE and to switch the data bath completely to be delivered through the target care-of address. In this case, the tMAG sends a PBU with the MN-ID, Interface ID, MN-HNP and at the same time sets the HI to 3. The tMAG does not include the transient registration option as shown in Figure 3. Muhanna, et al. Expires August 28, 2008 [Page 8] Internet-Draft PMIPv6 Support Transient Registration February 2008 +-----+ +-----+ +-----+ +-----+ | MN | |s-MAG| |t-MAG| | LMA | +-----+ +-----+ +-----+ +-----+ | | | bi-directional | | |<<<<<<<<========================>>>>>>>>| | | | pBCE | | | [HNP1, s-pCOA, IF1] Handoff Event | | | | MN HO Event | | | | HO Event Acquire | | | MN pBCE[MN-ID, HNP1, IF1] | LL Attach to | | | tMAG AN | |-------P-BU (tReg.)------->| | | | Create tBCE | | | [HNP1, t-pCOA, IF1] | | | pBCE HO Progress | | |<------P-BA (tReg.)--------| | | | | | | bi-directional | | |<<<<<<<<========================>>>>>>>>| | | | | | | | uplink only | | | |>>>>>>=============>>>>>>>>| | | | | | | HO Complete | | | |----- P-BU (NO tReg.) ---->| | | | | | | | Update tBCE to pBCE | | | pBCE=[HNP1, t-pCOA, IF1] | | |<--------- P-BA -----------| | |` | | | | |<<<<<<<<===========>>>>>>>>| | | | | | | | remove Source pBCE | | | | Figure 3: Target MAG Update MN tBCE during Inter-MAG Handover In the event that the target MAG receives downlink traffic destined to the mobile node from the LMA over the MAG-LMA tunnel, the tMAG MUST deliver the downlink traffic to the mobile node. In this case, the tMAG choose not to send a PBU to update the mobile node tBCE. The tMAG may assume that the LMA has updated the mobile node tBCE to regular BCE possibly after the LMA received a de-registration message from the source MAG for the pBCE with care-of address s-pCoA. Muhanna, et al. Expires August 28, 2008 [Page 9] Internet-Draft PMIPv6 Support Transient Registration February 2008 6. Local Mobility Anchor Operation When an uplink packet is received from the MN through the target MAG, the LMA MUST verify if the source address of the packet matches the transient pCoA. If the address matches, the LMA MUST consider the packet to be valid and MUST forward the packet appropriately based on the contents of the decapsulated packet. If the mobile node's tBCE indicates uplink traffic forwarding capability, the LMA MUST NOT use the tBCE for sending out downlink traffic to the MN through the target MAG. When the LMA receives a PBU with the transient registration option included and the MN-ID, HNP, and the IF-ID, the LMA allocates all the binding cache entries for the same MN-ID. The LMA then identifies the BCE that have the same HNP and Interface ID. The LMA set an indication flag to "handoff in progress". The LMA creates a tBCE after allocating the same HNP and sets the transient lifetime field to the value received in the TRO. LMA sends a PBA with HI equals to the value received in PBU and as per the processes in PMIPv6 base protocol. After the LMA creates the mobile node transient BCE, the LMA add another routing entry to the MN for the new t-pCOA. As long as the tBCE is active, the LMA MUST forward all of the mobile node intercepted downlink traffic to the source pCOA. 7. Transient Binding Cache Entries Update The transient binding cache entry, which was created by the procedure described in this document, needs to be short lived. i.e. for the duration of the inter-MAG handover. After the handover completes, this entry needs to be updated to a pBCE state. At the same time, the LMA deletes the mobile node pBCE which is tagged as "handoff in progress" and points to the source pCOA which is hosted at the sMAG. There are three ways by which this process can happen: 1. The target MAG sends a new PBU with HI value 3 (Handoff between mobile access gateways for the same interface): The transient binding cache entry is converted into a full blown binding cache entry and the BCE for the source MAG is removed. Figure 3 shows the call flow for this procedure. Muhanna, et al. Expires August 28, 2008 [Page 10] Internet-Draft PMIPv6 Support Transient Registration February 2008 2. The source MAG sends a deregistration PBU: The transient binding cache entry is converted into a pBCE and the pBCE for the source MAG is removed. Figure 4 shows the call flow for this procedure. 3. Transient BCE lifetime expires: If the tBCE lifetime expires before the tBCE has been updated based on one of the above cases Paragraph 1 or Paragraph 2, the LMA MUST update the tBCE to pBCE and remove the pBCE for the source MAG as shown in Figure 5 . Additionally, the LMA MAY send a revocation indication message to indicate to the source MAG that the mobile node's pBCE has been removed and it needs to clean associated resources. Muhanna, et al. Expires August 28, 2008 [Page 11] Internet-Draft PMIPv6 Support Transient Registration February 2008 +-----+ +-----+ +-----+ +-----+ | MN | |s-MAG| |t-MAG| | LMA | +-----+ +-----+ +-----+ +-----+ | | | bi-directional | | |<<<<<<<<========================>>>>>>>>| | | | pBCE | | | [HNP1, s-pCOA, IF1] Handoff Event | | | | MN HO Event | | | | HO Event Acquire | | | MN pBCE[MN-ID, HNP1, IF1] | LL Attach to | | | tMAG AN | | | | | |-------P-BU (tReg.)------->| | | | | | | | Create tBCE | | | [HNP1, t-pCOA, IF1] | | | pBCE HO Progress | | |<------P-BA (tReg.)--------| | | | | | | bi-directional | | |<<<<<<<<========================>>>>>>>>| | | | | | | | uplink only | | | |>>>>>>=============>>>>>>>>| | HO | | | Complete | | | |------------- P-BU (de-Reg.) ---------->| | | | | | | | Remove Source pBCE | |<------------------ P-BA ---------------| | | | | | | | Update tBCE to pBCE | | | pBCE=[HNP1, t-pCOA, IF1] | |` | | | | |<<<<<<<<===========>>>>>>>>| | | | | Figure 4: Source MAG Deregister MN Old pBCE during Inter-MAG Handover Muhanna, et al. Expires August 28, 2008 [Page 12] Internet-Draft PMIPv6 Support Transient Registration February 2008 +-----+ +-----+ +-----+ +-----+ | MN | |s-MAG| |t-MAG| | LMA | +-----+ +-----+ +-----+ +-----+ | | | | | | | tBCE Active | | | tReg. Lifetime Start | | bi-directional | | |<<<<<<<<========================>>>>>>>>| | | | | | | | uplink only | | | |>>>>>>=============>>>>>>>>| | HO | | | Complete | | | | | tReg. Lifetime Expires | | | No PBU from tMAG | | | No De-reg. from sMAG | | | | | | | | | | | Update tBCE to pBCE | | | bi-directional | | | |<<<<<<<<===========>>>>>>>>| | | | | | | | remove source pBCE | | | | | | | | Figure 5: LMA Updates Transient BCE upon Transient Registration Lifetime Expiry 8. IANA Considerations This document defines one new Mobility Header option, the Transient Registration option, which is described in Figure 2. The Type value for this option needs to be assigned from the same numbering space as allocated for the other mobility options, as defined in [3]. 9. Security Considerations This document does not present any new security requirement on the top of the security requirements listed in PMIPv6 base protocol [1]. It only presents a mechanism which allows a mobile node to be transitionally multihomed at two care of addresses during an inter- MAG active handoff using the existing trust relationship and security Muhanna, et al. Expires August 28, 2008 [Page 13] Internet-Draft PMIPv6 Support Transient Registration February 2008 association between the LMA and the source and target MAGs. 10. Acknowledgements The idea to capture transient registration as presented in this document came out of a discussion during IETF70 at Vancouver in December 2007. The following people were involved in the discussion (listed by last name) Kuntal Chowdhury, Vijay Devarapalli, Sri Gundavelli, Lalit Kotecha, Suresh Krishnan, Kent Leung and Ahmad Muhanna. 11. References 11.1. Normative References [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-11 (work in progress), February 2008. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Muhanna, A. and M. Khalil, "Proxy MIPv6 support for Mobile Nodes with Multihoming", draft-muhanna-netlmm-multihoming-support-01 (work in progress), February 2008. 11.2. Informative References [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [6] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in progress), November 2007. Muhanna, et al. Expires August 28, 2008 [Page 14] Internet-Draft PMIPv6 Support Transient Registration February 2008 Authors' Addresses Ahmad Muhanna Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Phone: +1 (972) 685-1416 Email: amuhanna@nortel.com Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 (514) 345-7900 x42871 Email: suresh.krishnan@ericsson.com Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: kleung@cisco.com Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 USA Email: basavaraj.patil@nsn.com Muhanna, et al. Expires August 28, 2008 [Page 15] Internet-Draft PMIPv6 Support Transient Registration February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Muhanna, et al. Expires August 28, 2008 [Page 16]