draft-ietf-idr-bgp4-13.txt

xorp源码hg

   construct the forwarding table that is used for packet forwarding) is
   maintained in the Routing Table. The Routing Table accumulates routes
   to directly connected networks, static routes, routes learned from
   the IGP protocols, and routes learned from BGP.  Whether or not a
   specific BGP route should be installed in the Routing Table, and
   whether a BGP route should override a route to the same destination
   installed by another source is a local policy decision, not specified
   in this document. Besides actual packet forwarding, the Routing Table
   is used for resolution of the next-hop addresses specified in BGP
   updates (see Section 9.1.2).






Expiration Date March 2002                                      [Page 6]





RFC DRAFT                                                 September 2001


4. Message Formats

   This section describes message formats used by BGP.

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



Expiration Date March 2002                                      [Page 7]





RFC DRAFT                                                 September 2001


         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:


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



Expiration Date March 2002                                      [Page 8]





RFC DRAFT                                                 September 2001


       |                       Optional Parameters                     |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      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 March 2002                                      [Page 9]





RFC DRAFT                                                 September 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.

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



Expiration Date March 2002                                     [Page 10]





RFC DRAFT                                                 September 2001


               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:


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



      Withdrawn 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



Expiration Date March 2002                                     [Page 11]





RFC DRAFT                                                 September 2001


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