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 processing via the Mediation Level, accepts default
RFC929 December 1984
Proposed Host-Front End Protocol
Local Address parameters, and sets the Begin Timeout Interval
to infinity. The precedence of the TCP connection is Normal,
and the TCP interpreter is informed that the data stream will
consist of primarily small blocks.
Notes to the Implementor
Response 203 might seem silly to some readers, but it's there
in case somebody goofed in using the Channel Layer.
Transmit
Purpose of the Transmit Command
The purpose of the Transmit command is to permit the process 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 process in the Host. The
Transmit command is particularly relevant to connection and
stream type protocols, although it has applications for
connectionless protocols as well. After the Begin command is
issued successfully and the proper Response received, Transmit
commands can be issued on the given channel. The semantics of
the Transmit command depend on whether it was issued by the
Host or the OPE.
- If the Host issues the Transmit command, a process in the
Host wishes to send the data to the destination specified to
the off-loaded protocol interpreter that was established
(typically) by a previous Begin command on the given H-FP
channel.
- If the OPE issues the command, the OPE has received data
destined for a process in the Host from a connection or stream
supported by the off-loaded protocol that was established by a
previous Begin command on the given H-FP channel.
Parameters of the Transmit Command
The Transmit command has one parameter associated with it. It
is an optional parameter, to temporarily override the response
discipline for this particular transmit command. Some protocols
may have protocol-idiosyncratic parameters as well. The
transmit command also has data associated with it. All
parameters must precede the data to be transmitted.
RFC929 December 1984
Proposed Host-Front End Protocol
Response Discipline Override
The Response Discipline Override parameter indicates the
desired response discipline for that individual Transmit
Command, overriding the default response discipline. A single
ASCII character is used to indicate the desired discipline.
The character "N" indicates that this Transmit command should
not block, and should return a response as soon as the data is
given to the protocol interpreter in the OPE. The character "B"
indicates that this Transmit command should block, meaning that
a response should not be generated until the data has been sent
to the destination. The default value of this parameter is the
currently defined Transmit Command response discipline. The
use of this parameter does not alter the currently defined
Transmit command response 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 Transmit 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, unless otherwise specified
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.
Responses
The following responses for the Transmit command have been
identified:
000 Transmit Command completed successfully
201 Transmit Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Transmit Command
302 Invalid Transmit Command Response Discipline
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
RFC929 December 1984
Proposed Host-Front End Protocol
Additionally, protocol-idiosyncratic responses will be defined
for each off-loaded protocol.
Example of Transmit Command
The transmit command is used in TCP to provide the TCP write
call. An example of such a transmit command would be:
C TR N <nl> <DATA>
Where N indicates non-blocking transmission discipline, <nl> is
the required command-ending newline, and <DATA> is presumed to
be the user's data that is to be transmitted.
Notes to the Implementor
If you get a 403 or a 501 response and have sent a multiple
chunk it probably makes sense to try a single chunk; if you've
sent a single chunk, it makes sense to wait a while and try
again a few times before giving up on the stream/channel.
Condition
Purpose of the Condition Command
The primary purpose of the Condition command is to permit a
process to alter the characteristics that were originally set
up with the Begin command. (That is, "condition" is a verb.)
These characteristics include the addresses, 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 sense. For example, changing the
destination address of a TCP connection involves closing one
connection and opening another. Consequently, in may make more
sense to first issue an End command, and then a Begin with the
new address. In other protocols, such as IP or UDP, changing
the address on each datagram would be a perfectly reasonable
thing to do.
RFC929 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 expressed in a Condition command
indicate the new values of the characteristics to be altered;
all parameters not expressed retain the current value.
Although it is possible to express the change of any of the
characteristics originally set up in the Begin command using
the Condition command, there are some characteristics that do
not make sense to alter, at least for some protocols. For
example, once a connection is opened, it does not make much
sense to change the Foreign Address Primary or Secondary
Components. Doing so is inconsistent with current versions of
TCP, and would require the closing of the existing connection
and opening a new one to another address. Earlier versions of
TCP did permit connections to be moved. If a protocol that
provided such a feature was implemented in the OPE, the
changing the Secondary Address Components would be a reasonable
thing to do.
Responses
The responses 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 associated with
the channel. An example of this (which also demonstrates the
ability to skip parameters) is:
C -ts T <nl>
which causes the offloaded PI associated with the current
channel to attempt to achieve high throughput (in its use of
the comm subnet(s) in play).
Notes to the Implementor
RFC929 December 1984
Proposed Host-Front End Protocol
Signal
Purpose of Signal Command
The purpose of the Signal Command (implicitly at least) is to
permit the transfer 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
issued by the Host or the OPE.
- If the Signal command was issued by the Host, it means a
process in the Host desires to send out-of-band data or an
out-of-band signal.
- If the Signal command was issued by the OPE, it means
out-of-band data or an out-of-band signal arrived for the
process associated with the channel 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 Transport 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.
Responses
The following responses have been identified for the Signal
command:
000 Command completed successfully
201 Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Command
RFC929 December 1984
Proposed Host-Front End Protocol
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
Additionally, protocol-idiosyncratic responses will be defined
for each off-loaded protocol.
Example of Signal Command
The major perceived use for the Signal command when offloading
a connection protocol is sending an out-of-band signal with no
data. In such a case, the appropriate signal command would be:
C SI <nl>
Notes to the Implementor
Some protocols may allow only only one outstanding signal at a
time. For these protocols, it is an implementation issue
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 response 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 appropriate to deal with such a thing as a
protocol idiosyncratic parameter on the Transmit command
instead of using the Signal command (even if it's the closest
approximation to an out-of-band signal in the given protocol).
If it's provided using the Signal command, the expedited data
should not be passed as ASCII, and should appear after the
command-terminating newline character (and appropriate padding
with space characters).
Status
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 connection).
RFC929 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 response, and contain the status information.
Request/Report
This parameter indicates whether the command is a Status
request or a Status report. It consists 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 specific 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.
Responses
The following responses have been identified for the Status
command:
000 Command completed successfully
201 Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Command
302 Inappropriate status request
303 Inappropriate status response
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
9xx Protocol Idiosyncratic status responses
RFC929 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
possible 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 <nl>
Notes to the Implementor
End
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 issued by the Host
or the OPE.
- If the Host issues the End command, it means the process in
the Host no longer requires the services of the offloaded
protocol.
- If the OPE issues the End command, it means the remote entity
has no more data to send (e.g., the off-loaded protocol is TCP
and the remote user has issued a TCP close).
Parameters of the End Command
One parameter is associated 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 transit is allowed to reach its
destination before service is actually terminated. An
abrupt End occurs immediately; all data transmitted from the
Host but still pending in the OPE is discarded, and no new
incoming data is sent to the Host from the OPE.
RFC929 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.
Responses
The following responses have been identified for the End
command:
000 Command completed successfully
201 Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Command
302 Illegal Type of End Command
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
Additionally, protocol idiosyncratic responses will be defined
for each off-loaded protocol.
Example of End Command
The syntax of the End command is relatively straightforward. It
consists of a chunk that contains only a chunk usage
identifier, the end command string, and the parameter
indicating whether the end should be graceful or abrupt. A
possible valid (abrupt) End command would be:
C EN A <nl>
Notes to the Implementor
Once an End has been issued in a given direction any other
commands on the channel in the same direction are in error and
should be responded to appropriately.
RFC929 December 1984
Proposed Host-Front End Protocol
No-op
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 support features of certain protocols
(e.g., Telnet's Are You There command).
Parameters of the No-op Command
There are no parameters associated with the No-op command.
Responses
There are only two possible legal responses 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 consists
of a chunk that contains only the chunk usage identifier and
the string for the command, and the newline. One possible
valid No-op command is:
C NO <nl>
Notes to the Implementor
No-ops are included for use in testing and initial
synchronization. (The latter use is not mandatory, however.
That is, no exchange of No-ops is required at start-up time,
but it is conceivable that some implementations might want to
do it just for exercise.) They are also traditional.
RFC929 December 1984
Proposed Host-Front End Protocol
References
(References [1]-[3] will be available in M. A. Padlipsky's "The
Elements of Networking Style", Prentice Hall, 1985.)
[1] Padlipsky, M. A., "The Host-Front End Protocol Approach",
MTR-3996, Vol. III, MITRE Corp., 1980.
[2] Padlipsky, M. A., "The Elements of Networking Style", M81-41,
MITRE Corp., 1981.
[3] Padlipsky, M. A., "A Perspective on the ARPANET Reference Model",
M82-47, MITRE Corp., 1982.
[4] Bailey, G., "Network Access Protocol", S-216,718, National
Security Agency Central Security Service, 1982.
[5] Day, J. D., G. R. Grossman, and R. H. Howe, "WWMCCS Host to Front
End Protocol", 78012.C-INFE.14, Digital Technology Incorporated,
1979.
RFC929 December 1984
Proposed Host-Front End Protocol
APPENDIX
Per-Protocol Offloading Descriptions
1. Command Level Interface to an Off-loaded TCP
This appendix discusses the use of the commands described in the
body of this document to provide an interface between a Host
process and an off-loaded interpreter of the DoD's Transmission
Control Protocol (TCP). The interface described here is
functionally equivalent to the interface found in the MIL-STD 1778
specification of TCP. It is not, however, identical, in that some
features of the interface are particularly relevant only in an
inboard implementation.
The first section describes the mapping between the interface
events of MIL-STD 1778 and the commands and responses of this
H-FP, and highlights the unique features of the interface. The
next sections discuss the details of each command. These details
include the specialized 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 responses of the TCP interface
specified in MIL-STD 1778 are mapped directly to H-FP Commands
and responses. The exceptions are noted in the following
descriptions.
1.1.1. Requests
Unspecified Passive Open, Fully Specified Passive Open,
Active Open, and Active Open with Data requests are all
implemented using variations of the Begin command. The
distinction between Passive and Active Open is made using
the Active/Passive parameter of Begin. The distinction
between unspecified and fully specified lies in the presence
or absence of the destination address 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 Transmit
command. Special protocol idiosyncratic parameters are
provided for Urgent, Push, and changing the ULP timeout
action and values. The response to the Transmit command
indicates that the appropriate Send call has been made.
RFC929 December 1984
Proposed Host-Front End Protocol
There is no corresponding response in the specified TCP
interface; its only significance is that the Host can issue
another Transmit command.
The Allocate event is a specification feature of MIL-STD
1778 to indicate the willingness of the user to accept
incoming data across the interface. However, because this
is precisely the type of flow control provided by the
Channel 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 process indicates its
willingness to accept new data by informing the channel 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 response indicates that the End
command has been received and the corresponding Close or
Abort was issued. There is no corresponding response in the
specified TCP interface.
Status is provided by using the query form of the Status
command. The response to the Status command contains the
information (see below).
1.1.2. Responses
The Open Id response is provided so that the user has a
shorthand name by which to refer to the connection. With an
outboarded TCP interpreter, there is a one-to-one mapping
between TCP connections and H-FP channels. Hence, the Open
Id event is not needed, since the channel ID is sufficient
to indicate the desired connection.
The Open Failure and Open Success responses are provided
using OPE-generated responses to Begin commands (which
provide the Active and Passive Service response primitives)
issued by the Host. The value of the response code
indicates whether the Begin command succeeded or failed, and
can be mapped to the appropriate Open Failure or Open
Success indication by the Host.
Deliver is provided by having the OPE issue a Transmit
command. As mentioned above, the "flow control" between the
TCP interpreter and the Host is provided by the Channel
layer, so no explicit interface events are needed. The
RFC929 December 1984
Proposed Host-Front End Protocol
response to the Transmit command indicates the data was
received by the Host process. There is no corresponding
response in the specified TCP interface.
The Closing and Terminate service responses are provided
using the End command. Closing is indicated using the
graceful version of the command, while terminate is provided
using the abrupt version. The response indicates the End
command was received by the Host process. There is no
corresponding response in the specified TCP interface.
Status Response is provided by a response to the query
version of the Status command. The status information is
communicated via protocol-idiosyncratic parameters following
the Response code.
Error messages are reported using the spontaneously
generated version of the Status command issued by the OPE.
The error message is provided in a parameter. The response
indicates the error message was received by the Host
process. There is no corresponding event in the specified
TCP interface.
1.2. The Begin Command
The Begin command is used in TCP in three major ways:
1. To inform the OPE that a process in the Host wishes to
open a connection to a particular port on a internet
address.
2. To inform the OPE that a process in the Host wishes to be
informed when a connection attempt is made to any or to a
specific port at this Host's internet address.
3. To inform the Host that a connection attempt to the OPE
has arrived, and there was no Begin of the second type
(passive open) issued by the Host relevant to that
particular port.
1.2.1. Specialized Usage
There are four major aspects to the specialized usage of the
Begin command and its parameters. These parameters are:
1. The meaning of the Mediation Level parameter
RFC929 December 1984
Proposed Host-Front End Protocol
2. The selection of blocking treatment of Transmit
command
3. The meaning of the address components
4. The selection of the TCP Active Open with Data
primitive.
The Mediation Level parameter has only two possible values
when offloading TCP. These are "9" and "0". The normal
usage of an off-loaded TCP uses the value "9", which means
the Host is in no way involved in the operation of TCP. The
value "0" indicates the Host wishes to negotiate with the
TCP options.
The normal TCP Send event is non-blocking. That is, when a
user issues the send command, it counts on the reliability
services of TCP, and is not explicitly notified when the
data has reached the other end of the connection and been
properly acknowledged. Hence, the default value for this
parameter with TCP is "N". There are some applications
where the user may not wish to receive a response to a
Transmit command until the data has been acknowledged by the
other end of the connection. In these cases, the value "B"
should be used for this parameter. If such a feature is not
supported by the offloaded TCP interpreter, then it is
acceptable to issue a 100 level Conditional acceptance
indicating that blocking is not supported, but the Begin
command will proceed using non-blocking Transmits.
The primary address components of the local and remote
addresses refer to the internet addresses of (or a symbolic
Host name for) the respective Hosts. The secondary
components refer to the particular sockets at those internet
addresses. Normally, the secondary components (ports) are
specified numerically. They may, however, be specified by
name if the port is a well-known service port. In an Active
Begin command, the remote addresses primary and secondary
components must be specified. The local address components
need not be specified, unless the user wishes to indicate
that the connection should be from a particular port or a
particular internet address of a multi-homed Host. In a
Passive Begin command, the remote addresses are specified
only if connection attempts from one particular Host are of
interest. The local address secondary component must be
used to indicate on which port to perform the Listen.
RFC929 December 1984
Proposed Host-Front End Protocol
The way the TCP Active Open with data is provided is by
including the data with the Begin Command. This data is
included in the same Channel level chunk, immediately
following the newline. If the data is more than a single
chunk can hold, then the multi-chunk command feature of the
H-FP must be used.
1.2.2. Protocol-Idiosyncratic Parameters
The protocol-idiosyncratic parameter identified for the TCP
interface is the "ULP timeout" information. This
information includes whether the offloaded interpreter
should abort the connection on a ULP timeout or report it to
the inboard user, and also the numerical value of the
timeout interval. The format chosen for this parameter is a
single letter followed immediately (with no spaces) by an
ASCII number. The letter can be either "R" or "A", and
indicates that the ULP timeout should cause a report or an
abort, respectively. The number is interpreted to be the
timeout interval in seconds.
1.2.3. Examples of the Command
An example of an Active Begin command that might be issued
by an inboard user Telnet is:
C BE TCP A ISIA 9 N 23 ,, 60 R 0 -pi R120 <nl>
ISIA is the destination Host, 23 is the well-known port
number for Telnet connections, a Begin timeout of 60 seconds
was chosen. The desired type of service is to strive for
good response time, the transmissions are expected to be in
small units, and protocol-idiosyncratic parameter R120
implies that a ULP timeout of 120 seconds should be
reported.
An example of a Passive Begin Command that might be issued
by an inboard server Telnet is:
C BE TCP P ,, 9 N ,, 23 ,, R 0 -pi R120 <nl>
The major differences are that no remote address components
are specified, and the local secondary address component is
identified as the socket on which the Listen is being
performed. Also, the default ("infinite") timeout is taken.
RFC929 December 1984
Proposed Host-Front End Protocol
1.3. The Transmit Command
The Transmit command is used by the Host process to instruct
the off-loaded TCP interpreter to send data to a remote site
via the TCP connection associated with the command's channel.
It is used by the OPE to deliver incoming data from the
connection to the process in the Host.
1.3.1. Specialized Usage
The Transmit command must be capable of providing all the
specialized features of the Send and Deliver Event. These
special features are Urgent, Push, and modification of the
ULP Timeout action and/or interval.
Urgent is a means to communicate that some point upcoming in
the data stream has been marked as URGENT by the sender.
While the actual Urgent bit travels through the connection
out-of-band, it carries a pointer that is related to the
sequence numbers of the in-band communication. Hence, the
urgency must be indicated in the Transmit command rather
than the Signal command.
Push is a feature of the TCP Send Event that is used to
indicate that the data in the Transmit command should be
sent immediately (within the flow control constraints),
rather than waiting for additional send commands or a
timeout. Push is indicated in the Transmit Command. The
push feature has the same meaning when sent from the OPE to
the Host. If the Host implementation does no internal
queuing, the flag has no meaning.
The TCP Send event permits the user to modify the "ULP
timeout action" and/or the "ULP timeout interval" associated
with that connection. When changed, the new values take
effect for the remainder of the connection, unless changed
later with another Send. This feature is provided in this
H-FP using the Transmit Command.
1.3.2. Protocol-Idiosyncratic Parameters
The three features identified above are provided using
protocol-idiosyncratic parameters.
The first such parameter is the Urgent parameter. From the
point of view of the interface, it is just a flag that
indicates the data is urgent (the actual Urgent pointer is a
RFC929 December 1984
Proposed Host-Front End Protocol
concern of the off-loaded TCP interpreter, which is keeping
track of the sequence numbers). When issued by the Host
process, the Urgent flag means the stream should be marked.
When issued by the OPE, it means the receiver should go to
(or remain in) the Urgent receive mode. If the flag is not
set in the Transmit issued by the OPE, then the receiver
should remain in (or return to) the non-urgent receive mode.
The value of this protocol-idiosyncratic parameter is "U" if
the Urgent is set, or "N" if it is not set. The default
value for this parameter is "N". Since this parameter is
the first protocol-idiosyncratic parameter for the Transmit
command, it requires no special flag, and can be indicated
using the flag -pi.
The second protocol-idiosyncratic parameter is the Push
flag. This parameter is only issued by the Host, since
there is no Push in the TCP Deliver event. Its value is "P"
for push, or "N" for normal. The default value of this
parameter is "N". Its control flag is -pu.
The third protocol-idiosyncratic parameter is the ULP
timeout action and value parameter. The action part
indicates whether the offloaded interpreter should abort the
connection on a timeout or report it to the inboard user.
The value part is the numerical value of the timeout
interval. The format used for this parameter is the same as
in the Begin command, which is a single letter followed
immediately (with no spaces) by an ASCII number. The letter
can be either "R" or "A", and indicates that the ULP timeout
should cause a report or an abort, respectively. The number
is interpreted to be the timeout interval in seconds. The
default interpretation for this parameter is its previous
value. The control flag for this parameter is -ul.
1.3.3. Examples of the Command
An example of a Transmit command issued by a Host process is
C TR -pi N P R160 <nl> <DATA>
where <DATA> is the data contained within the chunk. This
command is for a non-urgent but pushed TCP Send event, that
also resets the timeout action and interval to Report with a
value of 160 seconds. The response mode (i.e., nonblocking)
is derived from the Begin command and not effected by
transmit.
RFC929 December 1984
Proposed Host-Front End Protocol
An example of a Transmit command issued by the OPE is
C TR -pi N <nl> <DATA>
where <DATA> is the data contained within the chunk. This
command is for a non-urgent delivery (presumably, after a
previous Urgent delivery).
1.4. The Condition Command
The Condition command is used to modify the transmission
characteristics of the connection. The parameters that make
sense to modify with TCP are the Transmit Response discipline,
the Type of Service, and the Flow Control Advice.
1.4.1. Specialized Usage
There is no usage of the Condition command with an offloaded
TCP interpreter that is particularly specialized.
1.4.2. Protocol-Idiosyncratic Parameters
There are no protocol-idiosyncratic parameters for the
condition command for the off-loaded TCP. It would be
possible for the ULP timeout action values to be changed
with a condition command. However, this is accomplished
with the Transmit command, which more closely models the
interface specified in MIL-STD 1778. We propose that the
condition command not provide this capability.
1.4.3. Examples of the Command
An example of the Condition command to change the flow
control advice for a connection is
C CO -fc 1 <nl>
which indicates that relatively small transmission units are
now expected.
RFC929 December 1984
Proposed Host-Front End Protocol
1.5. The Signal Command
As we currently understand it, TCP's URGENT feature provides an
INband signal rather than a true out-of-band signal (and at
least one of us deeply regrets this). The actual URGENT bit is
sent out-of-band, but it contains an URGENT pointer which
relates the URGENT to its position in the data stream. The
actual semantics of the URGENT is left to the higher level
protocol (e.g., Telnet says to discard all data up to the
URGENT pointer). Since the Signal command is allowed to cross
a pending Transmit in the H-FP channel, it would be potentially
dangerous to implement the interface to TCP URGENT using the
Signal command since the wrong sequence number could be used as
the urgent pointer. Barring persuasive arguments to the
contrary, it is proposed that Signal should not be used with
TCP.
1.6. The Status Command
The Status command maps directly into the TCP Status event when
issued by a Host process. It is also used for the TCP error
event when issued by the OPE. There is currently some question
as to how information from lower protocol levels (e.g., ICMP
error messages) should be reported to TCP users. When these
issues are resolved, there may be other uses for the Status
command. We solicit other ideas for the Status command with
this report.
1.6.1. Specialized Usage
The major specialized usage of the Status command is to
provide the error reporting service. This usage is a form
of the Status generated by the OPE.
1.6.2. Protocol-Idiosyncratic Parameters
When used as a TCP Status request (command issued by the
Host process), there are no protocol-idiosyncratic
parameters associated with the Status command. The OPE
response codes the TCP status.
When used as a TCP error report (command issued by the OPE),
there is one protocol-idiosyncratic parameter associated
with the Status command. It is an error description in the
form of a text string. It requires no special control flag
since the flag -pi is unambiguous and there are no other
protocol-idiosyncratic parameters.
RFC929 December 1984
Proposed Host-Front End Protocol
1.6.3. Examples of the Command
An example of the Status command issued by the Host process
to request status information is
C ST Q <nl>
The status information is returned in the response to the
status command.
An example of the Status command issued by the OPE to report
an error from the TCP interpreter is
C ST R -pi "Connection already exists" <nl>
which is issued when a TCP open (HFP Begin) is issued to an
already opened (foreign) connection.
1.7. The End Command
The End command is used to indicate that TCP services are no
longer required. Thus, it can be mapped into either the TCP
Graceful Close or the TCP Abort events. It is also used as the
TCP Closing response (as contrasted with the response by the
OPE to the close command), when issued by the OPE.
1.7.1. Specialized Usage
Because of the nature of the two-way close provided by TCP,
there is a possibility that the Host and the OPE wish to
gracefully terminate the connection at the same instant. If
this happens, then both the Host and the OPE would issue End
commands at the same time. To be prepared for this, it is
necessary to make this the normal graceful closing sequence.
In other words, both the Graceful Close request and the
Closing response are mapped to End commands, and the
response to one of those commands only indicates that the
command has been received and executed, but not that the
connection is actually fully closed. The connection is
gracefully closed when both End commands have been issued,
and both successful responses have been received.
With an abrupt end, a two-way exchange is not necessary.
Only the Host or the OPE need issue it, for the connection
to be aborted.
RFC929 December 1984
Proposed Host-Front End Protocol
1.7.2. Protocol-Idiosyncratic Parameters
There are no protocol-idiosyncratic parameters for the End
command used with TCP.
1.7.3. Examples of the Command
An example of the End command used to indicate either a TCP
Close request (from the Host process) or TCP Closing
response (from the OPE) is
C EN G <nl>
An example of the End command used as an Abort request (from
the Host process) or as a Terminate response is
C EN A <nl>
2. Command Level Interface to an Off-loaded Telnet
This appendix is provided to discuss the use of the commands
described in the body of this document to provide an interface
between a Host process and an off-loaded interpreter of the Telnet
protocol.
The interface described here is not based on a formal interface.
There are several reasons for this, including the lack of a widely
accepted standard interface to Telnet, and its headerless nature.
Consequently, the interface described here is very similar to the
actual Telnet data stream.
2.1. The Begin Command
The Begin command is used with Telnet to initiate Telnet
connections.
2.1.1. Specialized Usage
There are three major specialized usages to the Begin
command. They are the meaning of the Mediation Level
parameter, the way the number of incoming Telnet connections
are supported, and the meaning of the secondary address
components.
The mediation level is used in Telnet to control which of
the various Telnet activities are performed by the OPE, and
which are controlled by the Host. It has been determined
RFC929 December 1984
Proposed Host-Front End Protocol
that all monitoring of the Telnet Socket should be performed
by the OPE. Mediation level 9, which is the default,
indicates the Host desires to play no role in Telnet
operation. Level 5 means that protocol-idiosyncratic
parameters to this Begin command indicate which incoming
options the Host wishes to handle; all other options, and
all NVT translations, are to be performed by the OPE. Level
0 indicates that the Host will handle all options, while all
NVT translations are to be performed in the OPE (see Section
B.1.3).
The Host can either accept the connections by fielding OPE
generated Begins, or by issuing passive Begins to the OPE.
The Host may wish to restrict the number of incoming Telnet
connections that it will handle at any particular time. It
can do this by rejecting OPE-generated Begins above a
certain number, or by limiting the number of Host-issued
passive Begins. However, precedence constraints dictate
that the Host actually issue additional passive Begins or
accept additional Begins from the OPE beyond the maximum
number it is normally willing to support, so that
high-priority service requests can be accommodated, possibly
by preempting lower priority activities.
The secondary address component is used to refer to specific
ports. Normally, they are used only when the standard or
default ports are not used, such as special purpose
applications or testing.
2.1.2. Protocol-Idiosyncratic Parameters
The protocol-idiosyncratic parameters to the Telnet Begin
command are the identifiers for the options which the host
wishes to negotiate when using mediation level 5. On other
mediation levels, these parameters are not used.
2.1.3. Examples of the Command
An example of a passive Begin for an outboard Telnet
protocol is:
C BE TEL P ,, 5 N -fc 0 -pi 9 <nl>
Where the parameters are:
TEL Code for the Telnet Protocol
P Passive Begin
RFC929 December 1984
Proposed Host-Front End Protocol
,, Skip the Foreign Address Primary Component
5 Mediation Level is 5
N Non Blocking Transmits
-fc Skips over parameters up to Flow Control Advice
S Small Blocks are appropriate for Telnet
-pi Skips over parameters to the Protocol Idiosyncratic
List of Options to be Handled by the Host.
9 Option Code for Line Length Option
Here, no remote address component was specified, since the
Host will accept connections from any Host. Similarly, no
local addresses are specified, since the default well-known
socket for this Host is to be used. In this example, the
Host specifies it will handle the line length option (number
9). Other options are handled in the OPE.
An example of an active Begin for an outboard Telnet
protocol is:
C BE TEL A ISIA 5 N -fc 0 -pi 9 <nl>
This command is identical to the passive command, except
that a remote primary address component is specified to
identify the intended Host. No remote secondary component
is specified, since the well-known socket at that Host is to
be used. No local secondary address components are
specified, since the connection can originate from any
available socket of the appropriate type selected by the
OPE.
2.2. The Transmit Command
The Transmit Command is used to send data across a Telnet
connection.
2.2.1. Specialized Usage
The Transmit command is used to transmit data over the
Telnet connection. There is one specialized aspect of the
Transmit command used with an outboard Telnet interpreter.
This is the provision of the Go Ahead feature of Telnet that
supports half-duplex devices.
Go Ahead is provided as a protocol idiosyncratic parameter
to the Transmit. It is only used if the Host will support
it, however. It is our opinion that Go Ahead is probably
not a proper thing for the default case.
RFC929 December 1984
Proposed Host-Front End Protocol
Go Aheads are a matter between the Host and the terminal. It
is difficult to offload the generation of Go Aheads to the
OPE, since the OPE is not really cognizant of the semantics
of the communication between the Host and the terminal.
Hence, the OPE does not know when the Host is done
transmitting and willing to pass "the turn" back to the
terminal. Similarly when the remote site relinquishes
control, the OPE includes Go Ahead in its TR.
We don't believe this Go Ahead problem to be an indictment
against outboard processing. It merely illustrates that
functionality not found in a Host cannot necessarily be
provided by the OPE. Hence, we provide this note to the
implementor: if the Host cannot generate the
protocol-idiosyncratic Go Ahead parameter, then the DO
Suppress Go Ahead must be issued immediately after the
connection is established.
2.2.2. Protocol Idiosyncratic Parameters
The protocol idiosyncratic parameter is the Go Ahead
indicator. When present, the character "G" is used to mean
the Go Ahead can be sent to the other end of the connection,
but only after the data associated with that Transmit
command is sent. When the character is any other value, or
is absent, the Go Ahead should not be sent.
2.2.3. Examples of the Command
An example of the Transmit command is:
C TR -pi G <nl> <DATA>
With this command, the Go Ahead is passed to the other side
after the data is sent.
2.3. The Condition Command
The Condition command is used with Telnet to modify the
Transmission characteristics and to enable or disable Telnet
options on a Telnet connection.
2.3.1. Specialized Usage
The Condition command takes on specialized usage with
Telnet, in addition to its normal usage. It is used to
RFC929 December 1984
Proposed Host-Front End Protocol
control the option selection and negotiation process, when
such selection is performed by the Host (currently, this is
done at mediation levels 5 and 1, but not at level 9).
A set of protocol-idiosyncratic parameters has been defined