rfc1655.txt

RFC 的详细文档！

   routing information.  Policies are determined by the AS
   administration.

   Routing policies are related to political, security, or economic
   considerations. For example, if an AS is unwilling to carry traffic
   to another AS, it can enforce a policy prohibiting this. The
   following are examples of routing policies that can be enforced with
   the use of BGP:

     1.  A multihomed AS can refuse to act as a transit AS for other
         AS's.  (It does so by only advertising routes to networks
         internal to the AS.)

     2.  A multihomed AS can become a transit AS for a restricted set of
         adjacent AS's, i.e., some, but not all, AS's can use the
         multihomed AS as a transit AS. (It does so by advertising its
         routing information to this set of AS's.)

     3.  An AS can favor or disfavor the use of certain AS's for
         carrying transit traffic from itself.

   A number of performance-related criteria can be controlled with the
   use of BGP:

     1.  An AS can minimize the number of transit AS's. (Shorter AS
         paths can be preferred over longer ones.)

     2.  The quality of transit AS's. If an AS determines that two or
         more AS paths can be used to reach a given destination, that AS
         can use a variety of means to decide which of the candidate AS
         paths it will use. The quality of an AS can be measured by such
         things as diameter, link speed, capacity, tendency to become
         congested, and quality of operation. Information about these
         qualities might be determined by means other than BGP.



Rekhter & Gross                                                 [Page 7]

RFC 1655                   BGP-4 Application                   July 1994


     3.  Preference of internal routes over external routes.

   For consistency within an AS, equal cost paths, resulting from
   combinations of policies and/or normal route selection procedures,
   must be resolved in a consistent fashion.

   Fundamental to BGP is the rule that an AS advertises to its
   neighboring AS's only those routes that it uses. This rule reflects
   the "hop-by-hop" routing paradigm generally used by the current
   Internet.

6. Path Selection with BGP

   One of the major tasks of a BGP speaker is to evaluate different
   paths to a destination network from its border gateways at that
   network, select the best one, apply appropriate policy constraints,
   and then advertise it to all of its BGP neighbors. The key issue is
   how different paths are evaluated and compared.  In traditional
   distance vector protocols (e.g., RIP) there is only one metric (e.g.,
   hop count) associated with a path. As such, comparison of different
   paths is reduced to simply comparing two numbers. A complication in
   Inter-AS routing arises from the lack of a universally agreed-upon
   metric among AS's that can be used to evaluate external paths.
   Rather, each AS may have its own set of criteria for path evaluation.

   A BGP speaker builds a routing database consisting of the set of all
   feasible paths and the list of networks reachable through each path.
   For purposes of precise discussion, it's useful to consider the set
   of feasible paths for a given destination network. In most cases, we
   would expect to find only one feasible path. However, when this is
   not the case, all feasible paths should be maintained, and their
   maintenance speeds adaptation to the loss of the primary path. Only
   the primary path at any given time will ever be advertised.

   The path selection process can be formalized by defining a complete
   order over the set of all feasible paths to a given destination
   network. One way to define this complete order is to define a
   function that maps each full AS path to a non-negative integer that
   denotes the path's degree of preference. Path selection is then
   reduced to applying this function to all feasible paths and choosing
   the one with the highest degree of preference.

   In actual BGP implementations, the criteria for assigning degree of
   preferences to a path are specified as configuration information.

   The process of assigning a degree of preference to a path can be
   based on several sources of information:




Rekhter & Gross                                                 [Page 8]

