RFC 6126 - The Babel Routing Protocol

18/2/2016
RFC6126TheBabelRoutingProtocol
IndependentSubmissionJ.Chroboczek
RequestforComments:6126PPS,UniversityofParis7
Category:ExperimentalApril2011
ISSN:20701721
TheBabelRoutingProtocol
Abstract
Babelisaloopavoidingdistancevectorroutingprotocolthatis
robustandefficientbothinordinarywirednetworksandinwireless
meshnetworks.
StatusofThisMemo
ThisdocumentisnotanInternetStandardsTrackspecification;itis
publishedforexamination,experimentalimplementation,and
evaluation.
ThisdocumentdefinesanExperimentalProtocolfortheInternet
community.ThisisacontributiontotheRFCSeries,independently
ofanyotherRFCstream.TheRFCEditorhaschosentopublishthis
documentatitsdiscretionandmakesnostatementaboutitsvaluefor
implementationordeployment.Documentsapprovedforpublicationby
theRFCEditorarenotacandidateforanylevelofInternet
Standard;seeSection2ofRFC5741.
Informationaboutthecurrentstatusofthisdocument,anyerrata,
andhowtoprovidefeedbackonitmaybeobtainedat
http://www.rfceditor.org/info/rfc6126.
CopyrightNotice
Copyright(c)2011IETFTrustandthepersonsidentifiedasthe
documentauthors.Allrightsreserved.
ThisdocumentissubjecttoBCP78andtheIETFTrust'sLegal
ProvisionsRelatingtoIETFDocuments
(http://trustee.ietf.org/licenseinfo)ineffectonthedateof
publicationofthisdocument.Pleasereviewthesedocuments
carefully,astheydescribeyourrightsandrestrictionswithrespect
tothisdocument.
https://tools.ietf.org/html/rfc6126
1/90
18/2/2016
ChroboczekExperimental[Page1]
2/90
18/2/2016
RFC6126TheBabelRoutingProtocolApril2011
TableofContents
1.Introduction.........................3
1.1.Features.........................3
1.2.Limitations.......................4
1.3.SpecificationofRequirements..............4
2.ConceptualDescriptionoftheProtocol............4
2.1.Costs,Metrics,andNeighbourship............5
2.2.TheBellmanFordAlgorithm................5
2.3.TransientLoopsinBellmanFord.............6
2.4.FeasibilityConditions..................6
2.5.SolvingStarvation:SequencingRoutes..........8
2.6.Requests.........................9
2.7.MultipleRouters.....................10
2.8.OverlappingPrefixes...................11
3.ProtocolOperation......................11
3.1.MessageTransmissionandReception............11
3.2.DataStructures.....................12
3.3.AcknowledgedPackets...................15
3.4.NeighbourAcquisition..................15
3.5.RoutingTableMaintenance................17
3.6.RouteSelection.....................21
3.7.SendingUpdates.....................22
3.8.ExplicitRouteRequests.................24
4.ProtocolEncoding......................27
4.1.DataTypes........................28
4.2.PacketFormat......................29
4.3.TLVFormat........................29
4.4.DetailsofSpecificTLVs.................30
5.IANAConsiderations.....................39
6.SecurityConsiderations...................39
7.References..........................40
7.1.NormativeReferences...................40
7.2.InformativeReferences..................40
AppendixA.CostandMetricComputation.............41
A.1.MaintainingHelloHistory................41
A.2.CostComputation.....................42
A.3.MetricComputation....................43
AppendixB.Constants......................43
AppendixC.SimplifiedImplementations.............44
AppendixD.SoftwareAvailability................45
3/90
18/2/2016
4/90
18/2/2016
1.Introduction
Babelisaloopavoidingdistancevectorroutingprotocolthatis
designedtoberobustandefficientbothinnetworksusingprefix
basedroutingandinnetworksusingflatrouting("meshnetworks"),
andbothinrelativelystablewirednetworksandinhighlydynamic
wirelessnetworks.
1.1.Features
ThemainpropertythatmakesBabelsuitableforunstablenetworksis
that,unlikenaivedistancevectorroutingprotocols[RIP],it
stronglylimitsthefrequencyanddurationofroutingpathologies
suchasroutingloopsandblackholesduringreconvergence.Even
afteramobilityeventisdetected,aBabelnetworkusuallyremains
loopfree.Babelthenquicklyreconvergestoaconfigurationthat
preservestheloopfreedomandconnectednessofthenetwork,butis
notnecessarilyoptimal;inmanycases,thisoperationrequiresno
packetexchangesatall.Babelthenslowlyconverges,inatimeon
thescaleofminutes,toanoptimalconfiguration.Thisisachieved
byusingsequencedroutes,atechniquepioneeredbyDestination
SequencedDistanceVectorrouting[DSDV].
Moreprecisely,Babelhasthefollowingproperties:
owheneveryprefixisoriginatedbyatmostonerouter,Babelnever
suffersfromroutingloops;
owhenaprefixisoriginatedbymultiplerouters,Babelmay
occasionallycreateatransientroutingloopforthisparticular
prefix;thisloopdisappearsinatimeproportionaltoits
diameter,andneveragain(uptoanarbitrarygarbagecollection
(GC)time)willtheroutersinvolvedparticipateinaroutingloop
forthesameprefix;
oassumingreasonablepacketlossrates,anyroutingblackholes
thatmayappearafteramobilityeventarecorrectedinatimeat
mostproportionaltothenetwork'sdiameter.
Babelhasprovisionsforlinkqualityestimationandforfairly
arbitrarymetrics.Whenconfiguredsuitably,Babelcanimplement
shortestpathrouting,oritmayuseametricbased,forexample,on
measuredpacketloss.
Babelnodeswillsuccessfullyestablishanassociationevenwhenthey
areconfiguredwithdifferentparameters.Forexample,amobilenode
thatislowonbatterymaychoosetouselargertimeconstants(hello
andupdateintervals,etc.)thananodethathasaccesstowall
5/90
18/2/2016
6/90
18/2/2016
power.Conversely,anodethatdetectshighlevelsofmobilitymay
choosetousesmallertimeconstants.Theabilitytobuildsuch
heterogeneousnetworksmakesBabelparticularlyadaptedtothe
wirelessenvironment.
Finally,Babelisahybridroutingprotocol,inthesensethatitcan
carryroutesformultiplenetworklayerprotocols(IPv4andIPv6),
whicheverprotocoltheBabelpacketsarethemselvesbeingcarried
over.
1.2.Limitations
Babelhastwolimitationsthatmakeitunsuitableforuseinsome
environments.First,Babelreliesonperiodicroutingtableupdates
ratherthanusingareliabletransport;hence,inlarge,stable
networksitgeneratesmoretrafficthanprotocolsthatonlysend
updateswhenthenetworktopologychanges.Insuchnetworks,
protocolssuchasOSPF[OSPF],ISIS[ISIS],ortheEnhanced
InteriorGatewayRoutingProtocol(EIGRP)[EIGRP]mightbemore
suitable.
Second,Babeldoesimposeaholdtimewhenaprefixisretracted
(Section3.5.5).Whilethisholdtimedoesnotapplytotheexact
prefixbeingretracted,andhencedoesnotpreventfastreconvergence
shoulditbecomeavailableagain,itdoesapplytoanyshorterprefix
thatcoversit.Hence,ifapreviouslydeaggregatedprefixbecomes
aggregated,itwillbeunreachableforafewminutes.Thismakes
Babelunsuitableforuseinmobilenetworksthatimplementautomatic
prefixaggregation.
1.3.SpecificationofRequirements
Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",
"SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"inthis
documentaretobeinterpretedasdescribedin[RFC2119].
2.ConceptualDescriptionoftheProtocol
Babelisamostlyloopfreedistancevectorprotocol:itisbasedon
theBellmanFordprotocol,justlikethevenerableRIP[RIP],but
includesanumberofrefinementsthateitherpreventloopformation
altogether,orensurethataloopdisappearsinatimelymannerand
doesn'tformagain.
Conceptually,BellmanFordisexecutedinparallelforeverysource
ofroutinginformation(destinationofdatatraffic).Inthe
followingdiscussion,wefixasourceS;thereaderwillrecallthat
thesamealgorithmisexecutedforallsources.
7/90
18/2/2016
8/90
18/2/2016
2.1.Costs,Metrics,andNeighbourship
Asmanyroutingalgorithms,Babelcomputescostsoflinksbetweenany
twoneighbouringnodes,abstractvaluesattachedtotheedgesbetween
twonodes.WewriteC(A,B)forthecostoftheedgefromnodeAto
nodeB.
Givenaroutebetweenanytwonodes,themetricoftherouteisthe
sumofthecostsofalltheedgesalongtheroute.Thegoalofthe
routingalgorithmistocompute,foreverysourceS,thetreeofthe
routesoflowestmetrictoS.
Costsandmetricsneednotbeintegers.Ingeneral,theycanbe
valuesinanyalgebrathatsatisfiestwofairlygeneralconditions
(Section3.5.2).
ABabelnodeperiodicallybroadcastsHellomessagestoallofits
neighbours;italsoperiodicallysendsanIHU("IHeardYou")message
toeveryneighbourfromwhichithasrecentlyheardaHello.From
theinformationderivedfromHelloandIHUmessagesreceivedfromits
neighbourB,anodeAcomputesthecostC(A,B)ofthelinkfromAto
B.
2.2.TheBellmanFordAlgorithm
EverynodeAmaintainstwopiecesofdata:itsestimateddistanceto
S,writtenD(A),anditsnexthoproutertoS,writtenNH(A).
Initially,D(S)=0,D(A)isinfinite,andNH(A)isundefined.
Periodically,everynodeBsendstoallofitsneighboursaroute
update,amessagecontainingD(B).WhenaneighbourAofBreceives
therouteupdate,itcheckswhetherBisitsselectednexthop;if
thatisthecase,thenNH(A)issettoB,andD(A)issettoC(A,B)
+D(B).Ifthatisnotthecase,thenAcomparesC(A,B)+D(B)to
itscurrentvalueofD(A).Ifthatvalueissmaller,meaningthat
thereceivedupdateadvertisesaroutethatisbetterthanthe
currentlyselectedroute,thenNH(A)issettoB,andD(A)issetto
C(A,B)+D(B).
Anumberofrefinementstothisalgorithmarepossible,andareused
byBabel.Inparticular,convergencespeedmaybeincreasedby
sendingunscheduled"triggeredupdates"wheneveramajorchangein
thetopologyisdetected,inadditiontotheregular,scheduled
updates.Additionally,anodemaymaintainanumberofalternate
routes,whicharebeingadvertisedbyneighboursotherthanits
selectedneighbour,andwhichcanbeusedimmediatelyiftheselected
routeweretofail.
9/90
18/2/2016
10/90
18/2/2016
2.3.TransientLoopsinBellmanFord
ItiswellknownthatanaiveapplicationofBellmanFordto
distributedroutingcancausetransientloopsafteratopology
change.Considerforexamplethefollowingdiagram:
B
1/|
1/|
SA|1
\|
1\|
C
Afterconvergence,D(B)=D(C)=2,withNH(B)=NH(C)=A.
SupposenowthatthelinkbetweenSandAfails:
B
1/|
/|
SA|1
\|
1\|
C
Whenitdetectsthefailureofthelink,AswitchesitsnexthoptoB
(whichisstilladvertisingaroutetoSwithmetric2),and
advertisesametricequalto3,andthenadvertisesanewroutewith
metric3.Thisprocessofnodeschangingselectedneighboursand
increasingtheirmetriccontinuesuntiltheadvertisedmetricreaches
"infinity",avaluelargerthanallthemetricsthattherouting
protocolisabletocarry.
2.4.FeasibilityConditions
BellmanFordisaveryrobustalgorithm:itsconvergenceproperties
arepreservedwhenroutersdelayrouteacquisitionorwhenthey
discardsomeupdates.Babelroutersdiscardreceivedroute
announcementsunlesstheycanprovethatacceptingthemcannot
possiblycausearoutingloop.
Moreformally,wedefineaconditionoverrouteannouncements,known
asthefeasibilitycondition,thatguaranteestheabsenceofrouting
loopswheneverallroutersignorerouteupdatesthatdonotsatisfy
thefeasibilitycondition.Ineffect,thismakesBellmanFordintoa
familyofroutingalgorithms,parameterisedbythefeasibility
condition.
11/90
18/2/2016
12/90
18/2/2016
Manydifferentfeasibilityconditionsarepossible.Forexample,BGP
canbemodelledasbeingadistancevectorprotocolwitha(rather
drastic)feasibilitycondition:aroutingupdateisonlyaccepted
whenthereceivingnode'sASnumberisnotincludedintheupdate's
ASPathattribute(notethatBGP'sfeasibilityconditiondoesnot
ensuretheabsenceoftransitory"microloops"duringreconvergence).
Anothersimplefeasibilitycondition,usedinDestinationSequenced
DistanceVector(DSDV)routing[DSDV]andinAdhocOnDemand
DistanceVector(AODV)routing,stemsfromthefollowingobservation:
aroutingloopcanonlyariseafterarouterhasswitchedtoaroute
withalargermetricthantheroutethatithadpreviouslyselected.
Hence,onecoulddecidethatarouteisfeasibleonlywhenitsmetric
atthelocalnodewouldbenolargerthanthemetricofthecurrently
selectedroute,i.e.,anannouncementcarryingametricD(B)is
acceptedbyAwhenC(A,B)+D(B)<=D(A).Ifallroutersobeythis
constraint,thenthemetricateveryrouterisnonincreasing,andthe
followinginvariantisalwayspreserved:ifAhasselectedBasits
successor,thenD(B)<D(A),whichimpliesthattheforwardinggraph
isloopfree.
Babelusesaslightlymorerefinedfeasibilitycondition,usedin
EIGRP[DUAL].GivenarouterA,definethefeasibilitydistanceof
A,writtenFD(A),asthesmallestmetricthatAhaseveradvertised
forStoanyofitsneighbours.AnupdatesentbyaneighbourBofA
isfeasiblewhenthemetricD(B)advertisedbyBisstrictlysmaller
thanA'sfeasibilitydistance,i.e.,whenD(B)<FD(A).
Itiseasytoseethatthislatterconditionisnomorerestrictive
thanDSDVfeasibility.SupposethatnodeAobeysDSDVfeasibility;
thenD(A)isnonincreasing,henceatalltimesD(A)<=FD(A).
SupposenowthatAreceivesaDSDVfeasibleupdatethatadvertisesa
metricD(B).SincetheupdateisDSDVfeasible,C(A,B)+D(B)<=
D(A),henceD(B)<D(A),andsinceD(A)<=FD(A),D(B)<FD(A).
Toseethatitisstrictlylessrestrictive,considerthefollowing
diagram,whereAhasselectedtheroutethroughB,andD(A)=FD(A)=
2.SinceD(C)=1<FD(A),thealternateroutethroughCisfeasible
forA,althoughitsmetricC(A,C)+D(C)=5islargerthanthatof
thecurrentlyselectedroute:
B
1/\1
/\
SA
\/
1\/4
C
13/90
18/2/2016
14/90
18/2/2016
Toshowthatthisfeasibilityconditionstillguaranteesloop
freedom,recallthatatthetimewhenAacceptsanupdatefromB,the
metricD(B)announcedbyBisnosmallerthanFD(B);sinceitis
smallerthanFD(A),atthatpointintimeFD(B)<FD(A).Sincethis
propertyispreservedwhenAsendsupdates,itremainstrueatall
times,whichensuresthattheforwardinggraphhasnoloops.
2.5.SolvingStarvation:SequencingRoutes
Obviously,thefeasibilityconditionsdefinedabovecausestarvation
whenarouterrunsoutoffeasibleroutes.Considerthefollowing
diagram,wherebothAandBhaveselectedthedirectroutetoS:
A
1/|D(A)=1
/|FD(A)=1
S|1
\|D(B)=2
2\|FD(B)=2
B
SupposenowthatthelinkbetweenAandSbreaks:
A
|
|FD(A)=1
S|1
\|D(B)=2
2\|FD(B)=2
B
TheonlyrouteavailablefromAtoS,theonethatgoesthroughB,is
notfeasible:Asuffersfromaspuriousstarvation.
Atthispoint,thewholenetworkmustberebootedinordertosolve
thestarvation;thisisessentiallywhatEIGRPdoeswhenitperforms
aglobalsynchronisationofalltheroutersinthenetworkwiththe
source(the"active"phaseofEIGRP).
Babelreactstostarvationinalessdrasticmanner,byusing
sequencedroutes,atechniqueintroducedbyDSDVandadoptedbyAODV.
Inadditiontoametric,everyroutecarriesasequencenumber,a
nondecreasingintegerthatispropagatedunchangedthroughthe
networkandisonlyeverincrementedbythesource;apair(s,m),
wheresisasequencenumberandmametric,iscalledadistance.
Areceivedupdateisfeasiblewheneitheritismorerecentthanthe
feasibilitydistancemaintainedbythereceivingnode,oritis
15/90
18/2/2016
16/90
18/2/2016
equallyrecentandthemetricisstrictlysmaller.Moreformally,if
FD(A)=(s,m),thenanupdatecarryingthedistance(s',m')is
feasiblewheneithers'>s,ors=s'andm'<m.
AssumingthesequencenumberofSis137,thediagramabovebecomes:
A
|
|FD(A)=(137,1)
S|1
\|D(B)=(137,2)
2\|FD(B)=(137,2)
B
AfterSincreasesitssequencenumber,andthenewsequencenumberis
propagatedtoB,wehave:
A
|
|FD(A)=(137,1)
S|1
\|D(B)=(138,2)
2\|FD(B)=(138,2)
B
atwhichpointtheroutethroughBbecomesfeasibleagain.
Notethatwhilesequencenumbersareusedfordetermining
feasibility,theyarenotnecessarilyusedinrouteselection:anode
willnormallyignorethesequencenumberwhenselectingaroute
(Section3.6).
2.6.Requests
InDSDV,thesequencenumberofasourceisincreasedperiodically.
Aroutebecomesfeasibleagainafterthesourceincreasesits
sequencenumber,andthenewsequencenumberispropagatedthrough
thenetwork,whichmay,ingeneral,requireasignificantamountof
time.
Babeltakesadifferentapproach.Whenanodedetectsthatitis
sufferingfromapotentiallyspuriousstarvation,itsendsan
explicitrequesttothesourceforanewsequencenumber.This
requestisforwardedhopbyhoptothesource,withnoregardtothe
feasibilitycondition.Uponreceivingtherequest,thesource
increasesitssequencenumberandbroadcastsanupdate,whichis
forwardedtotherequestingnode.
17/90
18/2/2016
18/90
18/2/2016
Notethatafterachangeinnetworktopologynotallsuchrequests
will,ingeneral,reachthesource,assomewillbesentoverlinks
thatarenowbroken.However,ifthenetworkisstillconnected,
thenatleastoneamongthenodessufferingfromspuriousstarvation
hasan(unfeasible)routetothesource;hence,intheabsenceof
packetloss,atleastonesuchrequestwillreachthesource.
(Resendingrequestsasmallnumberoftimescompensatesforpacket
loss.)
Sincerequestsareforwardedwithnoregardtothefeasibility
condition,theymay,ingeneral,becaughtinaforwardingloop;this
isavoidedbyhavingnodesperformduplicatedetectionforthe
requeststhattheyforward.
2.7.MultipleRouters
Theabovediscussionassumesthateveryprefixisoriginatedbya
singlerouter.Inrealnetworks,however,itisoftennecessaryto
haveasingleprefixoriginatedbymultiplerouters;forexample,the
defaultroutewillbeoriginatedbyalloftheedgeroutersofa
routingdomain.
Sincesynchronisingsequencenumbersbetweendistinctroutersis
problematic,Babeltreatsroutesforthesameprefixasdistinct
entitieswhentheyareoriginatedbydifferentrouters:everyroute
announcementcarriestherouteridofitsoriginatingrouter,and
feasibilitydistancesarenotmaintainedperprefix,butpersource,
whereasourceisapairofarouteridandaprefix.Ineffect,
Babelguaranteesloopfreedomfortheforwardinggraphtoevery
source;sincetheunionofmultipleacyclicgraphsisnotingeneral
acyclic,Babeldoesnotingeneralguaranteeloopfreedomwhena
prefixisoriginatedbymultiplerouters,butanyloopswillbe
brokeninatimeatmostproportionaltothediameteroftheloop
assoonasanupdatehas"gonearound"theroutingloop.
Considerforexamplethefollowingdiagram,whereAhasselectedthe
defaultroutethroughS,andBhasselectedtheonethroughS':
111
::/0SABS'::/0
Supposethatbothdefaultroutesfailatthesametime;thennothing
preventsAfromswitchingtoB,andBsimultaneouslyswitchingtoA.
However,assoonasAhassuccessfullyadvertisedthenewroutetoB,
theroutethroughAwillbecomeunfeasibleforB.Conversely,as
soonasBwillhaveadvertisedtheroutethroughA,theroutethrough
BwillbecomeunfeasibleforA.
19/90
18/2/2016
20/90
18/2/2016
Ineffect,theroutingloopdisappearsatthelatestwhenrouting
informationhasgonearoundtheloop.Sincethisprocesscanbe
delayedbylostpackets,Babelmakescertaineffortstoensurethat
updatesaresentreliablyafterarouteridchange.
Additionally,aftertheroutershaveadvertisedthetworoutes,both
sourceswillbeintheirsourcetables,whichwillpreventthemfrom
everagainparticipatinginaroutingloopinvolvingroutesfromS
andS'(uptothesourceGCtime,which,availablememorypermitting,
canbesettoarbitrarilylargevalues).
2.8.OverlappingPrefixes
Intheabovediscussion,wehaveassumedthatallprefixesare
disjoint,asisthecaseinflat("mesh")routing.Inpractice,
however,prefixesmayoverlap:forexample,thedefaultroute
overlapswithalloftheroutespresentinthenetwork.
Afteraroutefails,itisnotcorrectingeneraltoswitchtoa
routethatsubsumesthefailedroute.Considerforexamplethe
followingconfiguration:
11
::/0ABC
SupposethatnodeCfails.IfBforwardspacketsdestinedtoCby
followingthedefaultroute,aroutingloopwillform,andpersist
untilAlearnsofB'sretractionofthedirectroutetoC.Babel
avoidsthispitfallbymaintainingan"unreachable"routeforafew
minutesafterarouteisretracted;thetimeforwhichsucharoute
mustbemaintainedshouldbetheworstcasepropagationtimeofthe
retractionoftheroutetoC.
3.ProtocolOperation
EveryBabelspeakerisassignedarouterid,whichisanarbitrary
stringof8octetsthatisassumeduniqueacrosstheroutingdomain.
WesuggestthatrouteridsshouldbeassignedinmodifiedEUI64
format[ADDRARCH].(Asamatteroffact,theprotocolencodingis
slightlymorecompactwhenrouteridsareassignedinthesamemanner
astheIPv6layerassignshostIDs.)
3.1.MessageTransmissionandReception
BabelprotocolpacketsaresentinthebodyofaUDPdatagram.Each
BabelpacketconsistsofoneormoreTLVs.
21/90
18/2/2016
22/90
18/2/2016
ThesourceaddressofaBabelpacketisalwaysaunicastaddress,
linklocalinthecaseofIPv6.Babelpacketsmaybesenttoawell
known(linklocal)multicastaddress(thisistheusualcase)ortoa
(linklocal)unicastaddress.Innormaloperation,aBabelspeaker
sendsbothmulticastandunicastpacketstoitsneighbours.
WiththeexceptionofHelloTLVsandacknowledgements,allBabelTLVs
canbesenttoeitherunicastormulticastaddresses,andtheir
semanticsdoesnotdependonwhetherthedestinationwasaunicastor
multicastaddress.Hence,aBabelspeakerdoesnotneedtodetermine
thedestinationaddressofapacketthatitreceivesinorderto
interpretit.
AmoderateamountofjitterisappliedtopacketssentbyaBabel
speaker:outgoingTLVsarebufferedandSHOULDbesentwithasmall
randomdelay.Thisisdonefortwopurposes:itavoids
synchronisationofmultipleBabelspeakersacrossanetwork[JITTER],
anditallowsfortheaggregationofmultipleTLVsintoasingle
packet.
Theexactdelayandamountofjitterappliedtoapacketdependson
whetheritcontainsanyurgentTLVs.AcknowledgementTLVsMUSTbe
sentbeforethedeadlinespecifiedinthecorrespondingrequest.The
particularclassofupdatesspecifiedinSection3.7.2MUSTbesent
inatimelymanner.TheparticularclassofrequestandupdateTLVs
specifiedinSection3.8.2SHOULDbesentinatimelymanner.
3.2.DataStructures
EveryBabelspeakermaintainsanumberofdatastructures.
3.2.1.SequenceNumber
Anode'ssequencenumberisa16bitintegerthatisincludedin
routeupdatessentforroutesoriginatedbythisnode.Anode
incrementsitssequencenumber(modulo2^16)wheneveritreceivesa
requestforanewsequencenumber(Section3.8.1.2).
AnodeSHOULDNOTincrementitssequencenumber(seqno)
spontaneously,sinceincreasingseqnosmakesitlesslikelythat
othernodeswillhavefeasiblealternaterouteswhentheirselected
routesfail.
3.2.2.TheInterfaceTable
Theinterfacetablecontainsthelistofinterfacesonwhichthenode
speakstheBabelprotocol.Everyinterfacetableentrycontainsthe
interface'sHelloseqno,a16bitintegerthatissentwitheach
23/90
18/2/2016
24/90
18/2/2016
HelloTLVonthisinterfaceandisincremented(modulo2^16)whenever
aHelloissent.(Notethataninterface'sHelloseqnoisunrelated
tothenode'sseqno.)
Therearetwotimersassociatedwitheachinterfacetableentry
theHellotimer,whichgovernsthesendingofperiodicHelloandIHU
packets,andtheupdatetimer,whichgovernsthesendingofperiodic
routeupdates.
3.2.3.TheNeighbourTable
Theneighbourtablecontainsthelistofallneighbouringinterfaces
fromwhichaBabelpackethasbeenrecentlyreceived.Theneighbour
tableisindexedbypairsoftheform(interface,address),andevery
neighbourtableentrycontainsthefollowingdata:
othelocalnode'sinterfaceoverwhichthisneighbourisreachable;
otheaddressoftheneighbouringinterface;
oahistoryofrecentlyreceivedHellopacketsfromthisneighbour;
thiscan,forexample,beasequenceofnbits,forsomesmall
valuen,indicatingwhichofthenhellosmostrecentlysentby
thisneighbourhavebeenreceivedbythelocalnode;
othe"transmissioncost"valuefromthelastIHUpacketreceived
fromthisneighbour,orFFFFhexadecimal(infinity)iftheIHU
holdtimerforthisneighbourhasexpired;
otheneighbour'sexpectedHellosequencenumber,anintegermodulo
2^16.
Therearetwotimersassociatedwitheachneighbourentrythe
hellotimer,whichisinitialisedfromtheintervalvaluecarriedby
HelloTLVs,andtheIHUtimer,whichisinitialisedtoasmall
multipleoftheintervalcarriedinIHUTLVs.
NotethattheneighbourtableisindexedbyIPaddresses,notby
routerids:neighbourshipisarelationshipbetweeninterfaces,not
betweennodes.Therefore,twonodeswithmultipleinterfacescan
participateinmultipleneighbourshiprelationships,afairlycommon
situationwhenwirelessnodeswithmultipleradiosareinvolved.
3.2.4.TheSourceTable
Thesourcetableisusedtorecordfeasibilitydistances.Itis
indexedbytriplesoftheform(prefix,plen,routerid),andevery
sourcetableentrycontainsthefollowingdata:
25/90
18/2/2016
26/90
18/2/2016
otheprefix(prefix,plen),whereplenistheprefixlength,that
thisentryappliesto;
otherouteridofarouteroriginatingthisprefix;
oapair(seqno,metric),thissource'sfeasibilitydistance.
Thereisonetimerassociatedwitheachentryinthesourcetable
thesourcegarbagecollectiontimer.Itisinitialisedtoatimeon
theorderofminutesandresetasspecifiedinSection3.7.3.
3.2.5.TheRouteTable
Theroutetablecontainstheroutesknowntothisnode.Itis
indexedbytriplesoftheform(prefix,plen,neighbour),andevery
routetableentrycontainsthefollowingdata:
othesource(prefix,plen,routerid)forwhichthisrouteis
advertised;
otheneighbourthatadvertisedthisroute;
othemetricwithwhichthisroutewasadvertisedbytheneighbour,
orFFFFhexadecimal(infinity)forarecentlyretractedroute;
othesequencenumberwithwhichthisroutewasadvertised;
othenexthopaddressofthisroute;
oabooleanflagindicatingwhetherthisrouteisselected,i.e.,
whetheritiscurrentlybeingusedforforwardingandisbeing
advertised.
Thereisonetimerassociatedwitheachroutetableentrythe
routeexpirytimer.Itisinitialisedandresetasspecifiedin
Section3.5.4.
3.2.6.TheTableofPendingRequests
Thetableofpendingrequestscontainsalistofseqnorequeststhat
thelocalnodehassent(eitherbecausetheyhavebeenoriginated
locally,orbecausetheywereforwarded)andtowhichnoreplyhas
beenreceivedyet.Thistableisindexedbyprefixes,andevery
entryinthistablecontainsthefollowingdata:
otheprefix,routerid,andseqnobeingrequested;
27/90
18/2/2016
28/90
18/2/2016
otheneighbour,ifany,onbehalfofwhichweareforwardingthis
request;
oasmallintegerindicatingthenumberoftimesthatthisrequest
willberesentifitremainsunsatisfied.
Thereisonetimerassociatedwitheachpendingrequest;itgoverns
boththeresendingofrequestsandtheirexpiry.
3.3.AcknowledgedPackets
ABabelspeakermayrequestthatanyneighbourreceivingagiven
packetreplywithanexplicitacknowledgementwithinagiventime.
Whiletheuseofacknowledgementrequestsisoptional,everyBabel
speakerMUSTbeabletoreplytosucharequest.
AnacknowledgementMUSTbesenttoaunicastdestination.Onthe
otherhand,acknowledgementrequestsmaybesenttoeitherunicastor
multicastdestinations,inwhichcasetheyrequestanacknowledgement
fromallofthereceivingnodes.
Whentorequestacknowledgementsisamatteroflocalpolicy;the
simpleststrategyistoneverrequestacknowledgementsandtorelyon
periodicupdatestoensurethatanyreachableroutesareeventually
propagatedthroughouttheroutingdomain.Forincreasedefficiency,
wesuggestthatacknowledgedpacketsshouldbeusedinordertosend
urgentupdates(Section3.7.2)whenthenumberofneighboursona
giveninterfaceissmall.SinceBabelisdesignedtodealgracefully
withpacketlossonunreliablemedia,sendingallpacketswith
acknowledgementrequestsisnotnecessary,andnotevenrecommended,
astheacknowledgementscauseadditionaltrafficandmayforce
additionalAddressResolutionProtocol(ARP)orNeighbourDiscovery
exchanges.
3.4.NeighbourAcquisition
NeighbouracquisitionistheprocessbywhichaBabelnodediscovers
thesetofneighboursheardovereachofitsinterfacesand
ascertainsbidirectionalreachability.Onunreliablemedia,
neighbouracquisitionadditionallyprovidessomestatisticsthatMAY
beusedinlinkqualitycomputation.
3.4.1.ReverseReachabilityDetection
EveryBabelnodesendsperiodicHellosovereachofitsinterfaces.
EachHelloTLVcarriesanincreasing(modulo2^16)sequencenumber
andtheintervalbetweensuccessiveperiodicpacketssentonthis
particularinterface.
29/90
18/2/2016
30/90
18/2/2016
InadditiontotheperiodicHellopackets,anodeMAYsend
unscheduledHellopackets,e.g.,toacceleratelinkcostestimation
whenanewneighbourisdiscovered,orwhenlinkconditionshave
suddenlychanged.
AnodeMAYchangeitsHellointerval.TheHellointervalMAYbe
decreasedatanytime;itSHOULDNOTbeincreased,exceptimmediately
beforesendingaHellopacket.(Equivalently,anodeSHOULDsendan
unscheduledHelloimmediatelyafterincreasingitsHellointerval.)
HowtodealwithreceivedHelloTLVsandwhatstatisticstomaintain
areconsideredlocalimplementationmatters;typically,anodewill
maintainsomesortofhistoryofrecentlyreceivedHellos.A
possiblealgorithmisdescribedinAppendixA.1.
AfterreceivingaHello,ordeterminingthatithasmissedone,the
noderecomputestheassociation'scost(Section3.4.3)andrunsthe
routeselectionprocedure(Section3.6).
3.4.2.BidirectionalReachabilityDetection
Inordertoestablishbidirectionalreachability,everynodesends
periodicIHU("IHeardYou")TLVstoeachofitsneighbours.Since
IHUscarryanexplicitintervalvalue,theyMAYbesentlessoften
thanHellosinordertoreducetheamountofroutingtrafficindense
networks;inparticular,theySHOULDbesentlessoftenthanHellos
overlinkswithlittlepacketloss.WhileIHUsareconceptually
unicast,theySHOULDbesenttoamulticastaddressinordertoavoid
anARPorNeighbourDiscoveryexchangeandtoaggregatemultipleIHUs
inasinglepacket.
InadditiontotheperiodicIHUs,anodeMAY,atanytime,sendan
unscheduledIHUpacket.ItMAYalso,atanytime,decreaseitsIHU
interval,anditMAYincreaseitsIHUintervalimmediatelybefore
sendinganIHU.
EveryIHUTLVcontainstwopiecesofdata:thelink'srxcost
(receptioncost)fromthesender'sperspective,usedbytheneighbour
forcomputinglinkcosts(Section3.4.3),andtheintervalbetween
periodicIHUpackets.AnodereceivinganIHUupdatesthevalueof
thesendingneighbour'stxcost(transmissioncost),fromits
perspective,tothevaluecontainedintheIHU,andresetsthis
neighbour'sIHUtimertoasmallmultipleofthevaluereceivedin
theIHU.
Whenaneighbour'sIHUtimerexpires,itstxcostissettoinfinity.
31/90
18/2/2016
32/90
18/2/2016
Afterupdatinganeighbour'stxcost,thereceivingnoderecomputes
theneighbour'scost(Section3.4.3)andrunstherouteselection
procedure(Section3.6).
3.4.3.CostComputation
Aneighbourshipassociation'slinkcostiscomputedfromthevalues
maintainedintheneighbourtablenamely,thestatisticskeptin
theneighbourtableaboutthereceptionofHellos,andthetxcost
computedfromreceivedIHUpackets.
Foreveryneighbour,aBabelnodecomputesavalueknownasthis
neighbour'srxcost.ThisvalueisusuallyderivedfromtheHello
history,whichmaybecombinedwithotherdata,suchasstatistics
maintainedbythelinklayer.Therxcostissenttoaneighbourin
eachIHU.
Howthetxcostandrxcostarecombinedinordertocomputealink's
costisamatteroflocalpolicy;asfarasBabel'scorrectnessis
concerned,onlythefollowingconditionsMUSTbesatisfied:
othecostisstrictlypositive;
oifnohelloswerereceivedrecently,thenthecostisinfinite;
oifthetxcostisinfinite,thenthecostisinfinite.
Notethatwhilethisdocumentdoesnotconstraincostcomputationany
further,notallcostcomputationstrategieswillgivegoodresults.
Wegiveafewexamplesofstrategiesforcomputingalink'scostthat
areknowntoworkwellinpracticeinAppendixA.2.
3.5.RoutingTableMaintenance
Conceptually,aBabelupdateisaquintuple(prefix,plen,routerid,
seqno,metric),where(prefix,plen)istheprefixforwhicharoute
isbeingadvertised,routeridistherouteridoftherouter
originatingthisupdate,seqnoisanondecreasing(modulo2^16)
integerthatcarriestheoriginatingrouterseqno,andmetricisthe
announcedmetric.
Beforebeingaccepted,anupdateischeckedagainstthefeasibility
condition(Section3.5.1),whichensuresthattheroutedoesnot
createaroutingloop.Ifthefeasibilityconditionisnot
satisfied,theupdateiseitherignoredortreatedasaretraction,
dependingonsomeotherconditions(Section3.5.4).Ifthe
feasibilityconditionissatisfied,thentheupdatecannotpossibly
causearoutingloop,andtheupdateisaccepted.
33/90
18/2/2016
34/90
18/2/2016
3.5.1.TheFeasibilityCondition
Thefeasibilityconditionisappliedtoallreceivedupdates.The
feasibilityconditioncomparesthemetricinthereceivedupdatewith
themetricsoftheupdatespreviouslysentbythereceivingnode;
updateswithfinitemetricslargeenoughtocausealoopare
discarded.
Afeasibilitydistanceisapair(seqno,metric),whereseqnoisan
integermodulo2^16andmetricisapositiveinteger.Feasibility
distancesarecomparedlexicographically,withthefirstcomponent
inverted:wesaythatadistance(seqno,metric)isstrictlybetter
thanadistance(seqno',metric'),written
(seqno,metric)<(seqno',metric')
when
seqno>seqno'or(seqno=seqno'andmetric<metric')
wheresequencenumbersarecomparedmodulo2^16.
Givenasource(p,plen,id),anode'sfeasibilitydistanceforthis
sourceistheminimum,accordingtotheorderingdefinedabove,of
thedistancesofallthefiniteupdateseversentbythisparticular
nodefortheprefix(p,plen)carryingtherouteridid.Feasibility
distancesaremaintainedinthesourcetable;theexactprocedureis
giveninSection3.7.3.
Areceivedupdateisfeasiblewheneitheritisaretraction(its
metricisFFFFhexadecimal),ortheadvertiseddistanceisstrictly
better,inthesensedefinedabove,thanthefeasibilitydistancefor
thecorrespondingsource.Moreprecisely,arouteadvertisement
carryingthequintuple(prefix,plen,routerid,seqno,metric)is
feasibleifoneofthefollowingconditionsholds:
ometricisinfinite;or
onoentryexistsinthesourcetableindexedby(id,prefix,plen);
or
oanentry(prefix,plen,routerid,seqno',metric')existsinthe
sourcetable,andeither
*seqno'<seqnoor
*seqno=seqno'andmetric<metric'.
35/90
18/2/2016
36/90
18/2/2016
Notethatthefeasibilityconditionconsidersthemetricadvertised
bytheneighbour,nottheroute'smetric;hence,afluctuationina
neighbour'scostcannotrenderaselectedrouteunfeasible.
3.5.2.MetricComputation
Aroute'smetriciscomputedfromthemetricadvertisedbythe
neighbourandtheneighbour'slinkcost.Justlikecostcomputation,
metriccomputationisconsideredalocalpolicymatter;asfaras
Babelisconcerned,thefunctionM(c,m)usedforcomputingametric
fromalocallycomputedlinkcostandthemetricadvertisedbya
neighbourMUSTonlysatisfythefollowingconditions:
oifcisinfinite,thenM(c,m)isinfinite;
oMisstrictlymonotonic:M(c,m)>m.
Additionally,themetricSHOULDsatisfythefollowingcondition:
oMisisotonic:ifm<=m',thenM(c,m)<=M(c,m').
Notethatwhilestrictmonotonicityisessentialtotheintegrityof
thenetwork(persistentroutingloopsmayappearifitisnot
satisfied),isotonicityisnot:ifitisnotsatisfied,Babelwill
stillconvergetoalocallyoptimalroutingtable,butmightnot
reachaglobaloptimum(infact,suchaglobaloptimummaynoteven
exist).
Aswithcostcomputation,notallstrategiesforcomputingroute
metricswillgivegoodresults.Inparticular,somemetricsaremore
likelythanotherstoleadtoroutinginstabilities(routeflapping).
InAppendixA.3,wegiveanumberofexamplesofstrictlymonotonic,
isotonicroutingmetricsthatareknowntoworkwellinpractice.
3.5.3.EncodingofUpdates
Inalargenetwork,thebulkofBabeltrafficconsistsofroute
updates;hence,somecarehasbeengiventoencodingthem
efficiently.AnUpdateTLVitselfonlycontainstheprefix,seqno,
andmetric,whilethenexthopisderivedeitherfromthenetwork
layersourceaddressofthepacketorfromanexplicitNextHopTLV
inthesamepacket.Therouteridisderivedfromaseparate
RouterIdTLVinthesamepacket,whichoptimisesthecasewhen
multipleupdatesaresentwiththesamerouterid.
Additionally,aprefixoftheadvertisedprefixcanbeomittedinan
UpdateTLV,inwhichcaseitiscopiedfromapreviousUpdateTLVin
thesamepacketthisisknownasaddresscompression[PACKETBB].
37/90
18/2/2016
38/90
18/2/2016
Finally,asaspecialoptimisationforthecasewhenarouterid
coincideswiththeinterfaceidpartofanIPv6address,the
routeridcanoptionallybederivedfromtheloworderbitsofthe
advertisedprefix.
TheencodingofupdatesisdescribedindetailinSection4.4.
3.5.4.RouteAcquisition
WhenaBabelnodereceivesanupdate(id,prefix,seqno,metric)from
aneighbourneighwithalinkcostvalueequaltocost,itchecks
whetheritalreadyhasaroutingtableentryindexedby(neigh,id,
prefix).
Ifnosuchentryexists:
oiftheupdateisunfeasible,itisignored;
oifthemetricisinfinite(theupdateisaretraction),theupdate
isignored;
ootherwise,anewroutetableentryiscreated,indexedby(neigh,
id,prefix),withseqnoequaltoseqnoandanadvertisedmetric
equaltothemetriccarriedbytheupdate.
Ifsuchanentryexists:
oiftheentryiscurrentlyinstalledandtheupdateisunfeasible,
thenthebehaviourdependsonwhethertherouteridsofthetwo
entriesmatch.Iftherouteridsaredifferent,theupdateis
treatedasthoughitwerearetraction(i.e.,asthoughthemetric
wereFFFFhexadecimal).Iftherouteridsareequal,theupdate
isignored;
ootherwise(i.e.,ifeithertheupdateisfeasibleortheentryis
notcurrentlyinstalled),thentheentry'ssequencenumber,
advertisedmetric,metric,androuteridareupdatedand,unless
theadvertisedmetricisinfinite,theroute'sexpirytimeris
resettoasmallmultipleoftheIntervalvalueincludedinthe
update.
Whenaroute'sexpirytimertriggers,thebehaviourdependson
whethertheroute'smetricisfinite.Ifthemetricisfinite,itis
settoinfinityandtheexpirytimerisreset.Ifthemetricis
alreadyinfinite,therouteisflushedfromtheroutetable.
Aftertheroutingtableisupdated,therouteselectionprocedure
(Section3.6)isrun.
39/90
18/2/2016
40/90
18/2/2016
3.5.5.HoldTime
Whenaprefixpisretracted,becauseallroutesareunfeasible,too
old,orhaveaninfinitemetric,andashorterprefixp'thatcovers
pisreachable,p'cannotingeneralbeusedforroutingpackets
destinedtopwithoutrunningtheriskofcreatingaroutingloop
(Section2.8).
Toavoidthisissue,wheneveraprefixisretracted,aroutingtable
entrywithinfinitemetricismaintainedasdescribedin
Section3.5.4above,andpacketsdestinedforthatprefixMUSTNOTbe
forwardedbyfollowingarouteforashorterprefix.Theinfinite
metricentryismaintaineduntilitissupersededbyafeasible
update;ifnosuchupdatearriveswithintherouteholdtime,the
entryisflushed.
3.6.RouteSelection
Routeselectionistheprocessbywhichasinglerouteforagiven
prefixisselectedtobeusedforforwardingpacketsandtobe
readvertisedtoanode'sneighbours.
Babelisdesignedtoallowflexiblerouteselectionpolicies.Asfar
astheprotocol'scorrectnessisconcerned,therouteselection
policyMUSTonlysatisfythefollowingproperties:
oaroutewithinfinitemetric(aretractedroute)isnever
selected;
oanunfeasiblerouteisneverselected.
Note,however,thatBabeldoesnotnaturallyguaranteethestability
ofrouting,andconfiguringconflictingrouteselectionpolicieson
differentroutersmayleadtopersistentrouteoscillation.
DefiningagoodrouteselectionpolicyforBabelisanopenresearch
problem.Routeselectioncantakeintoaccountmultiplemutually
contradictorycriteria;inroughlydecreasingorderofimportance,
theseare:
orouteswithasmallmetricshouldbepreferredoverrouteswitha
largemetric;
oswitchingrouteridsshouldbeavoided;
oroutesthroughstableneighboursshouldbepreferredoverroutes
throughunstableones;
41/90
18/2/2016
42/90
18/2/2016
ostableroutesshouldbepreferredoverunstableones;
oswitchingnexthopsshouldbeavoided.
Asimplestrategyistochoosethefeasibleroutewiththesmallest
metric,withasmallamountofhysteresisappliedtoavoidswitching
routerids.
Aftertherouteselectionprocedureisrun,triggeredupdates
(Section3.7.2)andrequests(Section3.8.2)aresent.
3.7.SendingUpdates
ABabelspeakeradvertisestoitsneighboursitssetofselected
routes.Normally,thisisdonebysendingoneormoremulticast
packetscontainingUpdateTLVsonallofitsconnectedinterfaces;
however,onlinktechnologieswheremulticastissignificantlymore
expensivethanunicast,anodeMAYchoosetosendmultiplecopiesof
updatesinunicastpacketswhenthenumberofneighboursissmall.
Additionally,inordertoensurethatanyblackholesarereliably
clearedinatimelymanner,aBabelnodesendsretractions(updates
withaninfinitemetric)foranyrecentlyretractedprefixes.
IfanupdateisforarouteinjectedintotheBabeldomainbythe
localnode(e.g.,theaddressofalocalinterface,theprefixofa
directlyattachednetwork,orredistributedfromadifferentrouting
protocol),therouteridissettothelocalid,themetricissetto
somearbitraryfinitevalue(typically0),andtheseqnoissetto
thelocalrouter'ssequencenumber.
IfanupdateisforaroutelearnedfromanotherBabelspeaker,the
routeridandsequencenumberarecopiedfromtheroutingtable
entry,andthemetriciscomputedasspecifiedinSection3.5.2.
3.7.1.PeriodicUpdates
EveryBabelspeakerperiodicallyadvertisesallofitsselected
routesonallofitsinterfaces,includinganyrecentlyretracted
routes.SinceBabeldoesn'tsufferfromroutingloops(thereisno
"countingtoinfinity")andreliesheavilyontriggeredupdates
(Section3.7.2),thisfulldumponlyneedstohappeninfrequently.
3.7.2.TriggeredUpdates
Inadditiontotheperiodicroutingupdates,aBabelspeakersends
unscheduled,ortriggered,updatesinordertoinformitsneighbours
ofasignificantchangeinthenetworktopology.
43/90
18/2/2016
44/90
18/2/2016
Achangeofrouteridfortheselectedroutetoagivenprefixmaybe
indicativeofaroutingloopinformation;hence,anodeMUSTsenda
triggeredupdateinatimelymannerwheneveritchangestheselected
routeridforagivendestination.Additionally,itSHOULDmakea
reasonableattemptatensuringthatallneighboursreceivethis
update.
Therearetwostrategiesforensuringthat.Ifthenumberof
neighboursissmall,thenitisreasonabletosendtheupdate
togetherwithanacknowledgementrequest;theupdateisresentuntil
allneighbourshaveacknowledgedthepacket,uptosomenumberof
times.Ifthenumberofneighboursislarge,however,requesting
acknowledgementsfromallofthemmightcauseanonnegligibleamount
ofnetworktraffic;inthatcase,itmaybepreferabletosimply
repeattheupdatesomereasonablenumberoftimes(say,5for
wirelessand2forwiredlinks).
Arouteretractionissomewhatlessworrying:iftherouteretraction
doesn'treachallneighbours,ablackholemightbecreated,which,
unlikearoutingloop,doesnotendangertheintegrityofthe
network.Whenarouteisretracted,anodeSHOULDsendatriggered
updateandSHOULDmakeareasonableattemptatensuringthatall
neighboursreceivethisretraction.
Finally,anodeMAYsendatriggeredupdatewhenthemetricfora
givenprefixchangesinasignificantmanner,eitherduetoa
receivedupdateorbecausealinkcosthaschanged.AnodeSHOULD
NOTsendtriggeredupdatesforotherreasons,suchaswhenthereisa
minorfluctuationinaroute'smetric,whentheselectednexthop
changes,ortopropagateanewsequencenumber(excepttosatisfya
request,asspecifiedinSection3.8).
3.7.3.MaintainingFeasibilityDistances
Beforesendinganupdate(prefix,plen,routerid,seqno,metric)
withfinitemetric(i.e.,notarouteretraction),aBabelnode
updatesthefeasibilitydistancemaintainedinthesourcetable.
Thisisdoneasfollows.
Ifnoentryindexedby(prefix,plen,routerid)existsinthesource
table,thenoneiscreatedwithvalue(prefix,plen,routerid,
seqno,metric).
Ifanentry(prefix,plen,routerid,seqno',metric')exists,then
itisupdatedasfollows:
oifseqno>seqno',thenseqno':=seqno,metric':=metric;
45/90
18/2/2016
46/90
18/2/2016
oifseqno=seqno'andmetric'>metric,thenmetric':=metric;
ootherwise,nothingneedstobedone.
Thegarbagecollectiontimerforthemodifiedentryisthenreset.
Notethatthegarbagecollectiontimerisnotresetwhenaretraction
issent.
3.7.4.SplitHorizon
Whenrunningoveratransitive,symmetriclinktechnology,e.g.,a
pointtopointlinkorawiredLANtechnologysuchasEthernet,a
BabelnodeSHOULDuseanoptimisationknownassplithorizon.When
splithorizonisusedonagiveninterface,aroutingupdateisnot
sentonthisparticularinterfacewhentheadvertisedroutewas
learntfromaneighbouroverthesameinterface.
SplithorizonSHOULDNOTbeappliedtoaninterfaceunlessthe
interfaceisknowntobesymmetricandtransitive;inparticular,
splithorizonisnotapplicabletodecentralisedwirelesslink
technologies(e.g.,IEEE802.11inadhocmode).
3.8.ExplicitRouteRequests
Innormaloperation,anode'sroutingtableispopulatedbythe
regularandtriggeredupdatessentbyitsneighbours.Undersome
circumstances,however,anodesendsexplicitrequeststocausea
resynchronisationwiththesourceafteramobilityeventorto
preventaroutefromspuriouslyexpiring.
TheBabelprotocolprovidestwokindsofexplicitrequests:route
requests,whichsimplyrequestanupdateforagivenprefix,and
seqnorequests,whichrequestanupdateforagivenprefixwitha
specificsequencenumber.Theformerareneverforwarded;thelatter
areforwardediftheycannotbesatisfiedbyaneighbour.
3.8.1.HandlingRequests
Uponreceivingarequest,anodeeitherforwardstherequestorsends
anupdateinreplytotherequest,asdescribedinthefollowing
sections.Ifthiscausesanupdatetobesent,theupdateiseither
senttoamulticastaddressontheinterfaceonwhichtherequestwas
received,ortotheunicastaddressoftheneighbourthatsentthe
update.
Theexactbehaviourisdifferentforrouterequestsandseqno
requests.
47/90
18/2/2016
48/90
18/2/2016
3.8.1.1.RouteRequests
Whenanodereceivesarouterequestforaprefix(prefix,plen),it
checksitsroutetableforaselectedroutetothisexactprefix.If
sucharouteexists,itMUSTsendanupdate;ifsucharoutedoes
not,itMUSTsendaretractionforthatprefix.
Whenanodereceivesawildcardrouterequest,itSHOULDsendafull
routingtabledump.
3.8.1.2.SeqnoRequests
Whenanodereceivesaseqnorequestforagivenrouteridand
sequencenumber,itcheckswhetheritsroutingtablecontainsa
selectedentryforthatprefix;ifnosuchentryexists,ortheentry
hasinfinitemetric,itignorestherequest.
Ifaselectedrouteforthegivenprefixexists,andeitherthe
routeridsaredifferentortherouteridsareequalandtheentry's
sequencenumberisnosmallerthantherequestedsequencenumber,it
MUSTsendanupdateforthegivenprefix.
Iftherouteridsmatchbuttherequestedseqnoislargerthanthe
routeentry's,thenodecomparestherouteridagainstitsown
routerid.Iftherouteridisitsown,thenitincreasesits
sequencenumberby1andsendsanupdate.AnodeMUSTNOTincrease
itssequencenumberbymorethan1inresponsetoarouterequest.
Iftherequestedrouteridisnotitsown,thereceivedrequest'shop
countis2ormore,andthenodehasaroute(notnecessarilya
feasibleone)fortherequestedprefixthatdoesnotusethe
requestorasanexthop,thenodeSHOULDforwardtherequest.It
doessobydecreasingthehopcountandsendingtherequestina
unicastpacketdestinedtoaneighbourthatadvertisesthegiven
prefix(notnecessarilytheselectedneighbour)andthatisdistinct
fromtheneighbourfromwhichtherequestwasreceived.
AnodeSHOULDmaintainalistofrecentlyforwardedrequestsand
forwardthereplyinatimelymanner.AnodeSHOULDcompareevery
incomingrequestagainstitslistofrecentlyforwardedrequestsand
avoidforwardingitifitisredundant.
Sincetherequestforwardingmechanismdoesnotnecessarilyobeythe
feasibilitycondition,itmaygetcaughtinroutingloops;hence,
requestscarryahopcounttolimitthetimeforwhichtheyremainin
thenetwork.However,sincerequestsareonlyeverforwardedas
unicastpackets,theinitialhopcountneednotbekeptparticularly
49/90
18/2/2016
50/90
18/2/2016
low,andperforminganexpandinghorizonsearchisnotnecessary.A
requestMUSTNOTbeforwardedtoamulticastaddress,anditMUSTbe
forwardedtoasingleneighbouronly.
3.8.2.SendingRequests
ABabelnodeMAYsendarouteorseqnorequestatanytime,toa
multicastoraunicastaddress;thereisonlyonecasewhen
originatingrequestsisrequired(Section3.8.2.1).
3.8.2.1.AvoidingStarvation
Whenarouteisretractedorexpires,aBabelnodeusuallyswitches
toanotherfeasiblerouteforthesameprefix.Itmaybethecase,
however,thatnosuchroutesareavailable.
AnodethathaslostallfeasibleroutestoagivendestinationMUST
sendaseqnorequest.Therouteridoftherequestissettothe
routeridoftheroutethatithasjustlost,andtherequestedseqno
isthevaluecontainedinthesourcetable,plus1.
SucharequestSHOULDbemulticastoverallofthenode'sattached
interfaces.Similarrequestswillbesentbyothernodesthatare
affectedbytheroute'slossandwillbeforwardedbyneighbouring
nodesuptothesource.Ifthenetworkisconnected,andthereisno
packetloss,thiswillresultinaroutebeingadvertisedwithanew
sequencenumber.(Notethat,duetoduplicatesuppression,onlya
smallnumberofsuchrequestswillactuallyreachthesource.)
Inordertocompensateforpacketloss,anodeSHOULDrepeatsucha
requestasmallnumberoftimesifnoroutebecomesfeasiblewithina
shorttime.Underheavypacketloss,however,allsuchrequestsmay
belost;inthatcase,thesecondmechanisminthenextsectionwill
eventuallyensurethatanewseqnoisreceived.
3.8.2.2.DealingwithUnfeasibleUpdates
Whenaroute'smetricincreases,anodemightreceiveanunfeasible
updateforaroutethatithascurrentlyselected.Asspecifiedin
Section3.5.1,thereceivingnodewilleitherignoretheupdateor
retracttheroute.
Inordertokeeproutesfromspuriouslyexpiringbecausetheyhave
becomeunfeasible,anodeSHOULDsendaunicastseqnorequest
wheneveritreceivesanunfeasibleupdateforaroutethatis
currentlyselected.Therequestedsequencenumberiscomputedfrom
thesourcetableasabove.
51/90
18/2/2016
52/90
18/2/2016
Additionally,anodeSHOULDsendaunicastseqnorequestwheneverit
receivesanunfeasibleupdatefromacurrentlyunselectedneighbour
thatis"goodenough",i.e.,thatwouldleadtothereceivedroute
becomingselectedwereitfeasible.
3.8.2.3.PreventingRoutesfromExpiring
Innormaloperation,aroute'sexpirytimershouldnevertrigger:
sincearoute'sholdtimeiscomputedfromanexplicitinterval
includedinUpdateTLVs,anewupdateshouldarriveintimeto
preventaroutefromexpiring.
Inthepresenceofpacketloss,however,itmaybethecasethatno
updateissuccessfullyreceivedforanextendedperiodoftime,
causingaroutetoexpire.Inordertoavoidsuchspuriousexpiry,
shortlybeforeaselectedrouteexpires,aBabelnodeSHOULDsenda
unicastrouterequesttotheneighbourthatadvertisedthisroute;
sincenodesalwayssendretractionsinresponsetononwildcardroute
requests(Section3.8.1.1),thiswillusuallyresultineitherthe
routebeingrefreshedoraretractionbeingreceived.
3.8.2.4.AcquiringNewNeighbours
Inordertospeedupconvergenceafteramobilityevent,anodeMAY
sendaunicastwildcardrequestafteracquiringanewneighbour.
Additionally,anodeMAYsendasmallnumberofmulticastwildcard
requestsshortlyafterbooting.
4.ProtocolEncoding
ABabelpacketissentasthebodyofaUDPdatagram,withnetwork
layerhopcountsetto1,destinedtoawellknownmulticastaddress
ortoaunicastaddress,overIPv4orIPv6;inthecaseofIPv6,
theseaddressesarelinklocal.BoththesourceanddestinationUDP
portaresettoawellknownportnumber.ABabelpacketMUSTbe
silentlyignoredunlessitssourceaddressiseitheralinklocal
IPv6address,oranIPv4addressbelongingtothelocalnetwork,and
itssourceportisthewellknownBabelport.BabelpacketsMUSTNOT
besentasIPv6Jumbograms.
Inordertominimisethenumberofpacketsbeingsentwhileavoiding
lowerlayerfragmentation,aBabelnodeSHOULDattempttomaximise
thesizeofthepacketsitsends,uptotheoutgoinginterface'sMTU
adjustedforlowerlayerheaders(28octetsforUDP/IPv4,48octets
forUDP/IPv6).ItMUSTNOTsendpacketslargerthantheattached
interface'sMTU(adjustedforlowerlayerheaders)or512octets,
whicheverislarger,butnotexceeding2^161adjustedforlower
53/90
18/2/2016
54/90
18/2/2016
layerheaders.EveryBabelspeakerMUSTbeabletoreceivepackets
thatareaslargeasanyattachedinterface'sMTU(adjustedfor
lowerlayerheaders)or512octets,whicheverislarger.
InordertoavoidglobalsynchronisationofaBabelnetworkandto
aggregatemultipleTLVsintolargepackets,aBabelnodeMUSTbuffer
everyTLVanddelaysendingaUDPpacketbyasmall,randomlychosen
delay[JITTER].Inordertoallowaccuratecomputationofpacket
lossrates,thisdelayMUSTNOTbelargerthanhalftheadvertised
Hellointerval.
4.1.DataTypes
4.1.1.Interval
Relativetimesarecarriedas16bitvaluesspecifyinganumberof
centiseconds(hundredthsofasecond).Thisallowstimesupto
roughly11minuteswithagranularityof10ms,whichshouldcover
allreasonableapplicationsofBabel.
4.1.2.RouterId
Arouteridisanarbitrary8octetvalue.RouteridsSHOULDbe
assignedinmodifiedEUI64format[ADDRARCH].
4.1.3.Address
Sincethebulkoftheprotocolistakenbyaddresses,multipleways
ofencodingaddressesaredefined.Additionally,acommonsubnet
prefixmaybeomittedwhenmultipleaddressesaresentinasingle
packetthisisknownasaddresscompression[PACKETBB].
Addressencodings:
oAE0:wildcardaddress.Thevalueis0octetslong.
oAE1:IPv4address.Compressionisallowed.4octetsorless.
oAE2:IPv6address.Compressionisallowed.16octetsorless.
oAE3:linklocalIPv6address.Thevalueis8octetslong,a
prefixoffe80::/64isimplied.
TheaddressfamilyofanaddressiseitherIPv4orIPv6;itis
undefinedforAE0,IPv4forAE1,andIPv6forAE2and3.
55/90
18/2/2016
56/90
18/2/2016
4.1.4.Prefixes
Anetworkprefixisencodedjustlikeanetworkaddress,butitis
storedinthesmallestnumberofoctetsthatareenoughtoholdthe
significantbits(uptotheprefixlength).
4.2.PacketFormat
ABabelpacketconsistsofa4octetheader,followedbyasequence
ofTLVs.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Magic|Version|Bodylength|
+++++++++++++++++++++++++++++++++
|PacketBody...
+++++++++++++
Fields:
MagicThearbitrarybutcarefullychosenvalue42(decimal);
packetswithafirstoctetdifferentfrom42MUSTbe
silentlyignored.
VersionThisdocumentspecifiesversion2oftheBabelprotocol.
Packetswithasecondoctetdifferentfrom2MUSTbe
silentlyignored.
BodylengthThelengthinoctetsofthebodyfollowingthepacket
header.
BodyThepacketbody;asequenceofTLVs.
AnydatafollowingthebodyMUSTbesilentlyignored.
4.3.TLVFormat
WiththeexceptionofPad1,allTLVshavethefollowingstructure:
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type|Length|Body...
+++++++++++++++++++++++++
57/90
18/2/2016
58/90
18/2/2016
Fields:
TypeThetypeoftheTLV.
LengthThelengthofthebody,exclusiveoftheTypeandLength
fields.Ifthebodyislongerthantheexpectedlengthof
agiventypeofTLV,anyextradataMUSTbesilently
ignored.
BodyTheTLVbody,theinterpretationofwhichdependsonthe
type.
TLVswithanunknowntypevalueMUSTbesilentlyignored.
4.4.DetailsofSpecificTLVs
4.4.1.Pad1
0
01234567
+++++++++
|Type=0|
+++++++++
Fields:
TypeSetto0toindicateaPad1TLV.
ThisTLVissilentlyignoredonreception.
4.4.2.PadN
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=1|Length|MBZ...
+++++++++++++++++++++++++
Fields:
TypeSetto1toindicateaPadNTLV.
fields.
MBZSetto0ontransmission.
ThisTLVissilentlyignoredonreception.
59/90
18/2/2016
60/90
18/2/2016
4.4.3.AcknowledgementRequest
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=2|Length|Reserved|
+++++++++++++++++++++++++++++++++
|Nonce|Interval|
+++++++++++++++++++++++++++++++++
ThisTLVrequeststhatthereceiversendanAcknowledgementTLV
withinthenumberofcentisecondsspecifiedbytheIntervalfield.
Fields:
TypeSetto2toindicateanAcknowledgementRequestTLV.
fields.
ReservedSentas0andMUSTbeignoredonreception.
NonceAnarbitraryvaluethatwillbeechoedinthereceiver's
AcknowledgementTLV.
IntervalAtimeintervalincentisecondsafterwhichthesenderwill
assumethatthispackethasbeenlost.ThisMUSTNOTbe0.
ThereceiverMUSTsendanacknowledgementbeforethistime
haselapsed(withamarginallowingforpropagationtime).
4.4.4.Acknowledgement
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=3|Length|Nonce|
+++++++++++++++++++++++++++++++++
ThisTLVissentbyanodeuponreceivinganAcknowledgementRequest.
Fields:
TypeSetto3toindicateanAcknowledgementTLV.
fields.
61/90
18/2/2016
62/90
18/2/2016
NonceSettotheNoncevalueoftheAcknowledgementRequestthat
promptedthisAcknowledgement.
Sincenoncevaluesarenotgloballyunique,thisTLVMUSTbesentto
aunicastaddress.
4.4.5.Hello
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
|Seqno|Interval|
+++++++++++++++++++++++++++++++++
ThisTLVisusedforneighbourdiscoveryandfordeterminingalink's
receptioncost.
Fields:
TypeSetto4toindicateaHelloTLV.
fields.
SeqnoThevalueofthesendingnode'sHelloseqnoforthis
interface.
IntervalAnupperbound,expressedincentiseconds,onthetime
afterwhichthesendingnodewillsendanewHelloTLV.
ThisMUSTNOTbe0.
SincethereisasingleseqnocounterforalltheHellossentbya
givennodeoveragiveninterface,thisTLVMUSTbesenttoa
multicastdestination.Inordertoavoidlargediscontinuitiesin
linkquality,multipleHelloTLVsSHOULDNOTbesentinthesame
packet.
63/90
18/2/2016
64/90
18/2/2016
4.4.6.IHU
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=5|Length|AE|Reserved|
+++++++++++++++++++++++++++++++++
|Rxcost|Interval|
+++++++++++++++++++++++++++++++++
|Address...
++++++++++++
AnIHU("IHeardYou")TLVisusedforconfirmingbidirectional
reachabilityandcarryingalink'stransmissioncost.
Fields:
TypeSetto5toindicateanIHUTLV.
fields.
AETheencodingoftheAddressfield.Thisshouldbe1or3
inmostcases.Asanoptimisation,itMAYbe0iftheTLV
issenttoaunicastaddress,iftheassociationisovera
pointtopointlink,orwhenbidirectionalreachabilityis
ascertainedbymeansoutsideoftheBabelprotocol.
RxcostTherxcostaccordingtothesendingnodeoftheinterface
whoseaddressisspecifiedintheAddressfield.Thevalue
FFFFhexadecimal(infinity)indicatesthatthisinterface
isunreachable.
afterwhichthesendingnodewillsendanewIHU;thisMUST
NOTbe0.Thereceivingnodewillusethisvalueinorder
tocomputeaholdtimeforthissymmetricassociation.
AddressTheaddressofthedestinationnode,intheformat
specifiedbytheAEfield.Addresscompressionisnot
allowed.
Conceptually,anIHUisdestinedtoasingleneighbour.However,IHU
TLVscontainanexplicitdestinationaddress,anditSHOULDbesent
toamulticastaddress,asthisallowsaggregationofIHUsdestined
65/90
18/2/2016
66/90
18/2/2016
todistinctneighboursintoasinglepacketandavoidstheneedfor
anARPorNeighbourDiscoveryexchangewhenaneighbourisnotbeing
usedfordatatraffic.
IHUTLVswithanunknownvaluefortheAEfieldMUSTbesilently
ignored.
4.4.7.RouterId
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
||
+RouterId+
||
+++++++++++++++++++++++++++++++++
ARouterIdTLVestablishesarouteridthatisimpliedbysubsequent
UpdateTLVs.
Fields:
TypeSetto6toindicateaRouterIdTLV.
fields.
RouterIdTherouteridforroutesadvertisedinsubsequentUpdate
TLVs
4.4.8.NextHop
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=7|Length|AE|Reserved|
+++++++++++++++++++++++++++++++++
|Nexthop...
++++++++++++
ANextHopTLVestablishesanexthopaddressforagivenaddress
family(IPv4orIPv6)thatisimpliedbysubsequentUpdateTLVs.
67/90
18/2/2016
68/90
18/2/2016
Fields:
TypeSetto7toindicateaNextHopTLV.
fields.
AETheencodingoftheAddressfield.ThisSHOULDbe1or3
andMUSTNOTbe0.
NexthopThenexthopaddressadvertisedbysubsequentUpdateTLVs,
forthisaddressfamily.
Whentheaddressfamilymatchesthenetworklayerprotocolthatthis
packetistransportedover,aNextHopTLVisnotneeded:inthat
case,thenexthopistakentobethesourceaddressofthepacket.
NextHopTLVswithanunknownvaluefortheAEfieldMUSTbesilently
ignored.
4.4.9.Update
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=8|Length|AE|Flags|
+++++++++++++++++++++++++++++++++
|Plen|Omitted|Interval|
+++++++++++++++++++++++++++++++++
|Seqno|Metric|
+++++++++++++++++++++++++++++++++
|Prefix...
++++++++++++
AnUpdateTLVadvertisesorretractsaroute.Asanoptimisation,
thiscanalsohavethesideeffectofestablishinganewimplied
routeridandanewdefaultprefix.
Fields:
TypeSetto8toindicateanUpdateTLV.
fields.
AETheencodingofthePrefixfield.
69/90
18/2/2016
70/90
18/2/2016
FlagsTheindividualbitsofthisfieldspecifyspecialhandling
ofthisTLV(seebelow).EverynodeMUSTbeableto
interprettheflagswithvalues80and40hexadecimal;
unknownflagsMUSTbesilentlyignored.
PlenThelengthoftheadvertisedprefix.
OmittedThenumberofoctetsthathavebeenomittedatthe
beginningoftheadvertisedprefixandthatshouldbetaken
fromaprecedingUpdateTLVwiththeflagwithvalue80
hexadecimalset.
afterwhichthesendingnodewillsendanewupdatefor
thisprefix.ThisMUSTNOTbe0andSHOULDNOTbeless
than10.Thereceivingnodewillusethisvaluetocompute
aholdtimeforthisroutingtableentry.ThevalueFFFF
hexadecimal(infinity)expressesthatthisannouncement
willnotberepeatedunlessarequestisreceived
(Section3.8.2.3).
SeqnoTheoriginator'ssequencenumberforthisupdate.
MetricThesender'smetricforthisroute.ThevalueFFFF
hexadecimal(infinity)meansthatthisisaroute
retraction.
PrefixTheprefixbeingadvertised.Thisfield'ssizeis(Plen/8
Omitted)roundedupwards.
TheFlagsfieldisinterpretedasfollows:
oifthebitwithvalue80hexadecimalisset,thenthisUpdate
establishesanewdefaultprefixforsubsequentUpdateTLVswitha
matchingaddressfamilywithinthesamepacket;
oifthebitwithvalue40hexadecimalisset,thentheloworder8
octetsoftheadvertisedprefixestablishanewdefaultrouterid
forthisTLVandsubsequentUpdateTLVsinthesamepacket.
TheprefixbeingadvertisedbyanUpdateTLViscomputedasfollows:
othefirstOmittedoctetsoftheprefixaretakenfromtheprevious
UpdateTLVwithflag80hexadecimalsetandthesameaddress
family;
othenext(Plen/8Omitted)(roundedupwards)octetsaretaken
fromthePrefixfield;
71/90
18/2/2016
72/90
18/2/2016
otheremainingoctetsaresetto0.
IftheMetricfieldisfinite,therouteridoftheoriginatingnode
forthisannouncementistakenfromtheloworder8octetsofthe
prefixadvertisedbythisUpdateifthebitwithvalue40hexadecimal
issetintheFlagsfield.Otherwise,itistakeneitherfromthe
precedingRouterIdpacket,ortheprecedingUpdatepacketwithflag
40hexadecimalset,whichevercomeslast.
Thenexthopaddressforthisupdateistakenfromthelastpreceding
NextHopTLVwithamatchingaddressfamilyinthesamepacket;ifno
suchTLVexists,itistakenfromthenetworklayersourceaddressof
thispacket.
IfthemetricfieldisFFFFhexadecimal,thisTLVspecifiesa
retraction.Inthatcase,thecurrentrouteridandtheSeqnoare
notused.AEMAYthenbe0,inwhichcasethisUpdateretractsall
oftheroutespreviouslyadvertisedonthisinterface.
UpdateTLVswithanunknownvaluefortheAEfieldMUSTbesilently
ignored.
4.4.10.RouteRequest
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=9|Length|AE|Plen|
+++++++++++++++++++++++++++++++++
|Prefix...
++++++++++++
ARouteRequestTLVpromptsthereceivertosendanupdatefora
givenprefix,orafullroutingtabledump.
Fields:
TypeSetto9toindicateaRouteRequestTLV.
fields.
AETheencodingofthePrefixfield.Thevalue0specifies
thatthisisarequestforafullroutingtabledump(a
wildcardrequest).
PlenThelengthoftherequestedprefix.
73/90
18/2/2016
74/90
18/2/2016
PrefixTheprefixbeingrequested.Thisfield'ssizeisPlen/8
roundedupwards.
ARequestTLVpromptsthereceivingnodetosendanupdatemessage
fortheprefixspecifiedbytheAE,Plen,andPrefixfields,ora
fulldumpofitsroutingtableifAEis0(inwhichcasePlenMUSTbe
0,andPrefixisoflength0).ARequestmaybesenttoaunicast
addressifitisdestinedtoasinglenode,ortoamulticastaddress
iftherequestisdestinedtoalloftheneighboursofthesending
interface.
4.4.11.SeqnoRequest
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Type=10|Length|AE|Plen|
+++++++++++++++++++++++++++++++++
|Seqno|HopCount|Reserved|
+++++++++++++++++++++++++++++++++
||
+RouterId+
||
+++++++++++++++++++++++++++++++++
|Prefix...
+++++++++++
ASeqnoRequestTLVpromptsthereceivertosendanUpdatefora
givenprefixwithagivensequencenumber,ortoforwardtherequest
furtherifitcannotbesatisfiedlocally.
Fields:
TypeSetto10toindicateaSeqnoRequestmessage.
fields.
AETheencodingofthePrefixfield.ThisMUSTNOTbe0.
PlenThelengthoftherequestedprefix.
SeqnoThesequencenumberthatisbeingrequested.
HopCountThemaximumnumberoftimesthatthisTLVmaybeforwarded,
plus1.ThisMUSTNOTbe0.
75/90
18/2/2016
76/90
18/2/2016
PrefixTheprefixbeingrequested.Thisfield'ssizeisPlen/8
roundedupwards.
ASeqnoRequestTLVpromptsthereceivingnodetosendanUpdatefor
theprefixspecifiedbytheAE,Plen,andPrefixfields,witheither
arouteriddifferentfromwhatisspecifiedbytheRouterIdfield,
oraSeqnonolessthanwhatisspecifiedbytheSeqnofield.If
thisrequestcannotbesatisfiedlocally,thenitisforwarded
accordingtotherulessetoutinSection3.8.1.2.
WhileaSeqnoRequestMAYbesenttoamulticastaddress,itMUSTNOT
beforwardedtoamulticastaddressandMUSTNOTbeforwardedtomore
thanoneneighbour.ArequestMUSTNOTbeforwardedifitsHopCount
fieldis1.
5.IANAConsiderations
IANAhasregisteredtheUDPportnumber6697,called"babel",foruse
bytheBabelprotocol.
IANAhasregisteredtheIPv6multicastgroupff02:0:0:0:0:0:1:6and
theIPv4multicastgroup224.0.0.111forusebytheBabelprotocol.
6.SecurityConsiderations
Asdefinedinthisdocument,Babelisacompletelyinsecureprotocol.
Anyattackercanattractdatatrafficbyadvertisingrouteswitha
lowmetric.Thisparticularissuecanbesolvedeitherbylower
layersecuritymechanisms(e.g.,IPsecorlinklayersecurity),orby
appendingacryptographickeytoBabelpackets;theprovisionof
ignoringanydatacontainedwithinaBabelpacketbeyondthebody
lengthdeclaredbytheheaderisdesignedforjustsuchapurpose.
TheinformationthataBabelnodeannouncestothewholerouting
domainisoftensufficienttodetermineamobilenode'sphysical
locationwithreasonableprecision.Theprivacyissuesthatthis
causescanbemitigatedsomewhatbyusingrandomlychosenrouterids
andrandomlychosenIPaddresses,andchangingthemperiodically.
WhencarriedoverIPv6,Babelpacketsareignoredunlesstheyare
sentfromalinklocalIPv6address;sinceroutersdon'tforward
linklocalIPv6packets,thisprovidesprotectionagainstspoofed
BabelpacketsbeingsentfromtheglobalInternet.Nosuchnatural
protectionexistswhenBabelpacketsarecarriedoverIPv4.
77/90
18/2/2016
78/90
18/2/2016
7.References
7.1.NormativeReferences
[ADDRARCH]Hinden,R.andS.Deering,"IPVersion6Addressing
Architecture",RFC4291,February2006.
[RFC2119]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
7.2.InformativeReferences
[DSDV]Perkins,C.andP.Bhagwat,"HighlyDynamicDestination
SequencedDistanceVectorRouting(DSDV)forMobile
Computers",ACMSIGCOMM'94ConferenceonCommunications
Architectures,ProtocolsandApplications234244,1994.
[DUAL]GarciaLunaAceves,J.,"LoopFreeRoutingUsing
DiffusingComputations",IEEE/ACMTransactionson
Networking1:1,February1993.
[EIGRP]Albrightson,B.,GarciaLunaAceves,J.,andJ.Boyle,
"EIGRPaFastRoutingProtocolBasedonDistance
Vectors",Proc.Interop94,1994.
[ETX]DeCouto,D.,Aguayo,D.,Bicket,J.,andR.Morris,"A
highthroughputpathmetricformultihopwireless
networks",Proc.MobiCom2003,2003.
[ISIS]"InformationtechnologyTelecommunicationsand
informationexchangebetweensystemsIntermediate
SystemtoIntermediateSystemintradomainrouteing
informationexchangeprotocolforuseinconjunctionwith
theprotocolforprovidingtheconnectionlessmode
networkservice(ISO8473)",ISO/IEC10589:2002.
[JITTER]Floyd,S.andV.Jacobson,"Thesynchronizationof
periodicroutingmessages",IEEE/ACMTransactionson
Networking2,2,122136,April1994.
[OSPF]Moy,J.,"OSPFVersion2",STD54,RFC2328,April1998.
[PACKETBB]Clausen,T.,Dearlove,C.,Dean,J.,andC.Adjih,
"GeneralizedMobileAdHocNetwork(MANET)Packet/Message
Format",RFC5444,February2009.
[RIP]Malkin,G.,"RIPVersion2",STD56,RFC2453,
November1998.
79/90
18/2/2016
80/90
18/2/2016
AppendixA.CostandMetricComputation
Thestrategyforcomputinglinkcostsandroutemetricsisalocal
matter;Babelitselfonlyrequiresthatitcomplywiththeconditions
giveninSections3.4.3and3.5.2.DifferentnodesMAYusedifferent
strategiesinasinglenetworkandMAYusedifferentstrategieson
differentinterfacetypes.Thissectiongivesafewexamplesofsuch
strategies.
ThesampleimplementationofBabelmaintainsstatisticsaboutthe
last16receivedHelloTLVs(AppendixA.1),computescostsbyusing
the2outof3strategy(AppendixA.2.1)onwiredlinks,andETX
[ETX]onwirelesslinks.Itusesanadditivealgebraformetric
computation(AppendixA.3.1).
A.1.MaintainingHelloHistory
Foreachneighbour,thesampleimplementationofBabelmaintainsa
Hellohistoryandanexpectedsequencenumber.TheHellohistoryis
avectorof16bits,wherea1valuerepresentsareceivedHello,and
a0valueamissedHello.Theexpectedsequencenumber,writtenne,
isthesequencenumberthatisexpectedtobecarriedbythenext
receivedhellofromthisneighbour.
WheneveritreceivesaHellopacketfromaneighbour,anodecompares
thereceivedsequencenumbernrwithitsexpectedsequencenumberne.
Dependingontheoutcomeofthiscomparison,oneofthefollowing
actionsistaken:
oifthetwodifferbymorethan16(modulo2^16),thenthesending
nodehasprobablyrebootedandlostitssequencenumber;the
associatedneighbourtableentryisflushed;
ootherwise,ifthereceivednrissmaller(modulo2^16)thanthe
expectedsequencenumberne,thenthesendingnodehasincreased
itsHellointervalwithoutournoticing;thereceivingnode
removesthelast(nenr)entriesfromthisneighbour'sHello
history(we"undohistory");
ootherwise,ifnrislarger(modulo2^16)thanne,thenthesending
nodehasdecreaseditsHellointerval,andsomeHelloswerelost;
thereceivingnodeadds(nrne)0bitstotheHellohistory(we
"fastforward").
81/90
18/2/2016
82/90
18/2/2016
Thereceivingnodethenappendsa1bittotheneighbour'sHello
history,resetstheneighbour'sHellotimer,andsetsneto(nr+1).
Itthenresetstheneighbour'sHellotimerto1.5timesthevalue
advertisedinthereceivedHello(theextramarginallowsforthe
delayduetojitter).
WhenevertheHellotimerassociatedtoaneighbourexpires,thelocal
nodeaddsa0bittothisneighbour'sHellohistory,andincrements
theexpectedHellonumber.IftheHellohistoryisempty(it
contains0bitsonly),theneighbourentryisflushed;otherwise,it
resetstheneighbour'sHellotimertothevalueadvertisedinthe
lastHelloreceivedfromthisneighbour(noextramarginisnecessary
inthiscase).
A.2.CostComputation
A.2.1.koutofj
Koutofjlinksensingissuitableforwiredlinksthatareeither
up,inwhichcasetheyonlyoccasionallydropapacket,ordown,in
whichcasetheydropallpackets.
Thekoutofjstrategyisparameterisedbytwosmallintegerskand
j,suchthat0<k<=j,andthenominallinkcost,aconstantK>=
1.Anodekeepsahistoryofthelastjhellos;ifkormoreof
thosehavebeencorrectlyreceived,thelinkisassumedtobeup,and
therxcostissettoK;otherwise,thelinkisassumedtobedown,
andtherxcostissettoinfinity.
Thecostofsuchalinkisdefinedas
ocost=FFFFhexadecimalifrxcost=FFFFhexadecimal;
ocost=txcostotherwise.
A.2.2.ETX
TheEstimatedTransmissionCostmetric[ETX]estimatesthenumberof
timesthataunicastframewillberetransmittedbytheIEEE802.11
MAC,assuminginfinitepersistence.
Anodeusesaneighbour'sHellohistorytocomputeanestimate,
writtenbeta,oftheprobabilitythataHelloTLVissuccessfully
received.Therxcostisdefinedas256/beta.
LetalphabeMIN(1,256/txcost),anestimateoftheprobabilityof
successfullysendingaHelloTLV.Thecostisthencomputedby
83/90
18/2/2016
84/90
18/2/2016
cost=256/(alpha*beta)
or,equivalently,
cost=(MAX(txcost,256)*rxcost)/256.
A.3.MetricComputation
A.3.1.AdditiveMetrics
Thesimplestapproachforobtainingamonotonic,isotonicmetricis
todefinethemetricofarouteasthesumofthecostsofthe
componentlinks.Moreformally,ifaneighbouradvertisesaroute
withmetricmoveralinkwithcostc,thentheresultingroutehas
metricM(c,m)=c+m.
Amultiplicativemetriccanbeconvertedtoanadditiveonebytaking
thelogarithm(insomesuitablebase)ofthelinkcosts.
A.3.2.ExternalSourcesofWillingness
Anodemaywanttovaryitswillingnesstoforwardpacketsbytaking
intoaccountinformationthatisexternaltotheBabelprotocol,such
asthemonetarycostofalink,thenode'sbatterystatus,CPUload,
etc.Thiscanbedonebyaddingtoeveryroute'smetricavaluek
thatdependsontheexternaldata.Forexample,ifabatterypowered
nodereceivesanupdatewithmetricmoveralinkwithcostc,it
mightcomputeametricM(c,m)=k+c+m,wherekdependsonthe
batterystatus.
Inordertopreservestrictmonotonicity(Section3.5.2),thevaluek
mustbegreaterthanc.
AppendixB.Constants
Thechoiceoftimeconstantsisatradeoffbetweenfastdetectionof
mobilityeventsandprotocoloverhead.TwoimplementationsofBabel
withdifferenttimeconstantswillinteroperate,althoughthe
resultingconvergencetimewillmostlikelybedictatedbythe
slowestofthetwoimplementations.
ExperiencewiththesampleimplementationofBabelindicatesthatthe
Hellointervalisthemostimportanttimeconstant:amobilityevent
isdetectedwithin1.5to3Hellointervals.DuetoBabel'sreliance
ontriggeredupdatesandexplicitrequests,theUpdateintervalonly
hasaneffectonthetimeittakesforaccuratemetricstobe
propagatedaftervariationsinlinkcoststoosmalltotriggeran
unscheduledupdate.
85/90
18/2/2016
86/90
18/2/2016
Atthetimeofwriting,thesampleimplementationofBabelusesthe
followingdefaultvalues:
HelloInterval:4secondsonwirelesslinks,20secondsonwired
links.
IHUInterval:theadvertisedIHUintervalisalways3timesthe
Hellointerval.IHUsareactuallysentwitheachHelloonlossy
links(asdeterminedfromtheHellohistory),butonlywithevery
thirdHelloonlosslesslinks.
UpdateInterval:4timestheHellointerval.
IHUHoldTime:3.5timestheadvertisedIHUinterval.
RouteExpiryTime:3.5timestheadvertisedupdateinterval.
SourceGCtime:3minutes.
Theamountofjitterappliedtoapacketdependsonwhetherit
containsanyurgentTLVsornot.Urgenttriggeredupdatesandurgent
requestsaredelayedbynomorethan200ms;otherTLVsaredelayed
bynomorethanonehalftheHellointerval.
AppendixC.SimplifiedImplementations
Babelisafairlyeconomicprotocol.Routeupdatestakebetween12
and40octetsperdestination,dependingonhowsuccessful
compressionis;inadoublestackmeshnetwork,anaverageofless
than24octetsistypical.Theroutetableoccupiesabout35octets
perIPv6entry.Toputthesevaluesintoperspective,asinglefull
sizeEthernetframecancarrysome65routeupdates,andamegabyte
ofmemorycancontaina20000entryroutingtableandtheassociated
sourcetable.
Babelisalsoareasonablysimpleprotocol.Thesample
implementationconsistsoflessthan8000linesofCcode,andit
compilestolessthan60kBoftextona32bitCISCarchitecture.
Nonetheless,insomeveryconstrainedenvironments,suchasPDAs,
microwaveovens,orabacuses,itmaybedesirabletohavesubset
implementationsoftheprotocol.
AparasiticimplementationisonethatusesaBabelnetworkfor
routingitspacketsbutdoesnotannounceanyoftheroutesthatit
haslearntfromitsneighbours.(Thisisslightlymorethana
passiveimplementation,whichdoesn'tevenannounceroutesto
itself.)Itmayeithermaintainafullroutingtableorsimply
87/90
18/2/2016
88/90
18/2/2016
selectagatewayamongstanyoneofitsneighboursthatannouncesa
defaultroute.Sinceaparasiticimplementationneverforwards
packets,itcannotpossiblyparticipateinaroutingloop;hence,it
neednotevaluatethefeasibilityconditionandneednotmaintaina
sourcetable.
AparasiticimplementationMUSTansweracknowledgementrequestsand
MUSTparticipateintheHello/IHUprotocol.Finally,itMUSTbeable
toreplytoseqnorequestsforroutesthatitannouncesandSHOULDbe
abletoreplytorouterequests.
AppendixD.SoftwareAvailability
ThesampleimplementationofBabelisavailablefrom
<http://www.pps.jussieu.fr/~jch/software/babel/>.
Author'sAddress
JuliuszChroboczek
PPS,UniversityofParis7
Case7014
75205ParisCedex13,
France
EMail:jch@pps.jussieu.fr
89/90
18/2/2016
90/90

RFC 6126 - The Babel Routing Protocol

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

RFC 6126 - The Babel Routing Protocol

Încărcat de

Drepturi de autor:

Formate disponibile

18/2/2016

S-ar putea să vă placă și