Border Gateway Protocol 3 (BGP-3)
RFC 1267
| Document | Type |
RFC - Historic
(October 1991; No errata)
Obsoletes RFC 1163
Was draft-ietf-bgp-bgp3 (idr WG)
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 1267 (Historic) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group K. Lougheed
Request for Comments: 1267 cisco Systems
Obsoletes RFCs: 1105, 1163 Y. Rekhter
T.J. Watson Research Center, IBM Corp.
October 1991
A Border Gateway Protocol 3 (BGP-3)
Status of this Memo
This memo, together with its companion document, "Application of the
Border Gateway Protocol in the Internet", define an inter-autonomous
system routing protocol for the Internet. 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.
1. Acknowledgements
We would like to express our thanks to Guy Almes (Rice University),
Len Bosack (cisco Systems), Jeffrey C. Honig (Cornell Theory Center)
and all members of the Interconnectivity Working Group of the
Internet Engineering Task Force, chaired by Guy Almes, for their
contributions to this document.
We like to explicitly thank Bob Braden (ISI) for the review of this
document as well as his constructive and valuable comments.
We would also like to thank Bob Hinden, Director for Routing of the
Internet Engineering Steering Group, and the team of reviewers he
assembled to review earlier versions of this document. This team,
consisting of Deborah Estrin, Milo Medin, John Moy, Radia Perlman,
Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted with a
strong combination of toughness, professionalism, and courtesy.
2. Introduction
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol. It is built on experience gained with EGP as
defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
described in RFC 1092 [2] and RFC 1093 [3].
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network
reachability information includes information on the full path of
Lougheed & Rekhter [Page 1]
RFC 1267 BGP-3 October 1991
Autonomous Systems (ASs) that traffic must transit to reach these
networks. This information is sufficient to construct a graph of AS
connectivity from which routing loops may be pruned and some policy
decisions at the AS level may be enforced.
To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that an AS advertize to its
neighbor ASs only those routes that it itself uses. This rule
reflects the "hop-by-hop" routing paradigm generally used throughout
the current Internet. Note that some policies cannot be supported by
the "hop-by-hop" routing paradigm and thus require techniques such as
source routing to enforce. For example, BGP does not enable one AS
to send traffic to a neighbor AS intending that that traffic take a
different route from that taken by traffic originating in the
neighbor AS. On the other hand, BGP can support any policy
conforming to the "hop-by-hop" routing paradigm. Since the current
Internet uses only the "hop-by-hop" routing paradigm and since BGP
can support any policy that conforms to that paradigm, BGP is highly
applicable as an inter-AS routing protocol for the current Internet.
A more complete discussion of what policies can and cannot be
enforced with BGP is outside the scope of this document (but refer to
the companion document discussing BGP usage [5]).
BGP runs over a reliable transport protocol. This eliminates the
need to implement explicit update fragmentation, retransmission,
acknowledgement, and sequencing. Any authentication scheme used by
the transport protocol may be used in addition to BGP's own
authentication mechanisms. The error notification mechanism used in
BGP assumes that the transport protocol supports a "graceful" close,
i.e., that all outstanding data will be delivered before the
connection is closed.
BGP uses TCP [4] as its transport protocol. TCP meets BGP's
transport requirements and is present in virtually all commercial
routers and hosts. In the following descriptions the phrase
"transport protocol connection" can be understood to refer to a TCP
connection. BGP uses TCP port 179 for establishing its connections.
This memo uses the term `Autonomous System' (AS) throughout. The
Show full document text