Mipshop Working Group Youngsong Mun Internet-Draft Kyunghye Lee Expires: August, 2009 Soongsil University February, 2009 Fast Macro Mobility Handovers in HMIPv6 draft-mun-mipshop-fhmacro-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 17, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from one MAP domain to another can experience both long handover latency and packet loss due to the distance between the two MAPs. To solve the problems, this document describes two fast handover schemes that Y. Mun, et al. Expires August, 2009 [Page 1] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 support fast macro mobility handover. These fast handover schemes can reduce both the handover latency and the pakcet loss. The schemes described in this document adopt the fast handover of FMIPv6 protocol to the edge access routers in MAP domains. The schemes support two fast handover modes for macro mobility handover in HMIPv6. Table of Contents 1. Introduction.....................................................3 2. Terminology......................................................4 3. Fast Macro Mobility Handovers in HMIPv6..........................6 3.1 Overview.....................................................6 3.2 Operation of the Predictive Mode of Macro Mobility Handover..7 3.3 Operation of the Reactive Mode of Macro Mobility Handover....8 4. Security Considerations..........................................9 5. References......................................................10 6. Authors' Addresses..............................................10 Y. Mun, et al. Expires August, 2009 [Page 2] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 1. Introduction Increasingly, the wireless access services and devices has released and used widely. According to the tendency of the many customers, wireless access devices should support more rapid and stable access services to access Internet. Mobile IPv6 (MIPv6) is a protocol to provide MN with mobility in IPv6 environment. Although MIPv6 enables the IPv6 MN to be connected to the layer 3 while it changes its point of attachment, MIPv6 raises two critical problems; the long handover latency and packet loss. To make up for the problems, the fast handovers for mobile IPv6 (FMIPv6) and the hierarchical mobile IPv6 protocol have proposed. To reduce the handover latency and the packet loss, FMIPv6 provides the fast handover schemes between the access routers in order to support seamless network access services to the MNs in IPv6 network. The layer 3 handover before performing the layer 2 handover is performed by FMIPv6 protocol prior to move into new link. During the real layer 2 handover, access routers use a tunnel for the MN's packets that are transmitted to the previous link. FMIPv6 has two modes of operation in accordance with the time of layer 2 handover of MN; a predictive mode and a reactive mode. These modes support more robust, fast handover to the MN which moves between access routers. HMIPv6 introduces a new entity, called a Mobility Anchor Point. HMIPv6 manages the movement of the MNs by using the MAP. In HMIPv6 network, a MN 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 MN moves into a new access router belonging to a new MAP domain, the movement 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 the MN moves from one access router to another belonging to different MAP domain, the movement is a macro mobility handover. When the MN performs a macro mobility handover, this means that it moves into a new MAP domain. The MN must create two care-of addresses, RCoA and LCoA. Obviously, a new RCoA generation is the same that a MN changes CoA in MIPv6. Thus, change of RCoA causes the same problems as MIPv6's. Although the macro mobility handover causes the same long handover latency and packet loss problems, there is no efficient method to sovle the problems. Therefore, a new method is needed to execute the macro mobility handover rapidly and to reduce both the long handover latency and the packet loss. This document describes the fast macro mobility handovers in HMIPv6 to perform efficiently the handover and reduce both the handover Y. Mun, et al. Expires August, 2009 [Page 3] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 latency and the packet loss. The fast macro mobility handovers have two modes according to the time of layer 2 handover 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 in a MN's home link. HA manages the bindings between the home address and the care-of address of the MN. Correspondent Node (CN) A node that a MN is communicating with. Mobile Node (MN) An Mobile IPv6 node. New Access Router (nAR) The new access router predicted that a MN moves into. Previous Access Router (pAR) The default access router which a MN 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 MN is attached before the macro mobility hanover. Router Solicitation for Proxy Advertisement (RtSolPr) A message used by the MN 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 MN based on the prefix of the nMAP in accordance with PrRtAdv message received from pAR at the previous link. Y. Mun, et al. Expires August, 2009 [Page 4] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 New on-link Care-of Address (nLCoA) An IPv6 address generated by the MN 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 MN to request fast handover to the pAR. In this document, a MN 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 MN. When a MN 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 MN to the MAP in order to register the nRCoA and the nLCoA. The MAP binds the two care-of address. Local Binding Acknowledgement (LBA) A message sent by the MAP to the MN to inform the result of the two addresses binding. Y. Mun, et al. Expires August, 2009 [Page 5] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 3. Fast Macro Mobility Handovers in HMIPv6 3.1. Overview In HMIPv6, a macro mobility handover is that a MN moves from the pAR in the pMAR domain to the nAR in the nMAP domain. The fast macro mobility handover has two modes of operation. One is a predictive mode of the macro mobility handover. Another mode is a reactive mode. It occurs when the MN just perform the real layer 2 handover before exchanging messages for the fast handover prior to move into a new link. In the predictive mode, the handover occurs immediately after the MN receives the FBAck message from the pAR in the pMAP domain. In the reactive mode, the MN does not receive the FBAck message before the layer 2 handover. It is possbile in the case that the MN moves rapidly prior to complete the preparation of the fast handover. For this situation, the packets transmitted to the MN's old address are needed to transfer to the MN's new address. Thus, the reactive mode also uses a tunnel between the MN's pAR and the MN's nAR in order to receive the packets without any loss. For the fast macro mobility handover, 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 August, 2009 [Page 6] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 3.2. Operation of the predictive mode of macro mobility handover A MN receives PrRtAdv messages periodically from the currently attached access router and other access routers close to it. The MN also can request the PrRtAdv messages by sending a RtSolPr message in order to obtain the network information immediately. If the received PrRtAdv message includes information about the new MAP domain, the MN would anticipate the occurence of the macro mobility handover. Using the information included in the received PrRtAdv message, the MN creates both an nLCoA based on the prefix of the nAR and an nRCoA based on the prefix of the nMAP. The MN then sends a FBU message to the pAR. The pAR received FBU message from the MN sends a HI message to the nAR that the MN expects to move into. The nAR must perform a Duplicate Address Detection (DAD) process for the nLCoA requested by the MN as defined in [1]. Simutaneously, the nAR also sends a HI message to the nMAP in order to request the DAD test for the nRCoA asked by the MN. 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 with an NAACK option to the MN. The NAACK option informs that the nRCoA is not available in the nMAP domain and 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 messages between the nAR and the pAR, a tunnel is established between the nAR and the pAR for forwarding packets destined to the MN during the layer 2 handover. The pAR received the HAck message from the nAR sends FBAck message to both the nAR and the MN simutaneously. As soon as the nAR and the MN receive the FBAck messages, the layer 2 handover occurs. During the handover, the packets destined to the MN 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 MN should send a FNA message to the nAR in order to receive the packets forwarded during the handover. After the FNA message, the MN can use the nLCoA. Thus, the handover latency can be reduced. Finally, the MN should perform the local registration by using LBU and LBA messages with the nMAP. After completion of the local registration, the MN 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 August, 2009 [Page 7] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 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 Mode of Macro Mobility Handover 3.3. Operation of the Reactive Macro Mobility Mode The reactive mode of macro mobility handover is analogous to the reactive mode of FMIPv6. A MN 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 mode of macro mobility handover would be the solution to improve the fast handover operation. In the reactive mode of macro mobility handover, if the MN carries out the layer 2 handover before completing the fast binding operation, which the MN does not send or receive the FBU or FBAck messages, the MN would convert the fast handover operation into the reactive mode of macro mobility handover. The MN receives PrRtAdv messages periodically or requests the messages by sending RtSolPr messages, as mentioned section 3.2. Due to the MN's rapid movement from the previous link to the new one or the erroneous situation, the MN 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 mode. After the layer 2 handover, the MN should firstly generate a special FNA message. This Y. Mun, et al. Expires August, 2009 [Page 8] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 FNA message is defined in [2]. The MN sends the FNA message 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 MN. At the same time, the nAR sends FBU message to the pAR of the MN. The pAR sends a FBAck message in reply to the FBU message and then forwards the packets of the MN to the nAR. Therefore, the MN can receive the packets transferred to the pAR from the nAR without packet loss. Finally, the MN 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 mode of macro mobility handover 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 macro mobility handovers 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 August, 2009 [Page 9] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 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 August, 2009 [Page10] Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 November 2007 Y. Mun, et al. Expires August, 2009 [Page11]