Mobile IPv6 Extensions Group F. Zhao Internet-Draft A. Damle Expires: April 27, 2009 Marvell October 24, 2008 Fast Handover for IP Flow Mobility draft-zhao-mipshop-fho-flows-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 Fast Handover for IP Flow Mobility October 2008 Abstract This document discusses and proposes some extensions to reduce handover latency, especially when the mobile node or router handovers IP flows between different access networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Handover Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. The First IP Flow Handover Scenario . . . . . . . . . . . 6 4.2. The Second IP Flow Handover Scenario . . . . . . . . . . . 9 5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 12 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Zhao & Damle Expires April 27, 2009 [Page 2] Internet-Draft Fast Handover for IP Flow Mobility October 2008 1. Introduction As specified in RFC 5268, the Mobile IP Fast Handover protocol [1] aims to reduce handover latency when the mobile node moves from one source access network to one target access network with the Mobile IP protocol used. Recently, the Mobile IPv6 protocol [2] has been extended to allow a mobile node to bind multiple care-of addresses to one home address [3], and furthermore, to bind a particular flow to a care-of address [4]. Such extensions allows a mobile node to direct a specific flow to one of its interfaces and exchange flows with a home agent via different access networks simultaneously, since certain flow may be better suited to the characteristics of a certain access network. Furthermore, the PFMIP protocol [5] is proposed to reduce handover latency when the mobile node handovers with the PMIP used. Such extensions introduce new handover scenarios, for example, a mobile node may handover some flows from one access network to another access network while still keeping other flows on the first access network, by using the same or different mobility protocols. Handover latency for a specific flow in such scenarios is expected to be not different from that of Mobile IPv6. In order to reduce handover latency in such new handover scenarios, we discuss and propose some extensions in this document. 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 [6]. Throughout this document, we adopt mobility related terminology used in RFC 3775 [2], RFC 5268 [1], [5], [3] and [4]. Zhao & Damle Expires April 27, 2009 [Page 3] Internet-Draft Fast Handover for IP Flow Mobility October 2008 3. Handover Scenarios The Mobile IPv6 Fast Handover protocol focuses on the scenario where the mobile node moves all its flows from one access router to another access router. With the extensions of multiple CoAs and flow bindings, new handover scenarios become possible. +------+ +------+ | HA | HoA | HA | HoA +------+ +------+ /\ /\ flow1 / \ ==> flow1 / \ flow2 + flow2 / \ / \ / \ / \ +-----+ +-----+ +-----+ +-----+ | AR1 | | AR2 | | AR1 | | AR2 | +-----+ +-----+ +-----+ +-----+ ~ ~ ~ ~ +----+ ~ +----+ ~ IF1 ~ =| MN |= IF2 IF1 ~ =| MN |= ~ ~ IF2 CoA1 +----+ CoA1 +----+ CoA2 Figure 1: The first IP flow handover scenario As shown in Figure 1, a mobile node previously exchanges both the flow 1 and the flow 2 with the home agent via the access network 1; and later when it discovers the access network 2, the mobile node decides to move the flow 2 from the access network 1 to the access network 2 and still keeps the flow 1 on the access network 1. An example of such mobile node could be a cell phone equipped with both a cellular radio and a Wifi interface. In this case, the mobile node uses the MIP on both access networks. Zhao & Damle Expires April 27, 2009 [Page 4] Internet-Draft Fast Handover for IP Flow Mobility October 2008 +------+ +------+ | HA | HoA/HNP | HA | HoA/HNP +------+ +------+ /\ /\ flow1 / \ ==> flow1 / \ flow2 + flow2 / \ / \ / \ / \ +----+ +-----+ +----+ +-----+ | AR | | MAG | | AR | | MAG | +----+ +-----+ +----+ +-----+ ~ ~ ~ ~ +----+ ~ +----+ ~ IF1 ~ =| MN |= IF2 IF1 ~ =| MN |= ~ IF2 CoA +----+ CoA +----+ Figure 2: The second IP flow handover scenario As shown in Figure 2, a mobile node previously exchanges both the flow 1 and the flow 2 with the home agent via the access network 1 by using the MIP protocol; and later when it discovers the access network 2 and chooses to use the PMIP there, the mobile node decides to move the flow 2 from the access network 1 to the access network 2 and still keeps the flow 1 on the access network 1. A similar scenario is also discussed in [7]. Zhao & Damle Expires April 27, 2009 [Page 5] Internet-Draft Fast Handover for IP Flow Mobility October 2008 4. Discussion As stated in RFC 5268, the Mobile IPv6 Fast Handover protocol aims to addresses the following problems: "how to allow a mobile node to send packets as soon as it detects a new subnet link and how to deliver packets to a mobile node as soon as its attachment is detected by the new access router." In the context of IP flow mobility, the problem to be addressed is slightly different: how to allow a mobile node to send uplink packets via a better access link as soon as it detects such a new access link and how to deliver downlink packets to a mobile node via a better access link as soon as its attachment to such a new access link is detected by the new access router. By fulfilling such goals, not only can handover latency be largely improved, but also applications running on the mobile node can take full advantage of what underlying access networks can offer, and therefore, to improve overall performance. The handover scenarios as described in Figure 1 and Figure 2 are similar to the typical scenario in the Mobile IPv6 Fast Handover protocol, in the sense that certain flows are moved from the source access network(s) to the target access networks. Therefore, the motivation to optimize the Mobile IP operation to reduce handover delay remains the same. 4.1. The First IP Flow Handover Scenario To support IP flow mobility as shown in Figure 1, most messages defined in the Mobile IPv6 Fast Handover protocol do not need to be changed, such as the RtSolPr message, the PrRtAdv message, the UNA message, the HI message and the HAck message. The most notable differences are for the FBU message and FBA message. This is because the mobile node needs to provide the flow information to the NAR and receive the response from the NAR. In the following, we focus our discussion on the predictive mode in the handover scenario shown in Figure 1. In this scenario, the mobile node needs to tell the AR1 (i.e. the NAR) that the flow 1 needs to be forwarded to the CoA1 (i.e. the PCoA) and the flow 2 needs to be forwarded to the CoA2 (i.e. the NCoA). The BID mobility option [3] and the FID mobility option [4] can be used to carry such information in the FBU and FBA to bind the flow 1 to CoA1 and the flow 2 to CoA2 at the AR1 while the Mobile IPv6 Fast Handover protocol currently only supports binding the CoA2 with the CoA1. In other words, it seems that the mobile node registers two flow bindings at the AR1 to direct two different flows to the interface connecting to both a "home link" (the access network 1 is a "home link" for the CoA1) and a "foreign link" (the access network 2 is a "foreign link" for the CoA1) simultaneously. The case can be handled by the Multiple CoA draft where a 'H" bit is set in the BID option together with an empty Zhao & Damle Expires April 27, 2009 [Page 6] Internet-Draft Fast Handover for IP Flow Mobility October 2008 care-of address field to indicate the simultaneous use of both the home link and the foreign link. Furthermore, for a specific scenario as shown in the Figure 1, it may look plausible that in the FBU message the mobile node only specify the flow 2 together with the CoA2 in the Alt-CoA option. However, the mobile node needs to also specify either a default flow binding or a flow binding for the CoA1; otherwise, the AR1 does not know where to forward the flow 1. Another possible way is that the mobile node sends two separate FBU messages to the AR1; however, it results in more packet overheads and potential packet loss, for example, when the AR1 does not receive or process these two messages all together, and therefore one flow filter is installed long before another. However, during fast handover, the prospective new CoA formulated by the mobile node may not be valid at the NAR, therefore a new NCoA needs to be provided in the FBA. Currently, there is no corresponding status code defined in the multiple CoA draft (this is because the multiple CoA draft is addressing a different issue). Furthermore, with the solution for the point-to-point link mode proposed in [8], the PAR and the NAR create states (i.e. allocating a dedicated prefix) by exchanging the HI/HAck after the MN sends the RtSolPr message and before sending the FBU message. In this document, we propose that the mobile node provides information for the stateless NCoA configuration in the FBU to the NAR, without knowing the dedicated prefix valid at the NAR at first. Then the PAR is informed about the dedicated prefix from the NAR when receiving a HAck message as a response to the HI message exchange. Then, the PAR returns such information to the MN by sending a FAck to the MN's interface connecting to the PAR link. Finally, the MN configures such IP address on the interface connecting to the NAR link. The Mobile IPv6 Fast Handover protocol defines a LLA mobility option; however, the BID option is not defined to carry such information for stateless IP address configuration at the NAR link (In fact, the LLA option used in such draft is for packet forwarding on the home link). Therefore, we propose to extend the BID option to include the LLA address inside. The predictive fast handover procedure for the first scenario is shown as follows in Figure 3. Zhao & Damle Expires April 27, 2009 [Page 7] Internet-Draft Fast Handover for IP Flow Mobility October 2008 MN AR1(PAR) AR2(NAR) | | | 1) |------RtSolPr------->| | 2) |<-----PrRtAdv--------| | 3) |------FBU(IF1)------>| | 4) | |----------HI--------->| 5) | |<--------HAck---------| 6) |<------FBack(IF1)----|---FBack--> | | | | 7) | forward | |<================= packets ================>| | | | 8) connect | | | | | 9) |------------UNA(IF2)----------------------->| 10) |<=================================== deliver packets | | Figure 3: 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. 2) The MN may receive the PrRtAdv message either as a response or as an unsolicited message sent by the AR1. The MN chooses to perform handover and maintain session continuity by using the MIP on the new access network. And it may configure a CoA2 (i.e. NCoA). 3) The MN sends a FBU message to the AR1 (i.e. the PAR) to bind the flow 1 to the CoA1 and bind the flow 2 to the CoA2. If the MN knows the AR2 link is a point-to-point link, it provides the information for stateless IP configuration in the BID and binds the flow 2 to such BID even though it does not know about the dedicated prefix valid at the AR2 link yet. 4) The AR1 sends a HI message to the AR2 based on the Mobile IPv6 Fast Handover protocol. It may request a dedicated prefix if the AR1 receives a BID containing only the information for stateless IP configuration instead of an IP address. 5) The AR2 returns a HAck message. It may also include a dedicated prefix if requested. Zhao & Damle Expires April 27, 2009 [Page 8] Internet-Draft Fast Handover for IP Flow Mobility October 2008 6) The AR1 sends a FBack message back to the MN (i.e. the IF1) once it receives the HAck message. Based on the dedicated prefix, if included, the AR1 then updates the IP address (i.e. the NCoA) for the MN. 7) The AR1 forwards the corresponding packets in different flows to the MN and the AR2 accordingly. 8) The IF2 on the MN connects to the AR2 link. 9) The MN may send a UNA message to the AR2. 10) The AR2 delivers buffered packets to the MN. 4.2. The Second IP Flow Handover Scenario The reference [7] discusses the case when the MN uses different mobility protocols on different access networks, and proposes some extensions to allow the MN to tell the access router to forward traffic through a tunnel established through the PFMIP protocol. Similar extensions are also needed in the scenario illustrated in Figure 2 except that in order to support IP flow mobility, such indication needs to be provided in the BID option. Zhao & Damle Expires April 27, 2009 [Page 9] Internet-Draft Fast Handover for IP Flow Mobility October 2008 5. Extensions The following status code (TBD less than 128) is defined to be carried in the status field of the FBA message: FBU accepted but NCoA is invalid. Use NCoA supplied in the BID. The following status code (TBD less than 128) is defined to be carried in the status field of the BID option: COA INVALID: Use CoA supplied in the BID instead. 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding ID (BID) | Status |O|H|L|F|Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + : Different type of data when different flag is set : + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Extension to the BID option L (1 bit) This bit MUST be set to 1 when a LLA is provided in the option. Note that the L bit and the F bit cannot be set as 1 at the same time. F (1 bit) This bit MUST be set to 1 when a forwarding IP address is provided in the option. Note that the L bit and the F bit cannot be set as 1 at the same time. Data The LLA: The variable length link-layer address, used together with the dedicated prefix allocated for the MN at the NAR link by the NAR to generate a NCoA for flow binding. 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 Zhao & Damle Expires April 27, 2009 [Page 10] Internet-Draft Fast Handover for IP Flow Mobility October 2008 Length field. The format of such field is illustrated in Figure 5. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + : forwarding IP Address : + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The Data field for a forwarding IP address Zhao & Damle Expires April 27, 2009 [Page 11] Internet-Draft Fast Handover for IP Flow Mobility 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, [5], [3] and [4]. 7. IANA Consideration TBD. 8. Conclusions In this document, we discuss and propose extensions to improve latency during IP flow handover. 9. References 9.1. Normative References [1] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-09 (work in progress), August 2008. [4] 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. [5] 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. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [7] Zhao, F., "Interworking between FMIP and PFMIP", draft-zhao-mipshop-fmip-pfmip-00 (work in progress), October 2008. [8] Xia, F. and B. Sarikaya, "Prefix Management for Mobile IPv6 Zhao & Damle Expires April 27, 2009 [Page 12] Internet-Draft Fast Handover for IP Flow Mobility October 2008 Fast Handover on Point-to-Point Links", draft-xia-mipshop-fmip-ptp-02 (work in progress), February 2008. [9] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [10] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [11] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [12] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 9.2. Informative References [13] 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 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 Fast Handover for IP Flow Mobility 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]