### ----------------------------------------------------
### -- Net::BGP
### -- Licenses: Artistic-2.0
### -- Authors: Joelle Maslak
### -- File: rfc/rfc4271.txt
### ----------------------------------------------------
### -- Chunk 4 of 7
 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.





Rekhter, et al.             Standards Track                    [Page 51]

RFC 4271                         BGP-4                      January 2006


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





Rekhter, et al.             Standards Track                    [Page 52]

RFC 4271                         BGP-4                      January 2006


   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.




Rekhter, et al.             Standards Track                    [Page 53]

RFC 4271                         BGP-4                      January 2006


      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,




Rekhter, et al.             Standards Track                    [Page 54]

RFC 4271                         BGP-4                      January 2006


        - 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



Rekhter, et al.             Standards Track                    [Page 55]

RFC 4271                         BGP-4                      January 2006


        - 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,




Rekhter, et al.             Standards Track                    [Page 56]

RFC 4271                         BGP-4                      January 2006


        - 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:



Rekhter, et al.             Standards Track                    [Page 57]

RFC 4271                         BGP-4                      January 2006


        - 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.





Rekhter, et al.             Standards Track                    [Page 58]

RFC 4271                         BGP-4                      January 2006


   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,




Rekhter, et al.             Standards Track                    [Page 59]

RFC 4271                         BGP-4                      January 2006


        - 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),



Rekhter, et al.             Standards Track                    [Page 60]

RFC 4271                         BGP-4                      January 2006


        - 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:






Rekhter, et al.             Standards Track                    [Page 61]

