draft-ietf-idr-bgp4-20.txt

xorp源码hg

   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.

   Well-known attributes MUST be recognized by all BGP implementations.
   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.

   All well-known attributes MUST be passed along (after proper updat-
   ing, if necessary) to other BGP 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 October 2003                                   [Page 23]





RFC DRAFT                                                     April 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 is not 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 October 2003                                   [Page 24]





RFC DRAFT                                                     April 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).
         If the act of prepending will cause an overflow in the AS_PATH
         segment, i.e. more than 255 ASs, it is legal to 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
         AS_SEQUENCE to the AS_PATH, including its own AS number in that



Expiration Date October 2003                                   [Page 25]





RFC DRAFT                                                     April 2003


         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
         NEXT_HOP attribute an interface address of the internal peer



Expiration Date October 2003                                   [Page 26]





RFC DRAFT                                                     April 2003


         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.

   The NEXT_HOP attribute is used by the BGP speaker to determine the



Expiration Date October 2003                                   [Page 27]





RFC DRAFT                                                     April 2003


   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 multiple entries of equal cost exist.  The Routing Table
   entry which resolves the IP address in the NEXT_HOP attribute will
   always specify the outbound interface. If the entry specifies an
   attached subnet, but does not specify a next-hop address, then the
   address in the NEXT_HOP attribute SHOULD be used as the immediate
   next-hop address.  If the entry also specifies the next-hop address,
   this address SHOULD be used as the immediate next-hop address for
   packet forwarding.


5.1.4 MULTI_EXIT_DISC


   The MULTI_EXIT_DISC is an optional non-transitive attribute which is
   intended to be used on external (inter-AS) links to discriminate
   among multiple exit or entry points to the same neighboring AS.  The
   value of the MULTI_EXIT_DISC attribute is a four octet unsigned num-
   ber which is called a metric. All other factors being equal, the exit
   point with lower metric SHOULD be preferred. If received over EBGP,
   the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to other
   BGP speakers within the same AS. The MULTI_EXIT_DISC attribute
   received from a neighboring AS MUST NOT be propagated to other neigh-
   boring ASs.

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.  This MAY
   be done prior to determining the degree of preference of the route
   and performing route selection (decision process phases 1 and 2). See
   Section 9.1.2.2 for necessary restrictions on this.


5.1.5 LOCAL_PREF


   LOCAL_PREF is a well-known attribute that SHALL be included in all
   UPDATE messages that a given BGP speaker sends to the other internal



Expiration Date October 2003