RFC 929 (rfc929) - Page 2 of 56

Proposed Host-Front End Protocol

RFC 929                                                    December 1984
Proposed Host-Front End Protocol


Conceptual Model

   There are two fundamental motivations for doing outboard processing.
   One is to conserve the Hosts' resources (CPU cycles and memory) in a
   resource sharing intercomputer network, by offloading as much of the
   required networking software from the Hosts to Outboard Processing
   Environments (or "Network Front-Ends") as possible. The other is to
   facilitate procurement of implementations of the various
   intercomputer networking protocols for the several types of Host in
   play in a typical heterogeneous intercomputer network, by employing
   common implementations in the OPE.  A third motivation, of basing a
   network security approach on trusted mandatory OPEs, will not be
   dealt with here, but is at least worthy of mention.

   Neither motivation should be allowed to detract from the underlying,
   assumed desire to perform true intercomputer networking, however.
   Therefore, it is further assumed that OPEs will be attached to Hosts
   via a flexible attachment strategy, as described in [1]. That is, at
   the software level an explicit Host-Front End Protocol (H-FP) will be
   employed between Hosts and OPEs, rather than having OPEs emulate
   devices or device controllers already "known" to Host operating
   systems (in order to avoid introducing new code into the Host).

   For reasons discussed in the Introduction, an H-FP resolves into
   three layers.  The Link layer enables the exchange of bits between
   Host and OPE.  The Channel layer enables the bit streams to be
   demultiplexed and flow controlled  (both the Channel and Link layers
   may use preexisting per-Host mechanizations, it should be recalled).
   The Command (or "Service Access") layer is our primary concern at
   present. It serves as the distributed processing mechanism which
   allows processes on Hosts to manipulate protocol interpreters (PIs)
   in OPEs on their behalf; for convenience, it will be referred to as
   "the H-FP" here.  (It should be noted that the Link and Channel
   layers may be viewed as roughly equivalent to the inboard processing
   investment for a Host-comm subnet processor PI and device driver, so
   in practical terms the savings of resources achieved by outboard
   processing come from making the H-FP "smaller" than the inboard
   implementations of the protocols it allows to be offloaded.)

   The crucial property of the H-FP conceptually is that it stands as
   the interface between a (Host) process and a PI (which is actually
   outboard).  Usually, the model is that of a closed subroutine
   interface, although in some cases an interprocess communication
   mechanism model must be appealed to.  That is, the interactions
   between cooperating H-FP PIs in some sense mimic subroutine or IPC
   calls, from the perspective of Host processes calling upon their own
   H-FP PIs, which in turn are of course interfacing via just such


Lilienkamp & Mandell & Padlipsky