As per Relevance of the word indicate, we have this rfc below:
Network Working Group Joel Lilienkamp (SDC
Request for Comments: 929 Richard Mandell (SDC
Michael Padlipsky (Mitre Corp.)
December 1984
PROPOSED HOST-FRONT END
Status Of This
The reader should be aware of several things in regard to what
present document is up to. First and foremost, IT IS A PROPOSAL
A STANDARD, NOT A STANDARD ITSELF. Next, it assumes that
separate document, RFC 928, which is an introduction to the
document, has been read before it is. Next, it should be
that "final cut" over this version of the document has been
by the author of RFC 928, not by the primary author of the
document, so any readers bothered by style considerations should
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
hard to manage, so if I'm typing it myself I'm going to fiddle
it myself too, including, but not limited to, sticking my own
on the Conceptual Model in before Joel's words start, rather
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
protocol offloadings, describing their uses of protocol
parameters and even their interpretations of the standard per-
parameters, but in order to get what we've got into circulation
haven't waited until all such appendices have been written up. (
do have notes on how to handle FTP, e.g., and UDP will be
straightforward, but getting them ready would have delayed
into still another calendar year, which would have been very
... not to say embarrassing.) For that matter, it's not even
finished document with respect to what is here. Not only is it
stated intention to revise the protocol based upon
experience gained from volunteer test implementations, but it's
the case that it hasn't proven feasible to iron out all
wrinkles in what is being presented. For example, the response
almost certainly need clarification and expansion, and at least
of us doesn't think mandatory initial parameters need control flags
However, to try too hard for polish would be to stay in
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-
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
Conceptual
There are two fundamental motivations for doing outboard processing
One is to conserve the Hosts' resources (CPU cycles and memory) in
resource sharing intercomputer network, by offloading as much of
required networking software from the Hosts to Outboard
Environments (or "Network Front-Ends") as possible. The other is
facilitate procurement of implementations of the
intercomputer networking protocols for the several types of Host
play in a typical heterogeneous intercomputer network, by
common implementations in the OPE. A third motivation, of basing
network security approach on trusted mandatory OPEs, will not
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
via a flexible attachment strategy, as described in [1]. That is,
the software level an explicit Host-Front End Protocol (H-FP) will
employed between Hosts and OPEs, rather than having OPEs
devices or device controllers already "known" to Host
systems (in order to avoid introducing new code into the Host).
For reasons discussed in the Introduction, an H-FP resolves
three layers. The Link layer enables the exchange of bits
Host and OPE. The Channel layer enables the bit streams to
demultiplexed and flow controlled (both the Channel and Link
may use preexisting per-Host mechanizations, it should be recalled).
The Command (or "Service Access") layer is our primary concern
present. It serves as the distributed processing mechanism
allows processes on Hosts to manipulate protocol interpreters (PIs
in OPEs on their behalf; for convenience, it will be referred to
"the H-FP" here. (It should be noted that the Link and
layers may be viewed as roughly equivalent to the inboard
investment for a Host-comm subnet processor PI and device driver,
in practical terms the savings of resources achieved by
processing come from making the H-FP "smaller" than the
implementations of the protocols it allows to be offloaded.)
The crucial property of the H-FP conceptually is that it stands
the interface between a (Host) process and a PI (which is
outboard). Usually, the model is that of a closed
interface, although in some cases an interprocess
mechanism model must be appealed to. That is, the
between cooperating H-FP PIs in some sense mimic subroutine or
calls, from the perspective of Host processes calling upon their
H-FP PIs, which in turn are of course interfacing via just
Lilienkamp & Mandell & Padlipsky [Page 2]
RFC 929 December 1984
Proposed Host-Front End
mechanisms themselves. Another way of putting it is that "if
protocols were inboard," the processes invoking H-FP wouldn't
the difference. H-FP, then, may be viewed as a roundabout way
letting Host processes "get at" various PIs
Naturally, the mechanization of the desired concept cannot
particularly literal. After all, the Hosts and the OPEs
different processors, so we're not envisioning a passing through
parameters in an exact fashion. However, in broad terms the model
just that of a somewhat funny interface between a process and a PI
(This should not be construed as ruling out the occurrence of
which prompt the OPE to initiate an exchange of commands with
Host, though; see the Introduction for more on the topic
"Symmetric Begins.")
Interaction
The interaction between the Host and the OPE must be capable
providing a suitable interface between processes (or
interpreters) in the Host and the off-loaded protocol interpreters
the OPE. This interaction must not, however, burden the Host
heavily than would have resulted from supporting the
inboard, lest the advantage of using an OPE be overridden
Channel Level
As stated elsewhere, the Channel level protocol (implicitly
conjunction with the Link level) provides two major functions.
are demultiplexing the traffic from the Link level into distinct
streams, and providing flow control between the Host and the OPE on
per stream basis. These hold even if the Host-OPE attachment is DMA
The data streams between the Host and the OPE are bidirectional.
this document, the basic unit of data transferred by the
level is referred to as a "chunk". The primary motivation for
terminology is that the H-FP permits the Channel level to be one
several possible protocols, each with its own terminology.
example, a chunk on an X.25 Channel would be a packet, while a
on the DTI H-FP channel would be a message. While the Command
is, in a sense, "more efficient" when the chunk size is permitted
be large, the flexibility permitted in the choice of protocols at
Channel level precludes any assumptions about the chunk size
Each data stream is fully asynchronous. A Channel protocol user
send data at any time, once the channel has been properly opened
(The Command level's logic may render some actions meaningless
however.) The data transfer service provided by the Channel
Lilienkamp & Mandell & Padlipsky [Page 3]
RFC 929 December 1984
Proposed Host-Front End
is reliable; this entails delivery in the correct order,
duplication, and checked for bit errors. All retransmission,
checking, and duplicate detection is provided by this protocol in
way that is transparent to the user. (If the attachment is DMA
stream identification and chunk length must still be provided for.)
The flow control at the Channel level is provided to prevent the
and the Host from overloading each other's resources by
transmissions. In general, this flow control should not
affect the outboard protocol interpreters' operation. On the
had, this flow control has the same effect as explicit
events that provide flow control between the user and the
interpreter (e.g., the Allocate event of the interface
for TCP found in MIL-STD 1778). Hence, such events do not need to
communicated explicitly at the Command level. (If the attachment
DMA, flow control must still be provided for.)
Should Hosts require an OPE to be attached via a Link Level
furnishes physical demultiplexing (e.g., a group of RS232 ports),
attempt to avoid furnishing reliability and explicit flow control,
done at their peril; we have not chosen to assist such
enterprise, but neither have we precluded it. (It would
violate the spirit of the thing, however.)
Command Level
The approach chosen for this H-FP is to base the interaction on
small set of commands, separately applicable to a given Channel
channel. The commands are simple, but sufficiently flexible to
the off-loading of the interpreters of the large number of
at various levels in the hierarchy. This flexibility is
possible in part by the similar nature of the interfaces to
protocols, combined with the provision of "protocol
parameters". These parameters are defined for each offloaded
interpreter in the OPE. The use of such parameters does
complicate the basic design of the OPE, since it must be
for each off-loaded protocol anyway, and all that is required of
OPE for those parameters is to pass them to the off-loaded
interpreter. Hence, an interface tailored to a particular
can be created in a straightforward and cost-effective way
The command dialog is more or less asynchronous. Commands can
issued at any particular time (except when there is a
command, which will be discussed below), and there is no need
dummy traffic on a channel when no commands are issued
Associated with each command is a response. The purpose of
Lilienkamp & Mandell & Padlipsky [Page 4]
RFC 929 December 1984
Proposed Host-Front End
response is to indicate, at some level that depends in part on
particular protocol interpreter that is offloaded to the OPE,
the command was successfully executed, and if unsuccessful,
reason. Often, generating the response involves interaction with
protocol interpreter before a response can be generated
When a command is issued, the issuer must wait for a response
another command is issued. The nature of the communication
the Host and the OPE is thus a lock step command/response dialog
There are two major exceptions to this principle, however.
exception is the abrupt form of the End command, which can be
at any time to cancel any previously issued commands, and
that services are no longer desired. The other exception is
Signal command. Since a Signal is out-of-band and usually of
importance, forcing it to wait on a response would be undesirable
Hence, a Signal command can be issued while commands (other
Signal) are pending. However, a Signal command should not be
before a successful response to the Begin command has been received
Since it is possible for more than one command of different types
be pending at one time, a mechanism to distinguish responses
needed. Since there are never two commands of the same type pending
including the command name in the response is sufficient to make
distinction
A special case command is the Transmit command. Details of
Transmit command are provided in the next section. Essentially,
Transmit command is used to invoke the data transfer services of
off-loaded protocol (when issued by the Host) or to indicate
arrival of new data from the network (when issued by the OPE).
nature of specific protocol interfaces for these events varies
between protocols. Some may block until the data is accepted by
remote counterpart (or "peer") protocol interpreter, while others
not. Hence, there is a special parameter which indicates the
of the Transmit command interface. It can either require that
response should be generated immediately after determining
Transmit command is complete and formed properly, or can
that the response should not be generated until the
interface event is given by the remote protocol interpreter.
default action for all Transmit commands can be initialized using
Begin command and changed using the Condition command. Also,
default action can be temporarily overridden by specifying
parameter with the Transmit command. The net result of this
is to allow the Host to determine within reason just how lock-
transmissions are to be. (It is assumed that the usual case will
to transfer the burden of buffering to the OPE by taking
responses, provided that doing so "makes sense" with the
offloaded protocol in play.)
Lilienkamp & Mandell & Padlipsky [Page 5]
RFC 929 December 1984
Proposed Host-Front End
Some protocols provide a block-oriented data transfer service
than a stream-oriented one. With such a service, the data
with a transfer request is viewed as an integral unit. For
network transmission, the protocol may permit these units to
grouped or fragmented. However, the receiving end must deliver
data in the original, integral units. Protocols that conform to
model include some datagram protocols such as IP and UDP, and
some connection protocols such as NBS TP
To cater to these types of protocols, it is a convention
commands, their parameters, and any associated data be
between the Host and the OPE in a single chunk. Any data
with an H-FP command is viewed as an integral unit which is used
the corresponding service request given to the outboard
interpreter or delivered as a complete unit to the process in
Host. Operation of stream-oriented protocols such as TCP will not
adversely affected by this convention
To accommodate Channel protocols that do not provide for
large chunks, a mechanism at the Command level is required to
the linking of multiple chunks into a single command, in order
transfer the burden of buffering as much as possible from the Host
the OPE. The facility proposed here would consist of an
at the beginning of each chunk which would distinguish
commands, fragments of a command for which more fragments are yet
arrive, and the final fragment of a command. The details of
mechanism are discussed in the section on the syntax of commands
responses
It is a convention for this H-FP that any data associated with
command must start on a word boundary (as defined by the
system). Consequently, there is a need to provide padding within
commands. Such padding is used only to fill to the next
boundary, and has no semantic significance to the command
(i.e., two commands that are identical except for the amount
padding should behave identically). The details of this padding
discussed in the section on the syntax of commands and responses
Lilienkamp & Mandell & Padlipsky [Page 6]
RFC 929 December 1984
Proposed Host-Front End
Syntax
At the Command Level, communication between the Host and the
takes the form of commands and responses. A command is a request
some particular action, and the response indicates the success
failure of performing the requested action
All commands and responses are coded in ASCII characters. (
precludes OPEs from accepting EBCDIC from Hosts that use it in
mode, but that is not required.) These characters are sent in
way convenient for the Host, and the OPE is sufficiently flexible
interpret them. (i.e., OPEs are expected to accommodate
idiosyncracies in regard to such things as use of 7-bit ASCII in
9-bit field.) This approach offers several advantages
Adaptabilities in most Hosts: Most Hosts have the ability
generate and interpret ASCII character streams. Hence,
H-FP into a Host will not require difficult software
Script generation: Generation of test and operational
scripts will be simplified, since they will not need to
special characters
Terminal Operation: Using simple command streams simplifies
conversion of an OPE to a generic virtual terminal support machine
This is particularly useful during development and testing
Testing: Testing will not require special hardware to
commands and responses. A terminal or data line analyzer would
adequate
The specific format for the commands and responses will be
in the sections that follow. In those sections, the quote
is used to indicate strings. The symbols "<" and ">" (referred to
angle brackets) are used as meta-characters
Syntax of
As alluded to in the section discussing the interaction
between the Host and the OPE, a function is provided by which a
can be used to carry either a complete command or a fragment of
command. The mechanism chosen to provide this function entails
of the first character position in the chunk as a chunk
identifier. The character "C" in the first position indicates
chunk containing a single, complete command. "F" in the
position indicates a chunk which is the first part of a
command. "M" in the first position indicates the chunk is a
Lilienkamp & Mandell & Padlipsky [Page 7]
RFC 929 December 1984
Proposed Host-Front End
part (neither the first nor the last chunk) of a command. Finally
"L" indicates the chunk is the last chunk of a multi-chunk command
Hence, the following sequences of chunks (the letter corresponds
the chunk usage identifier in each chunk, and the angle
enclose a chunk) are legal
while the following are not legal
Tactics for handling multiple chunks with regard to OPE
limits are left to the ingenuity of OPE builders. The spirit is
take as much as you can, in order to relieve the Host of
necessity of buffering itself
A command always begins immediately following the
character, with possible intervening spaces. This implies a
can contain at most one complete command. The end of the
(not including the data) is signified by a newline (denoted as
in this document) that does not appear inside a quoted string (
below). The end of the data is designated by the end of the
chunk
Commands take the form of an ASCII string. The command identifier
the first word of the chunk. It consists of at least the first
letters of the command, in either upper or lower case (e.g.,
sequences "BE", "Be", "bE", and "be" all identify the Begin command).
Additional letters of the command name can be included if desired
aid readability of the command stream
Following the command identifier is a list of parameters.
parameters are also represented as ASCII strings, although
specific format will depend on the particular parameter. The data
be transmitted is not considered a control parameter, however,
need not be ASCII data
Parameters are separated by one or more spaces. Tabs, newlines,
other white space are not legal parameter separators
Parameter strings may be quoted, using the character <">.
Lilienkamp & Mandell & Padlipsky [Page 8]
RFC 929 December 1984
Proposed Host-Front End
characters between the <"> characters are a part of the parameter
including spaces and newlines. The character <"> that is part of
parameter is represented inside a quoted string as <"">.
The order in which the parameters appear within the command
significant to their interpretation by the Host and by the OPE
Optional parameters may be skipped by using the characters ",,"
indicate a NULL parameter. Such a NULL parameter takes its
value. Alternatively, each parameter has a MULTICS/UNIX
Control Argument/Flag associated with it that can be used to
the parameter, without placing NULL parameters for each
skipped. This flag consists of one or two ASCII characters,
either upper or lower case may be used. For example, if the
parameter of a command had a flag of "-p" and the user wished
first three parameters to be null, he could use
command -p
command -P
instead
command ,, ,, ,,
if it were more convenient for the Host to do so. Flagged
must still appear in the correct sequence within the command
however
There may be data associated with some of the commands. Any
data is placed into the chunk following all the parameters and
unquoted newline. Padding can be provided by placing spaces
the end of the final parameter string and the newline, so that
begins on a word boundary. The OPE will always pad to a host
boundary. Padding by hosts is optional
Syntax of
Responses are actually just a special form of a command. It
anticipated that all responses would fit into a single channel chunk
although the mechanisms described for multichunk commands
certainly be used in responses. The ASCII string used to
identify the response command is "RE" ("Re", "rE", and "re" are
permitted).
After the response command identifier is the original
Lilienkamp & Mandell & Padlipsky [Page 9]
RFC 929 December 1984
Proposed Host-Front End
identifier, so the response can be associated with the
command. Following this identifier is a three ASCII digit
code, a set of protocol idiosyncratic parameters, and a
message. The protocol idiosyncratic parameters are used to
interface information between the Host and the OPE, and may not
needed when off-loading some protocol interpreters. The
message is intended for human interpretation of the response codes
and is not required by the protocol. The three digits
identify the semantics of the response, at least within the
of a particular command and particular outboarded
interpreter
Responses are numerically grouped by the type of information
convey. The first digit identifies this group, and the last
digits further qualify the reply. The following list
this grouping
0XX Successful: The command was executed successfully.
response code may contain further information
1XX Conditional Success: The command was executed successfully
but not exactly according to the service and flow
suggestions. If those suggestions were particularly
to the requester, he may wish to issue an End command.
response code contains information on what suggestion
suggestions could not be followed
2XX Command Level Error: An error at the command level
occurred. This could include requesting services of
protocol not supported, or a problem in the way those
were requested. This level does not include problems with
syntax of the command or its parameters
3XX Syntax and Parameter Errors: An error in the syntax of
command or a problem with one of its parameters has occurred
A problem with a parameter may be other than syntactical,
as illegal address
4XX Off-loaded Protocol Interpreter Problems: Some problem
the particular off-loaded protocol has occurred
5XX Local OPE Internal Problems: Problems, such as
OPE resources, or problems with OPE to subnet interface
6XX Security Problem: Some problem with Host, network, or
security has occurred. The response code indicates
problem
Lilienkamp & Mandell & Padlipsky [Page 10]
RFC 929 December 1984
Proposed Host-Front End
7XX Reserved for Future
8XX Reserved for Future
9XX Protocol Idiosyncratic Errors: Some error occurred that
idiosyncratic to the particular off-loaded protocol
used. The response code indicates the error
Description of the
As stated above, communication between the Host and the OPE at
Command Level is accomplished using commands and responses.
may be issued by either the Host or the OPE, and are used
stimulate activity in the other entity. Some commands may only have
meaningful interpretation in one direction, however. A
indicates that the activity started by the command was completed,
a code indicates success or failure of the command, and perhaps
information related to the command as well
Associated with each command is a set of parameters. The order
which the parameters appear is significant to the correct
of the protocols. More information on the syntax of
parameters can be found in the syntax descriptions
The commands are
- Begin: initiate communication between a process in the Host
an off-loaded protocol interpreter in the OPE. (A Channel
stream/connection will typically have been opened as a prior step
All other commands, except No-op, apply to a stream on which
successful Begin has been done.)
- Transmit: transmit data between a process in the Host and
off-loaded protocol interpreter in the OPE
- Signal: cause an out-of-band signal to be sent by
off-loaded protocol interpreter to its peer, or indicate
arrival of such a signal from the remote side
- Condition: alter the off-loaded protocol interpreter'
operational characteristics
- Status: transfer status requests or information between
process in the Host and an off-loaded protocol interpreter in
OPE
Lilienkamp & Mandell & Padlipsky [Page 11]
RFC 929 December 1984
Proposed Host-Front End
- End: indicate that services from the off-loaded
interpreter are no longer required, or will no longer be provided
- No-op: performs no operation, but facilitates testing
These commands will be discussed in the following sections. Each
these sections includes a discussion of the purpose of the command,
description of each of the parameters used with the command, a
of responses for the command, an example of the command, and a set
notes for the implementor. (An appendix will eventually be
for each protocol offloading, showing the use of its
idiosyncratic parameters as well as of the general parameters on
per-command basis. Initially, only representative offloadings
be treated in appendices, with others to be added after the
gains acceptance.)
Purpose of the Begin
The purpose of a Begin command is to initiate
between the Host and the OPE on a particular stream or
(the channel is opened as a separate step, of course).
interpretation of the command is somewhat dependent
whether it was issued by the Host of the OPE
- If the command was issued by the Host, it means some
in the Host is requesting services of a protocol that
off-loaded to the OPE. The user request results in
establishment of a channel connection between the Host and
OPE, and a Begin command to the Command interpreter in the OPE
- If the command was issued by the OPE, it means some
interpreter in the OPE has data for some process in the
which is not currently known by the OPE. An example would
an incoming UDP datagram on a new port, or if no Begin for
had been issued at all by the Host. (An incoming
connection request could be handled by a response to the user'
Passive Open request, which had previously caused a
request from the Host; an incoming TCP connection request to
port on which no Listen had been issued would cause an
generated Begin, however.)
As indicated earlier, any particular Host is not required
support two-way Begins
Lilienkamp & Mandell & Padlipsky [Page 12]
RFC 929 December 1984
Proposed Host-Front End
Parameters of the Begin
The Begin command has several parameters associated with it
These parameters contain information needed by the
protocol to provide an adequate level of network service.
information includes protocol, source and
addresses, and also type of service and flow control advice
These parameters are discussed in detail below
The protocol parameter identifies that off-loaded protocol
the OPE to which Begin is directed, or which issued the
to the Host. For example, if the user wished to utilize
services, and the TCP software was off-loaded into the OPE
then the Protocol parameter for the Begin command would be TCP
There are two categories of protocol parameters -- generic
specific. A generic parameter identifies a type of
service required, but does not identify the actual protocol
Use of generic protocols allows a Host process to
network services without specific knowledge of what protocol
being used; this could be appropriate for use in
where no specific aspect(s) of a specific protocol is/
required. For example, the user may select a
Host-to-Host connection protocol, and (at some point in
future) may actually receive services from either TCP or
NBS Transport Protocol, depending on the network (or even
foreign Host) in question. A specific protocol
identifies some particular protocol, e.g., TCP, whose use
required for the given channel
The valid entries for the protocol field include
Generic Specific
GIP IP Datagram Internetwork
HHP TCP Connection Transport/Host-Host
GDP UDP Datagram Transport/Host-Host
VTP TEL Virtual Terminal (Telnet)
GFP FTP File Transfer
MAIL SMTP Mail Transfer
PROX PROX Proximate Net Interface
(Note that the final line is meant to allow for a process in
OPE'd Host's getting at the PI of the Network
Protocol for whatever the proximate network is. Of course,
Lilienkamp & Mandell & Padlipsky [Page 13]
RFC 929 December 1984
Proposed Host-Front End
doing only makes sense in specialized contexts. We conceive
the desirability of "pumping bits at a peripheral" on a LAN
though, and don't want to preclude it, even if it would
impossible on many LAN's to deal with the problem
distinguishing traffic coming back on the LAN in this "raw
mode from normal, IP traffic. Indeed, in some contexts it
likely that administrative considerations would
avoidance of IP even if technical considerations allowed it
but it's still the case that "the protocol" should provide
hook for going directly to the L I protocol in play.)
There is no default value for this parameter. If it is
present, the Begin command is in error. The control flag
this parameter is -pr
Active/
The Active/Passive parameter indicates whether the issuer
the Begin command desires to be the Active or Passive user
the protocol. This parameter is particularly relevant
connection-oriented protocols such as TCP, where the user
actively pursue connection establishment, or else may
wait for the remote entity to actively establish
connection; it also allows some process to establish itself
the Host "fielder" of incoming traffic for a
protocol such as IP
Active is requested using the single character "A". Passive
indicated using the character "P". The default value of
parameter is "A". Also, when the OPE issues the Begin command
the value must be "A". The control flag for this parameter
-ap
Foreign Address Primary
The addressing structure supported by H-FP is two level.
address has two components, the primary and the secondary.
exact interpretation of these two components is
specific, but some generalities do apply. The
component of the address identifies where the protocol is
deliver the information. The secondary component
which recipient at that location is to receive the information
For example, the TCP primary address component is the Host'
Internet Address, while the secondary address component is
TCP port. Similarly, IP's primary address component is
Host's Internet Address, and the secondary address component
the IP ULP field. Some protocols provide only a single
Lilienkamp & Mandell & Padlipsky [Page 14]
RFC 929 December 1984
Proposed Host-Front End
of addressing, or the secondary level can be deduced from
other information (e.g., Telnet). In these cases, only
primary component is used. To cater to such cases,
secondary component parameter comes later in the
list
The Foreign Address Primary Component parameter contains
primary component of the destination address. It may be
either a numeric or symbolic form. (Note that this allows
the OPE to exercise a Name Server type of protocol
appropriate, as well as freeing the Host from the necessity
maintaining an in-board name to address table.) The
value for this parameter, although it only makes sense
Passive Begins, is "Any Host". The control flag for
parameter is -fp
Mediation
The mediation level parameter is an indication of the role
Host wishes the OPE to play in the operation of the protocol
The extreme ranges of this mediation would be the case
the Host wished to remain completely uninvolved, and the
where the Host wished to make every possible decision.
specific interpretation of this parameter is dependent upon
particular off-loaded protocol
The concept of mediation level can best be clarified by
of example. A full inboard implementation of the
protocol places several responsibilities on the Host.
responsibilities include negotiation and provision of
options, translation between local and network character
and formats, and monitoring the well-known socket for
connection requests. The mediation level indicates
these responsibilities are assigned to the Host or to the
when the Telnet implementation is outboard. If no
mediation is selected, the Host is involved with
negotiation of the Telnet options, and all format conversions
With full OPE mediation, all option negotiation and all
conversions are performed by the OPE. An intermediate level
mediation might have ordinary option negotiation,
conversion, and socket monitoring done in the OPE,
options not known to the OPE are handled by the Host
The parameter is represented with a single ASCII digit.
value 9 represents full OPE mediation, and the value 0
represents no OPE mediation. Other values may be defined
Lilienkamp & Mandell & Padlipsky [Page 15]
RFC 929 December 1984
Proposed Host-Front End
some protocols (e.g., the intermediate mediation
discussed above for Telnet). The default value for
parameter is 9. The control flag for this parameter is -m
Transmit Response
The Transmit Response Discipline parameter is used to set
desired action on the OPE's part for generating responses
Transmit commands. Essentially the parameter determines
the OPE's response to the transmit command occurs (i.e.,
immediately or delayed).
The Transmit Response Discipline value is represented by
single ASCII character. The character "N" is used
nonblocking Transmit commands, which implies that responses
Transmit commands should be generated as soon as the
has been examined for correctness (i.e., that the syntax
good and the parameters appear reasonable). In other words
the outboard protocol interpreter has the data in its queue
but hasn't necessarily transmitted it to the net.
character "B" is used for blocking Transmit commands,
requests that the response not be generated until the
interpreter has successfully transmitted the data (unless,
course, the Transmit command was badly formed). The
value for this parameter is "N", or a nonblocking
command. The control flag for this parameter is -tr
(Depending on the protocol in play, "successfully transmitted
might well imply that an acknowledgment of some sort has
received from the foreign Host, but for other protocols
might only mean that the given collection of bits has
passed from the OPE to the proximate net.)
Foreign Address Secondary
The addressing mechanisms supported by this level of H-FP
discussed above. The Foreign Address Secondary
parameter contains the value of the destination address'
secondary component. Some protocols do not require
parameter, or can obtain it from other information. Therefore
the default value for this parameter is NULL. A NULL
component might be an error for some protocols, however.
secondary component can be expressed either numerically
symbolically. The control flag for this parameter is -fs
(Note that it is intended to be "legal" to specify a
Component other than the Well-Known Socket for the protocol
play; in such cases, the result should be that the
of the given protocol be applied to the stream, in
Lilienkamp & Mandell & Padlipsky [Page 16]
RFC 929 December 1984
Proposed Host-Front End
expectation that that's what the other side is expecting.
is to cater to, for example, a Terminal-Terminal protocol
merely "does Telnet" to a socket other than the usual Logger.)
Local Address Secondary
The Local Address Secondary Component parameter contains
value of the local address's secondary component. (The
component is assumed to be the default for the Host, but can
altered as well; see below.) Some protocols do not require
parameter, or can obtain it from other information. In
cases, the OPE may already know the value for this
and therefore not require it. The default value of
parameter is NULL. The local address secondary component
be expressed either numerically or symbolically. The
flag for this parameter is -ls
Begin Timeout
After a Begin command is issued, a timer can be started.
the activity requested cannot be performed within some
interval, then the Begin command may expire. An expired
command returns a response code indicating a Begin
occurred. The Begin Timeout Interval parameter contains
length of time the timer will run before the Begin
occurs
The parameter is represented as a string of ASCII
indicating the time interval in seconds. The default value
this parameter is infinity (i.e., the Begin command will
timeout). The control flag for this parameter is -bt
Type of Service
The Type of Service Advice parameter contains information
the service characteristics the user desires from the
protocol. Included in this parameter is the precedence of
data transfer, and also indication of whether high throughput
fast response time, or low error rate is the primary goal
The format of this parameter is a letter immediately (i.e.
intervening spaces) followed by a digit. The letter "T
indicates that high throughput is desired. The letter "R
indicates minimal response time is the goal. The letter "E
indicates that low error rates are the goal. The letter "N
indicates there are no special service requirements to
conveyed. The digit immediately following the
Lilienkamp & Mandell & Padlipsky [Page 17]
RFC 929 December 1984
Proposed Host-Front End
indicates the desired precedence level, with zero being
lowest, and nine being the highest. The
interpretation of this parameter is dependent on what
options are provided by the protocol. The default value
this parameter is the lowest precedence (ROUTINE), and
special service requests. The control flag for this
is -ts
Flow Control
The Flow Control Advice parameter contains information on
flow characteristics desired by the user. Some
such as file transfer operate more efficiently if the data
transferred in large pieces, while other, more
applications are more efficiently served if smaller pieces
used. This parameter then indicates whether large or
data blocks should be used. It is only relevant in stream
connection-oriented protocols, where the user sends more than
single piece of data
This parameter is represented by a single ASCII digit. A
0 means the data should be sent in relatively small
(e.g., character or line oriented applications), while a
9 means the data should be sent in relatively large
(e.g., block or file oriented applications). Other
represent sizes between those extremes. The character "N
indicates that no special flow control advice is provided.
actual interpretation of this parameter is dependent on
particular protocol in the OPE. The default value of
parameter is no flow control advice. In this case, the
in the OPE will operate based only on information available
the OPE. The control flag for this parameter is -fc
Local Address Primary
This parameter contains the local address primary component.
is anticipated that under most circumstances, this component
known to both the Host and the OPE. Consequently,
parameter is seldom required. It would be useful if the
desired to select one of several valid addresses, however.
control flag for this parameter is -lp
The security parameters contain a set of security level
compartment, community of interest, and handling
information. Currently, security is provided by performing
Lilienkamp & Mandell & Padlipsky [Page 18]
RFC 929 December 1984
Proposed Host-Front End
processing at system high level or at a single level
Consequently, these parameters are probably redundant,
the security information is known. In the future, however
these parameters may be required. Therefore a field
provided. The control flag for this parameter is -s
Protcol Idiosyncratic
The remaining parameters are protocol idiosyncratic. That is
each protocol that is off-loaded may have a set of
parameters, which are documented with a description of
off-loaded protocol. The default value for these parameters
NULL, unless otherwise specified by a particular
protocol. The control flag for this set of parameters is -pi
which identifies the first protocol idiosyncratic parameters
Control flags for other protocol idiosyncratic parameters
be defined for each off-loaded protocol
After the Protocol Idiosyncratic Parameters, if any, and
required , if the protocol in play allows for it at
juncture the rest of the chunk will be interpreted as data
be transmitted. That is, in connection oriented protocols
may or may not be permitted at connection initiation time,
in connectionless protocols it certainly makes sense to
the H-FP Begin command to convey data. (This will also
useful when we get to the Condition command.)
The following responses have been identified for the
command
000 Command completed
101 Throughput not available; using
102 Reliability not available; using
103 Delay not available; using
110 Flow Control advice not followed; smaller blocks
111 Flow Control advice not followed; larger blocks
201 Failed; Begin not implemented in this
202 Failed;
203 Failed; Begin command on already active
300 Problem with multiple
301 Syntax problem with Begin
302 Protocol not supported in OPE/
303 Active service not
Lilienkamp & Mandell & Padlipsky [Page 19]
RFC 929 December 1984
Proposed Host-Front End
304 Passive service not
305 Invalid Foreign Address Primary
306 Invalid Transmit
307 Invalid Foreign Address Secondary
308 Invalid Local Address Secondary
309 Invalid Timeout
310 Invalid Type of Service
311 Invalid Flow control
312 Invalid Local Address Primary
401 Protocol Interpreter in OPE not
402 Remote Protocol Interpreter not
403 Failed; insufficient protocol interpreter
501 Failed; insufficient OPE
601 Request violates security
602 Security parameter
Additionally, protocol idiosyncratic responses will be
for each off-loaded protocol
Example of Begin
The Begin command is the most complex of the H-FP
Level. When the off-loaded protocol is TCP, the Begin
is used to open TCP connections. One possible example of
Begin command issued by an inboard Telnet interpreter to open
TCP connection to ISIA, with no begin timeout interval, is
C BE TCP A ISIA 9 N 23 ,, ,, N0 S
Where
TCP The code for the protocol
A Indicates Active
ISIA The name of a Host at USC-
9 Mediation Level 9: Full OPE
N Non-blocking
23 Destination Telnet
,, skip over parameters (Local Address Secondary
Begin Timeout Interval
N0 Type of Service Advice: No special Advice
Normal
S Flow Control Advice: use small
This command will cause the OPE to invoke the TCP
to generate the initial SYN packet to the well-known
socket on Host ISIA. It also informs the OPE to do all
related processing via the Mediation Level, accepts
Lilienkamp & Mandell & Padlipsky [Page 20]
RFC 929 December 1984
Proposed Host-Front End
Local Address parameters, and sets the Begin Timeout
to infinity. The precedence of the TCP connection is Normal
and the TCP interpreter is informed that the data stream
consist of primarily small blocks
Notes to the
Response 203 might seem silly to some readers, but it's
in case somebody goofed in using the Channel Layer
Purpose of the Transmit
The purpose of the Transmit command is to permit the process
the Host to send data using an off-loaded protocol
in the OPE, and also to permit the OPE to deliver data
from the network destined for the process in the Host.
Transmit command is particularly relevant to connection
stream type protocols, although it has applications
connectionless protocols as well. After the Begin command
issued successfully and the proper Response received,
commands can be issued on the given channel. The semantics
the Transmit command depend on whether it was issued by
Host or the OPE
- If the Host issues the Transmit command, a process in
Host wishes to send the data to the destination specified
the off-loaded protocol interpreter that was
(typically) by a previous Begin command on the given H-
channel
- If the OPE issues the command, the OPE has received
destined for a process in the Host from a connection or
supported by the off-loaded protocol that was established by
previous Begin command on the given H-FP channel
Parameters of the Transmit
The Transmit command has one parameter associated with it.
is an optional parameter, to temporarily override the
discipline for this particular transmit command. Some
may have protocol-idiosyncratic parameters as well.
transmit command also has data associated with it.
parameters must precede the data to be transmitted
Lilienkamp & Mandell & Padlipsky [Page 21]
RFC 929 December 1984
Proposed Host-Front End
Response Discipline
The Response Discipline Override parameter indicates
desired response discipline for that individual
Command, overriding the default response discipline. A
ASCII character is used to indicate the desired discipline
The character "N" indicates that this Transmit command
not block, and should return a response as soon as the data
given to the protocol interpreter in the OPE. The character "B
indicates that this Transmit command should block, meaning
a response should not be generated until the data has been
to the destination. The default value of this parameter is
currently defined Transmit Command response discipline.
use of this parameter does not alter the currently
Transmit command response discipline; the default is
with the Condition command. The control flag for
parameter is -rd
Protocol-Idiosyncratic
Any other parameters to the Transmit command
protocol-idiosyncratic. That is, each protocol that
off-loaded has a set of these parameters, which are
with a description of the off-loaded protocol. The
value for these parameters is NULL, unless otherwise
by a particular off-loaded protocol. The control flag for
set of parameters is -pi, which identifies the
protocol-idiosyncratic parameters. Control flags for
protocol-idiosyncratic parameters must be defined for
off-loaded protocol
The following responses for the Transmit command have
identified
000 Transmit Command completed
201 Transmit Command not
300 Problem with multiple
301 Syntax problem with Transmit
302 Invalid Transmit Command Response
401 Protocol Interpreter in OPE not
402 Failure in remote protocol
403 Failed; insufficient protocol interpreter
501 Failed; insufficient OPE
601 Request violates security
Lilienkamp & Mandell & Padlipsky [Page 22]
RFC 929 December 1984
Proposed Host-Front End
Additionally, protocol-idiosyncratic responses will be
for each off-loaded protocol
Example of Transmit
The transmit command is used in TCP to provide the TCP
call. An example of such a transmit command would be
C TR N
Where N indicates non-blocking transmission discipline,
the required command-ending newline, and is presumed
be the user's data that is to be transmitted
Notes to the
If you get a 403 or a 501 response and have sent a
chunk it probably makes sense to try a single chunk; if you'
sent a single chunk, it makes sense to wait a while and
again a few times before giving up on the stream/channel
Purpose of the Condition
The primary purpose of the Condition command is to permit
process to alter the characteristics that were originally
up with the Begin command. (That is, "condition" is a verb.)
These characteristics include the addresses, the
level, the type of service, and the flow control
from Begin. They may also include protocol-
characteristics. (Although Condition is usually thought of as
Host->OPE command, it may also be used OPE->Host in
contexts.)
Condition is a generic command that may find little use in
off-loaded protocols. In others, only some of the
identified may make sense. For example, changing
destination address of a TCP connection involves closing
connection and opening another. Consequently, in may make
sense to first issue an End command, and then a Begin with
new address. In other protocols, such as IP or UDP,
the address on each datagram would be a perfectly
thing to do
Lilienkamp & Mandell & Padlipsky [Page 23]
RFC 929 December 1984
Proposed Host-Front End
Parameters of the Condition
The Condition command has the same parameters as the
command. Any parameters expressed in a Condition
indicate the new values of the characteristics to be altered
all parameters not expressed retain the current value
Although it is possible to express the change of any of
characteristics originally set up in the Begin command
the Condition command, there are some characteristics that
not make sense to alter, at least for some protocols.
example, once a connection is opened, it does not make
sense to change the Foreign Address Primary or
Components. Doing so is inconsistent with current versions
TCP, and would require the closing of the existing
and opening a new one to another address. Earlier versions
TCP did permit connections to be moved. If a protocol
provided such a feature was implemented in the OPE,
changing the Secondary Address Components would be a
thing to do
The responses to the Condition command are the same as those
the Begin command
Example of Condition
The Condition Command can be quite complex, and can be used
many purposes. One conceived use of the condition
would be to change the type of service advice associated
the channel. An example of this (which also demonstrates
ability to skip parameters) is
C -ts T
which causes the offloaded PI associated with the
channel to attempt to achieve high throughput (in its use
the comm subnet(s) in play).
Notes to the
Lilienkamp & Mandell & Padlipsky [Page 24]
RFC 929 December 1984
Proposed Host-Front End
Purpose of Signal
The purpose of the Signal Command (implicitly at least) is
permit the transfer of out-of-band signals or
between the Host and the OPE, in order to utilize (explicitly
out-of-band signaling services of the off-loaded protocol.
semantics of the Signal command depend upon whether it
issued by the Host or the OPE
- If the Signal command was issued by the Host, it means
process in the Host desires to send out-of-band data or
out-of-band signal
- If the Signal command was issued by the OPE, it
out-of-band data or an out-of-band signal arrived for
process associated with the channel in the Host
Parameters of the Signal
The basic usage of the Signal command is with no parameters
which sends or reports the receipt of an out-of-band signal
Some protocols, such as the NBS Transport Protocol, permit
user to send data with the out-of-band signal. Hence, data
permitted to accompany the Signal command. There may also
protocol-idiosyncratic parameters for the Signal command.
this is the case, these parameters would come before the data
Protocol-Idiosyncratic
The parameters for the Signal command are
idiosyncratic. That is, each protocol off-loaded has a set
these parameters. The default value for these parameters
their previous values. Control flags for
protocol-idiosyncratic parameters must be defined for
off-loaded protocol
The following responses have been identified for the
command
000 Command completed
201 Command not
300 Problem with multiple 