Proposed Host-Front End Protocol
RFC 929
|
Document |
Type |
|
RFC - Historic
(December 1984; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 929 (Historic)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group Joel Lilienkamp (SDC)
Request for Comments: 929 Richard Mandell (SDC)
Michael Padlipsky (Mitre Corp.)
December 1984
PROPOSED HOST-FRONT END PROTOCOL
Status Of This Memo
The reader should be aware of several things in regard to what the
present document is up to. First and foremost, IT IS A PROPOSAL FOR
A STANDARD, NOT A STANDARD ITSELF. Next, it assumes that the
separate document, RFC 928, which is an introduction to the present
document, has been read before it is. Next, it should be understood
that "final cut" over this version of the document has been exercised
by the author of RFC 928, not by the primary author of the present
document, so any readers bothered by style considerations should feel
free to blame the former, who's used to it, rather than the latter,
who may well be guiltless. (Editing at a distance finally become too
hard to manage, so if I'm typing it myself I'm going to fiddle with
it myself too, including, but not limited to, sticking my own section
on the Conceptual Model in before Joel's words start, rather than
leaving it in the Introduction. MAP)
Finally, it should be noted that this is not a finished document.
That is, the intent is eventually to supply appendices for all of the
protocol offloadings, describing their uses of protocol idiosyncratic
parameters and even their interpretations of the standard per-command
parameters, but in order to get what we've got into circulation we
haven't waited until all such appendices have been written up. (We
do have notes on how to handle FTP, e.g., and UDP will be pretty
straightforward, but getting them ready would have delayed things
into still another calendar year, which would have been very annoying
... not to say embarrassing.) For that matter, it's not even a
finished document with respect to what is here. Not only is it our
stated intention to revise the protocol based upon implementation
experience gained from volunteer test implementations, but it's also
the case that it hasn't proven feasible to iron out all known
wrinkles in what is being presented. For example, the response codes
almost certainly need clarification and expansion, and at least one
of us doesn't think mandatory initial parameters need control flags.
However, to try too hard for polish would be to stay in subcommittee
for the better part of forever, so what you see is what we've got,
but certainly isn't meant to be what you or we are stuck with.
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
Lilienkamp & Mandell & Padlipsky [Page 1]
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
Show full document text