1. Mobile IP, and Micro Mobility
Gihwan Cho

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

3. Mobile IP Now, let’s talk about 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

4. Why Mobile IP ? (I) Background IPv4 routing considerations
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

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

6. Protocol Overview (I) [1][2]
Three steps with the protocol
agent discovery: MAs may advertise their availability for they provide 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]

7. Protocol Overview (II)
Mobile Node
FA (FA)
HA (HA)
Correspondent Node
Agent Solicitation
agent discovery
Agent Advertisement
Registration Request
Registration Request
Registration Reply
registration
Registration Reply
Data sent
Data received
tunneling

8. Protocol Overview (III)
Internet
Correspondent Node HA FA
data paths (before registration)
Mobile Node
location registration
Mobile Node
host moving
packet tunneling
data paths (after registration)
data paths (sent from MN)
agent discovery
tunnel

9. Triangle Routing on Mobile IP
Triangle routing is undesirable :
Increased network utilization (sensitivity to network partition)
Irregularity of performance variance
Internet Host
Home-based
Location
Reply Path
Tunneling
Home
Agent FA
MH k
Host Moving

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

11. 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 the “prefix+suffix” mode of MD5 as originally mandated in RFC 2002

12. 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 routers
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 ability for MHs to use the advertisements even when the newly defined bits are not understood

13. 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 rejects 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

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

15. Micro Mobility – HAWAII [6]
Now, let’s talk about
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

16. IP Micro Mobility – HAWAII (I)
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

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

18. 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 state update, to prevent its out-of-state situation
refresh message

19. IP Micro Mobility – HAWAII (IV)

20. IP Micro Mobility – HAWAII (V)

21. Forwarding Path Setup

22. Non-Forwarding Path Setup

23. Paging
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

24. Hierarchy using Domain

25. Paging Design Goals Efficiency Scalability Reliability Flexibility
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

26. Paging Support … HAWAII (I)

27. Paging Support … HAWAII (II)

28. Router Operation

29. Paging with Mobile-IP When using FAs When operating without 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

30. Micro Mobility – Cellular IP [7]
Now, let’s talk about
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

31. Cellular IP (CIP) Cellular IP is intended to: Design principles
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 by regular IP datagrams
location information is stored as soft state
location management strategy is separated between the idle MH and the active MH

32. Protocol Requirement 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 placed without leaving the cellular IP network
an MH migrating between cellular IP network must be to use Mobile 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

33. Hierarchical Mobility Management (I)
Global mobility with Mobile IP

34. Hierarchical Mobility Management (II)
Local mobility with cellular IP
fast handoff within a mobile access network
less load in the global Internet

35. Wireless Overlay Networks

36. Mobile Access Network

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

38. 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 caches
paging caches have a longer timeout value than routing caches and are not necessarily maintained in every Node

39. Mobile IP vs. Cellular IP
Global mobility support vs. local fast smooth handoff

40. Uplink Path : Shortest Path

41. Uplink Packets Create Location Information

42. Downlink Packets (I)
Mobile IP’s centralized location management

43. Downlink Packets (II)
Cellular IP’s distributed location database

44. Control Packet in Uplink if no Data or a Move Detected

45. Handoff is Automatic

46. Idle Host Location Management Tradeoff

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

48. Paging Cache Update with a move

49. Paging Route with Paging Cache

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

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

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

53. Micro Mobility – Fast Handoff [8]
Now, let’s talk about
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

54. 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 copies 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

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

56. Simultaneous bindings (I)
Simultaneous bindings in MIPv4
may be achieved by setting the ‘S’ bit in the Mobile IP Registration Request message sent by the MN
cause the receiving agents(HA, GFA, regional FA, previous FA) to 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

57. Simultaneous bindings (II)HA CN
Internet
old FA
: bicasting MN
new FA MN

58. Flat and Hierarchical MIPv4 model
A flat and a hierarchical (with GFA) MIPv4 model
GFA
Internet HA CN MN
AP2
FA2
FA1
AP1
AP3
FA3
Visited Domain MN
Internet HA CN
AP2
FA2
FA1
AP1

59. 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 handoffs
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

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

61. FMIPv4 (III) Inter-FA solicitation : MN AP current FA new FA
4. Agent advertisement
5. Registration Request MN
6. Registration Request
3. Agent advertisement AP
1. Agent Solicitation
7. Registration Request
current FA
2. Agent advertisement
new FA

