Mipshop Working Group Youngsong Mun
Internet-Draft Kyunghye Lee
Expires: December, 2007 Soongsil University
June, 2007
Fast Macro Mobility Handovers in HMIPv6
draft-mun-mipshop-fhmacro-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 January 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In Hierarchical Mobile IPv6 (HMIPv6), a mobile can experience a long
handover latency and packet loss problems due to the MN's
movement between access routers belonging to different Mobility
Anchor Point (MAP) domain, called a macro mobility handover. To
improve the performance of macro mobility handover, this document
describes a new scheme that can execute the macro mobility handover
rapidly and reduce both the handover latency and packet loss. The
scheme described in this document is a fast macro mobility handover
by applying FMIPv6 protocol to the edge access routers in MAP domain.
Y. Mun, et al. Expires December, 2007 [Page 1]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
The scheme supports two modes to be used according to the situation of
the MN.
Table of Contents
1. Introduction.....................................................3
2. Terminology......................................................4
3. Fast Macro Mobility Handovers in HMIPv6..........................6
3.1 Overview.....................................................6
3.2 Operation of the Predictive Mode of Macro Mobility Handover..7
3.3 Operation of the Reactive Mode of Macro Mobility Handover....8
4. Security Considerations..........................................9
5. References......................................................10
6. Authors' Addresses..............................................10
Y. Mun, et al. Expires June, 2007 [Page 2]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
1. Introduction
Increasingly, the wireless access services are important since plenty
of wireless access devices has released and used widely. According to
the tendency of the many customers, wireless access devices should
support more rapid and stable access services to access Internet.
Mobile IPv6 (MIPv6) is a protocol to provide MN with mobility in IPv6
network. Although MIPv6 enables the IPv6 MN to be connected to the
layer 3 while it changes its point of attachment, MIPv6 raises two
critical problems; the long handover latency and packet loss. To make
up for the problems, the fast handovers for mobile IPv6 (FMIPv6)
protocol and the hierarchical mobile IPv6 (HMIPv6) protocol have
proposed.
To reduce the handover latency and the packet loss, FMIPv6 protocol
provides the fast handover schemes between the access routers in
order to support seamless network access services to the MNs in IPv6
network. The layer 3 handover before performing the layer 2 handover
is performed by FMIPv6 protocol prior to move into new link. During
the real layer 2 handover, access routers use a tunnel for the MN's
packets that are transmitted to the previous link. FMIPv6 has two
modes of operation in accordance with the time of layer 2 handover of
MN; a predictive mode and a reactive mode. These modes support more
robust and fast handover to the mobile
node which moves between access routers.
HMIPv6 protocol uses a new entity, called a Mobility Anchor Point.
HMIPv6 manages the movement of the MNs by using the MAP. In HMIPv6
network, a MN has to generate two care-of addresses; a regional
care-of address (RCoA) and an on-link care-of address (LCoA). A RCoA
is created based on the prefix of the MAP domain and a LCoA is
created based on the prefix of the attached access router. When a MN
moves into a new access router belonging to a new MAP domain, the
movement is called a micro mobility handover. To improve performance
of the micro mobility handover, there is a method applied the fast
handover technique of FMIPv6 to the access routers. If the MN moves
from one access router to another belonging to different MAP domain,
the movement is a macro mobility handover.
When the MN performs a macro mobility handover, this means that it
moves into a new MAP domain. The MN must create two care-of
addresses, RCoA and LCoA. Obviously, a new RCoA generation is the
same that a MN changes CoA in MIPv6. Thus, change of RCoA causes the
same problems as MIPv6's. Although the macro mobility handover causes
the same long handover latency and packet loss problems, there is no
efficient method to sovle the problems. Therefore, a new method is
needed to execute the macro mobility handover rapidly and to reduce
Y. Mun, et al. Expires June, 2007 [Page 3]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
both the long handover latency and the packet loss.
This document describes the fast macro mobility handovers in HMIPv6
to perform efficiently the handover and reduce both the handover
latency and the packet loss. The fast macro mobility handovers have
two modes according to the time of layer 2 handover of the mobile
node, as the two modes of FMIPv6.
2. Terminology
Most of terminologies used in this draft are defined in MIPv6 [1],
FMIPv6 [2], and HMIPv6 [3].
Home Agent (HA)
A router in a MN's home link. HA manages the bindings
between the home address and the care-of address of the MN.
Correspondent Node (CN)
A node that a MN is communicating with.
Mobile Node (MN)
An Mobile IPv6 node.
New Access Router (nAR)
The new access router predicted that a MN moves into.
Previous Access Router (pAR)
The default access router which a MN is attached before the
macro mobility handover.
New Mobility Anchor Point (nMAP)
The new Mobility Anchor Point which the nAR belongs to.
Previous Mobility Anchor Point (pMAP)
The Mobility Anchor Point that a MN is attached before the
macro mobility hanover.
Router Solicitation for Proxy Advertisement (RtSolPr)
A message used by the MN in order to obtain Proxy Router
Advertisement message swiftly from access routers.
Proxy Router Advertisement (PrRtAdv)
A message used by the access routers to advertise the
information about the network. Specifically, when the edge
access routers sends a PrRtAdv message, it should contain
the information of the MAP domain, such as prefixes.
Y. Mun, et al. Expires June, 2007 [Page 4]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
New Regional Care-of Address (nRCoA)
An IPv6 address created by the MN based on the prefix of the
nMAP in accordance with PrRtAdv message received from pAR at
the previous link.
New on-link Care-of Address (nLCoA)
An IPv6 address generated by the MN based on the prefix of
the nAR according to PrRtAdv message received from pAR at
the previous link.
Fast Binding Update (FBU)
A message used by the MN to request fast handover to the
pAR. In this document, a MN should contain the nRCoA in FBU
message together with nLCoA.
Fast Binding Acknowledgement (FBAck)
A message used by access routers to inform that the
preparation of the fast handover is completed and both the
nRCoA and the nLCoA are available to use in response to the
FBU message.
Handover Initiate (HI)
A message used by access routers in order to establish a
tunnel between two edge access routers and to check that the
two care-of address are unique in new link.
Handover Acknowledge (HAck)
A message in respose to the HI in order to the result of the
two care-of address check and the tunnel establishment.
Fast Neigbhor Advertisement (FNA)
A message used by the MN. When a MN moves into the new MAP
domian, it should send this message to the nAR in order to
inform the existence of itself and receive the packets
transmitted to the nAR during the handover.
Neighbor Advertisement Acknowledgment (NAACK) option
An option included in the FNA message to notify that the new
address is duplicated or not in the new link.
Local Binding Update (LBU)
A message sent by the MN to the MAP in order to register the
nRCoA and the nLCoA. The MAP binds the two care-of address.
Local Binding Acknowledgement (LBA)
A message sent by the MAP to the MN to inform the result of
the two addresses binding.
Y. Mun, et al. Expires June, 2007 [Page 5]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
3. Fast Macro Mobility Handovers in HMIPv6
3.1. Overview
In HMIPv6, a macro mobility handover is that a MN moves from the pAR
in the pMAR domain to the nAR in the nMAP domain. The fast macro
mobility handover has two modes of operation. One is a predictive
mode of the macro mobility handover. Another mode is a reactive mode.
It occurs when the MN just perform the real layer 2 handover before
exchanging messages for the fast handover prior to move into a new
link. In the predictive mode, the handover occurs immediately after
the MN receives the FBAck message from the pAR in the pMAP domain.
In the reactive mode, the MN does not receive the FBAck message
before the layer 2 handover. It is possbile in the case that the MN
moves rapidly prior to complete the preparation of the fast handover.
For this situation, the packets transmitted to the MN's old address
are needed to transfer to the MN's new address. Thus, the reactive
mode also uses a tunnel between the MN's pAR and the MN's nAR in
order to receive the packets without any loss. For the fast macro
mobility handover, the reference scenario is shown as Figure.1.
+-------+
| HA | +----+
+-------+ | CN |
| +----+
| |
+----+----------------+--+
|pRCoA |nRCoA
+--------+ +--------+
| pMAP | | nMAP |
+--------+ +--------+
| | |
| | |
| | |
| | |
+-----+ +-----+ +-----+
| AR | | pAR | | nAR |
+-----+ +-----+ +-----+
pLCoA nLCoA
|
|
+----+
| MN | movement
+----+ ------------>
Figure 1 : Reference scenerio for the macro mobiity handover
Y. Mun, et al. Expires June, 2007 [Page 6]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
3.2. Operation of the predictive mode of macro mobility handover
A MN receives PrRtAdv messages periodically from the currently
attached access router and other access routers close to it. The MN
also can request the PrRtAdv messages by sending a RtSolPr message in
order to obtain the network information immediately.
If the received PrRtAdv message includes information about the new
MAP domain, the MN would anticipate the occurence of the macro
mobility handover. Using the information included in the received
PrRtAdv message, the MN creates both an nLCoA based on the prefix of
the nAR and an nRCoA based on the prefix of the nMAP. The MN then
sends a FBU message to the pAR.
The pAR received FBU message from the MN sends a HI message to the
nAR that the MN expects to move into. The nAR must perform a
Duplicate Address Detection (DAD) process for the nLCoA requested by
the MN as defined in [1]. Simutaneously, the nAR also sends a HI
message to the nMAP in order to request the DAD test for the nRCoA
asked by the MN. In reply to the HI message, the nAR sends a HAck
message to the pAR at the same time. If the nRCoA is duplicated in
the nMAP domain, the nMAP informs the result to the nAR and nAR sends
a FNA message with an NAACK option to the MN. The NAACK option
informs that the nRCoA is not available in the nMAP domain and it
must create a new RCoA. Thus, the nAR does not need to wait for the
HAck message from the nMAP. Through the exchange of the HI and HAck
messages between the nAR and the pAR, a tunnel is established between
the nAR and the pAR for forwarding packets destined to the MN during
the layer 2 handover.
The pAR received the HAck message from the nAR sends FBAck message to
both the nAR and the MN simutaneously. As soon as the nAR and the MN
receive the FBAck messages, the layer 2 handover occurs. During the
handover, the packets destined to the MN are forwarded from the pAR
to the nAR, and stored in the nAR for a while. Therefore, the packet
loss can be reduced in macro mobility handover. After the handover,
the MN should send a FNA message to the nAR in order to receive the
packets forwarded during the handover. After the FNA message, the MN
can use the nLCoA. Thus, the handover latency can be reduced.
Finally, the MN should perform the local registration by using LBU
and LBA messages with the nMAP. After completion of the local
registration, the MN must sending BU message to the its HA in order
to bind the its home address with the nRCoA as the CoA. Figure 2
represent the procedure of the predictive macro mobility mode.
Y. Mun, et al. Expires June, 2007 [Page 7]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
MN pAR pMAP nAR nMAP HA
| | | | | |
|--RtSolPR-->| | | | |
|<--PrRtAdv--| | | | |
|----FBU---->| | | | |
| |-----------HI----------->| | |
| | | nLCoA DAD+----HI----->| |
| |<----------HAck----------| +nRCoA DAD |
| | | |<---HAck----| |
| <--FBAck--|-------FBAck--------> | | |
disconnect | | | | |
| |===Packet forwarding====>| | |
connect | | | | |
|---------------FNA------------------->| | |
|<========Packet forwarding============| | |
|<---------FNA with NAACCK-------------| | |
|-----------------------LBU------------------------>| |
|<----------------------LBA-------------------------| |
|-------------------------------BU------------------------------>|
|<------------------------------BA-------------------------------|
| | | | | |
Figure 2 : Predictive Mode of Macro Mobility Handover
3.3. Operation of the Reactive Macro Mobility Mode
The reactive mode of macro mobility handover is analogous to the
reactive mode of FMIPv6. A MN performs the reactive mode of operation
in order to solve the various erroneous situations. Similarly, the
fast macro mobility handover is needed to solve the various erroneous
cases. The reactive mode of macro mobility handover would be the
solution to improve the fast handover operation.
In the reactive mode of macro mobility handover, if the MN carries
out the layer 2 handover before completing the fast binding
operation, which the MN does not send or receive the FBU or FBAck
messages, the MN would convert the fast handover operation into the
reactive mode of macro mobility handover.
The MN receives PrRtAdv messages periodically or requests the
messages by sending RtSolPr messages, as mentioned section 3.2. Due
to the MN's rapid movement from the previous link to the new one or
the erroneous situation, the MN could not send or receive the FBU
message or FBAck message prior to the layer 2 handover. In this case,
the macro mobility handover is the reactive mode. After the layer 2
handover, the MN should firstly generate a special FNA message. This
Y. Mun, et al. Expires June, 2007 [Page 8]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
FNA message is defined in [2]. The MN sends the FNA message with the
FBU message to the nAR. The nAR received the FNA message included the
FBU message should perform the DAD operation for the addresses of the
MN. At the same time, the nAR sends FBU message to the pAR of the MN.
The pAR sends a FBAck message in reply to the FBU message and then
forwards the packets of the MN to the nAR. Therefore, the MN can
receive the packets transferred to the pAR from the nAR without
packet loss.
Finally, the MN also should perform both the local binding operation
by using LBU and LBA messages and the home bidning operation by using
BU and BA messages with its HA. The procedure of the reactive mode of
macro mobility handover is shown as Figure 3.
MN pAR pMAP nAR nMAP HA
| | | | | |
|--RtSolPR-->| | | | |
|<--PrRtAdv--| | | | |
disconnect | | | | |
| | | | | |
connect | | | | |
|-------------FNA[FBU]---------------->| | |
| | | +nLCoA DAD | |
| |<---------FBU------------| | |
| |----------FBAck----------| | |
| |====Packet forwarding===>| | |
|<=========Packet forwarding===========| | |
|-----------------------LBU------------------------>| |
|<----------------------LBA-------------------------| |
|-------------------------------BU------------------------------>|
|<------------------------------BA-------------------------------|
| | | | | |
Figure 3 : Reactive Macro Mobility Mode
4. Security Considerations
This document describes the fast macro mobility handovers in HMIPv6
environment. The two handover modes represented in this document
assumes that the edge access routers within a MAP domain have
association with adjacent edge access routers in other MAP domains.
Due to this assumption, the association between each MAP domain
considers possible security theats caused by communicating between
two edge routers belongs to different MAP domains. Also, this fast
handover methods have the security consideration of [1], [2] and [3].
Y. Mun, et al. Expires June, 2007 [Page 9]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 2006
5. References
[1] D. Johnson, C. E. Perkins, and J. Arkko, "Mobility Support in
IPv6", Request for Comments (Proposed Standard) 3775, Internet
Engineering Task Force, June 2004.
[2] R. Koodli, (editor), "Fast Handovers for Mobile IPv6", Request
for Comments (Experimental) 4068, Internet Engineering Task
Force, July 2005.
[3] H. Soliman, C. Catelluccia, K. Malki, L. Bellier, "Hierarchical
Mobile IPv6 mobility management (HMIPv6)", Request for Comments
(Experimental) 4140, Internet Engineering Task Force, August
2005.
[4] T. Narten, E. Nordmark, and W. Simpson, "Neigbhor Discovery for
IP Version 6 (IPv6)", Request for Comments 2461, Internet
Engineering Task Force, December 1998.
[5] D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery Proxies
(ND Proxy)", Request for Comments 4389, Internet Engineering
Task Force, April 2006.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6. Authors' Addresses
Youngsong Mun, Professor
Department of Computing, Soongsil University,
#1-1 SangDo-5 Dong, DongJak-Gu,
Seoul, 156-743
Korea
Phone: +82-2-820-0676
Fax: +82-2-822-2236
E-mail: mun@computing.ssu.ac.kr
Kyunghye Lee
Department of Computing, Soongsil University,
#1-1 SangDo-5 Dong, DongJak-Gu,
Seoul, 156-743
Korea
Phone: +82-2-812-0689
Fax: +82-2-822-2236
E-mail: lkhmymi@sunny.ssu.ac.kr
Y. Mun, et al. Expires June, 2007 [Page10]
Internet-Draft Fast Handovers for Macro Mobility in HMIPv6 December 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 IETF's procedures with respect to rights in IETF 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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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 IETF Trust (2007). 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.
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, THE IETF TRUST 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.
Y. Mun, et al. Expires June, 2007 [Page11]