draft-ietf-idr-bgp4-22.txt

BCAST Implementation for NS2

                               2 - Bad Peer AS.
                               3 - Bad BGP Identifier.
                               4 - Unsupported Optional Parameter.
                               5 - [Deprecated - see Appendix A].
                               6 - Unacceptable Hold Time.

         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 - [Deprecated - see Appendix A].
                               8 - Invalid NEXT_HOP Attribute.
                               9 - Optional Attribute Error.
                              10 - Invalid Network Field.



Expiration Date April 2004                                     [Page 23]





RFC DRAFT                                                   October 2003


                              11 - Malformed AS_PATH.


      Data:

         This variable-length field is used to diagnose the reason for
         the NOTIFICATION. The contents of the Data field depend upon
         the Error Code and Error Subcode. See Section 6 below for more
         details.

         Note that the length of the Data field can be determined from
         the message Length field by the formula:

                  Message Length = 21 + Data Length

   The minimum length of the NOTIFICATION message is 21 octets (includ-
   ing message header).


5. Path Attributes


   This section discusses the path attributes of the UPDATE message.

   Path attributes fall into four separate categories:

               1. Well-known mandatory.
               2. Well-known discretionary.
               3. Optional transitive.
               4. Optional non-transitive.

   BGP implementations MUST recognize all well-known attributes.  Some
   of these attributes are mandatory and MUST be included in every
   UPDATE message that contains NLRI. Others are discretionary and MAY
   or MAY NOT be sent in a particular UPDATE message.

   Once a BGP peer has updated any well-known attributes, it MUST pass
   these attributes in any updates it transmits to its peers.

   In addition to well-known attributes, each path MAY contain one or
   more optional attributes. It is not required or expected that all BGP
   implementations support all optional attributes. The handling of an
   unrecognized optional attribute is determined by the setting of the
   Transitive bit in the attribute flags octet. Paths with unrecognized
   transitive optional attributes SHOULD be accepted. If a path with
   unrecognized transitive optional attribute is accepted and passed
   along to other BGP peers, then the unrecognized transitive optional
   attribute of that path MUST be passed along with the path to other



Expiration Date April 2004                                     [Page 24]





RFC DRAFT                                                   October 2003


   BGP peers with the Partial bit in the Attribute Flags octet set to 1.
   If a path with recognized transitive optional attribute is accepted
   and passed along to other BGP peers and the Partial bit in the
   Attribute Flags octet is set to 1 by some previous AS, it MUST NOT be
   set back to 0 by the current AS. Unrecognized non-transitive optional
   attributes MUST be quietly ignored and not passed along to other BGP
   peers.

   New transitive optional attributes MAY be attached to the path by the
   originator or by any other BGP speaker in the path. If they are not
   attached by the originator, the Partial bit in the Attribute Flags
   octet is set to 1. The rules for attaching new non-transitive
   optional attributes will depend on the nature of the specific
   attribute. The documentation of each new non-transitive optional
   attribute will be expected to include such rules. (The description of
   the MULTI_EXIT_DISC attribute gives an example.) All optional
   attributes (both transitive and non-transitive) MAY be updated (if
   appropriate) by BGP speakers in the path.

   The sender of an UPDATE message SHOULD order path attributes within
   the UPDATE message in ascending order of attribute type. The receiver
   of an UPDATE message MUST be prepared to handle path attributes
   within the UPDATE message that are out of order.

   The same attribute (attribute with the same type) can not appear more
   than once within the Path Attributes field of a particular UPDATE
   message.

   The mandatory category refers to an attribute which MUST be present
   in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE
   message.  Attributes classified as optional for the purpose of the
   protocol extension mechanism may be purely discretionary, or discre-
   tionary, required, or disallowed in certain contexts.

        attribute           EBGP                    IBGP
         ORIGIN             mandatory               mandatory
         AS_PATH            mandatory               mandatory
         NEXT_HOP           mandatory               mandatory
         MULTI_EXIT_DISC    discretionary           discretionary
         LOCAL_PREF         see Section 5.1.5       required
         ATOMIC_AGGREGATE   see Section 5.1.6 and 9.1.4
         AGGREGATOR         discretionary           discretionary









Expiration Date April 2004                                     [Page 25]





RFC DRAFT                                                   October 2003


5.1 Path Attribute Usage


   The usage of each BGP path attribute is described in the following
   clauses.



5.1.1 ORIGIN


   ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is
   generated by the speaker that originates the associated routing
   information. Its value SHOULD NOT be changed by any other speaker.


5.1.2 AS_PATH


   AS_PATH is a well-known mandatory attribute. This attribute identi-
   fies the autonomous systems through which routing information carried
   in this UPDATE message has passed. The components of this list can be
   AS_SETs or AS_SEQUENCEs.

   When a BGP speaker propagates a route which it has learned from
   another BGP speaker's UPDATE message, it modifies the route's AS_PATH
   attribute based on the location of the BGP speaker to which the route
   will be sent:

      a) When a given BGP speaker advertises the route to an internal
      peer, the advertising speaker SHALL NOT modify the AS_PATH
      attribute associated with the route.

      b) When a given BGP speaker advertises the route to an external
      peer, then the advertising speaker updates the AS_PATH attribute
      as follows:

         1) if the first path segment of the AS_PATH is of type
         AS_SEQUENCE, the local system prepends its own AS number as the
         last element of the sequence (put it in the leftmost position
         with respect to the position of octets in the protocol mes-
         sage). If the act of prepending will cause an overflow in the
         AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
         new segment of type AS_SEQUENCE and prepend its own AS number
         to this new segment.

         2) if the first path segment of the AS_PATH is of type AS_SET,
         the local system prepends a new path segment of type



