rfc rfc1771

8/8/2019 www.ietf.org rfc rfc1771

1/58

Network Working Group Y. Rekhter

Request for Comments: 1771 T.J. Watson Research Center, IBM Corp.Obsoletes: 1654 T. LiCategory: Standards Track cisco Systems

EditorsMarch 1995

A Border Gateway Protocol 4 (BGP-4)

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.

Abstract

This document, together with its companion document, "Application ofthe Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet.

1. Acknowledgements

This document was originally published as RFC 1267 in October 1991,jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter(IBM).

We would like to express our thanks to Guy Almes (ANS), Len Bosack(cisco Systems), and Jeffrey C. Honig (Cornell University) for theircontributions to the earlier version of this document.

We like to explicitly thank Bob Braden (ISI) for the review of theearlier version of this document as well as his constructive andvaluable comments.

We would also like to thank Bob Hinden, Director for Routing of theInternet Engineering Steering Group, and the team of reviewers heassembled to review the previous version (BGP-2) of this document.This team, consisting of Deborah Estrin, Milo Medin, John Moy, RadiaPerlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, actedwith a strong combination of toughness, professionalism, andcourtesy.

Rekhter & Li [Page 1]


2/58

RFC 1771 BGP-4 March 1995

This updated version of the document is the product of the IETF IDRWorking Group with Yakov Rekhter and Tony Li as editors. Certainsections of the document borrowed heavily from IDRP [7], which is the

OSI counterpart of BGP. For this credit should be given to the ANSIX3S3.3 group chaired by Lyman Chapin (BBN) and to Charles Kunzinger(IBM Corp.) who was the IDRP editor within that group. We would alsolike to thank Mike Craren (Proteon, Inc.), Dimitry Haskin (BayNetworks, Inc.), John Krawczyk (Bay Networks, Inc.), and Paul Traina(cisco Systems) for their insightful comments.

We would like to specially acknowledge numerous contributions byDennis Ferguson (MCI).

The work of Yakov Rekhter was supported in part by the NationalScience Foundation under Grant Number NCR-9219216.

2. Introduction

The Border Gateway Protocol (BGP) is an inter-Autonomous Systemrouting protocol. It is built on experience gained with EGP asdefined in RFC 904 [1] and EGP usage in the NSFNET Backbone asdescribed in RFC 1092 [2] and RFC 1093 [3].

The primary function of a BGP speaking system is to exchange networkreachability information with other BGP systems. This networkreachability information includes information on the list ofAutonomous Systems (ASs) that reachability information traverses.This information is sufficient to construct a graph of AS

connectivity from which routing loops may be pruned and some policydecisions at the AS level may be enforced.

BGP-4 provides a new set of mechanisms for supporting classlessinterdomain routing. These mechanisms include support foradvertising an IP prefix and eliminates the concept of network"class" within BGP. BGP-4 also introduces mechanisms which allowaggregation of routes, including aggregation of AS paths. Thesechanges provide support for the proposed supernetting scheme [8, 9].

To characterize the set of policy decisions that can be enforcedusing BGP, one must focus on the rule that a BGP speaker advertise toits peers (other BGP speakers which it communicates with) inneighboring ASs only those routes that it itself uses. This rulereflects the "hop-by-hop" routing paradigm generally used throughoutthe current Internet. Note that some policies cannot be supported bythe "hop-by-hop" routing paradigm and thus require techniques such assource routing to enforce. For example, BGP does not enable one ASto send traffic to a neighboring AS intending that the traffic take adifferent route from that taken by traffic originating in the



3/58


neighboring AS. On the other hand, BGP can support any policyconforming to the "hop-by-hop" routing paradigm. Since the currentInternet uses only the "hop-by-hop" routing paradigm and since BGP

can support any policy that conforms to that paradigm, BGP is highlyapplicable as an inter-AS routing protocol for the current Internet.

A more complete discussion of what policies can and cannot beenforced with BGP is outside the scope of this document (but refer tothe companion document discussing BGP usage [5]).

BGP runs over a reliable transport protocol. This eliminates theneed to implement explicit update fragmentation, retransmission,acknowledgement, and sequencing. Any authentication scheme used bythe transport protocol may be used in addition to BGP's ownauthentication mechanisms. The error notification mechanism used in

BGP assumes that the transport protocol supports a "graceful" close,i.e., that all outstanding data will be delivered before theconnection is closed.

BGP uses TCP [4] as its transport protocol. TCP meets BGP'stransport requirements and is present in virtually all commercialrouters and hosts. In the following descriptions the phrase"transport protocol connection" can be understood to refer to a TCPconnection. BGP uses TCP port 179 for establishing its connections.

This document uses the term `Autonomous System' (AS) throughout. Theclassic definition of an Autonomous System is a set of routers undera single technical administration, using an interior gateway protocol

and common metrics to route packets within the AS, and using anexterior gateway protocol to route packets to other ASs. Since thisclassic definition was developed, it has become common for a singleAS to use several interior gateway protocols and sometimes severalsets of metrics within an AS. The use of the term Autonomous Systemhere stresses the fact that, even when multiple IGPs and metrics areused, the administration of an AS appears to other ASs to have asingle coherent interior routing plan and presents a consistentpicture of what destinations are reachable through it.

The planned use of BGP in the Internet environment, including suchissues as topology, the interaction between BGP and IGPs, and theenforcement of routing policy rules is presented in a companiondocument [5]. This document is the first of a series of documentsplanned to explore various aspects of BGP application. Please sendcomments to the BGP mailing list ([email protected]).



4/58


3. Summary of Operation

Two systems form a transport protocol connection between one another.

They exchange messages to open and confirm the connection parameters.The initial data flow is the entire BGP routing table. Incrementalupdates are sent as the routing tables change. BGP does not requireperiodic refresh of the entire BGP routing table. Therefore, a BGPspeaker must retain the current version of the entire BGP routingtables of all of its peers for the duration of the connection.KeepAlive messages are sent periodically to ensure the liveness ofthe connection. Notification messages are sent in response to errorsor special conditions. If a connection encounters an errorcondition, a notification message is sent and the connection isclosed.

The hosts executing the Border Gateway Protocol need not be routers.A non-routing host could exchange routing information with routersvia EGP or even an interior routing protocol. That non-routing hostcould then use BGP to exchange routing information with a borderrouter in another Autonomous System. The implications andapplications of this architecture are for further study.

If a particular AS has multiple BGP speakers and is providing transitservice for other ASs, then care must be taken to ensure a consistentview of routing within the AS. A consistent view of the interiorroutes of the AS is provided by the interior routing protocol. Aconsistent view of the routes exterior to the AS can be provided byhaving all BGP speakers within the AS maintain direct BGP connections

with each other. Using a common set of policies, the BGP speakersarrive at an agreement as to which border routers will serve asexit/entry points for particular destinations outside the AS. Thisinformation is communicated to the AS's internal routers, possiblyvia the interior routing protocol. Care must be taken to ensure thatthe interior routers have all been updated with transit informationbefore the BGP speakers announce to other ASs that transit service isbeing provided.

Connections between BGP speakers of different ASs are referred to as"external" links. BGP connections between BGP speakers within thesame AS are referred to as "internal" links. Similarly, a peer in adifferent AS is referred to as an external peer, while a peer in thesame AS may be described as an internal peer.



5/58


3.1 Routes: Advertisement and Storage

For purposes of this protocol a route is defined as a unit of

information that pairs a destination with the attributes of a path tothat destination:

- Routes are advertised between a pair of BGP speakers in UPDATEmessages: the destination is the systems whose IP addresses arereported in the Network Layer Reachability Information (NLRI)field, and the the path is the information reported in the pathattributes fields of the same UPDATE message.

- Routes are stored in the Routing Information Bases (RIBs):namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routesthat will be advertised to other BGP speakers must be present in

the Adj-RIB-Out; routes that will be used by the local BGP speakermust be present in the Loc-RIB, and the next hop for each of theseroutes must be present in the local BGP speaker's forwardinginformation base; and routes that are received from other BGPspeakers are present in the Adj-RIBs-In.

If a BGP speaker chooses to advertise the route, it may add to ormodify the path attributes of the route before advertising it to apeer.

BGP provides mechanisms by which a BGP speaker can inform its peerthat a previously advertised route is no longer available for use.There are three methods by which a given BGP speaker can indicate

that a route has been withdrawn from service:

a) the IP prefix that expresses destinations for a previouslyadvertised route can be advertised in the WITHDRAWN ROUTES fieldin the UPDATE message, thus marking the associated route as beingno longer available for use

b) a replacement route with the same Network Layer ReachabilityInformation can be advertised, or

c) the BGP speaker - BGP speaker connection can be closed, whichimplicitly removes from service all routes which the pair ofspeakers had advertised to each other.



6/58


3.2 Routing Information Bases

The Routing Information Base (RIB) within a BGP speaker consists of

three distinct parts:

a) Adj-RIBs-In: The Adj-RIBs-In store routing information that hasbeen learned from inbound UPDATE messages. Their contentsrepresent routes that are available as an input to the DecisionProcess.

b) Loc-RIB: The Loc-RIB contains the local routing informationthat the BGP speaker has selected by applying its local policiesto the routing information contained in its Adj-RIBs-In.

c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the

local BGP speaker has selected for advertisement to its peers. Therouting information stored in the Adj-RIBs-Out will be carried inthe local BGP speaker's UPDATE messages and advertised to itspeers.

In summary, the Adj-RIBs-In contain unprocessed routing informationthat has been advertised to the local BGP speaker by its peers; theLoc-RIB contains the routes that have been selected by the local BGPspeaker's Decision Process; and the Adj-RIBs-Out organize the routesfor advertisement to specific peers by means of the local speaker'sUPDATE messages.

Although the conceptual model distinguishes between Adj-RIBs-In,

Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that animplementation must maintain three separate copies of the routinginformation. The choice of implementation (for example, 3 copies ofthe information vs 1 copy with pointers) is not constrained by theprotocol.

4. Message Formats

This section describes message formats used by BGP.

Messages are sent over a reliable transport protocol connection. Amessage is processed only after it is entirely received. The maximummessage size is 4096 octets. All implementations are required tosupport this maximum message size. The smallest message that may besent consists of a BGP header without a data portion, or 19 octets.



7/58


4.1 Message Header Format

Each message has a fixed-size header. There may or may not be a data

portion following the header, depending on the message type. Thelayout of these fields is shown below:

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + Marker + +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Marker:

This 16-octet field contains a value that the receiver of themessage can predict. If the Type of the message is OPEN, or ifthe OPEN message carries no Authentication Information (as anOptional Parameter), then the Marker must be all ones.Otherwise, the value of the marker can be predicted by some acomputation specified as part of the authentication mechanism

(which is specified as part of the Authentication Information)used. The Marker can be used to detect loss of synchronizationbetween a pair of BGP peers, and to authenticate incoming BGPmessages.

Length:

This 2-octet unsigned integer indicates the total length of themessage, including the header, in octets. Thus, e.g., itallows one to locate in the transport-level stream the (Markerfield of the) next message. The value of the Length field mustalways be at least 19 and no greater than 4096, and may befurther constrained, depending on the message type. No"padding" of extra data after the message is allowed, so theLength field must have the smallest value required given therest of the message.



8/58


Type:

This 1-octet unsigned integer indicates the type code of the

message. The following type codes are defined:

1 - OPEN2 - UPDATE3 - NOTIFICATION4 - KEEPALIVE

4.2 OPEN Message Format

After a transport protocol connection is established, the firstmessage sent by each side is an OPEN message. If the OPEN message isacceptable, a KEEPALIVE message confirming the OPEN is sent back.

Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATIONmessages may be exchanged.

In addition to the fixed-size BGP header, the OPEN message containsthe following fields:

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+ Version +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ My Autonomous System +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hold Time +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BGP Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Opt Parm Len +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optional Parameters +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version:

This 1-octet unsigned integer indicates the protocol versionnumber of the message. The current BGP version number is 4.

My Autonomous System:

This 2-octet unsigned integer indicates the Autonomous Systemnumber of the sender.



9/58


Hold Time:

This 2-octet unsigned integer indicates the number of seconds

that the sender proposes for the value of the Hold Timer. Uponreceipt of an OPEN message, a BGP speaker MUST calculate thevalue of the Hold Timer by using the smaller of its configuredHold Time and the Hold Time received in the OPEN message. TheHold Time MUST be either zero or at least three seconds. Animplementation may reject connections on the basis of the HoldTime. The calculated value indicates the maximum number ofseconds that may elapse between the receipt of successiveKEEPALIVE, and/or UPDATE messages by the sender.

BGP Identifier:

This 4-octet unsigned integer indicates the BGP Identifier ofthe sender. A given BGP speaker sets the value of its BGPIdentifier to an IP address assigned to that BGP speaker. Thevalue of the BGP Identifier is determined on startup and is thesame for every local interface and every BGP peer.

Optional Parameters Length:

This 1-octet unsigned integer indicates the total length of theOptional Parameters field in octets. If the value of this fieldis zero, no Optional Parameters are present.

Optional Parameters:

This field may contain a list of optional parameters, whereeach parameter is encoded as a triplet.

0 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Parm. Type Parm. Length Parameter Value (variable)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

Parameter Type is a one octet field that unambiguouslyidentifies individual parameters. Parameter Length is a oneoctet field that contains the length of the Parameter Valuefield in octets. Parameter Value is a variable length fieldthat is interpreted according to the value of the ParameterType field.



10/58


This document defines the following Optional Parameters:

a) Authentication Information (Parameter Type 1):

This optional parameter may be used to authenticate a BGPpeer. The Parameter Value field contains a 1-octetAuthentication Code followed by a variable lengthAuthentication Data.

0 1 2 3 4 5 6 7 8+-+-+-+-+-+-+-+-+ Auth. Code +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication Data

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authentication Code:

This 1-octet unsigned integer indicates theauthentication mechanism being used. Whenever anauthentication mechanism is specified for use withinBGP, three things must be included in thespecification:

- the value of the Authentication Code which indicatesuse of the mechanism,

- the form and meaning of the Authentication Data, and- the algorithm for computing values of Marker fields.

Note that a separate authentication mechanism may beused in establishing the transport level connection.

Authentication Data:

The form and meaning of this field is a variable-length field depend on the Authentication Code.

The minimum length of the OPEN message is 29 octets (includingmessage header).



11/58


4.3 UPDATE Message Format

UPDATE messages are used to transfer routing information between BGP

peers. The information in the UPDATE packet can be used to constructa graph describing the relationships of the various AutonomousSystems. By applying rules to be discussed, routing informationloops and some other anomalies may be detected and removed frominter-AS routing.

An UPDATE message is used to advertise a single feasible route to apeer, or to withdraw multiple unfeasible routes from service (see3.1). An UPDATE message may simultaneously advertise a feasible routeand withdraw multiple unfeasible routes from service. The UPDATEmessage always includes the fixed-size BGP header, and can optionallyinclude the other fields as shown below:

+-----------------------------------------------------+ Unfeasible Routes Length (2 octets) +-----------------------------------------------------+ Withdrawn Routes (variable) +-----------------------------------------------------+ Total Path Attribute Length (2 octets) +-----------------------------------------------------+ Path Attributes (variable) +-----------------------------------------------------+ Network Layer Reachability Information (variable) +-----------------------------------------------------+

Unfeasible Routes Length:

This 2-octets unsigned integer indicates the total length ofthe Withdrawn Routes field in octets. Its value must allow thelength of the Network Layer Reachability Information field tobe determined as specified below.

A value of 0 indicates that no routes are being withdrawn fromservice, and that the WITHDRAWN ROUTES field is not present inthis UPDATE message.

Withdrawn Routes:

This is a variable length field that contains a list of IPaddress prefixes for the routes that are being withdrawn fromservice. Each IP address prefix is encoded as a 2-tuple of theform , whose fields are described below:



12/58


+---------------------------+ Length (1 octet) +---------------------------+

Prefix (variable) +---------------------------+

The use and the meaning of these fields are as follows:

a) Length:

The Length field indicates the length in bits of the IPaddress prefix. A length of zero indicates a prefix thatmatches all IP addresses (with prefix, itself, of zerooctets).

b) Prefix:

The Prefix field contains IP address prefixes followed byenough trailing bits to make the end of the field fall on anoctet boundary. Note that the value of trailing bits isirrelevant.

Total Path Attribute Length:

This 2-octet unsigned integer indicates the total length of thePath Attributes field in octets. Its value must allow thelength of the Network Layer Reachability field to be determinedas specified below.

A value of 0 indicates that no Network Layer ReachabilityInformation field is present in this UPDATE message.

Path Attributes:

A variable length sequence of path attributes is present inevery UPDATE. Each path attribute is a triple of variable length.

Attribute Type is a two-octet field that consists of theAttribute Flags octet followed by the Attribute Type Codeoctet.

0 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attr. Flags Attr. Type Code+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



13/58


The high-order bit (bit 0) of the Attribute Flags octet is theOptional bit. It defines whether the attribute is optional (ifset to 1) or well-known (if set to 0).

The second high-order bit (bit 1) of the Attribute Flags octetis the Transitive bit. It defines whether an optionalattribute is transitive (if set to 1) or non-transitive (if setto 0). For well-known attributes, the Transitive bit must beset to 1. (See Section 5 for a discussion of transitiveattributes.)

The third high-order bit (bit 2) of the Attribute Flags octetis the Partial bit. It defines whether the informationcontained in the optional transitive attribute is partial (ifset to 1) or complete (if set to 0). For well-known attributes

and for optional non-transitive attributes the Partial bit mustbe set to 0.

The fourth high-order bit (bit 3) of the Attribute Flags octetis the Extended Length bit. It defines whether the AttributeLength is one octet (if set to 0) or two octets (if set to 1).Extended Length may be used only if the length of the attributevalue is greater than 255 octets.

The lower-order four bits of the Attribute Flags octet are .unused. They must be zero (and must be ignored when received).

The Attribute Type Code octet contains the Attribute Type Code.

Currently defined Attribute Type Codes are discussed in Section5.

If the Extended Length bit of the Attribute Flags octet is setto 0, the third octet of the Path Attribute contains the lengthof the attribute data in octets.

If the Extended Length bit of the Attribute Flags octet is setto 1, then the third and the fourth octets of the pathattribute contain the length of the attribute data in octets.

The remaining octets of the Path Attribute represent theattribute value and are interpreted according to the AttributeFlags and the Attribute Type Code. The supported Attribute TypeCodes, their attribute values and uses are the following:



14/58


a) ORIGIN (Type Code 1):

ORIGIN is a well-known mandatory attribute that defines the

origin of the path information. The data octet can assumethe following values:

Value Meaning

0 IGP - Network Layer Reachability Informationis interior to the originating AS

1 EGP - Network Layer Reachability Informationlearned via EGP

2 INCOMPLETE - Network Layer Reachability

Information learned by some other means

Its usage is defined in 5.1.1

b) AS_PATH (Type Code 2):

AS_PATH is a well-known mandatory attribute that is composedof a sequence of AS path segments. Each AS path segment isrepresented by a triple .



15/58


The path segment type is a 1-octet long field with thefollowing values defined:

Value Segment Type

1 AS_SET: unordered set of ASs a route in theUPDATE message has traversed

2 AS_SEQUENCE: ordered set of ASs a route inthe UPDATE message has traversed

The path segment length is a 1-octet long field containingthe number of ASs in the path segment value field.

The path segment value field contains one or more AS

numbers, each encoded as a 2-octets long field.

Usage of this attribute is defined in 5.1.2.

c) NEXT_HOP (Type Code 3):

This is a well-known mandatory attribute that defines the IPaddress of the border router that should be used as the nexthop to the destinations listed in the Network LayerReachability field of the UPDATE message.

Usage of this attribute is defined in 5.1.3.

d) MULTI_EXIT_DISC (Type Code 4):

This is an optional non-transitive attribute that is a fouroctet non-negative integer. The value of this attribute maybe used by a BGP speaker's decision process to discriminateamong multiple exit points to a neighboring autonomoussystem.

Its usage is defined in 5.1.4.

e) LOCAL_PREF (Type Code 5):

LOCAL_PREF is a well-known discretionary attribute that is afour octet non-negative integer. It is used by a BGP speakerto inform other BGP speakers in its own autonomous system ofthe originating speaker's degree of preference for anadvertised route. Usage of this attribute is described in5.1.5.



16/58


f) ATOMIC_AGGREGATE (Type Code 6)

ATOMIC_AGGREGATE is a well-known discretionary attribute of

length 0. It is used by a BGP speaker to inform other BGPspeakers that the local system selected a less specificroute without selecting a more specific route which isincluded in it. Usage of this attribute is described in5.1.6.

g) AGGREGATOR (Type Code 7)

AGGREGATOR is an optional transitive attribute of length 6.The attribute contains the last AS number that formed theaggregate route (encoded as 2 octets), followed by the IPaddress of the BGP speaker that formed the aggregate route

(encoded as 4 octets). Usage of this attribute is describedin 5.1.7

Network Layer Reachability Information:

This variable length field contains a list of IP addressprefixes. The length in octets of the Network LayerReachability Information is not encoded explicitly, but can becalculated as:

UPDATE message Length - 23 - Total Path Attributes Length -Unfeasible Routes Length

where UPDATE message Length is the value encoded in the fixed-size BGP header, Total Path Attribute Length and UnfeasibleRoutes Length are the values encoded in the variable part ofthe UPDATE message, and 23 is a combined length of the fixed-size BGP header, the Total Path Attribute Length field and theUnfeasible Routes Length field.

Reachability information is encoded as one or more 2-tuples ofthe form , whose fields are described below:

+---------------------------+ Length (1 octet) +---------------------------+ Prefix (variable) +---------------------------+



17/58


The use and the meaning of these fields are as follows:

a) Length:

The Length field indicates the length in bits of the IPaddress prefix. A length of zero indicates a prefix thatmatches all IP addresses (with prefix, itself, of zerooctets).

b) Prefix:

The Prefix field contains IP address prefixes followed byenough trailing bits to make the end of the field fall on anoctet boundary. Note that the value of the trailing bits isirrelevant.

The minimum length of the UPDATE message is 23 octets -- 19 octetsfor the fixed header + 2 octets for the Unfeasible Routes Length + 2octets for the Total Path Attribute Length (the value of UnfeasibleRoutes Length is 0 and the value of Total Path Attribute Length is0).

An UPDATE message can advertise at most one route, which may bedescribed by several path attributes. All path attributes containedin a given UPDATE messages apply to the destinations carried in theNetwork Layer Reachability Information field of the UPDATE message.

An UPDATE message can list multiple routes to be withdrawn from

service. Each such route is identified by its destination (expressedas an IP prefix), which unambiguously identifies the route in thecontext of the BGP speaker - BGP speaker connection to which it hasbeen previously been advertised.

An UPDATE message may advertise only routes to be withdrawn fromservice, in which case it will not include path attributes or NetworkLayer Reachability Information. Conversely, it may advertise only afeasible route, in which case the WITHDRAWN ROUTES field need not bepresent.

4.4 KEEPALIVE Message Format

BGP does not use any transport protocol-based keep-alive mechanism todetermine if peers are reachable. Instead, KEEPALIVE messages areexchanged between peers often enough as not to cause the Hold Timerto expire. A reasonable maximum time between KEEPALIVE messageswould be one third of the Hold Time interval. KEEPALIVE messagesMUST NOT be sent more frequently than one per second. Animplementation MAY adjust the rate at which it sends KEEPALIVE



18/58


messages as a function of the Hold Time interval.

If the negotiated Hold Time interval is zero, then periodic KEEPALIVE

messages MUST NOT be sent.

KEEPALIVE message consists of only message header and has a length of19 octets.

4.5 NOTIFICATION Message Format

A NOTIFICATION message is sent when an error condition is detected.The BGP connection is closed immediately after sending it.

In addition to the fixed-size BGP header, the NOTIFICATION messagecontains the following fields:

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error code Error subcode Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Error Code:

This 1-octet unsigned integer indicates the type ofNOTIFICATION. The following Error Codes have been defined:

Error Code Symbolic Name Reference

1 Message Header Error Section 6.1

2 OPEN Message Error Section 6.2

3 UPDATE Message Error Section 6.3

4 Hold Timer Expired Section 6.5

5 Finite State Machine Error Section 6.6

6 Cease Section 6.7

Error subcode:

This 1-octet unsigned integer provides more specificinformation about the nature of the reported error. Each ErrorCode may have one or more Error Subcodes associated with it.



19/58


If no appropriate Error Subcode is defined, then a zero(Unspecific) value is used for the Error Subcode field.

Message Header Error subcodes:

1 - Connection Not Synchronized.2 - Bad Message Length.3 - Bad Message Type.

OPEN Message Error subcodes:

1 - Unsupported Version Number.2 - Bad Peer AS.3 - Bad BGP Identifier. '

4 - Unsupported Optional Parameter.

5 - Authentication Failure.6 - Unacceptable Hold Time.

UPDATE Message Error subcodes:

1 - Malformed Attribute List.2 - Unrecognized Well-known Attribute.3 - Missing Well-known Attribute.4 - Attribute Flags Error.5 - Attribute Length Error.6 - Invalid ORIGIN Attribute7 - AS Routing Loop.8 - Invalid NEXT_HOP Attribute.

9 - Optional Attribute Error.10 - Invalid Network Field.11 - Malformed AS_PATH.

Data:

This variable-length field is used to diagnose the reason forthe NOTIFICATION. The contents of the Data field depend uponthe Error Code and Error Subcode. See Section 6 below for moredetails.

Note that the length of the Data field can be determined fromthe message Length field by the formula:

Message Length = 21 + Data Length

The minimum length of the NOTIFICATION message is 21 octets(including message header).



20/58


5. Path Attributes

This section discusses the path attributes of the UPDATE message.

Path attributes fall into four separate categories:

1. Well-known mandatory.2. Well-known discretionary.3. Optional transitive.4. Optional non-transitive.

Well-known attributes must be recognized by all BGP implementations.Some of these attributes are mandatory and must be included in everyUPDATE message. Others are discretionary and may or may not be sentin a particular UPDATE message.

All well-known attributes must be passed along (after properupdating, if necessary) to other BGP peers.

In addition to well-known attributes, each path may contain one ormore optional attributes. It is not required or expected that allBGP implementations support all optional attributes. The handling ofan unrecognized optional attribute is determined by the setting ofthe Transitive bit in the attribute flags octet. Paths withunrecognized transitive optional attributes should be accepted. If apath with unrecognized transitive optional attribute is accepted andpassed along to other BGP peers, then the unrecognized transitiveoptional attribute of that path must be passed along with the path to

other BGP peers with the Partial bit in the Attribute Flags octet setto 1. If a path with recognized transitive optional attribute isaccepted and passed along to other BGP peers and the Partial bit inthe Attribute Flags octet is set to 1 by some previous AS, it is notset back to 0 by the current AS. Unrecognized non-transitive optionalattributes must be quietly ignored and not passed along to other BGPpeers.

New transitive optional attributes may be attached to the path by theoriginator or by any other AS in the path. If they are not attachedby the originator, the Partial bit in the Attribute Flags octet isset to 1. The rules for attaching new non-transitive optionalattributes will depend on the nature of the specific attribute. Thedocumentation of each new non-transitive optional attribute will beexpected to include such rules. (The description of theMULTI_EXIT_DISC attribute gives an example.) All optional attributes(both transitive and non-transitive) may be updated (if appropriate)by ASs in the path.



21/58


The sender of an UPDATE message should order path attributes withinthe UPDATE message in ascending order of attribute type. Thereceiver of an UPDATE message must be prepared to handle path

attributes within the UPDATE message that are out of order.

The same attribute cannot appear more than once within the PathAttributes field of a particular UPDATE message.

5.1 Path Attribute Usage

The usage of each BGP path attributes is described in the followingclauses.

5.1.1 ORIGIN

ORIGIN is a well-known mandatory attribute. The ORIGIN attributeshall be generated by the autonomous system that originates theassociated routing information. It shall be included in the UPDATEmessages of all BGP speakers that choose to propagate thisinformation to other BGP speakers.

5.1.2 AS_PATH

AS_PATH is a well-known mandatory attribute. This attributeidentifies the autonomous systems through which routing informationcarried in this UPDATE message has passed. The components of thislist can be AS_SETs or AS_SEQUENCEs.

When a BGP speaker propagates a route which it has learned fromanother BGP speaker's UPDATE message, it shall modify the route'sAS_PATH attribute based on the location of the BGP speaker to whichthe route will be sent:

a) When a given BGP speaker advertises the route to another BGPspeaker located in its own autonomous system, the advertisingspeaker shall not modify the AS_PATH attribute associated with theroute.

b) When a given BGP speaker advertises the route to a BGP speakerlocated in a neighboring autonomous system, then the advertisingspeaker shall update the AS_PATH attribute as follows:

1) if the first path segment of the AS_PATH is of typeAS_SEQUENCE, the local system shall prepend its own AS numberas the last element of the sequence (put it in the leftmostposition).



22/58


2) if the first path segment of the AS_PATH is of type AS_SET,the local system shall prepend a new path segment of typeAS_SEQUENCE to the AS_PATH, including its own AS number in that

segment.

When a BGP speaker originates a route then:

a) the originating speaker shall include its own AS number inthe AS_PATH attribute of all UPDATE messages sent to BGPspeakers located in neighboring autonomous systems. (In thiscase, the AS number of the originating speaker's autonomoussystem will be the only entry in the AS_PATH attribute).

b) the originating speaker shall include an empty AS_PATHattribute in all UPDATE messages sent to BGP speakers located

in its own autonomous system. (An empty AS_PATH attribute isone whose length field contains the value zero).

5.1.3 NEXT_HOP

The NEXT_HOP path attribute defines the IP address of the borderrouter that should be used as the next hop to the destinations listedin the UPDATE message. If a border router belongs to the same AS asits peer, then the peer is an internal border router. Otherwise, itis an external border router. A BGP speaker can advertise anyinternal border router as the next hop provided that the interfaceassociated with the IP address of this border router (as specified inthe NEXT_HOP path attribute) shares a common subnet with both the

local and remote BGP speakers. A BGP speaker can advertise anyexternal border router as the next hop, provided that the IP addressof this border router was learned from one of the BGP speaker'speers, and the interface associated with the IP address of thisborder router (as specified in the NEXT_HOP path attribute) shares acommon subnet with the local and remote BGP speakers. A BGP speakerneeds to be able to support disabling advertisement of externalborder routers.

A BGP speaker must never advertise an address of a peer to that peeras a NEXT_HOP, for a route that the speaker is originating. A BGPspeaker must never install a route with itself as the next hop.

When a BGP speaker advertises the route to a BGP speaker located inits own autonomous system, the advertising speaker shall not modifythe NEXT_HOP attribute associated with the route. When a BGP speakerreceives the route via an internal link, it may forward packets tothe NEXT_HOP address if the address contained in the attribute is ona common subnet with the local and remote BGP speakers.



23/58


5.1.4 MULTI_EXIT_DISC

The MULTI_EXIT_DISC attribute may be used on external (inter-AS)

links to discriminate among multiple exit or entry points to the sameneighboring AS. The value of the MULTI_EXIT_DISC attribute is a fouroctet unsigned number which is called a metric. All other factorsbeing equal, the exit or entry point with lower metric should bepreferred. If received over external links, the MULTI_EXIT_DISCattribute may be propagated over internal links to other BGP speakerswithin the same AS. The MULTI_EXIT_DISC attribute is neverpropagated to other BGP speakers in neighboring AS's.

5.1.5 LOCAL_PREF

LOCAL_PREF is a well-known discretionary attribute that shall be

included in all UPDATE messages that a given BGP speaker sends to theother BGP speakers located in its own autonomous system. A BGPspeaker shall calculate the degree of preference for each externalroute and include the degree of preference when advertising a routeto its internal peers. The higher degree of preference should bepreferred. A BGP speaker shall use the degree of preference learnedvia LOCAL_PREF in its decision process (see section 9.1.1).

A BGP speaker shall not include this attribute in UPDATE messagesthat it sends to BGP speakers located in a neighboring autonomoussystem. If it is contained in an UPDATE message that is received froma BGP speaker which is not located in the same autonomous system asthe receiving speaker, then this attribute shall be ignored by the

receiving speaker.

5.1.6 ATOMIC_AGGREGATE

ATOMIC_AGGREGATE is a well-known discretionary attribute. If a BGPspeaker, when presented with a set of overlapping routes from one ofits peers (see 9.1.4), selects the less specific route withoutselecting the more specific one, then the local system shall attachthe ATOMIC_AGGREGATE attribute to the route when propagating it toother BGP speakers (if that attribute is not already present in thereceived less specific route). A BGP speaker that receives a routewith the ATOMIC_AGGREGATE attribute shall not remove the attributefrom the route when propagating it to other speakers. A BGP speakerthat receives a route with the ATOMIC_AGGREGATE attribute shall notmake any NLRI of that route more specific (as defined in 9.1.4) whenadvertising this route to other BGP speakers. A BGP speaker thatreceives a route with the ATOMIC_AGGREGATE attribute needs to becognizant of the fact that the actual path to destinations, asspecified in the NLRI of the route, while having the loop-freeproperty, may traverse ASs that are not listed in the AS_PATH



24/58


attribute.

5.1.7 AGGREGATOR

AGGREGATOR is an optional transitive attribute which may be includedin updates which are formed by aggregation (see Section 9.2.4.2). ABGP speaker which performs route aggregation may add the AGGREGATORattribute which shall contain its own AS number and IP address.

6. BGP Error Handling.

This section describes actions to be taken when errors are detectedwhile processing BGP messages.

When any of the conditions described here are detected, a

NOTIFICATION message with the indicated Error Code, Error Subcode,and Data fields is sent, and the BGP connection is closed. If noError Subcode is specified, then a zero must be used.

The phrase "the BGP connection is closed" means that the transportprotocol connection has been closed and that all resources for thatBGP connection have been deallocated. Routing table entriesassociated with the remote peer are marked as invalid. The fact thatthe routes have become invalid is passed to other BGP peers beforethe routes are deleted from the system.

Unless specified explicitly, the Data field of the NOTIFICATIONmessage that is sent to indicate an error is empty.

6.1 Message Header error handling.

All errors detected while processing the Message Header are indicatedby sending the NOTIFICATION message with Error Code Message HeaderError. The Error Subcode elaborates on the specific nature of theerror.

The expected value of the Marker field of the message header is allones if the message type is OPEN. The expected value of the Markerfield for all other types of BGP messages determined based on thepresence of the Authentication Information Optional Parameter in theBGP OPEN message and the actual authentication mechanism (if theAuthentication Information in the BGP OPEN message is present). Ifthe Marker field of the message header is not the expected one, thena synchronization error has occurred and the Error Subcode is set toConnection Not Synchronized.



25/58


If the Length field of the message header is less than 19 or greaterthan 4096, or if the Length field of an OPEN message is less thanthe minimum length of the OPEN message, or if the Length field of an

UPDATE message is less than the minimum length of the UPDATE message,or if the Length field of a KEEPALIVE message is not equal to 19, orif the Length field of a NOTIFICATION message is less than theminimum length of the NOTIFICATION message, then the Error Subcode isset to Bad Message Length. The Data field contains the erroneousLength field.

If the Type field of the message header is not recognized, then theError Subcode is set to Bad Message Type. The Data field containsthe erroneous Type field.

6.2 OPEN message error handling.

All errors detected while processing the OPEN message are indicatedby sending the NOTIFICATION message with Error Code OPEN MessageError. The Error Subcode elaborates on the specific nature of theerror.

If the version number contained in the Version field of the receivedOPEN message is not supported, then the Error Subcode is set toUnsupported Version Number. The Data field is a 2-octet unsignedinteger, which indicates the largest locally supported version numberless than the version the remote BGP peer bid (as indicated in thereceived OPEN message).

If the Autonomous System field of the OPEN message is unacceptable,then the Error Subcode is set to Bad Peer AS. The determination ofacceptable Autonomous System numbers is outside the scope of thisprotocol.

If the Hold Time field of the OPEN message is unacceptable, then theError Subcode MUST be set to Unacceptable Hold Time. Animplementation MUST reject Hold Time values of one or two seconds.An implementation MAY reject any proposed Hold Time. Animplementation which accepts a Hold Time MUST use the negotiatedvalue for the Hold Time.

If the BGP Identifier field of the OPEN message is syntacticallyincorrect, then the Error Subcode is set to Bad BGP Identifier.Syntactic correctness means that the BGP Identifier field representsa valid IP host address.

If one of the Optional Parameters in the OPEN message is notrecognized, then the Error Subcode is set to Unsupported OptionalParameters.



26/58


If the OPEN message carries Authentication Information (as anOptional Parameter), then the corresponding authentication procedureis invoked. If the authentication procedure (based on Authentication

Code and Authentication Data) fails, then the Error Subcode is set toAuthentication Failure.

6.3 UPDATE message error handling.

All errors detected while processing the UPDATE message are indicatedby sending the NOTIFICATION message with Error Code UPDATE MessageError. The error subcode elaborates on the specific nature of theerror.

Error checking of an UPDATE message begins by examining the pathattributes. If the Unfeasible Routes Length or Total Attribute

Length is too large (i.e., if Unfeasible Routes Length + TotalAttribute Length + 23 exceeds the message Length), then the ErrorSubcode is set to Malformed Attribute List.

If any recognized attribute has Attribute Flags that conflict withthe Attribute Type Code, then the Error Subcode is set to AttributeFlags Error. The Data field contains the erroneous attribute (type,length and value).

If any recognized attribute has Attribute Length that conflicts withthe expected length (based on the attribute type code), then theError Subcode is set to Attribute Length Error. The Data fieldcontains the erroneous attribute (type, length and value).

If any of the mandatory well-known attributes are not present, thenthe Error Subcode is set to Missing Well-known Attribute. The Datafield contains the Attribute Type Code of the missing well-knownattribute.

If any of the mandatory well-known attributes are not recognized,then the Error Subcode is set to Unrecognized Well-known Attribute.The Data field contains the unrecognized attribute (type, length andvalue).

If the ORIGIN attribute has an undefined value, then the ErrorSubcode is set to Invalid Origin Attribute. The Data field containsthe unrecognized attribute (type, length and value).

If the NEXT_HOP attribute field is syntactically incorrect, then theError Subcode is set to Invalid NEXT_HOP Attribute. The Data fieldcontains the incorrect attribute (type, length and value). Syntacticcorrectness means that the NEXT_HOP attribute represents a valid IPhost address. Semantic correctness applies only to the external BGP



27/58


links. It means that the interface associated with the IP address, asspecified in the NEXT_HOP attribute, shares a common subnet with thereceiving BGP speaker and is not the IP address of the receiving BGP

speaker. If the NEXT_HOP attribute is semantically incorrect, theerror should be logged, and the the route should be ignored. In thiscase, no NOTIFICATION message should be sent.

The AS_PATH attribute is checked for syntactic correctness. If thepath is syntactically incorrect, then the Error Subcode is set toMalformed AS_PATH.

If an optional attribute is recognized, then the value of thisattribute is checked. If an error is detected, the attribute isdiscarded, and the Error Subcode is set to Optional Attribute Error.The Data field contains the attribute (type, length and value).

If any attribute appears more than once in the UPDATE message, thenthe Error Subcode is set to Malformed Attribute List.

The NLRI field in the UPDATE message is checked for syntacticvalidity. If the field is syntactically incorrect, then the ErrorSubcode is set to Invalid Network Field.

6.4 NOTIFICATION message error handling.

If a peer sends a NOTIFICATION message, and there is an error in thatmessage, there is unfortunately no means of reporting this error viaa subsequent NOTIFICATION message. Any such error, such as an

unrecognized Error Code or Error Subcode, should be noticed, loggedlocally, and brought to the attention of the administration of thepeer. The means to do this, however, lies outside the scope of thisdocument.

6.5 Hold Timer Expired error handling.

If a system does not receive successive KEEPALIVE and/or UPDATEand/or NOTIFICATION messages within the period specified in the HoldTime field of the OPEN message, then the NOTIFICATION message withHold Timer Expired Error Code must be sent and the BGP connectionclosed.

6.6 Finite State Machine error handling.

Any error detected by the BGP Finite State Machine (e.g., receipt ofan unexpected event) is indicated by sending the NOTIFICATION messagewith Error Code Finite State Machine Error.



28/58


6.7 Cease.

In absence of any fatal errors (that are indicated in this section),

a BGP peer may choose at any given time to close its BGP connectionby sending the NOTIFICATION message with Error Code Cease. However,the Cease NOTIFICATION message must not be used when a fatal errorindicated by this section does exist.

6.8 Connection collision detection.

If a pair of BGP speakers try simultaneously to establish a TCPconnection to each other, then two parallel connections between thispair of speakers might well be formed. We refer to this situation asconnection collision. Clearly, one of these connections must beclosed.

Based on the value of the BGP Identifier a convention is establishedfor detecting which BGP connection is to be preserved when acollision does occur. The convention is to compare the BGPIdentifiers of the peers involved in the collision and to retain onlythe connection initiated by the BGP speaker with the higher-valuedBGP Identifier.

Upon receipt of an OPEN message, the local system must examine all ofits connections that are in the OpenConfirm state. A BGP speaker mayalso examine connections in an OpenSent state if it knows the BGPIdentifier of the peer by means outside of the protocol. If amongthese connections there is a connection to a remote BGP speaker whose

BGP Identifier equals the one in the OPEN message, then the localsystem performs the following collision resolution procedure:

1. The BGP Identifier of the local system is compared to the BGPIdentifier of the remote system (as specified in the OPENmessage).

2. If the value of the local BGP Identifier is less than theremote one, the local system closes BGP connection that alreadyexists (the one that is already in the OpenConfirm state), andaccepts BGP connection initiated by the remote system.

3. Otherwise, the local system closes newly created BGP connection(the one associated with the newly received OPEN message), andcontinues to use the existing one (the one that is already in theOpenConfirm state).

Comparing BGP Identifiers is done by treating them as (4-octetlong) unsigned integers.



29/58


A connection collision with an existing BGP connection that is inEstablished states causes unconditional closing of the newlycreated connection. Note that a connection collision cannot be

detected with connections that are in Idle, or Connect, or Activestates.

Closing the BGP connection (that results from the collisionresolution procedure) is accomplished by sending the NOTIFICATIONmessage with the Error Code Cease.

7. BGP Version Negotiation.

BGP speakers may negotiate the version of the protocol by makingmultiple attempts to open a BGP connection, starting with the highestversion number each supports. If an open attempt fails with an Error

Code OPEN Message Error, and an Error Subcode Unsupported VersionNumber, then the BGP speaker has available the version number ittried, the version number its peer tried, the version number passedby its peer in the NOTIFICATION message, and the version numbers thatit supports. If the two peers do support one or more commonversions, then this will allow them to rapidly determine the highestcommon version. In order to support BGP version negotiation, futureversions of BGP must retain the format of the OPEN and NOTIFICATIONmessages.

8. BGP Finite State machine.

This section specifies BGP operation in terms of a Finite State

Machine (FSM). Following is a brief summary and overview of BGPoperations by state as determined by this FSM. A condensed versionof the BGP FSM is found in Appendix 1.

Initially BGP is in the Idle state.

Idle state:

In this state BGP refuses all incoming BGP connections. Noresources are allocated to the peer. In response to the Startevent (initiated by either system or operator) the local systeminitializes all BGP resources, starts the ConnectRetry timer,initiates a transport connection to other BGP peer, whilelistening for connection that may be initiated by the remoteBGP peer, and changes its state to Connect. The exact value ofthe ConnectRetry timer is a local matter, but should besufficiently large to allow TCP initialization.

If a BGP speaker detects an error, it shuts down the connectionand changes its state to Idle. Getting out of the Idle state



30/58


requires generation of the Start event. If such an event isgenerated automatically, then persistent BGP errors may resultin persistent flapping of the speaker. To avoid such a

condition it is recommended that Start events should not begenerated immediately for a peer that was previouslytransitioned to Idle due to an error. For a peer that waspreviously transitioned to Idle due to an error, the timebetween consecutive generation of Start events, if such eventsare generated automatically, shall exponentially increase. Thevalue of the initial timer shall be 60 seconds. The time shallbe doubled for each consecutive retry.

Any other event received in the Idle state is ignored.

Connect state:

In this state BGP is waiting for the transport protocolconnection to be completed.

If the transport protocol connection succeeds, the local systemclears the ConnectRetry timer, completes initialization, sendsan OPEN message to its peer, and changes its state to OpenSent.

If the transport protocol connect fails (e.g., retransmissiontimeout), the local system restarts the ConnectRetry timer,continues to listen for a connection that may be initiated bythe remote BGP peer, and changes its state to Active state.

In response to the ConnectRetry timer expired event, the localsystem restarts the ConnectRetry timer, initiates a transportconnection to other BGP peer, continues to listen for aconnection that may be initiated by the remote BGP peer, andstays in the Connect state.

Start event is ignored in the Active state.

In response to any other event (initiated by either system oroperator), the local system releases all BGP resourcesassociated with this connection and changes its state to Idle.

Active state:

In this state BGP is trying to acquire a peer by initiating atransport protocol connection.

If the transport protocol connection succeeds, the local systemclears the ConnectRetry timer, completes initialization, sendsan OPEN message to its peer, sets its Hold Timer to a large



31/58


value, and changes its state to OpenSent. A Hold Timer valueof 4 minutes is suggested.

In response to the ConnectRetry timer expired event, the localsystem restarts the ConnectRetry timer, initiates a transportconnection to other BGP peer, continues to listen for aconnection that may be initiated by the remote BGP peer, andchanges its state to Connect.

If the local system detects that a remote peer is trying toestablish BGP connection to it, and the IP address of theremote peer is not an expected one, the local system restartsthe ConnectRetry timer, rejects the attempted connection,continues to listen for a connection that may be initiated bythe remote BGP peer, and stays in the Active state.

Start event is ignored in the Active state.

In response to any other event (initiated by either system oroperator), the local system releases all BGP resourcesassociated with this connection and changes its state to Idle.

OpenSent state:

In this state BGP waits for an OPEN message from its peer.When an OPEN message is received, all fields are checked forcorrectness. If the BGP message header checking or OPENmessage checking detects an error (see Section 6.2), or a

connection collision (see Section 6.8) the local system sends aNOTIFICATION message and changes its state to Idle.

If there are no errors in the OPEN message, BGP sends aKEEPALIVE message and sets a KeepAlive timer. The Hold Timer,which was originally set to a large value (see above), isreplaced with the negotiated Hold Time value (see section 4.2).If the negotiated Hold Time value is zero, then the Hold Timetimer and KeepAlive timers are not started. If the value ofthe Autonomous System field is the same as the local AutonomousSystem number, then the connection is an "internal" connection;otherwise, it is "external". (This will effect UPDATEprocessing as described below.) Finally, the state is changedto OpenConfirm.

If a disconnect notification is received from the underlyingtransport protocol, the local system closes the BGP connection,restarts the ConnectRetry timer, while continue listening forconnection that may be initiated by the remote BGP peer, andgoes into the Active state.



32/58


If the Hold Timer expires, the local system sends NOTIFICATIONmessage with error code Hold Timer Expired and changes itsstate to Idle.

In response to the Stop event (initiated by either system oroperator) the local system sends NOTIFICATION message withError Code Cease and changes its state to Idle.

Start event is ignored in the OpenSent state.

In response to any other event the local system sendsNOTIFICATION message with Error Code Finite State Machine Errorand changes its state to Idle.

Whenever BGP changes its state from OpenSent to Idle, it closes

the BGP (and transport-level) connection and releases allresources associated with that connection.

OpenConfirm state:

In this state BGP waits for a KEEPALIVE or NOTIFICATIONmessage.

If the local system receives a KEEPALIVE message, it changesits state to Established.

If the Hold Timer expires before a KEEPALIVE message isreceived, the local system sends NOTIFICATION message with

error code Hold Timer Expired and changes its state to Idle.

If the local system receives a NOTIFICATION message, it changesits state to Idle.

If the KeepAlive timer expires, the local system sends aKEEPALIVE message and restarts its KeepAlive timer.

If a disconnect notification is received from the underlyingtransport protocol, the local system changes its state to Idle.

In response to the Stop event (initiated by either system oroperator) the local system sends NOTIFICATION message withError Code Cease and changes its state to Idle.

Start event is ignored in the OpenConfirm state.

In response to any other event the local system sendsNOTIFICATION message with Error Code Finite State Machine Errorand changes its state to Idle.



33/58


Whenever BGP changes its state from OpenConfirm to Idle, itcloses the BGP (and transport-level) connection and releasesall resources associated with that connection.

Established state:

In the Established state BGP can exchange UPDATE, NOTIFICATION,and KEEPALIVE messages with its peer.

If the local system receives an UPDATE or KEEPALIVE message, itrestarts its Hold Timer, if the negotiated Hold Time value isnon-zero.

If the local system receives a NOTIFICATION message, it changesits state to Idle.

If the local system receives an UPDATE message and the UPDATEmessage error handling procedure (see Section 6.3) detects anerror, the local system sends a NOTIFICATION message andchanges its state to Idle.

If a disconnect notification is received from the underlyingtransport protocol, the local system changes its state to Idle.

If the Hold Timer expires, the local system sends aNOTIFICATION message with Error Code Hold Timer Expired andchanges its state to Idle.

If the KeepAlive timer expires, the local system sends aKEEPALIVE message and restarts its KeepAlive timer.

Each time the local system sends a KEEPALIVE or UPDATE message,it restarts its KeepAlive timer, unless the negotiated HoldTime value is zero.

In response to the Stop event (initiated by either system oroperator), the local system sends a NOTIFICATION message withError Code Cease and changes its state to Idle.

Start event is ignored in the Established state.

In response to any other event, the local system sendsNOTIFICATION message with Error Code Finite State Machine Errorand changes its state to Idle.

Whenever BGP changes its state from Established to Idle, itcloses the BGP (and transport-level) connection, releases allresources associated with that connection, and deletes all



34/58


routes derived from that connection.

9. UPDATE Message Handling

An UPDATE message may be received only in the Established state.When an UPDATE message is received, each field is checked forvalidity as specified in Section 6.3.

If an optional non-transitive attribute is unrecognized, it isquietly ignored. If an optional transitive attribute isunrecognized, the Partial bit (the third high-order bit) in theattribute flags octet is set to 1, and the attribute is retained forpropagation to other BGP speakers.

If an optional attribute is recognized, and has a valid value, then,

depending on the type of the optional attribute, it is processedlocally, retained, and updated, if necessary, for possiblepropagation to other BGP speakers.

If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,the previously advertised routes whose destinations (expressed as IPprefixes) contained in this field shall be removed from the Adj-RIB-In. This BGP speaker shall run its Decision Process since thepreviously advertised route is not longer available for use.

If the UPDATE message contains a feasible route, it shall be placedin the appropriate Adj-RIB-In, and the following additional actionsshall be taken:

i) If its Network Layer Reachability Information (NLRI) is identicalto the one of a route currently stored in the Adj-RIB-In, then thenew route shall replace the older route in the Adj-RIB-In, thusimplicitly withdrawing the older route from service. The BGP speakershall run its Decision Process since the older route is no longeravailable for use.

ii) If the new route is an overlapping route that is included (see9.1.4) in an earlier route contained in the Adj-RIB-In, the BGPspeaker shall run its Decision Process since the more specific routehas implicitly made a portion of the less specific route unavailablefor use.

iii) If the new route has identical path attributes to an earlierroute contained in the Adj-RIB-In, and is more specific (see 9.1.4)than the earlier route, no further actions are necessary.

iv) If the new route has NLRI that is not present in any of theroutes currently stored in the Adj-RIB-In, then the new route shall



35/58


be placed in the Adj-RIB-In. The BGP speaker shall run its DecisionProcess.

v) If the new route is an overlapping route that is less specific(see 9.1.4) than an earlier route contained in the Adj-RIB-In, theBGP speaker shall run its Decision Process on the set of destinationsdescribed only by the less specific route.

9.1 Decision Process

The Decision Process selects routes for subsequent advertisement byapplying the policies in the local Policy Information Base (PIB) tothe routes stored in its Adj-RIB-In. The output of the DecisionProcess is the set of routes that will be advertised to all peers;the selected routes will be stored in the local speaker's Adj-RIB-

Out.

The selection process is formalized by defining a function that takesthe attribute of a given route as an argument and returns a non-negative integer denoting the degree of preference for the route.The function that calculates the degree of preference for a givenroute shall not use as its inputs any of the following: theexistence of other routes, the non-existence of other routes, or thepath attributes of other routes. Route selection then consists ofindividual application of the degree of preference function to eachfeasible route, followed by the choice of the one with the highestdegree of preference.

The Decision Process operates on routes contained in each Adj-RIB-In,and is responsible for:

- selection of routes to be advertised to BGP speakers located inthe local speaker's autonomous system

- selection of routes to be advertised to BGP speakers located inneighboring autonomous systems

- route aggregation and route information reduction

The Decision Process takes place in three distinct phases, eachtriggered by a different event:

a) Phase 1 is responsible for calculating the degree of preferencefor each route received from a BGP speaker located in aneighboring autonomous system, and for advertising to the otherBGP speakers in the local autonomous system the routes that havethe highest degree of preference for each distinct destination.



36/58


b) Phase 2 is invoked on completion of phase 1. It is responsiblefor choosing the best route out of all those available for eachdistinct destination, and for installing each chosen route into

the appropriate Loc-RIB.

c) Phase 3 is invoked after the Loc-RIB has been modified. It isresponsible for disseminating routes in the Loc-RIB to each peerlocated in a neighboring autonomous system, according to thepolicies contained in the PIB. Route aggregation and informationreduction can optionally be performed within this phase.

9.1.1 Phase 1: Calculation of Degree of Preference

The Phase 1 decision function shall be invoked whenever the local BGPspeaker receives an UPDATE message from a peer located in a

neighboring autonomous system that advertises a new route, areplacement route, or a withdrawn route.

The Phase 1 decision function is a separate process which completeswhen it has no further work to do.

The Phase 1 decision function shall lock an Adj-RIB-In prior tooperating on any route contained within it, and shall unlock it afteroperating on all new or unfeasible routes contained within it.

For each newly received or replacement feasible route, the local BGPspeaker shall determine a degree of preference. If the route islearned from a BGP speaker in the local autonomous system, either the

value of the LOCAL_PREF attribute shall be taken as the degree ofpreference, or the local system shall compute the degree ofpreference of the route based on preconfigured policy information. Ifthe route is learned from a BGP speaker in a neighboring autonomoussystem, then the degree of preference shall be computed based onpreconfigured policy information. The exact nature of this policyinformation and the computation involved is a local matter. Thelocal speaker shall then run the internal update process of 9.2.1 toselect and advertise the most preferable route.

9.1.2 Phase 2: Route Selection

The Phase 2 decision function shall be invoked on completion of Phase1. The Phase 2 function is a separate process which completes whenit has no further work to do. The Phase 2 process shall consider allroutes that are present in the Adj-RIBs-In, including those receivedfrom BGP speakers located in its own autonomous system and thosereceived from BGP speakers located in neighboring autonomous systems.



37/58


The Phase 2 decision function shall be blocked from running while thePhase 3 decision function is in process. The Phase 2 function shalllock all Adj-RIBs-In prior to commencing its function, and shall

unlock them on completion.

If the NEXT_HOP attribute of a BGP route depicts an address to whichthe local BGP speaker doesn't have a route in its Loc-RIB, the BGProute SHOULD be excluded from the Phase 2 decision function.

For each set of destinations for which a feasible route exists in theAdj-RIBs-In, the local BGP speaker shall identify the route that has:

a) the highest degree of preference of any route to the same setof destinations, or

b) is the only route to that destination, or

c) is selected as a result of the Phase 2 tie breaking rulesspecified in 9.1.2.1.

The local speaker SHALL then install that route in the Loc-RIB,replacing any route to the same destination that is currently beingheld in the Loc-RIB. The local speaker MUST determine the immediatenext hop to the address depicted by the NEXT_HOP attribute of theselected route by performing a lookup in the IGP and selecting one ofthe possible paths in the IGP. This immediate next hop MUST be usedwhen installing the selected route in the Loc-RIB. If the route tothe address depicted by the NEXT_HOP attribute changes such that the

immediate next hop changes, route selection should be recalculated asspecified above.

Unfeasible routes shall be removed from the Loc-RIB, andcorresponding unfeasible routes shall then be removed from the Adj-RIBs-In.

9.1.2.1 Breaking Ties (Phase 2)

In its Adj-RIBs-In a BGP speaker may have several routes to the samedestination that have the same degree of preference. The localspeaker can select only one of these routes for inclusion in theassociated Loc-RIB. The local speaker considers all equallypreferable routes, both those received from BGP speakers located inneighboring autonomous systems, and those received from other BGPspeakers located in the local speaker's autonomous system.

The following tie-breaking procedure assumes that for each candidateroute all the BGP speakers within an autonomous system can ascertainthe cost of a path (interior distance) to the address depicted by the



38/58


NEXT_HOP attribute of the route. Ties shall be broken according tothe following algorithm:

a) If the local system is configured to take into accountMULTI_EXIT_DISC, and the candidate routes differ in theirMULTI_EXIT_DISC attribute, select the route that has the lowestvalue of the MULTI_EXIT_DISC attribute.

b) Otherwise, select the route that has the lowest cost (interiordistance) to the entity depicted by the NEXT_HOP attribute of theroute. If there are several routes with the same cost, then thetie-breaking shall be broken as follows:

- if at least one of the candidate routes was advertised by theBGP speaker in a neighboring autonomous system, select the

route that was advertised by the BGP speaker in a neighboringautonomous system whose BGP Identifier has the lowest valueamong all other BGP speakers in neighboring autonomous systems;

- otherwise, select the route that was advertised by the BGPspeaker whose BGP Identifier has the lowest value.

9.1.3 Phase 3: Route Dissemination

The Phase 3 decision function shall be invoked on completion of Phase2, or when any of the following events occur:

a) when routes in a Loc-RIB to local destinations have changed

b) when locally generated routes learned by means outside of BGPhave changed

c) when a new BGP speaker - BGP speaker connection has beenestablished

The Phase 3 function is a separate process which completes when ithas no further work to do. The Phase 3 Routing Decision functionshall be blocked from running while the Phase 2 decision function isin process.

All routes in the Loc-RIB shall be processed into a correspondingentry in the associated Adj-RIBs-Out. Route aggregation andinformation reduction techniques (see 9.2.4.1) may optionally beapplied.

For the benefit of future support of inter-AS multicast capabilities,a BGP speaker that participates in inter-AS multicast routing shalladvertise a route it receives from one of its external peers and if



39/58


it installs it in its Loc-RIB, it shall advertise it back to the peerfrom which the route was received. For a BGP speaker that does notparticipate in inter-AS multicast routing such an advertisement is

optional. When doing such an advertisement, the NEXT_HOP attributeshould be set to the address of the peer. An implementation may alsooptimize such an advertisement by truncating information in theAS_PATH attribute to include only its own AS number and that of thepeer that advertised the route (such truncation requires the ORIGINattribute to be set to INCOMPLETE). In addition an implementation isnot required to pass optional or discretionary path attributes withsuch an advertisement.

When the updating of the Adj-RIBs-Out and the Forwarding InformationBase (FIB) is complete, the local BGP speaker shall run the externalupdate process of 9.2.2.

9.1.4 Overlapping Routes

A BGP speaker may transmit routes with overlapping Network LayerReachability Information (NLRI) to another BGP speaker. NLRI overlapoccurs when a set of destinations are identified in non-matchingmultiple routes. Since BGP encodes NLRI using IP prefixes, overlapwill always exhibit subset relationships. A route describing asmaller set of destinations (a longer prefix) is said to be morespecific than a route describing a larger set of destinations (ashorted prefix); similarly, a route describing a larger set ofdestinations (a shorter prefix) is said to be less specific than aroute describing a smaller set of destinations (a longer prefix).

The precedence relationship effectively decomposes less specificroutes into two parts:

- a set of destinations described only by the less specificroute, and

- a set of destinations described by the overlap of the lessspecific and the more specific routes

When overlapping routes are present in the same Adj-RIB-In, the morespecific route shall take precedence, in order from more specific toleast specific.

The set of destinations described by the overlap represents a portionof the less specific route that is feasible, but is not currently inuse. If a more specific route is later withdrawn, the set ofdestinations described by the overlap will still be reachable usingthe less specific route.



40/58


If a BGP speaker receives overlapping routes, the Decision Processshall take into account the semantics of the overlapping routes. Inparticular, if a BGP speaker accepts the less specific route while

rejecting the more specific route from the same peer, then thedestinations represented by the overlap may not forward along the ASslisted in the AS_PATH attribute of that route. Therefore, a BGPspeaker has the following choices:

a) Install both the less and the more specific routes

b) Install the more specific route only

c) Install the non-overlapping part of the less specificroute only (that implies de-aggregation)

d) Aggregate the two routes and install the aggregated route

e) Install the less specific route only

f) Install neither route

If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATEattribute to the route. A route that carries ATOMIC_AGGREGATEattribute can not be de-aggregated. That is, the NLRI of this routecan not be made more specific. Forwarding along such a route doesnot guarantee that IP packets will actually traverse only ASs listedin the AS_PATH attribute of the route. If a BGP speaker chooses a),it must not advertise the more general route without the more

specific route.

9.2 Update-Send Process

The Update-Send process is responsible for advertising UPDATEmessages to all peers. For example, it distributes the routes chosenby the Decision Process to other BGP speakers which may be located ineither the same autonomous system or a neighboring autonomous system.rules for information exchange between BGP speakers located indifferent autonomous systems are given in 9.2.2; rules forinformation exchange between BGP speakers located in the sameautonomous system are given in 9.2.1.

Distribution of routing information between a set of BGP speakers,all of which are located in the same autonomous system, is referredto as internal distribution.



41/58


9.2.1 Internal Updates

The Internal update process is concerned with the distribution of

routing information to BGP speakers located in the local speaker'sautonomous system.

When a BGP speaker receives an UPDATE message from another BGPspeaker located in its own autonomous system, the receiving BGPspeaker shall not re-distribute the routing information contained inthat UPDATE message to other BGP speakers located in its ownautonomous system.

When a BGP speaker receives a new route from a BGP speaker in aneighboring autonomous system, it shall advertise that route to allother BGP speakers in its autonomous system by means of an UPDATE

message if any of the following conditions occur:

1) the degree of preference assigned to the newly received routeby the local BGP speaker is higher than the degree of preferencethat the local speaker has assigned to other routes that have beenreceived from BGP speakers in neighboring autonomous systems, or

2) there are no other routes that have been received from BGPspeakers in neighboring autonomous systems, or

3) the newly received route is selected as a result of breaking atie between several routes which have the highest degree ofpreference, and the same destination (the tie-breaking procedure

is specified in 9.2.1.1).

When a BGP speaker receives an UPDATE message with a non-emptyWITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In allroutes whose destinations was carried in this field (as IP prefixes).The speaker shall take the following additional steps:

1) if the corresponding feasible route had not been previouslyadvertised, then no further action is necessary

2) if the corresponding feasible route had been previouslyadvertised, then:

i) if a new route is selected for advertisement that has thesame Network Layer Reachability Information as the unfeasibleroutes, then the local BGP speaker shall advertise thereplacement route

ii) if a replacement route is not available for advertisement,then the BGP speaker shall include the destinations of the



42/58


unfeasible route (in form of IP prefixes) in the WITHDRAWNROUTES field of an UPDATE message, and shall send this messageto each peer to whom it had previously advertised the

corresponding feasible route.

All feasible routes which are advertised shall be placed in theappropriate Adj-RIBs-Out, and all unfeasible routes which areadvertised shall be removed from the Adj-RIBs-Out.

9.2.1.1 Breaking Ties (Internal Updates)

If a local BGP speaker has connections to several BGP speakers inneighboring autonomous systems, there will be multiple Adj-RIBs-Inassociated with these peers. These Adj-RIBs-In might contain severalequally preferable routes to the same destination, all of which were

advertised by BGP speakers located in neighboring autonomous systems.The local BGP speaker shall select one of these routes according tothe following rules:

a) If the candidate route differ only in their NEXT_HOP andMULTI_EXIT_DISC attributes, and the local system is configured totake into account MULTI_EXIT_DISC attribute, select the routesthat has the lowest value of the MULTI_EXIT_DISC attribute.

b) If the local system can ascertain the cost of a path to theentity depicted by the NEXT_HOP attribute of the candidate route,select the route with the lowest cost.

c) In all other cases, select the route that was advertised by theBGP speaker whose BGP Identifier has the lowest value.

9.2.2 External Updates

The external update process is concerned with the distribution ofrouting information to BGP speakers located in neighboring autonomoussystems. As part of Phase 3 route selection process, the BGP speakerhas updated its Adj-RIBs-Out and its Forwarding Table. All newlyinstalled routes and all newly unfeasible routes for which there isno replacement route shall be advertised to BGP speakers located inneighboring autonomous systems by means of UPDATE message.

Any routes in the Loc-RIB marked as unfeasible shall be removed.Changes to the reachable destinations within its own autonomoussystem shall also be advertised in an UPDATE message.



43/58


9.2.3 Controlling Routing Traffic Overhead

The BGP protocol constrains the amount of routing traffic (that is,

UPDATE messages) in order to limit both the link bandwidth needed toadvertise UPDATE messages and the processing power needed by theDecision Process to digest the information contained in the UPDATEmessages.

9.2.3.1 Frequency of Route Advertisement

The parameter MinRouteAdvertisementInterval determines the minimumamount of time that must elapse between advertisement of routes to aparticular destination from a single BGP speaker. This rate limitingprocedure applies on a per-destination basis, although the value ofMinRouteAdvertisementInterval is set on a per BGP peer basis.

Two UPDATE messages sent from a single BGP speaker that advertisefeasible routes to some common set of destinations received from BGPspeakers in neighboring autonomous systems must be separated by atleast MinRouteAdvertisementInterval. Clearly, this can only beachieved precisely by keeping a separate timer for each common set ofdestinations. This would be unwarranted overhead. Any technique whichensures that the interval between two UPDATE messages sent from asingle BGP speaker that advertise feasible routes to some common setof destinations received from BGP speakers in neighboring autonomoussystems will be at least MinRouteAdvertisementInterval, and will alsoensure a constant upper bound on the interval is acceptable.

Since fast convergence is needed within an autonomous system, thisprocedure does not apply for routes receives from other BGP speakersin the same autonomous system. To avoid long-lived black holes, theprocedure does not apply to the explicit withdrawal of unfeasibleroutes (that is, routes whose destinations (expressed as IP prefixes)are listed in the WITHDRAWN ROUTES field of an UPDATE message).

This procedure does not limit the rate of route selection, but onlythe rate of route advertisement. If new routes are selected multipletimes while awaiting the expiration of MinRouteAdvertisementInterval,the

Date post:	09-Apr-2018
Category:	Documents
Upload:	adamovic5
View:	219 times
Download:	0 times

rfc rfc1771

Documents