Introduction to proposed DoD standard H-FP
RFC 928

Document Type RFC - Unknown (December 1984; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf 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