draft-ietf-idr-bgp4-12.txt

xorp源码hg

Expiration Date July 2001                                       [Page 6]





RFC DRAFT                                                   January 2001


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 OPEN message carries no Authentication Information (as an
         Optional Parameter), 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
         (which is specified as part of the Authentication Information)
         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



Expiration Date July 2001                                       [Page 7]





RFC DRAFT                                                   January 2001


         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:




        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                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opt Parm Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Optional Parameters                     |
       |                                                               |



Expiration Date July 2001                                       [Page 8]





RFC DRAFT                                                   January 2001


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



      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.

      Optional Parameters Length:

         This 1-octet unsigned integer indicates the total length of the
         Optional Parameters field in octets. If the value of this field
         is zero, no Optional Parameters are present.

      Optional Parameters:

         This field may contain a list of optional parameters, where
         each parameter is encoded as a <Parameter Type, Parameter
         Length, Parameter Value> triplet.






Expiration Date July 2001                                       [Page 9]





RFC DRAFT                                                   January 2001


                0                   1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
               |  Parm. Type   | Parm. Length  |  Parameter Value (variable)
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...


         Parameter Type is a one octet field that unambiguously
         identifies individual parameters. Parameter Length is a one
         octet field that contains the length of the Parameter Value
         field in octets.  Parameter Value is a variable length field
         that is interpreted according to the value of the Parameter
         Type field.

         This document defines the following Optional Parameters:

         a) Authentication Information (Parameter Type 1):


            This optional parameter may be used to authenticate a BGP
            peer. The Parameter Value field contains a 1-octet
            Authentication Code followed by a variable length
            Authentication Data.


                0 1 2 3 4 5 6 7 8
                +-+-+-+-+-+-+-+-+
                |  Auth. Code   |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                                                     |
                |              Authentication Data                    |
                |                                                     |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



               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.




Expiration Date July 2001                                      [Page 10]





RFC DRAFT                                                   January 2001


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

               Authentication Data:

                  Authentication Data is a variable length field that is
                  interpreted according to the value of the
                  Authentication Code field.


         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.

   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:




Expiration Date July 2001                                      [Page 11]





RFC DRAFT                                                   January 2001


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


         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