draft-ietf-idr-bgp4-12.txt

xorp源码hg

       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Error Code:

         This 1-octet unsigned integer indicates the type of
         NOTIFICATION.  The following Error Codes have been defined:

            Error Code       Symbolic Name               Reference

              1         Message Header Error             Section 6.1

              2         OPEN Message Error               Section 6.2

              3         UPDATE Message Error             Section 6.3

              4         Hold Timer Expired               Section 6.5

              5         Finite State Machine Error       Section 6.6

              6         Cease                            Section 6.7


      Error subcode:

         This 1-octet unsigned integer provides more specific
         information about the nature of the reported error.  Each Error
         Code may have one or more Error Subcodes associated with it.
         If no appropriate Error Subcode is defined, then a zero
         (Unspecific) value is used for the Error Subcode field.




Expiration Date July 2001                                      [Page 18]





RFC DRAFT                                                   January 2001


         Message Header Error subcodes:

                               1  - Connection Not Synchronized.
                               2  - Bad Message Length.
                               3  - Bad Message Type.

         OPEN Message Error subcodes:

                               1  - Unsupported Version Number.
                               2  - Bad Peer AS.
                               3  - Bad BGP Identifier.
                               4  - Unsupported Optional Parameter.
                               5  - Authentication Failure.
                               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
                               8 - Invalid NEXT_HOP Attribute.
                               9 - Optional Attribute Error.
                              10 - Invalid Network Field.
                              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
   (including message header).








Expiration Date July 2001                                      [Page 19]





RFC DRAFT                                                   January 2001


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
   updating, 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 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 AS 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 ASs in the path.




Expiration Date July 2001                                      [Page 20]





RFC DRAFT                                                   January 2001


   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 cannot 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
   discretionary, 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         disallowed              required
         ATOMIC_AGGREGATE   see section 5.1.6 and 9.1.4
         AGGREGATOR         discretionary           discretionary




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 autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers.


5.1.2   AS_PATH


   AS_PATH is a well-known mandatory attribute. This attribute



Expiration Date July 2001                                      [Page 21]





RFC DRAFT                                                   January 2001


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

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


5.1.3 NEXT_HOP


   The NEXT_HOP path attribute defines the IP address of the border
   router that should be used as the next hop to the destinations listed
   in the UPDATE message.  When advertising a NEXT_HOP attribute to an



Expiration Date July 2001                                      [Page 22]





RFC DRAFT                                                   January 2001


   external peer, a router may use one of its own interface addresses in
   the NEXT_HOP attribute provided the external peer to which the route
   is being advertised shares a common subnet with the NEXT_HOP address.
   This is known as a "first party" NEXT_HOP attribute.  A BGP speaker
   can advertise to an external peer an interface of any internal peer
   router in the NEXT_HOP attribute provided the external peer to which
   the route is being advertised shares a common subnet with the
   NEXT_HOP address.  This is known as a "third party" NEXT_HOP
   attribute.  A BGP speaker can advertise any adjacent router in the
   NEXT_HOP attribute provided that the IP address of this router was
   learned from an external peer and the external peer to which the
   route is being advertised shares a common subnet with the NEXT_HOP
   address. This is a second form of "third party" NEXT_HOP attribute.

   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.

   When a BGP speaker advertises the route to an internal peer, the
   advertising speaker should not modify the NEXT_HOP attribute
   associated with the route.  When a BGP speaker receives the route via
   an internal link, it may forward packets to the NEXT_HOP address if
   the address contained in the attribute is on a common subnet with the
   local and remote BGP speakers.


5.1.4   MULTI_EXIT_DISC


   The MULTI_EXIT_DISC attribute 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 or entry point with lower metric should be
   preferred.  If received over external links, the MULTI_EXIT_DISC
   attribute MAY be propagated over internal links 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 either prior to or after determining the
   degree of preference of the route and performing route selection



Expiration Date July 2001                                      [Page 23]





RFC DRAFT                                                   January 2001