Internet DRAFT - draft-jaehwoon-mipshop-flush-mipv6
draft-jaehwoon-mipshop-flush-mipv6
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]
