Network Working Group Network Technical Advisory Group
Request for Comments: 985 NSF
May 1986
Requirements for Internet Gateways -- Draft
Status of this Memo
This RFC summarizes the requirements for gateways to be used on
networks supporting the DARPA Internet protocols. While it applies
specifically to National Science Foundation research programs, the
requirements are stated in a general context and are believed
applicable throughout the Internet community. This document was
prepared by the Gateway Requirements Subcommittee of the NSF Network
Technical Advisory Group in cooperation with the Internet Activities
Board, Internet Architecture Task Force and Internet Engineering Task
Force. It requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
The purpose of this document is to present guidance for vendors
offering products that might be used or adapted for use in an
Internet application. It enumerates the protocols required and gives
references to RFCs and other documents describing the current
specifications. In a number of cases the specifications are evolving
and may contain ambiguous or incomplete information. In these cases
further discussion giving specific guidance is included in this
document. Specific policy issues relevant to the NSF scientific
networking community are summarized in an Appendix.
*********************************************************************
This is a DRAFT edition of this statement of gateway requirements.
Comments are sought on this document for consideration and
possibly incorporated in the final edition. Comments are
especially sought from those actually developing gateways,
particular vendors and potential vendors of gateways. The period
for comments is 90 days ending 15-Aug-86, at which time revised
edition will be issued with a new RFC number.
*********************************************************************
Suggestions and comments on this document can be sent to the
subcommittee chairman Dave Mills (mills@usc-isid.arpa), or NTAG
committee chairman Dave Farber (farber@huey.udel.edu). The
subcommittee members, present affiliations and Internet mailboxes are
as follows:
Hank Dardy, NRL dardy@nrl.arpa
Dave Farber, U Delaware farber@huey.udel.edu
Dennis Jennings, JVNC jennings%pucc.bitnet@wiscvm.wisc.edu
NTAG [Page 1]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
Larry Landweber, U Wisconsin landweber@rsch.wisc.edu
Tony Lauck, DEC rhea!bergil!lauck@decwrl.arpa
Dave Mills (Chairman), Linkabit mills@usc-isid.arpa
Dennis Perry, DARPA/IPTO perry@ipto.arpa
The subcommittee wishes to thank the following additional
contributors and invited referees:
Len Bosack, Stanford U/CISCO bosack@su-score.arpa
Bob Braden, ISI braden@isi-braden.arpa
Hans-Werner Braun, U Michigan hwb@gw.umich.edu
Noel Chiappa, MIT/Proteon jnc@proteon.arpa
Doug Comer, Purdue U dec@cs.purdue.edu
Ira Fuchs, Princeton U fuchs%pucc.bitnet@wiscvm.wisc.edu
Ed Krol, U Illinois krol%uiucvmd.bitnet@wiscvm.wisc.edu
Barry Leiner, RIACS leiner@riacs.arpa
Mike Muuss, BRL mike@brl.arpa
Ron Natalie, BRL ron@brl.arpa
Harvey Newman, CIT newman@cit-hex.arpa
Jon Postel, ISI postel@usc-isib.arpa
Marshall Rose, NRTC mrose@nrtc-gremlin.northrop.com
Jeff Schiller, MIT jis@bitsy.mit.edu
Lixia Zhang, MIT lixia@xx.lcs.mit.edu
1. Introduction
The following sections are intended as an introduction and background
for those unfamiliar with the DARPA Internet architecture and the
Internet gateway model. General background and discussion on the
Internet architecture and supporting protocol suite can be found in
the DDN Protocol Handbook [25] and ARPANET Information Brochure [26],
both available from the Network Information Center, SRI
International, Menlo Park, CA 94025. Readers familiar with these
concepts can proceed directly to Section 2.
1.1. The DARPA Internet Architecture
The DARPA Internet system consists of a number of gateways and
networks that collectively provide packet transport for hosts
subscribing to the DARPA Internet protocol architecture. These
protocols include the Internet Protocol (IP), Internet Control
Message Protocol (ICMP), Transmission Control Protocol (TCP) and
application protocols depending upon them. All protocols use IP
as the basic packet-transport mechanism. IP is a datagram, or
connectionless, service and includes provision for service
specification, fragmentation/reassembly and security information.
ICMP is considered an integral part of IP, although it is
NTAG [Page 2]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
architecturally layered upon it. ICMP provides error reporting,
flow control and first-hop gateway redirection. Reliable data
delivery is provided in the protocol suite by TCP, which provides
end-end retransmission, resequencing and connection control.
Connectionless service is provided by the User Datagram Protocol
(UDP).
The Internet community presently includes several thousand hosts
connected to over 400 networks with about 120 gateways. There are
now well over 2400 hosts registered in the ARPA domain alone and
an unknown number registered in other domains, with the total
increasing at about ten percent each month. Many of the hosts,
gateways and networks in the Internet community are administered
by civil organizations, including universities, research
laboratories and equipment manufacturers. Most of the remainder
are administered by the US DoD and considered part of the DDN
Internet, which presently consists of three sets of networks: the
experimental segment, or ARPANET, the unclassified segment, or
MILNET, and the classified segment, which does not yet have a
collective name.
The Internet model includes constituent networks, called local
networks to distinguish them from the Internet system as a whole,
which are required only to provide datagram (connectionless)
transport. This requires only best-effort delivery of individual
packets, or datagrams. Each datagram carries 32-bit source and
destination addresses, which are encoded in three formats
providing a two-part address, one of which is the local-network
number and the other the host number on that local net. According
to the Internet service specification, datagrams can be delivered
out of order, be lost or duplicated and/or contain errors. In
those networks providing connection-oriented service the extra
reliability provided by virtual circuits enhances the end-end
robustness of the system, but is not strictly necessary.
Local networks are connected together in the Internet model by
means of Internet gateways. These gateways provide datagram
transport only and normally seek to minimize the state information
necessary to sustain this service in the interest of routing
flexibility and robustness. In the conventional model the gateway
has a physical interface and address on each of the local nets
between which it provides forwarding services. The gateway also
participates in one or more distributed routing or reachability
algorithm such as the Gateway-Gateway Protocol (GGP) or Exterior
Gateway Protocol (EGP) in order to maintain its routing tables.
NTAG [Page 3]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
1.2. The Internet Gateway Model
An Internet gateway is a self-contained, stand-alone packet switch
that performs the following functions:
1. Interfaces to two or more packet-switching networks,
including encapsulation, address transformation and flow
control.
2. Conforms to specific DARPA Internet protocols specified in
this document, including the Internet Protocol (IP),
Internet Control Message Protocol (ICMP), Exterior Gateway
Protocol (EGP) and others as necessary.
3. Supports an interior gateway protocol (IGP) reachability or
routing algorithm in cases of multiple gateways operating
as a system. Supports the EGP reachability algorithm to
exchange routes between systems, in particular the DARPA
"core" system operated by BBN.
4. Receives and forwards Internet datagrams consistent with
good engineering practice in the management of resources,
congestion control and fairness. Recognizes various error
conditions and generates ICMP error and information
messages as required.
5. Provides system support facilities, including loading,
debugging, status reporting, exception reporting and
control.
In some configurations gateways may be connected to
packet-switching local nets that provide generic local-net
routing, error-control and resource-management functions. In
others gateways may be directly connected via serial lines, so
that these functions must be provided by the gateways themselves.
There are three typical scenarios that should be addressed by
gateway vendors:
1. National or regional network. Gateways of this class
should be capable of switching multiple continuous flows in
the 1.5-Mbps range at rates to several thousand packets per
second. They will be high-performance, possibly redundant,
multiple-processor devices, probably procured as a system
and operated remotely from a regional or national
monitoring center. The design of these gateways should
emphasize high aggregate throughput, throughput-sensitive
NTAG [Page 4]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
resource management and very high reliability. The typical
application would be an NSF backbone net or one of the
consortium or regional nets.
2. Campus network. Gateways of this class should be capable
of switching some burst flows at 10-Mbps (Ethernets, etc.),
together with some flows in the 64-Kbps range or lower, at
rates to perhaps several thousand packets per second. They
will be medium-performance devices, probably competitively
procured from different vendors for each campus and
operated from a campus computing center. The design of
these gateways should emphasize low average delay and good
burst performance, together with delay and type-of-service
sensitive resource management. Their chief function might
be to interconnect various LANs and campus computing
resources, including a high-speed interconnect to a
national or regional net. An important factor will be a
very flexible routing mechanism, since these gateways may
have to select among several backbone nets based on
cost/performance considerations.
3. Department network. Gateways of this class should be
capable of switching a small number of burst flows at
10-Mbps (Ethernets, etc.), together with a small number of
flows in the range 64-Kbps or lower, at rates of a few
hundred packets per second. They will be
medium-performance devices procured from a variety of
vendors and used for protocol-matching, LAN repeaters and
as general utility packet switches. They will probably be
locally maintained by the various users and not be used as
transit switches.
It is important to realize that Internet gateways normally operate
in an unattended mode, but that equipment and software faults can
affect the entire Internet. While some of the above scenarios
involve positive control of some gateways from a monitoring
center, usually via a path involving other networks and Internet
gateways, others may involve much less formal control procedures.
Thus the gateways must be highly robust and be expected to
operate, possibly in a degraded state, under conditions of extreme
congestion or failure of network resources.
NTAG [Page 5]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
2. Protocols Required
The Internet architecture uses datagram gateways to interconnect
networks and subnetworks. These gateways function as intermediate
systems (IS) with respect to the ISO connectionless network model and
incorporate defined packet formats, routing algorithms and related
procedures. In the following it is assumed the protocol
implementation supports the full protocol, including all required
options, with exceptions only as noted.
2.1. Internet Protocol (IP)
This is the basic datagram protocol used in the Internet system.
It is described in RFC-791 [1] and also MIL-STD-1777 [5], both of
which are intended to describe the same standard, but in quite
different words.
With respect to current gateway requirements the following can be
ignored, although they may be required in future: Type of Service
field, Security option, Stream ID option and Timestamp option.
However, if recognized, the interpretation of these quantities
must conform to the standard specification.
Note that the Internet gateway model does not require that the
gateway reassemble IP datagrams with destination address other
than the gateway itself. However, in the case of those protocols
in which the gateway directly participates as a peer, including
routing and monitor/control protocols, the gateway may have to
reassemble datagrams addressed to it. This consideration is most
pertinent to EGP.
Note that, of the five classes of IP addresses. Class-A through
Class-E, Class-D and Class-E addresses are reserved for
experimental use. A gateway which is not participating in these
experiments should ignore all packets with a Class-D or Class-E
destination IP address. No ICMP Destination Unreachable or ICMP
Redirect messages should result from receiving such packets.
2.2. Internet Control Message Protocol (ICMP)
This is an auxiliary protocol used to convey advice and error
messages and is described in RFC-792 [2].
The distinction between subnets of a subnetted network, which
depends on an arbitrary mask as described in RFC-950 [21], is in
general not visible outside that network. This distinction is
important in the case of certain ICMP messages, including the ICMP
NTAG [Page 6]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
Destination Unreachable and ICMP Redirect messages. The ICMP
Destination Unreachable message is sent by a gateway in response
to a datagram which cannot be forwarded because the destination is
unreachable or down. A choice of several types of these messages
is available, including one designating the destination network
and another the destination host. However, the span of addresses
implied by the former is ill-defined unless the subnet mask is
known to the sender, which is in general not the case. It is
recommended that use of the ICMP Destination Network Unreachable
messages be avoided. Instead, an ICMP Destination Host
Unreachable message should be sent for each distinct unreachable
IP address.
The ICMP Redirect message is sent by a gateway to a host in order
to change the address used by the host for a designated host or
net. A choice of four types of messages is available, depending
on whether it applies to a particular host, network or service.
As in the previous case, these distinctions may depend upon the
subnet mask. As in the above case, it is recommended that the use
of ICMP messages implying a span of addresses (e.g. net
unreachable, net redirect) be avoided in favor of those implying
specific addresses (e.g. host unreachable, host redirect).
The ICMP Source Quench message has been the subject of much
controversy. It is not considered realistic at this time to
specify in detail the conditions under which this message is to be
generated or interpreted by a host or gateway.
New host and gateway implementations are expected to support the
ICMP Address Mask messages described in RFC-950. It is highly
desirable, although not required, to provide correct data for ICMP
Timestamp messages, which have been found useful in network
debugging and maintenance.
2.3. Exterior Gateway Protocol (EGP)
This is the basic protocol used to exchange information between
gateway systems of the Internet and is described in RFC-904 [11].
However, EGP as presently specified is an asymmetric protocol with
only the "non-core" procedures defined in RFC-904. There are at
present no "core" procedures specified, which would be necessary
for a stand-alone Internet. RFC-975 [27] suggests certain
modifications leading to a symmetric model; however, this is not
an official specification.
In principle, a stand-alone Internet can be built with non-core
EGP gateways using the EGP distance field to convey some metric
NTAG [Page 7]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
such as hop count. However, the use of EGP in this way as a
routing algorithm is discouraged, since typical implementations
adapt very slowly to changing topology and have no loop-protection
features.
The EGP model requires each gateway belong to an autonomous system
of gateways. If a routing algorithm is operated in one or more
gateways of an autonomous system, its data base must be coupled to
the EGP implementation in such a way that, when a net is declared
down by the routing algorithm, the net is also declared down via
EGP to other autonomous systems. This requirement is designed to
minimize spurious traffic to "black holes" and insure fair
utilization of the resources on other systems.
There are no peer-discovery or authentication procedures defined
in the present EGP specification and no defined interpretation of
the distance fields in the update messages, although such
procedures may be defined in future (see RFC-975). There is
currently no guidance on the selection of polling parameters and
no specific recovery procedures in case of certain error messages
(e.g. "administratively prohibited"). It is recommended that EGP
implementations include provisions to initialize these parameters
as part of the monitoring and control procedures and that changing
these procedures not require recompilation or rebooting the
gateway.
2.4. Address Resolution Protocol (ARP)
This is an auxiliary protocol used to manage the
address-translation function between hardware addresses in a
local-net environment and Internet addresses and described in
RFC-826 [4]. However, there are a number of unresolved issues
having to do with subnets and response to addresses not in the
same subnet or net. These issues, which are intertwined with ICMP
and various gateway models, are discussed in Appendix A.
3. Subnets
The concept of subnets was introduced in order to allow arbitrary
complexity of interconnected LAN structures within an organization,
while insulating the Internet system against explosive growth in
network numbers and routing complexity. The subnet architecture,
described in RFC-950 [21], is intended to specify a standard approach
that does not require reconfiguration for host implementations,
regardless of subnetting scheme. The document also specifies a new
NTAG [Page 8]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
ICMP Address Mask message, which a gateway can use to specify certain
details of the subnetting scheme to hosts and is required in new host
and gateway implementations.
The current subnet specification RFC-950 does not describe the
specific procedures to be used by the gateway, except by implication.
It is recommended that a (sub)net address and address mask be
provided for each network interface and that these values be
established as part of the gateway configuration procedure. It is
not usually necessary to change these values during operation of any
particular gateway; however, it should be possible to add new
gateways and/or (sub)nets and make other configuration changes to a
gateway without taking the entire network down.
4. Local Network Interface
The packet format used for transmission of datagrams on the various
subnetworks is described in a number of documents summarized below.
4.1. Public data networks via X.25
The formats specified for public data networks via X.25 access are
described in RFC-877 [8]. Datagrams are transmitted over standard
level-3 virtual circuits as complete packet sequences. Virtual
circuits are usually established dynamically as required and time
out after a period of no traffic. Retransmission, resequencing
and flow control are performed by the network for each virtual
circuit and by the LAPB link-level protocol. Multiple parallel
virtual circuits are often used in order to improve the
utilization of the subscriber access line, which can result in
random resequencing. The correspondence between Internet and
X.121 addresses is usually established by table-lookup. It is
expected that this will be replaced by some sort of directory
procedure in future.
4.2. ARPANET via 1822 Local Host, Distant Host or HDLC Distant Host
The formats specified for ARPANET networks via 1822 access are
described in BBN Report 1822 [3], which includes the procedures
for several subscriber access methods. The Local Host (LH) and
Very Distant Host (VDH) methods are not recommended for new
implementations. The Distant Host (DH) method is used when the
host and IMP are separated by not more than about 2000 feet of
cable, while the HDLC Distant Host is used for greater distances
where a modem is required. Retransmission, resequencing and flow
control are performed by the network and by the HDLC link-level
protocol, when used. While the ARPANET 1822 protocols are widely
NTAG [Page 9]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
used at present, they are expected to be eventually overtaken by
the DDN Standard X.25 protocol (see below) and the new PSN
End-to-End Protocol described in RFC-979 [29].
While the cited report gives details of the various ARPANET
subscriber access methods, it specifies neither the IP packet
encapsulation format nor address mappings. While these are
generally straightforward and easy to implement, the details
involve considerations beyond the scope of readily accessable
documentation. Potential vendors are encouraged to contact one of
the individuals listed at the beginning of this document for
further information.
Gateways connected to ARPANET/MILNET IMPs must incorporate
features to avoid host-port blocking (RFNM counting) and to detect
and report (as ICMP Unreachable messages) the failure of
destination hosts or gateways.
4.3. ARPANET via DDN Standard X.25
The formats specified for ARPANET networks via X.25 are described
in the Defense Data Network X.25 Host Interface Specification [6].
This document describes two sets of procedures, the DDN Basic X.25
and the DDN Standard X.25, but only the latter is suitable for use
in the Internet system. The DDN Standard X.25 procedures are
similar to the public data subnetwork X.25 procedures, except in
the address mappings. Retransmission, resequencing and flow
control are performed by the network and by the LAPB link-level
protocol.
4.4. Ethernets
The formats specified for Ethernet networks are described in
RFC-894 [10]. Datagrams are encapsulated as Ethernet packets with
48-bit source and destination address fields and a 16-bit type
field. Address translation between Ethernet addresses and Internet
addresses is managed by the Address Resolution Protocol, which is
required in all Ethernet implementations. There is no explicit
retransmission, resequencing or flow control. although most
hardware interfaces will retransmit automatically in case of
collisions on the cable.
It is expected that amendments will be made to this specification
as the result of IEEE 802.3 evolution. See RFC-948 [20] for
further discussion and recommendations in this area. Note also
that the IP broadcast address, which has primary application to
Ethernets and similar technologies that support an inherent
NTAG [Page 10]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
broadcast function, has an all-ones value in the host field of the
IP address. Some early implementations chose the all-zeros value
for this purpose, which is presently not in conformance with the
definitive specification RFC-950 [21].
See Appendix A for further considerations.
4.5. Serial-Line Protocols
Gateways may be used as packet switches in order to build
networks. In some configurations gateways may be interconnected
with each other and some hosts by means of serial asynchronous or
synchronous lines, with or without modems. When justified by the
expected error rate and other factors, a link-level protocol may
be required on the serial line. While there is no requirement that
a particular standard protocol be used for this, it is recommended
that standard hardware and protocols be used, unless a convincing
reason to the contrary exists. In order to support the greatest
variety of configurations, it is recommended that some variation
on full X.25 (i.e. "symmetric mode") be used where resources
permit; however, X.25 LAPB would also be acceptable where
requirements permit. In the case of asynchronous lines no clear
choice is apparent.
5. Interoperability
In order to assure interoperability between gateways procured from
different vendors, it is necessary to specify points of protocol
demarcation. With respect to interoperability of the routing
function, this is specified as EGP. All gateway systems must include
one or more gateways which support EGP with a core gateway, as
described in RFC-904 [11]. It is desirable that these gateways be
able to operate in a mode that does not require a core gateway or
system. Additional discussion on these issues can be found in
RFC-975 [27].
With respect to the interoperability at the network layer and below,
two points of protocol demarcation are specified, one for Ethernets
and the other for serial lines. In the case of Ethernets the
protocols are as specified in Section 4.4 and Appendix A of this
document. For serial lines between gateways of different vendors,
the protocols are specified in Section 4.5 of this document.
Exceptions to these requirements may be appropriate in some cases.
NTAG [Page 11]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
6. Subnetwork Architecture
It is recognized that gateways may also function as general packet
switches to build networks of modest size. This requires additional
functionality in order to manage network routing, control and
configuration. While it is beyond the scope of this document to
specify the details of the mechanisms used in any particular, perhaps
proprietary, architecture, there are a number of basic requirements
which must be provided by any acceptable architecture.
6.1. Reachability Procedures
The architecture must provide a robust mechanism to establish the
operational status of each link and node in the network, including
the gateways, the links connecting them and, where appropriate,
the hosts as well. Ordinarily, this requires at least a
link-level reachability protocol involving a periodic exchange of
hello messages across each link. This function might be intrinsic
to the link-level protocols used (e.g. LAPB, DDCMP). However, it
is in general ill-advised to assume a host or gateway is operating
correctly if its link-level reachability protocol is operating
correctly. Additional confirmation is required in the form of an
operating routing algorithm or peer-level reachability protocol,
such as used in EGP.
Failure and restoration of a link and/or gateway are considered
network events and must be reported to the control center. It is
desirable, although not required, that reporting paths not require
correct functioning of the routing algorithm itself.
6.2. Routing Algorithm
It has been the repeated experience of the Internet community
participants that the routing mechanism, whether static or
dynamic, is the single most important engineering issue in network
design. In all but trivial network topologies it is necessary
that some degree of routing dynamics is vital to successful
operation, whether it be affected by manual or automatic means or
some combination of both. In particular, if routing changes are
made manually, the changes must be possible without taking down
the gateways for reconfiguration and, preferably, be possible from
a remote site such as a control center.
It is not likely that all nets can be maintained from a
full-service control center, so that automatic-fallback or
rerouting features may be required. This must be considered the
normal case, so that systems of gateways operating as the only
NTAG [Page 12]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
packet switches in a network would normally be expected to have a
routing algorithm with the capability of reacting to link and
other gateway failures and changing the routing automatically.
Following is a list of features considered necessary:
1. The algorithm must sense the failure or restoration of a
link or other gateway and switch to appropriate paths
within an interval less than the typical TCP user timeout
(one minute is a safe assumption).
2. The algorithm must never form routing loops between
neighbor gateways and must contain provisions to avoid and
suppress routing loops that may form between non-neighbor
gateways. In no case should a loop persist for longer than
an interval greater than the typical TCP user timeout.
3. The control traffic necessary to operate the routing
algorithm must not significantly degrade or disrupt normal
network operation. Changes in state which might momentarily
disrupt normal operation in a local area must not cause
disruption in remote areas of the network.
4. As the size of the network increases, the demand on
resources must be controlled in an efficient way. Table
lookups should be hashed, for example, and data-base
updates handled piecemeal, with only the changes broadcast
over a wide area. Reachability and delay metrics, if used,
must not depend on direct connectivity to all other
gateways or the use of network-specific broadcast
mechanisms. Polling procedures (e.g. for consistency
checking) should be used only sparingly and in no case
introduce an overhead exceeding a constant independent of
network topology times the longest non-looping path.
5. The use of a default gateway as a means to reduce the size
of the routing data base is strongly discouraged in view of
the many problems with multiple paths, loops and
mis-configuration vulnerabilities. If used at all, it
should be limited to a discovery function, with operational
routes cached from external or internal data bases via
either the routing algorithm or EGP.
6. This document places no restriction on the type of routing
algorithm, such as node-based, link-based or any other
algorithm, or metric, such as delay or hop-count. However,
the size of the routing data base must not be allowed to
exceed a constant independent of network topology times the
NTAG [Page 13]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
number of nodes times the mean connectivity (average number
of incident links). An advanced design would not require
that the entire routing data base be kept in any particular
gateway, so that discovery and caching techniques would be
necessary.
7. Operation and Maintenance
Gateways and packets switches are often operated as a system by some
organization who agrees to operate and maintain the gateways, as well
as to resolve link problems with the respective common carriers. It
is important to note that the network control site may not be
physically attached to the network being monitored. In general, the
following requirements apply:
1. Each gateway must operate as a stand-alone device for the
purposes of local hardware maintenance. Means must be
available to run diagnostic programs at the gateway site using
only on-site tools, which might be only a diskette or tape and
local terminal. It is desirable, although not required, to
run diagnostics via the network and to automatically reboot
and dump the gateway via the net in case of fault. In
general, this requires special hardware.
The use of full-blown transport services such as TCP is in
general ill-advised if required just to reboot and dump the
gateway. Consideration should be given simple
retransmission-overlay protocols based on UDP or specific
monitoring protocols such as HMP described in RFC-869 [7].
2. It must be possible to reboot and dump the gateway manually
from the control site. Every gateway must include a watchdog
timer that either initiates a reboot or signals a remote
control site if not reset periodically by the software. It is
desirable that the data involved reside at the control site
and be transmitted via the net; however, the use of local
devices at the gateway site is acceptable. Nevertheless, the
operation of initiating reboot or dump must be possible via
the net, assuming a path is available and the connecting links
are operating.
3. A mechanism must be provided to accumulate traffic statistics
including, but not limited to, packet tallies, error-message
tallies and so forth. The preferred method of retrieving
these data is by explicit, periodic request from the control
site using a standard datagram protocol based on UDP or HMP.
NTAG [Page 14]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
The use of full-blown transport services such as TCP is in
general ill-advised if required just to collect statistics
from the gateway. Consideration should be given simple
retransmission-overlay protocols based on UDP or HMP.
4. Exception reports ("traps") occuring as the result of hardware
or software malfunctions should be transmitted immediately
(batched to reduce packet overheads when possible) to the
control site using a standard datagram protocol based on UDP
or HMP.
5. A mechanism must be provided to display link and node status
on a continuous basis at the control site. While it is
desirable that a complete map of all links and nodes be
available, it is acceptable that only those components in use
by the routing algorithm be displayed. This information is
usually available locally at the control site, assuming that
site is a participant in the routing algorithm.
The above functions require in general the participation of a control
site or agent. The preferred way to provide this is as a user
program suitable for operation in a standard software environment
such as Unix. The program would use standard IP protocols such as
TCP, UDP, and HMP to control and monitor the gateways. The use of
specialized host hardware and software requiring significant
additional investment is strongly discouraged; nevertheless, some
vendors may elect to provide the control agent as an integrated part
of the network in which the gateways are a part. If this is the
case, it is required that a means be available to operate the control
agent from a remote site using Internet protocols and paths and with
equivalent functionality with respect to a local agent terminal.
Remote control of a gateway via Internet paths can involve either a
direct approach, in which the gateway supports TCP and/or UDP
directly, or an indirect approach, in which the control agent
supports these protocols and controls the gateway itself using
proprietary protocols. The former approach is preferred, although
either approach is acceptable.
NTAG [Page 15]
RFC 985 May 1986
Requirements for Internet Gateways -- DRAFT
8. References and Bibliography
[1] Defense Advanced Research Projects Agency, "Internet Protocol",
DARPA Network Working Group Report RFC-791, USC Information
Sciences Institute, September 1981.
[2] Defense Advanced Research Projects Agency, "Internet Control
Message Protocol", DARPA Network Working Group Report RFC-792,
USC Information Sciences Institute, September 1981.
[