62. FMIPv4 (III) Inter-FA solicitation : Internet MN GFA HA old FA new FA
8. Registration request
1. Agent solicitation
old FA
new FA
2. Agent advertisement
6. Registration request
7. Registration request
3. Agent advertisement
old AP
5. Registration request
new AP MN
4. Agent advertisement

63. 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 send 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

64. FMIPv4 (V) Piggy-backing advertisements on layer 2 messaging : MN GFA
Internet HA
7. Request registration
old FA
2. Reply advertisement
new FA
3. Reply advertisement
1. Request advertisement
old AP
6. Request registration
5. Request registration
new AP
4. Reply advertisement MN

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

66. HMIPv4 (II) HMIPv4 supplements with the following for Fat MIPv4
limitation of triangle routing for communication between hosts within 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 of address
some of the HA’s functionality is performed locally in the GFA

67. Regional Registration (I) : HMIPv4
When MN first arrives at a visited domain, it performs a registration with its home network
1. Registration Request MN
6. Registration Reply
2. Registration Request
5. Registration Reply
Regional FA
3. Registration Request
4. Registration Reply
GFA HA

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

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

70. 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 simultaneous 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

71. 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 the 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 receiving 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

72. Fast Handoffs(III) : HMIPv4
MAA extension advertises FA and GFA address only
1. Agent Advertisement (MAA extension)
2. RR Request
5. RR Reply MN
New FA
3. RR Request
4. RR Reply
GFA

73. Fast Handoffs(IV) : HMIPv4
MAA extension advertises complete order of FAs in the branch
where multiple regional FA levels, and multiple paths from the MN 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 different 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

74. Fast Handoffs(V) : HMIPv4
MAA extension advertises complete order of FAs in the branch
1. Agent Advertisement (MAA extension)
2. RR Request
7. RR Reply MN
3. RR Request
6. RR Reply
New FA
4. RR Request
5. RR Reply
GFA

75. Micro Mobility - Proactive, Anchor Handoff [9][10]
Now, let’s talk about
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

76. 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 MH
it allows L3 registration to proceed
finally, handoff control is driven by the network as opposed to MH

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

78. Proactive Handoff (III)
Source trigger proactive handoff HA
Internet
GFA
4. Registration Reply
Move detect
3. Registration Request
oFA
1. Handoff Request
nFA
2. Handoff Reply MN MN

79. Proactive Handoff (IV)
Target trigger proactive handoff HA
Internet
GFA
4. Registration Reply
3. Registration Request
oFA
Move detect
1. Handoff Request
nFA
2. Handoff Reply MN MN

80. Proactive Handoff (IV)
Functional components
FAAA
DHCPv6
SMM MN
HA1
HA2
HAn
HAAA
HMM
SMM : Serving Mobility Manager
HMM : Home Mobility Manager

81. Proactive Handoff (V) Proactive intradomain handoff time
BU : Binding Update
BA : Binding Ack.
time
System Handoff Request
Mobile Node
DHCPv6
Request
nSMM
DHCPv6Res
Handoff And
Context Trans
Response
Handoff And
Context Trans Request
System
Handoff
Response
DHCPv6 BU BA
oSMM BU BA
HAn
HMM BU BA BU BA
HAm
CNn

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

83. Proactive Handoff (VII)
Proactive interdomain handoff
Proactive interdomain handoff
BU : Binding Update
BA : Binding Ack.
time
System Handoff Request
Mobile Node
DHCPv6
Req
RegReq
Reg Res
nSMM
DHCPv6Res.
DHCPv6
AAan HAndoff And
Context Trans Res
nFAAA
System
Handoff
Res
AAan HAndoff
And Context
Trans Request
AAA Reg
Req BU
oFAAA
AAA Reg
Res BA
oSMM BU BA
HAk
HAAA
RegReq
RegRes
HMM HA

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

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

86. 2. then, L3 registration is started
Fast vs. Proactive (I)
Proactive HA
Internet
1. L2 handoff is completed
2. then, L3 registration is started
GFA 2
oFA
nFA
Layer 3
oAP
Layer 2
nAP 1 MN MN

87. Fast vs. Proactive (I) Fast HA Internet GFA oFA nFA oAP nAP MN MN
1. L3 registration is completed, rather than L2 handoff
Internet
2. Bi-Casting
GFA 2
3. it is not sure whether L2 handoff has completed
oFA
nFA
Layer 3
oAP
Layer 2
nAP 1
3. L2 handoff MN MN

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

