rfc1267.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         If the local system receives a NOTIFICATION message, it changes
         its state to Idle.

         If the KeepAlive timer expires, the local system sends a
         KEEPALIVE message and restarts its KeepAlive timer.

         If a disconnect notification is received from the underlying
         transport protocol, the local system changes its state to Idle.

         In response to the Stop event (initiated by either system or
         operator) the local system sends NOTIFICATION message with
         Error Code Cease and changes its state to Idle.

         Start event is ignored in the OpenConfirm state.

         In response to any other event the local system sends
         NOTIFICATION message with Error Code Finite State Machine Error
         and changes its state to Idle.

         Whenever BGP changes its state from OpenConfirm to Idle, it
         closes the BGP (and transport-level) connection and releases
         all resources associated with that connection.

      Established state:

         In the Established state BGP can exchange UPDATE, NOTIFICATION,
         and KEEPALIVE messages with its peer.

         If the local system receives an UPDATE or KEEPALIVE message, it
         restarts its Holdtime timer.

         If the local system receives a NOTIFICATION message, it changes
         its state to Idle.

         If the local system receives an UPDATE message and the UPDATE
         message error handling procedure (see Section 6.3) detects an
         error, the local system sends a NOTIFICATION message and
         changes its state to Idle.

         If a disconnect notification is received from the underlying
         transport protocol, the local system  changes its state to
         Idle.

         If the Holdtime timer expires, the local system sends a
         NOTIFICATION message with Error Code Hold Timer Expired and
         changes its state to Idle.

         If the KeepAlive timer expires, the local system sends a



Lougheed & Rekhter                                             [Page 23]

RFC 1267                         BGP-3                      October 1991


         KEEPALIVE message and restarts its KeepAlive timer.

         Each time the local system sends a KEEPALIVE or UPDATE message,
         it restarts its KeepAlive timer.

         In response to the Stop event (initiated by either system or
         operator), the local system sends a NOTIFICATION message with
         Error Code Cease and changes its state to Idle.

         Start event is ignored in the Established state.

         In response to any other event, the local system sends
         NOTIFICATION message with Error Code Finite State Machine Error
         and changes its state to Idle.

         Whenever BGP changes its state from Established to Idle, it
         closes the BGP (and transport-level) connection, releases all
         resources associated with that connection, and deletes all
         routes derived from that connection.

9.  UPDATE Message Handling

   An UPDATE message may be received only in the Established state.
   When an UPDATE message is received, each field is checked for
   validity as specified in Section 6.3.

   If an optional non-transitive attribute is unrecognized, it is
   quietly ignored.  If an optional transitive attribute is
   unrecognized, the Partial bit (the third high-order bit) in the
   attribute flags octet is set to 1, and the attribute is retained for
   propagation to other BGP speakers.

   If an optional attribute is recognized, and has a valid value, then,
   depending on the type of the optional attribute, it is processed
   locally, retained, and updated, if necessary, for possible
   propagation to other BGP speakers.

   If the network and the path attributes associated with a route to
   that network are correct, then the route is compared with other
   routes to the same network.

   When a BGP speaker receives a new route from a peer over external BGP
   link, it shall advertise that route to other BGP speakers in its
   autonomous system by means of an UPDATE message if either of the
   following conditions occur:

      a) the newly received route is considered to be better
         than the other routes to the same network (as listed



Lougheed & Rekhter                                             [Page 24]

RFC 1267                         BGP-3                      October 1991


         in the UPDATE message) that have been received over
         external BGP links, or

      b) there are no other acceptable routes to the network
         (as listed in the UPDATE message) that have been
         received over external BGP links.

   When a BGP speaker receives an unreachable route from a BGP peer over
   external BGP link, it shall advertise that route to all other BGP
   speakers in its autonomous system, indicating that it has become
   unreachable, if the following condition occur:

      a) a corresponding acceptable route to the same destination
         was considered to be the best one among all routes to that
         destination that have been received over external BGP links
         (that is the local system has been advertising the
         route to all other BGP speakers in its autonomous system
         before it received the UPDATE message that reported it
         as unreachable).

   Whenever a BGP speaker selects a new route (among all the routes
   received from external and internal BGP peers), or determines that
   the reachable destinations within its own autonomous system have
   changed, it shall generate an UPDATE message and forward it to each
   of its external peers (peers connected via external BGP links).

   If a route in the UPDATE was received over an internal link, it is
   not propagated over any other internal link.  This restriction is due
   to the fact that all BGP speakers within a single AS form a
   completely connected graph (see above).

   If the UPDATE message is propagated over an external link, then the
   local AS number is prepended to the AS_PATH attribute, and the
   NEXT_HOP attribute is updated with an IP address of the router that
   should be used as a next hop to the network.  If the UPDATE message
   is propagated over an internal link, then the AS_PATH attribute and
   the NEXT_HOP attribute are passed unmodified.

   Generally speaking, the rules for comparing routes among several
   alternatives are outside the scope of this document.  There are two
   exceptions:

      - If the local AS appears in the AS path of the new route being
        considered, then that new route cannot be viewed as better than
        any other route.  If such a route were ever used, a routing loop
        would result.

      - In order to achieve successful distributed operation, only routes



