Introduction to proposed DoD standard H-FP
RFC 928
|
Document |
Type |
|
RFC - Unknown
(December 1984; 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 928 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group M. A. Padlipsky
Request for Comments: 928 Mitre Corp.
December 1984
INTRODUCTION TO PROPOSED DOD STANDARD H-FP
Status Of This Memo
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
Important Prefatory Note
The broad outline of the Host-Front End Protocol introduced here and
described in RFC 929 is the result of the deliberations of a number
of experienced H-FP designers, who sat as a committee of the DoD
Protocol Standards Technical Panel under the author's chairmanship.
The particular protocol to be described is, however, the result of
the deliberations of a small, ad hoc group, who sat as a de facto
subcommittee of the H-FP committee, also under the author's
chairmanship. The protocol, then, follows the consensus of the full
group as to what the new H-FP should "look like," but has not
benefitted from painstaking study by a large number of experienced
H-FP designers and implementers. (It has been looked at before
release as an RFC by several of them, though.) Even if that were not
the case, it would still be the intent of the designers that the
protocol be subjected to multiple test implementations and probable
iteration before being agreed upon as any sort of "standard".
Therefore, the first order of business is to declare that THIS IS A
PROPOSAL, NOT A FINAL STANDARD, and the second order of business is
to request that any readers of these documents who are able to do
test implementations (a) do so and (b) coordinate their efforts with
the author (617-271-2978 or Padlipsky@USC-ISI.ARPA.).
Historical/Philosophical Context
Late in May of 1971, the author was presenting a status report on
whether the Multics ARPANET implementation would be ready by the
July 1 deadline declared by the sponsor earlier that month. Some
controversy developed over the fact that the Multics "NCP" (Network
Control Program--actually a blanket term covering the Host-Host and
Host-IMP protocol interpreters) did not queue requests for
connections. As the specification explicitly declared the topic to
be one of implementors' choice, the author attempted to avoid the
argument by asking the interrogator what he was up to these days.
The answer was, "Oh, I'm working on the High-Speed Modular IMP now"
(later the Pluribus IMP). And the proverbial coin dropped: The
author replied, "I've got a great idea. Now that we've got some
space to program in the IMP, why don't we separate out most of the
Padlipsky [Page 1]
RFC 928 December 1984
Introduction to H-FP
NCP and do it outboard: the only thing that really matters in the
Host is associating sockets with processes, and if we had common
implementations of all the bit-diddling stuff in the IMPs, we
wouldn't have disputes over the interpretation of the spec and we'd
also save a lot of Host CPU cycles!"
As far as the author knows, that incident was the beginning of what
came to be called "Network Front-Ends" and, more recently, "Outboard
Processing Environments." (The name change, by the way, was
motivated by a desire to prevent further confusion between NETWORK
Front Ends--always conceived of as distributed processing mechanisms
for the offloading of intercomputer networking protocols from
Hosts--and traditional communications front-ends, which have no
connotation of bearing protocol interpreters invokable by Host-side
programs.) At least, the idea was original to him and he later was a
principal designer and the primary author of the first Host-Front End
Protocol. So, on the one hand, the present document might be marred
for some readers by undertones of parental pride, but on the other
hand, if you like primary sources....
The evolution of the outboard processing idea has been dealt with
elsewhere [1]. For present purposes, it should suffice to observe
that some half-a-dozen implementors of "NFE's" of various sorts are
known to the author to have met with success. The topic of why use
an explicit protocol in the first place (as opposed to emulating a
device, or devices, already known to the Host/operating system)
deserves a word or two here, however. ([2] deals with it in more
general terms.) The crucial consideration is that in the general
case you wind up "not doing real networking" if you attach a Host to
a network by known device emulation, where real networking is taken
to mean what has been called "resource sharing" in the ARPANET
literature, and what appears to be dubbed "open system
Show full document text