rfc1266.txt

RFC 的详细文档！

   bandwidth consumed by the protocol. Observations on the CA*Net by
   Dennis Ferguson, and on the T1 NSFNET Backbone by Susan Hares
   confirmed clear superiority of BGP as compared with EGP in the area
   of CPU requirements.

9. Using TCP as a transport for BGP.

9.1. Introduction.

   On multiple occasions some members of IETF expressed concern about
   using TCP as a transport protocol for BGP. In this section we examine
   the use of TCP for BGP in terms of:

      - real versus perceived problems
      - offer potential solutions to real problems
      - perspective on the convergence problem
      - conclusions

   BGP is based on the incremental updates. This is done intentionally
   to conserve the CPU and bandwidth requirements. Extensive operational
   experience with BGP in the Internet showed that indeed the use of the
   incremental updates allows significant saving both in terms of the
   CPU utilization and bandwidth consumption.  However, to operate
   correctly the incremental updates must be exchanged over a reliable



BGP Working Group                                               [Page 5]

RFC 1266            Experience with the BGP Protocol        October 1991


   transport.  BGP uses TCP as such transport. It had been suggested
   that another transport protocol would be more suitable for BGP.

9.2. Examination of Problems - Real and "perceived".

   Extensive operational experience with BGP in the Internet showed that
   the only real problem that was attributed to BGP in general, and the
   use of TCP as the transport for BGP in particular, was its slow
   convergence in presence of congestion.  This problem was experienced
   in CA*Net. As we mentioned before, CA*Net is composed of 10 routers
   that form a ring. The routers are connected by 56 Kbits/sec links.
   All links are heavily utilized and are often congested.  Experience
   with BGP in CA*Net showed that unless special measures are taken, the
   protocol may exhibit slow convergence when BGP information is passed
   over the slow speed (56 Kbits/sec) congested links. This is because a
   large percentage of packets carrying BGP information are being
   dropped due to congestion.  Therefore, there are three inter-related
   problems: congestion, packet drops, and the resulting slow
   convergence of routing under congestion and packet drops.

   Observe, that any transport protocol used by BGP would have
   difficulty preventing packets from being dropped under congestion,
   since it has no direct control over the routers that drop the
   packets, and the congestion has nothing to do with the BGP traffic.
   Therefore, since BGP is not the cause of congestion, and cannot
   directly influence dropping at the routers, replacing TCP (as the BGP
   transport) with another transport protocol would have no effect on
   packets being dropped due to congestion. We think that once a network
   is congested, packets will be dropped (regardless of whether these
   packets carry BGP or any other information), unless special measures
   outside of BGP in general, and the transport protocol used by BGP in
   particular, are taken.

   If packets carrying routing information are lost, any distributed
   routing protocol will exhibit slow convergence.  If quick convergence
   is viewed as important for a routing within a network, special
   measures to minimize the loss of packets that carry routing
   information must be taken.  The next section suggests some possible
   methods.

9.3. Solutions to the problem.

   Two possible measures could be taken to reduce the drop of BGP
   packets which slows convergence of routing:

      1) alleviate the congestion

      2) reduce the percentage of BGP packets that are dropped due



BGP Working Group                                               [Page 6]