RFC 4271                         BGP-4                      January 2006


        - (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.





Rekhter, et al.             Standards Track                    [Page 62]

RFC 4271                         BGP-4                      January 2006


      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,



Rekhter, et al.             Standards Track                    [Page 63]

RFC 4271                         BGP-4                      January 2006


        - 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
      OPEN message is received.

      A TCP Connection Request for an Invalid port (Tcp_CR_Invalid
      (Event 15)) is ignored.

      If a TcpConnectionFails event (Event 18) is received, the local
      system:

        - closes the BGP connection,

        - restarts the ConnectRetryTimer,

        - continues to listen for a connection that may be initiated by
          the remote BGP peer, and

        - changes its state to Active.






Rekhter, et al.             Standards Track                    [Page 64]

RFC 4271                         BGP-4                      January 2006


      When an OPEN message is received, all fields are checked for
      correctness.  If there are no errors in the OPEN message (Event
      19), the local system:

        - resets the DelayOpenTimer to zero,

        - sets the BGP ConnectRetryTimer to zero,

        - sends a KEEPALIVE message, and

        - sets a KeepaliveTimer (via the text below)

        - sets the HoldTimer according to the negotiated value (see
          Section 4.2),

        - changes its state to OpenConfirm.

      If the negotiated hold time value is zero, then the HoldTimer and
      KeepaliveTimer are not started.  If the value of the Autonomous
      System field is the same as the local Autonomous System number,
      then the connection is an "internal" connection; otherwise, it is
      an "external" connection.  (This will impact UPDATE processing as
      described below.)

      If the BGP message header checking (Event 21) or OPEN message
      checking detects an error (Event 22)(see Section 6.2), the local
      system:

        - sends a NOTIFICATION message with the appropriate error code,

        - 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 TRUE, and

        - changes its state to Idle.

      Collision detection mechanisms (Section 6.8) need to be applied
      when a valid BGP OPEN message is received (Event 19 or Event 20).
      Please refer to Section 6.8 for the details of the comparison.  A





Rekhter, et al.             Standards Track                    [Page 65]

RFC 4271                         BGP-4                      January 2006


      CollisionDetectDump event occurs when the BGP implementation
      determines, by means outside the scope of this document, that a
      connection collision has occurred.

      If a connection in the OpenSent state is determined to be the
      connection that must be closed, an OpenCollisionDump (Event 23) is
      signaled to the state machine.  If such an event is received in
      the OpenSent state, the local system:

        - sends a NOTIFICATION with a Cease,

        - 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:

        - sets the ConnectRetryTimer to zero,

        - releases all BGP resources,

        - drops the TCP connection, and

        - changes its state to Idle.

      In response to any other event (Events 9, 11-13, 20, 25-28), the
      local system:

        - sends the NOTIFICATION with the Error Code Finite State
          Machine Error,

        - sets the ConnectRetryTimer to zero,

        - releases all BGP resources,

        - drops the TCP connection,

        - increments the ConnectRetryCounter by 1,



Rekhter, et al.             Standards Track                    [Page 66]

RFC 4271                         BGP-4                      January 2006


        - (optionally) performs peer oscillation damping if the
          DampPeerOscillations attribute is set to TRUE, and

        - changes its state to Idle.

   OpenConfirm State:

      In this state, BGP waits for a KEEPALIVE or NOTIFICATION message.

      Any start event (Events 1, 3-7) is ignored in the OpenConfirm
      state.

      In response to a ManualStop event (Event 2) initiated by the
      operator, the local system:

        - sends the NOTIFICATION message with a Cease,

        - releases all BGP resources,

        - drops the TCP connection,

        - sets the ConnectRetryCounter to zero,

        - sets the ConnectRetryTimer to zero, and

        - changes its state to Idle.

      In response to the AutomaticStop event initiated by the system
      (Event 8), the local system:

        - sends the NOTIFICATION message with a Cease,

        - 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 the HoldTimer_Expires event (Event 10) occurs before a
      KEEPALIVE message is received, the local system:




Rekhter, et al.             Standards Track                    [Page 67]

RFC 4271                         BGP-4                      January 2006


        - sends the 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 by 1,

        - (optionally) performs peer oscillation damping if the
          DampPeerOscillations attribute is set to TRUE, and

        - changes its state to Idle.

      If the local system receives a KeepaliveTimer_Expires event (Event
      11), the local system:

        - sends a KEEPALIVE message,

        - restarts the KeepaliveTimer, and

        - remains in the OpenConfirmed state.

      In the event of a TcpConnection_Valid event (Event 14), or the
      success of a TCP connection (Event 16 or Event 17) while in
      OpenConfirm, the local system needs to track the second
      connection.

      If a TCP connection is attempted with an invalid port (Event 15),
      the local system will ignore the second connection attempt.

      If the local system receives a TcpConnectionFails event (Event 18)
      from the underlying TCP or a NOTIFICATION message (Event 25), 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




Rekhter, et al.             Standards Track                    [Page 68]

RFC 4271                         BGP-4                      January 2006


        - changes its state to Idle.

      If the local system receives a NOTIFICATION message with a version
      error (NotifMsgVerErr (Event 24)), the local system:

        - sets the ConnectRetryTimer to zero,

        - releases all BGP resources,

        - drops the TCP connection, and

        - changes its state to Idle.

      If the local system receives a valid OPEN message (BGPOpen (Event
      19)), the collision detect function is processed per Section 6.8.
      If this connection is to be dropped due to connection collision,
      the local system:

        - sends a NOTIFICATION with a Cease,

        - sets the ConnectRetryTimer to zero,

        - releases all BGP resources,

        - drops the TCP connection (send TCP FIN),

        - 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, all fields are checked for
      correctness.  If the BGP message header checking (BGPHeaderErr
      (Event 21)) or OPEN message checking detects an error (see Section
      6.2) (BGPOpenMsgErr (Event 22)), the local system:

        - sends a NOTIFICATION message with the appropriate error code,

        - sets the ConnectRetryTimer to zero,

        - releases all BGP resources,

        - drops the TCP connection,

        - increments the ConnectRetryCounter by 1,




Rekhter, et al.             Standards Track                    [Page 69]

RFC 4271                         BGP-4                      January 2006


        - (optionally) performs peer oscillation damping if the
          DampPeerOscillations attribute is set to TRUE, and

        - changes its state to Idle.

      If, during the processing of another OPEN message, the BGP
      implementation determines, by a means outside the scope of this
      document, that a connection collision has occurred and this
      connection is to be closed, the local system will issue an
      OpenCollisionDump event (Event 23).  When the local system
      receives an OpenCollisionDump event (Event 23), the local system:

        - sends a NOTIFICATION with a Cease,

        - 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 the local system receives a KEEPALIVE message (KeepAliveMsg
      (Event 26)), the local system:

        - restarts the HoldTimer and

        - changes its state to Established.

      In response to any other event (Events 9, 12-13, 20, 27-28), the
      local system:

        - sends a NOTIFICATION with a code of Finite State Machine
          Error,

        - sets the ConnectRetryTimer to zero,

        - releases all BGP resources,

        - drops the TCP connection,

        - increments the ConnectRetryCounter by 1,




Rekhter, et al.             Standards Track                    [Page 70]

RFC 4271                         BGP-4                      January 2006


        - (optionally) performs peer oscillation damping if the
          DampPeerOscillations attribute is set to TRUE, and

        - changes its state to Idle.

   Established State:

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

      Any Start event (Events 1, 3-7) is ignored in the Established
      state.

      In response to a ManualStop event (initiated by an operator)
      (Event 2), the local system:

        - sends the NOTIFICATION message with a Cease,

        - sets the ConnectRetryTimer to zero,

        - deletes all routes associated with this connection,

        - releases BGP resources,

        - drops the TCP connection,

        - sets the ConnectRetryCounter to zero, and

         - changes its state to Idle.

      In response to an AutomaticStop event (Event 8), the local system:

        - sends a NOTIFICATION with a Cease,

        - sets the ConnectRetryTimer to zero

        - deletes all routes associated with this connection,

        - 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.



Rekhter, et al.             Standards Track                    [Page 71]

RFC 4271                         BGP-4                      January 2006


      One reason for an AutomaticStop event is: A BGP receives an UPDATE
      messages with a number of prefixes for a given peer such that the
      total prefixes received exceeds the maximum number of prefixes
      configured.  The local system automatically disconnects the peer.

      If the HoldTimer_Expires event occurs (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 by 1,

        - (optionally) performs peer oscillation damping if the
          DampPeerOscillations attribute is set to TRUE, and

        - changes its state to Idle.

      If the KeepaliveTimer_Expires event occurs (Event 11), the local
      system:

        - sends a KEEPALIVE message, and

        - restarts its KeepaliveTimer, unless the negotiated HoldTime
          value is zero.

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

      A TcpConnection_Valid (Event 14), received for a valid port, will
      cause the second connection to be tracked.

      An invalid