DTIC ADA458849: Efficient Routing in Packet-Radio Networks Using Link-State Information

6 Pages·0.11 MB·English

by  Defense Technical Information Center

1of5
Efficient Routing in Packet-Radio Networks Using Link-State Information
J.J.Garcia-Luna-Aceves MarceloSpohn
ComputerEngineeringDepartment RooftopCommunications
UniversityofCalifornia MountainView,California94041
SantaCruz,California95064 [email protected]
[email protected]
Abstract-We present the source-tree adaptive routing (STAR) tancevectorsaretheroutingprotocoloftheDARPApacket-radionet-
protocol,whichweshowthroughsimulationexperimentstobefar work [8], DSDV [12], WRP [15], and WIRP [4]. Prior table-driven
more efficient than the Dynamic SourceRouting(DSR) protocol, approachestolink-stateroutinginpacket-radionetworksarebasedon
whichhasbeenshowntobeoneofthebestperformingon-demand topologybroadcast. However,disseminatingcompletelink-stateinfor-
routingprotocols.ArouterinSTARcommunicatestoitsneighbors mation to all routers incurs excessive communication overhead in an
the parameters of its source routing tree, which consists of each ad-hocnetworkbecauseofthedynamicsofthenetworkandthesmall
linkthattherouterneedstoreacheverydestination. Toconserve bandwidthavailable.Accordingly,alllink-stateroutingapproachesfor
transmissionbandwidthandenergy,aroutertransmitschangesto packet-radionetworkshavebeenbasedonhierarchicalroutingschemes
its source routingtree only when the router detects new destina- [14],[16].
tions, thepossibilityoflooping, orthepossibilityof nodefailures Todate,thedebateonwhetheratable-drivenoranon-demandrout-
ornetworkpartitions. ing approach is best for wireless networks has assumed that table-
drivenroutingnecessarilyhastoprovideoptimum(e.g.,shortest-path)
I. INTRODUCTION routing,wheninfacton-demandroutingprotocolscannotensureopti-
mumpaths.Inthispaper,weintroducethesource-treeadaptiverouting
Multi-hop packet-radio networks, or ad-hoc networks, consist of
(STAR)protocol, whichisthefirstexample of atable-driven routing
mobile hosts interconnected by routers that can also move. The de-
protocolthatismoreefficientthananyon-demandroutingprotocolby
ployment of such routers is ad-hoc and the topology of the network
exploiting link-stateinformationand allowing pathstaken todestina-
isverydynamic, because of host and router mobility, signal lossand
tionstodeviatefromtheoptimuminordertosavebandwidth.Further-
interference, and power outages. In addition, the channel bandwidth
more,STARcanbeusedwithdistributedhierarchicalroutingschemes
available in ad-hoc networks is relatively limited compared to wired
proposedinthepastforbothdistance-vectororlink-staterouting.
networks,anduntetheredroutersmayneedtooperatewithbattery-life
SectionIIdescribesSTAR,andSectionIIIcomparesSTAR’sperfor-
constraints.
manceagainsttheperformanceofDSR,whichhasbeenshowntoincur
Routingalgorithmsforad-hocnetworkscanbecategorizedaccord-
theleastoverheadamongseveralon-demandroutingprotocols[2].
ing to the way in which routers obtain routing information, and ac-
cordingtothetypeofinformationtheyusetocomputepreferredpaths.
II. STARDESCRIPTION
Intermsofthewayinwhichroutersobtaininformation, routingpro-
tocols have been classified as table-driven and on-demand. In terms A. Overview
ofthetypeofinformationusedbyroutingprotocols,routingprotocols
InSTAR,eachrouterreportstoitsneighborsthecharacteristicsof
canbeclassifiedintolink-stateprotocolsanddistance-vectorprotocols.
every link it uses to reach a destination. The set of links used by a
Routersrunningalink-stateprotocolusetopologyinformationtomake
router initspreferred pathtodestinations iscalledthesource tree of
routing decisions; routers running a distance-vector protocol use dis-
therouter. Arouter knows itsadjacent links and thesource treesre-
tances and, in some cases, path information, to destinations to make
portedbyitsneighbors;theaggregationofarouter’sadjacentlinksand
routingdecisions.
thesourcetreesreportedbyitsneighborsconstituteapartialtopology
Inanon-demandroutingprotocol,routersmaintainpathinformation
graph. Thelinksinthesourcetreeandtopologygraphmustbeadja-
foronlythosedestinationsthattheyneedtocontactasasourceorre-
cent linksorlinksreported byatleast oneneighbor. Therouter uses
lay of information. The basic approach consists of allowing a router
thetopologygraphtogenerateitsownsourcetree.Eachrouterderives
that does not know how toreach adestination tosend aflood-search
aroutingtablespecifyingthesuccessortoeachdestinationbyrunning
messagetoobtainthepathinformationitneeds. Thefirstroutingpro-
alocalroute-selectionalgorithmonitssourcetree. Althoughanytype
tocolofthistypewasproposedtoestablishvirtualcircuitsintheMSE
of local route-selection algorithm can be used in STAR,we describe
network [9], and there are several more recent examples of this ap-
STAR assuming that Dijkstra’s shortest-path first (SPF) algorithm is
proach(e.g.,AODV[13],DSR[7],TORA[11]).TheDynamicSource
usedateachroutertocomputepreferredpaths.
Routing(DSR)protocolhasbeenshowntooutperformmanyotheron-
ArouterrunningSTARsendsupdatesonitssourcetreetoitsneigh-
demandroutingprotocols[2]. Alloftheon-demandroutingprotocols
borsonlywhenitlosesallpathstooneoremoredestinations,whenit
reportedtodatearebasedondistancestodestinations,andtherehave
detectsanewdestination, orwhenitdeterminesthatlocalchangesto
beennoon-demandlink-stateproposalstodate.
itssourcetreecanpotentiallycreatelongtermroutingloops. Because
Inatable-drivenalgorithm,eachroutermaintainspathinformation
eachroutercommunicatesitssourcetreetoitsneighbors,thedeletion
foreachknowndestinationinthenetworkandupdatesitsrouting-table
ofalinknolongerusedtoreachadestinationisimplicitwiththeaddi-
entriesasneeded. Examplesoftable-drivenalgorithmsbasedondis-
tionofthenewlinkusedtoreachthedestinationandneednotbesent
explicitlyasanupdate;aroutermakesexplicitreferencetoafailedlink
ThisworkwassupportedinpartatUCSCbytheDefenseAdvancedResearchProjectsAgency(DAR
PA)underGrantF30602-97-2-0338. onlywhenthedeletionofalinkcausestheroutertohavenopathsto
Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
1999 2. REPORT TYPE 00-00-1999 to 00-00-1999
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Efficient Routing in Packet-Radio Networks Using Link-State
5b. GRANT NUMBER
Information
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
University of California,Computer Engineering Department,Santa REPORT NUMBER
Cruz,CA,95064
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
14. ABSTRACT
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON

a. REPORT b. ABSTRACT c. THIS PAGE 5
unclassified unclassified unclassified
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
2of5
oneormoredestinations,inwhichcasetheroutercannotprovidenew paring itssource treeagainst thesource treesit hasreceived fromits
linkstomakethedeletionofthefailedlinkimplicit. neighbors.
The basic update unit used in STAR to communicate changes to
LORA-1:Router findsanewdestination,oranyofitsneighbors
source treesisthe link-stateupdate (LSU).An LSUfor a link
reportsianewdestination.
in an update message is a tuple reporting the char(auc;tevr)-
isticsofthelink,where represen(tus;tvh;el;csonst)ofthelinkand isthe Whenever a router hears from a new neighbor that is also a new
sequencenumberassigneldtotheLSU;anupdatemessageconstaninsone destination,itsendsanupdatemessagethatincludesthenewLSUsin
ormoreLSUs.Foralinkbetweenrouter androuterordestination , itssource tree. Obviously, when a router is firstinitializedor after a
router iscalledtheheadnodeofthelinkuinthedirectionfrom tov. reboot,therouteritselfisanewdestinationandshouldsendanupdate
Theheuadnodeofalinkistheonlyrouterthatcanreportchangesuinthve message to its neighbors. Link-level support should be used for the
parametersofthatlink. router to know its neighbors within a short time, and then report its
LSUsarevalidated using sequence numbers, arouter receiving an linkstothoseneighborswithLSUssentinanupdatemessage. Else,a
LSUacceptstheLSUasvalidifthereceivedLSUhasalargersequence simplewaytoimplementaninitializationactionconsistsofrequiring
number than the sequence number of the LSU stored from the same the router to listen for some time for neighbor traffic, so that it can
source,orifthereisnoentryforthelinkinthetopologygraphandthe detecttheexistenceoflinkstoneighbors.
LSUisnotreportinganinfinitecost. Link-stateinformationforfailed
LORA-2:Atleastonedestinationbecomesunreachabletorouter
linksaretheonlyLSUserasedfromthetopologygraphduetoaging
oranyofitsneighbors. i
(whichisintheorderofanhourafterhavingprocessedtheLSU).LSUs
foroperationallinksareerasedfromthetopologygraphwhenthelinks Whenarouterprocessesaninputevent(e.g.,alinkfails,anupdate
areerasedfromthesourcetreeofalltheneighbors. messageisreceived)thatcauses allitspathsthroughallitsneighbors
Wenotethat,becauseLSUsforoperationallinksneverageout,there to one or more destination to be severed, the router sends an update
isnoneedfortheheadnodeofalinktosendperiodicLSUstoupdate message that includes an LSUspecifying an infinitecost for the link
the sequence number of the link. This is very important, because it connectingtotheheadofeachsubtreeofthesourcetreethatbecomes
meansthatSTARdoesnotneedperiodicupdatemessagestovalidate unreachable. TheupdatemessagedoesnothavetoincludeanLSUfor
link-stateinformationlikeOSPF[10]andeverysingleroutingprotocol eachnodeinanunreachablesubtree,becauseaneighborreceivingthe
basedonsequencenumbersortimestampsdoes! Tosimplifyourde- update message has the sending node’s source tree and can therefore
scription,thespecificationintherestofthispaperdescribesSTARasif inferthatallnodesbelowtherootofthesubtreearealsounreachable,
unboundedcounterswereavailabletokeeptrackofsequencenumbers. unlessLSUsaresentfornewlinksusedtoreachsomeofthenodesin
An underlying protocol, which we call the neighbor protocol, as- thesubtree.
sures that arouter detects within afinitetime the existence of anew
LORA-3:Thisrulehasthreeparts:
neighbor and the loss of connectivity with a neighbor, and provides
the reliable transmission of update messages generated by STAR to 1. Apathimpliedinthesourcetreeofrouter leadstoaloop.
the neighbors of the router. All messages, changes in the cost of a 2. Thenewsuccessorchosentoagivendestiinationhasanaddress
link,linkfailures,andnew-neighbornotificationsareprocessedoneat largerthantheaddressofrouter .
atimewithinafinitetimeandintheorderinwhichtheyaredetected. 3. Thereporteddistancefromtheniewchosensuccessor toades-
Routersareassumedtooperatecorrectly, andinformationisassumed tination islongerthanthereporteddistancefromthneprevious
tobestoredwithouterrors.Thecostofafailedlinkisconsideredtobe successojrtothesamedestination.However,ifthelink fails
infinity. and isaneighborof ,noupdatemessageisneeded(ir;egja)rding
ornanydestinationwhjosepathfrom involves .
B. ExchangingUpdateMessages j i j
Wecandistinguishbetweentwomainapproachestoupdatingrout- Eachtimearouterprocessesanupdatemessagefromaneighbor,it
ing information in the routing protocols that have been designed for updatesthatneighbor’ssourcetreeandtraversesthattreetodetermine
wirelessnetworks:theoptimumroutingapproach(ORA)andtheleast- forwhichdestinationsitsneighborusestherouterasarelayinitspre-
overhead routingapproach(LORA).WithORA,theroutingprotocol ferredpaths.Therouterthendeterminesifitisusingthesameneighbor
attemptstoupdateroutingtablesasquicklyaspossibletoprovidepaths asarelayforanyofthesamedestinations. Aroutingloopisdetected
that are optimum with respect to a defined metric. In contrast, with iftherouterandneighboruseeachotherasrelaytoanydestination,in
LORA,theroutingprotocolattemptstoprovideviablepathsaccording whichcasetheloopmustbebrokenandtheroutermustsendanupdate
toa given performance metric, which need not be optimum, toincur messagewiththecorrespondingchanges.
theleastamountofcontroltraffic. ToexplaintheneedforthesecondpartofLORA-3,weobservethat,
On-demandroutingprotocolssuchasDSRfollowLORA.Interest- in any routing loop among routers with unique addresses, one of the
ingly,allthetable-drivenroutingprotocolsreportedtodateforad-hoc routersmusthavethesmallestaddressintheloop;therefore,ifarouter
networksadheretoORA,andadmittedlyhavebeenadaptationsofrout- isforcedtosendanupdatemessagewhenitchoosesasuccessorwhose
ing protocols developed for wired networks; STAR is the first table- addressislargerthanitsown, thenitisnot possibleforallroutersin
drivenroutingprotocolthatimplementsLORA. aroutinglooptoremainquiet afterchoosing oneanother, because at
In an on-demand routing protocol, a router can keep using a path least one of themisforced tosend an update message, which causes
foundaslongasthepathleadstothedestination,evenifthepathdoes thelooptobreakwhenroutersupdatetheirsourcetrees.
nothaveoptimumcost. AsimilarapproachisusedinSTAR,because ThelastpartofLORA-3isneededwhenlinkcostscanassumedif-
eachrouterhasacompletepathtoeverydestinationaspartofitssource ferent values indifferent directions, in whichcase thesecond part of
tree.Arouter runningSTARshouldsendupdatemessagesaccording LORA-3 may not suffice to break loops because the node with the
tothefollowinigthreerules,whichinformroutersofunreachabledesti- smallestaddressintheloopmaynothavetochangesuccessorswhen
nations,newdestinations,andupdatetopologyinformationtoprevent the loop is formed. The following example illustrates this scenario.
permanent routing loops. Router implements these rules by com- Considerthesix-nodewirelessnetworkshowninFigure1andassume
i
3of5
that the third part of LORA-3 is not in effect at the routers running
STAR.Inthisexample,nodesaregivenidentifiersthatarelexicograph- b e b e b e
icallyordered,i.e., isthesmallestidentifierand isthelargestiden- a 1 5 f a f a f
tifierinthegraph. aAlllinksandnodesareassumfedtohavethesame
propagationdelays,andallthelinksbutlink haveunitcost. Fig- c d c d c d
ures1(b)through1(d)showthesourcetreesa(bc;coc)rdingtoSTARatthe
routersindicatedwithfilledcirclesforthenetworktopologydepicted (a) (b) (c)
inFigure1(a). Arrowheadsonsolidlinesindicatethedirectionofthe
linksstoredintherouter’ssourcetree.Figure1(e)shows ’snewsource
treeafterprocessingthefailureoflink ;wenotetchat doesnot b e b e b e
generateanupdatemessage, because (c;d)byassumption.cSuppose a f a f a f
link failsimmediatelyafterthefacilu>rebof ,node computes
itsne(wb;seo)urcetreeshowninFigure1(f)without(cre;pdo)rtingchbangestoit c d c d c d
because isitsnewsuccessortodestinations , ,and ,and .A
permaneantloopformsamongnodes , ,andd.e f a<b (d) (e) (f)
Figure2depictsthesequence ofaevebnts tricggeredby theexecution
of the third part of LORA-3 in the same example introduced in Fig- Fig.1. RoutersrunningSTARwithoutthethirdpartofLORA-3ineffect.
ure1,afterthefailuresoflinks and . Thefigureshowsthe
LSUsgeneratedbythenodewit(hc;fidll)edcir(cble;et)ransmittedinanupdate b e b e b e
messagetotheneighbors, andshowssuchLSUsinparentheses. The
a 1 5 f a f a f
thirdelementinanLSUcorrespondstothecostofthelink. Unlikein
the previous example, node transmits an update message after pro- c d c d c d
cessingthefailureoflink c becauseofthethirdpartofLORA-3; (b, e, 1) (e, d, 1) (e, f, 1) (e, d, 1) (e, f, 1)
thedistancefromthenew(scu;cdc)essor to and islongerthanfrom
the previous successor . When linkb d failsf, node realizes that (a) (b) (c)
the destinations , , andd are unreac(hb;aeb)le and generabtes an update
messagereportindgtehefailufreofthelinkconnectingtotheheadofthe
b e b b
subtreeofthesourcetreethatbecomesunreachable. Theupdatemes-
sagefrom triggerstheupdatemessagesthatallownodes , ,and a a a
torealizethbattherearenopathsto , ,and . Asimilarseaqubenceocf
c c c
eventstakesplaceattheothersideodftheenetwforkpartition. (b, e, infinity) (b, e, infinity) (b, e, infinity)
Theexample shown inFigure3illustratesthe scenarioinwhich a
routerthatchoosesanewsuccessortoadestinationwithalargerdis- (d) (e) (f)
tancetoitdoesnotneedtosendanupdatemessage. Forthisexample,
thesourcetreesofnodes , ,and aredepictedinFigures2(c),1(c), Fig.2. RoutersrunningSTARwiththethirdpartofLORA-3ineffect.
and2(b),respectively.Figaureb3(b)schowsthenewsourcetreeofnode
afterthefailureoflink . Inthiscase, doesnotneedtosendanc
b e b e
updatemessagebecause(cth;eb)parentnodeoftchesubtreeheadedby isa
neighborof andthereforenopermanentloopcanbeformed. b a 1 5 f a f
Toensurecthattheaboverulesworkwithincrementalupdatesspeci-
c d c d
fyingonlychangestoasourcetree,aroutermustrememberthesource 10
treethatwaslastnotifiedtoitsneighbors.IfanyofLORA-1toLORA-
(a) (b)
3aresatisfied,theroutermustdooneoftwothings:
Ifthenewsourcetreeincludesnewneighborsthanthosepresent
(cid:15) Fig.3. ThethirdpartofLORA-3notalwaystriggersthegenerationofanupdatemessage:
inthesourcetreethatwaslastupdated,thentheroutermustsend
(a)networktopology,and(b)thenewsourcetreeofnode afterprocessingthefailure
its entire source tree in its update, so that new neighbors learn oflink . c
aboutallthedestinationstherouterknows. (c;b)
Ifthetwosourcetreesimplythesameneighbors,theroutersends updatemessagesconsistsofaroutersendinganupdatemessageevery
(cid:15) onlytheupdatesneededtoobtainthenewtreefromtheoldone. timeitssourcetreechanges.
ToensurethatSTARstopssendingupdatemessages,asimplerule
III. PERFORMANCEEVALUATION
canbeusedtodeterminewhichroutermuststopusingitsneighboras
arelay, such arulecan be, for example, “the router with thesmaller STARhas thesame communication, storage, and time complexity
addressmustchangeitspath.” thanALP[5]andefficienttable-driven distance-vectorroutingproto-
The above rules are sufficient to ensure that every router obtains colsproposed todate (e.g., WRP[15]). However, worst-case perfor-
loopless paths to all known destinations, without the routers having manceisnottrulyindicativeofSTAR’sperformance.
tosend updates periodically. Inaddition totheabilityfor arouter to WecompareSTARwithDSR,becauseDSRhasbeenshowntobe
detectloopsinSTAR,thetwokeyfeaturesthatenableSTARtoadopt oneofthebest-performingon-demandroutingprotocols[2].
LORAare: (a)validatingLSUswithouttheneedofperiodicupdates, The protocol stack implementation in our simulator runs the very
and(b)theabilitytoeitherlistentoneighbors’packetsoruseaneigh- same code used in a real embedded wireless router and IP (Internet
borprotocolatthelinklayertodeterminewhotheneighborsofarouter Protocol)isusedasthenetworkprotocol.
are. Thelinklayerimplementsamediumaccesscontrol(MAC)protocol
IfORAistobesupportedinSTAR,theonlyruleneededforsending similartotheIEEE802.11[6]standardandthephysicallayerisbased
4of5
onadirectsequencespreadspectrumradiowithalinkbandwidthof1 Number UpdatePktsSent DataPktsDelivered DataPkts
ofFlows STAR DSR STAR DSR Generated
Mbit/sec.Theneighborprotocolisconfiguredtoreportlossofconnec-
8 585 791 14898 14740 24100
tivitytoaneighboriftheprobationofthelinkfailsinaperiodofabout
14 560 1466 15206 15367 25917
10seconds.
20 575 3122 13922 6830 23718
The simulation experiments use 20 nodes forming an ad-hoc net-
TABLEI
work, moving over a flat space (5000m x 7000m), and initially ran-
AVERAGEPERFORMANCEOFSTARANDDSRFORNODESMOVINGDURING900
domlydistributedatadensityofonenodepersquarekilometer.
SECONDSOFSIMULATEDTIME,TOTALCHANGESINLINKCONNECTIVITYWAS1460.
The simulation study was conducted in the C++ Protocol Toolkit
(CPT)simulatorenvironment.
Thesimulationexperimentsusethesamemethodologyusedrecently Number UpdatePktsSent DataPktsDelivered DataPkts
to evaluate DSR and other on-demand routing protocols [2]. To run ofFlows STAR DSR STAR DSR Generated
DSRinoursimulationenvironment, weportedthens2codeavailable 8 946 1963 33159 32650 52900
from[17]intotheCPTsimulator.Thereareonlytwodifferencesinour 14 911 2648 31992 32390 54716
20 934 6605 29978 10175 52518
DSRimplementationwithrespecttothatusedin[2]:(1)intheembed-
dedwirelessroutersandsimulatedprotocolstackweusedthereisno TABLEII
accesstotheMAClayerandcannotreschedulepacketsalreadysched- AVERAGEPERFORMANCEOFSTARANDDSRFORNODESMOVINGDURING1800
uledfortransmissionover alink(however, thisisthecaseforallthe SECONDSOFSIMULATEDTIME,TOTALCHANGESINLINKCONNECTIVITYWAS2787.
protocolswesimulate),and(2)routerscannotoperatetheirnetworkin-
terfacesinpromiscuousmodebecausetheMACprotocoloperatesover
asthreetimesmoredatapacketsthanDSRduring1800secondsofsim-
multiple channels and a router does not know on which channels its
ulatedtime,andalmosttwicetheamountofdatapacketsdeliveredby
neighborsaretransmitting,unlessthepacketsaremeantfortherouter.
DSRduring900secondsofsimulatedtime.
BothSTARandDSRcanbuffer20packetsthatareawaitingdiscovery
ofaroutethroughthenetwork. TheMAClayerdiscardsallpacketsscheduledfortransmissiontoa
Theoverallgoalofthesimulationexperimentswastomeasurethe neighborwhenthelinktotheneighbor fails,whichcontributestothe
abilityoftheroutingprotocolstoreacttochangesinthenetworktopol- highlossofdatapacketsseenbynodes. InDSR,eachpacket header
carries the complete ordered list of routers through which the packet
ogy while delivering data packets to their destinations. To measure
this ability we applied to the simulated network three different com- must pass and may be updated by nodes along the path towards the
munication patterns corresponding to 8, 14, and 20 data flows. The destination. Thelowthroughput achieved byDSRfor thecaseof 20
totalworkloadinthethreescenarioswasthesameandconsistedof32 sources of data isdue tothe poor choice of source routestherouters
datapackets/sec,inthescenariowith8flowseachcontinuousbitrate make, leadingtoasignificantincreaseinthenumberofROUTEER-
(CBR)sourcegenerated4packets/sec,inthescenariowith20sources RORpacketsgenerated. Datapacketsarealsodiscardedduetolackof
routestothedestinationsbecausethenetworkmaybecometemporar-
eachCBRsourcegenerated1.6packets/sec,andinthescenariowith14
flowstherewere7flowsfromdistinctCBRsourcestothesamedestina- ilypartitionedorbecausetheroutingtableshavenotconvergedinthe
tion generatinganaggregateof28packets/secand7flowshaving highlydynamictopologywesimulate.
asthDeCBRsourceandtheother7sourcesofdataasdestinations.InaDll Figures4(a)through4(c)showthecumulativedistributionofpacket
thescenariosthenumber ofuniquedestinationswas8andthepacket delay experienced by data packets during 1800 seconds of simulated
sizewas64bytes. Thedataflowswerestartedattimesuniformlydis- time, for aworkload of 8, 14, and 20 flows respectively. The higher
tributedbetween20and120seconds(wechosetostarttheflowsafter delay introduced by DSR when relaying data packets is not directly
20secondsofsimulatedtimetogivesometimetotheLinkLayerfor
Number Protocol NumberofHops
determiningthesetofnodesthatareneighborsoftherouters). ofFlows 1 2 3 4 5 6
Theprotocolevaluationsarebasedonthesimulationof20wireless 8 STAR 92.0 7.4 0.2 0.4
nodes in continuous motion for 900 and 1800 seconds of simulated DSR 64.9 31.2 2.6 1.3
time. 14 STAR 82.0 16.0 1.7 0.3
DSR 64.1 26.9 4.0 4.5 0.5
TablesIandIIsummarizethebehaviorofSTARandDSRaccord-
20 STAR 92.6 5.1 2.0 0.3
ingtothesimulatedtime. Thetablesshowthetotalnumberofupdate
DSR 61.9 32.4 5.1 0.3 0.3
packetstransmittedbythenodesandthetotalnumberofdatapackets
delivered to the applications for the three simulated workloads. The TABLEIII
total number of update packets transmitted by routers running STAR DISTRIBUTIONOFDATAPACKETSDELIVEREDACCORDINGTOTHENUMBEROF
varieswiththenumberofchangesinlinkconnectivitywhileDSRgen- HOPSTRAVERSED(900SECONDSOFSIMULATEDTIME).
eratescontrolpacketsbasedonbothvariationofchangesinconnectiv-
ityandthetypeofworkloadinsertedinthenetwork. Routersrunning
Number Protocol NumberofHops
STARgeneratedlessupdatepacketsthanDSRinallsimulatedscenar- ofFlows 1 2 3 4 5 6
ios,thedifferenceincreasedsignificantlywhendatatrafficwasinserted 8 STAR 92.8 6.7 0.3 0.2
inthenetworkfor1800seconds:routersrunningDSRsentfrom100% DSR 64.3 29.2 5.9 0.6
to 600% more update packets than STAR when nodes were moving 14 STAR 86.0 11.4 2.2 0.2 0.2
DSR 71.4 21.8 3.0 3.6 0.2
during1800secondsofsimulatedtime,andfrom35%to400%more
20 STAR 91.1 6.9 1.4 0.5 0.1
update packets when nodes were moving during 900 seconds. Both
DSR 67.5 28.7 3.5 0.2 0.1
STAR and DSR were able to deliver about the same number of data
packets to the applications in the simulated scenarios with 8 and 14 TABLEIV
flows. Whenweincreasedthenumberofsourcesofdatafrom8to20 DISTRIBUTIONOFDATAPACKETSDELIVEREDACCORDINGTOTHENUMBEROF
nodes,whileinsertingthesamenumberofdatapacketsinthenetwork HOPSTRAVERSED(1800SECONDSOFSIMULATEDTIME).
(32packets/sec),weobservedthatSTARwasabletodeliverasmuch
5of5
Wenotethatincaseswhereroutersfailorthenetworkbecomespar-
1
STAR titionedforextendedtimeperiodsthebandwidthconsumedbySTARis
DSR
0.9 muchthesameasinscenariosinwhichnorouterfails,becauseallthat
0.8 musthappenisforupdatesaboutthefailedlinkstounreachabledesti-
0.7 nationstopropagateacrossthenetwork. Incontrast,DSRandseveral
% of data packets 000...456 omwtoehrsessrta-ogcnea-ssdeetrmbyaiannngddwtroiodurthteianucgthiplitrzhoaettoifocaonillesfodwrdoDeusSldtRinc.aoTtniootinnil,uluwesthtoriacstheenwtdhoefluoilmoddpc-aasceutasretchhae
failureofasingledestinationhasinDSRwehavere-runthesimulation
0.3
scenariowith8flowspresentinthenetworkfor1800secondsmaking
0.2 oneofthedestinationsfailafter900secondsofsimulatedtime,routers
0.1 running STAR sent 1088 update packets while routers running DSR
0 sent3043 updatepackets. Theexistenceof asingleflowofdatatoa
0.001 0.01 0.1 1 10 100 1000
delay (secs) destinationthatwasunreachablefor900secondsmadeDSRtogener-
ate 55% more update packets while STARgenerated about the same
(a)
numberofupdates(seeTableII).
1 IV. CONCLUSIONS
STAR
0.9 DSR WehavepresentedSTAR,alink-stateprotocolthatincurslessover-
0.8 head than on-demand routing protocols. Because STARcan be used
withanyclusteringmechanismproposedtodate,theseresultsclearly
0.7
indicatethatSTARisaveryattractiveapproachforroutinginpacket-
% of data packets 000...456 rtaravodedinouucenesed,twsiunocrShkTsaA.sRdPeevfroehrlaoplpesiansmgt-oosrivemeirimhlaepraopdrrtoraotnoutctliyon,lgsthboeapseaenpdsporuonpadcmihstaawnnyecerhevasveeecatroicnrh-s
0.3 anddetermininghowrouteaggregationworksunderLORA.
0.2
REFERENCES
0.1
0 [1] D.BertsekasandR.Gallager,DataNetworks,SecondEdition,Prentice-Hall,Inc.,
0.001 0.01 0.1 1 10 100 1000
delay (secs) 1992.
[2] J.Brochetal,“APerformanceComparisonofMulti-HopWirelessAdHocNetwork
(b) RoutingProtocols,”Proc.ACMMOBICOM98,Dallas,TX,October1998.
[3] J.J.Garcia-Luna-AcevesandJ.Behrens,“Distributed,scalableroutingbasedonvec-
torsoflinkstates,”IEEEJournalonSel.AreasinCommun.,Vol.13,No.8,1995.
1 STAR [4] J.J.Garcia-Luna-Acevesetal.,“WirelessInternetGateways(WINGS),”Proc.IEEE
0.9 DSR MILCOM’97,Monterey,California,November1997.
[5] J.J.Garcia-Luna-AcevesandM.Spohn,“ScalableLink-StateInternetRouting,”Proc.
0.8
IEEEInternationalConferenceonNetworkProtocols(ICNP98),Austin,Texas,Oc-
0.7 tober14-16,1998.
% of data packets 00..56 [[67]] PiDc8a.0lJ2oS.hp1ne1sc–oiUfincnaaantpidopnDrso.,vMIeEdaElDtEzr,,aJ“fatP:nruWoatiorryceol1els9ss9fo6Lr.AANdMapetdiviuemWAircecleessssCanodntMroolb(MileANCe)tawnodrkPihnygs,”-
0.4 IEEEPers.Commun.,Vol.3,No.1,February1996.
[8] J.JubinandJ.Tornow,“TheDARPAPacketRadioNetworkProtocols,”Proceedings
0.3
oftheIEEE,Vol.75,No.1,January1987.
0.2 [9] V.O.K.LiandR.Chang,“ProposedroutingalgorithmsfortheUSArmymobilesub-
scriberequipment(MSE)network,”Proc.IEEEMILCOM’86,Monterey,California,
0.1
0.001 0.01 0.1 delay 1(secs) 10 100 1000 October1986.
[10] J.Moy,“OSPFVersion2,”RFC1583,NetworkWorkingGroup,March1994.
(c) [11] V.ParkandM.Corson,“AHighlyAdaptiveDistributedRoutingAlgorithmforMo-
bileWirelessNetworks,”Proc.IEEEINFOCOM97,Kobe,Japan,April1997.
Fig.4. Cumulativedistributionofpacketdelayexperiencedbydatapacketsduring1800 [12] C. Perkins and P. Bhagwat, “Highly Dynamic Destination-Sequenced Distance-
secondsofsimulatedtimeforaworkloadof(a)8flows,(b)14flows,and(c)20flows. VectorRouting(DSDV)forMobileComputers,”Proc.ACMSIGCOMM94,London,
UK,October1994.
relatedwiththenumberofhopstraversedbythepackets(asshownin [13] C. Perkins, “Ad-Hoc On Demand Distance Vector (AODV) Routing,” draft-ietf-
TablesIIIandIV)butwiththepoorchoiceofsourcerouteswhenthe manet-aodv-00.txt,November1997.
numberofflowsincreasefrom8to20. [14] R. Ramanathan and M. Steenstrup, “Hierarchically-organized, Multihop Mobile
WirelessNetworksforQuality-of-ServiceSupport,”ACMMobileNetworksandAp-
In all the simulation scenarios the number of destinations was set
plications,Vol.3,No.1,pp.101-119,1998.
tojust40%ofthenumber ofnodesinthenetworkinordertobefair
[15] S.MurthyandJ.J.Garcia-Luna-Aceves,“AnEfficientRoutingProtocolforWireless
withDSR.Forthecasesinwhichallthenodesinthenetworkreceive Networks,”ACMMobileNetworksandApplicationsJournal,SpecialissueonRouting
data, STAR would introduce no extra overhead while DSR could be inMobileCommunicationNetworks,1996.
severelypenalized. Itisalsoimportanttonotethelowratioofupdate [16] M.Steenstrup(Ed.),RoutinginCommunicationNetworks,Prentice-Hall,1995.
messages generated by STARcompared tothenumber of changes in [17] TheCMUMonarchProject,“WirelessandMobilityExtensionstons-2-Snapshot
linkconnectivity(TablesIandII). 1.0.0-beta,”URL:http://www.monarch.cs.cmu.edu/cmu-ns.html,August1998.