draft-ietf-idr-bgp4-22.txt

BCAST Implementation for NS2

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


4. Message Formats

   This section describes message formats used by BGP.

   BGP messages are sent over a TCP 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 mes-
   sage size. The smallest message that may be sent consists of a BGP
   header without a data portion, or 19 octets.

   All multi-octet fields are in network byte order.


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 lay-
   out of these fields is shown below:










Expiration Date April 2004                                     [Page 12]





RFC DRAFT                                                   October 2003


      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 is included for compatibility; it MUST be
         set to all ones.

      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 TCP 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. This document defines the following type codes:

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

         [RFC2918] defines one more type code.


4.2 OPEN Message Format

   After a TCP connection is established, the first message sent by each
   side is an OPEN message. If the OPEN message is acceptable, a



Expiration Date April 2004                                     [Page 13]





RFC DRAFT                                                   October 2003


   KEEPALIVE message confirming the OPEN is sent back.

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


      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:



Expiration Date April 2004                                     [Page 14]





RFC DRAFT                                                   October 2003


         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP Iden-
         tifier 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 contains a list of optional parameters, where each
         parameter is encoded as a <Parameter Type, Parameter Length,
         Parameter Value> triplet.

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

         [RFC3392] defines the Capabilities Optional Parameter.

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


4.3 UPDATE Message Format


   UPDATE messages are used to transfer routing information between BGP
   peers. The information in the UPDATE message can be used to construct
   a graph describing the relationships of the various Autonomous Sys-
   tems. 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 feasible routes sharing common
   path attributes to a peer, or to withdraw multiple unfeasible routes



Expiration Date April 2004                                     [Page 15]





RFC DRAFT                                                   October 2003


   from service (see 3.1). An UPDATE message MAY simultaneously adver-
   tise a feasible route and withdraw multiple unfeasible routes from
   service. The UPDATE message always includes the fixed-size BGP
   header, and also includes the other fields as shown below (note, some
   of the shown fields may not be present in every UPDATE message):

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




Expiration Date April 2004                                     [Page 16]





RFC DRAFT                                                   October 2003


            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 an IP address prefix followed by
            the minimum number of trailing bits needed 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 allows the length of
         the Network Layer Reachability field to be determined as speci-
         fied 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 message, except for an UPDATE message that carries
         only the withdrawn routes. 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.