draft-ietf-idr-bgp4-18.txt

xorp源码hg

         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.

   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



Expiration Date April 2003                                     [Page 23]





RFC DRAFT                                                   October 2002


   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
   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 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 2003                                     [Page 24]





RFC DRAFT                                                   October 2002


5.1 Path Attribute Usage


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



5.1.1 ORIGIN


   ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
   shall be 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 shall modify 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 shall update the AS_PATH
      attribute as follows:

         1) if the first path segment of the AS_PATH is of type
         AS_SEQUENCE, the local system shall prepend 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 shall be 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 shall prepend a new path segment of type



Expiration Date April 2003                                     [Page 25]





RFC DRAFT                                                   October 2002


         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 shall include 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 shall include 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 border router that should be used as the next hop to
   the destinations 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



Expiration Date April 2003                                     [Page 26]





RFC DRAFT                                                   October 2002


         peer or is locally originated, the BGP speaker can use for the
         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 announcing
         router's own interfaces, the router 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 BGP speaker must never advertise an address of a peer to that peer
   as a NEXT_HOP, for a route that the speaker is originating. A BGP
   speaker must never install a route with itself as the next hop.



Expiration Date April 2003                                     [Page 27]





RFC DRAFT                                                   October 2002


   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 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 may
   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 number 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 neighboring
   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 pref