rfc1164.txt

RFC 的详细文档！

Network Working Group              J. Honig, Cornell Univ. Theory Center
Request for Comments: 1164                         D. Katz, Merit/NSFNET
                             M. Mathis, Pittsburgh Supercomputing Center
                       Y. Rekhter, T.J. Watson Research Center, IBM Corp
                                                     J. Yu, Merit/NSFNET
                                                               June 1990

       Application of the Border Gateway Protocol in the Internet

Status of this Memo

   This RFC, together with its companion RFC-1163, "A Border Gateway
   Protocol (BGP)", define a Proposed Standard for an inter-autonomous
   system routing protocol for the Internet.

   This protocol, like any other at this initial stage, may undergo
   modifications before reaching full Internet Standard status as a
   result of deployment experience.  Implementers are encouraged to
   track the progress of this or any protocol as it moves through the
   standardization process, and to report their own experience with the
   protocol.

   This protocol is being considered by the Interconnectivity Working
   Group (IWG) of the Internet Engineering Task Force (IETF).
   Information about the progress of BGP can be monitored and/or
   reported on the IWG mailing list ([e-mail]).

   Please refer to the latest edition of the "IAB Official Protocol
   Standards" RFC for current information on the state and status of
   standard Internet protocols.

   Distribution of this memo is unlimited.

Table of Contents

   1. Acknowledgements.......................................    2
   2. Introduction...........................................    2
   3. BGP Theory and Application.............................    3
   3.1 Topological Model.....................................    3
   3.2 BGP in the Internet...................................    4
   3.2.1 Topology Considerations.............................    4
   3.2.2 Global Nature of BGP................................    5
   3.2.3 BGP Neighbor Relationships..........................    5
   3.3 Policy Making with BGP................................    6
   4. Operational Issues.....................................    7
   4.1 Path Selection........................................    7
   4.2 Syntax and Semantics for BGP Configuration Files......    9
   5. The Interaction of BGP and an IGP......................   17



Interconnectivity Working Group                                 [Page 1]

RFC 1164                   BGP - Application                   June 1990


   5.1 Overview..............................................   17
   5.2 Methods for Achieving Stable Interactions.............   17
   5.2.1 Propagation of BGP Information via the IGP..........   18
   5.2.2 Tagged Interior Gateway Protocol....................   18
   5.2.3 Encapsulation.......................................   19
   5.2.4 Other Cases.........................................   19
   6. Implementation Recommendations.........................   20
   6.1 Multiple Networks Per Message.........................   20
   6.2 Preventing Excessive Resource Utilization.............   20
   6.3 Processing Messages on a Stream Protocol..............   21
   6.4 Processing Update Messages............................   21
   7. Conclusion.............................................   22
   References................................................   22
   Security Considerations...................................   22
   Authors' Addresses........................................   22

1. Acknowledgements

   The authors would like to thank Guy Almes (Rice University), Kirk
   Lougheed (cisco Systems), Hans-Werner Braun (Merit/NSFNET), Sue Hares
   (Merit/NSFNET), and the Interconnectivity Working Group of the
   Internet Engineering Task Force (chaired by Guy Almes) for their
   contributions to this paper.

2. Introduction

   The Border Gateway Protocol (BGP), described in RFC 1163, is an
   interdomain 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].

   This memo uses the term "Autonomous System" throughout.  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 ASs.  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 ASs to have a single
   coherent interior routing plan and presents a consistent picture of
   what networks are reachable through it.  From the standpoint of
   exterior routing, an AS can be viewed as monolithic: reachability to
   networks directly connected to the AS must be equivalent from all
   border gateways of the AS.




Interconnectivity Working Group                                 [Page 2]

RFC 1164                   BGP - Application                   June 1990


   This paper discusses the use of BGP in the Internet environment.
   Issues such as topology, the interaction between BGP and IGPs, and
   the enforcement of policy rules with BGP will be presented.

   All of the discussions in this paper are based on the assumption that
   the Internet is a collection of arbitrarily connected Autonomous
   Systems.  The AS is 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.

3. BGP Theory and Application

3.1 Topological Model

   We will be concerned throughout this paper with a general graph whose
   nodes are ASs and whose edges are connections between pairs of ASs.
   The notion of AS is discussed above in Section 2.  When we say that a
   connection exists between two ASs, we mean both of two things:

   physical connection: there is a shared network between the two ASs,
      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 ASs, 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 ASs 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.  Only the AS's border
   gateways on the connection's shared network may be used by that AS's
   BGP speakers on that shared network in NEXT_HOP attributes in Update
   messages.  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.  In all BGP usage, we intend
   that the flow of packets from one AS to the other correspond to
   advertised AS paths.

   Much of the traffic carried within an AS either originates or



Interconnectivity Working Group                                 [Page 3]

RFC 1164                   BGP - Application                   June 1990


   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 another AS.
      Naturally, a stub AS only carries local traffic.

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

   transit AS: an AS that has more than one connection to other ASs 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 ASs.

3.2 BGP in the Internet

3.2.1 Topology Considerations

   The overall Internet topology may be viewed as an arbitrary
   interconnection of transit, multihomed, and stub ASs.  In order to
   minimize the impact on the current Internet infrastructure, stub and
   multihomed ASs need not use BGP.  These ASs may run other protocols
   (e.g., EGP) to exchange reachability information with transit ASs.
   Transit ASs then tag this information as having been learned via EGP
   or some other method.  The fact that BGP need not run on stub or
   multihomed ASs has no negative impact on the overall quality of
   inter-AS routing for traffic not local to the stub or multihomed ASs
   in question.

   Of course, BGP may be used for stub and multihomed ASs as well,
   providing 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 mulitihomed ASs.






Interconnectivity Working Group                                 [Page 4]

RFC 1164                   BGP - Application                   June 1990


3.2.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 ASs, 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 this paper.

3.2.3 BGP Neighbor Relationships

   As discussed in the introduction, the Internet is viewed as a set of
   arbitrarily connected Autonomous Systems (ASs).  BGP gateways in each
   AS communicate with each other to exchange network reachability
   information based on a set of policies established within each AS.
   Computers 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 ASs.  For the sake of discussion, BGP communications
   with neighbors in different ASs will be referred to as External BGP,
   and with neighbors in the same AS as Internal BGP.

   External BGP In the case of External BGP, the BGP neighbors must
      belong to different ASs, 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.

   Internal BGP There can be as many BGP gateways as deemed necessary
      within an AS.  Usually, if an AS has multiple connections to other
      ASs, multiple BGP gateways are needed.  All BGP gateways
      representing the same AS must give a consistent image of the AS to
      the outside.  This requires that the BGP gateways 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 gateways within an AS must be consistent.




Interconnectivity Working Group                                 [Page 5]

RFC 1164                   BGP - Application                   June 1990


3.3 Policy Making with BGP

   BGP provides the capability of enforcing some policies based on
   various preferences and constraints.  Policies are determined by the
   AS administration and are provided to BGP in the form of
   configuration information.  These policies are enforced within a BGP
   speaker by affecting the selection of paths from multiple
   alternatives, and by controlling the redistribution of routing
   information.  Policies are not directly encoded in the protocol.

   Non-technical constraints 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 examples of non-technical constraints can be enforced with
   the use of BGP:

      1. A multihomed AS can refuse to act as a transit AS for other
         ASs.  (It does so by not advertising routes to networks other
         than those directly connected to it.)

      2. A multihomed AS can become a transit AS by allowing a certain
         set of ASs to use it as such.  (It does so by advertising
         routes to networks to this set of ASs.)

      3. An AS can favor or disfavor the use of certain ASs for carrying
         transit traffic from itself to networks advertised with
         competing AS paths.

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

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

      2. The quality of transit ASs.  If an AS determines, using BGP,
         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