Internet DRAFT - draft-jaehwoon-mipshop-ifhmipv6
draft-jaehwoon-mipshop-ifhmipv6
MIPSHOP Working Group
INTERNET-DRAFT Jaehwoon Lee
Expired: December 2006 Dongguk University
Sanghyun Ahn
University of Seoul
June 2006
I-FHMIPv6: A Novel FMIPv6 and HMIPv6 Integration Mechanism
draft-jaehwoon-mipshop-ifhmipv6-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 December 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-01.txt Expires - Dec. 2006 [Page 1]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 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-01.txt Expires - Dec. 2006 [Page 2]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 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-01.txt Expires - Dec. 2006 [Page 3]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 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 |
| |<----------------------------------|
| | Flush |
| | | (Modify binding cache)
| | |<----------------|
| | | FBack |
| | |<================|
| | | Forward packet |
| |================>| |
| Forward buffered packets |
| |---------------->| |
| Send Flush message and close tunnel |
(connect) | | |
|---------------------------------->| |
| FNA | |
|<==================================| |
| Forward packets | |
| | | |
| | | |
(a) Predictive mode
draft-jaehwoon-mipshop-ifhmipv6-01.txt Expires - Dec. 2006 [Page 4]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 2006
MN PAR NAR MAP
| | | |
| | | |
| | | |
|---------------->| | |
| RtSolPr | | |
|<----------------| | |
| PrRtAdv | | |
(disconnect) | | |
| | | |
| | | |
(connect) | | |
|---------------------------------->| |
| FNA(FBU) | |
| |<----------------| |
| | FBU | |
| (Buffer packets) | |
| |---------------------------------->|
| | FBU |
| | |<----------------|
| | | HI |
| | |---------------->|
| | | HAck |
| |<----------------------------------|
| | Flush |
| | | (Modify binding cache)
| | |<----------------|
| | | FBack |
| | |<================|
| | | Forward packet |
| |================>| |
| 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-ifhmipv6-01.txt Expires - Dec. 2006 [Page 5]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 2006
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-01.txt Expires - Dec. 2006 [Page 6]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 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 Flush message to the PAR to notify that its binding
cache entry is about to be updated. After updating its binding cache
entry, the MAP sends a Fast Binding Acknowledgement (FBAck) message
which has the NLCoA as the destination address. And then, the MAP
tunnels all the packets to the MN using the NLCoA as the destination
address.
The PAR having received the Flush message from the MAP 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-01.txt Expires - Dec. 2006 [Page 7]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 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-01.txt Expires - Dec. 2006 [Page 8]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 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-01.txt Expires - Dec. 2006 [Page 9]
A Novel FMIPv6 and HMIPv6 Integration Mechanism June 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 (2006). 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-01.txt Expires - Dec. 2006 [Page 10]
