国内领先的B2M2C教育培训网上信息平台
选择分类
热门推荐
>> RFC929 - Proposed Host-Front End Protocol59790ceb0ca66518
RFC929 - Proposed Host-Front End Protocol59790ceb0ca66518
网友投搞 转载日期：
2011.07.28 作者：
佚名 浏览次数：
核心提示：
网络学院频道所转载文章、数据等内容纯属作者个人观点，仅供学习参考使用。本文《
》来源于网络并非原创内容，请读者以官方内容为准，如果您发现本资料有侵犯您的知识产权，
，我们将第一时间内删除该资料，以保障您的知识产权。
　　Network Working Group Joel Lilienkamp (SDC)
Request for Comments: 929 Richard Mandell (SDC)
Michael Padli ky (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 a umes that the
separate document,
, 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
, not by the primary author of the present
document, so any readers bothered by style co ideratio should feel
free to blame the former, who's used to it, rather than the latter,
who may well be guiltle . (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 su ly a endices for all of the
protocol offloadings, describing their uses of protocol idiosyncratic
parameters and even their interpretatio of the standard per-command
parameters, but in order to get what we've got into circulation we
haven't waited until all such a endices 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 a oying
... not to say embarra ing.) For that matter, it's not even a
finished document with re ect to what is here. Not only is it our
stated intention to revise the protocol based upon implementation
eXPerience gained from volunteer test implementatio , but it's also
the case that it ha 't proven feasible to iron out all known
wrinkles in what is being presented. For example, the re o e codes
almost certainly need clarification and expa ion, and at least one
of us doe '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 i 't meant to be what you or we are stuck with.
This RFCsuggests a proposed protocol for the ARPA-Internet
community, and requests discu ion and suggestio for improvements.
Distribution of this memo is unlimited.
December 1984
Proposed Host-Front End Protocol
Conceptual Model
There are two fundamental motivatio for doing outboard proce ing.
One is to co erve 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 Proce ing
Environments (or "Network Front-Ends") as po ible. The other is to
facilitate procurement of implementatio of the various
intercomputer networking protocols for the several types of Host in
play in a typical heterogeneous intercomputer network, by employing
common implementatio in the OPE. A third motivation, of basing a
network security a roach 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,
a umed desire to perform true intercomputer networking, however.
Therefore, it is further a umed 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 reaso discu ed in the Introduction, an H-FP resolves into
three layers. The Link layer enables the exchange of bits between
Host and OPE. The Cha el layer enables the bit streams to be
demultiplexed and flow controlled (both the Cha el and Link layers
may use preexisting per-Host mechanizatio , it should be recalled).
The Command (or "Service Acce ") layer is our primary concern at
present. It serves as the distributed proce ing mechanism which
allows proce es 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 Cha el
layers may be viewed as roughly equivalent to the i oard proce ing
investment for a Host-comm su et proce or PI and device driver, so
in practical terms the savings of resources achieved by outboard
proce ing come from making the H-FP "smaller" than the i oard
implementatio 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) proce and a PI (which is actually
outboard). Usually, the model is that of a closed subroutine
interface, although in some cases an interproce communication
mechanism model must be a ealed to. That is, the interactio between cooperating H-FP PIs in some se e mimic subroutine or IPC
calls, from the per ective of Host proce es calling upon their own
H-FP PIs, which in turn are of course interfacing via just such
December 1984
Proposed Host-Front End Protocol
mechanisms themselves. Another way of putting it is that "if the
protocols were i oard," the proce es invoking H-FP wouldn't know
the difference. H-FP, then, may be viewed as a roundabout way of
letting Host proce es "get at" various PIs.
Naturally, the mechanization of the desired concept ca ot be
particularly literal. After all, the Hosts and the OPEs are
different proce ors, so we're not envisioning a pa ing through of
parameters in an exact fashion. However, in broad terms the model is
just that of a somewhat fu y interface between a proce and a PI.
(This should not be co trued 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 Begi .")
Interaction Discipline
The interaction between the Host and the OPE must be capable of
providing a suitable interface between proce es (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 su orting the protocols
i oard, lest the advantage of using an OPE be overridden.
Cha el Level Interaction
As stated elsewhere, the Cha el level protocol (implicitly in
conjunction with the Link level) provides two major functio . 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 tra ferred by the Cha el
level is referred to as a "chunk". The primary motivation for this
terminology is that the H-FP permits the Cha el level to be one of
several po ible protocols, each with its own terminology. For
example, a chunk on an X.25 Cha el would be a packet, while a chunk
on the DTI H-FP cha el would be a me age. While the Command level
is, in a se e, "more efficient" when the chunk size is permitted to
be large, the flexibility permitted in the choice of protocols at the
Cha el level precludes any a umptio about the chunk size.
Each data stream is fully asynchronous. A Cha el protocol user can
send data at any time, once the cha el has been properly opened.
(The Command level's logic may render some actio meaningle ,
however.) The data tra fer service provided by the Cha el protocol
December 1984
Proposed Host-Front End Protocol
is reliable; this entails delivery in the correct order, without
duplication, and checked for bit errors. All retra mi ion, error
checking, and duplicate detection is provided by this protocol in a
way that is tra arent to the user. (If the attachment is DMA,
stream identification and chunk length must still be provided for.)
The flow control at the Cha el level is provided to prevent the OPE
and the Host from overloading each other's resources by exce ive
tra mi io . 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 ecification
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 a ist such an
enterprise, but neither have we precluded it. (It would certainly
violate the irit of the thing, however.)
Command Level Interaction
The a roach chosen for this H-FP is to base the interaction on a
small set of commands, separately a licable to a given Cha el Level
cha el. 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
po ible 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 pa 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 le asynchronous. Commands can be
i ued at any particular time (except when there is a pending
command, which will be discu ed below), and there is no need for
dummy traffic on a cha el when no commands are i ued.
A ociated with each command is a re o e. The purpose of this
December 1984
Proposed Host-Front End Protocol
re o e 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 succe fully executed, and if u ucce ful, the
reason. Often, generating the re o e involves interaction with the
protocol interpreter before a re o e can be generated.
When a command is i ued, the i uer must wait for a re o e before
another command is i ued. The nature of the communication between
the Host and the OPE is thus a lock step command/re o e dialog.
There are two major exceptio to this principle, however. One
exception is the abrupt form of the End command, which can be i ued
at any time to cancel any previously i ued 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 re o e would be undesirable.
Hence, a Signal command can be i ued while commands (other than
Signal) are pending. However, a Signal command should not be i ued
before a succe ful re o e to the Begin command has been received.
Since it is po ible for more than one command of different types to
be pending at one time, a mechanism to distinguish re o es is
needed. Since there are never two commands of the same type pending,
including the command name in the re o e is sufficient to make this
distinction.
A ecial case command is the Tra mit command. Details of the
Tra mit command are provided in the next section. E entially, the
Tra mit command is used to invoke the data tra fer services of the
off-loaded protocol (when i ued by the Host) or to indicate the
arrival of new data from the network (when i ued by the OPE). The
nature of ecific 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 ecial parameter which indicates the nature
of the Tra mit command interface. It can either require that the
re o e should be generated immediately after determining the
Tra mit command is complete and formed properly, or can indicate
that the re o e should not be generated until the a ropriate
interface event is given by the remote protocol interpreter. The
default action for all Tra mit commands can be initialized using the
Begin command and changed using the Condition command. Also, the
default action can be temporarily overridden by ecifying a
parameter with the Tra mit command. The net result of this mechanism
is to allow the Host to determine within reason just how lock-ste ed
tra mi io are to be. (It is a umed that the usual case will be
to tra fer the burden of buffering to the OPE by taking immediate
re o es, provided that doing so "makes se e" with the particular
offloaded protocol in play.)
December 1984
Proposed Host-Front End Protocol
Some protocols provide a block-oriented data tra fer service rather
than a stream-oriented one. With such a service, the data a ociated
with a tra fer request is viewed as an integral unit. For actual
network tra mi ion, 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 co ection protocols such as NBS TP.
To cater to these types of protocols, it is a convention that
commands, their parameters, and any a ociated data be tra ferred
between the Host and the OPE in a single chunk. Any data a ociated
with an H-FP command is viewed as an integral unit which is used in
the corre onding service request given to the outboard protocol
interpreter or delivered as a complete unit to the proce in the
Host. Operation of stream-oriented protocols such as TCP will not be
adversely affected by this convention.
To accommodate Cha el 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
tra fer the burden of buffering as much as po ible from the Host to
the OPE. The facility proposed here would co ist of an indication
at the begi ing 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 discu ed in the section on the syntax of commands and
re o es.
It is a convention for this H-FP that any data a ociated with a
command must start on a word boundary (as defined by the local
system). Co equently, there is a need to provide padding within the
commands. Such padding is used only to fill to the next a ropriate
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
discu ed in the section on the syntax of commands and re o es.
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 re o es. A command is a request for
some particular action, and the re o e indicates the succe or
failure of performing the requested action.
All commands and re o es 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 a roach 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 ecial characters.
Terminal Operation: Using simple command streams simplifies the
conversion of an OPE to a generic virtual terminal su ort machine.
This is particularly useful during development and testing.
Testing: Testing will not require ecial hardware to interpret
commands and re o es. A terminal or data line analyzer would be
adequate.
The ecific format for the commands and re o es will be discu ed
in the sectio that follow. In those sectio , 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 discu ing 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
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 corre onds to
the chunk usage identifier in each chunk, and the angle brackets
enclose a chunk) are legal:
while the following are not legal:
Tactics for handling multiple chunks with regard to OPE buffering
limits are left to the ingenuity of OPE builders. The irit is to
take as much as you can, in order to relieve the Host of the
nece ity of buffering itself.
A command always begi immediately following the indicator
character, with po ible intervening aces. 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 < l
in this document) that does not a ear i ide a quoted string (see
below). The end of the data is designated by the end of the last
Commands take the form of an ASCII string. The command identifier is
the first word of the chunk. It co ists of at least the first two
letters of the command, in either u er 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 ecific format will depend on the particular parameter. The data to
be tra mitted is not co idered a control parameter, however, and
need not be ASCII data.
Parameters are separated by one or more aces. Ta , newlines, and
other white ace are not legal parameter separators.
Parameter strings may be quoted, using the character ". Any
December 1984
Proposed Host-Front End Protocol
characters between the " characters are a part of the parameter,
including aces and newlines. The character " that is part of the
parameter is represented i ide a quoted string as "".
The order in which the parameters a ear within the command is
significant to their interpretation by the Host and by the OPE.
Optional parameters may be ski ed 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 a ociated with it that can be used to identify
the parameter, without placing NULL parameters for each parameter
ski ed. This flag co ists of one or two ASCII characters, and
either u er 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
command -P value
i tead of
command ,, ,, ,, value
if it were more convenient for the Host to do so. Flagged parameters
must still a ear in the correct sequence within the command,
however.
There may be data a ociated 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 aces between
the end of the final parameter string and the newline, so that data
begi on a word boundary. The OPE will always pad to a host word
boundary. Padding by hosts is optional.
Syntax of Re o es
Re o es are actually just a ecial form of a command. It is
anticipated that all re o es would fit into a single cha el chunk,
although the mechanisms described for multichunk commands can
certainly be used in re o es. The ASCII string used to uniquely
identify the re o e command is "RE" ("Re", "rE", and "re" are also
permitted).
After the re o e command identifier is the original command
December 1984
Proposed Host-Front End Protocol
identifier, so the re o e can be a ociated with the proper
command. Following this identifier is a three ASCII digit re o e
code, a set of protocol idiosyncratic parameters, and a textual
me age. The protocol idiosyncratic parameters are used to tra fer
interface information between the Host and the OPE, and may not be
needed when off-loading some protocol interpreters. The textual
me age is intended for human interpretation of the re o e codes,
and is not required by the protocol. The three digits uniquely
identify the semantics of the re o e, at least within the context
of a particular command and particular outboarded protocol
interpreter.
Re o es 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 Succe ful: The command was executed succe fully. The
re o e code may contain further information.
1XX Conditional Succe : The command was executed succe fully,
but not exactly according to the service and flow control
suggestio . If those suggestio were particularly important
to the requester, he may wish to i ue an End command. The
re o e code contai information on what suggestion or
suggestio 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 su orted, 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 addre .
4XX Off-loaded Protocol Interpreter Problems: Some problem with
the particular off-loaded protocol has occurred.
5XX Local OPE Internal Problems: Problems, such as i ufficient
OPE resources, or problems with OPE to su et interface.
6XX Security Problem: Some problem with Host, network, or OPE
security has occurred. The re o e code indicates the
problem.
December 1984
Proposed Host-Front End Protocol
7XX Reserved for Future Expa ion
8XX Reserved for Future Expa ion
9XX Protocol Idiosyncratic Errors: Some error occurred that is
idiosyncratic to the particular off-loaded protocol being
used. The re o e 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 re o es. Commands
may be i ued 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 re o e
indicates that the activity started by the command was completed, and
a code indicates succe or failure of the command, and perha other
information related to the command as well.
A ociated with each command is a set of parameters. The order in
which the parameters a ear is significant to the correct operation
of the protocols. More information on the syntax of command
parameters can be found in the syntax descriptio .
The commands are:
- Begin: initiate communication between a proce in the Host and
an off-loaded protocol interpreter in the OPE. (A Cha el level
stream/co ection will typically have been opened as a prior step.
All other commands, except No-op, a ly to a stream on which a
succe ful Begin has been done.)
- Tra mit: tra mit data between a proce 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: tra fer status requests or information between a
proce in the Host and an off-loaded protocol interpreter in the
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 discu ed in the following sectio . Each of
these sectio includes a discu ion of the purpose of the command, a
description of each of the parameters used with the command, a list
of re o es for the command, an example of the command, and a set of
notes for the implementor. (An a endix 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 a endices, with others to be added after the protocol
gai acceptance.)
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 cha el
(the cha el is opened as a separate step, of course). The
interpretation of the command is somewhat dependent upon
whether it was i ued by the Host of the OPE.
- If the command was i ued by the Host, it mea some proce 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 cha el co ection between the Host and the
OPE, and a Begin command to the Command interpreter in the OPE.
- If the command was i ued by the OPE, it mea some protocol
interpreter in the OPE has data for some proce 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 i ued at all by the Host. (An incoming TCP
co ection request could be handled by a re o e to the user's
Pa ive Open request, which had previously caused a Begin
request from the Host; an incoming TCP co ection request to a
port on which no Listen had been i ued would cause an OPE
generated Begin, however.)
As indicated earlier, any particular Host is not required to
su ort two-way Begi .
December 1984
Proposed Host-Front End Protocol
Parameters of the Begin Command
The Begin command has several parameters a ociated 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
addre es, and also type of service and flow control advice.
These parameters are discu ed in detail below.
Protocol
The protocol parameter identifies that off-loaded protocol in
the OPE to which Begin is directed, or which i ued 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 ecific. A generic parameter identifies a type of protocol
service required, but does not identify the actual protocol.
Use of generic protocols allows a Host proce to oBTain
network services without ecific knowledge of what protocol is
being used; this could be a ropriate for use in situatio where no ecific ASPect(s) of a ecific protocol is/are
required. For example, the user may select a generic
Host-to-Host co ection protocol, and (at some point in the
future) may actually receive services from either TCP or the
NBS Tra ort Protocol, depending on the network (or even the
foreign Host) in question. A ecific protocol parameter
identifies some particular protocol, e.g., TCP, whose use is
required for the given cha el.
The valid entries for the protocol field include:
Generic Specific Comment
GIP IP Datagram Internetwork Protocol
HHP TCP Co ection Tra ort/Host-Host Protocol
GDP UDP Datagram Tra ort/Host-Host Protocol
VTP TEL Virtual Terminal (Telnet) Protocol
GFP FTP File Tra fer Protocol
MAIL SMTP Mail Tra fer Protocol
PROX PROX Proximate Net Interface Protocol
(Note that the final line is meant to allow for a proce in an
OPE'd Host's getting at the PI of the Network Interface
Protocol for whatever the proximate network is. Of course, so
December 1984
Proposed Host-Front End Protocol
doing only makes se e in ecialized 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
impo ible 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 co ideratio would preclude
avoidance of IP even if technical co ideratio 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/Pa ive
The Active/Pa ive parameter indicates whether the i uer of
the Begin command desires to be the Active or Pa ive user of
the protocol. This parameter is particularly relevant to
co ection-oriented protocols such as TCP, where the user may
actively pursue co ection establishment, or else may pa ively
wait for the remote entity to actively establish the
co ectio it also allows some proce to establish itself as
the Host "fielder" of incoming traffic for a co ectionle protocol such as IP.
Active is requested using the single character "A". Pa ive is
indicated using the character "P". The default value of this
parameter is "A". Also, when the OPE i ues the Begin command,
the value must be "A". The control flag for this parameter is
Foreign Addre Primary Component
The addre ing structure su orted by H-FP is two level. Each
addre has two components, the primary and the secondary. The
exact interpretation of these two components is protocol ecific, but some generalities do a ly. The primary
component of the addre 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 addre component is the Host's
Internet Addre , while the secondary addre component is the
TCP port. Similarly, IP's primary addre component is the
Host's Internet Addre , and the secondary addre component is
the IP ULP field. Some protocols provide only a single level
December 1984
Proposed Host-Front End Protocol
of addre ing, 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
The Foreign Addre Primary Component parameter contai the
primary component of the destination addre . 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
a ropriate, as well as freeing the Host from the nece ity of
maintaining an in-board name to addre table.) The default
value for this parameter, although it only makes se e for
Pa ive Begi , 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 po ible decision. The ecific interpretation of this parameter is dependent upon the
particular off-loaded protocol.
The concept of mediation level can best be clarified by mea of example. A full i oard implementation of the Telnet
protocol places several re o ibilities on the Host. These
re o ibilities include negotiation and provision of protocol
optio , tra lation between local and network character codes
and formats, and monitoring the well-known socket for incoming
co ection requests. The mediation level indicates whether
these re o ibilities are a igned 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 optio , and all format conversio .
With full OPE mediation, all option negotiation and all format
conversio 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
optio 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
December 1984
Proposed Host-Front End Protocol
some protocols (e.g., the intermediate mediation level
discu ed above for Telnet). The default value for this
parameter is 9. The control flag for this parameter is -m.
Tra mit Re o e Discipline
The Tra mit Re o e Discipline parameter is used to set the
desired action on the OPE's part for generating re o es to
Tra mit commands. E entially the parameter determines when
the OPE's re o e to the tra mit command occurs (i.e.,
immediately or delayed).
The Tra mit Re o e Discipline value is represented by a
single ASCII character. The character "N" is used for
no locking Tra mit commands, which implies that re o es for
Tra mit commands should be generated as soon as the command
has been examined for correctne (i.e., that the syntax is
good and the parameters a ear reasonable). In other words,
the outboard protocol interpreter has the data in its queue,
but ha 't nece arily tra mitted it to the net. The
character "B" is used for blocking Tra mit commands, which
requests that the re o e not be generated until the protocol
interpreter has succe fully tra mitted the data (unle , of
course, the Tra mit command was badly formed). The default
value for this parameter is "N", or a no locking Tra mit
command. The control flag for this parameter is -tr.
(Depending on the protocol in play, "succe fully tra mitted"
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
pa ed from the OPE to the proximate net.)
Foreign Addre Secondary Component
The addre ing mechanisms su orted by this level of H-FP are
discu ed above. The Foreign Addre Secondary Component
parameter contai the value of the destination addre '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 expre ed either numerically or
symbolically. The control flag for this parameter is -fs.
(Note that it is intended to be "legal" to ecify 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 a lied to the stream, in the
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 Addre Secondary Component
The Local Addre Secondary Component parameter contai the
value of the local addre 's secondary component. (The primary
component is a umed 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 addre secondary component can
be expre ed either numerically or symbolically. The control
flag for this parameter is -ls.
Begin Timeout Interval
After a Begin command is i ued, a timer can be started. If
the activity requested ca ot be performed within some timed
interval, then the Begin command may expire. An expired Begin
command retur a re o e code indicating a Begin timeout
occurred. The Begin Timeout Interval parameter contai 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 contai information on
the service characteristics the user desires from the offloaded
protocol. Included in this parameter is the precedence of the
data tra fer, and also indication of whether high throughput,
fast re o e time, or low error rate is the primary goal.
The format of this parameter is a letter immediately (i.e. no
intervening aces) followed by a digit. The letter "T"
indicates that high throughput is desired. The letter "R"
indicates minimal re o e time is the goal. The letter "E"
indicates that low error rates are the goal. The letter "N"
indicates there are no ecial service requirements to be
conveyed. The digit immediately following the character
December 1984
Proposed Host-Front End Protocol
indicates the desired precedence level, with zero being the
lowest, and nine being the highest. The ecific
interpretation of this parameter is dependent on what service
optio are provided by the protocol. The default value of
this parameter is the lowest precedence (ROUTINE), and no ecial service requests. The control flag for this parameter
is -ts.
Flow Control Advice
The Flow Control Advice parameter contai information on the
flow characteristics desired by the user. Some a licatio such as file tra fer operate more efficiently if the data is
tra ferred in large pieces, while other, more interactive
a licatio 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
co ection-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 mea the data should be sent in relatively small blocks
(e.g., character or line oriented a licatio ), while a value
9 mea the data should be sent in relatively large blocks
(e.g., block or file oriented a licatio ). Other values
represent sizes between those extremes. The character "N"
indicates that no ecial 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 Addre Primary Component
This parameter contai the local addre primary component. It
is anticipated that under most circumstances, this component is
known to both the Host and the OPE. Co equently, this
parameter is seldom required. It would be useful if the Host
desired to select one of several valid addre es, 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
December 1984
Proposed Host-Front End Protocol
proce ing at system high level or at a single level.
Co equently, 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, unle otherwise ecified 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.
After the Protocol Idiosyncratic Parameters, if any, and the
required < l, if the protocol in play allows for it at this
juncture the rest of the chunk will be interpreted as data to
be tra mitted. That is, in co ection oriented protocols data
may or may not be permitted at co ection initiation time, but
in co ectionle protocols it certainly makes se e to allow
the H-FP Begin command to convey data. (This will also be
useful when we get to the Condition command.)
Re o es
The following re o es have been identified for the Begin
command:
000 Command completed succe fully
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 cha el
300 Problem with multiple chunks
301 Syntax problem with Begin command
302 Protocol not su orted in OPE/Host
303 Active service not available
December 1984
Proposed Host-Front End Protocol
304 Pa ive service not available
305 Invalid Foreign Addre Primary Component
306 Invalid Tra mit Discipline
307 Invalid Foreign Addre Secondary Component
308 Invalid Local Addre Secondary Component
309 Invalid Timeout Interval
310 Invalid Type of Service Advice
311 Invalid Flow control Advice
312 Invalid Local Addre Primary Component
401 Protocol Interpreter in OPE not re onding
402 Remote Protocol Interpreter not available
403 Failed; i ufficient protocol interpreter resources
501 Failed; i ufficient OPE resources
601 Request violates security policy
602 Security parameter problem
Additionally, protocol idiosyncratic re o es 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 co ectio . One po ible example of a
Begin command i ued by an i oard Telnet interpreter to open a
TCP co ection to ISIA, with no begin timeout interval, is:
C BE TCP A ISIA 9 N 23 ,, ,, N0 S < l
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 tra mit
23 Destination Telnet Port
,, skip over parameters (Local Addre Secondary,
Begin Timeout Interval)
N0 Type of Service Advice: No ecial Advice,
Normal Precedence
S Flow Control Advice: use small blocks
This command will cause the OPE to invoke the TCP interpreter
to generate the initial SYN packet to the well-known Telnet
socket on Host ISIA. It also informs the OPE to do all TCP
related proce ing via the Mediation Level, accepts default
December 1984
Proposed Host-Front End Protocol
Local Addre parameters, and sets the Begin Timeout Interval
to infinity. The precedence of the TCP co ection is Normal,
and the TCP interpreter is informed that the data stream will
co ist of primarily small blocks.
Notes to the Implementor
Re o e 203 might seem silly to some readers, but it's there
in case somebody goofed in using the Cha el Layer.
Tra mit
Purpose of the Tra mit Command
The purpose of the Tra mit command is to permit the proce in
the Host to send data using an off-loaded protocol interpreter
in the OPE, and also to permit the OPE to deliver data received
from the network destined for the proce in the Host. The
Tra mit command is particularly relevant to co ection and
stream type protocols, although it has a licatio for
co ectionle protocols as well. After the Begin command is
i ued succe fully and the proper Re o e received, Tra mit
commands can be i ued on the given cha el. The semantics of
the Tra mit command depend on whether it was i ued by the
Host or the OPE.
- If the Host i ues the Tra mit command, a proce in the
Host wishes to send the data to the destination ecified to
the off-loaded protocol interpreter that was established
(typically) by a previous Begin command on the given H-FP
cha el.
- If the OPE i ues the command, the OPE has received data
destined for a proce in the Host from a co ection or stream
su orted by the off-loaded protocol that was established by a
previous Begin command on the given H-FP cha el.
Parameters of the Tra mit Command
The Tra mit command has one parameter a ociated with it. It
is an optional parameter, to temporarily override the re o e
discipline for this particular tra mit command. Some protocols
may have protocol-idiosyncratic parameters as well. The
tra mit command also has data a ociated with it. All
parameters must precede the data to be tra mitted.
December 1984
Proposed Host-Front End Protocol
Re o e Discipline Override
The Re o e Discipline Override parameter indicates the
desired re o e discipline for that individual Tra mit
Command, overriding the default re o e discipline. A single
ASCII character is used to indicate the desired discipline.
The character "N" indicates that this Tra mit command should
not block, and should return a re o e as soon as the data is
given to the protocol interpreter in the OPE. The character "B"
indicates that this Tra mit command should block, meaning that
a re o e should not be generated until the data has been sent
to the destination. The default value of this parameter is the
currently defined Tra mit Command re o e discipline. The
use of this parameter does not alter the currently defined
Tra mit command re o e discipline; the default is changed
with the Condition command. The control flag for this
parameter is -rd.
Protocol-Idiosyncratic Parameters
Any other parameters to the Tra mit command are
protocol-idiosyncratic. That is, each protocol that is
off-loaded has a set of these parameters, which are documented
with a description of the off-loaded protocol. The default
value for these parameters is NULL, unle otherwise ecified
by a particular off-loaded 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.
Re o es
The following re o es for the Tra mit command have been
identified:
000 Tra mit Command completed succe fully
201 Tra mit Command not a ropriate
300 Problem with multiple chunks
301 Syntax problem with Tra mit Command
302 Invalid Tra mit Command Re o e Discipline
401 Protocol Interpreter in OPE not re onding
402 Failure in remote protocol interpreter
403 Failed; i ufficient protocol interpreter resources
501 Failed; i ufficient OPE resources
601 Request violates security policy
December 1984
Proposed Host-Front End Protocol
Additionally, protocol-idiosyncratic re o es will be defined
for each off-loaded protocol.
Example of Tra mit Command
The tra mit command is used in TCP to provide the TCP write
call. An example of such a tra mit command would be:
C TR N < l DATA
Where N indicates non-blocking tra mi ion discipline, < l is
the required command-ending newline, and DATA is presumed to
be the user's data that is to be tra mitted.
Notes to the Implementor
If you get a 403 or a 501 re o e and have sent a multiple
chunk it probably makes se e to try a single chunk; if you've
sent a single chunk, it makes se e to wait a while and try
again a few times before giving up on the stream/cha el.
Condition
Purpose of the Condition Command
The primary purpose of the Condition command is to permit a
proce to alter the characteristics that were originally set
up with the Begin command. (That is, "condition" is a verb.)
These characteristics include the addre es, the mediation
level, the type of service, and the flow control parameters
from Begin. They may also include protocol-idiosyncratic
characteristics. (Although Condition is usually thought of as a
Host-OPE command, it may also be used OPE-Host in some
contexts.)
Condition is a generic command that may find little use in some
off-loaded protocols. In others, only some of the parameters
identified may make se e. For example, changing the
destination addre of a TCP co ection involves closing one
co ection and opening another. Co equently, in may make more
se e to first i ue an End command, and then a Begin with the
new addre . In other protocols, such as IP or UDP, changing
the addre on each datagram would be a perfectly reasonable
thing to do.
December 1984
Proposed Host-Front End Protocol
Parameters of the Condition Command
The Condition command has the same parameters as the Begin
command. Any parameters expre ed in a Condition command
indicate the new values of the characteristics to be altered;
all parameters not expre ed retain the current value.
Although it is po ible to expre the change of any of the
characteristics originally set up in the Begin command using
the Condition command, there are some characteristics that do
not make se e to alter, at least for some protocols. For
example, once a co ection is opened, it does not make much
se e to change the Foreign Addre Primary or Secondary
Components. Doing so is inco istent with current versio of
TCP, and would require the closing of the existing co ection
and opening a new one to another addre . Earlier versio of
TCP did permit co ectio to be moved. If a protocol that
provided such a feature was implemented in the OPE, the
changing the Secondary Addre Components would be a reasonable
thing to do.
Re o es
The re o es to the Condition command are the same as those to
the Begin command.
Example of Condition Command
The Condition Command can be quite complex, and can be used for
many purposes. One conceived use of the condition command
would be to change the type of service advice a ociated with
the cha el. An example of this (which also demo trates the
ability to skip parameters) is:
C -ts T < l
which causes the offloaded PI a ociated with the current
cha el to attempt to achieve high throughput (in its use of
the comm su et(s) in play).
Notes to the Implementor
December 1984
Proposed Host-Front End Protocol
Purpose of Signal Command
The purpose of the Signal Command (implicitly at least) is to
permit the tra fer of out-of-band signals or information
between the Host and the OPE, in order to utilize (explicitly)
out-of-band signaling services of the off-loaded protocol. The
semantics of the Signal command depend upon whether it was
i ued by the Host or the OPE.
- If the Signal command was i ued by the Host, it mea a
proce in the Host desires to send out-of-band data or an
out-of-band signal.
- If the Signal command was i ued by the OPE, it mea out-of-band data or an out-of-band signal arrived for the
proce a ociated with the cha el in the Host.
Parameters of the Signal Command
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 Tra ort Protocol, permit the
user to send data with the out-of-band signal. Hence, data is
permitted to accompany the Signal command. There may also be
protocol-idiosyncratic parameters for the Signal command. If
this is the case, these parameters would come before the data.
Protocol-Idiosyncratic Parameters
The parameters for the Signal command are protocol
idiosyncratic. That is, each protocol off-loaded has a set of
these parameters. The default value for these parameters is
their previous values. Control flags for multiple
protocol-idiosyncratic parameters must be defined for each
off-loaded protocol.
Re o es
The following re o es have been identified for the Signal
command:
000 Command completed succe fully
201 Command not a ropriate
300 Problem with multiple chunks
301 Syntax problem with Command
December 1984
Proposed Host-Front End Protocol
401 Protocol Interpreter in OPE not re onding
402 Failure in remote protocol interpreter
403 Failed; i ufficient protocol interpreter resources
501 Failed; i ufficient OPE resources
601 Request violates security policy
Additionally, protocol-idiosyncratic re o es will be defined
for each off-loaded protocol.
Example of Signal Command
The major perceived use for the Signal command when offloading
a co ection protocol is sending an out-of-band signal with no
data. In such a case, the a ropriate signal command would be:
C SI < l
Notes to the Implementor
Some protocols may allow only only one outstanding signal at a
time. For these protocols, it is an implementation i ue
whether the OPE will buffer several signals, but a good case
could be made for the position that a scrupulous OPE would
reflect a 202 re o e back to the Host in such cases.
There is some question as to the proper handling of the
"expedited data" notion of some (particularly ISO) protocols.
It might be more a ropriate to deal with such a thing as a
protocol idiosyncratic parameter on the Tra mit command
i tead of using the Signal command (even if it's the closest
a roximation to an out-of-band signal in the given protocol).
If it's provided using the Signal command, the expedited data
should not be pa ed as ASCII, and should a ear after the
command-terminating newline character (and a ropriate padding
with ace characters).
Purpose of Status Command
The purpose of the Status command is to permit the Host to
request and obtain status information from the OPE, and vice
versa. This includes status request of a conventional protocol
interface (e.g., in TCP, there is a request to determine the
state of a particular co ection).
December 1984
Proposed Host-Front End Protocol
Parameters of the Status Command
The parameters for the Status command indicate whether it is a
request or a re o e, and contain the status information.
Request/Report
This parameter indicates whether the command is a Status
request or a Status report. It co ists of a single ASCII
character. Q indicates a request (query), and R indicates a
report. It should be noted that a report may be generated
as the result of a query, or may be generated as the result
of ecific protocol mechanisms.
Protocol-Idiosyncratic Parameters
The parameters to the status command are
protocol-idiosyncratic. That is, each protocol off-loaded has a
set of these parameters. The default value for these
parameters is their previous values. Among these parameters is
an identifier of the type of status information contained or
requested, and a value or set of values that contain the
particular status information. The status information itself
should be the last item in the command. 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.
Re o es
The following re o es have been identified for the Status
command:
000 Command completed succe fully
201 Command not a ropriate
300 Problem with multiple chunks
301 Syntax problem with Command
302 Ina ropriate status request
303 Ina ropriate status re o e
401 Protocol Interpreter in OPE not re onding
402 Failure in remote protocol interpreter
403 Failed; i ufficient protocol interpreter resources
501 Failed; i ufficient OPE resources
601 Request violates security policy
9xx Protocol Idiosyncratic status re o es
December 1984
Proposed Host-Front End Protocol
Example of Status Command
The status command can be particularly complex, depending on
the protocol and particular type of status information. One
po ible use of the status command when off-loading TCP is to
communicate the status service request. For performing this
operation the status command would be:
C ST Q < l
Notes to the Implementor
Purpose of the End Command
The purpose of the End command is to communicate that services
of the off-loaded protocol are not required. The semantics of
the End command depends upon whether it was i ued by the Host
or the OPE.
- If the Host i ues the End command, it mea the proce in
the Host no longer requires the services of the offloaded
protocol.
- If the OPE i ues the End command, it mea the remote entity
has no more data to send (e.g., the off-loaded protocol is TCP
and the remote user has i ued a TCP close).
Parameters of the End Command
One parameter is a ociated with the End Command. It indicates
whether the termination should be "graceful" or "abrupt" (see
below).
Graceful/Abrupt
The Graceful/Abrupt parameter indicates whether the End
should be handled gracefully or abruptly. If it is handled
gracefully, then data in tra it is allowed to reach its
destination before service is actually terminated. An
abrupt End occurs immediately; all data tra mitted from the
Host but still pending in the OPE is discarded, and no new
incoming data is sent to the Host from the OPE.
December 1984
Proposed Host-Front End Protocol
The parameter is indicated by a single ASCII character. The
character "G" denotes graceful, and "A" denotes abrupt. The
default value for this parameter is graceful.
Re o es
The following re o es have been identified for the End
command:
000 Command completed succe fully
201 Command not a ropriate
300 Problem with multiple chunks
301 Syntax problem with Command
302 Illegal Type of End Command
401 Protocol Interpreter in OPE not re onding
402 Failure in remote protocol interpreter
403 Failed; i ufficient protocol interpreter resources
501 Failed; i ufficient OPE resources
601 Request violates security policy
Additionally, protocol idiosyncratic re o es will be defined
for each off-loaded protocol.
Example of End Command
The syntax of the End command is relatively straightforward. It
co ists of a chunk that contai only a chunk usage
identifier, the end command string, and the parameter
indicating whether the end should be graceful or abrupt. A
po ible valid (abrupt) End command would be:
C EN A < l
Notes to the Implementor
Once an End has been i ued in a given direction any other
commands on the cha el in the same direction are in error and
should be re onded to a ropriately.
December 1984
Proposed Host-Front End Protocol
Purpose of the No-op Command
The No-op command performs no operation. Its purpose is to
permit the Host and OPE to participate in a dialog which does
not alter the state of communication activities, both for
debugging purposes and to su ort features of certain protocols
(e.g., Telnet's Are You There command).
Parameters of the No-op Command
There are no parameters a ociated with the No-op command.
Re o es
There are only two po ible legal re o es to the No-op
command. They are:
000 No-op Command Completed Correctly
300 Problem with multiple chunks
Example of No-op Command
Syntactically the No-op command is quite simple. It co ists
of a chunk that contai only the chunk usage identifier and
the string for the command, and the newline. One po ible
valid No-op command is:
C NO < l
Notes to the Implementor
No-o are included for use in testing and initial
synchronization. (The latter use is not mandatory, however.
That is, no exchange of No-o is required at start-up time,
but it is conceivable that some implementatio might want to
do it just for exercise.) They are also traditional.
December 1984
Proposed Host-Front End Protocol
References
(References [1]-[3] will be available in M. A. Padli ky's "The
Elements of Networking Style", Prentice Hall, 1985.)
[1] Padli ky, M. A., "The Host-Front End Protocol A roach",
MTR-3996, Vol. III, MITRE Corp., 1980.
[2] Padli ky, M. A., "The Elements of Networking Style", M81-41,
MITRE Corp., 1981.
[3] Padli ky, M. A., "A Per ective on the ARPANET Reference Model",
M82-47, MITRE Corp., 1982.
[4] Bailey, G., "Network Acce Protocol", S-216,718, National
Security Agency Central Security Service, 1982.
[5] Day, J. D., G. R. Gro man, and R. H. Howe, "WWMCCS Host to Front
End Protocol", 78012.C-INFE.14, Digital Technology Incorporated,
December 1984
Proposed Host-Front End Protocol
APPENDIX
Per-Protocol Offloading Descriptio 1. Command Level Interface to an Off-loaded TCP
This a endix discu es the use of the commands described in the
body of this document to provide an interface between a Host
proce and an off-loaded interpreter of the DoD's Tra mi ion
Control Protocol (TCP). The interface described here is
functionally equivalent to the interface found in the MIL-STD 1778 ecification of TCP. It is not, however, identical, in that some
features of the interface are particularly relevant only in an
i oard implementation.
The first section describes the ma ing between the interface
events of MIL-STD 1778 and the commands and re o es of this
H-FP, and highlights the unique features of the interface. The
next sectio discu the details of each command. These details
include the ecialized usages of the command and the
protocol-idiosyncratic parameters for that command.
1.1. Relation to MIL-STD 1778 Interface
Most of the requests and re o es of the TCP interface ecified in MIL-STD 1778 are ma ed directly to H-FP Commands
and re o es. The exceptio are noted in the following
descriptio .
1.1.1. Requests
U ecified Pa ive Open, Fully Specified Pa ive Open,
Active Open, and Active Open with Data requests are all
implemented using variatio of the Begin command. The
distinction between Pa ive and Active Open is made using
the Active/Pa ive parameter of Begin. The distinction
between u ecified and fully ecified lies in the presence
or a ence of the destination addre fields. An active
open with data is identical to a normal active open, except
for the presence of data following the command.
The Send Service Request is implemented using the Tra mit
command. Special protocol idiosyncratic parameters are
provided for Urgent, Push, and changing the ULP timeout
action and values. The re o e to the Tra mit command
indicates that the a ropriate Send call has been made.
December 1984
Proposed Host-Front End Protocol
There is no corre onding re o e in the ecified TCP
interface; its only significance is that the Host can i ue
another Tra mit command.
The Allocate event is a ecification feature of MIL-STD
1778 to indicate the willingne of the user to accept
incoming data acro the interface. However, because this
is precisely the type of flow control provided by the
Cha el level, the Allocate event would be a superfluous
mechanism. Thus, there is no direct analogy to that event
in the H-FP interface. A Host proce indicates its
willingne to accept new data by informing the cha el via
its flow control interface (if it has an explicit one).
Close and Abort are provided by the End command. Close uses
the graceful version of the End command, while Abort uses
the abrupt version. The re o e indicates that the End
command has been received and the corre onding Close or
Abort was i ued. There is no corre onding re o e in the ecified TCP interface.
Status is provided by using the query form of the Status
command. The re o e to the Status command contai the
information (see below).
1.1.2. Re o es
The Open Id re o e is provided so that the user has a
shorthand name by which to refer to the co ection. With an
outboarded TCP interpreter, there is a one-to-one ma ing
between TCP co ectio and H-FP cha els. Hence, the Open
Id event is not needed, since the c