MIPSHOP Working Group R. Wakikawa Internet-Draft Toyota ITC Expires: May 21, 2009 S. Kiriyama Keio Univ. J. Xia Huawei November 17, 2008 Context Reflection: Context Transfer for Proxy Mobile IPv6 draft-wakikawa-pmip-ct-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 21, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Wakikawa, et al. Expires May 21, 2009 [Page 1] Internet-Draft Context Transfer for PMIP November 2008 Abstract This document introduces a simple Context Transfer mechanism for Proxy Mobile IPv6. This context transfer mechanism can carry information of a mobile node between mobility anchor gateways without any assumption of inter-MAG trust nor direct connectivity. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Context Reflection Mobility Message . . . . . . . . . . . 9 4.2. Context Data Option . . . . . . . . . . . . . . . . . . . 10 4.3. New option-code for the IP address option . . . . . . . . 11 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 13 A.1. Normative References . . . . . . . . . . . . . . . . . . . 13 A.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Wakikawa, et al. Expires May 21, 2009 [Page 2] Internet-Draft Context Transfer for PMIP November 2008 1. Introduction In Proxy Mobile IPv6, a Context Transfer mechanism is not specified in [RFC-5213], though it is somehow expected to be available. For instance, policy profile or the sequence number of a binding update list for a mobile node are ideally exchanged between mobile access gateways during mobile node's handover. Whenever a mobile node changes the attached mobile access gateway, the mobile node's policy profile is fetched by a new mobile access gateway. If a context transfer mechanism is available in Proxy Mobile IPv6, many optimization can be expected to handover performance. On the proposed context transfer mechanism, we introduce neither new trust nor physical link among mobile anchor gateways. All the contexts are transferred between mobile access gateways always via a local mobility anchor as shown in Figure 1-b). Context Notification and Reflection are defined as independent signaling, but they carry the same mobile node's context. Each mobile access gateways establishes trust (ex. IPsec Security Association) with its local mobility anchor, but it does not maintain security association with the other mobile access gateways according to [RFC-5213]. The overhead of trust and link establishments between mobile access gateways cannot be negligible. Specially in Proxy Mobile IPv6, we should promote more effective use of trust between LMA and MAG. In addition, if we consider to support different wireless access technology in a single NETLMM domain, it is better not to assume any trust and links between MAGs. +-------+ +-------+ | LMA | | LMA | +-------+ +-------+ / \ ^ \\ / \ // \\ / \ context // \\ context / \ Notification// \\ Reflection / \ // v +------+ context +------+ +------+ +------+ | pMAG |==========>| nMAG | | pMAG | | nMAG | +------+ +------+ +------+ +------+ a) b) Figure 1: Layer 3 topology for Proxy Mobile IPv6 On the other hand, since the contexts are always routed via a local mobility anchor, from the network (layer3) topology point of view, there is a concern that the path between mobile access gateways Wakikawa, et al. Expires May 21, 2009 [Page 3] Internet-Draft Context Transfer for PMIP November 2008 becomes redundant. However, if we carefully look the physical topology of Proxy Mobile IPv6 domain, it is not such common to have the direct physical links among mobile access gateways. Even if a message is directly sent between mobile access gateways like Figure 1-a), the message might be sent via a network core. Figure 2 shows that the logical topology is not always matched to layer-1 topology. Note that each MAG need to have links to all the neighboring MAGs to which a mobile node can handover. We draw only two links per MAG due to the limit of ASCII art in Figure 2-a). _.--'''MAG''''`-. MAG ..MAG | MAG MAG | MAG : \_____ |_____/ `. \_____ |_____/ : _------LMA____ : _------LMA____ MAG-/ __/ ||__ \------MAG MAG-/ __/ ||__ \------MAG | / | \__ .: / | \__ '---MAG MAG MAG..: MAG MAG MAG -...'' `....' a) Logical Topology b) Layer-1 Topology Figure 2: Layer 1 topology for Proxy Mobile IPv6 In addition, if contexts are always relayed by LMA, LMA can verify and control the context transfer. For instance, if LMA finds an error in one of contexts, it can prefent reflecting context to a new MAG. Since our context reflection mechanism can carry any kinds of mobile node's context including mobile node's policy profile, and binding states, etc., it can optimize the handover, too. However, optimizing handover is out of scope in this document. Wakikawa, et al. Expires May 21, 2009 [Page 4] Internet-Draft Context Transfer for PMIP November 2008 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. All terms in this document are defined in [RFC-5213] and [ID-PFMIP]. Wakikawa, et al. Expires May 21, 2009 [Page 5] Internet-Draft Context Transfer for PMIP November 2008 3. Protocol Overview Context Reflector requires the following assumptions. o pMAG MUST detect MN's detachment. o pMAG MUST obtain nMAG information. How to get NMAG address is out of scope in this document. Similar approach of [ID-PFMIP] can be used. o A single LMA is always used for a mobile node in a NETLMM domain. Figure 3 shows the signal sequence of the Context Reflector mechanism. Since LMA, pMAG and nMAG share certain security association, all the messages for the context reflection mechanism can be securely exchanged. MN PMAG NMAG LMA | | | | | [DETACHED] | | | *---------------------->* 1. dereg-PBU w/ context | * | * | *<----------------------* 2. PBA | * *<----------* 3. Context Reflection | * * * | * [ATTACHED] * | * *---------->| 4. reg-PBU | * *<----------| 5. PBA | |<----------*-----------| 6. Binding Revocation | | | | * Contexts are being stored. Figure 3: Signaling Sequence 1. As soon as PMAG detects detachment of a mobile node, it sends a deregistration Proxy Binding Update to LMA (showin in Figure 4). In that Proxy Binding Update, PMAG stores all the required context of the mobile node as mobility options. It also stores the new MAG address in an IP address option. In this document, we piggyback the context information in the PBU, but we can define a separate message (ex. Context Notification message) for context transfer purpose if needed. Wakikawa, et al. Expires May 21, 2009 [Page 6] Internet-Draft Context Transfer for PMIP November 2008 IPv6 header (src=Proxy-CoA, dst=LMAA) Mobility header - BU /* P & A flags MUST be set to value 1 */ Mobility Options - Mobile Node Identifier option (mandatory) - Home Network Prefix option(s) (mandatory) - Handoff Indicator option (mandatory) - Access Technology Type option (mandatory) - Timestamp option (optional) - Mobile Node Link-layer Identifier option (optional) - Link-local Address option (optional) [NEW MOBILITY OPTIONS for Context Reflection] + IP address option* * option-code is set to 6, see Section 4.3 + Context Data options Figure 4: Proxy Binding Update Message Format 2. LMA verifies the Proxy Binding Update and removes the proxy binding cache for the mobile node. In addition, it caches the contexts of the mobile node for the context reflection. Then, LMA replies a proxy binding acknowledgment to PMAG. 3. After LMA obtains context of the mobile node carried in the proxy binding de-registration message from PMAG, it reflects the contexts to NMAG. In order to notify the contexts to NMAG, a new mobility header message named Context Reflection message is define. When NMAG receives the Context Reflection message as shown in Figure 5, it caches the context until MN attaches to the NMAG. LMA learn the NMAG's IP address from the IP address option carried in the deregistration PBU from PMAG. IPv6 header (src=LMAA, dst=NMAG-Proxy-CoA) Mobility header - Context Reflection Mobility Options - Mobile Node Identifier option (mandatory) - Home Network Prefix option(s) (mandatory) - Handoff Indicator option (mandatory) - Access Technology Type option (mandatory) - Timestamp option (optional) - Mobile Node Link-layer Identifier option (optional) - Link-local Address option (optional) + Context Data options (mandatory) Wakikawa, et al. Expires May 21, 2009 [Page 7] Internet-Draft Context Transfer for PMIP November 2008 Figure 5: Context Reflection Message Format 4. When the mobile node attaches to the NMAG, NMAG sends a proxy binding update as [RFC-5213]. This proxy binding update indicates the completion of the mobile node's handover and let LMA to remove all the cached context for the mobile node. 5. After processing proxy binding registration, LMA MAY send a modified binding revocation message [ID-REVCATION] to PMAG as a notification of handover completion. After this explicit notification, PMAG MAY remove the cached context of the mobile node. Alternatively, PMAG MAY manage the mobile node's context with certain lifetime. We will specifiy the detailed operation of context removal from PMAG in the next revision. Wakikawa, et al. Expires May 21, 2009 [Page 8] Internet-Draft Context Transfer for PMIP November 2008 4. Messages This section defines extensions to the Proxy Mobile IPv6 [RFC-5213] protocol messages. 4.1. Context Reflection Mobility Message The Context Reflection message is used by LMA to notify MN's context to NMAG. It MUST be unicasted and MUST be authenticated by IPsec ESP. This message has the MH Type value TBD. Note that this message can be implemented as a generic notification message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Context Reflection Mobility Message Lifetime 16-bit unsigned integer indicating the lifetime of the mobile node's context. If lifetime is expired, this context will be discarded even during the mobile node's handover. Sequence # 16-bit unsigned integer indicating the sequence number of a proxy binding cache for the mobile node. This value MUST be copied from the corresponding received Proxy Binding Update message. Reserved This 16-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Wakikawa, et al. Expires May 21, 2009 [Page 9] Internet-Draft Context Transfer for PMIP November 2008 Mobility Options This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in section 6.2 of [RFC-3775]. Figure 5 shows the required mobility options in the Context Reflection message 4.2. Context Data Option A new option, Context Data option is defined for use with the Proxy Binding Update message and the Context Reflection message. This option is used for exchanging the mobile node's context data. There can be multiple Context Data options present in the message. The format of the Context Data option is shown below. Based on the size of the data, the option MUST be aligned appropriately, as per mobility option alignment requirements specified in [RFC-3775]. 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 | Feature Profile Type (FPT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Context Data Option Type IANA Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. Feature Profile Type (FPT) Wakikawa, et al. Expires May 21, 2009 [Page 10] Internet-Draft Context Transfer for PMIP November 2008 16-bit integer, assigned by IANA, indicating the type of data included in the Data field, as specified in [RFC-4067]. Data A variable length field containing the data specific to the mobile node's context type-dependent data. 4.3. New option-code for the IP address option New option-code for the IP address mobility option [RFC-5268] is defined to convey the NMAG's IP address from PMAG to LMA. Option-Code 6 MAG Wakikawa, et al. Expires May 21, 2009 [Page 11] Internet-Draft Context Transfer for PMIP November 2008 5. IANA considerations TBA Wakikawa, et al. Expires May 21, 2009 [Page 12] Internet-Draft Context Transfer for PMIP November 2008 6. Security Considerations No security vulnerability is introduced in this specification. All the signaling for context reflection are exchanged between LMA and MAG and are protected by IPsec as [RFC-5213]. Appendix A. References A.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC5213, August 2008. [ID-DSMIP6] Soliman, H., et al, "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05.txt ,July 2007. [RFC-4067] J. Loughney, et al, "Context Transfer Protocol (CXTP)", RFC4067, July 2005. [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC5268, June 2008. [ID-REVOCATION] A. Muhanna, et al, "Binding Revocation for IPv6 Mobility", draft-ietf-mext-binding-revocation-01.txt, August 2008. A.2. Informative References [ID-PFMIP] H. Yokota et.al, "Fast Handovers for PMIPv6", draft-yokota-mipshop-pfmipv6-03.txt, July 2008. Wakikawa, et al. Expires May 21, 2009 [Page 13] Internet-Draft Context Transfer for PMIP November 2008 Authors' Addresses Ryuji Wakikawa Toyota ITC / Keio University 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: ryuji@jp.toyota-itc.com Sawako Kiriyama Graduate School of Science and Technology, Keio University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Email: kiri@tera.ics.keio.ac.jp Jinwei Xia Huawei Technologies Co., Ltd. Huihong Mansion, No.91 Baixia Rd. Nanjing, Jiangsu 21001 China Email: xiajinwei@huawei.com Wakikawa, et al. Expires May 21, 2009 [Page 14] Internet-Draft Context Transfer for PMIP November 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). Wakikawa, et al. Expires May 21, 2009 [Page 15]