BGP message can be anywhere from 19 bytes (just the header) to a maximum of 4096 bytes, as shown in Figure A3.2.
The Marker is a 16-byte fi eld, set to ones. The Length is a 2-byte fi eld indicat-ing the total length of the message in bytes. The Type fi eld is 1-byte long, and indicates the purpose and format of the message, as follows:
I Open message (message type 1)—starts a BGP session.
I Update message (message type 2)—exchanges information about the routes.
I Notifi cation message (message type 3)—is sent when an error is detected and the BGP connection should end.
I KeepAlive messages (message type 4)—periodic messages that verify the continuous connection of the BGP peer.59
The BGP formats for the various messages are described in the following.
Open
The Open message (see format in Figure A3.3) is the fi rst message sent by both BGP routers (called BGP speakers) when a TCP connection is established.
59Additional message type 5, “Route Refresh,” was proposed in RFC2918 [77], and is not discussed here.
FIGURE A3.2 BGP header
0 1 2 3
Marker Type Length
0 4 8 12 16
0 1 2 3
Marker
Type⫽1 Length
0 4 8 12
16 Version
Hold Time My Autonomous System
Opt parm len 20
24 28
Optional Parameters BGP Identifier
FIGURE A3.3
Notifi cation message format
In addition to the header fi elds, the Open message contains the following fi elds:
Version is a 1-byte fi eld that indicates the version number of the message protocol (currently 4). My Autonomous System is a 2-byte fi eld that indicates the AS sender number (AS-ID). Hold Time is a 2-byte fi eld that indicates the maximum elapsed time between successive KeepAlive message and/or Update message receipt (in seconds). BGP Identifi er identifi es the sender by its IP address, and Optional Parameter Length is 1-byte long and indicates the length of the following Optional Parameter fi eld in bytes. The Optional Parameter fi eld consists of an encoded list of parameters in the < Type, Length, Value> format, as shown in Figure A3.4.
Update
The Update message advertises routes to a set of destinations that have the same prefi x of IP address. The message is used by a BGP speaker to advertise a previ-ously received route, to add or modify the path attributes before advertising it, or to “delete” (withdraw) an already advertised route.
The update message is shown in Figure A3.5, and includes a variable number of fi elds in two parts of the message; some of the fi elds are themselves of vari-able length. After the header there is a part that defi nes the withdrawn routes, which is followed by the second part that describes the new or updated routes.
This latter part is also composed of two subparts, the fi rst of which describes the FIGURE A3.4
Optional parameters
Parm Type Parm Length Parameter Value
0 1 2 3
pref#1 len Withdrawn route#1 prefix (0-4 bytes), according to pref len
Attr#1 type code Attribute#1 Length (1 or 2 bytes) Attribute#1 Value (variable length, according to type)
Total Path Attributes length (0-…) Withdrawn Routes Length (0-…)
Network Layer Reachability
Information pref#m len Withdrawn route#m prefix (0-4 bytes), according to pref len 19
Attr#n type flags Attr#n type code Attribute#n Length (1 or 2 bytes) Attribute#n Value (variable length, according to type)
21
NLRI pref#1 len NLRI#1 prefix (0-4 bytes), according to pref len NLRI pref#k len NLRI#k prefix (0-4 bytes), according to pref len
Marker
Appendix A: Routing Information Distribution Protocols 139
common path attributes of these routes, while the second defi nes the IP address prefi x that all target destinations have.
Withdrawn Routes Length is a two-byte fi eld that indicates the total length of the Withdrawn Routes part of the message in bytes (if 0, no withdrawn routes exist in that message). Each of the Withdrawn Routes entries is a variable-length description of an IP address prefi x to be withdrawn, consisting of a pair of <length, prefi x>. Length is one byte that contains the prefi x-length (in bits) of the IP address, and Prefi x is the prefi x of the IP addresses (which is 0–4 bytes long, depending on the prefi x length).
Total Path Attributes Length is a two-byte fi eld that indicates the total length of the Path Attributes fi eld in bytes (if 0, neither Path Attributes nor Network Layer Reachability Information [NLRI] are distributed by this message). Path Attributes are the common path parameters that are distributed in the Update message, and they are represented in the <Type, Length, Value> format. Each is of a variable length according to its type. Attribute Type is two bytes long; the fi rst byte contains the Attribute’s Flags60 and the second byte is the Attribute Type Code, described as follows.
Attribute Length is one or two bytes long (according to the Extended Length fl ag), indicating the length of the Value fi eld in bytes, and the attribute’s Value fi eld is interpreted according to the Attribute Type Code. The three well-known and mandatory attributes are:
I ORIGIN (Type code 1)—defi nes the origin of the prefi x (0 means from inte-rior routing in the originating AS; 1 means for NLRI acquired from inter-AS routing, or 2 from somewhere else).
I AS_PATH (Type code 2)—describes the associated AS path vector, which is composed of a set or sequence of AS path segments through which routing information has passed. Each segment is described by the TLV format.61
I NEXT_HOP (Type code 3)—provides the IP address of the border router that should be used for the next hop to reach the destinations listed in the NLRI.
The NLRI fi eld consists of a list of IP address prefi xes. IP address prefi xes are defi ned by one byte containing the length of the network mask in Classless
60The fl ags are 8 bits, where just the fi rst four most signifi cant bits are currently used. The fi rst, the high-order bit, is the optional (1) or well-known (0) attribute, and in the case of an optional attribute, the second bit instructs the BGP receiver to accept the path and distribute it if it is transitive (1), and to set the next, third bit, the partial bit. This partial bit indicates to BGP routers that somewhere along the path there was at least one BGP router that wasn’t familiar with the optional attribute.
The last bit, the fourth high-order one, is the extended length fl ag that is used to indicate a long attribute, and the Length fi eld is two bytes long (rather than just one) for Value lengths greater than 255 bytes.
61The AS_PATH attribute is composed of a set or sequence of AS path segments; each segment is represented by Type, Length, and Value parameters. Type is a 1-byte fi eld, containing “1” (indicating an unordered set of AS’s in the path) or “2” (indicating an ordered sequence of AS’s in the path).
Length is a 1-byte fi eld, containing the number of AS’s in the Value fi eld, and the Value fi eld is one or more AS’s in a 2-bytes long fi eld for each of the AS numbers.
Interdomain Routing (CIDR) terminology, and up to four bytes that contain the address prefi x itself (IP addressing, including CIDR, is described in Chapter 5.The NLRI has no explicit encoded length in the message, and should be calculated by subtracting 23,62 the Withdrawn Routed Length and the Total Path Attributes Length from the Update Message Length.
Notifi cation
The Notifi cation message is sent before terminating the BGP connection, to notify that an error condition was detected. Three fi elds exist in the notifi cation message, as shown in Figure A3.6; Error Code is a 1-byte fi eld that indicates the primary error condition (containing 1 to indicate an error in the message header, 2 for an error in the Open message, 3 for an error in the Update message, 4 for expiration of the Hold Time, 5 for a BGP state machine error, or 6 for an unexplained session termination). Error Subcode is a 1-byte fi eld that provides more details about the error. The Data fi eld is of variable length, and it is used to diagnose the reason for the Notifi cation message. No explicit, encoded length of the data exists in the message, and it must be calculated by subtracting 21 from the Notifi cation mes-sage length.
KeepAlive
The KeepAlive message is used for keeping the Hold-Time from expiring, thereby maintaining a keep-alive mechanism that ensures peers’ reachability. The KeepAlive message format is just the header, with type of message equals 4.