Network Side Fast handover Support in Mobile IPv6

HeeYoung Jung and HongSeok Jeon

Protocol Engineering Center, Electronics and Telecommunications Research Institute
hyjung@etri.re.kr

bi-directional tunnel between a previous access router and new

access router. The proposed fast handover scheme has simpler
procedure than the existing FMIPv6 mostly uses the existing

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.
The structure of this paper is as follows. Section 2 describes
the overview of the proposed protocol. In Section 3, we
.
. d
.
explain the more detal procedure. Section 4 shows the
changes of the proposed protocol from existing protocol and
finally this paper is concluded in Section 5.

Keywords - Mobile IPv6, fast handover, network control,

real-time service.

2. Protocol Overview
2.1 Basic assumption

Abstract This paper 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 to users by using only networks entities.

To achieve network side fast handover, this paper basically uses

messages.

This paper 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

1. Introduction

Mobile IPv6 [1] 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 [2] 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 [2].
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 paper provides a solution to support the fast handover
by using only network entities as the name of NS-FMIPv6. To
achieve it, this paper basically uses a bi-directional tunnel
between PAR and NAR. This approach is very similar to the
post-registration method described in [3] 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 [4] for mobile nodes. Moreover the procedure of

ISBN 89-5519-129-4

This paper also assumes following the same reference

architecture as in FMIPV6.

LU

PAR

NAR

MN

Figure 1. Reference Architecture

2.2 Design considerations

In NS-FMIPv6, the first consideration is to make the
handover support to MiNs 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.

- 1997 -

Feb. 20-22, 2006 ICA0T2006

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.

(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.

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.

(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

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.

NAR.

(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.

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 ofthe existing FMIPv6 because these
messages are used just for the exchange of information of MN
and possibly for tunnel establishment.

(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.

3. Protocol Operations
Figure 2 shows the handover procedure in NS-FMIPv6.
MN

PAR

HA/CN (or MAP)

NAR

(7) After configuring new CoA, the MN performs binding

update to HA/CN according to normal Mobile IPv6
procedure.

Pre-HO
HI

4.

HACK

Forwarding

lZZZZ~ |
Fast RA &

Packet delivery

Fast RA &

BU

_
Figure 2. Handover Procedure

The descriptions for each step are given as follows.

ISBN 89-5519-129-4

NS-FMIPv6 basically follows the procedures and message

formats of FMIPv6. However, several changes are needed to

LUachieve network only solution.

LU

Op-DAD

(optional)

Changes from FMIPv6

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.
oTneigpiti

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.

- 1998 -

Feb. 20-22, 2006 ICA0T2006

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
attacment
hrouh LU trigger,
rigge, th
ends unsolicited
nsolcitedfast
attachment
through
the NAR sends
fast

RA to the MN.
o

REFERENCE

[1] D. Johnson, et al., "Mobility Support in IPv6," RFC 3775, June 2004.
[2] 2005.
R. Koodli, et al., "Fast Handovers for Mobile IPv6," RFC 4068, July

[3] K. El Malki, "Low Latency Handoffs in Mobile IPv4," IETF draft

draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt, June 2004
[4] N. Moore, "Optimistic Duplicate Address Detection for IPv6,"

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.

draft-ietf-ipv6-optimistic-dad-05, February 2005.

[5] Mohamed Khalil et al., "Fast Router advertisement," IETF draft

draft-mlkhalil-ipv6-fastra-06.txt, Feburay 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 ofbi-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.)

5. Conclusions
This paper proposed a solution to support the fast handover
by using only network entities as the name of NS-FMIPv6.
The proposed protocols may be very helpful for network

operators who want to realize fast handover in their networks

because it could be implemented only by using only network
side entities. Moreover NS-FMIPv6 does not need additional
messages except existing FMIPv6 messages so that it could be
easily evolved from FMIPv6 based networks.

ISBN 89-5519-129-4

- 1999 -

Feb. 20-22, 2006 ICA0T2006