RFC 1266            Experience with the BGP Protocol        October 1991


         to congestion by marking BGP packets and setting policies to
         routers to try not to drop BGP packets

   Alleviating the network congestion is a subject outside the control
   of BGP, and will not be discussed in this paper.

   Operational experience with BGP in CA*Net shows that reducing the
   percentage of BGP packets dropped due to congestion by marking them,
   and setting policies to routers to try not to drop BGP packets
   completely solves the problem of slow convergence in presence of
   congestion.

   The BGP packets can be marked (explicitly or implicitly) by the
   following three methods:

      a) by means of IP precedence (Internetwork Control)

      b) by using a well-known TCP port number

      c) by identifying packets by just source or destination IP
         address.

   Appendix 4 of the BGP protocol specification, RFC 1163, recommends
   the use of IP precedence (Internetwork Control) because the
   precedence provides a well-defined mechanism to mark BGP packets.
   The method of a well-known TCP port number to identify packets is
   similar to the one that was used by Dave Mills in the NSFNET Phase I.
   Dave Mills identified Telnet traffic by a well known TCP port number,
   and gave it priority over the rest of the traffic.  CA*Net identified
   BGP traffic based on it's source and destination IP address.  Packets
   receive a priority if either the source or the destination IP address
   belongs to CA*Net.

   If packets that carry the routing information are being dropped
   (because of congestion), one also may ask about how does a particular
   routing protocol react to such an event.  In the case of BGP the
   packets are retransmitted using the TCP retransmission mechanism. It
   seems plausible that being more aggressive in terms of the
   retransmission should have positive effect on the convergence.  This
   can be done completely within TCP by adjusting the TCP retransmission
   timers. However, we would like to point out that the change in the
   retransmission strategy should not be viewed as a cure for the
   problem, since the root of the problem lies in the way how packets
   that carry the BGP information are handled within a congested
   network, and not in how frequently the lost packets are
   retransmitted.

   It should also be pointed out that the local system can control the



BGP Working Group                                               [Page 7]

RFC 1266            Experience with the BGP Protocol        October 1991


   amount of data to be retransmitted (in case of a congestion or
   losses) by adjusting the TCP Window size. That allows to control the
   amount of potentially obsolete data that has to be retransmitted.

9.4. Perspective on the Convergence Problem.

   To put the convergence problem in a proper perspective, we'd like to
   point out that much of the Internet now uses EGP at AS borders,
   ensuring that routing changes cannot be guaranteed to propagate
   between ASes in less than a few minutes. It would take huge amount of
   congestion to slow BGP to this pace. Additionally, the problems of
   EGP in the face of packet loss are well known and far exceed any
   imaginable problem BGP/TCP might ever suffer.  Therefore, the worst
   case behavior of BGP is about the same as the steady case behavior of
   EGP.

   Within an AS the speed of convergence of the AS's IGP in the face of
   congestion is of far greater concern than the propagation speed of
   BGP, and indeed avoiding loss of packets carrying IGP, and a more
   aggressive transport is similarly of much greater importance for an
   IGP than for BGP.

   The issue of BGP convergence is of exaggerated importance to CA*Net
   since CA*Net carries no information about external routes in its IGP.
   CA*Net uses BGP to transfer external routes for use in computing
   internal routes through the CA*Net network.  The reason CA*Net does
   this has nothing to do with BGP. Under more ordinary circumstances an
   IGP carries external routing information for use in computing
   internal routes. CA*Net shows that BGP can work under extreme stress.
   However, it's results should not be taken as the norm since most
   networks will use BGP in a different (and less stressful)
   configuration, where information about external routes will be
   carried by an IGP.

9.5. Conclusion.

   The extensive operational experience with BGP showed that the only
   problem attributed to BGP was the slow convergence problem in
   presence of congestion.  We demonstrated that this problem has
   nothing to do with BGP in general, or with TCP as the BGP transport
   in particular, but is directly related to the way how packets that
   carry routing information are handled within a congested network. The
   document suggests possible ways of solving the problem.  We would
   like to point out that the issue of convergence in presence of
   congested network is important to all distributed routing protocol,
   and not just to BGP.  Therefore, we recommend that every routing
   protocol (whether it is intra-autonomous system or inter-autonomous
   system) should clearly specify how its behavior is affected by the



BGP Working Group                                               [Page 8]

RFC 1266            Experience with the BGP Protocol        October 1991


   congestion in the networks, and what are the possible mechanisms to
   avoid the negative effect of congestion (if any).

10. Bibliography.

   [1] Hinden, B., "Internet Routing Protocol Standardization Criteria",
       RFC 1264, BBN, October 1991.

   [2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
       Protocol in the Internet", RFC 1268, T.J. Watson Research Center,
       IBM Corp., ANS, October 1991.

   [3] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
       3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM
       Corp., October 1991.

   [4] Willis, S., and J. Burruss, "Definitions of Managed Objects for
       the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet
       Communications Inc., October 1991.

Security Considerations

   Security issues are discussed in section 6.

Author's Address

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598

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

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















BGP Working Group                                               [Page 9]