Expiration Date April 2004                                     [Page 26]





RFC DRAFT                                                   October 2003


         AS_SEQUENCE to the AS_PATH, including its own AS number in that
         segment.

   When a BGP speaker originates a route then:

      a) the originating speaker includes its own AS number in a path
      segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE
      messages sent to an external peer. (In this case, the AS number of
      the originating speaker's autonomous system will be the only entry
      the path segment, and this path segment will be the only segment
      in the AS_PATH attribute).

      b) the originating speaker includes an empty AS_PATH attribute in
      all UPDATE messages sent to internal peers.  (An empty AS_PATH
      attribute is one whose length field contains the value zero).

   Whenever the modification of the AS_PATH attribute calls for includ-
   ing or prepending the AS number of the local system, the local system
   MAY include/prepend more than one instance of its own AS number in
   the AS_PATH attribute. This is controlled via local configuration.


5.1.3 NEXT_HOP


   The NEXT_HOP is a well-known mandatory attribute that defines the IP
   address of the router that SHOULD be used as the next hop to the des-
   tinations listed in the UPDATE message. The NEXT_HOP attribute is
   calculated as follows.

      1) When sending a message to an internal peer, if the route is not
      locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP
      attribute, unless it has been explicitly configured to announce
      its own IP address as the NEXT_HOP. When announcing a locally
      originated route to an internal peer, the BGP speaker SHOULD use
      as the NEXT_HOP the interface address of the router through which
      the announced network is reachable for the speaker; if the route
      is directly connected to the speaker, or the interface address of
      the router through which the announced network is reachable for
      the speaker is the internal peer's address, then the BGP speaker
      SHOULD use for the NEXT_HOP attribute its own IP address (the
      address of the interface that is used to reach the peer).

      2) When sending a message to an external peer X, and the peer is
      one IP hop away from the speaker:

         - If the route being announced was learned from an internal
         peer or is locally originated, the BGP speaker can use for the



Expiration Date April 2004                                     [Page 27]





RFC DRAFT                                                   October 2003


         NEXT_HOP attribute an interface address of the internal peer
         router (or the internal router) through which the announced
         network is reachable for the speaker, provided that peer X
         shares a common subnet with this address. This is a form of
         "third party" NEXT_HOP attribute.

         - Otherwise, if the route being announced was learned from an
         external peer, the speaker can use in the NEXT_HOP attribute an
         IP address of any adjacent router (known from the received
         NEXT_HOP attribute) that the speaker itself uses for local
         route calculation, provided that peer X shares a common subnet
         with this address. This is a second form of "third party"
         NEXT_HOP attribute.

         - Otherwise, if the external peer to which the route is being
         advertised shares a common subnet with one of the interfaces of
         the announcing BGP speaker, the speaker MAY use the IP address
         associated with such an interface in the NEXT_HOP attribute.
         This is known as a "first party" NEXT_HOP attribute.

         - By default (if none of the above conditions apply), the BGP
         speaker SHOULD use in the NEXT_HOP attribute the IP address of
         the interface that the speaker uses to establish the BGP con-
         nection to peer X.

      3) When sending a message to an external peer X, and the peer is
      multiple IP hops away from the speaker (aka "multihop EBGP"):

         - The speaker MAY be configured to propagate the NEXT_HOP
         attribute.  In this case when advertising a route that the
         speaker learned from one of its peers, the NEXT_HOP attribute
         of the advertised route is exactly the same as the NEXT_HOP
         attribute of the learned route (the speaker just doesn't modify
         the NEXT_HOP attribute).

         - By default, the BGP speaker SHOULD use in the NEXT_HOP
         attribute the IP address of the interface that the speaker uses
         to establish the BGP connection to peer X.

   Normally the NEXT_HOP attribute is chosen such that the shortest
   available path will be taken. A BGP speaker MUST be able to support
   disabling advertisement of third party NEXT_HOP attributes to handle
   imperfectly bridged media.

   A route originated by a BGP speaker SHALL NOT be advertised to a peer
   using an address of that peer as NEXT_HOP. A BGP speaker SHALL NOT
   install a route with itself as the next hop.




Expiration Date April 2004                                     [Page 28]





RFC DRAFT                                                   October 2003


   The NEXT_HOP attribute is used by the BGP speaker to determine the
   actual outbound interface and immediate next-hop address that SHOULD
   be used to forward transit packets to the associated destinations.

   The immediate next-hop address is determined by performing a recur-
   sive route lookup operation for the IP address in the NEXT_HOP
   attribute using the contents of the Routing Table, selecting one
   entry if