RFC Rfc4271

3/2/2015
www.ietf.org/rfc/rfc4271.txt
NetworkWorkingGroupY.Rekhter,Ed.
RequestforComments:4271T.Li,Ed.
Obsoletes:1771S.Hares,Ed.
Category:StandardsTrackJanuary2006
ABorderGatewayProtocol4(BGP4)
StatusofThisMemo
ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.
CopyrightNotice
Copyright(C)TheInternetSociety(2006).
Abstract
ThisdocumentdiscussestheBorderGatewayProtocol(BGP),whichis
aninterAutonomousSystemroutingprotocol.
TheprimaryfunctionofaBGPspeakingsystemistoexchangenetwork
reachabilityinformationwithotherBGPsystems.Thisnetwork
reachabilityinformationincludesinformationonthelistof
AutonomousSystems(ASes)thatreachabilityinformationtraverses.
ThisinformationissufficientforconstructingagraphofAS
connectivityforthisreachabilityfromwhichroutingloopsmaybe
pruned,and,attheASlevel,somepolicydecisionsmaybeenforced.
BGP4providesasetofmechanismsforsupportingClasslessInter
DomainRouting(CIDR).Thesemechanismsincludesupportfor
advertisingasetofdestinationsasanIPprefix,andeliminating
theconceptofnetwork"class"withinBGP.BGP4alsointroduces
mechanismsthatallowaggregationofroutes,includingaggregationof
ASpaths.
ThisdocumentobsoletesRFC1771.
Rekhter,etal.StandardsTrack[Page1]
RFC4271BGP4January2006
TableofContents
http://www.ietf.org/rfc/rfc4271.txt
1/90
3/2/2015
1.Introduction....................................................4
1.1.DefinitionofCommonlyUsedTerms..........................4
1.2.SpecificationofRequirements..............................6
2.Acknowledgements................................................6
3.SummaryofOperation............................................7
3.1.Routes:AdvertisementandStorage..........................9
3.2.RoutingInformationBase..................................10
4.MessageFormats................................................11
4.1.MessageHeaderFormat.....................................12
4.2.OPENMessageFormat.......................................13
4.3.UPDATEMessageFormat.....................................14
4.4.KEEPALIVEMessageFormat..................................21
4.5.NOTIFICATIONMessageFormat...............................21
5.PathAttributes................................................23
5.1.PathAttributeUsage......................................25
5.1.1.ORIGIN.............................................25
5.1.2.AS_PATH............................................25
5.1.3.NEXT_HOP...........................................26
5.1.4.MULTI_EXIT_DISC....................................28
5.1.5.LOCAL_PREF.........................................29
5.1.6.ATOMIC_AGGREGATE...................................29
5.1.7.AGGREGATOR.........................................30
6.BGPErrorHandling.............................................30
6.1.MessageHeaderErrorHandling.............................31
6.2.OPENMessageErrorHandling...............................31
6.3.UPDATEMessageErrorHandling.............................32
6.4.NOTIFICATIONMessageErrorHandling.......................34
6.5.HoldTimerExpiredErrorHandling.........................34
6.6.FiniteStateMachineErrorHandling.......................35
6.7.Cease.....................................................35
6.8.BGPConnectionCollisionDetection........................35
7.BGPVersionNegotiation........................................36
8.BGPFiniteStateMachine(FSM).................................37
8.1.EventsfortheBGPFSM....................................38
8.1.1.OptionalEventsLinkedtoOptionalSession
Attributes.........................................38
8.1.2.AdministrativeEvents..............................42
8.1.3.TimerEvents.......................................46
8.1.4.TCPConnectionBasedEvents........................47
8.1.5.BGPMessageBasedEvents...........................49
8.2.DescriptionofFSM........................................51
8.2.1.FSMDefinition.....................................51
8.2.1.1.Terms"active"and"passive"..............52
8.2.1.2.FSMandCollisionDetection...............52
8.2.1.3.FSMandOptionalSessionAttributes.......52
8.2.1.4.FSMEventNumbers.........................53
8.2.1.5.FSMActionsthatareImplementation
Dependent.................................53
8.2.2.FiniteStateMachine...............................53
9.UPDATEMessageHandling........................................75
9.1.DecisionProcess..........................................76
9.1.1.Phase1:CalculationofDegreeofPreference.......77
9.1.2.Phase2:RouteSelection...........................77
9.1.2.1.RouteResolvabilityCondition.............79
9.1.2.2.BreakingTies(Phase2)...................80
9.1.3.Phase3:RouteDissemination.......................82
9.1.4.OverlappingRoutes.................................83
2/90
3/2/2015
9.2.UpdateSendProcess.......................................84
9.2.1.ControllingRoutingTrafficOverhead...............85
9.2.1.1.FrequencyofRouteAdvertisement..........85
9.2.1.2.FrequencyofRouteOrigination............85
9.2.2.EfficientOrganizationofRoutingInformation......86
9.2.2.1.InformationReduction.....................86
9.2.2.2.AggregatingRoutingInformation...........87
9.3.RouteSelectionCriteria..................................89
9.4.OriginatingBGProutes....................................89
10.BGPTimers....................................................90
AppendixA.ComparisonwithRFC1771.............................92
AppendixB.ComparisonwithRFC1267.............................93
AppendixC.ComparisonwithRFC1163.............................93
AppendixD.ComparisonwithRFC1105.............................94
AppendixE.TCPOptionsthatMayBeUsedwithBGP................94
AppendixF.ImplementationRecommendations.......................95
AppendixF.1.MultipleNetworksPerMessage.........95
AppendixF.2.ReducingRouteFlapping...............96
AppendixF.3.PathAttributeOrdering...............96
AppendixF.4.AS_SETSorting........................96
AppendixF.5.ControlOverVersionNegotiation......96
AppendixF.6.ComplexAS_PATHAggregation...........96
SecurityConsiderations...........................................97
IANAConsiderations...............................................99
NormativeReferences.............................................101
InformativeReferences...........................................101
1.Introduction
TheBorderGatewayProtocol(BGP)isaninterAutonomousSystem
routingprotocol.
connectivityforthisreachability,fromwhichroutingloopsmaybe
prunedand,attheASlevel,somepolicydecisionsmaybeenforced.
BGP4providesasetofmechanismsforsupportingClasslessInter
DomainRouting(CIDR)[RFC1518,RFC1519].Thesemechanismsinclude
supportforadvertisingasetofdestinationsasanIPprefixand
eliminatingtheconceptofnetwork"class"withinBGP.BGP4also
introducesmechanismsthatallowaggregationofroutes,including
aggregationofASpaths.
3/90
3/2/2015
RoutinginformationexchangedviaBGPsupportsonlythedestination
basedforwardingparadigm,whichassumesthatarouterforwardsa
packetbasedsolelyonthedestinationaddresscarriedintheIP
headerofthepacket.This,inturn,reflectsthesetofpolicy
decisionsthatcan(andcannot)beenforcedusingBGP.BGPcan
supportonlythosepoliciesconformingtothedestinationbased
forwardingparadigm.
1.1.DefinitionofCommonlyUsedTerms
Thissectionprovidesdefinitionsfortermsthathaveaspecific
meaningtotheBGPprotocolandthatareusedthroughoutthetext.
AdjRIBIn
TheAdjRIBsIncontainsunprocessedroutinginformationthathas
beenadvertisedtothelocalBGPspeakerbyitspeers.
AdjRIBOut
TheAdjRIBsOutcontainstheroutesforadvertisementtospecific
peersbymeansofthelocalspeaker'sUPDATEmessages.
AutonomousSystem(AS)
TheclassicdefinitionofanAutonomousSystemisasetofrouters
underasingletechnicaladministration,usinganinteriorgateway
protocol(IGP)andcommonmetricstodeterminehowtoroute
packetswithintheAS,andusinganinterASroutingprotocolto
determinehowtoroutepacketstootherASes.Sincethisclassic
definitionwasdeveloped,ithasbecomecommonforasingleASto
useseveralIGPsand,sometimes,severalsetsofmetricswithinan
AS.TheuseofthetermAutonomousSystemstressesthefactthat,
evenwhenmultipleIGPsandmetricsareused,theadministration
ofanASappearstootherASestohaveasinglecoherentinterior
routingplan,andpresentsaconsistentpictureofthe
destinationsthatarereachablethroughit.
BGPIdentifier
A4octetunsignedintegerthatindicatestheBGPIdentifierof
thesenderofBGPmessages.AgivenBGPspeakersetsthevalueof
itsBGPIdentifiertoanIPaddressassignedtothatBGPspeaker.
ThevalueoftheBGPIdentifierisdetermineduponstartupandis
thesameforeverylocalinterfaceandBGPpeer.
BGPspeaker
ArouterthatimplementsBGP.
EBGP
ExternalBGP(BGPconnectionbetweenexternalpeers).
Externalpeer
PeerthatisinadifferentAutonomousSystemthanthelocal
system.
Feasibleroute
Anadvertisedroutethatisavailableforusebytherecipient.
IBGP
InternalBGP(BGPconnectionbetweeninternalpeers).
4/90
3/2/2015
Internalpeer
PeerthatisinthesameAutonomousSystemasthelocalsystem.
IGP
InteriorGatewayProtocolaroutingprotocolusedtoexchange
routinginformationamongrouterswithinasingleAutonomous
System.
LocRIB
TheLocRIBcontainstheroutesthathavebeenselectedbythe
localBGPspeaker'sDecisionProcess.
NLRI
NetworkLayerReachabilityInformation.
Route
Aunitofinformationthatpairsasetofdestinationswiththe
attributesofapathtothosedestinations.Thesetof
destinationsaresystemswhoseIPaddressesarecontainedinone
IPaddressprefixcarriedintheNetworkLayerReachability
Information(NLRI)fieldofanUPDATEmessage.Thepathisthe
informationreportedinthepathattributesfieldofthesame
UPDATEmessage.
RIB
RoutingInformationBase.
Unfeasibleroute
Apreviouslyadvertisedfeasibleroutethatisnolongeravailable
foruse.
1.2.SpecificationofRequirements
Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",
"SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"inthis
documentaretobeinterpretedasdescribedinRFC2119[RFC2119].
2.Acknowledgements
Thisdocumentwasoriginallypublishedas[RFC1267]inOctober1991,
jointlyauthoredbyKirkLougheedandYakovRekhter.
WewouldliketoexpressourthankstoGuyAlmes,LenBosack,and
JeffreyC.Honigfortheircontributionstotheearlierversion
(BGP1)ofthisdocument.
Wewouldliketospeciallyacknowledgenumerouscontributionsby
DennisFergusontotheearlierversionofthisdocument.
WewouldliketoexplicitlythankBobBradenforthereviewofthe
earlierversion(BGP2)ofthisdocument,andforhisconstructive
andvaluablecomments.
WewouldalsoliketothankBobHinden,DirectorforRoutingofthe
InternetEngineeringSteeringGroup,andtheteamofreviewershe
assembledtoreviewtheearlierversion(BGP2)ofthisdocument.
5/90
3/2/2015
Thisteam,consistingofDeborahEstrin,MiloMedin,JohnMoy,Radia
Perlman,MarthaSteenstrup,MikeSt.Johns,andPaulTsuchiya,acted
withastrongcombinationoftoughness,professionalism,and
courtesy.
CertainsectionsofthedocumentborrowedheavilyfromIDRP
[IS10747],whichistheOSIcounterpartofBGP.Forthis,credit
shouldbegiventotheANSIX3S3.3groupchairedbyLymanChapinand
toCharlesKunzinger,whowastheIDRPeditorwithinthatgroup.
WewouldalsoliketothankBenjaminAbarbanel,EnkeChen,Edward
Crabbe,MikeCraren,VincentGillet,EricGray,JeffreyHaas,Dimitry
Haskin,StephenKent,JohnKrawczyk,DavidLeRoy,DanMassey,
JonathanNatale,DanPei,MathewRichardson,JohnScudder,John
StewartIII,DaveThaler,PaulTraina,RussWhite,CurtisVillamizar,
andAlexZininfortheircomments.
WewouldliketospeciallyacknowledgeAndrewLangeforhishelpin
preparingthefinalversionofthisdocument.
Finally,wewouldliketothankallthemembersoftheIDRWorking
Groupfortheirideasandthesupporttheyhavegiventothis
document.
3.SummaryofOperation
TheBorderGatewayProtocol(BGP)isaninterAutonomousSystem
routingprotocol.ItisbuiltonexperiencegainedwithEGP(as
definedin[RFC904])andEGPusageintheNSFNETBackbone(as
describedin[RFC1092]and[RFC1093]).FormoreBGPrelated
information,see[RFC1772],[RFC1930],[RFC1997],and[RFC2858].
connectivity,fromwhichroutingloopsmaybepruned,and,attheAS
level,somepolicydecisionsmaybeenforced.
Inthecontextofthisdocument,weassumethataBGPspeaker
advertisestoitspeersonlythoseroutesthatitusesitself(in
thiscontext,aBGPspeakerissaidto"use"aBGProuteifitisthe
mostpreferredBGProuteandisusedinforwarding).Allothercases
areoutsidethescopeofthisdocument.
Inthecontextofthisdocument,theterm"IPaddress"referstoan
IPVersion4address[RFC791].
RoutinginformationexchangedviaBGPsupportsonlythedestination
basedforwardingparadigm,whichassumesthatarouterforwardsa
packetbasedsolelyonthedestinationaddresscarriedintheIP
headerofthepacket.This,inturn,reflectsthesetofpolicy
decisionsthatcan(andcannot)beenforcedusingBGP.Notethat
somepoliciescannotbesupportedbythedestinationbasedforwarding
paradigm,andthusrequiretechniquessuchassourcerouting(aka
explicitrouting)tobeenforced.Suchpoliciescannotbeenforced
6/90
3/2/2015
usingBGPeither.Forexample,BGPdoesnotenableoneAStosend
traffictoaneighboringASforforwardingtosomedestination
(reachablethroughbut)beyondthatneighboringAS,intendingthat
thetraffictakeadifferentroutetothattakenbythetraffic
originatingintheneighboringAS(forthatsamedestination).On
theotherhand,BGPcansupportanypolicyconformingtothe
destinationbasedforwardingparadigm.
BGP4providesanewsetofmechanismsforsupportingClassless
InterDomainRouting(CIDR)[RFC1518,RFC1519].Thesemechanisms
includesupportforadvertisingasetofdestinationsasanIPprefix
andeliminatingtheconceptofanetwork"class"withinBGP.BGP4
alsointroducesmechanismsthatallowaggregationofroutes,
includingaggregationofASpaths.
Thisdocumentusestheterm`AutonomousSystem'(AS)throughout.The
classicdefinitionofanAutonomousSystemisasetofroutersunder
asingletechnicaladministration,usinganinteriorgatewayprotocol
(IGP)andcommonmetricstodeterminehowtoroutepacketswithinthe
AS,andusinganinterASroutingprotocoltodeterminehowtoroute
packetstootherASes.Sincethisclassicdefinitionwasdeveloped,
ithasbecomecommonforasingleAStouseseveralIGPsand,
sometimes,severalsetsofmetricswithinanAS.Theuseoftheterm
AutonomousSystemstressesthefactthat,evenwhenmultipleIGPsand
metricsareused,theadministrationofanASappearstootherASes
tohaveasinglecoherentinteriorroutingplanandpresentsa
consistentpictureofthedestinationsthatarereachablethroughit.
BGPusesTCP[RFC793]asitstransportprotocol.Thiseliminatesthe
needtoimplementexplicitupdatefragmentation,retransmission,
acknowledgement,andsequencing.BGPlistensonTCPport179.The
errornotificationmechanismusedinBGPassumesthatTCPsupportsa
"graceful"close(i.e.,thatalloutstandingdatawillbedelivered
beforetheconnectionisclosed).
ATCPconnectionisformedbetweentwosystems.Theyexchange
messagestoopenandconfirmtheconnectionparameters.
TheinitialdataflowistheportionoftheBGProutingtablethatis
allowedbytheexportpolicy,calledtheAdjRibsOut(see3.2).
Incrementalupdatesaresentastheroutingtableschange.BGPdoes
notrequireaperiodicrefreshoftheroutingtable.Toallowlocal
policychangestohavethecorrecteffectwithoutresettinganyBGP
connections,aBGPspeakerSHOULDeither(a)retainthecurrent
versionoftheroutesadvertisedtoitbyallofitspeersforthe
durationoftheconnection,or(b)makeuseoftheRouteRefresh
extension[RFC2918].
7/90
3/2/2015
KEEPALIVEmessagesmaybesentperiodicallytoensurethatthe
connectionislive.NOTIFICATIONmessagesaresentinresponseto
errorsorspecialconditions.Ifaconnectionencountersanerror
condition,aNOTIFICATIONmessageissentandtheconnectionis
closed.
ApeerinadifferentASisreferredtoasanexternalpeer,whilea
peerinthesameASisreferredtoasaninternalpeer.InternalBGP
andexternalBGParecommonlyabbreviatedasIBGPandEBGP.
IfaparticularAShasmultipleBGPspeakersandisprovidingtransit
serviceforotherASes,thencaremustbetakentoensurea
consistentviewofroutingwithintheAS.Aconsistentviewofthe
interiorroutesoftheASisprovidedbytheIGPusedwithintheAS.
Forthepurposeofthisdocument,itisassumedthataconsistent
viewoftheroutesexteriortotheASisprovidedbyhavingallBGP
speakerswithintheASmaintainIBGPwitheachother.
ThisdocumentspecifiesthebasebehavioroftheBGPprotocol.This
behaviorcanbe,andis,modifiedbyextensionspecifications.When
theprotocolisextended,thenewbehaviorisfullydocumentedinthe
extensionspecifications.
3.1.Routes:AdvertisementandStorage
Forthepurposeofthisprotocol,arouteisdefinedasaunitof
informationthatpairsasetofdestinationswiththeattributesofa
pathtothosedestinations.Thesetofdestinationsaresystems
whoseIPaddressesarecontainedinoneIPaddressprefixthatis
carriedintheNetworkLayerReachabilityInformation(NLRI)fieldof
anUPDATEmessage,andthepathistheinformationreportedinthe
pathattributesfieldofthesameUPDATEmessage.
RoutesareadvertisedbetweenBGPspeakersinUPDATEmessages.
Multipleroutesthathavethesamepathattributescanbeadvertised
inasingleUPDATEmessagebyincludingmultipleprefixesintheNLRI
fieldoftheUPDATEmessage.
RoutesarestoredintheRoutingInformationBases(RIBs):namely,
theAdjRIBsIn,theLocRIB,andtheAdjRIBsOut,asdescribedin
Section3.2.
IfaBGPspeakerchoosestoadvertiseapreviouslyreceivedroute,it
MAYaddto,ormodify,thepathattributesoftheroutebefore
advertisingittoapeer.
BGPprovidesmechanismsbywhichaBGPspeakercaninformitspeers
thatapreviouslyadvertisedrouteisnolongeravailableforuse.
TherearethreemethodsbywhichagivenBGPspeakercanindicate
thataroutehasbeenwithdrawnfromservice:
a)theIPprefixthatexpressesthedestinationforapreviously
advertisedroutecanbeadvertisedintheWITHDRAWNROUTES
fieldintheUPDATEmessage,thusmarkingtheassociatedroute
asbeingnolongeravailableforuse,
8/90
3/2/2015
b)areplacementroutewiththesameNLRIcanbeadvertised,or
c)theBGPspeakerconnectioncanbeclosed,whichimplicitly
removesallroutesthepairofspeakershadadvertisedtoeach
otherfromservice.
Changingtheattribute(s)ofarouteisaccomplishedbyadvertisinga
replacementroute.Thereplacementroutecarriesnew(changed)
attributesandhasthesameaddressprefixastheoriginalroute.
3.2.RoutingInformationBase
TheRoutingInformationBase(RIB)withinaBGPspeakerconsistsof
threedistinctparts:
a)AdjRIBsIn:TheAdjRIBsInstoresroutinginformationlearned
frominboundUPDATEmessagesthatwerereceivedfromotherBGP
speakers.Theircontentsrepresentroutesthatareavailable
asinputtotheDecisionProcess.
b)LocRIB:TheLocRIBcontainsthelocalroutinginformationthe
BGPspeakerselectedbyapplyingitslocalpoliciestothe
routinginformationcontainedinitsAdjRIBsIn.Theseare
theroutesthatwillbeusedbythelocalBGPspeaker.The
nexthopforeachoftheseroutesMUSTberesolvableviathe
localBGPspeaker'sRoutingTable.
c)AdjRIBsOut:TheAdjRIBsOutstoresinformationthelocalBGP
speakerselectedforadvertisementtoitspeers.Therouting
informationstoredintheAdjRIBsOutwillbecarriedinthe
localBGPspeaker'sUPDATEmessagesandadvertisedtoits
peers.
Insummary,theAdjRIBsIncontainsunprocessedroutinginformation
thathasbeenadvertisedtothelocalBGPspeakerbyitspeers;the
LocRIBcontainstheroutesthathavebeenselectedbythelocalBGP
speaker'sDecisionProcess;andtheAdjRIBsOutorganizestheroutes
foradvertisementtospecificpeers(bymeansofthelocalspeaker's
UPDATEmessages).
AlthoughtheconceptualmodeldistinguishesbetweenAdjRIBsIn,
LocRIB,andAdjRIBsOut,thisneitherimpliesnorrequiresthatan
implementationmustmaintainthreeseparatecopiesoftherouting
information.Thechoiceofimplementation(forexample,3copiesof
theinformationvs1copywithpointers)isnotconstrainedbythe
protocol.
RoutinginformationthattheBGPspeakerusestoforwardpackets(or
toconstructtheforwardingtableusedforpacketforwarding)is
maintainedintheRoutingTable.TheRoutingTableaccumulates
routestodirectlyconnectednetworks,staticroutes,routeslearned
fromtheIGPprotocols,androuteslearnedfromBGP.Whethera
specificBGProuteshouldbeinstalledintheRoutingTable,and
whetheraBGProuteshouldoverridearoutetothesamedestination
9/90
3/2/2015
installedbyanothersource,isalocalpolicydecision,andisnot
specifiedinthisdocument.Inadditiontoactualpacketforwarding,
theRoutingTableisusedforresolutionofthenexthopaddresses
specifiedinBGPupdates(seeSection5.1.3).
4.MessageFormats
ThissectiondescribesmessageformatsusedbyBGP.
BGPmessagesaresentoverTCPconnections.Amessageisprocessed
onlyafteritisentirelyreceived.Themaximummessagesizeis4096
octets.Allimplementationsarerequiredtosupportthismaximum
messagesize.Thesmallestmessagethatmaybesentconsistsofa
BGPheaderwithoutadataportion(19octets).
Allmultioctetfieldsareinnetworkbyteorder.
4.1.MessageHeaderFormat
Eachmessagehasafixedsizeheader.Theremayormaynotbeadata
portionfollowingtheheader,dependingonthemessagetype.The
layoutofthesefieldsisshownbelow:
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
||
++
||
++
|Marker|
++
||
+++++++++++++++++++++++++++++++++
|Length|Type|
+++++++++++++++++++++++++
Marker:
This16octetfieldisincludedforcompatibility;itMUSTbe
settoallones.
Length:
10/90
3/2/2015
This2octetunsignedintegerindicatesthetotallengthofthe
message,includingtheheaderinoctets.Thus,itallowsone
tolocatethe(Markerfieldofthe)nextmessageintheTCP
stream.ThevalueoftheLengthfieldMUSTalwaysbeatleast
19andnogreaterthan4096,andMAYbefurtherconstrained,
dependingonthemessagetype."padding"ofextradataafter
themessageisnotallowed.Therefore,theLengthfieldMUST
havethesmallestvaluerequired,giventherestofthe
message.
Type:
This1octetunsignedintegerindicatesthetypecodeofthe
message.Thisdocumentdefinesthefollowingtypecodes:
1OPEN
2UPDATE
3NOTIFICATION
4KEEPALIVE
[RFC2918]definesonemoretypecode.
4.2.OPENMessageFormat
AfteraTCPconnectionisestablished,thefirstmessagesentbyeach
sideisanOPENmessage.IftheOPENmessageisacceptable,a
KEEPALIVEmessageconfirmingtheOPENissentback.
InadditiontothefixedsizeBGPheader,theOPENmessagecontains
thefollowingfields:
0123
01234567890123456789012345678901
+++++++++
|Version|
+++++++++++++++++
|MyAutonomousSystem|
+++++++++++++++++
|HoldTime|
+++++++++++++++++++++++++++++++++
|BGPIdentifier|
+++++++++++++++++++++++++++++++++
|OptParmLen|
+++++++++++++++++++++++++++++++++
||
|OptionalParameters(variable)|
||
+++++++++++++++++++++++++++++++++
Version:
This1octetunsignedintegerindicatestheprotocolversion
numberofthemessage.ThecurrentBGPversionnumberis4.
MyAutonomousSystem:
This2octetunsignedintegerindicatestheAutonomousSystem
numberofthesender.
11/90
3/2/2015
HoldTime:
This2octetunsignedintegerindicatesthenumberofseconds
thesenderproposesforthevalueoftheHoldTimer.Upon
receiptofanOPENmessage,aBGPspeakerMUSTcalculatethe
valueoftheHoldTimerbyusingthesmallerofitsconfigured
HoldTimeandtheHoldTimereceivedintheOPENmessage.The
HoldTimeMUSTbeeitherzerooratleastthreeseconds.An
implementationMAYrejectconnectionsonthebasisoftheHold
Time.Thecalculatedvalueindicatesthemaximumnumberof
secondsthatmayelapsebetweenthereceiptofsuccessive
KEEPALIVEand/orUPDATEmessagesfromthesender.
BGPIdentifier:
This4octetunsignedintegerindicatestheBGPIdentifierof
thesender.AgivenBGPspeakersetsthevalueofitsBGP
IdentifiertoanIPaddressthatisassignedtothatBGP
speaker.ThevalueoftheBGPIdentifierisdeterminedupon
startupandisthesameforeverylocalinterfaceandBGPpeer.
OptionalParametersLength:
OptionalParametersfieldinoctets.Ifthevalueofthis
fieldiszero,noOptionalParametersarepresent.
OptionalParameters:
Thisfieldcontainsalistofoptionalparameters,inwhich
eachparameterisencodedasa<ParameterType,Parameter
Length,ParameterValue>triplet.
01
0123456789012345
++++++++++++++++++++...
|Parm.Type|Parm.Length|ParameterValue(variable)
++++++++++++++++++++...
ParameterTypeisaoneoctetfieldthatunambiguously
identifiesindividualparameters.ParameterLengthisaone
octetfieldthatcontainsthelengthoftheParameterValue
fieldinoctets.ParameterValueisavariablelengthfield
thatisinterpretedaccordingtothevalueoftheParameter
Typefield.
[RFC3392]definestheCapabilitiesOptionalParameter.
TheminimumlengthoftheOPENmessageis29octets(includingthe
messageheader).
4.3.UPDATEMessageFormat
UPDATEmessagesareusedtotransferroutinginformationbetweenBGP
12/90
3/2/2015
peers.TheinformationintheUPDATEmessagecanbeusedto
constructagraphthatdescribestherelationshipsofthevarious
AutonomousSystems.Byapplyingrulestobediscussed,routing
informationloopsandsomeotheranomaliesmaybedetectedand
removedfrominterASrouting.
AnUPDATEmessageisusedtoadvertisefeasibleroutesthatshare
commonpathattributestoapeer,ortowithdrawmultipleunfeasible
routesfromservice(see3.1).AnUPDATEmessageMAYsimultaneously
advertiseafeasiblerouteandwithdrawmultipleunfeasibleroutes
fromservice.TheUPDATEmessagealwaysincludesthefixedsizeBGP
header,andalsoincludestheotherfields,asshownbelow(note,
someoftheshownfieldsmaynotbepresentineveryUPDATEmessage):
++
|WithdrawnRoutesLength(2octets)|
++
|WithdrawnRoutes(variable)|
++
|TotalPathAttributeLength(2octets)|
++
|PathAttributes(variable)|
++
|NetworkLayerReachabilityInformation(variable)|
++
WithdrawnRoutesLength:
This2octetsunsignedintegerindicatesthetotallengthof
theWithdrawnRoutesfieldinoctets.Itsvalueallowsthe
lengthoftheNetworkLayerReachabilityInformationfieldto
bedetermined,asspecifiedbelow.
Avalueof0indicatesthatnoroutesarebeingwithdrawnfrom
service,andthattheWITHDRAWNROUTESfieldisnotpresentin
thisUPDATEmessage.
WithdrawnRoutes:
ThisisavariablelengthfieldthatcontainsalistofIP
addressprefixesfortheroutesthatarebeingwithdrawnfrom
service.EachIPaddressprefixisencodedasa2tupleofthe
form<length,prefix>,whosefieldsaredescribedbelow:
++
|Length(1octet)|
++
|Prefix(variable)|
++
13/90
3/2/2015
Theuseandthemeaningofthesefieldsareasfollows:
a)Length:
TheLengthfieldindicatesthelengthinbitsoftheIP
addressprefix.Alengthofzeroindicatesaprefixthat
matchesallIPaddresses(withprefix,itself,ofzero
octets).
b)Prefix:
ThePrefixfieldcontainsanIPaddressprefix,followedby
theminimumnumberoftrailingbitsneededtomaketheend
ofthefieldfallonanoctetboundary.Notethatthevalue
oftrailingbitsisirrelevant.
TotalPathAttributeLength:
PathAttributesfieldinoctets.Itsvalueallowsthelength
oftheNetworkLayerReachabilityfieldtobedeterminedas
specifiedbelow.
Avalueof0indicatesthatneithertheNetworkLayer
ReachabilityInformationfieldnorthePathAttributefieldis
presentinthisUPDATEmessage.
PathAttributes:
Avariablelengthsequenceofpathattributesispresentin
everyUPDATEmessage,exceptforanUPDATEmessagethatcarries
onlythewithdrawnroutes.Eachpathattributeisatriple
<attributetype,attributelength,attributevalue>ofvariable
length.
AttributeTypeisatwooctetfieldthatconsistsofthe
AttributeFlagsoctet,followedbytheAttributeTypeCode
octet.
01
0123456789012345
+++++++++++++++++
|Attr.Flags|Attr.TypeCode|
+++++++++++++++++
Thehighorderbit(bit0)oftheAttributeFlagsoctetisthe
Optionalbit.Itdefineswhethertheattributeisoptional(if
setto1)orwellknown(ifsetto0).
Thesecondhighorderbit(bit1)oftheAttributeFlagsoctet
istheTransitivebit.Itdefineswhetheranoptional
attributeistransitive(ifsetto1)ornontransitive(ifset
to0).
Forwellknownattributes,theTransitivebitMUSTbesetto1.
(SeeSection5foradiscussionoftransitiveattributes.)
14/90
3/2/2015
Thethirdhighorderbit(bit2)oftheAttributeFlagsoctet
isthePartialbit.Itdefineswhethertheinformation
containedintheoptionaltransitiveattributeispartial(if
setto1)orcomplete(ifsetto0).Forwellknownattributes
andforoptionalnontransitiveattributes,thePartialbit
MUSTbesetto0.
Thefourthhighorderbit(bit3)oftheAttributeFlagsoctet
istheExtendedLengthbit.ItdefineswhethertheAttribute
Lengthisoneoctet(ifsetto0)ortwooctets(ifsetto1).
ThelowerorderfourbitsoftheAttributeFlagsoctetare
unused.TheyMUSTbezerowhensentandMUSTbeignoredwhen
received.
TheAttributeTypeCodeoctetcontainstheAttributeTypeCode.
CurrentlydefinedAttributeTypeCodesarediscussedinSection
5.
IftheExtendedLengthbitoftheAttributeFlagsoctetisset
to0,thethirdoctetofthePathAttributecontainsthelength
oftheattributedatainoctets.
IftheExtendedLengthbitoftheAttributeFlagsoctetisset
to1,thethirdandfourthoctetsofthepathattributecontain
thelengthoftheattributedatainoctets.
TheremainingoctetsofthePathAttributerepresentthe
attributevalueandareinterpretedaccordingtotheAttribute
FlagsandtheAttributeTypeCode.ThesupportedAttribute
TypeCodes,andtheirattributevaluesandusesareasfollows:
a)ORIGIN(TypeCode1):
ORIGINisawellknownmandatoryattributethatdefinesthe
originofthepathinformation.Thedataoctetcanassume
thefollowingvalues:
ValueMeaning
0IGPNetworkLayerReachabilityInformation
isinteriortotheoriginatingAS
15/90
3/2/2015
1EGPNetworkLayerReachabilityInformation
learnedviatheEGPprotocol[RFC904]
2INCOMPLETENetworkLayerReachability
Informationlearnedbysomeothermeans
Usageofthisattributeisdefinedin5.1.1.
b)AS_PATH(TypeCode2):
AS_PATHisawellknownmandatoryattributethatiscomposed
ofasequenceofASpathsegments.EachASpathsegmentis
representedbyatriple<pathsegmenttype,pathsegment
length,pathsegmentvalue>.
Thepathsegmenttypeisa1octetlengthfieldwiththe
followingvaluesdefined:
ValueSegmentType
1AS_SET:unorderedsetofASesarouteinthe
UPDATEmessagehastraversed
2AS_SEQUENCE:orderedsetofASesaroutein
theUPDATEmessagehastraversed
Thepathsegmentlengthisa1octetlengthfield,
containingthenumberofASes(notthenumberofoctets)in
thepathsegmentvaluefield.
ThepathsegmentvaluefieldcontainsoneormoreAS
numbers,eachencodedasa2octetlengthfield.
c)NEXT_HOP(TypeCode3):
Thisisawellknownmandatoryattributethatdefinesthe
(unicast)IPaddressoftherouterthatSHOULDbeusedas
thenexthoptothedestinationslistedintheNetworkLayer
ReachabilityInformationfieldoftheUPDATEmessage.
d)MULTI_EXIT_DISC(TypeCode4):
Thisisanoptionalnontransitiveattributethatisa
fouroctetunsignedinteger.Thevalueofthisattribute
MAYbeusedbyaBGPspeaker'sDecisionProcessto
discriminateamongmultipleentrypointstoaneighboring
autonomoussystem.
e)LOCAL_PREF(TypeCode5):
LOCAL_PREFisawellknownattributethatisafouroctet
unsignedinteger.ABGPspeakerusesittoinformitsother
16/90
3/2/2015
internalpeersoftheadvertisingspeaker'sdegreeof
preferenceforanadvertisedroute.
f)ATOMIC_AGGREGATE(TypeCode6)
ATOMIC_AGGREGATEisawellknowndiscretionaryattributeof
length0.
g)AGGREGATOR(TypeCode7)
AGGREGATORisanoptionaltransitiveattributeoflength6.
TheattributecontainsthelastASnumberthatformedthe
aggregateroute(encodedas2octets),followedbytheIP
addressoftheBGPspeakerthatformedtheaggregateroute
(encodedas4octets).ThisSHOULDbethesameaddressas
theoneusedfortheBGPIdentifierofthespeaker.
NetworkLayerReachabilityInformation:
ThisvariablelengthfieldcontainsalistofIPaddress
prefixes.Thelength,inoctets,oftheNetworkLayer
ReachabilityInformationisnotencodedexplicitly,butcanbe
calculatedas:
UPDATEmessageLength23TotalPathAttributesLength
WithdrawnRoutesLength
whereUPDATEmessageLengthisthevalueencodedinthefixed
sizeBGPheader,TotalPathAttributeLength,andWithdrawn
RoutesLengtharethevaluesencodedinthevariablepartof
theUPDATEmessage,and23isacombinedlengthofthefixed
sizeBGPheader,theTotalPathAttributeLengthfield,andthe
WithdrawnRoutesLengthfield.
Reachabilityinformationisencodedasoneormore2tuplesof
theform<length,prefix>,whosefieldsaredescribedbelow:
++
|Length(1octet)|
++
|Prefix(variable)|
++
Theuseandthemeaningofthesefieldsareasfollows:
a)Length:
TheLengthfieldindicatesthelengthinbitsoftheIP
addressprefix.Alengthofzeroindicatesaprefixthat
matchesallIPaddresses(withprefix,itself,ofzero
octets).
17/90
3/2/2015
b)Prefix:
ThePrefixfieldcontainsanIPaddressprefix,followedby
enoughtrailingbitstomaketheendofthefieldfallonan
octetboundary.Notethatthevalueofthetrailingbitsis
irrelevant.
TheminimumlengthoftheUPDATEmessageis23octets19octets
forthefixedheader+2octetsfortheWithdrawnRoutesLength+2
octetsfortheTotalPathAttributeLength(thevalueofWithdrawn
RoutesLengthis0andthevalueofTotalPathAttributeLengthis
0).
AnUPDATEmessagecanadvertise,atmost,onesetofpathattributes,
butmultipledestinations,providedthatthedestinationssharethese
attributes.AllpathattributescontainedinagivenUPDATEmessage
applytoalldestinationscarriedintheNLRIfieldoftheUPDATE
message.
AnUPDATEmessagecanlistmultipleroutesthataretobewithdrawn
fromservice.Eachsuchrouteisidentifiedbyitsdestination
(expressedasanIPprefix),whichunambiguouslyidentifiestheroute
inthecontextoftheBGPspeakerBGPspeakerconnectiontowhich
ithasbeenpreviouslyadvertised.
AnUPDATEmessagemightadvertiseonlyroutesthataretobe
withdrawnfromservice,inwhichcasethemessagewillnotinclude
pathattributesorNetworkLayerReachabilityInformation.
Conversely,itmayadvertiseonlyafeasibleroute,inwhichcasethe
WITHDRAWNROUTESfieldneednotbepresent.
AnUPDATEmessageSHOULDNOTincludethesameaddressprefixinthe
WITHDRAWNROUTESandNetworkLayerReachabilityInformationfields.
However,aBGPspeakerMUSTbeabletoprocessUPDATEmessagesin
thisform.ABGPspeakerSHOULDtreatanUPDATEmessageofthisform
asthoughtheWITHDRAWNROUTESdonotcontaintheaddressprefix.
4.4.KEEPALIVEMessageFormat
BGPdoesnotuseanyTCPbased,keepalivemechanismtodetermineif
peersarereachable.Instead,KEEPALIVEmessagesareexchanged
betweenpeersoftenenoughnottocausetheHoldTimertoexpire.A
reasonablemaximumtimebetweenKEEPALIVEmessageswouldbeonethird
oftheHoldTimeinterval.KEEPALIVEmessagesMUSTNOTbesentmore
frequentlythanonepersecond.AnimplementationMAYadjustthe
rateatwhichitsendsKEEPALIVEmessagesasafunctionoftheHold
Timeinterval.
IfthenegotiatedHoldTimeintervaliszero,thenperiodicKEEPALIVE
messagesMUSTNOTbesent.
AKEEPALIVEmessageconsistsofonlythemessageheaderandhasa
lengthof19octets.
18/90
3/2/2015
4.5.NOTIFICATIONMessageFormat
ANOTIFICATIONmessageissentwhenanerrorconditionisdetected.
TheBGPconnectionisclosedimmediatelyafteritissent.
InadditiontothefixedsizeBGPheader,theNOTIFICATIONmessage
containsthefollowingfields:
0123
01234567890123456789012345678901
+++++++++++++++++++++++++++++++++
|Errorcode|Errorsubcode|Data(variable)|
+++++++++++++++++++++++++++++++++
ErrorCode:
This1octetunsignedintegerindicatesthetypeof
NOTIFICATION.ThefollowingErrorCodeshavebeendefined:
ErrorCodeSymbolicNameReference
1MessageHeaderErrorSection6.1
2OPENMessageErrorSection6.2
3UPDATEMessageErrorSection6.3
4HoldTimerExpiredSection6.5
5FiniteStateMachineErrorSection6.6
6CeaseSection6.7
Errorsubcode:
This1octetunsignedintegerprovidesmorespecific
informationaboutthenatureofthereportederror.EachError
CodemayhaveoneormoreErrorSubcodesassociatedwithit.
IfnoappropriateErrorSubcodeisdefined,thenazero
(Unspecific)valueisusedfortheErrorSubcodefield.
MessageHeaderErrorsubcodes:
1ConnectionNotSynchronized.
2BadMessageLength.
3BadMessageType.
19/90
3/2/2015
OPENMessageErrorsubcodes:
1UnsupportedVersionNumber.
2BadPeerAS.
3BadBGPIdentifier.
4UnsupportedOptionalParameter.
5[DeprecatedseeAppendixA].
6UnacceptableHoldTime.
UPDATEMessageErrorsubcodes:
1MalformedAttributeList.
2UnrecognizedWellknownAttribute.
3MissingWellknownAttribute.
4AttributeFlagsError.
5AttributeLengthError.
6InvalidORIGINAttribute.
7[DeprecatedseeAppendixA].
8InvalidNEXT_HOPAttribute.
9OptionalAttributeError.
10InvalidNetworkField.
11MalformedAS_PATH.
Data:
Thisvariablelengthfieldisusedtodiagnosethereasonfor
theNOTIFICATION.ThecontentsoftheDatafielddependupon
theErrorCodeandErrorSubcode.SeeSection6formore
details.
NotethatthelengthoftheDatafieldcanbedeterminedfrom
themessageLengthfieldbytheformula:
MessageLength=21+DataLength
TheminimumlengthoftheNOTIFICATIONmessageis21octets
(includingmessageheader).
5.PathAttributes
ThissectiondiscussesthepathattributesoftheUPDATEmessage.
Pathattributesfallintofourseparatecategories:
1.Wellknownmandatory.
2.Wellknowndiscretionary.
3.Optionaltransitive.
4.Optionalnontransitive.
BGPimplementationsMUSTrecognizeallwellknownattributes.Some
oftheseattributesaremandatoryandMUSTbeincludedinevery
UPDATEmessagethatcontainsNLRI.OthersarediscretionaryandMAY
orMAYNOTbesentinaparticularUPDATEmessage.
20/90
3/2/2015
OnceaBGPpeerhasupdatedanywellknownattributes,itMUSTpass
theseattributestoitspeersinanyupdatesittransmits.
Inadditiontowellknownattributes,eachpathMAYcontainoneor
moreoptionalattributes.Itisnotrequiredorexpectedthatall
BGPimplementationssupportalloptionalattributes.Thehandlingof
anunrecognizedoptionalattributeisdeterminedbythesettingof
theTransitivebitintheattributeflagsoctet.Pathswith
unrecognizedtransitiveoptionalattributesSHOULDbeaccepted.Ifa
pathwithanunrecognizedtransitiveoptionalattributeisaccepted
andpassedtootherBGPpeers,thentheunrecognizedtransitive
optionalattributeofthatpathMUSTbepassed,alongwiththepath,
tootherBGPpeerswiththePartialbitintheAttributeFlagsoctet
setto1.Ifapathwitharecognized,transitiveoptionalattribute
isacceptedandpassedalongtootherBGPpeersandthePartialbit
intheAttributeFlagsoctetissetto1bysomepreviousAS,itMUST
NOTbesetbackto0bythecurrentAS.Unrecognizednontransitive
optionalattributesMUSTbequietlyignoredandnotpassedalongto
otherBGPpeers.
New,transitiveoptionalattributesMAYbeattachedtothepathby
theoriginatororbyanyotherBGPspeakerinthepath.Iftheyare
notattachedbytheoriginator,thePartialbitintheAttribute
Flagsoctetissetto1.Therulesforattachingnewnontransitive
optionalattributeswilldependonthenatureofthespecific
attribute.Thedocumentationofeachnewnontransitiveoptional
attributewillbeexpectedtoincludesuchrules(thedescriptionof
theMULTI_EXIT_DISCattributegivesanexample).Alloptional
attributes(bothtransitiveandnontransitive),MAYbeupdated(if
appropriate)byBGPspeakersinthepath.
ThesenderofanUPDATEmessageSHOULDorderpathattributeswithin
theUPDATEmessageinascendingorderofattributetype.The
receiverofanUPDATEmessageMUSTbepreparedtohandlepath
attributeswithinUPDATEmessagesthatareoutoforder.
Thesameattribute(attributewiththesametype)cannotappearmore
thanoncewithinthePathAttributesfieldofaparticularUPDATE
message.
ThemandatorycategoryreferstoanattributethatMUSTbepresentin
bothIBGPandEBGPexchangesifNLRIarecontainedintheUPDATE
message.Attributesclassifiedasoptionalforthepurposeofthe
protocolextensionmechanismmaybepurelydiscretionary,
discretionary,required,ordisallowedincertaincontexts.
attributeEBGPIBGP
ORIGINmandatorymandatory
AS_PATHmandatorymandatory
NEXT_HOPmandatorymandatory
MULTI_EXIT_DISCdiscretionarydiscretionary
LOCAL_PREFseeSection5.1.5required
ATOMIC_AGGREGATEseeSection5.1.6and9.1.4
AGGREGATORdiscretionarydiscretionary
21/90
3/2/2015
5.1.PathAttributeUsage
TheusageofeachBGPpathattributeisdescribedinthefollowing
clauses.
5.1.1.ORIGIN
ORIGINisawellknownmandatoryattribute.TheORIGINattributeis
generatedbythespeakerthatoriginatestheassociatedrouting
information.ItsvalueSHOULDNOTbechangedbyanyotherspeaker.
5.1.2.AS_PATH
AS_PATHisawellknownmandatoryattribute.Thisattribute
identifiestheautonomoussystemsthroughwhichroutinginformation
carriedinthisUPDATEmessagehaspassed.Thecomponentsofthis
listcanbeAS_SETsorAS_SEQUENCEs.
WhenaBGPspeakerpropagatesarouteitlearnedfromanotherBGP
speaker'sUPDATEmessage,itmodifiestheroute'sAS_PATHattribute
basedonthelocationoftheBGPspeakertowhichtheroutewillbe
sent:
a)WhenagivenBGPspeakeradvertisestheroutetoaninternal
peer,theadvertisingspeakerSHALLNOTmodifytheAS_PATH
attributeassociatedwiththeroute.
b)WhenagivenBGPspeakeradvertisestheroutetoanexternal
peer,theadvertisingspeakerupdatestheAS_PATHattributeas
follows:
1)ifthefirstpathsegmentoftheAS_PATHisoftype
AS_SEQUENCE,thelocalsystemprependsitsownASnumberas
thelastelementofthesequence(putitintheleftmost
positionwithrespecttothepositionofoctetsinthe
protocolmessage).Iftheactofprependingwillcausean
overflowintheAS_PATHsegment(i.e.,morethan255ASes),
itSHOULDprependanewsegmentoftypeAS_SEQUENCEand
prependitsownASnumbertothisnewsegment.
2)ifthefirstpathsegmentoftheAS_PATHisoftypeAS_SET,
thelocalsystemprependsanewpathsegmentoftype
AS_SEQUENCEtotheAS_PATH,includingitsownASnumberin
thatsegment.
3)iftheAS_PATHisempty,thelocalsystemcreatesapath
segmentoftypeAS_SEQUENCE,placesitsownASintothat
segment,andplacesthatsegmentintotheAS_PATH.
WhenaBGPspeakeroriginatesaroutethen:
a)theoriginatingspeakerincludesitsownASnumberinapath
segment,oftypeAS_SEQUENCE,intheAS_PATHattributeofall
UPDATEmessagessenttoanexternalpeer.Inthiscase,theAS
22/90
3/2/2015
numberoftheoriginatingspeaker'sautonomoussystemwillbe
theonlyentrythepathsegment,andthispathsegmentwillbe
theonlysegmentintheAS_PATHattribute.
b)theoriginatingspeakerincludesanemptyAS_PATHattributein
allUPDATEmessagessenttointernalpeers.(AnemptyAS_PATH
attributeisonewhoselengthfieldcontainsthevaluezero).
WheneverthemodificationoftheAS_PATHattributecallsfor
includingorprependingtheASnumberofthelocalsystem,thelocal
systemMAYinclude/prependmorethanoneinstanceofitsownAS
numberintheAS_PATHattribute.Thisiscontrolledvialocal
configuration.
5.1.3.NEXT_HOP
TheNEXT_HOPisawellknownmandatoryattributethatdefinestheIP
addressoftherouterthatSHOULDbeusedasthenexthoptothe
destinationslistedintheUPDATEmessage.TheNEXT_HOPattributeis
calculatedasfollows:
1)Whensendingamessagetoaninternalpeer,iftherouteisnot
locallyoriginated,theBGPspeakerSHOULDNOTmodifythe
NEXT_HOPattributeunlessithasbeenexplicitlyconfiguredto
announceitsownIPaddressastheNEXT_HOP.Whenannouncinga
locallyoriginatedroutetoaninternalpeer,theBGPspeaker
SHOULDusetheinterfaceaddressoftherouterthroughwhich
theannouncednetworkisreachableforthespeakerasthe
NEXT_HOP.Iftherouteisdirectlyconnectedtothespeaker,
oriftheinterfaceaddressoftherouterthroughwhichthe
announcednetworkisreachableforthespeakeristheinternal
peer'saddress,thentheBGPspeakerSHOULDuseitsownIP
addressfortheNEXT_HOPattribute(theaddressofthe
interfacethatisusedtoreachthepeer).
2)Whensendingamessagetoanexternalpeer,X,andthepeeris
oneIPhopawayfromthespeaker:
Iftheroutebeingannouncedwaslearnedfromaninternal
peerorislocallyoriginated,theBGPspeakercanusean
interfaceaddressoftheinternalpeerrouter(orthe
internalrouter)throughwhichtheannouncednetworkis
reachableforthespeakerfortheNEXT_HOPattribute,
providedthatpeerXsharesacommonsubnetwiththis
address.Thisisaformof"thirdparty"NEXT_HOPattribute.
Otherwise,iftheroutebeingannouncedwaslearnedfroman
externalpeer,thespeakercanuseanIPaddressofany
adjacentrouter(knownfromthereceivedNEXT_HOPattribute)
thatthespeakeritselfusesforlocalroutecalculationin
theNEXT_HOPattribute,providedthatpeerXsharesacommon
subnetwiththisaddress.Thisisasecondformof"third
party"NEXT_HOPattribute.
Otherwise,iftheexternalpeertowhichtherouteisbeing
advertisedsharesacommonsubnetwithoneoftheinterfaces
oftheannouncingBGPspeaker,thespeakerMAYusetheIP
23/90
3/2/2015
addressassociatedwithsuchaninterfaceintheNEXT_HOP
attribute.Thisisknownasa"firstparty"NEXT_HOP
attribute.
Bydefault(ifnoneoftheaboveconditionsapply),theBGP
speakerSHOULDusetheIPaddressoftheinterfacethatthe
speakerusestoestablishtheBGPconnectiontopeerXinthe
NEXT_HOPattribute.
3)WhensendingamessagetoanexternalpeerX,andthepeeris
multipleIPhopsawayfromthespeaker(aka"multihopEBGP"):
ThespeakerMAYbeconfiguredtopropagatetheNEXT_HOP
attribute.Inthiscase,whenadvertisingaroutethatthe
speakerlearnedfromoneofitspeers,theNEXT_HOPattribute
oftheadvertisedrouteisexactlythesameastheNEXT_HOP
attributeofthelearnedroute(thespeakerdoesnotmodify
theNEXT_HOPattribute).
Bydefault,theBGPspeakerSHOULDusetheIPaddressofthe
interfacethatthespeakerusesintheNEXT_HOPattributeto
establishtheBGPconnectiontopeerX.
Normally,theNEXT_HOPattributeischosensuchthattheshortest
availablepathwillbetaken.ABGPspeakerMUSTbeabletosupport
thedisablingadvertisementofthirdpartyNEXT_HOPattributesin
ordertohandleimperfectlybridgedmedia.
ArouteoriginatedbyaBGPspeakerSHALLNOTbeadvertisedtoapeer
usinganaddressofthatpeerasNEXT_HOP.ABGPspeakerSHALLNOT
installaroutewithitselfasthenexthop.
TheNEXT_HOPattributeisusedbytheBGPspeakertodeterminethe
actualoutboundinterfaceandimmediatenexthopaddressthatSHOULD
beusedtoforwardtransitpacketstotheassociateddestinations.
Theimmediatenexthopaddressisdeterminedbyperforminga
recursiveroutelookupoperationfortheIPaddressintheNEXT_HOP
attribute,usingthecontentsoftheRoutingTable,selectingone
entryifmultipleentriesofequalcostexist.TheRoutingTable
entrythatresolvestheIPaddressintheNEXT_HOPattributewill
alwaysspecifytheoutboundinterface.Iftheentryspecifiesan
attachedsubnet,butdoesnotspecifyanexthopaddress,thenthe
addressintheNEXT_HOPattributeSHOULDbeusedastheimmediate
nexthopaddress.Iftheentryalsospecifiesthenexthopaddress,
thisaddressSHOULDbeusedastheimmediatenexthopaddressfor
packetforwarding.
5.1.4.MULTI_EXIT_DISC
TheMULTI_EXIT_DISCisanoptionalnontransitiveattributethatis
intendedtobeusedonexternal(interAS)linkstodiscriminate
amongmultipleexitorentrypointstothesameneighboringAS.The
valueoftheMULTI_EXIT_DISCattributeisafouroctetunsigned
number,calledametric.Allotherfactorsbeingequal,theexit
pointwiththelowermetricSHOULDbepreferred.Ifreceivedover
EBGP,theMULTI_EXIT_DISCattributeMAYbepropagatedoverIBGPto
24/90
3/2/2015
otherBGPspeakerswithinthesameAS(seealso9.1.2.2).The
MULTI_EXIT_DISCattributereceivedfromaneighboringASMUSTNOTbe
propagatedtootherneighboringASes.
ABGPspeakerMUSTimplementamechanism(basedonlocal
configuration)thatallowstheMULTI_EXIT_DISCattributetobe
removedfromaroute.IfaBGPspeakerisconfiguredtoremovethe
MULTI_EXIT_DISCattributefromaroute,thenthisremovalMUSTbe
donepriortodeterminingthedegreeofpreferenceoftherouteand
priortoperformingrouteselection(DecisionProcessphases1and
2).
AnimplementationMAYalso(basedonlocalconfiguration)alterthe
valueoftheMULTI_EXIT_DISCattributereceivedoverEBGP.IfaBGP
speakerisconfiguredtoalterthevalueoftheMULTI_EXIT_DISC
attributereceivedoverEBGP,thenalteringthevalueMUSTbedone
priortodeterminingthedegreeofpreferenceoftherouteandprior
toperformingrouteselection(DecisionProcessphases1and2).See
Section9.1.2.2fornecessaryrestrictionsonthis.
5.1.5.LOCAL_PREF
LOCAL_PREFisawellknownattributethatSHALLbeincludedinall
UPDATEmessagesthatagivenBGPspeakersendstootherinternal
peers.ABGPspeakerSHALLcalculatethedegreeofpreferencefor
eachexternalroutebasedonthelocallyconfiguredpolicy,and
includethedegreeofpreferencewhenadvertisingaroutetoits
internalpeers.ThehigherdegreeofpreferenceMUSTbepreferred.
ABGPspeakerusesthedegreeofpreferencelearnedviaLOCAL_PREFin
itsDecisionProcess(seeSection9.1.1).
ABGPspeakerMUSTNOTincludethisattributeinUPDATEmessagesit
sendstoexternalpeers,exceptinthecaseofBGPConfederations
[RFC3065].IfitiscontainedinanUPDATEmessagethatisreceived
fromanexternalpeer,thenthisattributeMUSTbeignoredbythe
receivingspeaker,exceptinthecaseofBGPConfederations
[RFC3065].
5.1.6.ATOMIC_AGGREGATE
ATOMIC_AGGREGATEisawellknowndiscretionaryattribute.
WhenaBGPspeakeraggregatesseveralroutesforthepurposeof
advertisementtoaparticularpeer,theAS_PATHoftheaggregated
routenormallyincludesanAS_SETformedfromthesetofASesfrom
whichtheaggregatewasformed.Inmanycases,thenetwork
administratorcandetermineiftheaggregatecansafelybeadvertised
withouttheAS_SET,andwithoutformingrouteloops.
IfanaggregateexcludesatleastsomeoftheASnumberspresentin
theAS_PATHoftheroutesthatareaggregatedasaresultofdropping
theAS_SET,theaggregatedroute,whenadvertisedtothepeer,SHOULD
includetheATOMIC_AGGREGATEattribute.
25/90
3/2/2015
ABGPspeakerthatreceivesaroutewiththeATOMIC_AGGREGATE
attributeSHOULDNOTremovetheattributewhenpropagatingtheroute
tootherspeakers.
attributeMUSTNOTmakeanyNLRIofthatroutemorespecific(as
definedin9.1.4)whenadvertisingthisroutetootherBGPspeakers.
attributeneedstobeawareofthefactthattheactualpathto
destinations,asspecifiedintheNLRIoftheroute,whilehavingthe
loopfreeproperty,maynotbethepathspecifiedintheAS_PATH
attributeoftheroute.
5.1.7.AGGREGATOR
AGGREGATORisanoptionaltransitiveattribute,whichMAYbeincluded
inupdatesthatareformedbyaggregation(seeSection9.2.2.2).A
BGPspeakerthatperformsrouteaggregationMAYaddtheAGGREGATOR
attribute,whichSHALLcontainitsownASnumberandIPaddress.The
IPaddressSHOULDbethesameastheBGPIdentifierofthespeaker.
6.BGPErrorHandling.
Thissectiondescribesactionstobetakenwhenerrorsaredetected
whileprocessingBGPmessages.
Whenanyoftheconditionsdescribedherearedetected,a
NOTIFICATIONmessage,withtheindicatedErrorCode,ErrorSubcode,
andDatafields,issent,andtheBGPconnectionisclosed(unlessit
isexplicitlystatedthatnoNOTIFICATIONmessageistobesentand
theBGPconnectionisnottobeclosed).IfnoErrorSubcodeis
specified,thenazeroMUSTbeused.
Thephrase"theBGPconnectionisclosed"meanstheTCPconnection
hasbeenclosed,theassociatedAdjRIBInhasbeencleared,andall
resourcesforthatBGPconnectionhavebeendeallocated.Entriesin
theLocRIBassociatedwiththeremotepeeraremarkedasinvalid.
Thelocalsystemrecalculatesitsbestroutesforthedestinationsof
theroutesmarkedasinvalid.Beforetheinvalidroutesaredeleted
fromthesystem,itadvertises,toitspeers,eitherwithdrawsfor
theroutesmarkedasinvalid,orthenewbestroutesbeforethe
invalidroutesaredeletedfromthesystem.
Unlessspecifiedexplicitly,theDatafieldoftheNOTIFICATION
messagethatissenttoindicateanerrorisempty.
6.1.MessageHeaderErrorHandling
AllerrorsdetectedwhileprocessingtheMessageHeaderMUSTbe
26/90
3/2/2015
indicatedbysendingtheNOTIFICATIONmessagewiththeErrorCode
MessageHeaderError.TheErrorSubcodeelaboratesonthespecific
natureoftheerror.
TheexpectedvalueoftheMarkerfieldofthemessageheaderisall
ones.IftheMarkerfieldofthemessageheaderisnotasexpected,
thenasynchronizationerrorhasoccurredandtheErrorSubcodeMUST
besettoConnectionNotSynchronized.
Ifatleastoneofthefollowingistrue:
iftheLengthfieldofthemessageheaderislessthan19or
greaterthan4096,or
iftheLengthfieldofanOPENmessageislessthantheminimum
lengthoftheOPENmessage,or
iftheLengthfieldofanUPDATEmessageislessthanthe
minimumlengthoftheUPDATEmessage,or
iftheLengthfieldofaKEEPALIVEmessageisnotequalto19,
or
iftheLengthfieldofaNOTIFICATIONmessageislessthanthe
minimumlengthoftheNOTIFICATIONmessage,
thentheErrorSubcodeMUSTbesettoBadMessageLength.TheData
fieldMUSTcontaintheerroneousLengthfield.
IftheTypefieldofthemessageheaderisnotrecognized,thenthe
ErrorSubcodeMUSTbesettoBadMessageType.TheDatafieldMUST
containtheerroneousTypefield.
6.2.OPENMessageErrorHandling
AllerrorsdetectedwhileprocessingtheOPENmessageMUSTbe
OPENMessageError.TheErrorSubcodeelaboratesonthespecific
natureoftheerror.
IftheversionnumberintheVersionfieldofthereceivedOPEN
messageisnotsupported,thentheErrorSubcodeMUSTbesetto
UnsupportedVersionNumber.TheDatafieldisa2octetunsigned
integer,whichindicatesthelargest,locallysupportedversion
numberlessthantheversiontheremoteBGPpeerbid(asindicatedin
thereceivedOPENmessage),orifthesmallest,locallysupported
versionnumberisgreaterthantheversiontheremoteBGPpeerbid,
thenthesmallest,locallysupportedversionnumber.
IftheAutonomousSystemfieldoftheOPENmessageisunacceptable,
thentheErrorSubcodeMUSTbesettoBadPeerAS.Thedetermination
ofacceptableAutonomousSystemnumbersisoutsidethescopeofthis
protocol.
IftheHoldTimefieldoftheOPENmessageisunacceptable,thenthe
ErrorSubcodeMUSTbesettoUnacceptableHoldTime.An
implementationMUSTrejectHoldTimevaluesofoneortwoseconds.
27/90
3/2/2015
AnimplementationMAYrejectanyproposedHoldTime.An
implementationthatacceptsaHoldTimeMUSTusethenegotiatedvalue
fortheHoldTime.
IftheBGPIdentifierfieldoftheOPENmessageissyntactically
incorrect,thentheErrorSubcodeMUSTbesettoBadBGPIdentifier.
SyntacticcorrectnessmeansthattheBGPIdentifierfieldrepresents
avalidunicastIPhostaddress.
IfoneoftheOptionalParametersintheOPENmessageisnot
recognized,thentheErrorSubcodeMUSTbesettoUnsupported
OptionalParameters.
IfoneoftheOptionalParametersintheOPENmessageisrecognized,
butismalformed,thentheErrorSubcodeMUSTbesetto0
(Unspecific).
6.3.UPDATEMessageErrorHandling
AllerrorsdetectedwhileprocessingtheUPDATEmessageMUSTbe
UPDATEMessageError.Theerrorsubcodeelaboratesonthespecific
natureoftheerror.
ErrorcheckingofanUPDATEmessagebeginsbyexaminingthepath
attributes.IftheWithdrawnRoutesLengthorTotalAttributeLength
istoolarge(i.e.,ifWithdrawnRoutesLength+TotalAttribute
Length+23exceedsthemessageLength),thentheErrorSubcodeMUST
besettoMalformedAttributeList.
IfanyrecognizedattributehasAttributeFlagsthatconflictwith
theAttributeTypeCode,thentheErrorSubcodeMUSTbesetto
AttributeFlagsError.TheDatafieldMUSTcontaintheerroneous
attribute(type,length,andvalue).
IfanyrecognizedattributehasanAttributeLengththatconflicts
withtheexpectedlength(basedontheattributetypecode),thenthe
ErrorSubcodeMUSTbesettoAttributeLengthError.TheDatafield
MUSTcontaintheerroneousattribute(type,length,andvalue).
Ifanyofthewellknownmandatoryattributesarenotpresent,then
theErrorSubcodeMUSTbesettoMissingWellknownAttribute.The
DatafieldMUSTcontaintheAttributeTypeCodeofthemissing,
wellknownattribute.
Ifanyofthewellknownmandatoryattributesarenotrecognized,
thentheErrorSubcodeMUSTbesettoUnrecognizedWellknown
Attribute.TheDatafieldMUSTcontaintheunrecognizedattribute
(type,length,andvalue).
IftheORIGINattributehasanundefinedvalue,thentheErrorSub
codeMUSTbesettoInvalidOriginAttribute.TheDatafieldMUST
containtheunrecognizedattribute(type,length,andvalue).
IftheNEXT_HOPattributefieldissyntacticallyincorrect,thenthe
ErrorSubcodeMUSTbesettoInvalidNEXT_HOPAttribute.TheData
28/90
3/2/2015
fieldMUSTcontaintheincorrectattribute(type,length,andvalue).
SyntacticcorrectnessmeansthattheNEXT_HOPattributerepresentsa
validIPhostaddress.
TheIPaddressintheNEXT_HOPMUSTmeetthefollowingcriteriatobe
consideredsemanticallycorrect:
a)ItMUSTNOTbetheIPaddressofthereceivingspeaker.
b)InthecaseofanEBGP,wherethesenderandreceiverareone
IPhopawayfromeachother,eithertheIPaddressinthe
NEXT_HOPMUSTbethesender'sIPaddressthatisusedto
establishtheBGPconnection,ortheinterfaceassociatedwith
theNEXT_HOPIPaddressMUSTshareacommonsubnetwiththe
receivingBGPspeaker.
IftheNEXT_HOPattributeissemanticallyincorrect,theerrorSHOULD
belogged,andtherouteSHOULDbeignored.Inthiscase,a
NOTIFICATIONmessageSHOULDNOTbesent,andtheconnectionSHOULD
NOTbeclosed.
TheAS_PATHattributeischeckedforsyntacticcorrectness.Ifthe
pathissyntacticallyincorrect,thentheErrorSubcodeMUSTbeset
toMalformedAS_PATH.
IftheUPDATEmessageisreceivedfromanexternalpeer,thelocal
systemMAYcheckwhethertheleftmost(withrespecttotheposition
ofoctetsintheprotocolmessage)ASintheAS_PATHattributeis
equaltotheautonomoussystemnumberofthepeerthatsentthe
message.Ifthecheckdeterminesthisisnotthecase,theError
SubcodeMUSTbesettoMalformedAS_PATH.
Ifanoptionalattributeisrecognized,thenthevalueofthis
attributeMUSTbechecked.Ifanerrorisdetected,theattribute
MUSTbediscarded,andtheErrorSubcodeMUSTbesettoOptional
AttributeError.TheDatafieldMUSTcontaintheattribute(type,
length,andvalue).
IfanyattributeappearsmorethanonceintheUPDATEmessage,then
theErrorSubcodeMUSTbesettoMalformedAttributeList.
TheNLRIfieldintheUPDATEmessageischeckedforsyntactic
validity.Ifthefieldissyntacticallyincorrect,thentheError
SubcodeMUSTbesettoInvalidNetworkField.
IfaprefixintheNLRIfieldissemanticallyincorrect(e.g.,an
unexpectedmulticastIPaddress),anerrorSHOULDbeloggedlocally,
andtheprefixSHOULDbeignored.
AnUPDATEmessagethatcontainscorrectpathattributes,butnoNLRI,
SHALLbetreatedasavalidUPDATEmessage.
6.4.NOTIFICATIONMessageErrorHandling
IfapeersendsaNOTIFICATIONmessage,andthereceiverofthe
29/90
3/2/2015
messagedetectsanerrorinthatmessage,thereceivercannotusea
NOTIFICATIONmessagetoreportthiserrorbacktothepeer.Anysuch
error(e.g.,anunrecognizedErrorCodeorErrorSubcode)SHOULDbe
noticed,loggedlocally,andbroughttotheattentionofthe
administrationofthepeer.Themeanstodothis,however,lies
outsidethescopeofthisdocument.
6.5.HoldTimerExpiredErrorHandling
IfasystemdoesnotreceivesuccessiveKEEPALIVE,UPDATE,and/or
NOTIFICATIONmessageswithintheperiodspecifiedintheHoldTime
fieldoftheOPENmessage,thentheNOTIFICATIONmessagewiththe
HoldTimerExpiredErrorCodeissentandtheBGPconnectionis
closed.
6.6.FiniteStateMachineErrorHandling
AnyerrordetectedbytheBGPFiniteStateMachine(e.g.,receiptof
anunexpectedevent)isindicatedbysendingtheNOTIFICATIONmessage
withtheErrorCodeFiniteStateMachineError.
6.7.Cease
Intheabsenceofanyfatalerrors(thatareindicatedinthis
section),aBGPpeerMAYchoose,atanygiventime,tocloseitsBGP
connectionbysendingtheNOTIFICATIONmessagewiththeErrorCode
Cease.However,theCeaseNOTIFICATIONmessageMUSTNOTbeusedwhen
afatalerrorindicatedbythissectiondoesexist.
ABGPspeakerMAYsupporttheabilitytoimposealocallyconfigured,
upperboundonthenumberofaddressprefixesthespeakeriswilling
toacceptfromaneighbor.Whentheupperboundisreached,the
speaker,undercontroloflocalconfiguration,either(a)discards
newaddressprefixesfromtheneighbor(whilemaintainingtheBGP
connectionwiththeneighbor),or(b)terminatestheBGPconnection
withtheneighbor.IftheBGPspeakerdecidestoterminateitsBGP
connectionwithaneighborbecausethenumberofaddressprefixes
receivedfromtheneighborexceedsthelocallyconfigured,upper
bound,thenthespeakerMUSTsendtheneighboraNOTIFICATIONmessage
withtheErrorCodeCease.ThespeakerMAYalsologthislocally.
6.8.BGPConnectionCollisionDetection
IfapairofBGPspeakerstrytoestablishaBGPconnectionwitheach
othersimultaneously,thentwoparallelconnectionswellbeformed.
IfthesourceIPaddressusedbyoneoftheseconnectionsisthesame
asthedestinationIPaddressusedbytheother,andthedestination
IPaddressusedbythefirstconnectionisthesameasthesourceIP
addressusedbytheother,connectioncollisionhasoccurred.Inthe
eventofconnectioncollision,oneoftheconnectionsMUSTbeclosed.
BasedonthevalueoftheBGPIdentifier,aconventionisestablished
fordetectingwhichBGPconnectionistobepreservedwhena
collisionoccurs.TheconventionistocomparetheBGPIdentifiers
30/90
3/2/2015
ofthepeersinvolvedinthecollisionandtoretainonlythe
connectioninitiatedbytheBGPspeakerwiththehighervaluedBGP
Identifier.
UponreceiptofanOPENmessage,thelocalsystemMUSTexamineallof
itsconnectionsthatareintheOpenConfirmstate.ABGPspeakerMAY
alsoexamineconnectionsinanOpenSentstateifitknowstheBGP
Identifierofthepeerbymeansoutsideoftheprotocol.If,among
theseconnections,thereisaconnectiontoaremoteBGPspeaker
whoseBGPIdentifierequalstheoneintheOPENmessage,andthis
connectioncollideswiththeconnectionoverwhichtheOPENmessage
isreceived,thenthelocalsystemperformsthefollowingcollision
resolutionprocedure:
1)TheBGPIdentifierofthelocalsystemiscomparedtotheBGP
Identifieroftheremotesystem(asspecifiedintheOPEN
message).ComparingBGPIdentifiersisdonebyconvertingthem
tohostbyteorderandtreatingthemas4octetunsigned
integers.
2)IfthevalueofthelocalBGPIdentifierislessthanthe
remoteone,thelocalsystemclosestheBGPconnectionthat
alreadyexists(theonethatisalreadyintheOpenConfirm
state),andacceptstheBGPconnectioninitiatedbytheremote
system.
3)Otherwise,thelocalsystemclosesthenewlycreatedBGP
connection(theoneassociatedwiththenewlyreceivedOPEN
message),andcontinuestousetheexistingone(theonethat
isalreadyintheOpenConfirmstate).
Unlessallowedviaconfiguration,aconnectioncollisionwithan
existingBGPconnectionthatisintheEstablishedstatecauses
closingofthenewlycreatedconnection.
Notethataconnectioncollisioncannotbedetectedwithconnections
thatareinIdle,Connect,orActivestates.
ClosingtheBGPconnection(thatresultsfromthecollision
resolutionprocedure)isaccomplishedbysendingtheNOTIFICATION
messagewiththeErrorCodeCease.
7.BGPVersionNegotiation
BGPspeakersMAYnegotiatetheversionoftheprotocolbymaking
multipleattemptsatopeningaBGPconnection,startingwiththe
highestversionnumbereachBGPspeakersupports.Ifanopenattempt
failswithanErrorCode,OPENMessageError,andanErrorSubcode,
UnsupportedVersionNumber,thentheBGPspeakerhasavailablethe
versionnumberittried,theversionnumberitspeertried,the
versionnumberpassedbyitspeerintheNOTIFICATIONmessage,and
theversionnumbersitsupports.Ifthetwopeersdosupportoneor
morecommonversions,thenthiswillallowthemtorapidlydetermine
thehighestcommonversion.InordertosupportBGPversion
negotiation,futureversionsofBGPMUSTretaintheformatofthe
OPENandNOTIFICATIONmessages.
31/90
3/2/2015
8.BGPFiniteStateMachine(FSM)
ThedatastructuresandFSMdescribedinthisdocumentareconceptual
anddonothavetobeimplementedpreciselyasdescribedhere,as
longastheimplementationssupportthedescribedfunctionalityand
theyexhibitthesameexternallyvisiblebehavior.
ThissectionspecifiestheBGPoperationintermsofaFiniteState
Machine(FSM).Thesectionfallsintotwoparts:
1)DescriptionofEventsfortheStatemachine(Section8.1)
2)DescriptionoftheFSM(Section8.2)
Sessionattributesrequired(mandatory)foreachconnectionare:
1)State
2)ConnectRetryCounter
3)ConnectRetryTimer
4)ConnectRetryTime
5)HoldTimer
6)HoldTime
7)KeepaliveTimer
8)KeepaliveTime
ThestatesessionattributeindicatesthecurrentstateoftheBGP
FSM.TheConnectRetryCounterindicatesthenumberoftimesaBGP
peerhastriedtoestablishapeersession.
ThemandatoryattributesrelatedtotimersaredescribedinSection
10.Eachtimerhasa"timer"anda"time"(theinitialvalue).
TheoptionalSessionattributesarelistedbelow.Theseoptional
attributesmaybesupported,eitherperconnectionorperlocal
system:
1)AcceptConnectionsUnconfiguredPeers
2)AllowAutomaticStart
3)AllowAutomaticStop
4)CollisionDetectEstablishedState
5)DampPeerOscillations
6)DelayOpen
7)DelayOpenTime
8)DelayOpenTimer
9)IdleHoldTime
10)IdleHoldTimer
11)PassiveTcpEstablishment
12)SendNOTIFICATIONwithoutOPEN
13)TrackTcpState
TheoptionalsessionattributessupportdifferentfeaturesoftheBGP
32/90
3/2/2015
functionalitythathaveimplicationsfortheBGPFSMstate
transitions.Twogroupsoftheattributeswhichrelatetotimers
are:
group1:DelayOpen,DelayOpenTime,DelayOpenTimer
group2:DampPeerOscillations,IdleHoldTime,IdleHoldTimer
Thefirstparameter(DelayOpen,DampPeerOscillations)isanoptional
attributethatindicatesthattheTimerfunctionisactive.The
"Time"valuespecifiestheinitialvalueforthe"Timer"
(DelayOpenTime,IdleHoldTime).The"Timer"specifiestheactual
timer.
PleaserefertoSection8.1.1foranexplanationoftheinteraction
betweentheseoptionalattributesandtheeventssignaledtothe
statemachine.Section8.2.1.3alsoprovidesashortoverviewofthe
differenttypesofoptionalattributes(flagsortimers).
8.1.EventsfortheBGPFSM
8.1.1.OptionalEventsLinkedtoOptionalSessionAttributes
TheInputstotheBGPFSMareevents.Eventscaneitherbemandatory
oroptional.Someoptionaleventsarelinkedtooptionalsession
attributes.OptionalsessionattributesenableseveralgroupsofFSM
functionality.
ThelinkagebetweenFSMfunctionality,events,andtheoptional
sessionattributesaredescribedbelow.
Group1:AutomaticAdministrativeEvents(Start/Stop)
OptionalSessionAttributes:AllowAutomaticStart,
AllowAutomaticStop,
DampPeerOscillations,
IdleHoldTime,IdleHoldTimer
Option1:AllowAutomaticStart
Description:ABGPpeerconnectioncanbestartedandstopped
byadministrativecontrol.Thisadministrative
controlcaneitherbemanual,basedonoperator
intervention,orunderthecontroloflogicthat
isspecifictoaBGPimplementation.Theterm
"automatic"referstoastartbeingissuedtothe
BGPpeerconnectionFSMwhensuchlogicdetermines
thattheBGPpeerconnectionshouldberestarted.
TheAllowAutomaticStartattributespecifiesthat
thisBGPconnectionsupportsautomaticstartingof
theBGPconnection.
IftheBGPimplementationsupports
AllowAutomaticStart,thepeermayberepeatedly
restarted.Threeotheroptionscontroltherate
atwhichtheautomaticrestartoccurs:
DampPeerOscillations,IdleHoldTime,andthe
IdleHoldTimer.
33/90
3/2/2015
TheDampPeerOscillationsoptionspecifiesthatthe
implementationengagesadditionallogictodamp
theoscillationsofBGPpeersinthefaceof
sequencesofautomaticstartandautomaticstop.
IdleHoldTimespecifiesthelengthoftimetheBGP
peerisheldintheIdlestatepriortoallowing
thenextautomaticrestart.TheIdleHoldTimeris
thetimerthatholdsthepeerinIdlestate.
AnexampleofDampPeerOscillationslogicisan
increaseoftheIdleHoldTimevalueifaBGPpeer
oscillatesconnectivity(connected/disconnected)
repeatedlywithinatimeperiod.Toengagethis
logic,apeercouldconnectanddisconnect10
timeswithin5minutes.TheIdleHoldTimevalue
wouldberesetfrom0to120seconds.
Values:TRUEorFALSE
Option2:AllowAutomaticStop
Description:ThisBGPpeersessionoptionalattributeindicates
thattheBGPconnectionallows"automatic"
stoppingoftheBGPconnection.An"automatic"
stopisdefinedasastopunderthecontrolof
implementationspecificlogic.The
implementationspecificlogicisoutsidethescope
ofthisspecification.
Values:TRUEorFALSE
Option3:DampPeerOscillations
Description:TheDampPeerOscillationsoptionalsession
attributeindicatesthattheBGPconnectionis
usinglogicthatdampsBGPpeeroscillationsin
theIdleState.
Value:TRUEorFALSE
Option4:IdleHoldTime
Description:TheIdleHoldTimeisthevaluethatissetinthe
IdleHoldTimer.
Values:Timeinseconds
Option5:IdleHoldTimer
Description:TheIdleHoldTimeraidsincontrollingBGPpeer
oscillation.TheIdleHoldTimerisusedtokeep
theBGPpeerinIdleforaparticularduration.
TheIdleHoldTimer_Expireseventisdescribedin
Section8.1.3.
Values:Timeinseconds
34/90
3/2/2015
Group2:UnconfiguredPeers
OptionalSessionAttributes:AcceptConnectionsUnconfiguredPeers
Option1:AcceptConnectionsUnconfiguredPeers
Description:TheBGPFSMoptionallyallowstheacceptanceof
BGPpeerconnectionsfromneighborsthatarenot
preconfigured.The
"AcceptConnectionsUnconfiguredPeers"optional
sessionattributeallowstheFSMtosupportthe
statetransitionsthatallowtheimplementationto
acceptorrejecttheseunconfiguredpeers.
TheAcceptConnectionsUnconfiguredPeershas
securityimplications.PleaserefertotheBGP
Vulnerabilitiesdocument[RFC4272]fordetails.
Value:TrueorFalse
Group3:TCPprocessing
OptionalSessionAttributes:PassiveTcpEstablishment,
TrackTcpState
Option1:PassiveTcpEstablishment
Description:ThisoptionindicatesthattheBGPFSMwill
passivelywaitfortheremoteBGPpeerto
establishtheBGPTCPconnection.
value:TRUEorFALSE
Option2:TrackTcpState
Description:TheBGPFSMnormallytrackstheendresultofa
TCPconnectionattemptratherthanindividualTCP
messages.Optionally,theBGPFSMcansupport
additionalinteractionwiththeTCPconnection
negotiation.TheinteractionwiththeTCPevents
mayincreasetheamountofloggingtheBGPpeer
connectionrequiresandthenumberofBGPFSM
changes.
Value:TRUEorFALSE
Group4:BGPMessageProcessing
OptionalSessionAttributes:DelayOpen,DelayOpenTime,
DelayOpenTimer,
SendNOTIFICATIONwithoutOPEN,
CollisionDetectEstablishedState
Option1:DelayOpen
35/90
3/2/2015
Description:TheDelayOpenoptionalsessionattributeallows
implementationstobeconfiguredtodelaysending
anOPENmessageforaspecifictimeperiod
(DelayOpenTime).ThedelayallowstheremoteBGP
PeertimetosendthefirstOPENmessage.
Value:TRUEorFALSE
Option2:DelayOpenTime
Description:TheDelayOpenTimeistheinitialvaluesetinthe
DelayOpenTimer.
Value:Timeinseconds
Option3:DelayOpenTimer
Description:TheDelayOpenTimeroptionalsessionattributeis
usedtodelaythesendingofanOPENmessageona
connection.TheDelayOpenTimer_Expiresevent
(Event12)isdescribedinSection8.1.3.
Value:Timeinseconds
Option4:SendNOTIFICATIONwithoutOPEN
Description:TheSendNOTIFICATIONwithoutOPENallowsapeerto
sendaNOTIFICATIONwithoutfirstsendinganOPEN
message.Withoutthisoptionalsessionattribute,
theBGPconnectionassumesthatanOPENmessage
mustbesentbyapeerpriortothepeersendinga
NOTIFICATIONmessage.
Value:TrueorFalse
Option5:CollisionDetectEstablishedState
Description:Normally,aDetectCollision(seeSection6.8)
willbeignoredintheEstablishedstate.This
optionalsessionattributeindicatesthatthisBGP
connectionprocessescollisionsintheEstablished
state.
Value:TrueorFalse
Note:TheoptionalsessionattributesclarifytheBGPFSM
descriptionforexistingfeaturesofBGPimplementations.
Theoptionalsessionattributesmaybepredefinedforan
implementationandnotreadableviamanagementinterfaces
forexistingcorrectimplementations.AsnewerBGPMIBs
(version2andbeyond)aresupported,thesefieldswillbe
accessibleviaamanagementinterface.
8.1.2.AdministrativeEvents
Anadministrativeeventisaneventinwhichtheoperatorinterface
36/90
3/2/2015
andBGPPolicyenginesignaltheBGPfinitestatemachinetostartor
stoptheBGPstatemachine.Thebasicstartandstopindicationsare
augmentedbyoptionalconnectionattributesthatsignalacertain
typeofstartorstopmechanismtotheBGPFSM.Anexampleofthis
combinationisEvent5,AutomaticStart_with_PassiveTcpEstablishment.
Withthisevent,theBGPimplementationsignalstotheBGPFSMthat
theimplementationisusinganAutomaticStartwiththeoptiontouse
aPassiveTCPEstablishment.ThePassiveTCPestablishmentsignals
thatthisBGPFSMwillwaitfortheremotesidetostarttheTCP
establishment.
NotethatonlyEvent1(ManualStart)andEvent2(ManualStop)are
mandatoryadministrativeevents.Allotheradministrativeeventsare
optional(Events38).Eacheventbelowhasaname,definition,
status(mandatoryoroptional),andtheoptionalsessionattributes
thatSHOULDbesetateachstage.WhengeneratingEvent1through
Event8fortheBGPFSM,theconditionsspecifiedinthe"Optional
AttributeStatus"sectionareverified.Ifanyoftheseconditions
arenotsatisfied,thenthelocalsystemshouldloganFSMerror.
Thesettingsofoptionalsessionattributesmaybeimplicitinsome
implementations,andthereforemaynotbesetexplicitlybyan
externaloperatoraction.Section8.2.1.5describestheseimplicit
settingsoftheoptionalsessionattributes.Theadministrative
statesdescribedbelowmayalsobeimplicitinsomeimplementations
andnotdirectlyconfigurablebyanexternaloperator.
Event1:ManualStart
Definition:Localsystemadministratormanuallystartsthepeer
connection.
Status:Mandatory
Optional
Attribute
Status:ThePassiveTcpEstablishmentattributeSHOULDbeset
toFALSE.
Event2:ManualStop
Definition:Localsystemadministratormanuallystopsthepeer
connection.
Status:Mandatory
Optional
Attribute
Status:Nointeractionwithanyoptionalattributes.
Event3:AutomaticStart
Definition:LocalsystemautomaticallystartstheBGP
connection.
Status:Optional,dependingonlocalsystem
37/90
3/2/2015
Optional
Attribute
Status:1)TheAllowAutomaticStartattributeSHOULDbeset
toTRUEifthiseventoccurs.
2)IfthePassiveTcpEstablishmentoptionalsession
attributeissupported,itSHOULDbesetto
FALSE.
3)IftheDampPeerOscillationsissupported,it
SHOULDbesettoFALSEwhenthiseventoccurs.
Event4:ManualStart_with_PassiveTcpEstablishment
Definition:Localsystemadministratormanuallystartsthepeer
connection,buthasPassiveTcpEstablishment
enabled.ThePassiveTcpEstablishmentoptional
attributeindicatesthatthepeerwilllistenprior
toestablishingtheconnection.
Optional
Attribute
Status:1)ThePassiveTcpEstablishmentattributeSHOULDbe
settoTRUEifthiseventoccurs.
2)TheDampPeerOscillationsattributeSHOULDbeset
toFALSEwhenthiseventoccurs.
Event5:AutomaticStart_with_PassiveTcpEstablishment
Definition:LocalsystemautomaticallystartstheBGP
connectionwiththePassiveTcpEstablishment
enabled.ThePassiveTcpEstablishmentoptional
attributeindicatesthatthepeerwilllistenprior
toestablishingaconnection.
Optional
Attribute
toTRUE.
2)ThePassiveTcpEstablishmentattributeSHOULDbe
settoTRUE.
3)IftheDampPeerOscillationsattributeis
supported,theDampPeerOscillationsSHOULDbe
settoFALSE.
38/90
3/2/2015
Event6:AutomaticStart_with_DampPeerOscillations
Definition:LocalsystemautomaticallystartstheBGPpeer
connectionwithpeeroscillationdampingenabled.
Theexactmethodofdampingpersistentpeer
oscillationsisdeterminedbytheimplementation
andisoutsidethescopeofthisdocument.
Status:Optional,dependingonlocalsystem.
Optional
Attribute
toTRUE.
toTRUE.
settoFALSE.
Event7:AutomaticStart_with_DampPeerOscillations_and_
PassiveTcpEstablishment
Definition:LocalsystemautomaticallystartstheBGPpeer
connectionwithpeeroscillationdampingenabled
andPassiveTcpEstablishmentenabled.Theexact
methodofdampingpersistentpeeroscillationsis
determinedbytheimplementationandisoutsidethe
scopeofthisdocument.
Optional
Attributes
toTRUE.
toTRUE.
settoTRUE.
Event8:AutomaticStop
Definition:LocalsystemautomaticallystopstheBGP
connection.
Anexampleofanautomaticstopeventisexceeding
thenumberofprefixesforagivenpeerandthe
localsystemautomaticallydisconnectingthepeer.
Optional
Attribute
Status:1)TheAllowAutomaticStopattributeSHOULDbeTRUE.
8.1.3.TimerEvents
39/90
3/2/2015
Event9:ConnectRetryTimer_Expires
Definition:AneventgeneratedwhentheConnectRetryTimer
expires.
Status:Mandatory
Event10:HoldTimer_Expires
Definition:AneventgeneratedwhentheHoldTimerexpires.
Status:Mandatory
Event11:KeepaliveTimer_Expires
Definition:AneventgeneratedwhentheKeepaliveTimerexpires.
Status:Mandatory
Event12:DelayOpenTimer_Expires
Definition:AneventgeneratedwhentheDelayOpenTimerexpires.
Status:Optional
Optional
Attribute
Status:Ifthiseventoccurs,
1)DelayOpenattributeSHOULDbesettoTRUE,
2)DelayOpenTimeattributeSHOULDbesupported,
3)DelayOpenTimerSHOULDbesupported.
Event13:IdleHoldTimer_Expires
Definition:AneventgeneratedwhentheIdleHoldTimerexpires,
indicatingthattheBGPconnectionhascompleted
waitingforthebackoffperiodtopreventBGPpeer
oscillation.
TheIdleHoldTimerisonlyusedwhenthepersistent
peeroscillationdampingfunctionisenabledby
settingtheDampPeerOscillationsoptionalattribute
toTRUE.
Implementationsnotimplementingthepersistent
peeroscillationdampingfunctionmaynothavethe
IdleHoldTimer.
Status:Optional
Optional
Attribute
Status:Ifthiseventoccurs:
1)DampPeerOscillationsattributeSHOULDbesetto
TRUE.
2)IdleHoldTimerSHOULDhavejustexpired.
40/90
3/2/2015
8.1.4.TCPConnectionBasedEvents
Event14:TcpConnection_Valid
Definition:Eventindicatingthelocalsystemreceptionofa
TCPconnectionrequestwithavalidsourceIP
address,TCPport,destinationIPaddress,andTCP
Port.Thedefinitionofinvalidsourceandinvalid
destinationIPaddressisdeterminedbythe
implementation.
BGP'sdestinationportSHOULDbeport179,as
definedbyIANA.
TCPconnectionrequestisdenotedbythelocal
systemreceivingaTCPSYN.
Status:Optional
Optional
Attribute
Status:1)TheTrackTcpStateattributeSHOULDbesetto
TRUEifthiseventoccurs.
Event15:Tcp_CR_Invalid
Definition:Eventindicatingthelocalsystemreceptionofa
TCPconnectionrequestwitheitheraninvalid
sourceaddressorportnumber,oraninvalid
destinationaddressorportnumber.
BGPdestinationportnumberSHOULDbe179,as
definedbyIANA.
ATCPconnectionrequestoccurswhenthelocal
systemreceivesaTCPSYN.
Status:Optional
Optional
Attribute
Status:1)TheTrackTcpStateattributeshouldbesetto
TRUEifthiseventoccurs.
Event16:Tcp_CR_Acked
Definition:Eventindicatingthelocalsystem'srequestto
establishaTCPconnectiontotheremotepeer.
Thelocalsystem'sTCPconnectionsentaTCPSYN,
receivedaTCPSYN/ACKmessage,andsentaTCPACK.
Status:Mandatory
Event17:TcpConnectionConfirmed
Definition:Eventindicatingthatthelocalsystemhasreceived
41/90
3/2/2015
aconfirmationthattheTCPconnectionhasbeen
establishedbytheremotesite.
Theremotepeer'sTCPenginesentaTCPSYN.The
localpeer'sTCPenginesentaSYN,ACKmessageand
nowhasreceivedafinalACK.
Status:Mandatory
Event18:TcpConnectionFails
Definition:Eventindicatingthatthelocalsystemhasreceived
aTCPconnectionfailurenotice.
TheremoteBGPpeer'sTCPmachinecouldhavesenta
FIN.ThelocalpeerwouldrespondwithaFINACK.
Anotherpossibilityisthatthelocalpeer
indicatedatimeoutintheTCPconnectionand
downedtheconnection.
Status:Mandatory
8.1.5.BGPMessageBasedEvents
Event19:BGPOpen
Definition:AneventisgeneratedwhenavalidOPENmessagehas
beenreceived.
Status:Mandatory
Optional
Attribute
Status:1)TheDelayOpenoptionalattributeSHOULDbeset
toFALSE.
2)TheDelayOpenTimerSHOULDnotberunning.
Event20:BGPOpenwithDelayOpenTimerrunning
Definition:AneventisgeneratedwhenavalidOPENmessagehas
beenreceivedforapeerthathasasuccessfully
establishedtransportconnectionandiscurrently
delayingthesendingofaBGPopenmessage.
Status:Optional
Optional
Attribute
Status:1)TheDelayOpenattributeSHOULDbesettoTRUE.
2)TheDelayOpenTimerSHOULDberunning.
Event21:BGPHeaderErr
Definition:AneventisgeneratedwhenareceivedBGPmessage
headerisnotvalid.
Status:Mandatory
42/90
3/2/2015
Event22:BGPOpenMsgErr
Definition:AneventisgeneratedwhenanOPENmessagehasbeen
receivedwitherrors.
Status:Mandatory
Event23:OpenCollisionDump
Definition:Aneventgeneratedadministrativelywhena
connectioncollisionhasbeendetectedwhile
processinganincomingOPENmessageandthis
connectionhasbeenselectedtobedisconnected.
SeeSection6.8formoreinformationoncollision
detection.
Event23isanadministrativeactiongeneratedby
implementationlogicthatdetermineswhetherthis
connectionneedstobedroppedpertherulesin
Section6.8.ThiseventmayoccuriftheFSMis
implementedastwolinkedstatemachines.
Status:Optional
Optional
Attribute
Status:Ifthestatemachineistoprocessthiseventin
theEstablishedstate,
1)CollisionDetectEstablishedStateoptional
attributeSHOULDbesettoTRUE.
Pleasenote:TheOpenCollisionDumpeventcanoccur
inIdle,Connect,Active,OpenSent,andOpenConfirm
withoutanyoptionalattributesbeingset.
Event24:NotifMsgVerErr
Definition:AneventisgeneratedwhenaNOTIFICATIONmessage
with"versionerror"isreceived.
Status:Mandatory
Event25:NotifMsg
Definition:AneventisgeneratedwhenaNOTIFICATIONmessage
isreceivedandtheerrorcodeisanythingbut
"versionerror".
Status:Mandatory
Event26:KeepAliveMsg
Definition:AneventisgeneratedwhenaKEEPALIVEmessageis
received.
Status:Mandatory
43/90
3/2/2015
Event27:UpdateMsg
Definition:AneventisgeneratedwhenavalidUPDATEmessage
isreceived.
Status:Mandatory
Event28:UpdateMsgErr
Definition:AneventisgeneratedwhenaninvalidUPDATE
messageisreceived.
Status:Mandatory
8.2.DescriptionofFSM
8.2.1.FSMDefinition
BGPMUSTmaintainaseparateFSMforeachconfiguredpeer.EachBGP
peerpairedinapotentialconnectionwillattempttoconnecttothe
other,unlessconfiguredtoremainintheidlestate,orconfigured
toremainpassive.Forthepurposeofthisdiscussion,theactiveor
connectingsideoftheTCPconnection(thesideofaTCPconnection
sendingthefirstTCPSYNpacket)iscalledoutgoing.Thepassiveor
listeningside(thesenderofthefirstSYN/ACK)iscalledan
incomingconnection.(SeeSection8.2.1.1forinformationonthe
termsactiveandpassiveusedbelow.)
ABGPimplementationMUSTconnecttoandlistenonTCPport179for
incomingconnectionsinadditiontotryingtoconnecttopeers.For
eachincomingconnection,astatemachineMUSTbeinstantiated.
Thereexistsaperiodinwhichtheidentityofthepeerontheother
endofanincomingconnectionisknown,buttheBGPidentifierisnot
known.Duringthistime,bothanincomingandoutgoingconnection
mayexistforthesameconfiguredpeering.Thisisreferredtoasa
connectioncollision(seeSection6.8).
ABGPimplementationwillhave,atmost,oneFSMforeachconfigured
peering,plusoneFSMforeachincomingTCPconnectionforwhichthe
peerhasnotyetbeenidentified.EachFSMcorrespondstoexactly
oneTCPconnection.
Theremaybemorethanoneconnectionbetweenapairofpeersifthe
connectionsareconfiguredtouseadifferentpairofIPaddresses.
Thisisreferredtoasmultiple"configuredpeerings"tothesame
peer.
44/90
3/2/2015
8.2.1.1.Terms"active"and"passive"
ThetermsactiveandpassivehavebeenintheInternetoperator's
vocabularyforalmostadecadeandhaveprovenuseful.Thewords
activeandpassivehaveslightlydifferentmeaningswhenappliedtoa
TCPconnectionorapeer.Thereisonlyoneactivesideandone
passivesidetoanyoneTCPconnection,perthedefinitionaboveand
thestatemachinebelow.WhenaBGPspeakerisconfiguredasactive,
itmayenduponeithertheactiveorpassivesideoftheconnection
thateventuallygetsestablished.OncetheTCPconnectionis
completed,itdoesn'tmatterwhichendwasactiveandwhichwas
passive.TheonlydifferenceisinwhichsideoftheTCPconnection
hasportnumber179.
8.2.1.2.FSMandCollisionDetection
ThereisoneFSMperBGPconnection.Whentheconnectioncollision
occurspriortodeterminingwhatpeeraconnectionisassociated
with,theremaybetwoconnectionsforonepeer.Afterthe
connectioncollisionisresolved(seeSection6.8),theFSMforthe
connectionthatisclosedSHOULDbedisposed.
8.2.1.3.FSMandOptionalSessionAttributes
OptionalSessionAttributesspecifyeitherattributesthatactas
flags(TRUEorFALSE)oroptionaltimers.Foroptionalattributes
thatactasflags,iftheoptionalsessionattributecanbesetto
TRUEonthesystem,thecorrespondingBGPFSMactionsmustbe
supported.Forexample,ifthefollowingoptionscanbesetinaBGP
implementation:AutoStartandPassiveTcpEstablishment,thenEvents3,
4and5mustbesupported.IfanOptionalSessionattributecannot
besettoTRUE,theeventssupportingthatsetofoptionsdonothave
tobesupported.
Eachoftheoptionaltimers(DelayOpenTimerandIdleHoldTimer)hasa
groupofattributesthatare:
flagindicatingsupport,
TimesetinTimer
Timer.
Thetwooptionaltimersshowthisformat:
DelayOpenTimer:DelayOpen,DelayOpenTime,DelayOpenTimer
IdleHoldTimer:DampPeerOscillations,IdleHoldTime,
IdleHoldTimer
Iftheflagindicatingsupportforanoptionaltimer(DelayOpenor
DampPeerOscillations)cannotbesettoTRUE,thetimersandevents
supportingthatoptiondonothavetobesupported.
8.2.1.4.FSMEventNumbers
45/90
3/2/2015
TheEventnumbers(128)utilizedinthisstatemachinedescription
aidinspecifyingthebehavioroftheBGPstatemachine.
ImplementationsMAYusethesenumberstoprovidenetworkmanagement
information.TheexactformofanFSMortheFSMeventsarespecific
toeachimplementation.
8.2.1.5.FSMActionsthatareImplementationDependent
Atcertainpoints,theBGPFSMspecifiesthatBGPinitializationwill
occurorthatBGPresourceswillbedeleted.Theinitializationof
theBGPFSMandtheassociatedresourcesdependonthepolicyportion
oftheBGPimplementation.Thedetailsoftheseactionsareoutside
thescopeoftheFSMdocument.
8.2.2.FiniteStateMachine
Idlestate:
Initially,theBGPpeerFSMisintheIdlestate.Hereafter,the
BGPpeerFSMwillbeshortenedtoBGPFSM.
Inthisstate,BGPFSMrefusesallincomingBGPconnectionsfor
thispeer.Noresourcesareallocatedtothepeer.Inresponse
toaManualStartevent(Event1)oranAutomaticStartevent(Event
3),thelocalsystem:
initializesallBGPresourcesforthepeerconnection,
setsConnectRetryCountertozero,
startstheConnectRetryTimerwiththeinitialvalue,
initiatesaTCPconnectiontotheotherBGPpeer,
listensforaconnectionthatmaybeinitiatedbytheremote
BGPpeer,and
changesitsstatetoConnect.
TheManualStopevent(Event2)andAutomaticStop(Event8)event
areignoredintheIdlestate.
InresponsetoaManualStart_with_PassiveTcpEstablishmentevent
(Event4)orAutomaticStart_with_PassiveTcpEstablishmentevent
(Event5),thelocalsystem:
initializesallBGPresources,
setstheConnectRetryCountertozero,
startstheConnectRetryTimerwiththeinitialvalue,
listensforaconnectionthatmaybeinitiatedbytheremote
peer,and
changesitsstatetoActive.
46/90
3/2/2015
TheexactvalueoftheConnectRetryTimerisalocalmatter,butit
SHOULDbesufficientlylargetoallowTCPinitialization.
IftheDampPeerOscillationsattributeissettoTRUE,the
followingthreeadditionaleventsmayoccurwithintheIdlestate:
AutomaticStart_with_DampPeerOscillations(Event6),
AutomaticStart_with_DampPeerOscillations_and_
PassiveTcpEstablishment(Event7),
IdleHoldTimer_Expires(Event13).
Uponreceivingthese3events,thelocalsystemwillusethese
eventstopreventpeeroscillations.Themethodofpreventing
persistentpeeroscillationisoutsidethescopeofthisdocument.
Anyotherevent(Events912,1528)receivedintheIdlestate
doesnotcausechangeinthestateofthelocalsystem.
ConnectState:
Inthisstate,BGPFSMiswaitingfortheTCPconnectiontobe
completed.
Thestartevents(Events1,37)areignoredintheConnectstate.
InresponsetoaManualStopevent(Event2),thelocalsystem:
dropstheTCPconnection,
releasesallBGPresources,
stopstheConnectRetryTimerandsetsConnectRetryTimerto
zero,and
changesitsstatetoIdle.
InresponsetotheConnectRetryTimer_Expiresevent(Event9),the
localsystem:
restartstheConnectRetryTimer,
stopstheDelayOpenTimerandresetsthetimertozero,
continuestolistenforaconnectionthatmaybeinitiatedby
theremoteBGPpeer,and
staysintheConnectstate.
IftheDelayOpenTimer_Expiresevent(Event12)occursinthe
47/90
3/2/2015
Connectstate,thelocalsystem:
sendsanOPENmessagetoitspeer,
setstheHoldTimertoalargevalue,and
changesitsstatetoOpenSent.
IftheBGPFSMreceivesaTcpConnection_Validevent(Event14),
theTCPconnectionisprocessed,andtheconnectionremainsinthe
Connectstate.
IftheBGPFSMreceivesaTcp_CR_Invalidevent(Event15),the
localsystemrejectstheTCPconnection,andtheconnection
remainsintheConnectstate.
IftheTCPconnectionsucceeds(Event16orEvent17),thelocal
systemcheckstheDelayOpenattributepriortoprocessing.Ifthe
DelayOpenattributeissettoTRUE,thelocalsystem:
stopstheConnectRetryTimer(ifrunning)andsetsthe
ConnectRetryTimertozero,
setstheDelayOpenTimertotheinitialvalue,and
staysintheConnectstate.
IftheDelayOpenattributeissettoFALSE,thelocalsystem:
completesBGPinitialization
sendsanOPENmessagetoitspeer,
setstheHoldTimertoalargevalue,and
AHoldTimervalueof4minutesissuggested.
IftheTCPconnectionfails(Event18),thelocalsystemchecks
theDelayOpenTimer.IftheDelayOpenTimerisrunning,thelocal
system:
restartstheConnectRetryTimerwiththeinitialvalue,
stopstheDelayOpenTimerandresetsitsvaluetozero,
IftheDelayOpenTimerisnotrunning,thelocalsystem:
stopstheConnectRetryTimertozero,
48/90
3/2/2015
releasesallBGPresources,and
IfanOPENmessageisreceivedwhiletheDelayOpenTimerisrunning
completestheBGPinitialization,
stopsandclearstheDelayOpenTimer(setsthevaluetozero),
sendsanOPENmessage,
sendsaKEEPALIVEmessage,
iftheHoldTimerinitialvalueisnonzero,
startstheKeepaliveTimerwiththeinitialvalueand
resetstheHoldTimertothenegotiatedvalue,
else,iftheHoldTimerinitialvalueiszero,
resetstheKeepaliveTimerand
resetstheHoldTimervaluetozero,
andchangesitsstatetoOpenConfirm.
Ifthevalueoftheautonomoussystemfieldisthesameasthe
localAutonomousSystemnumber,settheconnectionstatustoan
internalconnection;otherwiseitwillbe"external".
IfBGPmessageheaderchecking(Event21)orOPENmessagechecking
detectsanerror(Event22)(seeSection6.2),thelocalsystem:
(optionally)IftheSendNOTIFICATIONwithoutOPENattributeis
settoTRUE,thenthelocalsystemfirstsendsaNOTIFICATION
messagewiththeappropriateerrorcode,andthen
incrementstheConnectRetryCounterby1,
(optionally)performspeeroscillationdampingifthe
DampPeerOscillationsattributeissettoTRUE,and
49/90
3/2/2015
IfaNOTIFICATIONmessageisreceivedwithaversionerror(Event
24),thelocalsystemcheckstheDelayOpenTimer.Ifthe
DelayOpenTimerisrunning,thelocalsystem:
stopsandresetstheDelayOpenTimer(setstozero),
dropstheTCPconnection,and
stopstheConnectRetryTimerandsetstheConnectRetryTimerto
zero,
performspeeroscillationdampingiftheDampPeerOscillations
attributeissettoTrue,and
Inresponsetoanyotherevents(Events8,1011,13,19,23,
2528),thelocalsystem:
iftheConnectRetryTimerisrunning,stopsandresetsthe
ConnectRetryTimer(setstozero),
iftheDelayOpenTimerisrunning,stopsandresetsthe
DelayOpenTimer(setstozero),
performspeeroscillationdampingiftheDampPeerOscillations
attributeissettoTrue,and
50/90
3/2/2015
ActiveState:
Inthisstate,BGPFSMistryingtoacquireapeerbylistening
for,andaccepting,aTCPconnection.
Thestartevents(Events1,37)areignoredintheActivestate.
InresponsetoaManualStopevent(Event2),thelocalsystem:
IftheDelayOpenTimerisrunningandthe
SendNOTIFICATIONwithoutOPENsessionattributeisset,the
localsystemsendsaNOTIFICATIONwithaCease,
releasesallBGPresourcesincludingstoppingthe
DelayOpenTimer
stopstheConnectRetryTimerandsetstheConnectRetryTimerto
zero,and
InresponsetoaConnectRetryTimer_Expiresevent(Event9),the
localsystem:
restartstheConnectRetryTimer(withinitialvalue),
continuestolistenforaTCPconnectionthatmaybeinitiated
byaremoteBGPpeer,and
changesitsstatetoConnect.
IfthelocalsystemreceivesaDelayOpenTimer_Expiresevent(Event
12),thelocalsystem:
setstheConnectRetryTimertozero,
stopsandclearstheDelayOpenTimer(settozero),
sendstheOPENmessagetoitsremotepeer,
setsitsholdtimertoalargevalue,and
51/90
3/2/2015
AHoldTimervalueof4minutesisalsosuggestedforthisstate
transition.
IfthelocalsystemreceivesaTcpConnection_Validevent(Event
14),thelocalsystemprocessestheTCPconnectionflagsandstays
intheActivestate.
IfthelocalsystemreceivesaTcp_CR_Invalidevent(Event15),
thelocalsystemrejectstheTCPconnectionandstaysinthe
ActiveState.
InresponsetothesuccessofaTCPconnection(Event16orEvent
17),thelocalsystemcheckstheDelayOpenoptionalattribute
priortoprocessing.
IftheDelayOpenattributeissettoTRUE,thelocalsystem:
stopstheConnectRetryTimerandsetstheConnectRetryTimer
tozero,
setstheDelayOpenTimertotheinitialvalue
(DelayOpenTime),and
staysintheActivestate.
IftheDelayOpenattributeissettoFALSE,thelocalsystem:
sendstheOPENmessagetoitspeer,
setsitsHoldTimertoalargevalue,and
AHoldTimervalueof4minutesissuggestedasa"largevalue"for
theHoldTimer.
IfthelocalsystemreceivesaTcpConnectionFailsevent(Event
18),thelocalsystem:
restartstheConnectRetryTimer(withtheinitialvalue),
stopsandclearstheDelayOpenTimer(setsthevaluetozero),
releasesallBGPresource,
optionallyperformspeeroscillationdampingifthe
IfanOPENmessageisreceivedandtheDelayOpenTimerisrunning
52/90
3/2/2015
stopsandclearstheDelayOpenTimer(setstozero),
sendsanOPENmessage,
iftheHoldTimervalueisnonzero,
startstheKeepaliveTimertoinitialvalue,
resetstheHoldTimertothenegotiatedvalue,
elseiftheHoldTimeriszero
resetstheKeepaliveTimer(settozero),
resetstheHoldTimertozero,and
changesitsstatetoOpenConfirm.
Ifthevalueoftheautonomoussystemfieldisthesameasthe
localAutonomousSystemnumber,settheconnectionstatustoan
internalconnection;otherwiseitwillbeexternal.
IfBGPmessageheaderchecking(Event21)orOPENmessagechecking
detectsanerror(Event22)(seeSection6.2),thelocalsystem:
(optionally)sendsaNOTIFICATIONmessagewiththeappropriate
errorcodeiftheSendNOTIFICATIONwithoutOPENattributeisset
toTRUE,
24),thelocalsystemcheckstheDelayOpenTimer.Ifthe
DelayOpenTimerisrunning,thelocalsystem:
53/90
3/2/2015
stopsandresetstheDelayOpenTimer(setstozero),
Inresponsetoanyotherevent(Events8,1011,13,19,23,
2528),thelocalsystem:
incrementstheConnectRetryCounterbyone,
OpenSent:
Inthisstate,BGPFSMwaitsforanOPENmessagefromitspeer.
Thestartevents(Events1,37)areignoredintheOpenSent
state.
IfaManualStopevent(Event2)isissuedintheOpenSentstate,
thelocalsystem:
sendstheNOTIFICATIONwithaCease,
54/90
3/2/2015
setstheConnectRetryCountertozero,and
IfanAutomaticStopevent(Event8)isissuedintheOpenSent
state,thelocalsystem:
sendstheNOTIFICATIONwithaCease,
releasesalltheBGPresources,
IftheHoldTimer_Expires(Event10),thelocalsystem:
sendsaNOTIFICATIONmessagewiththeerrorcodeHoldTimer
Expired,
incrementstheConnectRetryCounter,
IfaTcpConnection_Valid(Event14),Tcp_CR_Acked(Event16),ora
TcpConnectionConfirmedevent(Event17)isreceived,asecondTCP
connectionmaybeinprogress.ThissecondTCPconnectionis
trackedperConnectionCollisionprocessing(Section6.8)untilan
OPENmessageisreceived.
ATCPConnectionRequestforanInvalidport(Tcp_CR_Invalid
(Event15))isignored.
IfaTcpConnectionFailsevent(Event18)isreceived,thelocal
system:
closestheBGPconnection,
restartstheConnectRetryTimer,
55/90
3/2/2015
WhenanOPENmessageisreceived,allfieldsarecheckedfor
correctness.IftherearenoerrorsintheOPENmessage(Event
19),thelocalsystem:
resetstheDelayOpenTimertozero,
setstheBGPConnectRetryTimertozero,
sendsaKEEPALIVEmessage,and
setsaKeepaliveTimer(viathetextbelow)
setstheHoldTimeraccordingtothenegotiatedvalue(see
Section4.2),
changesitsstatetoOpenConfirm.
Ifthenegotiatedholdtimevalueiszero,thentheHoldTimerand
KeepaliveTimerarenotstarted.IfthevalueoftheAutonomous
SystemfieldisthesameasthelocalAutonomousSystemnumber,
thentheconnectionisan"internal"connection;otherwise,itis
an"external"connection.(ThiswillimpactUPDATEprocessingas
describedbelow.)
IftheBGPmessageheaderchecking(Event21)orOPENmessage
checkingdetectsanerror(Event22)(seeSection6.2),thelocal
system:
sendsaNOTIFICATIONmessagewiththeappropriateerrorcode,
DampPeerOscillationsattributeisTRUE,and
Collisiondetectionmechanisms(Section6.8)needtobeapplied
whenavalidBGPOPENmessageisreceived(Event19orEvent20).
PleaserefertoSection6.8forthedetailsofthecomparison.A
56/90
3/2/2015
CollisionDetectDumpeventoccurswhentheBGPimplementation
determines,bymeansoutsidethescopeofthisdocument,thata
connectioncollisionhasoccurred.
IfaconnectionintheOpenSentstateisdeterminedtobethe
connectionthatmustbeclosed,anOpenCollisionDump(Event23)is
signaledtothestatemachine.Ifsuchaneventisreceivedin
theOpenSentstate,thelocalsystem:
sendsaNOTIFICATIONwithaCease,
24),thelocalsystem:
Inresponsetoanyotherevent(Events9,1113,20,2528),the
localsystem:
sendstheNOTIFICATIONwiththeErrorCodeFiniteState
MachineError,
57/90
3/2/2015
OpenConfirmState:
Inthisstate,BGPwaitsforaKEEPALIVEorNOTIFICATIONmessage.
Anystartevent(Events1,37)isignoredintheOpenConfirm
state.
InresponsetoaManualStopevent(Event2)initiatedbythe
operator,thelocalsystem:
sendstheNOTIFICATIONmessagewithaCease,
setstheConnectRetryCountertozero,
setstheConnectRetryTimertozero,and
InresponsetotheAutomaticStopeventinitiatedbythesystem
IftheHoldTimer_Expiresevent(Event10)occursbeforea
KEEPALIVEmessageisreceived,thelocalsystem:
sendstheNOTIFICATIONmessagewiththeErrorCodeHoldTimer
Expired,
58/90
3/2/2015
IfthelocalsystemreceivesaKeepaliveTimer_Expiresevent(Event
11),thelocalsystem:
restartstheKeepaliveTimer,and
remainsintheOpenConfirmedstate.
IntheeventofaTcpConnection_Validevent(Event14),orthe
successofaTCPconnection(Event16orEvent17)whilein
OpenConfirm,thelocalsystemneedstotrackthesecond
connection.
IfaTCPconnectionisattemptedwithaninvalidport(Event15),
thelocalsystemwillignorethesecondconnectionattempt.
IfthelocalsystemreceivesaTcpConnectionFailsevent(Event18)
fromtheunderlyingTCPoraNOTIFICATIONmessage(Event25),the
localsystem:
IfthelocalsystemreceivesaNOTIFICATIONmessagewithaversion
error(NotifMsgVerErr(Event24)),thelocalsystem:
IfthelocalsystemreceivesavalidOPENmessage(BGPOpen(Event
19)),thecollisiondetectfunctionisprocessedperSection6.8.
Ifthisconnectionistobedroppedduetoconnectioncollision,
thelocalsystem:
59/90
3/2/2015
dropstheTCPconnection(sendTCPFIN),
IfanOPENmessageisreceived,allfieldsarecheckedfor
correctness.IftheBGPmessageheaderchecking(BGPHeaderErr
(Event21))orOPENmessagecheckingdetectsanerror(seeSection
6.2)(BGPOpenMsgErr(Event22)),thelocalsystem:
sendsaNOTIFICATIONmessagewiththeappropriateerrorcode,
If,duringtheprocessingofanotherOPENmessage,theBGP
implementationdetermines,byameansoutsidethescopeofthis
document,thataconnectioncollisionhasoccurredandthis
connectionistobeclosed,thelocalsystemwillissuean
OpenCollisionDumpevent(Event23).Whenthelocalsystem
receivesanOpenCollisionDumpevent(Event23),thelocalsystem:
releasesallBGPresources
IfthelocalsystemreceivesaKEEPALIVEmessage(KeepAliveMsg
(Event26)),thelocalsystem:
60/90
3/2/2015
restartstheHoldTimerand
changesitsstatetoEstablished.
Inresponsetoanyotherevent(Events9,1213,20,2728),the
localsystem:
sendsaNOTIFICATIONwithacodeofFiniteStateMachine
Error,
EstablishedState:
IntheEstablishedstate,theBGPFSMcanexchangeUPDATE,
NOTIFICATION,andKEEPALIVEmessageswithitspeer.
AnyStartevent(Events1,37)isignoredintheEstablished
state.
InresponsetoaManualStopevent(initiatedbyanoperator)
deletesallroutesassociatedwiththisconnection,
releasesBGPresources,
setstheConnectRetryCountertozero,and
InresponsetoanAutomaticStopevent(Event8),thelocalsystem:
setstheConnectRetryTimertozero
61/90
3/2/2015
OnereasonforanAutomaticStopeventis:ABGPreceivesanUPDATE
messageswithanumberofprefixesforagivenpeersuchthatthe
totalprefixesreceivedexceedsthemaximumnumberofprefixes
configured.Thelocalsystemautomaticallydisconnectsthepeer.
IftheHoldTimer_Expireseventoccurs(Event10),thelocal
system:
sendsaNOTIFICATIONmessagewiththeErrorCodeHoldTimer
Expired,
IftheKeepaliveTimer_Expireseventoccurs(Event11),thelocal
system:
sendsaKEEPALIVEmessage,and
restartsitsKeepaliveTimer,unlessthenegotiatedHoldTime
valueiszero.
EachtimethelocalsystemsendsaKEEPALIVEorUPDATEmessage,it
restartsitsKeepaliveTimer,unlessthenegotiatedHoldTimevalue
iszero.
ATcpConnection_Valid(Event14),receivedforavalidport,will
causethesecondconnectiontobetracked.
AninvalidTCPconnection(Tcp_CR_Invalidevent(Event15))will
beignored.
InresponsetoanindicationthattheTCPconnectionis
successfullyestablished(Event16orEvent17),thesecond
connectionSHALLbetrackeduntilitsendsanOPENmessage.
62/90
3/2/2015
IfavalidOPENmessage(BGPOpen(Event19))isreceived,andif
theCollisionDetectEstablishedStateoptionalattributeisTRUE,
theOPENmessagewillbecheckedtoseeifitcollides(Section
6.8)withanyotherconnection.IftheBGPimplementation
determinesthatthisconnectionneedstobeterminated,itwill
processanOpenCollisionDumpevent(Event23).Ifthisconnection
needstobeterminated,thelocalsystem:
DampPeerOscillationsissettoTRUE,and
IfthelocalsystemreceivesaNOTIFICATIONmessage(Event24or
Event25)oraTcpConnectionFails(Event18)fromtheunderlying
TCP,thelocalsystem:
releasesalltheBGPresources,
63/90
3/2/2015
IfthelocalsystemreceivesaKEEPALIVEmessage(Event26),the
localsystem:
restartsitsHoldTimer,ifthenegotiatedHoldTimevalueis
nonzero,and
remainsintheEstablishedstate.
IfthelocalsystemreceivesanUPDATEmessage(Event27),the
localsystem:
processesthemessage,
restartsitsHoldTimer,ifthenegotiatedHoldTimevalueis
nonzero,and
remainsintheEstablishedstate.
IfthelocalsystemreceivesanUPDATEmessage,andtheUPDATE
messageerrorhandlingprocedure(seeSection6.3)detectsan
error(Event28),thelocalsystem:
sendsaNOTIFICATIONmessagewithanUpdateerror,
Inresponsetoanyotherevent(Events9,1213,2022),thelocal
system:
sendsaNOTIFICATIONmessagewiththeErrorCodeFiniteState
MachineError,
64/90
3/2/2015
9.UPDATEMessageHandling
AnUPDATEmessagemaybereceivedonlyintheEstablishedstate.
ReceivinganUPDATEmessageinanyotherstateisanerror.Whenan
UPDATEmessageisreceived,eachfieldischeckedforvalidity,as
specifiedinSection6.3.
Ifanoptionalnontransitiveattributeisunrecognized,itis
quietlyignored.Ifanoptionaltransitiveattributeis
unrecognized,thePartialbit(thethirdhighorderbit)inthe
attributeflagsoctetissetto1,andtheattributeisretainedfor
propagationtootherBGPspeakers.
Ifanoptionalattributeisrecognizedandhasavalidvalue,then,
dependingonthetypeoftheoptionalattribute,itisprocessed
locally,retained,andupdated,ifnecessary,forpossible
propagationtootherBGPspeakers.
IftheUPDATEmessagecontainsanonemptyWITHDRAWNROUTESfield,
thepreviouslyadvertisedroutes,whosedestinations(expressedasIP
prefixes)arecontainedinthisfield,SHALLberemovedfromthe
AdjRIBIn.ThisBGPspeakerSHALLrunitsDecisionProcessbecause
thepreviouslyadvertisedrouteisnolongeravailableforuse.
IftheUPDATEmessagecontainsafeasibleroute,theAdjRIBInwill
beupdatedwiththisrouteasfollows:iftheNLRIofthenewroute
isidenticaltotheonetheroutecurrentlyhasstoredintheAdj
RIBIn,thenthenewrouteSHALLreplacetheolderrouteintheAdj
RIBIn,thusimplicitlywithdrawingtheolderroutefromservice.
Otherwise,iftheAdjRIBInhasnoroutewithNLRIidenticaltothe
newroute,thenewrouteSHALLbeplacedintheAdjRIBIn.
OncetheBGPspeakerupdatestheAdjRIBIn,thespeakerSHALLrun
itsDecisionProcess.
9.1.DecisionProcess
TheDecisionProcessselectsroutesforsubsequentadvertisementby
applyingthepoliciesinthelocalPolicyInformationBase(PIB)to
theroutesstoredinitsAdjRIBsIn.TheoutputoftheDecision
Processisthesetofroutesthatwillbeadvertisedtopeers;the
selectedrouteswillbestoredinthelocalspeaker'sAdjRIBsOut,
accordingtopolicy.
TheBGPDecisionProcessdescribedhereisconceptual,anddoesnot
havetobeimplementedpreciselyasdescribed,aslongasthe
implementationssupportthedescribedfunctionalityandtheyexhibit
thesameexternallyvisiblebehavior.
Theselectionprocessisformalizedbydefiningafunctionthattakes
theattributeofagivenrouteasanargumentandreturnseither(a)
anonnegativeintegerdenotingthedegreeofpreferenceforthe
route,or(b)avaluedenotingthatthisrouteisineligibletobe
65/90
3/2/2015
installedinLocRIBandwillbeexcludedfromthenextphaseof
routeselection.
Thefunctionthatcalculatesthedegreeofpreferenceforagiven
routeSHALLNOTuseanyofthefollowingasitsinputs:theexistence
ofotherroutes,thenonexistenceofotherroutes,orthepath
attributesofotherroutes.Routeselectionthenconsistsofthe
individualapplicationofthedegreeofpreferencefunctiontoeach
feasibleroute,followedbythechoiceoftheonewiththehighest
degreeofpreference.
TheDecisionProcessoperatesonroutescontainedintheAdjRIBsIn,
andisresponsiblefor:
selectionofroutestobeusedlocallybythespeaker
selectionofroutestobeadvertisedtootherBGPpeers
routeaggregationandrouteinformationreduction
TheDecisionProcesstakesplaceinthreedistinctphases,each
triggeredbyadifferentevent:
a)Phase1isresponsibleforcalculatingthedegreeofpreference
foreachroutereceivedfromapeer.
b)Phase2isinvokedoncompletionofphase1.Itisresponsible
forchoosingthebestrouteoutofallthoseavailableforeach
distinctdestination,andforinstallingeachchosenrouteinto
theLocRIB.
c)Phase3isinvokedaftertheLocRIBhasbeenmodified.Itis
responsiblefordisseminatingroutesintheLocRIBtoeach
peer,accordingtothepoliciescontainedinthePIB.Route
aggregationandinformationreductioncanoptionallybe
performedwithinthisphase.
9.1.1.Phase1:CalculationofDegreeofPreference
ThePhase1decisionfunctionisinvokedwheneverthelocalBGP
speakerreceives,fromapeer,anUPDATEmessagethatadvertisesa
newroute,areplacementroute,orwithdrawnroutes.
ThePhase1decisionfunctionisaseparateprocess,fwhichcompletes
whenithasnofurtherworktodo.
ThePhase1decisionfunctionlocksanAdjRIBInpriortooperating
onanyroutecontainedwithinit,andunlocksitafteroperatingon
allneworunfeasibleroutescontainedwithinit.
Foreachnewlyreceivedorreplacementfeasibleroute,thelocalBGP
speakerdeterminesadegreeofpreferenceasfollows:
Iftherouteislearnedfromaninternalpeer,eitherthevalueof
theLOCAL_PREFattributeistakenasthedegreeofpreference,or
thelocalsystemcomputesthedegreeofpreferenceoftheroute
basedonpreconfiguredpolicyinformation.Notethatthelatter
mayresultinformationofpersistentroutingloops.
66/90
3/2/2015
Iftherouteislearnedfromanexternalpeer,thenthelocalBGP
speakercomputesthedegreeofpreferencebasedonpreconfigured
policyinformation.Ifthereturnvalueindicatestherouteis
ineligible,therouteMAYNOTserveasaninputtothenextphase
ofrouteselection;otherwise,thereturnvalueMUSTbeusedas
theLOCAL_PREFvalueinanyIBGPreadvertisement.
Theexactnatureofthispolicyinformation,andthecomputation
involved,isalocalmatter.
9.1.2.Phase2:RouteSelection
ThePhase2decisionfunctionisinvokedoncompletionofPhase1.
ThePhase2functionisaseparateprocess,whichcompleteswhenit
hasnofurtherworktodo.ThePhase2processconsidersallroutes
thatareeligibleintheAdjRIBsIn.
ThePhase2decisionfunctionisblockedfromrunningwhilethePhase
3decisionfunctionisinprocess.ThePhase2functionlocksall
AdjRIBsInpriortocommencingitsfunction,andunlocksthemon
completion.
IftheNEXT_HOPattributeofaBGProutedepictsanaddressthatis
notresolvable,orifitwouldbecomeunresolvableiftheroutewas
installedintheroutingtable,theBGProuteMUSTbeexcludedfrom
thePhase2decisionfunction.
IftheAS_PATHattributeofaBGProutecontainsanASloop,theBGP
routeshouldbeexcludedfromthePhase2decisionfunction.ASloop
detectionisdonebyscanningthefullASpath(asspecifiedinthe
AS_PATHattribute),andcheckingthattheautonomoussystemnumberof
thelocalsystemdoesnotappearintheASpath.OperationsofaBGP
speakerthatisconfiguredtoacceptrouteswithitsownautonomous
systemnumberintheASpathareoutsidethescopeofthisdocument.
ItiscriticalthatBGPspeakerswithinanASdonotmakeconflicting
decisionsregardingrouteselectionthatwouldcauseforwardingloops
tooccur.
Foreachsetofdestinationsforwhichafeasiblerouteexistsinthe
AdjRIBsIn,thelocalBGPspeakeridentifiestheroutethathas:
a)thehighestdegreeofpreferenceofanyroutetothesameset
ofdestinations,or
b)istheonlyroutetothatdestination,or
c)isselectedasaresultofthePhase2tiebreakingrules
specifiedinSection9.1.2.2.
ThelocalspeakerSHALLtheninstallthatrouteintheLocRIB,
replacinganyroutetothesamedestinationthatiscurrentlybeing
heldintheLocRIB.WhenthenewBGProuteisinstalledinthe
67/90
3/2/2015
RoutingTable,caremustbetakentoensurethatexistingroutesto
thesamedestinationthatarenowconsideredinvalidareremovedfrom
theRoutingTable.WhetherthenewBGProutereplacesanexisting
nonBGProuteintheRoutingTabledependsonthepolicyconfigured
ontheBGPspeaker.
ThelocalspeakerMUSTdeterminetheimmediatenexthopaddressfrom
theNEXT_HOPattributeoftheselectedroute(seeSection5.1.3).If
eithertheimmediatenexthoportheIGPcosttotheNEXT_HOP(where
theNEXT_HOPisresolvedthroughanIGProute)changes,Phase2Route
SelectionMUSTbeperformedagain.
NoticethateventhoughBGProutesdonothavetobeinstalledinthe
RoutingTablewiththeimmediatenexthop(s),implementationsMUST
takecarethat,beforeanypacketsareforwardedalongaBGProute,
itsassociatedNEXT_HOPaddressisresolvedtotheimmediate
(directlyconnected)nexthopaddress,andthatthisaddress(or
multipleaddresses)isfinallyusedforactualpacketforwarding.
UnresolvableroutesSHALLberemovedfromtheLocRIBandtherouting
table.However,correspondingunresolvableroutesSHOULDbekeptin
theAdjRIBsIn(incasetheybecomeresolvable).
9.1.2.1.RouteResolvabilityCondition
AsindicatedinSection9.1.2,BGPspeakersSHOULDexclude
unresolvableroutesfromthePhase2decision.Thisensuresthat
onlyvalidroutesareinstalledinLocRIBandtheRoutingTable.
Therouteresolvabilityconditionisdefinedasfollows:
1)ArouteRte1,referencingonlytheintermediatenetwork
address,isconsideredresolvableiftheRoutingTablecontains
atleastoneresolvablerouteRte2thatmatchesRte1's
intermediatenetworkaddressandisnotrecursivelyresolved
(directlyorindirectly)throughRte1.Ifmultiplematching
routesareavailable,onlythelongestmatchingrouteSHOULDbe
considered.
2)Routesreferencinginterfaces(withorwithoutintermediate
addresses)areconsideredresolvableifthestateofthe
referencedinterfaceisupandifIPprocessingisenabledon
thisinterface.
BGProutesdonotrefertointerfaces,butcanberesolvedthrough
theroutesintheRoutingTablethatcanbeofbothtypes(thosethat
specifyinterfacesorthosethatdonot).IGProutesandroutesto
directlyconnectednetworksareexpectedtospecifytheoutbound
interface.Staticroutescanspecifytheoutboundinterface,the
intermediateaddress,orboth.
NotethataBGProuteisconsideredunresolvableinasituationwhere
theBGPspeaker'sRoutingTablecontainsnoroutematchingtheBGP
route'sNEXT_HOP.Mutuallyrecursiveroutes(routesresolvingeach
otherorthemselves)alsofailtheresolvabilitycheck.
Itisalsoimportantthatimplementationsdonotconsiderfeasible
68/90
3/2/2015
routesthatwouldbecomeunresolvableiftheywereinstalledinthe
RoutingTable,eveniftheirNEXT_HOPsareresolvableusingthe
currentcontentsoftheRoutingTable(anexampleofsuchroutes
wouldbemutuallyrecursiveroutes).ThischeckensuresthataBGP
speakerdoesnotinstallroutesintheRoutingTablethatwillbe
removedandnotusedbythespeaker.Therefore,inadditiontolocal
RoutingTablestability,thischeckalsoimprovesbehaviorofthe
protocolinthenetwork.
WheneveraBGPspeakeridentifiesaroutethatfailsthe
resolvabilitycheckbecauseofmutualrecursion,anerrormessage
SHOULDbelogged.
9.1.2.2.BreakingTies(Phase2)
InitsAdjRIBsIn,aBGPspeakermayhaveseveralroutestothesame
destinationthathavethesamedegreeofpreference.Thelocal
speakercanselectonlyoneoftheseroutesforinclusioninthe
associatedLocRIB.Thelocalspeakerconsidersallrouteswiththe
samedegreesofpreference,boththosereceivedfrominternalpeers,
andthosereceivedfromexternalpeers.
Thefollowingtiebreakingprocedureassumesthat,foreachcandidate
route,alltheBGPspeakerswithinanautonomoussystemcanascertain
thecostofapath(interiordistance)totheaddressdepictedbythe
NEXT_HOPattributeoftheroute,andfollowthesamerouteselection
algorithm.
Thetiebreakingalgorithmbeginsbyconsideringallequally
preferableroutestothesamedestination,andthenselectsroutesto
beremovedfromconsideration.Thealgorithmterminatesassoonas
onlyonerouteremainsinconsideration.ThecriteriaMUSTbe
appliedintheorderspecified.
Severalofthecriteriaaredescribedusingpseudocode.Notethat
thepseudocodeshownwaschosenforclarity,notefficiency.Itis
notintendedtospecifyanyparticularimplementation.BGP
implementationsMAYuseanyalgorithmthatproducesthesameresults
asthosedescribedhere.
a)Removefromconsiderationallroutesthatarenottiedfor
havingthesmallestnumberofASnumberspresentintheir
AS_PATHattributes.Notethatwhencountingthisnumber,an
AS_SETcountsas1,nomatterhowmanyASesareintheset.
b)Removefromconsiderationallroutesthatarenottiedfor
havingthelowestOriginnumberintheirOriginattribute.
69/90
3/2/2015
c)Removefromconsiderationrouteswithlesspreferred
MULTI_EXIT_DISCattributes.MULTI_EXIT_DISCisonlycomparable
betweenrouteslearnedfromthesameneighboringAS(the
neighboringASisdeterminedfromtheAS_PATHattribute).
RoutesthatdonothavetheMULTI_EXIT_DISCattributeare
consideredtohavethelowestpossibleMULTI_EXIT_DISCvalue.
Thisisalsodescribedinthefollowingprocedure:
form=allroutesstillunderconsideration
forn=allroutesstillunderconsideration
if(neighborAS(m)==neighborAS(n))and(MED(n)<MED(m))
removeroutemfromconsideration
Inthepseudocodeabove,MED(n)isafunctionthatreturnsthe
valueofrouten'sMULTI_EXIT_DISCattribute.Ifroutenhas
noMULTI_EXIT_DISCattribute,thefunctionreturnsthelowest
possibleMULTI_EXIT_DISCvalue(i.e.,0).
Similarly,neighborAS(n)isafunctionthatreturnsthe
neighborASfromwhichtheroutewasreceived.Iftherouteis
learnedviaIBGP,andtheotherIBGPspeakerdidn'toriginate
theroute,itistheneighborASfromwhichtheotherIBGP
speakerlearnedtheroute.IftherouteislearnedviaIBGP,
andtheotherIBGPspeakereither(a)originatedtheroute,or
(b)createdtheroutebyaggregationandtheAS_PATHattribute
oftheaggregaterouteiseitheremptyorbeginswithan
AS_SET,itisthelocalAS.
IfaMULTI_EXIT_DISCattributeisremovedbeforereadvertising
arouteintoIBGP,thencomparisonbasedonthereceivedEBGP
MULTI_EXIT_DISCattributeMAYstillbeperformed.Ifan
implementationchoosestoremoveMULTI_EXIT_DISC,thenthe
optionalcomparisononMULTI_EXIT_DISC,ifperformed,MUSTbe
performedonlyamongEBGPlearnedroutes.ThebestEBGP
learnedroutemaythenbecomparedwithIBGPlearnedroutes
aftertheremovaloftheMULTI_EXIT_DISCattribute.If
MULTI_EXIT_DISCisremovedfromasubsetofEBGPlearned
routes,andtheselected"best"EBGPlearnedroutewillnot
haveMULTI_EXIT_DISCremoved,thentheMULTI_EXIT_DISCmustbe
usedinthecomparisonwithIBGPlearnedroutes.ForIBGP
learnedroutes,theMULTI_EXIT_DISCMUSTbeusedinroute
comparisonsthatreachthisstepintheDecisionProcess.
IncludingtheMULTI_EXIT_DISCofanEBGPlearnedrouteinthe
comparisonwithanIBGPlearnedroute,thenremovingthe
MULTI_EXIT_DISCattribute,andadvertisingtheroutehasbeen
proventocauserouteloops.
d)IfatleastoneofthecandidaterouteswasreceivedviaEBGP,
removefromconsiderationallroutesthatwerereceivedvia
IBGP.
e)Removefromconsiderationanyrouteswithlesspreferred
interiorcost.Theinteriorcostofarouteisdeterminedby
calculatingthemetrictotheNEXT_HOPfortherouteusingthe
70/90
3/2/2015
RoutingTable.IftheNEXT_HOPhopforarouteisreachable,
butnocostcanbedetermined,thenthisstepshouldbeskipped
(equivalently,considerallroutestohaveequalcosts).
Thisisalsodescribedinthefollowingprocedure.
form=allroutesstillunderconsideration
forn=allroutesinstillunderconsideration
if(cost(n)islowerthancost(m))
removemfromconsideration
Inthepseudocodeabove,cost(n)isafunctionthatreturns
thecostofthepath(interiordistance)totheaddressgiven
intheNEXT_HOPattributeoftheroute.
f)Removefromconsiderationallroutesotherthantheroutethat
wasadvertisedbytheBGPspeakerwiththelowestBGP
Identifiervalue.
g)Prefertheroutereceivedfromthelowestpeeraddress.
9.1.3.Phase3:RouteDissemination
ThePhase3decisionfunctionisinvokedoncompletionofPhase2,or
whenanyofthefollowingeventsoccur:
a)whenroutesintheLocRIBtolocaldestinationshavechanged
b)whenlocallygeneratedrouteslearnedbymeansoutsideofBGP
havechanged
c)whenanewBGPspeakerconnectionhasbeenestablished
ThePhase3functionisaseparateprocessthatcompleteswhenithas
nofurtherworktodo.ThePhase3RoutingDecisionfunctionis
blockedfromrunningwhilethePhase2decisionfunctionisin
process.
AllroutesintheLocRIBareprocessedintoAdjRIBsOutaccording
toconfiguredpolicy.ThispolicyMAYexcludearouteintheLocRIB
frombeinginstalledinaparticularAdjRIBOut.ArouteSHALLNOT
beinstalledintheAdjRibOutunlessthedestination,andNEXT_HOP
describedbythisroute,maybeforwardedappropriatelybythe
RoutingTable.IfarouteinLocRIBisexcludedfromaparticular
AdjRIBOut,thepreviouslyadvertisedrouteinthatAdjRIBOutMUST
bewithdrawnfromservicebymeansofanUPDATEmessage(see9.2).
Routeaggregationandinformationreductiontechniques(seeSection
9.2.2.1)mayoptionallybeapplied.
AnylocalpolicythatresultsinroutesbeingaddedtoanAdjRIBOut
withoutalsobeingaddedtothelocalBGPspeaker'sforwardingtable
isoutsidethescopeofthisdocument.
WhentheupdatingoftheAdjRIBsOutandtheRoutingTableis
complete,thelocalBGPspeakerrunstheUpdateSendprocessof9.2.
71/90
3/2/2015
9.1.4.OverlappingRoutes
ABGPspeakermaytransmitrouteswithoverlappingNetworkLayer
ReachabilityInformation(NLRI)toanotherBGPspeaker.NLRIoverlap
occurswhenasetofdestinationsareidentifiedinnonmatching
multipleroutes.BecauseBGPencodesNLRIusingIPprefixes,overlap
willalwaysexhibitsubsetrelationships.Aroutedescribinga
smallersetofdestinations(alongerprefix)issaidtobemore
specificthanaroutedescribingalargersetofdestinations(a
shorterprefix);similarly,aroutedescribingalargersetof
destinationsissaidtobelessspecificthanaroutedescribinga
smallersetofdestinations.
Theprecedencerelationshipeffectivelydecomposeslessspecific
routesintotwoparts:
asetofdestinationsdescribedonlybythelessspecificroute,
and
asetofdestinationsdescribedbytheoverlapoftheless
specificandthemorespecificroutes
Thesetofdestinationsdescribedbytheoverlaprepresentsaportion
ofthelessspecificroutethatisfeasible,butisnotcurrentlyin
use.Ifamorespecificrouteislaterwithdrawn,thesetof
destinationsdescribedbytheoverlapwillstillbereachableusing
thelessspecificroute.
IfaBGPspeakerreceivesoverlappingroutes,theDecisionProcess
MUSTconsiderbothroutesbasedontheconfiguredacceptancepolicy.
Ifbothalessandamorespecificrouteareaccepted,thenthe
DecisionProcessMUSTinstall,inLocRIB,eitherboththelessand
themorespecificroutesoraggregatethetworoutesandinstall,in
LocRIB,theaggregatedroute,providedthatbothrouteshavethe
samevalueoftheNEXT_HOPattribute.
IfaBGPspeakerchoosestoaggregate,thenitSHOULDeitherinclude
allASesusedtoformtheaggregateinanAS_SET,oraddthe
ATOMIC_AGGREGATEattributetotheroute.Thisattributeisnow
primarilyinformational.WiththeeliminationofIProuting
protocolsthatdonotsupportclasslessrouting,andtheelimination
ofrouterandhostimplementationsthatdonotsupportclassless
routing,thereisnolongeraneedtodeaggregate.RoutesSHOULD
NOTbedeaggregated.Inparticular,aroutethatcarriesthe
ATOMIC_AGGREGATEattributeMUSTNOTbedeaggregated.Thatis,the
NLRIofthisroutecannotbemorespecific.Forwardingalongsucha
routedoesnotguaranteethatIPpacketswillactuallytraverseonly
ASeslistedintheAS_PATHattributeoftheroute.
9.2.UpdateSendProcess
TheUpdateSendprocessisresponsibleforadvertisingUPDATE
messagestoallpeers.Forexample,itdistributestherouteschosen
bytheDecisionProcesstootherBGPspeakers,whichmaybelocated
ineitherthesameautonomoussystemoraneighboringautonomous
system.
72/90
3/2/2015
WhenaBGPspeakerreceivesanUPDATEmessagefromaninternalpeer,
thereceivingBGPspeakerSHALLNOTredistributetherouting
informationcontainedinthatUPDATEmessagetootherinternalpeers
(unlessthespeakeractsasaBGPRouteReflector[RFC2796]).
AspartofPhase3oftherouteselectionprocess,theBGPspeaker
hasupdateditsAdjRIBsOut.Allnewlyinstalledroutesandall
newlyunfeasibleroutesforwhichthereisnoreplacementrouteSHALL
beadvertisedtoitspeersbymeansofanUPDATEmessage.
ABGPspeakerSHOULDNOTadvertiseagivenfeasibleBGProutefrom
itsAdjRIBOutifitwouldproduceanUPDATEmessagecontainingthe
sameBGProuteaswaspreviouslyadvertised.
AnyroutesintheLocRIBmarkedasunfeasibleSHALLberemoved.
Changestothereachabledestinationswithinitsownautonomous
systemSHALLalsobeadvertisedinanUPDATEmessage.
If,duetothelimitsonthemaximumsizeofanUPDATEmessage(see
Section4),asingleroutedoesn'tfitintothemessage,theBGP
speakerMUSTnotadvertisetheroutetoitspeersandMAYchooseto
loganerrorlocally.
9.2.1.ControllingRoutingTrafficOverhead
TheBGPprotocolconstrainstheamountofroutingtraffic(thatis,
UPDATEmessages),inordertolimitboththelinkbandwidthneededto
advertiseUPDATEmessagesandtheprocessingpowerneededbythe
DecisionProcesstodigesttheinformationcontainedintheUPDATE
messages.
9.2.1.1.FrequencyofRouteAdvertisement
TheparameterMinRouteAdvertisementIntervalTimerdeterminesthe
minimumamountoftimethatmustelapsebetweenanadvertisement
and/orwithdrawalofroutestoaparticulardestinationbyaBGP
speakertoapeer.Thisratelimitingprocedureappliesonaper
destinationbasis,althoughthevalueof
MinRouteAdvertisementIntervalTimerissetonaperBGPpeerbasis.
TwoUPDATEmessagessentbyaBGPspeakertoapeerthatadvertise
feasibleroutesand/orwithdrawalofunfeasibleroutestosomecommon
setofdestinationsMUSTbeseparatedbyatleast
MinRouteAdvertisementIntervalTimer.Thiscanonlybeachievedby
keepingaseparatetimerforeachcommonsetofdestinations.This
wouldbeunwarrantedoverhead.Anytechniquethatensuresthatthe
intervalbetweentwoUPDATEmessagessentfromaBGPspeakertoa
peerthatadvertisefeasibleroutesand/orwithdrawalofunfeasible
routestosomecommonsetofdestinationswillbeatleast
MinRouteAdvertisementIntervalTimer,andwillalsoensurethata
constantupperboundontheintervalisacceptable.
Sincefastconvergenceisneededwithinanautonomoussystem,either
(a)theMinRouteAdvertisementIntervalTimerusedforinternalpeers
SHOULDbeshorterthantheMinRouteAdvertisementIntervalTimerused
forexternalpeers,or(b)theproceduredescribeinthissection
SHOULDNOTapplytoroutessenttointernalpeers.
73/90
3/2/2015
Thisproceduredoesnotlimittherateofrouteselection,butonly
therateofrouteadvertisement.Ifnewroutesareselectedmultiple
timeswhileawaitingtheexpirationof
MinRouteAdvertisementIntervalTimer,thelastrouteselectedSHALLbe
advertisedattheendofMinRouteAdvertisementIntervalTimer.
9.2.1.2.FrequencyofRouteOrigination
TheparameterMinASOriginationIntervalTimerdeterminestheminimum
amountoftimethatmustelapsebetweensuccessiveadvertisementsof
UPDATEmessagesthatreportchangeswithintheadvertisingBGP
speaker'sownautonomoussystems.
9.2.2.EfficientOrganizationofRoutingInformation
Havingselectedtheroutinginformationitwilladvertise,aBGP
speakermayavailitselfofseveralmethodstoorganizethis
informationinanefficientmanner.
9.2.2.1.InformationReduction
Informationreductionmayimplyareductioningranularityofpolicy
controlafterinformationiscollapsed,thesamepolicieswill
applytoalldestinationsandpathsintheequivalenceclass.
TheDecisionProcessmayoptionallyreducetheamountofinformation
thatitwillplaceintheAdjRIBsOutbyanyofthefollowing
methods:
a)NetworkLayerReachabilityInformation(NLRI):
DestinationIPaddressescanberepresentedasIPaddress
prefixes.Incaseswherethereisacorrespondencebetweenthe
addressstructureandthesystemsundercontrolofan
autonomoussystemadministrator,itwillbepossibletoreduce
thesizeoftheNLRIcarriedintheUPDATEmessages.
b)AS_PATHs:
ASpathinformationcanberepresentedasorderedAS_SEQUENCEs
orunorderedAS_SETs.AS_SETsareusedintheroute
aggregationalgorithmdescribedinSection9.2.2.2.They
reducethesizeoftheAS_PATHinformationbylistingeachAS
numberonlyonce,regardlessofhowmanytimesitmayhave
appearedinmultipleAS_PATHsthatwereaggregated.
AnAS_SETimpliesthatthedestinationslistedintheNLRIcan
bereachedthroughpathsthattraverseatleastsomeofthe
constituentautonomoussystems.AS_SETsprovidesufficient
informationtoavoidroutinginformationlooping;however,
theirusemayprunepotentiallyfeasiblepathsbecausesuch
pathsarenolongerlistedindividuallyintheformof
AS_SEQUENCEs.Inpractice,thisisnotlikelytobeaproblem
becauseonceanIPpacketarrivesattheedgeofagroupof
autonomoussystems,theBGPspeakerislikelytohavemore
detailedpathinformationandcandistinguishindividualpaths
74/90
3/2/2015
fromdestinations.
9.2.2.2.AggregatingRoutingInformation
Aggregationistheprocessofcombiningthecharacteristicsof
severaldifferentroutesinsuchawaythatasingleroutecanbe
advertised.AggregationcanoccuraspartoftheDecisionProcessto
reducetheamountofroutinginformationthatwillbeplacedinthe
AdjRIBsOut.
AggregationreducestheamountofinformationthataBGPspeakermust
storeandexchangewithotherBGPspeakers.Routescanbeaggregated
byapplyingthefollowingprocedure,separately,topathattributes
ofthesametypeandtotheNetworkLayerReachabilityInformation.
RoutesthathavedifferentMULTI_EXIT_DISCattributesSHALLNOTbe
aggregated.
IftheaggregatedroutehasanAS_SETasthefirstelementinits
AS_PATHattribute,thentherouterthatoriginatestherouteSHOULD
NOTadvertisetheMULTI_EXIT_DISCattributewiththisroute.
Pathattributesthathavedifferenttypecodescannotbeaggregated
together.Pathattributesofthesametypecodemaybeaggregated,
accordingtothefollowingrules:
NEXT_HOP:
WhenaggregatingroutesthathavedifferentNEXT_HOP
attributes,theNEXT_HOPattributeoftheaggregatedroute
SHALLidentifyaninterfaceontheBGPspeakerthatperforms
theaggregation.
ORIGINattribute:
Ifatleastonerouteamongroutesthatareaggregatedhas
ORIGINwiththevalueINCOMPLETE,thentheaggregatedroute
MUSThavetheORIGINattributewiththevalueINCOMPLETE.
Otherwise,ifatleastonerouteamongroutesthatare
aggregatedhasORIGINwiththevalueEGP,thentheaggregated
routeMUSThavetheORIGINattributewiththevalueEGP.In
allothercases,,thevalueoftheORIGINattributeofthe
aggregatedrouteisIGP.
AS_PATHattribute:
IfroutestobeaggregatedhaveidenticalAS_PATHattributes,
thentheaggregatedroutehasthesameAS_PATHattributeas
eachindividualroute.
ForthepurposeofaggregatingAS_PATHattributes,wemodel
eachASwithintheAS_PATHattributeasatuple<type,value>,
where"type"identifiesatypeofthepathsegmenttheAS
75/90
3/2/2015
belongsto(e.g.,AS_SEQUENCE,AS_SET),and"value"identifies
theASnumber.Iftheroutestobeaggregatedhavedifferent
AS_PATHattributes,thentheaggregatedAS_PATHattributeSHALL
satisfyallofthefollowingconditions:
alltuplesoftypeAS_SEQUENCEintheaggregatedAS_PATH
SHALLappearinalloftheAS_PATHsintheinitialsetof
routestobeaggregated.
alltuplesoftypeAS_SETintheaggregatedAS_PATHSHALL
appearinatleastoneoftheAS_PATHsintheinitialset
(theymayappearaseitherAS_SETorAS_SEQUENCEtypes).
foranytupleXoftypeAS_SEQUENCEintheaggregated
AS_PATH,whichprecedestupleYintheaggregatedAS_PATH,
XprecedesYineachAS_PATHintheinitialset,which
containsY,regardlessofthetypeofY.
NotupleoftypeAS_SETwiththesamevalueSHALLappear
morethanonceintheaggregatedAS_PATH.
MultipletuplesoftypeAS_SEQUENCEwiththesamevaluemay
appearintheaggregatedAS_PATHonlywhenadjacentto
anothertupleofthesametypeandvalue.
Animplementationmaychooseanyalgorithmthatconformsto
theserules.Ataminimum,aconformantimplementationSHALL
beabletoperformthefollowingalgorithmthatmeetsallof
theaboveconditions:
determinethelongestleadingsequenceoftuples(as
definedabove)commontoalltheAS_PATHattributesofthe
routestobeaggregated.Makethissequencetheleading
sequenceoftheaggregatedAS_PATHattribute.
setthetypeoftherestofthetuplesfromtheAS_PATH
attributesoftheroutestobeaggregatedtoAS_SET,and
appendthemtotheaggregatedAS_PATHattribute.
iftheaggregatedAS_PATHhasmorethanonetuplewiththe
samevalue(regardlessoftuple'stype),eliminateallbut
onesuchtuplebydeletingtuplesofthetypeAS_SETfrom
theaggregatedAS_PATHattribute.
foreachpairofadjacenttuplesintheaggregatedAS_PATH,
ifbothtupleshavethesametype,mergethemtogether,as
longasdoingsowillnotcauseasegmentwithalength
greaterthan255tobegenerated.
AppendixF,SectionF.6presentsanotheralgorithmthat
satisfiestheconditionsandallowsformorecomplexpolicy
configurations.
ATOMIC_AGGREGATE:
76/90
3/2/2015
Ifatleastoneoftheroutestobeaggregatedhas
ATOMIC_AGGREGATEpathattribute,thentheaggregatedroute
SHALLhavethisattributeaswell.
AGGREGATOR:
AnyAGGREGATORattributesfromtheroutestobeaggregatedMUST
NOTbeincludedintheaggregatedroute.TheBGPspeaker
performingtherouteaggregationMAYattachanewAGGREGATOR
attribute(seeSection5.1.7).
9.3.RouteSelectionCriteria
Generally,additionalrulesforcomparingroutesamongseveral
alternativesareoutsidethescopeofthisdocument.Therearetwo
exceptions:
IfthelocalASappearsintheASpathofthenewroutebeing
considered,thenthatnewroutecannotbeviewedasbetterthan
anyotherroute(providedthatthespeakerisconfiguredto
acceptsuchroutes).Ifsucharoutewereeverused,arouting
loopcouldresult.
Inordertoachieveasuccessfuldistributedoperation,only
routeswithalikelihoodofstabilitycanbechosen.Thus,an
ASSHOULDavoidusingunstableroutes,anditSHOULDNOTmake
rapid,spontaneouschangestoitschoiceofroute.Quantifying
theterms"unstable"and"rapid"(fromtheprevioussentence)
willrequireexperience,buttheprincipleisclear.Routes
thatareunstablecanbe"penalized"(e.g.,byusingthe
proceduresdescribedin[RFC2439]).
9.4.OriginatingBGProutes
ABGPspeakermayoriginateBGProutesbyinjectingrouting
informationacquiredbysomeothermeans(e.g.,viaanIGP)intoBGP.
ABGPspeakerthatoriginatesBGProutesassignsthedegreeof
preference(e.g.,accordingtolocalconfiguration)totheseroutes
bypassingthemthroughtheDecisionProcess(seeSection9.1).
TheseroutesMAYalsobedistributedtootherBGPspeakerswithinthe
localASaspartoftheupdateprocess(seeSection9.2).The
decisionofwhethertodistributenonBGPacquiredrouteswithinan
ASviaBGPdependsontheenvironmentwithintheAS(e.g.,typeof
IGP)andSHOULDbecontrolledviaconfiguration.
10.BGPTimers
BGPemploysfivetimers:ConnectRetryTimer(seeSection8),HoldTimer
(seeSection4.2),KeepaliveTimer(seeSection8),
MinASOriginationIntervalTimer(seeSection9.2.1.2),and
MinRouteAdvertisementIntervalTimer(seeSection9.2.1.1).
TwooptionaltimersMAYbesupported:DelayOpenTimer,IdleHoldTimer
byBGP(seeSection8).Section8describestheiruse.Thefull
operationoftheseoptionaltimersisoutsidethescopeofthis
document.
ConnectRetryTimeisamandatoryFSMattributethatstorestheinitial
valuefortheConnectRetryTimer.Thesuggesteddefaultvalueforthe
77/90
3/2/2015
ConnectRetryTimeis120seconds.
HoldTimeisamandatoryFSMattributethatstorestheinitialvalue
fortheHoldTimer.ThesuggesteddefaultvaluefortheHoldTimeis
90seconds.
Duringsomeportionsofthestatemachine(seeSection8),the
HoldTimerissettoalargevalue.Thesuggesteddefaultforthis
largevalueis4minutes.
TheKeepaliveTimeisamandatoryFSMattributethatstoresthe
initialvaluefortheKeepaliveTimer.Thesuggesteddefaultvalue
fortheKeepaliveTimeis1/3oftheHoldTime.
ThesuggesteddefaultvaluefortheMinASOriginationIntervalTimeris
15seconds.
Thesuggesteddefaultvalueforthe
MinRouteAdvertisementIntervalTimeronEBGPconnectionsis30seconds.
Thesuggesteddefaultvalueforthe
MinRouteAdvertisementIntervalTimeronIBGPconnectionsis5seconds.
AnimplementationofBGPMUSTallowtheHoldTimertobeconfigurable
onaperpeerbasis,andMAYallowtheothertimerstobe
configurable.
TominimizethelikelihoodthatthedistributionofBGPmessagesbya
givenBGPspeakerwillcontainpeaks,jitterSHOULDbeappliedtothe
timersassociatedwithMinASOriginationIntervalTimer,KeepaliveTimer,
MinRouteAdvertisementIntervalTimer,andConnectRetryTimer.Agiven
BGPspeakerMAYapplythesamejittertoeachofthesequantities,
regardlessofthedestinationstowhichtheupdatesarebeingsent;
thatis,jitterneednotbeconfiguredonaperpeerbasis.
ThesuggesteddefaultamountofjitterSHALLbedeterminedby
multiplyingthebasevalueoftheappropriatetimerbyarandom
factor,whichisuniformlydistributedintherangefrom0.75to1.0.
AnewrandomvalueSHOULDbepickedeachtimethetimerisset.The
rangeofthejitter'srandomvalueMAYbeconfigurable.
78/90
3/2/2015
AppendixA.ComparisonwithRFC1771
Therearenumerouseditorialchangesincomparisonto[RFC1771](too
manytolisthere).
Thefollowinglistthetechnicalchanges:
ChangestoreflecttheusageoffeaturessuchasTCPMD5
[RFC2385],BGPRouteReflectors[RFC2796],BGPConfederations
[RFC3065],andBGPRouteRefresh[RFC2918].
ClarificationoftheuseoftheBGPIdentifierintheAGGREGATOR
attribute.
Proceduresforimposinganupperboundonthenumberofprefixes
thataBGPspeakerwouldacceptfromapeer.
TheabilityofaBGPspeakertoincludemorethanoneinstanceof
itsownASintheAS_PATHattributeforthepurposeofinterAS
trafficengineering.
ClarificationofthevarioustypesofNEXT_HOPs.
ClarificationoftheuseoftheATOMIC_AGGREGATEattribute.
Therelationshipbetweentheimmediatenexthop,andthenexthop
asspecifiedintheNEXT_HOPpathattribute.
Clarificationofthetiebreakingprocedures.
Clarificationofthefrequencyofrouteadvertisements.
79/90
3/2/2015
OptionalParameterType1(AuthenticationInformation)hasbeen
deprecated.
UPDATEMessageErrorsubcode7(ASRoutingLoop)hasbeen
deprecated.
OPENMessageErrorsubcode5(AuthenticationFailure)hasbeen
deprecated.
UseoftheMarkerfieldforauthenticationhasbeendeprecated.
ImplementationsMUSTsupportTCPMD5[RFC2385]forauthentication.
ClarificationofBGPFSM.
AppendixB.ComparisonwithRFC1267
AllthechangeslistedinAppendixA,plusthefollowing.
BGP4iscapableofoperatinginanenvironmentwhereasetof
reachabledestinationsmaybeexpressedviaasingleIPprefix.The
conceptofnetworkclasses,orsubnetting,isforeigntoBGP4.To
accommodatethesecapabilities,BGP4changesthesemanticsand
encodingassociatedwiththeAS_PATHattribute.Newtexthasbeen
addedtodefinesemanticsassociatedwithIPprefixes.These
abilitiesallowBGP4tosupporttheproposedsupernettingscheme
[RFC1518,RFC1519].
Tosimplifyconfiguration,thisversionintroducesanewattribute,
LOCAL_PREF,thatfacilitatesrouteselectionprocedures.
TheINTER_AS_METRICattributehasbeenrenamedMULTI_EXIT_DISC.
Anewattribute,ATOMIC_AGGREGATE,hasbeenintroducedtoinsurethat
certainaggregatesarenotdeaggregated.Anothernewattribute,
AGGREGATOR,canbeaddedtoaggregateroutestoadvertisewhichAS
andwhichBGPspeakerwithinthatAScausedtheaggregation.
ToensurethatHoldTimersaresymmetric,theHoldTimerisnow
negotiatedonaperconnectionbasis.HoldTimersofzeroarenow
supported.
AppendixC.ComparisonwithRFC1163
AllofthechangeslistedinAppendicesAandB,plusthefollowing.
TodetectandrecoverfromBGPconnectioncollision,anewfield(BGP
Identifier)hasbeenaddedtotheOPENmessage.Newtext(Section
6.8)hasbeenaddedtospecifytheprocedurefordetectingand
recoveringfromcollision.
Thenewdocumentnolongerrestrictstherouterthatispassedinthe
NEXT_HOPpathattributetobepartofthesameAutonomousSystemas
theBGPSpeaker.
Thenewdocumentoptimizesandsimplifiestheexchangeofinformation
80/90
3/2/2015
aboutpreviouslyreachableroutes.
AppendixD.ComparisonwithRFC1105
AllofthechangeslistedinAppendicesA,B,andC,plusthe
following.
Minorchangestothe[RFC1105]FiniteStateMachinewerenecessaryto
accommodatetheTCPuserinterfaceprovidedbyBSDversion4.3.
ThenotionofUp/Down/HorizontalrelationspresentedinRFC1105has
beenremovedfromtheprotocol.
ThechangesinthemessageformatfromRFC1105areasfollows:
1.TheHoldTimefieldhasbeenremovedfromtheBGPheaderand
addedtotheOPENmessage.
2.TheversionfieldhasbeenremovedfromtheBGPheaderand
addedtotheOPENmessage.
3.TheLinkTypefieldhasbeenremovedfromtheOPENmessage.
4.TheOPENCONFIRMmessagehasbeeneliminatedandreplacedwith
implicitconfirmation,providedbytheKEEPALIVEmessage.
5.TheformatoftheUPDATEmessagehasbeenchanged
significantly.NewfieldswereaddedtotheUPDATEmessageto
supportmultiplepathattributes.
6.TheMarkerfieldhasbeenexpandedanditsrolebroadenedto
supportauthentication.
NotethatquiteoftenBGP,asspecifiedinRFC1105,isreferredto
asBGP1;BGP,asspecifiedin[RFC1163],isreferredtoasBGP2;
BGP,asspecifiedinRFC1267isreferredtoasBGP3;andBGP,as
specifiedinthisdocumentisreferredtoasBGP4.
AppendixE.TCPOptionsthatMayBeUsedwithBGP
IfalocalsystemTCPuserinterfacesupportstheTCPPUSHfunction,
theneachBGPmessageSHOULDbetransmittedwithPUSHflagset.
SettingPUSHflagforcesBGPmessagestobetransmittedtothe
receiverpromptly.
IfalocalsystemTCPuserinterfacesupportssettingtheDSCPfield
[RFC2474]forTCPconnections,thentheTCPconnectionusedbyBGP
SHOULDbeopenedwithbits02oftheDSCPfieldsetto110(binary).
AnimplementationMUSTsupporttheTCPMD5option[RFC2385].
81/90
3/2/2015
AppendixF.ImplementationRecommendations
Thissectionpresentssomeimplementationrecommendations.
AppendixF.1.MultipleNetworksPerMessage
TheBGPprotocolallowsformultipleaddressprefixeswiththesame
pathattributestobespecifiedinonemessage.Usingthis
capabilityishighlyrecommended.Withoneaddressprefixper
messagethereisasubstantialincreaseinoverheadinthereceiver.
Notonlydoesthesystemoverheadincreaseduetothereceptionof
multiplemessages,buttheoverheadofscanningtheroutingtablefor
updatestoBGPpeersandotherroutingprotocols(andsendingthe
associatedmessages)isincurredmultipletimesaswell.
Onemethodofbuildingmessagesthatcontainmanyaddressprefixes
perpathattributesetfromaroutingtablethatisnotorganizedon
aperpathattributesetbasisistobuildmanymessagesasthe
routingtableisscanned.Aseachaddressprefixisprocessed,a
messagefortheassociatedsetofpathattributesisallocated,ifit
doesnotexist,andthenewaddressprefixisaddedtoit.Ifsucha
messageexists,thenewaddressprefixisappendedtoit.Ifthe
messagelacksthespacetoholdthenewaddressprefix,itis
transmitted,anewmessageisallocated,andthenewaddressprefix
isinsertedintothenewmessage.Whentheentireroutingtablehas
beenscanned,allallocatedmessagesaresentandtheirresourcesare
released.Maximumcompressionisachievedwhenalldestinations
coveredbytheaddressprefixesshareacommonsetofpath
attributes,makingitpossibletosendmanyaddressprefixesinone
4096bytemessage.
WhenpeeringwithaBGPimplementationthatdoesnotcompress
multipleaddressprefixesintoonemessage,itmaybenecessaryto
takestepstoreducetheoverheadfromthefloodofdatareceived
whenapeerisacquiredorwhenasignificantnetworktopologychange
occurs.Onemethodofdoingthisistolimittherateofupdates.
Thiswilleliminatetheredundantscanningoftheroutingtableto
provideflashupdatesforBGPpeersandotherroutingprotocols.A
disadvantageofthisapproachisthatitincreasesthepropagation
latencyofroutinginformation.Bychoosingaminimumflashupdate
intervalthatisnotmuchgreaterthanthetimeittakestoprocess
themultiplemessages,thislatencyshouldbeminimized.Abetter
methodwouldbetoreadallreceivedmessagesbeforesendingupdates.
AppendixF.2.ReducingRouteFlapping
Toavoidexcessiverouteflapping,aBGPspeakerthatneedsto
82/90
3/2/2015
withdrawadestinationandsendanupdateaboutamorespecificor
lessspecificrouteshouldcombinethemintothesameUPDATEmessage.
AppendixF.3.PathAttributeOrdering
Implementationsthatcombineupdatemessages(asdescribedabovein
Section6.1)mayprefertoseeallpathattributespresentedina
knownorder.Thispermitsthemtoquicklyidentifysetsof
attributesfromdifferentupdatemessagesthataresemantically
identical.Tofacilitatethis,itisausefuloptimizationtoorder
thepathattributesaccordingtotypecode.Thisoptimizationis
entirelyoptional.
AppendixF.4.AS_SETSorting
Anotherusefuloptimizationthatcanbedonetosimplifythis
situationistosorttheASnumbersfoundinanAS_SET.This
optimizationisentirelyoptional.
AppendixF.5.ControlOverVersionNegotiation
BecauseBGP4iscapableofcarryingaggregatedroutesthatcannotbe
properlyrepresentedinBGP3,animplementationthatsupportsBGP4
andanotherBGPversionshouldprovidethecapabilitytoonlyspeak
BGP4onaperpeerbasis.
AppendixF.6.ComplexAS_PATHAggregation
Animplementationthatchoosestoprovideapathaggregation
algorithmretainingsignificantamountsofpathinformationmaywish
tousethefollowingprocedure:
ForthepurposeofaggregatingAS_PATHattributesoftworoutes,
wemodeleachASasatuple<type,value>,where"type"identifies
atypeofthepathsegmenttheASbelongsto(e.g.,AS_SEQUENCE,
AS_SET),and"value"istheASnumber.TwoASesaresaidtobe
thesameiftheircorresponding<type,value>tuplesarethesame.
ThealgorithmtoaggregatetwoAS_PATHattributesworksas
follows:
a)IdentifythesameASes(asdefinedabove)withineach
AS_PATHattributethatareinthesamerelativeorderwithin
bothAS_PATHattributes.TwoASes,XandY,aresaidtobe
inthesameorderifeither:
XprecedesYinbothAS_PATHattributes,or
YprecedesXinbothAS_PATHattributes.
b)TheaggregatedAS_PATHattributeconsistsofASesidentified
in(a),inexactlythesameorderastheyappearinthe
AS_PATHattributestobeaggregated.Iftwoconsecutive
ASesidentifiedin(a)donotimmediatelyfolloweachother
inbothoftheAS_PATHattributestobeaggregated,thenthe
interveningASes(ASesthatarebetweenthetwoconsecutive
ASesthatarethesame)inbothattributesarecombinedinto
anAS_SETpathsegmentthatconsistsoftheinterveningASes
frombothAS_PATHattributes.Thissegmentisthenplaced
83/90
3/2/2015
betweenthetwoconsecutiveASesidentifiedin(a)ofthe
aggregatedattribute.IftwoconsecutiveASesidentifiedin
(a)immediatelyfolloweachotherinoneattribute,butdo
notfollowinanother,thentheinterveningASesofthe
latterarecombinedintoanAS_SETpathsegment.This
segmentisthenplacedbetweenthetwoconsecutiveASes
identifiedin(a)oftheaggregatedattribute.
c)ForeachpairofadjacenttuplesintheaggregatedAS_PATH,
ifbothtupleshavethesametype,mergethemtogetherif
doingsowillnotcauseasegmentofalengthgreaterthan
255tobegenerated.
If,asaresultoftheaboveprocedure,agivenASnumberappears
morethanoncewithintheaggregatedAS_PATHattribute,allbut
thelastinstance(rightmostoccurrence)ofthatASnumbershould
beremovedfromtheaggregatedAS_PATHattribute.
SecurityConsiderations
ABGPimplementationMUSTsupporttheauthenticationmechanism
specifiedinRFC2385[RFC2385].Theauthenticationprovidedbythis
mechanismcouldbedoneonaperpeerbasis.
BGPmakesuseofTCPforreliabletransportofitstrafficbetween
peerrouters.Toprovideconnectionorientedintegrityanddata
originauthenticationonapointtopointbasis,BGPspecifiesuseof
themechanismdefinedinRFC2385.Theseservicesareintendedto
detectandrejectactivewiretappingattacksagainsttheinterrouter
TCPconnections.Absenttheuseofmechanismsthateffectthese
securityservices,attackerscandisrupttheseTCPconnectionsand/or
masqueradeasalegitimatepeerrouter.Becausethemechanism
definedintheRFCdoesnotprovidepeerentityauthentication,these
connectionsmaybesubjecttosomeformsofreplayattacksthatwill
notbedetectedattheTCPlayer.Suchattacksmightresultin
delivery(fromTCP)of"broken"or"spoofed"BGPmessages.
ThemechanismdefinedinRFC2385augmentsthenormalTCPchecksum
witha16bytemessageauthenticationcode(MAC)thatiscomputed
overthesamedataastheTCPchecksum.ThisMACisbasedonaone
wayhashfunction(MD5)anduseofasecretkey.Thekeyisshared
betweenpeerroutersandisusedtogenerateMACvaluesthatarenot
readilycomputedbyanattackerwhodoesnothaveaccesstothekey.
Acompliantimplementationmustsupportthismechanism,andmust
allowanetworkadministratortoactivateitonaperpeerbasis.
RFC2385doesnotspecifyameansofmanaging(e.g.,generating,
distributing,andreplacing)thekeysusedtocomputetheMAC.RFC
3562[RFC3562](aninformationaldocument)providessomeguidancein
thisarea,andprovidesrationaletosupportthisguidance.Itnotes
thatadistinctkeyshouldbeusedforcommunicationwitheach
protectedpeer.Ifthesamekeyisusedformultiplepeers,the
offeredsecurityservicesmaybedegraded,e.g.,duetoanincreased
riskofcompromiseatonerouterthatadverselyaffectsother
routers.
ThekeysusedforMACcomputationshouldbechangedperiodically,to
minimizetheimpactofakeycompromiseorsuccessfulcryptanalytic
84/90
3/2/2015
attack.RFC3562suggestsacryptoperiod(theintervalduringwhich
akeyisemployed)of,atmost,90days.Morefrequentkeychanges
reducethelikelihoodthatreplayattacks(asdescribedabove)will
befeasible.However,absentastandardmechanismforeffectingsuch
changesinacoordinatedfashionbetweenpeers,onecannotassume
thatBGP4implementationscomplyingwiththisRFCwillsupport
frequentkeychanges.
Obviously,eachshouldkeyalsobechosentobedifficultforan
attackertoguess.ThetechniquesspecifiedinRFC1750forrandom
numbergenerationprovideaguideforgenerationofvaluesthatcould
beusedaskeys.RFC2385callsforimplementationstosupportkeys
"composedofastringofprintableASCIIof80bytesorless."RFC
3562suggestskeysusedinthiscontextbe12to24bytesofrandom
(pseudorandom)bits.Thisisfairlyconsistentwithsuggestionsfor
analogousMACalgorithms,whichtypicallyemploykeysintherangeof
16to20bytes.Toprovideenoughrandombitsatthelowendofthis
range,RFC3562alsoobservesthatatypicalACSIItextstringwould
havetobeclosetotheupperboundforthekeylengthspecifiedin
RFC2385.
BGPvulnerabilitiesanalysisisdiscussedin[RFC4272].
IANAConsiderations
AlltheBGPmessagescontainan8bitmessagetype,forwhichIANA
hascreatedandismaintainingaregistryentitled"BGPMessage
Types".Thisdocumentdefinesthefollowingmessagetypes:
NameValueDefinition
OPEN1SeeSection4.2
UPDATE2SeeSection4.3
NOTIFICATION3SeeSection4.5
KEEPALIVE4SeeSection4.4
FutureassignmentsaretobemadeusingeithertheStandardsAction
processdefinedin[RFC2434],ortheEarlyIANAAllocationprocess
definedin[RFC4020].Assignmentsconsistofanameandthevalue.
TheBGPUPDATEmessagesmaycarryoneormorePathAttributes,where
eachAttributecontainsan8bitAttributeTypeCode.IANAis
alreadymaintainingsucharegistry,entitled"BGPPathAttributes".
ThisdocumentdefinesthefollowingPathAttributesTypeCodes:
NameValueDefinition
ORIGIN1SeeSection5.1.1
AS_PATH2SeeSection5.1.2
NEXT_HOP3SeeSection5.1.3
MULTI_EXIT_DISC4SeeSection5.1.4
LOCAL_PREF5SeeSection5.1.5
ATOMIC_AGGREGATE6SeeSection5.1.6
85/90
3/2/2015
AGGREGATOR7SeeSection5.1.7
TheBGPNOTIFICATIONmessagecarriesan8bitErrorCode,forwhich
IANAhascreatedandismaintainingaregistryentitled"BGPError
Codes".ThisdocumentdefinesthefollowingErrorCodes:
NameValueDefinition
MessageHeaderError1Section6.1
OPENMessageError2Section6.2
UPDATEMessageError3Section6.3
HoldTimerExpired4Section6.5
FiniteStateMachineError5Section6.6
Cease6Section6.7
TheBGPNOTIFICATIONmessagecarriesan8bitErrorSubcode,where
eachSubcodehastobedefinedwithinthecontextofaparticular
ErrorCode,andthushastobeuniqueonlywithinthatcontext.
IANAhascreatedandismaintainingasetofregistries,"Error
Subcodes",withaseparateregistryforeachBGPErrorCode.Future
assignmentsaretobemadeusingeithertheStandardsActionprocess
definedin[RFC2434],ortheEarlyIANAAllocationprocessdefinedin
[RFC4020].Assignmentsconsistofanameandthevalue.
ThisdocumentdefinesthefollowingMessageHeaderErrorsubcodes:
NameValueDefinition
ConnectionNotSynchronized1SeeSection6.1
BadMessageLength2SeeSection6.1
BadMessageType3SeeSection6.1
ThisdocumentdefinesthefollowingOPENMessageErrorsubcodes:
NameValueDefinition
UnsupportedVersionNumber1SeeSection6.2
BadPeerAS2SeeSection6.2
BadBGPIdentifier3SeeSection6.2
UnsupportedOptionalParameter4SeeSection6.2
[Deprecated]5SeeAppendixA
UnacceptableHoldTime6SeeSection6.2
ThisdocumentdefinesthefollowingUPDATEMessageErrorsubcodes:
NameValueDefinition
MalformedAttributeList1SeeSection6.3
UnrecognizedWellknownAttribute2SeeSection6.3
86/90
3/2/2015
MissingWellknownAttribute3SeeSection6.3
AttributeFlagsError4SeeSection6.3
AttributeLengthError5SeeSection6.3
InvalidORIGINAttribute6SeeSection6.3
[Deprecated]7SeeAppendixA
InvalidNEXT_HOPAttribute8SeeSection6.3
OptionalAttributeError9SeeSection6.3
InvalidNetworkField10SeeSection6.3
MalformedAS_PATH11SeeSection6.3
NormativeReferences
[RFC791]Postel,J.,"InternetProtocol",STD5,RFC791,September
1981.
[RFC793]Postel,J.,"TransmissionControlProtocol",STD7,RFC
793,September1981.
[RFC2119]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[RFC2385]Heffernan,A.,"ProtectionofBGPSessionsviatheTCPMD5
SignatureOption",RFC2385,August1998.
[RFC2434]Narten,T.andH.Alvestrand,"GuidelinesforWritingan
IANAConsiderationsSectioninRFCs",BCP26,RFC2434,
October1998.
InformativeReferences
[RFC904]Mills,D.,"ExteriorGatewayProtocolformal
specification",RFC904,April1984.
[RFC1092]Rekhter,J.,"EGPandpolicybasedroutinginthenew
NSFNETbackbone",RFC1092,February1989.
[RFC1093]Braun,H.,"NSFNETroutingarchitecture",RFC1093,
February1989.
[RFC1105]Lougheed,K.andY.Rekhter,"BorderGatewayProtocol
(BGP)",RFC1105,June1989.
[RFC1163]Lougheed,K.andY.Rekhter,"BorderGatewayProtocol
(BGP)",RFC1163,June1990.
[RFC1267]Lougheed,K.andY.Rekhter,"BorderGatewayProtocol3
(BGP3)",RFC1267,October1991.
[RFC1771]Rekhter,Y.andT.Li,"ABorderGatewayProtocol4(BGP
4)",RFC1771,March1995.
[RFC1772]Rekhter,Y.andP.Gross,"ApplicationoftheBorder
GatewayProtocolintheInternet",RFC1772,March1995.
[RFC1518]Rekhter,Y.andT.Li,"AnArchitectureforIPAddress
AllocationwithCIDR",RFC1518,September1993.
87/90
3/2/2015
[RFC1519]Fuller,V.,Li,T.,Yu,J.,andK.Varadhan,"Classless
InterDomainRouting(CIDR):anAddressAssignmentand
AggregationStrategy",RFC1519,September1993.
[RFC1930]Hawkinson,J.andT.Bates,"Guidelinesforcreation,
selection,andregistrationofanAutonomousSystem(AS)",
BCP6,RFC1930,March1996.
[RFC1997]Chandra,R.,Traina,P.,andT.Li,"BGPCommunities
Attribute",RFC1997,August1996.
[RFC2439]Villamizar,C.,Chandra,R.,andR.Govindan,"BGPRoute
FlapDamping",RFC2439,November1998.
[RFC2474]Nichols,K.,Blake,S.,Baker,F.,andD.Black,
"DefinitionoftheDifferentiatedServicesField(DSField)
intheIPv4andIPv6Headers",RFC2474,December1998.
[RFC2796]Bates,T.,Chandra,R.,andE.Chen,"BGPRouteReflection
AnAlternativetoFullMeshIBGP",RFC2796,April2000.
[RFC2858]Bates,T.,Rekhter,Y.,Chandra,R.,andD.Katz,
"MultiprotocolExtensionsforBGP4",RFC2858,June2000.
[RFC3392]Chandra,R.andJ.Scudder,"CapabilitiesAdvertisement
withBGP4",RFC3392,November2002.
[RFC2918]Chen,E.,"RouteRefreshCapabilityforBGP4",RFC2918,
September2000.
[RFC3065]Traina,P.,McPherson,D.,andJ.Scudder,"Autonomous
SystemConfederationsforBGP",RFC3065,February2001.
[RFC3562]Leech,M.,"KeyManagementConsiderationsfortheTCPMD5
SignatureOption",RFC3562,July2003.
[IS10747]"InformationProcessingSystemsTelecommunicationsand
InformationExchangebetweenSystemsProtocolfor
ExchangeofInterdomainRouteingInformationamong
IntermediateSystemstoSupportForwardingofISO8473
PDUs",ISO/IECIS10747,1993.
[RFC4272]Murphy,S.,"BGPSecurityVulnerabilitiesAnalysis",RFC
4272,January2006
[RFC4020]Kompella,K.andA.Zinin,"EarlyIANAAllocationof
StandardsTrackCodePoints",BCP100,RFC4020,February
2005.
Editors'Addresses
88/90
3/2/2015
YakovRekhter
JuniperNetworks
EMail:yakov@juniper.net
TonyLi
EMail:tony.li@tony.li
SusanHares
NextHopTechnologies,Inc.
825VictorsWay
AnnArbor,MI48108
Phone:(734)2221610
EMail:skh@nexthop.com
FullCopyrightStatement
Copyright(C)TheInternetSociety(2006).
Thisdocumentissubjecttotherights,licensesandrestrictions
containedinBCP78,andexceptassetforththerein,theauthors
retainalltheirrights.
Thisdocumentandtheinformationcontainedhereinareprovidedonan
"ASIS"basisandTHECONTRIBUTOR,THEORGANIZATIONHE/SHEREPRESENTS
89/90
3/2/2015
ORISSPONSOREDBY(IFANY),THEINTERNETSOCIETYANDTHEINTERNET
ENGINEERINGTASKFORCEDISCLAIMALLWARRANTIES,EXPRESSORIMPLIED,
INCLUDINGBUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHE
INFORMATIONHEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIED
WARRANTIESOFMERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
IntellectualProperty
TheIETFtakesnopositionregardingthevalidityorscopeofany
IntellectualPropertyRightsorotherrightsthatmightbeclaimedto
pertaintotheimplementationoruseofthetechnologydescribedin
thisdocumentortheextenttowhichanylicenseundersuchrights
mightormightnotbeavailable;nordoesitrepresentthatithas
madeanyindependentefforttoidentifyanysuchrights.Information
ontheprocedureswithrespecttorightsinRFCdocumentscanbe
foundinBCP78andBCP79.
CopiesofIPRdisclosuresmadetotheIETFSecretariatandany
assurancesoflicensestobemadeavailable,ortheresultofan
attemptmadetoobtainagenerallicenseorpermissionfortheuseof
suchproprietaryrightsbyimplementersorusersofthis
specificationcanbeobtainedfromtheIETFonlineIPRrepositoryat
http://www.ietf.org/ipr.
TheIETFinvitesanyinterestedpartytobringtoitsattentionany
copyrights,patentsorpatentapplications,orotherproprietary
rightsthatmaycovertechnologythatmayberequiredtoimplement
thisstandard.PleaseaddresstheinformationtotheIETFat
ietfipr@ietf.org.
Acknowledgement
FundingfortheRFCEditorfunctionisprovidedbytheIETF
AdministrativeSupportActivity(IASA).
90/90

RFC Rfc4271

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFC Rfc4271

Uploaded by

Copyright:

Available Formats

3/2/2015

You might also like