Flexible Network Support for Mobile Hosts XinhuaZhao a ClaudeCastelluccia b MaryBaker a a
ComputerScienceDepartment,Stanford University,Stanford,CA94305
b
INRIARhone-Alpes,38330 MontbonnotSaintMartin,France
Fueledbythelargenumberofpowerfullight-weightportablecomputers,theexpandingavailabilityofwireless
networks,andthepopularityoftheInternet,thereisanincreasingdemandtoconnectportablecomputerstothe
Internetatanytimeandinanyplace. However,thedynamicnatureofamobilehost'sconnectivityanditsuseof
multiplenetworkinterfacesrequiremoreexiblenetworksupportthanhastypicallybeenavailableforstationary
workstations.
Thispaperintroducestwoow-orientedmechanisms,inthecontextofMobileIP[23],toensureamobilehost's
robustandeÆcientcommunicationwithotherhostsinachangingenvironment. Onemechanismsupportsmultiple
packetdeliverymethods(suchasregularIPorMobileIP)andadaptivelyselectsthemostappropriateonetouse
accordingtothecharacteristicsofeachtraÆc ow. Theothermechanismenables amobilehost tomakeuseof
multiplenetworkinterfacessimultaneouslyandtocontroltheselectionofthemostdesirablenetworkinterfacesfor
bothoutgoingandincomingpacketsfordierenttraÆcows. Wedemonstratetheusefulnessofthesetwonetwork
layermechanismsanddescribetheirimplementationandperformance.
1. Introduction
Light-weightportablecomputers, thespreadof wirelessnetworks andservices, andthe popularityof
the Internetcombine to makemobile computingan attractivegoal. With these technologies, usersshould
beable to connect to the Internet at any time and in any place, to read email, querydatabases, retrieve
informationfrom theweb,orentertainthemselves.
Toachievetheabovegoal,amobile hostrequiresaunique unchangingaddress,despite thefact that
asitswitchesfromonecommunicationmediumtoanother,orfrom onenetworksegmenttoanother,theIP
addressassociatedwithitsnetworkinterfacemustchangeaccordingly. TheIPaddressmustchangebecause
IP[25]assumesthatahost'sIPaddressuniquelyidentiesthesegmentofthenetworkthroughwhichahost
is attachedto theInternet. Unfortunately, changingtheaddresswill break ongoingnetwork conversations
betweenamobilehostandother hosts,becauseconnection-orientedprotocolssuchasTCP[26] usetheIP
addresses of both ends of a connection to identify the connection. Therefore, Mobile IP [23], oranother
similar mechanismthat allowsahost tobeaddressedbya singleaddress,is neededto accommodate host
mobilitywithin theInternet.
However,due tothedynamicnatureofamobilehost'sconnectivityanditsuseofmultipleinterfaces,
providing network support for a mobile host can be a much more complex task than for its stationary
counterparts. Mobile IP takesan important step towards supporting mobility and is the context forour
work,butthroughday-to-dayexperienceusingtheMosquitoNet[16]mobilenetwork,wehavefoundthatit
isdesirabletohavenercontroloverthenetworktraÆcofamobilehostonaperowbasisthanisprovided
by Mobile IP. The work presentedin thispaperis mainly motivated by the following observations onthe
uniquecharacteristicsofamobilehost:
Duality: Themobilehosthastworolesasbothahostvirtuallyconnectedtoitshomenetworkandasa
Dynamicallychangingpointofattachment: Weconnectaportabletovariousnetworks,suchasouroÆce
network while at work,the network of awireless Internet access service provider whileon theroad, or
anothernetwork at homeor elsewhere. Dierent networks may havedierent policies for dealingwith
packets from mobile hosts. Depending on where a mobile host currently operates and with whom it
communicates,itmayneedto usedierentpacketdeliverymethodsthatareeither morerobustormore
eÆcient.
Multiple network interfaces: Toachieveconnectivity in anyplace at any time, mobile hosts will likely
require more than one type of network device. For example, our mobile hosts use Ethernet or
Wave-LAN[28]wheninasuitablyequippedoÆceorhome,buttheyuseaslowerwirelesspacketradionetwork
suchasMetricomRicochet[18]elsewhere.
There is no single network device that can provide the desired quality of service (QoS) all the time.
Thereisalwaysatrade-oamongcoverage,performance,andprice. Thereareeventimeswhenmultiple
network devices need to be used at the same time (such as a satellite connection for downlink and a
modem connectionforuplink). In thiscase, themobilehostis physically multi-homedaswell. Making
useofthese network interfacessimultaneouslyfordierentowsof traÆcisachallenge.
Our goal is to enable a mobile host to communicate both robustly and eÆciently with other hosts
asit moves from place to place. While there are waysto satisfy onegoalorthe other, satisfying both at
onceisachallenge. Forexample,wecantreatamobilehostasvirtuallyconnectedtoits homenetworkby
alwaystunnelingpacketsbetweenthemobilehostanditshomeagent. Althoughrobust,thisisobviouslynot
eÆcient. AchievingeÆciencyaswellrequires amobilehosttohavemoreexibilitythanhasbeenprovided
bypreviouslyexisting mechanisms.
This paper addressesthe followingtwoissues in providing the exibilitydesirable fora mobile host.
Firstistheneedatthenetworkroutinglayertosupportmultiplepacketdeliverymethods(suchaswhether
touseregularIPorMobileIP).Atthenetworklayer,wehavedevelopedageneral-purposemechanism,the
MobilePolicyTable,whichsupportsmultiplepacketdeliverymethodssimultaneouslyfordierentowsand
adaptivelyselectsthemostappropriatemethod accordingtothecharacteristicsofeachtraÆc ow. Second
istheneedto makeuseofmultiple networkinterfacessimultaneouslyandtocontrol theinterfaceselection
of both outgoing and incoming packets for dierent traÆc ows. This is achieved by extending the base
Mobile IPprotocol to controlthe choiceof interfacesto useforincomingtraÆc to amobilehost. Wealso
amend the routingtable lookupto enable the useof multiple network interfaces for outgoingtraÆc ows
fromamobilehost. TheresultisasystemthatappliesMobileIPmoreexiblybytakingintoconsideration
traÆccharacteristicsonaow-by-owbasis.
Therestofthepaperisorganizedasfollows: Insection2,wegiveabriefdescriptionofMobileIP,the
contextinwhichourworkisdone. Insection3,weillustratescenariosfortheuseofmultiplepacketdelivery
methods fordierentows oftraÆc. Insection4,wedetailthegeneral-purpose mechanismthat supports
this use of multiple packet deliverymethods. In section 5, we describe the simultaneous use of multiple
networkinterfaces. Insection6,wereporttheimplementation statusofthesystemand presenttheresults
ofsystemperformancemeasurementsobtainedfrom ourexperiments. Insection7,welistrelatedwork. In
section8,weconsidertheapplicabilityandpotentialofourworkwithIPv6. Finally,wepresentconclusions
togetherwithsomefutureandcontinuingworkinsection9.
2. Background: Mobile IP
MobileIP[23]isamechanismformaintainingtransparentnetworkconnectivitytomobilehosts. Mobile
IPallowsamobile hostto be addressedby theIPaddressitusesin its homenetwork (homeIPaddress),
Host
Host
Correspondent
Mobile
Foreign Network
Agent
Home
Home Network
Internet
Figure1. BasicMobileIPProtocol. Packetsfromthecorrespondenthosttothemobilehostarealwayssenttothemobilehost's
homenetworkrst,andthenforwarded(tunneled)bythehomeagenttothemobilehost'scurrentpointofattachment(care-of
address).Packetsoriginatingfromthemobilehostaresentdirectlytothecorrespondenthost,thusformingatriangularroute.
Thethicklineindicatesthat the originalpacket isencapsulatedinanotherIPpacket whenforwarded,and isthereforeof a
largersize.
TheMobile IPspecicationallowsfor twotypesof attachmentfor amobilehostvisiting a\foreign"
network(anetworkotherthanthemobilehost'shomenetwork). Forthersttypeofattachment,themobile
hostcanconnectto theforeignnetworkthrougha\foreignagent",anagentpresentintheforeignnetwork,
byregisteringtheforeignagent'sIPaddresswithitshomeagent. Thehomeagentthentunnels[22]packets
totheforeignagent,whichdecapsulatesthemandsendsthemtothemobilehostvialink-levelmechanisms.
AlthoughourMobile IPimplementationsupportstheuseofforeignagents,ourworkismorefocused
onthe second typeof attachment,which providesamobile hostwith itsown \co-located"care-of address
in the foreignnetwork. In this scenario, the mobile host receivesan IPaddress to use while it visitsthe
network,viaDHCP[6]orsomeotherprotocolorpolicy. Itregistersthisaddresswithitshomeagent,which
thentunnelspacketsdirectlytothemobilehostatthisaddress. Thedisadvantageofthisscenarioisthatthe
mobilehosthastodecapsulatepacketsitself andmoreIPaddressesareneededin theforeignnetwork,one
foreachvisitingmobilehost. Theadvantageisthatthemobilehostalsobecomesmoredirectlyresponsible
fortheaddressingandroutingdecisionsforthepacketsitsendsout,anditthereforehasmorecontrolover
suchoperations.
While Mobile IP has laid the groundwork for Internet mobility, there are still many challenges to
tackle, as seen from on-going eorts in this area. These eorts include route optimization [13], rewall
traversal[20],and\bi-directionaltunneling"(or\reverse-tunneling")[19]toallowpacketstocross
security-conscious boundary routers. This last problem, asdescribed in section 3.2, is one of our motivations for
makingit possiblefor mobilehosts to choosedynamically betweendierentpacket addressingand routing
options. We believe that these eorts make evident the inherent need for mobile hosts to use dierent
techniquesunder dierentcircumstances.
3. Supporting MultiplePacketDeliveryMethods
Supportingmultiplepacketdeliverymethodsistherstareainwhichwehaveincreasedtheexibility
of mobile hosts. Byavoiding asingle method of delivery, the mobile host only pays for the extracost of
mobilitysupportor securityperimetertraversalwhenitistrulyneeded.
Weillustratesomeofthesituationsforwhichwehavefoundsuchexibilitytobebenecialinpractice.
Although Figure 2only showsthe exampleswehaveimplementedso far, themechanism we propose here
Web traffic,
Local services,
Transparent
Mobility?
Tunneling?
Reverse
Bi-directional
Tunneling
Triangular Routing
Classical
Default of
basic Mobile IP
Mobile IP
routers
ingree-filtering
needs to traverse
Traffic that
etc.
outside a mobile host
Traffic initiated
IP telephony,
Telnet,
etc.
Regular IP
No
Yes
No
Yes
Figure2. SimultaneousUseofMultiplePacketDeliveryMethods. Thisguresummarizesthedierentpacketdeliverychoices
(inrectangleboxes)wehaveimplementedsofar. Listedinthe circlesareexampleusesforeachpacket deliverychoice. The
policydecisionstobemadeareindiamonds.
3.1. Providing Transparent MobilitySupportOnlyWhen Necessary
Thetransparentmobility support ofMobile IPis importantforlong-livedconnection-orientedtraÆc
orfor incoming traÆc initiatedby correspondent hosts. However, this transparentmobility support does
notcomewithoutcost. IntheabsenceofrouteoptimizationforMobileIP,packetsdestinedtoamobilehost
are deliveredto its home network and then forwarded to the mobile host's current care-ofaddress in the
networkitisvisiting. Ifamobilehostisfarawayfrom homebutrelativelyclosetoitscorrespondenthost,
thepathtraversedbythesepacketsissignicantlylongerthanthepathtraveledifthemobilehostandthe
correspondent hosttalk to each other directly. Theextra path lengthnot only increaseslatency but also
generatesextraloadontheInternet. It evenincreasesloadonthehomeagent,potentiallycontributingto
acommunicationbottleneckifthehomeagentisservingmanymobilehostssimultaneously.
ItwouldbeidealtouseMobileIProuteoptimization[13]. However,sinceMobileIProuteoptimization
requiresextrasupportoncorrespondenthostsinadditiontosupportonthemobilehostanditshomeagent,
itrequireswidespreadchangesthroughouttheInternet,whichisunrealisticforthenearfuture.
Fortunately,therearecertaintypesoftraÆcforwhichamobilehostmaynotrequireMobileIPsupport.
Examples are most web browsing traÆc and communication with local services discoveredby the mobile
host. Web connections are usually short-lived, so it is unlikely that a mobile host will change its foreign
networkaddressinthemidstofaconnection(exceptionsarewebpushtechnologyandHTTP1.1[8],which
canpotentiallyusepersistenttransportconnections). Evenifitdoes,theusercansimplypressreload,and
the web transferwill be retried. With such traÆc, we can avoid the extra cost associated with mobility
support.
3.2. SupportingBi-directional TunnelsandTriangle Routes
When communication requires transparent mobility, there still remains a choice of packet delivery
methods. An importantexampleiscommunicationthat musttraversesecurity-consciousboundaryrouters.
AsaresultofIPaddressspoongattacksandinaccordancewithaCERTadvisory[4],moreroutersare
lteringonthesourceaddress(ingressltering)[7]andwilldropapacketwhoseaddressisnot\topologically
correct"(whoseoriginatingnetworkcannotbetheoneidentiedbythesourceaddress). Inthepresenceof
Correspondent
Host
Home
Agent
Mobile
Host
Figure3. TheProblemwithSourceIPAddressFilteringataSecurity-consciousBoundaryRouter.Whenthemobilehostsends
packetsdirectlytothecorrespondenthostinitshomedomainwiththesourceIPaddressofthepacketssettothemobilehost's
homeIPaddress,thesepacketswillbedroppedbytheboundaryrouter,becausetheyarrivefromoutsideoftheinstitutionand
yetclaimtooriginatefromwithin.
Host
Mobile
Agent
Home
Correspondent
Host
Figure4. SolutiontotheIngressFilteringProblem.ToaddresstheproblemcausedbysourceIPaddresslteringon
security-consciousboundaryrouters,themobilehostsendspacketsbytunnelingalongthereversepathaswell. Sincetheencapsulated
packetsinthetunnelfromthemobilehosttoitshomeagentusethemobilehost'scare-ofaddressastheirsourceIPaddress
(whichistopologicallycorrect),thesepacketswillnolongerbedroppedbythesecurity-consciousboundaryrouters.
As anotherexample,iftheboundaryrouterisin thedomain visitedbythemobile host,itmaydrop
packets thatare receivedfrom inside but claimto originatefrom outside;these packetslook asiftheyare
\transittraÆc",andnotallnetworkswillcarrytransittraÆc.
Toaddresstheaboveproblems,wecantunnelpacketssentbythemobilehostthroughitshomeagent
to itscorrespondenthosts,in much thesamewaywetunnelpacketssenttothemobilehost. This iscalled
\bi-directionaltunneling"[19]. Figure4illustrates thesolution.
This bi-directional tunneling addresses the problem related with ingress ltering routers, but again,
this comeswithincreasedcost. If amobile hostvisitsanetworkfarawayfromhomeand triesto talkto a
correspondenthostinanearbynetwork,packetsoriginatingfromthemobilehostwillnowhavetotravelall
thewayhomeandthenbacktothecorrespondenthost,increasingthelengthofthis reversepath.
However,notallthepacketsneedtobesentthisway. ItisunnecessarytoforcealltraÆcthrougha
bi-directionaltunneljust becausesomeingresslteringrouterswoulddroptraÆcsenttospecicdestinations.
SuchtunnelingmaybeunnecessaryforalargepartofthetraÆcforwhichthetopologicallyincorrectsource
IPaddressinpacketheadersisnotaproblem. Therefore,itisimportanttosupporttheuseofbothtriangle
routingand bi-directionaltunneling simultaneously, so that only those traÆc ows that truly needto use
bi-directionaltunneling payforthisextracost.
3.3. Joining MulticastGroups inDierent Ways
using its co-located care-of addressin the foreignnetwork. This exibility is necessary because multicast
traÆc is oftenlimitedto aparticular siteby scoping [5]. Also, there are advantages anddisadvantages to
either choice[1]evenifscoping isnotanissue.
Joininglocally: Inthisrespectthemobilehostisnodierentfromanynormalhostonthesamesubnet.
TheadvantageisthatthedeliveryofmulticasttraÆctothemobilehostismoreeÆcient. The
disadvan-tages are that it requires the existence of amulticast-capable router in the foreign network, and those
mobilehostsactivelyparticipatinginthemulticastsessionwill havetore-identifythemselveswithinthe
groupwhentheymovetoanothernetwork.
Joiningthroughthehomenetwork: All multicast traÆchastobetunneled bi-directionallybetweenthe
mobile host and its home agent. The advantages of this choice are that it does not require multicast
supportontheforeignnetwork,andthemobilehostwillretainitsmembershipasitmovesaround. The
disadvantageisthattherouteislesseÆcient. Althoughthereareoptimizationsthatallowasinglecopy
of multiple packets to betunneled to aforeignagentserving multiple mobile hosts [9], thehome agent
still must tunnel acopy of amulticast packet to each foreignnetwork that has oneof its mobile hosts
visiting.
We can choose either option for dierent multicast groups. To join a multicast group locally, we
add an entryin the Mobile Policy Table instructing traÆc destined to certain multicast addresses to use
conventionalIPsupport. Tojoin amulticast groupremotely, weadd anentryin theMobile Policy Table
to usebi-directionaltunneling fortraÆcdestined tothese multicastgroups. Themobilehostalsoneedsto
notifyitshomeagent,in aregistrationpacket,toforwardmulticast traÆctoit.
4. A General-purpose Mechanismfor FlexibleRouting
In this section, we describe the mechanism used to achieve the exibility features described in the
previous section. This general-purpose mechanism is centered around the idea of introducing a Mobile
Policy Tablein theroutinglayerof thenetwork softwarestack. TheIProute lookuproutineip rtroute
is augmentedto taketheMobile PolicyTableinto considerationtogether withthenormalroutingtable in
determininghowapacket shouldbesent.
4.1. Supportinthe NetworkLayer
We choose to add our support for multiple packet deliverymethods to the network layerdue to its
uniqueposition inthenetworksoftwarestack. Bymodifyingthelayerthroughwhichpacketsconvergeand
then diverge, we avoida proliferation of modications. Relatively fewer changes need to be made in the
kernelnetworksoftware,andboththeupperlayerprotocolmodules(suchasTCPorUDP)andlowerlayer
driversfordierentnetworkdevicesremainunchanged.
Wefurtheridentifytheroutelookuproutineasanaturalplacetoaddsuchsupport. Alongwithnormal
routeselection,theenhancedroutelookupalsomakesdecisionsforchoosingamongmultiplewaystodeliver
packets,asnecessitated bythechangingenvironmentofamobilehost.
4.2. The MobilePolicy Table
The Mobile Policy Table species how the packets should be sent and received for each traÆc ow
matching certain characteristics. The routingand addressingpolicy decisions currently supported in the
Mobile Policy Tableare:
Destination Netmask PortNum Mobility Tunneling
171.64.0.0 255.255.0.0 0 Yes Yes
0.0.0.0 0.0.0.0 80 No N/A
0.0.0.0 0.0.0.0 0 Yes No
Table1
ASampleMobilePolicyTable. Thismobilepolicytablespeciesthatall traÆcdestinedbackto the
mobilehost'shomedomainshouldusebi-directional tunneling,tosatisfy theboundaryroutersat its
homeinstitution(rstrow);alltraÆctoport80(webtraÆc)shouldavoidusingtransparentmobility
support(secondrow);andtheremainingtraÆcshouldbydefaultuseMobileIPwitharegulartriangular
route(thirdrow).ThesecondentryappliestoalltraÆcwithadestinationportnumberof80,evenfor
destinationsmatchingtherstentry,sinceportnumberspecicationtakesprecedence.
These policies are speciedthrough twotypes of entries: \per-socket"entries and \generic" entries,
with per-socket entries taking precedence. While theMobile Policy Table onlycontains generic entries, a
per-socket entrykeptwithin thesocket datastructure allowsanyapplication to overridethegeneralrules.
Without a per-socketentry, traÆc issubjectonly to genericentries in the policy table,which specifythe
deliverypolicyforalltraÆcmatchingthegivencharacteristics.
Forgeneric entries, the Mobile Policy Table lookup currently determines which policy entry to use
basedontwotraÆccharacteristics: thecorrespondentaddressandportnumber(forTCPandUDP). The
correspondent addressis useful, because we often want to treat ows to dierent destinations dierently.
Theportnumberisusefulaswell,becausetherearemanyreservedportnumbersthatindicatethenatureof
thetraÆc, suchasTCPport23fortelnet, orport80forHTTPtraÆc. Whilethesearethecharacteristics
currentlytakenintoconsideration,wecanextendthetechniquetoincludeothercharacteristicsinthefuture.
Table1shows,asanexample,theMobilePolicyTablecurrentlyusedonourmobilehostswhenvisiting
places outsideof their home domain. The Mobile Policy Table lookupoperationalways chooses the most
specically matched entries (those with more restricted netmaskand/or port number specications) over
moregeneralones.
4.3. HowitWorks
Figure5illustratestheuseoftheMobile PolicyTableandroutingtablewithintheLinuxkernel. The
modicationto thekernelismainly limitedto theroute lookupfunction. Forbackwardcompatibility,the
normalroutingtable remainsintact. Duringaroutelookup, extraargumentssuchasothercharacteristics
ofthetraÆcow(currentlyonlytheTCPorUDPportnumber)andthesourceIPaddresschosenareused
in additiontothecorrespondenthost'saddressfordecidinghowthepacketshould besent.
ThenewroutelookupfunctionusesthespeciedsourceIPaddresstodetermineifthepacketissubject
topolicydecisionsintheMobilePolicyTable. IfthesourceIPaddresshasalreadybeensettotheIPaddress
associated with one of the physical network interfaces, this indicates that no mobility decision should be
made for the packet. Packets mayhave their sourceaddress set either after they arelooped back bythe
virtual interface (described below), since a mobility decision has already been made by that time, orby
certain applications. An example of such an application is the mobile host daemon handlingregistration
and deregistration with the home agent; this daemon needs to force a packet through a particular real
interfaceusingregularIP.IncaseswherethesourceIPaddressisalreadyset, onlythenormalroutingtable
isconsultedbaseduponthedestinationaddress,andtheresultingrouteentryisreturned. Fortherestofthe
packets,theMobilePolicyTableneedstobeconsultedto chooseamongmultiple packetdeliverymethods.
Thevirtual interface(\vif") handles packetsthat need to be encapsulatedand tunneled. It provides
theillusionthat themobilehostisstillin itshomenetwork. Packetssentthroughvifareencapsulatedand
MPT
MPT
Table
Routing
TCP
radio
ether
IPIP
UDP
Network Layer (IP)
IP Route Lookup
loopback
vif
Figure5. Thisgure shows where the MobilePolicyTable (MPT) ts into the link, network,and transport layersof our
protocolstack. TheMPTresidesinthemiddle(network)layer,consultedbytheIProutelookupfunctioninconjunctionwith
thenormalroutingtabletodeterminehowpacketsshouldbesent. Thebottom(link)layershowsthedeviceinterfaces,withvif
beingavirtualinterfacethathandlesencapsulationandtunnelingofpackets. Thetop(transport)layershowsTCPandUDP,
alongwithanIP-within-IPprocessingmodule. Thearrowsdepictthe passingofdata packetsdown thelayers. Theshaded
boxesindicatethattheIPIPand vifmoduleshaveoverlapping functionalities. Theboldbi-directionalarcshows theneedto
passpacketsbetweenthetwomodules.
so it will nowbe sent through oneof the physical interfaces. Accordingly, packets beingtunneled to the
mobilehostbyitshomeagentarealsoloopedbytheIPIPmoduletovif,sothattheyappeartohavearrived
atthemobilehostasifitwereconnectedtoitshomenetwork.
Tomaintain reasonableprocessing overhead, policy table entries are cached in a manner similar to
routingtableentries. IfthecharacteristicsofthetraÆcmatch acachedentry, thesoftwareusesthecached
entryto speedupthe process of policy lookup. Otherwise, a newpolicy table lookup will be carriedout.
Wheneverthemobilepolicytable ismodied,thecachedentriesareushed.
Webelievethisisageneral-purposemechanism,becauseitcanbeeasilyextendedtotakeothertraÆc
characteristicsinto consideration and to add more policy decisions if it becomes desirable to do so. For
instance, if particular correspondent hosts have the ability to decapsulate packets themselves, we could
note this information in the Mobile Policy Table for those destinations, and the mobile host could send
encapsulatedpacketsdirectlyto thesehosts,bypassingthehomeagentyetstillprovidingtherobustnessof
abi-directionaltunnel.
4.4. Dynamic Adaptationof the MobilePolicy Table
The entries in the Mobile Policy Table canbe changed at runtime to specify a dierent policy. We
currentlyhavethefollowingtwomechanismsto adjustentriesintheMobilePolicyTabledynamically.
First,wecan swapin anewsetofentriesfortheMobilePolicyTablewheneveramobilehostchanges
its care-of address. When amobile host changes its point of attachmentto theInternet, the best way to
communicate with otherhosts often changes accordingly. Forexample,when our mobilehosts movefrom
withintheStanforddomaintoaforeignnetworkoutside,theyneedtoswitchtousingreversetunnelingfor
traÆcbacktotheirhomedomaindue totheingresslteringrouterspresentattheboundaryofStanford's
domain. Forforeignnetworksfrequentlyvisitedbyamobilehost,weusepredenedcongurationlesthat
contain theset ofentries to usein theMobile Policy Tableso that asuitableset ofpolicies canbe put in
place quicklywhenamobilehostchangeslocation. Forpreviouslyunknownforeignnetworks,adefault set
ofpolicieswillbeused.
Inaddition,wemakeitpossibletochangespecicentriesintheMobilePolicyTabledynamically. For
acurrentsettingintheMobile PolicyTablefails orwhenitissimplyimpossibletospecifytherightpolicy
beforehand. Theadaptationappliesonlytocachedentries,i.e.weonlyadjustthoseentriesthatareactually
in use.
Toimplementthis mechanism,weautomatically dispatch aseparate process that probeseach
desti-nationaddress bysending ICMP echorequests using triangularrouting, with theinterval betweenprobes
being increased exponentiallyup to aprecongured maximum value. For a ow using reverse tunneling,
if areply to any of theprobesis successfully received, the Mobile Policy Tableentryfor this ow will be
changedfrombi-directionaltunnelingtousethemoreeÆcienttriangularrouting. Foraowusingtriangular
routing,theMobilePolicyTableentryischangedbacktousebi-directionaltunnelingifacertainnumberof
probes(currently, ve) havefailed in arow. After theinitial stage,this separateprocess keepsprobing in
thebackgroundwiththemaximumprobeinterval. Ifaseriesofprobesfailswhileaowisusingtriangular
routing, we switch to use bi-directionaltunneling. If a probe succeedswhile a ow is using bi-directional
tunneling,theMobilePolicyTableentrywillbechangedtousetriangularroutingimmediately. Inallother
cases,noactionisnecessary. Thisway, aowis ableto selectadaptivelythemosteÆcientpacketdelivery
method.
5. Supporting the Useof MultipleNetwork Interfaces Simultaneously
Theuseofmultiplenetworkinterfacesisdierentonmobilehoststhanontypicalstationarymachines.
Stationary hosts with multiple network interfaces are usually routers, forwarding packets with dierent
destinationaddressesthroughdierentnetworkinterfaces. Onamobilehost,these network devicesinstead
representdierent waysthis singlemobilehostcancommunicate withtheoutsideworld. Forexample,we
maywanttousetwodierentinterfaces(onefortelnetandanotherforledownloading)forcommunication
withthesamehost.
Although some operating systems candirect broadcastor multicast traÆc out througha particular
network interface to its immediately connected subnets, all these operating systems (except for Linux)
makeroutingdecisionsbydestinationaddressesalone, withouttakingothertraÆcowcharacteristicsinto
consideration. ThestandardLinuxdistributionincludesourcontributionthatenableseachsockettochoose
among dierent simultaneously active network interfaces for outgoing traÆc to destinations beyond the
directly connected subnets. Our goal is to enable a mobile host to make use of multiple active network
interfacessimultaneouslyfordierentowsoftraÆcin amoregeneralway.
5.1. Motivation for MultipleInterfaces
Wendthesupportfortheuseofmultiple activeinterfacesusefulforthefollowingreasons:
1. Smoother hand-os: With theabilityto usemultiple network interfacessimultaneously, amobile host
canprobetheusabilityofotherinterfacesbeyonditsdirectly connectedsubnet withoutdisturbingthe
interfacecurrentlyinuse. Thecurrentnetworkinterfacecanremaininuseuntilthenewcare-ofaddress
onthe new network can be successfully registeredwith the home agent. This eliminatesunnecessary
packet losswhenswitchingcare-ofaddresses.
2. Qualityofservice(QoS):Thedierentphysicalnetworksto whichauserhasaccessmayoerdierent
QoSguarantees. For example,amobileusermayhavesimultaneous accesstoaGSMdatanetwork[27]
that has low bandwidth but relatively low latency, as well as to a Metricom Ricochet network that
oershigherbandwidthbut hashigherandmorevariablelatency. Themobilehostmightdecidetouse
theGSM network forits low-bandwidth interactiveows(such as itstelnet traÆc)which requirelow
latencyforusersatisfaction,whileusing theMetricomnetworkforitsbulkdatatransferows(such as
3. Link asymmetry: Some networks only provide unidirectional connectivity. This is the case for many
satellite systems,which usually provide downlinks only. In these systems,connectivity in the reverse
direction is provided via adierent means, such as aSLIP orPPP dialup line, a cellular modem, or
aCDPD[2] device. Being ableto specify the incomingand outgoinginterfacesexplicitly in anatural
mannerisausefulfeature.
4. Costandbilling: Thecostofaccessingdierentnetworksmaybeadecisivefactorininterfaceselection.
Usersmightselectdierentinterfacesaccordingtotheidentityofthebillpayer.Forexample,theymight
choose acheaperand lowerqualityaccess network for personal communicationsand amoreexpensive
andbetterqualityoneforbusinesscommunications.
5. Privacyandsecurity: Privacyandsecuritymayalsobeofconsiderableimportanceininterfaceselection.
Usersmaytrustsomenetworksmorethanothersandpreferto usethemforcondentialandimportant
communications. Theymight also want, for privacy reasons, to choose dierentnetworks for business
andpersonalcommunications.
Thefollowingsectionsexplainhowtosupportthisfeature forpackettransmissionandreception.
5.2. SupportingMultiple Interfaces inTransmission
Foramobilehostto usemultiple networkinterfacessimultaneouslytosend packets,wehavedevised
thefollowingtwotechniques. Therstistomakeuseofthemetriceldin theexistingroutingtableentry
sothatmultipleroutesthroughdierentinterfacescanbeassociatedwithacertaindestinationspecication.
Usuallythenormaldefaultroutehasametricof one. Routesthroughotherinterfaceswithmetricsgreater
thanonecancoexistwiththenormaldefaultrouteintheroutingtable.Aroutelookupthatdoesnotspecify
aparticularinterfacewillthusndthenormaldefaultroute,maintainingbackwardscompatibility,sincethe
lookupalwayschoosesthematchingroutewiththesmallestmetric.
The second technique we provide is a \bind-to-device" socket option that applications can call to
associateaspecicdevicewithacertainsocket. Theroutelookuproutinehasbeenmodiedsothatwhena
deviceselectionisspecied,onlythoserouteentriesassociatedwiththeparticulardevicewillbeconsidered.
Therefore,dierentapplicationsrunningsimultaneouslycaneachchoosedierentnetworkinterfacestouse
forsendingpackets.
5.3. SupportingMultiple Interfaces inReception
5.3.1. Overviewof the scheme
A mobile hostwith multiple interfaces running standardMobile IPcannot receive dierent owsof
packets ondierentinterfacessimultaneously. With Mobile IP, amobile host sendslocation updates that
indicateitscurrenthhomeaddress,care-ofaddressibindingtoitshomeagentandpossiblytoits
correspon-denthosts. As aresult,allpacketsaddressedto amobile hostaresentoverthesameinterfaceorpossibly
overmultipleinterfacesallat thesametimeifthe\S" (simultaneous binding)agissetintheregistration.
WehaveextendedMobileIPtoallowamobilehosttousedierentinterfacestoreceivedierentows.
Inourwork,wedeneaowasatriplet: hthe mobilehost's home IPaddress,the correspondent host'sIP
address,the portnumberonthecorrespondenthosti. Ourdenitionisdierentfromtypicalowdenitions
in that wedonot include certainelds such astheport numberonthe mobile host. This actuallymakes
certain ows from the same mobile host indistinguishable from each other. However, since our current
goal is to treat traÆc ows dierently based on whom a mobile host is talking to and the nature of the
communication(forexample,whetheritisinteractivetraÆcorbulktransfer),webelievethatthistripletis
suÆcientincapturing theessentialtraÆcowcharacteristicstoservethispurpose.
Correspondent
Host
Care-of
Address2
Mobile
Host
Care-of
Address1
GSM
Ricochet
Flow2
Agent
Home
Flow1
Internet
Figure6. SupportingMultipleIncomingInterfaces.Packetsbelongingtoanyowsaddressedtothemobilehostarriveonthe
homenetworkviastandardIProuting. Thehomeagentinterceptspackets andtunnelsthemto thecare-ofaddressselected
based on the packets' destination addresses, sourceaddresses and sourceports. Packets of ow1 are tunneled to Care-of
Address1,whilepacketsofow2aretunneledtoCare-ofAddress2.
species themobilehost'scare-ofaddressthat thehome agentshould useto forwardpackets belonging to
theow.
UponreceptionofaFlow-to-Interfacebinding,ahomeagentupdatesitsextended bindinglist,which
containsentriesthatassociateaparticularowspecicationwithamobilehost'scare-ofaddress. Thereafter,
when thehomeagentreceivesapacketaddressedto amobilehostitis serving,itsearchesin its extended
binding list for an entry matching the corresponding elds of the packet and forwards the packet to the
associatedcare-ofaddress. Ifnoentryisfound, thepacketisforwardedto themobile host'sdefaultcare-of
address.
Figure 6illustrates theroutingofdatagramsto amobilehostawayfromhome, oncethemobile host
has registered several Flow-to-Interface bindings with its home agent. It is worth noting that since the
port numberonacorrespondenthost isafactor in distinguishingbetweendierentows,thehome agent
musttreatalreadyfragmentedpacketstomobilehostsspecially. Currently,wereassemblethesefragmented
packetsatthehomeagentbeforeforwardingthemtomobilehosts. Sinceallpacketspassthroughthehome
agent,wedonotsuerfromtheproblemnormallyassociatedwithdoingreassemblyatintermediaterouters
(whereinthe routersare notguaranteed to seeall thefragments). As wedescribe in Section 8,the useof
IPv6owlabelwilleliminatetheneedforde-fragmentation.
TheFlow-to-InterfacebindingsareregisteredtothehomeagentviatwonewextensionsoftheMobile
IP registration messages. The following sections review briey the Mobile IP registration procedure and
detailthenewextensionswehavedevised.
5.3.2. The MobileIPRegistrationProcedure
A mobile host and its home agent exchange Mobile IP registration request and reply messages in
UDP packets. The format of the registration request packet is shown in Figure 7. The xed portion of
the registration request is followedby extensions, a generalmechanismto allow optional information and
protocol extensibility. We use this general mechanismto extendthe Mobile IPprotocol so that dierent
owsto amobilehostcanbeassociatedwithdierentnetworkinterfacesonthathost.
5.3.3. The Flow-to-InterfaceBindingExtension
AmobilehostmayaskahomeagenttoregisteranumberofFlow-to-Interfacebindingsbyappending
to aregistrationrequestalistof Flow-to-Interfaceextensions, each deningaFlow-to-Interfacebindingto
1
3
4
0
2
SBDMGVTR
Type
Lifetime
Home Agent
Home Address
Care-of Address
Identification
Extensions ...
Figure7. MobileIP RegistrationRequest. Aregistrationrequest isusedbya mobilehostto create,on its homeagent, a
mobilitybindingfromthestaticIPaddressatitshomenetwork(i.e.itshomeaddress)toitscurrentcare-ofaddress.Ageneral
extensionmechanismisdenedforextendingtheprotocol.
Type
Length
1
3
4
0
2
CH Port
CH Address
Flow Care-of Address
Figure8.Flow-to-InterfaceBindingExtension. TheCH(correspondenthost)AddressandtheCHPorteldsinthisextension
togetherwiththemobilehost'shomeaddressdenetheowthatshouldnowbeassociatedwiththecare-ofaddressspecied
intheFlowCare-ofAddresseld.
Type
Length
Reserved
1
3
4
New Care-of Address
Old Care-of Address
0
2
Figure9. Flow-to-InterfaceBindingUpdateExtension. Allowspreviouslyboundtotheoldcare-ofaddressshouldnowbe
redirectedtothenewcare-ofaddress.
5.3.4. The Flow-to-InterfaceBindingUpdate Extension
A mobile host may ask ahome agentto redirectcertain existing owbindings to a dierentcare-of
addressby usingthe Flow-to-Interfacebinding update extension. Thebinding update extension formatis
detailed inFigure9. Thisextensionisusefulwhenamobilehostchangesthepointofattachmentofoneof
itsinterfacesandobtainsanewcare-ofaddressforthisinterface.
5.3.5. Some Compatibility Issues
Wewantto ensurethat unmodiedmobile hosts areableto useour enhancedhomeagent,and that
ourenhancedmobile hostsworkproperlywithunmodiedhomeagents. Therst scenarioisnotanissue,
sincetheenhancedhomeagentcanprocessbothregularregistrationmessagesaswellasthosewithournew
extensions. However,thesecondscenariorequiresfurtherconsideration.
AccordingtotheMobileIPspecication[23],whenanextensionnumberedwithin therange0through
127 is encountered but not recognized,the message containingthat extension must be silentlydiscarded.
When an extension numberedin therange 128 through255 is encountered but notrecognized, only that
particularextension isignored,buttherest oftheextensionsand themessagemust stillbeprocessed. We
When a mobile host sends a Flow-to-Interface binding registration to a home agent that does not
support Flow-to-Interfacebindings, thepackets will still be processed. This is safe, since theregistration
message is anormal registration message excluding the Flow-to-Interface binding extension. However, to
distinguish theseunsuspectinghome agents from theenhancedhomeagents, wemaketheenhancedhome
agentsusedierentreturncodesin reply toregistration requestswith Flow-to-Interfaceextensions. Ifthe
registrationisaccepted,thehomeagentreturnsthecode2insteadof0. Thereturncode3(insteadof1)will
beusediftheregistrationisacceptedandsimultaneous mobilitybindingisgranted. Therefore,ifamobile
hostsendsoutregistrationrequestswithFlow-to-Interfacebindingextensionsbut getsareturncode0or1
in reply,itshould stopsending Flow-to-Interfacebindingextensionsto itshome agent,sincecontinuing to
sendthemwill justwastebandwidth.
6. ImplementationStatusand Experiments
6.1. ImplementationStatus
Wehaveimplementedthesupportformultiplepacketdeliverymethodsandsimultaneoususeofmultiple
networkinterfacesontopofourMobileIPimplementation[3]underLinux(currentlykernelversion2.0.36).
SomecorefunctionsofourMobileIPimplementationresidewithinthekernel,suchaspacketencapsulation
andforwarding. Otherfunctions,suchassendingandreceivingregistrationmessages,areimplementedin a
user-leveldaemon.
AmobilehostcanchoosetheuseofeitherMobile IPorregularIPandtheuseofeitherbi-directional
tunneling ortriangularroutingfor dierentowsoftraÆc allat thesametime. Wealso provide
mobility-awareapplications withtheexibility tochooseincoming andoutgoinginterfaces. Weusetwonewsocket
optionstobindowstogiveninterfaces:
SOBINDTODEVICE: 1
This optionis usedbyanapplicationto bindtheoutgoingowsofasocket to
aninterface.
SOBINDFLOWTODEVICE: This option is used by an application to bind the incoming ows of a
socket toagiveninterface.
6.2. Experiments withMultiple PacketDeliveryMethods
6.2.1. Benets
The choice of deliverymethod has aperformance impact ontraÆc ows. We look at a mobile host
in oneparticularreal scenariotoillustrate thepotentialbenets certainowswill beableto receivewhen
theycanusethemoreeÆcientdeliverymethodsmadepossiblebyourexiblemechanism. Note thatother
scenarioscouldsee verydierentresultsdepending ontheactualnetworklatencybetweenthemobile host,
thehomeagentandthecorrespondenthost.
We evaluatethe latency improvementresulting from using the most direct route possible under the
circumstances. Fortheseexperiments, themobilehostconnectsto aforeignnetworkin oneofourcampus
residences,whichisalsoonEthernet,andregistersitscurrentcare-ofaddresswithitshomeagent. Thesetup
of the test scenario is illustrated in Figure 10. Themobile hostsends ping (ICMP echorequest) packets
to thedefault gateway(actingas itscorrespondenthost) ofitslocalsubnetand wemeasuretheround-trip
latency using the following three delivery methods, switching between them by manipulating the Mobile
PolicyTable:
RegularIP(notransparentmobilitysupport);
1
Home
Gateway
Home
Core
Gateway
Residence
Gateway
Residence
Network
Mobile
Host
Department
Network
Network
Home
Agent
Department
Gateway
Figure10. SetupoftheTestEnvironmentforExperimentsonMultiplePacket DeliveryMethods. Themobilehostvisitsthe
campusresidencenetworkasaforeignnetwork.ThemobilehostisaThinkpad560,andthehomeagentisa90MHzPentium.
TheyarebothrunningLinux.
DeliveryMethod Min(ms) Max(ms) Avg(ms) StandardDeviation
Bi-directionalTunneling 7.3 9.3 7.9 0.36
TriangularRoute 4.5 6.2 5.0 0.35
RegularIP 2.0 4.0 2.4 0.35
Table2
LatencyComparisonWhenUsingSmallPackets. Using64bytesofICMPdata (i.e.,the defaultping
packetsize),thetestforeachdeliverymethodisrepeated100timeswithanintervalof2seconds.
DeliveryMethod Min(ms) Max(ms) Avg(ms) StandardDeviation
Bi-directionalTunneling 37.4 42.4 38.4 1.2
TriangularRoute 24.6 30.9 25.4 1.0
RegularIP 11.5 14.5 12.4 0.6
Table3
Latency ComparisonWhenUsingLarge Packets. Using1440 bytes ofICMP data, the test for each
deliverymethodisrepeated100timeswithanintervalof2seconds.
Triangulardelivery(the defaultbehaviorinMobile IP);
Bi-directionaltunneling (forsecurity-consciousboundaryrouters).
We collect the data by repeating the above test 100times with an interval of two seconds for each
deliverymethod. TheresultsareshowninTable2forsmallpacketsandTable3forlargepackets. Forthis
experimentalsetup,ourexiblemechanismreduces thelatencybyonehalfforbothsmallandlargepackets
when choosing regularIP overthe default Mobile IP behavior. Even when mobility support is necessary,
thisexiblemechanismstillreducesthelatencybyaboutonethirdforsmallandlargepacketswhenwecan
choosethetriangularrouteovertherobustbutmorecostlybi-directionaltunnel.
6.2.2. Cost
Wemeasureboththetimespentindoingregularroutelookupandthetimespentindoingroutelookup
withaMobilePolicyTablelookuponamobilehost. Wethenexaminethedierencetodeterminetheadded
latencyin makingpolicydecisionsaccordingtotheMobilePolicyTable.
Cached Uncached
Experiment Time(s) StandardDeviation Time(s) StandardDeviation
Regularroutelookup 18.5 0.8 100.1 0.9
Routelookupw/MPT 23.5 0.7 116.5 1.2
Table4
CosttoSupporttheSimultaneousUseofMultiplePacketDeliveryMethods.Thisexperimentmeasures
boththetimeneededfortheregularroutelookupandthetimespenttodothemodiedroutelookup
withMobilePolicyTable(MPT)consultation. Eachmeasurementisrepeated10times.Wetestedcases
forbothacachehitandacachemisswhenlookinguproutes.
Home
Agent
Correspondent
Host
Mobile
Host
Foreign Network
Home Network
Router
Host
Mobile
Figure 11. Setup of the Test Environmentfor Experiments on Flow Demultiplexing. The MobileHost isa Gateway2000
(486DX2-40processor)andtheHomeAgentisaToshibaTecra(Pentium133MHz),bothofwhichhaveanEthernetinterface
aswellasaMetricomradiointerface.TheCorrespondentHostisa90MHzPentium. AllmachinesarerunningLinux.
round-triptimebetweentwohosts onthesameEthernetsegment(typicallyaround2ms).
6.3. Experiments withMultiple ActiveInterfaces
The main possible source of overhead for supporting multiple interfaces is the ow demultiplexing
processing on the home agent, which may aect both the latency and the throughput. The goal of the
experimentsdescribedinthissectionistoevaluatethelatencycostofthisdemultiplexing,i.e.theextratime
ittakesforahomeagenttoforwardapacketaddressedtoamobilehost.
Thesetupof ourtestenvironmentis illustratedin Figure 11. Forthese experiments,themobile host
connectstoaforeignnetworkononeofourdepartment'sEthernetsandregistersitscurrentcare-ofaddress
with itshomeagent. Thecorrespondenthostsendsping packets tothe mobilehost. Wemeasure theow
binding demultiplexing timeat thehome agentbymonitoringthecodeusing theLinux dogettimeofday
kernelfunction. We consider twocases: when the home agenthas no Flow-to-Interfacebindings, regular
Mobile IP is used; when the home agent contains Flow-to-Interface bindings, it must search the list of
bindingsbeforeforwardingapackettothemobilehost.
Wecollectthedatabyrepeatingtheabovetest 10timeseach asthenumberofbindingsinthehome
agent'slistincreasesfrom0to60. Table5displaystheresults.
Theseresultsfortheowbindingdemultiplexingcostmayseemlargecomparedtothedemultiplexing
time incurred withregular Mobile IPonthe homeagent(2.1 s), but theextracost is asmall additional
factorwhencomparedto theround-triptimebetweenthemobilehostandthecorrespondenthost,whichis
approximately5400sinthis experimentalsetup. Theowbindingdemultiplexingcostvaries from2.3s
foronebindingto 9.2sfor60bindings.
Notethatthecostperowbindingdecreasesasthenumberofowbindingsinthelistincreases,with
Packet Processing DemultiplexingbyFlow
FlowBindings Time(s) StandardDeviation Cost(s) Perbinding(s)
0 2.1 0.30 N/A 1 2.3 0.45 0.2 0.20 2 2.7 0.30 0.6 0.30 10 3.9 0.30 1.8 0.18 20 4.7 0.46 2.6 0.13 30 5.3 0.46 3.2 0.11 40 6.7 0.64 4.6 0.12 60 9.2 0.40 7.1 0.12 Table5
FlowBindingDemultiplexingCost.ThePacketProcessingcolumndisplaysthetotaltimespentbythe
homeagentindecidinghowtoforwardapackettothemobilehost.TheDemultiplexingbyFlowcolumn
displaysthecostofowdemultiplexingwhichispartofthetotalpacketprocessingtime.
entryfor themobilehostin themobilitybindingtable onthehomeagentbyhashingonthemobile host's
home IP address. The second part searches into a list for a ow binding corresponding to the incoming
packet. Whenthenumberofbindingsinthelistissmall,thecostoftherstpartdominates. Ontheother
hand,whenthenumberofbindingsin thelistislarge,thecostoftherstpartisamortized,and itseect
becomesnegligible.
7. Related Work
Thereareseveralprojectsfocusingonprovidingexibilitysupportformobilehosts atdierentlayers
ofthenetworksoftwarestack.
Workat OregonGraduateInstituteandPortlandStateUniversity[11]concentratesonlowernetwork
layersthan ours. It addresses the exibilityneeds of amobile hostin the face of physical media changes,
mainly dealingwith IPreconguration issues. Thefocusisonamodel thatdeterminesthesetof available
network devices and dynamically recongures a mobile system in response to changes in the link-layer
environment.
TheCMUMonarchproject[12]aimsatenablingmobilehoststocommunicatewitheachotherandwith
stationary orwired hosts transparently andadaptively, making themost eÆcient use of thebest network
connectivityavailable to the mobile hostat any time. It has anoverall goalsimilar to ours,although the
projectcurrently does notsupport the use of multiple packet delivery methods simultaneously. Monarch
alsofocusesonadhocnetworking,whichwecurrentlydonotsupport.
The CMUOdyssey project[21] extends the Unix systemcall interfaceto support adaptationat the
applicationlayer. Odysseyexposesresourcestoapplicationsbyallowingthemtospecifyaboundoftolerance
for aresource. When thebehaviorof theresourcemovesoutsidethetolerance window, theapplication is
informedviaanup-call.
Making simultaneous use of multiple interfaces is also an important goal of the work by Maltz and
Bhagwat [17]. Theirapproach provides transport layermobility bysplitting each TCP session between a
mobilehostandaserverintotwoseparateTCPconnectionsattheproxy,throughwhichallpacketsbetween
themobile hostand theserverwill travel. It allowsamobilehostto changeitspointofattachmenttothe
Internetbyrebindingthemobile-proxyconnectionwhilekeepingtheproxy-serverconnectionunchanged. It
can control which network interfaces are used for dierent kindsof data leaving from and arriving at the
mobile host. However, their work diers from ours in that it does not use Mobile IP and it selects the
interfaceby explicitlypicking thecorrespondingIPaddresses touse onapersession basis,while withour
TheBARWANproject[14]atUCBerkeleyalsoprovidesnetworklayermechanismstosupportmobile
hosts,butwithadierentfocus. Itaimsatbuildingmobileinformationsystemsuponheterogeneouswireless
overlaynetworkstosupportservicesallowingmobileapplicationstooperateacrossawiderangeofnetworks.
Theyconcentrateonprovidinglow-latencyhand-osamongmultiplenetworkdevices.
TheuseofaMobilePolicyTableissimilartotheSecurityPolicyDatabase(SPD)inIPsec[15],which
needstobeconsultedinprocessingalltraÆc. WhiletheMobilePolicyTableisusedtodirecttheaddressing
androutingdecisionsinsendingpackets,theSPDdealswiththesecurityaspectsoftraÆccontrol. Another
dierenceisthattheMobilePolicyTableisonlyineectforoutgoingtraÆc. ItaectstheincomingtraÆc
throughtheselectionofthesourceIPaddressfortheoutgoingtraÆcand/orthroughcoordinationwiththe
homeagent. TheSPDisineect forbothinbound andoutbound traÆcallthetime.
Insummary,ourapproachfocusesonthenetworklayer,providingincreasedsupportforamobilehost
to control howit sends and receivespackets. Our work diers from other work in the combination ofthe
followingfeatures:
1. Mobile IPisan integralpartofoursystem. Weaddresstheissue ofhowMobile IPcanbeused most
eÆcientlyandexiblyonmobilehosts.
2. Oursystemprovidessupportformultiple packetdeliverymethods.
3. Oursystemenablestheuseofmultiple activeinterfacessimultaneously.
8. IPv6 Considerations
WithIPv6[10]amobilehostwillalwaysbeabletoobtainaco-locatedcare-ofaddressin thenetwork
it is visiting. However, the fact that a mobile host will alwayshave both a home role (acting as a host
still connected to its home network) and a local role (acting as a normal host in the visited network)
simultaneouslywillstillbeanissue. Anexampleisin multicastscoping. Amobilehostneedstoassumeits
homerole ifitwantsto join themulticast groupscoped withinits homedomain, whileit needstoassume
itslocalroletojointhemulticastgroupscopedwithinthevisiteddomain. Therefore,becauseoftheduality
of therolesamobile hostcan assume,there is alwaystheneed foramobile hosttoselect dierentpacket
deliverymethods fordierenttraÆc ows.
With regardto multipleinterfacemanagementunder IPv6,wehavethefollowingobservations:
1. Mobile IPv6 [24] provides route optimization. As a result, the correspondent hosts can send packets
directly to the mobile host without going through the home agent. Therefore, the Flow-to-Interface
bindingextensionsneedtobesentto thecorrespondenthostsaswell.
2. TheIPv6ow labeleld can beveryusefulforprovidingmultiple interface support. The owlabelis
aeld of theIPv6header thatis setbythe sourceofthepacketand usedbyrouters toidentify ows.
ThisowlabeleldcouldbeusedbytheHomeAgenttodemultiplexpacketsandforwardthemonthe
appropriateinterfaceswithoutlooking intothetransportlayereldfortheport informationtoidentify
aow. This alsosimplies the handlingof fragmentedpackets onthe home agent by eliminatingthe
needtoreassemblethembeforeforwardingthem tothemobilehost.
3. IPv6 provides apriority (class) eld used by routers to provide dierent servicesto dierent typesof
packets. Thiseld can potentiallybeusedin ourproposalbythehomeagentindetermining themost
appropriateinterfaces throughwhich to forward packets addressed to amobile hostin theabsence of
9. Conclusions and Future Work
Because of a mobile host's use of multiple interfaces and the dynamic environmentin which it may
operate, amobile hostusing Mobile IPdemands exibility in the way itsends and receives packets. Fine
granularitycontrolofnetworktraÆconaperowbasisisneeded. Ourexperimentsshowthatwithreasonable
overheadwecanaddresstheexibilityneedsofamobilehostbymaintainingabalancebetweentherobustness
andeÆciencyneedsofpacketdelivery.
It isdesirabletochoosedierentpacketdeliverymethodsaccordingto thecharacteristicsofdierent
traÆcows. Wehavedevisedageneral-purposemechanismatthenetworkroutinglayertomakethispossible
bycouplingtheconsultationofaMobilePolicyTablewiththeregularroutingtablelookup.
Itisalsodesirableforamobilehosttobeabletomakeuseofmultiplenetworkinterfacessimultaneously
fordierentowsoftraÆc. Forthis, wehaveaddedtwonewsocket optionsand haveextended theMobile
IPprotocolwithnewregistrationextensionssothatamobilehosthasmorecontrol overwhichinterfaceto
usetosendandreceivepackets.
10. Acknowledgements
We thankPetrosManiatis, KevinLai, Mema Roussopoulos,and Diane Tang of MosquitoNet Group
for discussions and feedback on the ideas presented in this paper. Ajay Bakre and Charlie Perkins
pro-vided thoughtfulcommentsandsuggestionsonanearlierversionofthepaper. Weare alsograteful tothe
anonymousreviewersfortheirextremelydetailedcomments.
This work wassupported in partbyastudentfellowship from XeroxPARC,aTermanFellowship,a
grantfrom NTTDoCoMo,and agrantfromthe KeioResearch Instituteat SFC,KeioUniversityandthe
Information-technologyPromotionAgency,Japan.
References
[1] A.Acharya,A.Bakre,andB.Badrinath.IPMulticastExtensionsforMobileInternetworking.InProceedingsoftheIEEE
INFOCOM'96,1996.
[2] J.AgostaandT.Russell.CellularDigitalPacketDataStandardsandTechnology. McGraw-Hill,1996.
[3] M.Baker,X.Zhao,S.Cheshire,andJ.Stone.SupportingMobilityinMosquitoNet.InProceedingsoftheAnnualUSENIX
TechnicalConference,1996.
[4] ComputerEmergencyResponseTeam(CERT). IPSpoongAttacksandHijackedTerminalConnections. InCA-95:01,
1995.
[5] S.DeeringandD.Cheriton. MulticastRoutinginDatagramInternetworksandExtendedLANs. ACMTransactionson
ComputerSystems,Vol.8,No.2,pp.85-110,1990.
[6] R.Droms.DynamicHostCongurationProtocol. RFC2131,March1997.
[7] P.FergusonandD.Senie.NetworkIngressFiltering:DefeatingDenialofServiceAttackswhichEmployIPSourceAddress
Spoong. RFC2267,1998.
[8] R.Fielding,J.Gettys,J.Mogul,H.Frystyk,andT.Berners-Lee. HypertextTransferProtocol{HTTP/1.1. RFC2068,
1997.
[9] T.G.Harrison,C.L.Williamson,W.L.Mackrell,andR.B.Bunt.MobileMulticast(MoM)Protocol: MulticastSupport
forMobileHosts. InProceedingsof theThird AnnualACM/IEEEInternationalConferenceon MobileComputingand
Networking,1997.
[10] C.Huitema. IPv6: TheNewInternetProtocol. PrenticeHall,1997.
[11] J.Inouye,J.Binkley,andJ.Walpole. DynamicNetworkRecongurationSupportforMobileComputers. InProceedings
of theThirdAnnualACM/IEEEInternationalConferenceonMobileComputingandNetworking,1997.
[12] D.B.JohnsonandD.A.Maltz.ProtocolsforAdaptiveWirelessandMobileNetworking.IEEEPersonalCommunications,
3(1):34-42,1995.
[14] R. H. Katzand E. A. Brewer. The Case for Wireless Overlay Networks. InProceedings of the SPIE Conference on
MultimediaandNetworking,1996.
[15] S.KentandR.Atkinson.SecurityArchitecturefortheInternetProtocol.RFC2401,1998.
[16] K. Lai,M.Roussopoulos,D.Tang, X.Zhao,andM.Baker. ExperienceswithaMobileTestbed. InProceedings ofthe
SecondInternationalConferenceonWorldwideComputinganditsApplications(WWCA'98),1998.
[17] D. A. Maltzand P.Bhagwat. MSOCKS: AnArchitecture forTransport LayerMobility. In Proceedings of theIEEE
INFOCOM'98,1998.
[18] Metricom. TheRicochetWirelessNetworkOverview. http://www.ricochet.net/ricochet/, 1997.
[19] G.Montenegro. ReverseTunnelingforMobileIP.RFC2344,1998.
[20] G.MontenegroandV.Gupta.Sun'sSKIPFirewallTraversalforMobileIP. RFC2356,1998.
[21] B.Noble,M.Satyanarayanan,D.Narayanan,J.E.Tilton,J.Flinn,andK.Walker. AgileApplication-AwareAdaptation
forMobility. InProceedingsofthe16thACMSymposiumonOperatingSystemPrinciples,1997.
[22] C.Perkins.IPEncapsulationwithinIP. RFC2003,1996.
[23] C.Perkins.IPMobilitySupport.RFC2002,1996.
[24] C.E.PerkinsandD.B.Johnson.MobilitySupportinIPv6.InProceedingsoftheSecondAnnualACM/IEEEInternational
ConferenceonMobileComputingandNetworking,1996.
[25] J.Postel. InternetProtocol. RFC791,1981.
[26] DARPAInternetProgram.TransmissionControlProtocol.RFC793,1981.
[27] S.H.Redl,M.K.Weber,andM.W.Oliphant. AnIntroductiontoGSM. ArtechHouse,1995.
