Haas, Ed. Request for Comments: S. Hares, Ed. 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.
|Published (Last):||21 July 2005|
|PDF File Size:||17.99 Mb|
|ePub File Size:||16.50 Mb|
|Price:||Free* [*Free Regsitration Required]|
Rekhter Request for Comments: T. Obsoletes: T. 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, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet.
Honig Cornell University for their contributions to the earlier version of this document. We like to explicitly thank Bob Braden ISI for the review of the earlier version of this document as well as his constructive and valuable comments. Johns, and Paul Tsuchiya, acted with a strong combination of toughness, professionalism, and courtesy. We would also like to thank Mike Craren Proteon, Inc. This network reachability information includes information on the list of Autonomous Systems ASs that reachability information traverses.
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. BGP-4 provides a new set of mechanisms for supporting classless interdomain routing. These mechanisms include support for advertising an IP prefix and eliminates the concept of network "class" within BGP.
BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. These changes provide support for the proposed supernetting scheme [ 8 , 9 ].
To characterize the set of policy decisions that can be enforced using BGP, one must focus on the rule that a BGP speaker advertise to its peers other BGP speakers which it communicates with in neighboring 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.
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. The error notification mechanism used in BGP assumes that the transport protocol supports a "graceful" close, i. In the following descriptions the phrase "transport protocol connection" can be understood to refer to a TCP connection. 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 destinations are reachable through it.
The planned use of BGP in the Internet environment, including such issues as topology, the interaction between BGP and IGPs, and the enforcement of routing policy rules is presented in a companion document [ 5 ]. This document is the first of a series of documents planned to explore various aspects of BGP application. Please send comments to the BGP mailing list bgp ans. Summary of Operation Two systems form a transport protocol connection between one another.
They exchange messages to open and confirm the connection parameters. The initial data flow is the entire BGP routing table. Incremental updates are sent as the routing tables change. Therefore, a BGP speaker must retain the current version of the entire BGP routing tables of all of its peers for the duration of the connection. KeepAlive messages are sent periodically to ensure the liveness of the connection. Notification messages are sent in response to errors or special conditions.
If a connection encounters an error condition, a notification message is sent and the connection is closed. The hosts executing the Border Gateway Protocol need not be routers. A non-routing host could exchange routing information with routers via EGP or even an interior routing protocol. That non-routing host could then use BGP to exchange routing information with a border router in another Autonomous System.
The implications and applications of this architecture are for further study. If a particular AS has multiple BGP speakers and is providing transit service for other ASs, then care must be taken to ensure a consistent view of routing within the AS.
A consistent view of the interior routes of the AS is provided by the interior routing protocol. Care must be taken to ensure that the interior routers have all been updated with transit information before the BGP speakers announce to other ASs that transit service is being provided. Similarly, a peer in a different AS is referred to as an external peer, while a peer in the same AS may be described as an internal peer.
If a BGP speaker chooses to advertise the route, it may add to or modify the path attributes of the route before advertising it to a peer. BGP provides mechanisms by which a BGP speaker can inform its peer that a previously advertised route is no longer available for use.
Their contents represent routes that are available as an input to the Decision Process. The choice of implementation for example, 3 copies of the information vs 1 copy with pointers is not constrained by the protocol. Messages are sent over a reliable transport protocol connection. A message is processed only after it is entirely received. The maximum message size is octets. All implementations are required to support this maximum message size.
The smallest message that may be sent consists of a BGP header without a data portion, or 19 octets. There may or may not be a data portion following the header, depending on the message type. Otherwise, the value of the marker can be predicted by some a computation specified as part of the authentication mechanism which is specified as part of the Authentication Information used. Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets.
Thus, e. The value of the Length field must always be at least 19 and no greater than , and may be further constrained, depending on the message type. No "padding" of extra data after the message is allowed, so the Length field must have the smallest value required given the rest of the message. The current BGP version number is 4. My Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the sender.
An implementation may reject connections on the basis of the Hold Time. Optional Parameters Length: This 1-octet unsigned integer indicates the total length of the Optional Parameters field in octets. If the value of this field is zero, no Optional Parameters are present. Type Parm. Parameter Type is a one octet field that unambiguously identifies individual parameters.
Parameter Length is a one octet field that contains the length of the Parameter Value field in octets. Parameter Value is a variable length field that is interpreted according to the value of the Parameter Type field. Whenever an authentication mechanism is specified for use within BGP, three things must be included in the specification: - the value of the Authentication Code which indicates use of the mechanism, - the form and meaning of the Authentication Data, and - the algorithm for computing values of Marker fields.
Note that a separate authentication mechanism may be used in establishing the transport level connection. Authentication Data: The form and meaning of this field is a variable- length field depend on the Authentication Code. The minimum length of the OPEN message is 29 octets including message header.
By applying rules to be discussed, routing information loops and some other anomalies may be detected and removed from inter-AS routing. An UPDATE message is used to advertise a single feasible route to a peer, or to withdraw multiple unfeasible routes from service see 3. Its value must allow the length of the Network Layer Reachability Information field to be determined as specified below. Withdrawn Routes: This is a variable length field that contains a list of IP address prefixes for the routes that are being withdrawn from service.
A length of zero indicates a prefix that matches all IP addresses with prefix, itself, of zero octets. Note that the value of trailing bits is irrelevant. Total Path Attribute Length: This 2-octet unsigned integer indicates the total length of the Path Attributes field in octets. Its value must allow the length of the Network Layer Reachability field to be determined as specified below.
Attribute Type is a two-octet field that consists of the Attribute Flags octet followed by the Attribute Type Code octet. Flags Attr.
It defines whether the attribute is optional if set to 1 or well-known if set to 0. The second high-order bit bit 1 of the Attribute Flags octet is the Transitive bit. It defines whether an optional attribute is transitive if set to 1 or non-transitive if set to 0. For well-known attributes, the Transitive bit must be set to 1. See Section 5 for a discussion of transitive attributes.
The third high-order bit bit 2 of the Attribute Flags octet is the Partial bit. It defines whether the information contained in the optional transitive attribute is partial if set to 1 or complete if set to 0. For well-known attributes and for optional non-transitive attributes the Partial bit must be set to 0. The fourth high-order bit bit 3 of the Attribute Flags octet is the Extended Length bit.
It defines whether the Attribute Length is one octet if set to 0 or two octets if set to 1. Extended Length may be used only if the length of the attribute value is greater than octets. The lower-order four bits of the Attribute Flags octet are. They must be zero and must be ignored when received. Currently defined Attribute Type Codes are discussed in Section 5.
Border Gateway Protocol
It represents the consensus of the IETF community. All rights reserved. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Mauch, et al.
Rekhter, Ed. Request for Comments: T. Li, Ed. Obsoletes: S.
This full-mesh configuration requires that each router maintain a session to every other router. In large networks, this number of sessions may degrade performance of routers, due to either a lack of memory, or high CPU process requirements. Route reflectors[ edit ] Route reflectors  reduce the number of connections required in an AS. A single router or two for redundancy can be made a route reflector: other routers in the AS need only be configured as peers to them. A route reflector offers an alternative to the logical full-mesh requirement of internal border gateway protocol IBGP.