Network Side Fast handover Support in Mobile IPv6HeeYoung Jung and HongSeok Jeon

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

Abstract This paper addresses a network side solution of fast NS-FMIPV6 is much simpler than it of the existing FMIPv6handover in Mobile IPv6. Existing FMIPv6 basically assumes the because it does not require the involvement of MNs. It isinvolvement of mobile nodes in handover procedure. However, in expected that the simpler procedure may result in lowersome cases, it may not be easy to realize fast handover function handover latency.into all mobile nodes. In the case, a network operator may want The structure of this paper is as follows. Section 2 describesto provide fast handover to users by using only networks entities. the overview of the proposed protocol. In Section 3, weTo achieve network side fast handover, this paper basically uses . . . dbi-directional tunnel between a previous access router and new explain the more detal procedure. Section 4 shows theaccess router. The proposed fast handover scheme has simpler changes of the proposed protocol from existing protocol andprocedure than the existing FMIPv6 mostly uses the existing finally this paper is concluded in Section 5.messages.

2. Protocol OverviewKeywords - Mobile IPv6, fast handover, network control,

real-time service. 2.1 Basic assumption1. Introduction This paper basically assumes followings.

- Pre-handover trigger (PRE-HO), which indicatesimminent layer 2 handover, and link up trigger (LU) are

Mobile IPv6 [1] was developed to support mobility in IPv6 availablenetwork. Mobile IPv6 can provide service continuity across - Network entities such as PAR and NAR can aware thesesubnets to mobile nodes (MN) through binding update (BU) to triggers but MNs may notHA/CN. However it was being reported that Mobile IPv6 may - Mobile nodes have only the handover functions specifiedhave difficulty with supporting real-time services because of in Mobile IPv6 and optionally optimistic DADits latency during handover. Considering the requirements of - Collision probability is low enough to use optimistic DADnext generation IP network, the support for the real-timeservices like VoIP would be a crucial requirement. This paper also assumes following the same referenceAccordingly some protocols are being suggested to address architecture as in FMIPV6.this problem.FMIPv6 [2] is a typical solution to solve the handover

latency problem of Mobile IPv6. FMIPv6 realizes the fasthandover by using link layer triggers, new CoApre-configuration, and tunneling. However it is noted thatFMIPv6 essentially assumes the involvement of mobile nodesin handover procedure. That is, in FMIPv6, a mobile nodeshould performs several works related to handover such as theawareness of link layer triggers, solicitation ofproxy RA, newCoA pre-configuration, sending of F-BU to PAR and FNA toNAR as specified in [2]. LU

However, in some cases, it may not be easy for networkoperators to implement the handover function into all mobile PAR v NARnodes in economical or practical way. In this case, it will bevery hopeful ifwe can realize the fast handover by using onlynetwork side entities, e.g. PAR and NAR, etc. MN

This paper provides a solution to support the fast handover Figure 1. Reference Architectureby using only network entities as the name ofNS-FMIPv6. Toachieve it, this paper basically uses a bi-directional tunnel 2.2 Design considerationsbetween PAR and NAR. This approach is very similar to the In NS-FMIPv6, the first consideration is to make thepost-registration method described in [3] and additionally handover support to MiNs possible even if only Mobile IPv6some schemes considering IPv6 characteristics are added. and optionally op-DAD are implemented in them. ThisNote that NS-FMIPv6 does not require handover consideration may be one of important requirements in thefunctionalities except those in Mobile IPv6 and optionally deployment aspect for fast handover schemes in Mobile IPv6.op-DAD [4] for mobile nodes. Moreover the procedure of

ISBN 89-5519-129-4 - 1997 - Feb. 20-22, 2006 ICA0T2006

In FMIPv6, the handover latency of Mobile IPv6 was (1) PAR receives pre-ho trigger. The trigger indicates thatclassified into three main delay factors such as movement link layer handover of an MN is imminent and includesdetection, CoA configuration and binding update. Basically the link layer address (e.g. MAC address) of the MN andNS-FMIPv6 follows the approach specified in FMIPv6. NAR. It is assumed that PAR already has the mappingHowever the process regarding CoA configuration is a little between link layer address and IP address of the MN anddifferent because the process highly requires the involvement NAR.of MNs.

The considerations on each delay factor in NS-FMIPv6 are (2) PAR sends HI message to NAR to negotiatedescribed in the followings. bi-directional tunnel with NAR for the MN. The HI

message includes link layer address of the MN ando Movement detection delay previous CoA (PCoA) as specified in FMIPv6.NS-FMIPv6 uses the same approach as FMIPv6. That is, it

needs pre-handover trigger (PRE-HO), which indicates (3) NAR replies with HACK which includes the result forimminent link layer handover, and link up trigger (LU), which bi-directional tunnel negotiation. Also NAR creates hostinforms the establishment of new link at NAR for quick routing entry for the PCoA of the MN.movement detection. However networks entities aware thesetrigger but MNs may not. (4) If PAR received HACK and its result is successful, it

