BGP Message Types

BGP is an application layer protocol that uses TCP as its transport layer protocol – TCP Port number 179, which provides connection-oriented reliable delivery of packets. BGP assumes that its communication is reliable, and does not implement any fragmentation, retransmission, acknowledgment, sequencing, and error-recovery mechanisms as like EIGRP. BGP information is encapsulated inside TCP segments, which are then encapsulated inside IP packets. BGP is the only IP routing protocol that uses TCP as its transport layer. RIP uses UDP for its transport layer; IGRP, EIGRP, and OSPF reside directly above the IP layer; and IS-IS is resides in the network layer.

BGP routers establish a TCP connection between them via the standard TCP three-way handshake to exchange messages to confirm the connection parameters and full routing updates. BGP routers send only changes (triggered updates) subsequently. BGP also sends periodic keepalive messages, similar to the Hello packets in EIGRP, OSPF, and IS-IS.

EIGRP and OSPF implement a one-for-one window to ensure that update packets are explicitly acknowledged. When there are multiple packets to send, the next packet cannot be sent until an acknowledgment for the current packet is received. The acknowledgment process can be very inefficient and causes latency issues if many update packets must be exchanged over slow links. However, OSPF and EIGRP rarely have to exchange thousands of updates packets. EIGRP can hold more than 100 networks in a single EIGRP update packet; therefore 100 EIGRP update packets can hold up to 10000 networks. Most organizations do not have 10000 subnets!

BGP, which always has more than 120’000 Internet routes to advertise, uses TCP to handle the acknowledgment process. The 16-bit TCP Window allows up to 65536 bytes to be sent without waiting for an acknowledgment. If 1000-byte packets are being sent, around 65 packets are allowed to be sent without waiting for an acknowledgment.

With TCP sliding window, the receiver often acknowledges at halfway of the sending window, which allows any TCP applications, eg: BGP, to stream packets without having to stop and wait for acknowledgments. TCP was selected as the transport layer for BGP as TCP can transmit a large volume of data reliably. With the full Internet routing table exceeding 32MB in size and exceeding 1000 bytes of BGP changes per minute, rely upon TCP for windowing and reliability is better than implementing a BGP one-for-one windowing capability as like EIGRP and OSPF.

BGP messages are carried within TCP segments. The minimum and maximum message sizes are 19 and 4096 octets or bytes respectively. All BGP messages share a common header. A data portion might or might not follow the header depend upon the message type.

The BGP Message Header

Marker is a 16-byte field that is used to detect loss of synchronization between BGP peers and to authenticate messages when authentication is supported. It is set to all 1s if the message type is Open or if the Open message does not contain authentication information; otherwise, the value of the Marker can be predicted by some computation as part of the authentication process.
Length is a 2-byte field that indicates the total length of the message including the header, in octets.
Type is a 1-byte field that specifies the message type.
BGP defines the following message types:

Open (Type Code 1)	The 1st message sent by both peers after a TCP connection has been established. If the Open message is acceptable, a Keepalive message is sent to confirm the Open. Keepalive, Update, and Notification messages can be exchanged only after the Open has been confirmed and the BGP connection is established.
Update (Type Code 2)	BGP peers exchange full BGP routing tables upon the initial TCP connection. Incremental updates upon the changes in the routing table are sent subsequently.
Notification (Type Code 3)	Sent when an error or special condition is detected. The BGP connection is terminated immediately upon a Notification message is sent. A Notification message includes an Error Code, an Error Subcode, and the Data or reason for the error.
Keepalive (Type Code 4)	Consists of only the 19-byte BGP message header with no additional data. Maintains the BGP connection between 2 BGP peers. Exchanged on a period of one-third (1/3) of the hold time, but not less than 1 second; 60 seconds by default. Keepalive messages are not sent if the negotiated hold time for the BGP session is 0.

The BGP Open Message Format

The BGP Open message contains the following fields and information:
 Version. A 1-byte field that indicates the BGP version number running on the originator. The highest common version that both routers negotiated and support will be used. Most current BGP implementations use the current version – BGP-4.
 My Autonomous System. A 2-byte field that indicates the AS number of the originator. A BGP peer uses this information to determine whether the BGP session is EBGP or IBGP and will terminate the BGP session if it is not the expected AS number.
 Hold Time. A 2-byte field that indicates the number of seconds proposed by the originator for the hold time of the BGP session – the period of time that can elapse before the receiver must receive either a Keepalive or Update message from the originator. The receiver of the Open message calculates the hold timer value to use by comparing the Hold Time field specified in the Open message and its configured hold timer value; and accepts the smaller value or rejects the connection.
The hold time must be either 0 or at least 3 seconds. The default hold time is 180 seconds.
 BGP Identifier. A 4-byte field that indicates the Router ID of the originator. The BGP identifier is an IP address assigned to a BGP router and is determined upon the startup of a BGP routing process. The BGP Router ID is chosen the same way as the OSPF Router ID is chosen. The BGP Router ID can be statically configured to override the automatic selection.
 Optional Parameters Length. A 1-byte field that indicates the total length of the following Optional Parameters field, in octets. A value of zero indicates that there is no Optional Parameters field is included in the Open message.
 Optional Parameters. A variable-length field that contains a list of optional parameters. Each parameter is specified by a 1-byte Type field, a 1-byte Length field, and a variable-length Value field that contains the parameter value itself. This field is used to advertise the support for optional capabilities, eg: multiprotocol extensions, route refresh, etc.

The BGP Update Message Format

A BGP Update message is able to advertise a single feasible route, or withdrawn multiple unfeasible routes, or both. An Update message contains information about a single path only; multiple paths require multiple Update messages. All the path attributes in the Update message refer to a particular path, and the prefixes that can be reached through the specified path – update packing. The BGP Update message contains the following fields and information:
 Unfeasible Routes Length. A 2-byte field that indicates the total length of the following Withdrawn Routes field, in octets. A value of zero indicates that no routes are being withdrawn and there is no Withdrawn Routes field is included in the Update message.
 Withdrawn Routes. A variable-length field that contains a list of unreachable routes that are to be withdrawn from service, if any. Each route in the list is described with a (Length – Prefix) tuple. If the Length part of the tuple is 0, the Prefix matches all routes.
 Total Path Attribute Length. A 2-byte field that indicates the total length of the following Path Attributes field, in octets. A value of zero indicates that no path attributes and NLRI are included in the Update message.
 Path Attributes. A variable-length field that lists the attributes associated with the NLRI in the following field. Each path attribute is a variable-length triplet of (Attribute Type, Attribute Length, Attribute Value). The 2-byte Attribute Type field of the triplet consists of the 4 Attribute Flag bits, 4 unused bits, and a 1-byte Attribute Type Code field.
 Network Layer Reachability Information (NLRI). A variable-length field that contains a list of IP prefixes that can be reached via this path using the (Length – Prefix) tuples. A Length value of 0 indicates a prefix that matches all IP prefixes.
Note: BGP is more towards a reachability protocol than a routing protocol.
Note: If the path attributes associated with a route has changed, or a new path for the same prefix has been selected, a withdrawn route is not required; an Update message with the new attributes and matching NLRI will be advertised instead – implicit withdraw.

The Attribute Types and Associated Attribute Values of BGP Path Attributes