Internet DRAFT - draft-jung-mipshop-nsfho
draft-jung-mipshop-nsfho
Internet Draft HeeYoung Jung, ETRI
Internet Engineering Task Force HongSeok Jeon, ETRI
draft-jung-mipshop-nsfho-00.txt
Expires February 2006
August 2005
Network Side Fast Handover in Mobile IPv6
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
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document addresses a network side solution of fast handover in
Mobile IPv6. Existing FMIPv6 basically assumes the involvement of
mobile nodes in handover procedure. However, in some cases, it may not
be easy to realize fast handover function into all mobile nodes. In
the case, a network operator may want to provide fast handover service
to users by using only networks entities. To achieve network side fast
handover, this document basically uses bi-directional tunnel between a
previous access router and new access router. The proposed fast
handover scheme has simpler procedure than the existing FMIPv6 and
mostly uses the existing messages.
Jung, et al. Expires February 2006 [Page 1]
Internet Draft Network Side Fast Handover June 2005
Table of Contents
1. Motivation....................................................3
2. Terminology...................................................3
3. Protocol overview.............................................4
3.1 Assumptions...............................................4
3.2 Design considerations.....................................5
4. Protocol Operations...........................................5
5. Changes from FMIPv6...........................................7
6. Security Considerations.......................................8
7. Acknowledgement...............................................8
8. References....................................................9
Author's Addresses...............................................9
Full Copyright Statement.........................................9
Intellectual Property...........................................10
Jung, et al. Expires February 2006 [Page 2]
Internet Draft Network Side Fast Handover June 2005
1. Motivation
Mobile IPv6 [3] was developed to support mobility in IPv6 network.
Mobile IPv6 can provide service continuity across subnets to mobile
nodes (MN) through binding update (BU) to HA/CN. However it was being
reported that Mobile IPv6 may have difficulty with supporting real-
time services because of its latency during handover. Considering the
requirements of next generation IP network, the support for the real-
time services like VoIP would be a crucial requirement. Accordingly
some protocols are being suggested to address this problem.
FMIPv6 [4] is a typical solution to solve the handover latency problem
of Mobile IPv6. FMIPv6 realizes the fast handover by using link layer
triggers, new CoA pre-configuration, and tunneling. However it is
noted that FMIPv6 essentially assumes the involvement of mobile nodes
in handover procedure. That is, in FMIPv6, a mobile node should
performs several works related to handover such as the awareness of
link layer triggers, solicitation of proxy RA, new CoA pre-
configuration, sending of F-BU to PAR and FNA to NAR as specified in
[4].
However, in some cases, it may not be easy for network operators to
implement the handover function into all mobile nodes in economical or
practical way. In this case, it will be very hopeful if we can realize
the fast handover by using only network side entities, e.g. PAR and
NAR, etc.
This document provides a solution to support the fast handover by
using only network entities as the name of NS-FMIPv6. To achieve it,
this document basically uses a bi-directional tunnel between PAR and
NAR. This approach is very similar to the post-registration method
described in [5] and additionally some schemes considering IPv6
characteristics are added. Note that NS-FMIPv6 does not require
handover functionalities except those in Mobile IPv6 and optionally
op-DAD [6] for mobile nodes. Moreover the procedure of NS-FMIPV6 is
much simpler than it of the existing FMIPv6 because it does not
require the involvement of MNs. It is expected that the simpler
procedure may result in lower handover latency.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
This document uses the same terminologies described in the MIPv6 [3]
and FMIPv6 [4] documents.
Jung, et al. Expires February 2006 [Page 3]
Internet Draft Network Side Fast Handover June 2005
3. Protocol overview
3.1 Assumptions
This document basically assumes followings.
- Pre-handover trigger (PRE-HO), which indicates imminent layer 2
handover, and link up trigger (LU) are available
- Network entities such as PAR and NAR can aware these triggers but
MNs may not
- Mobile nodes have only the handover functions specified in Mobile
IPv6 and optionally optimistic DAD
- Collision probability is low enough to use optimistic DAD
This document also assumes following the same reference architecture
as in FMIPV6.
+-----+ +----+
| HA | | CN |
+-----+ +----+
| |
+-----+ +-----+
| |
+============+
| |
| IP Network |
| |
+============+
| |
+-------+ +------+
| |
+-----+ +-----+
Pre-HO ~> | PAR | | NAR |<~ LU
+-----+ +-----+
+----+
| MN | ---------->
+----+ Movement
Figure 1: Reference Architecture
Jung, et al. Expires February 2006 [Page 4]
Internet Draft Network Side Fast Handover June 2005
3.2 Design considerations
In NS-FMIPv6, the first consideration is to make the handover support
to MNs possible even if only Mobile IPv6 and optionally op-DAD are
implemented in them. This consideration may be one of important
requirements in the deployment aspect for fast handover schemes in
Mobile IPv6.
In FMIPv6, the handover latency of Mobile IPv6 was classified into
three main delay factors such as movement detection, CoA configuration
and binding update. Basically NS-FMIPv6 follows the approach specified
in FMIPv6. However the process regarding CoA configuration is a little
different because the process highly requires the involvement of MNs.
The considerations on each delay factor in NS-FMIPv6 are described in
the followings.
o Movement detection delay
NS-FMIPv6 uses the same approach as FMIPv6. That is, it needs pre-
handover trigger (PRE-HO), which indicates imminent link layer
handover, and link up trigger (LU), which informs the establishment of
new link at NAR for quick movement detection. However networks
entities aware these trigger but MNs may not.
o CoA configuration delay
NS-FMIPv6 does not support new CoA pre-configuration in order to keep
the independency with MNs. Therefore additional schemes may be needed
to support fast CoA configuration in NAR.
o Binding update delay
Bi-directional tunnel will be used to prevent service interruption
during link change and binding update like specified in FMIPv6.
However the HI/HACK messages are a little different from them of the
existing FMIPv6 because these messages are used just for the exchange
of information of MN and possibly for tunnel establishment.
4. Protocol Operations
Figure 2 shows the handover procedure in NS-FMIPv6.
Jung, et al. Expires February 2006 [Page 5]
Internet Draft Network Side Fast Handover June 2005
MN PAR NAR HA/CN(or MAP)
| | | |
| Pre-HO| | |
| ==>| | |
| | HI | |
| |---------->| |
| | | |
| | HACK | |
| |<----------| |
| | | |
| | Forwarding| |
| |==========>| |
| | | |
| | |<== LU |
| fast RA & | |
| Packet delivery | |
|<----------------------| |
| | | |
@@@ op-DAD(optional) | |
| | | |
| BU | | |
|---------------------------------->|
| | | |
| | | |
Figure 2: Handover Procedure
The descriptions for each step are given as follows.
(1) PAR receives pre-ho trigger. The trigger indicates that link layer
handover of an MN is imminent and includes the link layer address
(e.g. MAC address) of the MN and NAR. It is assumed that PAR
already has the mapping between link layer address and IP address
of the MN and NAR.
(2) PAR sends HI message to NAR to negotiate bi-directional tunnel
with NAR for the MN. The HI message includes link layer address of
the MN and previous CoA (PCoA) as specified in FMIPv6.
(3) NAR replies with HACK which includes the result for bi-directional
tunnel negotiation. Also NAR creates host routing entry for the
PCoA of the MN.
(4) If PAR received HACK and its result is successful, it starts
forwarding the packet destined to the MN toward NAR.
Jung, et al. Expires February 2006 [Page 6]
Internet Draft Network Side Fast Handover June 2005
(5) When NAR is informed that new link to the MN is established after
the completion of link layer handover through LU trigger, NAR
immediately unicasts (or muticasts) RA to the MN. Note that the RA
is different from existing fast RA [7] in the point that it is
unsolicited router advertisement. The unicast of RA is chosen for
air resource efficiency. If an air interface naturally supports
broadcast, Multicast RA also can be used. Simultaneously, the NAR
deliveries the buffered packet to the MNs using the host entry for
the MN.
(6) If the network is being well managed and the probability of
address collision is very low, then the MN can configure new
address using the fast RA without DAD procedure. Optionally, Op-
DAD could be used to enhance the stability of operation.
(7) After configuring new CoA, the MN performs binding update to HA/CN
according to normal Mobile IPv6 procedure.
5. Changes from FMIPv6
NS-FMIPv6 basically follows the procedures and message formats of
FMIPv6. However, several changes are needed to achieve network only
solution.
o Triggering of HI message
In FMIPv6, HI message is normally triggered by FBU message. On the
other hand, the HI message in NS-FMIPv6 is sent from PAR to NAR if
PRE-HO trigger is informed to PAR because it does not assume the
triggering message from MNs.
o Tunneling point in NAR
In FMIPv6, the tunnel end point in NAR is NCoA. However, it is noted
that NCoA is not pre-configured in NS-FMIPv6. Therefore the end point
in NS-FMIPv6 should be changed to NAR. To deliver the packets destine
to PCoA, NAR also has to prepare host routing entry for the PCoA in
advance.
o NAR's awareness of attaching of MN
In FMIPv6, NAR is aware of attaching of MN by FNA message from the MN.
On the other hand, since it is assumed in NS-FMIPv6 that the NAR can
quickly recognize the attachment through LU trigger, the NAR sends
unsolicited fast RA to the MN.
o Changed in HI/HACK messages
NS-FMIPv6 uses HI/HACK messages only for the information exchange for
the moving MN and the tunnel establishment for packet forwarding, not
for the verification of pre-configured NCoA. Therefore some minor
changes are required in the existing HI/HACK messages.
Jung, et al. Expires February 2006 [Page 7]
Internet Draft Network Side Fast Handover June 2005
- Handover Initiate (HI) message
The HI message for NS-FMIPv6 is identical to FMIPv6 HI excepting Code
value. The HI for NS-FMIPv6 newly defines a code value of 2 in order
for PAR to inform NAR that NS-FMIPv6 is now working.
Code
0: when PAR processes an FBU with PCoA as source IP address.
1: when PAR processes an FBU whose source IP address is not PCoA.
2: When PAR processes NS-FMIPv6, not pure FMIPv6.
Also, two flags should be set as follows.
S: This flag MUST be 0 because HI of NS-FMIPv6 does not include NCoA.
U: This flag MUST be 1 in order NAR starts to buffer packets addressed
to MN.
Valid Option:
Link-layer address of MN
Previous Care of Address
New Care of Address (it is not necessary in NS-FMIPv6)
It might be required that the lifetime of bi-directional tunnel is
conveyed by HI, since there is not FBU message in NS-FMIPv6.
- Handover Acknowledge (HAck)
The HAck for NS-FMIPv6 is the same as that of FMIPv6. However the
consideration on the following option should be given.
Valid Options:
New Care of Address (Hack of S-FMIPv6 does not include this option
because 'S' bit in HI is not set.)
6. Security Considerations
The security issues of NS-FMIPv6 are basically in line with it of
FMIPv6. Note that the security of NS-FMIPv6 could be simpler than
FMIPv6 because it does not need the security consideration over air
interface like in FMIPv6.
7. Acknowledgement
The Authors would like to give special thanks to JungHoon Jee for his
valuable comments and discussion for enhancing the NS-FMIPv6.
Jung, et al. Expires February 2006 [Page 8]
Internet Draft Network Side Fast Handover June 2005
8. References
[1] S. Bradner, "Intellectual Property Rights in IETF Technology," BCP
79, RFC 3668, February 2004.
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," BCP, RFC 2119, March 1997.
[3] D. Johnson, et al., "Mobility Support in IPv6," RFC 3775, June
2004.
[4] R. Koodli, et al., "Fast Handovers for Mobile IPv6," RFC 4068,
July 2005.
[5] K. El Malki, "Low Latency Handoffs in Mobile IPv4," IETF draft
draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt, June 2004
[6] N. Moore, "Optimistic Duplicate Address Detection for IPv6,"
draft-ietf-ipv6-optimistic-dad-05, February 2005.
[7] Mohamed Khalil et al., "Fast Router advertisement," IETF draft
draft-mkhalil-ipv6-fastra-06.txt, Feburay 2005
Author's Addresses
HeeYoung Jung
hyjung@etri.re.kr
Protocol Engineering Center, ETRI
HongSeok Jeon
jeonhs@etri.re.kr
Protocol Engineering Center, ETRI
Full 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.
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.
Jung, et al. Expires February 2006 [Page 9]
Internet Draft Network Side Fast Handover June 2005
Intellectual Property
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.
Jung, et al. Expires February 2006 [Page 10]
