HAL Id: inria-00471712
https://hal.inria.fr/inria-00471712
Submitted on 8 Apr 2010
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of
sci-entific research documents, whether they are
pub-L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
Thomas Clausen, Philippe Jacquet, Cédric Adjih, Anis Laouiti, Pascale
Minet, Paul Muhlethaler, Amir Qayyum, Laurent Viennot
To cite this version:
Thomas Clausen, Philippe Jacquet, Cédric Adjih, Anis Laouiti, Pascale Minet, et al.. Optimized Link
State Routing Protocol (OLSR). 2003. �inria-00471712�
a p p o r t
d e r e c h e r c h e
THÈME 1
The Optimised Routing Protocol for Mobile Ad-hoc
Networks: protocol specification
Thomas Clausen (editor), Philippe Jacquet (editor)
C. Adjih, A. Laouiti, P. Minet, P. Muhlethaler, A. Qayyum, L. Viennot
N° 5145
Thomas Clausen (editor),PhilippeJacquet (editor)
C. Adjih, A. Laouiti,P.Minet, P. Muhlethaler, A.Qayyum, L. Viennot
Thème1Réseauxetsystèmes ProjetHIPERCOM
Rapportderecherche n° 5145 Mars200453pages
Abstract: ThisdocumentdescribestheOptimizedLinkState Routing(OLSR)protocol formobileadhocnetworks. Theprotocolisanoptimizationoftheclassicallinkstate algo-rithmtailoredto therequirementsofamobile wirelessLAN. Thekeyconcept usedin the protocolisthatofmultipointrelays(MPRs). MPRsareselectednodeswhichforward broad-castmessagesduringthe oodingprocess. Thistechniquesubstantiallyreducesthemessage overheadascomparedtoaclassical oodingmechanism,whereeverynoderetransmitseach message when it receivesthe rst copy of the message. In OLSR, link state information is generated only bynodeselected as MPRs. Thus, a second optimization is achievedby minimizingthenumberofcontrolmessages oodedinthenetwork. Asathirdoptimization, anMPRnodemaychosetoreportonlylinksbetweenitselfanditsMPRselectors. Hence, ascontraryto theclassiclink statealgorithm, partiallink stateinformation is distributed in the network. This information is then used by for route calculation. OLSR provides optimalroutes(intermsofnumberofhops). Theprotocolisparticularlysuitableforlarge anddensenetworksasthetechniqueofMPRsworkswellin thiscontext.
Résumé:
Ce document décrit le protocole "Optimized Link State Routing" (OLSR) dédié aux communications dans les réseaux mobiles ad hoc. Le protocole est une optimisation de l'algorithmeclassiquedit"àétatsdesliens"auxregardsdescontraintesdesréseauxlocaux mobiles. Le protocole repose sur le concept clef des relais multipoints (MPR). Les MPR sont des noeuds sélectionnés pourrelayerles messages àdiusion générale. La technique réduitdemanièretrèssigni cativelasurchargeoccasionnéedansladiusionparinnondation classique,oùchaquenoeudretransmetlemessagelapremièrefoisqu'illereçoit.
Dans le protocole OLSR, lesinformations sur l'état desliens ne sont générées que par lesnoeudséluscommeMPR. Doncunesecondeoptimisationpermet deminimiseraussile nombredemessagesdecontrôlediusésdansleréseau. Unetroisièmeoptimisationfaitque cesmessagesdecontrôlenementionnentquelesliensqui relientunnoeud aveclesnoeuds quil'ontéluMPR;enconséquencelesmessagesdecontrôlenediusentqu'uneinformation partiellesur lesétatsdesliens duréseau. Cetteinformationest alorsutiliséepourcalculer lesroutes dansle réseau. Le protocole OLSR fournit desroutes delongueuroptimale par rapportàlatopologiecomplète. Leprotocoleestparticulièrementadaptéauxgransréseaux densedanslamesureoùlatechniquedesMPRmarcheàpleinrendementdanscecontexte. Mots-clés : Réseauxmobilesadhoc,Protocolederoutage,OLSR,Descriptiondu proto-cole
1 Introduction
The Optimized LinkState Routing Protocol (OLSR) is developed formobile ad hoc net-works. Itoperatesasatabledriven,proactiveprotocol,i.eexchangestopologyinformation withothernodesof thenetwork regularly. Each nodeselectsaset ofitsneighbornodesas "multipointrelays" (MPR). InOLSR, only nodes, selectedassuch MPRs, areresponsible forforwardingcontroltra c, intendedfordiusionintotheentirenetwork. MPRsprovide ane cientmechanismfor oodingcontroltra c byreducingthenumberof transmissions required.
Nodes, selected as MPRs, also have a special responsibility when declaring link state informationinthenetwork.Indeed,theonlyrequirementforOLSRtoprovideshortestpath routesto all destinationsis that MPRnodesdeclarelink-state informationfor theirMPR selectors. Additional availablelink-stateinformationmaybeutilized,e.g. forredundancy.
Nodeswhichhavebeenselectedasmultipointrelaysbysomeneighbornode(s)announce this information periodically in their control messages. Therebya node announcesto the network,that ithasreachabilityto thenodes which haveselectedit asanMPR. Inroute calculation,theMPRsareusedtoformtheroutefromagivennodetoanydestinationinthe network.Furthermore,theprotocolusestheMPRsto facilitatee cient oodingofcontrol messagesinthenetwork.
A node selects MPRs from among its one hop neighbors with "symmetrical", i.e. bi-directional, linkages. Therefore, selecting the route through MPRs automatically avoids the problems associated with data packet transfer overuni-directional links (such as the problem of notgetting link-layeracknowledgmentsfor data packets at each hop, for link-layersemployingthistechniqueforunicasttra c).
OLSRisdevelopedtoworkindependentlyfromotherprotocols. Likewise,OLSRmakes noassumptionsabouttheunderlyinglink-layer.
OLSR inherits theconceptof forwardingandrelayingfrom HIPERLAN (a MAClayer protocol) which is standardized byETSI[4]. Theprotocolis developed in theIPANEMA project(partoftheEuclidprogram)andinthePRIMAproject(partoftheRNRTprogram).
1.1 OLSR Terminology
Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD", "SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"inthisdocumentare tobeinterpretedasdescribedinRFC2119[3]. Additionally,thisdocumentusesthefollowing terminology:
node
A MANET router which implementsthe Optimized Link State Routingprotocol as speci edin thisdocument.
AnetworkdeviceparticipatinginaMANETrunningOLSR.Anodemayhaveseveral OLSRinterfaces,eachinterfaceassignedanuniqueIPaddress.
nonOLSR interface
A network device, notparticipating in aMANET runningOLSR. A node may have severalnonOLSRinterfaces(wirelessand/orwired). Routinginformationfromthese interfacesMAYbeinjectedintotheOLSRroutingdomain.
singleOLSRinterfacenode
AnodewhichhasasingleOLSRinterface,participatingin anOLSRroutingdomain.
multiple OLSRinterfacenode
AnodewhichhasmultipleOLSRinterfaces,participatinginanOLSRroutingdomain.
main address
Themain addressofanode, which willbeusedin OLSRcontrol tra casthe "orig-inator address"of all messagesemittedby this node. It isthe addressof oneofthe OLSRinterfacesofthenode.
A single OLSR interface node MUST use the addressof its only OLSR interface as themainaddress.
A multiple OLSR interface node MUST choose oneof its OLSR interfaceaddresses as its "main address" (equivalent of "router ID" or "node identi er"). It is of no importance which addressis chosen,howevera node SHOULD alwaysuse the same addressasitsmainaddress.
neighbornode
AnodeXisaneighbornodeofnodeYifnodeYcanhearnodeX(i.e. abidirectional link existsbetweenanOLSR interfacesonnodeXandanOLSRinterfaceonY).
2-hopneighbor
Anodeheardbyaneighbor.
strict2-hopneighbor
a2-hopneighborwhichisnotthenodeitselforaneighborofthenode,andinaddition is a neighbor of a neighbor, with willingness dierent from WILL_NEVER, of the node.
multipointrelay(MPR)
A node which is selected by its one-hop neighbor, node X, to "re-transmit"all the broadcastmessagesthatitreceivesfromX,providedthatthemessageisnota dupli-cate,andthatthetimetolive eldofthemessageisgreaterthanone.
multipointrelayselector(MPRselector,MS)
A nodewhichhasselected itsone-hopneighbor,nodeX, asitsmultipointrelay,will becalled amultipointrelayselectorofnodeX.
link
Alink isapairofOLSRinterfaces(from twodierentnodes)susceptibletohear one another(i.e. onemaybeabletoreceivetra cfromtheother). Anodeissaidtohave alink toanother nodewhenoneof itsinterfacehasalinkto oneoftheinterfacesof theothernode.
symmetriclink
Averi edbi-directionallinkbetweentwoOLSR interfaces.
asymmetric link
Alink betweentwoOLSRinterfaces,veri edinonlyone direction.
symmetric1-hopneighborhood
Thesymmetric 1-hopneighborhoodof anynodeX isthe setof nodeswhich haveat leastonesymmetriclink toX.
symmetric2-hopneighborhood
Thesymmetric2-hopneighborhoodofXisthesetofnodes,excludingXitself,which haveasymmetriclinkto thesymmetric1-hopneighborhoodofX.
symmetricstrict2-hopneighborhood
The symmetric 2-hopneighborhood of X is the set of nodes, excludingX itself and its neighbors,which haveasymmetriclink to somesymmetric1-hop neighbor,with willingnessdierentofWILL_NEVER,ofX.
1.2 Protocol Applicability
OLSR isaproactiveroutingprotocolfor mobilead-hocnetworks (MANETs) [6], [1]. It is wellsuitedtolargeanddensemobilenetworks,astheoptimizationachievedusingtheMPRs workswellinthiscontext. Thelargerandmoredenseanetwork,themoreoptimizationcan beachievedascomparedtotheclassiclinkstatealgorithm. OLSRuseshop-by-hoprouting, i.e. eachnodeusesitslocalinformationtoroutepackets.
OLSR is wellsuited for networks, where the tra c is random and sporadic between a largersetofnodesratherthanbeingalmostexclusivelybetweenasmallspeci csetofnodes. Asaproactiveprotocol,OLSRisalsosuitableforscenarioswherethecommunicatingpairs changeovertime: noadditionalcontroltra cisgeneratedinthissituationsinceroutesare maintainedforallknowndestinationsat alltimes.
1.3 Protocol Overview
OLSR is a proactive routingprotocol for mobile ad hoc networks. The protocol inherits thestabilityof alink statealgorithmand hastheadvantageofhavingroutesimmediately availablewhenneededduetoitsproactivenature. OLSRisanoptimizationovertheclassical linkstateprotocol, tailoredformobileadhocnetworks.
OLSR minimizes the overhead from ooding of control tra c by using only selected nodes, called MPRs, to retransmit control messages. This technique signi cantly reduces the number of retransmissions required to ood a message to all nodes in the network. Secondly, OLSR requires only partial link stateto be oodedin order toprovideshortest pathroutes. Theminimalsetoflinkstateinformationrequiredis,thatallnodes,selectedas MPRs,MUSTdeclarethelinkstotheirMPRselectors. Additionaltopologicalinformation, ifpresent,MAYbeutilizede.g. forredundancypurposes.
OLSR MAY optimize thereactivityto topological changes by reducingthe maximum timeintervalforperiodiccontrolmessagetransmission. Furthermore,asOLSRcontinuously maintains routes to all destinations in the network, the protocol is bene cial for tra c patterns where a large subset of nodes are communicating with another large subset of nodes, and where the [source, destination] pairs are changing overtime. The protocol is particularly suited for large and dense networks, as the optimization done using MPRs workswellinthiscontext. Thelargerandmoredenseanetwork,themoreoptimizationcan beachievedascomparedtotheclassiclinkstatealgorithm.
OLSRisdesignedtoworkinacompletelydistributedmanneranddoesnotdependonany centralentity. TheprotocoldoesNOTREQUIREreliabletransmissionofcontrolmessages: each node sends control messagesperiodically, andcan thereforesustain areasonableloss ofsomesuchmessages. Such lossesoccurfrequentlyin radio networksdue to collisionsor othertransmissionproblems.
Also, OLSR does not require sequenced delivery of messages. Each control message containsasequence numberwhich is incremented foreachmessage. Thus therecipientof acontrolmessagecan,ifrequired,easilyidentify whichinformationismorerecent-evenif messageshavebeenre-orderedwhilein transmission.
Furthermore,OLSRprovidessupportforprotocolextensionssuchassleepmode opera-tion,multicast-routingetc. Suchextensionsmaybeintroducedasadditionstotheprotocol withoutbreaking backwardscompatibilitywithearlierversions.
OLSR doesnotrequireany changesto theformatof IP packets. Thus anyexistingIP stackcanbeusedasis: theprotocolonlyinteractswithroutingtablemanagement.
1.4 Multipoint Relays
Theideaofmultipointrelaysistominimizetheoverheadof oodingmessagesinthenetwork byreducingredundantretransmissionsinthesameregion. Eachnodeinthenetworkselects a set of nodes in its symmetric 1-hop neighborhood which may retransmit its messages. This set of selected neighbor nodes is called the "Multipoint Relay" (MPR) set of that
node. The neighbors of node N which are *NOT* in its MPR set, receive and process broadcastmessagesbut donotretransmitbroadcastmessagesreceivedfromnodeN.
Each node selectsitsMPR set from amongits onehop symmetricneighbors. This set is selected such that it covers(in terms of radio range)all symmetric strict 2-hop nodes. TheMPRsetofN,denotedasMPR(N),isthenanarbitrarysubsetofthesymmetric1-hop neighborhood of N which satis es the following condition: every node in the symmetric strict2-hopneighborhood ofNmusthaveasymmetriclink towardsMPR(N).Thesmaller aMPRset,thelesscontrol tra c overhead resultsfromthe routingprotocol. [1]givesan analysisandexampleof MPRselectionalgorithms.
Each node maintains information about the set of neighbors that have selected it as MPR.Thissetiscalledthe"MultipointRelaySelectorset"(MPRselectorset)ofanode. A nodeobtainsthisinformationfromperiodicHELLOmessagesreceivedfromtheneighbors. A broadcastmessage, intended to be diused in the whole network, comingfrom any of the MPR selectors of node N is assumed to be retransmitted by node N, ifN has not receivedit yet. Thisset can change overtime(i.e. whenanode selectsanotherMPR-set) andisindicatedbytheselectornodesin theirHELLOmessages.
2 Protocol Functioning
Thissectionoutlinestheoverallprotocolfunctioning.
OLSR is modularized into a "core" of functionality, which is always required for the protocolto operate,andasetofauxiliaryfunctions.
Thecore speci es, in itsownright,aprotocol ableto provide routingin astand-alone MANET.
Each auxiliary function provides additional functionality, which may be applicable in speci c scenarios. E.g. in caseanode isprovidingconnectivitybetweenthe MANETand anotherroutingdomain.
Allauxiliaryfunctionsarecompatible,totheextentwhereany(sub)setofauxiliary func-tionsmaybeimplementedwith the core. Furthermore, theprotocolallowsheterogeneous nodes,i.e. nodeswhich implementdierentsubsetsoftheauxiliaryfunctions,to coexist in thenetwork.
Thepurpose ofdividingthe functioningof OLSR intoacorefunctionalityand aset of auxiliaryfunctions istoprovideasimpleandeasy-to-comprehendprotocol,andtoprovide awayofonlyaddingcomplexitywherespeci c additionalfunctionalityisrequired.
2.1 Core Functioning
The core functionality of OLSR speci es the behavior of a node, equipped with OLSR interfacesparticipatingintheMANETandrunningOLSRasroutingprotocol.Thisincludes a universal speci cation of OLSR protocol messages and their transmission through the network,aswellaslinksensing,topologydiusionandroutecalculation.
Packet FormatandForwarding
An universalspeci cationofthepacketformatandanoptimized oodingmechanism servesasthetransportmechanismforallOLSRcontroltra c.
LinkSensing
LinkSensingisaccomplishedthroughperiodicemissionofHELLOmessagesoverthe interfacesthroughwhichconnectivityischecked. AseparateHELLOmessageis gener-atedforeachinterfaceandemittedincorrespondencewiththeprovisionsinsection7. Resultingfrom LinkSensing isalocal link set, describinglinksbetween"local inter-faces"and"remoteinterfaces"-i.e. interfacesonneighbornodes.
Ifsu cientinformationisprovidedbythelink-layer,thismaybeutilizedtopopulate thelocallink setinsteadofHELLOmessageexchange.
Neighbor detection
Givenanetworkwithonlysingleinterfacenodes,anodemaydeducttheneighborset directlyfromtheinformationexchangedaspartoflinksensing: the"mainaddress"of asingleinterfacenodeis,byde nition,theaddressoftheonlyinterfaceonthatnode. Inanetworkwithmultipleinterfacenodes,additionalinformationisrequiredinorder to map interface addresses to main addresses (and, thereby, to nodes). This addi-tionalinformationisacquiredthroughmultipleinterfacedeclaration(MID)messages, describedin section5.
MPRSelectionandMPRSignaling
Theobjective ofMPRselection isfor anodeto selectasubset ofitsneighborssuch that abroadcastmessage,retransmittedbytheseselectedneighbors,willbereceived byallnodes2hopsaway. TheMPRset ofanodeiscomputedsuchthat it,for each interface, satis es this condition. The information required to perform this calcula-tion is acquired throuth the periodic exchange of HELLO messages,as described in section6. MPRselectionproceduresaredetailed insection8.3.
MPRsignalingisprovidedincorrespondencewiththeprovisionsin thesection6.
TopologyControlMessageDiusion
TopologyControl messagesare diused with the purpose of providing each node in thenetworkwithsu cientlink-stateinformationtoallowroutecalculation. Topology Control messagesarediusedin correspondencewiththeprovisionsinsection9.
Route Calculation
Giventhelinkstateinformationacquiredthroughperiodicmessageexchange, aswell as the interface con guration of the nodes, the routing table for each node can be computed. Thisisdetailedin section10.
Feature Section Packetformatandforwarding 3 Informationrepositories 4 Mainaddrandmultipleif. 5 Hellomessages 6
Linksensing 7
Neighbordetection 8 Topologydiscovery 9 Routingtablecomputation 10 Nodecon guration 11
Table1: CoreProtocol componentsandcorrespondingspeci cationsections
Feature Section Non-OLSRinterfaces 12 Link-layernoti cations 13 Advanced linksensing 14 Redundanttopology 15 RedundantMPR ooding 16
Table2: Auxilaryprotocolcomponentsandcorrespondingspeci cationsections
Thekeynotionforthese mechanismsistheMPRrelationship.
The following table speci es the component of thecorefunctionality of OLSR, aswell astheirrelationstothisdocument.
2.2 Auxiliary Functioning
InadditiontothecorefunctioningofOLSR,therearesituationswhereadditional function-alityisdesired. Thisincludessituationswhereanodehasmultipleinterfaces,someofwhich participatein anotherroutingdomain,where theprogramminginterfaceto thenetworking hardwareprovidesadditionalinformationin formof linklayernoti cationsand whereitis desiredtoprovideredundanttopologicalinformationtothenetworkonexpenseofprotocol overhead.
Thefollowingtablespeci esauxiliaryfunctions andtheirrelationtothisdocument. The interpretation of the above table is asfollows: if the feature listed is required, it SHOULDbeprovidedasspeci edin thecorrespondingsection.
3 Packet Format and Forwarding
OLSRcommunicatesusingauni edpacketformatforalldatarelatedtotheprotocol.The purposeofthisistofacilitateextensibilityoftheprotocolwithoutbreakingbackwards com-patibility. This alsoprovidesaneasywayofpiggybackingdierent"types" ofinformation intoasingletransmission,andthusforagivenimplementationtooptimizetowardsutilizing the maximal frame-size, provided by the network. These packets are embedded in UDP datagrams for transmission over the network. The present draft is presented with IPv4 addresses. ConsiderationsregardingIPv6aregivenin section17.
Eachpacketencapsulatesoneormoremessages. Themessagesshareacommonheader format,whichenablesnodes tocorrectly acceptand(if applicable) retransmitmessagesof anunknowntype.
Messages can be ooded onto the entire network, or ooding canbe limited to nodes within adiameter (in termsof numberof hops)from theoriginator of themessage. Thus transmittingamessagetotheneighborhoodofanodeisjustaspecialcaseof ooding. When oodinganycontrolmessage,duplicateretransmissionswill beeliminatedlocally(i.e. each node maintains a duplicate set to prevent transmitting the same OLSR control message twice)andminimizedintheentirenetworkthroughtheusageofMPRsasdescribedinlater sections.
Furthermore,anodecanexaminetheheaderofamessagetoobtaininformationonthe distance (in termsof numberof hops)to the originatorof themessage. This feature may be useful in situations where, e.g., thetime informationfrom areceivedcontrol messages storedinanodedepends onthedistancetotheoriginator.
3.1 Protocol and Port Number
Packets in OLSR arecommunicatedusing UDP. Port 698hasbeenassigned byIANA for exclusiveusagebytheOLSRprotocol.
3.2 Main Address
Foranodewithoneinterface,themainaddressofanode,asde nedin"OLSRTerminology", MUSTbesetto theaddressofthatinterface.
3.3 Packet Format
ThebasiclayoutofanypacketinOLSR(omittingIPandUDPheaders),isgivenin gure1.
3.3.1 Packet Header Packet Length
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Packet Length | Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Time To Live | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Time To Live | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | | : MESSAGE : | | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ : : (etc)
Packet SequenceNumber
ThePacket SequenceNumber(PSN) MUSTbe incrementedbyoneeachtime anew OLSRpacketistransmitted. "Wrap-around"ishandledasdescribedinsection18.10. AseparatePacketSequenceNumberismaintainedforeachinterfacesuchthatpackets transmittedoveraninterfacearesequentiallyenumerated.
TheIP addressoftheinterfaceoverwhichapacketwastransmittedis obtainablefrom theIPheaderofthepacket.
If thepacket containsnomessages (i.e. thePacketLength is lessthanorequalto the sizeofthepacket header),thepacket MUSTsilentlybediscarded.
For IPv4 addresses, this implies that packets, where the Packet Length < 16 MUST silentlybediscarded.
3.3.2 Message Header MessageType
This eld indicates which type of messageis to be found in the"MESSAGE" part. Message types in therange of 0-127are reserved formessagesin thisdocument and in possibleextensions.
Vtime
This eld indicates for how long time after reception a node MUST consider the information contained in the message as valid, unless a more recent update to the informationisreceived. Thevaliditytimeisrepresentedbyitsmantissa(fourhighest bits of Vtime eld) and by its exponent (four lowest bits of Vtime eld). In other words: validitytime=C(1+ a 16 )2 b inseconds
where a is the integerrepresented bythe four highest bits of Vtime eld and b the integerrepresentedbythefour lowest bitsof Vtime eld. Theproposed valueofthe scalingfactorCisspeci edinsection18.
MessageSize
This eld gives the size of this message, counted in bytes and measured from the beginningof the"MessageType" eld anduntilthebeginningof thenext"Message Type" eld (or-ifthere arenofollowingmessages-untiltheendofthepacket).
OriginatorAddress
This eld containsthe main addressof thenode, which hasoriginallygenerated this message. This eld SHOULD NOT be confused with the source address from the
IP header, which is changed each time to the address of the intermediate interface which isre-transmitting this message. The OriginatorAddress eld MUST NEVER bechangedin retransmissions.
TimeToLive
This eldcontainsthemaximumnumberofhopsamessagewillbetransmitted.Before amessageis retransmitted, theTime ToLiveMUST bedecrementedby1. When a node receives a message with a Time To Live equal to 0 or1, the message MUST NOTberetransmittedunder anycircumstances. Normally,anodewouldnotreceive amessagewithaTTLof zero.
Thus,bysettingthis eld,theoriginatorofamessagecanlimitthe oodingradius.
HopCount
This eld contains thenumberof hops amessagehas attained. Before amessageis retransmitted,theHopCountMUSTbeincrementedby1.
Initially, thisissetto'0'bytheoriginatorof themessage.
MessageSequenceNumber
Whilegeneratingamessage,the"originator"node willassignauniqueidenti cation numbertoeachmessage. ThisnumberisinsertedintotheSequenceNumber eldofthe message. Thesequence numberis increased by1 (one)for each message originating from the node. "Wrap-around" is handled as described in section 18.10. Message sequencenumbersareusedto ensurethat agivenmessageisnotretransmittedmore thanoncebyanynode.
3.4 Packet Processing and Message Flooding
Uponreceivingabasicpacket,anodeexamineseachofthe"messageheaders". Basedonthe valueofthe"MessageType" eld,thenodecandeterminethefateofthemessage. Anode mayreceivethesamemessageseveraltimes. Thus,toavoidre-processingofsomemessages which were already received and processed, each node maintains aDuplicate Set. In this set,thenoderecordsinformationaboutthemostrecentlyreceivedmessageswhereduplicate processingofamessageisto beavoided. Forsuchamessage,anoderecordsa"Duplicate Tuple" (D_addr, D_seq_num, D_retransmitted, D_iface_list, D_time), where D_addr istheoriginatoraddressofthemessage,D_seq_numisthemessagesequencenumberofthe message, D_retransmitted is a boolean indicating whether the message has beenalready retransmitted,D_iface_listisalistoftheaddressesoftheinterfacesonwhichthemessage hasbeenreceivedand D_timespeci es thetimeatwhichatupleexpiresand*MUST*be removed.
Inanode,theset ofDuplicateTuplesaredenoted the"Duplicateset".
Inthis section,theterm"OriginatorAddress"willbeusedfor themainaddressofthe node which sent the message. The term "Sender Interface Address" will be used for the
senderaddress(givenintheIPheaderofthepacketcontainingthemessage)oftheinterface whichsentthemessage. Theterm"ReceivingInterfaceAddress"willbeusedfortheaddress oftheinterfaceofthenodewhichreceivedthemessage.
Thus,uponreceivingabasicpacket,anodeMUSTperformthefollowingtasksforeach encapsulatedmessage:
1. Ifthepacketcontainsnomessages(i.e. thePacketLengthislessthanorequaltothe size ofthepacketheader),thepacketMUSTsilentlybediscarded.
ForIPv4 addresses, thisimplies that packets, where thePacket Length< 16MUST silentlybediscarded.
2. Ifthe timetoliveofthemessageislessthanorequalto'0'(zero), orifthemessage wassentbythereceivingnode(i.e. theOriginatorAddressofthemessageisthemain addressofthereceivingnode): themessageMUSTsilentlybedropped.
3. Processingcondition:
(a) ifthereexistsatupleintheduplicateset,where: D_addr==OriginatorAddress,AND D_seq_num==MessageSequenceNumber
thenthemessagehasalreadybeencompletelyprocessedandMUSTnotbe pro-cessedagain.
(b) Otherwise,ifthenodeimplementstheMessageTypeofthemessage,themessage MUSTbeprocessedaccordingtothespeci cationsforthemessagetype.
4. Forwardingcondition:
(a) ifthereexistsatupleintheduplicateset,where: D_addr==OriginatorAddress,AND
D_seq_num==MessageSequenceNumber,AND thereceivinginterface(address)isin D_iface_list
thenthemessagehasalreadybeenconsideredforforwardingandSHOULDNOT beretransmittedagain.
(b) Otherwise:
IfthenodeimplementstheMessageTypeofthemessage,themessageMUST beconsideredforforwardingaccordingtothespeci cationsforthemessage type.
Otherwise,ifthenodedoesnotimplementtheMessageTypeofthemessage, themessageSHOULD beprocessedaccordingto thedefault forwarding al-gorithmdescribedbelow.
3.4.1 Default ForwardingAlgorithm Thedefault forwardingalgorithmisthefollowing:
1. Ifthe senderinterfaceaddressof themessageisnotdetectedto bein thesymmetric 1-hop neighborhood of the node, theforwardingalgorithm MUST silentlystop here (andthemessageMUSTNOTbeforwarded).
2. Ifthereexists atuplein theduplicatesetwhere:
D_addr==OriginatorAddress
D_seq_num==MessageSequenceNumber
Thenthemessagewill befurtherconsideredforforwardingifandonlyif:
D_retransmittedisfalse,AND
the(addressof the) interfacewhich receivedthemessageisnotincludedamong theaddressesinD_iface_list
3. Otherwise, if such an entry doesn't exist, the message is further considered for for-warding.
Ifafter thosesteps,themessageisnotconsideredforforwarding,thentheprocessing of this sectionstops (i.e. steps 4to 8areignored), otherwise, ifit isstill considered forforwardingthenthefollowingalgorithmisused:
4. If thesenderinterfaceaddressisaninterfaceaddressofaMPRselector ofthis node and if the time to live of the message is greater than '1', the message MUST be retransmitted(asdescribedlaterin steps6to8).
5. Ifanentryintheduplicatesetexists,withsameOriginatorAddress,andsameMessage Sequence Number,theentryisupdatedasfollows:
D_time=currenttime+DUP_HOLD_TIME.
6. Thereceivinginterface(address)isaddedtoD_iface_list.
7. D_retransmittedissettotrueifandonlyifthemessagewillberetransmitted accord-ingtostep4.
8. Otherwiseanentryintheduplicatesetisrecordedwith:
D_addr=OriginatorAddress
D_seq_num=MessageSequenceNumber D_time=currenttime+DUP_HOLD_TIME.
D_iface_listcontainsthereceivinginterfaceaddress.
D_retransmittedissettotrueifandonlyifthemessagewillberetransmitted accord-ingtostep4.
9. If,andonlyif,accordingtostep4,themessagemustberetransmittedthen:
10. TheTTLofthemessageisreducedbyone.
11. Thehop-countofthemessageisincreasedbyone
12. Themessageisbroadcastonallinterfaces(Notice: Theremaining eldsofthemessage headerSHOULDbeleftunmodi ed.)
3.4.2 Considerationson Processing and Forwarding
Itshould benotedthat processingand forwardingmessagesare twodierentactions, con-ditioned by dierentrules. Processing relatesto using the content of the messages,while forwardingisrelatedtoretransmittingthesamemessageforothernodesofthenetwork.
Notice that this speci cation includes a description for both the forwarding and the processingofeachknownmessagetype. MessageswithknownmessagetypesMUST*NOT* be forwarded "blindly" by this algorithm. Forwarding (and setting the correct message header in theforwarded, known, message)istheresponsibilityof thealgorithm specifying howthemessageisto behandled and,ifnecessary, retransmitted. Thisenablesamessage typetobespeci edsuchthatthemessagecanbemodi edwhileintransit(e.g. tore ectthe routethemessagehastaken). ItalsoenablesbypassingoftheMPR oodingmechanismiffor somereasonclassical ooding of amessagetypeis required, thealgorithm which speci es how such messagesshould be handled will simply rebroadcast the message, regardless of MPRs.
Byde ningasetofmessagetypes,whichMUSTberecognizedbyallimplementationsof OLSR,itwillbepossibletoextendtheprotocolthroughintroductionofadditionalmessage types, while still being able to maintain compatibility with older implementations. The REQUIREDmessagetypesforthecorefunctionalityofOLSR are:
HELLO-messages,performingthe taskof link sensing, neighbordetectionand MPR signaling,
TC-messages,performingthetaskoftopologydeclaration(advertisementoflinkstates).
MID-messages,performingthetaskofdeclaringthepresenceofmultipleinterfaceson anode.
Other messagetypesinclude those speci edin later sections,aswellaspossible future extensions such asmessagesenabling powerconservation /sleepmode, multicast routing, supportforunidirectionallinks,auto-con guration/addressassignmentetc.
3.5 Message Emission and Jitter
As abasicimplementation requirement, synchronization of control messagesSHOULD be avoided. As a consequence, OLSR control messages SHOULD beemitted such that they avoidsynchronization.
Emissionofcontroltra cfromneighboringnodesmay,forvariousreasons(mainlytimer interactionswithpacketprocessing),becomesynchronizedsuchthatseveralneighbornodes attempttotransmitcontroltra csimultaneously. Dependingonthenatureofthe underly-inglink-layer,thismayormaynotleadtocollisionsandhencemessageloss-possiblyloss ofseveralsubsequentmessagesofthesametype.
Toavoidsuchsynchronizations,thefollowingsimplestrategyforemittingcontrol mes-sages is proposed. A node SHOULD add an amount of jitter to the interval at which messagesare generated. The jitter must be a random value for each message generated. Thus,foranodeutilizingjitter:
Actualmessageinterval=MESSAGE_INTERVAL-jitter
Wherejitterisavalue,randomlyselectedfromtheinterval
0;MAXJITTER
andMESSAGE_INTERVALis thevalueofthemessageintervalspeci edforthe message being emitted(e.g. HELLO_INTERVAL forHELLO messages,TC_INTERVALfor TC-messagesetc.).
Jitter SHOULD also be introduced when forwarding messages. The following simple strategymay beadopted: whenamessageis tobeforwardedbyanode,it shouldbekept inthenodeduringashortperiod oftime:
Keepmessageperiod=jitter
Wherejitterisarandomvaluein[0,MAXJITTER].
Noticethatwhenthenodesendsacontrolmessage,theopportunitytopiggybackother messages (before their keeping period is expired) may be taken to reduce the number of packettransmissions.
Notice, that aminimal rateofcontrolmessagesisimposed. A nodeMAYsend control messagesatahigherrate,ifbene cialforaspeci c deployment.
4 Information Repositories
ThroughtheexchangeofOLSRcontrolmessages,eachnodeaccumulatesinformationabout thenetwork. Thisinformationisstoredaccordingtothedescriptionsinthissection.
4.1 Multiple Interface Association Information Base
Foreachdestinationinthenetwork,"InterfaceAssociationTuples"(I_iface_addr,I_main_addr, I_time)arerecorded. I_iface_addrisaninterfaceaddressofanode,I_main_addristhe mainaddressofthisnode. I_timespeci esthetimeatwhichthistupleexpiresandMUST beremoved.
Inanode, thesetof InterfaceAssociationTuplesis denotedthe "InterfaceAssociation Set".
4.2 Link Sensing: Local Link Information Base
Thelocallinkinformationbase storesinformationaboutlinkstoneighbors.
4.2.1 Link Set
A node records a set of "Link Tuples" (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, L_ASYM_time, L_time). L_local_iface_addr is the interface address of the local node (i.e. oneendpoint of the link), L_neighbor_iface_addris theinterface addressoftheneighbornode(i.e. theotherendpointofthelink),L_SYM_timeisthetime until which thelink is considered symmetric, L_ASYM_time is thetime until which the neighbor interfaceisconsidered heard, andL_timespeci es thetime atwhich thisrecord expiresandMUST beremoved. WhenL_SYM_timeandL_ASYM_timeareexpired,the linkisconsideredlost.
ThisinformationisusedwhendeclaringtheneighborinterfacesintheHELLOmessages. L_SYM_time is used to decidethe Link Typedeclared for the neighbor interface. If L_SYM_timeis notexpired, the link MUSTbe declaredsymmetric. If L_SYM_timeis expired,thelinkMUSTbedeclaredasymmetric.IfbothL_SYM_timeandL_ASYM_time areexpired,thelink MUSTbedeclaredlost.
Inanode,theset ofLinkTuplesaredenotedthe"LinkSet".
4.3 Neighbor Detection: Neighborhood Information Base
The neighborhood information base stores information about neighbors, 2-hop neighbors, MPRsandMPRselectors.
4.3.1 NeighborSet
Anoderecordsasetof"neighbortuples"(N_neighbor_main_addr,N_status,N_willingness), describingsymmetricneighbors.N_neighbor_main_addristhemainaddressofaneighbor, N_statusspeci esifthenodeisNOT_SYMorSYM.N_willingnessin anintegerbetween 0and7,andspeci esanodeswillingnesstocarrytra conbehalfofothernodes.
4.3.2 2-hop NeighborSet
Anoderecordsasetof"2-hoptuples"(N_neighbor_main_addr,N_2hop_addr,N_time), describingsymmetric(and,sinceMPRlinks byde nitionarealso symmetric,therebyalso MPR)linksbetweenitsneighborsandthesymmetric2-hopneighborhood. N_neighbor_main_addr is themain addressofaneighbor, N_2hop_addris themain addressof a2-hop neighbor withasymmetriclinktoN_neighbor_main_addr,andN_timespeci esthetimeatwhich thetupleexpiresandMUST beremoved.
Inanode,theset of2-hoptuplesaredenoted the"2-hopNeighborSet".
4.3.3 MPR Set
Anode maintainsaset ofneighborswhichareselectedasMPR.Theirmain addressesare listedintheMPRSet.
4.3.4 MPR Selector Set
A node recordsaset ofMPR-selector tuples (MS_main_addr,MS_time), describingthe neighborswhichhaveselectedthisnodeasaMPR.MS_main_addristhemainaddressof anode,whichhasselectedthisnodeasMPR.MS_timespeci esthetimeatwhich atuple expiresandMUST beremoved.
Inanode,theset ofMPR-selectortuplesaredenotedthe"MPRSelectorSet".
4.4 Topology Information Base
Each node in thenetwork maintainstopologyinformation aboutthe network. This infor-mationis acquiredfromTC-messagesandisusedforroutingtable calculations.
Thus,foreachdestinationinthenetwork,atleastone"TopologyTuple"(T_dest_addr, T_last_addr,T_seq, T_time) is recorded. T_dest_addris the main addressof anode, which may be reached in one hop from the node with the main address T_last_addr. Typically, T_last_addr is a MPR of T_dest_addr. T_seq is a sequence number, and T_timespeci esthetimeatwhichthistupleexpiresand MUST beremoved.
Inanode,theset ofTopologyTuples aredenotedthe"TopologySet".
5 Main Addresses and Multiple Interfaces
ForsingleOLSR interfacenodes, therelationshipbetweenanOLSR interfaceaddressand thecorrespondingmainaddressistrivial: themain addressis theOLSR interfaceaddress. Formultiple OLSRinterfacenodes,therelationshipbetweenOLSRinterfaceaddressesand main addresses is de ned through the exchange of Multiple Interface Declaration (MID) messages. ThissectiondescribeshowMIDmessagesareexchangedandprocessed.
EachnodewithmultipleinterfacesMUSTannounce,periodically,informationdescribing its interface con guration to other nodes in the network. This is accomplished through
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | OLSR Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | OLSR Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
Figure 2: LayoutofOLSR MIDmessages
ooding aMultipleInterfaceDeclarationmessageto allnodesin the networkthroughthe MPR oodingmechanism.
Eachnodeinthenetworkmaintainsinterfaceinformationabouttheother nodesinthe network. This information acquired from MID messages, emitted by nodes withmultiple interfacesparticipatingin theMANET, andisusedforroutingtablecalculations.
Speci cally, multiple interfacedeclarationassociatesmultiple interfacesto anode(and toamainaddress)throughpopulatingthemultipleinterfaceassociationbasein eachnode.
5.1 MID Message Format
TheproposedformatofaMID messageisasfollows:
This is sent as the data-portion of the general packet format described in section 3, withthe"MessageType"settoMID_MESSAGE.ThetimetoliveSHOULDbesetto255 (maximumvalue) todiusethemessageintotheentirenetworkandVtimeset accordingly tothevalueofMID_HOLD_TIME, asspeci edinsection18.3.
OLSR InterfaceAddress
This eldcontainstheaddressofanOLSRinterfaceofthenode,excludingthenodes main address(whichalreadyindicatedintheoriginatoraddress).
Allinterfaceaddressesotherthanthemainaddressoftheoriginatornodeareputinthe MIDmessage. Ifthemaximumallowedmessagesize(asimposedbythenetwork)isreached whiletherearestillinterfaceaddresseswhichhavenotbeeninsertedintotheMIDmessage, moreMID messagesaregenerateduntiltheentireinterfaceaddressesset hasbeensent.
5.2 MID Message Generation
AMID messageis sentbyanodein thenetwork todeclareitsmultipleinterfaces(if any). I.e., the MID message contains the list of interface addresses which are associated to its main address. The list of addresses can be partial in each MID message (e.g. due to
message size limitations, imposed by the network), but parsing of all MID messages de-scribingtheinterfacesetfromanodeMUSTbecompletewithinacertainrefreshingperiod (MID_INTERVAL). The informationdiused in the networkby these MID messageswill help each node to calculate its routing table. A node which has only a single interface addressparticipatingintheMANET(i.e. runningOLSR),MUSTNOTgenerateanyMID message.
Anodewithmoreinterfaces,whereonlyoneisparticipatingintheMANETandrunning OLSR(e.g. anodeisconnected toawirednetworkaswellastoaMANET)MUSTNOT generateanyMIDmessages.
A nodewithmoreinterfaces,where morethan oneisparticipatingin theMANETand runningOLSR MUSTgenerateMIDmessagesasspeci ed.
5.3 MID Message Forwarding
MIDmessagesarebroadcastandretransmittedbytheMPRsinordertodiusethemessages intheentirenetwork. The"defaultforwardingalgorithm"(describedinsection3MUSTbe usedforforwardingofMIDmessages.
5.4 MID Message Processing
Thetuplesin themultiple interfaceassociationset arerecordedwiththeinformation that isexchangedthroughMIDmessages.
UponreceivingaMIDmessage,the"validitytime"MUSTbecomputedfromtheVtime eldofthemessageheader(asdescribedinsection3.3.2). TheMultipleInterfaceAssociation InformationBaseSHOULDthenbeupdatedasfollows:
1. If the sender interface (NB: notoriginator) of this message is not in the symmetric 1-hopneighborhoodof thisnode,themessageMUSTbediscarded.
2. Foreach interfaceaddresslistedintheMIDmessage:
(a) ifthereexistsometupleintheinterfaceassociationsetwhere: I_iface_addr==interfaceaddress,AND
I_main_addr==originatoraddress, thentheholdingtimeofthattuple issetto:
I_time=currenttime+validitytime.
(b) Otherwise,anewtupleisrecordedintheinterfaceassociationsetwhere: I_iface_addr=interfaceaddress,
I_main_addr=originatoraddress, I_time=currenttime+validitytime.
5.5 Resolving a Main Address from an Interface Address
Ingeneral,theonlypartofOLSRrequiringuseof"interfaceaddresses"islinksensing. The remainingparts of OLSR operateon nodes, uniquelyidenti ed by their"main addresses" (eectively,themainaddressofanodeisits"nodeid"-whichforconveniencecorresponds to theaddressof oneof its interfaces). Ina network with only singleinterfacenodes, the mainaddressofanodewill,byde nition,beequaltotheinterfaceaddressofthenode. In networkswithmultipleinterfacenodesoperatingwithinacommonOLSRarea,itisrequired tobeabletomapanyinterfaceaddresstothecorrespondingmainaddress.
TheexchangeofMIDmessagesprovidesawayinwhichinterfaceinformationisacquired bynodesin thenetwork. Thispermitsidenti cationof anodes"mainaddress",givenone ofitsinterfaceaddresses.
Givenaninterfaceaddress:
1. ifthereexistssometupleintheinterfaceassociationsetwhere:
I_iface_addr==interfaceaddress
then theresultof themain addresssearch istheoriginator addressI_main_addrof thetuple.
2. Otherwise,theresultofthemainaddresssearchistheinterfaceaddressitself.
6 HELLO Message Format and Generation
A commonmechanism isemployedfor populatingthe local link information base andthe neighborhoodinformation base,namely periodicexchange ofHELLOmessages. Thus this sectiondescribesthegeneralHELLOmessagemechanism,followedbyadescriptionoflink sensingandtopologydetection,respectively.
6.1 HELLO Message Format
To accommodate for link sensing, neighborhood detection and MPR selection signalling, aswellastoaccommodate forfuture extensions,anapproachsimilarto theoverallpacket formatistaken. ThustheproposedformatofaHELLOmessageisasindicatedin gure3. Thisissentasthedata-portionofthegeneralpacketformatdescribedinsection3,with the"MessageType"settoHELLO_MESSAGE,theTTL eldsetto1(one)andVtimeset accordinglytothevalueofNEIGHB_HOLD_TIME,speci edin section18.3.
Reserved
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Reserved | Htime | Willingness | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Link Code | Reserved | Link Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
: . . . :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Link Code | Reserved | Link Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Neighbor Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
: :
: : (etc)
HTime
This eld speci es theHELLOemission intervalused bythe nodeon thisparticular interface,i.e. thetimebefore thetransmissionofthe nextHELLO(thisinformation maybeusedin advancedlink sensing,seesection14). TheHELLOemissioninterval is representedby its mantissa(four highest bits of Htime eld) and by its exponent (fourlowestbitsofHtime eld). Inotherwords:
HELLOemissioninterval=C(1+ a 16
)2 b
[inseconds]
where a is the integerrepresented bythe four highest bits of Htime eld and b the integerrepresentedbythefour lowest bitsof Htime eld. Theproposed valueofthe scalingfactorCisspeci edinsection18.
Willingness
This eld speci es the willingness of a node to carry and forward tra c for other nodes.
A node with willingness WILL_NEVER (see section REF:wc, for willingness con-stants) MUST never be selected as MPR by any node. A node with willingness WILL_ALWAYS MUST always be selected asMPR. By default, anode SHOULD advertiseawillingnessofWILL_DEFAULT.
LinkCode
This eldspeci esinformationsaboutthelinkbetweentheinterfaceofthesenderand thefollowinglistofneighborinterfaces. Italsospeci esinformationsaboutthestatus oftheneighbor.
Linkcodes,notknownbyanode,aresilentlydiscarded.
LinkMessageSize
Thesizeofthelinkmessage,countedinbytesandmeasuredfromthebeginningofthe "LinkCode" eld anduntilthenext"LinkCode" eld (or-ifthere arenomorelink types-theend ofthemessage).
NeighborInterfaceAddress
An addressoftheinterfaceofaneighbornode.
6.1.1 Link Code as Link Type and NeighborType Thisdocumentonlyspeci es processingofLinkCodes<16.
If the LinkCode valueis less orequal to 15, then it MUST be interpreted asholding twodierent elds,oftwobitseach, asillustratedin gure4.
7 6 5 4 3 2 1 0 +---+---+---+- --- ---+ --- ---- +--- --- -+-- ---- -+- ---- --+ | 0 | 0 | 0 | 0 | Neighbor Type | Link Type | +---+---+---+- --- ---+ --- ---- +--- --- -+-- ---- -+- ---- --+
Figure4: Linkcodesandneighbortypes
UNSPEC_LINK
indicatingthatnospeci cinformationaboutthelinks isgiven. ASYM_LINK
indicatingthatthelinksareasymmetric (i.e. theneighborinterfaceis"heard"). SYM_LINK
indicatingthatthelinksaresymmetricwiththeinterface. LOST_LINK
indicatingthatthelinkshavebeenlost.
Thefollowingthree"NeighborTypes"areREQUIREDbyOLSR:
SYM_NEIGH
indicatingthattheneighborshaveatleastonesymmetricallinkwiththisnode. MPR_NEIGH
indicatingthattheneighborshaveatleastonesymmetricallinkANDhavebeenbeen selectedasMPRbythesender.
NOT_NEIGH
indicating that the nodes are either no longer or havenot yet become symmetrical neighbors.
NotethatanimplementationshouldbecarefulinnotconfusingLinkTypewithNeighbor Typenortheconstants(confusingSYM_NEIGHwithSYM_LINK forinstance).
Alink codeadvertising:
LinkType== SYM_LINKAND NeighborType==NOT_NEIGH
is invalid, and any links adverticed as such MUST be silently discarded without any processing.
Likewise a NeighborType eld advertising a numerical value which is not one of the constantsSYM_NEIGH,MPR_NEIGH,NOT_NEIGH,isinvalid,andanylinksadverticed assuchMUSTbesilentlydiscardedwithoutanyprocessing.
6.2 HELLO Message Generation
ThisinvolvestransmittingtheLinkSet,theNeighborSetandtheMPRSet. Inprinciple,a HELLOmessageservesthree independenttasks:
link sensing
neighbordetection
MPRselectionsignaling
Threetasksareallarebasedonperiodicinformationexchangewithinanodes neighbor-hood, andservethecommonpurpose of"local topologydiscovery". AHELLOmessageis thereforegeneratedbasedontheinformationstoredintheLocalLinkSet,theNeighborSet andtheMPRSetfrom thelocal linkinformationbase.
Anodemustperformlinksensingoneachinterface,inordertodetectlinksbetweenthe interfaceandneighborinterfaces. Furthermore,anodemustadvertiseitsentiresymmetric 1-hopneighborhood on each interfacein order to perform neighbor detection. Hence, for a given interface, a HELLO message will contain a list of links on that interface (with associated link types), as well as a list of the entire neighborhood (with an associated neighbortypes).
TheVtime eldissetsuchthatitcorrespondstothevalueofthenode'sNEIGHB_HOLD_TIME parameter. The Htime eld is set such that it corresponds to the value of the node's HELLO_INTERVALparameter(seesection18.3).
The Willingness eld is set such that it corresponds to the node's willingness to for-wardtra c onbehalf ofother nodes(seesection 18.8). Anode MUSTadvertise thesame willingnessonallinterfaces.
The lists of addressesdeclared in a HELLOmessage isa list of neighborinterface ad-dressescomputedasfollows:
ForeachtupleintheLinkSet,where:
1. L_local_iface_addristheinterfacewheretheHELLOistobetransmitted,andwhere L_time >= current time (i.e. not expired), L_neighbor_iface_addr is advertised with:
(a) TheLinkTypesetaccordingtothefollowing: ifL_SYM_time>=currenttime(notexpired) LinkType=SYM_LINK
2. Otherwise,if:
L_ASYM_time>=currenttime(not expired)AND L_SYM_time<currenttime(expired)
LinkType=ASYM_LINK
3. Otherwise,if
L_ASYM_time<currenttime(expired)AND L_SYM_time<currenttime(expired)
then:
LinkType=LOST_LINK
4. TheNeighborTypeissetaccordingtothefollowing:
(a) Ifthemainaddress,correspondingtoL_neighbor_iface_addr,isincludedinthe MPRset:
NeighborType=MPR_NEIGH
(b) Otherwise,ifthemain address,correspondingto L_neighbor_iface_addr,is in-cludedin theneighborset:
i. ifN_status==SYM
Neighbor Type=SYM_NEIGH ii. Otherwise,ifN_status== NOT_SYM
Neighbor Type=NOT_NEIGH
Foreachtuplein theNeighborSet,forwhichnoL_neighbor_iface_addrfroman asso-ciated link tuple hasbeenadvertised by thepreviousalgorithm, N_neighbor_main_addr isadvertisedwith:
LinkType=UNSPEC_LINK,
Neighbor Typesetas describedinstep2above/
Foranodewith asingleOLSRinterface,themain addressis simplytheaddressofthe OLSRinterface. I.e. foranodewithasingleOLSRinterface,themainaddress, correspond-ingtoL_neighbor_iface_addrissimplyL_neighbor_iface_addr.
A HELLO message can be partial (e.g. due to message size limitations, imposed by the network), the rule being the following, on each interface: each link and each neigh-bor node MUST be cited at least once within a predetermined refreshing period, RE-FRESH_INTERVAL.Tokeeptrackoffastconnectivitychanges,aHELLOmessagemustbe sentatleasteveryHELLO_INTERVALperiod,smallerthanorequaltoREFRESH_INTERVAL.
Notice that forlimitingthe impactfrom lossofcontrolmessages,it is desirablethat a message(plus thegenericpacketheader)can tintoasingleMACframe.
6.3 HELLO Message Forwarding
EachHELLOmessagegeneratedisbroadcastbythenodeononeinterfacetoitsneighbors. HELLOmessagesMUSTneverbeforwarded.
6.4 HELLO Message Processing
A node processes incoming HELLO messages for the purpose of conducting link sensing (detailed in section 7), neighbor detection and MPR selector set population (detailed in section8.
7 Link Sensing
Linksensingpopulatesthelocallinkinformationbase. Linksensingisexclusivelyconcerned with OLSR interface addresses and the ability to exchange packets between such OLSR interfaces.
ThemechanismforlinksensingistheperiodicexchangeofHELLOmessages.
7.1 Populating the Link Set
TheLinkSetispopulatedwithinformationonlinkstoneighbornodes. Theprocessof pop-ulatingthissetisdenoted"linksensing"andisperformedusingHELLOmessageexchange, updatingalocallinkinformationbase ineachnode.
Eachnodeshoulddetectthelinksbetweenitselfandneighbornodes. Uncertaintiesover radio propagation maymakesome links unidirectional. Consequently, alllinks MUST be checkedinbothdirections inordertobeconsideredvalid.
A"link"isdescribedbyapairofinterfaces: alocalandaremoteinterface.
Forthepurposeof link sensing,eachneighbornode (morespeci cally, thelink toeach neighbor) has an associated status of either "symmetric" or "asymmetric". "Symmetric" indicates, that the link to that neighbor node has been veri ed to be bi-directional, i.e. it is possible to transmit data in both directions. "Asymmetric" indicates that HELLO messagesfrom the node have been heard(i.e. communicationfrom the neighbor node is possible), however it is not con rmed that this nodeis also ableto receive messages(i.e. communicationtotheneighbornodeisnotcon rmed).
Theinformation, acquired throughandusedby thelink sensing,isaccumulatedin the linkset.
7.1.1 HELLO Message Processing
The"OriginatorAddress"ofaHELLOmessageisthemainaddressofthenode,which has emittedthemessage.
UponreceivingaHELLOmessage, anode SHOULDupdate itsLinkSet. Notice, that aHELLOmessageMUSTneitherbeforwardednorberecordedintheduplicateset.
Upon receiving a HELLO message, the "validity time"MUST be computed from the Vtime eldofthemessageheader(seesectionREF:msghdr). Then,theLinkSetSHOULD beupdatedasfollows:
1. UponreceivingaHELLOmessage,ifthereexistsnolink tuplewith
L_neighbor_iface_addr==SourceAddress
anewtupleis createdwith
L_neighbor_iface_addr=SourceAddress
L_local_iface_addr=AddressoftheinterfacewhichreceivedtheHELLO mes-sage
L_SYM_time=currenttime-1(expired) L_time=currenttime+validitytime
2. Thetuple(existingornew)with:
L_neighbor_iface_addr==SourceAddress
isthenmodi edas follows:
(a) L_ASYM_time=currenttime+validitytime;
(b) ifthenode ndstheaddressoftheinterfacewhichreceivedtheHELLOmessage among the addresses listed in the link message then the tuple is modi ed as follows:
i. ifLinkTypeisequalto LOST_LINKthen
L_SYM_time=currenttime-1(i.e. expired)
ii. else,ifLinkTypeisequaltoSYM_LINKorASYM_LINKthen: L_SYM_time=currenttime+validitytime,
L_time=L_SYM_time+NEIGHB_HOLD_TIME (c) L_time=max(L_time,L_ASYM_time)
aTheaboveruleforsettingL_timeisthefollowing:alinklosingitssymmetrySHOULD still be advertised during at least the duration of the "validity time" advertised in the generatedHELLO.Thisallowsneighborstodetectthelink breakage.
8 Neighbor Detection
Neighbordetection populatesthe neighborhood information base and concerns itself with nodes and node main addresses. The relationship betweenOLSR interfaceaddresses and mainaddressesisdescribedin section5.
8.1 Populating the Neighbor Set
A node maintains a set of neighbor tuples, based on the link tuples. This information is updatedaccordingtochangesin theLinkSet.
The LinkSet keepsthe information aboutthe links, whilethe NeighborSet keepsthe informationabouttheneighbors. Thereisaclearassociationbetweenthosetwosets,since anodeisaneighborofanothernodeifandonlyifthereisatleastonelinkbetweenthetwo nodes.
Inanycase,theformalcorrespondencebetweenlinksandneighborsisde nedasfollows: The "associated neighbor tuple" of a link tuple, is, if it exists, the neighbor tuple
where:
N_neighbor_main_addr==mainaddressofL_neighbor_iface_addr
The"associatedlinktuples"ofaneighbortuple, areallthelink tuples,where:
N_neighbor_main_addr==mainaddressofL_neighbor_iface_addr
The NeighborSet MUST bepopulated by maintaining the propercorrespondence be-tweenlink tuplesandassociatedneighbortuples,asfollows:
Creation
Each time a link appears, that is, each time alink tuple is created, the associated neighbortupleMUSTbecreated,ifitdoesn'talreadyexist,withthefollowingvalues:
N_neighbor_main_addr =main addressof L_neighbor_iface_addr (fromthe link tuple)
Inanycase,theN_statusMUSTthenbecomputedasdescribedin thenextstep. Update
Eachtimealinkchanges,thatis,eachtimetheinformationofalinktupleismodi ed, the node MUST ensurethat the N_statusof the associated neighbortuple respects theproperty:
Iftheneighborhasanyassociatedlinktuple which indicatesasymmetricallink (i.e. withL_SYM_time>= currenttime),then:
N_statusissetto SYM elseN_statusisset toNOT_SYM
Removal
.nhEachtimealinkisdeleted,thatis,eachtimealinktupleisremoved,theassociated neighbortupleMUSTberemovedifithasnolongeranyassociatedlinktuples. These rules ensurethat there is exactlyoneassociated neighbortuple fora link tuple, andthateveryneighbortuplehasatleastoneassociatedlinktuple.
8.1.1 HELLO Message Processing
The"OriginatorAddress"ofaHELLOmessageisthemainaddressofthenode,which has emittedthemessage. Likewise,the"willingness"MUSTbecomputedfromtheWillingness eldoftheHELLOmessage(seesection6).
UponreceivingaHELLOmessage,anodeSHOULD rstupdateitsLinkSetasdescribed before. It SHOULDthenupdateitsNeighborSetasfollows:
if the OriginatorAddress is the N_neighbor_main_addr from a neighbortuple in-cludedin theNeighborSet:
then,theneighbortuple SHOULDbeupdatedasfollows: * N_willingness=willingnessfromtheHELLOmessage
8.2 Populating the 2-hop Neighbor Set
The2-hopneighborsetdescribesthesetofnodeswhichhaveasymmetriclinktoasymmetric neighbor. ThisinformationsetismaintainedthroughperiodicexchangeofHELLOmessages asdescribedin thissection.
8.2.1 HELLO Message Processing
The"OriginatorAddress"ofaHELLOmessageisthemainaddressofthenode,which has emittedthemessage.
UponreceivingaHELLOmessagefromasymmetricneighbor,anodeSHOULDupdate its2-hopNeighborSet. Notice,thataHELLOmessageMUSTneitherbeforwardednorbe recordedintheduplicateset.
Upon receiving a HELLO message, the "validity time" MUST be computed from the Vtime eldofthemessageheader(seesection3.3.2).
Ifthe OriginatorAddressisthemain addressofaL_neighbor_iface_addrfrom alink tupleincludedintheLinkSetwith
L_SYM_time>=currenttime(not expired)
(in other words: if the Originator Address is a symmetric neighbor) then the 2-hop NeighborSetSHOULDbeupdatedasfollows:
1. foreachaddress(henceforth: 2-hopneighboraddress),listed in theHELLOmessage withNeighborTypeequaltoSYM_NEIGHorMPR_NEIGH:
(a) if the main addressof the2-hop neighbor address =main addressof receiving node:
silentlydiscardthe2-hopneighboraddress. (inotherwords: anodeisnotitsown2-hopneighbor).
(b) Otherwise,a2-hoptupleiscreatedwith:
N_neighbor_main_addr=OriginatorAddress; N_2hop_addr=mainaddressofthe2-hopneighbor; N_time=currenttime+validitytime.
ThistuplemayreplaceanoldersimilartuplewithsameN_neighbor_main_addr andN_2hop_addrvalues.
2. For each 2-hop node listed in the HELLO message with Neighbor Type equal to NOT_NEIGH,all2-hoptuples where:
N_neighbor_main_addr==OriginatorAddressAND N_2hop_addr==main addressofthe2-hopneighbor
aredeleted.
8.3 Populating the MPR set
MPRsareusedto ood controlmessagesfromanodeinto thenetworkwhilereducingthe number of retransmissions that will occur in a region. Thus, the concept of MPR is an optimizationofaclassical oodingmechanism.
Each node in the network selects, independently, itsown set of MPRsamong its sym-metric1-hopneighborhood. ThesymmetriclinkswithMPRsareadvertisedwithLinkType MPR_NEIGHinsteadofSYM_NEIGHinHELLOmessages.
TheMPRsetMUSTbecalculatedbyanodeinsuchawaythatit,throughtheneighbors intheMPR-set,canreachallsymmetricstrict2-hopneighbors.(Noticethatanode,a,which isadirect neighborofanothernode, b,isnotalsoastrict 2-hopneighborofnodeb). This meansthattheunionofthesymmetric1-hopneighborhoodsoftheMPRnodescontainsthe symmetric strict 2-hop neighborhood. MPR set recalculation should occur when changes aredetectedin theneighborhoodorinthe2-hopneighborhood.
MPRsarecomputedperinterface,theunionoftheMPRsetsofeachinterfacemakeup theMPRset forthenode.
WhileitisnotessentialthattheMPRsetisminimal,itisessentialthatallstrict2-hop neighbors can be reached through the selected MPR nodes. A node SHOULD select an MPR set such that anystrict 2-hop neighbor is coveredby at least oneMPRnode. This ensuresthat theoverheadoftheprotocoliskeptataminimum.
The MPR set cancoincide with the entire symmetricneighbor set. This could bethe caseat networkinitialization(andwillcorrespondtoclassiclink-staterouting).
8.3.1 MPR Computation
Thefollowingspeci esaproposedheuristicforselectionofMPRs. ItconstructsanMPR-set thatenablesanodetoreachanynodeinthesymmetricalstrict2-hopneighborhoodthrough
relayingby one MPRnodewith willingnessdierentfrom WILL_NEVER. Theheuristic MUST be applied per interface,I. TheMPR set fora nodeis the unionof theMPR sets foundforeachinterface. Thefollowingterminologywillbeusedindescribingtheheuristics:
neighbor ofaninterface
anodeisa"neighborofaninterface"iftheinterface(onthelocalnode)hasalinkto anyoneinterfaceof theneighbor node.
2-hopneighborsreachablefromaninterface
the list of 2-hop neighbors of the node that can be reached from neighbors of this interface.
MPRsetof aninterface
a(sub)setoftheneighborsofaninterfacewithawillingnessdierentfromWILL_NEVER, selected such that throughthese selected nodes, allstrict 2-hop neighbors reachable from thatinterfacearereachable.
N
Nisthesubsetofneighborsofthenode,whichareneighboroftheinterfaceI.
N2:
Thesetoftwo-hopneighborsreachablefromtheinterfaceI,excluding:
thenodesonlyreachablebymembersofNwithwillingnessWILL_NEVER thenodeperformingthecomputation
all thesymmetric neighbors: the nodes forwhich there exists asymmetric link tothisnodeonsomeinterface.
D(y):
Thedegreeof anonehop neighbornodey(where yisamemberofN),is de ned as the number of symmetric neighbors of node y, EXCLUDING all the members of N andEXCLUDINGthenodeperformingthecomputation.
Theproposed heuristicisasfollows:
1. Start with an MPR set made of all members of N with N_willingness equal to WILL_ALWAYS
2. CalculateD(y),whereyisamemberof N,forallnodesin N.
3. Addto theMPRsetthosenodesinN, whicharethe*only*nodestoprovide reacha-bilityto anodeinN2. I.e. ifnodeb inN2canbereachedonlythroughasymmetric link to node a in N, then add node ato the MPR set. Removethe nodes from N2 whicharenowcoveredbyanodeintheMPRset.
4. WhilethereexistnodesinN2whicharenotcoveredbyatleastonenodeintheMPR set:
(a) For each node in N, calculate the reachability, i.e. the number of nodes in N2 which arenot yet coveredbyat least onenode in the MPRset, and which are reachablethroughthisonehopneighbor;
(b) SelectasaMPRthenodewithhighestN_willingnessamongthenodesinNwith non-zeroreachability. Incase of multiple choice selectthe node which provides reachabilityto themaximumnumberofnodesin N2. Incase ofmultiple nodes providing thesameamountof reachability,selectthenode asMPRwhoseD(y) is greater. Removethenodesfrom N2which arenowcoveredby anodein the MPRset.
(c) Anode'sMPRsetisgeneratedfromtheunionoftheMPRsetsforeachinterface. As an optimization, process each node, y, in the MPR set in increasing order of N_willingness. If all nodes in N2 are still covered by at least one node in the MPR set excluding node y, and if N_willingness of node yis smallerthan WILL_ALWAYS,thennodeyMAYberemovedfromtheMPRset.
Otheralgorithms,aswellasimprovementsoverthisalgorithm,arepossible. Forexample, assumethatin amultiple-interfacescenariothereexists morethanonelinkbetweennodes 'a' and 'b'. If node 'a' has selected node 'b' as MPR for oneof its interfaces, then node 'b'canbeselectedas MPRwithoutadditionalperformancelossbyanyother interfaceson node'a'.
8.4 Populating the MPR Selector Set
TheMPRselectorsetof anode, n,ispopulatedbythemain addressesofthenodeswhich haveselectednasMPR.MPRselectionissignaledthroughHELLOmessages.
8.4.1 HELLO Message Processing
UponreceivingaHELLOmessage,ifanode ndsoneofitsowninterfaceaddressesinthe listwith aNeighbor Typeequalto MPR_NEIGH, informationfrom theHELLO message mustberecordedintheMPRSelectorSet.
The"validitytime"MUSTbecomputedfromtheVtime eldofthemessageheader(see section3.3.2). TheMPRSelectorSetSHOULDthenbeupdatedasfollows:
1. Ifthereexists noMPRselectortuplewith:
MS_main_addr==OriginatorAddress
thenanewtupleis createdwith:
2. Thetuple(neworotherwise)with
MS_main_addr==OriginatorAddress
isthenmodi edasfollows:
MS_time=currenttime+validitytime.
Deletion ofMPR selector tuples occurs in case ofexpiration of the timerorin caseof linkbreakageasdescribedinthe"Neighborhoodand2-hopNeighborhoodChanges".
8.5 Neighborhood and 2-hop Neighborhood Changes Achangein theneighborhoodisdetectedwhen:
TheL_SYM_time eld ofalinktuple expires. Thisisconsidered asaneighborloss ifthe linkdescribedbythe expiredtuplewasthelast link withaneighbornode (on thecontrary,alink withaninterfacemaybreakwhilealinkwithanotherinterfaceof theneighbornoderemainswithoutbeingobservedasaneighborhoodchange).
A new link tuple is inserted in the Link Set with a non expired L_SYM_time or atuple withexpired L_SYM_timeis modi edso that L_SYM_timebecomes non-expired. Thisis considered asaneighborappearance ifthere waspreviouslyno link tupledescribingalink withthecorrespondingneighbornode.
Achange inthe2-hopneighborhoodisdetectedwhena2-hopneighbortupleexpiresor isdeletedaccordingtosection8.2.
Thefollowingprocessingoccurs whenchanges intheneighborhood orthe2-hop neigh-borhoodaredetected:
In case of neighbor loss, all 2-hop tuples with N_neighbor_main_addr == Main AddressoftheneighborMUSTbedeleted.
In case of neighbor loss, all MPR selector tuples with MS_main_addr == Main AddressoftheneighborMUSTbedeleted
TheMPRsetMUSTbere-calculatedwhenaneighborappearanceorlossisdetected, orwhen achangein the2-hopneighborhoodisdetected.
9 Topology Discovery
Thelinksensingandneighbordetectionpartoftheprotocolbasicallyoers,toeachnode,a listofneighborswithwhichitcancommunicatedirectlyand,incombinationwiththePacket Format and Forwarding part, an optimized ooding mechanism through MPRs. Based on this, topology information is disseminated through the network. The present section describeswhat partoftheinformation givenbythe linksensingand neighbordetectionis disseminatedtotheentirenetworkandhowitisusedtoconstructroutes.
Routesareconstructedthroughadvertisedlinksandlinkswithneighbors. Anodemust atleast disseminatelinks betweenitselfand thenodesin itsMPR-selectorset, inorder to providesu cientinformationtoenablerouting.
9.1 TC Message Format
TheproposedformatofaTCmessageisasfollows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
| ANSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Advertised Neighbor Main Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+ | Advertised Neighbor Main Address | +-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ -+-+ -+- +-+- +-+- +-+ -+-+ -+-+ -+- +-+- +-+
Thisissentasthedata-portionofthegeneralmessageformatwiththe"MessageType"settoTC_MESSAGE. ThetimetoliveSHOULDbesetto 255(maximumvalue) todiusethemessageintothe entirenetwork andVtimesetaccordinglytothevalueofTOP_HOLD_TIME,asspeci edinsection18.3.
AdvertisedNeighborSequenceNumber(ANSN)
A sequence number isassociated with the advertisedneighbor set. Every time a node detects a changeinitsadvertisedneighborset,itincrementsthissequencenumber("Wraparound"ishandled as describedinsection18.10). Thisnumber issentinthisANSN eldofthe TCmessagetokeep trackofthemostrecentinformation. WhenanodereceivesaTCmessage,itcandecideonthebasis of thisAdvertisedNeighbor SequenceNumber,whether ornot the receivedinformationaboutthe advertisedneighborsoftheoriginatornodeismorerecentthanwhatitalreadyhas.
AdvertisedNeighborMainAddress
This eldcontainsthemainaddressofaneighbornode. Allmainaddressesoftheadvertisedneighbors oftheOriginatornodeareputintheTCmessage. Ifthemaximumallowedmessagesize(asimposed bythenetwork)isreachedwhiletherearestilladvertisedneighboraddresses whichhavenotbeen insertedintotheTC-message,moreTCmessageswillbegenerateduntiltheentireadvertisedneighbor sethasbeensent. Extramainaddressesofneighbornodesmaybeincluded,ifredundancyisdesired. Reserved
9.2 Advertised Neighbor Set
ATC messageissentbya nodeinthenetwork todeclareaset oflinks,calledadvertisedlinkset which MUSTincludeatleastthelinkstoallnodesofitsMPRSelectorset,i.e.,theneighborswhichhaveselected thesendernodeasaMPR.
If,forsomereason,itisrequiredtodistributeredundantTCinformation,refertosection15.
Thesequencenumber(ANSN)associatedwiththeadvertisedneighborsetisalsosentwiththelist.The ANSNnumberMUSTbeincrementedwhenlinksareremovedfromtheadvertisedneighborset;theANSN numberSHOULDbeincrementedwhenlinksareaddedtotheadvertisedneighborset.
9.3 TC Message Generation
Inorderto buildthe topology informationbase,eachnode,which hasbeen selectedasMPR,broadcasts TopologyControl(TC)messages.TCmessagesare oodedtoallnodesinthenetworkandtakeadvantage ofMPRs. MPRsenableabetterscalabilityinthedistributionoftopologyinformation[1].
ThelistofaddressescanbepartialineachTCmessage(e.g.duetomessagesizelimitations,imposedby thenetwork),butparsingofallTCmessagesdescribingtheadvertisedlinksetofanodeMUSTbecomplete withinacertainrefreshingperiod(TC_INTERVAL).TheinformationdiusedinthenetworkbytheseTC messageswillhelpeachnodecalculateitsroutingtable.
Whenthe advertisedlinkset ofa nodebecomesempty,it SHOULDstillsend(empty)TC-messages duringtheadurationequaltothe"validitytime"(typically,thiswillbeequaltoTC_HOLD_TIME)ofits previouslyemittedTC-messages,inordertoinvalidatethepreviousTC-messages. It SHOULDthen stop sendingTC-messagesuntilsomenodeisinsertedinitsadvertisedlinkset.
Anode MAYtransmit additionalTC-messages to increaseits reactiveness to linkfailures. When a changetotheMPRselectorsetisdetectedandthischangecanbeattributedtoalinkfailure,aTC-message SHOULDbetransmittedafterashorterintervalthanTC_INTERVAL.
9.4 TC Message Forwarding
TCmessagesarebroadcast andretransmittedbythe MPRsinordertodiusethemessagesinthe entire network. TCmessagesMUSTbeforwardedaccordingtothe"defaultforwardingalgorithm".
9.5 TC Message Processing
UponreceivingaTCmessage,the"validitytime"MUSTbecomputedfromtheVtime eldofthemessage header(seesection3.3.2). ThetopologysetSHOULDthen beupdatedasfollows(usingsection18.10for comparisonofANSN):
1. Ifthesenderinterface(NB:notoriginator)ofthismessageisnotinthesymmetric1-hopneighborhood ofthisnode,themessageMUSTbediscarded.
2. Ifthereexistsometupleinthetopologysetwhere: T_last_addr==originatoraddressAND T_seq>ANSN,
then furtherprocessingof thisTC messageMUST NOTbeperformedandthe messageMUSTbe silentlydiscarded(case:messagereceivedoutoforder).
3. Alltuplesinthetopologysetwhere:
T_last_addr==originatoraddressAND T_seq<ANSN
