One document matched: draft-jaehwoon-mipshop-flush-mipv6-00.txt
MIPSHOP Working Group
INTERNET-DRAFT Jaehwoon Lee
Expired: January 2006 Dongguk University
Sanghyun Ahn
University of Seoul
July 2005
Flushing Mechanism to Notify Binding Update in MIPv6
draft-jaehwoon-mipshop-flush-mipv6-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 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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-00.txt Expires - Jan. 2006 [Page 1]
Flushing Mechanism to notify Binding Update in MIPv6 July 2005
Table of Contents:
1. Introduction...................................................3
2. Terminology....................................................4
3. Protocol description...........................................4
4. Flush message format...........................................5
5. Applicability Statement........................................6
6. IANA Considerations............................................7
7. Security Considerations........................................7
References........................................................7
Author's Addresses................................................7
Intellectual Property Statement...................................8
Disclaimer of validity............................................8
Copyright Statement...............................................8
draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 2]
Flushing Mechanism to notify Binding Update in MIPv6 July 2005
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 [MIPv6]. 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 indicating that the
HA/CN is about to update its binding cache entry when a MN registers
its home address and CoA to its HA/CN by using a binding update
message. That is, when a MN moves in a new network, the MN sends a
binding update message to its HA/CN in order to register its home
address as well as its new CoA (NCoA). However, packets sent from
the HA/CN to the MN has the previous CoA (PCoA) as the destination
address until the binding update message arrives at the HA/CN and
the corresponding binding cache entry is updated. If the binding
update message arrives and the binding cache entry is updated at the
HA/CN, the MN will receive packets with 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. In MIPv6, a MN cannot
know the last packet with the PCoA as the destination address.
Knowing it is especially necessary when a MN tries to deliver the
received packets to the upper layer in order.
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.
draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 3]
Flushing Mechanism to notify Binding Update in MIPv6 July 2005
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
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
draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 4]
Flushing Mechanism to notify Binding Update in MIPv6 July 2005
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.
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:
draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 5]
Flushing Mechanism to notify Binding Update in MIPv6 July 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++++++++++++++++++++++|
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flush Message
IP fields:
Source address = IP address 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 [FMIPv6]. 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
draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 6]
Flushing Mechanism to notify Binding Update in MIPv6 July 2005
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
Flush message. An MH Type value for the Flush message must be
assigned by IANA.
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. Koodli (Editor), et. al, "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03.txt, work in progress.
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 7]
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 (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-flush-mipv6-00.txt Expires - Jan. 2006 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 06:09:11 |