RFC 1655                   BGP-4 Application                   July 1994


     1.  Information explicitly present in the full AS path.

     2.  A combination of information that can be derived from the full
         AS path and information outside the scope of BGP (e.g., policy
         routing constraints provided as configuration information).

   Possible criteria for assigning a degree of preference to a path are:

       - AS count. Paths with a smaller AS count are generally better.

       - Policy considerations. BGP supports policy-based routing based
         on the controlled distribution of routing information.  A BGP
         speaker may be aware of some policy constraints (both within
         and outside of its own AS) and do appropriate path selection.
         Paths that do not comply with policy requirements are not
         considered further.

       - Presence or absence of a certain AS or AS's in the path. By
         means of information outside the scope of BGP, an AS may know
         some performance characteristics (e.g., bandwidth, MTU, intra-
         AS diameter) of certain AS's and may try to avoid or prefer
         them.

       - Path origin. A path learned entirely from BGP (i.e., whose
         endpoint is internal to the last AS on the path) is generally
         better than one for which part of the path was learned via EGP
         or some other means.

       - AS path subsets. An AS path that is a subset of a longer AS
         path to the same destination should be preferred over the
         longer path.  Any problem in the shorter path (such as an
         outage) will also be a problem in the longer path.

       - Link dynamics. Stable paths should be preferred over unstable
         ones. Note that this criterion must be used in a very careful
         way to avoid causing unnecessary route fluctuation. Generally,
         any criteria that depend on dynamic information might cause
         routing instability and should be treated very carefully.

7. Required set of supported routing policies

   Policies are provided to BGP in the form of configuration
   information.  This information is not directly encoded in the
   protocol. Therefore, BGP can provide support for very complex routing
   policies. However, it is not required that all BGP implementations
   support such policies.





Rekhter & Gross                                                 [Page 9]

RFC 1655                   BGP-4 Application                   July 1994


   We are not attempting to standardize the routing policies that must
   be supported in every BGP implementation; we strongly encourage all
   implementors to support the following set of routing policies:

     1.  BGP implementations should allow an AS to control announcements
         of BGP-learned routes to adjacent AS's.  Implementations should
         also support such control with at least the granularity of a
         single network.  Implementations should also support such
         control with the granularity of an autonomous system, where the
         autonomous system may be either the autonomous system that
         originated the route, or the autonomous system that advertised
         the route to the local system (adjacent autonomous system).
         Care must be taken when a BGP speaker selects a new route that
         can't be announced to a particular external peer, while the
         previously selected route was announced to that peer.
         Specifically, the local system must explicitly indicate to the
         peer that the previous route is now infeasible.

     2.  BGP implementations should allow an AS to prefer a particular
         path to a destination (when more than one path is available).
         At the minimum an implementation shall support this
         functionality by allowing to administratively assign a degree
         of preference to a route based solely on the IP address of the
         neighbor the route is received from. The allowed range of the
         assigned degree of preference shall be between 0 and 2^(31) -
         1.

     3.  BGP implementations should allow an AS to ignore routes with
         certain AS's in the AS_PATH path attribute.  Such function can
         be implemented by using the technique outlined in [2], and by
         assigning "infinity" as "weights" for such AS's. The route
         selection process must ignore routes that have "weight" equal
         to "infinity".

8. Interaction with other exterior routing protocols

   The guidelines suggested in this section are consistent with the
   guidelines presented in [3].

   An AS should advertise a minimal aggregate for its internal networks
   with respect to the amount of address space that it is actually
   using.  This can be used by administrators of non-BGP 4 AS's to
   determine how many routes to explode from a single aggregate.

   A route that carries the ATOMIC_AGGREGATE path attribute shall not be
   exported into either BGP-3 or EGP2, unless such an exportation can be
   accomplished without exploding the NLRI of the route.




Rekhter & Gross                                                [Page 10]

RFC 1655                   BGP-4 Application                   July 1994


8.1 Exchanging information with EGP2

   This document suggests the following guidelines for exchanging
   routing information between BGP-4 and EGP2.

   To provide for graceful migration, a BGP speaker may participate in
   EGP2, as well as in BGP-4. Thus, a BGP speaker may receive IP
   reachability information by means of EGP2 as well as by means of
   BGP-4.  The information received by EGP2 can be injected into BGP-4
   with the ORIGIN path attribute set to 1.  Likewise,  the information
   received via BGP-4 can be injected into EGP2 as well. In the latter
   case, however, one needs to be aware of the potential information
   explosion when a given IP prefix received from BGP-4 denotes a set of
   consecutive A/B/C class networks.  Injection of BGP-4 received NLRI
   that denotes IP subnets requires the BGP speaker to inject the
   corresponding network into EGP2.  The local system shall provide
   mechanisms to control the exchange of reachability information
   between EGP2 and BGP-4.  Specifically, a conformant implementation is
   required to support all of the following options when injecting BGP-4
   received reachability information into EGP2:

       - inject default only (0.0.0.0); no export of any other NLRI

       - allow controlled deaggregation, but only of specific routes;
         allow export of non-aggregated NLRI

       - allow export of only non-aggregated NLRI

   The exchange of routing information via EGP2 between a BGP speaker
   participating in BGP-4 and a pure EGP2 speaker may occur  only at the
   domain (autonomous system) boundaries.

