Chonbuk National University, DCS Lab presented by ghcho 1 Mobile IP, and Micro Mobility Gihwan Cho [email protected].

Chonbuk National University, DCS Lab presented by ghcho1

Mobile IP, and Micro Mobility

Gihwan Cho

[email protected]


Presentation Outline

Our talk includes Mobile IP, and Mobile IP in IPv6 micro mobility variants

HAWAII Cellular IP fast handoff proactive, anchor handoff hierarchical handoff paging extension

as a conclusion


Mobile IP

Now, let’s talk about Mobile IP, and Mobile IP in IPv6 micro mobility variants


as a conclusion


Why Mobile IP ? (I)

Background Internet explosion increasing the mobile workforce, and mobile users increased reliance on networked computing prevailing the portable devices, technologies

IPv4 routing considerations two level hierarchical address structure (network id, host id) longest prefix (network id) matching based static routing

host id based routing may produce the scalability problem if a host moves around, the network id should be changed! then, the routing scheme to the MH may not applied!!

clearly, a corresponding host does not know (need not – by network layering concept) the moving host’s current network id


Why Mobile IP ? (II)

So, which layer should take charge of host mobility? applications, transport? IP? NI? sure, IP could give to higher level protocols the abstraction that the

network address remains unchanged, therefore Mobile IP

Mobile IP allows users of portable computers to move form one place to another and yet maintain transparent network access through the wireless link

Initially, it does not assumed in design phase, for the host mobility nature, so much appropriated to macro mobility however, in the practical point of view, most moving entities have

some degree of moving pattern, that is micro mobility family


Protocol Overview (I) [1][2]

Three steps with the protocol agent discovery: MAs may advertise their availability for they pro

vide service, or a newly arrived MH may send a solicitation to learn if any prospective agents are present ICMP router discovery [3]

registration: when an MH is away from home, it registers its care-of address with its HA UDP control messages [1] [2]

tunneling: datagrams sent to an MH is away from home must be tunneled to hide its home address from intervening routers encapsulation protocol [4][5]


Protocol Overview (II)

Correspondent Node

HA (HA)FA (FA)Mobile Node

Agent Solicitation

Agent Advertisement

Registration Request

Registration Request

Registration Reply

Registration Reply

Data sent

Data received

agent discovery

registration

tunneling


Protocol Overview (III)

Internet

Correspondent Node

HA

FA

FA

data paths (before registration)

Mobile Node

Mobile Node

host movingagent discovery

location registration

data paths (sent from MN)

packet tunneling

data paths (after registration)

tunnel


Triangle Routing on Mobile IP

Triangle routing is undesirable : Increased network utilization (sensitivity to network partition) Irregularity of performance variance

HomeAgent

FA

Internet Host

MH kMH k

Tunneling

Reply PathHome-based Location

Host Moving


Mobile IPv4 – revised (I)

Specification that the SPI of the MN-HA authentication extension is to be used as part of the data over which the authentication algorithm must be computed

Specification that FA may send advertisements at a rate faster than once per second, but must be chosen so that the advertisements do not burden the capacity of the local link

Specification that FAs should support reverse tunneling, and HAs must support decapsulation of reverse tunnels


Mobile IPv4 – revised (II)

Changed the pre-configuration requirements for the MHs to reflect its capability

An FA is not required to discard Registration Replies that have a home address field that does not match any pending Registration Request

Allowed registration to be authenticated by use of a security association between the MH and a suitable authentication entity acceptable to the HA noted that HMAC-MD5 should be considered for use in place of t

he “prefix+suffix” mode of MD5 as originally mandated in RFC 2002


Mobile IPv4 – revised (III)

Clarification that an MA should only put its own addresses into the initial list of routers in the mobility advertisement RFC 2002 suggests that an MA might advertise other default rou

ters

Specification that an MH must ignore reserved bits in Agent Advertisement, as opposed to discarding such advertisements in this way, new bits can be defined later, without affecting the a

bility for MHs to use the advertisements even when the newly defined bits are not understood


Mobile IPv4 – revised (IV)

Specification that the FA checks to make sure that the indicated HA does not belong to any of its network interface before relaying a Registration Request if the check fails, and the FA is not the MH’s HA, then the FA rej

