rfc1654.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,534 行 · 第 1/5 页

         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.

         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 Authentication Code.
                               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
                               7 - AS Routing Loop.
                               8 - Invalid NEXT_HOP Attribute.



Rekhter & Li                                                   [Page 17]

RFC 1654                         BGP-4                         July 1994


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

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



Rekhter & Li                                                   [Page 18]

RFC 1654                         BGP-4                         July 1994


   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.

   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.

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



Rekhter & Li                                                   [Page 19]

RFC 1654                         BGP-4                         July 1994


   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 another BGP
      speaker located in its own autonomous system, the advertising
      speaker shall not modify the AS_PATH attribute associated with the
      route.

      b) When a given BGP speaker advertises the route to a BGP speaker
      located in a neighboring autonomous system, 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 BGP
         speakers located in neighboring autonomous systems. (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 BGP speakers located
         in its own autonomous system. (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 networks listed in
   the UPDATE message.  If a border router belongs to the same AS as its
   peer, then the peer is an internal border router. Otherwise, it is an
   external border router.  A BGP speaker can advertise any internal
   border router as the next hop provided that the interface associated
   with the IP address of this border router (as specified in the
   NEXT_HOP path attribute) shares a common subnet with both the local
   and remote BGP speakers. A BGP speaker can advertise any external
   border router as the next hop, provided that the IP address of this
   border router was learned from one of the BGP speaker's peers, and



Rekhter & Li                                                   [Page 20]

RFC 1654                         BGP-4                         July 1994


   the interface associated with the IP address of this border router
   (as specified in the NEXT_HOP path attribute) shares a common subnet
   with the local and remote BGP speakers.  A BGP speaker needs to be
   able to support disabling advertisement of external border routers.

   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 a BGP speaker located in
   its own autonomous system, the advertising speaker shall 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 is never
   propagated to other BGP speakers in neighboring AS's.

5.1.5   LOCAL_PREF

   LOCAL_PREF is a well-known discretionary attribute that shall be
   included in all UPDATE messages that a given BGP speaker sends to the
   other BGP speakers located in its own autonomous system. A BGP
   speaker shall calculate the degree of preference for each external
   route and include the degree of preference when advertising a route
   to its internal peers. The higher degree of preference should be
   preferred. A BGP speaker shall use the degree of preference learned
   via LOCAL_PREF in its decision process (see section 9.1.1).

   A BGP speaker shall not include this attribute in UPDATE messages
   that it sends to BGP speakers located in a neighboring autonomous
   system. If it is contained in an UPDATE message that is received from
   a BGP speaker which is not located in the same autonomous system as
   the receiving speaker, then this attribute shall be ignored by the
   receiving speaker.






Rekhter & Li                                                   [Page 21]

RFC 1654                         BGP-4                         July 1994


5.1.6   ATOMIC_AGGREGATE

   ATOMIC_AGGREGATE is a well-known discretionary attribute.  If a BGP
   speaker, when presented with a set of overlapping routes from one of
   its peers (see 9.1.4), selects the less specific route without
   selecting the more specific one, then the local system shall attach
   the ATOMIC_AGGREGATE attribute to the route when propagating it to
   other BGP speakers (if that attribute is not already present in the
   received less specific route). A BGP speaker that receives a route
   with the ATOMIC_AGGREGATE attribute shall not remove the attribute
   from the route when propagating it to other speakers. A BGP speaker
   that receives a route with the ATOMIC_AGGREGATE attribute shall not
   make any NLRI of that route more specific (as defined in 9.1.4) when
   advertising this route to other BGP speakers.  A BGP speaker that
   receives a route with the ATOMIC_AGGREGATE attribute needs to be
   cognizant of the fact that the actual path to destinations, as
   specified in the NLRI of the route, while having the loop-free
   property, may traverse ASs that are not listed in the AS_PATH
   attribute.

5.1.7   AGGREGATOR

   AGGREGATOR is an optional transitive attribute which may be included
   in updates which are formed by aggregation (see Section 9.2.4.2).  A
   BGP speaker which performs route aggregation may add the AGGREGATOR
   attribute which shall contain its own AS number and IP address.

6.  BGP Error Handling.

   This section describes actions to be taken when errors are detected
   while processing BGP messages.

   When any of the conditions described here are detected, a
   NOTIFICATION message with the indicated Error Code, Error Subcode,
   and Data fields is sent, and the BGP connection is closed.  If no
   Error Subcode is specified, then a zero must be used.

   The phrase "the BGP connection is closed" means that the transport
   protocol connection has been closed and that all resources for that
   BGP connection have been deallocated.  Routing table entries
   associated with the remote peer are marked as invalid.  The fact that
   the routes have become invalid is passed to other BGP peers before
   the routes are deleted from the system.

   Unless specified explicitly, the Data field of the NOTIFICATION
   message that is sent to indicate an error is empty.