8.2 Exchanging information with BGP-3

   This document suggests the following guidelines for exchanging
   routing information between BGP-4 and BGP-3.

   To provide for graceful migration, a BGP speaker may participate in
   BGP-3, as well as in BGP-4. Thus, a BGP speaker may receive IP
   reachability information by means of BGP-3, as well as by means of
   BGP-4.

   A BGP speaker may inject the information received by BGP-4 into BGP-3
   as follows.

   If an AS_PATH attribute of a BGP-4 route carries AS_SET path
   segments, then the AS_PATH attribute of the BGP-3 route shall be
   constructed by treating the AS_SET segments as AS_SEQUENCE segments,



Rekhter & Gross                                                [Page 11]

RFC 1655                   BGP-4 Application                   July 1994


   with the resulting AS_PATH being a single AS_SEQUENCE. While this
   procedure loses set/sequence information, it doesn't affect
   protection for routing loops suppression, but may affect policies, if
   the policies are based on the content or ordering of the AS_PATH
   attribute.

   While injecting BGP-4 derived NLRI into BGP-3, one needs to be aware
   of the potential information explosion when a given IP prefix denotes
   a set of consecutive A/B/C class networks. Injection of BGP-4 derived
   NLRI that denotes IP subnets requires the BGP speaker to inject the
   corresponding network into BGP-3. The local system shall provide
   mechanisms to control the exchange of routing information between
   BGP-3 and BGP-4.  Specifically, a conformant implementation is
   required to support all of the following options when injecting BGP-4
   received routing information into BGP-3:

       - inject default only (0.0.0.0), no export of any other NLRI

       - allow controlled deaggregation, but only of specific routes;
         allow export of non-aggregated NLRI

       - allow export of only non-aggregated NLRI

   The exchange of routing information via BGP-3 between a BGP speaker
   participating in BGP-4 and a pure BGP-3 speaker may occur  only at
   the autonomous system boundaries. Within a single autonomous system
   BGP conversations between all the BGP speakers of that autonomous
   system have to be either BGP-3 or BGP-4, but not a mixture.

9. Operations over Switched Virtual Circuits

   When using BGP over Switched Virtual Circuit (SVC) subnetworks it may
   be desirable to minimize traffic generated by BGP. Specifically, it
   may be desirable to eliminate traffic associated with periodic
   KEEPALIVE messages.  BGP includes a mechanism for operation over
   switched virtual circuit (SVC) services which avoids keeping SVCs
   permanently open and allows it to eliminates periodic sending of
   KEEPALIVE messages.

   This section describes how to operate without periodic KEEPALIVE
   messages to minimise SVC usage when using an intelligent SVC circuit
   manager.  The proposed scheme may also be used on "permanent"
   circuits, which support a feature like link quality monitoring or
   echo request to determine the status of link connectivity.

   The mechanism described in this section is suitable only between the
   BGP speakers that are directly connected over a common virtual
   circuit.



Rekhter & Gross                                                [Page 12]

RFC 1655                   BGP-4 Application                   July 1994


9.1 Establishing a BGP Connection

   The feature is selected by specifying zero Hold Time in the OPEN
   message.

9.2 Circuit Manager Properties

   The circuit manager must have sufficient functionality to be able to
   compensate for the lack of periodic KEEPALIVE messages:

       - It must be able to determine link layer unreachability in a
         predictable finite period of a failure occurring.

       - On determining unreachability it should:

                - start a configurable dead timer (comparable to a
                  typical Hold timer value).

                - attempt to re-establish the Link Layer connection.

       - If the dead timer expires it should:

                - send an internal circuit DEAD indication to TCP.

       - If the connection is re-established it should:

                - cancel the dead timer.

                - send an internal circuit UP indication to TCP.

9.3 TCP Properties

   A small modification must be made to TCP to process internal
   notifications from the circuit manager: