Https WWW - Ietf.org RFC Rfc2328

3/2/2015
https://www.ietf.org/rfc/rfc2328.txt
NetworkWorkingGroupJ.Moy
RequestforComments:2328AscendCommunications,Inc.
STD:54April1998
Obsoletes:2178
Category:StandardsTrack
OSPFVersion2
StatusofthisMemo
ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemois
unlimited.
CopyrightNotice
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Abstract
Thismemodocumentsversion2oftheOSPFprotocol.OSPFisa
linkstateroutingprotocol.Itisdesignedtoberuninternaltoa
singleAutonomousSystem.EachOSPFroutermaintainsanidentical
databasedescribingtheAutonomousSystem'stopology.Fromthis
database,aroutingtableiscalculatedbyconstructingashortest
pathtree.
OSPFrecalculatesroutesquicklyinthefaceoftopologicalchanges,
utilizingaminimumofroutingprotocoltraffic.OSPFprovides
supportforequalcostmultipath.Anarearoutingcapabilityis
provided,enablinganadditionallevelofroutingprotectionanda
reductioninroutingprotocoltraffic.Inaddition,allOSPF
routingprotocolexchangesareauthenticated.
ThedifferencesbetweenthismemoandRFC2178areexplainedin
AppendixG.Alldifferencesarebackwardcompatibleinnature.
MoyStandardsTrack[Page1]
RFC2328OSPFVersion2April1998
ImplementationsofthismemoandofRFCs2178,1583,and1247will
interoperate.
Pleasesendcommentstoospf@gated.cornell.edu.
TableofContents
1Introduction...........................................6
1.1ProtocolOverview......................................6
1.2Definitionsofcommonlyusedterms.....................8
1/188
3/2/2015
1.3Briefhistoryoflinkstateroutingtechnology........11
1.4Organizationofthisdocument.........................12
1.5Acknowledgments.......................................12
2Thelinkstatedatabase:organizationandcalculations13
2.1Representationofroutersandnetworks................13
2.1.1Representationofnonbroadcastnetworks..............15
2.1.2Anexamplelinkstatedatabase........................18
2.2Theshortestpathtree................................21
2.3Useofexternalroutinginformation...................23
2.4Equalcostmultipath..................................26
3SplittingtheASintoAreas...........................26
3.1ThebackboneoftheAutonomousSystem.................27
3.2Interarearouting....................................27
3.3Classificationofrouters.............................28
3.4Asampleareaconfiguration...........................29
3.5IPsubnettingsupport.................................35
3.6Supportingstubareas.................................37
3.7Partitionsofareas...................................38
4FunctionalSummary....................................40
4.1Interarearouting....................................41
4.2ASexternalroutes....................................41
4.3Routingprotocolpackets..............................42
4.4Basicimplementationrequirements.....................43
4.5OptionalOSPFcapabilities............................46
5Protocoldatastructures..............................47
6TheAreaDataStructure...............................49
7BringingUpAdjacencies...............................52
7.1TheHelloProtocol....................................52
7.2TheSynchronizationofDatabases......................53
7.3TheDesignatedRouter.................................54
7.4TheBackupDesignatedRouter..........................56
7.5Thegraphofadjacencies..............................56
8ProtocolPacketProcessing............................58
8.1Sendingprotocolpackets..............................58
8.2Receivingprotocolpackets............................61
9TheInterfaceDataStructure..........................63
9.1Interfacestates......................................67
9.2Eventscausinginterfacestatechanges................70
9.3TheInterfacestatemachine...........................72
9.4ElectingtheDesignatedRouter........................75
9.5SendingHellopackets.................................77
9.5.1SendingHellopacketsonNBMAnetworks................79
10TheNeighborDataStructure...........................80
10.1Neighborstates.......................................83
10.2Eventscausingneighborstatechanges.................87
10.3TheNeighborstatemachine............................89
10.4Whethertobecomeadjacent............................95
10.5ReceivingHelloPackets...............................96
10.6ReceivingDatabaseDescriptionPackets................99
10.7ReceivingLinkStateRequestPackets.................102
10.8SendingDatabaseDescriptionPackets.................103
10.9SendingLinkStateRequestPackets...................104
10.10AnExample...........................................105
11TheRoutingTableStructure..........................107
11.1Routingtablelookup.................................111
11.2Sampleroutingtable,withoutareas..................111
11.3Sampleroutingtable,withareas.....................112
2/188
3/2/2015
12LinkStateAdvertisements(LSAs).....................115
12.1TheLSAHeader.......................................116
12.1.1LSage...............................................116
12.1.2Options..............................................117
12.1.3LStype..............................................117
12.1.4LinkStateID........................................117
12.1.5AdvertisingRouter...................................119
12.1.6LSsequencenumber...................................120
12.1.7LSchecksum..........................................121
12.2Thelinkstatedatabase..............................121
12.3RepresentationofTOS................................122
12.4OriginatingLSAs.....................................123
12.4.1RouterLSAs..........................................126
12.4.1.1Describingpointtopointinterfaces.................130
12.4.1.2DescribingbroadcastandNBMAinterfaces.............130
12.4.1.3Describingvirtuallinks.............................131
12.4.1.4DescribingPointtoMultiPointinterfaces............131
12.4.1.5ExamplesofrouterLSAs..............................132
12.4.2NetworkLSAs.........................................133
12.4.2.1ExamplesofnetworkLSAs.............................134
12.4.3SummaryLSAs.........................................135
12.4.3.1OriginatingsummaryLSAsintostubareas.............137
12.4.3.2ExamplesofsummaryLSAs.............................138
12.4.4ASexternalLSAs.....................................139
12.4.4.1ExamplesofASexternalLSAs.........................140
13TheFloodingProcedure...............................143
13.1DeterminingwhichLSAisnewer.......................146
13.2InstallingLSAsinthedatabase......................147
13.3Nextstepinthefloodingprocedure..................148
13.4ReceivingselforiginatedLSAs.......................151
13.5SendingLinkStateAcknowledgmentpackets............152
13.6RetransmittingLSAs..................................154
13.7Receivinglinkstateacknowledgments.................155
14AgingTheLinkStateDatabase........................156
14.1PrematureagingofLSAs..............................157
15VirtualLinks........................................158
16Calculationoftheroutingtable.....................160
16.1Calculatingtheshortestpathtreeforanarea.......161
16.1.1Thenexthopcalculation.............................167
16.2Calculatingtheinterarearoutes....................178
16.3Examiningtransitareas'summaryLSAs................170
16.4CalculatingASexternalroutes.......................173
16.4.1Externalpathpreferences............................175
16.5IncrementalupdatessummaryLSAs..................175
16.6IncrementalupdatesASexternalLSAs..............177
16.7Eventsgeneratedasaresultofroutingtablechanges177
16.8Equalcostmultipath.................................178
Footnotes............................................179
References...........................................183
AOSPFdataformats....................................185
A.1EncapsulationofOSPFpackets........................185
A.2TheOptionsfield....................................187
A.3OSPFPacketFormats..................................189
A.3.1TheOSPFpacketheader...............................190
A.3.2TheHellopacket.....................................193
A.3.3TheDatabaseDescriptionpacket......................195
A.3.4TheLinkStateRequestpacket........................197
3/188
3/2/2015
A.3.5TheLinkStateUpdatepacket.........................199
A.3.6TheLinkStateAcknowledgmentpacket.................201
A.4LSAformats..........................................203
A.4.1TheLSAheader.......................................204
A.4.2RouterLSAs..........................................206
A.4.3NetworkLSAs.........................................210
A.4.4SummaryLSAs.........................................212
A.4.5ASexternalLSAs.....................................214
BArchitecturalConstants..............................217
CConfigurableConstants...............................219
C.1Globalparameters....................................219
C.2Areaparameters......................................220
C.3Routerinterfaceparameters..........................221
C.4Virtuallinkparameters..............................224
C.5NBMAnetworkparameters..............................224
C.6PointtoMultiPointnetworkparameters...............225
C.7Hostrouteparameters................................226
DAuthentication.......................................227
D.1Nullauthentication..................................227
D.2Simplepasswordauthentication.......................228
D.3Cryptographicauthentication.........................228
D.4Messagegeneration...................................231
D.4.1GeneratingNullauthentication.......................231
D.4.2GeneratingSimplepasswordauthentication............232
D.4.3GeneratingCryptographicauthentication..............232
D.5Messageverification.................................234
D.5.1VerifyingNullauthentication........................234
D.5.2VerifyingSimplepasswordauthentication.............234
D.5.3VerifyingCryptographicauthentication...............235
EAnalgorithmforassigningLinkStateIDs............236
FMultipleinterfacestothesamenetwork/subnet.......239
GDifferencesfromRFC2178............................240
G.1Floodingmodifications...............................240
G.2Changestoexternalpathpreferences.................241
G.3Incompleteresolutionofvirtualnexthops...........241
G.4Routingtablelookup.................................241
SecurityConsiderations..............................243
Author'sAddress.....................................243
FullCopyrightStatement.............................244
1.Introduction
ThisdocumentisaspecificationoftheOpenShortestPathFirst
(OSPF)TCP/IPinternetroutingprotocol.OSPFisclassifiedasan
InteriorGatewayProtocol(IGP).Thismeansthatitdistributes
4/188
3/2/2015
routinginformationbetweenroutersbelongingtoasingleAutonomous
System.TheOSPFprotocolisbasedonlinkstateorSPFtechnology.
ThisisadeparturefromtheBellmanFordbaseusedbytraditional
TCP/IPinternetroutingprotocols.
TheOSPFprotocolwasdevelopedbytheOSPFworkinggroupofthe
InternetEngineeringTaskForce.Ithasbeendesignedexpresslyfor
theTCP/IPinternetenvironment,includingexplicitsupportforCIDR
andthetaggingofexternallyderivedroutinginformation.OSPF
alsoprovidesfortheauthenticationofroutingupdates,and
utilizesIPmulticastwhensending/receivingtheupdates.In
addition,muchworkhasbeendonetoproduceaprotocolthat
respondsquicklytotopologychanges,yetinvolvessmallamountsof
routingprotocoltraffic.
1.1.Protocoloverview
OSPFroutesIPpacketsbasedsolelyonthedestinationIP
addressfoundintheIPpacketheader.IPpacketsarerouted
"asis"theyarenotencapsulatedinanyfurtherprotocol
headersastheytransittheAutonomousSystem.OSPFisa
dynamicroutingprotocol.Itquicklydetectstopological
changesintheAS(suchasrouterinterfacefailures)and
calculatesnewloopfreeroutesafteraperiodofconvergence.
Thisperiodofconvergenceisshortandinvolvesaminimumof
routingtraffic.
Inalinkstateroutingprotocol,eachroutermaintainsa
databasedescribingtheAutonomousSystem'stopology.This
databaseisreferredtoasthelinkstatedatabase.Each
participatingrouterhasanidenticaldatabase.Eachindividual
pieceofthisdatabaseisaparticularrouter'slocalstate
(e.g.,therouter'susableinterfacesandreachableneighbors).
TherouterdistributesitslocalstatethroughouttheAutonomous
Systembyflooding.
Allroutersruntheexactsamealgorithm,inparallel.Fromthe
linkstatedatabase,eachrouterconstructsatreeofshortest
pathswithitselfasroot.Thisshortestpathtreegivesthe
routetoeachdestinationintheAutonomousSystem.Externally
derivedroutinginformationappearsonthetreeasleaves.
Whenseveralequalcostroutestoadestinationexist,traffic
isdistributedequallyamongthem.Thecostofarouteis
describedbyasingledimensionlessmetric.
OSPFallowssetsofnetworkstobegroupedtogether.Sucha
groupingiscalledanarea.Thetopologyofanareaishidden
fromtherestoftheAutonomousSystem.Thisinformationhiding
enablesasignificantreductioninroutingtraffic.Also,
routingwithintheareaisdeterminedonlybythearea'sown
topology,lendingtheareaprotectionfrombadroutingdata.An
areaisageneralizationofanIPsubnettednetwork.
OSPFenablestheflexibleconfigurationofIPsubnets.Each
routedistributedbyOSPFhasadestinationandmask.Two
5/188
3/2/2015
differentsubnetsofthesameIPnetworknumbermayhave
differentsizes(i.e.,differentmasks).Thisiscommonly
referredtoasvariablelengthsubnetting.Apacketisrouted
tothebest(i.e.,longestormostspecific)match.Hostroutes
areconsideredtobesubnetswhosemasksare"allones"
(0xffffffff).
AllOSPFprotocolexchangesareauthenticated.Thismeansthat
onlytrustedrouterscanparticipateintheAutonomousSystem's
routing.Avarietyofauthenticationschemescanbeused;in
fact,separateauthenticationschemescanbeconfiguredforeach
IPsubnet.
Externallyderivedroutingdata(e.g.,routeslearnedfroman
ExteriorGatewayProtocolsuchasBGP;see[Ref23])is
advertisedthroughouttheAutonomousSystem.Thisexternally
deriveddataiskeptseparatefromtheOSPFprotocol'slink
statedata.Eachexternalroutecanalsobetaggedbythe
advertisingrouter,enablingthepassingofadditional
informationbetweenroutersontheboundaryoftheAutonomous
System.
1.2.Definitionsofcommonlyusedterms
Thissectionprovidesdefinitionsfortermsthathaveaspecific
meaningtotheOSPFprotocolandthatareusedthroughoutthe
text.ThereaderunfamiliarwiththeInternetProtocolSuiteis
referredto[Ref13]foranintroductiontoIP.
Router
AlevelthreeInternetProtocolpacketswitch.Formerly
calledagatewayinmuchoftheIPliterature.
AutonomousSystem
Agroupofroutersexchangingroutinginformationviaa
commonroutingprotocol.AbbreviatedasAS.
InteriorGatewayProtocol
Theroutingprotocolspokenbytheroutersbelongingtoan
Autonomoussystem.AbbreviatedasIGP.EachAutonomous
SystemhasasingleIGP.SeparateAutonomousSystemsmaybe
runningdifferentIGPs.
RouterID
A32bitnumberassignedtoeachrouterrunningtheOSPF
protocol.Thisnumberuniquelyidentifiestherouterwithin
anAutonomousSystem.
Network
Inthismemo,anIPnetwork/subnet/supernet.Itispossible
foronephysicalnetworktobeassignedmultipleIP
network/subnetnumbers.Weconsiderthesetobeseparate
networks.Pointtopointphysicalnetworksareanexception
theyareconsideredasinglenetworknomatterhowmany
(ifanyatall)IPnetwork/subnetnumbersareassignedto
them.
6/188
3/2/2015
Networkmask
A32bitnumberindicatingtherangeofIPaddresses
residingonasingleIPnetwork/subnet/supernet.This
specificationdisplaysnetworkmasksashexadecimalnumbers.
Forexample,thenetworkmaskforaclassCIPnetworkis
displayedas0xffffff00.Suchamaskisoftendisplayed
elsewhereintheliteratureas255.255.255.0.
Pointtopointnetworks
Anetworkthatjoinsasinglepairofrouters.A56Kb
seriallineisanexampleofapointtopointnetwork.
Broadcastnetworks
Networkssupportingmany(morethantwo)attachedrouters,
togetherwiththecapabilitytoaddressasinglephysical
messagetoalloftheattachedrouters(broadcast).
Neighboringroutersarediscovereddynamicallyonthesenets
usingOSPF'sHelloProtocol.TheHelloProtocolitself
takesadvantageofthebroadcastcapability.TheOSPF
protocolmakesfurtheruseofmulticastcapabilities,if
theyexist.Eachpairofroutersonabroadcastnetworkis
assumedtobeabletocommunicatedirectly.Anethernetis
anexampleofabroadcastnetwork.
Nonbroadcastnetworks
Networkssupportingmany(morethantwo)routers,buthaving
nobroadcastcapability.Neighboringroutersaremaintained
onthesenetsusingOSPF'sHelloProtocol.However,dueto
thelackofbroadcastcapability,someconfiguration
informationmaybenecessarytoaidinthediscoveryof
neighbors.Onnonbroadcastnetworks,OSPFprotocolpackets
thatarenormallymulticastneedtobesenttoeach
neighboringrouter,inturn.AnX.25PublicDataNetwork
(PDN)isanexampleofanonbroadcastnetwork.
OSPFrunsinoneoftwomodesovernonbroadcastnetworks.
Thefirstmode,callednonbroadcastmultiaccessorNBMA,
simulatestheoperationofOSPFonabroadcastnetwork.The
secondmode,calledPointtoMultiPoint,treatsthenon
broadcastnetworkasacollectionofpointtopointlinks.
NonbroadcastnetworksarereferredtoasNBMAnetworksor
PointtoMultiPointnetworks,dependingonOSPF'smodeof
operationoverthenetwork.
7/188
3/2/2015
Interface
Theconnectionbetweenarouterandoneofitsattached
networks.Aninterfacehasstateinformationassociated
withit,whichisobtainedfromtheunderlyinglowerlevel
protocolsandtheroutingprotocolitself.Aninterfaceto
anetworkhasassociatedwithitasingleIPaddressand
mask(unlessthenetworkisanunnumberedpointtopoint
network).Aninterfaceissometimesalsoreferredtoasa
link.
Neighboringrouters
Tworoutersthathaveinterfacestoacommonnetwork.
Neighborrelationshipsaremaintainedby,andusually
dynamicallydiscoveredby,OSPF'sHelloProtocol.
Adjacency
Arelationshipformedbetweenselectedneighboringrouters
forthepurposeofexchangingroutinginformation.Not
everypairofneighboringroutersbecomeadjacent.
Linkstateadvertisement
Unitofdatadescribingthelocalstateofarouteror
network.Forarouter,thisincludesthestateofthe
router'sinterfacesandadjacencies.Eachlinkstate
advertisementisfloodedthroughouttheroutingdomain.The
collectedlinkstateadvertisementsofallroutersand
networksformstheprotocol'slinkstatedatabase.
Throughoutthismemo,linkstateadvertisementis
abbreviatedasLSA.
HelloProtocol
ThepartoftheOSPFprotocolusedtoestablishandmaintain
neighborrelationships.OnbroadcastnetworkstheHello
Protocolcanalsodynamicallydiscoverneighboringrouters.
Flooding
ThepartoftheOSPFprotocolthatdistributesand
synchronizesthelinkstatedatabasebetweenOSPFrouters.
DesignatedRouter
EachbroadcastandNBMAnetworkthathasatleasttwo
attachedroutershasaDesignatedRouter.TheDesignated
RoutergeneratesanLSAforthenetworkandhasother
specialresponsibilitiesintherunningoftheprotocol.
TheDesignatedRouteriselectedbytheHelloProtocol.
TheDesignatedRouterconceptenablesareductioninthe
numberofadjacenciesrequiredonabroadcastorNBMA
network.Thisinturnreducestheamountofrouting
protocoltrafficandthesizeofthelinkstatedatabase.
Lowerlevelprotocols
Theunderlyingnetworkaccessprotocolsthatprovide
servicestotheInternetProtocolandinturntheOSPF
protocol.ExamplesofthesearetheX.25packetandframe
levelsforX.25PDNs,andtheethernetdatalinklayerfor
ethernets.
8/188
3/2/2015
1.3.Briefhistoryoflinkstateroutingtechnology
OSPFisalinkstateroutingprotocol.Suchprotocolsarealso
referredtointheliteratureasSPFbasedordistributed
databaseprotocols.Thissectiongivesabriefdescriptionof
thedevelopmentsinlinkstatetechnologythathaveinfluenced
theOSPFprotocol.
Thefirstlinkstateroutingprotocolwasdevelopedforusein
theARPANETpacketswitchingnetwork.Thisprotocolis
describedin[Ref3].Ithasformedthestartingpointforall
otherlinkstateprotocols.ThehomogeneousARPANET
environment,i.e.,singlevendorpacketswitchesconnectedby
synchronousseriallines,simplifiedthedesignand
implementationoftheoriginalprotocol.
Modificationstothisprotocolwereproposedin[Ref4].These
modificationsdealtwithincreasingthefaulttoleranceofthe
routingprotocolthrough,amongotherthings,addingachecksum
totheLSAs(therebydetectingdatabasecorruption).Thepaper
alsoincludedmeansforreducingtheroutingtrafficoverheadin
alinkstateprotocol.Thiswasaccomplishedbyintroducing
mechanismswhichenabledtheintervalbetweenLSAoriginations
tobeincreasedbyanorderofmagnitude.
AlinkstatealgorithmhasalsobeenproposedforuseasanISO
ISISroutingprotocol.Thisprotocolisdescribedin[Ref2].
Theprotocolincludesmethodsfordataandroutingtraffic
reductionwhenoperatingoverbroadcastnetworks.Thisis
accomplishedbyelectionofaDesignatedRouterforeach
broadcastnetwork,whichthenoriginatesanLSAforthenetwork.
TheOSPFWorkingGroupoftheIETFhasextendedthisworkin
developingtheOSPFprotocol.TheDesignatedRouterconcepthas
beengreatlyenhancedtofurtherreducetheamountofrouting
trafficrequired.Multicastcapabilitiesareutilizedfor
additionalroutingbandwidthreduction.Anarearoutingscheme
hasbeendevelopedenablinginformation
hiding/protection/reduction.Finally,thealgorithmshavebeen
tailoredforefficientoperationinTCP/IPinternets.
1.4.Organizationofthisdocument
Thefirstthreesectionsofthisspecificationgiveageneral
overviewoftheprotocol'scapabilitiesandfunctions.Sections
416explaintheprotocol'smechanismsindetail.Packet
formats,protocolconstantsandconfigurationitemsare
specifiedintheappendices.
LabelssuchasHelloIntervalencounteredinthetextreferto
protocolconstants.Theymayormaynotbeconfigurable.
ArchitecturalconstantsaresummarizedinAppendixB.
ConfigurableconstantsaresummarizedinAppendixC.
9/188
3/2/2015
Thedetailedspecificationoftheprotocolispresentedinterms
ofdatastructures.Thisisdoneinordertomakethe
explanationmoreprecise.Implementationsoftheprotocolare
requiredtosupportthefunctionalitydescribed,butneednot
usetheprecisedatastructuresthatappearinthismemo.
1.5.Acknowledgments
TheauthorwouldliketothankRanAtkinson,FredBaker,Jeffrey
Burgan,RobColtun,DinoFarinacci,VinceFuller,Phanindra
Jujjavarapu,MiloMedin,TomPusateri,KannanVaradhan,Zhaohui
ZhangandtherestoftheOSPFWorkingGroupfortheideasand
supporttheyhavegiventothisproject.
TheOSPFPointtoMultiPointinterfaceisbasedonworkdoneby
FredBaker.
TheOSPFCryptographicAuthenticationoptionwasdevelopedby
FredBakerandRanAtkinson.
2.TheLinkstateDatabase:organizationandcalculations
ThefollowingsubsectionsdescribetheorganizationofOSPF'slink
statedatabase,andtheroutingcalculationsthatareperformedon
thedatabaseinordertoproducearouter'sroutingtable.
2.1.Representationofroutersandnetworks
TheAutonomousSystem'slinkstatedatabasedescribesadirected
graph.Theverticesofthegraphconsistofroutersand
networks.Agraphedgeconnectstworouterswhentheyare
attachedviaaphysicalpointtopointnetwork.Anedge
connectingaroutertoanetworkindicatesthattherouterhas
aninterfaceonthenetwork.Networkscanbeeithertransitor
stubnetworks.Transitnetworksarethosecapableofcarrying
datatrafficthatisneitherlocallyoriginatednorlocally
destined.Atransitnetworkisrepresentedbyagraphvertex
havingbothincomingandoutgoingedges.Astubnetwork'svertex
hasonlyincomingedges.
Theneighborhoodofeachnetworknodeinthegraphdependson
thenetwork'stype(pointtopoint,broadcast,NBMAorPoint
toMultiPoint)andthenumberofroutershavinganinterfaceto
thenetwork.ThreecasesaredepictedinFigure1a.Rectangles
indicaterouters.Circlesandoblongsindicatenetworks.
RouternamesareprefixedwiththelettersRTandnetworknames
withtheletterN.Routerinterfacenamesareprefixedbythe
letterI.Linesbetweenroutersindicatepointtopoint
networks.Theleftsideofthefigureshowsnetworkswiththeir
connectedrouters,withtheresultinggraphsshownontheright.
10/188
3/2/2015
**FROM**
*|RT1|RT2|
++Ia++*
|RT1||RT2|TRT1||X|
++Ib++ORT2|X||
*Ia||X|
*Ib|X||
Physicalpointtopointnetworks
**FROM**
++*
|RT7|*|RT7|N3|
++T
|ORT7|||
++*N3|X||
N3*
Stubnetworks
**FROM**
++++
|RT3||RT4||RT3|RT4|RT5|RT6|N2|
++++*
|N2|*RT3|||||X|
++TRT4|||||X|
||ORT5|||||X|
++++*RT6|||||X|
|RT5||RT6|*N2|X|X|X|X||
++++
BroadcastorNBMAnetworks
Figure1a:Networkmapcomponents
Networksandroutersarerepresentedbyvertices.
AnedgeconnectsVertexAtoVertexBiffthe
intersectionofColumnAandRowBismarkedwith
anX.
ThetopofFigure1ashowstworoutersconnectedbyapointto
pointlink.Intheresultinglinkstatedatabasegraph,thetwo
routerverticesaredirectlyconnectedbyapairofedges,one
11/188
3/2/2015
ineachdirection.Interfacestopointtopointnetworksneed
notbeassignedIPaddresses.Wheninterfaceaddressesare
assigned,theyaremodelledasstublinks,witheachrouter
advertisingastubconnectiontotheotherrouter'sinterface
address.Optionally,anIPsubnetcanbeassignedtothepoint
topointnetwork.Inthiscase,bothroutersadvertiseastub
linktotheIPsubnet,insteadofadvertisingeachothers'IP
interfaceaddresses.
ThemiddleofFigure1ashowsanetworkwithonlyoneattached
router(i.e.,astubnetwork).Inthiscase,thenetworkappears
ontheendofastubconnectioninthelinkstatedatabase's
graph.
Whenmultipleroutersareattachedtoabroadcastnetwork,the
linkstatedatabasegraphshowsallroutersbidirectionally
connectedtothenetworkvertex.Thisispicturedatthebottom
ofFigure1a.
Eachnetwork(stubortransit)inthegraphhasanIPaddress
andassociatednetworkmask.Themaskindicatesthenumberof
nodesonthenetwork.Hostsattacheddirectlytorouters
(referredtoashostroutes)appearonthegraphasstub
networks.Thenetworkmaskforahostrouteisalways
0xffffffff,whichindicatesthepresenceofasinglenode.
2.1.1.Representationofnonbroadcastnetworks
Asmentionedpreviously,OSPFcanrunovernonbroadcast
networksinoneoftwomodes:NBMAorPointtoMultiPoint.
ThechoiceofmodedeterminesthewaythattheHello
protocolandfloodingworkoverthenonbroadcastnetwork,
andthewaythatthenetworkisrepresentedinthelink
statedatabase.
InNBMAmode,OSPFemulatesoperationoverabroadcast
network:aDesignatedRouteriselectedfortheNBMA
network,andtheDesignatedRouteroriginatesanLSAforthe
network.Thegraphrepresentationforbroadcastnetworksand
NBMAnetworksisidentical.Thisrepresentationispictured
inthemiddleofFigure1a.
NBMAmodeisthemostefficientwaytorunOSPFovernon
broadcastnetworks,bothintermsoflinkstatedatabase
sizeandintermsoftheamountofroutingprotocoltraffic.
However,ithasonesignificantrestriction:itrequiresall
routersattachedtotheNBMAnetworktobeableto
communicatedirectly.Thisrestrictionmaybemetonsome
nonbroadcastnetworks,suchasanATMsubnetutilizing
SVCs.Butitisoftennotmetonothernonbroadcast
networks,suchasPVConlyFrameRelaynetworks.Onnon
broadcastnetworkswherenotallrouterscancommunicate
directlyyoucanbreakthenonbroadcastnetworkinto
logicalsubnets,withtheroutersoneachsubnetbeingable
tocommunicatedirectly,andthenruneachseparatesubnet
asanNBMAnetwork(see[Ref15]).Thishoweverrequires
12/188
3/2/2015
quiteabitofadministrativeoverhead,andisproneto
misconfiguration.Itisprobablybettertorunsuchanon
broadcastnetworkinPointtoMultipointmode.
InPointtoMultiPointmode,OSPFtreatsallrouterto
routerconnectionsoverthenonbroadcastnetworkasifthey
werepointtopointlinks.NoDesignatedRouteriselected
forthenetwork,noristhereanLSAgeneratedforthe
network.Infact,avertexforthePointtoMultiPoint
networkdoesnotappearinthegraphofthelinkstate
database.
Figure1billustratesthelinkstatedatabaserepresentation
ofaPointtoMultiPointnetwork.Ontheleftsideofthe
figure,aPointtoMultiPointnetworkispictured.Itis
assumedthatallrouterscancommunicatedirectly,except
forroutersRT4andRT5.I3thoughI6indicatetherouters'
IPinterfaceaddressesonthePointtoMultiPointnetwork.
Inthegraphicalrepresentationofthelinkstatedatabase,
routersthatcancommunicatedirectlyoverthePointto
MultiPointnetworkarejoinedbybidirectionaledges,and
eachrouteralsohasastubconnectiontoitsownIP
interfaceaddress(whichisincontrasttothe
representationofrealpointtopointlinks;seeFigure1a).
Onsomenonbroadcastnetworks,useofPointtoMultiPoint
modeanddatalinkprotocolssuchasInverseARP(see
[Ref14])willallowautodiscoveryofOSPFneighborseven
thoughbroadcastsupportisnotavailable.
**FROM**
++++
|RT3||RT4||RT3|RT4|RT5|RT6|
++++*
I3|N2|I4*RT3||X|X|X|
++TRT4|X|||X|
I5||I6ORT5|X|||X|
++++*RT6|X|X|X||
|RT5||RT6|*I3|X||||
++++I4||X|||
I5|||X||
I6||||X|
Figure1b:Networkmapcomponents
PointtoMultiPointnetworks
AllrouterscancommunicatedirectlyoverN2,except
routersRT4andRT5.I3throughI6indicateIP
interfaceaddresses
13/188
3/2/2015
2.1.2.Anexamplelinkstatedatabase
Figure2showsasamplemapofanAutonomousSystem.The
rectanglelabelledH1indicatesahost,whichhasaSLIP
connectiontoRouterRT12.RouterRT12istherefore
advertisingahostroute.Linesbetweenroutersindicate
physicalpointtopointnetworks.Theonlypointtopoint
networkthathasbeenassignedinterfaceaddressesisthe
onejoiningRoutersRT6andRT10.RoutersRT5andRT7have
BGPconnectionstootherAutonomousSystems.AsetofBGP
learnedrouteshavebeendisplayedforbothofthese
routers.
Acostisassociatedwiththeoutputsideofeachrouter
interface.Thiscostisconfigurablebythesystem
administrator.Thelowerthecost,themorelikelythe
interfaceistobeusedtoforwarddatatraffic.Costsare
alsoassociatedwiththeexternallyderivedroutingdata
(e.g.,theBGPlearnedroutes).
ThedirectedgraphresultingfromthemapinFigure2is
depictedinFigure3.Arcsarelabelledwiththecostof
thecorrespondingrouteroutputinterface.Arcshavingno
labelledcosthaveacostof0.Notethatarcsleadingfrom
networkstoroutersalwayshavecost0;theyaresignificant
nonetheless.Notealsothattheexternallyderivedrouting
dataappearsonthegraphasstubs.
ThelinkstatedatabaseispiecedtogetherfromLSAs
generatedbytherouters.Intheassociatedgraphical
representation,theneighborhoodofeachrouterortransit
networkisrepresentedinasingle,separateLSA.Figure4
showstheseLSAsgraphically.RouterRT12hasaninterface
totwobroadcastnetworksandaSLIPlinetoahost.
NetworkN6isabroadcastnetworkwiththreeattached
routers.ThecostofalllinksfromNetworkN6toits
attachedroutersis0.NotethattheLSAforNetworkN6is
actuallygeneratedbyoneofthenetwork'sattachedrouters:
therouterthathasbeenelectedDesignatedRouterforthe
network.
+
|3++N12N14
N1||RT1|\1\N13/
|++\8\|8/8
14/188
3/2/2015
+\____\|/
/\1++88++6
*N3*|RT4||RT5|+
\____/++++|
+/||7|
|3++/|||
N2||RT2|/1|1|6|
|++++86++|
+|RT3||RT6||
++++|
|2Ia|7|
|||
++||
N4||
||
||
N11||
++||
|||N12
|3||62/
++|++/
|RT9|||RT7|N15
++|++9
|1+||1
_|__|Ib|5__|_
/\1++2|3++1/\
*N9*|RT11|||RT10|*N6*
\____/++|++\____/
|||
|1+|1
++10++N8++
|H1||RT12||RT8|
++SLIP++++
|2|4
||
++++
N10N7
Figure2:AsampleAutonomousSystem
**FROM**
|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
|1|2|3|4|5|6|7|8|9|10|11|12|N3|N6|N8|N9|
RT1|||||||||||||0||||
RT2|||||||||||||0||||
RT3||||||6|||||||0||||
RT4|||||8||||||||0||||
RT5||||8||6|6||||||||||
RT6|||8||7|||||5|||||||
RT7|||||6|||||||||0|||
*RT8||||||||||||||0|||
*RT9||||||||||||||||0|
TRT10||||||7||||||||0|0||
ORT11|||||||||||||||0|0|
*RT12||||||||||||||||0|
*N1|3||||||||||||||||
15/188
3/2/2015
N2||3|||||||||||||||
N3|1|1|1|1|||||||||||||
N4|||2||||||||||||||
N6|||||||1|1||1|||||||
N7||||||||4|||||||||
N8||||||||||3|2||||||
N9|||||||||1||1|1|||||
N10||||||||||||2|||||
N11|||||||||3||||||||
N12|||||8||2||||||||||
N13|||||8||||||||||||
N14|||||8||||||||||||
N15|||||||9||||||||||
H1||||||||||||10|||||
Figure3:Theresultingdirectedgraph
AnedgeofcostXconnectsVertexAtoVertexBiff
theintersectionofColumnAandRowBismarked
withanX.
**FROM****FROM**
|RT12|N9|N10|H1||RT9|RT11|RT12|N9|
**
*RT12|||||*RT9||||0|
TN9|1||||TRT11||||0|
ON10|2||||ORT12||||0|
*H1|10||||*N9|||||
**
RT12'srouterLSAN9'snetworkLSA
Figure4:Individuallinkstatecomponents
withanX.
2.2.Theshortestpathtree
WhennoOSPFareasareconfigured,eachrouterintheAutonomous
Systemhasanidenticallinkstatedatabase,leadingtoan
identicalgraphicalrepresentation.Aroutergeneratesits
routingtablefromthisgraphbycalculatingatreeofshortest
pathswiththerouteritselfasroot.Obviously,theshortest
pathtreedependsontherouterdoingthecalculation.The
shortestpathtreeforRouterRT6inourexampleisdepictedin
Figure5.
Thetreegivestheentirepathtoanydestinationnetworkor
host.However,onlythenexthoptothedestinationisusedin
theforwardingprocess.Notealsothatthebestroutetoany
routerhasalsobeencalculated.Fortheprocessingofexternal
data,wenotethenexthopanddistancetoanyrouter
advertisingexternalroutes.Theresultingroutingtablefor
16/188
3/2/2015
RouterRT6ispicturedinTable2.Notethatthereisa
separaterouteforeachendofanumberedpointtopointnetwork
(inthiscase,theseriallinebetweenRoutersRT6andRT10).
RoutestonetworksbelongingtootherAS'es(suchasN12)appear
asdashedlinesontheshortestpathtreeinFigure5.Useof
RT6(origin)
RT5oooIb
/|\6|\7
8/8|8\|\
/|\6|\
o|o|\7
N12oN14|\
N132|\
N4ooRT3\
/\5
1/RT10ooIa
/|\
RT4ooN33|\1
/||\N6RT7
/|N8ooo
/|||/|
RT2ooRT1||2/|9
/|||RT8/|
/3|3RT11oooo
/|||N12N15
N2ooN11||4
||
N9ooN7
/|
/|
N11RT9/|RT12
oooooH1
3|10
|2
|
oN10
Figure5:TheSPFtreeforRouterRT6
Edgesthatarenotmarkedwithacosthaveacostof
ofzero(thesearenetworktorouterlinks).Routes
tonetworksN12N15areexternalinformationthatis
consideredinSection2.3
17/188
3/2/2015
DestinationNextHopDistance
__________________________________
N1RT310
N2RT310
N3RT37
N4RT38
Ib*7
IaRT1012
N6RT108
N7RT1012
N8RT1010
N9RT1011
N10RT1013
N11RT1014
H1RT1021
__________________________________
RT5RT56
RT7RT108
Table2:TheportionofRouterRT6'sroutingtablelistinglocal
destinations.
thisexternallyderivedroutinginformationisconsideredinthe
nextsection.
2.3.Useofexternalroutinginformation
Afterthetreeiscreatedtheexternalroutinginformationis
examined.Thisexternalroutinginformationmayoriginatefrom
anotherroutingprotocolsuchasBGP,orbestatically
configured(staticroutes).Defaultroutescanalsobeincluded
aspartoftheAutonomousSystem'sexternalroutinginformation.
Externalroutinginformationisfloodedunalteredthroughoutthe
AS.Inourexample,alltheroutersintheAutonomousSystem
knowthatRouterRT7hastwoexternalroutes,withmetrics2and
9.
OSPFsupportstwotypesofexternalmetrics.Type1external
metricsareexpressedinthesameunitsasOSPFinterfacecost
(i.e.,intermsofthelinkstatemetric).Type2external
metricsareanorderofmagnitudelarger;anyType2metricis
consideredgreaterthanthecostofanypathinternaltotheAS.
UseofType2externalmetricsassumesthatroutingbetween
AS'esisthemajorcostofroutingapacket,andeliminatesthe
needforconversionofexternalcoststointernallinkstate
metrics.
AsanexampleofType1externalmetricprocessing,supposethat
theRoutersRT7andRT5inFigure2areadvertisingType1
externalmetrics.Foreachadvertisedexternalroute,thetotal
costfromRouterRT6iscalculatedasthesumoftheexternal
route'sadvertisedcostandthedistancefromRouterRT6tothe
advertisingrouter.Whentworoutersareadvertisingthesame
externaldestination,RT6pickstheadvertisingrouterproviding
18/188
3/2/2015
theminimumtotalcost.RT6thensetsthenexthoptothe
externaldestinationequaltothenexthopthatwouldbeused
whenroutingpacketstothechosenadvertisingrouter.
InFigure2,bothRouterRT5andRT7areadvertisinganexternal
routetodestinationNetworkN12.RouterRT7ispreferredsince
itisadvertisingN12atadistanceof10(8+2)toRouterRT6,
whichisbetterthanRouterRT5's14(6+8).Table3showsthe
entriesthatareaddedtotheroutingtablewhenexternalroutes
areexamined:
DestinationNextHopDistance
__________________________________
N12RT1010
N13RT514
N14RT514
N15RT1017
Table3:TheportionofRouterRT6'sroutingtable
listingexternaldestinations.
ProcessingofType2externalmetricsissimpler.TheAS
boundaryrouteradvertisingthesmallestexternalmetricis
chosen,regardlessoftheinternaldistancetotheASboundary
router.SupposeinourexamplebothRouterRT5andRouterRT7
wereadvertisingType2externalroutes.Thenalltraffic
destinedforNetworkN12wouldbeforwardedtoRouterRT7,since
2<8.WhenseveralequalcostType2routesexist,the
internaldistancetotheadvertisingroutersisusedtobreak
thetie.
BothType1andType2externalmetricscanbepresentintheAS
atthesametime.Inthatevent,Type1externalmetricsalways
takeprecedence.
Thissectionhasassumedthatpacketsdestinedforexternal
destinationsarealwaysroutedthroughtheadvertisingAS
boundaryrouter.Thisisnotalwaysdesirable.Forexample,
supposeinFigure2thereisanadditionalrouterattachedto
NetworkN6,calledRouterRTX.SupposefurtherthatRTXdoes
notparticipateinOSPFrouting,butdoesexchangeBGP
informationwiththeASboundaryrouterRT7.Then,RouterRT7
wouldendupadvertisingOSPFexternalroutesforall
destinationsthatshouldberoutedtoRTX.Anextrahopwill
sometimesbeintroducedifpacketsforthesedestinationsneed
alwaysberoutedfirsttoRouterRT7(theadvertisingrouter).
Todealwiththissituation,theOSPFprotocolallowsanAS
boundaryroutertospecifya"forwardingaddress"initsAS
externalLSAs.Intheaboveexample,RouterRT7wouldspecify
RTX'sIPaddressasthe"forwardingaddress"forallthose
destinationswhosepacketsshouldberouteddirectlytoRTX.
19/188
3/2/2015
The"forwardingaddress"hasoneotherapplication.Itenables
routersintheAutonomousSystem'sinteriortofunctionas
"routeservers".Forexample,inFigure2therouterRT6could
becomearouteserver,gainingexternalroutinginformation
throughacombinationofstaticconfigurationandexternal
routingprotocols.RT6wouldthenstartadvertisingitselfas
anASboundaryrouter,andwouldoriginateacollectionofOSPF
ASexternalLSAs.IneachASexternalLSA,RouterRT6would
specifythecorrectAutonomousSystemexitpointtouseforthe
destinationthroughappropriatesettingoftheLSA's"forwarding
address"field.
2.4.Equalcostmultipath
Theabovediscussionhasbeensimplifiedbyconsideringonlya
singleroutetoanydestination.Inreality,ifmultiple
equalcostroutestoadestinationexist,theyareall
discoveredandused.Thisrequiresnoconceptualchangestothe
algorithm,anditsdiscussionispostponeduntilweconsiderthe
treebuildingprocessinmoredetail.
Withequalcostmultipath,arouterpotentiallyhasseveral
availablenexthopstowardsanygivendestination.
3.SplittingtheASintoAreas
OSPFallowscollectionsofcontiguousnetworksandhoststobe
groupedtogether.Suchagroup,togetherwiththeroutershaving
interfacestoanyoneoftheincludednetworks,iscalledanarea.
Eacharearunsaseparatecopyofthebasiclinkstaterouting
algorithm.Thismeansthateachareahasitsownlinkstate
databaseandcorrespondinggraph,asexplainedintheprevious
section.
Thetopologyofanareaisinvisiblefromtheoutsideofthearea.
Conversely,routersinternaltoagivenareaknownothingofthe
detailedtopologyexternaltothearea.Thisisolationofknowledge
enablestheprotocoltoeffectamarkedreductioninroutingtraffic
ascomparedtotreatingtheentireAutonomousSystemasasingle
linkstatedomain.
Withtheintroductionofareas,itisnolongertruethatall
routersintheAShaveanidenticallinkstatedatabase.Arouter
actuallyhasaseparatelinkstatedatabaseforeachareaitis
connectedto.(Routersconnectedtomultipleareasarecalledarea
borderrouters).Tworoutersbelongingtothesameareahave,for
thatarea,identicalarealinkstatedatabases.
RoutingintheAutonomousSystemtakesplaceontwolevels,
dependingonwhetherthesourceanddestinationofapacketreside
inthesamearea(intraarearoutingisused)ordifferentareas
(interarearoutingisused).Inintraarearouting,thepacketis
routedsolelyoninformationobtainedwithinthearea;norouting
20/188
3/2/2015
informationobtainedfromoutsidetheareacanbeused.This
protectsintraarearoutingfromtheinjectionofbadrouting
information.WediscussinterarearoutinginSection3.2.
3.1.ThebackboneoftheAutonomousSystem
TheOSPFbackboneisthespecialOSPFArea0(oftenwrittenas
Area0.0.0.0,sinceOSPFAreaID'saretypicallyformattedasIP
addresses).TheOSPFbackbonealwayscontainsallareaborder
routers.Thebackboneisresponsiblefordistributingrouting
informationbetweennonbackboneareas.Thebackbonemustbe
contiguous.However,itneednotbephysicallycontiguous;
backboneconnectivitycanbeestablished/maintainedthroughthe
configurationofvirtuallinks.
Virtuallinkscanbeconfiguredbetweenanytwobackbonerouters
thathaveaninterfacetoacommonnonbackbonearea.Virtual
linksbelongtothebackbone.Theprotocoltreatstworouters
joinedbyavirtuallinkasiftheywereconnectedbyan
unnumberedpointtopointbackbonenetwork.Onthegraphofthe
backbone,twosuchroutersarejoinedbyarcswhosecostsare
theintraareadistancesbetweenthetworouters.Therouting
protocoltrafficthatflowsalongthevirtuallinkusesintra
arearoutingonly.
3.2.Interarearouting
Whenroutingapacketbetweentwononbackboneareasthe
backboneisused.Thepaththatthepacketwilltravelcanbe
brokenupintothreecontiguouspieces:anintraareapathfrom
thesourcetoanareaborderrouter,abackbonepathbetweenthe
sourceanddestinationareas,andthenanotherintraareapath
tothedestination.Thealgorithmfindsthesetofsuchpaths
thathavethesmallestcost.
Lookingatthisanotherway,interarearoutingcanbepictured
asforcingastarconfigurationontheAutonomousSystem,with
thebackboneashubandeachofthenonbackboneareasas
spokes.
Thetopologyofthebackbonedictatesthebackbonepathsused
betweenareas.Thetopologyofthebackbonecanbeenhancedby
addingvirtuallinks.Thisgivesthesystemadministratorsome
controlovertheroutestakenbyinterareatraffic.
Thecorrectareaborderroutertouseasthepacketexitsthe
sourceareaischoseninexactlythesamewayrouters
advertisingexternalroutesarechosen.Eachareaborderrouter
inanareasummarizesfortheareaitscosttoallnetworks
externaltothearea.AftertheSPFtreeiscalculatedforthe
21/188
3/2/2015
area,routestoallinterareadestinationsarecalculatedby
examiningthesummariesoftheareaborderrouters.
3.3.Classificationofrouters
Beforetheintroductionofareas,theonlyOSPFroutershavinga
specializedfunctionwerethoseadvertisingexternalrouting
information,suchasRouterRT5inFigure2.WhentheASis
splitintoOSPFareas,theroutersarefurtherdividedaccording
tofunctionintothefollowingfouroverlappingcategories:
Internalrouters
Arouterwithalldirectlyconnectednetworksbelongingto
thesamearea.Theseroutersrunasinglecopyofthebasic
routingalgorithm.
Areaborderrouters
Arouterthatattachestomultipleareas.Areaborder
routersrunmultiplecopiesofthebasicalgorithm,onecopy
foreachattachedarea.Areaborderrouterscondensethe
topologicalinformationoftheirattachedareasfor
distributiontothebackbone.Thebackboneinturn
distributestheinformationtotheotherareas.
Backbonerouters
Arouterthathasaninterfacetothebackbonearea.This
includesallroutersthatinterfacetomorethanonearea
(i.e.,areaborderrouters).However,backboneroutersdo
nothavetobeareaborderrouters.Routerswithall
interfacesconnectingtothebackboneareaaresupported.
ASboundaryrouters
Arouterthatexchangesroutinginformationwithrouters
belongingtootherAutonomousSystems.Sucharouter
advertisesASexternalroutinginformationthroughoutthe
AutonomousSystem.ThepathstoeachASboundaryrouterare
knownbyeveryrouterintheAS.Thisclassificationis
completelyindependentofthepreviousclassifications:AS
boundaryroutersmaybeinternalorareaborderrouters,and
mayormaynotparticipateinthebackbone.
3.4.Asampleareaconfiguration
Figure6showsasampleareaconfiguration.Thefirstarea
consistsofnetworksN1N4,alongwiththeirattachedrouters
RT1RT4.ThesecondareaconsistsofnetworksN6N8,alongwith
theirattachedroutersRT7,RT8,RT10andRT11.Thethirdarea
consistsofnetworksN9N11andHostH1,alongwiththeir
attachedroutersRT9,RT11andRT12.Thethirdareahasbeen
configuredsothatnetworksN9N11andHostH1willallbe
groupedintoasingleroute,whenadvertisedexternaltothe
area(seeSection3.5formoredetails).
InFigure6,RoutersRT1,RT2,RT5,RT6,RT8,RT9andRT12are
internalrouters.RoutersRT3,RT4,RT7,RT10andRT11arearea
22/188
3/2/2015
borderrouters.Finally,asbefore,RoutersRT5andRT7areAS
boundaryrouters.
Figure7showstheresultinglinkstatedatabasefortheArea1.
Thefigurecompletelydescribesthatarea'sintraarearouting.
Italsoshowsthecompleteviewoftheinternetforthetwo
internalroutersRT1andRT2.Itisthejoboftheareaborder
routers,RT3andRT4,toadvertiseintoArea1thedistancesto
alldestinationsexternaltothearea.Theseareindicatedin
Figure7bythedashedstubroutes.Also,RT3andRT4must
advertiseintoArea1thelocationoftheASboundaryrouters
RT5andRT7.Finally,ASexternalLSAsfromRT5andRT7are
floodedthroughouttheentireAS,andinparticularthroughout
Area1.TheseLSAsareincludedinArea1'sdatabase,andyield
routestoNetworksN12N15.
RoutersRT3andRT4mustalsosummarizeArea1'stopologyfor
...........................
.+.
.|3++.N12N14
.N1||RT1|\1.\N13/
.|++\.8\|8/8
.+\____.\|/
./\1++88++6
.*N3*|RT4||RT5|+
.\____/++++|
.+/\.|7|
.|3++/\.||
.N2||RT2|/11\.|6|
.|++++86++|
.+|RT3||RT6||
.++++|
.2/.Ia|7|
./.||
.++.||
.Area1N4.||
...........................||
..........................||
.N11.||
.++.||
.|.||N12
.|3.Ib|5|62/
.++.++++/
.|RT9|..........|RT10|.....|RT7|N15.
.++..++++9.
.|1..+/31\|1.
._|__..|/\__|_.
./\1++2|/\/\.
.*N9*|RT11||*N6*.
.\____/++|\____/.
.|..||.
.|1..+|1.
.++10++..N8++.
.|H1||RT12|..|RT8|.
.++SLIP++..++.
.|2..|4.
23/188
3/2/2015
.|..|.
.++..++.
.N10..N7.
...Area2.
.Area3.................................
..........................
Figure6:AsampleOSPFareaconfiguration
distributiontothebackbone.TheirbackboneLSAsareshownin
Table4.Thesesummariesshowwhichnetworksarecontainedin
Area1(i.e.,NetworksN1N4),andthedistancetothese
networksfromtheroutersRT3andRT4respectively.
ThelinkstatedatabaseforthebackboneisshowninFigure8.
Thesetofrouterspicturedarethebackbonerouters.Router
RT11isabackbonerouterbecauseitbelongstotwoareas.In
ordertomakethebackboneconnected,avirtuallinkhasbeen
configuredbetweenRoutersR10andR11.
TheareaborderroutersRT3,RT4,RT7,RT10andRT11condense
theroutinginformationoftheirattachednonbackboneareasfor
distributionviathebackbone;thesearethedashedstubsthat
appearinFigure8.Rememberthatthethirdareahasbeen
configuredtocondenseNetworksN9N11andHostH1intoasingle
route.ThisyieldsasingledashedlinefornetworksN9N11and
HostH1inFigure8.RoutersRT5andRT7areASboundary
routers;theirexternallyderivedinformationalsoappearson
thegraphinFigure8asstubs.
NetworkRT3adv.RT4adv.
_____________________________
N144
N244
N311
N423
Table4:Networksadvertisedtothebackbone
byRoutersRT3andRT4.
**FROM**
|RT|RT|RT|RT|RT|RT|
|1|2|3|4|5|7|N3|
24/188
3/2/2015
RT1|||||||0|
RT2|||||||0|
RT3|||||||0|
*RT4|||||||0|
*RT5|||14|8||||
TRT7|||20|14||||
ON1|3|||||||
*N2||3||||||
*N3|1|1|1|1||||
N4|||2|||||
Ia,Ib|||20|27||||
N6|||16|15||||
N7|||20|19||||
N8|||18|18||||
N9N11,H1|||29|36||||
N12|||||8|2||
N13|||||8|||
N14|||||8|||
N15||||||9||
Figure7:Area1'sDatabase.
withanX.
**FROM**
|RT|RT|RT|RT|RT|RT|RT
|3|4|5|6|7|10|11|
RT3||||6||||
RT4|||8|||||
RT5||8||6|6|||
RT6|8||7|||5||
RT7|||6|||||
*RT10||||7|||2|
*RT11||||||3||
TN1|4|4||||||
ON2|4|4||||||
*N3|1|1||||||
*N4|2|3||||||
Ia||||||5||
Ib||||7||||
N6|||||1|1|3|
N7|||||5|5|7|
25/188
3/2/2015
N8|||||4|3|2|
N9N11,H1|||||||11|
N12|||8||2|||
N13|||8|||||
N14|||8|||||
N15|||||9|||
Figure8:Thebackbone'sdatabase.
withanX.
Thebackboneenablestheexchangeofsummaryinformationbetween
areaborderrouters.Everyareaborderrouterhearsthearea
summariesfromallotherareaborderrouters.Itthenformsa
pictureofthedistancetoallnetworksoutsideofitsareaby
examiningthecollectedLSAs,andaddinginthebackbone
distancetoeachadvertisingrouter.
AgainusingRoutersRT3andRT4asanexample,theprocedure
goesasfollows:TheyfirstcalculatetheSPFtreeforthe
backbone.Thisgivesthedistancestoallotherareaborder
routers.Alsonotedarethedistancestonetworks(IaandIb)
andASboundaryrouters(RT5andRT7)thatbelongtothe
backbone.ThiscalculationisshowninTable5.
Next,bylookingattheareasummariesfromtheseareaborder
routers,RT3andRT4candeterminethedistancetoallnetworks
outsidetheirarea.Thesedistancesarethenadvertised
internallytotheareabyRT3andRT4.Theadvertisementsthat
RouterRT3andRT4willmakeintoArea1areshowninTable6.
NotethatTable6assumesthatanarearangehasbeenconfigured
forthebackbonewhichgroupsIaandIbintoasingleLSA.
TheinformationimportedintoArea1byRoutersRT3andRT4
enablesaninternalrouter,suchasRT1,tochooseanarea
borderrouterintelligently.RouterRT1woulduseRT4for
traffictoNetworkN6,RT3fortraffictoNetworkN10,andwould
distfromdistfrom
RT3RT4
__________________________________
toRT3*21
toRT422*
toRT72014
toRT101522
toRT111825
__________________________________
toIa2027
toIb1522
__________________________________
26/188
3/2/2015
toRT5148
toRT72014
Table5:Backbonedistancescalculated
byRoutersRT3andRT4.
DestinationRT3adv.RT4adv.
_________________________________
Ia,Ib2027
N61615
N72019
N81818
N9N11,H12936
_________________________________
RT5148
RT72014
Table6:DestinationsadvertisedintoArea1
byRoutersRT3andRT4.
loadsharebetweenthetwofortraffictoNetworkN8.
RouterRT1canalsodetermineinthismannertheshortestpath
totheASboundaryroutersRT5andRT7.Then,bylookingatRT5
andRT7'sASexternalLSAs,RouterRT1candecidebetweenRT5or
RT7whensendingtoadestinationinanotherAutonomousSystem
(oneofthenetworksN12N15).
NotethatafailureofthelinebetweenRoutersRT6andRT10
willcausethebackbonetobecomedisconnected.Configuringa
virtuallinkbetweenRoutersRT7andRT10willgivethebackbone
moreconnectivityandmoreresistancetosuchfailures.
3.5.IPsubnettingsupport
OSPFattachesanIPaddressmasktoeachadvertisedroute.The
maskindicatestherangeofaddressesbeingdescribedbythe
particularroute.Forexample,asummaryLSAforthe
destination128.185.0.0withamaskof0xffff0000actuallyis
describingasingleroutetothecollectionofdestinations
128.185.0.0128.185.255.255.Similarly,hostroutesare
alwaysadvertisedwithamaskof0xffffffff,indicatingthe
presenceofonlyasingledestination.
27/188
3/2/2015
Includingthemaskwitheachadvertiseddestinationenablesthe
implementationofwhatiscommonlyreferredtoasvariable
lengthsubnetting.ThismeansthatasingleIPclassA,B,orC
networknumbercanbebrokenupintomanysubnetsofvarious
sizes.Forexample,thenetwork128.185.0.0couldbebrokenup
into62variablesizedsubnets:15subnetsofsize4K,15
subnetsofsize256,and32subnetsofsize8.Table7shows
someoftheresultingnetworkaddressestogetherwiththeir
masks.
NetworkaddressIPaddressmaskSubnetsize
_______________________________________________
128.185.16.00xfffff0004K
128.185.1.00xffffff00256
128.185.0.80xfffffff88
Table7:Somesamplesubnetsizes.
TherearemanypossiblewaysofdividingupaclassA,B,andC
networkintovariablesizedsubnets.Thepreciseprocedurefor
doingsoisbeyondthescopeofthisspecification.This
specificationhoweverestablishesthefollowingguideline:When
anIPpacketisforwarded,itisalwaysforwardedtothenetwork
thatisthebestmatchforthepacket'sdestination.Herebest
matchissynonymouswiththelongestormostspecificmatch.
Forexample,thedefaultroutewithdestinationof0.0.0.0and
mask0x00000000isalwaysamatchforeveryIPdestination.Yet
itisalwayslessspecificthananyothermatch.Subnetmasks
mustbeassignedsothatthebestmatchforanyIPdestination
isunambiguous.
Attachinganaddressmasktoeachroutealsoenablesthesupport
ofIPsupernetting.Forexample,asinglephysicalnetwork
segmentcouldbeassignedthe[address,mask]pair
[192.9.4.0,0xfffffc00].ThesegmentwouldthenbesingleIP
network,containingaddressesfromthefourconsecutiveclassC
networknumbers192.9.4.0through192.9.7.0.Suchaddressingis
nowbecomingcommonplacewiththeadventofCIDR(see[Ref10]).
Inordertogetbetteraggregationatareaboundaries,area
addressrangescanbeemployed(seeSectionC.2formore
details).Eachaddressrangeisdefinedasan[address,mask]
pair.Manyseparatenetworksmaythenbecontainedinasingle
addressrange,justasasubnettednetworkiscomposedofmany
separatesubnets.Areaborderroutersthensummarizethearea
contents(fordistributiontothebackbone)byadvertisinga
singlerouteforeachaddressrange.Thecostoftherouteis
themaximumcosttoanyofthenetworksfallinginthespecified
range.
Forexample,anIPsubnettednetworkmightbeconfiguredasa
singleOSPFarea.Inthatcase,asingleaddressrangecouldbe
configured:aclassA,B,orCnetworknumberalongwithits
naturalIPmask.Insidethearea,anynumberofvariablesized
28/188
3/2/2015
subnetscouldbedefined.However,externaltotheareaa
singleroutefortheentiresubnettednetworkwouldbe
distributed,hidingeventhefactthatthenetworkissubnetted
atall.Thecostofthisrouteisthemaximumofthesetof
coststothecomponentsubnets.
3.6.Supportingstubareas
InsomeAutonomousSystems,themajorityofthelinkstate
databasemayconsistofASexternalLSAs.AnOSPFASexternal
LSAisusuallyfloodedthroughouttheentireAS.However,OSPF
allowscertainareastobeconfiguredas"stubareas".AS
externalLSAsarenotfloodedinto/throughoutstubareas;
routingtoASexternaldestinationsintheseareasisbasedona
(perarea)defaultonly.Thisreducesthelinkstatedatabase
size,andthereforethememoryrequirements,forastubarea's
internalrouters.
InordertotakeadvantageoftheOSPFstubareasupport,
defaultroutingmustbeusedinthestubarea.Thisis
accomplishedasfollows.Oneormoreofthestubarea'sarea
borderroutersmustadvertiseadefaultrouteintothestubarea
viasummaryLSAs.Thesesummarydefaultsarefloodedthroughout
thestubarea,butnofurther.(Forthisreasonthesedefaults
pertainonlytotheparticularstubarea).Thesesummary
defaultrouteswillbeusedforanydestinationthatisnot
explicitlyreachablebyanintraareaorinterareapath(i.e.,
ASexternaldestinations).
Anareacanbeconfiguredasastubwhenthereisasingleexit
pointfromthearea,orwhenthechoiceofexitpointneednot
bemadeonaperexternaldestinationbasis.Forexample,Area
3inFigure6couldbeconfiguredasastubarea,becauseall
externaltrafficmusttravelthoughitssingleareaborder
routerRT11.IfArea3wereconfiguredasastub,RouterRT11
wouldadvertiseadefaultroutefordistributioninsideArea3
(inasummaryLSA),insteadoffloodingtheASexternalLSAsfor
NetworksN12N15into/throughoutthearea.
TheOSPFprotocolensuresthatallroutersbelongingtoanarea
agreeonwhethertheareahasbeenconfiguredasastub.This
guaranteesthatnoconfusionwillariseinthefloodingofAS
externalLSAs.
Thereareacoupleofrestrictionsontheuseofstubareas.
Virtuallinkscannotbeconfiguredthroughstubareas.In
addition,ASboundaryrouterscannotbeplacedinternaltostub
areas.
3.7.Partitionsofareas
OSPFdoesnotactivelyattempttorepairareapartitions.When
anareabecomespartitioned,eachcomponentsimplybecomesa
separatearea.Thebackbonethenperformsroutingbetweenthe
newareas.Somedestinationsreachableviaintraarearouting
29/188
3/2/2015
beforethepartitionwillnowrequireinterarearouting.
However,inordertomaintainfullroutingafterthepartition,
anaddressrangemustnotbesplitacrossmultiplecomponentsof
theareapartition.Also,thebackboneitselfmustnot
partition.Ifitdoes,partsoftheAutonomousSystemwill
becomeunreachable.Backbonepartitionscanberepairedby
configuringvirtuallinks(seeSection15).
Anotherwaytothinkaboutareapartitionsistolookatthe
AutonomousSystemgraphthatwasintroducedinSection2.Area
IDscanbeviewedascolorsforthegraph'sedges.[1]Eachedge
ofthegraphconnectstoanetwork,orisitselfapointto
pointnetwork.Ineithercase,theedgeiscoloredwiththe
network'sAreaID.
Agroupofedges,allhavingthesamecolor,andinterconnected
byvertices,representsanarea.Ifthetopologyofthe
AutonomousSystemisintact,thegraphwillhaveseveralregions
ofcolor,eachcolorbeingadistinctAreaID.
WhentheAStopologychanges,oneoftheareasmaybecome
partitioned.ThegraphoftheASwillthenhavemultiple
regionsofthesamecolor(AreaID).Theroutinginthe
AutonomousSystemwillcontinuetofunctionaslongasthese
regionsofsamecolorareconnectedbythesinglebackbone
region.
30/188
3/2/2015
4.FunctionalSummary
AseparatecopyofOSPF'sbasicroutingalgorithmrunsineacharea.
Routershavinginterfacestomultipleareasrunmultiplecopiesof
thealgorithm.Abriefsummaryoftheroutingalgorithmfollows.
Whenarouterstarts,itfirstinitializestheroutingprotocoldata
structures.Therouterthenwaitsforindicationsfromthelower
levelprotocolsthatitsinterfacesarefunctional.
ArouterthenusestheOSPF'sHelloProtocoltoacquireneighbors.
TheroutersendsHellopacketstoitsneighbors,andinturn
receivestheirHellopackets.Onbroadcastandpointtopoint
networks,therouterdynamicallydetectsitsneighboringroutersby
sendingitsHellopacketstothemulticastaddressAllSPFRouters.
Onnonbroadcastnetworks,someconfigurationinformationmaybe
necessaryinordertodiscoverneighbors.OnbroadcastandNBMA
networkstheHelloProtocolalsoelectsaDesignatedrouterforthe
network.
Therouterwillattempttoformadjacencieswithsomeofitsnewly
acquiredneighbors.Linkstatedatabasesaresynchronizedbetween
pairsofadjacentrouters.OnbroadcastandNBMAnetworks,the
DesignatedRouterdetermineswhichroutersshouldbecomeadjacent.
Adjacenciescontrolthedistributionofroutinginformation.
Routingupdatesaresentandreceivedonlyonadjacencies.
Arouterperiodicallyadvertisesitsstate,whichisalsocalled
linkstate.Linkstateisalsoadvertisedwhenarouter'sstate
changes.Arouter'sadjacenciesarereflectedinthecontentsof
itsLSAs.Thisrelationshipbetweenadjacenciesandlinkstate
allowstheprotocoltodetectdeadroutersinatimelyfashion.
LSAsarefloodedthroughoutthearea.Thefloodingalgorithmis
reliable,ensuringthatallroutersinanareahaveexactlythesame
linkstatedatabase.Thisdatabaseconsistsofthecollectionof
LSAsoriginatedbyeachrouterbelongingtothearea.Fromthis
databaseeachroutercalculatesashortestpathtree,withitselfas
root.Thisshortestpathtreeinturnyieldsaroutingtablefor
theprotocol.
4.1.Interarearouting
Theprevioussectiondescribedtheoperationoftheprotocol
withinasinglearea.Forintraarearouting,nootherrouting
informationispertinent.Inordertobeabletorouteto
destinationsoutsideofthearea,theareaborderroutersinject
additionalroutinginformationintothearea.Thisadditional
informationisadistillationoftherestoftheAutonomous
System'stopology.
31/188
3/2/2015
Thisdistillationisaccomplishedasfollows:Eachareaborder
routerisbydefinitionconnectedtothebackbone.Eacharea
borderroutersummarizesthetopologyofitsattachednon
backboneareasfortransmissiononthebackbone,andhenceto
allotherareaborderrouters.Anareaborderrouterthenhas
completetopologicalinformationconcerningthebackbone,and
theareasummariesfromeachoftheotherareaborderrouters.
Fromthisinformation,theroutercalculatespathstoall
interareadestinations.Therouterthenadvertisesthesepaths
intoitsattachedareas.Thisenablesthearea'sinternal
routerstopickthebestexitrouterwhenforwardingtraffic
interareadestinations.
4.2.ASexternalroutes
RoutersthathaveinformationregardingotherAutonomousSystems
canfloodthisinformationthroughouttheAS.Thisexternal
routinginformationisdistributedverbatimtoevery
participatingrouter.Thereisoneexception:externalrouting
informationisnotfloodedinto"stub"areas(seeSection3.6).
Toutilizeexternalroutinginformation,thepathtoallrouters
advertisingexternalinformationmustbeknownthroughouttheAS
(exceptingthestubareas).Forthatreason,thelocationsof
theseASboundaryroutersaresummarizedbythe(nonstub)area
borderrouters.
4.3.Routingprotocolpackets
TheOSPFprotocolrunsdirectlyoverIP,usingIPprotocol89.
OSPFdoesnotprovideanyexplicitfragmentation/reassembly
support.Whenfragmentationisnecessary,IP
fragmentation/reassemblyisused.OSPFprotocolpacketshave
beendesignedsothatlargeprotocolpacketscangenerallybe
splitintoseveralsmallerprotocolpackets.Thispracticeis
recommended;IPfragmentationshouldbeavoidedwhenever
possible.
RoutingprotocolpacketsshouldalwaysbesentwiththeIPTOS
fieldsetto0.Ifatallpossible,routingprotocolpackets
shouldbegivenpreferenceoverregularIPdatatraffic,both
whenbeingsentandreceived.Asanaidtoaccomplishingthis,
OSPFprotocolpacketsshouldhavetheirIPprecedencefieldset
tothevalueInternetworkControl(see[Ref5]).
AllOSPFprotocolpacketsshareacommonprotocolheaderthatis
describedinAppendixA.TheOSPFpackettypesarelistedbelow
inTable8.TheirformatsarealsodescribedinAppendixA.
TypePacketnameProtocolfunction
32/188
3/2/2015
__________________________________________________________
1HelloDiscover/maintainneighbors
2DatabaseDescriptionSummarizedatabasecontents
3LinkStateRequestDatabasedownload
4LinkStateUpdateDatabaseupdate
5LinkStateAckFloodingacknowledgment
Table8:OSPFpackettypes.
OSPF'sHelloprotocolusesHellopacketstodiscoverand
maintainneighborrelationships.TheDatabaseDescriptionand
LinkStateRequestpacketsareusedintheformingof
adjacencies.OSPF'sreliableupdatemechanismisimplementedby
theLinkStateUpdateandLinkStateAcknowledgmentpackets.
EachLinkStateUpdatepacketcarriesasetofnewlinkstate
advertisements(LSAs)onehopfurtherawayfromtheirpointof
origination.AsingleLinkStateUpdatepacketmaycontainthe
LSAsofseveralrouters.EachLSAistaggedwiththeIDofthe
originatingrouterandachecksumofitslinkstatecontents.
EachLSAalsohasatypefield;thedifferenttypesofOSPFLSAs
arelistedbelowinTable9.
OSPFroutingpackets(withtheexceptionofHellos)aresent
onlyoveradjacencies.ThismeansthatallOSPFprotocol
packetstravelasingleIPhop,exceptthosethataresentover
virtualadjacencies.TheIPsourceaddressofanOSPFprotocol
packetisoneendofarouteradjacency,andtheIPdestination
addressiseithertheotherendoftheadjacencyoranIP
multicastaddress.
4.4.Basicimplementationrequirements
AnimplementationofOSPFrequiresthefollowingpiecesof
systemsupport:
Timers
Twodifferentkindoftimersarerequired.Thefirstkind,
called"singleshottimers",fireonceandcauseaprotocol
eventtobeprocessed.Thesecondkind,called"interval
timers",fireatcontinuousintervals.Theseareusedfor
thesendingofpacketsatregularintervals.Agoodexample
ofthisistheregularbroadcastofHellopackets.The
granularityofbothkindsoftimersisonesecond.
Intervaltimersshouldbeimplementedtoavoiddrift.In
somerouterimplementations,packetprocessingcanaffect
timerexecution.Whenmultipleroutersareattachedtoa
singlenetwork,alldoingbroadcasts,thiscanleadtothe
synchronizationofroutingpackets(whichshouldbe
avoided).Iftimerscannotbeimplementedtoavoiddrift,
smallrandomamountsshouldbeaddedto/subtractedfromthe
intervaltimerateachfiring.
33/188
3/2/2015
LSLSALSAdescription
typename
________________________________________________________
1RouterLSAsOriginatedbyallrouters.
ThisLSAdescribes
thecollectedstatesofthe
router'sinterfacestoan
area.Floodedthroughouta
singleareaonly.
________________________________________________________
2NetworkLSAsOriginatedforbroadcast
andNBMAnetworksby
theDesignatedRouter.This
LSAcontainsthe
listofroutersconnected
tothenetwork.Flooded
throughoutasingleareaonly.
________________________________________________________
3,4SummaryLSAsOriginatedbyareaborder
routers,andfloodedthrough
outtheLSA'sassociated
area.EachsummaryLSA
describesaroutetoa
destinationoutsidethearea,
yetstillinsidetheAS
(i.e.,aninterarearoute).
Type3summaryLSAsdescribe
routestonetworks.Type4
summaryLSAsdescribe
routestoASboundaryrouters.
________________________________________________________
5ASexternalLSAsOriginatedbyASboundary
routers,andfloodedthrough
outtheAS.Each
ASexternalLSAdescribes
aroutetoadestinationin
anotherAutonomousSystem.
DefaultroutesfortheAScan
alsobedescribedby
ASexternalLSAs.
Table9:OSPFlinkstateadvertisements(LSAs).
IPmulticast
34/188
3/2/2015
CertainOSPFpacketstaketheformofIPmulticast
datagrams.SupportforreceivingandsendingIPmulticast
datagrams,alongwiththeappropriatelowerlevelprotocol
support,isrequired.TheIPmulticastdatagramsusedby
OSPFnevertravelmorethanonehop.Forthisreason,the
abilitytoforwardIPmulticastdatagramsisnotrequired.
ForinformationonIPmulticast,see[Ref7].
Variablelengthsubnetsupport
Therouter'sIPprotocolsupportmustincludetheabilityto
divideasingleIPclassA,B,orCnetworknumberintomany
subnetsofvarioussizes.Thisiscommonlycalled
variablelengthsubnetting;seeSection3.5fordetails.
IPsupernettingsupport
Therouter'sIPprotocolsupportmustincludetheabilityto
aggregatecontiguouscollectionsofIPclassA,B,andC
networksintolargerquantitiescalledsupernets.
Supernettinghasbeenproposedasonewaytoimprovethe
scalingofIProutingintheworldwideInternet.Formore
informationonIPsupernetting,see[Ref10].
Lowerlevelprotocolsupport
Thelowerlevelprotocolsreferredtoherearethenetwork
accessprotocols,suchastheEthernetdatalinklayer.
IndicationsmustbepassedfromtheseprotocolstoOSPFas
thenetworkinterfacegoesupanddown.Forexample,onan
ethernetitwouldbevaluabletoknowwhentheethernet
transceivercablebecomesunplugged.
Nonbroadcastlowerlevelprotocolsupport
Onnonbroadcastnetworks,theOSPFHelloProtocolcanbe
aidedbyprovidinganindicationwhenanattemptismadeto
sendapackettoadeadornonexistentrouter.For
example,onanX.25PDNadeadneighboringroutermaybe
indicatedbythereceptionofaX.25clearwithan
appropriatecauseanddiagnostic,andthisinformationwould
bepassedtoOSPF.
Listmanipulationprimitives
MuchoftheOSPFfunctionalityisdescribedintermsofits
operationonlistsofLSAs.Forexample,thecollectionof
LSAsthatwillberetransmittedtoanadjacentrouteruntil
acknowledgedaredescribedasalist.AnyparticularLSA
maybeonmanysuchlists.AnOSPFimplementationneedsto
beabletomanipulatetheselists,addinganddeleting
constituentLSAsasnecessary.
Taskingsupport
Certainproceduresdescribedinthisspecificationinvoke
otherprocedures.Attimes,theseotherproceduresshould
beexecutedinline,thatis,beforethecurrentprocedure
isfinished.Thisisindicatedinthetextbyinstructions
toexecuteaprocedure.Atothertimes,theother
proceduresaretobeexecutedonlywhenthecurrent
35/188
3/2/2015
procedurehasfinished.Thisisindicatedbyinstructions
toscheduleatask.
4.5.OptionalOSPFcapabilities
TheOSPFprotocoldefinesseveraloptionalcapabilities.A
routerindicatestheoptionalcapabilitiesthatitsupportsin
itsOSPFHellopackets,DatabaseDescriptionpacketsandinits
LSAs.Thisenablesrouterssupportingamixofoptional
capabilitiestocoexistinasingleAutonomousSystem.
Somecapabilitiesmustbesupportedbyallroutersattachedtoa
specificarea.Inthiscase,arouterwillnotaccepta
neighbor'sHelloPacketunlessthereisamatchinreported
capabilities(i.e.,acapabilitymismatchpreventsaneighbor
relationshipfromforming).Anexampleofthisisthe
ExternalRoutingCapability(seebelow).
OthercapabilitiescanbenegotiatedduringtheDatabase
Exchangeprocess.Thisisaccomplishedbyspecifyingthe
optionalcapabilitiesinDatabaseDescriptionpackets.A
capabilitymismatchwithaneighborinthiscasewillresultin
onlyasubsetofthelinkstatedatabasebeingexchangedbetween
thetwoneighbors.
Theroutingtablebuildprocesscanalsobeaffectedbythe
presence/absenceofoptionalcapabilities.Forexample,since
theoptionalcapabilitiesarereportedinLSAs,routers
incapableofcertainfunctionscanbeavoidedwhenbuildingthe
shortestpathtree.
TheOSPFoptionalcapabilitiesdefinedinthismemoarelisted
below.SeeSectionA.2formoreinformation.
ExternalRoutingCapability
EntireOSPFareascanbeconfiguredas"stubs"(seeSection
3.6).ASexternalLSAswillnotbefloodedintostubareas.
ThiscapabilityisrepresentedbytheEbitintheOSPF
Optionsfield(seeSectionA.2).Inordertoensure
consistentconfigurationofstubareas,allrouters
interfacingtosuchanareamusthavetheEbitclearin
theirHellopackets(seeSections9.5and10.5).
5.ProtocolDataStructures
TheOSPFprotocolisdescribedhereinintermsofitsoperationon
variousprotocoldatastructures.Thefollowinglistcomprisesthe
toplevelOSPFdatastructures.Anyinitializationthatneedstobe
doneisnoted.OSPFareas,interfacesandneighborsalsohave
associateddatastructuresthataredescribedlaterinthis
specification.
RouterID
A32bitnumberthatuniquelyidentifiesthisrouterintheAS.
36/188
3/2/2015
Onepossibleimplementationstrategywouldbetousethe
smallestIPinterfaceaddressbelongingtotherouter.Ifa
router'sOSPFRouterIDischanged,therouter'sOSPFsoftware
shouldberestartedbeforethenewRouterIDtakeseffect.In
thiscasetheroutershouldflushitsselforiginatedLSAsfrom
theroutingdomain(seeSection14.1)beforerestarting,orthey
willpersistforuptoMaxAgeminutes.
Areastructures
Eachoneoftheareastowhichtherouterisconnectedhasits
owndatastructure.Thisdatastructuredescribestheworking
ofthebasicOSPFalgorithm.Rememberthateacharearunsa
separatecopyofthebasicOSPFalgorithm.
Backbone(area)structure
TheOSPFbackboneareaisresponsibleforthedisseminationof
interarearoutinginformation.
Virtuallinksconfigured
Thevirtuallinksconfiguredwiththisrouterasoneendpoint.
Inordertohaveconfiguredvirtuallinks,therouteritself
mustbeanareaborderrouter.Virtuallinksareidentifiedby
theRouterIDoftheotherendpointwhichisanotherarea
borderrouter.Thesetwoendpointroutersmustbeattachedtoa
commonarea,calledthevirtuallink'sTransitarea.Virtual
linksarepartofthebackbone,andbehaveasiftheywere
unnumberedpointtopointnetworksbetweenthetworouters.A
virtuallinkusestheintraarearoutingofitsTransitareato
forwardpackets.Virtuallinksarebroughtupanddownthrough
thebuildingoftheshortestpathtreesfortheTransitarea.
Listofexternalroutes
TheseareroutestodestinationsexternaltotheAutonomous
System,thathavebeengainedeitherthroughdirectexperience
withanotherroutingprotocol(suchasBGP),orthrough
configurationinformation,orthroughacombinationofthetwo
(e.g.,dynamicexternalinformationtobeadvertisedbyOSPF
withconfiguredmetric).Anyrouterhavingtheseexternalroutes
iscalledanASboundaryrouter.Theseroutesareadvertisedby
therouterintotheOSPFroutingdomainviaASexternalLSAs.
ListofASexternalLSAs
Partofthelinkstatedatabase.Thesehaveoriginatedfromthe
ASboundaryrouters.Theycompriseroutestodestinations
externaltotheAutonomousSystem.Notethat,iftherouteris
itselfanASboundaryrouter,someoftheseASexternalLSAs
havebeenselforiginated.
37/188
3/2/2015
Theroutingtable
Derivedfromthelinkstatedatabase.Eachentryintherouting
tableisindexedbyadestination,andcontainsthe
destination'scostandasetofpathstouseinforwarding
packetstothedestination.Apathisdescribedbyitstypeand
nexthop.Formoreinformation,seeSection11.
Figure9showsthecollectionofdatastructurespresentina
typicalrouter.TherouterpicturedisRT10,fromthemapinFigure
6.NotethatRouterRT10hasavirtuallinkconfiguredtoRouter
RT11,withArea2asthelink'sTransitarea.Thisisindicatedby
thedashedlineinFigure9.Whenthevirtuallinkbecomesactive,
throughthebuildingoftheshortestpathtreeforArea2,it
becomesaninterfacetothebackbone(seethetwobackbone
interfacesdepictedinFigure9).
6.TheAreaDataStructure
Theareadatastructurecontainsalltheinformationusedtorunthe
basicOSPFroutingalgorithm.Eachareamaintainsitsownlinkstate
database.Anetworkbelongstoasinglearea,andarouterinterface
connectstoasinglearea.Eachrouteradjacencyalsobelongstoa
singlearea.
TheOSPFbackboneisthespecialOSPFarearesponsiblefor
disseminatinginterarearoutinginformation.
Thearealinkstatedatabaseconsistsofthecollectionofrouter
LSAs,networkLSAsandsummaryLSAsthathaveoriginatedfromthe
area'srouters.Thisinformationisfloodedthroughoutasingle
areaonly.ThelistofASexternalLSAs(seeSection5)isalso
consideredtobepartofeacharea'slinkstatedatabase.
AreaID
A32bitnumberidentifyingthearea.TheAreaIDof0.0.0.0is
reservedforthebackbone.
Listofareaaddressranges
Inordertoaggregateroutinginformationatareaboundaries,
areaaddressrangescanbeemployed.Eachaddressrangeis
specifiedbyan[address,mask]pairandastatusindicationof
eitherAdvertiseorDoNotAdvertise(seeSection12.4.3).
++
|RT10|+
++\++
/\|RoutingTable|
/\++
/\
++/\++
|Area2|++|Backbone|
++***********+++
/\*/\
/\*/\
++++++++
38/188
3/2/2015
|Interface||Interface||VirtualLink||InterfaceIb|
|toN6||toN8||toRT11|++
++++++|
/\|||
/\|||
++++|++++
|Neighbor||Neighbor|||NeighborRT11||NeighborRT6|
|RT8||RT7||++++
++++|
|
++
|NeighborRT11|
++
Figure9:RouterRT10'sDatastructures
Associatedrouterinterfaces
Thisrouter'sinterfacesconnectingtothearea.Arouter
interfacebelongstooneandonlyonearea(orthebackbone).
Forthebackboneareathislistincludesallthevirtuallinks.
AvirtuallinkisidentifiedbytheRouterIDofitsother
endpoint;itscostisthecostoftheshortestintraareapath
throughtheTransitareathatexistsbetweenthetworouters.
ListofrouterLSAs
ArouterLSAisgeneratedbyeachrouterinthearea.It
describesthestateoftherouter'sinterfacestothearea.
ListofnetworkLSAs
OnenetworkLSAisgeneratedforeachtransitbroadcastandNBMA
networkinthearea.AnetworkLSAdescribesthesetofrouters
currentlyconnectedtothenetwork.
ListofsummaryLSAs
SummaryLSAsoriginatefromthearea'sareaborderrouters.
TheydescriberoutestodestinationsinternaltotheAutonomous
System,yetexternaltothearea(i.e.,interarea
destinations).
Shortestpathtree
Theshortestpathtreeforthearea,withthisrouteritselfas
root.DerivedfromthecollectedrouterLSAsandnetworkLSAs
bytheDijkstraalgorithm(seeSection16.1).
TransitCapability
Thisparameterindicateswhethertheareacancarrydatatraffic
thatneitheroriginatesnorterminatesintheareaitself.This
parameteriscalculatedwhenthearea'sshortestpathtreeis
built(seeSection16.1,whereTransitCapabilityissettoTRUE
ifandonlyifthereareoneormorefullyadjacentvirtual
linksusingtheareaasTransitarea),andisusedasaninput
toasubsequentstepoftheroutingtablebuildprocess(see
Section16.3).Whenanarea'sTransitCapabilityissettoTRUE,
theareaissaidtobea"transitarea".
39/188
3/2/2015
WhetherASexternalLSAswillbefloodedinto/throughoutthe
area.Thisisaconfigurableparameter.IfASexternalLSAs
areexcludedfromthearea,theareaiscalleda"stub".Within
stubareas,routingtoASexternaldestinationswillbebased
solelyonadefaultsummaryroute.Thebackbonecannotbe
configuredasastubarea.Also,virtuallinkscannotbe
configuredthroughstubareas.Formoreinformation,see
Section3.6.
StubDefaultCost
Iftheareahasbeenconfiguredasastubarea,andtherouter
itselfisanareaborderrouter,thentheStubDefaultCost
indicatesthecostofthedefaultsummaryLSAthattherouter
shouldadvertiseintothearea.SeeSection12.4.3formore
information.
Unlessotherwisespecified,theremainingsectionsofthisdocument
refertotheoperationoftheOSPFprotocolwithinasinglearea.
7.BringingUpAdjacencies
OSPFcreatesadjacenciesbetweenneighboringroutersforthepurpose
ofexchangingroutinginformation.Noteverytwoneighboring
routerswillbecomeadjacent.Thissectioncoversthegeneralities
involvedincreatingadjacencies.Forfurtherdetailsconsult
Section10.
7.1.TheHelloProtocol
TheHelloProtocolisresponsibleforestablishingand
maintainingneighborrelationships.Italsoensuresthat
communicationbetweenneighborsisbidirectional.Hellopackets
aresentperiodicallyoutallrouterinterfaces.Bidirectional
communicationisindicatedwhentherouterseesitselflistedin
theneighbor'sHelloPacket.OnbroadcastandNBMAnetworks,
theHelloProtocolelectsaDesignatedRouterforthenetwork.
TheHelloProtocolworksdifferentlyonbroadcastnetworks,NBMA
networksandPointtoMultiPointnetworks.Onbroadcast
networks,eachrouteradvertisesitselfbyperiodically
multicastingHelloPackets.Thisallowsneighborstobe
discovereddynamically.TheseHelloPacketscontainthe
router'sviewoftheDesignatedRouter'sidentity,andthelist
ofrouterswhoseHelloPacketshavebeenseenrecently.
OnNBMAnetworkssomeconfigurationinformationmaybenecessary
fortheoperationoftheHelloProtocol.Eachrouterthatmay
potentiallybecomeDesignatedRouterhasalistofallother
40/188
3/2/2015
routersattachedtothenetwork.Arouter,havingDesignated
Routerpotential,sendsHelloPacketstoallotherpotential
DesignatedRouterswhenitsinterfacetotheNBMAnetworkfirst
becomesoperational.ThisisanattempttofindtheDesignated
Routerforthenetwork.Iftherouteritselfiselected
DesignatedRouter,itbeginssendingHelloPacketstoallother
routersattachedtothenetwork.
OnPointtoMultiPointnetworks,aroutersendsHelloPacketsto
allneighborswithwhichitcancommunicatedirectly.These
neighborsmaybediscovereddynamicallythroughaprotocolsuch
asInverseARP(see[Ref14]),ortheymaybeconfigured.
Afteraneighborhasbeendiscovered,bidirectional
communicationensured,and(ifonabroadcastorNBMAnetwork)a
DesignatedRouterelected,adecisionismaderegardingwhether
ornotanadjacencyshouldbeformedwiththeneighbor(see
Section10.4).Ifanadjacencyistobeformed,thefirststep
istosynchronizetheneighbors'linkstatedatabases.Thisis
coveredinthenextsection.
7.2.TheSynchronizationofDatabases
Inalinkstateroutingalgorithm,itisveryimportantforall
routers'linkstatedatabasestostaysynchronized.OSPF
simplifiesthisbyrequiringonlyadjacentrouterstoremain
synchronized.Thesynchronizationprocessbeginsassoonasthe
routersattempttobringuptheadjacency.Eachrouter
describesitsdatabasebysendingasequenceofDatabase
Descriptionpacketstoitsneighbor.EachDatabaseDescription
PacketdescribesasetofLSAsbelongingtotherouter's
database.WhentheneighborseesanLSAthatismorerecent
thanitsowndatabasecopy,itmakesanotethatthisnewerLSA
shouldberequested.
ThissendingandreceivingofDatabaseDescriptionpacketsis
calledthe"DatabaseExchangeProcess".Duringthisprocess,
thetworoutersformamaster/slaverelationship.EachDatabase
DescriptionPackethasasequencenumber.DatabaseDescription
Packetssentbythemaster(polls)areacknowledgedbytheslave
throughechoingofthesequencenumber.Bothpollsandtheir
responsescontainsummariesoflinkstatedata.Themasteris
theonlyoneallowedtoretransmitDatabaseDescriptionPackets.
Itdoessoonlyatfixedintervals,thelengthofwhichisthe
configuredperinterfaceconstantRxmtInterval.
EachDatabaseDescriptioncontainsanindicationthatthereare
morepacketstofollowtheMbit.TheDatabaseExchange
ProcessisoverwhenarouterhasreceivedandsentDatabase
DescriptionPacketswiththeMbitoff.
41/188
3/2/2015
DuringandaftertheDatabaseExchangeProcess,eachrouterhas
alistofthoseLSAsforwhichtheneighborhasmoreuptodate
instances.TheseLSAsarerequestedinLinkStateRequest
Packets.LinkStateRequestpacketsthatarenotsatisfiedare
retransmittedatfixedintervalsoftimeRxmtInterval.Whenthe
DatabaseDescriptionProcesshascompletedandallLinkState
Requestshavebeensatisfied,thedatabasesaredeemed
synchronizedandtheroutersaremarkedfullyadjacent.Atthis
timetheadjacencyisfullyfunctionalandisadvertisedinthe
tworouters'routerLSAs.
Theadjacencyisusedbythefloodingprocedureassoonasthe
DatabaseExchangeProcessbegins.Thissimplifiesdatabase
synchronization,andguaranteesthatitfinishesina
predictableperiodoftime.
7.3.TheDesignatedRouter
EverybroadcastandNBMAnetworkhasaDesignatedRouter.The
DesignatedRouterperformstwomainfunctionsfortherouting
protocol:
oTheDesignatedRouteroriginatesanetworkLSAonbehalfof
thenetwork.ThisLSAliststhesetofrouters(including
theDesignatedRouteritself)currentlyattachedtothe
network.TheLinkStateIDforthisLSA(seeSection
12.1.4)istheIPinterfaceaddressoftheDesignated
Router.TheIPnetworknumbercanthenbeobtainedbyusing
thenetwork'ssubnet/networkmask.
oTheDesignatedRouterbecomesadjacenttoallotherrouters
onthenetwork.Sincethelinkstatedatabasesare
synchronizedacrossadjacencies(throughadjacencybringup
andthenthefloodingprocedure),theDesignatedRouter
playsacentralpartinthesynchronizationprocess.
TheDesignatedRouteriselectedbytheHelloProtocol.A
router'sHelloPacketcontainsitsRouterPriority,whichis
configurableonaperinterfacebasis.Ingeneral,whena
router'sinterfacetoanetworkfirstbecomesfunctional,it
checkstoseewhetherthereiscurrentlyaDesignatedRouterfor
thenetwork.Ifthereis,itacceptsthatDesignatedRouter,
regardlessofitsRouterPriority.(Thismakesitharderto
predicttheidentityoftheDesignatedRouter,butensuresthat
theDesignatedRouterchangeslessoften.Seebelow.)
Otherwise,therouteritselfbecomesDesignatedRouterifithas
thehighestRouterPriorityonthenetwork.Amoredetailed
(andmoreaccurate)descriptionofDesignatedRouterelectionis
presentedinSection9.4.
TheDesignatedRouteristheendpointofmanyadjacencies.In
ordertooptimizethefloodingprocedureonbroadcastnetworks,
theDesignatedRoutermulticastsitsLinkStateUpdatePackets
totheaddressAllSPFRouters,ratherthansendingseparate
42/188
3/2/2015
packetsovereachadjacency.
Section2ofthisdocumentdiscussesthedirectedgraph
representationofanarea.Routernodesarelabelledwiththeir
RouterID.Transitnetworknodesareactuallylabelledwiththe
IPaddressoftheirDesignatedRouter.Itfollowsthatwhenthe
DesignatedRouterchanges,itappearsasifthenetworknodeon
thegraphisreplacedbyanentirelynewnode.Thiswillcause
thenetworkandallitsattachedrouterstooriginatenewLSAs.
Untilthelinkstatedatabasesagainconverge,sometemporary
lossofconnectivitymayresult.ThismayresultinICMP
unreachablemessagesbeingsentinresponsetodatatraffic.
Forthatreason,theDesignatedRoutershouldchangeonly
infrequently.RouterPrioritiesshouldbeconfiguredsothat
themostdependablerouteronanetworkeventuallybecomes
DesignatedRouter.
7.4.TheBackupDesignatedRouter
InordertomakethetransitiontoanewDesignatedRouter
smoother,thereisaBackupDesignatedRouterforeachbroadcast
andNBMAnetwork.TheBackupDesignatedRouterisalsoadjacent
toallroutersonthenetwork,andbecomesDesignatedRouter
whenthepreviousDesignatedRouterfails.Iftherewereno
BackupDesignatedRouter,whenanewDesignatedRouterbecame
necessary,newadjacencieswouldhavetobeformedbetweenthe
newDesignatedRouterandallotherroutersattachedtothe
network.Partoftheadjacencyformingprocessisthe
synchronizingoflinkstatedatabases,whichcanpotentially
takequitealongtime.Duringthistime,thenetworkwouldnot
beavailablefortransitdatatraffic.TheBackupDesignated
obviatestheneedtoformtheseadjacencies,sincetheyalready
exist.Thismeanstheperiodofdisruptionintransittraffic
lastsonlyaslongasittakestofloodthenewLSAs(which
announcethenewDesignatedRouter).
TheBackupDesignatedRouterdoesnotgenerateanetworkLSAfor
thenetwork.(Ifitdid,thetransitiontoanewDesignated
Routerwouldbeevenfaster.However,thisisatradeoff
betweendatabasesizeandspeedofconvergencewhenthe
DesignatedRouterdisappears.)
TheBackupDesignatedRouterisalsoelectedbytheHello
Protocol.EachHelloPackethasafieldthatspecifiesthe
BackupDesignatedRouterforthenetwork.
Insomestepsofthefloodingprocedure,theBackupDesignated
Routerplaysapassiverole,lettingtheDesignatedRouterdo
moreofthework.Thiscutsdownontheamountoflocalrouting
traffic.SeeSection13.3formoreinformation.
7.5.Thegraphofadjacencies
Anadjacencyisboundtothenetworkthatthetworoutershave
incommon.Iftworoutershavemultiplenetworksincommon,
theymayhavemultipleadjacenciesbetweenthem.
43/188
3/2/2015
Onecanpicturethecollectionofadjacenciesonanetworkas
forminganundirectedgraph.Theverticesconsistofrouters,
withanedgejoiningtworoutersiftheyareadjacent.The
graphofadjacenciesdescribestheflowofroutingprotocol
packets,andinparticularLinkStateUpdatePackets,through
theAutonomousSystem.
Twographsarepossible,dependingonwhetheraDesignated
Routeriselectedforthenetwork.Onphysicalpointtopoint
networks,PointtoMultiPointnetworksandvirtuallinks,
neighboringroutersbecomeadjacentwhenevertheycan
communicatedirectly.Incontrast,onbroadcastandNBMA
networksonlytheDesignatedRouterandtheBackupDesignated
Routerbecomeadjacenttoallotherroutersattachedtothe
network.
++++
|RT1||RT2|oo
++N1++RT1RT2
RT7
o+
++++++/|\|
|RT7||RT3||RT4|/|\|
++++++/|\|
|||/|\|
++RT5oRT6ooRT4|
||N2***|
++++***|
|RT5||RT6|***|
++++***|
o+
RT3
Figure10:Thegraphofadjacencies
ThesegraphsareshowninFigure10.ItisassumedthatRouter
RT7hasbecometheDesignatedRouter,andRouterRT3theBackup
DesignatedRouter,fortheNetworkN2.TheBackupDesignated
Routerperformsalesserfunctionduringthefloodingprocedure
thantheDesignatedRouter(seeSection13.3).Thisisthe
44/188
3/2/2015
reasonforthedashedlinesconnectingtheBackupDesignated
RouterRT3.
8.ProtocolPacketProcessing
ThissectiondiscussesthegeneralprocessingofOSPFrouting
protocolpackets.Itisveryimportantthattherouterlinkstate
databasesremainsynchronized.Forthisreason,routingprotocol
packetsshouldgetpreferentialtreatmentoverordinarydata
packets,bothinsendingandreceiving.
Routingprotocolpacketsaresentalongadjacenciesonly(withthe
exceptionofHellopackets,whichareusedtodiscoverthe
adjacencies).Thismeansthatallroutingprotocolpacketstravela
singleIPhop,exceptthosesentovervirtuallinks.
Allroutingprotocolpacketsbeginwithastandardheader.The
sectionsbelowprovidedetailsonhowtofillinandverifythis
standardheader.Then,foreachpackettype,thesectiongiving
moredetailsonthatparticularpackettype'sprocessingislisted.
8.1.Sendingprotocolpackets
Whenaroutersendsaroutingprotocolpacket,itfillsinthe
fieldsofthestandardOSPFpacketheaderasfollows.Formore
detailsontheheaderformatconsultSectionA.3.1:
Version#
Setto2,theversionnumberoftheprotocolasdocumented
inthisspecification.
Packettype
ThetypeofOSPFpacket,suchasLinkstateUpdateorHello
Packet.
Packetlength
ThelengthoftheentireOSPFpacketinbytes,includingthe
standardOSPFpacketheader.
RouterID
Theidentityoftherouteritself(whoisoriginatingthe
packet).
AreaID
TheOSPFareathatthepacketisbeingsentinto.
Checksum
ThestandardIP16bitone'scomplementchecksumofthe
entireOSPFpacket,excludingthe64bitauthentication
field.Thischecksumiscalculatedaspartofthe
appropriateauthenticationprocedure;forsomeOSPF
authenticationtypes,thechecksumcalculationisomitted.
SeeSectionD.4fordetails.
AuTypeandAuthentication
45/188
3/2/2015
EachOSPFpacketexchangeisauthenticated.Authentication
typesareassignedbytheprotocolandaredocumentedin
AppendixD.Adifferentauthenticationprocedurecanbe
usedforeachIPnetwork/subnet.Autypeindicatesthetype
ofauthenticationprocedureinuse.The64bit
authenticationfieldisthenforusebythechosen
authenticationprocedure.Thisprocedureshouldbethelast
calledwhenformingthepackettobesent.SeeSectionD.4
fordetails.
TheIPdestinationaddressforthepacketisselectedas
follows.Onphysicalpointtopointnetworks,theIP
destinationisalwayssettotheaddressAllSPFRouters.Onall
othernetworktypes(includingvirtuallinks),themajorityof
OSPFpacketsaresentasunicasts,i.e.,sentdirectlytothe
otherendoftheadjacency.Inthiscase,theIPdestinationis
justtheNeighborIPaddressassociatedwiththeotherendof
theadjacency(seeSection10).Theonlypacketsnotsentas
unicastsareonbroadcastnetworks;onthesenetworksHello
packetsaresenttothemulticastdestinationAllSPFRouters,the
DesignatedRouteranditsBackupsendbothLinkStateUpdate
PacketsandLinkStateAcknowledgmentPacketstothemulticast
addressAllSPFRouters,whileallotherrouterssendboththeir
LinkStateUpdateandLinkStateAcknowledgmentPacketstothe
multicastaddressAllDRouters.
RetransmissionsofLinkStateUpdatepacketsareALWAYSsent
directlytotheneighbor.Onmultiaccessnetworks,thismeans
thatretransmissionsshouldbesenttotheneighbor'sIP
address.
TheIPsourceaddressshouldbesettotheIPaddressofthe
sendinginterface.Interfacestounnumberedpointtopoint
networkshavenoassociatedIPaddress.Ontheseinterfaces,
theIPsourceshouldbesettoanyoftheotherIPaddresses
belongingtotherouter.Forthisreason,theremustbeat
leastoneIPaddressassignedtotherouter.[2]Notethat,for
mostpurposes,virtuallinksactpreciselythesameas
unnumberedpointtopointnetworks.However,eachvirtuallink
doeshaveanIPinterfaceaddress(discoveredduringtherouting
tablebuildprocess)whichisusedastheIPsourcewhensending
packetsoverthevirtuallink.
FormoreinformationontheformatofspecificOSPFpacket
types,consultthesectionslistedinTable10.
TypePacketnamedetailedsection(transmit)
_________________________________________________________
1HelloSection9.5
2DatabasedescriptionSection10.8
3LinkstaterequestSection10.9
4LinkstateupdateSection13.3
5LinkstateackSection13.5
46/188
3/2/2015
Table10:SectionsdescribingOSPFprotocolpackettransmission.
8.2.Receivingprotocolpackets
Wheneveraprotocolpacketisreceivedbytherouteritis
markedwiththeinterfaceitwasreceivedon.Forroutersthat
havevirtuallinksconfigured,itmaynotbeimmediatelyobvious
whichinterfacetoassociatethepacketwith.Forexample,
considertheRouterRT11depictedinFigure6.IfRT11receives
anOSPFprotocolpacketonitsinterfacetoNetworkN8,itmay
wanttoassociatethepacketwiththeinterfacetoArea2,or
withthevirtuallinktoRouterRT10(whichispartofthe
backbone).Inthefollowing,weassumethatthepacketis
initiallyassociatedwiththenonvirtuallink.[3]
InorderforthepackettobeacceptedattheIPlevel,itmust
passanumberoftests,evenbeforethepacketispassedtoOSPF
forprocessing:
oTheIPchecksummustbecorrect.
oThepacket'sIPdestinationaddressmustbetheIPaddress
ofthereceivinginterface,oroneoftheIPmulticast
addressesAllSPFRoutersorAllDRouters.
oTheIPprotocolspecifiedmustbeOSPF(89).
oLocallyoriginatedpacketsshouldnotbepassedontoOSPF.
Thatis,thesourceIPaddressshouldbeexaminedtomake
surethisisnotamulticastpacketthattherouteritself
generated.
Next,theOSPFpacketheaderisverified.Thefieldsspecified
intheheadermustmatchthoseconfiguredforthereceiving
interface.Iftheydonot,thepacketshouldbediscarded:
oTheversionnumberfieldmustspecifyprotocolversion2.
oTheAreaIDfoundintheOSPFheadermustbeverified.If
bothofthefollowingcasesfail,thepacketshouldbe
discarded.TheAreaIDspecifiedintheheadermusteither:
47/188
3/2/2015
(1)MatchtheAreaIDofthereceivinginterface.Inthis
case,thepackethasbeensentoverasinglehop.
Therefore,thepacket'sIPsourceaddressisrequiredto
beonthesamenetworkasthereceivinginterface.This
canbeverifiedbycomparingthepacket'sIPsource
addresstotheinterface'sIPaddress,aftermasking
bothaddresseswiththeinterfacemask.Thiscomparison
shouldnotbeperformedonpointtopointnetworks.On
pointtopointnetworks,theinterfaceaddressesofeach
endofthelinkareassignedindependently,iftheyare
assignedatall.
(2)Indicatethebackbone.Inthiscase,thepackethas
beensentoveravirtuallink.Thereceivingrouter
mustbeanareaborderrouter,andtheRouterID
specifiedinthepacket(thesourcerouter)mustbethe
otherendofaconfiguredvirtuallink.Thereceiving
interfacemustalsoattachtothevirtuallink's
configuredTransitarea.Ifallofthesechecks
succeed,thepacketisacceptedandisfromnowon
associatedwiththevirtuallink(andthebackbone
area).
oPacketswhoseIPdestinationisAllDRoutersshouldonlybe
acceptedifthestateofthereceivinginterfaceisDRor
Backup(seeSection9.1).
oTheAuTypespecifiedinthepacketmustmatchtheAuType
specifiedfortheassociatedarea.
oThepacketmustbeauthenticated.Theauthentication
procedureisindicatedbythesettingofAuType(see
AppendixD).Theauthenticationproceduremayuseoneor
moreAuthenticationkeys,whichcanbeconfiguredonaper
interfacebasis.Theauthenticationproceduremayalso
verifythechecksumfieldintheOSPFpacketheader(which,
whenused,issettothestandardIP16bitone'scomplement
checksumoftheOSPFpacket'scontentsafterexcludingthe
64bitauthenticationfield).Iftheauthentication
procedurefails,thepacketshouldbediscarded.
IfthepackettypeisHello,itshouldthenbefurtherprocessed
bytheHelloProtocol(seeSection10.5).Allotherpacket
typesaresent/receivedonlyonadjacencies.Thismeansthat
thepacketmusthavebeensentbyoneoftherouter'sactive
neighbors.Ifthereceivinginterfaceconnectstoabroadcast
network,PointtoMultiPointnetworkorNBMAnetworkthesender
isidentifiedbytheIPsourceaddressfoundinthepacket'sIP
header.Ifthereceivinginterfaceconnectstoapointtopoint
networkoravirtuallink,thesenderisidentifiedbythe
RouterID(sourcerouter)foundinthepacket'sOSPFheader.
Thedatastructureassociatedwiththereceivinginterface
containsthelistofactiveneighbors.Packetsnotmatchingany
activeneighborarediscarded.
Atthispointallreceivedprotocolpacketsareassociatedwith
48/188
3/2/2015
anactiveneighbor.Forthefurtherinputprocessingof
specificpackettypes,consultthesectionslistedinTable11.
TypePacketnamedetailedsection(receive)
________________________________________________________
1HelloSection10.5
2DatabasedescriptionSection10.6
3LinkstaterequestSection10.7
4LinkstateupdateSection13
5LinkstateackSection13.7
Table11:SectionsdescribingOSPFprotocolpacketreception.
9.TheInterfaceDataStructure
AnOSPFinterfaceistheconnectionbetweenarouterandanetwork.
WeassumeasingleOSPFinterfacetoeachattachednetwork/subnet,
althoughsupportingmultipleinterfacesonasinglenetworkis
consideredinAppendixF.Eachinterfacestructurehasatmostone
IPinterfaceaddress.
AnOSPFinterfacecanbeconsideredtobelongtotheareathat
containstheattachednetwork.Allroutingprotocolpackets
originatedbytherouteroverthisinterfacearelabelledwiththe
interface'sAreaID.Oneormorerouteradjacenciesmaydevelop
overaninterface.Arouter'sLSAsreflectthestateofits
interfacesandtheirassociatedadjacencies.
Thefollowingdataitemsareassociatedwithaninterface.Note
thatanumberoftheseitemsareactuallyconfigurationforthe
attachednetwork;suchitemsmustbethesameforallrouters
connectedtothenetwork.
Type
TheOSPFinterfacetypeiseitherpointtopoint,broadcast,
NBMA,PointtoMultiPointorvirtuallink.
State
Thefunctionallevelofaninterface.Statedetermineswhether
ornotfulladjacenciesareallowedtoformovertheinterface.
Stateisalsoreflectedintherouter'sLSAs.
IPinterfaceaddress
TheIPaddressassociatedwiththeinterface.Thisappearsas
theIPsourceaddressinallroutingprotocolpacketsoriginated
overthisinterface.Interfacestounnumberedpointtopoint
networksdonothaveanassociatedIPaddress.
IPinterfacemask
Alsoreferredtoasthesubnetmask,thisindicatestheportion
oftheIPinterfaceaddressthatidentifiestheattached
49/188
3/2/2015
network.MaskingtheIPinterfaceaddresswiththeIPinterface
maskyieldstheIPnetworknumberoftheattachednetwork.On
pointtopointnetworksandvirtuallinks,theIPinterfacemask
isnotdefined.Onthesenetworks,thelinkitselfisnot
assignedanIPnetworknumber,andsotheaddressesofeachside
ofthelinkareassignedindependently,iftheyareassignedat
all.
AreaID
TheAreaIDoftheareatowhichtheattachednetworkbelongs.
Allroutingprotocolpacketsoriginatingfromtheinterfaceare
labelledwiththisAreaID.
HelloInterval
Thelengthoftime,inseconds,betweentheHellopacketsthat
theroutersendsontheinterface.AdvertisedinHellopackets
sentoutthisinterface.
RouterDeadInterval
Thenumberofsecondsbeforetherouter'sneighborswilldeclare
itdown,whentheystophearingtherouter'sHelloPackets.
AdvertisedinHellopacketssentoutthisinterface.
InfTransDelay
TheestimatednumberofsecondsittakestotransmitaLink
StateUpdatePacketoverthisinterface.LSAscontainedinthe
LinkStateUpdatepacketwillhavetheirageincrementedbythis
amountbeforetransmission.Thisvalueshouldtakeintoaccount
transmissionandpropagationdelays;itmustbegreaterthan
zero.
RouterPriority
An8bitunsignedinteger.Whentworoutersattachedtoa
networkbothattempttobecomeDesignatedRouter,theonewith
thehighestRouterPrioritytakesprecedence.Arouterwhose
RouterPriorityissetto0isineligibletobecomeDesignated
Routerontheattachednetwork.AdvertisedinHellopackets
sentoutthisinterface.
HelloTimer
AnintervaltimerthatcausestheinterfacetosendaHello
packet.ThistimerfireseveryHelloIntervalseconds.Note
thatonnonbroadcastnetworksaseparateHellopacketissent
toeachqualifiedneighbor.
WaitTimer
Asingleshottimerthatcausestheinterfacetoexitthe
Waitingstate,andasaconsequenceselectaDesignatedRouter
onthenetwork.ThelengthofthetimerisRouterDeadInterval
seconds.
Listofneighboringrouters
Theotherroutersattachedtothisnetwork.Thislistisformed
bytheHelloProtocol.Adjacencieswillbeformedtosomeof
50/188
3/2/2015
theseneighbors.Thesetofadjacentneighborscanbe
determinedbyanexaminationofalloftheneighbors'states.
DesignatedRouter
TheDesignatedRouterselectedfortheattachednetwork.The
DesignatedRouterisselectedonallbroadcastandNBMAnetworks
bytheHelloProtocol.Twopiecesofidentificationarekept
fortheDesignatedRouter:itsRouterIDanditsIPinterface
addressonthenetwork.TheDesignatedRouteradvertiseslink
stateforthenetwork;thisnetworkLSAislabelledwiththe
DesignatedRouter'sIPaddress.TheDesignatedRouteris
initializedto0.0.0.0,whichindicatesthelackofaDesignated
Router.
BackupDesignatedRouter
TheBackupDesignatedRouterisalsoselectedonallbroadcast
andNBMAnetworksbytheHelloProtocol.Allroutersonthe
attachednetworkbecomeadjacenttoboththeDesignatedRouter
andtheBackupDesignatedRouter.TheBackupDesignatedRouter
becomesDesignatedRouterwhenthecurrentDesignatedRouter
fails.TheBackupDesignatedRouterisinitializedto0.0.0.0,
indicatingthelackofaBackupDesignatedRouter.
Interfaceoutputcost(s)
Thecostofsendingadatapacketontheinterface,expressedin
thelinkstatemetric.Thisisadvertisedasthelinkcostfor
thisinterfaceintherouterLSA.Thecostofaninterfacemust
begreaterthanzero.
RxmtInterval
ThenumberofsecondsbetweenLSAretransmissions,for
adjacenciesbelongingtothisinterface.Alsousedwhen
retransmittingDatabaseDescriptionandLinkStateRequest
Packets.
AuType
Thetypeofauthenticationusedontheattachednetwork/subnet.
AuthenticationtypesaredefinedinAppendixD.AllOSPFpacket
exchangesareauthenticated.Differentauthenticationschemes
maybeusedondifferentnetworks/subnets.
Authenticationkey
Thisconfigureddataallowstheauthenticationprocedureto
generateand/orverifyOSPFprotocolpackets.The
Authenticationkeycanbeconfiguredonaperinterfacebasis.
Forexample,iftheAuTypeindicatessimplepassword,the
Authenticationkeywouldbea64bitclearpasswordwhichis
insertedintotheOSPFpacketheader.IfinsteadAutype
indicatesCryptographicauthentication,thentheAuthentication
keyisasharedsecretwhichenablesthegeneration/verification
ofmessagedigestswhichareappendedtotheOSPFprotocol
51/188
3/2/2015
packets.WhenCryptographicauthenticationisused,multiple
simultaneouskeysaresupportedinordertoachievesmoothkey
transition(seeSectionD.3).
9.1.Interfacestates
Thevariousstatesthatrouterinterfacesmayattainis
documentedinthissection.Thestatesarelistedinorderof
progressingfunctionality.Forexample,theinoperativestate
islistedfirst,followedbyalistofintermediatestates
beforethefinal,fullyfunctionalstateisachieved.The
specificationmakesuseofthisorderingbysometimesmaking
referencessuchas"thoseinterfacesinstategreaterthanX".
Figure11showsthegraphofinterfacestatechanges.Thearcs
ofthegrapharelabelledwiththeeventcausingthestate
change.TheseeventsaredocumentedinSection9.2.The
interfacestatemachineisdescribedinmoredetailinSection
9.3.
Down
Thisistheinitialinterfacestate.Inthisstate,the
lowerlevelprotocolshaveindicatedthattheinterfaceis
unusable.Noprotocoltrafficatallwillbesentor
receivedonsuchainterface.Inthisstate,interface
parametersshouldbesettotheirinitialvalues.All
interfacetimersshouldbedisabled,andthereshouldbeno
adjacenciesassociatedwiththeinterface.
Loopback
Inthisstate,therouter'sinterfacetothenetworkis
++UnloopInd++
|Down|<|Loopback|
++++
|
|InterfaceUp
++|++
|Waiting|<+>|Pointtopoint|
++++
|
WaitTimer|BackupSeen
|
|
|NeighborChange
++++<++
|Backup|<|?|>|DROther|
++>++<+++
Neighbor||
Change||Neighbor
||Change
|++
+>|DR|
++
Figure11:InterfaceStatechanges
52/188
3/2/2015
Inadditiontothestatetransitionspictured,
EventInterfaceDownalwaysforcesDownState,and
EventLoopIndalwaysforcesLoopbackState
loopedback.Theinterfacemaybeloopedbackinhardware
orsoftware.Theinterfacewillbeunavailableforregular
datatraffic.However,itmaystillbedesirabletogain
informationonthequalityofthisinterface,eitherthrough
sendingICMPpingstotheinterfaceorthroughsomething
likeabiterrortest.Forthisreason,IPpacketsmay
stillbeaddressedtoaninterfaceinLoopbackstate.To
facilitatethis,suchinterfacesareadvertisedinrouter
LSAsassinglehostroutes,whosedestinationistheIP
interfaceaddress.[4]
Waiting
Inthisstate,therouteristryingtodeterminethe
identityofthe(Backup)DesignatedRouterforthenetwork.
Todothis,theroutermonitorstheHelloPacketsit
receives.TherouterisnotallowedtoelectaBackup
DesignatedRouternoraDesignatedRouteruntilit
transitionsoutofWaitingstate.Thispreventsunnecessary
changesof(Backup)DesignatedRouter.
Pointtopoint
Inthisstate,theinterfaceisoperational,andconnects
eithertoaphysicalpointtopointnetworkortoavirtual
link.Uponenteringthisstate,therouterattemptstoform
anadjacencywiththeneighboringrouter.HelloPacketsare
senttotheneighboreveryHelloIntervalseconds.
DROther
TheinterfaceistoabroadcastorNBMAnetworkonwhich
anotherrouterhasbeenselectedtobetheDesignated
Router.Inthisstate,therouteritselfhasnotbeen
selectedBackupDesignatedRoutereither.Therouterforms
adjacenciestoboththeDesignatedRouterandtheBackup
DesignatedRouter(iftheyexist).
Backup
Inthisstate,therouteritselfistheBackupDesignated
Routerontheattachednetwork.Itwillbepromotedto
DesignatedRouterwhenthepresentDesignatedRouterfails.
Therouterestablishesadjacenciestoallotherrouters
attachedtothenetwork.TheBackupDesignatedRouter
performsslightlydifferentfunctionsduringtheFlooding
Procedure,ascomparedtotheDesignatedRouter(seeSection
13.3).SeeSection7.4formoredetailsonthefunctions
performedbytheBackupDesignatedRouter.
DRInthisstate,thisrouteritselfistheDesignatedRouter
53/188
3/2/2015
ontheattachednetwork.Adjacenciesareestablishedtoall
otherroutersattachedtothenetwork.Theroutermustalso
originateanetworkLSAforthenetworknode.Thenetwork
LSAwillcontainlinkstoallrouters(includingthe
DesignatedRouteritself)attachedtothenetwork.See
Section7.3formoredetailsonthefunctionsperformedby
theDesignatedRouter.
9.2.Eventscausinginterfacestatechanges
Statechangescanbeeffectedbyanumberofevents.These
eventsarepicturedasthelabelledarcsinFigure11.The
labeldefinitionsarelistedbelow.Foradetailedexplanation
oftheeffectoftheseeventsonOSPFprotocoloperation,
consultSection9.3.
InterfaceUp
Lowerlevelprotocolshaveindicatedthatthenetwork
interfaceisoperational.Thisenablestheinterfaceto
transitionoutofDownstate.Onvirtuallinks,the
interfaceoperationalindicationisactuallyaresultofthe
shortestpathcalculation(seeSection16.7).
WaitTimer
TheWaitTimerhasfired,indicatingtheendofthewaiting
periodthatisrequiredbeforeelectinga(Backup)
DesignatedRouter.
BackupSeen
Therouterhasdetectedtheexistenceornonexistenceofa
BackupDesignatedRouterforthenetwork.Thisisdonein
oneoftwoways.First,anHelloPacketmaybereceived
fromaneighborclaimingtobeitselftheBackupDesignated
Router.Alternatively,anHelloPacketmaybereceivedfrom
aneighborclaimingtobeitselftheDesignatedRouter,and
indicatingthatthereisnoBackupDesignatedRouter.In
eithercasetheremustbebidirectionalcommunicationwith
theneighbor,i.e.,theroutermustalsoappearinthe
neighbor'sHelloPacket.Thiseventsignalsanendtothe
Waitingstate.
NeighborChange
Therehasbeenachangeinthesetofbidirectional
neighborsassociatedwiththeinterface.The(Backup)
DesignatedRouterneedstoberecalculated.Thefollowing
neighborchangesleadtotheNeighborChangeevent.Foran
54/188
3/2/2015
explanationofneighborstates,seeSection10.1.
oBidirectionalcommunicationhasbeenestablishedtoa
neighbor.Inotherwords,thestateoftheneighborhas
transitionedto2Wayorhigher.
oThereisnolongerbidirectionalcommunicationwitha
neighbor.Inotherwords,thestateoftheneighborhas
transitionedtoInitorlower.
oOneofthebidirectionalneighborsisnewlydeclaring
itselfaseitherDesignatedRouterorBackupDesignated
Router.Thisisdetectedthroughexaminationofthat
neighbor'sHelloPackets.
oOneofthebidirectionalneighborsisnolonger
declaringitselfasDesignatedRouter,orisnolonger
declaringitselfasBackupDesignatedRouter.Thisis
againdetectedthroughexaminationofthatneighbor's
HelloPackets.
oTheadvertisedRouterPriorityforabidirectional
neighborhaschanged.Thisisagaindetectedthrough
examinationofthatneighbor'sHelloPackets.
LoopInd
Anindicationhasbeenreceivedthattheinterfaceisnow
loopedbacktoitself.Thisindicationcanbereceived
eitherfromnetworkmanagementorfromthelowerlevel
protocols.
UnloopInd
Anindicationhasbeenreceivedthattheinterfaceisno
longerloopedback.AswiththeLoopIndevent,this
indicationcanbereceivedeitherfromnetworkmanagementor
fromthelowerlevelprotocols.
InterfaceDown
Lowerlevelprotocolsindicatethatthisinterfaceisno
longerfunctional.Nomatterwhatthecurrentinterface
stateis,thenewinterfacestatewillbeDown.
9.3.TheInterfacestatemachine
Adetaileddescriptionoftheinterfacestatechangesfollows.
Eachstatechangeisinvokedbyanevent(Section9.2).This
eventmayproducedifferenteffects,dependingonthecurrent
stateoftheinterface.Forthisreason,thestatemachine
belowisorganizedbycurrentinterfacestateandreceived
event.Eachentryinthestatemachinedescribestheresulting
newinterfacestateandtherequiredsetofadditionalactions.
Whenaninterface'sstatechanges,itmaybenecessaryto
originateanewrouterLSA.SeeSection12.4formoredetails.
55/188
3/2/2015
Someoftherequiredactionsbelowinvolvegeneratingeventsfor
theneighborstatemachine.Forexample,whenaninterface
becomesinoperative,allneighborconnectionsassociatedwith
theinterfacemustbedestroyed.Formoreinformationonthe
neighborstatemachine,seeSection10.3.
State(s):Down
Event:InterfaceUp
Newstate:Dependsuponactionroutine
Action:StarttheintervalHelloTimer,enablingthe
periodicsendingofHellopacketsouttheinterface.
Iftheattachednetworkisaphysicalpointtopoint
network,PointtoMultiPointnetworkorvirtual
link,theinterfacestatetransitionstoPointto
Point.Else,iftherouterisnoteligibleto
becomeDesignatedRoutertheinterfacestate
transitionstoDROther.
Otherwise,theattachednetworkisabroadcastor
NBMAnetworkandtherouteriseligibletobecome
DesignatedRouter.Inthiscase,inanattemptto
discovertheattachednetwork'sDesignatedRouter
theinterfacestateissettoWaitingandthesingle
shotWaitTimerisstarted.Additionally,ifthe
networkisanNBMAnetworkexaminetheconfigured
listofneighborsforthisinterfaceandgenerate
theneighboreventStartforeachneighborthatis
alsoeligibletobecomeDesignatedRouter.
State(s):Waiting
Event:BackupSeen
Newstate:Dependsuponactionroutine.
Action:Calculatetheattachednetwork'sBackupDesignated
RouterandDesignatedRouter,asshowninSection
9.4.Asaresultofthiscalculation,thenewstate
oftheinterfacewillbeeitherDROther,Backupor
DR.
State(s):Waiting
Event:WaitTimer
Action:Calculatetheattachednetwork'sBackupDesignated
56/188
3/2/2015
DR.
State(s):DROther,BackuporDR
Event:NeighborChange
Action:Recalculatetheattachednetwork'sBackupDesignated
DR.
State(s):AnyState
Event:InterfaceDown
Newstate:Down
Action:Allinterfacevariablesarereset,andinterface
timersdisabled.Also,allneighborconnections
associatedwiththeinterfacearedestroyed.This
isdonebygeneratingtheeventKillNbronall
associatedneighbors(seeSection10.2).
State(s):AnyState
Event:LoopInd
Newstate:Loopback
Action:Sincethisinterfaceisnolongerconnectedtothe
attachednetworktheactionsassociatedwiththe
aboveInterfaceDowneventareexecuted.
State(s):Loopback
Event:UnloopInd
Newstate:Down
Action:Noactionsarenecessary.Forexample,the
interfacevariableshavealreadybeenresetupon
enteringtheLoopbackstate.Notethatreceptionof
57/188
3/2/2015
anInterfaceUpeventisnecessarybeforethe
interfaceagainbecomesfullyfunctional.
9.4.ElectingtheDesignatedRouter
Thissectiondescribesthealgorithmusedforcalculatinga
network'sDesignatedRouterandBackupDesignatedRouter.This
algorithmisinvokedbytheInterfacestatemachine.The
initialtimearouterrunstheelectionalgorithmforanetwork,
thenetwork'sDesignatedRouterandBackupDesignatedRouterare
initializedto0.0.0.0.Thisindicatesthelackofbotha
DesignatedRouterandaBackupDesignatedRouter.
TheDesignatedRouterelectionalgorithmproceedsasfollows:
CalltherouterdoingthecalculationRouterX.Thelistof
neighborsattachedtothenetworkandhavingestablished
bidirectionalcommunicationwithRouterXisexamined.This
listispreciselythecollectionofRouterX'sneighbors(on
thisnetwork)whosestateisgreaterthanorequalto2Way(see
Section10.1).RouterXitselfisalsoconsideredtobeonthe
list.Discardallroutersfromthelistthatareineligibleto
becomeDesignatedRouter.(RoutershavingRouterPriorityof0
areineligibletobecomeDesignatedRouter.)Thefollowing
stepsarethenexecuted,consideringonlythoseroutersthat
remainonthelist:
(1)Notethecurrentvaluesforthenetwork'sDesignatedRouter
andBackupDesignatedRouter.Thisisusedlaterfor
comparisonpurposes.
(2)CalculatethenewBackupDesignatedRouterforthenetwork
asfollows.Onlythoseroutersonthelistthathavenot
declaredthemselvestobeDesignatedRouterareeligibleto
becomeBackupDesignatedRouter.Ifoneormoreofthese
routershavedeclaredthemselvesBackupDesignatedRouter
(i.e.,theyarecurrentlylistingthemselvesasBackup
DesignatedRouter,butnotasDesignatedRouter,intheir
HelloPackets)theonehavinghighestRouterPriorityis
declaredtobeBackupDesignatedRouter.Incaseofatie,
theonehavingthehighestRouterIDischosen.Ifno
routershavedeclaredthemselvesBackupDesignatedRouter,
choosetherouterhavinghighestRouterPriority,(again
excludingthoserouterswhohavedeclaredthemselves
DesignatedRouter),andagainusetheRouterIDtobreak
ties.
(3)CalculatethenewDesignatedRouterforthenetworkas
follows.Ifoneormoreoftheroutershavedeclared
themselvesDesignatedRouter(i.e.,theyarecurrently
listingthemselvesasDesignatedRouterintheirHello
Packets)theonehavinghighestRouterPriorityisdeclared
tobeDesignatedRouter.Incaseofatie,theonehaving
thehighestRouterIDischosen.Ifnoroutershave
declaredthemselvesDesignatedRouter,assigntheDesignated
RoutertobethesameasthenewlyelectedBackupDesignated
Router.
58/188
3/2/2015
(4)IfRouterXisnownewlytheDesignatedRouterornewlythe
BackupDesignatedRouter,orisnownolongertheDesignated
RouterornolongertheBackupDesignatedRouter,repeat
steps2and3,andthenproceedtostep5.Forexample,if
RouterXisnowtheDesignatedRouter,whenstep2is
repeatedXwillnolongerbeeligibleforBackupDesignated
Routerelection.Amongotherthings,thiswillensurethat
norouterwilldeclareitselfbothBackupDesignatedRouter
andDesignatedRouter.[5]
(5)Asaresultofthesecalculations,therouteritselfmaynow
beDesignatedRouterorBackupDesignatedRouter.See
Sections7.3and7.4fortheadditionaldutiesthiswould
entail.Therouter'sinterfacestateshouldbeset
accordingly.IftherouteritselfisnowDesignatedRouter,
thenewinterfacestateisDR.Iftherouteritselfisnow
BackupDesignatedRouter,thenewinterfacestateisBackup.
Otherwise,thenewinterfacestateisDROther.
(6)IftheattachednetworkisanNBMAnetwork,andtherouter
itselfhasjustbecomeeitherDesignatedRouterorBackup
DesignatedRouter,itmuststartsendingHelloPacketsto
thoseneighborsthatarenoteligibletobecomeDesignated
Router(seeSection9.5.1).Thisisdonebyinvokingthe
neighboreventStartforeachneighborhavingaRouter
Priorityof0.
(7)Iftheabovecalculationshavecausedtheidentityofeither
theDesignatedRouterorBackupDesignatedRoutertochange,
thesetofadjacenciesassociatedwiththisinterfacewill
needtobemodified.Someadjacenciesmayneedtobe
formed,andothersmayneedtobebroken.Toaccomplish
this,invoketheeventAdjOK?onallneighborswhosestate
isatleast2Way.Thiswillcausetheireligibilityfor
adjacencytobereexamined(seeSections10.3and10.4).
Thereasonbehindtheelectionalgorithm'scomplexityisthe
desireforanorderlytransitionfromBackupDesignatedRouter
toDesignatedRouter,whenthecurrentDesignatedRouterfails.
Thisorderlytransitionisensuredthroughtheintroductionof
hysteresis:nonewBackupDesignatedRoutercanbechosenuntil
theoldBackupacceptsitsnewDesignatedRouter
responsibilities.
Theaboveproceduremayelectthesameroutertobeboth
DesignatedRouterandBackupDesignatedRouter,althoughthat
routerwillneverbethecalculatingrouter(RouterX)itself.
TheelectedDesignatedRoutermaynotbetherouterhavingthe
highestRouterPriority,norwilltheBackupDesignatedRouter
necessarilyhavethesecondhighestRouterPriority.IfRouter
XisnotitselfeligibletobecomeDesignatedRouter,itis
possiblethatneitheraBackupDesignatedRouternora
DesignatedRouterwillbeselectedintheaboveprocedure.Note
alsothatifRouterXistheonlyattachedrouterthatis
eligibletobecomeDesignatedRouter,itwillselectitselfas
DesignatedRouterandtherewillbenoBackupDesignatedRouter
59/188
3/2/2015
forthenetwork.
9.5.SendingHellopackets
Hellopacketsaresentouteachfunctioningrouterinterface.
Theyareusedtodiscoverandmaintainneighbor
relationships.[6]OnbroadcastandNBMAnetworks,HelloPackets
arealsousedtoelecttheDesignatedRouterandBackup
DesignatedRouter.
TheformatofanHellopacketisdetailedinSectionA.3.2.The
HelloPacketcontainstherouter'sRouterPriority(usedin
choosingtheDesignatedRouter),andtheintervalbetweenHello
Packetssentouttheinterface(HelloInterval).TheHello
Packetalsoindicateshowoftenaneighbormustbeheardfromto
remainactive(RouterDeadInterval).BothHelloIntervaland
RouterDeadIntervalmustbethesameforallroutersattachedto
acommonnetwork.TheHellopacketalsocontainstheIPaddress
maskoftheattachednetwork(NetworkMask).Onunnumbered
pointtopointnetworksandonvirtuallinksthisfieldshould
besetto0.0.0.0.
TheHellopacket'sOptionsfielddescribestherouter'soptional
OSPFcapabilities.Oneoptionalcapabilityisdefinedinthis
specification(seeSections4.5andA.2).TheEbitofthe
Optionsfieldshouldbesetifandonlyiftheattachedareais
capableofprocessingASexternalLSAs(i.e.,itisnotastub
area).IftheEbitissetincorrectlytheneighboringrouters
willrefusetoaccepttheHelloPacket(seeSection10.5).
UnrecognizedbitsintheHelloPacket'sOptionsfieldshouldbe
settozero.
Inordertoensuretwowaycommunicationbetweenadjacent
routers,theHellopacketcontainsthelistofallrouterson
thenetworkfromwhichHelloPacketshavebeenseenrecently.
TheHellopacketalsocontainstherouter'scurrentchoicefor
DesignatedRouterandBackupDesignatedRouter.Avalueof
0.0.0.0inthesefieldsmeansthatonehasnotyetbeen
selected.
Onbroadcastnetworksandphysicalpointtopointnetworks,
HellopacketsaresenteveryHelloIntervalsecondstotheIP
multicastaddressAllSPFRouters.Onvirtuallinks,Hello
packetsaresentasunicasts(addresseddirectlytotheother
endofthevirtuallink)everyHelloIntervalseconds.OnPoint
toMultiPointnetworks,separateHellopacketsaresenttoeach
attachedneighboreveryHelloIntervalseconds.SendingofHello
packetsonNBMAnetworksiscoveredinthenextsection.
60/188
3/2/2015
9.5.1.SendingHellopacketsonNBMAnetworks
Staticconfigurationinformationmaybenecessaryinorder
fortheHelloProtocoltofunctiononnonbroadcastnetworks
(seeSectionsC.5andC.6).OnNBMAnetworks,every
attachedrouterwhichiseligibletobecomeDesignated
Routerbecomesawareofallofitsneighborsonthenetwork
(eitherthroughconfigurationorbysomeunspecified
mechanism).Eachneighborislabelledwiththeneighbor's
DesignatedRoutereligibility.
TheinterfacestatemustbeatleastWaitingforanyHello
PacketstobesentouttheNBMAinterface.HelloPackets
arethensentdirectly(asunicasts)tosomesubsetofa
router'sneighbors.SometimesanHelloPacketissent
periodicallyonatimer;atothertimesitissentasa
responsetoareceivedHelloPacket.Arouter'shello
sendingbehaviorvariesdependingonwhethertherouter
itselfiseligibletobecomeDesignatedRouter.
IftherouteriseligibletobecomeDesignatedRouter,it
mustperiodicallysendHelloPacketstoallneighborsthat
arealsoeligible.Inaddition,iftherouterisitselfthe
DesignatedRouterorBackupDesignatedRouter,itmustalso
sendperiodicHelloPacketstoallotherneighbors.This
meansthatanytwoeligibleroutersarealwaysexchanging
HelloPackets,whichisnecessaryforthecorrectoperation
oftheDesignatedRouterelectionalgorithm.Tominimize
thenumberofHelloPacketssent,thenumberofeligible
routersonanNBMAnetworkshouldbekeptsmall.
IftherouterisnoteligibletobecomeDesignatedRouter,
itmustperiodicallysendHelloPacketstoboththe
DesignatedRouterandtheBackupDesignatedRouter(ifthey
exist).ItmustalsosendanHelloPacketinreplytoan
HelloPacketreceivedfromanyeligibleneighbor(otherthan
thecurrentDesignatedRouterandBackupDesignatedRouter).
Thisisneededtoestablishaninitialbidirectional
relationshipwithanypotentialDesignatedRouter.
WhensendingHellopacketsperiodicallytoanyneighbor,the
intervalbetweenHelloPacketsisdeterminedbythe
neighbor'sstate.IftheneighborisinstateDown,Hello
PacketsaresenteveryPollIntervalseconds.Otherwise,
HelloPacketsaresenteveryHelloIntervalseconds.
10.TheNeighborDataStructure
AnOSPFrouterconverseswithitsneighboringrouters.Each
separateconversationisdescribedbya"neighbordatastructure".
EachconversationisboundtoaparticularOSPFrouterinterface,
61/188
3/2/2015
andisidentifiedeitherbytheneighboringrouter'sOSPFRouterID
orbyitsNeighborIPaddress(seebelow).ThusiftheOSPFrouter
andanotherrouterhavemultipleattachednetworksincommon,
multipleconversationsensue,eachdescribedbyauniqueneighbor
datastructure.Eachseparateconversationislooselyreferredto
inthetextasbeingaseparate"neighbor".
Theneighbordatastructurecontainsallinformationpertinentto
theformingorformedadjacencybetweenthetwoneighbors.
(However,rememberthatnotallneighborsbecomeadjacent.)An
adjacencycanbeviewedasahighlydevelopedconversationbetween
tworouters.
State
Thefunctionalleveloftheneighborconversation.Thisis
describedinmoredetailinSection10.1.
InactivityTimer
AsingleshottimerwhosefiringindicatesthatnoHelloPacket
hasbeenseenfromthisneighborrecently.Thelengthofthe
timerisRouterDeadIntervalseconds.
Master/Slave
Whenthetwoneighborsareexchangingdatabases,theyforma
master/slaverelationship.ThemastersendsthefirstDatabase
DescriptionPacket,andistheonlypartthatisallowedto
retransmit.Theslavecanonlyrespondtothemaster'sDatabase
DescriptionPackets.Themaster/slaverelationshipis
negotiatedinstateExStart.
DDSequenceNumber
TheDDSequencenumberoftheDatabaseDescriptionpacketthat
iscurrentlybeingsenttotheneighbor.
LastreceivedDatabaseDescriptionpacket
Theinitialize(I),more(M)andmaster(MS)bits,Optionsfield,
andDDsequencenumbercontainedinthelastDatabase
Descriptionpacketreceivedfromtheneighbor.Usedtodetermine
whetherthenextDatabaseDescriptionpacketreceivedfromthe
neighborisaduplicate.
NeighborID
TheOSPFRouterIDoftheneighboringrouter.TheNeighborID
islearnedwhenHellopacketsarereceivedfromtheneighbor,or
isconfiguredifthisisavirtualadjacency(seeSectionC.4).
NeighborPriority
TheRouterPriorityoftheneighboringrouter.Containedinthe
neighbor'sHellopackets,thisitemisusedwhenselectingthe
DesignatedRouterfortheattachednetwork.
NeighborIPaddress
TheIPaddressoftheneighboringrouter'sinterfacetothe
attachednetwork.UsedastheDestinationIPaddresswhen
protocolpacketsaresentasunicastsalongthisadjacency.
62/188
3/2/2015
AlsousedinrouterLSAsastheLinkIDfortheattachednetwork
iftheneighboringrouterisselectedtobeDesignatedRouter
(seeSection12.4.1).TheNeighborIPaddressislearnedwhen
Hellopacketsarereceivedfromtheneighbor.Forvirtual
links,theNeighborIPaddressislearnedduringtherouting
tablebuildprocess(seeSection15).
NeighborOptions
TheoptionalOSPFcapabilitiessupportedbytheneighbor.
LearnedduringtheDatabaseExchangeprocess(seeSection10.6).
Theneighbor'soptionalOSPFcapabilitiesarealsolistedinits
Hellopackets.ThisenablesreceivedHelloPacketstobe
rejected(i.e.,neighborrelationshipswillnotevenstartto
form)ifthereisamismatchincertaincrucialOSPF
capabilities(seeSection10.5).TheoptionalOSPFcapabilities
aredocumentedinSection4.5.
Neighbor'sDesignatedRouter
Theneighbor'sideaoftheDesignatedRouter.Ifthisisthe
neighboritself,thisisimportantinthelocalcalculationof
theDesignatedRouter.DefinedonlyonbroadcastandNBMA
networks.
Neighbor'sBackupDesignatedRouter
Theneighbor'sideaoftheBackupDesignatedRouter.Ifthisis
theneighboritself,thisisimportantinthelocalcalculation
oftheBackupDesignatedRouter.Definedonlyonbroadcastand
NBMAnetworks.
ThenextsetofvariablesarelistsofLSAs.Theselistsdescribe
subsetsofthearealinkstatedatabase.Thismemodefinesfive
distincttypesofLSAs,allofwhichmaybepresentinanarea
linkstatedatabase:routerLSAs,networkLSAs,andType3and4
summaryLSAs(allstoredintheareadatastructure),andAS
externalLSAs(storedintheglobaldatastructure).
Linkstateretransmissionlist
ThelistofLSAsthathavebeenfloodedbutnotacknowledgedon
thisadjacency.Thesewillberetransmittedatintervalsuntil
theyareacknowledged,oruntiltheadjacencyisdestroyed.
Databasesummarylist
ThecompletelistofLSAsthatmakeupthearealinkstate
database,atthemomenttheneighborgoesintoDatabaseExchange
state.ThislistissenttotheneighborinDatabase
Descriptionpackets.
Linkstaterequestlist
ThelistofLSAsthatneedtobereceivedfromthisneighborin
ordertosynchronizethetwoneighbors'linkstatedatabases.
ThislistiscreatedasDatabaseDescriptionpacketsare
received,andisthensenttotheneighborinLinkStateRequest
packets.ThelistisdepletedasappropriateLinkStateUpdate
packetsarereceived.
63/188
3/2/2015
10.1.Neighborstates
Thestateofaneighbor(really,thestateofaconversation
beingheldwithaneighboringrouter)isdocumentedinthe
followingsections.Thestatesarelistedinorderof
progressingfunctionality.Forexample,theinoperativestate
islistedfirst,followedbyalistofintermediatestates
beforethefinal,fullyfunctionalstateisachieved.The
specificationmakesuseofthisorderingbysometimesmaking
referencessuchas"thoseneighbors/adjacenciesinstategreater
thanX".Figures12and13showthegraphofneighborstate
changes.Thearcsofthegraphsarelabelledwiththeevent
causingthestatechange.Theneighboreventsaredocumentedin
Section10.2.
ThegraphinFigure12showsthestatechangeseffectedbythe
HelloProtocol.TheHelloProtocolisresponsibleforneighbor
acquisitionandmaintenance,andforensuringtwoway
communicationbetweenneighbors.
ThegraphinFigure13showstheformingofanadjacency.Not
everytwoneighboringroutersbecomeadjacent(seeSection
10.4).Theadjacencystartstoformwhentheneighborisin
stateExStart.Afterthetworoutersdiscovertheir
master/slavestatus,thestatetransitionstoExchange.Atthis
pointtheneighborstartstobeusedinthefloodingprocedure,
andthetwoneighboringroutersbeginsynchronizingtheir
databases.Whenthissynchronizationisfinished,theneighbor
isinstateFullandwesaythatthetworoutersarefully
adjacent.AtthispointtheadjacencyislistedinLSAs.
Foramoredetaileddescriptionofneighborstatechanges,
togetherwiththeadditionalactionsinvolvedineachchange,
seeSection10.3.
Down
Thisistheinitialstateofaneighborconversation.It
indicatesthattherehasbeennorecentinformationreceived
fromtheneighbor.OnNBMAnetworks,Hellopacketsmay
stillbesentto"Down"neighbors,althoughatareduced
frequency(seeSection9.5.1).
++
|Down|
++
|\
64/188
3/2/2015
|\Start
|\++
Hello|+>|Attempt|
Received|++
||
++<+|HelloReceived
|Init|<+
++<+
||
|2Way|1Way
|Received|Received
||
++|++
|ExStart|<+>|2Way|
++++
Figure12:Neighborstatechanges(HelloProtocol)
EventKillNbralwaysforcesDownState,
EventInactivityTimeralwaysforcesDownState,
EventLLDownalwaysforcesDownState
++
|ExStart|
++
|
NegotiationDone|
+>++
|Exchange|
+++
|
Exchange|
Done|
++|++
|Full|<+>|Loading|
++<+++
|LoadingDone|
++
Figure13:Neighborstatechanges(DatabaseExchange)
65/188
3/2/2015
EventSeqNumberMismatchforcesExStartstate,
EventBadLSReqforcesExStartstate,
Event1WayforcesInitstate,
EventKillNbralwaysforcesDownState,
EventInactivityTimeralwaysforcesDownState,
EventLLDownalwaysforcesDownState,
EventAdjOK?leadstoadjacencyforming/breaking
Attempt
ThisstateisonlyvalidforneighborsattachedtoNBMA
networks.Itindicatesthatnorecentinformationhasbeen
receivedfromtheneighbor,butthatamoreconcertedeffort
shouldbemadetocontacttheneighbor.Thisisdoneby
sendingtheneighborHellopacketsatintervalsof
HelloInterval(seeSection9.5.1).
Init
Inthisstate,anHellopackethasrecentlybeenseenfrom
theneighbor.However,bidirectionalcommunicationhasnot
yetbeenestablishedwiththeneighbor(i.e.,therouter
itselfdidnotappearintheneighbor'sHellopacket).All
neighborsinthisstate(orhigher)arelistedintheHello
packetssentfromtheassociatedinterface.
2Way
Inthisstate,communicationbetweenthetworoutersis
bidirectional.Thishasbeenassuredbytheoperationof
theHelloProtocol.Thisisthemostadvancedstateshort
ofbeginningadjacencyestablishment.The(Backup)
DesignatedRouterisselectedfromthesetofneighborsin
state2Wayorgreater.
ExStart
Thisisthefirststepincreatinganadjacencybetweenthe
twoneighboringrouters.Thegoalofthisstepistodecide
whichrouteristhemaster,andtodecideupontheinitial
DDsequencenumber.Neighborconversationsinthisstateor
greaterarecalledadjacencies.
Exchange
Inthisstatetherouterisdescribingitsentirelinkstate
databasebysendingDatabaseDescriptionpacketstothe
neighbor.EachDatabaseDescriptionPackethasaDD
sequencenumber,andisexplicitlyacknowledged.Onlyone
DatabaseDescriptionPacketisallowedoutstandingatany
onetime.Inthisstate,LinkStateRequestPacketsmay
alsobesentaskingfortheneighbor'smorerecentLSAs.
AlladjacenciesinExchangestateorgreaterareusedbythe
floodingprocedure.Infact,theseadjacenciesarefully
capableoftransmittingandreceivingalltypesofOSPF
routingprotocolpackets.
Loading
Inthisstate,LinkStateRequestpacketsaresenttothe
neighboraskingforthemorerecentLSAsthathavebeen
discovered(butnotyetreceived)intheExchangestate.
66/188
3/2/2015
Full
Inthisstate,theneighboringroutersarefullyadjacent.
TheseadjacencieswillnowappearinrouterLSAsand
networkLSAs.
10.2.Eventscausingneighborstatechanges
Statechangescanbeeffectedbyanumberofevents.These
eventsareshowninthelabelsofthearcsinFigures12and13.
Thelabeldefinitionsareasfollows:
HelloReceived
AnHellopackethasbeenreceivedfromtheneighbor.
Start
ThisisanindicationthatHelloPacketsshouldnowbesent
totheneighboratintervalsofHelloIntervalseconds.This
eventisgeneratedonlyforneighborsassociatedwithNBMA
networks.
2WayReceived
Bidirectionalcommunicationhasbeenrealizedbetweenthe
twoneighboringrouters.Thisisindicatedbytherouter
seeingitselfintheneighbor'sHellopacket.
NegotiationDone
TheMaster/Slaverelationshiphasbeennegotiated,andDD
sequencenumbershavebeenexchanged.Thissignalsthe
startofthesending/receivingofDatabaseDescription
packets.Formoreinformationonthegenerationofthis
event,consultSection10.8.
ExchangeDone
Bothroutershavesuccessfullytransmittedafullsequence
ofDatabaseDescriptionpackets.Eachrouternowknowswhat
partsofitslinkstatedatabaseareoutofdate.Formore
informationonthegenerationofthisevent,consultSection
10.8.
BadLSReq
ALinkStateRequesthasbeenreceivedforanLSAnot
containedinthedatabase.Thisindicatesanerrorinthe
DatabaseExchangeprocess.
LoadingDone
LinkStateUpdateshavebeenreceivedforalloutofdate
67/188
3/2/2015
portionsofthedatabase.ThisisindicatedbytheLink
staterequestlistbecomingemptyaftertheDatabase
Exchangeprocesshascompleted.
AdjOK?
Adecisionmustbemadeastowhetheranadjacencyshouldbe
established/maintainedwiththeneighbor.Thiseventwill
startsomeadjacenciesforming,anddestroyothers.
Thefollowingeventscausewelldevelopedneighborstorevertto
lesserstates.Unliketheaboveevents,theseeventsmayoccur
whentheneighborconversationisinanyofanumberofstates.
SeqNumberMismatch
ADatabaseDescriptionpackethasbeenreceivedthateither
a)hasanunexpectedDDsequencenumber,b)unexpectedlyhas
theInitbitsetorc)hasanOptionsfielddifferingfrom
thelastOptionsfieldreceivedinaDatabaseDescription
packet.Anyoftheseconditionsindicatethatsomeerror
hasoccurredduringadjacencyestablishment.
1Way
AnHellopackethasbeenreceivedfromtheneighbor,in
whichtherouterisnotmentioned.Thisindicatesthat
communicationwiththeneighborisnotbidirectional.
KillNbr
Thisisanindicationthatallcommunicationwiththe
neighborisnowimpossible,forcingtheneighborto
reverttoDownstate.
InactivityTimer
TheinactivityTimerhasfired.ThismeansthatnoHello
packetshavebeenseenrecentlyfromtheneighbor.The
neighborrevertstoDownstate.
LLDown
Thisisanindicationfromthelowerlevelprotocolsthat
theneighborisnowunreachable.Forexample,onanX.25
networkthiscouldbeindicatedbyanX.25clearindication
withappropriatecauseanddiagnosticfields.Thisevent
forcestheneighborintoDownstate.
10.3.TheNeighborstatemachine
Adetaileddescriptionoftheneighborstatechangesfollows.
Eachstatechangeisinvokedbyanevent(Section10.2).This
eventmayproducedifferenteffects,dependingonthecurrent
stateoftheneighbor.Forthisreason,thestatemachinebelow
isorganizedbycurrentneighborstateandreceivedevent.Each
entryinthestatemachinedescribestheresultingnewneighbor
stateandtherequiredsetofadditionalactions.
Whenaneighbor'sstatechanges,itmaybenecessarytorerun
68/188
3/2/2015
theDesignatedRouterelectionalgorithm.Thisisdeterminedby
whethertheinterfaceNeighborChangeeventisgenerated(see
Section9.2).Also,iftheInterfaceisinDRstate(therouter
isitselfDesignatedRouter),changesinneighborstatemay
causeanewnetworkLSAtobeoriginated(seeSection12.4).
Whentheneighborstatemachineneedstoinvoketheinterface
statemachine,itshouldbedoneasascheduledtask(see
Section4.4).Thissimplifiesthings,byensuringthatneither
statemachinewillbeexecutedrecursively.
State(s):Down
Event:Start
Newstate:Attempt
Action:SendanHelloPackettotheneighbor(thisneighbor
isalwaysassociatedwithanNBMAnetwork)andstart
theInactivityTimerfortheneighbor.Thetimer's
laterfiringwouldindicatethatcommunicationwith
theneighborwasnotattained.
State(s):Attempt
Event:HelloReceived
Newstate:Init
Action:RestarttheInactivityTimerfortheneighbor,since
theneighborhasnowbeenheardfrom.
State(s):Down
Event:HelloReceived
Newstate:Init
Action:StarttheInactivityTimerfortheneighbor.The
timer'slaterfiringwouldindicatethatthe
neighborisdead.
State(s):Initorgreater
Event:HelloReceived
Newstate:Nostatechange.
Action:RestarttheInactivityTimerfortheneighbor,since
theneighborhasagainbeenheardfrom.
State(s):Init
69/188
3/2/2015
Event:2WayReceived
Action:Determinewhetheranadjacencyshouldbeestablished
withtheneighbor(seeSection10.4).Ifnot,the
newneighborstateis2Way.
Otherwise(anadjacencyshouldbeestablished)the
neighborstatetransitionstoExStart.Upon
enteringthisstate,therouterincrementstheDD
sequencenumberintheneighbordatastructure.If
thisisthefirsttimethatanadjacencyhasbeen
attempted,theDDsequencenumbershouldbeassigned
someuniquevalue(likethetimeofdayclock).It
thendeclaresitselfmaster(setsthemaster/slave
bittomaster),andstartssendingDatabase
DescriptionPackets,withtheinitialize(I),more
(M)andmaster(MS)bitsset.ThisDatabase
DescriptionPacketshouldbeotherwiseempty.This
DatabaseDescriptionPacketshouldberetransmitted
atintervalsofRxmtIntervaluntilthenextstateis
entered(seeSection10.8).
State(s):ExStart
Event:NegotiationDone
Newstate:Exchange
Action:Theroutermustlistthecontentsofitsentirearea
linkstatedatabaseintheneighborDatabasesummary
list.Thearealinkstatedatabaseconsistsofthe
routerLSAs,networkLSAsandsummaryLSAscontained
intheareastructure,alongwiththeASexternal
LSAscontainedintheglobalstructure.AS
externalLSAsareomittedfromavirtualneighbor's
Databasesummarylist.ASexternalLSAsareomitted
fromtheDatabasesummarylistiftheareahasbeen
configuredasastub(seeSection3.6).LSAswhose
ageisequaltoMaxAgeareinsteadaddedtothe
neighbor'sLinkstateretransmissionlist.A
summaryoftheDatabasesummarylistwillbesentto
theneighborinDatabaseDescriptionpackets.Each
DatabaseDescriptionPackethasaDDsequence
number,andisexplicitlyacknowledged.Onlyone
DatabaseDescriptionPacketisallowedoutstanding
atanyonetime.Formoredetailonthesendingand
receivingofDatabaseDescriptionpackets,see
Sections10.8and10.6.
70/188
3/2/2015
State(s):Exchange
Event:ExchangeDone
Action:IftheneighborLinkstaterequestlistisempty,
thenewneighborstateisFull.Nootheractionis
required.Thisisanadjacency'sfinalstate.
Otherwise,thenewneighborstateisLoading.Start
(orcontinue)sendingLinkStateRequestpacketsto
theneighbor(seeSection10.9).Thesearerequests
fortheneighbor'smorerecentLSAs(whichwere
discoveredbutnotyetreceivedintheExchange
state).TheseLSAsarelistedintheLinkstate
requestlistassociatedwiththeneighbor.
State(s):Loading
Event:LoadingDone
Newstate:Full
Action:Noactionrequired.Thisisanadjacency'sfinal
state.
State(s):2Way
Event:AdjOK?
Action:Determinewhetheranadjacencyshouldbeformedwith
theneighboringrouter(seeSection10.4).Ifnot,
theneighborstateremainsat2Way.Otherwise,
transitiontheneighborstatetoExStartandperform
theactionsassociatedwiththeabovestatemachine
entryforstateInitandevent2WayReceived.
State(s):ExStartorgreater
Event:AdjOK?
Action:Determinewhethertheneighboringroutershould
stillbeadjacent.Ifyes,thereisnostatechange
andnofurtheractionisnecessary.
71/188
3/2/2015
Otherwise,the(possiblypartiallyformed)adjacency
mustbedestroyed.Theneighborstatetransitions
to2Way.TheLinkstateretransmissionlist,
DatabasesummarylistandLinkstaterequestlist
areclearedofLSAs.
State(s):Exchangeorgreater
Event:SeqNumberMismatch
Newstate:ExStart
Action:The(possiblypartiallyformed)adjacencyistorn
down,andthenanattemptismadeat
reestablishment.Theneighborstatefirst
transitionstoExStart.TheLinkstate
retransmissionlist,DatabasesummarylistandLink
staterequestlistareclearedofLSAs.Thenthe
routerincrementstheDDsequencenumberinthe
neighbordatastructure,declaresitselfmaster
(setsthemaster/slavebittomaster),andstarts
sendingDatabaseDescriptionPackets,withthe
initialize(I),more(M)andmaster(MS)bitsset.
ThisDatabaseDescriptionPacketshouldbeotherwise
empty(seeSection10.8).
State(s):Exchangeorgreater
Event:BadLSReq
Newstate:ExStart
Action:TheactionforeventBadLSReqisexactlythesameas
fortheneighboreventSeqNumberMismatch.The
(possiblypartiallyformed)adjacencyistorndown,
andthenanattemptismadeatreestablishment.For
moreinformation,seetheneighborstatemachine
entrythatisinvokedwheneventSeqNumberMismatch
isgeneratedinstateExchangeorgreater.
State(s):Anystate
Event:KillNbr
Newstate:Down
Action:TheLinkstateretransmissionlist,Databasesummary
listandLinkstaterequestlistareclearedof
LSAs.Also,theInactivityTimerisdisabled.
State(s):Anystate
Event:LLDown
72/188
3/2/2015
Newstate:Down
LSAs.Also,theInactivityTimerisdisabled.
State(s):Anystate
Event:InactivityTimer
Newstate:Down
LSAs.
State(s):2Wayorgreater
Event:1WayReceived
Newstate:Init
LSAs.
State(s):2Wayorgreater
Event:2WayReceived
Action:Noactionrequired.
State(s):Init
Event:1WayReceived
Action:Noactionrequired.
10.4.Whethertobecomeadjacent
Adjacenciesareestablishedwithsomesubsetoftherouter's
neighbors.Routersconnectedbypointtopointnetworks,
PointtoMultiPointnetworksandvirtuallinksalwaysbecome
adjacent.OnbroadcastandNBMAnetworks,allroutersbecome
adjacenttoboththeDesignatedRouterandtheBackupDesignated
Router.
Theadjacencyformingdecisionoccursintwoplacesinthe
neighborstatemachine.First,whenbidirectionalcommunication
73/188
3/2/2015
isinitiallyestablishedwiththeneighbor,andsecondly,when
theidentityoftheattachednetwork's(Backup)Designated
Routerchanges.Ifthedecisionismadetonotattemptan
adjacency,thestateoftheneighborcommunicationstopsat2
Way.
Anadjacencyshouldbeestablishedwithabidirectionalneighbor
whenatleastoneofthefollowingconditionsholds:
oTheunderlyingnetworktypeispointtopoint
oTheunderlyingnetworktypeisPointtoMultiPoint
oTheunderlyingnetworktypeisvirtuallink
oTherouteritselfistheDesignatedRouter
oTherouteritselfistheBackupDesignatedRouter
oTheneighboringrouteristheDesignatedRouter
oTheneighboringrouteristheBackupDesignatedRouter
10.5.ReceivingHelloPackets
Thissectionexplainsthedetailedprocessingofareceived
HelloPacket.(SeeSectionA.3.2fortheformatofHello
packets.)ThegenericinputprocessingofOSPFpacketswill
havecheckedthevalidityoftheIPheaderandtheOSPFpacket
header.Next,thevaluesoftheNetworkMask,HelloInterval,
andRouterDeadIntervalfieldsinthereceivedHellopacketmust
becheckedagainstthevaluesconfiguredforthereceiving
interface.Anymismatchcausesprocessingtostopandthe
packettobedropped.Inotherwords,theabovefieldsare
reallydescribingtheattachednetwork'sconfiguration.However,
thereisoneexceptiontotheaboverule:onpointtopoint
networksandonvirtuallinks,theNetworkMaskinthereceived
HelloPacketshouldbeignored.
ThereceivinginterfaceattachestoasingleOSPFarea(this
couldbethebackbone).ThesettingoftheEbitfoundinthe
HelloPacket'sOptionsfieldmustmatchthisarea's
ExternalRoutingCapability.IfASexternalLSAsarenotflooded
into/throughoutthearea(i.e,theareaisa"stub")theEbit
mustbeclearinreceivedHelloPackets,otherwisetheEbit
mustbeset.Amismatchcausesprocessingtostopandthe
packettobedropped.Thesettingoftherestofthebitsin
74/188
3/2/2015
theHelloPacket'sOptionsfieldshouldbeignored.
Atthispoint,anattemptismadetomatchthesourceofthe
HelloPackettooneofthereceivinginterface'sneighbors.If
thereceivinginterfaceconnectstoabroadcast,Pointto
MultiPointorNBMAnetworkthesourceisidentifiedbytheIP
sourceaddressfoundintheHello'sIPheader.Ifthereceiving
interfaceconnectstoapointtopointlinkoravirtuallink,
thesourceisidentifiedbytheRouterIDfoundintheHello's
OSPFpacketheader.Theinterface'scurrentlistofneighbors
iscontainedintheinterface'sdatastructure.Ifamatching
neighborstructurecannotbefound,(i.e.,thisisthefirst
timetheneighborhasbeendetected),oneiscreated.The
initialstateofanewlycreatedneighborissettoDown.
WhenreceivinganHelloPacketfromaneighboronabroadcast,
PointtoMultiPointorNBMAnetwork,settheneighbor
structure'sNeighborIDequaltotheRouterIDfoundinthe
packet'sOSPFheader.Forthesenetworktypes,theneighbor
structure'sRouterPriorityfield,Neighbor'sDesignatedRouter
field,andNeighbor'sBackupDesignatedRouterfieldarealso
setequaltothecorrespondingfieldsfoundinthereceived
HelloPacket;changesinthesefieldsshouldbenotedfor
possibleuseinthestepsbelow.WhenreceivinganHelloona
pointtopointnetwork(butnotonavirtuallink)setthe
neighborstructure'sNeighborIPaddresstothepacket'sIP
sourceaddress.
NowtherestoftheHelloPacketisexamined,generatingevents
tobegiventotheneighborandinterfacestatemachines.These
statemachinesarespecifiedeithertobeexecutedorscheduled
(seeSection4.4).Forexample,byspecifyingbelowthatthe
neighborstatemachinebeexecutedinline,severalneighbor
statetransitionsmaybeeffectedbyasinglereceivedHello:
oEachHelloPacketcausestheneighborstatemachinetobe
executedwiththeeventHelloReceived.
oThenthelistofneighborscontainedintheHelloPacketis
examined.Iftherouteritselfappearsinthislist,the
neighborstatemachineshouldbeexecutedwiththeevent2
WayReceived.Otherwise,theneighborstatemachineshould
beexecutedwiththeevent1WayReceived,andtheprocessing
ofthepacketstops.
oNext,ifachangeintheneighbor'sRouterPriorityfield
wasnoted,thereceivinginterface'sstatemachineis
scheduledwiththeeventNeighborChange.
oIftheneighborisbothdeclaringitselftobeDesignated
Router(HelloPacket'sDesignatedRouterfield=NeighborIP
address)andtheBackupDesignatedRouterfieldinthe
packetisequalto0.0.0.0andthereceivinginterfaceisin
stateWaiting,thereceivinginterface'sstatemachineis
scheduledwiththeeventBackupSeen.Otherwise,ifthe
75/188
3/2/2015
neighborisdeclaringitselftobeDesignatedRouterandit
hadnotpreviously,ortheneighborisnotdeclaringitself
DesignatedRouterwhereithadpreviously,thereceiving
interface'sstatemachineisscheduledwiththeevent
NeighborChange.
oIftheneighborisdeclaringitselftobeBackupDesignated
Router(HelloPacket'sBackupDesignatedRouterfield=
NeighborIPaddress)andthereceivinginterfaceisinstate
Waiting,thereceivinginterface'sstatemachineis
scheduledwiththeeventBackupSeen.Otherwise,ifthe
neighborisdeclaringitselftobeBackupDesignatedRouter
andithadnotpreviously,ortheneighborisnotdeclaring
itselfBackupDesignatedRouterwhereithadpreviously,the
receivinginterface'sstatemachineisscheduledwiththe
eventNeighborChange.
OnNBMAnetworks,receiptofanHelloPacketmayalsocausean
HelloPackettobesentbacktotheneighborinresponse.See
Section9.5.1formoredetails.
10.6.ReceivingDatabaseDescriptionPackets
Thissectionexplainsthedetailedprocessingofareceived
DatabaseDescriptionPacket.TheincomingDatabaseDescription
Packethasalreadybeenassociatedwithaneighborandreceiving
interfacebythegenericinputpacketprocessing(Section8.2).
WhethertheDatabaseDescriptionpacketshouldbeaccepted,and
ifso,howitshouldbefurtherprocesseddependsuponthe
neighborstate.
IfaDatabaseDescriptionpacketisaccepted,thefollowing
packetfieldsshouldbesavedinthecorrespondingneighbordata
structureunder"lastreceivedDatabaseDescriptionpacket":
thepacket'sinitialize(I),more(M)andmaster(MS)bits,
Optionsfield,andDDsequencenumber.Ifthesefieldsareset
identicallyintwoconsecutiveDatabaseDescriptionpackets
receivedfromtheneighbor,thesecondDatabaseDescription
packetisconsideredtobea"duplicate"intheprocessing
describedbelow.
IftheInterfaceMTUfieldintheDatabaseDescriptionpacket
indicatesanIPdatagramsizethatislargerthantheroutercan
acceptonthereceivinginterfacewithoutfragmentation,the
DatabaseDescriptionpacketisrejected.Otherwise,ifthe
neighborstateis:
Down
Thepacketshouldberejected.
Attempt
Thepacketshouldberejected.
Init
Theneighborstatemachineshouldbeexecutedwiththeevent
2WayReceived.Thiscausesanimmediatestatechangeto
76/188
3/2/2015
eitherstate2WayorstateExStart.Ifthenewstateis
ExStart,theprocessingofthecurrentpacketshouldthen
continueinthisnewstatebyfallingthroughtocase
ExStartbelow.
2Way
Thepacketshouldbeignored.DatabaseDescriptionPackets
areusedonlyforthepurposeofbringingupadjacencies.[7]
ExStart
Ifthereceivedpacketmatchesoneofthefollowingcases,
thentheneighborstatemachineshouldbeexecutedwiththe
eventNegotiationDone(causingthestatetotransitionto
Exchange),thepacket'sOptionsfieldshouldberecordedin
theneighborstructure'sNeighborOptionsfieldandthe
packetshouldbeacceptedasnextinsequenceandprocessed
further(seebelow).Otherwise,thepacketshouldbe
ignored.
oTheinitialize(I),more(M)andmaster(MS)bitsareset,
thecontentsofthepacketareempty,andtheneighbor's
RouterIDislargerthantherouter'sown.Inthiscase
therouterisnowSlave.Setthemaster/slavebitto
slave,andsettheneighbordatastructure'sDDsequence
numbertothatspecifiedbythemaster.
oTheinitialize(I)andmaster(MS)bitsareoff,the
packet'sDDsequencenumberequalstheneighbordata
structure'sDDsequencenumber(indicating
acknowledgment)andtheneighbor'sRouterIDissmaller
thantherouter'sown.Inthiscasetherouteris
Master.
Exchange
DuplicateDatabaseDescriptionpacketsarediscardedbythe
master,andcausetheslavetoretransmitthelastDatabase
Descriptionpacketthatithadsent.Otherwise(thepacket
isnotaduplicate):
oIfthestateoftheMSbitisinconsistentwiththe
master/slavestateoftheconnection,generatethe
neighboreventSeqNumberMismatchandstopprocessingthe
packet.
oIftheinitialize(I)bitisset,generatetheneighbor
eventSeqNumberMismatchandstopprocessingthepacket.
77/188
3/2/2015
oIfthepacket'sOptionsfieldindicatesadifferentset
ofoptionalOSPFcapabilitiesthanwerepreviously
receivedfromtheneighbor(recordedintheNeighbor
Optionsfieldoftheneighborstructure),generatethe
neighboreventSeqNumberMismatchandstopprocessingthe
packet.
oDatabaseDescriptionpacketsmustbeprocessedin
sequence,asindicatedbythepackets'DDsequence
numbers.Iftherouterismaster,thenextpacket
receivedshouldhaveDDsequencenumberequaltotheDD
sequencenumberintheneighbordatastructure.Ifthe
routerisslave,thenextpacketreceivedshouldhaveDD
sequencenumberequaltoonemorethantheDDsequence
numberstoredintheneighbordatastructure.Ineither
case,ifthepacketisthenextinsequenceitshouldbe
acceptedanditscontentsprocessedasspecifiedbelow.
oElse,generatetheneighboreventSeqNumberMismatchand
stopprocessingthepacket.
LoadingorFull
Inthisstate,therouterhassentandreceivedanentire
sequenceofDatabaseDescriptionPackets.Theonlypackets
receivedshouldbeduplicates(seeabove).Inparticular,
thepacket'sOptionsfieldshouldmatchthesetofoptional
OSPFcapabilitiespreviouslyindicatedbytheneighbor
(storedintheneighborstructure'sNeighborOptionsfield).
Anyotherpacketsreceived,includingthereceptionofa
packetwiththeInitialize(I)bitset,shouldgeneratethe
neighboreventSeqNumberMismatch.[8]Duplicatesshouldbe
discardedbythemaster.Theslavemustrespondto
duplicatesbyrepeatingthelastDatabaseDescriptionpacket
thatithadsent.
WhentherouteracceptsareceivedDatabaseDescriptionPacket
asthenextinsequencethepacketcontentsareprocessedas
follows.ForeachLSAlisted,theLSA'sLStypeischeckedfor
validity.IftheLStypeisunknown(e.g.,notoneoftheLS
types15definedbythisspecification),orifthisisanAS
externalLSA(LStype=5)andtheneighborisassociatedwitha
stubarea,generatetheneighboreventSeqNumberMismatchand
stopprocessingthepacket.Otherwise,therouterlooksupthe
LSAinitsdatabasetoseewhetheritalsohasaninstanceof
theLSA.Ifitdoesnot,orifthedatabasecopyislessrecent
(seeSection13.1),theLSAisputontheLinkstaterequest
listsothatitcanberequested(immediatelyoratsomelater
time)inLinkStateRequestPackets.
WhentherouteracceptsareceivedDatabaseDescriptionPacket
asthenextinsequence,italsoperformsthefollowingactions,
dependingonwhetheritismasterorslave:
Master
IncrementstheDDsequencenumberintheneighbordata
78/188
3/2/2015
structure.Iftherouterhasalreadysentitsentire
sequenceofDatabaseDescriptionPackets,andthejust
acceptedpackethasthemorebit(M)setto0,theneighbor
eventExchangeDoneisgenerated.Otherwise,itshouldsend
anewDatabaseDescriptiontotheslave.
Slave
SetstheDDsequencenumberintheneighbordatastructure
totheDDsequencenumberappearinginthereceivedpacket.
TheslavemustsendaDatabaseDescriptionPacketinreply.
Ifthereceivedpackethasthemorebit(M)setto0,and
thepackettobesentbytheslavewillalsohavetheMbit
setto0,theneighboreventExchangeDoneisgenerated.
Notethattheslavealwaysgeneratesthiseventbeforethe
master.
10.7.ReceivingLinkStateRequestPackets
ThissectionexplainsthedetailedprocessingofreceivedLink
StateRequestpackets.ReceivedLinkStateRequestPackets
specifyalistofLSAsthattheneighborwishestoreceive.
LinkStateRequestPacketsshouldbeacceptedwhentheneighbor
isinstatesExchange,Loading,orFull.Inallotherstates
LinkStateRequestPacketsshouldbeignored.
EachLSAspecifiedintheLinkStateRequestpacketshouldbe
locatedintherouter'sdatabase,andcopiedintoLinkState
Updatepacketsfortransmissiontotheneighbor.TheseLSAs
shouldNOTbeplacedontheLinkstateretransmissionlistfor
theneighbor.IfanLSAcannotbefoundinthedatabase,
somethinghasgonewrongwiththeDatabaseExchangeprocess,and
neighboreventBadLSReqshouldbegenerated.
10.8.SendingDatabaseDescriptionPackets
ThissectiondescribeshowDatabaseDescriptionPacketsaresent
toaneighbor.TheDatabaseDescriptionpacket'sInterfaceMTU
fieldissettothesizeofthelargestIPdatagramthatcanbe
sentoutthesendinginterface,withoutfragmentation.Common
MTUsinuseintheInternetcanbefoundinTable71of
[Ref22].InterfaceMTUshouldbesetto0inDatabase
Descriptionpacketssentovervirtuallinks.
Therouter'soptionalOSPFcapabilities(seeSection4.5)are
transmittedtotheneighborintheOptionsfieldoftheDatabase
Descriptionpacket.Theroutershouldmaintainthesamesetof
optionalcapabilitiesthroughouttheDatabaseExchangeand
floodingprocedures.Ifforsomereasontherouter'soptional
capabilitieschange,theDatabaseExchangeprocedureshouldbe
restartedbyrevertingtoneighborstateExStart.Oneoptional
capabilityisdefinedinthisspecification(seeSections4.5
andA.2).TheEbitshouldbesetifandonlyiftheattached
networkbelongstoanonstubarea.Unrecognizedbitsinthe
Optionsfieldshouldbesettozero.
79/188
3/2/2015
ThesendingofDatabaseDescriptionpacketsdependsonthe
neighbor'sstate.InstateExStarttheroutersendsempty
DatabaseDescriptionpackets,withtheinitialize(I),more(M)
andmaster(MS)bitsset.Thesepacketsareretransmittedevery
RxmtIntervalseconds.
InstateExchangetheDatabaseDescriptionPacketsactually
containsummariesofthelinkstateinformationcontainedinthe
router'sdatabase.EachLSAinthearea'slinkstatedatabase
(atthetimetheneighbortransitionsintoExchangestate)is
listedintheneighborDatabasesummarylist.EachnewDatabase
DescriptionPacketcopiesitsDDsequencenumberfromthe
neighbordatastructureandthendescribesthecurrenttopof
theDatabasesummarylist.ItemsareremovedfromtheDatabase
summarylistwhenthepreviouspacketisacknowledged.
InstateExchange,thedeterminationofwhentosendaDatabase
Descriptionpacketdependsonwhethertherouterismasteror
slave:
Master
DatabaseDescriptionpacketsaresentwheneithera)the
slaveacknowledgesthepreviousDatabaseDescriptionpacket
byechoingtheDDsequencenumberorb)RxmtIntervalseconds
elapsewithoutanacknowledgment,inwhichcasetheprevious
DatabaseDescriptionpacketisretransmitted.
Slave
DatabaseDescriptionpacketsaresentonlyinresponseto
DatabaseDescriptionpacketsreceivedfromthemaster.If
theDatabaseDescriptionpacketreceivedfromthemasteris
new,anewDatabaseDescriptionpacketissent,otherwise
thepreviousDatabaseDescriptionpacketisresent.
InstatesLoadingandFulltheslavemustresenditslast
DatabaseDescriptionpacketinresponsetoduplicateDatabase
Descriptionpacketsreceivedfromthemaster.Forthisreason
theslavemustwaitRouterDeadIntervalsecondsbeforefreeing
thelastDatabaseDescriptionpacket.ReceptionofaDatabase
Descriptionpacketfromthemasterafterthisintervalwill
generateaSeqNumberMismatchneighborevent.
10.9.SendingLinkStateRequestPackets
InneighborstatesExchangeorLoading,theLinkstaterequest
listcontainsalistofthoseLSAsthatneedtobeobtainedfrom
theneighbor.TorequesttheseLSAs,aroutersendsthe
neighborthebeginningoftheLinkstaterequestlist,packaged
inaLinkStateRequestpacket.
80/188
3/2/2015
Whentheneighborrespondstotheserequestswiththeproper
LinkStateUpdatepacket(s),theLinkstaterequestlistis
truncatedandanewLinkStateRequestpacketissent.This
processcontinuesuntiltheLinkstaterequestlistbecomes
empty.LSAsontheLinkstaterequestlistthathavebeen
requested,butnotyetreceived,arepackagedintoLinkState
RequestpacketsforretransmissionatintervalsofRxmtInterval.
ThereshouldbeatmostoneLinkStateRequestpacket
outstandingatanyonetime.
WhentheLinkstaterequestlistbecomesempty,andtheneighbor
stateisLoading(i.e.,acompletesequenceofDatabase
Descriptionpacketshasbeensenttoandreceivedfromthe
neighbor),theLoadingDoneneighboreventisgenerated.
10.10.AnExample
Figure14showsanexampleofanadjacencyforming.RoutersRT1
andRT2arebothconnectedtoabroadcastnetwork.Itis
assumedthatRT2istheDesignatedRouterforthenetwork,and
thatRT2hasahigherRouterIDthanRouterRT1.
Theneighborstatechangesrealizedbyeachrouterarelistedon
thesidesofthefigure.
AtthebeginningofFigure14,RouterRT1'sinterfacetothe
networkbecomesoperational.ItbeginssendingHelloPackets,
althoughitdoesn'tknowtheidentityoftheDesignatedRouter
orofanyotherneighboringrouters.RouterRT2hearsthis
hello(movingtheneighbortoInitstate),andinitsnextHello
PacketindicatesthatitisitselftheDesignatedRouterand
thatithasheardHelloPacketsfromRT1.Thisinturncauses
RT1togotostateExStart,asitstartstobringupthe
adjacency.
RT1beginsbyassertingitselfasthemaster.Whenitseesthat
RT2isindeedthemaster(becauseofRT2'shigherRouterID),
RT1transitionstoslavestateandadoptsitsneighbor'sDD
sequencenumber.DatabaseDescriptionpacketsarethen
exchanged,withpollscomingfromthemaster(RT2)andresponses
fromtheslave(RT1).ThissequenceofDatabaseDescription
++++
|RT1||RT2|
++++
DownDown
81/188
3/2/2015
Hello(DR=0,seen=0)
>
Hello(DR=RT2,seen=RT1,...)Init
<
ExStartDD(Seq=x,I,M,Master)
>
DD(Seq=y,I,M,Master)ExStart
<
ExchangeDD(Seq=y,M,Slave)
>
DD(Seq=y+1,M,Master)Exchange
<
DD(Seq=y+1,M,Slave)
>
...
...
...
DD(Seq=y+n,Master)
<
DD(Seq=y+n,Slave)
Loading>
LSRequestFull
>
LSUpdate
<
LSRequest
>
LSUpdate
<
Full
Figure14:Anadjacencybringupexample
Packetsendswhenboththepollandassociatedresponsehasthe
Mbitoff.
Inthisexample,itisassumedthatRT2hasacompletelyupto
datedatabase.Inthatcase,RT2goesimmediatelyintoFull
state.RT1willgointoFullstateafterupdatingthenecessary
partsofitsdatabase.ThisisdonebysendingLinkState
RequestPackets,andreceivingLinkStateUpdatePacketsin
response.Notethat,whileRT1haswaiteduntilacompleteset
ofDatabaseDescriptionPacketshasbeenreceived(fromRT2)
beforesendinganyLinkStateRequestPackets,thisneednotbe
thecase.RT1couldhaveinterleavedthesendingofLinkState
RequestPacketswiththereceptionofDatabaseDescription
Packets.
11.TheRoutingTableStructure
Theroutingtabledatastructurecontainsalltheinformation
82/188
3/2/2015
necessarytoforwardanIPdatapackettowarditsdestination.Each
routingtableentrydescribesthecollectionofbestpathstoa
particulardestination.WhenforwardinganIPdatapacket,the
routingtableentryprovidingthebestmatchforthepacket'sIP
destinationislocated.Thematchingroutingtableentrythen
providesthenexthoptowardsthepacket'sdestination.OSPFalso
providesfortheexistenceofadefaultroute(DestinationID=
DefaultDestination,AddressMask=0x00000000).Whenthedefault
routeexists,itmatchesallIPdestinations(althoughanyother
matchingentryisabettermatch).Findingtheroutingtableentry
thatbestmatchesanIPdestinationisfurtherdescribedinSection
11.1.
Thereisasingleroutingtableineachrouter.Twosamplerouting
tablesaredescribedinSections11.2and11.3.Thebuildingofthe
routingtableisdiscussedinSection16.
Therestofthissectiondefinesthefieldsfoundinaroutingtable
entry.Thefirstsetoffieldsdescribestheroutingtableentry's
destination.
DestinationType
Destinationtypeiseither"network"or"router".Onlynetwork
entriesareactuallyusedwhenforwardingIPdatatraffic.
Routerroutingtableentriesareusedsolelyasintermediate
stepsintheroutingtablebuildprocess.
AnetworkisarangeofIPaddresses,towhichIPdatatraffic
maybeforwarded.ThisincludesIPnetworks(classA,B,orC),
IPsubnets,IPsupernetsandsingleIPhosts.Thedefaultroute
alsofallsintothiscategory.
RouterentriesarekeptforareaborderroutersandASboundary
routers.Routingtableentriesforareaborderroutersareused
whencalculatingtheinterarearoutes(seeSection16.2),and
whenmaintainingconfiguredvirtuallinks(seeSection15).
RoutingtableentriesforASboundaryroutersareusedwhen
calculatingtheASexternalroutes(seeSection16.4).
DestinationID
Thedestination'sidentifierorname.Thisdependsonthe
DestinationType.Fornetworks,theidentifieristheir
associatedIPaddress.Forrouters,theidentifieristheOSPF
RouterID.[9]
AddressMask
Onlydefinedfornetworks.Thenetwork'sIPaddresstogether
withitsaddressmaskdefinesarangeofIPaddresses.ForIP
subnets,theaddressmaskisreferredtoasthesubnetmask.
Forhostroutes,themaskis"allones"(0xffffffff).
OptionalCapabilities
Whenthedestinationisarouterthisfieldindicatesthe
optionalOSPFcapabilitiessupportedbythedestinationrouter.
Theonlyoptionalcapabilitydefinedbythisspecificationis
theabilitytoprocessASexternalLSAs.Forafurther
83/188
3/2/2015
discussionofOSPF'soptionalcapabilities,seeSection4.5.
ThesetofpathstouseforadestinationmayvarybasedontheOSPF
areatowhichthepathsbelong.Thismeansthattheremaybe
multipleroutingtableentriesforthesamedestination,depending
onthevaluesofthenextfield.
Area
Thisfieldindicatestheareawhoselinkstateinformationhas
ledtotheroutingtableentry'scollectionofpaths.Thisis
calledtheentry'sassociatedarea.ForsetsofASexternal
paths,thisfieldisnotdefined.Fordestinationsoftype
"router",theremaybeseparatesetsofpaths(andtherefore
separateroutingtableentries)associatedwitheachofseveral
areas.Forexample,thiswillhappenwhentwoareaborder
routerssharemultipleareasincommon.Fordestinationsof
type"network",onlythesetofpathsassociatedwiththebest
area(theoneprovidingthepreferredroute)iskept.
Therestoftheroutingtableentrydescribesthesetofpathsto
thedestination.Thefollowingfieldspertaintothesetofpaths
asawhole.Inotherwords,eachoneofthepathscontainedina
routingtableentryisofthesamepathtypeandcost(seebelow).
Pathtype
Therearefourpossibletypesofpathsusedtoroutetrafficto
thedestination,listedhereindecreasingorderofpreference:
intraarea,interarea,type1externalortype2external.
Intraareapathsindicatedestinationsbelongingtooneofthe
router'sattachedareas.Interareapathsarepathsto
destinationsinotherOSPFareas.Thesearediscoveredthrough
theexaminationofreceivedsummaryLSAs.ASexternalpathsare
pathstodestinationsexternaltotheAS.Thesearedetected
throughtheexaminationofreceivedASexternalLSAs.
Cost
Thelinkstatecostofthepathtothedestination.Forall
pathsexcepttype2externalpathsthisdescribestheentire
path'scost.ForType2externalpaths,thisfielddescribes
thecostoftheportionofthepathinternaltotheAS.This
costiscalculatedasthesumofthecostsofthepath's
constituentlinks.
Type2cost
Onlyvalidfortype2externalpaths.Forthesepaths,this
84/188
3/2/2015
fieldindicatesthecostofthepath'sexternalportion.This
costhasbeenadvertisedbyanASboundaryrouter,andisthe
mostsignificantpartofthetotalpathcost.Forexample,a
type2externalpathwithtype2costof5isalwayspreferred
overapathwithtype2costof10,regardlessofthecostof
thetwopaths'internalcomponents.
LinkStateOrigin
Validonlyforintraareapaths,thisfieldindicatestheLSA
(routerLSAornetworkLSA)thatdirectlyreferencesthe
destination.Forexample,ifthedestinationisatransit
network,thisisthetransitnetwork'snetworkLSA.Ifthe
destinationisastubnetwork,thisistherouterLSAforthe
attachedrouter.TheLSAisdiscoveredduringtheshortestpath
treecalculation(seeSection16.1).MultipleLSAsmay
referencethedestination,howeveratiebreakingschemealways
reducesthechoicetoasingleLSA.TheLinkStateOriginfield
isnotusedbytheOSPFprotocol,butitisusedbytherouting
tablecalculationinOSPF'sMulticastroutingextensions
(MOSPF).
Whenmultiplepathsofequalpathtypeandcostexisttoa
destination(calledelsewhere"equalcost"paths),theyarestored
inasingleroutingtableentry.Eachoneofthe"equalcost"paths
isdistinguishedbythefollowingfields:
Nexthop
Theoutgoingrouterinterfacetousewhenforwardingtrafficto
thedestination.Onbroadcast,PointtoMultiPointandNBMA
networks,thenexthopalsoincludestheIPaddressofthenext
router(ifany)inthepathtowardsthedestination.
Advertisingrouter
ValidonlyforinterareaandASexternalpaths.Thisfield
indicatestheRouterIDoftherouteradvertisingthesummary
LSAorASexternalLSAthatledtothispath.
11.1.Routingtablelookup
WhenanIPdatapacketisreceived,anOSPFrouterfindsthe
routingtableentrythatbestmatchesthepacket'sdestination.
Thisroutingtableentrythenprovidestheoutgoinginterface
andnexthoproutertouseinforwardingthepacket.This
sectiondescribestheprocessoffindingthebestmatching
routingtableentry.
Beforethelookupbegins,"discard"routingtableentriesshould
beinsertedintotheroutingtableforeachoftherouter's
activeareaaddressranges(seeSection3.5).(Anarearangeis
considered"active"iftherangecontainsoneormorenetworks
reachablebyintraareapaths.)Thedestinationofa"discard"
entryisthesetofaddressesdescribedbyitsassociatedactive
areaaddressrange,andthepathtypeofeach"discard"entryis
setto"interarea".[10]
Severalroutingtableentriesmaymatchthedestinationaddress.
Inthiscase,the"bestmatch"istheroutingtableentrythat
85/188
3/2/2015
providesthemostspecific(longest)match.Anotherwayof
sayingthisistochoosetheentrythatspecifiesthenarrowest
rangeofIPaddresses.[11]Forexample,theentryforthe
address/maskpairof(128.185.1.0,0xffffff00)ismorespecific
thananentryforthepair(128.185.0.0,0xffff0000).The
defaultrouteistheleastspecificmatch,sinceitmatchesall
destinations.(Notethatforanysingleroutingtableentry,
multiplepathsmaybepossible.Inthesecases,thecalculations
inSections16.1,16.2,and16.4alwaysyieldthepathshaving
themostpreferentialpathtype,asdescribedinSection11).
Ifthereisnomatchingroutingtableentry,orthebestmatch
routingtableentryisoneoftheabove"discard"routingtable
entries,thenthepacket'sIPdestinationisconsidered
unreachable.Insteadofbeingforwarded,thepacketshouldthen
bediscardedandanICMPdestinationunreachablemessageshould
bereturnedtothepacket'ssource.
11.2.Sampleroutingtable,withoutareas
ConsidertheAutonomousSystempicturedinFigure2.NoOSPF
areashavebeenconfigured.Asinglemetricisshownper
outboundinterface.ThecalculationofRouterRT6'srouting
tableproceedsasdescribedinSection2.2.Theresulting
routingtableisshowninTable12.Destinationtypesare
abbreviated:Networkas"N",Routeras"R".
Therearenoinstancesofmultipleequalcostshortestpathsin
thisexample.Also,sincetherearenoareas,thereareno
interareapaths.
RoutersRT5andRT7areASboundaryrouters.Intraarearoutes
havebeencalculatedtoRoutersRT5andRT7.Thisallows
externalroutestobecalculatedtothedestinationsadvertised
byRT5andRT7(i.e.,NetworksN12,N13,N14andN15).Itis
assumedallASexternalLSAsoriginatedbyRT5andRT7are
advertisingtype1externalmetrics.Thisresultsintype1
externalpathsbeingcalculatedtodestinationsN12N15.
11.3.Sampleroutingtable,withareas
Considerthepreviousexample,thistimesplitintoOSPFareas.
AnOSPFareaconfigurationispicturedinFigure6.Router
RT4'sroutingtablewillbedescribedforthisarea
configuration.RouterRT4hasaconnectiontoArea1anda
backboneconnection.ThiscausesRouterRT4toviewtheASas
theconcatenationofthetwographsshowninFigures7and8.
TheresultingroutingtableisdisplayedinTable13.
Again,RoutersRT5andRT7areASboundaryrouters.Routers
RT3,RT4,RT7,RT10andRT11areareaborderrouters.Notethat
therearetworoutingentriesfortheareaborderrouterRT3,
sinceithastwoareasincommonwithRT4(Area1andthe
backbone).
86/188
3/2/2015
Backbonepathshavebeencalculatedtoallareaborderrouters.
Theseareusedwhendeterminingtheinterarearoutes.Note
thatalloftheinterarearoutesareassociatedwiththe
backbone;thisisalwaysthecasewhenthecalculatingrouteris
itselfanareaborderrouter.Routinginformationiscondensed
atareaboundaries.Inthisexample,weassumethatArea3has
beendefinedsothatnetworksN9N11andthehostroutetoH1
TypeDestAreaPathTypeCostNextAdv.
Hop(s)Router(s)
____________________________________________________________
NN10intraarea10RT3*
NN20intraarea10RT3*
NN30intraarea7RT3*
NN40intraarea8RT3*
NIb0intraarea7**
NIa0intraarea12RT10*
NN60intraarea8RT10*
NN70intraarea12RT10*
NH10intraarea21RT10*
RRT50intraarea6RT5*
RRT70intraarea8RT10*
____________________________________________________________
NN12*type1ext.10RT10RT7
Table12:TheroutingtableforRouterRT6
(noconfiguredareas).
areallcondensedtoasingleroutewhenadvertisedintothe
backbone(byRouterRT11).Notethatthecostofthisrouteis
themaximumofthesetofcoststoitsindividualcomponents.
ThereisavirtuallinkconfiguredbetweenRoutersRT10and
RT11.Withoutthisconfiguredvirtuallink,RT11wouldbe
unabletoadvertisearoutefornetworksN9N11andHostH1into
thebackbone,andtherewouldnotbeanentryforthesenetworks
inRouterRT4'sroutingtable.
InthisexampletherearetwoequalcostpathstoNetworkN12.
However,theybothusethesamenexthop(RouterRT5).
87/188
3/2/2015
RouterRT4'sroutingtablewouldimprove(i.e.,someofthe
pathsintheroutingtablewouldbecomeshorter)ifan
additionalvirtuallinkwereconfiguredbetweenRouterRT4and
RouterRT3.Thenewvirtuallinkwoulditselfbeassociated
withthefirstentryforareaborderrouterRT3inTable13(an
intraareapaththroughArea1).Thiswouldyieldacostof1
forthevirtuallink.Theroutingtableentrieschangesthat
wouldbecausedbytheadditionofthisvirtuallinkareshown
Hops(s)Router(s)
__________________________________________________________________
NN11intraarea4RT1*
NN21intraarea4RT2*
NN31intraarea1**
NN41intraarea3RT3*
RRT31intraarea1**
__________________________________________________________________
NIb0intraarea22RT5*
NIa0intraarea27RT5*
RRT50intraarea8**
__________________________________________________________________
NN60interarea15RT5RT7
NN9N11,H10interarea36RT5RT11
__________________________________________________________________
NN12*type1ext.16RT5RT5,RT7
Table13:RouterRT4'sroutingtable
inthepresenceofareas.
inTable14.
12.LinkStateAdvertisements(LSAs)
EachrouterintheAutonomousSystemoriginatesoneormorelink
stateadvertisements(LSAs).Thismemodefinesfivedistincttypes
ofLSAs,whicharedescribedinSection4.3.ThecollectionofLSAs
formsthelinkstatedatabase.EachseparatetypeofLSAhasa
separatefunction.RouterLSAsandnetworkLSAsdescribehowan
area'sroutersandnetworksareinterconnected.SummaryLSAs
provideawayofcondensinganarea'sroutinginformation.AS
externalLSAsprovideawayoftransparentlyadvertising
externallyderivedroutinginformationthroughouttheAutonomous
88/188
3/2/2015
System.
EachLSAbeginswithastandard20byteheader.ThisLSAheaderis
discussedbelow.
Hop(s)Router(s)
________________________________________________________________
NIb0intraarea16RT3*
NIa0intraarea21RT3*
RRT30intraarea1**
________________________________________________________________
NN9N11,H10interarea30RT3RT11
Table14:Changesresultingfroman
additionalvirtuallink.
12.1.TheLSAHeader
TheLSAheadercontainstheLStype,LinkStateIDand
AdvertisingRouterfields.Thecombinationofthesethree
fieldsuniquelyidentifiestheLSA.
TheremaybeseveralinstancesofanLSApresentinthe
AutonomousSystem,allatthesametime.Itmustthenbe
determinedwhichinstanceismorerecent.Thisdeterminationis
madebyexaminingtheLSsequence,LSchecksumandLSage
fields.Thesefieldsarealsocontainedinthe20byteLSA
header.
SeveraloftheOSPFpackettypeslistLSAs.Whentheinstance
isnotimportant,anLSAisreferredtobyitsLStype,Link
StateIDandAdvertisingRouter(seeLinkStateRequest
Packets).Otherwise,theLSsequencenumber,LSageandLS
checksumfieldsmustalsobereferenced.
AdetailedexplanationofthefieldscontainedintheLSAheader
follows.
12.1.1.LSage
ThisfieldistheageoftheLSAinseconds.Itshouldbe
processedasanunsigned16bitinteger.Itissetto0
whentheLSAisoriginated.Itmustbeincrementedby
InfTransDelayoneveryhopofthefloodingprocedure.LSAs
arealsoagedastheyareheldineachrouter'sdatabase.
89/188
3/2/2015
TheageofanLSAisneverincrementedpastMaxAge.LSAs
havingageMaxAgearenotusedintheroutingtable
calculation.WhenanLSA'sagefirstreachesMaxAge,itis
reflooded.AnLSAofageMaxAgeisfinallyflushedfromthe
databasewhenitisnolongerneededtoensuredatabase
synchronization.FormoreinformationontheagingofLSAs,
consultSection14.
TheLSagefieldisexaminedwhenarouterreceivestwo
instancesofanLSA,bothhavingidenticalLSsequence
numbersandLSchecksums.AninstanceofageMaxAgeisthen
alwaysacceptedasmostrecent;thisallowsoldLSAstobe
flushedquicklyfromtheroutingdomain.Otherwise,ifthe
agesdifferbymorethanMaxAgeDiff,theinstancehavingthe
smallerageisacceptedasmostrecent.[12]SeeSection13.1
formoredetails.
12.1.2.Options
TheOptionsfieldintheLSAheaderindicateswhichoptional
capabilitiesareassociatedwiththeLSA.OSPF'soptional
capabilitiesaredescribedinSection4.5.Oneoptional
capabilityisdefinedbythisspecification,representedby
theEbitfoundintheOptionsfield.Theunrecognizedbits
intheOptionsfieldshouldbesettozero.
TheEbitrepresentsOSPF'sExternalRoutingCapability.This
bitshouldbesetinallLSAsassociatedwiththebackbone,
andallLSAsassociatedwithnonstubareas(seeSection
3.6).ItshouldalsobesetinallASexternalLSAs.It
shouldberesetinallrouterLSAs,networkLSAsand
summaryLSAsassociatedwithastubarea.ForallLSAs,the
settingoftheEbitisforinformationalpurposesonly;it
doesnotaffecttheroutingtablecalculation.
12.1.3.LStype
TheLStypefielddictatestheformatandfunctionofthe
LSA.LSAsofdifferenttypeshavedifferentnames(e.g.,
routerLSAsornetworkLSAs).AllLSAtypesdefinedbythis
memo,excepttheASexternalLSAs(LStype=5),areflooded
throughoutasingleareaonly.ASexternalLSAsareflooded
throughouttheentireAutonomousSystem,exceptingstub
areas(seeSection3.6).EachseparateLSAtypeisbriefly
describedbelowinTable15.
12.1.4.LinkStateID
Thisfieldidentifiesthepieceoftheroutingdomainthat
isbeingdescribedbytheLSA.DependingontheLSA'sLS
type,theLinkStateIDtakesonthevalueslistedinTable
90/188
3/2/2015
LSTypeLSAdescription
________________________________________________
1ThesearetherouterLSAs.
Theydescribethecollected
statesoftherouter's
interfaces.Formoreinformation,
consultSection12.4.1.
________________________________________________
2ThesearethenetworkLSAs.
Theydescribethesetofrouters
attachedtothenetwork.For
moreinformation,consult
Section12.4.2.
________________________________________________
3or4ThesearethesummaryLSAs.
Theydescribeinterarearoutes,
andenablethecondensationof
routinginformationatarea
borders.Originatedbyareaborder
routers,theType3summaryLSAs
describeroutestonetworkswhilethe
Type4summaryLSAsdescriberoutesto
ASboundaryrouters.
________________________________________________
5ThesearetheASexternalLSAs.
OriginatedbyASboundaryrouters,
theydescriberoutes
todestinationsexternaltothe
AutonomousSystem.Adefaultroutefor
theAutonomousSystemcanalsobe
describedbyanASexternalLSA.
Table15:OSPFlinkstateadvertisements(LSAs).
16.
Actually,forType3summaryLSAs(LStype=3)andAS
externalLSAs(LStype=5),theLinkStateIDmay
LSTypeLinkStateID
_______________________________________________
1Theoriginatingrouter'sRouterID.
2TheIPinterfaceaddressofthe
network'sDesignatedRouter.
3Thedestinationnetwork'sIPaddress.
4TheRouterIDofthedescribedAS
boundaryrouter.
91/188
3/2/2015
5Thedestinationnetwork'sIPaddress.
Table16:TheLSA'sLinkStateID.
additionallyhaveoneormoreofthedestinationnetwork's
"host"bitsset.Forexample,whenoriginatinganAS
externalLSAforthenetwork10.0.0.0withmaskof
255.0.0.0,theLinkStateIDcanbesettoanythinginthe
range10.0.0.0through10.255.255.255inclusive(although
10.0.0.0shouldbeusedwheneverpossible).Thefreedomto
setcertainhostbitsallowsaroutertooriginateseparate
LSAsfortwonetworkshavingthesameaddressbutdifferent
masks.SeeAppendixEfordetails.
WhentheLSAisdescribinganetwork(LStype=2,3or5),
thenetwork'sIPaddressiseasilyderivedbymaskingthe
LinkStateIDwiththenetwork/subnetmaskcontainedinthe
bodyoftheLSA.WhentheLSAisdescribingarouter(LS
type=1or4),theLinkStateIDisalwaysthedescribed
router'sOSPFRouterID.
WhenanASexternalLSA(LSType=5)isdescribinga
defaultroute,itsLinkStateIDissetto
DefaultDestination(0.0.0.0).
12.1.5.AdvertisingRouter
ThisfieldspecifiestheOSPFRouterIDoftheLSA's
originator.ForrouterLSAs,thisfieldisidenticaltothe
LinkStateIDfield.NetworkLSAsareoriginatedbythe
network'sDesignatedRouter.SummaryLSAsoriginatedby
areaborderrouters.ASexternalLSAsareoriginatedbyAS
boundaryrouters.
12.1.6.LSsequencenumber
Thesequencenumberfieldisasigned32bitinteger.Itis
usedtodetectoldandduplicateLSAs.Thespaceof
sequencenumbersislinearlyordered.Thelargerthe
sequencenumber(whencomparedassigned32bitintegers)
themorerecenttheLSA.Todescribetosequencenumber
spacemoreprecisely,letNreferinthediscussionbelowto
theconstant2**31.
ThesequencenumberN(0x80000000)isreserved(and
unused).ThisleavesN+1(0x80000001)asthesmallest
(andthereforeoldest)sequencenumber;thissequencenumber
isreferredtoastheconstantInitialSequenceNumber.A
routerusesInitialSequenceNumberthefirsttimeit
originatesanyLSA.Afterwards,theLSA'ssequencenumber
isincrementedeachtimetherouteroriginatesanew
instanceoftheLSA.Whenanattemptismadetoincrement
thesequencenumberpastthemaximumvalueofN1
(0x7fffffff;alsoreferredtoasMaxSequenceNumber),the
92/188
3/2/2015
currentinstanceoftheLSAmustfirstbeflushedfromthe
routingdomain.ThisisdonebyprematurelyagingtheLSA
(seeSection14.1)andrefloodingit.Assoonasthisflood
hasbeenacknowledgedbyalladjacentneighbors,anew
instancecanbeoriginatedwithsequencenumberof
InitialSequenceNumber.
Theroutermaybeforcedtopromotethesequencenumberof
oneofitsLSAswhenamorerecentinstanceoftheLSAis
unexpectedlyreceivedduringthefloodingprocess.This
shouldbearareevent.Thismayindicatethatanoutof
dateLSA,originatedbytherouteritselfbeforeitslast
restart/reload,stillexistsintheAutonomousSystem.For
moreinformationseeSection13.4.
12.1.7.LSchecksum
Thisfieldisthechecksumofthecompletecontentsofthe
LSA,exceptingtheLSagefield.TheLSagefieldis
exceptedsothatanLSA'sagecanbeincrementedwithout
updatingthechecksum.Thechecksumusedisthesamethat
isusedforISOconnectionlessdatagrams;itiscommonly
referredtoastheFletcherchecksum.Itisdocumentedin
AnnexBof[Ref6].TheLSAheaderalsocontainsthelength
oftheLSAinbytes;subtractingthesizeoftheLSage
field(twobytes)yieldstheamountofdatatochecksum.
ThechecksumisusedtodetectdatacorruptionofanLSA.
ThiscorruptioncanoccurwhileanLSAisbeingflooded,or
whileitisbeingheldinarouter'smemory.TheLS
checksumfieldcannottakeonthevalueofzero;the
occurrenceofsuchavalueshouldbeconsideredachecksum
failure.Inotherwords,calculationofthechecksumisnot
optional.
ThechecksumofanLSAisverifiedintwocases:a)whenit
isreceivedinaLinkStateUpdatePacketandb)attimes
duringtheagingofthelinkstatedatabase.Thedetection
ofachecksumfailureleadstoseparateactionsineach
case.SeeSections13and14formoredetails.
WhenevertheLSsequencenumberfieldindicatesthattwo
instancesofanLSAarethesame,theLSchecksumfieldis
examined.Ifthereisadifference,theinstancewiththe
largerLSchecksumisconsideredtobemostrecent.[13]See
Section13.1formoredetails.
12.2.Thelinkstatedatabase
Arouterhasaseparatelinkstatedatabaseforeveryareato
whichitbelongs.Allroutersbelongingtothesameareahave
identicallinkstatedatabasesforthearea.
Thedatabasesforeachindividualareaarealwaysdealtwith
93/188
3/2/2015
separately.Theshortestpathcalculationisperformed
separatelyforeacharea(seeSection16).Componentsofthe
arealinkstatedatabasearefloodedthroughouttheareaonly.
Finally,whenanadjacency(belongingtoAreaA)isbeing
broughtup,onlythedatabaseforAreaAissynchronizedbetween
thetworouters.
TheareadatabaseiscomposedofrouterLSAs,networkLSAsand
summaryLSAs(alllistedintheareadatastructure).In
addition,externalroutes(ASexternalLSAs)areincludedinall
nonstubareadatabases(seeSection3.6).
AnimplementationofOSPFmustbeabletoaccessindividual
piecesofanareadatabase.Thislookupfunctionisbasedonan
LSA'sLStype,LinkStateIDandAdvertisingRouter.[14]There
willbeasingleinstance(themostuptodate)ofeachLSAin
thedatabase.Thedatabaselookupfunctionisinvokedduring
theLSAfloodingprocedure(Section13)andtheroutingtable
calculation(Section16).Inaddition,usingthislookup
functiontheroutercandeterminewhetherithasitselfever
originatedaparticularLSA,andifso,withwhatLSsequence
number.
AnLSAisaddedtoarouter'sdatabasewheneithera)itis
receivedduringthefloodingprocess(Section13)orb)itis
originatedbytherouteritself(Section12.4).AnLSAis
deletedfromarouter'sdatabasewheneithera)ithasbeen
overwrittenbyanewerinstanceduringthefloodingprocess
(Section13)orb)therouteroriginatesanewerinstanceofone
ofitsselforiginatedLSAs(Section12.4)orc)theLSAages
outandisflushedfromtheroutingdomain(Section14).
WheneveranLSAisdeletedfromthedatabaseitmustalsobe
removedfromallneighbors'Linkstateretransmissionlists(see
Section10).
12.3.RepresentationofTOS
ForbackwardcompatibilitywithpreviousversionsoftheOSPF
specification([Ref9]),TOSspecificinformationcanbeincluded
inrouterLSAs,summaryLSAsandASexternalLSAs.Theencoding
ofTOSinOSPFLSAsisspecifiedinTable17.Thattablerelates
theOSPFencodingtotheIPpacketheader'sTOSfield(defined
in[Ref12]).TheOSPFencodingisexpressedasadecimal
integer,andtheIPpacketheader'sTOSfieldisexpressedin
thebinaryTOSvaluesusedin[Ref12].
94/188
3/2/2015
OSPFencodingRFC1349TOSvalues
___________________________________________
00000normalservice
20001minimizemonetarycost
40010maximizereliability
60011
80100maximizethroughput
100101
120110
140111
161000minimizedelay
181001
201010
221011
241100
261101
281110
301111
Table17:RepresentingTOSinOSPF.
12.4.OriginatingLSAs
IntoanygivenOSPFarea,arouterwilloriginateseveralLSAs.
EachrouteroriginatesarouterLSA.Iftherouterisalsothe
DesignatedRouterforanyofthearea'snetworks,itwill
originatenetworkLSAsforthosenetworks.
AreaborderroutersoriginateasinglesummaryLSAforeach
knowninterareadestination.ASboundaryroutersoriginatea
singleASexternalLSAforeachknownASexternaldestination.
Destinationsareadvertisedoneatatimesothatthechangein
anysingleroutecanbefloodedwithoutrefloodingtheentire
collectionofroutes.Duringthefloodingprocedure,manyLSAs
canbecarriedbyasingleLinkStateUpdatepacket.
Asanexample,considerRouterRT4inFigure6.Itisanarea
borderrouter,havingaconnectiontoArea1andthebackbone.
RouterRT4originates5distinctLSAsintothebackbone(one
routerLSA,andonesummaryLSAforeachofthenetworksN1N4).
RouterRT4willalsooriginate8distinctLSAsintoArea1(one
routerLSAandsevensummaryLSAsaspicturedinFigure7).If
RT4hasbeenselectedasDesignatedRouterforNetworkN3,it
willalsooriginateanetworkLSAforN3intoArea1.
Inthissamefigure,RouterRT5willbeoriginating3distinct
ASexternalLSAs(oneforeachofthenetworksN12N14).These
willbefloodedthroughouttheentireAS,assumingthatnoneof
theareashavebeenconfiguredasstubs.However,ifarea3has
beenconfiguredasastubarea,theASexternalLSAsfor
networksN12N14willnotbefloodedintoarea3(seeSection
3.6).Instead,RouterRT11wouldoriginateadefaultsummary
LSAthatwouldbefloodedthroughoutarea3(seeSection
12.4.3).Thisinstructsallofarea3'sinternalroutersto
sendtheirASexternaltraffictoRT11.
95/188
3/2/2015
WheneveranewinstanceofanLSAisoriginated,itsLSsequence
numberisincremented,itsLSageissetto0,itsLSchecksum
iscalculated,andtheLSAisaddedtothelinkstatedatabase
andfloodedouttheappropriateinterfaces.SeeSection13.2
fordetailsconcerningtheinstallationoftheLSAintothelink
statedatabase.SeeSection13.3fordetailsconcerningthe
floodingofnewlyoriginatedLSAs.
TheteneventsthatcancauseanewinstanceofanLSAtobe
originatedare:
(1)TheLSagefieldofoneoftherouter'sselforiginatedLSAs
reachesthevalueLSRefreshTime.Inthiscase,anew
instanceoftheLSAisoriginated,eventhoughthecontents
oftheLSA(apartfromtheLSAheader)willbethesame.
ThisguaranteesperiodicoriginationsofallLSAs.This
periodicupdatingofLSAsaddsrobustnesstothelinkstate
algorithm.LSAsthatsolelydescribeunreachable
destinationsshouldnotberefreshed,butshouldinsteadbe
flushedfromtheroutingdomain(seeSection14.1).
WhenwhateverisbeingdescribedbyanLSAchanges,anewLSAis
originated.However,twoinstancesofthesameLSAmaynotbe
originatedwithinthetimeperiodMinLSInterval.Thismay
requirethatthegenerationofthenextinstancebedelayedby
uptoMinLSInterval.Thefollowingeventsmaycausethe
contentsofanLSAtochange.Theseeventsshouldcausenew
originationsifandonlyifthecontentsofthenewLSAwouldbe
different:
(2)Aninterface'sstatechanges(seeSection9.1).Thismay
meanthatitisnecessarytoproduceanewinstanceofthe
routerLSA.
(3)Anattachednetwork'sDesignatedRouterchanges.Anew
routerLSAshouldbeoriginated.Also,iftherouteritself
isnowtheDesignatedRouter,anewnetworkLSAshouldbe
produced.IftherouteritselfisnolongertheDesignated
Router,anynetworkLSAthatitmighthaveoriginatedfor
thenetworkshouldbeflushedfromtheroutingdomain(see
Section14.1).
(4)Oneoftheneighboringrouterschangesto/fromtheFULL
state.Thismaymeanthatitisnecessarytoproduceanew
instanceoftherouterLSA.Also,iftherouterisitself
theDesignatedRouterfortheattachednetwork,anew
networkLSAshouldbeproduced.
Thenextfoureventsconcernareaborderroutersonly:
(5)Anintraarearoutehasbeenadded/deleted/modifiedinthe
routingtable.Thismaycauseanewinstanceofasummary
LSA(forthisroute)tobeoriginatedineachattachedarea
96/188
3/2/2015
(possiblyincludingthebackbone).
(6)Aninterarearoutehasbeenadded/deleted/modifiedinthe
routingtable.Thismaycauseanewinstanceofasummary
LSA(forthisroute)tobeoriginatedineachattachedarea
(butNEVERforthebackbone).
(7)Therouterbecomesnewlyattachedtoanarea.Therouter
mustthenoriginatesummaryLSAsintothenewlyattached
areaforallpertinentintraareaandinterarearoutesin
therouter'sroutingtable.SeeSection12.4.3formore
details.
(8)Whenthestateofoneoftherouter'sconfiguredvirtual
linkschanges,itmaybenecessarytooriginateanew
routerLSAintothevirtuallink'sTransitarea(seethe
discussionoftherouterLSA'sbitVinSection12.4.1),as
wellasoriginatinganewrouterLSAintothebackbone.
ThelasttwoeventsconcernASboundaryrouters(andformerAS
boundaryrouters)only:
(9)Anexternalroutegainedthroughdirectexperiencewithan
externalroutingprotocol(likeBGP)changes.Thiswill
causeanASboundaryroutertooriginateanewinstanceof
anASexternalLSA.
(10)
ArouterceasestobeanASboundaryrouter,perhapsafter
restarting.Inthissituationtheroutershouldflushall
ASexternalLSAsthatithadpreviouslyoriginated.These
LSAscanbeflushedviatheprematureagingprocedure
specifiedinSection14.1.
TheconstructionofeachtypeofLSAisexplainedindetail
below.Ingeneral,thesesectionsdescribethecontentsofthe
LSAbody(i.e.,thepartcomingafterthe20byteLSAheader).
ForinformationconcerningthebuildingoftheLSAheader,see
Section12.1.
12.4.1.RouterLSAs
ArouteroriginatesarouterLSAforeachareathatit
belongsto.SuchanLSAdescribesthecollectedstatesof
therouter'slinkstothearea.TheLSAisflooded
throughouttheparticulararea,andnofurther.
97/188
3/2/2015
....................................
.192.1.2Area1.
.+.
.|.
.|3++1.
.N1||RT1|+.
.|++\.
.|\_______N3.
.+\/\.1++
.*192.1.1*|RT4|
.+/\_______/.++
.|/|.
.|3++1/|.
.N2||RT2|+1|.
.|++++8.6++
.||RT3||RT6|
.+++.++
.192.1.3|2.18.10.0.6|7
.|.|
.++.
.192.1.4(N4).
....................................
Figure15:Area1withIPaddressesshown
TheformatofarouterLSAisshowninAppendixA(Section
A.4.2).Thefirst20bytesoftheLSAconsistofthe
genericLSAheaderthatwasdiscussedinSection12.1.
routerLSAshaveLStype=1.
Arouteralsoindicateswhetheritisanareaborderrouter,
oranASboundaryrouter,bysettingtheappropriatebits
(bitBandbitE,respectively)initsrouterLSAs.This
enablespathstothosetypesofrouterstobesavedinthe
routingtable,forlaterprocessingofsummaryLSAsandAS
externalLSAs.BitBshouldbesetwhenevertherouteris
activelyattachedtotwoormoreareas,eveniftherouter
isnotcurrentlyattachedtotheOSPFbackbonearea.BitE
shouldneverbesetinarouterLSAforastubarea(stub
areascannotcontainASboundaryrouters).
Inaddition,theroutersetsbitVinitsrouterLSAfor
AreaAifandonlyiftherouteristheendpointofoneor
morefullyadjacentvirtuallinkshavingAreaAastheir
Transitarea.ThesettingofbitVenablesotherroutersin
AreaAtodiscoverwhethertheareasupportstransittraffic
(seeTransitCapabilityinSection6).
TherouterLSAthendescribestherouter'sworking
connections(i.e.,interfacesorlinks)tothearea.Each
linkistypedaccordingtothekindofattachednetwork.
EachlinkisalsolabelledwithitsLinkID.ThisLinkID
givesanametotheentitythatisontheotherendofthe
link.Table18summarizesthevaluesusedfortheTypeand
LinkIDfields.
98/188
3/2/2015
LinktypeDescriptionLinkID
__________________________________________________
1PointtopointNeighborRouterID
link
2LinktotransitInterfaceaddressof
networkDesignatedRouter
3LinktostubIPnetworknumber
network
4VirtuallinkNeighborRouterID
Table18:Linkdescriptionsinthe
routerLSA.
Inaddition,theLinkDatafieldisspecifiedforeachlink.
Thisfieldgives32bitsofextrainformationforthelink.
Forlinkstotransitnetworks,numberedpointtopointlinks
andvirtuallinks,thisfieldspecifiestheIPinterface
addressoftheassociatedrouterinterface(thisisneeded
bytheroutingtablecalculation,seeSection16.1.1).For
linkstostubnetworks,thisfieldspecifiesthestub
network'sIPaddressmask.Forunnumberedpointtopoint
links,theLinkDatafieldshouldbesettotheunnumbered
interface'sMIBII[Ref8]ifIndexvalue.
Finally,thecostofusingthelinkforoutputisspecified.
Theoutputcostofalinkisconfigurable.Withthe
exceptionoflinkstostubnetworks,theoutputcostmust
alwaysbenonzero.
Tofurtherdescribetheprocessofbuildingthelistoflink
descriptions,supposearouterwishestobuildarouterLSA
forAreaA.Therouterexaminesitscollectionofinterface
datastructures.Foreachinterface,thefollowingsteps
aretaken:
oIftheattachednetworkdoesnotbelongtoAreaA,no
linksareaddedtotheLSA,andthenextinterface
shouldbeexamined.
oIfthestateoftheinterfaceisDown,nolinksare
added.
oIfthestateoftheinterfaceisLoopback,addaType3
link(stubnetwork)aslongasthisisnotaninterface
toanunnumberedpointtopointnetwork.TheLinkID
shouldbesettotheIPinterfaceaddress,theLinkData
settothemask0xffffffff(indicatingahostroute),
andthecostsetto0.
oOtherwise,thelinkdescriptionsaddedtotherouterLSA
dependontheOSPFinterfacetype.Linkdescriptions
usedforpointtopointinterfacesarespecifiedin
Section12.4.1.1,forvirtuallinksinSection12.4.1.2,
99/188
3/2/2015
forbroadcastandNBMAinterfacesin12.4.1.3,andfor
PointtoMultiPointinterfacesin12.4.1.4.
Afterconsiderationofalltherouterinterfaces,hostlinks
areaddedtotherouterLSAbyexaminingthelistof
attachedhostsbelongingtoAreaA.Ahostrouteis
representedasaType3link(stubnetwork)whoseLinkIDis
thehost'sIPaddress,LinkDataisthemaskofallones
(0xffffffff),andcostthehost'sconfiguredcost(see
SectionC.7).
12.4.1.1.Describingpointtopointinterfaces
Forpointtopointinterfaces,oneormorelink
descriptionsareaddedtotherouterLSAasfollows:
oIftheneighboringrouterisfullyadjacent,adda
Type1link(pointtopoint).TheLinkIDshouldbe
settotheRouterIDoftheneighboringrouter.For
numberedpointtopointnetworks,theLinkData
shouldspecifytheIPinterfaceaddress.For
unnumberedpointtopointnetworks,theLinkData
fieldshouldspecifytheinterface'sMIBII[Ref8]
ifIndexvalue.Thecostshouldbesettotheoutput
costofthepointtopointinterface.
oInaddition,aslongasthestateoftheinterface
is"PointtoPoint"(andregardlessofthe
neighboringrouterstate),aType3link(stub
network)shouldbeadded.Therearetwoformsthat
thisstublinkcantake:
Option1
Assumingthattheneighboringrouter'sIP
addressisknown,settheLinkIDoftheType3
linktotheneighbor'sIPaddress,theLinkData
tothemask0xffffffff(indicatingahost
route),andthecosttotheinterface's
configuredoutputcost.[15]
Option2
Ifasubnethasbeenassignedtothepointto
pointlink,settheLinkIDoftheType3link
tothesubnet'sIPaddress,theLinkDatatothe
subnet'smask,andthecosttotheinterface's
configuredoutputcost.[16]
12.4.1.2.DescribingbroadcastandNBMAinterfaces
ForoperationalbroadcastandNBMAinterfaces,asingle
linkdescriptionisaddedtotherouterLSAasfollows:
100/188
3/2/2015
oIfthestateoftheinterfaceisWaiting,addaType
3link(stubnetwork)withLinkIDsettotheIP
networknumberoftheattachednetwork,LinkData
settotheattachednetwork'saddressmask,andcost
equaltotheinterface'sconfiguredoutputcost.
oElse,therehasbeenaDesignatedRouterelectedfor
theattachednetwork.Iftherouterisfully
adjacenttotheDesignatedRouter,oriftherouter
itselfisDesignatedRouterandisfullyadjacentto
atleastoneotherrouter,addasingleType2link
(transitnetwork)withLinkIDsettotheIP
interfaceaddressoftheattachednetwork's
DesignatedRouter(whichmaybetherouteritself),
LinkDatasettotherouter'sownIPinterface
address,andcostequaltotheinterface's
configuredoutputcost.Otherwise,addalinkasif
theinterfacestatewereWaiting(seeabove).
12.4.1.3.Describingvirtuallinks
Forvirtuallinks,alinkdescriptionisaddedtothe
routerLSAonlywhenthevirtualneighborisfully
adjacent.Inthiscase,addaType4link(virtuallink)
withLinkIDsettotheRouterIDofthevirtual
neighbor,LinkDatasettotheIPinterfaceaddress
associatedwiththevirtuallinkandcostsettothe
costcalculatedforthevirtuallinkduringtherouting
tablecalculation(seeSection15).
12.4.1.4.DescribingPointtoMultiPointinterfaces
ForoperationalPointtoMultiPointinterfaces,oneor
morelinkdescriptionsareaddedtotherouterLSAas
follows:
oAsingleType3link(stubnetwork)isaddedwith
LinkIDsettotherouter'sownIPinterface
address,LinkDatasettothemask0xffffffff
(indicatingahostroute),andcostsetto0.
oForeachfullyadjacentneighborassociatedwiththe
interface,addanadditionalType1link(pointto
point)withLinkIDsettotheRouterIDofthe
neighboringrouter,LinkDatasettotheIP
interfaceaddressandcostequaltotheinterface's
configuredoutputcost.
12.4.1.5.ExamplesofrouterLSAs
101/188
3/2/2015
ConsidertherouterLSAsgeneratedbyRouterRT3,as
picturedinFigure6.TheareacontainingRouterRT3
(Area1)hasbeenredrawn,withactualnetwork
addresses,inFigure15.Assumethatthelastbyteof
allofRT3'sinterfaceaddressesis3,givingitthe
interfaceaddresses192.1.1.3and192.1.4.3,andthat
theotherroutershavesimilaraddressingschemes.In
addition,assumethatalllinksarefunctional,andthat
RouterIDsareassignedasthesmallestIPinterface
address.
RT3originatestworouterLSAs,oneforArea1andone
forthebackbone.AssumethatRouterRT4hasbeen
selectedastheDesignatedrouterfornetwork192.1.1.0.
RT3'srouterLSAforArea1isthenshownbelow.It
indicatesthatRT3hastwoconnectionstoArea1,the
firstalinktothetransitnetwork192.1.1.0andthe
secondalinktothestubnetwork192.1.4.0.Notethat
thetransitnetworkisidentifiedbytheIPinterfaceof
itsDesignatedRouter(i.e.,theLinkID=192.1.1.4
whichistheDesignatedRouterRT4'sIPinterfaceto
192.1.1.0).NotealsothatRT3hasindicatedthatitis
anareaborderrouter.
;RT3'srouterLSAforArea1
LSage=0;alwaystrueonorigination
Options=(Ebit);
LStype=1;indicatesrouterLSA
LinkStateID=192.1.1.3;RT3'sRouterID
AdvertisingRouter=192.1.1.3;RT3'sRouterID
bitE=0;notanASboundaryrouter
bitB=1;areaborderrouter
#links=2
LinkID=192.1.1.4;IPaddressofDesig.Rtr.
LinkData=192.1.1.3;RT3'sIPinterfacetonet
Type=2;connectstotransitnetwork
#TOSmetrics=0
metric=1
LinkID=192.1.4.0;IPNetworknumber
LinkData=0xffffff00;Networkmask
Type=3;connectstostubnetwork
#TOSmetrics=0
metric=2
NextRT3'srouterLSAforthebackboneisshown.It
indicatesthatRT3hasasingleattachmenttothe
backbone.Thisattachmentisviaanunnumbered
pointtopointlinktoRouterRT6.RT3hasagain
indicatedthatitisanareaborderrouter.
;RT3'srouterLSAforthebackbone
Options=(Ebit);
LStype=1;indicatesrouterLSA
102/188
3/2/2015
LinkStateID=192.1.1.3;RT3'srouterID
AdvertisingRouter=192.1.1.3;RT3'srouterID
bitE=0;notanASboundaryrouter
bitB=1;areaborderrouter
#links=1
LinkID=18.10.0.6;Neighbor'sRouterID
LinkData=0.0.0.3;MIBIIifIndexofPPlink
Type=1;connectstorouter
#TOSmetrics=0
metric=8
12.4.2.NetworkLSAs
AnetworkLSAisgeneratedforeverytransitbroadcastor
NBMAnetwork.(Atransitnetworkisanetworkhavingtwoor
moreattachedrouters).ThenetworkLSAdescribesallthe
routersthatareattachedtothenetwork.
TheDesignatedRouterforthenetworkoriginatestheLSA.
TheDesignatedRouteroriginatestheLSAonlyifitisfully
adjacenttoatleastoneotherrouteronthenetwork.The
networkLSAisfloodedthroughouttheareathatcontainsthe
transitnetwork,andnofurther.ThenetworkLSAlists
thoseroutersthatarefullyadjacenttotheDesignated
Router;eachfullyadjacentrouterisidentifiedbyitsOSPF
RouterID.TheDesignatedRouterincludesitselfinthis
list.
TheLinkStateIDforanetworkLSAistheIPinterface
addressoftheDesignatedRouter.Thisvalue,maskedbythe
network'saddressmask(whichisalsocontainedinthe
networkLSA)yieldsthenetwork'sIPaddress.
ArouterthathasformerlybeentheDesignatedRouterfora
network,butisnolonger,shouldflushthenetworkLSAthat
ithadpreviouslyoriginated.ThisLSAisnolongerusedin
theroutingtablecalculation.Itisflushedbyprematurely
incrementingtheLSA'sagetoMaxAgeandreflooding(see
Section14.1).Inaddition,inthoserarecaseswherea
router'sRouterIDhaschanged,anynetworkLSAsthatwere
originatedwiththerouter'spreviousRouterIDmustbe
flushed.Sincetheroutermayhavenoideawhatit's
previousRouterIDmighthavebeen,thesenetworkLSAsare
indicatedbyhavingtheirLinkStateIDequaltooneofthe
router'sIPinterfaceaddressesandtheirAdvertisingRouter
equaltosomevalueotherthantherouter'scurrentRouter
ID(seeSection13.4formoredetails).
12.4.2.1.ExamplesofnetworkLSAs
AgainconsidertheareaconfigurationinFigure6.
NetworkLSAsareoriginatedforNetworkN3inArea1,
NetworksN6andN8inArea2,andNetworkN9inArea3.
AssumingthatRouterRT4hasbeenselectedasthe
DesignatedRouterforNetworkN3,thefollowing
networkLSAisgeneratedbyRT4onbehalfofNetworkN3
(seeFigure15fortheaddressassignments):
103/188
3/2/2015
;NetworkLSAforNetworkN3
Options=(Ebit);
LStype=2;indicatesnetworkLSA
LinkStateID=192.1.1.4;IPaddressofDesig.Rtr.
AdvertisingRouter=192.1.1.4;RT4'sRouterID
NetworkMask=0xffffff00
AttachedRouter=192.1.1.4;RouterID
12.4.3.SummaryLSAs
ThedestinationdescribedbyasummaryLSAiseitheranIP
network,anASboundaryrouterorarangeofIPaddresses.
SummaryLSAsarefloodedthroughoutasingleareaonly.The
destinationdescribedisonethatisexternaltothearea,
yetstillbelongstotheAutonomousSystem.
SummaryLSAsareoriginatedbyareaborderrouters.The
precisesummaryroutestoadvertiseintoanareaare
determinedbyexaminingtheroutingtablestructure(see
Section11)inaccordancewiththealgorithmdescribed
below.Notethatonlyintraarearoutesareadvertisedinto
thebackbone,whilebothintraareaandinterarearoutes
areadvertisedintotheotherareas.
TodeterminewhichroutestoadvertiseintoanattachedArea
A,eachroutingtableentryisprocessedasfollows.
Rememberthateachroutingtableentrydescribesasetof
equalcostbestpathstoaparticulardestination:
oOnlyDestinationTypesofnetworkandASboundaryrouter
areadvertisedinsummaryLSAs.Iftheroutingtable
entry'sDestinationTypeisareaborderrouter,examine
thenextroutingtableentry.
oASexternalroutesareneveradvertisedinsummaryLSAs.
IftheroutingtableentryhasPathtypeoftype1
externalortype2external,examinethenextrouting
tableentry.
oElse,iftheareaassociatedwiththissetofpathsis
theAreaAitself,donotgenerateasummaryLSAforthe
route.[17]
oElse,ifthenexthopsassociatedwiththissetofpaths
104/188
3/2/2015
belongtoAreaAitself,donotgenerateasummaryLSA
fortheroute.[18]Thisisthelogicalequivalentofa
DistanceVectorprotocol'ssplithorizonlogic.
oElse,iftheroutingtablecostequalsorexceedsthe
valueLSInfinity,asummaryLSAcannotbegeneratedfor
thisroute.
oElse,ifthedestinationofthisrouteisanASboundary
router,asummaryLSAshouldbeoriginatedifandonly
iftheroutingtableentrydescribesthepreferredpath
totheASboundaryrouter(seeStep3ofSection16.4).
Ifso,aType4summaryLSAisoriginatedforthe
destination,withLinkStateIDequaltotheASboundary
router'sRouterIDandmetricequaltotheroutingtable
entry'scost.Note:theseLSAsshouldnotbegenerated
ifAreaAhasbeenconfiguredasastubarea.
oElse,theDestinationtypeisnetwork.Ifthisisan
interarearoute,generateaType3summaryLSAforthe
destination,withLinkStateIDequaltothenetwork's
address(ifnecessary,theLinkStateIDcanalsohave
oneormoreofthenetwork'shostbitsset;seeAppendix
Efordetails)andmetricequaltotheroutingtable
cost.
oTheoneremainingcaseisanintraarearoutetoa
network.Thismeansthatthenetworkiscontainedin
oneoftherouter'sdirectlyattachedareas.In
general,thisinformationmustbecondensedbefore
appearinginsummaryLSAs.Rememberthatanareahasa
configuredlistofaddressranges,eachrangeconsisting
ofan[address,mask]pairandastatusindicationof
eitherAdvertiseorDoNotAdvertise.Atmostasingle
Type3summaryLSAisoriginatedforeachrange.When
therange'sstatusindicatesAdvertise,aType3
summaryLSAisgeneratedwithLinkStateIDequaltothe
range'saddress(ifnecessary,theLinkStateIDcan
alsohaveoneormoreoftherange's"host"bitsset;
seeAppendixEfordetails)andcostequaltothe
largestcostofanyofthecomponentnetworks.Whenthe
range'sstatusindicatesDoNotAdvertise,theType3
summaryLSAissuppressedandthecomponentnetworks
remainhiddenfromotherareas.
Bydefault,ifanetworkisnotcontainedinany
explicitlyconfiguredaddressrange,aType3summary
LSAisgeneratedwithLinkStateIDequaltothe
network'saddress(ifnecessary,theLinkStateIDcan
alsohaveoneormoreofthenetwork's"host"bitsset;
seeAppendixEfordetails)andmetricequaltothe
network'sroutingtablecost.
Ifanareaiscapableofcarryingtransittraffic(i.e.,
itsTransitCapabilityissettoTRUE),routing
informationconcerningbackbonenetworksshouldnotbe
condensedbeforebeingsummarizedintothearea.Nor
105/188
3/2/2015
shouldtheadvertisementofbackbonenetworksinto
transitareasbesuppressed.Inotherwords,the
backbone'sconfiguredrangesshouldbeignoredwhen
originatingsummaryLSAsintotransitareas.
IfarouteradvertisesasummaryLSAforadestinationwhich
thenbecomesunreachable,theroutermustthenflushtheLSA
fromtheroutingdomainbysettingitsagetoMaxAgeand
reflooding(seeSection14.1).Also,ifthedestinationis
stillreachable,yetcannolongerbeadvertisedaccording
totheaboveprocedure(e.g.,itisnowaninterarearoute,
whenitusedtobeanintraarearouteassociatedwithsome
nonbackbonearea;itwouldthusnolongerbeadvertisable
tothebackbone),theLSAshouldalsobeflushedfromthe
routingdomain.
12.4.3.1.OriginatingsummaryLSAsintostubareas
ThealgorithminSection12.4.3isoptionalwhenAreaA
isanOSPFstubarea.Areaborderroutersconnectingto
astubareacanoriginatesummaryLSAsintothearea
accordingtotheSection12.4.3'salgorithm,orcan
choosetooriginateonlyasubsetofthesummaryLSAs,
possiblyunderconfigurationcontrol.ThefewerLSAs
originated,thesmallerthestubarea'slinkstate
database,furtherreducingthedemandsonitsrouters'
resources.However,omittingLSAsmayalsoleadtosub
optimalinterarearouting,althoughroutingwill
continuetofunction.
AsspecifiedinSection12.4.3,Type4summaryLSAs
(ASBRsummaryLSAs)areneveroriginatedintostub
areas.
Inastubarea,insteadofimportingexternalroutes
eachareaborderrouteroriginatesa"defaultsummary
LSA"intothearea.TheLinkStateIDforthedefault
summaryLSAissettoDefaultDestination,andthemetric
settothe(perarea)configurableparameter
StubDefaultCost.NotethatStubDefaultCostneednotbe
configuredidenticallyinallofthestubarea'sarea
borderrouters.
12.4.3.2.ExamplesofsummaryLSAs
ConsideragaintheareaconfigurationinFigure6.
RoutersRT3,RT4,RT7,RT10andRT11areallareaborder
routers,andthereforeareoriginatingsummaryLSAs.
ConsiderinparticularRouterRT4.Itsroutingtable
wascalculatedastheexampleinSection11.3.RT4
originatessummaryLSAsintoboththebackboneandArea
1.Intothebackbone,RouterRT4originatesseparate
LSAsforeachofthenetworksN1N4.IntoArea1,
RouterRT4originatesseparateLSAsfornetworksN6N8
andtheASboundaryroutersRT5,RT7.Italsocondenses
106/188
3/2/2015
hostroutesIaandIbintoasinglesummaryLSA.
Finally,theroutestonetworksN9,N10,N11andHostH1
areadvertisedbyasinglesummaryLSA.This
condensationwasoriginallyperformedbytherouter
RT11.
TheseLSAsareillustratedgraphicallyinFigures7and
8.TwoofthesummaryLSAsoriginatedbyRouterRT4
follow.TheactualIPaddressesforthenetworksand
routersinquestionhavebeenassignedinFigure15.
;SummaryLSAforNetworkN1,
;originatedbyRouterRT4intothebackbone
Options=(Ebit);
LStype=3;Type3summaryLSA
LinkStateID=192.1.2.0;N1'sIPnetworknumber
AdvertisingRouter=192.1.1.4;RT4'sID
metric=4
;SummaryLSAforASboundaryrouterRT7
;originatedbyRouterRT4intoArea1
Options=(Ebit);
LStype=4;Type4summaryLSA
LinkStateID=RouterRT7'sID
AdvertisingRouter=192.1.1.4;RT4'sID
metric=14
12.4.4.ASexternalLSAs
ASexternalLSAsdescriberoutestodestinationsexternalto
theAutonomousSystem.MostASexternalLSAsdescribe
routestospecificexternaldestinations;inthesecasesthe
LSA'sLinkStateIDissettothedestinationnetwork'sIP
address(ifnecessary,theLinkStateIDcanalsohaveone
ormoreofthenetwork's"host"bitsset;seeAppendixEfor
details).However,adefaultroutefortheAutonomous
SystemcanbedescribedinanASexternalLSAbysettingthe
LSA'sLinkStateIDtoDefaultDestination(0.0.0.0).AS
externalLSAsareoriginatedbyASboundaryrouters.AnAS
boundaryrouteroriginatesasingleASexternalLSAforeach
externalroutethatithaslearned,eitherthroughanother
routingprotocol(suchasBGP),orthroughconfiguration
information.
107/188
3/2/2015
ASexternalLSAsaretheonlytypeofLSAsthatareflooded
throughouttheentireAutonomousSystem;allothertypesof
LSAsarespecifictoasinglearea.However,ASexternal
LSAsarenotfloodedinto/throughoutstubareas(seeSection
3.6).Thisenablesareductioninlinkstatedatabasesize
forroutersinternaltostubareas.
Themetricthatisadvertisedforanexternalroutecanbe
oneoftwotypes.Type1metricsarecomparabletothelink
statemetric.Type2metricsareassumedtobelargerthan
thecostofanyintraASpath.
IfarouteradvertisesanASexternalLSAforadestination
whichthenbecomesunreachable,theroutermustthenflush
theLSAfromtheroutingdomainbysettingitsagetoMaxAge
andreflooding(seeSection14.1).
12.4.4.1.ExamplesofASexternalLSAs
ConsideronceagaintheASpicturedinFigure6.There
aretwoASboundaryrouters:RT5andRT7.RouterRT5
originatesthreeASexternalLSAs,fornetworksN12N14.
RouterRT7originatestwoASexternalLSAs,fornetworks
N12andN15.AssumethatRT7haslearneditsrouteto
N12viaBGP,andthatitwishestoadvertiseaType2
metrictotheAS.RT7wouldthenoriginatethe
followingLSAforN12:
;ASexternalLSAforNetworkN12,
;originatedbyRouterRT7
Options=(Ebit);
LStype=5;ASexternalLSA
LinkStateID=N12'sIPnetworknumber
AdvertisingRouter=RouterRT7'sID
bitE=1;Type2metric
metric=2
Forwardingaddress=0.0.0.0
Intheaboveexample,theforwardingaddressfield
hasbeensetto0.0.0.0,indicatingthatpacketsfor
theexternaldestinationshouldbeforwardedtothe
advertisingOSPFrouter(RT7).Thisisnotalways
desirable.ConsidertheexamplepicturedinFigure
16.TherearethreeOSPFrouters(RTA,RTBandRTC)
connectedtoacommonnetwork.Onlyoneofthese
routers,RTA,isexchangingBGPinformationwiththe
nonOSPFrouterRTX.RTAmustthenoriginateAS
externalLSAsforthosedestinationsithaslearned
fromRTX.ByusingtheASexternalLSA'sforwarding
addressfield,RTAcanspecifythatpacketsfor
thesedestinationsbeforwardeddirectlytoRTX.
Withoutthisfeature,RoutersRTBandRTCwouldtake
anextrahoptogettothesedestinations.
108/188
3/2/2015
Notethatwhentheforwardingaddressfieldisnon
zero,itshouldpointtoarouterbelongingto
anotherAutonomousSystem.
Aforwardingaddresscanalsobespecifiedforthe
defaultroute.Forexample,infigure16RTAmay
wanttospecifythatallexternallydestinedpackets
shouldbydefaultbeforwardedtoitsBGPpeerRTX.
TheresultingASexternalLSAispicturedbelow.
NotethattheLinkStateIDissetto
DefaultDestination.
;Defaultroute,originatedbyRouterRTA
;PacketsforwardedthroughRTX
Options=(Ebit);
LStype=5;ASexternalLSA
LinkStateID=DefaultDestination;defaultroute
AdvertisingRouter=RouterRTA'sID
bitE=1;Type2metric
metric=1
Forwardingaddress=RTX'sIPaddress
Infigure16,supposeinsteadthatbothRTAandRTB
exchangeBGPinformationwithRTX.Inthiscase,
RTAandRTBwouldoriginatethesamesetofAS
externalLSAs.TheseLSAs,iftheyspecifythesame
metric,wouldbefunctionallyequivalentsincethey
wouldspecifythesamedestinationandforwarding
address(RTX).Thisleadstoaclearduplicationof
effort.IfonlyoneofRTAorRTBoriginatedthe
setofASexternalLSAs,theroutingwouldremain
thesame,andthesizeofthelinkstatedatabase
woulddecrease.However,itmustbeunambiguously
definedastowhichrouteroriginatestheLSAs
(otherwiseneithermay,ortheidentityofthe
originatormayoscillate).Thefollowingruleis
therebyestablished:iftworouters,bothreachable
fromoneanother,originatefunctionallyequivalent
ASexternalLSAs(i.e.,samedestination,costand
nonzeroforwardingaddress),thentheLSA
originatedbytherouterhavingthehighestOSPF
RouterIDisused.TherouterhavingthelowerOSPF
RouterIDcanthenflushitsLSA.FlushinganLSA
isdiscussedinSection14.1.
+
|
++.....|.BGP
|RTA||.....++
++||RTX|
|++
++|
|RTB||
109/188
3/2/2015
++|
|
++|
|RTC||
++|
|
+
Figure16:Forwardingaddressexample
13.TheFloodingProcedure
LinkStateUpdatepacketsprovidethemechanismforfloodingLSAs.
ALinkStateUpdatepacketmaycontainseveraldistinctLSAs,and
floodseachLSAonehopfurtherfromitspointoforigination.To
makethefloodingprocedurereliable,eachLSAmustbeacknowledged
separately.AcknowledgmentsaretransmittedinLinkState
Acknowledgmentpackets.Manyseparateacknowledgmentscanalsobe
groupedtogetherintoasinglepacket.
ThefloodingprocedurestartswhenaLinkStateUpdatepackethas
beenreceived.Manyconsistencycheckshavebeenmadeonthe
receivedpacketbeforebeinghandedtothefloodingprocedure(see
Section8.2).Inparticular,theLinkStateUpdatepackethasbeen
associatedwithaparticularneighbor,andaparticulararea.If
theneighborisinalesserstatethanExchange,thepacketshould
bedroppedwithoutfurtherprocessing.
AlltypesofLSAs,otherthanASexternalLSAs,areassociatedwith
aspecificarea.However,LSAsdonotcontainanareafield.An
LSA'sareamustbededucedfromtheLinkStateUpdatepacketheader.
ForeachLSAcontainedinaLinkStateUpdatepacket,thefollowing
stepsaretaken:
(1)ValidatetheLSA'sLSchecksum.Ifthechecksumturnsouttobe
invalid,discardtheLSAandgetthenextonefromtheLink
StateUpdatepacket.
(2)ExaminetheLSA'sLStype.IftheLStypeisunknown,discard
theLSAandgetthenextonefromtheLinkStateUpdatePacket.
ThisspecificationdefinesLStypes15(seeSection4.3).
(3)ElseifthisisanASexternalLSA(LStype=5),andthearea
hasbeenconfiguredasastubarea,discardtheLSAandgetthe
nextonefromtheLinkStateUpdatePacket.ASexternalLSAs
arenotfloodedinto/throughoutstubareas(seeSection3.6).
(4)ElseiftheLSA'sLSageisequaltoMaxAge,andthereis
currentlynoinstanceoftheLSAintherouter'slinkstate
database,andnoneofrouter'sneighborsareinstatesExchange
110/188
3/2/2015
orLoading,thentakethefollowingactions:a)Acknowledgethe
receiptoftheLSAbysendingaLinkStateAcknowledgmentpacket
backtothesendingneighbor(seeSection13.5),andb)Discard
theLSAandexaminethenextLSA(ifany)listedintheLink
StateUpdatepacket.
(5)Otherwise,findtheinstanceofthisLSAthatiscurrently
containedintherouter'slinkstatedatabase.Ifthereisno
databasecopy,orthereceivedLSAismorerecentthanthe
databasecopy(seeSection13.1belowforthedeterminationof
whichLSAismorerecent)thefollowingstepsmustbeperformed:
(a)Ifthereisalreadyadatabasecopy,andifthedatabase
copywasreceivedviafloodingandinstalledlessthan
MinLSArrivalsecondsago,discardthenewLSA(without
acknowledgingit)andexaminethenextLSA(ifany)listed
intheLinkStateUpdatepacket.
(b)OtherwiseimmediatelyfloodthenewLSAoutsomesubsetof
therouter'sinterfaces(seeSection13.3).Insomecases
(e.g.,thestateofthereceivinginterfaceisDRandthe
LSAwasreceivedfromarouterotherthantheBackupDR)the
LSAwillbefloodedbackoutthereceivinginterface.This
occurrenceshouldbenotedforlaterusebythe
acknowledgmentprocess(Section13.5).
(c)Removethecurrentdatabasecopyfromallneighbors'Link
stateretransmissionlists.
(d)InstallthenewLSAinthelinkstatedatabase(replacing
thecurrentdatabasecopy).Thismaycausetherouting
tablecalculationtobescheduled.Inaddition,timestamp
thenewLSAwiththecurrenttime(i.e.,thetimeitwas
received).Thefloodingprocedurecannotoverwritethe
newlyinstalledLSAuntilMinLSArrivalsecondshaveelapsed.
TheLSAinstallationprocessisdiscussedfurtherinSection
13.2.
(e)PossiblyacknowledgethereceiptoftheLSAbysendinga
LinkStateAcknowledgmentpacketbackoutthereceiving
interface.ThisisexplainedbelowinSection13.5.
(f)IfthisnewLSAindicatesthatitwasoriginatedbythe
receivingrouteritself(i.e.,isconsideredaself
originatedLSA),theroutermusttakespecialaction,either
updatingtheLSAorinsomecasesflushingitfromthe
routingdomain.Foradescriptionofhowselforiginated
LSAsaredetectedandsubsequentlyhandled,seeSection
13.4.
(6)Else,ifthereisaninstanceoftheLSAonthesending
neighbor'sLinkstaterequestlist,anerrorhasoccurredinthe
111/188
3/2/2015
DatabaseExchangeprocess.Inthiscase,restarttheDatabase
ExchangeprocessbygeneratingtheneighboreventBadLSReqfor
thesendingneighborandstopprocessingtheLinkStateUpdate
packet.
(7)Else,ifthereceivedLSAisthesameinstanceasthedatabase
copy(i.e.,neitheroneismorerecent)thefollowingtwosteps
shouldbeperformed:
(a)IftheLSAislistedintheLinkstateretransmissionlist
forthereceivingadjacency,therouteritselfisexpecting
anacknowledgmentforthisLSA.Theroutershouldtreatthe
receivedLSAasanacknowledgmentbyremovingtheLSAfrom
theLinkstateretransmissionlist.Thisistermedan
"impliedacknowledgment".Itsoccurrenceshouldbenoted
forlaterusebytheacknowledgmentprocess(Section13.5).
(b)PossiblyacknowledgethereceiptoftheLSAbysendinga
LinkStateAcknowledgmentpacketbackoutthereceiving
interface.ThisisexplainedbelowinSection13.5.
(8)Else,thedatabasecopyismorerecent.Ifthedatabasecopy
hasLSageequaltoMaxAgeandLSsequencenumberequalto
MaxSequenceNumber,simplydiscardthereceivedLSAwithout
acknowledgingit.(Inthiscase,theLSA'sLSsequencenumberis
wrapping,andtheMaxSequenceNumberLSAmustbecompletely
flushedbeforeanynewLSAinstancecanbeintroduced).
Otherwise,aslongasthedatabasecopyhasnotbeensentina
LinkStateUpdatewithinthelastMinLSArrivalseconds,sendthe
databasecopybacktothesendingneighbor,encapsulatedwithin
aLinkStateUpdatePacket.TheLinkStateUpdatePacketshould
besentdirectlytotheneighbor.Insodoing,donotputthe
databasecopyoftheLSAontheneighbor'slinkstate
retransmissionlist,anddonotacknowledgethereceived(less
recent)LSAinstance.
13.1.DeterminingwhichLSAisnewer
WhenarouterencounterstwoinstancesofanLSA,itmust
determinewhichismorerecent.Thisoccurredabovewhen
comparingareceivedLSAtoitsdatabasecopy.Thiscomparison
mustalsobedoneduringtheDatabaseExchangeprocedurewhich
occursduringadjacencybringup.
AnLSAisidentifiedbyitsLStype,LinkStateIDand
AdvertisingRouter.FortwoinstancesofthesameLSA,theLS
sequencenumber,LSage,andLSchecksumfieldsareusedto
determinewhichinstanceismorerecent:
oTheLSAhavingthenewerLSsequencenumberismorerecent.
SeeSection12.1.6foranexplanationoftheLSsequence
numberspace.IfbothinstanceshavethesameLSsequence
number,then:
oIfthetwoinstanceshavedifferentLSchecksums,thenthe
112/188
3/2/2015
instancehavingthelargerLSchecksum(whenconsideredasa
16bitunsignedinteger)isconsideredmorerecent.
oElse,ifonlyoneoftheinstanceshasitsLSagefieldset
toMaxAge,theinstanceofageMaxAgeisconsideredtobe
morerecent.
oElse,iftheLSagefieldsofthetwoinstancesdifferby
morethanMaxAgeDiff,theinstancehavingthesmaller
(younger)LSageisconsideredtobemorerecent.
oElse,thetwoinstancesareconsideredtobeidentical.
13.2.InstallingLSAsinthedatabase
InstallinganewLSAinthedatabase,eitherastheresultof
floodingoranewlyselforiginatedLSA,maycausetheOSPF
routingtablestructuretoberecalculated.Thecontentsofthe
newLSAshouldbecomparedtotheoldinstance,ifpresent.If
thereisnodifference,thereisnoneedtorecalculatethe
routingtable.WhencomparinganLSAtoitspreviousinstance,
thefollowingareallconsideredtobedifferencesincontents:
oTheLSA'sOptionsfieldhaschanged.
oOneoftheLSAinstanceshasLSagesettoMaxAge,and
theotherdoesnot.
oThelengthfieldintheLSAheaderhaschanged.
oThebodyoftheLSA(i.e.,anythingoutsidethe20byte
LSAheader)haschanged.Notethatthisexcludeschanges
inLSSequenceNumberandLSChecksum.
Ifthecontentsaredifferent,thefollowingpiecesofthe
routingtablemustberecalculated,dependingonthenewLSA's
LStypefield:
RouterLSAsandnetworkLSAs
Theentireroutingtablemustberecalculated,startingwith
theshortestpathcalculationsforeacharea(notjustthe
areawhoselinkstatedatabasehaschanged).Thereason
thattheshortestpathcalculationcannotberestrictedto
thesinglechangedareahastodowiththefactthatAS
boundaryroutersmaybelongtomultipleareas.Achangein
theareacurrentlyprovidingthebestroutemayforcethe
routertouseanintraarearouteprovidedbyadifferent
area.[19]
SummaryLSAs
Thebestroutetothedestinationdescribedbythesummary
LSAmustberecalculated(seeSection16.5).Ifthis
113/188
3/2/2015
destinationisanASboundaryrouter,itmayalsobe
necessarytoreexaminealltheASexternalLSAs.
ASexternalLSAs
ThebestroutetothedestinationdescribedbytheAS
externalLSAmustberecalculated(seeSection16.6).
Also,anyoldinstanceoftheLSAmustberemovedfromthe
databasewhenthenewLSAisinstalled.Thisoldinstancemust
alsoberemovedfromallneighbors'Linkstateretransmission
lists(seeSection10).
13.3.Nextstepinthefloodingprocedure
Whenanew(andmorerecent)LSAhasbeenreceived,itmustbe
floodedoutsomesetoftherouter'sinterfaces.Thissection
describesthesecondpartoffloodingprocedure(thefirstpart
beingtheprocessingthatoccurredinSection13),namely,
selectingtheoutgoinginterfacesandaddingtheLSAtothe
appropriateneighbors'Linkstateretransmissionlists.Also
includedinthispartofthefloodingprocedureisthe
maintenanceoftheneighbors'Linkstaterequestlists.
ThissectionisequallyapplicabletothefloodingofanLSA
thattherouteritselfhasjustoriginated(seeSection12.4).
FortheseLSAs,thissectionprovidestheentiretyofthe
floodingprocedure(i.e.,theprocessingofSection13isnot
performed,since,forexample,theLSAhasnotbeenreceived
fromaneighborandthereforedoesnotneedtobeacknowledged).
DependingupontheLSA'sLStype,theLSAcanbefloodedout
onlycertaininterfaces.Theseinterfaces,definedbythe
following,arecalledtheeligibleinterfaces:
ASexternalLSAs(LSType=5)
ASexternalLSAsarefloodedthroughouttheentireAS,with
theexceptionofstubareas(seeSection3.6).Theeligible
interfacesarealltherouter'sinterfaces,excluding
virtuallinksandthoseinterfacesattachingtostubareas.
AllotherLStypes
Allothertypesarespecifictoasinglearea(AreaA).The
eligibleinterfacesareallthoseinterfacesattachingto
theAreaA.IfAreaAisthebackbone,thisincludesall
thevirtuallinks.
114/188
3/2/2015
Linkstatedatabasesmustremainsynchronizedoverall
adjacenciesassociatedwiththeaboveeligibleinterfaces.This
isaccomplishedbyexecutingthefollowingstepsoneach
eligibleinterface.Itshouldbenotedthatthisproceduremay
decidenottofloodanLSAoutaparticularinterface,ifthere
isahighprobabilitythattheattachedneighborshavealready
receivedtheLSA.However,inthesecasestheflooding
proceduremustbeabsolutelysurethattheneighborseventually
doreceivetheLSA,sotheLSAisstilladdedtoeach
adjacency'sLinkstateretransmissionlist.Foreacheligible
interface:
(1)Eachoftheneighborsattachedtothisinterfaceare
examined,todeterminewhethertheymustreceivethenew
LSA.Thefollowingstepsareexecutedforeachneighbor:
(a)IftheneighborisinalesserstatethanExchange,it
doesnotparticipateinflooding,andthenextneighbor
shouldbeexamined.
(b)Else,iftheadjacencyisnotyetfull(neighborstate
isExchangeorLoading),examinetheLinkstaterequest
listassociatedwiththisadjacency.Ifthereisan
instanceofthenewLSAonthelist,itindicatesthat
theneighboringrouterhasaninstanceoftheLSA
already.ComparethenewLSAtotheneighbor'scopy:
oIfthenewLSAislessrecent,thenexaminethenext
neighbor.
oIfthetwocopiesarethesameinstance,thendelete
theLSAfromtheLinkstaterequestlist,and
examinethenextneighbor.[20]
oElse,thenewLSAismorerecent.DeletetheLSA
fromtheLinkstaterequestlist.
(c)IfthenewLSAwasreceivedfromthisneighbor,examine
thenextneighbor.
(d)Atthispointwearenotpositivethattheneighborhas
anuptodateinstanceofthisnewLSA.AddthenewLSA
totheLinkstateretransmissionlistfortheadjacency.
Thisensuresthatthefloodingprocedureisreliable;
theLSAwillberetransmittedatintervalsuntilan
acknowledgmentisseenfromtheneighbor.
(2)TheroutermustnowdecidewhethertofloodthenewLSAout
thisinterface.Ifinthepreviousstep,theLSAwasNOT
addedtoanyoftheLinkstateretransmissionlists,there
isnoneedtofloodtheLSAouttheinterfaceandthenext
interfaceshouldbeexamined.
(3)IfthenewLSAwasreceivedonthisinterface,anditwas
receivedfromeithertheDesignatedRouterortheBackup
DesignatedRouter,chancesarethatalltheneighborshave
receivedtheLSAalready.Therefore,examinethenext
115/188
3/2/2015
interface.
(4)IfthenewLSAwasreceivedonthisinterface,andthe
interfacestateisBackup(i.e.,therouteritselfisthe
BackupDesignatedRouter),examinethenextinterface.The
DesignatedRouterwilldothefloodingonthisinterface.
However,iftheDesignatedRouterfailstherouter(i.e.,
theBackupDesignatedRouter)willendupretransmittingthe
updates.
(5)Ifthisstepisreached,theLSAmustbefloodedoutthe
interface.SendaLinkStateUpdatepacket(includingthe
newLSAascontents)outtheinterface.TheLSA'sLSage
mustbeincrementedbyInfTransDelay(whichmustbe>0)
whenitiscopiedintotheoutgoingLinkStateUpdatepacket
(untiltheLSagefieldreachesthemaximumvalueof
MaxAge).
Onbroadcastnetworks,theLinkStateUpdatepacketsare
multicast.ThedestinationIPaddressspecifiedforthe
LinkStateUpdatePacketdependsonthestateofthe
interface.IftheinterfacestateisDRorBackup,the
addressAllSPFRoutersshouldbeused.Otherwise,the
addressAllDRoutersshouldbeused.
Onnonbroadcastnetworks,separateLinkStateUpdate
packetsmustbesent,asunicasts,toeachadjacentneighbor
(i.e.,thoseinstateExchangeorgreater).Thedestination
IPaddressesforthesepacketsaretheneighbors'IP
addresses.
13.4.ReceivingselforiginatedLSAs
Itisacommonoccurrenceforaroutertoreceiveself
originatedLSAsviathefloodingprocedure.Aselforiginated
LSAisdetectedwheneither1)theLSA'sAdvertisingRouteris
equaltotherouter'sownRouterIDor2)theLSAisanetwork
LSAanditsLinkStateIDisequaltooneoftherouter'sownIP
interfaceaddresses.
However,ifthereceivedselforiginatedLSAisnewerthanthe
lastinstancethattherouteractuallyoriginated,therouter
musttakespecialaction.ThereceptionofsuchanLSA
indicatesthatthereareLSAsintheroutingdomainthatwere
originatedbytherouterbeforethelasttimeitwasrestarted.
Inmostcases,theroutermustthenadvancetheLSA'sLS
sequencenumberonepastthereceivedLSsequencenumber,and
originateanewinstanceoftheLSA.
Itmaybethecasetherouternolongerwishestooriginatethe
receivedLSA.Possibleexamplesinclude:1)theLSAisa
summaryLSAorASexternalLSAandtherouternolongerhasan
(advertisable)routetothedestination,2)theLSAisa
networkLSAbuttherouterisnolongerDesignatedRouterfor
thenetworkor3)theLSAisanetworkLSAwhoseLinkStateID
isoneoftherouter'sownIPinterfaceaddressesbutwhose
116/188
3/2/2015
AdvertisingRouterisnotequaltotherouter'sownRouterID
(thislattercaseshouldberare,anditindicatesthatthe
router'sRouterIDhaschangedsinceoriginatingtheLSA).In
allthesecases,insteadofupdatingtheLSA,theLSAshouldbe
flushedfromtheroutingdomainbyincrementingthereceived
LSA'sLSagetoMaxAgeandreflooding(seeSection14.1).
13.5.SendingLinkStateAcknowledgmentpackets
EachnewlyreceivedLSAmustbeacknowledged.Thisisusually
donebysendingLinkStateAcknowledgmentpackets.However,
acknowledgmentscanalsobeaccomplishedimplicitlybysending
LinkStateUpdatepackets(seestep7aofSection13).
ManyacknowledgmentsmaybegroupedtogetherintoasingleLink
StateAcknowledgmentpacket.Suchapacketissentbackoutthe
interfacewhichreceivedtheLSAs.Thepacketcanbesentin
oneoftwoways:delayedandsentonanintervaltimer,orsent
directlytoaparticularneighbor.Theparticular
acknowledgmentstrategyuseddependsonthecircumstances
surroundingthereceiptoftheLSA.
Sendingdelayedacknowledgmentsaccomplishesseveralthings:1)
itfacilitatesthepackagingofmultipleacknowledgmentsina
singleLinkStateAcknowledgmentpacket,2)itenablesasingle
LinkStateAcknowledgmentpackettoindicateacknowledgmentsto
severalneighborsatonce(throughmulticasting)and3)it
randomizestheLinkStateAcknowledgmentpacketssentbythe
variousroutersattachedtoacommonnetwork.Thefixed
intervalbetweenarouter'sdelayedtransmissionsmustbeshort
(lessthanRxmtInterval)orneedlessretransmissionswillensue.
Directacknowledgmentsaresentdirectlytoaparticular
neighborinresponsetothereceiptofduplicateLSAs.Direct
acknowledgmentsaresentimmediatelywhentheduplicateis
received.Onmultiaccessnetworks,theseacknowledgmentsare
sentdirectlytotheneighbor'sIPaddress.
ThepreciseprocedureforsendingLinkStateAcknowledgment
packetsisdescribedinTable19.Thecircumstancessurrounding
thereceiptoftheLSAarelistedintheleftcolumn.The
acknowledgmentactionthentakenislistedinoneofthetwo
rightcolumns.Thisactiondependsonthestateofthe
concernedinterface;interfacesinstateBackupbehave
differentlyfrominterfacesinallotherstates.Delayed
acknowledgmentsmustbedeliveredtoalladjacentrouters
associatedwiththeinterface.Onbroadcastnetworks,thisis
accomplishedbysendingthedelayedLinkStateAcknowledgment
packetsasmulticasts.TheDestinationIPaddressuseddepends
117/188
3/2/2015
Actiontakeninstate
CircumstancesBackupAllotherstates
_________________________________________________________________
LSAhasNoacknowledgmentNoacknowledgment
beenfloodedbacksent.sent.
outreceivingin
terface(seeSec
tion13,step5b).
_________________________________________________________________
LSAisDelayedacknowledgDelayedack
morerecentthanmentsentifadvernowledgmentsent.
databasecopy,buttisementreceived
wasnotfloodedfromDesignated
backoutreceivingRouter,otherwise
interfacedonothing
_________________________________________________________________
LSAisaDelayedacknowledgNoacknowledgment
duplicate,andwasmentsentifadversent.
treatedasanimtisementreceived
pliedacknowledgfromDesignated
ment(seeSectionRouter,otherwise
13,step7a).donothing
_________________________________________________________________
LSAisaDirectacknowledgDirectacknowledg
duplicate,andwasmentsent.mentsent.
nottreatedasan
impliedack
nowledgment.
_________________________________________________________________
LSA'sLSDirectacknowledgDirectacknowledg
ageisequaltomentsent.mentsent.
MaxAge,andthereis
nocurrentinstance
oftheLSA
inthelinkstate
database,andnone
ofrouter'sneighbors
areinstatesExchange
orLoading(see
Section13,step4).
Table19:Sendinglinkstateacknowledgements.
onthestateoftheinterface.IftheinterfacestateisDRor
Backup,thedestinationAllSPFRoutersisused.Inallother
states,thedestinationAllDRoutersisused.Onnonbroadcast
networks,delayedLinkStateAcknowledgmentpacketsmustbe
unicastseparatelyovereachadjacency(i.e.,neighborwhose
stateis>=Exchange).
118/188
3/2/2015
Thereasoningbehindsendingtheabovepacketsasmulticastsis
bestexplainedbyanexample.Considerthenetwork
configurationdepictedinFigure15.SupposeRT4hasbeen
electedasDesignatedRouter,andRT3asBackupDesignated
RouterforthenetworkN3.WhenRouterRT4floodsanewLSAto
NetworkN3,itisreceivedbyroutersRT1,RT2,andRT3.These
routerswillnotfloodtheLSAbackontonetN3,buttheystill
mustensurethattheirlinkstatedatabasesremainsynchronized
withtheiradjacentneighbors.SoRT1,RT2,andRT4arewaiting
toseeanacknowledgmentfromRT3.Likewise,RT4andRT3are
bothwaitingtoseeacknowledgmentsfromRT1andRT2.Thisis
bestachievedbysendingtheacknowledgmentsasmulticasts.
ThereasonthattheacknowledgmentlogicforBackupDRsis
slightlydifferentisbecausetheyperformdifferentlyduring
thefloodingofLSAs(seeSection13.3,step4).
13.6.RetransmittingLSAs
LSAsfloodedoutanadjacencyareplacedontheadjacency'sLink
stateretransmissionlist.Inordertoensurethatfloodingis
reliable,theseLSAsareretransmitteduntiltheyare
acknowledged.Thelengthoftimebetweenretransmissionsisa
configurableperinterfacevalue,RxmtInterval.Ifthisisset
toolowforaninterface,needlessretransmissionswillensue.
Ifthevalueissettoohigh,thespeedoftheflooding,inthe
faceoflostpackets,maybeaffected.
SeveralretransmittedLSAsmayfitintoasingleLinkState
Updatepacket.WhenLSAsaretoberetransmitted,onlythe
numberfittinginasingleLinkStateUpdatepacketshouldbe
sent.Anotherpacketofretransmissionscanbesentwhenever
someoftheLSAsareacknowledged,oronthenextfiringofthe
retransmissiontimer.
LinkStateUpdatePacketscarryingretransmissionsarealways
sentdirectlytotheneighbor.Onmultiaccessnetworks,this
meansthatretransmissionsaresentdirectlytotheneighbor's
IPaddress.EachLSA'sLSagemustbeincrementedby
InfTransDelay(whichmustbe>0)whenitiscopiedintothe
outgoingLinkStateUpdatepacket(untiltheLSagefield
reachesthemaximumvalueofMaxAge).
Ifanadjacentroutergoesdown,retransmissionsmayoccuruntil
theadjacencyisdestroyedbyOSPF'sHelloProtocol.Whenthe
adjacencyisdestroyed,theLinkstateretransmissionlistis
cleared.
13.7.Receivinglinkstateacknowledgments
ManyconsistencycheckshavebeenmadeonareceivedLinkState
Acknowledgmentpacketbeforeitishandedtotheflooding
procedure.Inparticular,ithasbeenassociatedwitha
119/188
3/2/2015
particularneighbor.Ifthisneighborisinalesserstatethan
Exchange,theLinkStateAcknowledgmentpacketisdiscarded.
Otherwise,foreachacknowledgmentintheLinkState
Acknowledgmentpacket,thefollowingstepsareperformed:
oDoestheLSAacknowledgedhaveaninstanceontheLinkstate
retransmissionlistfortheneighbor?Ifnot,examinethe
nextacknowledgment.Otherwise:
oIftheacknowledgmentisforthesameinstancethatis
containedonthelist,removetheitemfromthelistand
examinethenextacknowledgment.Otherwise:
oLogthequestionableacknowledgment,andexaminethenext
one.
14.AgingTheLinkStateDatabase
EachLSAhasanLSagefield.TheLSageisexpressedinseconds.
AnLSA'sLSagefieldisincrementedwhileitiscontainedina
router'sdatabase.Also,whencopiedintoaLinkStateUpdate
Packetforfloodingoutaparticularinterface,theLSA'sLSageis
incrementedbyInfTransDelay.
AnLSA'sLSageisneverincrementedpastthevalueMaxAge.LSAs
havingageMaxAgearenotusedintheroutingtablecalculation.As
arouteragesitslinkstatedatabase,anLSA'sLSagemayreach
MaxAge.[21]Atthistime,theroutermustattempttoflushtheLSA
fromtheroutingdomain.Thisisdonesimplybyrefloodingthe
MaxAgeLSAjustasifitwasanewlyoriginatedLSA(seeSection
13.3).
WhencreatingaDatabasesummarylistforanewlyformingadjacency,
anyMaxAgeLSAspresentinthelinkstatedatabaseareaddedtothe
neighbor'sLinkstateretransmissionlistinsteadoftheneighbor's
Databasesummarylist.SeeSection10.3formoredetails.
AMaxAgeLSAmustberemovedimmediatelyfromtherouter'slink
statedatabaseassoonasbotha)itisnolongercontainedonany
neighborLinkstateretransmissionlistsandb)noneoftherouter's
neighborsareinstatesExchangeorLoading.
When,intheprocessofagingthelinkstatedatabase,anLSA'sLS
agehitsamultipleofCheckAge,itsLSchecksumshouldbeverified.
IftheLSchecksumisincorrect,aprogramormemoryerrorhasbeen
detected,andattheveryleasttherouteritselfshouldbe
restarted.
120/188
3/2/2015
14.1.PrematureagingofLSAs
AnLSAcanbeflushedfromtheroutingdomainbysettingitsLS
agetoMaxAge,whileleavingitsLSsequencenumberalone,and
thenrefloodingtheLSA.Thisprocedurefollowsthesamecourse
asflushinganLSAwhoseLSagehasnaturallyreachedthevalue
MaxAge(seeSection14).Inparticular,theMaxAgeLSAis
removedfromtherouter'slinkstatedatabaseassoonasa)it
isnolongercontainedonanyneighborLinkstateretransmission
listsandb)noneoftherouter'sneighborsareinstates
ExchangeorLoading.WecallthesettingofanLSA'sLSageto
MaxAge"prematureaging".
Prematureagingisusedwhenitistimeforaselforiginated
LSA'ssequencenumberfieldtowrap.Atthispoint,thecurrent
LSAinstance(havingLSsequencenumberMaxSequenceNumber)must
beprematurelyagedandflushedfromtheroutingdomainbeforea
newinstancewithsequencenumberequaltoInitialSequenceNumber
canbeoriginated.SeeSection12.1.6formoreinformation.
Prematureagingcanalsobeusedwhen,forexample,oneofthe
router'spreviouslyadvertisedexternalroutesisnolonger
reachable.Inthiscircumstance,theroutercanflushitsAS
externalLSAfromtheroutingdomainviaprematureaging.This
procedureispreferabletothealternative,whichisto
originateanewLSAforthedestinationspecifyingametricof
LSInfinity.Prematureagingisalsobeusedwhenunexpectedly
receivingselforiginatedLSAsduringthefloodingprocedure
(seeSection13.4).
AroutermayonlyprematurelyageitsownselforiginatedLSAs.
TheroutermaynotprematurelyageLSAsthathavebeen
originatedbyotherrouters.AnLSAisconsideredself
originatedwheneither1)theLSA'sAdvertisingRouterisequal
totherouter'sownRouterIDor2)theLSAisanetworkLSAand
itsLinkStateIDisequaltooneoftherouter'sownIP
interfaceaddresses.
15.VirtualLinks
Thesinglebackbonearea(AreaID=0.0.0.0)cannotbedisconnected,
orsomeareasoftheAutonomousSystemwillbecomeunreachable.To
establish/maintainconnectivityofthebackbone,virtuallinkscan
beconfiguredthroughnonbackboneareas.Virtuallinksserveto
connectphysicallyseparatecomponentsofthebackbone.Thetwo
endpointsofavirtuallinkareareaborderrouters.Thevirtual
linkmustbeconfiguredinbothrouters.Theconfiguration
informationineachrouterconsistsoftheothervirtualendpoint
121/188
3/2/2015
(theotherareaborderrouter),andthenonbackboneareathetwo
routershaveincommon(calledtheTransitarea).Virtuallinks
cannotbeconfiguredthroughstubareas(seeSection3.6).
Thevirtuallinkistreatedasifitwereanunnumberedpointto
pointnetworkbelongingtothebackboneandjoiningthetwoarea
borderrouters.Anattemptismadetoestablishanadjacencyover
thevirtuallink.Whenthisadjacencyisestablished,thevirtual
linkwillbeincludedinbackbonerouterLSAs,andOSPFpackets
pertainingtothebackboneareawillflowovertheadjacency.Such
anadjacencyhasbeenreferredtointhisdocumentasa"virtual
adjacency".
Ineachendpointrouter,thecostandviabilityofthevirtuallink
isdiscoveredbyexaminingtheroutingtableentryfortheother
endpointrouter.(Theentry'sassociatedareamustbethe
configuredTransitarea).Thisiscalledthevirtuallink's
correspondingroutingtableentry.TheInterfaceUpeventoccursfor
avirtuallinkwhenitscorrespondingroutingtableentrybecomes
reachable.Conversely,theInterfaceDowneventoccurswhenits
routingtableentrybecomesunreachable.Inotherwords,the
virtuallink'sviabilityisdeterminedbytheexistenceofan
intraareapath,throughtheTransitarea,betweenthetwo
endpoints.Notethatavirtuallinkwhoseunderlyingpathhascost
greaterthanhexadecimal0xffff(themaximumsizeofaninterface
costinarouterLSA)shouldbeconsideredinoperational(i.e.,
treatedthesameasifthepathdidnotexist).
Theotherdetailsconcerningvirtuallinksareasfollows:
oASexternalLSAsareNEVERfloodedovervirtualadjacencies.
Thiswouldbeduplicationofeffort,sincethesameAS
externalLSAsarealreadyfloodedthroughoutthevirtuallink's
Transitarea.Forthissamereason,ASexternalLSAsarenot
summarizedovervirtualadjacenciesduringtheDatabaseExchange
process.
oThecostofavirtuallinkisNOTconfigured.Itisdefinedto
bethecostoftheintraareapathbetweenthetwodefiningarea
borderrouters.Thiscostappearsinthevirtuallink's
correspondingroutingtableentry.Whenthecostofavirtual
linkchanges,anewrouterLSAshouldbeoriginatedforthe
backbonearea.
oJustasthevirtuallink'scostandviabilityaredeterminedby
theroutingtablebuildprocess(throughconstructionofthe
routingtableentryfortheotherendpoint),soaretheIP
interfaceaddressforthevirtualinterfaceandthevirtual
neighbor'sIPaddress.TheseareusedwhensendingOSPF
protocolpacketsoverthevirtuallink.Notethatwhenone(or
both)ofthevirtuallinkendpointsconnecttotheTransitarea
viaanunnumberedpointtopointlink,itmaybeimpossibleto
calculateeitherthevirtualinterface'sIPaddressand/orthe
virtualneighbor'sIPaddress,therebycausingthevirtuallink
tofail.
oIneachendpoint'srouterLSAforthebackbone,thevirtuallink
122/188
3/2/2015
isrepresentedasaType4linkwhoseLinkIDissettothe
virtualneighbor'sOSPFRouterIDandwhoseLinkDataissetto
thevirtualinterface'sIPaddress.SeeSection12.4.1formore
information.
oAnonbackboneareacancarrytransitdatatraffic(i.e.,is
considereda"transitarea")ifandonlyifitservesasthe
Transitareaforoneormorefullyadjacentvirtuallinks(see
TransitCapabilityinSections6and16.1).Suchanarearequires
specialtreatmentwhensummarizingbackbonenetworksintoit
(seeSection12.4.3),andduringtheroutingcalculation(see
Section16.3).
oThetimebetweenlinkstateretransmissions,RxmtInterval,is
configuredforavirtuallink.Thisshouldbewelloverthe
expectedroundtripdelaybetweenthetworouters.Thismaybe
hardtoestimateforavirtuallink;itisbettertoerronthe
sideofmakingittoolarge.
16.Calculationoftheroutingtable
ThissectiondetailstheOSPFroutingtablecalculation.Usingits
attachedareas'linkstatedatabasesasinput,arouterrunsthe
followingalgorithm,buildingitsroutingtablestepbystep.At
eachstep,theroutermustaccessindividualpiecesofthelink
statedatabases(e.g.,arouterLSAoriginatedbyacertainrouter).
ThisaccessisperformedbythelookupfunctiondiscussedinSection
12.2.ThelookupprocessmayreturnanLSAwhoseLSageisequalto
MaxAge.SuchanLSAshouldnotbeusedintheroutingtable
calculation,andistreatedjustasifthelookupprocesshad
failed.
TheOSPFroutingtable'sorganizationisexplainedinSection11.
Twoexamplesoftheroutingtablebuildprocessarepresentedin
Sections11.2and11.3.Thisprocesscanbebrokenintothe
followingsteps:
(1)Thepresentroutingtableisinvalidated.Theroutingtableis
builtagainfromscratch.Theoldroutingtableissavedso
thatchangesinroutingtableentriescanbeidentified.
(2)Theintraarearoutesarecalculatedbybuildingtheshortest
pathtreeforeachattachedarea.Inparticular,allrouting
tableentrieswhoseDestinationTypeis"areaborderrouter"are
calculatedinthisstep.Thisstepisdescribedintwoparts.
Atfirstthetreeisconstructedbyonlyconsideringthoselinks
betweenroutersandtransitnetworks.Thenthestubnetworks
areincorporatedintothetree.Duringthearea'sshortestpath
treecalculation,thearea'sTransitCapabilityisalso
calculatedforlateruseinStep4.
(3)Theinterarearoutesarecalculated,throughexaminationof
summaryLSAs.Iftherouterisattachedtomultipleareas
(i.e.,itisanareaborderrouter),onlybackbonesummaryLSAs
areexamined.
123/188
3/2/2015
(4)Inareaborderroutersconnectingtooneormoretransitareas
(i.e,nonbackboneareaswhoseTransitCapabilityisfoundtobe
TRUE),thetransitareas'summaryLSAsareexaminedtosee
whetherbetterpathsexistusingthetransitareasthanwere
foundinSteps23above.
(5)Routestoexternaldestinationsarecalculated,through
examinationofASexternalLSAs.ThelocationsoftheAS
boundaryrouters(whichoriginatetheASexternalLSAs)have
beendeterminedinsteps24.
Steps25areexplainedinfurtherdetailbelow.
Changesmadetoroutingtableentriesasaresultofthese
calculationscancausetheOSPFprotocoltotakefurtheractions.
Forexample,achangetoanintraarearoutewillcauseanarea
borderroutertooriginatenewsummaryLSAs(seeSection12.4).See
Section16.7foracompletelistoftheOSPFprotocolactions
resultingfromroutingtablechanges.
16.1.Calculatingtheshortestpathtreeforanarea
Thiscalculationyieldsthesetofintraarearoutesassociated
withanarea(calledhereafterAreaA).Aroutercalculatesthe
shortestpathtreeusingitselfastheroot.[22]Theformation
oftheshortestpathtreeisdonehereintwostages.Inthe
firststage,onlylinksbetweenroutersandtransitnetworksare
considered.UsingtheDijkstraalgorithm,atreeisformedfrom
thissubsetofthelinkstatedatabase.Inthesecondstage,
leavesareaddedtothetreebyconsideringthelinkstostub
networks.
Theprocedurewillbeexplainedusingthegraphterminologythat
wasintroducedinSection2.Thearea'slinkstatedatabaseis
representedasadirectedgraph.Thegraph'sverticesare
routers,transitnetworksandstubnetworks.Thefirststageof
theprocedureconcernsonlythetransitvertices(routersand
transitnetworks)andtheirconnectinglinks.Throughoutthe
shortestpathcalculation,thefollowingdataisalsoassociated
witheachtransitvertex:
Vertex(node)ID
A32bitnumberwhichtogetherwiththevertextype(router
ornetwork)uniquelyidentifiesthevertex.Forrouter
verticestheVertexIDistherouter'sOSPFRouterID.For
networkvertices,itistheIPaddressofthenetwork's
124/188
3/2/2015
DesignatedRouter.
AnLSA
EachtransitvertexhasanassociatedLSA.Forrouter
vertices,thisisarouterLSA.Fortransitnetworks,this
isanetworkLSA(whichisactuallyoriginatedbythe
network'sDesignatedRouter).Inanycase,theLSA'sLink
StateIDisalwaysequaltotheaboveVertexID.
Listofnexthops
Thelistofnexthopsforthecurrentsetofshortestpaths
fromtheroottothisvertex.Therecanbemultiple
shortestpathsduetotheequalcostmultipathcapability.
Eachnexthopindicatestheoutgoingrouterinterfacetouse
whenforwardingtraffictothedestination.Onbroadcast,
PointtoMultiPointandNBMAnetworks,thenexthopalso
includestheIPaddressofthenextrouter(ifany)inthe
pathtowardsthedestination.
Distancefromroot
Thelinkstatecostofthecurrentsetofshortestpaths
fromtheroottothevertex.Thelinkstatecostofapath
iscalculatedasthesumofthecostsofthepath's
constituentlinks(asadvertisedinrouterLSAsand
networkLSAs).Onepathissaidtobe"shorter"than
anotherifithasasmallerlinkstatecost.
Thefirststageoftheprocedure(i.e.,theDijkstraalgorithm)
cannowbesummarizedasfollows.Ateachiterationofthe
algorithm,thereisalistofcandidatevertices.Pathsfrom
theroottotheseverticeshavebeenfound,butnotnecessarily
theshortestones.However,thepathstothecandidatevertex
thatisclosesttotherootareguaranteedtobeshortest;this
vertexisaddedtotheshortestpathtree,removedfromthe
candidatelist,anditsadjacentverticesareexaminedfor
possibleadditionto/modificationofthecandidatelist.The
algorithmtheniteratesagain.Itterminateswhenthecandidate
listbecomesempty.
Thefollowingstepsdescribethealgorithmindetail.Remember
thatwearecomputingtheshortestpathtreeforAreaA.All
referencestolinkstatedatabaselookupbelowarefromAreaA's
database.
(1)Initializethealgorithm'sdatastructures.Clearthelist
ofcandidatevertices.Initializetheshortestpathtreeto
onlytheroot(whichistherouterdoingthecalculation).
SetAreaA'sTransitCapabilitytoFALSE.
(2)CallthevertexjustaddedtothetreevertexV.Examine
theLSAassociatedwithvertexV.Thisisalookupinthe
AreaA'slinkstatedatabasebasedontheVertexID.If
thisisarouterLSA,andbitVoftherouterLSA(see
SectionA.4.2)isset,setAreaA'sTransitCapabilityto
TRUE.Inanycase,eachlinkdescribedbytheLSAgivesthe
costtoanadjacentvertex.Foreachdescribedlink,(say
125/188
3/2/2015
itjoinsvertexVtovertexW):
(a)Ifthisisalinktoastubnetwork,examinethenext
linkinV'sLSA.Linkstostubnetworkswillbe
consideredinthesecondstageoftheshortestpath
calculation.
(b)Otherwise,Wisatransitvertex(routerortransit
network).LookupthevertexW'sLSA(routerLSAor
networkLSA)inAreaA'slinkstatedatabase.Ifthe
LSAdoesnotexist,oritsLSageisequaltoMaxAge,or
itdoesnothavealinkbacktovertexV,examinethe
nextlinkinV'sLSA.[23]
(c)IfvertexWisalreadyontheshortestpathtree,
examinethenextlinkintheLSA.
(d)CalculatethelinkstatecostDoftheresultingpath
fromtheroottovertexW.Disequaltothesumofthe
linkstatecostofthe(alreadycalculated)shortest
pathtovertexVandtheadvertisedcostofthelink
betweenverticesVandW.IfDis:
oGreaterthanthevaluethatalreadyappearsfor
vertexWonthecandidatelist,thenexaminethe
nextlink.
oEqualtothevaluethatappearsforvertexWonthe
candidatelist,calculatethesetofnexthopsthat
resultfromusingtheadvertisedlink.Inputto
thiscalculationisthedestination(W),andits
parent(V).ThiscalculationisshowninSection
16.1.1.Thissetofhopsshouldbeaddedtothe
nexthopvaluesthatappearforWonthecandidate
list.
oLessthanthevaluethatappearsforvertexWonthe
candidatelist,orifWdoesnotyetappearonthe
candidatelist,thensettheentryforWonthe
candidatelisttoindicateadistanceofDfromthe
root.Alsocalculatethelistofnexthopsthat
resultfromusingtheadvertisedlink,settingthe
nexthopvaluesforWaccordingly.Thenexthop
calculationisdescribedinSection16.1.1;ittakes
asinputthedestination(W)anditsparent(V).
(3)Ifatthisstepthecandidatelistisempty,theshortest
pathtree(oftransitvertices)hasbeencompletelybuilt
andthisstageoftheprocedureterminates.Otherwise,
choosethevertexbelongingtothecandidatelistthatis
closesttotheroot,andaddittotheshortestpathtree
(removingitfromthecandidatelistintheprocess).Note
thatwhenthereisachoiceofverticesclosesttotheroot,
networkverticesmustbechosenbeforerouterverticesin
ordertonecessarilyfindallequalcostpaths.Thisis
consistentwiththetiebreakersthatwereintroducedinthe
modifiedDijkstraalgorithmusedbyOSPF'sMulticastrouting
extensions(MOSPF).
126/188
3/2/2015
(4)Possiblymodifytheroutingtable.Forthoseroutingtable
entriesmodified,theassociatedareawillbesettoAreaA,
thepathtypewillbesettointraarea,andthecostwill
besettothenewlydiscoveredshortestpath'scalculated
distance.
IfthenewlyaddedvertexisanareaborderrouterorAS
boundaryrouter,aroutingtableentryisaddedwhose
destinationtypeis"router".TheOptionsfieldfoundin
theassociatedrouterLSAiscopiedintotheroutingtable
entry'sOptionalcapabilitiesfield.Callthenewlyadded
vertexRouterX.IfRouterXistheendpointofoneofthe
calculatingrouter'svirtuallinks,andthevirtuallink
usesAreaAasTransitarea:thevirtuallinkisdeclared
up,theIPaddressofthevirtualinterfaceissettotheIP
addressoftheoutgoinginterfacecalculatedabovefor
RouterX,andthevirtualneighbor'sIPaddressissetto
RouterX'sinterfaceaddress(containedinRouterX's
routerLSA)thatpointsbacktotherootoftheshortest
pathtree;equivalently,thisistheinterfacethatpoints
backtoRouterX'sparentvertexontheshortestpathtree
(similartothecalculationinSection16.1.1).
Ifthenewlyaddedvertexisatransitnetwork,therouting
tableentryforthenetworkislocated.Theentry's
DestinationIDistheIPnetworknumber,whichcanbe
obtainedbymaskingtheVertexID(LinkStateID)withits
associatedsubnetmask(foundinthebodyoftheassociated
networkLSA).Iftheroutingtableentryalreadyexists
(i.e.,thereisalreadyanintraarearoutetothe
destinationinstalledintheroutingtable),multiple
verticeshavemappedtothesameIPnetwork.Forexample,
thiscanoccurwhenanewDesignatedRouterisbeing
established.Inthiscase,thecurrentroutingtableentry
shouldbeoverwrittenifandonlyifthenewlyfoundpathis
justasshortandthecurrentroutingtableentry'sLink
StateOriginhasasmallerLinkStateIDthanthenewly
addedvertex'LSA.
Ifthereisnoroutingtableentryforthenetwork(the
usualcase),aroutingtableentryfortheIPnetworkshould
beadded.Theroutingtableentry'sLinkStateOrigin
shouldbesettothenewlyaddedvertex'LSA.
(5)IteratethealgorithmbyreturningtoStep2.
127/188
3/2/2015
Thestubnetworksareaddedtothetreeintheprocedure's
secondstage.Inthisstage,allrouterverticesareagain
examined.Thosethathavebeendeterminedtobeunreachablein
theabovefirstphasearediscarded.Foreachreachablerouter
vertex(callitV),theassociatedrouterLSAisfoundinthe
linkstatedatabase.Eachstubnetworklinkappearinginthe
LSAisthenexamined,andthefollowingstepsareexecuted:
(1)CalculatethedistanceDofstubnetworkfromtheroot.D
isequaltothedistancefromtheroottotheroutervertex
(calculatedinstage1),plusthestubnetworklink's
advertisedcost.Comparethisdistancetothecurrentbest
costtothestubnetwork.Thisisdonebylookingupthe
stubnetwork'scurrentroutingtableentry.Ifthe
calculateddistanceDislarger,goontoexaminethenext
stubnetworklinkintheLSA.
(2)Ifthisstepisreached,thestubnetwork'sroutingtable
entrymustbeupdated.Calculatethesetofnexthopsthat
wouldresultfromusingthestubnetworklink.This
calculationisshowninSection16.1.1;inputtothis
calculationisthedestination(thestubnetwork)andthe
parentvertex(theroutervertex).IfthedistanceDisthe
sameasthecurrentroutingtablecost,simplyaddthisset
ofnexthopstotheroutingtableentry'slistofnexthops.
Inthiscase,theroutingtablealreadyhasaLinkState
Origin.IfthisLinkStateOriginisarouterLSAwhose
LinkStateIDissmallerthanV'sRouterID,resettheLink
StateOrigintoV'srouterLSA.
OtherwiseDissmallerthantheroutingtablecost.
Overwritethecurrentroutingtableentrybysettingthe
routingtableentry'scosttoD,andbysettingtheentry's
listofnexthopstothenewlycalculatedset.Setthe
routingtableentry'sLinkStateOrigintoV'srouterLSA.
Thengoontoexaminethenextstubnetworklink.
Forallroutingtableentriesadded/modifiedinthesecond
stage,theassociatedareawillbesettoAreaAandthepath
typewillbesettointraarea.Whenthelistofreachable
routerLSAsisexhausted,thesecondstageiscompleted.At
thistime,allintraarearoutesassociatedwithAreaAhave
beendetermined.
Thespecificationdoesnotrequirethattheabovetwostage
methodbeusedtocalculatetheshortestpathtree.However,if
anotheralgorithmisused,anidenticaltreemustbeproduced.
Forthisreason,itisimportanttonotethatlinksbetween
transitverticesmustbebidirectionalinordertobeincluded
intheabovetree.Itshouldalsobementionedthatmore
efficientalgorithmsexistforcalculatingthetree;for
example,theincrementalSPFalgorithmdescribedin[Ref1].
16.1.1.Thenexthopcalculation
128/188
3/2/2015
Thissectionexplainshowtocalculatethecurrentsetof
nexthopstouseforadestination.Eachnexthopconsists
oftheoutgoinginterfacetouseinforwardingpacketsto
thedestinationtogetherwiththeIPaddressofthenexthop
router(ifany).Thenexthopcalculationisinvokedeach
timeashorterpathtothedestinationisdiscovered.This
canhappenineitherstageoftheshortestpathtree
calculation(seeSection16.1).Instage1ofthe
shortestpathtreecalculationashorterpathisfoundas
thedestinationisaddedtothecandidatelist,orwhenthe
destination'sentryonthecandidatelistismodified(Step
2dofStage1).Instage2ashorterpathisdiscovered
eachtimethedestination'sroutingtableentryismodified
(Step2ofStage2).
Thesetofnexthopstouseforthedestinationmaybe
recalculatedseveraltimesduringtheshortestpathtree
calculation,asshorterandshorterpathsarediscovered.
Intheend,thedestination'sroutingtableentrywill
alwaysreflectthenexthopsresultingfromtheabsolute
shortestpath(s).
Inputtothenexthopcalculationisa)thedestinationand
b)itsparentinthecurrentshortestpathbetweentheroot
(thecalculatingrouter)andthedestination.Theparentis
alwaysatransitvertex(i.e.,alwaysarouteroratransit
network).
Ifthereisatleastoneinterveningrouterinthecurrent
shortestpathbetweenthedestinationandtheroot,the
destinationsimplyinheritsthesetofnexthopsfromthe
parent.Otherwise,therearetwocases.Inthefirstcase,
theparentvertexistheroot(thecalculatingrouter
itself).Thismeansthatthedestinationiseithera
directlyconnectednetworkordirectlyconnectedrouter.
TheoutgoinginterfaceinthiscaseissimplytheOSPF
interfaceconnectingtothedestinationnetwork/router.If
thedestinationisarouterwhichconnectstothe
calculatingrouterviaaPointtoMultiPointnetwork,the
destination'snexthopIPaddress(es)canbedeterminedby
examiningthedestination'srouterLSA:eachlinkpointing
backtothecalculatingrouterandhavingaLinkDatafield
belongingtothePointtoMultiPointnetworkprovidesanIP
addressofthenexthoprouter.Ifthedestinationisa
directlyconnectednetwork,orarouterwhichconnectsto
thecalculatingrouterviaapointtopointinterface,no
nexthopIPaddressisrequired.Ifthedestinationisa
routerconnectedtothecalculatingrouterviaavirtual
link,thesettingofthenexthopshouldbedeferreduntil
thecalculationinSection16.3.
Inthesecondcase,theparentvertexisanetworkthat
directlyconnectsthecalculatingroutertothedestination
router.Thelistofnexthopsisthendeterminedby
examiningthedestination'srouterLSA.Foreachlinkin
therouterLSAthatpointsbacktotheparentnetwork,the
link'sLinkDatafieldprovidestheIPaddressofanexthop
router.Theoutgoinginterfacetousecanthenbederived
129/188
3/2/2015
fromthenexthopIPaddress(oritcanbeinheritedfrom
theparentnetwork).
16.2.Calculatingtheinterarearoutes
TheinterarearoutesarecalculatedbyexaminingsummaryLSAs.
Iftherouterhasactiveattachmentstomultipleareas,only
backbonesummaryLSAsareexamined.Routersattachedtoa
singleareaexaminethatarea'ssummaryLSAs.Ineithercase,
thesummaryLSAsexaminedbelowareallpartofasinglearea's
linkstatedatabase(callitAreaA).
SummaryLSAsareoriginatedbytheareaborderrouters.Each
summaryLSAinAreaAisconsideredinturn.Rememberthatthe
destinationdescribedbyasummaryLSAiseitheranetwork(Type
3summaryLSAs)oranASboundaryrouter(Type4summaryLSAs).
ForeachsummaryLSA:
(1)IfthecostspecifiedbytheLSAisLSInfinity,orifthe
LSA'sLSageisequaltoMaxAge,thenexaminethethenext
LSA.
(2)IftheLSAwasoriginatedbythecalculatingrouteritself,
examinethenextLSA.
(3)IfitisaType3summaryLSA,andthecollectionof
destinationsdescribedbythesummaryLSAequalsoneofthe
router'sconfiguredareaaddressranges(seeSection3.5),
andtheparticularareaaddressrangeisactive,thenthe
summaryLSAshouldbeignored."Active"meansthatthere
areoneormorereachable(byintraareapaths)networks
containedinthearearange.
(4)Else,callthedestinationdescribedbytheLSAN(forType
3summaryLSAs,N'saddressisobtainedbymaskingtheLSA's
LinkStateIDwiththenetwork/subnetmaskcontainedinthe
bodyoftheLSA),andtheareaborderoriginatingtheLSA
BR.LookuptheroutingtableentryforBRhavingAreaAas
itsassociatedarea.IfnosuchentryexistsforrouterBR
(i.e.,BRisunreachableinAreaA),donothingwiththis
LSAandconsiderthenextinthelist.Else,thisLSA
describesaninterareapathtodestinationN,whosecostis
thedistancetoBRplusthecostspecifiedintheLSA.Call
thecostofthisinterareapathIAC.
(5)Next,lookuptheroutingtableentryforthedestinationN.
(IfNisanASboundaryrouter,lookupthe"router"routing
tableentryassociatedwithAreaA).Ifnoentryexistsfor
Noriftheentry'spathtypeis"type1external"or"type
2external",theninstalltheinterareapathtoN,with
associatedareaAreaA,costIAC,nexthopequaltothelist
ofnexthopstorouterBR,andAdvertisingrouterequalto
BR.
130/188
3/2/2015
(6)Else,ifthepathspresentinthetableareintraarea
paths,donothingwiththeLSA(intraareapathsarealways
preferred).
(7)Else,thepathspresentintheroutingtablearealso
interareapaths.InstallthenewpaththroughBRifitis
cheaper,overridingthepathsintheroutingtable.
Otherwise,ifthenewpathisthesamecost,addittothe
listofpathsthatappearintheroutingtableentry.
16.3.Examiningtransitareas'summaryLSAs
Thisstepisonlyperformedbyareaborderroutersattachedto
oneormorenonbackboneareasthatarecapableofcarrying
transittraffic(i.e.,"transitareas",orthoseareaswhose
TransitCapabilityparameterhasbeensettoTRUEinStep2of
theDijkstraalgorithm(seeSection16.1).
Thepurposeofthecalculationbelowistoexaminethetransit
areastoseewhethertheyprovideanybetter(shorter)paths
thanthepathspreviouslycalculatedinSections16.1and16.2.
Anypathsfoundthatarebetterthanorequaltopreviously
discoveredpathsareinstalledintheroutingtable.
Thecalculationalsodeterminestheactualnexthop(s)forthose
destinationswhosenexthopwascalculatedasavirtuallinkin
Sections16.1and16.2.Aftercompletionofthecalculation
below,anypathscalculatedinSections16.1and16.2thatstill
haveunresolvedvirtualnexthopsshouldbediscarded.
Thecalculationproceedsasfollows.Allthetransitareas'
summaryLSAsareexaminedinturn.EachsuchsummaryLSA
describesaroutethroughatransitareaAreaAtoaNetworkN
(N'saddressisobtainedbymaskingtheLSA'sLinkStateIDwith
thenetwork/subnetmaskcontainedinthebodyoftheLSA)orin
thecaseofaType4summaryLSA,toanASboundaryrouterN.
SupposealsothatthesummaryLSAwasoriginatedbyanarea
borderrouterBR.
(1)IfthecostadvertisedbythesummaryLSAisLSInfinity,or
iftheLSA'sLSageisequaltoMaxAge,thenexaminethe
nextLSA.
(2)IfthesummaryLSAwasoriginatedbythecalculatingrouter
itself,examinethenextLSA.
(3)LookuptheroutingtableentryforN.(IfNisanAS
boundaryrouter,lookupthe"router"routingtableentry
associatedwiththebackbonearea).Ifitdoesnotexist,or
iftheroutetypeisotherthanintraareaorinterarea,or
iftheareaassociatedwiththeroutingtableentryisnot
thebackbonearea,thenexaminethenextLSA.Inother
words,thiscalculationonlyupdatesbackboneintraarea
131/188
3/2/2015
routesfoundinSection16.1andinterarearoutesfoundin
Section16.2.
(4)Lookuptheroutingtableentryfortheadvertisingrouter
BRassociatedwiththeAreaA.Ifitisunreachable,examine
thenextLSA.Otherwise,thecosttodestinationNisthe
sumofthecostinBR'sAreaAroutingtableentryandthe
costadvertisedintheLSA.CallthiscostIAC.
(5)IfthiscostislessthanthecostoccurringinN'srouting
tableentry,overwriteN'slistofnexthopswiththoseused
forBR,andsetN'sroutingtablecosttoIAC.Else,ifIAC
isthesameasN'scurrentcost,addBR'slistofnexthops
toN'slistofnexthops.Inanycase,theareaassociated
withN'sroutingtableentrymustremainthebackbonearea,
andthepathtype(eitherintraareaorinterarea)must
alsoremainthesame.
Itisimportanttonotethattheabovecalculationnevermakes
unreachabledestinationsreachable,butinsteadjustpotentially
findsbetterpathstoalreadyreachabledestinations.The
calculationinstallsanybettercostfoundintotherouting
tableentry,fromwhichitmaybereadvertisedinsummaryLSAs
tootherareas.
Asanexampleofthecalculation,considertheAutonomousSystem
picturedinFigure17.Thereisasinglenonbackbonearea
(Area1)thatphysicallydividesthebackboneintotwoseparate
pieces.Tomaintainconnectivityofthebackbone,avirtuallink
hasbeenconfiguredbetweenroutersRT1andRT4.Ontheright
sideofthefigure,NetworkN1belongstothebackbone.The
dottedlinesindicatethatthereisamuchshorterintraarea
........................
.Area1(transit).+
..|
.++11++100|
.|RT2||RT4|=========|
.1/++*********++|
./*******.|
.1/*Virtual.|
1++/*Link.Net|work
=======|RT1|*.|N1
++\.|
.\.|
.\.|
.1\++11++20|
.|RT3||RT5|=========|
.++++|
..|
........................+
Figure17:Routingthroughtransitareas
backbonepathbetweenrouterRT5andNetworkN1(cost20)than
thereisbetweenRouterRT4andNetworkN1(cost100).Both
RouterRT4andRouterRT5willinjectsummaryLSAsforNetwork
132/188
3/2/2015
N1intoArea1.
Aftertheshortestpathtreehasbeencalculatedforthe
backboneinSection16.1,RouterRT1(leftendofthevirtual
link)willhavecalculatedapaththroughRouterRT4forall
datatrafficdestinedforNetworkN1.However,sinceRouterRT5
issomuchclosertoNetworkN1,allroutersinternaltoArea1
(e.g.,RoutersRT2andRT3)willforwardtheirNetworkN1
traffictowardsRouterRT5,insteadofRT4.Andindeed,after
examiningArea1'ssummaryLSAsbytheabovecalculation,Router
RT1willalsoforwardNetworkN1traffictowardsRT5.Notethat
inthisexamplethevirtuallinkenablestransitdatatrafficto
beforwardedthroughArea1,buttheactualpaththetransit
datatraffictakesdoesnotfollowthevirtuallink.Inother
words,virtuallinksallowtransittraffictobeforwarded
throughanarea,butdonotdictatetheprecisepaththatthe
trafficwilltake.
16.4.CalculatingASexternalroutes
ASexternalroutesarecalculatedbyexaminingASexternalLSAs.
EachoftheASexternalLSAsisconsideredinturn.MostAS
externalLSAsdescriberoutestospecificIPdestinations.An
ASexternalLSAcanalsodescribeadefaultrouteforthe
AutonomousSystem(DestinationID=DefaultDestination,
network/subnetmask=0x00000000).ForeachASexternalLSA:
(1)IfthecostspecifiedbytheLSAisLSInfinity,orifthe
LSA'sLSageisequaltoMaxAge,thenexaminethenextLSA.
(2)IftheLSAwasoriginatedbythecalculatingrouteritself,
examinethenextLSA.
(3)CallthedestinationdescribedbytheLSAN.N'saddressis
obtainedbymaskingtheLSA'sLinkStateIDwiththe
network/subnetmaskcontainedinthebodyoftheLSA.Look
uptheroutingtableentries(potentiallyoneperattached
area)fortheASboundaryrouter(ASBR)thatoriginatedthe
LSA.IfnoentriesexistforrouterASBR(i.e.,ASBRis
unreachable),donothingwiththisLSAandconsiderthenext
inthelist.
Else,thisLSAdescribesanASexternalpathtodestination
N.ExaminetheforwardingaddressspecifiedintheAS
externalLSA.ThisindicatestheIPaddresstowhich
packetsforthedestinationshouldbeforwarded.
Iftheforwardingaddressissetto0.0.0.0,packetsshould
besenttotheASBRitself.Amongthemultipleroutingtable
entriesfortheASBR,selectthepreferredentryasfollows.
IfRFC1583Compatibilityissetto"disabled",prunetheset
ofroutingtableentriesfortheASBRasdescribedin
Section16.4.1.Inanycase,amongtheremainingrouting
tableentries,selecttheroutingtableentrywiththeleast
cost;whentherearemultipleleastcostroutingtable
entriestheentrywhoseassociatedareahasthelargestOSPF
AreaID(whenconsideredasanunsigned32bitinteger)is
133/188
3/2/2015
chosen.
Iftheforwardingaddressisnonzero,lookupthe
forwardingaddressintheroutingtable.[24]Thematching
routingtableentrymustspecifyanintraareaorinterarea
path;ifnosuchpathexists,donothingwiththeLSAand
considerthenextinthelist.
(4)LetXbethecostspecifiedbythepreferredroutingtable
entryfortheASBR/forwardingaddress,andYthecost
specifiedintheLSA.Xisintermsofthelinkstate
metric,andYisatype1or2externalmetric.
(5)LookuptheroutingtableentryforthedestinationN.If
noentryexistsforN,installtheASexternalpathtoN,
withnexthopequaltothelistofnexthopstothe
forwardingaddress,andadvertisingrouterequaltoASBR.
Iftheexternalmetrictypeis1,thenthepathtypeisset
totype1externalandthecostisequaltoX+Y.Ifthe
externalmetrictypeis2,thepathtypeissettotype2
external,thelinkstatecomponentoftheroute'scostisX,
andthetype2costisY.
(6)ComparetheASexternalpathdescribedbytheLSAwiththe
existingpathsinN'sroutingtableentry,asfollows.If
thenewpathispreferred,itreplacesthepresentpathsin
N'sroutingtableentry.Ifthenewpathisofequal
preference,itisaddedtoN'sroutingtableentry'slistof
paths.
(a)Intraareaandinterareapathsarealwayspreferred
overASexternalpaths.
(b)Type1externalpathsarealwayspreferredovertype2
externalpaths.Whenallpathsaretype2external
paths,thepathswiththesmallestadvertisedtype2
metricarealwayspreferred.
(c)IfthenewASexternalpathisstillindistinguishable
fromthecurrentpathsintheN'sroutingtableentry,
andRFC1583Compatibilityissetto"disabled",select
thepreferredpathsbasedontheintraASpathstothe
ASBR/forwardingaddresses,asspecifiedinSection
16.4.1.
(d)IfthenewASexternalpathisstillindistinguishable
fromthecurrentpathsintheN'sroutingtableentry,
selectthepreferredpathbasedonaleastcost
comparison.Type1externalpathsarecomparedby
lookingatthesumofthedistancetotheforwarding
134/188
3/2/2015
addressandtheadvertisedtype1metric(X+Y).Type2
externalpathsadvertisingequaltype2metricsare
comparedbylookingatthedistancetotheforwarding
addresses.
16.4.1.Externalpathpreferences
WhenmultipleintraASpathsareavailableto
ASBRs/forwardingaddresses,thefollowingrulesindicate
whichpathsarepreferred.Theserulesapplywhenthesame
ASBRisreachablethroughmultipleareas,orwhentryingto
decidewhichofseveralASexternalLSAsshouldbe
preferred.Intheformercasethepathsallterminateatthe
sameASBR,whileinthelatterthepathsterminateat
separateASBRs/forwardingaddresses.Ineithercase,each
pathisrepresentedbyaseparateroutingtableentryas
definedinSection11.
ThissectiononlyapplieswhenRFC1583Compatibilityisset
to"disabled".
Thepathpreferencerules,statedfromhighesttolowest
preference,areasfollows.Notethatasaresultofthese
rules,theremaystillbemultiplepathsofthehighest
preference.Inthiscase,thepathtousemustbedetermined
basedoncost,asdescribedinSection16.4.
oIntraareapathsusingnonbackboneareasarealwaysthe
mostpreferred.
oTheotherpaths,intraareabackbonepathsandinter
areapaths,areofequalpreference.
16.5.IncrementalupdatessummaryLSAs
WhenanewsummaryLSAisreceived,itisnotnecessaryto
recalculatetheentireroutingtable.Callthedestination
describedbythesummaryLSAN(N'saddressisobtainedby
maskingtheLSA'sLinkStateIDwiththenetwork/subnetmask
containedinthebodyoftheLSA),andletAreaAbetheareato
whichtheLSAbelongs.Therearethentwoseparatecases:
Case1:AreaAisthebackboneand/ortherouterisnotanarea
borderrouter.
Inthiscase,thefollowingcalculationsmustbeperformed.
First,ifthereispresentlyaninterarearoutetothe
destinationN,N'sroutingtableentryisinvalidated,
savingtheentry'svaluesforlatercomparisons.Thenthe
calculationinSection16.2isrunagainforthesingle
destinationN.Inthiscalculation,allofAreaA's
summaryLSAsthatdescribearoutetoNareexamined.In
addition,iftherouterisanareaborderrouterattachedto
oneormoretransitareas,thecalculationinSection16.3
mustberunagainforthesingledestination.Ifthe
resultsofthesecalculationshavechangedthecost/pathto
anASboundaryrouter(aswouldbethecaseforaType4
summaryLSA)ortoanyforwardingaddresses,allAS
135/188
3/2/2015
externalLSAswillhavetobereexaminedbyrerunningthe
calculationinSection16.4.Otherwise,ifNisnownewly
unreachable,thecalculationinSection16.4mustbererun
forthesingledestinationN,incaseanalternateexternal
routetoNexists.
Case2:AreaAisatransitareaandtherouterisanarea
borderrouter.
Inthiscase,thefollowingcalculationsmustbeperformed.
First,ifN'sroutingtableentrypresentlycontainsoneor
moreinterareapathsthatutilizethetransitareaAreaA,
thesepathsshouldberemoved.Ifthisremovesallpaths
fromtheroutingtableentry,theentryshouldbe
invalidated.Theentry'soldvaluesshouldbesavedfor
latercomparisons.NextthecalculationinSection16.3must
berunagainforthesingledestinationN.Iftheresultsof
thiscalculationhavecausedthecosttoNtoincrease,the
completeroutingtablecalculationmustbererunstarting
withtheDijkstraalgorithmspecifiedinSection16.1.
Otherwise,ifthecost/pathtoanASboundaryrouter(as
wouldbethecaseforaType4summaryLSA)ortoany
forwardingaddresseshaschanged,allASexternalLSAswill
havetobereexaminedbyrerunningthecalculationin
Section16.4.Otherwise,ifNisnownewlyunreachable,the
calculationinSection16.4mustbererunforthesingle
destinationN,incaseanalternateexternalroutetoN
exists.
16.6.IncrementalupdatesASexternalLSAs
WhenanewASexternalLSAisreceived,itisnotnecessaryto
recalculatetheentireroutingtable.Callthedestination
describedbytheASexternalLSAN.N'saddressisobtainedby
maskingtheLSA'sLinkStateIDwiththenetwork/subnetmask
containedinthebodyoftheLSA.Ifthereisalreadyanintra
areaorinterarearoutetothedestination,norecalculationis
necessary(internalroutestakeprecedence).
Otherwise,theprocedureinSection16.4willhavetobe
performed,butonlyforthoseASexternalLSAswhosedestination
isN.Beforethisprocedureisperformed,thepresentrouting
tableentryforNshouldbeinvalidated.
16.7.Eventsgeneratedasaresultofroutingtablechanges
ChangestoroutingtableentriessometimescausetheOSPFarea
borderrouterstotakeadditionalactions.Theseroutersneed
toactonthefollowingroutingtablechanges:
oThecostorpathtypeofaroutingtableentryhaschanged.
IfthedestinationdescribedbythisentryisaNetworkor
ASboundaryrouter,andthisisnotsimplyachangeofAS
externalroutes,newsummaryLSAsmayhavetobegenerated
(potentiallyoneforeachattachedarea,includingthe
backbone).SeeSection12.4.3formoreinformation.Ifa
previouslyadvertisedentryhasbeendeleted,orisno
longeradvertisabletoaparticulararea,theLSAmustbe
136/188
3/2/2015
flushedfromtheroutingdomainbysettingitsLSageto
MaxAgeandreflooding(seeSection14.1).
oAroutingtableentryassociatedwithaconfiguredvirtual
linkhaschanged.Thedestinationofsucharoutingtable
entryisanareaborderrouter.Thechangeindicatesa
modificationtothevirtuallink'scostorviability.
Iftheentryindicatesthattheareaborderrouterisnewly
reachable,thecorrespondingvirtuallinkisnow
operational.AnInterfaceUpeventshouldbegeneratedfor
thevirtuallink,whichwillcauseavirtualadjacencyto
begintoform(seeSection10.3).Atthistimethevirtual
link'sIPinterfaceaddressandthevirtualneighbor's
NeighborIPaddressarealsocalculated.
Iftheentryindicatesthattheareaborderrouterisno
longerreachable,thevirtuallinkanditsassociated
adjacencyshouldbedestroyed.ThismeansanInterfaceDown
eventshouldbegeneratedfortheassociatedvirtuallink.
Ifthecostoftheentryhaschanged,andthereisafully
establishedvirtualadjacency,anewrouterLSAforthe
backbonemustbeoriginated.Thisinturnmaycausefurther
routingtablechanges.
16.8.Equalcostmultipath
TheOSPFprotocolmaintainsmultipleequalcostroutestoall
destinations.Thiscanbeseeninthestepsusedaboveto
calculatetheroutingtable,andinthedefinitionofthe
routingtablestructure.
Eachoneofthemultiplerouteswillbeofthesametype
(intraarea,interarea,type1externalortype2external),
cost,andwillhavethesameassociatedarea.However,each
routemayspecifyaseparatenexthopandAdvertisingrouter.
ThereisnorequirementthatarouterrunningOSPFkeeptrackof
allpossibleequalcostroutestoadestination.An
implementationmaychoosetokeeponlyafixednumberofroutes
toanygivendestination.Thisdoesnotaffectanyofthe
algorithmspresentedinthisspecification.
137/188
3/2/2015
Footnotes
[1]Thegraph'sverticesrepresenteitherrouters,transitnetworks,
orstubnetworks.Sinceroutersmaybelongtomultipleareas,itis
notpossibletocolorthegraph'svertices.
[2]Itispossibleforallofarouter'sinterfacestobeunnumbered
pointtopointlinks.Inthiscase,anIPaddressmustbeassigned
totherouter.Thisaddresswillthenbeadvertisedintherouter's
routerLSAasahostroute.
[3]Notethatinthesecasesbothinterfaces,thenonvirtualandthe
virtual,wouldhavethesameIPaddress.
[4]Notethatnohostrouteisgeneratedfor,andnoIPpacketscan
beaddressedto,interfacestounnumberedpointtopointnetworks.
Thisisregardlessofsuchaninterface'sstate.
[5]ItisinstructivetoseewhathappenswhentheDesignatedRouter
forthenetworkcrashes.CalltheDesignatedRouterforthenetwork
RT1,andtheBackupDesignatedRouterRT2.IfRouterRT1crashes
(ormaybeitsinterfacetothenetworkdies),theotherrouterson
thenetworkwilldetectRT1'sabsencewithinRouterDeadInterval
seconds.Allroutersmaynotdetectthisatpreciselythesame
time;theroutersthatdetectRT1'sabsencebeforeRT2doeswill,
foratime,selectRT2tobebothDesignatedRouterandBackup
DesignatedRouter.WhenRT2detectsthatRT1isgoneitwillmove
itselftoDesignatedRouter.Atthistime,theremainingrouter
havinghighestRouterPrioritywillbeselectedasBackupDesignated
Router.
[6]Onpointtopointnetworks,thelowerlevelprotocolsindicate
whethertheneighborisupandrunning.Likewise,existenceofthe
neighboronvirtuallinksisindicatedbytheroutingtable
calculation.However,inboththesecases,theHelloProtocolis
stillused.Thisensuresthatcommunicationbetweentheneighbors
isbidirectional,andthateachoftheneighborshasafunctioning
routingprotocollayer.
[7]WhentheidentityoftheDesignatedRouterischanging,itmaybe
quitecommonforaneighborinthisstatetosendtheroutera
DatabaseDescriptionpacket;thismeansthatthereissomemomentary
disagreementontheDesignatedRouter'sidentity.
[8]Notethatitispossibleforaroutertoresynchronizeanyofits
fullyestablishedadjacenciesbysettingtheadjacency'sstateback
toExStart.Thiswillcausetheotherendoftheadjacencyto
processaSeqNumberMismatchevent,andthereforetoalsogobackto
ExStartstate.
[9]TheaddressspaceofIPnetworksandtheaddressspaceofOSPF
RouterIDsmayoverlap.Thatis,anetworkmayhaveanIPaddress
whichisidentical(whenconsideredasa32bitnumber)tosome
router'sRouterID.
[10]"Discard"entriesarenecessarytoensurethatroute
138/188
3/2/2015
summarizationatareaboundarieswillnotcausepacketlooping.
[11]Itisassumedthat,fortwodifferentaddressrangesmatching
thedestination,onerangeismorespecificthantheother.Non
contiguoussubnetmaskscanbeconfiguredtoviolatethis
assumption.Suchsubnetmaskconfigurationscannotbehandledbythe
OSPFprotocol.
[12]MaxAgeDiffisanarchitecturalconstant.Itindicatesthe
maximumdispersionofages,inseconds,thatcanoccurforasingle
LSAinstanceasitisfloodedthroughouttheroutingdomain.Iftwo
LSAsdifferbymorethanthis,theyareassumedtobedifferent
instancesofthesameLSA.Thiscanoccurwhenarouterrestarts
andlosestrackoftheLSA'spreviousLSsequencenumber.See
[13]WhentwoLSAshavedifferentLSchecksums,theyareassumedto
beseparateinstances.Thiscanoccurwhenarouterrestarts,and
losestrackoftheLSA'spreviousLSsequencenumber.Inthecase
wherethetwoLSAshavethesameLSsequencenumber,itisnot
possibletodeterminewhichLSAisactuallynewer.However,ifthe
wrongLSAisacceptedasnewer,theoriginatingrouterwillsimply
originateanotherinstance.SeeSection13.4forfurtherdetails.
[14]Thereisoneinstancewherealookupmustbedonebasedon
partialinformation.Thisisduringtheroutingtablecalculation,
whenanetworkLSAmustbefoundbasedsolelyonitsLinkStateID.
Thelookupinthiscaseisstillwelldefined,sincenotwo
networkLSAscanhavethesameLinkStateID.
[15]ThisisthewayRFC1583specifiedpointtopoint
representation.Ithasthreeadvantages:a)itdoesnotrequire
allocatingasubnettothepointtopointlink,b)ittendstobias
theroutingsothatpacketsdestinedforthepointtopoint
interfacewillactuallybereceivedovertheinterface(whichis
usefulfordiagnosticpurposes)andc)itallowsnetwork
bootstrappingofaneighbor,withoutrequiringthatthebootstrap
programcontainanOSPFimplementation.
[16]Thisisthemoretraditionalpointtopointrepresentationused
byprotocolssuchasRIP.
[17]Thisclausecoversthecase:Interarearoutesarenot
summarizedtothebackbone.Thisisbecauseinterarearoutesare
alwaysassociatedwiththebackbonearea.
[18]ThisclauseisonlyinvokedwhenanonbackboneAreaAsupports
transitdatatraffic(i.e.,hasTransitCapabilitysettoTRUE).For
example,intheareaconfigurationofFigure6,Area2cansupport
transittrafficduetotheconfiguredvirtuallinkbetweenRouters
RT10andRT11.Asaresult,RouterRT11needonlyoriginateasingle
summaryLSAintoArea2(havingthecollapseddestinationN9
N11,H1),sinceallofRouterRT11'sothereligiblerouteshavenext
hopsbelongingtoArea2itself(andassuchonlyneedbeadvertised
byotherareaborderrouters;inthiscase,RoutersRT10andRT7).
[19]Bykeepingmoreinformationintheroutingtable,itispossible
139/188
3/2/2015
foranimplementationtorecalculatetheshortestpathtreeforonly
asinglearea.Infact,thereareincrementalalgorithmsthatallow
animplementationtorecalculateonlyaportionofasinglearea's
shortestpathtree[Ref1].However,thesealgorithmsarebeyondthe
scopeofthisspecification.
[20]ThisishowtheLinkstaterequestlistisemptied,which
eventuallycausestheneighborstatetotransitiontoFull.See
[21]ItshouldbearelativelyrareoccurrenceforanLSA'sLSageto
reachMaxAgeinthisfashion.Usually,theLSAwillbereplacedby
amorerecentinstancebeforeitagesout.
[22]Strictlyspeaking,becauseofequalcostmultipath,the
algorithmdoesnotcreateatree.Wecontinuetousethe"tree"
terminologybecausethatiswhatoccursmostoftenintheexisting
literature.
[23]NotethatthepresenceofanylinkbacktoVissufficient;it
neednotbethematchinghalfofthelinkunderconsiderationfromV
toW.Thisisenoughtoensurethat,beforedatatrafficflows
betweenapairofneighboringrouters,theirlinkstatedatabases
willbesynchronized.
[24]Whentheforwardingaddressisnonzero,itshouldpointtoa
routerbelongingtoanotherAutonomousSystem.SeeSection12.4.4
formoredetails.
140/188
3/2/2015
References
[Ref1]McQuillan,J.,I.RicherandE.Rosen,"ARPANETRouting
AlgorithmImprovements",BBNTechnicalReport3803,April
1978.
[Ref2]DigitalEquipmentCorporation,"Informationprocessing
systemsDatacommunicationsIntermediateSystemto
IntermediateSystemIntraDomainRoutingProtocol",October
1987.
[Ref3]McQuillan,J.,et.al.,"TheNewRoutingAlgorithmforthe
ARPANET",IEEETransactionsonCommunications,May1980.
[Ref4]Perlman,R.,"FaultTolerantBroadcastofRouting
Information",ComputerNetworks,December1983.
[Ref5]Postel,J.,"InternetProtocol",STD5,RFC791,September
1981.
[Ref6]McKenzie,A.,"ISOTransportProtocolspecificationISODP
8073",RFC905,April1984.
[Ref7]Deering,S.,"HostextensionsforIPmulticasting",STD5,
RFC1112,May1988.
[Ref8]McCloghrie,K.,andM.Rose,"ManagementInformationBase
fornetworkmanagementofTCP/IPbasedinternets:MIBII",
STD17,RFC1213,March1991.
[Ref9]Moy,J.,"OSPFVersion2",RFC1583,March1994.
[Ref10]Fuller,V.,T.Li,J.Yu,andK.Varadhan,"Classless
InterDomainRouting(CIDR):anAddressAssignmentand
AggregationStrategy",RFC1519,September1993.
[Ref11]Reynolds,J.,andJ.Postel,"AssignedNumbers",STD2,RFC
1700,October1994.
[Ref12]Almquist,P.,"TypeofServiceintheInternetProtocol
Suite",RFC1349,July1992.
[Ref13]Leiner,B.,et.al.,"TheDARPAInternetProtocolSuite",DDN
ProtocolHandbook,April1985.
[Ref14]Bradley,T.,andC.Brown,"InverseAddressResolution
Protocol",RFC1293,January1992.
[Ref15]deSouza,O.,andM.Rodrigues,"GuidelinesforRunningOSPF
OverFrameRelayNetworks",RFC1586,March1994.
[Ref16]Bellovin,S.,"SecurityProblemsintheTCP/IPProtocol
141/188
3/2/2015
Suite",ACMComputerCommunicationsReview,Volume19,
Number2,pp.3238,April1989.
[Ref17]Rivest,R.,"TheMD5MessageDigestAlgorithm",RFC1321,
April1992.
[Ref18]Moy,J.,"MulticastExtensionstoOSPF",RFC1584,March
1994.
[Ref19]Coltun,R.,andV.Fuller,"TheOSPFNSSAOption",RFC1587,
March1994.
[Ref20]Ferguson,D.,"TheOSPFExternalAttributesLSA",workin
progress.
[Ref21]Moy,J.,"ExtendingOSPFtoSupportDemandCircuits",RFC
1793,April1995.
[Ref22]Mogul,J.,andS.Deering,"PathMTUDiscovery",RFC1191,
November1990.
[Ref23]Rekhter,Y.,andT.Li,"ABorderGatewayProtocol4(BGP
4)",RFC1771,March1995.
[Ref24]Hinden,R.,"InternetRoutingProtocolStandardization
Criteria",BBN,October1991.
[Ref25]Moy,J.,"OSPFVersion2",RFC2178,July1997.
[Ref26]Rosen,E.,"VulnerabilitiesofNetworkControlProtocols:An
Example",ComputerCommunicationReview,July1981.
A.OSPFdataformats
ThisappendixdescribestheformatofOSPFprotocolpacketsandOSPF
LSAs.TheOSPFprotocolrunsdirectlyovertheIPnetworklayer.
Beforeanydataformatsaredescribed,thedetailsoftheOSPF
encapsulationareexplained.
NexttheOSPFOptionsfieldisdescribed.Thisfielddescribes
variouscapabilitiesthatmayormaynotbesupportedbypiecesof
theOSPFroutingdomain.TheOSPFOptionsfieldiscontainedinOSPF
Hellopackets,DatabaseDescriptionpacketsandinOSPFLSAs.
OSPFpacketformatsaredetailedinSectionA.3.Adescriptionof
OSPFLSAsappearsinSectionA.4.
A.1EncapsulationofOSPFpackets
OSPFrunsdirectlyovertheInternetProtocol'snetworklayer.OSPF
packetsarethereforeencapsulatedsolelybyIPandlocaldatalink
headers.
OSPFdoesnotdefineawaytofragmentitsprotocolpackets,and
dependsonIPfragmentationwhentransmittingpacketslargerthan
thenetworkMTU.Ifnecessary,thelengthofOSPFpacketscanbeup
to65,535bytes(includingtheIPheader).TheOSPFpackettypes
142/188
3/2/2015
thatarelikelytobelarge(DatabaseDescriptionPackets,Link
StateRequest,LinkStateUpdate,andLinkStateAcknowledgment
packets)canusuallybesplitintoseveralseparateprotocol
packets,withoutlossoffunctionality.Thisisrecommended;IP
fragmentationshouldbeavoidedwheneverpossible.Usingthis
reasoning,anattemptshouldbemadetolimitthesizesofOSPF
packetssentovervirtuallinksto576bytesunlessPathMTU
Discoveryisbeingperformed(see[Ref22]).
TheotherimportantfeaturesofOSPF'sIPencapsulationare:
oUseofIPmulticast.SomeOSPFmessagesaremulticast,when
sentoverbroadcastnetworks.TwodistinctIPmulticast
addressesareused.Packetssenttothesemulticastaddresses
shouldneverbeforwarded;theyaremeanttotravelasinglehop
only.Toensurethatthesepacketswillnottravelmultiple
hops,theirIPTTLmustbesetto1.
AllSPFRouters
Thismulticastaddresshasbeenassignedthevalue
224.0.0.5.AllroutersrunningOSPFshouldbepreparedto
receivepacketssenttothisaddress.Hellopacketsare
alwayssenttothisdestination.Also,certainOSPF
protocolpacketsaresenttothisaddressduringthe
floodingprocedure.
AllDRouters
Thismulticastaddresshasbeenassignedthevalue
224.0.0.6.BoththeDesignatedRouterandBackupDesignated
Routermustbepreparedtoreceivepacketsdestinedtothis
address.CertainOSPFprotocolpacketsaresenttothis
addressduringthefloodingprocedure.
oOSPFisIPprotocolnumber89.Thisnumberhasbeenregistered
withtheNetworkInformationCenter.IPprotocolnumber
assignmentsaredocumentedin[Ref11].
oAllOSPFroutingprotocolpacketsaresentusingthenormal
serviceTOSvalueofbinary0000definedin[Ref12].
oRoutingprotocolpacketsaresentwithIPprecedencesetto
InternetworkControl.OSPFprotocolpacketsshouldbegiven
precedenceoverregularIPdatatraffic,inbothsendingand
receiving.SettingtheIPprecedencefieldintheIPheaderto
InternetworkControl[Ref5]mayhelpimplementthisobjective.
143/188
3/2/2015
A.2TheOptionsfield
TheOSPFOptionsfieldispresentinOSPFHellopackets,Database
DescriptionpacketsandallLSAs.TheOptionsfieldenablesOSPF
routerstosupport(ornotsupport)optionalcapabilities,andto
communicatetheircapabilityleveltootherOSPFrouters.Through
thismechanismroutersofdifferingcapabilitiescanbemixedwithin
anOSPFroutingdomain.
WhenusedinHellopackets,theOptionsfieldallowsarouterto
rejectaneighborbecauseofacapabilitymismatch.Alternatively,
whencapabilitiesareexchangedinDatabaseDescriptionpacketsa
routercanchoosenottoforwardcertainLSAstoaneighborbecause
ofitsreducedfunctionality.Lastly,listingcapabilitiesinLSAs
allowsrouterstoforwardtrafficaroundreducedfunctionality
routers,byexcludingthemfrompartsoftheroutingtable
calculation.
FivebitsoftheOSPFOptionsfieldhavebeenassigned,although
onlyone(theEbit)isdescribedcompletelybythismemo.Eachbit
isdescribedbrieflybelow.Routersshouldreset(i.e.clear)
unrecognizedbitsintheOptionsfieldwhensendingHellopacketsor
DatabaseDescriptionpacketsandwhenoriginatingLSAs.Conversely,
routersencounteringunrecognizedOptionbitsinreceivedHello
Packets,DatabaseDescriptionpacketsorLSAsshouldignorethe
capabilityandprocessthepacket/LSAnormally.
++
|*|*|DC|EA|N/P|MC|E|*|
++
TheOptionsfield
Ebit
ThisbitdescribesthewayASexternalLSAsareflooded,as
describedinSections3.6,9.5,10.8and12.1.2ofthismemo.
MCbit
ThisbitdescribeswhetherIPmulticastdatagramsareforwarded
accordingtothespecificationsin[Ref18].
N/Pbit
ThisbitdescribesthehandlingofType7LSAs,asspecifiedin
[Ref19].
EAbit
144/188
3/2/2015
Thisbitdescribestherouter'swillingnesstoreceiveand
forwardExternalAttributesLSAs,asspecifiedin[Ref20].
DCbit
Thisbitdescribestherouter'shandlingofdemandcircuits,as
specifiedin[Ref21].
A.3OSPFPacketFormats
TherearefivedistinctOSPFpackettypes.AllOSPFpackettypes
beginwithastandard24byteheader.Thisheaderisdescribed
first.Eachpackettypeisthendescribedinasucceedingsection.
Inthesesectionseachpacket'sdivisionintofieldsisdisplayed,
andthenthefielddefinitionsareenumerated.
AllOSPFpackettypes(otherthantheOSPFHellopackets)dealwith
listsofLSAs.Forexample,LinkStateUpdatepacketsimplementthe
floodingofLSAsthroughouttheOSPFroutingdomain.Becauseof
this,OSPFprotocolpacketscannotbeparsedunlesstheformatof
LSAsisalsounderstood.TheformatofLSAsisdescribedinSection
A.4.
ThereceiveprocessingofOSPFpacketsisdetailedinSection8.2.
ThesendingofOSPFpacketsisexplainedinSection8.1.
145/188
3/2/2015
A.3.1TheOSPFpacketheader
EveryOSPFpacketstartswithastandard24byteheader.This
headercontainsalltheinformationnecessarytodeterminewhether
thepacketshouldbeacceptedforfurtherprocessing.This
determinationisdescribedinSection8.2ofthespecification.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Version#|Type|Packetlength|
+++++++++++++++++++++++++++++++++
|RouterID|
+++++++++++++++++++++++++++++++++
|AreaID|
+++++++++++++++++++++++++++++++++
|Checksum|AuType|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
Version#
TheOSPFversionnumber.Thisspecificationdocumentsversion2
oftheprotocol.
Type
TheOSPFpackettypesareasfollows.SeeSectionsA.3.2through
A.3.6fordetails.
146/188
3/2/2015
TypeDescription
________________________________
1Hello
2DatabaseDescription
3LinkStateRequest
4LinkStateUpdate
5LinkStateAcknowledgment
Packetlength
ThelengthoftheOSPFprotocolpacketinbytes.Thislength
includesthestandardOSPFheader.
RouterID
TheRouterIDofthepacket'ssource.
AreaID
A32bitnumberidentifyingtheareathatthispacketbelongs
to.AllOSPFpacketsareassociatedwithasinglearea.Most
travelasinglehoponly.Packetstravellingoveravirtual
linkarelabelledwiththebackboneAreaIDof0.0.0.0.
Checksum
ThestandardIPchecksumoftheentirecontentsofthepacket,
startingwiththeOSPFpacketheaderbutexcludingthe64bit
authenticationfield.Thischecksumiscalculatedasthe16bit
one'scomplementoftheone'scomplementsumofallthe16bit
wordsinthepacket,exceptingtheauthenticationfield.Ifthe
packet'slengthisnotanintegralnumberof16bitwords,the
packetispaddedwithabyteofzerobeforechecksumming.The
checksumisconsideredtobepartofthepacketauthentication
procedure;forsomeauthenticationtypesthechecksum
calculationisomitted.
AuType
Identifiestheauthenticationproceduretobeusedforthe
packet.AuthenticationisdiscussedinAppendixDofthe
specification.ConsultAppendixDforalistofthecurrently
definedauthenticationtypes.
147/188
3/2/2015
Authentication
A64bitfieldforusebytheauthenticationscheme.See
AppendixDfordetails.
A.3.2TheHellopacket
HellopacketsareOSPFpackettype1.Thesepacketsaresent
periodicallyonallinterfaces(includingvirtuallinks)inorderto
establishandmaintainneighborrelationships.Inaddition,Hello
Packetsaremulticastonthosephysicalnetworkshavingamulticast
orbroadcastcapability,enablingdynamicdiscoveryofneighboring
routers.
Allroutersconnectedtoacommonnetworkmustagreeoncertain
parameters(Networkmask,HelloIntervalandRouterDeadInterval).
TheseparametersareincludedinHellopackets,sothatdifferences
caninhibittheformingofneighborrelationships.Adetailed
explanationofthereceiveprocessingforHellopacketsispresented
inSection10.5.ThesendingofHellopacketsiscoveredinSection
148/188
3/2/2015
9.5.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Version#|1|Packetlength|
+++++++++++++++++++++++++++++++++
|RouterID|
+++++++++++++++++++++++++++++++++
|AreaID|
+++++++++++++++++++++++++++++++++
|Checksum|AuType|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|NetworkMask|
+++++++++++++++++++++++++++++++++
|HelloInterval|Options|RtrPri|
+++++++++++++++++++++++++++++++++
|RouterDeadInterval|
+++++++++++++++++++++++++++++++++
|DesignatedRouter|
+++++++++++++++++++++++++++++++++
|BackupDesignatedRouter|
+++++++++++++++++++++++++++++++++
|Neighbor|
+++++++++++++++++++++++++++++++++
|...|
Networkmask
Thenetworkmaskassociatedwiththisinterface.Forexample,
iftheinterfaceistoaclassBnetworkwhosethirdbyteis
usedforsubnetting,thenetworkmaskis0xffffff00.
Options
Theoptionalcapabilitiessupportedbytherouter,asdocumented
inSectionA.2.
HelloInterval
Thenumberofsecondsbetweenthisrouter'sHellopackets.
RtrPri
Thisrouter'sRouterPriority.Usedin(Backup)Designated
Routerelection.Ifsetto0,therouterwillbeineligibleto
become(Backup)DesignatedRouter.
RouterDeadInterval
Thenumberofsecondsbeforedeclaringasilentrouterdown.
DesignatedRouter
TheidentityoftheDesignatedRouterforthisnetwork,inthe
viewofthesendingrouter.TheDesignatedRouterisidentified
herebyitsIPinterfaceaddressonthenetwork.Setto0.0.0.0
149/188
3/2/2015
ifthereisnoDesignatedRouter.
BackupDesignatedRouter
TheidentityoftheBackupDesignatedRouterforthisnetwork,
intheviewofthesendingrouter.TheBackupDesignatedRouter
isidentifiedherebyitsIPinterfaceaddressonthenetwork.
Setto0.0.0.0ifthereisnoBackupDesignatedRouter.
Neighbor
TheRouterIDsofeachrouterfromwhomvalidHellopacketshave
beenseenrecentlyonthenetwork.Recentlymeansinthelast
RouterDeadIntervalseconds.
A.3.3TheDatabaseDescriptionpacket
DatabaseDescriptionpacketsareOSPFpackettype2.Thesepackets
areexchangedwhenanadjacencyisbeinginitialized.Theydescribe
thecontentsofthelinkstatedatabase.Multiplepacketsmaybe
usedtodescribethedatabase.Forthispurposeapollresponse
procedureisused.Oneoftheroutersisdesignatedtobethe
master,theothertheslave.ThemastersendsDatabaseDescription
packets(polls)whichareacknowledgedbyDatabaseDescription
packetssentbytheslave(responses).Theresponsesarelinkedto
thepollsviathepackets'DDsequencenumbers.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
|RouterID|
+++++++++++++++++++++++++++++++++
|AreaID|
+++++++++++++++++++++++++++++++++
|Checksum|AuType|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|InterfaceMTU|Options|0|0|0|0|0|I|M|MS
+++++++++++++++++++++++++++++++++
|DDsequencenumber|
+++++++++++++++++++++++++++++++++
||
++
||
+AnLSAHeader+
||
++
||
++
||
+++++++++++++++++++++++++++++++++
|...|
150/188
3/2/2015
TheformatoftheDatabaseDescriptionpacketisverysimilarto
boththeLinkStateRequestandLinkStateAcknowledgmentpackets.
Themainpartofallthreeisalistofitems,eachitemdescribing
apieceofthelinkstatedatabase.ThesendingofDatabase
DescriptionPacketsisdocumentedinSection10.8.Thereceptionof
DatabaseDescriptionpacketsisdocumentedinSection10.6.
InterfaceMTU
ThesizeinbytesofthelargestIPdatagramthatcanbesent
outtheassociatedinterface,withoutfragmentation.TheMTUs
ofcommonInternetlinktypescanbefoundinTable71of
[Ref22].InterfaceMTUshouldbesetto0inDatabase
Descriptionpacketssentovervirtuallinks.
Options
Theoptionalcapabilitiessupportedbytherouter,asdocumented
inSectionA.2.
Ibit
TheInitbit.Whensetto1,thispacketisthefirstinthe
sequenceofDatabaseDescriptionPackets.
Mbit
TheMorebit.Whensetto1,itindicatesthatmoreDatabase
DescriptionPacketsaretofollow.
MSbit
TheMaster/Slavebit.Whensetto1,itindicatesthatthe
routeristhemasterduringtheDatabaseExchangeprocess.
Otherwise,therouteristheslave.
DDsequencenumber
UsedtosequencethecollectionofDatabaseDescriptionPackets.
Theinitialvalue(indicatedbytheInitbitbeingset)should
beunique.TheDDsequencenumberthenincrementsuntilthe
completedatabasedescriptionhasbeensent.
Therestofthepacketconsistsofa(possiblypartial)listofthe
linkstatedatabase'spieces.EachLSAinthedatabaseisdescribed
byitsLSAheader.TheLSAheaderisdocumentedinSectionA.4.1.
Itcontainsalltheinformationrequiredtouniquelyidentifyboth
theLSAandtheLSA'scurrentinstance.
A.3.4TheLinkStateRequestpacket
LinkStateRequestpacketsareOSPFpackettype3.Afterexchanging
DatabaseDescriptionpacketswithaneighboringrouter,aroutermay
findthatpartsofitslinkstatedatabaseareoutofdate.The
LinkStateRequestpacketisusedtorequestthepiecesofthe
neighbor'sdatabasethataremoreuptodate.MultipleLinkState
Requestpacketsmayneedtobeused.
ArouterthatsendsaLinkStateRequestpackethasinmindthe
151/188
3/2/2015
preciseinstanceofthedatabasepiecesitisrequesting.Each
instanceisdefinedbyitsLSsequencenumber,LSchecksum,andLS
age,althoughthesefieldsarenotspecifiedintheLinkState
RequestPacketitself.Theroutermayreceiveevenmorerecent
instancesinresponse.
ThesendingofLinkStateRequestpacketsisdocumentedinSection
10.9.ThereceptionofLinkStateRequestpacketsisdocumentedin
Section10.7.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
|RouterID|
+++++++++++++++++++++++++++++++++
|AreaID|
+++++++++++++++++++++++++++++++++
|Checksum|AuType|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|LStype|
+++++++++++++++++++++++++++++++++
|LinkStateID|
+++++++++++++++++++++++++++++++++
|AdvertisingRouter|
+++++++++++++++++++++++++++++++++
|...|
EachLSArequestedisspecifiedbyitsLStype,LinkStateID,and
AdvertisingRouter.ThisuniquelyidentifiestheLSA,butnotits
instance.LinkStateRequestpacketsareunderstoodtoberequests
forthemostrecentinstance(whateverthatmightbe).
152/188
3/2/2015
A.3.5TheLinkStateUpdatepacket
LinkStateUpdatepacketsareOSPFpackettype4.Thesepackets
implementthefloodingofLSAs.EachLinkStateUpdatepacket
carriesacollectionofLSAsonehopfurtherfromtheirorigin.
SeveralLSAsmaybeincludedinasinglepacket.
LinkStateUpdatepacketsaremulticastonthosephysicalnetworks
thatsupportmulticast/broadcast.Inordertomaketheflooding
procedurereliable,floodedLSAsareacknowledgedinLinkState
Acknowledgmentpackets.IfretransmissionofcertainLSAsis
necessary,theretransmittedLSAsarealwayssentdirectlytothe
neighbor.FormoreinformationonthereliablefloodingofLSAs,
consultSection13.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
|RouterID|
+++++++++++++++++++++++++++++++++
|AreaID|
+++++++++++++++++++++++++++++++++
|Checksum|AuType|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|#LSAs|
+++++++++++++++++++++++++++++++++
||
+++
|LSAs|
+++
|...|
153/188
3/2/2015
#LSAs
ThenumberofLSAsincludedinthisupdate.
ThebodyoftheLinkStateUpdatepacketconsistsofalistofLSAs.
EachLSAbeginswithacommon20byteheader,describedinSection
A.4.1.DetailedformatsofthedifferenttypesofLSAsaredescribed
inSectionA.4.
A.3.6TheLinkStateAcknowledgmentpacket
LinkStateAcknowledgmentPacketsareOSPFpackettype5.Tomake
thefloodingofLSAsreliable,floodedLSAsareexplicitly
acknowledged.Thisacknowledgmentisaccomplishedthroughthe
154/188
3/2/2015
sendingandreceivingofLinkStateAcknowledgmentpackets.
MultipleLSAscanbeacknowledgedinasingleLinkState
Acknowledgmentpacket.
Dependingonthestateofthesendinginterfaceandthesenderof
thecorrespondingLinkStateUpdatepacket,aLinkState
Acknowledgmentpacketissenteithertothemulticastaddress
AllSPFRouters,tothemulticastaddressAllDRouters,orasa
unicast.ThesendingofLinkStateAcknowledgementpacketsis
documentedinSection13.5.ThereceptionofLinkState
AcknowledgementpacketsisdocumentedinSection13.7.
TheformatofthispacketissimilartothatoftheDataDescription
packet.ThebodyofbothpacketsissimplyalistofLSAheaders.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
|RouterID|
+++++++++++++++++++++++++++++++++
|AreaID|
+++++++++++++++++++++++++++++++++
|Checksum|AuType|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
|Authentication|
+++++++++++++++++++++++++++++++++
||
++
||
+AnLSAHeader+
||
++
||
++
||
+++++++++++++++++++++++++++++++++
|...|
EachacknowledgedLSAisdescribedbyitsLSAheader.TheLSA
headerisdocumentedinSectionA.4.1.Itcontainsallthe
informationrequiredtouniquelyidentifyboththeLSAandtheLSA's
currentinstance.
155/188
3/2/2015
A.4LSAformats
ThismemodefinesfivedistincttypesofLSAs.EachLSAbeginswith
astandard20byteLSAheader.ThisheaderisexplainedinSection
A.4.1.SucceedingsectionsthendiagramtheseparateLSAtypes.
EachLSAdescribesapieceoftheOSPFroutingdomain.Everyrouter
originatesarouterLSA.Inaddition,whenevertherouteris
electedDesignatedRouter,itoriginatesanetworkLSA.Othertypes
ofLSAsmayalsobeoriginated(seeSection12.4).AllLSAsare
thenfloodedthroughouttheOSPFroutingdomain.Theflooding
algorithmisreliable,ensuringthatallroutershavethesame
collectionofLSAs.(SeeSection13formoreinformationconcerning
thefloodingalgorithm).ThiscollectionofLSAsiscalledthe
linkstatedatabase.
Fromthelinkstatedatabase,eachrouterconstructsashortestpath
treewithitselfasroot.Thisyieldsaroutingtable(seeSection
11).Forthedetailsoftheroutingtablebuildprocess,see
Section16.
156/188
3/2/2015
A.4.1TheLSAheader
AllLSAsbeginwithacommon20byteheader.Thisheadercontains
enoughinformationtouniquelyidentifytheLSA(LStype,LinkState
ID,andAdvertisingRouter).MultipleinstancesoftheLSAmay
existintheroutingdomainatthesametime.Itisthennecessary
todeterminewhichinstanceismorerecent.Thisisaccomplishedby
examiningtheLSage,LSsequencenumberandLSchecksumfieldsthat
arealsocontainedintheLSAheader.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|LSage|Options|LStype|
+++++++++++++++++++++++++++++++++
|LinkStateID|
+++++++++++++++++++++++++++++++++
|AdvertisingRouter|
+++++++++++++++++++++++++++++++++
|LSsequencenumber|
+++++++++++++++++++++++++++++++++
|LSchecksum|length|
+++++++++++++++++++++++++++++++++
LSage
ThetimeinsecondssincetheLSAwasoriginated.
Options
Theoptionalcapabilitiessupportedbythedescribedportionof
theroutingdomain.OSPF'soptionalcapabilitiesaredocumented
inSectionA.2.
LStype
ThetypeoftheLSA.EachLSAtypehasaseparateadvertisement
format.TheLSAtypesdefinedinthismemoareasfollows(see
Section12.1.3forfurtherexplanation):
157/188
3/2/2015
LSTypeDescription
___________________________________
1RouterLSAs
2NetworkLSAs
3SummaryLSAs(IPnetwork)
4SummaryLSAs(ASBR)
5ASexternalLSAs
LinkStateID
Thisfieldidentifiestheportionoftheinternetenvironment
thatisbeingdescribedbytheLSA.Thecontentsofthisfield
dependontheLSA'sLStype.Forexample,innetworkLSAsthe
LinkStateIDissettotheIPinterfaceaddressofthe
network'sDesignatedRouter(fromwhichthenetwork'sIPaddress
canbederived).TheLinkStateIDisfurtherdiscussedin
Section12.1.4.
AdvertisingRouter
TheRouterIDoftherouterthatoriginatedtheLSA.For
example,innetworkLSAsthisfieldisequaltotheRouterIDof
thenetwork'sDesignatedRouter.
LSsequencenumber
DetectsoldorduplicateLSAs.SuccessiveinstancesofanLSA
aregivensuccessiveLSsequencenumbers.SeeSection12.1.6
formoredetails.
LSchecksum
TheFletcherchecksumofthecompletecontentsoftheLSA,
includingtheLSAheaderbutexcludingtheLSagefield.See
Section12.1.7formoredetails.
length
ThelengthinbytesoftheLSA.Thisincludesthe20byteLSA
header.
A.4.2RouterLSAs
RouterLSAsaretheType1LSAs.Eachrouterinanareaoriginates
arouterLSA.TheLSAdescribesthestateandcostoftherouter's
links(i.e.,interfaces)tothearea.Alloftherouter'slinksto
theareamustbedescribedinasinglerouterLSA.Fordetails
concerningtheconstructionofrouterLSAs,seeSection12.4.1.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|LSage|Options|1|
+++++++++++++++++++++++++++++++++
|LinkStateID|
158/188
3/2/2015
+++++++++++++++++++++++++++++++++
|AdvertisingRouter|
+++++++++++++++++++++++++++++++++
|LSsequencenumber|
+++++++++++++++++++++++++++++++++
|LSchecksum|length|
+++++++++++++++++++++++++++++++++
|0|V|E|B|0|#links|
+++++++++++++++++++++++++++++++++
|LinkID|
+++++++++++++++++++++++++++++++++
|LinkData|
+++++++++++++++++++++++++++++++++
|Type|#TOS|metric|
+++++++++++++++++++++++++++++++++
|...|
+++++++++++++++++++++++++++++++++
|TOS|0|TOSmetric|
+++++++++++++++++++++++++++++++++
|LinkID|
+++++++++++++++++++++++++++++++++
|LinkData|
+++++++++++++++++++++++++++++++++
|...|
InrouterLSAs,theLinkStateIDfieldissettotherouter'sOSPF
RouterID.RouterLSAsarefloodedthroughoutasingleareaonly.
bitV
Whenset,therouterisanendpointofoneormorefully
adjacentvirtuallinkshavingthedescribedareaasTransitarea
(Visforvirtuallinkendpoint).
bitE
Whenset,therouterisanASboundaryrouter(Eisfor
external).
bitB
Whenset,therouterisanareaborderrouter(Bisforborder).
#links
ThenumberofrouterlinksdescribedinthisLSA.Thismustbe
thetotalcollectionofrouterlinks(i.e.,interfaces)tothe
area.
Thefollowingfieldsareusedtodescribeeachrouterlink(i.e.,
interface).Eachrouterlinkistyped(seethebelowTypefield).
TheTypefieldindicatesthekindoflinkbeingdescribed.Itmay
bealinktoatransitnetwork,toanotherrouterortoastub
network.Thevaluesofalltheotherfieldsdescribingarouter
linkdependonthelink'sType.Forexample,eachlinkhasan
associated32bitLinkDatafield.Forlinkstostubnetworksthis
fieldspecifiesthenetwork'sIPaddressmask.Forotherlinktypes
theLinkDatafieldspecifiestherouterinterface'sIPaddress.
159/188
3/2/2015
Type
Aquickdescriptionoftherouterlink.Oneofthefollowing.
Notethathostroutesareclassifiedaslinkstostubnetworks
withnetworkmaskof0xffffffff.
TypeDescription
__________________________________________________
1Pointtopointconnectiontoanotherrouter
2Connectiontoatransitnetwork
3Connectiontoastubnetwork
4Virtuallink
LinkID
Identifiestheobjectthatthisrouterlinkconnectsto.Value
dependsonthelink'sType.Whenconnectingtoanobjectthat
alsooriginatesanLSA(i.e.,anotherrouteroratransit
network)theLinkIDisequaltotheneighboringLSA'sLink
StateID.Thisprovidesthekeyforlookinguptheneighboring
LSAinthelinkstatedatabaseduringtheroutingtable
calculation.SeeSection12.2formoredetails.
TypeLinkID
______________________________________
1Neighboringrouter'sRouterID
2IPaddressofDesignatedRouter
3IPnetwork/subnetnumber
4Neighboringrouter'sRouterID
LinkData
Valueagaindependsonthelink'sTypefield.Forconnectionsto
stubnetworks,LinkDataspecifiesthenetwork'sIPaddress
mask.Forunnumberedpointtopointconnections,itspecifies
theinterface'sMIBII[Ref8]ifIndexvalue.Fortheotherlink
typesitspecifiestherouterinterface'sIPaddress.This
latterpieceofinformationisneededduringtheroutingtable
buildprocess,whencalculatingtheIPaddressofthenexthop.
SeeSection16.1.1formoredetails.
160/188
3/2/2015
#TOS
ThenumberofdifferentTOSmetricsgivenforthislink,not
countingtherequiredlinkmetric(referredtoastheTOS0
metricin[Ref9]).Forexample,ifnoadditionalTOSmetrics
aregiven,thisfieldissetto0.
metric
Thecostofusingthisrouterlink.
AdditionalTOSspecificinformationmayalsobeincluded,for
backwardcompatibilitywithpreviousversionsoftheOSPF
specification([Ref9]).Withineachlink,andforeachdesiredTOS,
TOSTOSspecificlinkinformationmaybeencodedasfollows:
TOSIPTypeofServicethatthismetricrefersto.Theencodingof
TOSinOSPFLSAsisdescribedinSection12.3.
TOSmetric
TOSspecificmetricinformation.
A.4.3NetworkLSAs
NetworkLSAsaretheType2LSAs.AnetworkLSAisoriginatedfor
eachbroadcastandNBMAnetworkintheareawhichsupportstwoor
morerouters.ThenetworkLSAisoriginatedbythenetwork's
DesignatedRouter.TheLSAdescribesallroutersattachedtothe
network,includingtheDesignatedRouteritself.TheLSA'sLink
StateIDfieldliststheIPinterfaceaddressoftheDesignated
Router.
161/188
3/2/2015
Thedistancefromthenetworktoallattachedroutersiszero.This
iswhymetricfieldsneednotbespecifiedinthenetworkLSA.For
detailsconcerningtheconstructionofnetworkLSAs,seeSection
12.4.2.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|LSage|Options|2|
+++++++++++++++++++++++++++++++++
|LinkStateID|
+++++++++++++++++++++++++++++++++
|AdvertisingRouter|
+++++++++++++++++++++++++++++++++
|LSsequencenumber|
+++++++++++++++++++++++++++++++++
|LSchecksum|length|
+++++++++++++++++++++++++++++++++
|NetworkMask|
+++++++++++++++++++++++++++++++++
|AttachedRouter|
+++++++++++++++++++++++++++++++++
|...|
NetworkMask
TheIPaddressmaskforthenetwork.Forexample,aclassA
networkwouldhavethemask0xff000000.
AttachedRouter
TheRouterIDsofeachoftheroutersattachedtothenetwork.
Actually,onlythoseroutersthatarefullyadjacenttothe
DesignatedRouterarelisted.TheDesignatedRouterincludes
itselfinthislist.Thenumberofroutersincludedcanbe
deducedfromtheLSAheader'slengthfield.
162/188
3/2/2015
A.4.4SummaryLSAs
SummaryLSAsaretheType3and4LSAs.TheseLSAsareoriginated
byareaborderrouters.SummaryLSAsdescribeinterarea
destinations.Fordetailsconcerningtheconstructionofsummary
LSAs,seeSection12.4.3.
Type3summaryLSAsareusedwhenthedestinationisanIPnetwork.
InthiscasetheLSA'sLinkStateIDfieldisanIPnetworknumber
(ifnecessary,theLinkStateIDcanalsohaveoneormoreofthe
network's"host"bitsset;seeAppendixEfordetails).Whenthe
destinationisanASboundaryrouter,aType4summaryLSAisused,
andtheLinkStateIDfieldistheASboundaryrouter'sOSPFRouter
ID.(Toseewhyitisnecessarytoadvertisethelocationofeach
ASBR,consultSection16.4.)OtherthanthedifferenceintheLink
StateIDfield,theformatofType3and4summaryLSAsis
identical.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|LSage|Options|3or4|
+++++++++++++++++++++++++++++++++
|LinkStateID|
+++++++++++++++++++++++++++++++++
|AdvertisingRouter|
+++++++++++++++++++++++++++++++++
|LSsequencenumber|
+++++++++++++++++++++++++++++++++
|LSchecksum|length|
+++++++++++++++++++++++++++++++++
|NetworkMask|
+++++++++++++++++++++++++++++++++
|0|metric|
+++++++++++++++++++++++++++++++++
|TOS|TOSmetric|
+++++++++++++++++++++++++++++++++
|...|
163/188
3/2/2015
Forstubareas,Type3summaryLSAscanalsobeusedtodescribea
(perarea)defaultroute.Defaultsummaryroutesareusedinstub
areasinsteadoffloodingacompletesetofexternalroutes.When
describingadefaultsummaryroute,thesummaryLSA'sLinkStateID
isalwayssettoDefaultDestination(0.0.0.0)andtheNetworkMask
issetto0.0.0.0.
NetworkMask
ForType3summaryLSAs,thisindicatesthedestination
network'sIPaddressmask.Forexample,whenadvertisingthe
locationofaclassAnetworkthevalue0xff000000wouldbe
used.ThisfieldisnotmeaningfulandmustbezeroforType4
summaryLSAs.
metric
Thecostofthisroute.Expressedinthesameunitsasthe
interfacecostsintherouterLSAs.
specification([Ref9]).ForeachdesiredTOS,TOSspecific
informationisencodedasfollows:
TOSIPTypeofServicethatthismetricrefersto.Theencodingof
TOSinOSPFLSAsisdescribedinSection12.3.
TOSmetric
A.4.5ASexternalLSAs
ASexternalLSAsaretheType5LSAs.TheseLSAsareoriginatedby
ASboundaryrouters,anddescribedestinationsexternaltotheAS.
FordetailsconcerningtheconstructionofASexternalLSAs,see
164/188
3/2/2015
Section12.4.3.
ASexternalLSAsusuallydescribeaparticularexternaldestination.
FortheseLSAstheLinkStateIDfieldspecifiesanIPnetwork
number(ifnecessary,theLinkStateIDcanalsohaveoneormoreof
thenetwork's"host"bitsset;seeAppendixEfordetails).AS
externalLSAsarealsousedtodescribeadefaultroute.Default
routesareusedwhennospecificrouteexiststothedestination.
Whendescribingadefaultroute,theLinkStateIDisalwayssetto
DefaultDestination(0.0.0.0)andtheNetworkMaskissetto0.0.0.0.
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|LSage|Options|5|
+++++++++++++++++++++++++++++++++
|LinkStateID|
+++++++++++++++++++++++++++++++++
|AdvertisingRouter|
+++++++++++++++++++++++++++++++++
|LSsequencenumber|
+++++++++++++++++++++++++++++++++
|LSchecksum|length|
+++++++++++++++++++++++++++++++++
|NetworkMask|
+++++++++++++++++++++++++++++++++
|E|0|metric|
+++++++++++++++++++++++++++++++++
|Forwardingaddress|
+++++++++++++++++++++++++++++++++
|ExternalRouteTag|
+++++++++++++++++++++++++++++++++
|E|TOS|TOSmetric|
+++++++++++++++++++++++++++++++++
|Forwardingaddress|
+++++++++++++++++++++++++++++++++
|ExternalRouteTag|
+++++++++++++++++++++++++++++++++
|...|
NetworkMask
TheIPaddressmaskfortheadvertiseddestination.For
example,whenadvertisingaclassAnetworkthemask0xff000000
wouldbeused.
bitE
Thetypeofexternalmetric.IfbitEisset,themetric
specifiedisaType2externalmetric.Thismeansthemetricis
consideredlargerthananylinkstatepath.IfbitEiszero,
thespecifiedmetricisaType1externalmetric.Thismeans
thatitisexpressedinthesameunitsasthelinkstatemetric
(i.e.,thesameunitsasinterfacecost).
metric
165/188
3/2/2015
Thecostofthisroute.Interpretationdependsontheexternal
typeindication(bitEabove).
Forwardingaddress
Datatrafficfortheadvertiseddestinationwillbeforwardedto
thisaddress.IftheForwardingaddressissetto0.0.0.0,data
trafficwillbeforwardedinsteadtotheLSA'soriginator(i.e.,
theresponsibleASboundaryrouter).
ExternalRouteTag
A32bitfieldattachedtoeachexternalroute.Thisisnot
usedbytheOSPFprotocolitself.Itmaybeusedtocommunicate
informationbetweenASboundaryrouters;theprecisenatureof
suchinformationisoutsidethescopeofthisspecification.
specification([Ref9]).ForeachdesiredTOS,TOSspecific
informationisencodedasfollows:
TOSTheTypeofServicethatthefollowingfieldsconcern.The
encodingofTOSinOSPFLSAsisdescribedinSection12.3.
bitE
Forbackwardcompatibilitywith[Ref9].
TOSmetric
Forwardingaddress
ExternalRouteTag
166/188
3/2/2015
B.ArchitecturalConstants
SeveralOSPFprotocolparametershavefixedarchitecturalvalues.
Theseparametershavebeenreferredtointhetextbynamessuchas
LSRefreshTime.Thesamenamingconventionisusedforthe
configurableprotocolparameters.TheyaredefinedinAppendixC.
Thenameofeacharchitecturalconstantfollows,togetherwithits
valueandashortdescriptionofitsfunction.
LSRefreshTime
Themaximumtimebetweendistinctoriginationsofanyparticular
LSA.IftheLSagefieldofoneoftherouter'sselforiginated
LSAsreachesthevalueLSRefreshTime,anewinstanceoftheLSA
isoriginated,eventhoughthecontentsoftheLSA(apartfrom
theLSAheader)willbethesame.ThevalueofLSRefreshTimeis
setto30minutes.
MinLSInterval
Theminimumtimebetweendistinctoriginationsofanyparticular
LSA.ThevalueofMinLSIntervalissetto5seconds.
MinLSArrival
ForanyparticularLSA,theminimumtimethatmustelapse
betweenreceptionofnewLSAinstancesduringflooding.LSA
instancesreceivedathigherfrequenciesarediscarded.The
valueofMinLSArrivalissetto1second.
MaxAge
ThemaximumagethatanLSAcanattain.WhenanLSA'sLSage
fieldreachesMaxAge,itisrefloodedinanattempttoflushthe
LSAfromtheroutingdomain(SeeSection14).LSAsofageMaxAge
arenotusedintheroutingtablecalculation.Thevalueof
MaxAgeissetto1hour.
CheckAge
WhentheageofanLSAinthelinkstatedatabasehitsa
multipleofCheckAge,theLSA'schecksumisverified.An
incorrectchecksumatthistimeindicatesaseriouserror.The
valueofCheckAgeissetto5minutes.
167/188
3/2/2015
MaxAgeDiff
Themaximumtimedispersionthatcanoccur,asanLSAisflooded
throughouttheAS.Mostofthistimeisaccountedforbythe
LSAssittingonrouteroutputqueues(andthereforenotaging)
duringthefloodingprocess.ThevalueofMaxAgeDiffissetto
15minutes.
LSInfinity
Themetricvalueindicatingthatthedestinationdescribedbyan
LSAisunreachable.UsedinsummaryLSAsandASexternalLSAsas
analternativetoprematureaging(seeSection14.1).Itis
definedtobethe24bitbinaryvalueofallones:0xffffff.
DefaultDestination
TheDestinationIDthatindicatesthedefaultroute.Thisroute
isusedwhennoothermatchingroutingtableentrycanbefound.
ThedefaultdestinationcanonlybeadvertisedinASexternal
LSAsandinstubareas'type3summaryLSAs.Itsvalueisthe
IPaddress0.0.0.0.ItsassociatedNetworkMaskisalsoalways
0.0.0.0.
InitialSequenceNumber
ThevalueusedforLSSequenceNumberwhenoriginatingthefirst
instanceofanyLSA.Itsvalueisthesigned32bitinteger
0x80000001.
MaxSequenceNumber
ThemaximumvaluethatLSSequenceNumbercanattain.Itsvalue
isthesigned32bitinteger0x7fffffff.
C.ConfigurableConstants
TheOSPFprotocolhasquiteafewconfigurableparameters.These
parametersarelistedbelow.Theyaregroupedintogeneral
functionalcategories(areaparameters,interfaceparameters,etc.).
Samplevaluesaregivenforsomeoftheparameters.
Someparametersettingsneedtobeconsistentamonggroupsof
routers.Forexample,allroutersinanareamustagreeonthat
area'sparameters,andallroutersattachedtoanetworkmustagree
onthatnetwork'sIPnetworknumberandmask.
Someparametersmaybedeterminedbyrouteralgorithmsoutsideof
thisspecification(e.g.,theaddressofahostconnectedtothe
routerviaaSLIPline).FromOSPF'spointofview,theseitemsare
168/188
3/2/2015
stillconfigurable.
C.1Globalparameters
Ingeneral,aseparatecopyoftheOSPFprotocolisrunforeach
area.Becauseofthis,mostconfigurationparametersare
definedonaperareabasis.Thefewglobalconfiguration
parametersarelistedbelow.
RouterID
Thisisa32bitnumberthatuniquelyidentifiestherouter
intheAutonomousSystem.OnealgorithmforRouterID
assignmentistochoosethelargestorsmallestIPaddress
assignedtotherouter.Ifarouter'sOSPFRouterIDis
changed,therouter'sOSPFsoftwareshouldberestarted
beforethenewRouterIDtakeseffect.Beforerestartingin
ordertochangeitsRouterID,theroutershouldflushits
selforiginatedLSAsfromtheroutingdomain(seeSection
14.1),ortheywillpersistforuptoMaxAgeminutes.
RFC1583Compatibility
ControlsthepreferencerulesusedinSection16.4when
choosingamongmultipleASexternalLSAsadvertisingthe
samedestination.Whensetto"enabled",thepreference
rulesremainthosespecifiedbyRFC1583([Ref9]).Whenset
to"disabled",thepreferencerulesarethosestatedin
Section16.4.1,whichpreventroutingloopswhenAS
externalLSAsforthesamedestinationhavebeenoriginated
fromdifferentareas.Setto"enabled"bydefault.
Inordertominimizethechanceofroutingloops,allOSPF
routersinanOSPFroutingdomainshouldhave
RFC1583Compatibilitysetidentically.Whentherearerouters
presentthathavenotbeenupdatedwiththefunctionality
specifiedinSection16.4.1ofthismemo,allroutersshould
haveRFC1583Compatibilitysetto"enabled".Otherwise,all
routersshouldhaveRFC1583Compatibilitysetto"disabled",
preventingallroutingloops.
C.2Areaparameters
Allroutersbelongingtoanareamustagreeonthatarea's
configuration.Disagreementsbetweentworouterswillleadto
aninabilityforadjacenciestoformbetweenthem,witha
resultinghindrancetotheflowofroutingprotocolanddata
traffic.Thefollowingitemsmustbeconfiguredforanarea:
AreaID
Thisisa32bitnumberthatidentifiesthearea.TheArea
IDof0.0.0.0isreservedforthebackbone.Ifthearea
representsasubnettednetwork,theIPnetworknumberofthe
subnettednetworkmaybeusedfortheAreaID.
Listofaddressranges
AnOSPFareaisdefinedasalistofaddressranges.Each
169/188
3/2/2015
addressrangeconsistsofthefollowingitems:
[IPaddress,mask]
DescribesthecollectionofIPaddressescontained
intheaddressrange.Networksandhostsare
assignedtoanareadependingonwhethertheir
addressesfallintooneofthearea'sdefining
addressranges.Routersareviewedasbelongingto
multipleareas,dependingontheirattached
networks'areamembership.
StatusSettoeitherAdvertiseorDoNotAdvertise.Routing
informationiscondensedatareaboundaries.
Externaltothearea,atmostasinglerouteis
advertised(viaasummaryLSA)foreachaddress
range.Therouteisadvertisedifandonlyifthe
addressrange'sStatusissettoAdvertise.
Unadvertisedrangesallowtheexistenceofcertain
networkstobeintentionallyhiddenfromother
areas.StatusissettoAdvertisebydefault.
Asanexample,supposeanIPsubnettednetworkistobeits
ownOSPFarea.Theareawouldbeconfiguredasasingle
addressrange,whoseIPaddressistheaddressofthe
subnettednetwork,andwhosemaskisthenaturalclassA,B,
orCaddressmask.Asingleroutewouldbeadvertised
externaltothearea,describingtheentiresubnetted
network.
WhetherASexternalLSAswillbefloodedinto/throughoutthe
area.IfASexternalLSAsareexcludedfromthearea,the
areaiscalleda"stub".Internaltostubareas,routingto
externaldestinationswillbebasedsolelyonadefault
summaryroute.Thebackbonecannotbeconfiguredasastub
area.Also,virtuallinkscannotbeconfiguredthroughstub
areas.Formoreinformation,seeSection3.6.
StubDefaultCost
Iftheareahasbeenconfiguredasastubarea,andthe
routeritselfisanareaborderrouter,thenthe
StubDefaultCostindicatesthecostofthedefaultsummary
LSAthattheroutershouldadvertiseintothearea.
C.3Routerinterfaceparameters
Someoftheconfigurablerouterinterfaceparameters(suchasIP
interfaceaddressandsubnetmask)actuallyimplypropertiesof
theattachednetworks,andthereforemustbeconsistentacross
alltheroutersattachedtothatnetwork.Theparametersthat
mustbeconfiguredforarouterinterfaceare:
170/188
3/2/2015
IPinterfaceaddress
TheIPprotocoladdressforthisinterface.Thisuniquely
identifiestherouterovertheentireinternet.AnIP
addressisnotrequiredonpointtopointnetworks.Sucha
pointtopointnetworkiscalled"unnumbered".
IPinterfacemask
Alsoreferredtoasthesubnet/networkmask,thisindicates
theportionoftheIPinterfaceaddressthatidentifiesthe
attachednetwork.MaskingtheIPinterfaceaddresswiththe
IPinterfacemaskyieldstheIPnetworknumberofthe
attachednetwork.Onpointtopointnetworksandvirtual
links,theIPinterfacemaskisnotdefined.Onthese
networks,thelinkitselfisnotassignedanIPnetwork
number,andsotheaddressesofeachsideofthelinkare
assignedindependently,iftheyareassignedatall.
AreaID
TheOSPFareatowhichtheattachednetworkbelongs.
Interfaceoutputcost
Thecostofsendingapacketontheinterface,expressedin
thelinkstatemetric.Thisisadvertisedasthelinkcost
forthisinterfaceintherouter'srouterLSA.Theinterface
outputcostmustalwaysbegreaterthan0.
RxmtInterval
ThenumberofsecondsbetweenLSAretransmissions,for
adjacenciesbelongingtothisinterface.Alsousedwhen
retransmittingDatabaseDescriptionandLinkStateRequest
Packets.Thisshouldbewellovertheexpectedroundtrip
delaybetweenanytworoutersontheattachednetwork.The
settingofthisvalueshouldbeconservativeorneedless
retransmissionswillresult.Samplevalueforalocalarea
network:5seconds.
InfTransDelay
TheestimatednumberofsecondsittakestotransmitaLink
StateUpdatePacketoverthisinterface.LSAscontainedin
theupdatepacketmusthavetheirageincrementedbythis
amountbeforetransmission.Thisvalueshouldtakeinto
accountthetransmissionandpropagationdelaysofthe
interface.Itmustbegreaterthan0.Samplevaluefora
localareanetwork:1second.
RouterPriority
An8bitunsignedinteger.Whentworoutersattachedtoa
networkbothattempttobecomeDesignatedRouter,theone
withthehighestRouterPrioritytakesprecedence.Ifthere
isstillatie,therouterwiththehighestRouterIDtakes
precedence.ArouterwhoseRouterPriorityissetto0is
ineligibletobecomeDesignatedRouterontheattached
171/188
3/2/2015
network.RouterPriorityisonlyconfiguredforinterfaces
tobroadcastandNBMAnetworks.
HelloInterval
Thelengthoftime,inseconds,betweentheHelloPackets
thattheroutersendsontheinterface.Thisvalueis
advertisedintherouter'sHelloPackets.Itmustbethe
sameforallroutersattachedtoacommonnetwork.The
smallertheHelloInterval,thefastertopologicalchanges
willbedetected;however,moreOSPFroutingprotocol
trafficwillensue.SamplevalueforaX.25PDNnetwork:30
seconds.Samplevalueforalocalareanetwork:10seconds.
RouterDeadInterval
Afterceasingtoheararouter'sHelloPackets,thenumber
ofsecondsbeforeitsneighborsdeclaretherouterdown.
Thisisalsoadvertisedintherouter'sHelloPacketsin
theirRouterDeadIntervalfield.Thisshouldbesome
multipleoftheHelloInterval(say4).Thisvalueagain
mustbethesameforallroutersattachedtoacommon
network.
AuType
Identifiestheauthenticationproceduretobeusedonthe
attachednetwork.Thisvaluemustbethesameforall
routersattachedtothenetwork.SeeAppendixDfora
discussionofthedefinedauthenticationtypes.
Authenticationkey
Thisconfigureddataallowstheauthenticationprocedureto
verifyOSPFprotocolpacketsreceivedovertheinterface.
Forexample,iftheAuTypeindicatessimplepassword,the
Authenticationkeywouldbeaclear64bitpassword.
AuthenticationkeysassociatedwiththeotherOSPF
authenticationtypesarediscussedinAppendixD.
C.4Virtuallinkparameters
Virtuallinksareusedtorestore/increaseconnectivityofthe
backbone.Virtuallinksmaybeconfiguredbetweenanypairof
areaborderroutershavinginterfacestoacommon(nonbackbone)
area.Thevirtuallinkappearsasanunnumberedpointtopoint
linkinthegraphforthebackbone.Thevirtuallinkmustbe
configuredinbothoftheareaborderrouters.
AvirtuallinkappearsinrouterLSAs(forthebackbone)asif
itwereaseparaterouterinterfacetothebackbone.Assuch,
ithasalloftheparametersassociatedwitharouterinterface
(seeSectionC.3).Althoughavirtuallinkactslikean
unnumberedpointtopointlink,itdoeshaveanassociatedIP
interfaceaddress.ThisaddressisusedastheIPsourcein
OSPFprotocolpacketsitsendsalongthevirtuallink,andis
setdynamicallyduringtheroutingtablebuildprocess.
Interfaceoutputcostisalsosetdynamicallyonvirtuallinks
tobethecostoftheintraareapathbetweenthetworouters.
TheparameterRxmtIntervalmustbeconfigured,andshouldbe
wellovertheexpectedroundtripdelaybetweenthetworouters.
172/188
3/2/2015
Thismaybehardtoestimateforavirtuallink;itisbetterto
erronthesideofmakingittoolarge.RouterPriorityisnot
usedonvirtuallinks.
Avirtuallinkisdefinedbythefollowingtwoconfigurable
parameters:theRouterIDofthevirtuallink'sotherendpoint,
andthe(nonbackbone)areathroughwhichthevirtuallinkruns
(referredtoasthevirtuallink'sTransitarea).Virtuallinks
cannotbeconfiguredthroughstubareas.
C.5NBMAnetworkparameters
OSPFtreatsanNBMAnetworkmuchlikeittreatsabroadcast
network.Sincetheremaybemanyroutersattachedtothe
network,aDesignatedRouterisselectedforthenetwork.This
DesignatedRouterthenoriginatesanetworkLSA,whichlistsall
routersattachedtotheNBMAnetwork.
However,duetothelackofbroadcastcapabilities,itmaybe
necessarytouseconfigurationparametersintheDesignated
Routerselection.Theseparameterswillonlyneedtobe
configuredinthoseroutersthatarethemselveseligibleto
becomeDesignatedRouter(i.e.,thoserouter'swhoseRouter
Priorityforthenetworkisnonzero),andthenonlyifno
automaticprocedurefordiscoveringneighborsexists:
Listofallotherattachedrouters
ThelistofallotherroutersattachedtotheNBMAnetwork.
EachrouterislistedbyitsIPinterfaceaddressonthe
network.Also,foreachrouterlisted,thatrouter's
eligibilitytobecomeDesignatedRoutermustbedefined.
WhenaninterfacetoaNBMAnetworkcomesup,therouter
sendsHelloPacketsonlytothoseneighborseligibleto
becomeDesignatedRouter,untiltheidentityofthe
DesignatedRouterisdiscovered.
PollInterval
Ifaneighboringrouterhasbecomeinactive(HelloPackets
havenotbeenseenforRouterDeadIntervalseconds),itmay
stillbenecessarytosendHelloPacketstothedead
neighbor.TheseHelloPacketswillbesentatthereduced
ratePollInterval,whichshouldbemuchlargerthan
HelloInterval.SamplevalueforaPDNX.25network:2
minutes.
C.6PointtoMultiPointnetworkparameters
OnPointtoMultiPointnetworks,itmaybenecessaryto
configurethesetofneighborsthataredirectlyreachableover
thePointtoMultiPointnetwork.Eachneighborisidentifiedby
itsIPaddressonthePointtoMultiPointnetwork.Designated
RoutersarenotelectedonPointtoMultiPointnetworks,sothe
DesignatedRoutereligibilityofconfiguredneighborsis
undefined.
Alternatively,neighborsonPointtoMultiPointnetworksmaybe
dynamicallydiscoveredbylowerlevelprotocolssuchasInverse
173/188
3/2/2015
ARP([Ref14]).
C.7Hostrouteparameters
HostroutesareadvertisedinrouterLSAsasstubnetworkswith
mask0xffffffff.Theyindicateeitherrouterinterfacesto
pointtopointnetworks,loopedrouterinterfaces,orIPhosts
thataredirectlyconnectedtotherouter(e.g.,viaaSLIP
line).Foreachhostdirectlyconnectedtotherouter,the
followingitemsmustbeconfigured:
HostIPaddress
TheIPaddressofthehost.
Costoflinktohost
Thecostofsendingapackettothehost,intermsofthe
linkstatemetric.However,sincethehostprobablyhas
onlyasingleconnectiontotheinternet,theactual
configuredcostinmanycasesisunimportant(i.e.,will
havenoeffectonrouting).
AreaID
TheOSPFareatowhichthehostbelongs.
D.Authentication
AllOSPFprotocolexchangesareauthenticated.TheOSPFpacket
header(seeSectionA.3.1)includesanauthenticationtypefield,
and64bitsofdataforusebytheappropriateauthenticationscheme
174/188
3/2/2015
(determinedbythetypefield).
Theauthenticationtypeisconfigurableonaperinterface(or
equivalently,onapernetwork/subnet)basis.Additional
authenticationdataisalsoconfigurableonaperinterfacebasis.
Authenticationtypes0,1and2aredefinedbythisspecification.
Allotherauthenticationtypesarereservedfordefinitionbythe
IANA(iana@ISI.EDU).Thecurrentlistofauthenticationtypesis
describedbelowinTable20.
AuTypeDescription
___________________________________________
0Nullauthentication
1Simplepassword
2Cryptographicauthentication
AllothersReservedforassignmentbythe
IANA(iana@ISI.EDU)
Table20:OSPFauthenticationtypes.
D.1Nullauthentication
Useofthisauthenticationtypemeansthatroutingexchanges
overthenetwork/subnetarenotauthenticated.The64bit
authenticationfieldintheOSPFheadercancontainanything;it
isnotexaminedonpacketreception.WhenemployingNull
authentication,theentirecontentsofeachOSPFpacket(other
thanthe64bitauthenticationfield)arechecksummedinorder
todetectdatacorruption.
D.2Simplepasswordauthentication
Usingthisauthenticationtype,a64bitfieldisconfiguredon
apernetworkbasis.Allpacketssentonaparticularnetwork
musthavethisconfiguredvalueintheirOSPFheader64bit
authenticationfield.Thisessentiallyservesasa"clear"64
bitpassword.Inaddition,theentirecontentsofeachOSPF
packet(otherthanthe64bitauthenticationfield)are
checksummedinordertodetectdatacorruption.
Simplepasswordauthenticationguardsagainstrouters
inadvertentlyjoiningtheroutingdomain;eachroutermustfirst
beconfiguredwithitsattachednetworks'passwordsbeforeit
canparticipateinrouting.However,simplepassword
authenticationisvulnerabletopassiveattackscurrently
widespreadintheInternet(see[Ref16]).Anyonewithphysical
accesstothenetworkcanlearnthepasswordandcompromisethe
securityoftheOSPFroutingdomain.
D.3Cryptographicauthentication
175/188
3/2/2015
Usingthisauthenticationtype,asharedsecretkeyis
configuredinallroutersattachedtoacommonnetwork/subnet.
ForeachOSPFprotocolpacket,thekeyisusedto
generate/verifya"messagedigest"thatisappendedtotheend
oftheOSPFpacket.Themessagedigestisaonewayfunctionof
theOSPFprotocolpacketandthesecretkey.Sincethesecret
keyisneversentoverthenetworkintheclear,protectionis
providedagainstpassiveattacks.
Thealgorithmsusedtogenerateandverifythemessagedigest
arespecifiedimplicitlybythesecretkey.Thisspecification
completelydefinestheuseofOSPFCryptographicauthentication
whentheMD5algorithmisused.
Inaddition,anondecreasingsequencenumberisincludedin
eachOSPFprotocolpackettoprotectagainstreplayattacks.
Thisprovideslongtermprotection;however,itisstill
possibletoreplayanOSPFpacketuntilthesequencenumber
changes.Toimplementthisfeature,eachneighbordatastructure
containsanewfieldcalledthe"cryptographicsequencenumber".
Thisfieldisinitializedtozero,andisalsosettozero
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|0|KeyID|AuthDataLen|
+++++++++++++++++++++++++++++++++
|Cryptographicsequencenumber|
+++++++++++++++++++++++++++++++++
Figure18:UsageoftheAuthenticationfield
intheOSPFpacketheaderwhenCryptographic
Authenticationisemployed
whenevertheneighbor'sstatetransitionsto"Down".Wheneveran
OSPFpacketisacceptedasauthentic,thecryptographicsequence
numberissettothereceivedpacket'ssequencenumber.
Thisspecificationdoesnotprovidearolloverprocedureforthe
cryptographicsequencenumber.Whenthecryptographicsequence
numberthattherouterissendinghitsthemaximumvalue,the
routershouldresetthecryptographicsequencenumberthatitis
sendingbackto0.Afterthisisdone,therouter'sneighbors
willrejecttherouter'sOSPFpacketsforaperiodof
RouterDeadInterval,andthentherouterwillbeforcedto
reestablishalladjacenciesovertheinterface.However,itis
expectedthatmanyimplementationswilluse"secondssince
reboot"(or"secondssince1960",etc.)asthecryptographic
sequencenumber.Suchachoicewillessentiallyprevent
rollover,sincethecryptographicsequencenumberfieldis32
bitsinlength.
TheOSPFCryptographicauthenticationoptiondoesnotprovide
confidentiality.
176/188
3/2/2015
Whencryptographicauthenticationisused,the64bit
AuthenticationfieldinthestandardOSPFpacketheaderis
redefinedasshowninFigure18.Thenewfielddefinitionsare
asfollows:
KeyID
Thisfieldidentifiesthealgorithmandsecretkeyusedto
createthemessagedigestappendedtotheOSPFpacket.Key
Identifiersareuniqueperinterface(orequivalently,per
subnet).
AuthDataLen
Thelengthinbytesofthemessagedigestappendedtothe
OSPFpacket.
Cryptographicsequencenumber
Anunsigned32bitnondecreasingsequencenumber.Usedto
guardagainstreplayattacks.
ThemessagedigestappendedtotheOSPFpacketisnotactually
consideredpartoftheOSPFprotocolpacket:themessagedigest
isnotincludedintheOSPFheader'spacketlength,althoughit
isincludedinthepacket'sIPheaderlengthfield.
EachkeyisidentifiedbythecombinationofinterfaceandKey
ID.Aninterfacemayhavemultiplekeysactiveatanyonetime.
Thisenablessmoothtransitionfromonekeytoanother.Eachkey
hasfourtimeconstantsassociatedwithit.Thesetimeconstants
canbeexpressedintermsofatimeofdayclock,orintermsof
arouter'slocalclock(e.g.,numberofsecondssincelast
reboot):
KeyStartAccept
Thetimethattherouterwillstartacceptingpacketsthat
havebeencreatedwiththegivenkey.
KeyStartGenerate
Thetimethattherouterwillstartusingthekeyforpacket
generation.
KeyStopGenerate
Thetimethattherouterwillstopusingthekeyforpacket
generation.
KeyStopAccept
Thetimethattherouterwillstopacceptingpacketsthat
havebeencreatedwiththegivenkey.
177/188
3/2/2015
Inordertoachievesmoothkeytransition,KeyStartAcceptshould
belessthanKeyStartGenerateandKeyStopGenerateshouldbeless
thanKeyStopAccept.IfKeyStopGenerateandKeyStopAcceptare
leftunspecified,thekey'slifetimeisinfinite.Whenanewkey
replacesanold,theKeyStartGeneratetimeforthenewkeymust
belessthanorequaltotheKeyStopGeneratetimeoftheold
key.
Keystorageshouldpersistacrossasystemrestart,warmor
cold,toavoidoperationalissues.Intheeventthatthelast
keyassociatedwithaninterfaceexpires,itisunacceptableto
reverttoanunauthenticatedcondition,andnotadvisableto
disruptrouting.Therefore,theroutershouldsenda"last
authenticationkeyexpiration"notificationtothenetwork
managerandtreatthekeyashavinganinfinitelifetimeuntil
thelifetimeisextended,thekeyisdeletedbynetwork
management,oranewkeyisconfigured.
D.4Messagegeneration
AfterbuildingthecontentsofanOSPFpacket,the
authenticationprocedureindicatedbythesendinginterface's
Autypevalueiscalledbeforethepacketissent.The
authenticationproceduremodifiestheOSPFpacketasfollows.
D.4.1GeneratingNullauthentication
WhenusingNullauthentication,thepacketismodifiedas
follows:
(1)TheAutypefieldinthestandardOSPFheaderissetto
0.
(2)ThechecksumfieldinthestandardOSPFheaderissetto
thestandardIPchecksumoftheentirecontentsofthe
packet,startingwiththeOSPFpacketheaderbut
excludingthe64bitauthenticationfield.This
checksumiscalculatedasthe16bitone'scomplementof
theone'scomplementsumofallthe16bitwordsinthe
packet,exceptingtheauthenticationfield.Ifthe
packet'slengthisnotanintegralnumberof16bit
words,thepacketispaddedwithabyteofzerobefore
checksumming.
D.4.2GeneratingSimplepasswordauthentication
WhenusingSimplepasswordauthentication,thepacketis
modifiedasfollows:
1.
(2)ThechecksumfieldinthestandardOSPFheaderissetto
thestandardIPchecksumoftheentirecontentsofthe
packet,startingwiththeOSPFpacketheaderbut
178/188
3/2/2015
excludingthe64bitauthenticationfield.This
checksumiscalculatedasthe16bitone'scomplementof
theone'scomplementsumofallthe16bitwordsinthe
packet,exceptingtheauthenticationfield.Ifthe
checksumming.
(3)The64bitauthenticationfieldintheOSPFpacket
headerissettothe64bitpassword(i.e.,
authenticationkey)thathasbeenconfiguredforthe
interface.
D.4.3GeneratingCryptographicauthentication
WhenusingCryptographicauthentication,theremaybe
multiplekeysconfiguredfortheinterface.Inthiscase,
amongthekeysthatarevalidformessagegeneration(i.e,
thathaveKeyStartGenerate<=currenttime<
KeyStopGenerate)choosetheonewiththemostrecent
KeyStartGeneratetime.Usingthiskey,modifythepacketas
follows:
2.
(2)ThechecksumfieldinthestandardOSPFheaderisnot
calculated,butisinsteadsetto0.
(3)TheKeyID(seeFigure18)issettothechosenkey's
KeyID.
(4)TheAuthDataLenfieldissettothelengthinbytesof
themessagedigestthatwillbeappendedtotheOSPF
packet.WhenusingMD5astheauthenticationalgorithm,
AuthDataLenwillbe16.
(5)The32bitCryptographicsequencenumber(seeFigure18)
issettoanondecreasingvalue(i.e.,avalueatleast
aslargeasthelastvaluesentouttheinterface).The
precisevaluestouseinthecryptographicsequence
numberfieldareimplementationspecific.Forexample,
itmaybebasedonasimplecounter,orbebasedonthe
system'sclock.
(6)Themessagedigestisthencalculatedandappendedto
theOSPFpacket.Theauthenticationalgorithmtobe
usedincalculatingthedigestisindicatedbythekey
itself.Inputtotheauthenticationalgorithmconsists
oftheOSPFpacketandthesecretkey.WhenusingMD5as
theauthenticationalgorithm,themessagedigest
calculationproceedsasfollows:
(a)The16byteMD5keyisappendedtotheOSPFpacket.
(b)Trailingpadandlengthfieldsareadded,as
179/188
3/2/2015
specifiedin[Ref17].
(c)TheMD5authenticationalgorithmisrunoverthe
concatenationoftheOSPFpacket,secretkey,pad
andlengthfields,producinga16bytemessage
digest(see[Ref17]).
(d)TheMD5digestiswrittenovertheOSPFkey(i.e.,
appendedtotheoriginalOSPFpacket).Thedigestis
notcountedintheOSPFpacket'slengthfield,but
isincludedinthepacket'sIPlengthfield.Any
trailingpadorlengthfieldsbeyondthedigestare
notcountedortransmitted.
D.5Messageverification
WhenanOSPFpackethasbeenreceivedonaninterface,itmust
beauthenticated.Theauthenticationprocedureisindicatedby
thesettingofAutypeinthestandardOSPFpacketheader,which
matchesthesettingofAutypeforthereceivingOSPFinterface.
IfanOSPFprotocolpacketisacceptedasauthentic,processing
ofthepacketcontinuesasspecifiedinSection8.2.Packets
whichfailauthenticationarediscarded.
D.5.1VerifyingNullauthentication
WhenusingNullauthentication,thechecksumfieldinthe
OSPFheadermustbeverified.Itmustbesettothe16bit
one'scomplementoftheone'scomplementsumofallthe16
bitwordsinthepacket,exceptingtheauthenticationfield.
(Ifthepacket'slengthisnotanintegralnumberof16bit
checksumming.)
D.5.2VerifyingSimplepasswordauthentication
WhenusingSimplepasswordauthentication,thereceivedOSPF
packetisauthenticatedasfollows:
(1)ThechecksumfieldintheOSPFheadermustbeverified.
Itmustbesettothe16bitone'scomplementofthe
one'scomplementsumofallthe16bitwordsinthe
packet,exceptingtheauthenticationfield.(Ifthe
checksumming.)
(2)The64bitauthenticationfieldintheOSPFpacket
headermustbeequaltothe64bitpassword(i.e.,
authenticationkey)thathasbeenconfiguredforthe
interface.
180/188
3/2/2015
D.5.3VerifyingCryptographicauthentication
WhenusingCryptographicauthentication,thereceivedOSPF
packetisauthenticatedasfollows:
(1)Locatethereceivinginterface'sconfiguredkeyhaving
KeyIDequaltothatspecifiedinthereceivedOSPF
packet(seeFigure18).Ifthekeyisnotfound,orif
thekeyisnotvalidforreception(i.e.,currenttime<
KeyStartAcceptorcurrenttime>=KeyStopAccept),the
OSPFpacketisdiscarded.
(2)IfthecryptographicsequencenumberfoundintheOSPF
header(seeFigure18)islessthanthecryptographic
sequencenumberrecordedinthesendingneighbor'sdata
structure,theOSPFpacketisdiscarded.
(3)Verifytheappendedmessagedigestinthefollowing
steps:
(a)Thereceiveddigestissetaside.
(b)Anewdigestiscalculated,asspecifiedinStep6
ofSectionD.4.3.
(c)Thecalculatedandreceiveddigestsarecompared.If
theydonotmatch,theOSPFpacketisdiscarded.If
theydomatch,theOSPFprotocolpacketisaccepted
asauthentic,andthe"cryptographicsequence
number"intheneighbor'sdatastructureissetto
thesequencenumberfoundinthepacket'sOSPF
header.
E.AnalgorithmforassigningLinkStateIDs
TheLinkStateIDinASexternalLSAsandsummaryLSAsisusually
settothedescribednetwork'sIPaddress.However,ifnecessaryone
ormoreofthenetwork'shostbitsmaybesetintheLinkStateID.
ThisallowstheroutertooriginateseparateLSAsfornetworks
havingthesameaddress,yetdifferentmasks.Suchnetworkscan
occurinthepresenceofsupernettingandsubnet0s(see[Ref10]).
Thisappendixgivesonepossiblealgorithmforsettingthehostbits
181/188
3/2/2015
inLinkStateIDs.Thechoiceofsuchanalgorithmisalocal
decision.Separateroutersarefreetousedifferentalgorithms,
sincetheonlyLSAsaffectedaretheonesthattherouteritself
originates.Theonlyrequirementonthealgorithmsusedisthatthe
network'sIPaddressshouldbeusedastheLinkStateIDwhenever
possible;thismaximizesinteroperabilitywithOSPFimplementations
predatingRFC1583.
ThealgorithmbelowisstatedforASexternalLSAs.Thisisonly
forclarity;theexactsamealgorithmcanbeusedforsummaryLSAs.
SupposethattherouterwishestooriginateanASexternalLSAfora
networkhavingaddressNAandmaskNM1.Thefollowingstepsarethen
usedtodeterminetheLSA'sLinkStateID:
(1)DeterminewhethertherouterisalreadyoriginatinganAS
externalLSAwithLinkStateIDequaltoNA(insuchanLSAthe
routeritselfwillbelistedastheLSA'sAdvertisingRouter).
Ifnot,theLinkStateIDissetequaltoNAandthealgorithm
terminates.Otherwise,
(2)Obtainthenetworkmaskfromthebodyofthealreadyexisting
ASexternalLSA.CallthismaskNM2.Therearethentwocases:
oNM1islonger(i.e.,morespecific)thanNM2.Inthiscase,
settheLinkStateIDinthenewLSAtobethenetwork
[NA,NM1]withallthehostbitsset(i.e.,equaltoNAor'ed
togetherwithallthebitsthatarenotsetinNM1,whichis
network[NA,NM1]'sbroadcastaddress).
oNM2islongerthanNM1.Inthiscase,changetheexisting
LSA(havingLinkStateIDofNA)toreferencethenew
network[NA,NM1]byincrementingthesequencenumber,
changingthemaskinthebodytoNM1andinsertingthecost
ofthenewnetwork.ThenoriginateanewLSAfortheold
network[NA,NM2],withLinkStateIDequaltoNAor'ed
togetherwiththebitsthatarenotsetinNM2(i.e.,
network[NA,NM2]'sbroadcastaddress).
Theabovealgorithmassumesthatallmasksarecontiguous;this
ensuresthatwhentwonetworkshavethesameaddress,onemaskis
morespecificthantheother.Thealgorithmalsoassumesthatno
networkexistshavinganaddressequaltoanothernetwork's
broadcastaddress.Giventhesetwoassumptions,theabovealgorithm
alwaysproducesuniqueLinkStateIDs.Theabovealgorithmcanalso
berewordedasfollows:WhenoriginatinganASexternalLSA,tryto
usethenetworknumberastheLinkStateID.Ifthatproducesa
conflict,examinethetwonetworksinconflict.Onewillbeasubset
oftheother.Forthelessspecificnetwork,usethenetworknumber
astheLinkStateIDandforthemorespecificusethenetwork's
broadcastaddressinstead(i.e.,flipallthe"host"bitsto1).If
themostspecificnetworkwasoriginatedfirst,thiswillcauseyou
tooriginatetwoLSAsatonce.
Asanexampleofthealgorithm,consideritsoperationwhenthe
followingsequenceofeventsoccursinasinglerouter(RouterA).
182/188
3/2/2015
(1)RouterAwantstooriginateanASexternalLSAfor
[10.0.0.0,255.255.255.0]:
(a)ALinkStateIDof10.0.0.0isused.
(2)RouterAthenwantstooriginateanASexternalLSAfor
[10.0.0.0,255.255.0.0]:
(a)TheLSAfor[10.0.0,0,255.255.255.0]isreoriginatedusinga
newLinkStateIDof10.0.0.255.
(b)ALinkStateIDof10.0.0.0isusedfor
[10.0.0.0,255.255.0.0].
(3)RouterAthenwantstooriginateanASexternalLSAfor
[10.0.0.0,255.0.0.0]:
(a)TheLSAfor[10.0.0.0,255.255.0.0]isreoriginatedusinga
newLinkStateIDof10.0.255.255.
(b)ALinkStateIDof10.0.0.0isusedfor
[10.0.0.0,255.0.0.0].
(c)Thenetwork[10.0.0.0,255.255.255.0]keepsitsLinkStateID
of10.0.0.255.
183/188
3/2/2015
F.Multipleinterfacestothesamenetwork/subnet
Thereareatleasttwowaystosupportmultiplephysicalinterfaces
tothesameIPsubnet.Bothmethodswillinteroperatewith
implementationsofRFC1583(andofcoursethismemo).Thetwo
methodsaresketchedbrieflybelow.Anassumptionhasbeenmadethat
eachinterfacehasbeenassignedaseparateIPaddress(otherwise,
supportformultipleinterfacesismoreofalinklevelorARPissue
thananOSPFissue).
Method1:
RuntheentireOSPFfunctionalityoverbothinterfaces,sending
andreceivinghellos,flooding,supportingseparateinterface
andneighborFSMsforeachinterface,etc.Whendoingthisall
otherroutersonthesubnetwilltreatthetwointerfacesas
separateneighbors,sinceneighborsareidentified(onbroadcast
andNBMAnetworks)bytheirIPaddress.
Method1hasthefollowingdisadvantages:
(1)Youincreasethetotalnumberofneighborsandadjacencies.
(2)Youlosethebidirectionalitytestonbothinterfaces,since
bidirectionalityisbasedonRouterID.
(3)Youhavetoconsiderbothinterfacestogetherduringthe
DesignatedRouterelection,sinceifyoudeclarebothtobe
DRsimultaneouslyyoucanconfusethetiebreaker(whichis
RouterID).
Method2:
RunOSPFoveronlyoneinterface(callittheprimary
interface),butincludeboththeprimaryandsecondary
interfacesinyourRouterLSA.
Method2hasthefollowingdisadvantages:
(1)Youlosethebidirectionalitytestonthesecondary
interface.
(2)Whentheprimaryinterfacefails,youneedtopromotethe
secondaryinterfacetoprimarystatus.
G.DifferencesfromRFC2178
ThissectiondocumentsthedifferencesbetweenthismemoandRFC
2178.Alldifferencesarebackwardcompatible.Implementationsof
thismemoandofRFCs2178,1583,and1247willinteroperate.
184/188
3/2/2015
G.1Floodingmodifications
Threechangeshavebeenmadetothefloodingprocedurein
Section13.
Thefirstchangeistostep4inSection13.NowMaxAgeLSAsare
acknowledgedandthendiscardedonlywhenbotha)thereisno
databasecopyoftheLSAandb)noneofrouter'sneighborsare
instatesExchangeorLoading.Inallothercases,theMaxAge
LSAisprocessedlikeanyotherLSA,installingtheLSAinthe
databaseandfloodingitouttheappropriateinterfaceswhenthe
LSAismorerecentthanthedatabasecopy(Step5ofSection
13).ThischangealsoaffectsthecontentsofTable19.
Thesecondchangeistostep5ainSection13.TheMinLSArrival
checkismeantonlyforLSAsreceivedduringflooding,and
shouldnotbeperformedonthoseLSAsthattherouteritself
originates.
Thethirdchangeistostep8inSection13.Confusionbetween
routersastowhichLSAinstanceismorerecentcancausea
disastrousamountoffloodinginalinkstateprotocol(see
[Ref26]).OSPFguardsagainstthisproblemintwoways:a)the
LSagefieldisusedlikeaTTLfieldinflooding,toeventually
removeloopingLSAsfromthenetwork(seeSection13.3),andb)
routersrefusetoacceptLSAupdatesmorefrequentlythanonce
everyMinLSArrivalseconds(seeSection13).However,thereis
stillonecaseinRFC2178wheredisagreementsregardingwhich
LSAismorerecentcancausealotoffloodingtraffic:
respondingtooldLSAsbyrefloodingthedatabasecopy.For
thisreason,Step8ofSection13hasbeenamendedtoonly
respondwiththedatabasecopywhenthatcopyhasnotbeensent
inanyLinkStateUpdatewithinthelastMinLSArrivalseconds.
G.2Changestoexternalpathpreferences
ThereisstillthepossibilityofaroutingloopinRFC2178
whenbotha)virtuallinksareinuseandb)thesameexternal
routeisbeingimportedbymultipleASBRs,eachofwhichisina
separatearea.Tofixthisproblem,Section16.4.1hasbeen
revised.TochoosethecorrectASBR/forwardingaddress,intra
areapathsthroughnonbackboneareasarealwayspreferred.
However,intraareapathsthroughthebackbonearea(Area0)and
interareapathsarenowofequalpreference,andmustbe
comparedsolelybasedoncost.
Thereasoningbehindthischangeisasfollows.Whenvirtual
linksareinuse,anintraareabackbonepathforoneroutercan
turnintoaninterareapathinarouterseveralhopscloserto
thedestination.Hence,intraareabackbonepathsandinterarea
pathsmustbeofequalpreference.Wecansafelycomparetheir
costs,preferringthepathwiththesmallestcost,duetothe
calculationsinSection16.3.
185/188
3/2/2015
ThankstoMichaelBriggsandJeremyMcCooeyoftheUNH
InterOperabilityLabforpointingoutthisproblem.
G.3Incompleteresolutionofvirtualnexthops
OneofthefunctionsofthecalculationinSection16.3isto
determinetheactualnexthop(s)forthosedestinationswhose
nexthopwascalculatedasavirtuallinkinSections16.1and
16.2.AftercompletionofthecalculationinSection16.3,any
pathscalculatedinSections16.1and16.2thatstillhave
unresolvedvirtualnexthopsshouldbediscarded.
G.4Routingtablelookup
TheroutingtablelookupalgorithminSection11.1hasbeen
modifiedtoreflectcurrentpractice.The"bestmatch"routing
tableentryisnowalwaysselectedtobetheoneprovidingthe
mostspecific(longest)match.Supposeforexamplearouteris
forwardingpacketstothedestination192.9.1.1.Aroutingtable
entryfor192.9.1/24willalwaysbeabettermatchthanthe
routingtableentryfor192.9/16,regardlessoftherouting
tableentries'pathtypes.Notehoweverthatwhenmultiplepaths
areavailableforagivenroutingtableentry,thecalculations
inSections16.1,16.2,and16.4alwaysyieldthepathshaving
themostpreferentialpathtype.(Intraareapathsarethemost
preferred,followedinorderbyinterarea,type1externaland
type2externalpaths;seeSection11).
186/188
3/2/2015
SecurityConsiderations
AllOSPFprotocolexchangesareauthenticated.OSPFsupports
multipletypesofauthentication;thetypeofauthenticationinuse
canbeconfiguredonapernetworksegmentbasis.OneofOSPF's
authenticationtypes,namelytheCryptographicauthentication
option,isbelievedtobesecureagainstpassiveattacksandprovide
significantprotectionagainstactiveattacks.Whenusingthe
Cryptographicauthenticationoption,eachrouterappendsa"message
digest"toitstransmittedOSPFpackets.Receiversthenusethe
sharedsecretkeyandreceiveddigesttoverifythateachreceived
OSPFpacketisauthentic.
ThequalityofthesecurityprovidedbytheCryptographic
authenticationoptiondependscompletelyonthestrengthofthe
messagedigestalgorithm(MD5iscurrentlytheonlymessagedigest
algorithmspecified),thestrengthofthekeybeingused,andthe
correctimplementationofthesecuritymechanisminall
communicatingOSPFimplementations.Italsorequiresthatall
partiesmaintainthesecrecyofthesharedsecretkey.
NoneoftheOSPFauthenticationtypesprovideconfidentiality.Nor
dotheyprotectagainsttrafficanalysis.Keymanagementisalsonot
addressedbythismemo.
Formoreinformation,seeSections8.1,8.2,andAppendixD.
Author'sAddress
JohnMoy
AscendCommunications,Inc.
1RobbinsRoad
Westford,MA01886
Phone:9789521367
Fax:9783922075
EMail:jmoy@casc.com
187/188
3/2/2015
FullCopyrightStatement
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraph
areincludedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
188/188

Https WWW - Ietf.org RFC Rfc2328

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Https WWW - Ietf.org RFC Rfc2328

Hochgeladen von

Copyright:

Verfügbare Formate

3/2/2015

Das könnte Ihnen auch gefallen