rfc985.txt

RFC 相关的技术文档

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 ([e-mail]), or NTAG
   committee chairman Dave Farber ([e-mail]).  The
   subcommittee members, present affiliations and Internet mailboxes are
   as follows:

      Hank Dardy, NRL                 [e-mail]
      Dave Farber, U Delaware         [e-mail]
      Dennis Jennings, JVNC         [e-mail]


NTAG                                                            [Page 1]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      Larry Landweber, U Wisconsin    [e-mail]
      Tony Lauck, DEC                 rhea!bergil![e-mail]
      Dave Mills (Chairman), Linkabit [e-mail]
      Dennis Perry, DARPA/IPTO        [e-mail]

   The subcommittee wishes to thank the following additional
   contributors and invited referees:

      Len Bosack, Stanford U/CISCO    [e-mail]
      Bob Braden, ISI                 [e-mail]
      Hans-Werner Braun, U Michigan   [e-mail]
      Noel Chiappa, MIT/Proteon       [e-mail]
      Doug Comer, Purdue U            [e-mail]
      Ira Fuchs, Princeton U          [e-mail]
      Ed Krol, U Illinois            [e-mail]
      Barry Leiner, RIACS             [e-mail]
      Mike Muuss, BRL                 [e-mail]
      Ron Natalie, BRL                [e-mail]
      Harvey Newman, CIT              [e-mail]
      Jon Postel, ISI                 [e-mail]
      Marshall Rose, NRTC             [e-mail]
      Jeff Schiller, MIT              [e-mail]
      Lixia Zhang, MIT                [e-mail]

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.