MIPSHOP Working Group INTERNET-DRAFT Jaehwoon Lee Expired: September 2006 Dongguk University Sanghyun Ahn University of Seoul February 2006 I-FHMIPv6: A Novel FMIPv6 and HMIPv6 Integration Mechanism draft-jaehwoon-mipshop-ifhmipv6-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 September 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The mobile IPv6 (MIPv6) enables a mobile node (MN) to maintain its connectivity with a correspondent node (CN) while changing its point of attachment. Since, in MIPv6, packets sent from a CN to an MN during handover can be lost, several mechanisms such as FMIPv6 and HMIPv6 have been proposed to reduce the number of lost packets. However, such mechanisms still suffer from the performance degradation due to not only packet losses but also out-of-sequence packets. In this draft, we propose I-FHMIPv6 which integrates FMIPv6 and HMIPv6 efficiently. I-FHMIPv6 uses the Flush message and can minimize packet losses. draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 1] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 2006 Table of Contents: 1. Introduction...................................................3 2. Terminology....................................................4 3. Protocol description...........................................4 4. Applicability Statement........................................8 5. IANA Considerations............................................8 6. Security Considerations........................................8 References........................................................8 Author's Addresses................................................9 Intellectual Property Statement...................................10 Disclaimer of validity............................................10 Copyright Statement...............................................10 draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 2] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 2006 1. Introduction Mobile IPv6 (MIPv6) defines a protocol that allows a mobile node (MN) to maintain connectivity with a correspondent node (CN) via the Internet while changing its point of attachment [1]. In MIPv6, a MN is assigned with an IPv6 address as the home address, and the home agent (HA) is the mobility agent which has the same network address as that of the home address of the MN. The access router (AR) is the router prividing the Internet access service to a MN when it is away from home. When a MN visits a foreign network, it is assigned with a care-of address (CoA) and registers its own home address and the CoA (i.e., the binding information) to its HA (if the route optimization is used, this binding information is also registered to the corresponding CN). In MIPv6, if an MN moves from a network to another one, the MN cannot get the Internet service from the new network during the handover. During this time interval, packets sent by the HA/CN are delivered to the previous AR (PAR) and may get lost. Longer handover latency causes more packet losses. To solve this problem, the Hierarchical MIPv6 (HMIPv6) and the Fast Handovers for MIPv6 (FMIPv6) have been proposed [2, 3]. In HMIPv6, a new type of router called the Mobility Anchor Point (MAP) is defined and those ARs with the same MAP information form a MAP domain. The MAP acts as a local HA in a MAP domain. If the MN gets connected to a new AR (NAR) within the same MAP doamin, it registers its local CoA to the MAP. This completes the MN's registration procedure. In this case, the handover latency is reduced since the handover procedure is limited within a single MAP domain. However, HMIPv6 still suffers from the packet loss during the handover latency within a MAP domain. FMIPv6 is a mechanism to reduce the handover latency and packet losses by constructing the new CoA (NCoA) by using the NAR information prior to its movement to a new network. In FMIPv6, even though an MN moves in a new network, before it registers its NCoA to the HA/CN, packets sent from the HA/CN are delivered to the PAR first and then tunneled to the NAR by the PAR and finally arrive at the MN. Once the MN completes the registration of its NCoA to the HA/CN, packets will arrive at the MN directly via the NAR. That is, packets sent from the HA/CN before the registration of the NCoA are delivered via the PAR and those after the registration of the NCoA via the NAR. If the MN receives packets from the NAR before it receives all packets from the PAR, packets can be out-of-sequence and this may degrade the performance [4,5]. In [6], we proposed the Flush message which is used by the HA/CN/MAP having received a BU message to notify the MN of the update of its binidng cache entry, which tries to overcome the out-of-sequence packet problem with minimizing packet losses. draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 3] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 2006 In this draft, we propose the I-FHMIPv6 mechanism which efficiently integrates FMIPv6 and HMIPv6 by using the Flush message. The proposed mechanism can resolve the out-of-sequence packet problem and, at the same time, minimize packet losses. 2. Terminology There is no terms defined only for this draft, except for terms defined in the references. 3. I-FHMIPv6: Integration of FMIPv6 and HMIPv6 MN PAR NAR MAP | | | | | | | | | | | | |---------------->| | | | RtSolPr | | | |<----------------| | | | PrRtAdv | | | |---------------->|---------------------------------->| | FBU (Buffer packets) | | | | |<----------------| (disconnect) | | HI | | | |---------------->| | | | HAck | | |<----------------------------------| | | FBack | | | | (Modify binding cache) | | |<================| | | | Forward packet | | <---|---------------->| | | Back | FBack | | | |================>| | | Forward buffered packets | | |---------------->| | | Send Flush message and close tunnel | (connect) | | | |---------------------------------->| | | FNA | | |<==================================| | | Forward packets | | | | | | | | | | (a) Predictive mode draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 4] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 2006 MN PAR NAR MAP | | | | | | | | | | | | |---------------->| | | | RtSolPr | | | |<----------------| | | | PrRtAdv | | | (disconnect) | | | | | | | | | | | (connect) | | | |---------------------------------->| | | FNA(FBU) | | | |<----------------| | | | FBU | | | (Buffer packets) | | | |---------------------------------->| | | FBU | | | |<----------------| | | | HI | | | |---------------->| | | | HAck | | |<----------------------------------| | | FBack | | | | (Modify binding cache) | | |<================| | | | Forward packet | | |---------------->| | | | FBack | | | |================>| | | Forward buffered packets | | |---------------->| | | Send Flush message and close tunnel | |<==================================| | | Forward packets | | | | | | | | | | (b) Reactive mode Figure 1. Message exchange procedure among network elements in I-FHMIPv6 draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 5] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 In this section, we describe the operation of the I-FHMIPv6 mechanism which efficiently integrates HMIPv6 and FMIPv6, and how to apply the Flush message to the mechanism. The message exchange procedure among network element is shown in figure 1. Even though the proposed mechanism includes both the predictive and the reactive modes, here we will focus only on the predictive mode. When an MN moves in a network within a new MAP domain, the MN exchanges Router Solicitation (RS) and Router Advertisement (RA) messages with the PAR to construct its Previous Local CoA (PLCoA) and RCoA. Then the MN registers this information to the MAP via the exchange of the local BU and the local BA (Binding Acknowledgment) message. The format of RS/RA and local BU/BA messages are defined in the HMIPv6 protocol [2]. In addition to that, the MN registers its RCoA and home address to the HA/CN via the exchange of BU and BA messages. In the case when the MN connected to the network detects its movement to another network within the same MAP domain by receiving a link layer signal from a new AP, the MN sends a RtSolPr message to the PAR. In this message, the link layer address of the newly detected AP and the link layer address option are included. When the PAR receives the RtSolPr message from the MN, it checks which NAR is connected to the detected AP. Also the PAR checks whether the NAR resides within the same MAP domain. After that, the PAR sends to the MN the RtAdvPr message including the link layer addresses of the AP and the NAR, the IP address and the Prefix of the NAR, and the MAP address information. Figure 2 shows the format of the MAP address option. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-type | Prefix Lengh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Mobility options | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of the MAP address option When the MN receives the RtAdvPr message, it checks whether the message has the MAP address option. If the MAP address within the MAP address option is the same as that MN registers, the MN assumes that it has moved within the same MAP domain and constructs its New Local CoA (NLCoA) using the prefix information of the NAR and sends the modified FBU message to the PAR and the MAP. The format of the draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 6] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 2006 modified FBU message is shown in figure 3. When the PAR receives the FBU message, it stores packets with the PLCoA as the destination address (i.e., PLCoA packets) without delivering them to the MN. +-----------------------------------------------------------+ | | | * IP header | | - Source address = MN's PLCoA | | - Destination address = PAR's address | | - Next header = Routing header | | * Routing header | | - Next header = Mobility header | | - IP address = MAP address | | * Mobility header | | - MH Type = Fast Binding Update | | - Altenate CoA option = NLCoA | | - New Router's IP address = NAR's IP address | | - Link-layer address of MN = MN's link layer address | | | +-----------------------------------------------------------+ Figure 3: Information included in the modified FBU message The MAP having received the FBU message from the MN sends a Handover Initiate (HI) message to the NAR. This message has the PAR address option in addition to the link layer address of the MN, the PLCoA and the NLCoA defined in the FMIPv6 protocol. The PAR address option has the same format as that of the PLCoA address option. The NAR having received the HI message checks whether the NLCoA which is to be chosen by the MN is available by performing the duplicate address detection (DAD) and, then, sends a Handover Acknowledgement (HAck) message to the MAP. Once the MAP receives the HAck message from the NAR, it assumes that the fast handover procedure is completed. Then, the MAP sends a Fast Binding Acknowledgement (FBAck) message to the PAR and updates its binding cache entry. After that, the MAP tunnels all the packets to the MN using the NLCoA as the destination address. The PAR having received the FBack message from the MAP sends the FBack message with the NLCoA as the destination address. The PAR may send to the MN a FBack message with the PLCoA as the destination address. And the PAR tunnels the PLCoA packets stored in its buffer by encapsulating them with the NLCoA as the destination address. And then, the PAR sends a Flush message that is the final packet having the PLCoA as the destination address. draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 7] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 2006 When a MN moves in a new network, it sends a FNA message to the NAR. Having received the FNA message from the MN, the NAR sends packets to the MN. Packets delivered to the MN via the NAR can be classified into those sent along the MAP->PAR->NAR path and those along the MAP->NAR path. That is, packets delivered via the MAP->PAR->NAR path have the PLCoA as the destination address and those via the MAP->NAR path the NLCoA as the destination address. Since PLCoA packets have been sent out from the source prior to those with the NLCoA, PLCoA packets must be delivered to the MN earlier than those with the NLCoA. The MN allocates two types of buffers for the packets destined to itself, one for those delivered via the PAR and the other for those delivered directly to the NAR from the MAP. The MN begins to deliver PLCoA packets to the upper layer and stores NLCoA packets in the buffer. If the MN receives a Flush message from the MAP, it begins to deliver NLCoA packets to the upper layer. Using this mechanism, the problem of out-of-sequence packets delivered to the MN can be resolved without using a timer. 4. Applicability statement The mechanism described in this draft can be applied without using bicasting or timer. Moreover, the mechanism can be applied when the MN is equipped with only one interface. 5. IANA Considerations This draft document defines a new MAP address option. An Type value for the MAP address option must be assigned by IANA. 6. Security Considerations There is no special security considerations in this draft. References [1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775. [2] H. Soliman et al, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)" RFC 4140. draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 8] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 2006 [3] R. Koodli (Editor), et. al, "Fast Handovers for Mobile IPv6", RFC 4068. [4] Q. Zhao, Li Feng, Z. Li and Y. Zhang, "Performance analysis of handoff management in mobile IP" Proc. Asia-Pacific Conference, pp. 893-897, Sep. 2004. [5] D. Lee, C. Oh, S. Lee, J. Park and K. Kim, "Design and Analysis of the Mobile Agent Preventing Out-of-sequence", ICOIN, 1999. [6] J. Lee and S. Ahn, "Flushing Mechanism to Notify Binding Update in MIPv6", Work in Progress, Oct. 2005. Authors' Addresses Jaehwoon Lee Dongguk University 26, 3-ga Pil-dong, Chung-gu Seoul 100-715, KOREA Email: jaehwoon@dongguk.edu Sanghyun Ahn University of Seoul 90, Cheonnong-dong, Tongdaemun-gu Seoul 130-743, KOREA Email: ahn@venus.uos.ac.kr draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 9] A Novel FMIPv6 and HMIPv6 Integration Mechanism Feb. 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 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. 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 (2004). 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. draft-jaehwoon-mipshop-ifhmipv6-00.txt Expires - Sep. 2006 [Page 10]