Proposed protocol for connecting host computers to ARPA-like networks via front end processors
RFC 647

Document Type RFC - Unknown (November 1974; No errata)
Last updated 2013-03-02
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 647 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                    M. A. Padlipsky
Request for Comments: 647                                      MITRE-TIP
NIC: 31117                                                 November 1974

                          FRONT END PROCESSORS

                          by Michael Padlipsky

                with the advice and general agreement of

     Jon Postel and Jim White (SRI-ARC), Virginia Strazisar (MITRE)

                      and the general agreement of

   Tom Boynton (ISI), Frank Brignoli (NSRDC), John Day (CAC), Bob Fink
   (LBL), Carl Ellison (UTAH), Eric Harslem (RAND), Wayne Hataway
   (AMES-67), John McConnell (I4-TENEX), Ari Ollikainen (UCLA), Dave
   Retz (SCRL), Al Rosenfeld (CASE), Stan Taylor (BRL), Doug Wells

   All affiliations are shown only for identifying ARPANET involvement,
   and do not necessarily denote organizational approval of the
   positions taken here.

   No -- repeat NO -- expression of general agreement should be taken to
   apply to Appendix 2, which is exclusively a personal viewpoint.

Padlipsky                                                       [Page 1]
RFC 647                                                    November 1974


   As this proposal is written, in the fall of 1974, the ARPA network
   has achieved sufficient acceptance that a rather large number of
   organizations are currently planning either to attach their general
   purpose computer systems directly to the ARPANET or to interconnect
   their systems employing "ARPANET technology".  The authors have been
   in touch with efforts sponsored by the Air Force systems command, the
   Naval Ship Research and Development Center, the Defense
   Communications Agency ("PWIN" -- the Prototype World-Wide Military
   command and Control system Intercomputer Network), ARPA (The National
   Software Works), the AEC, and other government agencies.  A common
   characteristic of these networks and the sub-networks is the presence
   of a number of systems which have no counterparts on the current
   ARPANET; thus, hardware "special interfaces" (between the host and
   the network Interface Message Processor) and -- more important --
   Network Control Programs cannot simply be copied from working
   versions.  (Systems include CDO 6600's, XDS Sigma 9's, Univac 494's,
   1107's, 1108's, 1110's, and IBM 370's running operating systems with
   no current ARPANET counterparts.)  Because it is also widely accepted
   that the design and implementation of an NCP for a "new" system is a
   major undertaking, an immediate area of concern for networks which
   employs as much off-the-shelf hardware and software as is
   practicable.  This paper addresses two such approaches, one which
   apparently is popularly assumed as of now to be the way to go and
   another which the authors feel is superior to the more widely known


   In what might be thought of as the greater network community, the
   consensus is so broad that the front-ending is desirable that the
   topic needs almost no discussion here.  Basically, a small machine (a
   PDP-11 is widely held to be most suitable) is interposed between the
   IMP and the host in order to shield the host from the complexities of
   the NCP.  The advantages of this fundamental approach are apparent:
   It is more economic to develop a single NCP.  "Outward" (User Telnet)
   network access is also furnished by the front end acting as a mini-
   Host.  The potentiality exists for file manipulations on the mini-
   Host.  Two operating systems are in advanced stages of development on
   the ARPANET for PDP-11's which will clearly serve well as bases for
   network front ends; thus, the hardware and software are copiable.  So
   if we consider a model along the following lines

   Host *** Front End --- IMP --- Network

   everything to the right of the asterisks may almost be taken as

Padlipsky                                                       [Page 2]
RFC 647                                                    November 1974

   (Caveat: Note the "almost" well in last sentence neither ANTS nor ELF
   -- the two systems alluded to above -- is a completely finished
   product in the estimation of either their respective developers or of
   the knowledgeable ARPANET workers who have contributed to this
   report.  Both are capable of being brought to fruition, though, and
   in a reasonable amount of time.  We will assume ELF as the actual
   front-end system here for two reasons: apparent consensus, and
   current activity level of the development team.  However, we have no
   reason to believe that readers who prefer ANTS would encounter
   substantive difficulties in implementing our proposal on it.)

   (Explanatory notes: ANTS is an acronym for ARPA Network Terminal
Show full document text