NetLMM Working Group M. Liebsch Internet-Draft L. Le Expires: May 12, 2008 NEC November 9, 2007 Inter-Technology Handover for Proxy MIPv6 draft-liebsch-netlmm-intertech-proxymip6ho-00.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 May 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Liebsch & Le Expires May 12, 2008 [Page 1] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 Abstract The IETF is specifying Proxy Mobile IPv6 for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and hand over from one network interface to another network interface while remaining anchored at the same Local Mobility Anchor. This extension avoids that the LMA will prematurely forward data packets for the mobile node to the mobile node's new interface before the address configuration of this interface has completed. With the proposed extension, packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be avoided. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Functional Components . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 5. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Description and use of extensions . . . . . . . . . . . . 8 5.2. Protocol extensions . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Liebsch & Le Expires May 12, 2008 [Page 2] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Liebsch & Le Expires May 12, 2008 [Page 3] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 2. Introduction The NetLMM WG is specifying Proxy Mobile IPv6 for network-based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover into account in a first protocol release. This document proposes an extension to Proxy Mobile IPv6 to suit MNs, which have multiple network interfaces implemented and hand over from one network interface to another network interface while remaining anchored at the same Local Mobility Anchor. Without such extension, inter-technology handover could result in tremendous packet loss. When an inter-technology handover occurs, the mobile node needs to perform address configuration for the new interface. For IPv6, this typically requires the mobile node to send a Router Solicitation and awaits a Router Advertisement. The mobile node also needs to perform duplicate address detection. During this time, the mobile node's new interface is not fully configured and not yet ready to receive data packets. If the LMA decides to forward data packets for the mobile node via the new MAG, severe packet losses can occur. This document proposes an extension to Proxy Mobile IPv6 that allows classification of a new binding as 'preliminary' and to 'activate' such binding only when the MN's new interface is fully configured and ready to receive data packets. Thanks to this extension, the LMA will not prematurely forward data packets for the MN to the new MAG before the address configuration for the MN's new interface is not completed. The result of this proposed extension is that packet buffering at the new MAG is not necessary and packet losses during an inter-technology handover can be avoided. Liebsch & Le Expires May 12, 2008 [Page 4] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 3. Terminology and Functional Components o MAG - Mobility Access Gateway. PMIPv6 functional component defined in [I-D.ietf-netlmm-proxymip6]. The MAG function is assumed to be located on the PMIPv6 domain's access routers. o LMA - Local Mobility Anchor. PMIPv6 functional component defined in [I-D.ietf-netlmm-proxymip6]. o pAR - Previous Access Router. Equivalent to current access router. In a layer 3 handover situation, the access router which the mobile node is leaving. o nAR - New Access Router. Equivalent to handover target access router. In a layer 3 handover situation, the access router towards which the mobile node is moving. o pMAG - previous MAG. In a layer 3 handover situation, the MAG function located on the previous access router o nMAG - new MAG. In a layer 3 handover situation, the MAG function located on the new access router. o IF - Interface. Any network interface, which offers an MN wireless or wired access to the network infrastructure. In case an MN has multiple interfaces implemented, they are numbered (IF1, IF2, ...) o Inter-RAT handover. Handover between different radio access technologies. Liebsch & Le Expires May 12, 2008 [Page 5] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 4. Problem Statement A problem that can occur during an inter-technology handover is that the MN's new interface may not be ready to receive packets immediately after the handover. The reason is that the MN needs to perform certain protocol operations to configure its new interface and these operations can take time. In order to complete the address configuration of its new interface, the MN needs to send a router solicitation and awaits a router advertisement. Upon receiving a router advertisement from the new MAG, the MN can complete its address configuration and the MN's new interface is now ready to receive packets. During the address configuration of the MN's interface, if the LMA and the new MAG already establishes a tunnel and the LMA starts forwarding data packets for the MN to the new MAG, these data packets will be lost (since address configuration of the MN's new interface is not completed and the new interface is not yet ready to receive data). However, delaying the registration signaling, which is sent from the new MAG to the LMA after the MN's new interface has attached to the network, is not possible, as the new MAG retrieves configuration data for the MN from the LMA. Host-based mobility protocols, such as Mobile IPv6 [RFC3775] can easily control when a binding is updated. This is different for network-based mobility management, where hosts are not involved in IP mobility management [RFC4831] The aforementioned problem is illustrated in Figure 1. An MN has attached to the network with interface IF1 and receives data on this interface. When the MN's new interface IF2 comes up and is detected by the new MAG, the new MAG sends a PBU and receives a PBA from the LMA. If the LMA decides to forward data packets for the MN via the new MAG, the new MAG has to buffer these packets until address configuration of the MN's new interface is completed and the MN's new interface is ready to receive packets. While setting up IF2, the MN may not reply to address resolution signaling, as sent by the new MAG (A). If the MAG's buffer overflows or the MN cannot reply to address resolution signaling for too long, all data packets for the MN are dropped and the MN can experience severe packet losses during an inter-technology handover (B). This document proposes an extension to Proxy Mobile IPv6 that provides the new MAG with a signaling mechanism to notify the LMA when the MN's new interface is fully configured and ready to receive data packets. Thanks to this signaling mechanism, the LMA will not prematurely forward data packets for the MN to the new MAG before the address configuration of the MN's new interface is not completed. The result of this proposed extension is that packet buffering at the Liebsch & Le Expires May 12, 2008 [Page 6] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 new MAG is not necessary and packet losses during an inter-technology handover can be avoided. +------+ +----+ +----+ +---+ | MN | |pMAG| |nMAG| |LMA| +------+ +----+ +----+ +---+ IF2 IF1 | | | | | | | | | |- - - - - - --- - Attach | | | | |---------------PBU--------------->| | | |<--------------PBA----------------| | |--------RtSol------->| | | | |<-------RtAdv--------| | | | Addr. | | | | Conf. | | | | |<--------------------|==================data============|-- | | | | | |- - - - - - - - --- - - - - - - - Attach | | | | |----------PBU-------->| | | | |<---------PBA---------| | | | |<-====data============|-- (A)?|<-----------NSol---------------------|<-====data============|-- | | | (B) ?|<-====data============|-- | | | ?|<-====data============|-- |-----------RtSol-------------------->|<-====data============|-- |<------------------------------------| : | Addr. | | | : | Conf. | | | : | |<-----------NSol---------------------| : | |------------NAdv-------------------->| | !|<------------------------------------|======data============|-- | | | | | | | | | | Figure 1: Issue with inter-RAT mobility. Liebsch & Le Expires May 12, 2008 [Page 7] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 5. PMIPv6 Extensions This section describes an extension to [I-D.ietf-netlmm-proxymip6] to solve the problem of using a handover target technology before it is ready to receive and send IP packets. The key extension is to allow classification of an MN's binding cache entry on the LMA as 'preliminary' or 'active'. Classification can be performed either locally on the LMA or on a network component, which is not colocated with the LMA. An example about how classification can be controlled and signaled is described in Section 5.1, whereas Section 5.2 describes associated extensions to existing signaling and states. 5.1. Description and use of extensions In an inter-technology handover scenario, an MN activates a network interface, which is different from the currently used one. The new interface should serve as interface through which the MN sends and receives packets. After a handover, the MN shuts down the previously used interface. The extension to the base PMIPv6 protocol as described in this document forwards downlink packets to an MN's new interface only when the new interface is ready to receive and send IP packets. Figure 2 illustrates the components of a PMIPv6 network, which comprises the MN's LMA as well as its pMAG and the nMAG. The pMAG is supposed to support an access network, which conforms to the technology of Interface 1 (IF1) of the MN, whereas the nMAG supports an access network, which conforms to the technology of IF2. The MN attaches to the PMIPv6 network with IF1 according to the procedure in [I-D.ietf-netlmm-proxymip6]. The MN starts receiving data packets on IF1. When the MN activates IF2 to prepare an inter- technology handover, the nMAG receives an attach indication and sends the PBU to the LMA to retrieve configuration information for the MN (e.g. HNP). The LMA should be able to identify a technology change for the MN's binding. This can be done by means of processing the Access Technology Type option, which comes along with the PBU. The PBU may also carry an MN Interface Identifier option, which helps the LMA also to identify a technology change. Alternative mechanisms to learn about the nature of a handover are possible, such as the explicit notification from the nMAG or from any other network component. This requires the LMA to maintain information about the MN's currently used technology into the MN's binding cache entry, as it is considered in [I-D.ietf-netlmm-proxymip6]. If the LMA detects a technology change for the same MN, it enters the nMAG as forwarding information into the binding cache, but classifies this binding as 'preliminary' (A). The status 'preliminary' causes Liebsch & Le Expires May 12, 2008 [Page 8] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 the LMA to keep using the previous binding as forwarding information until the preliminary binding will be activated. The LMA acknowledges the PBU by means of sending a PBA to the nMAG. The PBA carries the MN's HNP as well as a flag, which indicates the status 'preliminary' to the nMAG (B). The nMAG learns through the PBA, that an explicit activation of the binding is required. If explicit activation of the binding is expected from the nMAG, the nMAG should find out when the MN's new interface has been set up and configured completely. For example, the nMAG could listen to Neighbor Solicitations from the MN's IF2, which indicate that the MN has configured a global address at IF2 and performs duplicate address detection. Details about how the nMAG finds out that IF2 is ready for being used is out of scope of this version of the document. As soon as IF2 has been set up completely (C), the nMAG sends a further PBU to the LMA to 'activate' the previously as 'preliminary' classified binding. The PBU should indicate explicit activation by means of a flag. The activation causes the LMA to change forwarding information to refer to the nMAG and adjust the MN's binding cache entry accordingly (D). From that moment, downlink packets will be forwarded towards the MN's IF2 (E). Note: As the status 'preliminary' needs to be explicitly changed to 'active' before the LMA uses the new forwarding information, this example makes use of a further PBU/PBA handshake between the nMAG and the LMA. Alternative mechanisms are possible to activate the new state on the LMA. Liebsch & Le Expires May 12, 2008 [Page 9] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 +------+ +----+ +----+ +---+ | MN | |pMAG| |nMAG| |LMA| +------+ +----+ +----+ +---+ IF2 IF1 | | | | | | | | | |- - - - - - --- - Attach | | | | |---------------PBU--------------->| | | |<--------------PBA----------------| | |--------RtSol------->| | | | |<-------RtAdv--------| | | | Addr. | | | | Conf. | | | | |<--------------------|==================data============|-- | | | | | |- - - - - - - - --- - - - - - - - Attach | | | | |----------PBU-------->(A) | | | (B) |<-----PBA(prelim)-----| | | | | | | |<--------------------|==================================|-- |------------RtSol------------------->| | |<-----------RtAdv--------------------| | Addr. | | | | Conf | | (C) | | |------------NSol-------------------->|----PBU(activate)---->(D) | | | |<-------PBA-----------| |<------------------------------------|======================|-- | | | (E) | | | | | | | | | | | | Figure 2: Solution for inter-RAT mobility. 5.2. Protocol extensions The extension proposed in Section 5.1 requires maintenance of two forwarding entries on the LMA during an inter-technology handover procedure. One of these entries is marked as 'active', whereas the other one is 'preliminary'. Extensions to an MN's entry in the LMA's binding cache should comprise the interface identifier of the associated tunnel towards a MAG, as well as the associated access technology. If the MN Interface Identifier option is present in the PBU, this information should be linked to each forwarding entry accordingly. MAGs should maintain the status of an MN's binding in their binding update list. This is in particular important in case a new MAG needs Liebsch & Le Expires May 12, 2008 [Page 10] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 to explicitly activate a binding after the associated MN's new interface has proven to be ready for IP traffic. The PBU message should carry a binding status flag to allow indication of a binding status or the change of a binding status. The flag can be set to 1, which indicates 'activate'. A flag indicating '0' means 'preliminary'. In the PBU, the flag can in particular be used from a MAG to signal activation of a binding after the MN's new interface has been set up completely. If a MAG is not sure about the status of a binding, the MAG should indicate 'preliminary' in the PBU and learn about the status from the PBA sent by the LMA. Also the PBA message should carry the binding status flag to allow indication of a binding status. When set to '0', an LMA can indicate status 'preliminary' to a MAG when replying to a PBU. After the MAG explicitly activated a binding with a PBU, the LMA should set the flag to '1' in the PBA when the binding can be activated. Liebsch & Le Expires May 12, 2008 [Page 11] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 6. Security Considerations Signaling between MAGs and LMAs as well as information carried by PBU and PBA messages is protected and authenticated according to the mechanisms described in [I-D.ietf-netlmm-proxymip6]. In case MAGs or LMAs make use of a further protocol interface to an external component, the associated protocol must be protected and information must be authenticated. Such protocol interface may for example be used by an LMA or a MAG to learn about the nature of a handover or about the status of an MN's interface. Liebsch & Le Expires May 12, 2008 [Page 12] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 7. IANA Considerations This documents includes no request to IANA. Liebsch & Le Expires May 12, 2008 [Page 13] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 8. Normative References [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07 (work in progress), November 2007. [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. [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. Liebsch & Le Expires May 12, 2008 [Page 14] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 Authors' Addresses Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@nw.neclab.eu Long Le NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342224 Email: le@nw.neclab.eu Liebsch & Le Expires May 12, 2008 [Page 15] Internet-Draft Inter-Technology Handover for Proxy MIPv6 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). Liebsch & Le Expires May 12, 2008 [Page 16]