rfc1654.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,534 行 · 第 1/5 页

Rekhter & Li                                                   [Page 22]

RFC 1654                         BGP-4                         July 1994


6.1 Message Header error handling.

   All errors detected while processing the Message Header are indicated
   by sending the NOTIFICATION message with Error Code Message Header
   Error.  The Error Subcode elaborates on the specific nature of the
   error.

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN.  The expected value of the Marker
   field for all other types of BGP messages determined based on the
   Authentication Code in the BGP OPEN message and the actual
   authentication mechanism (if the Authentication Code in the BGP OPEN
   message is non-zero). If the Marker field of the message header is
   not the expected one, then a synchronization error has occurred and
   the Error Subcode is set to Connection Not Synchronized.

   If the Length field of the message header is less than 19 or greater
   than 4096, or if the Length field of an OPEN message is less  than
   the minimum length of the OPEN message, or if the Length field of an
   UPDATE message is less than the minimum length of the UPDATE message,
   or if the Length field of a KEEPALIVE message is not equal to 19, or
   if the Length field of a NOTIFICATION message is less than the
   minimum length of the NOTIFICATION message, then the Error Subcode is
   set to Bad Message Length.  The Data field contains the erroneous
   Length field.

   If the Type field of the message header is not recognized, then the
   Error Subcode is set to Bad Message Type.  The Data field contains
   the erroneous Type field.

6.2 OPEN message error handling.

   All errors detected while processing the OPEN message are indicated
   by sending the NOTIFICATION message with Error Code OPEN Message
   Error.  The Error Subcode elaborates on the specific nature of the
   error.

   If the version number contained in the Version field of the received
   OPEN message is not supported, then the Error Subcode is set to
   Unsupported Version Number.  The Data field is a 2-octet unsigned
   integer, which indicates the largest locally supported version number
   less than the version the remote BGP peer bid (as indicated in the
   received OPEN message).

   If the Autonomous System field of the OPEN message is unacceptable,
   then the Error Subcode is set to Bad Peer AS.  The determination of
   acceptable Autonomous System numbers is outside the scope of this
   protocol.



Rekhter & Li                                                   [Page 23]

RFC 1654                         BGP-4                         July 1994


   If the Hold Time field of the OPEN message is unacceptable, then the
   Error Subcode MUST be set to Unacceptable Hold Time.  An
   implementation MUST reject Hold Time values of one or two seconds.
   An implementation MAY reject any proposed Hold Time.  An
   implementation which accepts a Hold Time MUST use the negotiated
   value for the Hold Time.

   If the BGP Identifier field of the OPEN message is syntactically
   incorrect, then the Error Subcode is set to Bad BGP Identifier.
   Syntactic correctness means that the BGP Identifier field represents
   a valid IP host address.

   If the Authentication Code of the OPEN message is not recognized,
   then the Error Subcode is set to Unsupported Authentication Code.  If
   the Authentication Code is zero, then the Authentication Data must be
   of zero length.  Otherwise, the Error Subcode is set to
   Authentication Failure.

   If the Authentication Code is non-zero, then the corresponding
   authentication procedure is invoked.  If the authentication procedure
   (based on Authentication Code and Authentication Data) fails, then
   the Error Subcode is set to Authentication Failure.

6.3 UPDATE message error handling.

   All errors detected while processing the UPDATE message are indicated
   by sending the NOTIFICATION message with Error Code UPDATE Message
   Error.  The error subcode elaborates on the specific nature of the
   error.

   Error checking of an UPDATE message begins by examining the path
   attributes.  If the Unfeasible Routes Length or Total Attribute
   Length is too large (i.e., if Unfeasible Routes Length + Total
   Attribute Length + 23 exceeds the message Length), then the Error
   Subcode is set to Malformed Attribute List.

   If any recognized attribute has Attribute Flags that conflict with
   the Attribute Type Code, then the Error Subcode is set to Attribute
   Flags Error.  The Data field contains the erroneous attribute (type,
   length and value).

   If any recognized attribute has Attribute Length that conflicts with
   the expected length (based on the attribute type code), then the
   Error Subcode is set to Attribute Length Error.  The Data field
   contains the erroneous attribute (type, length and value).

   If any of the mandatory well-known attributes are not present, then
   the Error Subcode is set to Missing Well-known Attribute.  The Data



Rekhter & Li                                                   [Page 24]

RFC 1654                         BGP-4                         July 1994


   field contains the Attribute Type Code of the missing well-known
   attribute.

   If any of the mandatory well-known attributes are not recognized,
   then the Error Subcode is set to Unrecognized Well-known Attribute.
   The Data field contains the unrecognized attribute (type, length and
   value).

   If the ORIGIN attribute has an undefined value, then the Error
   Subcode is set to Invalid Origin Attribute.  The Data field contains
   the unrecognized attribute (type, length and value).

   If the NEXT_HOP attribute field is syntactically 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 and is not the IP address of the receiving BGP
   speaker.  If the NEXT_HOP attribute is semantically incorrect, the
   error should be logged, and the the route should be ignored.  In this
   case, no NOTIFICATION message should be sent.

   The AS_PATH attribute is checked for syntactic correctness.  If the
   path is syntactically incorrect, then the Error Subcode is set to
   Malformed AS_PATH.

   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.

   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.

   The NLRI field in the UPDATE message is checked for syntactic
   validity.  If the field is syntactically incorrect, 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



Rekhter & Li                                                   [Page 25]

RFC 1654                         BGP-4                         July 1994


   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
   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 OpenConfirm state.  A BGP speaker may
   also examine connections in an OpenSent state if it knows the BGP
   Identifier of the peer by means outside of the protocol.  If among
   these connections 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:




Rekhter & Li                                                   [Page 26]

RFC 1654                         BGP-4                         July 1994


      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 OpenConfirm 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
      OpenConfirm state).

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

      A connection collision with an existing BGP connection that is in
      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
   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.



Rekhter & Li                                                   [Page 27]

RFC 1654                         BGP-4                         July 1994


      Initially BGP is in the Idle state.

      Idle state:

         In this state BGP refuses all incoming BGP connections.  No
         resources are allocated to the peer.  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.

         If a BGP speaker detects an error, it shuts down the connection
         and changes its state to Idle. Getting o