Lougheed & Rekhter                                             [Page 25]

RFC 1267                         BGP-3                      October 1991


        with a likelihood of stability can be chosen.  Thus, an AS must
        avoid using unstable routes, and it must not make rapid
        spontaneous changes to its choice of route.  Quantifying the terms
        "unstable" and "rapid" in the previous sentence will require
        experience, but the principle is clear.

10. Detection of Inter-AS Policy Contradictions

   Since BGP requires no central authority for coordinating routing
   policies among ASs, and since routing policies are not exchanged via
   the protocol itself, it is possible for a group of ASs to have a set
   of routing policies that cannot simultaneously be satisfied.  This
   may cause an indefinite oscillation of the routes in this group of
   ASs.

   To help detect such a situation, all BGP speakers must observe the
   following rule.  If a route to a destination that is currently used
   by the local system is determined to be unreachable (e.g., as a
   result of receiving an UPDATE message for this route with the
   UNREACHABLE attribute), then, before switching to another route, this
   local system must advertize this route as unreachable to all the BGP
   neighbors to which it previously advertized this route.

   This rule will allow other ASs to distinguish between two different
   situations:

      - The local system has chosen to use a new route because the old
        route become unreachable.

      - The local system has chosen to use a new route because it
        preferred it over the old route.  The old route is still
        viable.

   In the former case, an UPDATE message with the UNREACHABLE attribute
   will be received for the old route.  In the latter case it will not.

   In some cases, this may allow a BGP speaker to detect the fact that
   its policies, taken together with the policies of some other AS,
   cannot simultaneously be satisfied.  For example, consider the
   following situation involving AS A and its neighbor AS B.  B
   advertises a route with a path of the form <B,...>, where A is not
   present in the path.  A then decides to use this path, and advertises
   <A,B,...> to all its neighbors.  B later advertises <B,...,A,...>
   back to A, without ever declaring its previous path <B,...> to be
   unreachable.  Evidently, A prefers routes via B and B prefers routes
   via A.  The combined policies of A and B, taken together, cannot be
   satisfied.  Such an event should be noticed, logged locally, and
   brought to the attention of AS A's administration.  The means to do



Lougheed & Rekhter                                             [Page 26]

RFC 1267                         BGP-3                      October 1991


   this, however, lies outside the scope of this document.  Also outside
   the document is a more complete procedure for detecting such
   contradictions of policy.

   While the above rules provide a mechanism to detect a set of routing
   policies that cannot be satisfied simultaneously, the protocol itself
   does not provide any mechanism for suppressing the route oscillation
   that may result from these unsatisfiable policies.  The reason for
   doing this is that routing policies are viewed as external to the
   protocol and as determined by the local AS administrator.

Appendix 1.  BGP FSM State Transitions and Actions.

   This Appendix discusses the transitions between states in the BGP FSM
   in response to BGP events.  The following is the list of these states
   and events.

    BGP States:

             1 - Idle
             2 - Connect
             3 - Active
             4 - OpenSent
             5 - OpenConfirm
             6 - Established


    BGP Events:

             1 - BGP Start
             2 - BGP Stop
             3 - BGP Transport connection open
             4 - BGP Transport connection closed
             5 - BGP Transport connection open failed
             6 - BGP Transport fatal error
             7 - ConnectRetry timer expired
             8 - Holdtime timer expired
             9 - KeepAlive timer expired
            10 - Receive OPEN message
            11 - Receive KEEPALIVE message
            12 - Receive UPDATE messages
            13 - Receive NOTIFICATION message

   The following table describes the state transitions of the BGP FSM
   and the actions triggered by these transitions.






Lougheed & Rekhter                                             [Page 27]

RFC 1267                         BGP-3                      October 1991


    Event                Actions               Message Sent   Next State
    --------------------------------------------------------------------
    Idle (1)
     1            Initialize resources            none             2
                  Start ConnectRetry timer
                  Initiate a transport connection
     others               none                    none             1

    Connect(2)
     1                    none                    none             2
     3            Complete initialization         OPEN             4
                  Clear ConnectRetry timer
     5            Restart ConnectRetry timer      none             3
     7            Restart ConnectRetry timer      none             2
                  Initiate a transport connection
     others       Release resources               none             1

    Active (3)
     1                    none                    none             3
     3            Complete initialization         OPEN             4
                  Clear ConnectRetry timer
     5            Close connection                                 3
                  Restart ConnectRetry timer
     7            Restart ConnectRetry timer      none             2
                  Initiate a transport connection