rfc1163.txt

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

   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
    +-+-+-+-+-+-+-+-+
    |    Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     My Autonomous System      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Hold Time           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Auth. Code   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                       Authentication Data                     |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version:

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






Lougheed & Rekhter                                              [Page 6]

RFC 1163                          BGP                          June 1990


   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.

   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 = 25 + Authentication Data Length

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




Lougheed & Rekhter                                              [Page 7]

RFC 1163                          BGP                          June 1990


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

     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.






Lougheed & Rekhter                                              [Page 8]

RFC 1163                          BGP                          June 1990


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

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



Lougheed & Rekhter                                              [Page 9]

RFC 1163                          BGP                          June 1990


      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.

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




Lougheed & Rekhter                                             [Page 10]

RFC 1163                          BGP                          June 1990


   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

   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  - Unsupported Authentication Code.
                      4  - 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.




Lougheed & Rekhter                                             [Page 11]