Event 26: KeepAliveMsg
Definition: An event is generated when a KEEPALIVE message is
received.
Status: Mandatory
Event 27: UpdateMsg
Definition: An event is generated when a valid UPDATE message
is received.
Status: Mandatory
Event 28: UpdateMsgErr
Definition: An event is generated when an invalid UPDATE
message is received.
Status: Mandatory
8.2. Description of FSM
8.2.1. FSM Definition
BGP MUST maintain a separate FSM for each configured peer. Each BGP
peer paired in a potential connection will attempt to connect to the
other, unless configured to remain in the idle state, or configured
to remain passive. For the purpose of this discussion, the active or
connecting side of the TCP connection (the side of a TCP connection
sending the first TCP SYN packet) is called outgoing. The passive or
listening side (the sender of the first SYN/ACK) is called an
incoming connection. (See Section 8.2.1.1 for information on the
terms active and passive used below.)
A BGP implementation MUST connect to and listen on TCP port 179 for
incoming connections in addition to trying to connect to peers. For
each incoming connection, a state machine MUST be instantiated.
There exists a period in which the identity of the peer on the other
end of an incoming connection is known, but the BGP identifier is not
known. During this time, both an incoming and outgoing connection
may exist for the same configured peering. This is referred to as a
connection collision (see Section 6.8).
A BGP implementation will have, at most, one FSM for each configured
peering, plus one FSM for each incoming TCP connection for which the
peer has not yet been identified. Each FSM corresponds to exactly
one TCP connection.
There may be more than one connection between a pair of peers if the
connections are configured to use a different pair of IP addresses.
This is referred to as multiple "configured peerings" to the same
peer.
8.2.1.1. Terms "active" and "passive"
The terms active and passive have been in the Internet operator’s
vocabulary for almost a decade and have proven useful. The words
active and passive have slightly different meanings when applied to a
TCP connection or a peer. There is only one active side and one
passive side to any one TCP connection, per the definition above and
the state machine below. When a BGP speaker is configured as active,
it may end up on either the active or passive side of the connection
that eventually gets established. Once the TCP connection is
completed, it doesn’t matter which end was active and which was
passive. The only difference is in which side of the TCP connection
has port number 179.
8.2.1.2. FSM and Collision Detection
There is one FSM per BGP connection. When the connection collision
occurs prior to determining what peer a connection is associated
with, there may be two connections for one peer. After the
connection collision is resolved (see Section 6.8), the FSM for the
connection that is closed SHOULD be disposed.
8.2.1.3. FSM and Optional Session Attributes
Optional Session Attributes specify either attributes that act as
flags (TRUE or FALSE) or optional timers. For optional attributes
that act as flags, if the optional session attribute can be set to
TRUE on the system, the corresponding BGP FSM actions must be
supported. For example, if the following options can be set in a BGP
implementation: AutoStart and PassiveTcpEstablishment, then Events 3,
4 and 5 must be supported. If an Optional Session attribute cannot
be set to TRUE, the events supporting that set of options do not have
to be supported.
Each of the optional timers (DelayOpenTimer and IdleHoldTimer) has a
group of attributes that are:
- flag indicating support,
- Time set in Timer
- Timer.
The two optional timers show this format:
DelayOpenTimer: DelayOpen, DelayOpenTime, DelayOpenTimer
IdleHoldTimer: DampPeerOscillations, IdleHoldTime,
IdleHoldTimer
If the flag indicating support for an optional timer (DelayOpen or
DampPeerOscillations) cannot be set to TRUE, the timers and events
supporting that option do not have to be supported.
8.2.1.4. FSM Event Numbers
The Event numbers (1-28) utilized in this state machine description
aid in specifying the behavior of the BGP state machine.
Implementations MAY use these numbers to provide network management
information. The exact form of an FSM or the FSM events are specific
to each implementation.
8.2.1.5. FSM Actions that are Implementation Dependent
At certain points, the BGP FSM specifies that BGP initialization will
occur or that BGP resources will be deleted. The initialization of
the BGP FSM and the associated resources depend on the policy portion
of the BGP implementation. The details of these actions are outside
the scope of the FSM document.
8.2.2. Finite State Machine
Idle state:
Initially, the BGP peer FSM is in the Idle state. Hereafter, the
BGP peer FSM will be shortened to BGP FSM.
In this state, BGP FSM refuses all incoming BGP connections for
this peer. No resources are allocated to the peer. In response
to a ManualStart event (Event 1) or an AutomaticStart event (Event
3), the local system:
- initializes all BGP resources for the peer connection,
- sets ConnectRetryCounter to zero,
- starts the ConnectRetryTimer with the initial value,
- initiates a TCP connection to the other BGP peer,
- listens for a connection that may be initiated by the remote
BGP peer, and
- changes its state to Connect.
The ManualStop event (Event 2) and AutomaticStop (Event 8) event
are ignored in the Idle state.
In response to a ManualStart_with_PassiveTcpEstablishment event
(Event 4) or AutomaticStart_with_PassiveTcpEstablishment event
(Event 5), the local system:
- initializes all BGP resources,
- sets the ConnectRetryCounter to zero,
- starts the ConnectRetryTimer with the initial value,
- listens for a connection that may be initiated by the remote
peer, and
- changes its state to Active.
The exact value of the ConnectRetryTimer is a local matter, but it
SHOULD be sufficiently large to allow TCP initialization.
If the DampPeerOscillations attribute is set to TRUE, the
following three additional events may occur within the Idle state:
- AutomaticStart_with_DampPeerOscillations (Event 6),
- AutomaticStart_with_DampPeerOscillations_and_
PassiveTcpEstablishment (Event 7),
- IdleHoldTimer_Expires (Event 13).
Upon receiving these 3 events, the local system will use these
events to prevent peer oscillations. The method of preventing
persistent peer oscillation is outside the scope of this document.
Any other event (Events 9-12, 15-28) received in the Idle state
does not cause change in the state of the local system.
Connect State:
In this state, BGP FSM is waiting for the TCP connection to be
completed.
The start events (Events 1, 3-7) are ignored in the Connect state.
In response to a ManualStop event (Event 2), the local system:
- drops the TCP connection,
- releases all BGP resources,
- sets ConnectRetryCounter to zero,
- stops the ConnectRetryTimer and sets ConnectRetryTimer to
zero, and
- changes its state to Idle.
In response to the ConnectRetryTimer_Expires event (Event 9), the
local system:
- drops the TCP connection,
- restarts the ConnectRetryTimer,
- stops the DelayOpenTimer and resets the timer to zero,
- initiates a TCP connection to the other BGP peer,
- continues to listen for a connection that may be initiated by
the remote BGP peer, and
- stays in the Connect state.
If the DelayOpenTimer_Expires event (Event 12) occurs in the
Connect state, the local system:
- sends an OPEN message to its peer,
- sets the HoldTimer to a large value, and
- changes its state to OpenSent.
If the BGP FSM receives a TcpConnection_Valid event (Event 14),
the TCP connection is processed, and the connection remains in the
Connect state.
If the BGP FSM receives a Tcp_CR_Invalid event (Event 15), the
local system rejects the TCP connection, and the connection
remains in the Connect state.
If the TCP connection succeeds (Event 16 or Event 17), the local
system checks the DelayOpen attribute prior to processing. If the
DelayOpen attribute is set to TRUE, the local system:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- sets the DelayOpenTimer to the initial value, and
- stays in the Connect state.
If the DelayOpen attribute is set to FALSE, the local system:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- completes BGP initialization
- sends an OPEN message to its peer,
- sets the HoldTimer to a large value, and
- changes its state to OpenSent.
A HoldTimer value of 4 minutes is suggested.
If the TCP connection fails (Event 18), the local system checks
the DelayOpenTimer. If the DelayOpenTimer is running, the local
system:
- restarts the ConnectRetryTimer with the initial value,
- stops the DelayOpenTimer and resets its value to zero,
- continues to listen for a connection that may be initiated by
the remote BGP peer, and
- changes its state to Active.
If the DelayOpenTimer is not running, the local system:
- stops the ConnectRetryTimer to zero,
- drops the TCP connection,
- releases all BGP resources, and
- changes its state to Idle.
If an OPEN message is received while the DelayOpenTimer is running
(Event 20), the local system:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- completes the BGP initialization,
- stops and clears the DelayOpenTimer (sets the value to zero),
- sends an OPEN message,
- sends a KEEPALIVE message,
- if the HoldTimer initial value is non-zero,
- starts the KeepaliveTimer with the initial value and
- resets the HoldTimer to the negotiated value,
else, if the HoldTimer initial value is zero,
- resets the KeepaliveTimer and
- resets the HoldTimer value to zero,
- and changes its state to OpenConfirm.
If the value of the autonomous system field is the same as the
local Autonomous System number, set the connection status to an
internal connection; otherwise it will be "external".
If BGP message header checking (Event 21) or OPEN message checking
detects an error (Event 22) (see Section 6.2), the local system:
- (optionally) If the SendNOTIFICATIONwithoutOPEN attribute is
set to TRUE, then the local system first sends a NOTIFICATION
message with the appropriate error code, and then
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
If a NOTIFICATION message is received with a version error (Event
24), the local system checks the DelayOpenTimer. If the
DelayOpenTimer is running, the local system:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- stops and resets the DelayOpenTimer (sets to zero),
- releases all BGP resources,
- drops the TCP connection, and
- changes its state to Idle.
If the DelayOpenTimer is not running, the local system:
- stops the ConnectRetryTimer and sets the ConnectRetryTimer to
zero,
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- performs peer oscillation damping if the DampPeerOscillations
attribute is set to True, and
- changes its state to Idle.
In response to any other events (Events 8, 10-11, 13, 19, 23,
25-28), the local system:
- if the ConnectRetryTimer is running, stops and resets the
ConnectRetryTimer (sets to zero),
- if the DelayOpenTimer is running, stops and resets the
DelayOpenTimer (sets to zero),
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- performs peer oscillation damping if the DampPeerOscillations
attribute is set to True, and
- changes its state to Idle.
Active State:
In this state, BGP FSM is trying to acquire a peer by listening
for, and accepting, a TCP connection.
The start events (Events 1, 3-7) are ignored in the Active state.
In response to a ManualStop event (Event 2), the local system:
- If the DelayOpenTimer is running and the
SendNOTIFICATIONwithoutOPEN session attribute is set, the
local system sends a NOTIFICATION with a Cease,
- releases all BGP resources including stopping the
DelayOpenTimer
- drops the TCP connection,
- sets ConnectRetryCounter to zero,
- stops the ConnectRetryTimer and sets the ConnectRetryTimer to
zero, and
- changes its state to Idle.
In response to a ConnectRetryTimer_Expires event (Event 9), the
local system:
- restarts the ConnectRetryTimer (with initial value),
- initiates a TCP connection to the other BGP peer,
- continues to listen for a TCP connection that may be initiated
by a remote BGP peer, and
- changes its state to Connect.
If the local system receives a DelayOpenTimer_Expires event (Event
12), the local system:
- sets the ConnectRetryTimer to zero,
- stops and clears the DelayOpenTimer (set to zero),
- completes the BGP initialization,
- sends the OPEN message to its remote peer,
- sets its hold timer to a large value, and
- changes its state to OpenSent.
A HoldTimer value of 4 minutes is also suggested for this state
transition.
If the local system receives a TcpConnection_Valid event (Event
14), the local system processes the TCP connection flags and stays
in the Active state.
If the local system receives a Tcp_CR_Invalid event (Event 15),
the local system rejects the TCP connection and stays in the
Active State.
In response to the success of a TCP connection (Event 16 or Event
17), the local system checks the DelayOpen optional attribute
prior to processing.
If the DelayOpen attribute is set to TRUE, the local system:
- stops the ConnectRetryTimer and sets the ConnectRetryTimer
to zero,
- sets the DelayOpenTimer to the initial value
(DelayOpenTime), and
- stays in the Active state.
If the DelayOpen attribute is set to FALSE, the local system:
- sets the ConnectRetryTimer to zero,
- completes the BGP initialization,
- sends the OPEN message to its peer,
- sets its HoldTimer to a large value, and
- changes its state to OpenSent.
A HoldTimer value of 4 minutes is suggested as a "large value" for
the HoldTimer.
If the local system receives a TcpConnectionFails event (Event
18), the local system:
- restarts the ConnectRetryTimer (with the initial value),
- stops and clears the DelayOpenTimer (sets the value to zero),
- releases all BGP resource,
- increments the ConnectRetryCounter by 1,
- optionally performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
If an OPEN message is received and the DelayOpenTimer is running
(Event 20), the local system:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- stops and clears the DelayOpenTimer (sets to zero),
- completes the BGP initialization,
- sends an OPEN message,
- sends a KEEPALIVE message,
- if the HoldTimer value is non-zero,
- starts the KeepaliveTimer to initial value,
- resets the HoldTimer to the negotiated value,
else if the HoldTimer is zero
- resets the KeepaliveTimer (set to zero),
- resets the HoldTimer to zero, and
- changes its state to OpenConfirm.
If the value of the autonomous system field is the same as the
local Autonomous System number, set the connection status to an
internal connection; otherwise it will be external.
If BGP message header checking (Event 21) or OPEN message checking
detects an error (Event 22) (see Section 6.2), the local system:
- (optionally) sends a NOTIFICATION message with the appropriate
error code if the SendNOTIFICATIONwithoutOPEN attribute is set
to TRUE,
- sets the ConnectRetryTimer to zero,
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
If a NOTIFICATION message is received with a version error (Event
24), the local system checks the DelayOpenTimer. If the
DelayOpenTimer is running, the local system:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- stops and resets the DelayOpenTimer (sets to zero),
- releases all BGP resources,
- drops the TCP connection, and
- changes its state to Idle.
If the DelayOpenTimer is not running, the local system:
- sets the ConnectRetryTimer to zero,
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
In response to any other event (Events 8, 10-11, 13, 19, 23,
25-28), the local system:
- sets the ConnectRetryTimer to zero,
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by one,
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
OpenSent:
In this state, BGP FSM waits for an OPEN message from its peer.
The start events (Events 1, 3-7) are ignored in the OpenSent
state.
If a ManualStop event (Event 2) is issued in the OpenSent state,
the local system:
- sends the NOTIFICATION with a Cease,
- sets the ConnectRetryTimer to zero,
- releases all BGP resources,
- drops the TCP connection,
- sets the ConnectRetryCounter to zero, and
- changes its state to Idle.
If an AutomaticStop event (Event 8) is issued in the OpenSent
state, the local system:
- sends the NOTIFICATION with a Cease,
- sets the ConnectRetryTimer to zero,
- releases all the BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
If the HoldTimer_Expires (Event 10), the local system:
- sends a NOTIFICATION message with the error code Hold Timer
Expired,
- sets the ConnectRetryTimer to zero,
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter,
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
If a TcpConnection_Valid (Event 14), Tcp_CR_Acked (Event 16), or a
TcpConnectionConfirmed event (Event 17) is received, a second TCP
connection may be in progress. This second TCP connection is
tracked per Connection Collision processing (Section 6.8) until an