📄 rfc929.txt
字号:
5XX Local OPE Internal Problems: Problems, such as insufficient
OPE resources, or problems with OPE to subnet interface.
6XX Security Problem: Some problem with Host, network, or OPE
security has occurred. The response code indicates the
problem.
Lilienkamp & Mandell & Padlipsky [Page 10]
RFC 929 December 1984
Proposed Host-Front End Protocol
7XX Reserved for Future Expansion
8XX Reserved for Future Expansion
9XX Protocol Idiosyncratic Errors: Some error occurred that is
idiosyncratic to the particular off-loaded protocol being
used. The response code indicates the error.
Description of the Commands
As stated above, communication between the Host and the OPE at the
Command Level is accomplished using commands and responses. Commands
may be issued by either the Host or the OPE, and are used to
stimulate activity in the other entity. Some commands may only have a
meaningful interpretation in one direction, however. A response
indicates that the activity started by the command was completed, and
a code indicates success or failure of the command, and perhaps other
information related to the command as well.
Associated with each command is a set of parameters. The order in
which the parameters appear is significant to the correct operation
of the protocols. More information on the syntax of command
parameters can be found in the syntax descriptions.
The commands are:
- Begin: initiate communication between a process in the Host and
an off-loaded protocol interpreter in the OPE. (A Channel level
stream/connection will typically have been opened as a prior step.
All other commands, except No-op, apply to a stream on which a
successful Begin has been done.)
- Transmit: transmit data between a process in the Host and an
off-loaded protocol interpreter in the OPE.
- Signal: cause an out-of-band signal to be sent by the
off-loaded protocol interpreter to its peer, or indicate the
arrival of such a signal from the remote side.
- Condition: alter the off-loaded protocol interpreter's
operational characteristics.
- Status: transfer status requests or information between a
process in the Host and an off-loaded protocol interpreter in the
OPE.
Lilienkamp & Mandell & Padlipsky [Page 11]
RFC 929 December 1984
Proposed Host-Front End Protocol
- End: indicate that services from the off-loaded protocol
interpreter are no longer required, or will no longer be provided.
- No-op: performs no operation, but facilitates testing.
These commands will be discussed in the following sections. Each of
these sections includes a discussion of the purpose of the command, a
description of each of the parameters used with the command, a list
of responses for the command, an example of the command, and a set of
notes for the implementor. (An appendix will eventually be furnished
for each protocol offloading, showing the use of its protocol
idiosyncratic parameters as well as of the general parameters on a
per-command basis. Initially, only representative offloadings will
be treated in appendices, with others to be added after the protocol
gains acceptance.)
Begin
Purpose of the Begin Command
The purpose of a Begin command is to initiate communication
between the Host and the OPE on a particular stream or channel
(the channel is opened as a separate step, of course). The
interpretation of the command is somewhat dependent upon
whether it was issued by the Host of the OPE.
- If the command was issued by the Host, it means some process
in the Host is requesting services of a protocol that was
off-loaded to the OPE. The user request results in the
establishment of a channel connection between the Host and the
OPE, and a Begin command to the Command interpreter in the OPE.
- If the command was issued by the OPE, it means some protocol
interpreter in the OPE has data for some process in the Host
which is not currently known by the OPE. An example would be
an incoming UDP datagram on a new port, or if no Begin for UDP
had been issued at all by the Host. (An incoming TCP
connection request could be handled by a response to the user's
Passive Open request, which had previously caused a Begin
request from the Host; an incoming TCP connection request to a
port on which no Listen had been issued would cause an OPE
generated Begin, however.)
As indicated earlier, any particular Host is not required to
support two-way Begins.
Lilienkamp & Mandell & Padlipsky [Page 12]
RFC 929 December 1984
Proposed Host-Front End Protocol
Parameters of the Begin Command
The Begin command has several parameters associated with it.
These parameters contain information needed by the offloaded
protocol to provide an adequate level of network service. This
information includes protocol, source and destination
addresses, and also type of service and flow control advice.
These parameters are discussed in detail below.
Protocol
The protocol parameter identifies that off-loaded protocol in
the OPE to which Begin is directed, or which issued the Begin
to the Host. For example, if the user wished to utilize TCP
services, and the TCP software was off-loaded into the OPE,
then the Protocol parameter for the Begin command would be TCP.
There are two categories of protocol parameters -- generic and
specific. A generic parameter identifies a type of protocol
service required, but does not identify the actual protocol.
Use of generic protocols allows a Host process to obtain
network services without specific knowledge of what protocol is
being used; this could be appropriate for use in situations
where no specific aspect(s) of a specific protocol is/are
required. For example, the user may select a generic
Host-to-Host connection protocol, and (at some point in the
future) may actually receive services from either TCP or the
NBS Transport Protocol, depending on the network (or even the
foreign Host) in question. A specific protocol parameter
identifies some particular protocol, e.g., TCP, whose use is
required for the given channel.
The valid entries for the protocol field include:
Generic Specific Comment
GIP IP Datagram Internetwork Protocol
HHP TCP Connection Transport/Host-Host Protocol
GDP UDP Datagram Transport/Host-Host Protocol
VTP TEL Virtual Terminal (Telnet) Protocol
GFP FTP File Transfer Protocol
MAIL SMTP Mail Transfer Protocol
PROX PROX Proximate Net Interface Protocol
(Note that the final line is meant to allow for a process in an
OPE'd Host's getting at the PI of the Network Interface
Protocol for whatever the proximate network is. Of course, so
Lilienkamp & Mandell & Padlipsky [Page 13]
RFC 929 December 1984
Proposed Host-Front End Protocol
doing only makes sense in specialized contexts. We conceive of
the desirability of "pumping bits at a peripheral" on a LAN,
though, and don't want to preclude it, even if it would be
impossible on many LAN's to deal with the problem of
distinguishing traffic coming back on the LAN in this "raw"
mode from normal, IP traffic. Indeed, in some contexts it is
likely that administrative considerations would preclude
avoidance of IP even if technical considerations allowed it,
but it's still the case that "the protocol" should provide a
hook for going directly to the L I protocol in play.)
There is no default value for this parameter. If it is not
present, the Begin command is in error. The control flag for
this parameter is -pr.
Active/Passive
The Active/Passive parameter indicates whether the issuer of
the Begin command desires to be the Active or Passive user of
the protocol. This parameter is particularly relevant to
connection-oriented protocols such as TCP, where the user may
actively pursue connection establishment, or else may passively
wait for the remote entity to actively establish the
connection; it also allows some process to establish itself as
the Host "fielder" of incoming traffic for a connectionless
protocol such as IP.
Active is requested using the single character "A". Passive is
indicated using the character "P". The default value of this
parameter is "A". Also, when the OPE issues the Begin command,
the value must be "A". The control flag for this parameter is
-ap.
Foreign Address Primary Component
The addressing structure supported by H-FP is two level. Each
address has two components, the primary and the secondary. The
exact interpretation of these two components is protocol
specific, but some generalities do apply. The primary
component of the address identifies where the protocol is to
deliver the information. The secondary component identifies
which recipient at that location is to receive the information.
For example, the TCP primary address component is the Host's
Internet Address, while the secondary address component is the
TCP port. Similarly, IP's primary address component is the
Host's Internet Address, and the secondary address component is
the IP ULP field. Some protocols provide only a single level
Lilienkamp & Mandell & Padlipsky [Page 14]
RFC 929 December 1984
Proposed Host-Front End Protocol
of addressing, or the secondary level can be deduced from some
other information (e.g., Telnet). In these cases, only the
primary component is used. To cater to such cases, the
secondary component parameter comes later in the parameter
list.
The Foreign Address Primary Component parameter contains the
primary component of the destination address. It may be in
either a numeric or symbolic form. (Note that this allows for
the OPE to exercise a Name Server type of protocol if
appropriate, as well as freeing the Host from the necessity of
maintaining an in-board name to address table.) The default
value for this parameter, although it only makes sense for
Passive Begins, is "Any Host". The control flag for this
parameter is -fp.
Mediation Level
The mediation level parameter is an indication of the role the
Host wishes the OPE to play in the operation of the protocol.
The extreme ranges of this mediation would be the case where
the Host wished to remain completely uninvolved, and the case
where the Host wished to make every possible decision. The
specific interpretation of this parameter is dependent upon the
particular off-loaded protocol.
The concept of mediation level can best be clarified by means
of example. A full inboard implementation of the Telnet
protocol places several responsibilities on the Host. These
responsibilities include negotiation and provision of protocol
options, translation between local and network character codes
and formats, and monitoring the well-known socket for incoming
connection requests. The mediation level indicates whether
these responsibilities are assigned to the Host or to the OPE
when the Telnet implementation is outboard. If no OPE
mediation is selected, the Host is involved with all
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -