📄 rfc827.txt
字号:
RFC 827
EXTERIOR GATEWAY PROTOCOL (EGP)
Eric C. Rosen
Bolt Beranek and Newman Inc.
October 1982
It is proposed to establish a standard for Gateway to Gateway procedures
that allow the Gateways to be mutually suspicious. This document is a
DRAFT for that standard. Your comments are strongly encouraged.
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
Table of Contents
1 INTRODUCTION.......................................... 1
2 NEIGHBOR ACQUISITION.................................. 8
3 NEIGHBOR REACHABILITY PROTOCOL....................... 11
4 NETWORK REACHABILITY (NR) MESSAGE.................... 15
5 POLLING FOR NR MESSAGES.............................. 22
6 SENDING NR MESSAGES.................................. 25
7 INDIRECT NEIGHBORS................................... 27
8 HOW TO BE A STUB GATEWAY............................. 28
9 LIMITATIONS.......................................... 32
- i -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
1 INTRODUCTION
The DARPA Catenet is expected to be a continuously expanding
system, with more and more hosts on more and more networks
participating in it. Of course, this will require more and more
gateways. In the past, such expansion has taken place in a
relatively unstructured manner. New gateways, often containing
radically different software than the existing gateways, would be
added and would immediately begin participating in the common
routing algorithm via the GGP protocol. However, as the internet
grows larger and larger, this simple method of expansion becomes
less and less feasible. There are a number of reasons for this:
- the overhead of the routing algorithm becomes excessively
large;
- the proliferation of radically different gateways
participating in a single common routing algorithm makes
maintenance and fault isolation nearly impossible, since
it becomes impossible to regard the internet as an
integrated communications system;
- the gateway software and algorithms, especially the
routing algorithm, become too rigid and inflexible, since
any proposed change must be made in too many different
places and by too many different people.
- 1 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
In the future, the internet is expected to evolve into a set
of separate domains or "autonomous systems", each of which
consists of a set of one or more relatively homogeneous gateways.
The protocols, and in particular the routing algorithm which
these gateways use among themselves, will be a private matter,
and need never be implemented in gateways outside the particular
domain or system.
In the simplest case, an autonomous system might consist of
just a single gateway connecting, for example, a local network to
the ARPANET. Such a gateway might be called a "stub gateway",
since its only purpose is to interface the local network to the
rest of the internet, and it is not intended to be used for
handling any traffic which neither originated in nor is destined
for that particular local network. In the near-term future, we
will begin to think of the internet as a set of autonomous
systems, one of which consists of the DARPA gateways on ARPANET
and SATNET, and the others of which are stub gateways to local
networks. The former system, which we shall call the "core"
system, will be used as a transport or "long-haul" system by the
latter systems.
Ultimately, however, the internet may consist of a number of
co-equal autonomous systems, any of which may be used (with
certain restrictions which will be discussed later) as a
- 2 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
transport medium for traffic originating in any system and
destined for any system. When this more complex configuration
comes into being, it will be inappropriate to regard any one
autonomous system as a "core" system. For the sake of
concreteness, however, and because the initial implementations of
the Exterior Gateway Protocol are expected to focus on the the
case of connecting "stub gateways" to the DARPA gateways on
ARPANET and SATNET, we will often use the term "core" gateways in
our examples and discussion.
The purpose of the Exterior Gateway Protocol (EGP) is to
enable one or more autonomous systems to be used as transport
media for traffic originating in some other autonomous system and
destined for yet another, while allowing the end-user to see the
composite of all the autonomous systems as a single internet,
with a flat, uniform address space. The route which a datagram
takes through the internet, and the number of autonomous systems
which it traverses, are to be transparent to the end-user
(unless, of course, the end-user makes use of the IP "source
route" option).
In describing the Exterior Gateway Protocol, we have
deliberately left a great deal of latitude to the designers and
implementers of particular autonomous systems, particularly with
regard to timer values. We have done this because we expect that
- 3 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
different gateway implementations and different internet
environments may just have different requirements and goals, so
that no single strict implementation specification could apply to
all. However, this does NOT mean that ANY implementation which
conforms to the specification will work well, or that the areas
in which we have left latitude are not crucial to performance.
The fact that some time-out value, for example, is not specified
here does not mean that everything will work no matter what value
is assigned.
Autonomous systems will be assigned 16-bit identification
numbers (in much the same ways as network and protocol numbers
are now assigned), and every EGP message header contains one word
for this number. Zero will not be assigned to any autonomous
system; rather, the presence of a zero in this field will
indicate that no number is present.
We need to introduce the concept of one gateway being a
NEIGHBOR of another. In the simplest and most common case, we
call two gateways "neighbors" if there is a network to which each
has an interface. However, we will need a somewhat more general
notion of "neighbor" to allow the following two cases:
a) Two gateways may be regarded as neighbors if they are
directly connected not by a network (in the usual sense
- 4 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
of the term), but by a simple wire, or HDLC line, or some
similar means of "direct connection".
b) Two gateways may be regarded as neighbors if they are
connected by an "internet" which is transparent to them.
That is, we would like to be able to say that two
gateways are neighbors even if they are connected by an
internet, as long as the gateways utilize no knowledge of
the internal structure of that internet in their own
packet-forwarding algorithms.
In order to handle all these cases, let us say that two gateways
are NEIGHBORS if they are connected by some communications medium
whose internal structure is transparent to them. (See IEN 184
for a more general discussion of this notion of neighbor.)
If two neighbors are part of the same autonomous system, we
call them INTERIOR NEIGHBORS; if two neighbors are not part of
the same autonomous system, we call them EXTERIOR NEIGHBORS. In
order for one system to use another as a transport medium,
gateways which are exterior neighbors of each other must be able
to find out which networks can be reached through the other. The
Exterior Gateway Protocol enables this information to be passed
between exterior neighbors. Since it is a polling protocol, it
also enables each gateway to control the rate at which it sends
- 5 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
and receives network reachability information, allowing each
system to control its own overhead. It also enables each system
to have an independent routing algorithm whose operation cannot
be disrupted by failures of other systems.
It must be clearly understood that any autonomous system in
which routing needs to be performed among gateways within that
system must implement its own routing algorithm. (A routing
algorithm is not generally necessary for a simple autonomous
system which consists of a single stub gateway.) The Exterior
Gateway Protocol is NOT a routing algorithm. It enables exterior
neighbors to exchange information which is likely to be needed by
any routing algorithm, but it does NOT specify what the gateways
are to do with this information. The "routing updates" of some
autonomous system's interior routing algorithm may or may not be
similar in format to the messages of the exterior gateway
protocol. The gateways in the DARPA "core" system will initially
use the GGP protocol (the old Gateway-Gateway protocol) as their
routing algorithm, but this will be subject to change. Gateways
in other autonomous systems may use their own Interior Gateway
Protocols (IGPs), which may or may not be similar to the IGP of
any other autonomous system. They may, of course, use GGP, but
will not be permitted to exchange GGP messages with gateways in
other autonomous systems.
- 6 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
It must also be clearly understood that the Exterior Gateway
Protocol is NOT intended to provide information which could be
used as input to a completely general area or hierarchical
routing algorithm. It is intended for a set of autonomous
systems which are connected in a tree, with no cycles. It does
not enable the passing of sufficient information to prevent
routing loops if cycles in the topology do exist.
The Exterior Gateway Protocol has three parts: (a) Neighbor
Acquisition Protocol, (b) Neighbor Reachability Protocol, and (c)
Network Reachability determination. Note that all messages
defined by EGP are intended to travel only a single "hop". That
is, they originate at one gateway and are sent to a neighboring
gateway without the mediation of any intervening gateway.
Therefore, the time-to-live field should be set to a very small
value. Gateways which encounter EGP messages in their message
streams which are not addressed to them may discard them.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -