rfc1268.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 731 行 · 第 1/3 页

Network Working Group                                         Y. Rekhter
Request for Comments: 1268        T.J. Watson Research Center, IBM Corp.
Obsoletes: RFC 1164                                             P. Gross
                                                                     ANS
                                                                 Editors
                                                            October 1991


       Application of the Border Gateway Protocol in the Internet

Status of this Memo

   This protocol is being developed by the Border Gateway Protocol
   Working Group (BGP) of the Internet Engineering Task Force (IETF).
   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" 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 (BGP-3)", define an inter-autonomous system routing
   protocol for the Internet.  "A Border Gateway Protocol (BGP-3)"
   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]).

Table of Contents

   1. Introduction...................................................   2
   2. BGP Topological Model..........................................   3
   3. BGP in the Internet............................................   4
   4. Policy Making with BGP.........................................   5
   5. Path Selection with BGP........................................   6
   6. Required set of supported routing policies.....................   8
   7. Conclusion.....................................................   9
   Appendix A. The Interaction of BGP and an IGP.....................   9
   References........................................................  12
   Security Considerations...........................................  12
   Authors' Addresses................................................  13

Acknowledgements

   This document was original published as RFC 1164 in June 1990,



BGP Working Group                                               [Page 1]

RFC 1268           Application of BGP in the Internet       October 1991


   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).

   This updated version of the document is the product of the IETF BGP
   Working Group with Phillip Gross (ANS) and Yakov Rekhter (IBM) as
   editors.  John Moy (Proteon) contributed Section 6 "Recommended set
   of supported routing policies".

   We also like to explicitly thank Bob Braden (ISI) for the review of
   this document as well as his constructive and valuable comments.

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.

   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. From
   the standpoint of exterior routing, an AS can be viewed as
   monolithic: networks within an AS must maintain connectivity via
   intra-AS paths.




BGP Working Group                                               [Page 2]

RFC 1268           Application of BGP in the Internet       October 1991


   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
      resort to Inter-AS or Intra-AS routing.

      BGP connection:  There is a BGP session between BGP speakers on
      each of the AS's, and this session communicates to each connected
      AS those routes through the physically connected border gateways
      of the other AS that can be used for specific networks. 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 BGP
      session between the 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
   connection, 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 directly connected 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.




BGP Working Group                                               [Page 3]

RFC 1268           Application of BGP in the Internet       October 1991


      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
   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 not local to the stub or
   multihomed AS's in question.

   However, it is recommended that BGP may be used for stub and
   multihomed AS's as well, providing an advantage in bandwidth and
   performance over some of the currently used protocols (such as EGP).
   In addition, this would result in less need for the use of defaults
   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



BGP Working Group                                               [Page 4]

RFC 1268           Application of BGP in the Internet       October 1991


   between AS's, a combination of BGP and an IGP carries 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