|                                                               |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      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 20015.  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           discretionary5.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 attributeExpiration 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 anExpiration 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 selectionExpiration Date July 2001                                      [Page 23]RFC DRAFT                                                   January 2001