rfc1267.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   the unrecognized attribute (type, length and value).

   If the NEXT_HOP attribute field is syntactically or semantically
   incorrect, then the Error Subcode is set to Invalid NEXT_HOP
   Attribute.

   The Data field contains the incorrect attribute (type, length and
   value).  Syntactic correctness means that the NEXT_HOP attribute
   represents a valid IP host address.  Semantic correctness applies
   only to the external BGP links. It means that the interface
   associated with the IP address, as specified in the NEXT_HOP
   attribute, shares a common subnet with the receiving BGP speaker.

   The AS route specified by the AS_PATH attribute is checked for AS
   loops.  AS loop detection is done by scanning the full AS route (as
   specified in the AS_PATH attribute) and checking that each AS occurs
   at most once.  If a loop is detected, then the Error Subcode is set
   to AS Routing Loop.  The Data field contains the incorrect attribute
   (type, length and value).

   If an optional attribute is recognized, then the value of this
   attribute is checked.  If an error is detected, the attribute is
   discarded, and the Error Subcode is set to Optional Attribute Error.



Lougheed & Rekhter                                             [Page 17]

RFC 1267                         BGP-3                      October 1991


   The Data field contains the attribute (type, length and value).

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

   Each Network field in the UPDATE message is checked for syntactic
   validity.  If the Network field is syntactically incorrect, or
   contains a subnet or a host address, then the Error Subcode 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 that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message.  Any such error, such as an
   unrecognized Error Code or Error Subcode, should be noticed, logged
   locally, and brought to the attention of the administration of the
   peer.  The means to do this, however, lies outside the scope of this
   document.

6.5 Hold Timer Expired error handling.

   If a system does not receive successive KEEPALIVE and/or UPDATE
   and/or NOTIFICATION messages within the period specified in the Hold
   Time field of the OPEN message, then the NOTIFICATION message with
   Hold Timer Expired Error Code must be sent and the BGP connection
   closed.

6.6 Finite State Machine error handling.

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

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 connection
   by sending the NOTIFICATION message with Error Code Cease.  However,
   the Cease NOTIFICATION message must not be used when a fatal error
   indicated by this section does exist.

6.8 Connection collision detection.

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



Lougheed & Rekhter                                             [Page 18]

RFC 1267                         BGP-3                      October 1991


   closed.

   Based on the value of the BGP Identifier a convention is established
   for detecting which BGP connection is to be preserved when a
   collision does occur. The convention is to compare the BGP
   Identifiers of the peers involved in the collision and to retain only
   the connection initiated by the BGP speaker with the higher-valued
   BGP Identifier.

   Upon receipt of an OPEN message, the local system must examine all of
   its connections that are in the OpenSent state.  If among them there
   is a connection to a remote BGP speaker whose BGP Identifier equals
   the one in the OPEN message, then the local system performs the
   following collision resolution procedure:

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

          2. If the value of the local BGP Identifier is less than the
          remote one, the local system closes BGP connection that
          already exists (the one that is already in the OpenSent
          state), and accepts 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), and continues to use the existing one (the one
          that is already in the OpenSent state).

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

          A connection collision with existing BGP connections that
          are either in OpenConfirm or Established states causes
          unconditional closing of the newly created connection.  Note
          that a connection collision cannot be detected with
          connections that are in Idle, or Connect, or Active states.

          Closing the BGP connection (that results from the collision
          resolution procedure) is accomplished by sending the
          NOTIFICATION message with the Error Code Cease.

7.  BGP Version Negotiation.

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



Lougheed & Rekhter                                             [Page 19]

RFC 1267                         BGP-3                      October 1991


   Code OPEN Message Error, and an Error Subcode Unsupported Version
   Number, then the BGP speaker has available the version number it
   tried, the version number its peer tried, the version number passed
   by its peer in the NOTIFICATION message, and the version numbers that
   it supports.  If the two peers do support one or more common
   versions, then this will allow them to rapidly determine the highest
   common version. In order to support BGP version negotiation, future
   versions of BGP must retain the format of the OPEN and NOTIFICATION
   messages.

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 BGP
   operations by state as determined by this FSM.  A condensed version
   of 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.  No
         resources are allocated to the BGP neighbor.  In response to
         the Start event (initiated by either system or operator) the
         local system initializes all BGP resources, starts the
         ConnectRetry timer, initiates a transport connection to other
         BGP peer, while listening for connection that may be initiated
         by the remote BGP peer, and changes its state to Connect.
         The exact value of the ConnectRetry timer is a local matter,
         but should be sufficiently large to allow TCP initialization.

         Any other event received in the Idle state is ignored.

      Connect state:

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

         If the transport protocol connection succeeds, the local system
         clears the ConnectRetry timer, completes initialization, sends
         an OPEN message to its peer, and changes its state to OpenSent.

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

         In response to the ConnectRetry timer expired event, the local



Lougheed & Rekhter                                             [Page 20]

RFC 1267                         BGP-3                      October 1991


         system restarts the ConnectRetry timer, initiates a transport
         connection to other BGP peer, continues to listen for a
         connection that may be initiated by the remote BGP peer, and
         stays in the Connect state.

         Start event is ignored in the Active state.

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

      Active state:

         In this state BGP is trying to acquire a BGP neighbor by
         initiating a transport protocol connection.

         If the transport protocol connection succeeds, the local system
         clears the ConnectRetry timer, completes initialization, sends
         an OPEN message to its peer, sets its hold timer to a large
         value, and changes its state to OpenSent.

         In response to the ConnectRetry timer expired event, the local
         system restarts the ConnectRetry timer, initiates a transport
         connection to other BGP peer, continues to listen for a
         connection that may be be initiated by the remote BGP peer, and
         changes its state to Connect.

         If the local system detects that a remote peer is trying to
         establish BGP connection to it, and the IP address of the
         remote peer is not an expected one, the local system restarts
         the ConnectRetry timer, rejects the attempted connection,
         continues to listen for a connection that may be initiated by
         the 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 or
         operator), the local system releases all BGP resources
         associated 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 for
         correctness.  If the BGP message header checking or OPEN
         message checking detects an error (see Section 6.2), or
         a connection collision (see Section 6.8) the local
         system sends a NOTIFICATION message and changes its state to



Lougheed & Rekhter                                             [Page 21]

RFC 1267                         BGP-3                      October 1991


         Idle.

         If there are no errors in the OPEN message, BGP sends a
         KEEPALIVE message and sets a KeepAlive timer.  The hold timer,
         which was originally set to an arbitrary large value (see
         above), is replaced with the value indicated in the OPEN
         message.  If the value of the Autonomous System field is the
         same as our own, then the connection is "internal" connection;
         otherwise, it is "external".  (This will effect UPDATE
         processing as described below.)  Finally, the state is changed
         to OpenConfirm.

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

         If the hold time expires, the local system sends NOTIFICATION
         message with error code Hold Timer Expired and changes its
         state to Idle.

         In response to the Stop event (initiated by either system or
         operator) the local system sends NOTIFICATION message with
         Error 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 sends
         NOTIFICATION message with Error Code Finite State Machine Error
         and changes its state to Idle.

         Whenever BGP changes its state from OpenSent to Idle, it closes
         the BGP (and transport-level) connection and releases all
         resources associated with that connection.

      OpenConfirm state:

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

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

         If the hold timer expires before a KEEPALIVE message is
         received, the local system sends NOTIFICATION message with
         error code Hold Timer expired and changes its state to Idle.




Lougheed & Rekhter                                             [Page 22]

RFC 1267                         BGP-3                      October 1991