rfc1655.txt

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

Network Working Group                                         Y. Rekhter
Request for Comments: 1655        T.J. Watson Research Center, IBM Corp.
Obsoletes: 1268                                                 P. Gross
Category: Standards Track                                            MCI
                                                                 Editors
                                                               July 1994


       Application of the Border Gateway Protocol in the Internet

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document, together with its companion document, "A Border
   Gateway Protocol 4 (BGP-4)", define an inter-autonomous system
   routing protocol for the Internet.  "A Border Gateway Protocol 4
   (BGP-4)" defines the BGP protocol specification, and this document
   describes the usage of the BGP in the Internet.

   Information about the progress of BGP can be monitored and/or
   reported on the BGP mailing list ([e-mail]).

Acknowledgements

   This document was originally published as RFC 1164 in June 1990,
   jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz
   (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu
   (MERIT).

   The following also made key contributions to RFC 1164 -- Guy Almes
   (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-
   Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT).

   We like to explicitly thank Bob Braden (ISI) for the review of the
   previous version of this document.

   This updated version of the document is the product of the IETF BGP
   Working Group with Phill Gross (MCI) and Yakov Rekhter (IBM) as
   editors.





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


   John Moy (Proteon) contributed Section 7 "Required set of supported
   routing policies".

   Scott Brim (Cornell University) contributed the basis for Section 8
   "Interaction with other exterior routing protocols".

   Most of the text in Section 9 was contributed by Gerry Meyer
   (Spider).

   Parts of the Introduction were taken almost verbatim from [3].

   We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco
   Systems) for their review and comments on the current version of the
   document.

1. Introduction

   This memo describes the use of the Border Gateway Protocol (BGP) [1]
   in the Internet environment. BGP is an inter-Autonomous System
   routing protocol. The network reachability information exchanged via
   BGP provides sufficient information to detect routing loops and
   enforce routing decisions based on performance preference and policy
   constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges
   routing information containing full AS paths and enforces routing
   policies based on configuration information.

   As the Internet has evolved and grown over in recent years, it has
   become painfully evident that it is soon to face several serious
   scaling problems. These include:

       - Exhaustion of the class-B network address space. One
         fundamental cause of this problem is the lack of a network
         class of a size which is appropriate for mid-sized
         organization; class-C, with a maximum of 254 host addresses, is
         too small while class-B, which allows up to 65534 addresses, is
         too large to be densely populated.

       - Growth of routing tables in Internet routers are beyond the
         ability of current software (and people) to effectively manage.

       - Eventual exhaustion of the 32-bit IP address space.

   It has become clear that the first two of these problems are likely
   to become critical within the next one to three years.  Classless
   inter-domain routing (CIDR) attempts to deal with these problems by
   proposing a mechanism to slow the growth of the routing table and the
   need for allocating new IP network numbers. It does not attempt to
   solve the third problem, which is of a more long-term nature, but



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


   instead endeavors to ease enough of the short to mid-term
   difficulties to allow the Internet to continue to function
   efficiently while progress is made on a longer- term solution.

   BGP-4 is an extension of BGP-3 that provides support for routing
   information aggregation and reduction based on the Classless inter-
   domain routing architecture (CIDR) [3].  This memo describes the
   usage of BGP-4 in the Internet.

   All of the discussions in this paper are based on the assumption that
   the Internet is a collection of arbitrarily connected Autonomous
   Systems. That is, the Internet will be modeled as a general graph
   whose nodes are AS's and whose edges are connections between pairs of
   AS's.

   The classic definition of an Autonomous System is a set of routers
   under a single technical administration, using an interior gateway
   protocol and common metrics to route packets within the AS and using
   an exterior gateway protocol to route packets to other AS's. Since
   this classic definition was developed, it has become common for a
   single AS to use several interior gateway protocols and sometimes
   several sets of metrics within an AS. The use of the term Autonomous
   System here stresses the fact that, even when multiple IGPs and
   metrics are used, the administration of an AS appears to other AS's
   to have a single coherent interior routing plan and presents a
   consistent picture of which networks are reachable through it.

   AS's are assumed to be administered by a single administrative
   entity, at least for the purposes of representation of routing
   information to systems outside of the AS.

2. BGP Topological Model

   When we say that a connection exists between two AS's, we mean two
   things:

      Physical connection:  There is a shared network between the two
      AS's, and on this shared network each AS has at least one border
      gateway belonging to that AS. Thus the border gateway of each AS
      can forward packets to the border gateway of the other AS without
      resorting to Inter-AS or Intra-AS routing.

      BGP connection:  There is a BGP session between BGP speakers in
      each of the AS's, and this session communicates those routes that
      can be used for specific networks via the advertising AS.
      Throughout this document we place an additional restriction on the
      BGP speakers that form the BGP connection: they must themselves
      share the same network that their border gateways share. Thus, a



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


      BGP session between adjacent AS's requires no support from either
      Inter-AS or Intra-AS routing. Cases that do not conform to this
      restriction fall outside the scope of this document.

   Thus, at each connection, each AS has one or more BGP speakers and
   one or more border gateways, and these BGP speakers and border
   gateways are all located on a shared network. Note that BGP speakers
   do not need to be a border gateway, and vice versa. Paths announced
   by a BGP speaker of one AS on a given connection are taken to be
   feasible for each of the border gateways of the other AS on the same
   shared network, i.e. indirect neighbors are allowed.

   Much of the traffic carried within an AS either originates or
   terminates at that AS (i.e., either the source IP address or the
   destination IP address of the IP packet identifies a host on a
   network internal to that AS).  Traffic that fits this description is
   called "local traffic". Traffic that does not fit this description is
   called "transit traffic". A major goal of BGP usage is to control the
   flow of transit traffic.

   Based on how a particular AS deals with transit traffic, the AS may
   now be placed into one of the following categories:

      stub AS: an AS that has only a single connection to one other AS.
      Naturally, a stub AS only carries local traffic.

      multihomed AS: an AS that has connections to more than one other
      AS, but refuses to carry transit traffic.

      transit AS: an AS that has connections to more than one other AS,
      and is designed (under certain policy restrictions) to carry both
      transit and local traffic.

   Since a full AS path provides an efficient and straightforward way of
   suppressing routing loops and eliminates the "count-to-infinity"
   problem associated with some distance vector algorithms, BGP imposes
   no topological restrictions on the interconnection of AS's.