89. Anchor Handoff (II) Local registration HA Internet FA2 FA1 MN MN
Home
Network HA
Internet
Tunnel
Visited
Network
FA2
FA1
Anchor MN MN

90. Anchor Handoff (III) Global indirect registration HA Internet FA2 FA1
Home
Network HA
Internet
Tunnel
Visited
Network
FA2
FA1
Anchor MN MN

91. Micro Mobility – Hierarchical Handoff [12]
Now, let’s talk about
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

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

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

94. 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 respective location information
registration messages establish tunnels between neighboring FAs 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 connected to the GFA
in this case direct tunnels connect the GFA to FAs that are located at access points

95. Hierarchical Mobile IP (IV)HA
Correspondent Node
Internet
GFA FA
IP registration message
Tunnel
Route from CN to MN after regional registration FA MN

96. 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 signaling with external networks by employing local hierarchical structure
For this reason a new Mobile IPv6 node, called Mobility Server(MS), is used

97. Hierarchical Mobile IPv6 (II)
Features
as the existing hierarchical Mobile IP scheme it uses anchor points 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 of hierarchy (e.g. micro-mobility protocol and Mobile IP)
each domain contains one or several MSs as the level of hierarchy

98. 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 the MS but an address belongs to the MS’s subnet
as a result, the MS can be changed dynamically without having to change the GCoAs of the MHs currently roaming in the domain

99. Hierarchical Mobile IPv6 (IV)
Processing
packets addressed to the MH’s GCoA are routed to the domain intercepted by the MS and encapsulated to the MH’s current LCoA

100. Hierarchical Mobile IPv6 (V)HA
Correspondent Node
Internet
MS IPv6 router
IPv6 router
Route before registration
Tunnel
Intercept the packets
Route from CN to MN after regional registration MN

101. Micro Mobility – Paging Extension [16]
Now, let’s talk about
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

102. Paging Extensions for Mobile IP (I)
P-MIP
is designed to reduce signaling load in the core Internet and power 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 paging area
it is forced to register only when it moves to a new paging area

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

104. Paging Extensions for Mobile IP (III)HA
Data packets
Paging request message 1
Internet 2 4 FA
rFA 3 FA MN MN
Paging area MN

105. Paging Extensions for Mobile IP (IV)HA
Registration message
Paging reply message
Orphan data packets
Internet 6 7 FA
rFA FA MN 5 MN
Paging area MN

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

107. 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 points 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

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

109. Reference (I)
[1] C. Perkins, “IP Mobility Support,” IETF RFC 2002, Oct
[2] C. Perkins, “IP Mobility Support for IPv4, revised,” IETF Draft, draft-ietf-mobileip-rfc2002-bis-03.txt, Sep
[3] S. Deering, “ICMP Router Discovery Messages,” IETF RFC 1256, Sep
[4] C. Perkins, “IP Encapsulation within IP,” IETF RFC 2003, Oct
[5] C. Perkins, “Minimal Encapsulation within IP,” IETF RFC 2004, Oct
[6] R. Ramjee, et. al., “HAWAII : a domain-based approach for supporting mobility in wide-area wireless networks,” Proc. IEEE International Conference on Network Protocols, pp , 1999.
[7] A.Campbell, et. al., “Cellular IP,” IETF Draft, draft-ietf-mobileip-cellularip-00.txt, Dec
[8] K. Malki, H. Soliman, “Fast Handoffs in Mobile IPv4,” IETF Draft, draft-elmalki-mobileip-fast-handoffs-03.txt, Sep

110. 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
[12] E. Gustafsson, et. al., “Mobile IP Regional Registration,” IETF Draft, draft-ietf-mobileip-reg-tunnel-02.txt, Mar
[13] C. Castelluccia, L. Bellier, “Hierarchical Mobile IPv6,” IETF Draft, draft-castelluccia-mobileip-hmipv6-00.txt, Jul
[15] H. Soliman, et. al., “Hierarchical MIPv6 mobility management,” IETF Draft, draft-ietf-mobiliip-hmipv6-03.txt, Feb
[16] X. Zhang, et. al., “P-MIP : Minimal Paging Extensions for Mobile IP,” IETF Draft, draft-zhang–pmip-00.txt, Jul