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, RFC928, 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 RFC928, 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 RFCsuggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
RFC929 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
RFC929 December 1984
Proposed Host-Front End Protocol
mechanisms themselves. Another way of putting it is that "if the
protocols were inboard," the processes invoking H-FP wouldn't know
the difference. H-FP, then, may be viewed as a roundabout way of
letting Host processes "get at" various PIs.
Naturally, the mechanization of the desired concept cannot be
particularly literal. After all, the Hosts and the OPEs are
different processors, so we're not envisioning a passing through of
parameters in an exact fashion. However, in broad terms the model is
just that of a somewhat funny interface between a process and a PI.
(This should not be construed as ruling out the occurrence of events
which prompt the OPE to initiate an exchange of commands with the
Host, though; see the Introduction for more on the topic of
"Symmetric Begins.")
Interaction Discipline
The interaction between the Host and the OPE must be capable of
providing a suitable interface between processes (or protocol
interpreters) in the Host and the off-loaded protocol interpreters in
the OPE. This interaction must not, however, burden the Host more
heavily than would have resulted from supporting the protocols
inboard, lest the advantage of using an OPE be overridden.
Channel Level Interaction
As stated elsewhere, the Channel level protocol (implicitly in
conjunction with the Link level) provides two major functions. These
are demultiplexing the traffic from the Link level into distinct data
streams, and providing flow control between the Host and the OPE on a
per stream basis. These hold even if the Host-OPE attachment is DMA.
The data streams between the Host and the OPE are bidirectional. In
this document, the basic unit of data transferred by the Channel
level is referred to as a "chunk". The primary motivation for this
terminology is that the H-FP permits the Channel level to be one of
several possible protocols, each with its own terminology. For
example, a chunk on an X.25 Channel would be a packet, while a chunk
on the DTI H-FP channel would be a message. While the Command level
is, in a sense, "more efficient" when the chunk size is permitted to
be large, the flexibility permitted in the choice of protocols at the
Channel level precludes any assumptions about the chunk size.
Each data stream is fully asynchronous. A Channel protocol user can
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 protocol
RFC929 December 1984
Proposed Host-Front End Protocol
is reliable; this entails delivery in the correct order, without
duplication, and checked for bit errors. All retransmission, error
checking, and duplicate detection is provided by this protocol in a
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 OPE
and the Host from overloading each other's resources by excessive
transmissions. In general, this flow control should not directly
affect the outboard protocol interpreters' operation. On the other
had, this flow control has the same effect as explicit interface
events that provide flow control between the user and the protocol
interpreter (e.g., the Allocate event of the interface specification
for TCP found in MIL-STD 1778). Hence, such events do not need to be
communicated explicitly at the Command level. (If the attachment is
DMA, flow control must still be provided for.)
Should Hosts require an OPE to be attached via a Link Level that
furnishes physical demultiplexing (e.g., a group of RS232 ports), any
attempt to avoid furnishing reliability and explicit flow control, is
done at their peril; we have not chosen to assist such an
enterprise, but neither have we precluded it. (It would certainly
violate the spirit of the thing, however.)
Command Level Interaction
The approach chosen for this H-FP is to base the interaction on a
small set of commands, separately applicable to a given Channel Level
channel. The commands are simple, but sufficiently flexible to permit
the off-loading of the interpreters of the large number of protocols
at various levels in the hierarchy. This flexibility is made
possible in part by the similar nature of the interfaces to most
protocols, combined with the provision of "protocol idiosyncratic
parameters". These parameters are defined for each offloaded protocol
interpreter in the OPE. The use of such parameters does not
complicate the basic design of the OPE, since it must be customized
for each off-loaded protocol anyway, and all that is required of the
OPE for those parameters is to pass them to the off-loaded protocol
interpreter. Hence, an interface tailored to a particular protocol
can be created in a straightforward and cost-effective way.
The command dialog is more or less asynchronous. Commands can be
issued at any particular time (except when there is a pending
command, which will be discussed below), and there is no need for
dummy traffic on a channel when no commands are issued.
Associated with each command is a response. The purpose of this
RFC929 December 1984
Proposed Host-Front End Protocol
response is to indicate, at some level that depends in part on the
particular protocol interpreter that is offloaded to the OPE, whether
the command was successfully executed, and if unsuccessful, the
reason. Often, generating the response involves interaction with the
protocol interpreter before a response can be generated.
When a command is issued, the issuer must wait for a response before
another command is issued. The nature of the communication between
the Host and the OPE is thus a lock step command/response dialog.
There are two major exceptions to this principle, however. One
exception is the abrupt form of the End command, which can be issued
at any time to cancel any previously issued commands, and indicate
that services are no longer desired. The other exception is the
Signal command. Since a Signal is out-of-band and usually of high
importance, forcing it to wait on a response would be undesirable.
Hence, a Signal command can be issued while commands (other than
Signal) are pending. However, a Signal command should not be issued
before a successful response to the Begin command has been received.
Since it is possible for more than one command of different types to
be pending at one time, a mechanism to distinguish responses is
needed. Since there are never two commands of the same type pending,
including the command name in the response is sufficient to make this
distinction.
A special case command is the Transmit command. Details of the
Transmit command are provided in the next section. Essentially, the
Transmit command is used to invoke the data transfer services of the
off-loaded protocol (when issued by the Host) or to indicate the
arrival of new data from the network (when issued by the OPE). The
nature of specific protocol interfaces for these events varies widely
between protocols. Some may block until the data is accepted by the
remote counterpart (or "peer") protocol interpreter, while others may
not. Hence, there is a special parameter which indicates the nature
of the Transmit command interface. It can either require that the
response should be generated immediately after determining the
Transmit command is complete and formed properly, or can indicate
that the response should not be generated until the appropriate
interface event is given by the remote protocol interpreter. The
default action for all Transmit commands can be initialized using the
Begin command and changed using the Condition command. Also, the
default action can be temporarily overridden by specifying a
parameter with the Transmit command. The net result of this mechanism
is to allow the Host to determine within reason just how lock-stepped
transmissions are to be. (It is assumed that the usual case will be
to transfer the burden of buffering to the OPE by taking immediate
responses, provided that doing so "makes sense" with the particular
offloaded protocol in play.)
RFC929 December 1984
Proposed Host-Front End Protocol
Some protocols provide a block-oriented data transfer service rather
than a stream-oriented one. With such a service, the data associated
with a transfer request is viewed as an integral unit. For actual
network transmission, the protocol may permit these units to be
grouped or fragmented. However, the receiving end must deliver the
data in the original, integral units. Protocols that conform to this
model include some datagram protocols such as IP and UDP, and also
some connection protocols such as NBS TP.
To cater to these types of protocols, it is a convention that
commands, their parameters, and any associated data be transferred
between the Host and the OPE in a single chunk. Any data associated
with an H-FP command is viewed as an integral unit which is used in
the corresponding service request given to the outboard protocol
interpreter or delivered as a complete unit to the process in the
Host. Operation of stream-oriented protocols such as TCP will not be
adversely affected by this convention.
To accommodate Channel protocols that do not provide for arbitrarily
large chunks, a mechanism at the Command level is required to permit
the linking of multiple chunks into a single command, in order to
transfer the burden of buffering as much as possible from the Host to
the OPE. The facility proposed here would consist of an indication
at the beginning of each chunk which would distinguish integral
commands, fragments of a command for which more fragments are yet to
arrive, and the final fragment of a command. The details of this
mechanism are discussed in the section on the syntax of commands and
responses.
It is a convention for this H-FP that any data associated with a
command must start on a word boundary (as defined by the local
system). Consequently, there is a need to provide padding within the
commands. Such padding is used only to fill to the next appropriate
boundary, and has no semantic significance to the command interpreter
(i.e., two commands that are identical except for the amount of
padding should behave identically). The details of this padding are
discussed in the section on the syntax of commands and responses.
RFC929 December 1984
Proposed Host-Front End Protocol
Syntax Rules
At the Command Level, communication between the Host and the OPE
takes the form of commands and responses. A command is a request for
some particular action, and the response indicates the success or
failure of performing the requested action.
All commands and responses are coded in ASCII characters. (Nothing
precludes OPEs from accepting EBCDIC from Hosts that use it in native
mode, but that is not required.) These characters are sent in some
way convenient for the Host, and the OPE is sufficiently flexible to
interpret them. (i.e., OPEs are expected to accommodate Host
idiosyncracies in regard to such things as use of 7-bit ASCII in a
9-bit field.) This approach offers several advantages:
Adaptabilities in most Hosts: Most Hosts have the ability to
generate and interpret ASCII character streams. Hence, integrating
H-FP into a Host will not require difficult software.
Script generation: Generation of test and operational command
scripts will be simplified, since they will not need to contain
special characters.
Terminal Operation: Using simple command streams simplifies the
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 interpret
commands and responses. A terminal or data line analyzer would be
adequate.
The specific format for the commands and responses will be discussed
in the sections that follow. In those sections, the quote character
is used to indicate strings. The symbols "<" and ">" (referred to as
angle brackets) are used as meta-characters.
Syntax of Commands
As alluded to in the section discussing the interaction discipline
between the Host and the OPE, a function is provided by which a chunk
can be used to carry either a complete command or a fragment of a
command. The mechanism chosen to provide this function entails use
of the first character position in the chunk as a chunk usage
identifier. The character "C" in the first position indicates a
chunk containing a single, complete command. "F" in the first
position indicates a chunk which is the first part of a multichunk
command. "M" in the first position indicates the chunk is a middle
RFC929 December 1984
Proposed Host-Front End Protocol
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 to
the chunk usage identifier in each chunk, and the angle brackets
enclose a chunk) are legal:
<C>
<F><L>
<F><M><M><L>
while the following are not legal:
<L>
<M><L>
<F><C>
Tactics for handling multiple chunks with regard to OPE buffering
limits are left to the ingenuity of OPE builders. The spirit is to
take as much as you can, in order to relieve the Host of the
necessity of buffering itself.
A command always begins immediately following the indicator
character, with possible intervening spaces. This implies a chunk
can contain at most one complete command. The end of the command
(not including the data) is signified by a newline (denoted as <nl>
in this document) that does not appear inside a quoted string (see
below). The end of the data is designated by the end of the last
chunk.
Commands take the form of an ASCII string. The command identifier is
the first word of the chunk. It consists of at least the first two
letters of the command, in either upper or lower case (e.g., the
sequences "BE", "Be", "bE", and "be" all identify the Begin command).
Additional letters of the command name can be included if desired to
aid readability of the command stream.
Following the command identifier is a list of parameters. These
parameters are also represented as ASCII strings, although the
specific format will depend on the particular parameter. The data to
be transmitted is not considered a control parameter, however, and
need not be ASCII data.
Parameters are separated by one or more spaces. Tabs, newlines, and
other white space are not legal parameter separators.
Parameter strings may be quoted, using the character <">. Any
RFC929 December 1984
Proposed Host-Front End Protocol
characters between the <"> characters are a part of the parameter,
including spaces and newlines. The character <"> that is part of the
parameter is represented inside a quoted string as <"">.
The order in which the parameters appear within the command is
significant to their interpretation by the Host and by the OPE.
Optional parameters may be skipped by using the characters ",," to
indicate a NULL parameter. Such a NULL parameter takes its default
value. Alternatively, each parameter has a MULTICS/UNIX style
Control Argument/Flag associated with it that can be used to identify
the parameter, without placing NULL parameters for each parameter
skipped. This flag consists of one or two ASCII characters, and
either upper or lower case may be used. For example, if the fourth
parameter of a command had a flag of "-p" and the user wished the
first three parameters to be null, he could use:
command -p value
or
command -P value
instead of
command ,, ,, ,, value
if it were more convenient for the Host to do so. Flagged parameters
must still appear in the correct sequence within the command,
however.
There may be data associated with some of the commands. Any such
data is placed into the chunk following all the parameters and the
unquoted newline. Padding can be provided by placing spaces between
the end of the final parameter string and the newline, so that data
begins on a word boundary. The OPE will always pad to a host word
boundary. Padding by hosts is optional.
Syntax of Responses
Responses are actually just a special form of a command. It is
anticipated that all responses would fit into a single channel chunk,
although the mechanisms described for multichunk commands can
certainly be used in responses. The ASCII string used to uniquely
identify the response command is "RE" ("Re", "rE", and "re" are also
permitted).
After the response command identifier is the original command
RFC929 December 1984
Proposed Host-Front End Protocol
identifier, so the response can be associated with the proper
command. Following this identifier is a three ASCII digit response
code, a set of protocol idiosyncratic parameters, and a textual
message. The protocol idiosyncratic parameters are used to transfer
interface information between the Host and the OPE, and may not be
needed when off-loading some protocol interpreters. The textual
message is intended for human interpretation of the response codes,
and is not required by the protocol. The three digits uniquely
identify the semantics of the response, at least within the context
of a particular command and particular outboarded protocol
interpreter.
Responses are numerically grouped by the type of information they
convey. The first digit identifies this group, and the last two
digits further qualify the reply. The following list illustrates
this grouping.
0XX Successful: The command was executed successfully. The
response code may contain further information.
1XX Conditional Success: The command was executed successfully,
but not exactly according to the service and flow control
suggestions. If those suggestions were particularly important
to the requester, he may wish to issue an End command. The
response code contains information on what suggestion or
suggestions could not be followed.
2XX Command Level Error: An error at the command level has
occurred. This could include requesting services of a
protocol not supported, or a problem in the way those services
were requested. This level does not include problems with the
syntax of the command or its parameters.
3XX Syntax and Parameter Errors: An error in the syntax of the
command or a problem with one of its parameters has occurred.
A problem with a parameter may be other than syntactical, such
as illegal address.
4XX Off-loaded Protocol Interpreter Problems: Some problem with
the particular off-loaded protocol has occurred.
5XX Local OPE Internal Problems: Problems, such as insufficient
OPE resources, or problems with OPE to subnet interface.
6XX Security Problem: Some problem with Host, network, or OPE
security has occurred. The response code indicates the
problem.
RFC929 December 1984
Proposed Host-Front End Protocol
7XX Reserved for Future Expansion
8XX Reserved for Future Expansion
9XX Protocol Idiosyncratic Errors: Some error occurred that is
idiosyncratic to the particular off-loaded protocol being
used. The response code indicates the error.
Description of the Commands
As stated above, communication between the Host and the OPE at the
Command Level is accomplished using commands and responses. Commands
may be issued by either the Host or the OPE, and are used to
stimulate activity in the other entity. Some commands may only have a
meaningful interpretation in one direction, however. A response
indicates that the activity started by the command was completed, and
a code indicates success or failure of the command, and perhaps other
information related to the command as well.
Associated with each command is a set of parameters. The order in
which the parameters appear is significant to the correct operation
of the protocols. More information on the syntax of command
parameters can be found in the syntax descriptions.
The commands are:
- Begin: initiate communication between a process in the Host and
an off-loaded protocol interpreter in the OPE. (A Channel level
stream/connection will typically have been opened as a prior step.
All other commands, except No-op, apply to a stream on which a
successful Begin has been done.)
- Transmit: transmit data between a process in the Host and an
off-loaded protocol interpreter in the OPE.
- Signal: cause an out-of-band signal to be sent by the
off-loaded protocol interpreter to its peer, or indicate the
arrival of such a signal from the remote side.
- Condition: alter the off-loaded protocol interpreter's
operational characteristics.
- Status: transfer status requests or information between a
process in the Host and an off-loaded protocol interpreter in the
OPE.
RFC929 December 1984
Proposed Host-Front End Protocol
- End: indicate that services from the off-loaded protocol
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 of
these sections includes a discussion of the purpose of the command, a
description of each of the parameters used with the command, a list
of responses for the command, an example of the command, and a set of
notes for the implementor. (An appendix will eventually be furnished
for each protocol offloading, showing the use of its protocol
idiosyncratic parameters as well as of the general parameters on a
per-command basis. Initially, only representative offloadings will
be treated in appendices, with others to be added after the protocol
gains acceptance.)
Begin
Purpose of the Begin Command
The purpose of a Begin command is to initiate communication
between the Host and the OPE on a particular stream or channel
(the channel is opened as a separate step, of course). The
interpretation of the command is somewhat dependent upon
whether it was issued by the Host of the OPE.
- If the command was issued by the Host, it means some process
in the Host is requesting services of a protocol that was
off-loaded to the OPE. The user request results in the
establishment of a channel connection between the Host and the
OPE, and a Begin command to the Command interpreter in the OPE.
- If the command was issued by the OPE, it means some protocol
interpreter in the OPE has data for some process in the Host
which is not currently known by the OPE. An example would be
an incoming UDP datagram on a new port, or if no Begin for UDP
had been issued at all by the Host. (An incoming TCP
connection request could be handled by a response to the user's
Passive Open request, which had previously caused a Begin
request from the Host; an incoming TCP connection request to a
port on which no Listen had been issued would cause an OPE
generated Begin, however.)
As indicated earlier, any particular Host is not required to
support two-way Begins.
RFC929 December 1984
Proposed Host-Front End Protocol
Parameters of the Begin Command
The Begin command has several parameters associated with it.
These parameters contain information needed by the offloaded
protocol to provide an adequate level of network service. This
information includes protocol, source and destination
addresses, and also type of service and flow control advice.
These parameters are discussed in detail below.
Protocol
The protocol parameter identifies that off-loaded protocol in
the OPE to which Begin is directed, or which issued the Begin
to the Host. For example, if the user wished to utilize TCP
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 and
specific. A generic parameter identifies a type of protocol
service required, but does not identify the actual protocol.
Use of generic protocols allows a Host process to obtain
network services without specific knowledge of what protocol is
being used; this could be appropriate for use in situations
where no specific aspect(s) of a specific protocol is/are
required. For example, the user may select a generic
Host-to-Host connection protocol, and (at some point in the
future) may actually receive services from either TCP or the
NBS Transport Protocol, depending on the network (or even the
foreign Host) in question. A specific protocol parameter
identifies some particular protocol, e.g., TCP, whose use is
required for the given channel.
The valid entries for the protocol field include:
Generic Specific Comment
GIP IP Datagram Internetwork Protocol
HHP TCP Connection Transport/Host-Host Protocol
GDP UDP Datagram Transport/Host-Host Protocol
VTP TEL Virtual Terminal (Telnet) Protocol
GFP FTP File Transfer Protocol
MAIL SMTP Mail Transfer Protocol
PROX PROX Proximate Net Interface Protocol
(Note that the final line is meant to allow for a process in an
OPE'd Host's getting at the PI of the Network Interface
Protocol for whatever the proximate network is. Of course, so
RFC929 December 1984
Proposed Host-Front End Protocol
doing only makes sense in specialized contexts. We conceive of
the desirability of "pumping bits at a peripheral" on a LAN,
though, and don't want to preclude it, even if it would be
impossible on many LAN's to deal with the problem of
distinguishing traffic coming back on the LAN in this "raw"
mode from normal, IP traffic. Indeed, in some contexts it is
likely that administrative considerations would preclude
avoidance of IP even if technical considerations allowed it,
but it's still the case that "the protocol" should provide a
hook for going directly to the L I protocol in play.)
There is no default value for this parameter. If it is not
present, the Begin command is in error. The control flag for
this parameter is -pr.
Active/Passive
The Active/Passive parameter indicates whether the issuer of
the Begin command desires to be the Active or Passive user of
the protocol. This parameter is particularly relevant to
connection-oriented protocols such as TCP, where the user may
actively pursue connection establishment, or else may passively
wait for the remote entity to actively establish the
connection; it also allows some process to establish itself as
the Host "fielder" of incoming traffic for a connectionless
protocol such as IP.
Active is requested using the single character "A". Passive is
indicated using the character "P". The default value of this
parameter is "A". Also, when the OPE issues the Begin command,
the value must be "A". The control flag for this parameter is
-ap.
Foreign Address Primary Component
The addressing structure supported by H-FP is two level. Each
address has two components, the primary and the secondary. The
exact interpretation of these two components is protocol
specific, but some generalities do apply. The primary
component of the address identifies where the protocol is to
deliver the information. The secondary component identifies
which recipient at that location is to receive the information.
For example, the TCP primary address component is the Host's
Internet Address, while the secondary address component is the
TCP port. Similarly, IP's primary address component is the
Host's Internet Address, and the secondary address component is
the IP ULP field. Some protocols provide only a single level
RFC929 December 1984
Proposed Host-Front End Protocol
of addressing, or the secondary level can be deduced from some
other information (e.g., Telnet). In these cases, only the
primary component is used. To cater to such cases, the
secondary component parameter comes later in the parameter
list.
The Foreign Address Primary Component parameter contains the
primary component of the destination address. It may be in
either a numeric or symbolic form. (Note that this allows for
the OPE to exercise a Name Server type of protocol if
appropriate, as well as freeing the Host from the necessity of
maintaining an in-board name to address table.) The default
value for this parameter, although it only makes sense for
Passive Begins, is "Any Host". The control flag for this
parameter is -fp.
Mediation Level
The mediation level parameter is an indication of the role the
Host wishes the OPE to play in the operation of the protocol.
The extreme ranges of this mediation would be the case where
the Host wished to remain completely uninvolved, and the case
where the Host wished to make every possible decision. The
specific interpretation of this parameter is dependent upon the
particular off-loaded protocol.
The concept of mediation level can best be clarified by means
of example. A full inboard implementation of the Telnet
protocol places several responsibilities on the Host. These
responsibilities include negotiation and provision of protocol
options, translation between local and network character codes
and formats, and monitoring the well-known socket for incoming
connection requests. The mediation level indicates whether
these responsibilities are assigned to the Host or to the OPE
when the Telnet implementation is outboard. If no OPE
mediation is selected, the Host is involved with all
negotiation of the Telnet options, and all format conversions.
With full OPE mediation, all option negotiation and all format
conversions are performed by the OPE. An intermediate level of
mediation might have ordinary option negotiation, format
conversion, and socket monitoring done in the OPE, while
options not known to the OPE are handled by the Host.
The parameter is represented with a single ASCII digit. The
value 9 represents full OPE mediation, and the value 0
represents no OPE mediation. Other values may be defined for
RFC929 December 1984
Proposed Host-Front End Protocol
some protocols (e.g., the intermediate mediation level
discussed above for Telnet). The default value for this
parameter is 9. The control flag for this parameter is -m.
Transmit Response Discipline
The Transmit Response Discipline parameter is used to set the
desired action on the OPE's part for generating responses to
Transmit commands. Essentially the parameter determines when
the OPE's response to the transmit command occurs (i.e.,
immediately or delayed).
The Transmit Response Discipline value is represented by a
single ASCII character. The character "N" is used for
nonblocking Transmit commands, which implies that responses for
Transmit commands should be generated as soon as the command
has been examined for correctness (i.e., that the syntax is
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. The
character "B" is used for blocking Transmit commands, which
requests that the response not be generated until the protocol
interpreter has successfully transmitted the data (unless, of
course, the Transmit command was badly formed). The default
value for this parameter is "N", or a nonblocking Transmit
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 been
received from the foreign Host, but for other protocols it
might only mean that the given collection of bits has been
passed from the OPE to the proximate net.)
Foreign Address Secondary Component
The addressing mechanisms supported by this level of H-FP are
discussed above. The Foreign Address Secondary Component
parameter contains the value of the destination address's
secondary component. Some protocols do not require this
parameter, or can obtain it from other information. Therefore,
the default value for this parameter is NULL. A NULL secondary
component might be an error for some protocols, however. The
secondary component can be expressed either numerically or
symbolically. The control flag for this parameter is -fs.
(Note that it is intended to be "legal" to specify a Secondary
Component other than the Well-Known Socket for the protocol in
play; in such cases, the result should be that the virtualizing
of the given protocol be applied to the stream, in the
RFC929 December 1984
Proposed Host-Front End Protocol
expectation that that's what the other side is expecting. This
is to cater to, for example, a Terminal-Terminal protocol that
merely "does Telnet" to a socket other than the usual Logger.)
Local Address Secondary Component
The Local Address Secondary Component parameter contains the
value of the local address's secondary component. (The primary
component is assumed to be the default for the Host, but can be
altered as well; see below.) Some protocols do not require this
parameter, or can obtain it from other information. In some
cases, the OPE may already know the value for this parameter
and therefore not require it. The default value of this
parameter is NULL. The local address secondary component can
be expressed either numerically or symbolically. The control
flag for this parameter is -ls.
Begin Timeout Interval
After a Begin command is issued, a timer can be started. If
the activity requested cannot be performed within some timed
interval, then the Begin command may expire. An expired Begin
command returns a response code indicating a Begin timeout
occurred. The Begin Timeout Interval parameter contains the
length of time the timer will run before the Begin timeout
occurs.
The parameter is represented as a string of ASCII digits
indicating the time interval in seconds. The default value of
this parameter is infinity (i.e., the Begin command will never
timeout). The control flag for this parameter is -bt.
Type of Service Advice
The Type of Service Advice parameter contains information on
the service characteristics the user desires from the offloaded
protocol. Included in this parameter is the precedence of the
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. no
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 be
conveyed. The digit immediately following the character
RFC929 December 1984
Proposed Host-Front End Protocol
indicates the desired precedence level, with zero being the
lowest, and nine being the highest. The specific
interpretation of this parameter is dependent on what service
options are provided by the protocol. The default value of
this parameter is the lowest precedence (ROUTINE), and no
special service requests. The control flag for this parameter
is -ts.
Flow Control Advice
The Flow Control Advice parameter contains information on the
flow characteristics desired by the user. Some applications
such as file transfer operate more efficiently if the data is
transferred in large pieces, while other, more interactive
applications are more efficiently served if smaller pieces are
used. This parameter then indicates whether large or small
data blocks should be used. It is only relevant in stream or
connection-oriented protocols, where the user sends more than a
single piece of data.
This parameter is represented by a single ASCII digit. A value
0 means the data should be sent in relatively small blocks
(e.g., character or line oriented applications), while a value
9 means the data should be sent in relatively large blocks
(e.g., block or file oriented applications). Other values
represent sizes between those extremes. The character "N"
indicates that no special flow control advice is provided. The
actual interpretation of this parameter is dependent on the
particular protocol in the OPE. The default value of this
parameter is no flow control advice. In this case, the protocol
in the OPE will operate based only on information available in
the OPE. The control flag for this parameter is -fc.
Local Address Primary Component
This parameter contains the local address primary component. It
is anticipated that under most circumstances, this component is
known to both the Host and the OPE. Consequently, this
parameter is seldom required. It would be useful if the Host
desired to select one of several valid addresses, however. The
control flag for this parameter is -lp.
Security
The security parameters contain a set of security level,
compartment, community of interest, and handling restriction
information. Currently, security is provided by performing all
RFC929 December 1984
Proposed Host-Front End Protocol
processing at system high level or at a single level.
Consequently, these parameters are probably redundant, since
the security information is known. In the future, however,
these parameters may be required. Therefore a field is
provided. The control flag for this parameter is -s.
Protcol Idiosyncratic Parameters
The remaining parameters are protocol idiosyncratic. That is,
each protocol that is off-loaded may have a set of these
parameters, which are documented with a description of the
off-loaded protocol. The default value for these parameters is
NULL, unless otherwise specified by a particular offloaded
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 must
be defined for each off-loaded protocol.
Data
After the Protocol Idiosyncratic Parameters, if any, and the
required <nl>, if the protocol in play allows for it at this
juncture the rest of the chunk will be interpreted as data to
be transmitted. That is, in connection oriented protocols data
may or may not be permitted at connection initiation time, but
in connectionless protocols it certainly makes sense to allow
the H-FP Begin command to convey data. (This will also be
useful when we get to the Condition command.)
Responses
The following responses have been identified for the Begin
command:
000 Command completed successfully
101 Throughput not available; using maximum
102 Reliability not available; using maximum
103 Delay not available; using minimum
110 Flow Control advice not followed; smaller blocks used
111 Flow Control advice not followed; larger blocks used
201 Failed; Begin not implemented in this direction
202 Failed; timeout
203 Failed; Begin command on already active channel
300 Problem with multiple chunks
301 Syntax problem with Begin command
302 Protocol not supported in OPE/Host
303 Active service not available
RFC929 December 1984
Proposed Host-Front End Protocol
304 Passive service not available
305 Invalid Foreign Address Primary Component
306 Invalid Transmit Discipline
307 Invalid Foreign Address Secondary Component
308 Invalid Local Address Secondary Component
309 Invalid Timeout Interval
310 Invalid Type of Service Advice
311 Invalid Flow control Advice
312 Invalid Local Address Primary Component
401 Protocol Interpreter in OPE not responding
402 Remote Protocol Interpreter not available
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
602 Security parameter problem
Additionally, protocol idiosyncratic responses will be defined
for each off-loaded protocol.
Example of Begin Command
The Begin command is the most complex of the H-FP Command
Level. When the off-loaded protocol is TCP, the Begin command
is used to open TCP connections. One possible example of a
Begin command issued by an inboard Telnet interpreter to open a
TCP connection to ISIA, with no begin timeout interval, is:
C BE TCP A ISIA 9 N 23 ,, ,, N0 S <nl>
Where:
TCP The code for the protocol TCP
A Indicates Active Begin
ISIA The name of a Host at USC-ISI
9 Mediation Level 9: Full OPE mediation
N Non-blocking transmit
23 Destination Telnet Port
,, skip over parameters (Local Address Secondary,
Begin Timeout Interval)
N0 Type of Service Advice: No special Advice,
Normal Precedence
S Flow Control Advice: use small blocks
This command will cause the OPE to invoke the TCP interpreter