starts forwarding the packet destined to the MN towardo CoA configuration delay NAR.NS-FMIPv6 does not support new CoA pre-configuration in

order to keep the independency with MNs. Therefore (5) When NAR is informed that new link to the MN isadditional schemes may be needed to support fast CoA established after the completion of link layer handoverconfiguration in NAR. through LU trigger, NAR immediately unicasts (or

muticasts) RA to the MN. Note that the RA is differento Binding update delay from existing fast RA [7] in the point that it is unsolicitedBi-directional tunnel will be used to prevent service router advertisement. The unicast ofRA is chosen for air

interruption during link change and binding update like resource efficiency. If an air interface naturally supportsspecified in FMIPv6. However the HI/HACK messages are a broadcast, Multicast RA also can be used.little different from them ofthe existing FMIPv6 because these Simultaneously, the NAR deliveries the buffered packetmessages are used just for the exchange of information ofMN to the MNs using the host entry for the MN.and possibly for tunnel establishment.

(6) If the network is being well managed and the3. Protocol Operations probability of address collision is very low, then the MN

can configure new address using the fast RA withoutFigure 2 shows the handover procedure in NS-FMIPv6. DAD procedure. Optionally, Op-DAD could be used to

enhance the stability of operation.MN PAR NAR HA/CN (or MAP)

(7) After configuring new CoA, the MN performs bindingupdate to HA/CN according to normal Mobile IPv6

Pre-HO procedure.HI

4. Changes from FMIPv6HACK

NS-FMIPv6 basically follows the procedures and messageForwarding formats of FMIPv6. However, several changes are needed tolZZZZ~ | Fast RA & LUachieve network only solution.Fast RA& LU

Packet delivery o Triggering of HI messageOp-DAD In FMIPv6, HI message is normally triggered by FBU(optional) message. On the other hand, the HI message in NS-FMIPv6 is

BU _ sent from PAR to NAR ifPRE-HO trigger is informed to PARbecause it does not assume the triggering message from MNs.

Figure 2. Handover Procedure oTneigpiti AIn FMIPv6, the tunnel end point in NAR is NCoA. However,it is noted that NCoA is not pre-configured in NS-FMIPv6.

The descriptions for each step are given as follows. Therefore the end point in NS-FMIPv6 should be changed toNAR. To deliver the packets destine to PCoA, NAR also hasto prepare host routing entry for the PCoA in advance.

ISBN 89-5519-129-4 - 1998 - Feb. 20-22, 2006 ICA0T2006

o NAR's awareness of attaching ofMN REFERENCEIn FMIPv6, NAR is aware of attaching of MN by FNA

message from the MN. On the other hand, since it is assumed [1] D. Johnson, et al., "Mobility Support in IPv6," RFC 3775, June 2004.in NS-FMIPv6 that the NAR can quickly recognize the [2] R. Koodli, et al., "Fast Handovers for Mobile IPv6," RFC 4068, July

attacment hrouhLU rigge, th NAR ends nsolcitedfast 2005.attachment throughLUtrigger, theNARsends unsolicited fast [3] K. El Malki, "Low Latency Handoffs in Mobile IPv4," IETF draftRA to the MN. draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt, June 2004

[4] N. Moore, "Optimistic Duplicate Address Detection for IPv6,"o Changed in HI/HACK messages draft-ietf-ipv6-optimistic-dad-05, February 2005.[5] Mohamed Khalil et al., "Fast Router advertisement," IETF draftNS-FMIPv6 uses HI/HACK messages only for the draft-mlkhalil-ipv6-fastra-06.txt, Feburay 2005

information exchange for the moving MN and the tunnelestablishment for packet forwarding, not for the verification ofpre-configured NCoA. Therefore some minor changes arerequired in the existing HI/HACK messages.

- Handover Initiate (HI) messageThe HI message for NS-FMIPv6 is identical to FMIPv6 HI

excepting Code value. The HI for NS-FMIPv6 newly defines acode value of 2 in order for PAR to inform NAR thatNS-FMIPv6 is now working.

Code0: 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 ofNS-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 ofMNPrevious Care of AddressNew Care of Address (it is not necessary in NS-FMIPv6)

It might be required that the lifetime ofbi-directional tunnelis conveyed by HI, since there is not FBU message inNS-FMIPv6.

- Handover Acknowledge (HAck)The HAck for NS-FMIPv6 is the same as that of FMIPv6.

However the consideration on the following option shouldbe given.

Valid Options:New Care of Address (Hack of S-FMIPv6 does notinclude this option because 'S' bit in HI is not set.)

5. Conclusions

This paper proposed a solution to support the fast handoverby using only network entities as the name of NS-FMIPv6.The proposed protocols may be very helpful for networkoperators who want to realize fast handover in their networksbecause it could be implemented only by using only networkside entities. Moreover NS-FMIPv6 does not need additionalmessages except existing FMIPv6 messages so that it could beeasily evolved from FMIPv6 based networks.

ISBN 89-5519-129-4 - 1999 - Feb. 20-22, 2006 ICA0T2006