MIPSHOP Working Group INTERNET-DRAFT Jaehwoon Lee Expired: April 2006 Dongguk University Sanghyun Ahn University of Seoul Oct. 2005 Flushing Mechanism to Notify Binding Update in MIPv6 draft-jaehwoon-mipshop-flush-mipv6-01.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 April 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Mobile IPv6 (MIPv6) is 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. In MIPv6, a MN cannot know which packet is the last packet with the previous CoA (PCoA) as the destination address. In this draft, we define the format and the usage of the Flush message, in order for the MN to know the last packet with the PCoA as the destination address sent by the home agent (HA) and/or a CN. draft-jaehwoon-mipshop-flush-mipv6-01.txt Expires - Apr. 2006 [Page 1] Flushing Mechanism to notify Binding Update in MIPv6 Oct. 2005 Table of Contents: 1. Introduction...................................................3 2. Terminology....................................................4 3. Protocol description...........................................5 4. Flush message format...........................................6 5. Applicability Statement........................................7 6. IANA Considerations............................................7 7. Security Considerations........................................8 References........................................................8 Author's Addresses................................................8 Intellectual Property Statement...................................9 Disclaimer of validity............................................9 Copyright Statement...............................................9 draft-jaehwoon-mipshop-flush-mipv6-01.txt Expires - Apr. 2006 [Page 2] Flushing Mechanism to notify Binding Update in MIPv6 Oct. 2005 1. Introduction The 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, no message or procedure is defined for a HA/CN to notify a MN of the update of its corresponding binding cache entry. When a MN moves in a new network, the MN sends a binding update message to its HA/CN in order to register its binding information. However, before the HA/CN receives a binding update message from the MN and updates the corresponding binding cache entry, packets sent from the HA/CN to the MN have the previous CoA (PCoA) as the destination address. After a binding update message arrives and the binding cache entry is updated at the HA/CN, packets sent to the MN will have the NCoA as the destination address. That is, the MN will receive packets by using both routes, one via the PAR and the other via the NAR. If a MN receives packets from the NAR before it receives all of the packets from the PAR, the MN may receive packets out-of-sequence and this may result in the performance degradation. One way to resolve out-of-sequence packets is to use the bi-casting[2]. In this method, after an MN moves into a new network and notifies the HA of its move, for the time being, the HA bi-casts packets for the MN to the PCoA and the NCoA. This method duplicates and sends out packets to the network, so it may cause congestion. Another way is to use two types of buffers at the MN[3]. One type of buffer is for the storage of packets with the PCoA as the destination address, and the other for the storage of packets with the NCoA as the destination address. Let packets with the PCoA as the destination address be PCoA packets and those with the NCoA NCoA packets. Since PCoA packets have to be delivered to the upper layer ahead of NCoA packets, the MN gives a higher priority to the buffer with PCoA packets. Before the MN receives all PCoA packets, it delays the delivery of NCoA packets to the upper layer. Even though this mechanism can avoid out-of-sequence packets, a timer is required at the MN for the indication of the time when all PCoA packets are draft-jaehwoon-mipshop-flush-mipv6-01.txt Expires - Apr. 2006 [Page 3] Flushing Mechanism to notify Binding Update in MIPv6 Oct. 2005 received by the MN. If the timer expires, the MN assumes no more upcoming PCoA packets and starts to deliver NCoA packets to the upper layer. However, it is hard to decide the timer value and, since the delivery of NCoA packets to the upper layer is delayed until the timer expiration, service becomes unavailable during this time interval. In this draft, we define the format and the usage of the Flush message, in order for a MN to know the last packet sent by the HA/CN just before its updating the binding cache entry. That is, when a MN receives a Flush message with the PCoA as the destination address, the MN can consider those packets sent after the Flush message by the HA/CN as those with the NCoA as the destination address. 2. Terminology In this draft, we use the terms defined in MIPv6 and FMIPv6, except for the term described below. Flush: the message which is transmitted to a MN from the HA/CN using the PCoA to notify the MN that the HA or CN is going to update its own binding cache entry as soon as it sends out the Flush message draft-jaehwoon-mipshop-flush-mipv6-01.txt Expires - Apr. 2006 [Page 4] Flushing Mechanism to notify Binding Update in MIPv6 Oct. 2005 3. Protocol Description MN PAR NAR HA/CN | | | | |<---------------------| | | | Router Advertisement | | | To configure PCoA | | | |--------------------->|------------------------------>| | | Binding Update(PCoA) | | | | Create Binding | | | Cache Entry |<---------------------|<------------------------------| | Binding Ack (If necessary) | |<---------------------|<------------------------------| | Date packet from HA/CN to MN via PAR | | | | | Move from PAR to NAR | | | |<-----------------------------------| | | Router Advertisement | | To configure NCoA | | | |------------------------------------>---------------->| | Binding Update(NCoA) |<---------------------|<------------------------------| | Flush message from HA/CN to MN via PAR | | | | Update Binding | | | Cache Entry |<-----------------------------------|<----------------| | Binding Ack (If necessary) | |<---------------------|-------------|<----------------| | Date packet from HA/CN to MN via NAR | Figure 1: Message exchanging procedure Figure 1 shows the message exchanging procedure considered in this draft. If a MN is connected to a foreign network, it constructs a PCoA using the information received from the PAR. And then, the MN sends the binding update message having the PCoA and its Home address to the HA/CN, in order to register the information in the binding cache entry within the HA/CN. After that, Packets transmitted from the HA/CN can be delivered to the MN. When the MN moves to the NAR, it constructs the NCoA from the information provided by the NAR and registers its NCoA and home address to the HA/CN by sending a Binding Update message. draft-jaehwoon-mipshop-flush-mipv6-01.txt Expires - Apr. 2006 [Page 5] Flushing Mechanism to notify Binding Update in MIPv6 Oct. 2005 Before the Binding Update message is delivered to and updated by the HA/CN, packets from the HA/CN are delivered to the MN via the PAR. If the HA/CN receives the Binding Update message, the HA/CN transmits a Flush message to the MN by using the previous binding information to indicate that its binding cache entry is about to be updated. That is, The Flush message is the last packet with the PCoA as the destination address transmtted from the HA/CN to the MN. After the HA/CN transmits a Flush message, it updates its binding cache entry to the NCoA. And then, the HA/CN can transmit packets with the NCoA as the destination address to the MN. Since it takes time for the Binding Update message with the NCoA and the home address of the MN to arrive at the HA/CN and for the HA/CN to update its binding cache entry, during this period packets sent by the HA/CN to the MN has the PCoA as the destination address. Moreover,those packets transmitted after the update of the binding cache entry of the HA/CN have the NCoA as the destination address. That is, the MN can receive packets sent from the HA/CN by using two routes, one via the PAR and the other via the NAR, which may results in out-of-order packets at the MN. In this case, those packets with the PCoA as the destination address should be processed before those with the NCoA. How to process packets in sequence at a MN is implementation-dependent and this is out of scope of this draft. However, the MN needs to be indicated with the last packet with the PCoA as the destination address. If the MN receives a Flush message from the HA/CN, the MN considers that it is the last packet with the PCoA as the destination address. 4. Flush message format A Flush message is used by the HA/CN to notify a MN that the binding cache entry of the HA/CN is about to be updated. The format of the Flush message is shown as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++++++++++++++++++++++| | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Flush Message draft-jaehwoon-mipshop-flush-mipv6-01.txt Expires - Apr. 2006 [Page 6] Flushing Mechanism to notify Binding Update in MIPv6 Oct. 2005 IP fields: Source address = IP address of the node sending this message Destination Address = MN's PCoA Next Header = Mobility header Mobility header Payload proto = None (to be changed later) MH type = Flush (to be decided by IANA) Mobility options This specification does not define any options valid for the Flush message. 5. Applicability statement The mechanism described in this draft can be applied to FMIPv6 [4]. FMIPv6 has been proposed to reduce the handover latency of MIPv6. In FMIPv6, if a MN moves from a network to a new one and the NCoA is not registered yet to the HA/CN, packets from the HA/CN are delivered to the MN via both the PAR and the NAR. Once the MN registers the NCoA to the HA/CN, packets with the PCoA as the destination address will arrive at the MN via the PAR and then via the NAR. On the other hand, packets with the NCoA as the destination address will be delivered to the MN via the NAR. This mechanism notifies the MN of the last packet with the PCoA as the destination address delivered by the PAR. The Flush message does not confirm that it is really the last message since there can be route changes in the Internet. It can be the last message when a MN moves from one network to another, only when there is no route changes within the Internet. 6. IANA Considerations This draft document defines a new Mobility Header message which is the Flush message. An MH Type value for the Flush message must be assigned by IANA. draft-jaehwoon-mipshop-flush-mipv6-01.txt Expires - Apr. 2006 [Page 7] Flushing Mechanism to notify Binding Update in MIPv6 Oct. 2005 7. 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] R. Ramjee, et. al, "HAWAII: A Domain-Based Approach for Supporting Mobility in Wide-Area Wireless Networks", IEEE Trans. on Networking, vol.10, no. 3, pp. 396-410, June 2002. [3] D. Lee, G. Hwang and C. Oh, "Performance Enhancement of Mobile IP by reducing out-of-sequence packet using priority scheduling", IEICE Trans. on Commun., vol E85-B, No. 8, pp. 1442-1446, Aug. 2002. [4] R. Koodli (Editor), et. al, "Fast Handovers for Mobile IPv6", RFC 4068. 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-flush-mipv6-00.txt Expires - Jan. 2006 [Page 8] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 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 (2005). 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-flush-mipv6-01.txt Expires - Apr. 2006 [Page 9]