rfc1771.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,548 行 · 第 1/5 页
TXT
1,548 行
for advertisement to specific peers by means of the local speaker's
UPDATE messages.
Although the conceptual model distinguishes between Adj-RIBs-In,
Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an
implementation must maintain three separate copies of the routing
information. The choice of implementation (for example, 3 copies of
the information vs 1 copy with pointers) is not constrained by the
protocol.
4. Message Formats
This section describes message formats used by BGP.
Messages are sent over a reliable transport protocol connection. A
message is processed only after it is entirely received. The maximum
message size is 4096 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.
Rekhter & Li [Page 6]
RFC 1771 BGP-4 March 1995
4.1 Message Header Format
Each message has a fixed-size header. There may or may not be a data
portion following the header, depending on the message type. The
layout of these fields is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker:
This 16-octet field contains a value that the receiver of the
message can predict. If the Type of the message is OPEN, or if
the OPEN message carries no Authentication Information (as an
Optional Parameter), then the Marker must be all ones.
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. The Marker can be used to detect loss of synchronization
between a pair of BGP peers, and to authenticate incoming BGP
messages.
Length:
This 2-octet unsigned integer indicates the total length of the
message, including the header, in octets. Thus, e.g., it
allows one to locate in the transport-level stream the (Marker
field of the) next message. The value of the Length field must
always be at least 19 and no greater than 4096, 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.
Rekhter & Li [Page 7]
RFC 1771 BGP-4 March 1995
Type:
This 1-octet unsigned integer indicates the type code of the
message. The following type codes are defined:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
4.2 OPEN Message Format
After a transport protocol connection is established, the first
message sent by each side is an OPEN message. If the OPEN message is
acceptable, a KEEPALIVE message confirming the OPEN is sent back.
Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
messages may be exchanged.
In addition to the fixed-size BGP header, the OPEN message contains
the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
This 1-octet unsigned integer indicates the protocol version
number 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.
Rekhter & Li [Page 8]
RFC 1771 BGP-4 March 1995
Hold Time:
This 2-octet unsigned integer indicates the number of seconds
that the sender proposes for the value of the Hold Timer. Upon
receipt of an OPEN message, a BGP speaker MUST calculate the
value of the Hold Timer by using the smaller of its configured
Hold Time and the Hold Time received in the OPEN message. The
Hold Time MUST be either zero or at least three seconds. An
implementation may reject connections on the basis of the Hold
Time. The calculated value indicates the maximum number of
seconds that may elapse between the receipt of successive
KEEPALIVE, and/or UPDATE messages by the sender.
BGP Identifier:
This 4-octet unsigned integer indicates the BGP Identifier of
the sender. A given BGP speaker sets the value of its BGP
Identifier to an IP address assigned to that BGP speaker. The
value of the BGP Identifier is determined on startup and is the
same for every local interface and every BGP peer.
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.
Optional Parameters:
This field may contain a list of optional parameters, where
each parameter is encoded as a <Parameter Type, Parameter
Length, Parameter Value> triplet.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
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.
Rekhter & Li [Page 9]
RFC 1771 BGP-4 March 1995
This document defines the following Optional Parameters:
a) Authentication Information (Parameter Type 1):
This optional parameter may be used to authenticate a BGP
peer. The Parameter Value field contains a 1-octet
Authentication Code followed by a variable length
Authentication Data.
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code:
This 1-octet unsigned integer indicates the
authentication mechanism being used. 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).
Rekhter & Li [Page 10]
RFC 1771 BGP-4 March 1995
4.3 UPDATE Message Format
UPDATE messages are used to transfer routing information between BGP
peers. The information in the UPDATE packet can be used to construct
a graph describing the relationships of the various Autonomous
Systems. 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.1). An UPDATE message may simultaneously advertise a feasible route
and withdraw multiple unfeasible routes from service. The UPDATE
message always includes the fixed-size BGP header, and can optionally
include the other fields as shown below:
+-----------------------------------------------------+
| Unfeasible Routes Length (2 octets) |
+-----------------------------------------------------+
| Withdrawn Routes (variable) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+-----------------------------------------------------+
Unfeasible Routes Length:
This 2-octets unsigned integer indicates the total length of
the Withdrawn Routes field in octets. Its value must allow the
length of the Network Layer Reachability Information field to
be determined as specified below.
A value of 0 indicates that no routes are being withdrawn from
service, and that the WITHDRAWN ROUTES field is not present in
this UPDATE message.
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. Each IP address prefix is encoded as a 2-tuple of the
form <length, prefix>, whose fields are described below:
Rekhter & Li [Page 11]
RFC 1771 BGP-4 March 1995
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?