MIPSHOP Group F. Zhao Internet-Draft A. Damle Expires: April 27, 2009 Marvell October 24, 2008 Interworking between FMIP and PFMIP draft-zhao-mipshop-fmip-pfmip-00 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 April 27, 2009. Zhao & Damle Expires April 27, 2009 [Page 1] Internet-Draft Interworking between FMIP and PFMIP October 2008 Abstract This document discusses and proposes extensions to enable interworking between the FMIP and the PFMIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Handover Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. The First Scenario . . . . . . . . . . . . . . . . . . . . 6 4.1.1. The Predictive Mode . . . . . . . . . . . . . . . . . 6 4.1.2. The Reactive Mode . . . . . . . . . . . . . . . . . . 7 4.2. The Second Scenario . . . . . . . . . . . . . . . . . . . 7 4.2.1. The Predictive Mode . . . . . . . . . . . . . . . . . 7 4.2.2. The Reactive Mode . . . . . . . . . . . . . . . . . . 8 5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 11 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Zhao & Damle Expires April 27, 2009 [Page 2] Internet-Draft Interworking between FMIP and PFMIP October 2008 1. Introduction As specified in RFC 5268, the FMIP protocol [1] aims to reduce handover latency when the MIP is used as the mobility management protocol. Recently, the PFMIP protocol [2] has been proposed to reduce handover latency when the PMIP is used. It is expected that both PMIP and MIP will be deployed in networks; however, how to reduce handover latency when the MN uses different mobility protocols during handover has not addressed. In this document, we discuss and propose some extensions to address this issue. 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 [3]. Throughout this document, we adopt mobility related terminology used in RFC 3775 [4], RFC 5231 [5], RFC 5268 [1], and [2]. Zhao & Damle Expires April 27, 2009 [Page 3] Internet-Draft Interworking between FMIP and PFMIP October 2008 3. Handover Scenarios A MN may support both the MIP and the PMIP. There are the following two different handover scenarios. +------+ +------+ | HA | HoA/HNP | HA | HoA/HNP +------+ +------+ /\ /\ / \ ==> / \ / \ / \ / \ / \ +----+ +-----+ +----+ +-----+ | AR | | MAG | | AR | | MAG | +----+ +-----+ +----+ +-----+ ~ ~ ~ +----+ +----+ ~ ~ =| MN |= =| MN |= ~ ~ CoA +----+ +----+ Figure 1: The first handover scenario As shown in Figure 1, before handover, a MN connects to the access network 1 where it gains IP connectivity by using MIP. When the MN detects the access network 2 and decides to perform handover, the MN may choose to use the PMIP on the access network 2, for example, due to its configuration, preference or policy. In order to reduce handover latency, the MN starts the FMIP procedure on the access network 1 and provides the indication of using the PMIP on the access network 2, the access router in the access network 1 starts the PFMIP procedure with the MAG2 located in the access network 2. Note that it is possible that the access router in the access network 1 has the MAG functionality. Zhao & Damle Expires April 27, 2009 [Page 4] Internet-Draft Interworking between FMIP and PFMIP October 2008 +------+ +------+ | HA | HoA/HNP | HA | HoA/HNP +------+ +------+ /\ /\ / \ ==> / \ / \ / \ / \ / \ +-----+ +----+ +-----+ +----+ | MAG | | AR | | MAG | | AR | +-----+ +----+ +-----+ +----+ ~ ~ ~ +----+ +----+ ~ ~ =| MN |= =| MN |= ~ ~ +----+ +----+ CoA Figure 2: The second handover scenario As shown in Figure 2, before handover, a MN connects to the access network 1 where it gains IP connectivity by using PMIP. When the MN detects the access network 2 and decides to perform handover, the MN may choose to use the MIP on the access network 2, for example, due to its configuration, preference or policy. In order to reduce handover latency, with some indication, the MAG on the access network 1 starts the FMIP procedure. Note that a general discussion on the interaction between MIP and PMIP is provided in [13]. Zhao & Damle Expires April 27, 2009 [Page 5] Internet-Draft Interworking between FMIP and PFMIP October 2008 4. Proposals 4.1. The First Scenario 4.1.1. The Predictive Mode MN AR(PAR) MAG(NAR) | | | 1) |------RtSolPr------->| | 2) |<-----PrRtAdv--------| | 3) |------FBU----------->| | 4) | |----------HI--------->| 5) | |<--------HAck---------| 6) | <--FBack---|---FBack--> | 7) | ...... | Figure 3: The predictive fast handover procedure for the first scenario The Figure 3 shows the predictive fast handover procedure for the first scenario. 1) When the MN detects available new access network by using some link layer specific mechanisms, it may request more information by sending a RtSolPr message. Note that this message may be skipped if the MN knows about this new access network based on the AP-ID. 2) The MN may receive the PrRtAdv message either as a response or as an unsolicited message sent by the AR. The MN chooses to perform handover and maintain session continuity by using the PMIP on the new access network. How the MN selects the mobility protocol is not specified in this document. For example, the MN may be pre-configured with the information regarding the AP-ID, including if the PMIP should be used on such access network, or the PrRtAdv message provides such indication to the MN. 3) The MN sends a FBU message to the AR (i.e. the PAR) to register a binding between its home address and the current PCoA (the home address from the perspective of the AR). In addition, the MN indicates that the AR should perform the PFMIP with the MAG (i.e. NAR) in the access network 2. The information provided by the MN in this message includes the MN_ID, MN-HoA, MN IID, the HA address etc. Therefore, data packets sent to the MN through the HA, i.e. HA->CoA || CN->HoA, will be encapsulated by the AR firstly, i.e., AR->HoA || HA->CoA|| CN->HoA, and then forwarded through the tunnel between the AR and the MAG. Zhao & Damle Expires April 27, 2009 [Page 6] Internet-Draft Interworking between FMIP and PFMIP October 2008 4) The AR sends a HI message to the MAG based on the PFMIP protocol. 5) The MAG replies with a HAck message based on the PFMIP protocol. 6) The AR may send a FBack message once it receives the HAck message. 7) The rest of the procedure is the same as described in the PFMIP protocol. Note that when the AR sends the HI message to indicate that the packet forwarding is completed, the AR also deletes the binding between the CoA (i.e. the PCoA) and the HoA. The MN may send the FBU through the access network 2 to trigger such actions at the AR, for example after a configurable length of time. 4.1.2. The Reactive Mode The procedure in the reactive mode for the first handover scenario is similar to that described in the PFMIP protocol. 4.2. The Second Scenario 4.2.1. The Predictive Mode MN MAG(PAR) AR(NAR) | | | 1) |-Report/HO Initiate->| | 2) | |----------HI--------->| 3) | |<--------HAck---------| 4) | <-HO Response-|-HO Response-> | 5) | ...... | Figure 4: The predictive fast handover procedure for the second scenario The Figure 4 shows the predictive fast handover procedure for the second scenario. 1) When the MN detects available new access network by using some link layer specific mechanisms, it may decide to perform handover. Besides what is described in the PFMIP protocol, the MN may provide the indication of using the MIP on the target access network. How the MN make such decision is not specified in this document. Furthermore, additional information may be provided to the MAG to trigger the FMIP protocol in a link specific way or in one or more appropriate signaling messages. A binding between the Zhao & Damle Expires April 27, 2009 [Page 7] Internet-Draft Interworking between FMIP and PFMIP October 2008 HoA and the NCoA can be considered being created at the MAG. 2) The MAG sends the HI message to the AR as specified in the FMIP protocol. 3) The AR replies with a HAck message as specified in the FMIP protocol. 4) The MAG provides some notification to the MN in a similar way to the FBack message. Such notification may be provided in a link specific way or in one or more appropriate signaling messages. 5) The rest of the procedure is similar to what is specified in the FMIP protocol. 4.2.2. The Reactive Mode The procedure in the reactive mode for the first handover scenario is similar to that described in the FMIP protocol. Zhao & Damle Expires April 27, 2009 [Page 8] Internet-Draft Interworking between FMIP and PFMIP October 2008 5. Extensions The PFMIP protocol has described some options for both ICMP messages and the Mobility Headers. Such options can be used in the FBU message. However, it is not clear how the MN indicates to the AR that certain packets need to be forwarded through a tunnel established between the AR and the (new) MAG. In the following, we show the format of a forwarding IP address mobility option that can be used in either the FBU message or the FBA message. When such option is present, the Alt-CoA option MUST not be used. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Prefix Length |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + forwarding IP Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Forwarding IP Address option P (1 bit) This bit MUST be set to 1 when the MN requests the traffic destined at this forwarding IP address must be forwarded through a tunnel set up by the PFMIP protocol. The Forwarding IP address One IPv6 or one IPv4 address used for packet forwarding. It can be the home address of the MN. The type of the address in this field can be determined by the Length field. Status The status of such request. Zhao & Damle Expires April 27, 2009 [Page 9] Internet-Draft Interworking between FMIP and PFMIP October 2008 Prefix Length The length of the included forwarding IP address. Such prefix information may be needed in the HI/HAck messages for the target MAG to know the prefix length. One new status code is defined for the FBA message. 132: The Alt-CoA option is missing the received FBU message. This can be used for the MN to detect that the AR does not support the forwarding IP address option since normally with the FMIP protocol, the Alt-CoA option must be included in the FBU message if sent from the PAR link, and with the extension described in this document, the forwarding IP address option replaces the Alt-CoA option. Zhao & Damle Expires April 27, 2009 [Page 10] Internet-Draft Interworking between FMIP and PFMIP October 2008 6. Security Consideration The extensions described in this document do not introduce any new vulnerability. The security related issues are discussed in the "Security Considerations" section of RFC 5268, and [2]. 7. IANA Consideration TBD. 8. Conclusions In this document, we discuss and propose extensions to enable the interworking of the FMIP protocol and the PFMIP protocol. 9. References 9.1. Normative References [1] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. [2] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for PMIPv6", draft-yokota-mipshop-pfmipv6-03 (work in progress), July 2008. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [6] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [7] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [8] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Zhao & Damle Expires April 27, 2009 [Page 11] Internet-Draft Interworking between FMIP and PFMIP October 2008 [9] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [10] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-09 (work in progress), August 2008. [11] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-00 (work in progress), May 2008. [12] Xia, F. and B. Sarikaya, "Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links", draft-xia-mipshop-fmip-ptp-02 (work in progress), February 2008. 9.2. Informative References [13] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. [14] Lim, B., Ng, C., Aso, K., and S. Krishnan, "Verification of Care-of Addresses in Multiple Bindings Registration", draft-lim-mext-multiple-coa-verify-02 (work in progress), July 2008. Authors' Addresses Fan Zhao Marvell Semiconductor, Inc. 5488 Marvell Lane Santa Clara, CA 95054 US Email: fanzhao@marvell.com Zhao & Damle Expires April 27, 2009 [Page 12] Internet-Draft Interworking between FMIP and PFMIP October 2008 Ameya Damle Marvell Semiconductor, Inc. 5488 Marvell Lane Santa Clara, CA 95054 US Email: adamle@marvell.com Zhao & Damle Expires April 27, 2009 [Page 13] Internet-Draft Interworking between FMIP and PFMIP October 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. Zhao & Damle Expires April 27, 2009 [Page 14]