📄 rfc827.txt
字号:
- 7 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
2 NEIGHBOR ACQUISITION
Before it is possible to obtain routing information from an
exterior gateway, it is necessary to acquire that gateway as a
direct neighbor. (The distinction between direct and indirect
neighbors will be made in a later section.) In order for two
gateways to become direct neighbors, they must be neighbors, in
the sense defined above, and they must execute the NEIGHBOR
ACQUISITION PROTOCOL, which is simply a standard three-way
handshake.
A gateway that wishes to initiate neighbor acquisition with
another sends it a Neighbor Acquisition Request. This message
should be repeatedly transmitted (at a reasonable rate, perhaps
once every 30 seconds or so) until a Neighbor Acquisition Reply
is received. The Request will contain an identification number
which is copied into the reply so that request and reply can be
matched up.
A gateway receiving a Neighbor Acquisition Request must
determine whether it wishes to become a direct neighbor of the
source of the Request. If not, it may, at its option, respond
with a Neighbor Acquisition Refusal message, optionally
specifying the reason for refusal. Otherwise, it should send a
Neighbor Acquisition Reply message. It must also send a Neighbor
- 8 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
Acquisition Request message, unless it has done so already.
Two gateways become direct neighbors when each has sent a
Neighbor Acquisition Message to, and received the corresponding
Neighbor Acquisition Reply from, the other.
Unmatched Replies or Refusals should be discarded after a
reasonable period of time. However, information about any such
unmatched messages may be useful for diagnostic purposes.
A Neighbor Acquisition Message from a gateway which is
already a direct neighbor should be responded to with a Reply and
a Neighbor Acquisition Message.
If a Neighbor Acquisition Reply is received from a
prospective neighbor, but a period of time passes during which no
Neighbor Acquisition Message is received from that prospective
neighbor, the neighbor acquisition protocol shall be deemed
incomplete. A Neighbor Cease message (see below) should then be
sent. If one gateway still desires to acquire the other as a
neighbor, the protocol must be repeated from the beginning.
If a gateway wishes to cease being a neighbor of a
particular exterior gateway, it sends a Neighbor Cease message.
A gateway receiving a Neighbor Cease message should always
respond with a Neighbor Cease Acknowledgment. It should cease to
- 9 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
treat the sender of the message as a neighbor in any way. Since
there is a significant amount of protocol run between direct
neighbors (see below), if some gateway no longer needs to be a
direct neighbor of some other, it is "polite" to indicate this
fact with a Neighbor Cease Message. The Neighbor Cease Message
should be retransmitted (up to some number of times) until an
acknowledgment for it is received.
Once a Neighbor Cease message has been received, the
Neighbor Reachability Protocol (below) should cease to be
executed.
NOTE THAT WE HAVE NOT SPECIFIED THE WAY IN WHICH ONE GATEWAY
INITIALLY DECIDES THAT IT WANTS TO BECOME A NEIGHBOR OF ANOTHER.
While this is hardly a trivial problem, it is not part of the
External Gateway Protocol.
- 10 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
3 NEIGHBOR REACHABILITY PROTOCOL
It is important for a gateway to keep real-time information
as to the reachability of its neighbors. If a gateway concludes
that a particular neighbor cannot be reached, it should cease
forwarding traffic to that gateway. To make that determination,
a NEIGHBOR REACHABILITY protocol is needed. The EGP protocol
provides two messages types for this purpose -- a "Hello" message
and an "I Heard You" message.
When a "Hello" message is received from a direct neighbor,
an "I Heard You" must be returned to that neighbor "immediately".
The delay between receiving a "Hello" and returning an "I Heard
You" should never be more than a few seconds.
At the current time, the reachability determination
algorithm is left to the designers of a particular gateway. We
have in mind algorithms like the following:
A reachable neighbor shall be declared unreachable if,
during the time in which we sent our last n "Hello"s, we received
fewer than k "I Heard You"s in return. An unreachable neighbor
shall be declared reachable if, during the time in which we sent
our last m "Hello"s, we received at least j "I Heard You"s in
return.
- 11 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
However, the frequency with which the "Hello"s are sent, and
the values of the parameters k, n, j, and m cannot be specified
here. For best results, this will depend on the characteristics
of the neighbor and of the network which the neighbors have in
common. THIS IMPLIES THAT THE PROPER PARAMETERS MAY NEED TO BE
DETERMINED JOINTLY BY THE DESIGNERS AND IMPLEMENTERS OF THE TWO
NEIGHBORING GATEWAYS; choosing algorithms and parameters in
isolation, without considering the characteristics of the
neighbor and the connecting network, would not be expected to
result in optimum reachability determinations.
The "Hello" and "I Heard You" messages have a status field
which the sending gateway uses to indicate whether it thinks the
receiving gateway is reachable or not. This information can be
useful for diagnostic purposes. It also allows one gateway to
make its reachability determination parasitic on the other: only
one gateway actually needs to send "Hello" messages, and the
other can declare it up or down based on the status field in the
"Hello". That is, the "passive" gateway (which sends only "I
Heard You"s) declares the "active" one (which sends only
"Hello"s) to be reachable when the "Hello"s from the active one
indicate that it has declared the passive one to be reachable.
Of course, this can only work if there is prior agreement as to
which neighbor is to be the active one. (Ways of coming to this
- 12 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
"prior agreement" are not part of the Exterior Gateway Protocol.)
A direct neighbor gateway should also be declared
unreachable if the network connecting it supplies lower level
protocol information from which this can be deduced. Thus, for
example, if a gateway receives an 1822 Destination Dead message
from the ARPANET which indicates that a direct neighbor is dead,
it should declare that neighbor unreachable. The neighbor should
not be declared reachable again until the requisite number of
Hello/I-Heard-You packets have been exchanged.
A direct neighbor which has become unreachable does not
thereby cease to be a direct neighbor. The neighbor can be
declared reachable again without any need to go through the
neighbor acquisition protocol again. However, if the neighbor
remains unreachable for an extremely long period of time, such as
an hour, the gateway should cease to treat it as a neighbor,
i.e., should cease sending Hello messages to it. The neighbor
acquisition protocol would then need to be repeated before it
could become a direct neighbor again.
"Hello" and "I Heard You" messages from gateway G to gateway
G' also carry the identification number of the NR poll message
(see below) which G has most recently received from G'.
- 13 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
"Hello" and "I Heard You" messages from gateway G to gateway
G' also carry the minimum interval in minutes with which G is
willing to be polled by G' for NR messages (see below).
"Hello" messages from sources other than direct neighbors
should simply be ignored. However, logging the presence of any
such messages might provide useful diagnostic information.
A gateway which is going down, or whose interface to the
network which connects it to a particular neighbor is going down,
should send a Gateway Going Down message to all direct neighbors
which will no longer be able to reach it. It should retransmit
that message (up to some number of times) until it receives a
Gateway Going Down Acknowledgment. This provides the neighbors
with an advance warning of an outage, and enables them to prepare
for it in a way which will minimize disruption to existing
traffic.
- 14 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
4 NETWORK REACHABILITY (NR) MESSAGE
Terminology: Let gateway G have an interface to network N.
We say that G is AN APPROPRIATE FIRST HOP to network M relative
to network N (where M and N are distinct networks) if and only if
the following condition holds:
Traffic which is destined for network M, and which arrives
at gateway G over its network N interface, will be forwarded
to M by G over a path which does not include any other
gateway with an interface to network N.
In short, G is an appropriate first hop for network M
relative to network N just in case there is no better gateway on
network N through which to route traffic which is destined for
network M. For optimal routing, traffic in network N which is
destined for network M ought always to be forwarded to a gateway
which is an appropriate first hop.
In order for exterior neighbors G and G' (which are
neighbors over network N) to be able to use each other as packet
switches for forwarding traffic to remote networks, each needs to
know the list of networks for which the other is an appropriate
first hop. The Exterior Gateway Protocol defines a message,
called the Network Reachability Message (or NR message), for
transferring this information.
- 15 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
Let G be a gateway on network N. Then the NR message which
G sends about network N must contain the following information:
A list of all the networks for which G is an appropriate
first hop relative to network N.
If G' can obtain this information from exterior neighbor G, then
it knows that no traffic destined for networks which are NOT in
that list should be forwarded to G. (It cannot simply conclude,
however, that all traffic for any networks in that list ought to
be forwarded via G, since G' may also have other neighbors which
are also appropriate first hops to network N. For example, G and
G'' might each be neighbors of G', but might be "equidistant"
from some network M. Then each could be an appropriate first
hop.)
For each network in the list, the NR message also contains a
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -