rfc1771.txt

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


RFC 1771                         BGP-4                        March 1995


   messages as a function of the Hold Time interval.

   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.

   KEEPALIVE message consists of only message header and has a length of
   19 octets.

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.



Rekhter & Li                                                   [Page 18]

RFC 1771                         BGP-4                        March 1995


         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 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
                               7 - AS Routing Loop.
                               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).





Rekhter & Li                                                   [Page 19]

RFC 1771                         BGP-4                        March 1995


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





Rekhter & Li                                                   [Page 20]

RFC 1771                         BGP-4                        March 1995


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





Rekhter & Li                                                   [Page 21]

RFC 1771                         BGP-4                        March 1995


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




Rekhter & Li                                                   [Page 22]

RFC 1771                         BGP-4                        March 1995


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.

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