draft-ietf-idr-bgp4-13.txt

xorp源码hg

RFC DRAFT                                                 September 2001


4.5 NOTIFICATION Message Format


   A NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after sending it.

   In addition to the fixed-size BGP header, the NOTIFICATION 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Error code    | Error subcode |           Data                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      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 March 2002                                     [Page 18]





RFC DRAFT                                                 September 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 March 2002                                     [Page 19]





RFC DRAFT                                                 September 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 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.




Expiration Date March 2002                                     [Page 20]





RFC DRAFT                                                 September 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 March 2002                                     [Page 21]





RFC DRAFT                                                 September 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).

   For the purpose of inter-AS traffic engineering, a BGP speaker may
   include more than one instance of its own AS number in the AS_PATH
   attribute. This is controlled via local configuration.








Expiration Date March 2002                                     [Page 22]





RFC DRAFT                                                 September 2001


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. The NEXT_HOP attribute is calculated as
   follows.

      1) When sending a message to an internal peer, 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.

      2) When sending a message to an external peer X:

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

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

         - 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