rfc1772.txt

中、英文RFC文档大全打包下载完全版 .

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

       - DEAD: Flush transmit queue and abort TCP connection.




Rekhter & Gross                                                [Page 13]

RFC 1772                   BGP-4 Application                  March 1995


       - UP: Transmit any queued data or allow an outgoing TCP call to
         proceed.

9.4 Combined Properties

   Some implementations may not be able to guarantee that the BGP
   process and the circuit manager will operate as a single entity; i.e.
   they can have a separate existence when the other has been stopped or
   has crashed.

   If this is the case, a periodic two-way poll between the BGP process
   and the circuit manager should be implemented.  If the BGP process
   discovers the circuit manager has gone away it should close all
   relevant TCP connections.  If the circuit manager discovers the BGP
   process has gone away it should close all its connections associated
   with the BGP process and reject any further incoming connections.

10. Conclusion

   The BGP protocol provides a high degree of control and flexibility
   for doing interdomain routing while enforcing policy and performance
   constraints and avoiding routing loops. The guidelines presented here
   will provide a starting point for using BGP to provide more
   sophisticated and manageable routing in the Internet as it grows.



























Rekhter & Gross                                                [Page 14]

RFC 1772                   BGP-4 Application                  March 1995


Appendix A. The Interaction of BGP and an IGP

   This section outlines methods by which BGP can exchange routing
   information with an IGP. The methods outlined here are not proposed
   as part of the standard BGP usage at this time.  These methods are
   outlined for information purposes only.  Implementors may want to
   consider these methods when importing IGP information.

   This is general information that applies to any generic IGP.

   Interaction between BGP and any specific IGP is outside the scope of
   this section.  Methods for specific IGP's should be proposed in
   separate documents.  Methods for specific IGP's could be proposed for
   standard usage in the future.

Overview

   By definition, all transit AS's must be able to carry traffic which
   originates from and/or is destined to locations outside of that AS.
   This requires a certain degree of interaction and coordination
   between BGP and the Interior Gateway Protocol (IGP) used by that
   particular AS. In general, traffic originating outside of a given AS
   is going to pass through both interior gateways (gateways that
   support the IGP only) and border gateways (gateways that support both
   the IGP and BGP). All interior gateways receive information about
   external routes from one or more of the border gateways of the AS via
   the IGP.

   Depending on the mechanism used to propagate BGP information within a
   given AS, special care must be taken to ensure consistency between
   BGP and the IGP, since changes in state are likely to propagate at
   different rates across the AS. There may be a time window between the
   moment when some border gateway (A) receives new BGP routing
   information which was originated from another border gateway (B)
   within the same AS, and the moment the IGP within this AS is capable
   of routing transit traffic to that border gateway (B). During that
   time window, either incorrect routing or "black holes" can occur.

   In order to minimize such routing problems, border gateway (A) should
   not advertise to any of its external peers a route to some set of
   exterior destinations associated with a given address prefix X via
   border gateway (B) until all the interior gateways within the AS are
   ready to route traffic destined to these destinations via the correct
   exit border gateway (B). In other words, interior routing should
   converge on the proper exit gateway before/advertising routes via
   that exit gateway to external peers.





Rekhter & Gross                                                [Page 15]

RFC 1772                   BGP-4 Application                  March 1995


A.2 Methods for Achieving Stable Interactions

   The following discussion outlines several techniques capable of
   achieving stable interactions between BGP and the IGP within an
   Autonomous System.

A.2.1 Propagation of BGP Information via the IGP

   While BGP can provide its own mechanism for carrying BGP information
   within an AS, one can also use an IGP to transport this information,
   as long as the IGP supports complete flooding of routing information
   (providing the mechanism to distribute the BGP information) and one
   pass convergence (making the mechanism effectively atomic). If an IGP
   is used to carry BGP information, then the period of
   desynchronization described earlier does not occur at all, since BGP
   information propagates within the AS synchronously with the IGP, and
   the IGP converges more or less simultaneously with the arrival of the
   new routing information. Note that the IGP only carries BGP
   information and should not interpret or process this information.

A.2.2  Tagged Interior Gateway Protocol

   Certain IGPs can tag routes exterior to an AS with the identity of
   their exit points while propagating them within the AS. Each border
   gateway should use identical tags for announcing exterior routing
   information (received via BGP) both into the IGP and when propagating
   this information to other internal peers (peers within the same AS).
   Tags generated by a border gateway must uniquely identify that
   particular border gateway--different border gateways must use
   different tags.

   All Border Gateways within a single AS must observe the following two
   rules:

     1.  Information received from an internal peer by a border gateway
         A declaring a set of destination associated with a given
         address prefix to be unreachable must immediately be propagated
         to all of the external peers of A.

     2.  Information received from an internal peer by a border gateway
         A about a set of reachable destinations associated with a given
         address prefix X cannot be propagated to any of the external
         peers of A unless/until A has an IGP route to the set of
         destinations covered by X and both the IGP and the BGP routing
         information have identical tags.

   These rules guarantee that no routing information is announced
   externally unless the IGP is capable of correctly supporting it. It



Rekhter & Gross                                                [Page 16]

RFC 1772                   BGP-4 Application                  March 1995


   also avoids some causes of "black holes".

   One possible method for tagging BGP and IGP routes within an AS is to
   use the IP address of the exit border gateway announcing the exterior
   route into the AS. In this case the "gateway" field in the BGP UPDATE
   message is used as the tag.

   An alternate method for tagging BGP and IGP routes is to have BGP and
   the IGP agree on a router ID.  In this case, the router ID is
   available to all BGP (version 3 or higher) speakers.  Since this ID
   is already unique it can be used directly as the tag in the IGP.

A.2.3 Encapsulation

   Encapsulation provides the simplest (in terms of the interaction
   between the IGP and BGP) mechanism for carrying transit traffic
   across the AS. In this approach, transit traffic is encapsulated
   within an IP datagram addressed to the exit gateway. The only
   requirement imposed on the IGP by this approach is that it should be
   capable of supporting routing between border gateways within the same
   AS.

   The address of the exit gateway A for some exterior destination X is
   specified in the BGP identifier field of the BGP OPEN message
   received from gateway A (via BGP) by all other border gateways within
   the same AS. In order to route traffic to destination X, each border
   gateway within the AS encapsulates it in datagrams addressed to
   gateway A. Gateway A then performs decapsulation and forwards the
   original packet to the proper gateway in another AS.

   Since encapsulation does not rely on the IGP to carry exterior
   routing information, no synchronization between BGP and the IGP is
   required.

   Some means of identifying datagrams containing encapsulated IP, such
   as an IP protocol type code, must be defined if this method is to be
   used.

   Note that, if a packet to be encapsulated has length that is very
   close to the MTU, that packet would be fragmented at the gateway that
   performs encapsulation.

A.2.4  Pervasive BGP

   If all routers in an AS are BGP speakers, then there is no need to
   have any interaction between BGP and an IGP.  In such cases, all
   routers in the AS already have full information of all BGP routes.
   The IGP is then only used for routing within the AS, and no BGP



Rekhter & Gross                                                [Page 17]

RFC 1772                   BGP-4 Application                  March 1995


   routes are imported into the IGP.

   For routers to operate in this fashion, they must be able to perform
   a recursive lookup in their routing table.  The first lookup will use
   a BGP route to establish the exit router, while the second lookup
   will determine the IGP path to the exit router.

   Since the IGP carries no external information in this scenario, all
   routers in the AS will have converged as soon as all BGP speakers
   have new information about this route.  Since there is no need to
   delay for the IGP to converge, an implementation may advertise these
   routes without further delay due to the IGP.

A.2.5  Other Cases

   There may be AS's with IGPs which can neither carry BGP information
   nor tag exterior routes (e.g., RIP). In addition, encapsulation may
   be either infeasible or undesirable. In such situations, the
   following two rules must be observed:

     1.  Information received from an internal peer by a border gateway
         A declaring a destination to be unreachable must immediately be
         propagated to all of the external peers of A.

     2.  Information received from an internal peer by a border gateway
         A about a reachable destination X cannot be propagated to any
         of the external peers of A unless A has an IGP route to X and
         sufficient time has passed for the IGP routes to have
         converged.

   The above rules present necessary (but not sufficient) conditions for
   propagating BGP routing information to other AS's. In contrast to
   tagged IGPs, these rules cannot ensure that interior routes to the
   proper exit gateways are in place before propagating the routes to
   other AS's.

   If the convergence time of an IGP is less than some small value X,
   then the time window during which the IGP and BGP are unsynchronized
   is less than X as well, and the whole issue can be ignored at the
   cost of transient periods (of less than length X) of routing
   instability. A reasonable value for X is a matter for further study,
   but X should probably be less than one second.

   If the convergence time of an IGP cannot be ignored, a different
   approach is needed. Mechanisms and techniques which might be
   appropriate in this situation are subjects for further study.





Rekhter & Gross                                                [Page 18]

RFC 1772                   BGP-4 Application                  March 1995


References

   [1] Rekhter Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4), RFC
       1771, T.J. Watson Research Center, IBM Corp., cisco Systems,
       March 1995.

   [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
       Merit/NSFNET, June 1989.

   [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:  an
       Address Assignment and Aggregation Strategy", RFC1519, BARRNet,
       cisco, MERIT, OARnet, September 1993.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 704, Office H3-D40
   Yorktown Heights, NY 10598

   Phone: [phone]
   EMail: [e-mail]


   Phill Gross
   MCI Data Services Division
   2100 Reston Parkway, Room 6001,
   Reston, VA 22091

   Phone: [phone]
   EMail: [e-mail]


   IETF IDR WG mailing list: [e-mail]
   To be added: [e-mail]












Rekhter & Gross                                                [Page 19]