ects the request with code 136

Specification that, while they are away from the home network, MHs must not broadcast ARP packets to find the MAC address of another internet node

Specification that an FA must not use broadcast ARP for an MHs MAC address on a foreign network it may obtain the MAC address by copying the information from

an Agent Solicitation or a Reg. Request transmitted from an MH


Mobile IPv4 – revised (V)

Specification that an FA’s ARP cache for the MH’s IP address must not be allowed to expire before the MH’s visitor list entry expires

Clarified that an HA must not make any changes to the way it performs proxy ARP after it rejects an invalid deregistration request

Specification that multi-homed HA must use the registered care-of address as the source address in the outer IP header of the encapsulated datagram

Inserted “T” bit into its proper place in the Registration Request message format




as a conclusion

Micro Mobility – HAWAII [6]


Overview Handoff Aware Wireless Access Internet Infrastructure (by Lucent)

domain-based approach for supporting mobility approach : most user mobility is local to a domain specialized path setup schemes

host-based routing entry Characteristics

reduce mobility related disruption to user application reduce the number of mobility related updated simplify QoS support improved reliability with soft-state transition provide macro mobility in conjunction with Mobile IP include the paging concept

IP Micro Mobility – HAWAII (I)


IP Micro Mobility – HAWAII (II)

Mobility support for inter-HAWAII domain : Mobile IP so, macro mobility

HAWAII protocol defines the mobility support for intra-HAWAII domain, so, micro mobility each router maintains a routing entry per moving host then, change only the corresponding entry on host moving as a result, in a domain, the overhead of top most router can be

distributed into the lower-level routers host handoff may support by

a forwarding scheme a non forwarding scheme


IP Micro Mobility – HAWAII (III)

Use path setup message to establish and update host-based routing entries in selective routers in the domain -> where, how, and which routers are updates?

Forwarding scheme : optimized for TDMA network update the forwarding entry from old BS to new BS

Non forwarding scheme : optimized for CDMA network update the forwarding entry from new BS to old BS

Other routers has no MH’s current location Forwarding entry must be updated in periodical, so soft s

tate update, to prevent its out-of-state situation refresh message


IP Micro Mobility – HAWAII (IV)


IP Micro Mobility – HAWAII (V)


Forwarding Path Setup


Non-Forwarding Path Setup


Network determines the exact location by paging to deliver packets “idle” MHs update the network less frequently than “active”MHs

network has only approximate location information for idle MHs

Paging


Hierarchy using Domain


Efficiency limit updates from the MH when idle to conserve battery power

Scalability push paging initiation closer to the base station

Reliability allow paging initiation to occur at any router/base station (no

single points of failure)

Flexibility allow for fixed, hierarchical, or user-defined paging areas

Paging Design Goals


Paging Support … HAWAII (I)


Paging Support … HAWAII (II)


Router Operation


When using FAs group set of FAs into multicast group previous FA initiates paging impact of previous FA failure

When operating without FAs paging initiated from HA globally visible multicast address or separate unicasts necessary

scalability is an issue

Paging with Mobile-IP




as a conclusion

Micro Mobility – Cellular IP [7]


Cellular IP is intended to: specify a protocol that allows routing IP datagrams to an MH provide local mobility and handoff support minimize packet losses with the location update delay interwork with Mobile IP to provide wide area mobility support

Design principles location information is stored in distributed data bases location information referring to an MH is created and updated b

y regular IP datagrams location information is stored as soft state location management strategy is separated between the idle MH

and the active MH

Cellular IP (CIP)


Protocol requirement a host connected to a cellular IP network must be able to send

IP datagram to hosts outside the cellular IP network datagrams arriving to a cellular IP network should be delivered

with high probability to the destination host datagram delivery in a cellular IP network should be take place

d without leaving the cellular IP network an MH migrating between cellular IP network must be to use M

obile IP for wide area mobility, that is, a host in a cellular IP network has a home address with a care-of-address

hosts inside a cellular IP network are identified by IP addresses, but these have no location significance

hosts outside the cellular IP network must not need any updating or enhancement, i.e. they must remain unware of the host’s current location inside the cellular IP network

Protocol Requirement


Global mobility with Mobile IP

Hierarchical Mobility Management (I)


Local mobility with cellular IP fast handoff within a mobile access network less load in the global Internet

Hierarchical Mobility Management (II)


Wireless Overlay Networks


Mobile Access Network


Protocol Overview (I)

Base stations periodically emit beacon signals to be locate the nearest base station by MHs

All IP packets transmitted by an MH are routed from the BS to the GW by hop-by-hop shortest path routing regardless of the destination address

Cellular IP nodes maintain routing cache packets transmitted by the MH create and update entries in each

node's cache, thus an cache entry maps the MH’s IP address to the interface through which the packet entered the node

The chain of cached mappings referring to a single MH constitutes a reverse path for downlink packets addressed to the same MH


Protocol Overview (II)

as the MH migrates, the chain always points to its current location because its uplink packets create new mappings and old mappings are automatically cleared after a soft state timeout

To prevent its mappings from timing out, an MH can periodically transmit control packets control packets are regular IP packets with empty payloads

MHs that are not actively transmitting or receiving data but want to be reachable for incoming packets, let their routing cache mappings time out but maintain paging cache mappings IP packets addressed to these MHs will be routed by paging cac

hes paging caches have a longer timeout value than routing caches

and are not necessarily maintained in every Node


Mobile IP vs. Cellular IP

Global mobility support vs. local fast smooth handoff


Uplink Path : Shortest Path


Uplink Packets Create Location Information


Downlink Packets (I)

Mobile IP’s centralized location management


Downlink Packets (II)

Cellular IP’s distributed location database


Control Packet in Uplink if no Data or a Move Detected


Handoff is Automatic


Idle Host Location Management Tradeoff


Location Management of Idle Hosts

Paging setup paging cache maintains in just some selected nodes broadcast if a node has not paging (and routing) cache paging cache is updated with a control packet, with longer

timeout and less frequently


Paging Cache Update with a move


Paging Route with Paging Cache


Cellular IP MH

Each MH has two states in legal, active and idle when the state changed from idle to active, it sends a route

update packet to the gateway if an MH is in the active state

the MH has to send a route update packet whenever it changes its current base station

if an MH is in the idle state the MH has to send a paging update packet whenever it

enters a new paging area or it meets a predefined period


Extensions to Cellular IP

During handoffs between base stations within the same paging area, idle MHs may remain silent, as paging is performed within the entire paging area


Cellular IP Considerations

In Summary distributed location management location information established by uplink IP packet soft state management location management of idle hosts is separated from active

hosts Advantages

simple, self-sufficient nodes simple mobility management : just send control packet if no data no control messaging at handoff soft states give built-in fault tolerance handoff or faults do not differ from normal operation

Any problems? Load from control packets ...




as a conclusion

Micro Mobility – Fast Handoff [8]


Fast handoffs overviews (I)

Fast handoffs are required in mobile IPv4 in order to limit the period of service disruption experienced by an MN

It can be usually achieved by anticipating the movement of MN by utilizing simultaneous bindings in order to send multiple copie

s of the traffic to potential MN movement locations

Simply, it is achieved by bicasting traffic to the previous FA and new FA while the MN moving between them both a flat and a hierarchical mobile IPv4 model are considered


Fast handoffs overviews (II)

The anticipation of the MN’s movement is achieved by tight coupling with layer 2 functionality which is dependent on

the type of access technology used

Fast handoffs coupled to the layer 2 limit the total handoff delay to the time needed to perform the

layer 2 handoff allow MN to initiate fast handoff through the previous FA without

having direct access to the new FA

Fast handoffs may be applied to Mobile IP by performing registrations with the HA using simultaneous

bindings


Simultaneous bindings (I)

Simultaneous bindings in MIPv4 may be achieved by setting the ‘S’ bit in the Mobile IP Registrati

on Request message sent by the MN cause the receiving agents(HA, GFA, regional FA, previous FA) t

o add a new binding for the MN without removing any which are existing

are likely to be useful when an MN using at least one wireless network interface moves within wireless transmission range of more than one FA

cause the HA to send multiple copies of data packets towards multiple FAs which may be in the same region or domain


Simultaneous bindings (II)

Internet

CN

HA

old FA

new FAMN

: bicasting

MN


Flat and Hierarchical MIPv4 model

A flat and a hierarchical (with GFA) MIPv4 model

MN

InternetHA CN

AP2

FA2FA1

AP1

GFAInternetHA

CN MN

AP2

FA2 FA1

AP1 AP3

FA3

Visited Domain


Flat Mobile IPv4 (FMIPv4) (I)

The wireless layer 2 technology allows the MN to be connected to multiple wireless access points simultaneously the MN may solicit advertisements from FAs before completing h

andoffs

The layer 2 handoff does not finished until the MN’s registration with the new FA which produces a simultaneous binding at the HA

Fast handoff requires the MN to receive new agent advertisements through the old AP to perform a registration with the new FA through the old AP


FMIPv4 (II)

Initiating fast handoffs through the old FA inter-FA solicitation piggy backing advertisements on layer 2 messaging

Inter-FA solicitation this solution assumes that the FA with which the MN is currently

registered is aware of the IP address of the new FA once the current FA is aware of the address of the new FA

the current FA will send the new FA an agent solicitation message

the new FA will reply to the current FA by sending it an agent advertisement, then the current FA will send the agent advertisement to the MN

MN will send a registration request to the new FA through old AP served by the current FA


FMIPv4 (III)

new FA

Inter-FA solicitation :

current FA1. Agent Solicitation

5. Registration Request

AP 3. Agent advertisement

2. Agent advertisement




MN


FMIPv4 (III)

Inter-FA solicitation :

3. Agent advertisement 5. Registration

request

6. Registration request

old FA new FA1. Agent solicitation

MN



InternetHA

GFA



old AP

new AP


FMIPv4 (IV)

Piggy-backing advertisements on layer 2 messaging it is assumed that when an layer 2 handoff is initiated, old AP and

new AP perform layer 2 messaging procedures to negotiate handoff

since the MN is not attached to new AP yet new FA is unaware of the IP address of the MN and cannot se

nd an advertisement to it it is necessary for the layer 2 procedures to interwork with MIP

once an layer 2 handoff is initiated, such that old AP and new AP are in communication, it is possible for new AP to solicit an advertisement from new FA and transfer it to old AP

when the advertisement is received by the MN, the MN can perform a registration directed to new FA even though the MN has no data-connection to new AP yet


FMIPv4 (V)

Piggy-backing advertisements on layer 2 messaging :

new FAold FA

5. Request registration

MN

2. Reply advertisement

1. Request advertisement



Internet

HA

GFA



new AP

old AP


Hierarchical Mobile IPv4 (HMIPv4) (I)

HMIPv4 allows a MN to perform registrations locally with a Gateway FA(GFA) in order to reduce the number of signaling messages to the home network it achieves a reduction in the signaling delay when a MN moves

between FAs within a domain MN may be attached directly to any FA within the hierarchy and

moves between FAs there may be multiple paths between MN and GFA

Triangle routing between nodes within the hierarchical domain is eliminated by direct routing through regional FAs or reduced by routing through the GFA


HMIPv4 (II)

HMIPv4 supplements with the following for Fat MIPv4 limitation of triangle routing for communication between hosts wit

hin the administrative domain fast handoffs within the administrative domain considerations on regional deregistration

Regional tunnel management allows Regional Registrations within an administrative domain in order to avoid always having to perform registrations through HA the GAF’s address always appears to the HA as the MN’s care o

f address some of the HA’s functionality is performed locally in the GFA


Regional Registration (I) : HMIPv4

When MN first arrives at a visited domain, it performs a registration with its home network

GFA

HA


Regional FA

MN



4. Registration Reply




Regional Registration (II) : HMIPv4

The Signaling message flow for RR

GFA

1. RR Request

New FA

MN

2. RR Request 3. RR Reply

4. RR Reply


Regional Registration (III) : HMIPv4

FA announces its presence via an agent advertisement message an agent advertisement message includes the corresponding

addresses in order between its own address(first) and the GFA address(last) in the Mobility Agent Advertisement (MAA) extension

Once the home agent has registered the GFA address as the care of address of MN, MN may perform RR

When MN receives an agent advertisement from FA, MN can perform a RR with this FA and GFA


Fast Handoffs (I) : HMIPv4

When MN receives an agent advertisement with a MAA extension, MN must be eager to perform new bindings be lazy in releasing existing bindings

MN may add a hierarchical FA extension to registration requests in order to identify the exact FA path if MN has at least one existing binding with a FA, additional simu

ltaneous RR performed

There are two ways that MN choices the appropriate HA address in the RR Request MAA extension advertises FA and GFA address only MAA extension advertises complete order of FAs in the branch


Fast Handoffs(II) : HMIPv4

MAA extension advertises FA and GFA address only it is assumed that there is always a single path from the MN to th

e GFA MN always performs RR using the GFA address as HA address

and the advertising FA as care of address as the RR request is relayed towards the GFA, each FA receivin

g it will check whether it has an existing binding with the MN and whether RR has the ‘S’ bit set to request for simultaneous bindings

if this is true and the RR is validated by the GFA, FAs activate the simultaneous binding upon receiving the RR Replay from the GFA

it is not necessary to advertise to the MN all of the FA addresses in hierarchical branch


Fast Handoffs(III) : HMIPv4

MAA extension advertises FA and GFA address only

2. RR Request

New FA

MN


5. RR Reply

GFA

1. Agent Advertisement

(MAA extension)


Fast Handoffs(IV) : HMIPv4

MAA extension advertises complete order of FAs in the branch where multiple regional FA levels, and multiple paths from the M

N to the GFA are present, it may be necessary for the MN to identify the common route FA using the complete list of FAs in the hierarchical branch

MN must cache MAA extensions for its active bindings when MN receives an advertisement from new FA which has a d

ifferent MAA extension, MN will be eager to perform a new binding

MN compares the IP address in the new MAA extension with the ones it has cached for its active binding

a regional FA receiving RR request with it’s own address as HA address may return a RR reply to the MN


Fast Handoffs(V) : HMIPv4

MAA extension advertises complete order of FAs in the branch

2. RR Request

New FA

MN

3. RR Request


6. RR Reply

7. RR Reply

GFA

1. Agent Advertisement

(MAA extension)




as a conclusion

Micro Mobility - Proactive, Anchor Handoff [9][10]


Proactive Handoff (I) [10]

Proactive handoff aims to limit handoff delay to the time needed to perform a L2 handoff

It is based on predicting the movement of MHs anticipating new points of attachment first, it completes L2 handoff then starts to forward data to the M

H it allows L3 registration to proceed finally, handoff control is driven by the network as opposed to M

H


Proactive Handoff (II)

Movement Detection when an FA is aware that an handoff is occurring at the link-

layer, a trigger is sent to the mobile IP protocol stack a source trigger is one that is obtained by the old FA once the

link layer detects that the MH is departing its coverage area a target trigger is one that is obtained by the new FA once the

link layer detects that the MH is arriving in its coverage area


Proactive Handoff (III)

Source trigger proactive handoff

Internet

nFA

MN

HA

oFA

MN

GFA

1. Handoff Request

2. Handoff Reply


4. Registration ReplyMove detect


Proactive Handoff (IV)

Target trigger proactive handoff

Internet

nFA

MN

HA

oFA

MN

GFA

1. Handoff Request

2. Handoff Reply



Move detect


Proactive Handoff (IV)

Functional components

FAAADHCPv6

SMM

MN

HA1 HA2 HAn

HAAADHCPv6

HMM

HA1 HA2 HAn

SMM : Serving Mobility ManagerHMM : Home Mobility Manager


Proactive Handoff (V)

Proactive intradomain handofftime

System Handoff Request

Handoff And

Context Trans

Request

DHCPv6Request

DHCPv6Res

Handoff And

Context Trans

Response

BUBA

System Handoff

Response

BU

BUBA

BA

BU BA

BU : Binding UpdateBA : Binding Ack.

CNn

Mobile Node

HAn

nSMM

DHCPv6

oSMM

HMM

HAm


Proactive Handoff (VI)

1. when the MN detects that it is moving to another new sub-network that belongs to the same domain of the current sub-network , it sends a System Handoff Request to the current SMM (oSMM)

2. the oSMM sends an handoff and Context Transfer Request to the new SMM (nSMM)

3. the nSMM allocates a new COA to the MN and returns back a handoff and Context Transfer Response to the oSMM

4. the oSMM allocates an HA for the MN to bicast the data destined to the MN to both old and new COA. The oSMM sends a System Handoff Response to the MN confirming the completion of the handoff process

5. when the MN receives the System Handoff Response from the oSMM and establishes a L2 connectivity with the new


Proactive Handoff (VII)

Proactive interdomain handoff Proactive interdomain handofftime

System Handoff Request

DHCPv6Req

DHCPv6Res.

BUBA

System Handoff

Res BU

BA

BU : Binding UpdateBA : Binding Ack.

Mobile Node

nSMM

DHCPv6

nFAAA

oFAAA

HAk

oSMM

HAAA

HMM

HA

AAan HAndoff And Context Trans Request

AAan HAndoff And Context Trans Res

RegReq

AAA Reg Req

RegReq RegRes

AAA Reg Res

Reg Res


Proactive Handoff (VIII)

1. when the MN detects that it is moving to a new sub-network that belongs to a different administrative domain, it sends a System Handoff request to the old SMM(oSMM)

2. the oSMM sends a AAan HAndoff and Context Transfer Request to the new SMM(nSMM) via the AAA infrastructure

3. the nSMM allocates new COA to the MN and returns back a AAA infrastructure

4. the oSMM allocates an HA for the MN to bicast the data destined to the MN to both old and new COA. The oSMM sends a System Handoff Response to the MN confirming the completion of the handoff process

5. when the MN receives the System Handoff Response from the oSMM and establishes a L2 connectivity with the new sub-network it sends a Registration Request to the nSMM


Proactive Handoff (IX)

6. the nSMM constructs a AAA Registration Request and sends it to the HAAA via the FAA

7. when the HAAA receives the AAA Registration Request, it attempts to authenticate the MN. If the MN’s authentication and authorization are affirmative, the request is forwarded to the HMM for further processing

8. the HMM updates the user state information. It then constructs a Registration Response message and subsequently forwards to the MN via the HAAA and the FAAA

9. once the MN receives a successful Registration Response from the network, it proceeds with the regular MIPv6 registration


Fast vs. Proactive (I)

Proactive

Internet

HA

GFA2

1. L2 handoff is completed

2. then, L3 registration is started

nFA

MN

oFA

MN

Layer 21

Layer 3

oAP nAP


Fast vs. Proactive (I)

Fast

Internet

HA

3. it is not sure whether L2 handoff has completed

2. Bi-Casting

1. L3 registration is completed, rather than L2 handoff

nFA

MN

oFA

MN

GFA

Layer 3

Layer 2

2

1

3. L2 handoff

oAPnAP


Anchor Handoff (I) [11]

Anchor handoff proposes a number of enhancements to ease local registration and global indirect registration

An MH authenticates with its HA during global registration and establishes a secure tunnel between the HA and FA

The FA then acts as anchor FA for future registrations So, only a local registration is necessary after handoff This rule holds as long as the MH moves within the same

domain between the visiting FA and the anchor FA


Anchor Handoff (II)

Local registration

Internet

FA1

MN

HA

FA2

MN

Tunnel

HomeNetwork

Visited Network

Anchor


Anchor Handoff (III)

Global indirect registration

Internet

FA1

MN

HA

FA2

MN

Tunnel

Visited Network

HomeNetwork

Anchor




as a conclusion

Micro Mobility – Hierarchical Handoff [12]


Hierarchical Mobile IP (I) [13]

Background in Mobile IP

a mobile node registers with its HA each time it changes care-of address

if the distance between the visited network and the home network of the mobile node is large the signaling delay for these registration may be long

it is solution for performing registrations locally in the visited domain : regional registrations

by registering locally the signaling delay is reduced, and this may improve the performance of handover


Hierarchical Mobile IP (II)

Processing when an MN first arrives at a visited domain, it performs home

registration during a home registration the HA registers the address of

GFA(gateway FA) as the care-of address of the MH this care-of address will not change when the MH changes

FA under the same GFA when changing GFA, MN must perform a home registration


Hierarchical Mobile IP (III)

HMIP employs a hierarchy of FAs to locally handle Mobile IP registration MH send mobile IP registration messages to update their respec

tive location information registration messages establish tunnels between neighboring FA

s along the path from the MH to a GFA the use of tunnels makes it possible to employ the protocol in an

IP network that carries non-mobile traffic as well typically one level of hierarchy is considered where all FAs are c

onnected to the GFA in this case direct tunnels connect the GFA to FAs that are lo

cated at access points


InternetGFA

FA

MN

HA

FA

Correspondent Node

IP registration message

Tunnel

Route from CN to MN after regional registration

Hierarchical Mobile IP (IV)


Hierarchical Mobile IPv6 (I) [14] [15]

Background in Mobile IPv6 there are no FAs, but there is still need to provide

a central point to assist with MIP handoffs similar to MIPv4, Mobile IPv6 can benefit from reduce mobility si

gnaling with external networks by employing local hierarchical structure

For this reason a new Mobile IPv6 node, called Mobility Server(MS), is used


Hierarchical Mobile IPv6 (II)

Features as the existing hierarchical Mobile IP scheme it uses anchor poin

ts called mobility servers(MS) to deploy two levels of hierarchies (MS is called Mobility Anchor Point(MAP) in other IETF draft)

it uses of new IPv6 functionalities such as a large address space and neighbor discovery mechanisms to support flexible, scalable and robust mobility management

supports two or more levels of hierarchy the simplest implementation of HMIPv6 supports two levels o

f hierarchy (e.g. micro-mobility protocol and Mobile IP) each domain contains one or several MSs as the level of hierarc

hy


Hierarchical Mobile IPv6 (III)

Address allocation if MH moves into new domain it gets two CoA

global CoA(GCoA) and local CoA(LCoA) If it moves within a domain

it only needs to change its LCoA The GCoA remains the same

MH register its GCoA with its HA and correspondent hosts in contrast to HMIPv4 schemes, the GCoA is not the address of t

he MS but an address belongs to the MS’s subnet as a result, the MS can be changed dynamically without having t

o change the GCoAs of the MHs currently roaming in the domain


Hierarchical Mobile IPv6 (IV)

Processing packets addressed to the MH’s GCoA are routed to the domain i

ntercepted by the MS and encapsulated to the MH’s current LCoA


Internet MSIPv6 router

MN

HA

Correspondent Node

Route before registration

Tunnel

Intercept the packets

Route from CN to MN after regional registration

IPv6router

Hierarchical Mobile IPv6 (V)




as a conclusion

Micro Mobility – Paging Extension [16]


Paging Extensions for Mobile IP (I)

P-MIP is designed to reduce signaling load in the core Internet and powe

r consumption of MHs

The state of MH active mode : operate in exactly the same manner as in Mobile IP

when an MH changes its point of attachment, it registers with a new FA

idle mode : register to HA after receiving paging request in contrast, MH do not register when they move in a same pag

ing area it is forced to register only when it moves to a new paging area


Paging Extensions for Mobile IP (II)

1. HA forward data packets to registered FA(rFA)

2. rFA checks MH’s information on record if it has, rFA checks that MH supports paging or not if it supports, rFA checks the MH’s state

3. If MH is in active mode, rFA decapsulates and forwards packets to the MH

4. If MH is in idle mode, rFA sends a paging request message to its own access network and other FAs in the paging area

5. When MH receives a paging request, it registers through the current FA to its HA

6. After receiving a registration request MH sends a paging reply back to its rFA through its current FA to inform the register FA of its current location

7. When rFA receives a paging reply, it forwards any buffered packets to the MH


Internet

rFA

MN

HAData packets

Paging request message

FA

MNPaging area

FA

MN

Paging Extensions for Mobile IP (III)

1

2

3

4


Internet

rFA

MN

HARegistration message

Paging reply message

Orphan data packets

FA

MNPaging area

FA

MN

Paging Extensions for Mobile IP (IV)

5

67


As a Conclusion : Micro Mobility (I)

Mobile IP WG is in the process of consolidating all contributions with the idea of having one standard its filtering strategy is to eliminate any proposals that did not

support tunneling and Mobile IP messaging initially 4 proposals has been considered, then 2 proposals,

proactive and fast handoff were left in discussion at a moment, the WG is in the process of discussing the pos and

cons of these 2 proposals


As a Conclusion : Micro Mobility (II)

Similarities of the proactive handoff and fast handoff aim to limit delay to the time needed to perform a L2 handoff make use of predicting the movements of MHs to anticipate new p

oints of attachments

Differences of the proactive handoff and fast handoff the former first completes L2 handoff, then starts to forward data to

the MH, and finally, allows L3 registration to proceed : handoff control is driven by the network

the later anticipates the movements of an MH allowing the MH to register with the new FA or GFA prior to L2 connectivity being established : handoff is initiated by MH


As a Conclusion : Micro Mobility (III)

Considerations what is the minimal coupling between the L3 and L2 to facilitate

fast handoff? is the predicting new access points in advance assumption

reasonable? MH initiated or network initiated?

The process of consolidating these two proposals has recently resulted in a single proposal for fast and low latency handoff for Mobile IPv4, as well as Mobile IPv6


Reference (I)

[1] C. Perkins, “IP Mobility Support,” IETF RFC 2002, Oct. 1996.[2] C. Perkins, “IP Mobility Support for IPv4, revised,” IETF Draft, draft-ietf-mobi

leip-rfc2002-bis-03.txt, Sep. 2000.[3] S. Deering, “ICMP Router Discovery Messages,” IETF RFC 1256, Sep. 199

1.[4] C. Perkins, “IP Encapsulation within IP,” IETF RFC 2003, Oct. 1996.[5] C. Perkins, “Minimal Encapsulation within IP,” IETF RFC 2004, Oct. 1996.[6] R. Ramjee, et. al., “HAWAII : a domain-based approach for supporting mobil

ity in wide-area wireless networks,” Proc. IEEE International Conference on Network Protocols, pp.283-292, 1999.

[7] A.Campbell, et. al., “Cellular IP,” IETF Draft, draft-ietf-mobileip-cellularip-00.txt, Dec. 1999.

[8] K. Malki, H. Soliman, “Fast Handoffs in Mobile IPv4,” IETF Draft, draft-elmalki-mobileip-fast-handoffs-03.txt, Sep. 2000.


Reference (II)

[9] G. Tsirtsis, “Fast handovers for Mobile IPv6,” IETF Draft, draft-ietf-mobileip-fast-mipv6-01.txt, Apr. 2001

[10] P. Calhoun, et. al., “FA Assisted Hand-off,” IETF Draft, draft-calhoun-mobileip-proactive-fa-01.txt, Jun.2000.

[11] G. Dommety, “Local and Indirect Registration for Anchoring Handoffs,” IETF Draft, draft-dommety-mobileip-anchor-handoff-01.txt, Dec. 2000.

[12] E. Gustafsson, et. al., “Mobile IP Regional Registration,” IETF Draft, draft-ietf-mobileip-reg-tunnel-02.txt, Mar. 2000.

[13] C. Castelluccia, L. Bellier, “Hierarchical Mobile IPv6,” IETF Draft, draft-castelluccia-mobileip-hmipv6-00.txt, Jul. 2000.

[15] H. Soliman, et. al., “Hierarchical MIPv6 mobility management,” IETF Draft, draft-ietf-mobiliip-hmipv6-03.txt, Feb. 2001.

[16] X. Zhang, et. al., “P-MIP : Minimal Paging Extensions for Mobile IP,” IETF Draft, draft-zhang–pmip-00.txt, Jul. 2000.

Chonbuk National University, DCS Lab presented by ghcho 1 Mobile IP, and Micro Mobility Gihwan Cho [email protected].

Documents

mobile ip mobile ip

chonbuk national university

registration mobile

dcs lab

mobile users

mobile workforce

registration tunnel

network address