Proposed protocol for connecting host computers to ARPA-like networks via front end processors
RFC 647
|
Document |
Type |
|
RFC - Unknown
(November 1974; No errata)
|
|
Authors |
|
|
|
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
A PROPOSED PROTOCOL FOR CONNECTING HOST COMPUTERS TO
ARPA-LIKE NETWORK VIA DIRECTLY-CONNECTED
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
(MIT-MULTICS).
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
INTRODUCTION
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
alternative.
FRONT-ENDING
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
given.
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