Internet DRAFT - draft-mun-mipshop-fhmacro
draft-mun-mipshop-fhmacro
Mipshop Working Group Youngsong Mun
Internet-Draft Kyunghye Lee
Expires: March 22, 2012 Soongsil University
September 22, 2011
Fast Macro Mobility Handovers in HMIPv6
draft-mun-mipshop-fhmacro-06.txt
Abstract
In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from
one MAP domain to another can experience both long handover latency
and packet loss due to the distance between the two MAPs. To solve
the problems, this document describes two fast handover schemes that
support fast macro mobility handover. These fast handover schemes can
reduce both the handover latency and the pakcet loss. The schemes
described in this document adopt the fast handover of FMIPv6 protocol
to the edge access routers in MAP domains. The schemes support two
fast handover modes for macro mobility handover in HMIPv6.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 22, 2012.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
mun Expires March 22, 2012 [Page 1]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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
mun Expires March 22, 2012 [Page 2]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
1. Introduction
Increasingly, the wireless access services and 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 environment. 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) and the hierarchical mobile IPv6
protocol have proposed.
To reduce the handover latency and the packet loss, FMIPv6 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, fast handover to the MN which moves between access routers.
HMIPv6 introduces 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
both the long handover latency and the packet loss.
mun Expires March 22, 2012 [Page 3]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
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.
New Regional Care-of Address (nRCoA)
mun Expires March 22, 2012 [Page 4]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
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.
mun Expires March 22, 2012 [Page 5]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
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
mun Expires March 22, 2012 [Page 6]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
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.
mun Expires March 22, 2012 [Page 7]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
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
mun Expires March 22, 2012 [Page 8]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
handover, the MN should firstly generate a special FNA message. This
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].
mun Expires March 22, 2012 [Page 9]
Internet-Draft Macro Fast Handover in HMIPv6 September 2011
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
mun Expires March 22, 2012 [Page 10]
