rfc1267.txt

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

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version:

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

   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 maximum number of
      seconds that may elapse between the receipt of successive
      KEEPALIVE and/or UPDATE and/or NOTIFICATION messages.


   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 the IP address of one of its interfaces.
      The value of the BGP Identifier is determined on startup
      and is the same for every local interface and every BGP peer.

   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:



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


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

   In addition to the fixed-size BGP header, the UPDATE message contains
   the following fields (note that all fields may have arbitrary
   alignment):








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


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Total Path Attributes Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    /                      Path Attributes                          /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Network 1                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Network n                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 (non-
      negative integer) number of Network fields to be determined as
      specified below.

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

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attr. Flags  |Attr. Type Code|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The high-order bit (bit 0) of the Attribute Flags octet is the
      Optional bit.  It defines whether the attribute is optional (if
      set to 1) or well-known (if set to 0).

      The second high-order bit (bit 1) of the Attribute Flags octet is
      the Transitive bit.  It defines whether an optional attribute is
      transitive (if set to 1) or non-transitive (if set to 0).  For
      well-known attributes, the Transitive bit must be set to 1.  (See
      Section 5 for a discussion of transitive attributes.)



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


      The third high-order bit (bit 2) of the Attribute Flags octet is
      the Partial bit.  It defines whether the information contained in
      the optional transitive attribute is partial (if set to 1) or
      complete (if set to 0).  For well-known attributes and for
      optional non-transitive attributes the Partial bit must be set to
      0.

      The fourth high-order bit (bit 3) of the Attribute Flags octet is
      the Extended Length bit.  It defines whether the Attribute Length
      is one octet (if set to 0) or two octets (if set to 1).  Extended
      Length may be used only if the length of the attribute value is
      greater than 255 octets.

      The lower-order four bits of the Attribute Flags octet are unused.
      They must be zero (and must be ignored when received).

      The Attribute Type Code octet contains the Attribute Type Code.
      Currently defined Attribute Type Codes are discussed in Section 5.

      If the Extended Length bit of the Attribute Flags octet is set to
      0, the third octet of the Path Attribute contains the length of
      the attribute data in octets.

      If the Extended Length bit of the Attribute Flags octet is set to
      1, then the third and the fourth octets of the path attribute
      contain the length of the attribute data in octets.

      The remaining octets of the Path Attribute represent the attribute
      value and are interpreted according to the Attribute Flags and the
      Attribute Type Code.

      The meaning and handling of Path Attributes is discussed in
      Section 5.

   Network:

      Each 4-octet Internet network number indicates one network whose
      Inter-Autonomous System routing is described by the Path
      Attributes.  Subnets and host addresses are specifically not
      allowed.  The total number of Network fields in the UPDATE message
      can be determined by the formula:

         Message Length = 19 + Total Path Attribute Length + 4 * #Nets

      The message Length field of the message header and the Path
      Attributes Length field of the UPDATE message must be such that
      the formula results in a non-negative integer number of Network
      fields.



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


   The minimum length of the UPDATE message is 37 octets (including
   message header).

4.4 KEEPALIVE Message Format

   BGP does not use any transport protocol-based keep-alive mechanism to
   determine if peers are reachable.  Instead, KEEPALIVE messages are
   exchanged between peers often enough as not to cause the hold time
   (as advertised in the OPEN message) to expire.  A reasonable maximum
   time between KEEPALIVE messages would be one third of the Hold Time
   interval.

   KEEPALIVE message consists of only message header and has a length of
   19 octets.

4.5 NOTIFICATION Message Format

   A NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after sending it.

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

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Error code    | Error subcode |           Data                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Error Code:

      This 1-octet unsigned integer indicates the type of NOTIFICATION.
      The following Error Codes have been defined:

           Error Code       Symbolic Name               Reference

             1         Message Header Error             Section 6.1
             2         OPEN Message Error               Section 6.2
             3         UPDATE Message Error             Section 6.3
             4         Hold Timer Expired               Section 6.5
             5         Finite State Machine Error       Section 6.6
             6         Cease                            Section 6.7






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


   Error subcode:

      This 1-octet unsigned integer provides more specific information
      about the nature of the reported error.  Each Error Code may have
      one or more Error Subcodes associated with it.  If no appropriate
      Error Subcode is defined, then a zero (Unspecific) value is used
      for the Error Subcode field.

      Message Header Error subcodes:

                      1  - Connection Not Synchronized.
                      2  - Bad Message Length.
                      3  - Bad Message Type.

      OPEN Message Error subcodes:

                      1  - Unsupported Version Number.
                      2  - Bad Peer AS.
                      3  - Bad BGP Identifier.
                      4  - Unsupported Authentication Code.
                      5  - Authentication Failure.

      UPDATE Message Error subcodes:

                      1 - Malformed Attribute List.
                      2 - Unrecognized Well-known Attribute.
                      3 - Missing Well-known Attribute.
                      4 - Attribute Flags Error.
                      5 - Attribute Length Error.
                      6 - Invalid ORIGIN Attribute
                      7 - AS Routing Loop.
                      8 - Invalid NEXT_HOP Attribute.
                      9 - Optional Attribute Error.
                     10 - Invalid Network Field.


   Data: