NetLMM Working Group M. Liebsch Internet-Draft NEC Expires: February 1, 2008 C. Vogt Ericsson July 31, 2007 Context Transfer for Proxy MIPv6 draft-liebsch-netlmm-proxymip6ct-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 February 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Liebsch & Vogt Expires February 1, 2008 [Page 1] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 Abstract The IETF is specifying a protocol for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account. This document specifies how the IETF's Context Transfer Protocol, which is specified in RFC 4067, can be used with protocols for network-based mobility management, taking proactive and reactive handover scenarios into account. The protocol Proxy Mobile IPv6 is suitable to support network-based mobility management, which is the reference protocol solution for the integration of the context transfer mechanisms in this document. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Functional Components . . . . . . . . . . . . 5 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Reference Architecture . . . . . . . . . . . . . . . . . . 6 4.2. Deployment Options . . . . . . . . . . . . . . . . . . . . 7 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Reactive Handover - Case 1 . . . . . . . . . . . . . . . . 9 5.2. Reactive Handover - Case 2 . . . . . . . . . . . . . . . . 10 5.3. Proactive Handover - Case 1 . . . . . . . . . . . . . . . 11 5.4. Proactive Handover - Case 2 . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Liebsch & Vogt Expires February 1, 2008 [Page 2] Internet-Draft Context Transfer for Proxy MIPv6 July 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 & Vogt Expires February 1, 2008 [Page 3] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 2. Introduction The NetLMM WG is specifying a protocol for network-based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover into account in a first protocol release. The specification of extensions and optimization is for further study and subject for either being incorporated into future versions of the protocol or specified in separate documents. In scope of the base protocol specification is the set up and maintenance of a forwarding tunnel between an MN's Mobility Access Gateway (MAG) and its selected Local Mobility Anchor (LMA). The protocol Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is being designed to suit basic operation of network-based localized mobility management. According to [RFC4831], mobility management should not depend on mobility-related signaling from mobile nodes (MNs), such as location updates. However, it's considered as beneficial to support transfer of an MN's context between the MN's previous and new access routers in case the MN changes its point of attachment and this change implies a change in the MN's access router. Other mechanisms than receiving an explicit indication from the MN must be used to initiate the transfer of context between access routers. This document specifies, how context transfer can be achieved in a Proxy MIPv6 enabled network. [RFC4067] is referred to as base and generic protocol operation between access routers to perform context transfer. The associated functional components for context transfer are embedded into the Proxy MIPv6 architecture and protocol operation to support context transfer efficiently by means of reusing Proxy MIPv6 protocol elements and event indications, without the need to rely on explicit indication from MNs. This document first discusses different scenarios for context transfer in a Proxy-MIPv6 enabled network, taking context push and context pull operation, as well as support for proactive and reactive handover into account. Subsequently, the integrated protocol operation is described. Extensions to the Proxy MIPv6 protocol are described in case they are required to support some of the reference scenarios. If the integrated protocol operation relies on information, which is not available on the relevant network component, the source and means to retrieve such information is described. Liebsch & Vogt Expires February 1, 2008 [Page 4] Internet-Draft Context Transfer for Proxy MIPv6 July 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 CT - Context Transfer. Means the transfer of any mobile node related context from the mobile's previous access router to its handover target access router. o CR - Context Ready. Describes a state on an access router, indicating that the router is ready to activate a context as soon as it's available. o CA - Context Activation. Describes a state on an access router, indicating that the router has the complete context received and activated. o PHT - Proactive Handover Trigger. Describes an event on an access router, which indicates the preparation or execution of a proactive handover. Such indication provides further information about the handover target access router, such as its IP address or an unambiguous identifier. o ATT - Attach. Describes an event on an access router, which indicates that a mobile node has attached to the router and has a fully functional layer-2 link established for bi-directional traffic. Such indication provides further information, which is required for the network-based mobility management protocol to operate. Liebsch & Vogt Expires February 1, 2008 [Page 5] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 4. Protocol Design This section describes the integration of the IETF's Context Transfer protocol [RFC4067] with Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6]. The reference architecture is described in Figure 1. 4.1. Reference Architecture The reference architecture covers a mobile node (MN), which is attached to a local domain operating Proxy Mobile IPv6. The MN's Local Mobility Anchor (LMA) tracks the MN's location and maintains associated forwarding states towards the MN's current MAG. MAGs are assumed to be colocated with the domain's access routers. In case the MN changes its MAG due to a handover, the procedure implies that the MN detaches from its current access router, which implements the MN's previous MAG (pMAG) and attaches to a handover target access router, which implements the MN's new MAG (nMAG). The context transfer (CT) protocol is supposed to transfer the MN's context from its previous access router to its new access router. The reference architecture is illustrated in Figure 1. Liebsch & Vogt Expires February 1, 2008 [Page 6] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 Internet Backbone : : | +-----+ | LMA | +-----+ | | | | +-------+ +--------+ | | | | +-------+ +-------+ |+-----+| |+-----+| ||pMAG || ||nMAG || |+-----+| CT |+-----+| | AR |--------->| AR | +-------+ +-------+ : .: : .........: . ....: :: +--+ |MN|---------> +--+ Figure 1: Reference architecture for context transfer in Proxy MIPv6. Note: Within the context of the description in this document, pMAG always refers to the network component, which is the MN's previous access router, whereas nMAG refers to the MN's new access router. 4.2. Deployment Options The integrated context transfer protocol leaves network operators deployment liberties along three orthogonal axes: 1. Context transfer may happen reactively or proactively. 2. Context transfer may be initiated by the pMAG or by the nMAG. 3. The initiating pMAG/nMAG may obtain the IP address of the correspondent nMAG/pMAG from any third entity. Reactive context transfer is initiated either by the pMAG after the mobile node has detached from the pMAG, or by the nMAG after the Liebsch & Vogt Expires February 1, 2008 [Page 7] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 mobile node has attached to the nMAG. Proactive context transfer is initiated either by the pMAG before the mobile node detaches from the pMAG, or by the nMAG before the mobile node attaches to the nMAG. Context transfer requires a trigger for the initiating MAG to indicate when the transfer should start. In case the context transfer is reactive, this trigger may be a notification from the link layer. If the context transfer happens proactively, the trigger is likely to originate from a handover prediction algorithm that runs on the initiating MAG. Context transfer furthermore requires a "MAG resolution mechanism" through which the initiating MAG can obtain the IP address of the correspondent MAG. If the IP address of the correspondent MAG is to be obtained from the LMA, the MAG resolution mechanism may use options to Proxy Mobile IPv6 messages. The IP address of the correspondent MAG may also be obtained through a proprietary mechanism from the policy store, or via a local trigger. The nature of the MAG resolution mechanism determines whether the context transfer begins in parallel with the corresponding proxy binding update or afterwards. Liebsch & Vogt Expires February 1, 2008 [Page 8] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 5. Protocol Operation This section describes the operation of the integrated context transfer protocol. The protocol operation is described for reactive as well as proactive handover and assumes the required information for context transfer is made available either through Proxy Mobile IPv6 signaling or by means of a local event, which provides the required information. The reactive handover can distinguish two different scenarios. In one scenario, all information required to operate Context Transfer on MAGs will be retrieved from the MN's LMA. A different scenario might support the provision of some required information from a local event, such as an ATTACH indication. The proactive handover requires the pMAG to learn about the network entity, which implements the MN's nMAG. One general issue to be referred to is context deactivation and deletion on an MN's previous access router. It needs to be ensured that the context is not deleted before it has been completely transferred to the MN's new access router. This could be achieved by means of linking the lifetime of context information to the Proxy Mobile IPv6 binding update list (BUL) on a MAG. If the MN's entry expires in the BUL, the context can be deleted. This is somehow save, as a BUL entry is not explicitly deleted under control of an LMA, but has soft state characteristics, which expires. Deactivation of context on the pMAG should be coordinated by the individual component, which maintains the context. 5.1. Reactive Handover - Case 1 Figure 2 covers the integrated protocol operation for a reactive handover, where the nMAG can initiate context transfer only after the required information about the pMAG has been retrieved from the MN's LMA. As the LMA is aware of the MN's pMAG, it can inform the nMAG about the pMAG's IP address. This information can be conveyed in a Mobility Option of the Proxy BACK message. Possible option is a pMAG_Address option, which carries the pMAG's IP address. Alternatively, the pMAG can be identified by means of an identifier, which can be resolved on the nMAG into the pMAG's IP address. For this purpose, a pMAG_ID option can be specified. The nMAG is ready to receive and activate context after the reception of the Proxy BACK. The context can be activated after context data has been transferred completely from the pMAG. Liebsch & Vogt Expires February 1, 2008 [Page 9] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 +----+ +----+ +---+ |pMAG| |nMAG| |LMA| +----+ +----+ +---+ | | | | [ATT] | | |-------- Proxy BU ------->| | | | | |<------ Proxy BACK -------| | [CR] | |<----- CT-Req ------| | | | | |-------- CTD ------>| | | [CA] | |<-------CTDR*-------| | | | | | | | *Optional Figure 2: Reactive Handover - Case 1 5.2. Reactive Handover - Case 2 Figure 3 covers the integrated protocol operation for a reactive handover, where the nMAG retrieves information about the MN's pMAG through a local event, which also triggers the Proxy BU. This approach does not require any additional information from Proxy Mobile IPv6 operation. The context transfer can be performed in parallel to the Proxy Mobile IPv6 registration. The context can be activated on the nMAG after the reception of the context data. Liebsch & Vogt Expires February 1, 2008 [Page 10] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 +----+ +----+ +---+ |pMAG| |nMAG| |LMA| +----+ +----+ +---+ | | | | [ATT] | | |-------- Proxy BU ------->| |<----- CT-Req ------| | | |<-------Proxy BACK--------| | [CR] | |-------- CTD ------>| | | [CA] | |<-------CTDR*-------| | | | | | | | *Optional Figure 3: Reactive Handover - Case 2 5.3. Proactive Handover - Case 1 Figure 4 covers the integrated protocol operation for a proactive handover, where the pMAG can push an MN's context data to its target access router even before the MN attaches to the pMAG. The pMAG receives information about the MN's target access router through a local indication. This approach does not require any additional information from Proxy Mobile IPv6 operation. Advantageous of this approach is, that the nMAG can learn about the MN's LMA even before the MN attache MN attaches to the nMAG. The nMAG is in this scenario permanently in CR mode for a set of potential pMAGs. In a typical deployment scenario, MAGs that may exchange contexts have preconfigured security associations. A permanent CR mode between those MAGs that can authenticate each other does not introduce new security risks. Garbage collection at the nMAG ensures that transferred context will be removed automatically in case the mobile node to which the context belongs never arrives at the nMAG. Liebsch & Vogt Expires February 1, 2008 [Page 11] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 +----+ +----+ +---+ |pMAG| |nMAG| |LMA| +----+ +----+ +---+ | | | [PHT] | | |------- CTD ------->| | | | | |<------CTDR*--------| | | [ATT] | | |-------- Proxy BU ------->| | | | | |<------ Proxy BACK -------| | | | | | | *Optional Figure 4: Proactive Handover - Case 1 5.4. Proactive Handover - Case 2 Figure 5 covers the integrated protocol operation for a proactive handover, where the nMAG retrieves information about the MN's pMAG through a local event. This approach does not require additional information from Proxy Mobile IPv6 operation. The context can be activated on the nMAG after the reception of the context data. The nMAG initiates the Proxy Mobile IPv6 registration once the mobile node attaches to it. Liebsch & Vogt Expires February 1, 2008 [Page 12] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 +----+ +----+ +---+ |pMAG| |nMAG| |LMA| +----+ +----+ +---+ | | | | [PHT] | |<----- CT-Req ------| | | [CR] | |-------- CTD ------>| | | [CA] | |<-------CTDR*-------| | | | | | [ATT] | | |-------- Proxy BU ------->| | | | | |<------ Proxy BACK -------| | | | | | | *Optional Figure 5: Proactive Handover - Case 2 Liebsch & Vogt Expires February 1, 2008 [Page 13] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 6. Security Considerations The integrated scenario as described in this document must meet the security requirements of the two individual protocol components, namely context transfer [RFC4067] and Proxy MIPv6 [I-D.ietf-netlmm-proxymip6]. Information about an MN's previous access router must be authenticated on the nMAG. If such information is retrieved from a policy store, the access router which implements the nMAG should share a security association with the policy store. Other mechanisms to protect such information must be applied in case there is no security association available between these network entities. The same applies for information about the new access router, which is used on the MN's pMAG to initiate context transfer in case of a proactive handover scenario. Liebsch & Vogt Expires February 1, 2008 [Page 14] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 7. IANA Considerations This documents includes no request to IANA. Liebsch & Vogt Expires February 1, 2008 [Page 15] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 8. Contributors This document comprises valuable contributions from Julien Abeille (abeille@netlab.nec.de). Liebsch & Vogt Expires February 1, 2008 [Page 16] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 9. 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-01 (work in progress), June 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. [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. Liebsch & Vogt Expires February 1, 2008 [Page 17] Internet-Draft Context Transfer for Proxy MIPv6 July 2007 Authors' Addresses Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: liebsch@netlab.nec.de Christian Vogt Ericsson Research, NomadicLab Hirsalantie 11 02420 Jorvas Finland Email: christian.vogt@ericsson.com Liebsch & Vogt Expires February 1, 2008 [Page 18] Internet-Draft Context Transfer for Proxy MIPv6 July 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 & Vogt Expires February 1, 2008 [Page 19]