rfc928.txt

RFC 相关的技术文档

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 [e-mail].).

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
   interconnection" in the ISO literature: Operating systems' built-in
   assumptions about known devices--whether terminals, terminal
   controllers, or RJE stations--tend to get in the way of the sort of
   process-process and eventually procedure-procedure communications
   that serve as the basis for applications more interesting than simple
   remote login.  To those unfamiliar with the outboard processing
   approach, the premise that the way to attach is via an explicit
   protocol may be difficult to accept, but to those who have done it,
   it makes almost perfect sense.

   To those, by the way, who have worked in intercomputer networking
   from the perspective of inboard (Host-side) implementations of
   protocol suites, the outboard processing idea often seems to lead to
   less than optimal results, especially as to maximizing throughput.
   And it is difficult to argue that if a given Host were well and truly


Padlipsky                                                       [Page 2]



RFC 928                                                    December 1984
Introduction to H-FP


   fine-tuned to "do networking" the insertion of an extra processor
   could somehow lead to better networking.  However, for Hosts where
   conservation of CPU cycles is an issue, or even where memory is
   scarce (i.e., where it's desirable to conserve the resources being
   shared), outboarding is clearly the way to go.  For that matter,
   viewing outboard processing aright (as a form of distributed
   processing) it can be argued that even for extremely powerful
   "intelligent work stations"/"personal computers" which have the
   resources to spare it still makes sense to outboard in order not to
   have to do new implementations of entire protocol suites for each new
   such system--always assuming, of course, that the Host-Front End
   protocol in play is noticeably less complex than the offloaded
   protocols.

   None of this is meant to imply that outboard processing is the ONLY
   way to do intercomputer networking, of course.  It is, however, meant
   to suggest that outboard processing can be advantageous in a number
   of contexts.  Indeed, given the joint advents of microprocessors and
   Local Area Networks, a generic bus interface unit which also plays
   the role of a NFE (that is, is an Outboard Processing Environment)
   even allows for the original intent of "offloading to the IMP" to be
   realized, so that a free-standing, possibly fairly expensive NFE need
   not be interposed between Host and net.  Note, by the way, that
   nothing in the OPE approach requires that ALL Hosts employ OPEs. That
   is, the only protocols "seen" beyond the Comm Subnet Processor are
   the common intercomputer networking protocols (e.g., all DDN IMPs see
   and read IP datagrams). H-FP is strictly a matter between a Host and
   its OPE.

   It is also important to be aware that, given the advent of several
   different suites of protocols in the networking world, it might well
   be the case that the only reasonable way to achieve
   "interoperability" might well be to use a suitable H-FP (such as the
   one to be presented in the companion RFC) and an Outboard Processing
   Environment which is capable of parallel invocation of protcol suites
   (with the choice of suite for a given connection being dependent, of
   course, on the native suite of the desired target Host and/or
   application).

   The unquestionable advantages, then, of the approach, based on ten or
   more years of experience and analysis, would seem to be as
   follows--always recalling the assumption that the work to implement
   and execute the H-FP in play is small compared to the full protocol
   suite in question:  As noted, common implementation of a protocol
   suite has the automatic advantage of mutual consistency; further,
   particularly in the DOD context, it's far easier to procure common



Padlipsky                                                       [Page 3]



RFC 928                                                    December 1984
Introduction to H-FP


   implementations of standard protocols than to procure different ones
   on a per-Host type basis.  Also as noted, if the resources to be
   shared are viewed as being the participating Hosts'

   CPU cycles and memories, these resources are conserved by doing  as
   much as possible of the networking protocols in an OPE rather than in
   the mainframe.  Another, less evident advantage is that having an OPE
   effectively insulates a Host against changes in the
   outboarded/offloaded protocols--or even changes of the protocols,
   should the nascent international protocol standards ever mature
   sufficiently to supplant the in-place DOD standards.  (That is, given
   an abstract enough interface--in the spirit of the Principle of
   Layering--a Host could, for example, go from doing TCP as its
   "Host-Host" protocol to, say, ECMA Class 4 as its "Transport"
   protocol without taking any particular cognizance of the change,
   however unattractive such a change would be to advocates of the
   APRANET Reference Model such as the author. See [3] for more on the
   implied "Reference Model" issues.) Finally, although a few rather
   specialized points could also be adduced, it should be noted that for
   network security architectures which are predicated on the ability to
   control all means of egress from and ingress to "the net", uniform
   use of OPEs is clearly desirable.

   If we can stipulate that an OPE is/can be a good thing, then the
   remaining problem is just what the protocol interpreted by a Host and
   its OPE ought to be, once it's observed that a standard protocol is
   desirable in order to allow for as much commonality as possible among
   Host-side interpreters of the protocol.  That is, we envision the
   evolution of paradigmatic H-FP PIs which can more or less
   straightforwardly be integrated with  various operating systems, on
   the one hand, and the ability simply to transplant an H-FP PI from
   one instance of a given operating system to other instances of the
   same system, much as is currently being attempted in the DODIIS NFE
   program.  Again, the major motivation in the DOD context is the
   minimizing of procurement problems.

Technical Context

   As noted, some half-a-dozen Host-Front End protocols have been seen
   by the author.  Indeed, in December of 1982, a meeting was convened
   to allow the developers of those H-FPs to compare their experiences,
   with an eye to coming up with a proposal for a DOD standard H-FP;
   this paper is a direct result of that meeting.  In the current
   section, we present the consensus of the meeting as to the broad
   outline of the protocol; in the accompanying document, the current
   version of the proposed protocol will be presented, as detailed by
   the author and Richard Mandell and Joel Lilienkamp (both of SDC).


Padlipsky                                                       [Page 4]



RFC 928                                                    December 1984
Introduction to H-FP


   Note, by the way, that in some sense we should probably have changed
   the name from H-FP to H-OPEP (or something), but the habit of saying
   "H-FP" seems too deeply engrained, despite the fact that it does seem
   worthwhile to stop saying "NFE" and start saying "OPE."  (Besides,
   H-OPEP looks rather silly.)

   A final preliminary:  all the designers and implementors of H-FPs
   present at the December meeting concurred that the true test of any
   protocol is how well it implements.  Therefore, until several
   implementations of the "new" protocol have been performed and
   assessed, it must be understood that the proposed protocol is
   precisely that:  a proposal, not a standard.

   Not too surprisingly, the first point on which consensus was reached
   is that there are three separable aspects (or "layers") to an H-FP:
   At bottom, there must be some physical means for conveying bits from
   Host to OPE and from OPE to Host.  As it has always been a premise of
   outboard processing that the Host's convenience is paramount, just
   what this physical layer is can vary:  typically, a bit-serial
   interface is customary, but parallel/DMA interfaces, if available for
   the Host and interfaceable to a given OPE, are fair game.  (So would
   teleporting the bits be, for that matter.)

   In the middle, there must be a layer to manage the multiplexing of
   network "connections" and the control of the flow between Host and
   OPE.  If we agree to call the lowest layer the Link and the middle
   layer the Channel, one thing which must be noted is that between the
   two of them, the Link and Channel layers must be responsible for
   reliably conveying the bits between Host and OPE. After all, an OPE'd
   Host should not be "weaker" than one with an inboard implementation
   of a robust Host-Host protocol such as TCP.  It should be noted that
   any Host which "comes with" a suitable implementation of the X.25
   interface protocol (where the definition of "suitable" is rather too
   complex to deal with here) could, given an OPE conditioned to accept
   it, quite cheerfully satisfy the requirements of the lower two
   layers. This is not to say that X.25 "is" the mechanization of H-FP's
   Link and Channel layers, however; merely that it could be used.  The
   protocol spec itself will detail an alternative, less cumbersome
   channel layer for Hosts which don't have or want X.25.

   The top layer of H-FP is the most important:  we refer to it as the
   Command layer.  Here is where the peer H-FP modules in a given Host
   and OPE communicate with each other. Indeed, the segregation of JUST
   multiplexing and flow control (plus reliability) into the Channel
   Layer is done--in addition to making it easier for Hosts that possess
   preexisting software/hardware which could be turned to the
   purpose--so as to clarify "what the H-FP is":  it's the commands and


Padlipsky                                                       [Page 5]



RFC 928                                                    December 1984
Introduction to H-FP


   responses of the Command layer wherewith the Host's processes are
   able to manipulate the outboard implementations of the members of a
   protocol suite. The use of the phrase "commands and responses" is
   rather significant, as it happens. For in the protocol to be proposed
   for DOD standardization, unlike all but one of its predecessors,
   binary encoded "headers" are not employed; rather, the H-FP commands
   are indeed ASCII strings, and the responses (following the practice
   of ARPANET FTP) ASCII-encoded numbers.