Prof. Dr. rer. nat. habil. C. Görg
Dissertation
Performan e Evaluation and Improvement of the Mobile
Internet Proto ol: A Study of Hand-os, Transport Layer
Performan e and Flow Mobility
by
Nikolaos Albertos Fikouras
Bremen, January8, 2007
Supervised by:
We thought thatwe were
introdu ing into theworld an
inventionwhi hwouldmake further
wars pra ti ally impossible.
The Wrightbrothers
Thedawnofthenewmillenniumhasfoundtheworldinanin reasingstateoftransit.
As mobility be omes the wat hword of our ivilisation the way we ommuni ate,
so ialise and do business is being revolutionised. The apa ity of ommuni ation
networks to over omephysi al spa e with disregard for geopoliti alboundaries has
enabled people furthest apart to ome together. This experien e is hallenging
some of the most fundamental onventions of our so ieties, for ing our per eption
of the world to hange radi ally. At the forefront of this revolution is the Internet.
Originatingfromthe Advan edResear hProje tsAgen y Network(ARPANET)of
the US Department of Defen e, it has been witnessing tremendous expansion sin e
early1990whenthe USNationalS ien e Foundation(NSF)privatisedthenetwork.
It is the author's humble expe tation and hope that the work presented in this
thesis will assist this eort if only for an in nitesimal quantity. Maybe, mobile
ommuni ations will keep bringing people together and maybe the Internet will
be the stand for individuals that previously remained unrepresented to raise their
voi e. Thenmaybe,someday,ate hnology on eived by anorganisationof warwill
TCP/IP was originally designed without any onsiderationsfor mobile omputing.
The greatest te hni al di ulties are en ountered in the routing servi e of the IP
layer. Mobile IP isanenhan ement tothe IP proto olwhi hallows for transparent
routingoftra tomobilenodes inthe Internet. Inthis manner,mobilenodes may
vary their point of atta hment between Internet administrative domains without
having tointerrupta tive ommuni ations.
MobileIPintrodu esseveraloverheadsin ludingextendedpa ketlossduringMobile
IP/IP layer hand-os. Moreover, Mobile IP was designed fo using onmobile nodes
equipped with a single a ess interfa e, apable of maintaining a single point of
atta hment tothe Internet.
Thisthesisfo usesonevaluatingandimprovingtheperforman eofMobileIPandof
otherproto olsin onjun tionwithMobileIP.DierenttypesofMobileIPhand-os
have been investigated. Itwas determinedthat allstandardisedMobile IP hand-o
te hniquesintrodu easervi edisruptionuna eptableforrealtime ommuni ations
su h asInternet telephony orfor letransfer and WWW. In aneort toa elerate
Mobile IP hand-os, new hand-o typeswere introdu ed and proposals were made
regarding the hierar hi al organisation of Mobile IP infrastru ture. It was shown
that TCP, the primaryand reliable, transport layerproto ols of TCP/IP,
misinter-prets allpa ketlossexperien ed duringMobileIP hand-osasthe ee t ofnetwork
ongestionand urtailstheamountofoered loadtothe onne tioneverytimethat
a mobile node migrates. New proto ol extensions were proposed and evaluated,
aiming atresolving the in ompatibilitiesbetween TCP and Mobile IP.
The thesis demonstrateshow Mobile IP an be deployed tointrodu e Internet
mo-bility management fa ilities to WAP, the industrial de fa to standard for Internet
a ess to mobilephones. The demonstrationinvolves a migrations enariobetween
twoheterogeneouswirelesste hnologies,i.e. WirelessLANsandGSM.Itwasshown
that Mobile IP inherits the inter onne ting property of the Internet Proto ol. In
this manner, the problem of integrating heterogeneous proto ols, above and below
it, isredu ed intoa matter of routing.
Consideringtheeverin reasingavailabilityofmobiledevi esequippedwithmultiple
wireless a ess interfa es the inability of Mobile IP to take advantage e iently of
this property was onsidered a major drawba k. A signi ant part of this thesis
is devoted to the introdu tionof owmobility management fa ilitiesthat allowfor
dynami distribution of ows or parts of a ow (datagrams) between the available
TCP/IP wurde ursprungli hohne jegli he Abwägung für den mobilen Betrieb
kon-struiert. Die gröÿten te hnis hen S hwierigkeiten betreen die Routing F
unktio-nalität der IP-S hi ht . Mobile IP ist eine Erweiterung des IP Protokols, wel he
das transparenteRoutingvonDatenverkehr fürmobile KnotenimInternet erlaubt.
Auf dieser Weise können mobile Knoten ihren Ans hlusspunkt zwis hen Internet
Verwaltungsdomänen we hseln, ohne dabei ihre Kommunikationzu unterbre hen.
Mobile IP verursa ht Verwaltungsaufwand (wie z.B. einen gröÿeren Paketverlusst)
während einer Übergabeauf Mobile IP/IPEbene. Weiterhin,wurde Mobile IP mit
fokus auf mobilen Knoten konstruiert, wel he mit einer einzigen
Netzwerks hnitt-stelle ausgerüstetsind, und demzufolgeeineneinzigenInternetans hluÿ unterhalten
können.
Diese Dissertation fokusiert auf dieBewertung und Verbesserung der Leistung von
Mobile IP, wie au h von anderen Protokollen im Mobile IP Umfeld.
Unters hied-li he Typen von Mobile IP Übergaben wurden untersu ht. Es wurde festgestellt,
dass alle standarisierten Mobile IP Übergabemethoden eine für
E htzeitkommuni-kation(z.B.wie z.B.InternetTelefonie,DateienÜbertragungundWWWNutzung.)
unakzetable Dienstunterbre hung verursa hen. Der Versu h Mobile IP Übergaben
zu bes hleunigen, hat zu neuen Übergabemethoden, sowie Ansätzen zur
hierar hi-s hen Organisation der Mobile IP Infrastruktur geführt. Es zeigte si h, dass TCP
(dasprimäre,Transport-S hi htTCP/IPProtokolfürzuverlässigeKommunikation)
Pa ketverlusste während einer Mobile IP Übergabe alsdas Resultat einer Stauung
der Pakete misinterpretiert,und somitden angebottenen Verkehr beijeder
Überga-be des mobillen Knoten reduziert. Neue Protokolerweiterungen wel he
Inkompati-bilietäten zwis hen Mobile IP und TCP beheben sollen, wurden vorges hagen und
bewertet
Unter Bea htung der immer gröÿeren Verfügbarkeit von mobillen Geräten
ausge-rüstet mit mehrfa hen Funkzugangss hnittstellen, wird die une ziente
Unterstüt-zung von mehfa hen S hnittstellen dur h Mobile IP als groÿer Na hteil betra htet.
Ein erhebli her Teil dieser Dissertation ist der Einführung von
Flussmobilititäts-funktionalitätzur dynamis hen VerteillungvonganzenFlüssen oder
Flussabs hnit-ten (datagrammen) zwis hen verfügbaren S hnittstellen während einer Sitzung
ge-widmet. Dur h ausgedähnte experimentelle Bewertung wurde gezeigt dass sowohl
zuverlässige(TCP)wieau hunzuverlässige(UDP)Kommunikationvondiesem
An-satz pro tieren kann.
DieseDissertationdemonstriertwieFunktionalitätzurMobilitätsverwaltunginWAP
(das industriele de fa to Standard für Internet Zugang in Mobiltelefonen), dur h
und GSM. Es zeigte si h, dass Mobile IP die integrierenden Eigens haften des
Internet-Protokolls erbt. Auf dieser Weise kann das Problem der Integration
he-terogenen Protokollen,höher undniedrigeralsMobileIP aufeiner Routing
Prefa e 1
Abstra t 2
Kurzfassung 3
1 An Introdu tion to Internet Mobility 13
1.1 Motivation . . . 13
1.2 InternetRouting and Internet Mobility . . . 14
1.3 Do ument Stru ture . . . 15
2 A Review of Proto ols for Internet Mobility Support 17 2.1 Requirements forMobility Support . . . 17
2.1.1 OperationalTransparen y . . . 17 Lo ationManagement . . . 18 Hand-o Management . . . 18 2.1.2 Proto olTransparen y . . . 18 2.1.3 Performan e Transparen y . . . 18 2.2 Internet Infrastru ture . . . 19 2.2.1 Dynami DNS . . . 19
2.2.2 IKEv2 Mobility and Multi-homingProto ol . . . 20
2.3 Transport Layer Approa hes . . . 20
2.3.1 Split Conne tion Proto ols . . . 20
2.3.2 Mobility Extensionsto TransportProto ols . . . 21
TCP Migrate . . . 21
2.3.3 New MobilityAware Transport Proto ols . . . 22
Stream Control Transmission Proto ol . . . 22
Datagram Congestion ControlProto ol . . . 23
2.4 Convergen e LayerApproa hes . . . 23
2.4.1 Lo ationIndependent Network v6 . . . 23
2.4.2 Host Identity Proto ol . . . 25
2.4.3 Multiple AddressServi e for Transport . . . 26
2.5 Appli ationLayerApproa hes . . . 27
2.5.1 Session InitiationProto ol . . . 27
2.6 Network Layer Approa hes . . . 29
3 Mobile IP Hand-os 33
3.1 InternetMobility Management. . . 35
3.2 The Mobile IP Hand-o Life- y le . . . 36
3.3 Advertisement BasedMove Dete tion Algorithms . . . 38
3.3.1 Lazy Cell Swit hing . . . 39
3.3.2 Fast LazyCell Swit hing . . . 40
3.3.3 Eager Cell Swit hing . . . 41
3.3.4 Pre x Mat hing . . . 42
3.3.5 Analysis of Advertisement Based MoveDete tion . . . 42
3.4 Hint Basedalgorithms . . . 43
3.4.1 Hinted Cell Swit hing . . . 44
3.4.2 Fast Hinted Cell Swit hing . . . 46
3.5 SimulationSet-up . . . 46
3.5.1 Straight Line Movement . . . 48
3.5.2 Ba k-and-Forth Movement . . . 51
3.6 ExperimentalEvaluationof ECS and FHCS . . . 55
3.6.1 ExperimentalResults . . . 57
3.7 Analysisof ECS and FHCS Mobile IP Hand-os . . . 59
3.7.1 Comparison of Simulatory and Analyti al Results . . . 65
3.8 FastHand-os for Mobile IP . . . 69
3.8.1 Cost of Fast-Hand-os . . . 71
4 TCP Performan e over Mobile IP 73 4.1 The Transmission ControlProto ol . . . 73
4.2 Congestion Avoidan eAlgorithms . . . 74
4.2.1 Slow Start . . . 75
4.2.2 Congestion Avoidan e . . . 75
4.2.3 TheCombinedSlow-StartwithCongestionAvoidan eAlgorithm 77 4.2.4 Fast Retransmit . . . 78
4.2.5 Fast Re overy . . . 78
4.2.6 CombiningFastRetransmit with FastRe overy . . . 78
4.3 TCP Performan e duringMobile IP Hand-os . . . 79
4.4 Analysisof the TCP RetransmissionMe hanisms . . . 80
4.4.1 TCP Mobile IP Hand-o Re overy Time . . . 81
4.4.2 SimulationInvestigation . . . 82
4.4.3 ExperimentalInvestigation . . . 85
4.4.4 ExperimentalResults . . . 86
4.5 Comparison of Analyti aland SimulationResults . . . 87
4.6 Proposed Solution. . . 87
4.6.1 Mobile Node as Sender . . . 89
5 A hieving Integrated Platforms with Mobile IP 93
5.1 EnablingWAP Hand-os between GSM and WLAN with Mobile IP . 93
5.1.1 Introdu tion . . . 93
5.1.2 Re-Inventing in the Name of Wireless . . . 95
5.1.3 Converging in the Name of Progress. . . 96
5.1.4 The WAP TransportProto ols . . . 98
5.1.5 Mobile WAP Network Components . . . 99
5.2 ExperimentalSetup . . . 99
5.3 ExperimentalResults . . . 100
5.4 Con lusions . . . 103
6 Enhan ed Internet Terminal Mobility 105 6.1 S enarios for Enhan ed Terminal Mobility . . . 106
6.1.1 Every Day S enario . . . 106
6.1.2 Ta ti al Appli ation . . . 106
6.2 Requirements of Enhan ed TerminalMobility . . . 107
6.2.1 Seamless Roaming . . . 107
6.2.2 Mobile Node Identity . . . 108
6.2.3 Poli yBased Routing. . . 108
6.2.4 Multiple Interfa e Management . . . 108
6.3 Related Work . . . 109
6.3.1 Mobile IP . . . 109
6.3.2 Stream Control Transmission Proto ol . . . 110
6.3.3 Host Identity Proto ol . . . 111
6.3.4 Resour e reSerVation Proto ol . . . 111
6.4 Filtersfor Mobile IP . . . 111
6.4.1 The Need forFilters for Mobile IP . . . 112
6.4.2 Proto olOverview . . . 113
6.4.3 Modelof Operation . . . 115
6.4.4 Supportfor Multi-homing . . . 116
6.5 Con lusions . . . 117
7 Filters for Mobile IP and UDP Performan e 119 7.1 ExperimentalSetup . . . 119
7.2 UDP FlowMobility . . . 120
7.2.1 ExperimentDes ription . . . 120
7.2.2 ExperimentalResults . . . 121
7.3 UDP FlowDistribution . . . 126
7.3.1 ExperimentDes ription . . . 126
7.3.2 ExperimentalResults . . . 127
UDP Single Flow Distribution with 5:3 Pa ket Distribution
Rate . . . 129
7.4 Con lusions . . . 129
8 Filters for Mobile IP and TCP Performan e 133 8.1 TCP FlowMobility . . . 133 8.1.1 ExperimentDes ription . . . 134 8.1.2 ExperimentalResults . . . 134 8.2 TCP FlowDistribution . . . 137 8.2.1 ExperimentDes ription . . . 138 8.2.2 ExperimentalResults . . . 139
SingleTCPFlowDistributionwith1:1Pa ketDistributionRate139 SingleTCPFlowDistributionwith3:1Pa ketDistributionRate142 8.3 Con lusions . . . 142
9 Con lusionsand Future Resear h 145 A Filters for Mobility Bindings Proto ol Spe i ation 149 A.1 Mobile Node Considerations . . . 149
A.1.1 Filters forMobile IPv4 Bindings RegistrationFlag. . . 149
A.2 Mobile Node FilterManagement. . . 150
A.2.1 Creating a new mobilitybinding with Filters . . . 150
A.2.2 Repla inga Filter of amobilitybinding by Index . . . 150
A.2.3 Adding new Filtersto anexisting mobilitybinding . . . 150
A.2.4 Sharinga Filter between mobility binding . . . 150
A.2.5 Renewing a mobilitybinding with Filters . . . 151
A.2.6 Deleting one or more Filtersof a mobility binding . . . 151
A.2.7 Deleting allFilters for amobility binding . . . 151
A.2.8 Transferring aFilter between mobility bindings . . . 151
A.2.9 The Weight eld of the Filter ControlExtension . . . 151
A.3 FilteringAgentConsiderations . . . 151
A.3.1 Determiningthe validityof a Filter Body . . . 152
A.3.2 Pro essing FilteringRequests . . . 152
A.3.3 FilteringRequest ontains aFilterde larationwithanewIndex152 A.3.4 FilteringRequest ontainingFilterde larationswithallo ated Index. . . 152
A.3.5 FilteringRequest ontainingonly Filter ControlExtension . . 152
A.3.6 FilteringRequest ontainingonly Filter Deletion Extension. . 153
A.3.7 FilteringRequest withoutany Filterde larations orextensions 153 A.3.8 Applying Filters. . . 153
A.4 Home Agent Considerations . . . 153
A.5.1 Behaviour AggregateFilters (BAF)Extension . . . 156
A.5.2 Proto olExtension . . . 156
A.5.3 Sour e Address Extension . . . 157
A.5.4 Sour e Network Extension . . . 157
A.5.5 Sour e PortExtension . . . 158
A.5.6 Sour e Port Range Extension . . . 158
A.5.7 Destination Port Extension . . . 159
A.5.8 Destination PortRange Extension. . . 159
A.5.9 Free-FormExtension . . . 160
A.5.10 Filter ControlExtension . . . 161
A.5.11 Filter Deletion Extension. . . 161
A.5.12 Filter ReplyExtension . . . 161
A.5.13 Code Values for Filter ReplyExtension . . . 162
List of Figures 163
List of Tables 167
Glossary 169
List of Abbreviations 171
An Introdu tion to Internet Mobility
Thebeginning ishalfof everything.
An ientGreek proverb
C
ommuni ation has evolved throughout the ages from a fundamental part of humanso ietiestoanabsolutehumanne essity. Sin ehumanswere organisedinto smallgroups, people have always been in sear h of ways to ommuni ate. As
distan es grew larger it be ame impossible for individuals to relay large messages
verbally,so man invented new means of ommuni ating; smoke signalsgave way to
moving ags, trained homing-pigeons, the telegraph and lately to able and radio
data ommuni ations.
Hundreds of years havepassed sin e man lit res to ommuni ate and
ommuni a-tion systems have peaked in sophisti ation and omplexity. However, the need for
ommuni ationstillexists anditiseven moreimperative. Itisthis needthat ledto
the invention of the Internet and is the driving for etowards the mobile Internet.
This hapter gives an overview of onventional Internet routing and the problems
en ountered when the element of mobility is introdu ed. This hapter on ludes
with a des ription of the do ument stru ture.
1.1 Motivation
In the last three de ades omputer systems have witnessed an organisational shift
from monolithi (mainframes) towards in reasingly distributed, i.e. lient-server
systems. Their su ess was largely possible due to the availability of high speed,
reliable network hardware and proto ols that allowed for inter onne ting network
te hnology. The explosionofthe WorldWideWeb isanexampleof thepossibilities
enabled by the new approa h. Meanwhile, personal omputing platforms evolved,
on entrating in reasinglymore powerfulsystems in ever smallerform fa tors.
The wide spread of the Internet ombined with the proliferation of small portable
devi es that were nowput to use ineveryday life madea ess to the network vital.
Mobile devi es were alled upon to emulate a user experien e identi al to that at
the user's home desktop as onne tivity would have to guaranty a ess to servi es
and resour es available onlyin the home network. That would in linethat
onne -tivity by itself is useful but lo ation independent home network a ess is of equal
importan e[55℄.
ompletelydierentsites. Withthein reasing availabilityof wireless overage, user
mobility willbe omemore frequent and more demanding.
Mobile omputingisdierentiatedfromportable omputinginthat omputing
a tiv-itiesare not disrupted when the users hange their omputer's pointof atta hment
to the Internet. During that pro ess all needed re onne tion and re on guration
must o ur automati ally and withoutthe need for user intera tion.
Thespe i ationoftheInternetProto ol(IP)[119℄de neswithinitsresponsibilities
the pro ess of pa ket fragmentation and re-assembly aswellas:
the fun tions ne essary to deliver a pa ket of bits (an Internet
data-gram) from a sour e to a destination over an inter onne ted system of
networks.
Inthisdes riptionoftheroutingfun tionthe proto oldoesnotespe iallyin ludeor
ex lude the routing of tra for mobile nodes (host orrouter). As it willbe shown
IP routing is not adequatewhen the elementof mobilityis introdu ed.
1.2 Internet Routing and Internet Mobility
Ea h Internet node (host or router) is assigned an IP address 1
. Every IP address
onsistsofahostpartandanetworkpart[136℄. Thenetworkpartidenti esuniquely
the IP network, where the host is lo ated, while the host part identi es uniquely
the host within itsIP network. For routingbetween IP networks,only the network
part of anIP address needsto be onsideredby the intermediate routers. The host
part be omesimportantonlyafteranetwork pa ketenters thedestinationnetwork.
Thisapproa hoers maximum exibility,sin eonlytherouterofthenetworkneeds
to have knowledge of host addresses within a network. This hierar hi al way of
organising IP addresses ontributessigni antly inkeeping routingtables ompa t,
i.e. routers onlyneed to store informationon how to route datagrams to networks
rather than to individualhosts. However, when a mobile node migrates toanother
lo ationin ompatible with itsIP address, then pa ket delivery to the mobilenode
via onventional IP routing is impossible. This s enario is illustrated in gure 1.1.
It shows a mobile node allo ated an IP address within an Internet administrative
domain (subnet)
A.B.C.X
with anestablished onne tion with a xed sender. A ording tohierar hi al IProuting alltra isalways relayed tothe router,entrypoint to the next level of the hierar hy. On e tra has rea hed the router at the
host's own network, it is dire tly delivered to the host. Should the host migrate
to anotherInternet administrativedomain,su h as
A.B.D.X
, then itwould render itself unrea hable for in oming tra . That is, with respe t to hierar hi al IProuting alltra for the mobile node will be delivered to itshome network router.
Unaware ofthe mobilenode's new lo ation,the routerwilldrop allin omingtra
for the mobile node.
Figure 1.1: Hierar hi al Address Organisationand Mobility
In order for the mobile node to be ome rea hable again it must take on a new IP
address ompatible with its lo ation. That is, it has to adjust atleast the network
part of its IP address to mat h that of its neighbours. This, however, would be
una eptable for transport layer proto ols. In the transport layer of the Internet
proto ol suite ea h ommuni ation is identi ed by a 5-tuple that onsists of the
proto ol type along with the respe tive sender and re eiver Internet addresses and
port numbers [134℄. Moreover, transportproto ols use the Internet address bound
to ea h ommuni ation for the al ulation of the header he ksum. Should any of
thisinformation hangeduringthe ourseofa ommuni ation,thenitwillbeunable
to pro eed. This des ription reveals the problems en ountered at the network and
transport layers of the Internet proto olwhen mobility isintrodu ed.
There have been a number of dierent approa hes to Internet mobility support.
This thesis is devoted to the evaluation and improvement of one su h solution; the
Mobile Internet Proto ol(Mobile IP).
Subsequent hapters will demonstrate the reasons that led to the sele tion of the
Mobile IP, will highlight the short omings of the proto ol and introdu e a novel
proto olextension forenhan ed Internet mobility.
The followingse tion givesa detaileddes ription of the do ument stru ture.
1.3 Do ument Stru ture
The hapters to follow present the reasons that make Mobile IP the dominant
ap-proa hfor Internet mobilityand fo us on the performan e evaluationof Mobile IP
and ways toimproveit.
Chapter 2 gives an insight into a range of dierent approa hes to the problem of
Internetmobilityin ludingMobile IP. Theseare omparedwithea hotherinterms
of fun tionality and transparent integration intothe Internet.
Chapter 3 is devoted to the study of mobility management with Mobile IP and
the evaluation of dierent methods for a elerating re on guration in the event of
mobile node migration.
Chapter 5 is apresentation of the apa ity of Mobile IP tointegrate heterogeneous
proto ols above and below it.
Chapter 6 takes a look into the possibilities aroused by the ombinationof Mobile
IP and mobile devi es hosting multiple a ess interfa es. It introdu es a Mobile
IP proto olextensionfor ow managementinmobile nodes equipped withmultiple
a ess interfa es.
Chapters 7and 8are astudy onthe performan e ofInternetreliableand unreliable
transport proto ol (TCP, UDP) during ow management with the help of Mobile
IP.
A Review of Proto ols for Internet Mobility
Support
Igrow oldlearningsomething new
every day.
Solon
F
rom a te hni alstandpoint,a solutiontothe problemof Internet mobility an be supported through a number of dierent approa hes nesting at dierentlayers withinthe Internet sta k.
Everyproto olformobilitysupporthas tofa ilitate anumberof fun tionsfor
lo a-tionandhand-omanagementandhastodemonstrateviabilitythroughtransparent
integration into the Internet sta k and infrastru ture. There are also performan e
and se urity requirements with whi h a proto ol has to omply. This thesis is
dedi ated to the performan e evaluation and improvement of Mobile IP, while an
investigationof the e ien y of se urity me hanisms of Internet mobilityproto ols
is onsidered a resear h subje t by itself and is not handled within the framework
of this thesis.
The followingse tions give abrief des riptionof requirements forInternet mobility
supportfollowedbyapresentationofarangeofsu hproto ols. Theseare ompared
with ea h other with respe t to their viability and apa ity to omply with the
requirements set. As itwillbe shown, Mobile IP isthe mostviable solutionfor the
Internet today, supportinga pallet of me hanismsfor mobilitymanagement.
2.1 Requirements for Mobility Support
The viabilityofamobilityproto olisguarantiedbytransparentintegrationatlarge
s ale within the Internet sta k and existing infrastru ture. Transparen y has to be
established at threedierent levels [22℄ des ribed as follows:
•
Operationaltransparen y.•
Proto ol transparen y.•
Performan e transparen y.2.1.1 Operational Transparen y
Operationaltransparen yrequires that anysolutiontothe problemof Internet
does not in lude any su h fa ilities and as su h this should be the fun tion of a
separate proto olextension.
The primary fun tionof aproto olformobility supportis to ater forlo ationand
hand-o management.
Lo ation Management
On the Internet two dierent namespa es are used to identify a node's point of
atta hment to the Internet, namely the Internet Proto ol (IP) addresses and the
Domain Name Servi e (DNS) names. If a node is no longer a essible at the IP
addressresolved byitsFullyQuali ed DomainName(FQDN),thenno
ommuni a-tions willbeinitiated with that node. Therefore, a me hanismthat enables anode
torendezvous with anothermobile node, nolongerlo ated attheaddress indi ated
by its domainname, is ne essary. This problem des ription highlightsthe need for
a lo ation management s heme alsoknown as a rendezvous me hanism.
Hand-o Management
The manner in whi h lo ation information is updated at infrastru ture entities or
ommuni ation peers during mobile node mobility ae ts the performan e of
a -tive ommuni ations. Up to date lo ation information is usually made available a
posteriori withreferen e tothe time-pointof lo ation hange reating aservi e gap
between the time of mobility and the time of ommuni ation re overy.
The fa ilities oered by a mobility proto ol for sustaining a tive ommuni ations
a ross lo ation hanges is known as a hand-o management me hanism. A spe ial
hand-o s enario is en ountered when both ommuni ation peers are mobile and
simultaneously perform mobility. In that ase, a mobility proto ol should be able
to re over with the shortest possibleservi e interruption.
2.1.2 Proto ol Transparen y
Proto ol transparen y requires that any alterations should be restri ted to mobile
nodes and a minimum extent of existing Internet infrastru ture [114℄. In this
man-ner, existing andwell establishedInternet proto olsare preserved andremain
unaf-fe ted inspite of being deployed inenvironmentsother than those designed for.
Proto ol transparen y also in lines ba kwards ompatibility. That is, a mobility
proto ol should be able to remain operational even in environments that do not
provide fa ilitiesfor mobility support.
2.1.3 Performan e Transparen y
Performan e transparen y for es on Internet mobility solutions a requirement for
Itisthepurpose ofthisthesistoevaluateandimprovetheperforman eofMobileIP
proto olfor Internetmobilityandtodeliverperforman e levelsand servi esbeyond
those a user may be a ustomed tofrom a xed Internet lient.
The followingse tionsare devotedtothepresentationof varioussolutionsthathave
been pursued by resear hers in the past and others that are still a tivelly pursued
today. The presented approa hes are grouped in dierent ategories depending on
the part of the Internet sta k in whi h they are lo atedor the part of the network
infrastru turethattheyae t. Thedis ussionofpresentedsolutionsrevolvesaround
their apa ity to omply with the three levels of transparen y presented in this
se tion.
It isnotedthat the bulkofthe resear h presented inthis thesishas been ompleted
even beforeseveral of these approa hes hadbeenpublished. Nevertheless, itwillbe
shown that the sele tion of the Mobile IP proto ol as the basis of this thesis is as
validnowas itwas then.
2.2 Internet Infrastru ture
Maximum omplian etooperationalandproto oltransparen ydi tatesthata
mini-mumamountofalterationsshouldbeundertakenatmobilenodesortheir
ommuni- ationpeers; espe iallysin eend-devi es ingeneraland mobilenodes inspe i an
be assumed as thin lients with limited pro essing and battery apa ity. Solutions
based on this assumption have dire ted their fo us on the Internet infrastru ture
and the possibilitiesprovided by se urity me hanisms orthe Domain Name Servi e
(DNS).
2.2.1 Dynami DNS
Rendezvous fun tionality suggests the existen e of a registration me hanism that
allows mobile nodes to update their lo ation information at a stati entity that is
easily a essible by all potential ommuni ation peers. The DNS dynami update
[140℄ is a plausible me hanism to obtain new lo ation information. However,
Dy-nami DNSisnot widely deployed and thetypi alDNS re ordlifetimesettingsand
lient a hingbehaviourssuggestthatexistingDNSuseisbettertailoredfor hanges
overdays,ratherthanhoursorshortertimeintervals. More importantly,uptodate
lo ationinformationisoflimiteduseon eatransportlayer ommuni ationhas been
established between the twopeers.
Dynami DNS isalo ationmanagementme hanism thatdoesnot addresshand-o
management. For this reason, it partially omplies with operational transparen y.
2.2.2 IKEv2 Mobility and Multi-homing Proto ol
The IKEv2 Mobility and Multi-homing (MOBIKE) [78℄ proto olis anextension of
the Internet Key Ex hange Proto ol version 2 (IKEv2) [76℄, i.e. a omponent of
IPse used for performingmutual authenti ation and the establishmentand
main-tenan e of se urity asso iations. The extensions de ned by MOBIKE enable an
e ient managementof IKEandIPse Se urityAsso iationswhenahost possesses
multiple IP addresses and when the address of a node hanges due to mobility.
Mobility support is provided with the help of se ure tunnels whi h are set up and
renegotiatedwith every lo ation hange. Appli ationsrunninginside the MOBIKE
ontrolled IPse tunnel might not dete t the movement sin e their IP addresses
remain onstant.
MOBIKE does not provide any fa ilitiesfor lo ation management or the re overy
from simultaneous mobility and as su h it is not onsidered a omplete Internet
mobility proto ol.
Thefollowingse tiongivesabriefoverviewofapproa hes totheproblemofInternet
mobility atthe transport layer.
2.3 Transport Layer Approa hes
TransportlayersolutionsattempttoaddresstheproblemofInternetmobilityatthe
layer that suers most from mobility. Su h approa hes have the bene t of leaving
the IP infrastru ture un hanged. There have been many resear h eorts toresolve
the problemof Internet mobility at the transport layer. Mostsu h solutions fallin
one of the following ategories:
•
Split onne tionproto ols•
Mobilityextensions totransportproto ols•
New mobilityaware transport proto olsThe following se tions give a brief des ription of ea h of the three ategories and
resear h initiativesunder ea hof these ategories.
2.3.1 Split Conne tion Proto ols
Through the lifetime of the Internet several split onne tion proto ol approa hes
have been proposed ea h originating from dierent assumptions. The oldest
ap-proa hes su h as the I-TCP [13℄ and MTCP [145℄ are motivated by the unreliable
hara ter of the wirelesssegment onne ting themobile node tothenetwork. Later
approa hes su h as the Mobile TCP [62℄ address the limited pro essing apa ity
and battery lifetime of thin mobile lients. More re ent investigations su h as the
MSOCKS [91℄ assume more robust mobile devi es equipped with multiple wireless
onne -Stationary Node
Mobile Node
AP/Proxy
Wireless link
Wireless TCP
TCP
end -to-end communication
Internet
Figure 2.1: The Split TCP
proto olthat enablesboth TCP and UDP lient-serverappli ations touse se urely
the servi es of anetwork rewall.
TheSplit onne tionproto olapproa hinvolvesthedivisionofea hTCP onne tion
between a sender and a re eiver into two separate onne tions at an intermediate
devi e, usually the wireless a ess point (AP) or a proxy (see gure 2.1). The
rst onne tionis established between the mobile node and the a ess point and is
ne-tuned for optimal performan e over wireless links. Other approa hes assume
an assymetri TCP aimingat minimisingthe ommuni ation overhead for the thin
mobile lient. The se ond onne tion is established between the a ess point and
the re eiver and uses onventional TCP.
Split onne tionproto ols suer fromthe maindisadvantage of violatingTCP
end-to-end semanti s. The onne tion is no longer driven by the sender and re eiver
whereby it is possible for a pa ket to be re eived and a knowledged by the a ess
pointeven beforeit has been delivered to itsdestination. Moreover, the signi ant
amount of state that the a ess point maintains per onne tion may be di ult to
re-establish at another a ess point inthe event of ahand-o [130℄.
Split onne tion proto ols fo us stri tly on the re overy of a TCP ommuni ation
in the event of break up due to mobility. They do not address the issue of mobile
node rendezvous nor the s enario of simultaneous mobility. Finally, split
onne -tion proto olsfail to omply with the requirement forproto oltransparen y due to
violation of TCP end-to-end semanti s.
2.3.2 Mobility Extensions to Transport Proto ols
In this groupof solutions the transport layerproto olis extended tore over in the
eventofmobilityandtobeabletoresumeon eoneofthe ommuni ationpartieshas
beenrelo ated. Su happroa hessele tivelyaddresstheproblemofInternetmobility
for a spe i transport proto ol i.e. the TCP, in lining that a similar me hanism
would have tobede ned for UDP [130℄.
TCP Migrate
TCP Migrate [130℄ des ribes aset of TCP optionsthat enable an a tive TCP
appli ation- ommuni ation may not be prede ned. TCP Migrate di tates that when hanging
lo ationa mobilenode is required toinitiate anew separate TCP onne tion. The
Transmission Control Blo k (TCB) of the original TCP onne tion an be
trans-ferred tothe new onne tion ausingthe data transfertoresumewhereit leftoat
the time of the lo ation hange.
The TCB ontains all the importantinformationabout the onne tion, su has the
two so ket numbers that identify it and pointers to buers where in oming and
outgoing data are held. The TCB is also used to implement the sliding window
me hanism. It holds variables that keep tra k of the number of bytes re eived
and a knowledged, bytes re eived and not yet a knowledged as well as the urrent
windowsize.
TCP Migrateisanapproa hfo usingonthesupportofmobilityforaspe i
trans-port proto ol. It provides hand-o management but fails to address simultaneous
mobility. Moreover, it does not oer a lo ation management s heme. As a result,
TCP Migrate is not a omplete proto ol forInternet mobility support.
2.3.3 New Mobility Aware Transport Proto ols
Inthere entyearsseveralnewInternettransportproto olsfo usingonaspe ialised
appli ation domainhave undergone standardisation. In these proto ols the issue of
mobility is not dire tly addressed but further extensions to the basi proto ol aim
at providingsome mobility support.
Proto ols presented in this se tion are new to the Internet proto ol suite and as
su h do not omply with proto oland performan e transparen y. Theirevaluation
revolves aroundtheir apa ity to addressoperational transparen y.
Stream Control Transmission Proto ol
The Stream Control Transmission Proto ol (SCTP) is a reliable transport servi e.
SimilartoTCP,SCTPisasession-orientedme hanism,meaningthatarelationship
betweentheendpointsofanSCTP ommuni ationisnegotiatedpriortodata
trans-mission. SCTP in ludes native support for multi-homing but only for redundan y
purposes. Thismeansthat,SCTPendpointsex hangelistsofaddressesduring
initi-ationofthe asso iationwhileasingleoneis hosenfortheSCTPdatatransmission.
The set of addresses ex hanged during initialisationis known a priori and remains
xed throughout the ourse of the ommuni ation. Should the IP address in use
be omeunavailable or when demonstratinghigh pa ket lossrates, the
ommuni a-tion willfall-ba k toanother home IP address until the rst one be omes available
again.
Furtherproto olextensions forSCTP su hasthe [135℄enable SCTPtore on gure
dynami allyIPaddressinformationforasessionbyadding/deletingIPaddresses or
setting a new primary IP addressas the re ipient of ommuni ation tra . Mobile
Resear h in this area has not been nalised and is still onsidered work in progress
in Internet standardisation. At the same time deployment of SCTP inthe Internet
infrastru ture is minimal.
Mobile SCTP introdu es hand-o management in SCTP but does not address
si-multaneousmobility. MobileSCTPdoesnotprovideany onsiderationsforlo ation
management. Forthis MobileSCTP is onsidered, by itself,unsuitablefor mobility
management.
Datagram Congestion Control Proto ol
The Datagram Congestion Control Proto ol (DCCP) [79℄ is a transport proto ol
intended forstreaming appli ations. DCCP hasrisenfromthe inabilityofTCP and
UDP to ater forthe spe ialisedrequirementsof su happli ations;TCP introdu es
longdelays duetoits ow ontrolandre overyme hanisms,whileUDP avoidssu h
delays but relies onthe appli ationsto implement ow ontrol.
DCCP delivers a transport proto ol apable of sustaining a bidire tional, uni ast
onne tions of ongestion- ontrolled,unreliable datagrams.
A DCCP onne tion isasso iatedthrough itslifetimewithtwoIP addresses
identi-fyingthetwo onne tionendpoints. [80℄proposesanextensionofDCCP thatallows
for address rebinding thusallowing for hand-omanagement. Apart from that [80℄
does not address simultaneous mobility orlo ationmanagement.
AswithMobileSCTP,mobilityextensionsforDCCParestillundergoing
standardis-ationwhiletheappli ationenvironmentthatremainsthefo usofDCCPisrestri ted
to streaming appli ations. At the time of preparation of this thesis, deployment of
the DCCP is minimal.
2.4 Convergen e Layer Approa hes
A re ent approa h to mobility support de nes a new onvergen e layer that exists
onlywith ommuni ationpeersandoperatesbetween thenetworkandthetransport
layer. In this manner, it de ouples the IP routing fun tionality from transport
proto ols enabling both to evolve separately. The operations of the onvergen e
layer are invisibleto other layers above and below but require modi ations to IP
infrastru ture inorder to obtainfull rendezvous apabilities.
2.4.1 Lo ation Independent Network v6
Lo ation Independent Network v6 (LIN6) is a proto ol supporting multi-homing
and mobility in IPv6. LIN6 is based on LINA (Lo ation Independent Network
Ar hite ture) that introdu es two types of addresses, namely the node identi er
and the interfa e lo ator.
onne -Web , FTP
IEEE 802 .11 , GPRS,
Ethernet
4. Application
3. Transport
2. Internetwork
1. Link
TCP/UDP
Delivering sub-layer
Identification sub-layer
Figure 2.2: The Lo ationIndependent Network Ar hite ture Proto olSta k
lo ation,i.e. it denotes the urrent point of atta hment. It is assigned toa spe i
network interfa e and ae ts the pa kets' routing.
The asso iation between a node identi er and a node lo ator is denoted as a
map-ping. LINA assumes the existen e of a remote entity alled the mapping agent
that keeps re ord of amappingfor ea hmobile node. Mobile nodes are requiredto
register amapping and update itwhen relo ating.
Appli ationandtransportlayerinitiate ommuni ationsbyusingthenodeidenti er.
The resolution between the node identi er and the interfa e lo ator o urs in the
internetwork layer by querying the mapping agent as part of the fun tionality of
anidenti ationsub-layer. The deliveringsub-layer isresponsible fordelivering the
pa ketwith respe t to the interfa e lo ator(see gure 2.2).
LIN6 is onsideredtheappli ationof LINAtoIPv6 [3℄. TheLINAnodeidenti eris
de ned asthe LIN6 generalised identi er(LIN6 ID) represented by a64 bitunique
number. The LINA interfa e lo atoris alled the LIN6 address. The LIN6 address
isanIPv6globaluni astaddressformedbyjoiningthe networkpre x ofthemobile
node's urrent lo ationand it's LIN6 ID [137℄.
LIN6 deploystheDomain NameServi e(DNS)forlo atingtheresponsiblemobility
agentofamobilenode. Themappingregistration pro ess o ursintwosteps. First
the mobilenode dete ts the responsible mobilityagentsviaa DNSlookupand then
it issues a mapping update to the respe tive mobility agent [85℄. In this manner
LIN6 supports lo ationmanagement.
In the event of mobility, the mobile node will update the mobility agent as well
as all ommuni ation peers enabling ommuni ations to resume. In this manner,
LIN6 a hieves hand-o management. In the spe ial ase of simultaneous mobility
LIN6 mobile nodes would attemptto onta t ea hother dire tly at the lastknown
address orrespondingtotheformerlo ationsofthemobilenodesand,hen e,failing
to omplete the hand-o.
LIN6 delivers through its modus operandi operational transparen y whi h is one
of the fundamentalrequirementsfor Internetmobility support. Performan e
trans-paren y is a hieved through the adoptionof simple, s alable me hanisms based on
exter-Web , FTP
HIP
IEEE 802 .11 , GPRS,
Ethernet
5. Application
4. Transport
2. Internetwork
1. Link
Internet Protocol
TCP/UDP
3. Host Identity
Figure 2.3: The Host Identity Proto olSta k
delivery of tra tomobile nodes.
Theintrodu tionofanidenti ationsub-layerintothenetworklayeraimsat
provid-ing proto ol transparen y by limiting alterations to the network layer while layers
above and belowremain unae ted. An important aspe t of proto oltransparen y
is ba kwards ompatibility;the abilityto maintain servi e innetwork environments
where supportfor the proto olisnon existent.
In the ase that LIN6 is not supported by all ommuni ation peers, then none of
the addresses de ned by LINA may be put to use and none of the LIN6 spe i
operations may be exe uted. As su h mobility an alsonot besupported.
LIN6 provideslo ationand hand-o managementbut does not onsider the ase of
simultaneous mobility.
LIN6madeitsappearan einthe IETFwithadraftproto olproposalthatappeared
in 2003. It has sin e expired and not updated again.
2.4.2 Host Identity Proto ol
The HostIdentity Proto ol(HIP)Ar hite tureidenti esthatthe elementsof
multi-homing and mobility have reated a dis repan y between Internet addresses and
names handled by the Domain Name Servi e (DNS). The HIP ar hite ture
intro-du esanewnamespa e onsistingofHostIdentities(HI)aimingatbridgingthe gap
between the IPand DNS namespa es. [95℄des ribesthat any namethat isglobally
unique may serve as an HI. However, using ryptographi publi keys as HI an
authenti ate the HIP pa kets and prote tthem from various se urity atta ks.
The HIP ar hite ture de nes two types of addresses, namely the Host Identity Tag
(HIT) andthe Lo alS opeIdenti er (LSI) towhi h insteadofIP addresses, higher
layer proto ols an bind.
The HITisa128-bit ryptographi hash ofaHostIdentity. Itisthe samelengthas
an IPv6 address and an be used in address-sized elds in APIs and proto ols. A
Lo al S ope Identi er (LSI) is a 32-bit lo alised representation of a Host Identity.
layerde ouplesthetransportfromtheinternetworkinglayerandbindsthetransport
asso iationstothe HostIdentities (througha tually eitherthe HITorLSI) thereby
enabling ontinuityof ommuni ationsa rossIPaddress hanges. TheHIPproto ol
de nes the basi intera tion between hosts in order to establish a HIP asso iation,
priortoa ommuni ation. TheHIPasso iationinvolvestheex hangeoffourpa kets
between the ommuni ation initiator and responder in order to form an IP layer
ommuni ation ontext inwhi h partiesex hange keys and are authenti ated. The
HIP asso iation remainsvalidthroughout the ommuni ation.
TheHIPar hite ture onsidersarendezvous me hanismrealisedthroughstationary
rendezvous servers [83℄ whi h serve as an initial onta t point for lients. HIP
supports lo ation management by requiringall nodes to register[84℄ their lo ation
with rendezvous servers when they move.
WhenaHIPnodewantstoinitiatea ommuni ationwithanotherHIP node,it rst
needs to obtain the HI of the responder and then initiate a HIP base ex hange to
set up a HIP asso iationwith its peer.
[99℄ de nes a resour e re ord (RR) for DNS [93℄ that allows a HIP node to store
in DNS its HI, HIT and the Domain Names of its rendezvous servers. Through
su essiveDNSlookupsaninterestedpartymaydeterminewhetherthemobilenode
supports HIP as well its HI, HIT, the FQDN and IP address of the responsible
rendezvous server.
The initialpa ket of the HIP base ex hange is forwarded to the rendezvous server
while further pa kets are ex hanged dire tly. Clients of a rendezvous server are
requiredtouse theHIP RegistrationProto ol[84℄toregistertheiraddressmapping
with the rendezvous server.
IntheeventthatHIPisnotsupported, ommuni ationswillhavetouse onventional
IP operations failingtobene t fromthe advantages oered by HIP.
[64℄ de nes anextensionfor HIPsignallingthatenablesmobile HIPnodes tonotify
apeeraboutalternate IPaddresses onwhi hitisrea hable. The end-host mobility
onsiderationspresentedbythisproto olextension onstituteame hanismfor
hand-o management but fail toaddress simultaneous mobility.
HIP isanelegantapproa htoInternetmobilitythatis startingtogain momentum.
HIP is also work in progress. At the time of preparation of this thesis, HIP is not
mature enough to take on the role of the primary proto ol for Internet mobility
management. The impa t of HIP to this eld of resear h remains tobe de ided in
the years to ome.
2.4.3 Multiple Address Servi e for Transport
The Multiple Address Servi e for Transport (MAST) [33℄ supports the of multiple
IPaddresses duringthelifeofanytransportasso iation,byde ningalayerbetween
those of network and transport.
dif-proto ol for the ex hange of IP addresses and authorisation [32℄. As in HIP
ren-dezvous with mobile targets is supported through a two-stage pro ess. A domain
name is used as the stable, publi and globally unique domain name (Endpoint
Identi er). The DNS resolution ofthe EndpointIdenti er willresult inthe address
of a dynami servi e through whi h an endpoint an register its urrent set of IP
addresses.
MAST interfa es with transport proto ols in either of two ways. The rst assumes
thatatransportasso iationhas beenestablishedbetweentwo ommuni ationpeers
beforethe invo ationofMAST. Inthat ase,thetransportproto ol ommuni ation
hasalreadyformeda5-tuple ontainingtheIPaddressesofthe ommuni ationpeers.
MAST de nes a mapping between addresses at the MAST layer requiring pa kets
tobetranslated between the addressassumed by the transportlayerand that used
by the network layer for routing purposes. This fun tionality would be ne essary
for both in oming and outgoing tra . The alternate approa h assumes the use
of private addresses [123℄ foralldestination addresses providingthe transportlayer
with the illusion that alltra is omingfrom aninternally allo ated address.
The MASTproto olspe i allydi tatesthatrendezvous fun tionalityis onsidered
a part of the proto ol but does not address the event of simultaneous mobility.
The MAST spe i ation is not omplete and all do uments that have entered the
Internet standardisation tra k have expired sin e 2003.
Convergen e layer approa hes are quite elaborate and deliver a re ned solution to
the problems of mobility,multi-homing,se urity and authenti ationwith one blow.
However, none su h solution has so far been a knowledged with signi ant spread
on the Internet.
The following se tion is devoted to the des ription of the dominant approa h to
appli ation layermobility,known asthe Session Initiation Proto ol.
2.5 Appli ation Layer Approa hes
Multimedia streaming appli ations have spe ialised requirements that in lude
dy-nami session management e.g. session parameter negotiation, trans oding as well
as the need to support dierent types of mobility, besides terminal mobility. The
following se tion is devoted to the presentation of an appli ation layer mobility
proto ol; the Session InitiationProto ol.
2.5.1 Session Initiation Proto ol
The Session Initiation Proto ol (SIP) [126℄ is an appli ation-layer ontrol proto ol
that allows two or more parti ipants to establish, modify and terminate multiple
multimedia sessions ( onferen es). The multimedia streams an be audio, video or
any other Internet-based ommuni ation me hanism. The streams of a single user
SIP requires several logi al entities to operate, namely user agents, proxy servers
and redire t servers [26℄.
The SIP user agents have two basi fun tions: listeningfor in oming SIP messages
and issuingSIP messages in rea tionto user a tions orin oming messages.
Gener-ally,user agents are the only entities wheremedia and signalling onverge.
Typi ally, a SIP server ombines the fun tionality of a redire t and proxy server.
Depending on on guration and the spe i request, the server may a t either as
a proxy or as a redire t server. Both may a ept registrations from user agents.
Whenever an invitation message is re eived by a redire t server, it is required to
respond to the message initiator( aller) indi atinga next hop where the requestor
shoulddire t itsrequest. Thismay bethe user agent's urrentlo ationorafurther
SIP server.
As opposed toaredire tserver, whi hreturnsnext hop informationuponre eiptof
aninvitationbya aller,aproxytakesontheresponsibilitytoforwardtheinvitation
to a next hop itself. The next hop may be the destination user agent ( allee) or a
further SIP server. In this mannerit ispossible tohide the lo ationof a user agent
by restri ting redire t information.
It is expe ted that SIP proxy servers will demonstrate higher loads than their SIP
redire t ounterparts sin e they are required to parti ipate in the whole signalling
transa tion instead of justsending ananswerwith a user agent'slo ation[128℄.
A ording to its spe i ation, SIP overs ve dierent important aspe ts of
estab-lishing and terminating multimedia ommuni ations, whi hare [35℄:
•
Userlo ation,determiningthe end system tobeused for the ommuni ation.•
Useravailability,determining the intentions of the alledparty onengagingin ommuni ations.•
User apabilities,determiningthe media apabilitiesofterminalsaswellasthe preferablemedia parameters tobe used.•
Sessionset up, negotiation of sessionparameters for both aller and allee.•
Sessionmanagement,in ludingtransfer andterminationofsessions,modifying sessionparameters and invoking servi es.Thesefa ilitiesenableSIPtosupportdierenttypesofmobilityotherthanterminal
mobility [128℄whi h isthe fo us of this thesis.
SIP is a robust proto ol ne-tuned to the spe ialised requirements of a spe i
appli ation domain. SIP delivers mobility support to multimedia sessions with a
rendezvous me hanism and a range of solutions for simultaneous mobility [142℄.
However, even though this approa h an be onsidered a eptable for appli ations
with spe ialised requirements it might be too di ult to pursue for a range of
In-ternet appli ations. Hen e, SIP may not be onsidered the primary proto ol for
Internetmobilitysupport but an be usedin onjun tion withother proto ols su h
Figure 2.4: TCP/IP Proto olSta k with Mobile IP
The followingse tion presentsthe dominantapproa htoInternet mobilitythrough
the network layer.
2.6 Network Layer Approa hes
Internetmobilityis allabout routingtra to the movingpointof atta hment ofa
mobile node. The network layeris regarded as the part of the Internetsta k where
routing me hanismsreside, hen e, anapproa h di tatingthe introdu tionof a new
proto ol for mobility support at the network layer is onsidered the most natural
approa h. Motivated by this on lusion and based on the requirement for
opera-tional transparen y, theIETF formed arelevantworking groupwith thepurpose of
de ning a new proto ol. The requirement for proto ol transparen y was a
guide-line for the de nition of proto ols and a riterion of proposals on the way towards
standardisation [97, 98, 110, 116℄. Finally, performan e transparen y has been the
resear h obje tive of many studies and the primary fo us of this one. There have
beena numberof proposedstandards atthe Mobile IP working groupof the IETF.
Eventually, only one was onsidered mature enough and omplying best with the
requirements set. This solutionis presented inbrief inthe followingse tion.
2.6.1 Mobile Internet Proto ol
TheMobileIP(MIP)[114,109,112,71,115,117℄isanextensionofthebasi proto ol
design for Internet mobile node support, for this reason, Mobile IP is onsidered a
sub-layerof the Internet Proto olinthe Internetwork layerof the TCP/IPproto ol
sta k as itis shown in gure 2.4.
Mobile IP introdu es three new network entities, namely the Home Agent (HA),
ForeignAgent(FA)andmobilenode. AlternativeMobileIP on gurations(MIPv6)
[71, 132℄ may omit the FAs by distributing their fun tionality amongst the mobile
node and the network infrastru ture. In Mobile IP all potential ommuni ation
peers tothe mobile nodes are termedCorrespondent Nodes (CN).
! " # !$ %$ & ' %$ () * + + !, () - - " () * + + !, () *+ +!,
Figure 2.5: The Mobile Internet Proto ol
additionaltemporaryIP address ( are-of address) asso iated with its urrent point
of atta hment to the network. The are-of address an be a quired either by FA
period advertisement orwith the help of aremotea ess server su h asa DHCPor
PPPserver( o-lo atedmode). Asamobilenodemoves, itisrequiredtoregisterits
are-ofaddresswiththeHA,hen eestablishingabinding. Throughthisme hanism,
theHA maintainsanoverviewofthemobilenode'slo ation(lo ationmanagement).
The basi fun tionality of Mobile IP resembles the post-o e forwarding servi e.
For every registered mobile node the HA is required to a t asa proxy in the home
network, inter ept allin omingtra and redire tit through pa ket en apsulation
tothemobilenode's mostre ently registeredlo ation. Under ertain onditionsthe
mobile node may respond dire tly to the CN bypassing the HA.
Thevisualisationoftheaforementionedtra owresemblesatriangleandis
there-fore referred to as triangular routing ( gure 2.5). Several en apsulation te hniques
have been standardised by the IETF but within the framework of MIPv4, IP-in-IP
en apsulation has dominated [108℄.
In Mobile IP, a mobile node is identi ed by its permanent home IP address. All
tra destined for a mobile node is dire ted to its home IP address. If the mobile
node is roaming, the HA will intervene to assure that tra is delivered to the
mobile node's most re ently registered lo ation.
In the event of a hand-o, the mobile node will initiate a registration as soon as
it has a quired a new network link and a are-of address. CNs do not be ome
aware of hanges to the mobile node's lo ation and ontinue to dire t tra to
its home address (hand-o management). In this manner, transport asso iations
remain unae ted in spite of mobilenode mobility.
ThesameoperationalmodeallowsMobileIPtohandlesimultaneousmobility. That
is, if both parties of a ommuni ation hoose to move at the same time a quiring
new are-of addresses, they will ontinue to dire t tra to their peers' home IP
address. When both hand-os are ompleted, the ommuni ation willresume.
Throughe ientlo ationandhand-omanagementme hanisms,MobileIPsatis es
In the event thatMobile IP isnot supportedand FA's are not available, themobile
node will adopt o-lo ated mode, a quiring a are-of address from a lo al remote
a ess server. In this manner, proto oltransparen y is guaranteed.
Mobile IP introdu es a performan e degradation aused by the need for triangular
routing and Mobile IP hand-os.
There have been several subsequent extensions to Mobile IP trying to address
tri-angular routing and to introdu e route optimisation [113℄ fa ilities. Even though
they have not turned out to be parti ularly popular with MIPv4 they have been
integrated asdefault features in MIPv6.
Anadditionalpointof ontroversyhasbeenthe standardisationofanotherproto ol
extension for the hierar hi al organisation of Mobile IP networks [27, 122, 61, 37℄.
Their primary obje tive has been among others regional registration management,
mobility a eleration(hand-os)and pa ket lossre overy.
MobileIPistheonlyapproa hpresentedinthis hapterthat omplieswithalllevels
of transparen y. The signi ant number of ommer ial and open sour e
implemen-tations [4℄ of the proto ol enable Mobile IP to to stand out as the most mature
approa h to Internet mobility support. For this reason, ithas been sele ted as the
fo alpoint of this thesis.
As it willbeshown inthis thesis, Mobile IP an be brought todeliverperforman e
levelsequivalentto,if not ex eeding, thosea usermay experien e withastationary
lient.
Through global deployment of IPv6 the future remains bright for Mobile IPv6 in
future tele ommuni ationsystems. The ontrast between the urrent realitiesof IP
onne tivity andfuturepossibilitiesisapparentfromthetransitiontoward mobility
that has o urred intelephony overthe past twenty years. An analogous transition
inthe domainof networking, fromdependen e on xed pointsof atta hment tothe
exibility aordedby mobility, has onlyjust begun.
2.7 Con lusions
Inthis hapterdierentapproa hestoInternetmobilityhavebeenpresented. These
have been evaluatedwith respe t to their fun tionality and ability to maintain
op-erational, proto ol and performan e transparen y. It was determined that Mobile
IP is amature solution for Internet mobility management regardless of the type of
overlying appli ationortransport proto oland apableof deliveringservi e even in
environments that do not providefa ilitiesfor mobileoperation.
The following hapter givesanoverview of Mobile IP hand-omanagement
me ha-nism andits ee tontransport layer ommuni ations. It pro eedswith a
presenta-tion of aseries of improvementsand demonstratesby means of analysis,simulation
a eler-Mobile IP Hand-os
Ifyour name or mineis ever
remembereditwill only be be ause
ofhis.
1492: Conquestof Paradise (1992)
T
he purpose of this hapteris to providea omplete investigationof Mobile IP hand-os. It starts with a detailed breakdown of the Mobile IP hand-olife- y le indi atingthe Move Dete tion algorithmsas the de isive fa tor in Mobile IP
hand-o performan e. This is followed by a detailed investigationof various types
of MoveDete tion algorithms. In turn, they are evaluatedand ompared withea h
other with the help of simulations and mathemati al analysis. Finally, a sele tion
of su h algorithmsis experimentally evaluated inorder to determine the overheads
imposed by lower layers upon Mobile IP during hand-os. This hapter on ludes
withanintrodu tionofearlyapproa hestotheproblemofMobileIPhand-oservi e
disruption in a hierar hi al Mobile IP framework. A brief performan e analysis
demonstrates the ine ien y of su h solutions.
Due to the OSI fundamental assumption of layer independen e that prohibits the
ommuni ationbetween Mobile IPand lowerlayers, Mobile IPisrequiredtorealise
network layer based me hanisms in order to perform movement dete tion, lo al
mobility agent dis overy and agent sele tion. The resolution of the aforementioned
tasksisregardedasthe purpose oftheMobileIPMoveDete tionalgorithms. These
algorithmsareresponsiblefor initiatingaswellasdeterminingthe parameters(new
serving agent) of a Mobile IP Registration. As su h the performan e of Mobile IP
Move Dete tion algorithms is onsidered a de isive fa tor in Mobile IP hand-os.
MobileIP requiresthatMoveDete tionalgorithmsrelyonperiodi agentbroad ast
advertisements (bea ons) with a de ned maximum agent advertisement rate. This
has ledtothedevelopment ofthe Advertisement BasedMoveDete tionalgorithms,
namely Eager Cell Swit hing, LazyCell Swit hing and Pre x Mat hing.
[48℄ has indi ated for straight line movement patterns that the interruption
intro-du edbytheMobileIPMoveDete tionpro essalonemayrangeintermsofse onds,
even with the maximum advertisement rate. When delivering tele ommuni ation
servi es su h as telephony over IP, an interruption of that s ale is not a eptable.
[25℄ showed that optimum MoveDete tionperforman e an bea hieved by
in reas-ingthe advertisementrate above thede ned maximum,but indi ated thatfor high
per-the Hinted Cell Swit hing Move Dete tionalgorithm. It suggested that by
overrul-ing the OSI assumption of layer independen e and establishing a ommuni ation
between Mobile IP and lower-layers for the ommuni ation of events su h as
lower-layer hand-os, optimum Move Dete tion performan e ould be a hieved without
ae tingthe linkthroughput. Itwasshownthrough anexperimentalapproa hwith
the IEEE 802.11b Wireless LAN [66℄ that the need for the Advertisement Based
Move Dete tion pro ess an be eliminated by extending the amount of information
ommuni atedbetween MobileIPandthelower-layers toin ludeinformationabout
the mobile node's urrent environment, su h as the Internet and hardware address
of thelo almobilityagent[47℄. Thisinformation anbeuseddire tlyby themobile
node in order to initiate an immediate registration and therefore adapt as fast as
possible to its urrent lo ation. This solution was onsidered an extension of the
HintedCellSwit hingalgorithmandisthereforetermedFastHintedCellSwit hing.
Bothof these algorithmsrelyonlower-layerhintsinorderto performsome orallof
the Move Dete tion fun tionality. Thus, su h algorithms have been grouped under
the name HintBased Move Dete tionalgorithms.
Alternativeapproa hes tothe problemof Mobile IP hand-oswere based ona
Mo-bile IP fa ility allowing for the dupli ation of a mobile node's tra . It enabled
mobile nodes to initiate multiple auxiliary streams to potential migration
destina-tions, eliminating any interruption introdu ed by the Mobile IP hand-o pro ess.
This approa h, termed Fast Hand-os, introdu ed signi ant redundant tra and
was therefore deemed ine ient.
Existing resear h [48, 47, 50, 43℄ has measured the performan e of Advertisement
Based aswellas Hint BasedMove Dete tionalgorithmsex lusively underslowand
straight line movement patterns. In this hapter, these algorithms are analysed
and evaluated by means of simulations and mathemati al analysis and ompared
with ea h other. The movement patterns assumed in simulations in lude straight
line as well as ba k-and-forth movement of various speeds. This is followed by
anexperimental omparison ofthe twofastest advertisement and Hint BasedMove
Dete tionalgorithms. Experimentalresultsareveri edbyresultsa quiredbymeans
of mathemati al analysis of Advertisement Based and Hint Based Move Dete tion
algorithms. The purpose of this investigationis to determine the ee t of the
link-layer toMobile IP hand-os.
The s enarios investigated through this hapter involve single-agent IP networks.
However, on lusions drawn are valid for other s enarios. The overlying
ommuni- ation is a unidire tional Internet audio stream with the mobile node as re eiver.
Allthe on lusionsdrawn shouldbeappli ablefor ommuni ationsoriginatingfrom
the mobile node or bi-dire tional ommuni ations.
The hapter on ludes with a brief presentation of the Mobile IP Fast Hand-os
. ./0 /. / 0 1/2 3 4 5 6 7 89 :7 ;< = . > . > .? @ ABC ? D >E DC >F 2 AB BCGHA >I C >F0 A I C J AKC E D C >F L AM ?N C 0 A I C @ ABC ? D >E D C >F EO EO PQ R PQR STUV W TXY Z[ \ ]^ _`aX W TX Y Z[\ ]^
Figure 3.1: Mobile IP hand-o between IEEE 802.11and WLAN IP Network
3.1 Internet Mobility Management
Node mobility di tates the need for mobile node hand-os. In general, whenever a
mobilenodeleavesanetworkandentersanother,itisrequiredtoperformahand-o.
A MobileIP hand-oo urswhenever amobilenode movesbetweentwoIP
admin-istrative domains (IP networks). However, a single IP administrative domain may
ombine a variety of dierent wireless and wire-lined network te hnologies
(bear-ers). Mobility within these bearers (lower-layerhand-os) is transparent to Mobile
IP andtherefore doesnotae t itinanyway. Meanwhile, anylo ation hangethat
is a ompanied by a hange in the IP administrative domain requires a Mobile IP
hand-o.
Figure 3.1 illustrates a mobile node with multiple a ess-devi es that enable it to
re eiveInternetservi esthrough IPnetworksthat arebasedonGPRS andWireless
LAN(WLAN)respe tively. Aslongasthemobilenoderoamswithintheboundaries
ofthe GPRSnetwork,mobilitymanagementisperformedbyGPRSand istherefore
transparent to Mobile IP. At some point the mobile node rea hes the boundaries
of the WLAN network whose properties are unknown. For example, it is unknown
whether thenewlydis overedIPnetworkprovidesMobileIP servi esandifsowhat
the identity of the lo al mobility agent is. When this and other information has
been determined, the mobile node is required to de ide whether to hange its IP
servi e point between the GPRS and WLAN networks. In that state, the mobile
node issaid tobe performing agent sele tion.
The agent sele tionalgorithm an takeinto onsiderationvariousparametersof the
neighbouringIP networkswhen determiningthe preferredmobilityagent. Su h
pa-rametersin ludethesignalquality, ost,bit-rate,providedQoS,distan etopeerand
ex lusive lo al servi es [54, 141℄. From this it is understoodthat through agent
se-le tionnewsmartservi es anbeprovidedoverMobileIP.Ultimately,the exibility
ofagentsele tionisdependentontheextenttowhi h ontrolisshiftedfromthe
un-derlying networkte hnologiesintothe networklayer ofthe mobilenode. Currently,
twodistin t s enarios are identi ed.
empowered with the nal de ision when it omes to hoosing between alternative
providers or network te hnologies. The availability of multiple a ess-devi es
re-quires a rede nition of network servi e disruption during Mobile IP hand-os and
di tates the development of new agent sele tionalgorithms.
The se onds enarioisalsothe typi alenvironmentwhere MobileIP isdeployed. It
onsists of single network te hnologies where roaming is managed through a single
a ess-devi e. Inthat ase, thede isionwhethertoswit hbetweentwoIPnetworks
ismetwithinthea ess-devi e(lower-layers)a ordingtointernalrules. Anexample
of this behaviour an be found in the IEEE 802.11WLAN standard, wherea
link-layer hand-o o urs without prior onsultation of the IP/Mobile IP layer. Given
that Mobile IP an not ae t this pro ess, the role of agent sele tion is redu ed
into keeping the Home Agent registrations (bindings) up-to-date with the mobility
de isionsoflower-layers. Asitwillbeshown,poorperforman einthistask anlead
to un-adaptability and prolonged Mobile IP hand-os.
Fortheperforman eevaluationspresentedinthis hapter,thetypi alMobileIP
s e-nario has been assumed, i.e. mobile nodes with asingle a ess-devi e. In that ase,
agent sele tion is onsidered along with Move Dete tion and lo al mobility agent
dis overyasthe purpose ofa singlefun tion termedMoveDete tion. The fa tthat
this fun tion has been named after one of its task pro esses, i.e. Move Dete tion,
indi atestheimportan eofthis pro ess. Thereasonforthis isthatMoveDete tion
an take onsigni ant time periodsto omplete. Thereare dierent approa hes to
the problemofMoveDete tionbasedondierentassumptionswithdierent
perfor-man e. Itwillbeshown that,asMoveDete tionapproa hesoptimumperforman es
the role of agent sele tionand of other Mobile IP me hanisms in reases.
Earlyapproa hesaddressingtheproblemofprolongedservi edisruptionexperien ed
duringMobileIP hand-os onsideredthepossibilityofinitiatingmultipleauxiliary
streams dire ted to all potential migration destinations of a mobile node even for
short time periods. It willbe shown that this approa h isine ient.
3.2 The Mobile IP Hand-o Life- y le
In single a ess-devi e s enarios, the life- y le of a Mobile IP hand-o onsists of
the following stagesthat o ur serially:
1. Lower-layer hand-o
2. MoveDete tion
3. Registration
For the durationof alife- y le, the mobilenode is suering networkservi e
disrup-tion. Assuming multiple a ess-devi es, the aforementioned stages may not o ur
in the given order and they might even overlap. For su h onditions a rede nition
of Mobile IP hand-o network servi e disruption is required.