3. BGP in the Internet

3.1 Topology Considerations

   The overall Internet topology may be viewed as an arbitrary
   interconnection of transit, multihomed, and stub AS's.  In order to
   minimize the impact on the current Internet infrastructure, stub and
   multihomed AS's need not use BGP.  These AS's may run other protocols
   (e.g., EGP) to exchange reachability information with transit AS's.
   Transit AS's using BGP will tag this information as having been



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


   learned by some method other than BGP. The fact that BGP need not run
   on stub or multihomed AS's has no negative impact on the overall
   quality of inter-AS routing for traffic that either destined to or
   originated from the stub or multihomed AS's in question.

   However, it is recommended that BGP be used for stub and multihomed
   AS's as well. In these situations, BGP will provide an advantage in
   bandwidth and performance over some of the currently used protocols
   (such as EGP).  In addition, this would reduce the need for the use
   of default routes and in better choices of Inter-AS routes for
   multihomed AS's.

3.2 Global Nature of BGP

   At a global level, BGP is used to distribute routing information
   among multiple Autonomous Systems. The information flows can be
   represented as follows:


                    +-------+         +-------+
              BGP   |  BGP  |   BGP   |  BGP  |   BGP
           ---------+       +---------+       +---------
                    |  IGP  |         |  IGP  |
                    +-------+         +-------+

                    <-AS A-->         <--AS B->

   This diagram points out that, while BGP alone carries information
   between AS's, both BGP and an IGP may carry information across an AS.
   Ensuring consistency of routing information between BGP and an IGP
   within an AS is a significant issue and is discussed at length later
   in Appendix A.

3.3 BGP Neighbor Relationships

   The Internet is viewed as a set of arbitrarily connected AS's. BGP
   speakers in each AS communicate with each other to exchange network
   reachability information based on a set of policies established
   within each AS. Routers that communicate directly with each other via
   BGP are known as BGP neighbors. BGP neighbors can be located within
   the same AS or in different AS's. For the sake of discussion, BGP
   communications with neighbors in different AS's will be referred to
   as External BGP, and with neighbors in the same AS as Internal BGP.

   There can be as many BGP speakers as deemed necessary within an AS.
   Usually, if an AS has multiple connections to other AS's, multiple
   BGP speakers are needed. All BGP speakers representing the same AS
   must give a consistent image of the AS to the outside. This requires



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


   that the BGP speakers have consistent routing information among them.
   These gateways can communicate with each other via BGP or by other
   means. The policy constraints applied to all BGP speakers within an
   AS must be consistent. Techniques such as using a tagged IGP (see
   A.2.2) may be employed to detect possible inconsistencies.

   In the case of External BGP, the BGP neighbors must belong to
   different AS's, but share a common network. This common network
   should be used to carry the BGP messages between them. The use of BGP
   across an intervening AS invalidates the AS path information. An
   Autonomous System number must be used with BGP to specify which
   Autonomous System the BGP speaker belongs to.

4. Requirements for Route Aggregation

   A conformant BGP-4 implementation is required to have the ability to
   specify when an aggregated route may be generated out of partial
   routing information. For example, a BGP speaker at the border of an
   autonomous system (or group of autonomous systems) must be able to
   generate an aggregated route for a whole set of destination IP
   addresses (in BGP-4 terminology such a set is called the Network
   Layer Reachability Information or NLRI) over which it has
   administrative control (including those addresses it has delegated),
   even when not all of them are reachable at the same time.

   A conformant implementation may provide the capability to specify
   when an aggregated NLRI may be generated.

   A conformant implementation is required to have the ability to
   specify how NLRI may be de-aggregated.

   A conformant implementation is required to support the following
   options when dealing with overlapping routes:

       - Install both the less and the more specific routes

       - Install the more specific route only

       - Install the less specific route only

       - Install neither route

   By default a BGP speaker should aggregate NLRI representing subnets
   to the corresponding network.

   Injecting NLRI representing arbitrary subnets into BGP without
   aggregation to the corresponding network shall be controlled via
   configuration parameters.



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


   Certain routing policies may depend on the NLRI (e.g., "research"
   versus "commercial"). Therefore, a BGP speaker that performs route
   aggregation should be cognizant, if possible, of potential
   implications on routing policies when aggregating NLRI.

5. Policy Making with BGP

   BGP provides the capability for enforcing policies based on various
   routing preferences and constraints. Policies are not directly
   encoded in the protocol. Rather, policies are provided to BGP in the
   form of configuration information.

   BGP enforces policies by affecting the selection of paths from
   multiple alternatives and by controlling the redistribution of