Mipshop Working Group Youngsong Mun Internet-Draft Kyunghye Lee Expires: June, 2007 Soongsil University Jaehoon Nah Seungwon Sohn ETRI December, 2006 Fast Handovers for Macro Mobility in HMIPv6 draft-mun-mipshop-fhmacro-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 January 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In Hierarchical Mobile IPv6 (HMIPv6), the long handover latency and packet loss problems take place when a mobile node moves between access routers belonging to different Mobility Anchor Point (MAP) domain, called a macro mobility handover. To improve performance of the macro mobility handover, this document describes a method to execute macro mobility handover rapidly and to reduce both the Y. Mun, et al. Expires June, 2007 [Page 1] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 handover latency and packet loss. The method described in this document is fast handovers for macro mobility handover by applying fast handover method of FMIPv6 protocol to the edge access routers in MAP domain. The two modes of fast handover are used according to the situation of the mobile node. Table of Contents 1. Introduction.....................................................3 2. Terminology......................................................4 3. Fast handover for Macro Mobility ................................6 3.1 Overview.....................................................6 3.1 Operation of the Predictive Macro Mobility Mode..............7 3.2 Operation of the Reactive Macro Mobility Mode................8 4. Security Considerations..........................................9 5. References......................................................10 6. Authors' Addresses..............................................10 Y. Mun, et al. Expires June, 2007 [Page 2] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 1. Introduction Increasingly, the wireless access services are important since plenty of wireless access devices has released widely. According to the tendency of the many customers, more rapid and stable access services will be more important to provide wireless access services to the Internet. Mobile IPv6 (MIPv6) has been proposed to support mobility in IPv6 network. In spite of the fact that MIPv6 provides the layer 3 connectivity to the IPv6 mobile node, MIPv6 causes two critical problems; the long handover latency and packet loss. To make up for the problems, the fast handovers for mobile IPv6 (FMIPv6) protocol and the hierarchical mobile IPv6 (HMIPv6) protocol have proposed. To reduce the handover latency and the packet loss, FMIPv6 protocol provides the fast handover schemes between the access routers in order to support seamless network access services to the mobile nodes in IPv6 network. FMIPv6 provides two modes of operation in accordance with the situation of the mobile node. One is a predictive mode. Another is a reactive mode. These two mode provides more robust fast handover to the mobile node which moves between access routers. HMIPv6 protocol uses a new entity called a Mobility Anchor Point. HMIPv6 manages the movement of the mobile nodes by suing the MAP. In HMIPv6 network, a mobile node has to generate two care-of addresses; a regional care-of address (RCoA) and an on-link care-of address (LCoA). A RCoA is created based on the prefix of the MAP domain and a LCoA is created based on the prefix of the attached access router. When a mobile node moves between access routers belonging to the same MAP domain, it is called a micro mobility handover. To improve performance of the micro mobility handover, there is a method applied the fast handover technique of FMIPv6 to the access routers. If a mobile node moves from one access router to another belonging to different MAP domain, it is called a macro mobility handover. When a mobile node performs a macro mobility handover, this means that a mobile node moves into a new MAP domain. The mobile node must create two care-of addresses. Obviously, a new RCoA generation is the same that a mobile node changes CoA in MIPv6. Thus, change of RCoA has the same problems which occur in MIPv6. Although the macro mobility handover causes the same long handover latency and packet loss problems as the micro mobility handover, there is no efficient method to sovle the problems. Therefore, a new method to execute the macro mobility handover rapidly and to reduce both the long handover latency and the packet loss is needed. This document describes the fast handovers for the macro mobility handover in HMIPv6 in order to perform efficiently the handover and to reduce both the handover latency and the packet loss. The fast Y. Mun, et al. Expires June, 2007 [Page 3] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 handovers for macro mobility handover have two modes according to the situation of the mobile node, as the two modes of FMIPv6. 2. Terminology Most of terminologies used in this draft are defined in MIPv6 [1], FMIPv6 [2], and HMIPv6 [3]. Home Agent (HA) A router a mobile node's home link. HA manages the bindings between the home address and the care-of address of the mobile node. Correspondent Node (CN) A node that a mobile node is communicating with. Mobile Node (MN) An Mobile IPv6 node. New Access Router (nAR) The new access router predicted that a mobile node moves into. Previous Access Router (pAR) The default access router which a mobile node is attached before the macro mobility handover. New Mobility Anchor Point (nMAP) The new Mobility Anchor Point which the nAR belongs to. Previous Mobility Anchor Point (pMAP) The Mobility Anchor Point that a mobile node is attached before the macro mobility hanover. Router Solicitation for Proxy Advertisement (RtSolPr) A message used by the mobile node in order to obtain Proxy Router Advertisement message swiftly from access routers. Proxy Router Advertisement (PrRtAdv) A message used by the access routers to advertise the information about the network. Specifically, when the edge access routers sends a PrRtAdv message, it should contain the information of the MAP domain, such as prefixes. New Regional Care-of Address (nRCoA) An IPv6 address created by the mobile node based on the prefix of the nMAP in accordance with PrRtAdv message received from pAR at the previous link. Y. Mun, et al. Expires June, 2007 [Page 4] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 New on-link Care-of Address (nLCoA) An IPv6 address generated by the mobile node based on the prefix of the nAR according to PrRtAdv message received from pAR at the previous link. Fast Binding Update (FBU) A message used by the mobile node to request fast handover to the pAR. In this document, a mobile node should contain the nRCoA in FBU message together with nLCoA. Fast Binding Acknowledgement (FBAck) A message used by access routers to inform that the preparation of the fast handover is completed and both the nRCoA and the nLCoA are available to use in response to the FBU message. Handover Initiate (HI) A message used by access routers in order to establish a tunnel between two edge access routers and to check that the two care-of address are unique in new link. Handover Acknowledge (HAck) A message in respose to the HI in order to the result of the two care-of address check and the tunnel establishment. Fast Neigbhor Advertisement (FNA) A message used by the mobile node. When a mobile node moves into the new MAP domian, it should send this message to the nAR in order to inform the existence of itself and receive the packets transmitted to the nAR during the handover. Neighbor Advertisement Acknowledgment (NAACK) option An option included in the FNA message to notify that the new address is duplicated or not in the new link. Local Binding Update (LBU) A message sent by the mobile node to the MAP in order to register the nRCoA and the nLCoA. The MAP then binds the two care-of address. Local Binding Acknowledgement (LBA) A message sent by the MAP to the mobile node to inform the result of the two addresses binding. Y. Mun, et al. Expires June, 2007 [Page 5] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 3. Fast handovers for Macro Mobility in HMIPv6 3.1. Overview In HMIPv6, a macro mobility handover is that a mobile node moves from the pAR in the pMAR domain to the nAR in the nMAP domain. The fast handovers for macro mobility handover have two modes of operation. One is a predictive macro mobility handover mode. This operation is performed when a mobile node has engouh time to exchanges message for the fast handover. In the predictive macro mobility handover mode, the handover occurs immediately after the mobile node receive the FBAck message from the pAR in the pMAP domain. Another mode is a reactive macro mobility handover. This operation is performed when a mobile node does not receive the FBAck message before the handover. In this case, the mobile node moves fast before the completion of the preparation of the fast handover. For this situation, the packets transmitted during the handover are forwarded through the nAR to the mobile node as soon as sending FNA message. Thus, the reactive mode minimize the packet loss due to the incompletion of the preparation of the fast handover. For the fast handovers for Macro mobility, the reference scenario is shown as Figure.1. +-------+ | HA | +----+ +-------+ | CN | | +----+ | | +----+----------------+--+ |pRCoA |nRCoA +--------+ +--------+ | pMAP | | nMAP | +--------+ +--------+ | | | | | | | | | | | | +-----+ +-----+ +-----+ | AR | | pAR | | nAR | +-----+ +-----+ +-----+ pLCoA nLCoA +----+ | MN | +----+ ------------> Movement Figure 1 : Reference scenerio for the macro mobiity handover Y. Mun, et al. Expires June, 2007 [Page 6] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 3.2. Operation of the Predictive Macro Mobility Mode A mobile node receives PrRtAdv messages periodically from the attached access router. The mobile node also can request the PrRtAdv message by sending a RtSolPr message in order to obtain the network information immediately. If the received PrRtAdv message includes information about the both the new access router and the new MAP domain, the mobile node would anticipate the occurence of the macro mobility handover. The mobile node creates both an nLCoA based on the prefix of the nAR and an nRCoA based on the prefix of the nMAP included in PrRtAdv message. The mobile node then sends a FBU message to the pAR. The pAR received FBU message from the mobile node sends a HI message to the nAR which the mobile node expects to move into. The nAR must perform a Duplicate Address Detection (DAD) defined in [1] for the nLCoA requested by the mobile node. Simutaneously, the nAR also sends a HI message to the nMAP in order to request the DAD test for the nRCoA asked by the mobile node. In reply to the HI message, the nAR sends a HAck message to the pAR at the same time. If the nRCoA is duplicated in the nMAP domain, the nMAP informs the result to the nAR and nAR sends a FNA message together with an NAACK option to the mobile node in order to inform that the nRCoA is not available in the nMAP domain so that it must create a new RCoA. Thus, the nAR does not need to wait for the HAck message from the nMAP. Through the exchange of the HI and HAck message between the nAR and the pAR, a tunnel is established between the nAR and the pAR for forwarding packets destined to the mobile node during the layer 2 handover. The pAR received the HAck message from the nAR sends FBAck message to both the nAR and the mobile node simutaneously. As soon as the nAR and the mobile node receive the FBAck messages, the layer 2 handover occurs. During the handover, the packets destined to the mobile node are forwarded from the pAR to the nAR, and stored in the nAR for a while. Therefore, the packet loss can be reduced in macro mobility handover. After the handover, the mobile node should send a FNA message to the nAR in order to receive the packets forwarded during the handover. After the FNA message, the mobile node can use the nLCoA. Thus, the handover latency can be reduced. Finally, the mobile node should perform the local registration by using LBU and LBA messages with the nMAP. After completion of the local registration, the mobile node must sending BU message to the its HA in order to bind the its home address with the nRCoA as the CoA. Figure 2 represent the procedure of the predictive macro mobility mode. Y. Mun, et al. Expires June, 2007 [Page 7] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 MN pAR pMAP nAR nMAP HA | | | | | | |--RtSolPR-->| | | | | |<--PrRtAdv--| | | | | |----FBU---->| | | | | | |-----------HI----------->| | | | | | nLCoA DAD+----HI----->| | | |<----------HAck----------| +nRCoA DAD | | | | |<---HAck----| | | <--FBAck--|-------FBAck--------> | | | disconnect | | | | | | |===Packet forwarding====>| | | connect | | | | | |---------------FNA------------------->| | | |<========Packet forwarding============| | | |<---------FNA with NAACCK-------------| | | |-----------------------LBU------------------------>| | |<----------------------LBA-------------------------| | |-------------------------------BU------------------------------>| |<------------------------------BA-------------------------------| | | | | | | Figure 2 : Predictive Macro Mobility Mode 3.3. Operation of the Reactive Macro Mobility Mode The reactive macro mobility mode is analogous to the reactive mode of FMIPv6. A mobile node performs the reactive mode of operation in order to solve the various erroneous situations. Similarly, the fast macro mobility handover is needed to solve the various erroneous cases. The reactive macro mobility mode would be the solution to improve the fast handover operation. In the reactive macro mobility mode, if the mobile node carries out the layer 2 handover before performing the fast binding operation, which the mobile node does not send or receive the FBU or FBAck messages, the mobile node would convert the fast handover operation into the reactive macro mobility mode. The mobile node receives PrRtAdv messages periodically or requests the messages by sending RtSolPr messages, as mentioned section 3.2. Due to the mobile node's rapid movement from the previous link to the new one or the erroneous situation, the mobile node could not send or receive the FBU message or FBAck message prior to the layer 2 handover. In this case, the macro mobility handover is the reactive macro mobility handover. After the layer 2 handover, the mobile node should firstly generate a special FNA message. This FNA message is Y. Mun, et al. Expires June, 2007 [Page 8] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 defined in [2]. The mobile node sends the FNA message together with the FBU message to the nAR. The nAR received the FNA message included the FBU message should perform the DAD operation for the addresses of the mobile node. At the same time, the nAR sends FBU message to the pAR of the mobile node. The pAR sends a FBAck message in reply to the FBU message and then forwards the packets of the mobile node to the nAR. Therefore, the mobile node can receive the packets transferred to the pAR from the nAR without packet loss. Finally, the mobile node also should perform both the local binding operation by using LBU and LBA messages and the home bidning operation by using BU and BA messages with its HA. The procedure of the reactive macro mobility mode is shown as Figure 3. MN pAR pMAP nAR nMAP HA | | | | | | |--RtSolPR-->| | | | | |<--PrRtAdv--| | | | | disconnect | | | | | | | | | | | connect | | | | | |-------------FNA[FBU]---------------->| | | | | | +nLCoA DAD | | | |<---------FBU------------| | | | |----------FBAck----------| | | | |====Packet forwarding===>| | | |<=========Packet forwarding===========| | | |-----------------------LBU------------------------>| | |<----------------------LBA-------------------------| | |-------------------------------BU------------------------------>| |<------------------------------BA-------------------------------| | | | | | | Figure 3 : Reactive Macro Mobility Mode 4. Security Considerations This document describes the fast handovers for the macro mobility handover in HMIPv6 environment. The two handover modes represented in this document assumes that the edge access routers within a MAP domain have association with adjacent edge access routers in other MAP domains. Due to this assumption, the association between each MAP domain considers possible security theats caused by communicating between two edge routers belongs to different MAP domains. Also, this fast handover methods have the security consideration of [1], [2], and [3]. Y. Mun, et al. Expires June, 2007 [Page 9] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 5. References [1] D. Johnson, C. E. Perkins, and J. Arkko, "Mobility Support in IPv6", Request for Comments (Proposed Standard) 3775, Internet Engineering Task Force, June 2004. [2] R. Koodli, (editor), "Fast Handovers for Mobile IPv6", Request for Comments (Experimental) 4068, Internet Engineering Task Force, July 2005. [3] H. Soliman, C. Catelluccia, K. Malki, L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Request for Comments (Experimental) 4140, Internet Engineering Task Force, August 2005. [4] T. Narten, E. Nordmark, and W. Simpson, "Neigbhor Discovery for IP Version 6 (IPv6)", Request for Comments 2461, Internet Engineering Task Force, December 1998. [5] D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", Request for Comments 4389, Internet Engineering Task Force, April 2006. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6. Authors' Addresses Youngsong Mun, Professor Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-820-0676 Fax: +82-2-822-2236 E-mail: mun@computing.ssu.ac.kr Kyunghye Lee Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-812-0689 Fax: +82-2-822-2236 E-mail: lkhmymi@sunny.ssu.ac.kr Y. Mun, et al. Expires June, 2007 [Page10] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006 Intellectual Property Statement 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 IETF's procedures with respect to rights in IETF 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Y. Mun, et al. Expires June, 2007 [Page11]