rfc1268.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 731 行 · 第 1/3 页
TXT
731 行
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 (iwg@rice.edu).
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?