rfc1654.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,499 行 · 第 1/5 页

   Messages are sent over a reliable transport protocol connection.  A
   message is processed only after it is entirely received.  The maximum
   message size is 4096 octets.  All implementations are required to
   support this maximum message size.  The smallest message that may be
   sent consists of a BGP header without a data portion, or 19 octets.

4.1 Message Header Format

   Each message has a fixed-size header.  There may or may not be a data
   portion following the header, depending on the message type.  The
   layout of these fields is shown below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                                                               +
      |                           Marker                              |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Length               |      Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict.  If the Type of the message is OPEN, or if
         the Authentication Code used in the OPEN message of the
         connection is zero, then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism



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


         used.  The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

      Length:

         This 2-octet unsigned integer indicates the total length of the
         message, including the header, in octets.  Thus, e.g., it
         allows one to locate in the transport-level stream the (Marker
         field of the) next message.  The value of the Length field must
         always be at least 19 and no greater than 4096, and may be
         further constrained, depending on the message type.  No
         "padding" of extra data after the message is allowed, so the
         Length field must have the smallest value required given the
         rest of the message.

      Type:

         This 1-octet unsigned integer indicates the type code of the
         message.  The following type codes are defined:

                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

4.2 OPEN Message Format

   After a transport protocol connection is established, the first
   message sent by each side is an OPEN message.  If the OPEN message is
   acceptable, a KEEPALIVE message confirming the OPEN is sent back.
   Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
   messages may be exchanged.

   In addition to the fixed-size BGP header, the OPEN message contains
   the following fields:















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


        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+
       |    Version    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     My Autonomous System      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Hold Time           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         BGP Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Auth. Code   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Authentication Data                     |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version:

         This 1-octet unsigned integer indicates the protocol version
         number of the message.  The current BGP version number is 4.

      My Autonomous System:

         This 2-octet unsigned integer indicates the Autonomous System
         number of the sender.

      Hold Time:

         This 2-octet unsigned integer indicates the number of seconds
         that the sender proposes for the value of the Hold Timer.  Upon
         receipt of an OPEN message, a BGP speaker MUST calculate the
         value of the Hold Timer by using the smaller of its configured
         Hold Time and the Hold Time received in the OPEN message.  The
         Hold Time MUST be either zero or at least three seconds.  An
         implementation may reject connections on the basis of the Hold
         Time.  The calculated value indicates the maximum number of
         seconds that may elapse between the receipt of successive
         KEEPALIVE, and/or UPDATE messages by the sender.

      BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer.



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


      Authentication Code:

         This 1-octet unsigned integer indicates the authentication
         mechanism being used.  Whenever an authentication mechanism is
         specified for use within BGP, three things must be included in
         the specification:

         - the value of the Authentication Code which indicates use of
           the mechanism,
         - the form and meaning of the Authentication Data, and
         - the algorithm for computing values of Marker fields.  Only
           one authentication mechanism is specified as part of this
           memo:
         - its Authentication Code is zero,
         - its Authentication Data must be empty (of zero length), and
         - the Marker fields of all messages must be all ones.  The
           semantics of non-zero Authentication Codes lies outside the
           scope of this memo.

         Note that a separate authentication mechanism may be used in
         establishing the transport level connection.

      Authentication Data:

         The form and meaning of this field is a variable-length field
         depend on the Authentication Code.  If the value of
         Authentication Code field is zero, the Authentication Data
         field must have zero length.  The semantics of the non-zero
         length Authentication Data field is outside the scope of this
         memo.

         Note that the length of the Authentication Data field can be
         determined from the message Length field by the formula:

            Message Length = 29 + Authentication Data Length

         The minimum length of the OPEN message is 29 octets (including
         message header).

4.3 UPDATE Message Format

   UPDATE messages are used to transfer routing information between BGP
   peers.  The information in the UPDATE packet can be used to construct
   a graph describing the relationships of the various Autonomous
   Systems.  By applying rules to be discussed, routing information
   loops and some other anomalies may be detected and removed from
   inter-AS routing.




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


   An UPDATE message is used to advertise a single feasible route to a
   peer, or to withdraw multiple unfeasible routes from service (see
   3.1). An UPDATE message may simultaneously advertise a feasible route
   and withdraw multiple unfeasible routes from service.  The UPDATE
   message always includes the fixed-size BGP header, and can optionally
   include the other fields as shown below:

      +-----------------------------------------------------+
      |   Unfeasible Routes Length (2 octets)               |
      +-----------------------------------------------------+
      |  Withdrawn Routes (variable)                        |
      +-----------------------------------------------------+
      |   Total Path Attribute Length (2 octets)            |
      +-----------------------------------------------------+
      |    Path Attributes (variable)                       |
      +-----------------------------------------------------+
      |   Network Layer Reachability Information (variable) |
      +-----------------------------------------------------+

      Unfeasible Routes Length:

         This 2-octets unsigned integer indicates the total length of
         the Withdrawn Routes field in octets.  Its value must allow the
         length of the Network Layer Reachability Information field to
         be determined as specified below.

         A value of 0 indicates that no routes are being withdrawn from
         service, and that the WITHDRAWN ROUTES field is not present in
         this UPDATE message.

      Withdrawn Routes:


         This is a variable length field that contains a list of IP
         address prefixes for the routes that are being withdrawn from
         service.  Each IP address prefix is encoded as a 2-tuple of the
         form <length, prefix>, whose fields are described below:

                  +---------------------------+
                  |   Length (1 octet)        |
                  +---------------------------+
                  |   Prefix (variable)       |
                  +---------------------------+








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


         The use and the meaning of these fields are as follows:

         a) Length:

            The Length field indicates the length in bits of the IP
            address prefix. A length of zero indicates a prefix that
            matches all IP addresses (with prefix, itself, of zero
            octets).

         b) Prefix:

            The Prefix field contains IP address prefixes followed by
            enough trailing bits to make the end of the field fall on an
            octet boundary. Note that the value of trailing bits is
            irrelevant.

      Total Path Attribute Length:

         This 2-octet unsigned integer indicates the total length of the
         Path Attributes field in octets.  Its value must allow the
         length of the Network Layer Reachability field to be determined
         as specified below.

         A value of 0 indicates that no Network Layer Reachability
         Information field is present in this UPDATE message.

      Path Attributes:

         A variable length sequence of path attributes is present in
         every UPDATE.  Each path attribute is a triple <attribute type,
         attribute length, attribute value> of variable length.

         Attribute Type is a two-octet field that consists of the
         Attribute Flags octet followed by the Attribute Type Code