diff options
Diffstat (limited to 'doc/rfc/rfc929.txt')
| -rw-r--r-- | doc/rfc/rfc929.txt | 3192 |
1 files changed, 3192 insertions, 0 deletions
diff --git a/doc/rfc/rfc929.txt b/doc/rfc/rfc929.txt new file mode 100644 index 0000000..b1bde75 --- /dev/null +++ b/doc/rfc/rfc929.txt @@ -0,0 +1,3192 @@ + + +Network Working Group Joel Lilienkamp (SDC) +Request for Comments: 929 Richard Mandell (SDC) + Michael Padlipsky (Mitre Corp.) + December 1984 + + PROPOSED HOST-FRONT END PROTOCOL + + +Status Of This Memo + + The reader should be aware of several things in regard to what the + present document is up to. First and foremost, IT IS A PROPOSAL FOR + A STANDARD, NOT A STANDARD ITSELF. Next, it assumes that the + separate document, RFC 928, 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 RFC 928, not by the primary author of the present + document, so any readers bothered by style considerations should feel + free to blame the former, who's used to it, rather than the latter, + who may well be guiltless. (Editing at a distance finally become too + hard to manage, so if I'm typing it myself I'm going to fiddle with + it myself too, including, but not limited to, sticking my own section + on the Conceptual Model in before Joel's words start, rather than + leaving it in the Introduction. MAP) + + Finally, it should be noted that this is not a finished document. + That is, the intent is eventually to supply appendices for all of the + protocol offloadings, describing their uses of protocol idiosyncratic + parameters and even their interpretations of the standard per-command + parameters, but in order to get what we've got into circulation we + haven't waited until all such appendices have been written up. (We + do have notes on how to handle FTP, e.g., and UDP will be pretty + straightforward, but getting them ready would have delayed things + into still another calendar year, which would have been very annoying + ... not to say embarrassing.) For that matter, it's not even a + finished document with respect to what is here. Not only is it our + stated intention to revise the protocol based upon implementation + experience gained from volunteer test implementations, but it's also + the case that it hasn't proven feasible to iron out all known + wrinkles in what is being presented. For example, the response codes + almost certainly need clarification and expansion, and at least one + of us doesn't think mandatory initial parameters need control flags. + However, to try too hard for polish would be to stay in subcommittee + for the better part of forever, so what you see is what we've got, + but certainly isn't meant to be what you or we are stuck with. + + This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + + + + +Lilienkamp & Mandell & Padlipsky [Page 1] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + +Conceptual Model + + There are two fundamental motivations for doing outboard processing. + One is to conserve the Hosts' resources (CPU cycles and memory) in a + resource sharing intercomputer network, by offloading as much of the + required networking software from the Hosts to Outboard Processing + Environments (or "Network Front-Ends") as possible. The other is to + facilitate procurement of implementations of the various + intercomputer networking protocols for the several types of Host in + play in a typical heterogeneous intercomputer network, by employing + common implementations in the OPE. A third motivation, of basing a + network security approach on trusted mandatory OPEs, will not be + dealt with here, but is at least worthy of mention. + + Neither motivation should be allowed to detract from the underlying, + assumed desire to perform true intercomputer networking, however. + Therefore, it is further assumed that OPEs will be attached to Hosts + via a flexible attachment strategy, as described in [1]. That is, at + the software level an explicit Host-Front End Protocol (H-FP) will be + employed between Hosts and OPEs, rather than having OPEs emulate + devices or device controllers already "known" to Host operating + systems (in order to avoid introducing new code into the Host). + + For reasons discussed in the Introduction, an H-FP resolves into + three layers. The Link layer enables the exchange of bits between + Host and OPE. The Channel layer enables the bit streams to be + demultiplexed and flow controlled (both the Channel and Link layers + may use preexisting per-Host mechanizations, it should be recalled). + The Command (or "Service Access") layer is our primary concern at + present. It serves as the distributed processing mechanism which + allows processes on Hosts to manipulate protocol interpreters (PIs) + in OPEs on their behalf; for convenience, it will be referred to as + "the H-FP" here. (It should be noted that the Link and Channel + layers may be viewed as roughly equivalent to the inboard processing + investment for a Host-comm subnet processor PI and device driver, so + in practical terms the savings of resources achieved by outboard + processing come from making the H-FP "smaller" than the inboard + implementations of the protocols it allows to be offloaded.) + + The crucial property of the H-FP conceptually is that it stands as + the interface between a (Host) process and a PI (which is actually + outboard). Usually, the model is that of a closed subroutine + interface, although in some cases an interprocess communication + mechanism model must be appealed to. That is, the interactions + between cooperating H-FP PIs in some sense mimic subroutine or IPC + calls, from the perspective of Host processes calling upon their own + H-FP PIs, which in turn are of course interfacing via just such + + +Lilienkamp & Mandell & Padlipsky [Page 2] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + mechanisms themselves. Another way of putting it is that "if the + protocols were inboard," the processes invoking H-FP wouldn't know + the difference. H-FP, then, may be viewed as a roundabout way of + letting Host processes "get at" various PIs. + + Naturally, the mechanization of the desired concept cannot be + particularly literal. After all, the Hosts and the OPEs are + different processors, so we're not envisioning a passing through of + parameters in an exact fashion. However, in broad terms the model is + just that of a somewhat funny interface between a process and a PI. + (This should not be construed as ruling out the occurrence of events + which prompt the OPE to initiate an exchange of commands with the + Host, though; see the Introduction for more on the topic of + "Symmetric Begins.") + +Interaction Discipline + + The interaction between the Host and the OPE must be capable of + providing a suitable interface between processes (or protocol + interpreters) in the Host and the off-loaded protocol interpreters in + the OPE. This interaction must not, however, burden the Host more + heavily than would have resulted from supporting the protocols + inboard, lest the advantage of using an OPE be overridden. + + Channel Level Interaction + + As stated elsewhere, the Channel level protocol (implicitly in + conjunction with the Link level) provides two major functions. These + are demultiplexing the traffic from the Link level into distinct data + streams, and providing flow control between the Host and the OPE on a + per stream basis. These hold even if the Host-OPE attachment is DMA. + + The data streams between the Host and the OPE are bidirectional. In + this document, the basic unit of data transferred by the Channel + level is referred to as a "chunk". The primary motivation for this + terminology is that the H-FP permits the Channel level to be one of + several possible protocols, each with its own terminology. For + example, a chunk on an X.25 Channel would be a packet, while a chunk + on the DTI H-FP channel would be a message. While the Command level + is, in a sense, "more efficient" when the chunk size is permitted to + be large, the flexibility permitted in the choice of protocols at the + Channel level precludes any assumptions about the chunk size. + + Each data stream is fully asynchronous. A Channel protocol user can + send data at any time, once the channel has been properly opened. + (The Command level's logic may render some actions meaningless, + however.) The data transfer service provided by the Channel protocol + + +Lilienkamp & Mandell & Padlipsky [Page 3] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + is reliable; this entails delivery in the correct order, without + duplication, and checked for bit errors. All retransmission, error + checking, and duplicate detection is provided by this protocol in a + way that is transparent to the user. (If the attachment is DMA, + stream identification and chunk length must still be provided for.) + + The flow control at the Channel level is provided to prevent the OPE + and the Host from overloading each other's resources by excessive + transmissions. In general, this flow control should not directly + affect the outboard protocol interpreters' operation. On the other + had, this flow control has the same effect as explicit interface + events that provide flow control between the user and the protocol + interpreter (e.g., the Allocate event of the interface specification + for TCP found in MIL-STD 1778). Hence, such events do not need to be + communicated explicitly at the Command level. (If the attachment is + DMA, flow control must still be provided for.) + + Should Hosts require an OPE to be attached via a Link Level that + furnishes physical demultiplexing (e.g., a group of RS232 ports), any + attempt to avoid furnishing reliability and explicit flow control, is + done at their peril; we have not chosen to assist such an + enterprise, but neither have we precluded it. (It would certainly + violate the spirit of the thing, however.) + + Command Level Interaction + + The approach chosen for this H-FP is to base the interaction on a + small set of commands, separately applicable to a given Channel Level + channel. The commands are simple, but sufficiently flexible to permit + the off-loading of the interpreters of the large number of protocols + at various levels in the hierarchy. This flexibility is made + possible in part by the similar nature of the interfaces to most + protocols, combined with the provision of "protocol idiosyncratic + parameters". These parameters are defined for each offloaded protocol + interpreter in the OPE. The use of such parameters does not + complicate the basic design of the OPE, since it must be customized + for each off-loaded protocol anyway, and all that is required of the + OPE for those parameters is to pass them to the off-loaded protocol + interpreter. Hence, an interface tailored to a particular protocol + can be created in a straightforward and cost-effective way. + + The command dialog is more or less asynchronous. Commands can be + issued at any particular time (except when there is a pending + command, which will be discussed below), and there is no need for + dummy traffic on a channel when no commands are issued. + + Associated with each command is a response. The purpose of this + + +Lilienkamp & Mandell & Padlipsky [Page 4] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + response is to indicate, at some level that depends in part on the + particular protocol interpreter that is offloaded to the OPE, whether + the command was successfully executed, and if unsuccessful, the + reason. Often, generating the response involves interaction with the + protocol interpreter before a response can be generated. + + When a command is issued, the issuer must wait for a response before + another command is issued. The nature of the communication between + the Host and the OPE is thus a lock step command/response dialog. + There are two major exceptions to this principle, however. One + exception is the abrupt form of the End command, which can be issued + at any time to cancel any previously issued commands, and indicate + that services are no longer desired. The other exception is the + Signal command. Since a Signal is out-of-band and usually of high + importance, forcing it to wait on a response would be undesirable. + Hence, a Signal command can be issued while commands (other than + Signal) are pending. However, a Signal command should not be issued + before a successful response to the Begin command has been received. + Since it is possible for more than one command of different types to + be pending at one time, a mechanism to distinguish responses is + needed. Since there are never two commands of the same type pending, + including the command name in the response is sufficient to make this + distinction. + + A special case command is the Transmit command. Details of the + Transmit command are provided in the next section. Essentially, the + Transmit command is used to invoke the data transfer services of the + off-loaded protocol (when issued by the Host) or to indicate the + arrival of new data from the network (when issued by the OPE). The + nature of specific protocol interfaces for these events varies widely + between protocols. Some may block until the data is accepted by the + remote counterpart (or "peer") protocol interpreter, while others may + not. Hence, there is a special parameter which indicates the nature + of the Transmit command interface. It can either require that the + response should be generated immediately after determining the + Transmit command is complete and formed properly, or can indicate + that the response should not be generated until the appropriate + interface event is given by the remote protocol interpreter. The + default action for all Transmit commands can be initialized using the + Begin command and changed using the Condition command. Also, the + default action can be temporarily overridden by specifying a + parameter with the Transmit command. The net result of this mechanism + is to allow the Host to determine within reason just how lock-stepped + transmissions are to be. (It is assumed that the usual case will be + to transfer the burden of buffering to the OPE by taking immediate + responses, provided that doing so "makes sense" with the particular + offloaded protocol in play.) + + +Lilienkamp & Mandell & Padlipsky [Page 5] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + Some protocols provide a block-oriented data transfer service rather + than a stream-oriented one. With such a service, the data associated + with a transfer request is viewed as an integral unit. For actual + network transmission, the protocol may permit these units to be + grouped or fragmented. However, the receiving end must deliver the + data in the original, integral units. Protocols that conform to this + model include some datagram protocols such as IP and UDP, and also + some connection protocols such as NBS TP. + + To cater to these types of protocols, it is a convention that + commands, their parameters, and any associated data be transferred + between the Host and the OPE in a single chunk. Any data associated + with an H-FP command is viewed as an integral unit which is used in + the corresponding service request given to the outboard protocol + interpreter or delivered as a complete unit to the process in the + Host. Operation of stream-oriented protocols such as TCP will not be + adversely affected by this convention. + + To accommodate Channel protocols that do not provide for arbitrarily + large chunks, a mechanism at the Command level is required to permit + the linking of multiple chunks into a single command, in order to + transfer the burden of buffering as much as possible from the Host to + the OPE. The facility proposed here would consist of an indication + at the beginning of each chunk which would distinguish integral + commands, fragments of a command for which more fragments are yet to + arrive, and the final fragment of a command. The details of this + mechanism are discussed in the section on the syntax of commands and + responses. + + It is a convention for this H-FP that any data associated with a + command must start on a word boundary (as defined by the local + system). Consequently, there is a need to provide padding within the + commands. Such padding is used only to fill to the next appropriate + boundary, and has no semantic significance to the command interpreter + (i.e., two commands that are identical except for the amount of + padding should behave identically). The details of this padding are + discussed in the section on the syntax of commands and responses. + + + + + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 6] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + +Syntax Rules + + At the Command Level, communication between the Host and the OPE + takes the form of commands and responses. A command is a request for + some particular action, and the response indicates the success or + failure of performing the requested action. + + All commands and responses are coded in ASCII characters. (Nothing + precludes OPEs from accepting EBCDIC from Hosts that use it in native + mode, but that is not required.) These characters are sent in some + way convenient for the Host, and the OPE is sufficiently flexible to + interpret them. (i.e., OPEs are expected to accommodate Host + idiosyncracies in regard to such things as use of 7-bit ASCII in a + 9-bit field.) This approach offers several advantages: + + Adaptabilities in most Hosts: Most Hosts have the ability to + generate and interpret ASCII character streams. Hence, integrating + H-FP into a Host will not require difficult software. + + Script generation: Generation of test and operational command + scripts will be simplified, since they will not need to contain + special characters. + + Terminal Operation: Using simple command streams simplifies the + conversion of an OPE to a generic virtual terminal support machine. + This is particularly useful during development and testing. + + Testing: Testing will not require special hardware to interpret + commands and responses. A terminal or data line analyzer would be + adequate. + + The specific format for the commands and responses will be discussed + in the sections that follow. In those sections, the quote character + is used to indicate strings. The symbols "<" and ">" (referred to as + angle brackets) are used as meta-characters. + + Syntax of Commands + + As alluded to in the section discussing the interaction discipline + between the Host and the OPE, a function is provided by which a chunk + can be used to carry either a complete command or a fragment of a + command. The mechanism chosen to provide this function entails use + of the first character position in the chunk as a chunk usage + identifier. The character "C" in the first position indicates a + chunk containing a single, complete command. "F" in the first + position indicates a chunk which is the first part of a multichunk + command. "M" in the first position indicates the chunk is a middle + + +Lilienkamp & Mandell & Padlipsky [Page 7] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + part (neither the first nor the last chunk) of a command. Finally, + "L" indicates the chunk is the last chunk of a multi-chunk command. + Hence, the following sequences of chunks (the letter corresponds to + the chunk usage identifier in each chunk, and the angle brackets + enclose a chunk) are legal: + + <C> + <F><L> + <F><M><M><L> + + while the following are not legal: + + <L> + <M><L> + <F><C> + + Tactics for handling multiple chunks with regard to OPE buffering + limits are left to the ingenuity of OPE builders. The spirit is to + take as much as you can, in order to relieve the Host of the + necessity of buffering itself. + + A command always begins immediately following the indicator + character, with possible intervening spaces. This implies a chunk + can contain at most one complete command. The end of the command + (not including the data) is signified by a newline (denoted as <nl> + in this document) that does not appear inside a quoted string (see + below). The end of the data is designated by the end of the last + chunk. + + Commands take the form of an ASCII string. The command identifier is + the first word of the chunk. It consists of at least the first two + letters of the command, in either upper or lower case (e.g., the + sequences "BE", "Be", "bE", and "be" all identify the Begin command). + Additional letters of the command name can be included if desired to + aid readability of the command stream. + + Following the command identifier is a list of parameters. These + parameters are also represented as ASCII strings, although the + specific format will depend on the particular parameter. The data to + be transmitted is not considered a control parameter, however, and + need not be ASCII data. + + Parameters are separated by one or more spaces. Tabs, newlines, and + other white space are not legal parameter separators. + + Parameter strings may be quoted, using the character <">. Any + + + +Lilienkamp & Mandell & Padlipsky [Page 8] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + characters between the <"> characters are a part of the parameter, + including spaces and newlines. The character <"> that is part of the + parameter is represented inside a quoted string as <"">. + + The order in which the parameters appear within the command is + significant to their interpretation by the Host and by the OPE. + Optional parameters may be skipped by using the characters ",," to + indicate a NULL parameter. Such a NULL parameter takes its default + value. Alternatively, each parameter has a MULTICS/UNIX style + Control Argument/Flag associated with it that can be used to identify + the parameter, without placing NULL parameters for each parameter + skipped. This flag consists of one or two ASCII characters, and + either upper or lower case may be used. For example, if the fourth + parameter of a command had a flag of "-p" and the user wished the + first three parameters to be null, he could use: + + command -p value + + or + + command -P value + + instead of + + command ,, ,, ,, value + + if it were more convenient for the Host to do so. Flagged parameters + must still appear in the correct sequence within the command, + however. + + There may be data associated with some of the commands. Any such + data is placed into the chunk following all the parameters and the + unquoted newline. Padding can be provided by placing spaces between + the end of the final parameter string and the newline, so that data + begins on a word boundary. The OPE will always pad to a host word + boundary. Padding by hosts is optional. + + Syntax of Responses + + Responses are actually just a special form of a command. It is + anticipated that all responses would fit into a single channel chunk, + although the mechanisms described for multichunk commands can + certainly be used in responses. The ASCII string used to uniquely + identify the response command is "RE" ("Re", "rE", and "re" are also + permitted). + + After the response command identifier is the original command + + +Lilienkamp & Mandell & Padlipsky [Page 9] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + identifier, so the response can be associated with the proper + command. Following this identifier is a three ASCII digit response + code, a set of protocol idiosyncratic parameters, and a textual + message. The protocol idiosyncratic parameters are used to transfer + interface information between the Host and the OPE, and may not be + needed when off-loading some protocol interpreters. The textual + message is intended for human interpretation of the response codes, + and is not required by the protocol. The three digits uniquely + identify the semantics of the response, at least within the context + of a particular command and particular outboarded protocol + interpreter. + + Responses are numerically grouped by the type of information they + convey. The first digit identifies this group, and the last two + digits further qualify the reply. The following list illustrates + this grouping. + + 0XX Successful: The command was executed successfully. The + response code may contain further information. + + 1XX Conditional Success: The command was executed successfully, + but not exactly according to the service and flow control + suggestions. If those suggestions were particularly important + to the requester, he may wish to issue an End command. The + response code contains information on what suggestion or + suggestions could not be followed. + + 2XX Command Level Error: An error at the command level has + occurred. This could include requesting services of a + protocol not supported, or a problem in the way those services + were requested. This level does not include problems with the + syntax of the command or its parameters. + + 3XX Syntax and Parameter Errors: An error in the syntax of the + command or a problem with one of its parameters has occurred. + A problem with a parameter may be other than syntactical, such + as illegal address. + + 4XX Off-loaded Protocol Interpreter Problems: Some problem with + the particular off-loaded protocol has occurred. + + 5XX Local OPE Internal Problems: Problems, such as insufficient + OPE resources, or problems with OPE to subnet interface. + + 6XX Security Problem: Some problem with Host, network, or OPE + security has occurred. The response code indicates the + problem. + + +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 + negotiation of the Telnet options, and all format conversions. + With full OPE mediation, all option negotiation and all format + conversions are performed by the OPE. An intermediate level of + mediation might have ordinary option negotiation, format + conversion, and socket monitoring done in the OPE, while + options not known to the OPE are handled by the Host. + + The parameter is represented with a single ASCII digit. The + value 9 represents full OPE mediation, and the value 0 + represents no OPE mediation. Other values may be defined for + + + +Lilienkamp & Mandell & Padlipsky [Page 15] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + some protocols (e.g., the intermediate mediation level + discussed above for Telnet). The default value for this + parameter is 9. The control flag for this parameter is -m. + + Transmit Response Discipline + + The Transmit Response Discipline parameter is used to set the + desired action on the OPE's part for generating responses to + Transmit commands. Essentially the parameter determines when + the OPE's response to the transmit command occurs (i.e., + immediately or delayed). + + The Transmit Response Discipline value is represented by a + single ASCII character. The character "N" is used for + nonblocking Transmit commands, which implies that responses for + Transmit commands should be generated as soon as the command + has been examined for correctness (i.e., that the syntax is + good and the parameters appear reasonable). In other words, + the outboard protocol interpreter has the data in its queue, + but hasn't necessarily transmitted it to the net. The + character "B" is used for blocking Transmit commands, which + requests that the response not be generated until the protocol + interpreter has successfully transmitted the data (unless, of + course, the Transmit command was badly formed). The default + value for this parameter is "N", or a nonblocking Transmit + command. The control flag for this parameter is -tr. + (Depending on the protocol in play, "successfully transmitted" + might well imply that an acknowledgment of some sort has been + received from the foreign Host, but for other protocols it + might only mean that the given collection of bits has been + passed from the OPE to the proximate net.) + + Foreign Address Secondary Component + + The addressing mechanisms supported by this level of H-FP are + discussed above. The Foreign Address Secondary Component + parameter contains the value of the destination address's + secondary component. Some protocols do not require this + parameter, or can obtain it from other information. Therefore, + the default value for this parameter is NULL. A NULL secondary + component might be an error for some protocols, however. The + secondary component can be expressed either numerically or + symbolically. The control flag for this parameter is -fs. + (Note that it is intended to be "legal" to specify a Secondary + Component other than the Well-Known Socket for the protocol in + play; in such cases, the result should be that the virtualizing + of the given protocol be applied to the stream, in the + + +Lilienkamp & Mandell & Padlipsky [Page 16] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + expectation that that's what the other side is expecting. This + is to cater to, for example, a Terminal-Terminal protocol that + merely "does Telnet" to a socket other than the usual Logger.) + + Local Address Secondary Component + + The Local Address Secondary Component parameter contains the + value of the local address's secondary component. (The primary + component is assumed to be the default for the Host, but can be + altered as well; see below.) Some protocols do not require this + parameter, or can obtain it from other information. In some + cases, the OPE may already know the value for this parameter + and therefore not require it. The default value of this + parameter is NULL. The local address secondary component can + be expressed either numerically or symbolically. The control + flag for this parameter is -ls. + + Begin Timeout Interval + + After a Begin command is issued, a timer can be started. If + the activity requested cannot be performed within some timed + interval, then the Begin command may expire. An expired Begin + command returns a response code indicating a Begin timeout + occurred. The Begin Timeout Interval parameter contains the + length of time the timer will run before the Begin timeout + occurs. + + The parameter is represented as a string of ASCII digits + indicating the time interval in seconds. The default value of + this parameter is infinity (i.e., the Begin command will never + timeout). The control flag for this parameter is -bt. + + Type of Service Advice + + The Type of Service Advice parameter contains information on + the service characteristics the user desires from the offloaded + protocol. Included in this parameter is the precedence of the + data transfer, and also indication of whether high throughput, + fast response time, or low error rate is the primary goal. + + The format of this parameter is a letter immediately (i.e. no + intervening spaces) followed by a digit. The letter "T" + indicates that high throughput is desired. The letter "R" + indicates minimal response time is the goal. The letter "E" + indicates that low error rates are the goal. The letter "N" + indicates there are no special service requirements to be + conveyed. The digit immediately following the character + + +Lilienkamp & Mandell & Padlipsky [Page 17] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + indicates the desired precedence level, with zero being the + lowest, and nine being the highest. The specific + interpretation of this parameter is dependent on what service + options are provided by the protocol. The default value of + this parameter is the lowest precedence (ROUTINE), and no + special service requests. The control flag for this parameter + is -ts. + + Flow Control Advice + + The Flow Control Advice parameter contains information on the + flow characteristics desired by the user. Some applications + such as file transfer operate more efficiently if the data is + transferred in large pieces, while other, more interactive + applications are more efficiently served if smaller pieces are + used. This parameter then indicates whether large or small + data blocks should be used. It is only relevant in stream or + connection-oriented protocols, where the user sends more than a + single piece of data. + + This parameter is represented by a single ASCII digit. A value + 0 means the data should be sent in relatively small blocks + (e.g., character or line oriented applications), while a value + 9 means the data should be sent in relatively large blocks + (e.g., block or file oriented applications). Other values + represent sizes between those extremes. The character "N" + indicates that no special flow control advice is provided. The + actual interpretation of this parameter is dependent on the + particular protocol in the OPE. The default value of this + parameter is no flow control advice. In this case, the protocol + in the OPE will operate based only on information available in + the OPE. The control flag for this parameter is -fc. + + Local Address Primary Component + + This parameter contains the local address primary component. It + is anticipated that under most circumstances, this component is + known to both the Host and the OPE. Consequently, this + parameter is seldom required. It would be useful if the Host + desired to select one of several valid addresses, however. The + control flag for this parameter is -lp. + + Security + + The security parameters contain a set of security level, + compartment, community of interest, and handling restriction + information. Currently, security is provided by performing all + + +Lilienkamp & Mandell & Padlipsky [Page 18] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + processing at system high level or at a single level. + Consequently, these parameters are probably redundant, since + the security information is known. In the future, however, + these parameters may be required. Therefore a field is + provided. The control flag for this parameter is -s. + + Protcol Idiosyncratic Parameters + + The remaining parameters are protocol idiosyncratic. That is, + each protocol that is off-loaded may have a set of these + parameters, which are documented with a description of the + off-loaded protocol. The default value for these parameters is + NULL, unless otherwise specified by a particular offloaded + protocol. The control flag for this set of parameters is -pi, + which identifies the first protocol idiosyncratic parameters. + Control flags for other protocol idiosyncratic parameters must + be defined for each off-loaded protocol. + + Data + + After the Protocol Idiosyncratic Parameters, if any, and the + required <nl>, if the protocol in play allows for it at this + juncture the rest of the chunk will be interpreted as data to + be transmitted. That is, in connection oriented protocols data + may or may not be permitted at connection initiation time, but + in connectionless protocols it certainly makes sense to allow + the H-FP Begin command to convey data. (This will also be + useful when we get to the Condition command.) + + Responses + + The following responses have been identified for the Begin + command: + + 000 Command completed successfully + 101 Throughput not available; using maximum + 102 Reliability not available; using maximum + 103 Delay not available; using minimum + 110 Flow Control advice not followed; smaller blocks used + 111 Flow Control advice not followed; larger blocks used + 201 Failed; Begin not implemented in this direction + 202 Failed; timeout + 203 Failed; Begin command on already active channel + 300 Problem with multiple chunks + 301 Syntax problem with Begin command + 302 Protocol not supported in OPE/Host + 303 Active service not available + + +Lilienkamp & Mandell & Padlipsky [Page 19] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + 304 Passive service not available + 305 Invalid Foreign Address Primary Component + 306 Invalid Transmit Discipline + 307 Invalid Foreign Address Secondary Component + 308 Invalid Local Address Secondary Component + 309 Invalid Timeout Interval + 310 Invalid Type of Service Advice + 311 Invalid Flow control Advice + 312 Invalid Local Address Primary Component + 401 Protocol Interpreter in OPE not responding + 402 Remote Protocol Interpreter not available + 403 Failed; insufficient protocol interpreter resources + 501 Failed; insufficient OPE resources + 601 Request violates security policy + 602 Security parameter problem + + Additionally, protocol idiosyncratic responses will be defined + for each off-loaded protocol. + + Example of Begin Command + + The Begin command is the most complex of the H-FP Command + Level. When the off-loaded protocol is TCP, the Begin command + is used to open TCP connections. One possible example of a + Begin command issued by an inboard Telnet interpreter to open a + TCP connection to ISIA, with no begin timeout interval, is: + + C BE TCP A ISIA 9 N 23 ,, ,, N0 S <nl> + + Where: + + TCP The code for the protocol TCP + A Indicates Active Begin + ISIA The name of a Host at USC-ISI + 9 Mediation Level 9: Full OPE mediation + N Non-blocking transmit + 23 Destination Telnet Port + ,, skip over parameters (Local Address Secondary, + Begin Timeout Interval) + N0 Type of Service Advice: No special Advice, + Normal Precedence + S Flow Control Advice: use small blocks + + This command will cause the OPE to invoke the TCP interpreter + 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 + + +Lilienkamp & Mandell & Padlipsky [Page 20] + + + +RFC 929 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. + + + + +Lilienkamp & Mandell & Padlipsky [Page 21] + + + +RFC 929 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 + + + +Lilienkamp & Mandell & Padlipsky [Page 22] + + + +RFC 929 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. + + + + + +Lilienkamp & Mandell & Padlipsky [Page 23] + + + +RFC 929 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 + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 24] + + + +RFC 929 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 + + +Lilienkamp & Mandell & Padlipsky [Page 25] + + + +RFC 929 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). + + + + +Lilienkamp & Mandell & Padlipsky [Page 26] + + + +RFC 929 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 + + + +Lilienkamp & Mandell & Padlipsky [Page 27] + + + +RFC 929 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. + + + + + +Lilienkamp & Mandell & Padlipsky [Page 28] + + + +RFC 929 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. + + + + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 29] + + + +RFC 929 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. + + + + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 30] + + + +RFC 929 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 31] + + + +RFC 929 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. + + + +Lilienkamp & Mandell & Padlipsky [Page 32] + + + +RFC 929 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 + + + +Lilienkamp & Mandell & Padlipsky [Page 33] + + + +RFC 929 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 + + + +Lilienkamp & Mandell & Padlipsky [Page 34] + + + +RFC 929 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. + + + +Lilienkamp & Mandell & Padlipsky [Page 35] + + + +RFC 929 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. + + + + +Lilienkamp & Mandell & Padlipsky [Page 36] + + + +RFC 929 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 + + +Lilienkamp & Mandell & Padlipsky [Page 37] + + + +RFC 929 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. + + + +Lilienkamp & Mandell & Padlipsky [Page 38] + + + +RFC 929 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. + + + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 39] + + + +RFC 929 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. + + +Lilienkamp & Mandell & Padlipsky [Page 40] + + + +RFC 929 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. + + + + +Lilienkamp & Mandell & Padlipsky [Page 41] + + + +RFC 929 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 + + +Lilienkamp & Mandell & Padlipsky [Page 42] + + + +RFC 929 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 + + +Lilienkamp & Mandell & Padlipsky [Page 43] + + + +RFC 929 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. + + +Lilienkamp & Mandell & Padlipsky [Page 44] + + + +RFC 929 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 + + + +Lilienkamp & Mandell & Padlipsky [Page 45] + + + +RFC 929 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 + for this purpose. They are based heavily on the Telnet + negotiation and subnegotiation mechanisms. For simple + negotiations there are two parameters, a negotiation type + (from the set {DO, DONT, WILL, WONT}) followed by the code + (numeric) or name (symbolic) for the desired option. The + codes for the options are identified below. A basic + difference between the H-FP interface to Telnet and the + internal Telnet protocol is that additional parameters are + included with the request (DO or WILL). The Telnet protocol + subnegotiation is used internally to communicate that + information in the Telnet data stream. Option-specific, + protocol-idiosyncratic parameters are used for these + additional parameters. + + Both the Host and the OPE can issue these Condition + commands. When issued by the Host, it means the user wishes + to enable or disable a particular option. The OPE proceeds + to issue the appropriate negotiation commands (i.e., IAC + <DO> <code>) in the Telnet data stream. When the results of + the option negotiation are available, a response is + generated by the OPE. For the types DO and WILL, a 000 + Response indicates the appropriate acceptance (WILL or DO, + respectively). A nonzero Response code may indicate + negotiation failure or negotiation rejection (among other + things). For the types DONT and WONT, a 000 Response + indicates the option will be disabled. A negotiation + rejection should not be expected in those cases. + + When the Condition command is issued by the OPE, it means + the other end of the connection is negotiating a change. + Here the response from the Host indicates the Host's desired + action for the option negotiation. Again, valid requests to + disable options (DONT and WONT requests) should always get a + 000 Response. + + 2.3.2. Protocol-Idiosyncratic Parameters + + There are two protocol-idiosyncratic parameters for primary + negotiation using the Condition command. These are the + negotiation type and the option code. The negotiation type + is one of the set of {DO, DONT, WILL, WONT}. The option + code is a numeric value used to identify the particular + + +Lilienkamp & Mandell & Padlipsky [Page 46] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + option being negotiated. The values for these codes are + indicated here, but are identical to the codes used in the + actual Telnet negotiation. The codes are: + + Option Name Option Code Short Name + + Transmit Binary 0 Binary + Echo 1 Echo + Suppress Go-Ahead 3 SuppressGA + Approximate Message Size 4 NAMS + Status 5 Status + Timing Mark 6 TimingMark + RCTE 7 RCTE + Line Length 8 LineLength + Page Size 9 PageSize + Carriage Return Disp 10 CRDisp + Horizontal Tabstops 11 HTabStops + Horizontal Tab Disp 12 HTabDisp + Formfeed Disposition 13 FFDisp + Vertical Tabstops 14 VTabStops + Vertical Tab Disposition 15 VTabDisp + Linefeed Disposition 16 LFDisp + Extended ASCII 17 ExASCII + Logout 18 Logout + Data Entry Terminal 20 DET + Terminal Type 24 TermType + Extended options list 255 ExOptions + + Options not listed here may of course be used. The code + number should be the same as the option code used in Telnet + negotiation. + + 2.3.2.1. Simple Options + + Options that do not require additional parameters use the + simple negotiation mechanisms described briefly above and + in greater detail in the Telnet documentation. No + additional parameters are required. These options + include the Transmit Binary, Echo, Suppress Go Ahead, + Status, Timing Mark, and Logout options. + + 2.3.2.2. Approximate Message Size Option + + The Approximate Message Size option requires two + parameters. The first indicates whether the approximate + message size being negotiated applies to the local or the + remote end of the connection. DS means the size applies + + +Lilienkamp & Mandell & Padlipsky [Page 47] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + to the sender of the command (i.e., if the Host issues + the command, DS means the local end of the connection; + if issued by the OPE, DS means the remote end of the + connection). DR means the size applies to the receiver + of the command (i.e., if the Host issues the command, DR + means the remote end; if issued by the OPE, DR means the + local end of the connection). This convention is + consistent with the Telnet subnegotiation mechanisms. + The second character is an ASCII encoded numeric value, + which is a character count of the message size. + + 2.3.3. Line Width and Page Size Options + + The Line Width and Page Size Options require two additional + parameters. The first indicates whether the line width or + page size being negotiated applies to the local or the + remote end of the connection, and uses the DS and DR + convention described above. The second parameter is an + ASCII encoded numeric value, which is interpreted as follows + (assuming the Condition command was issued by the Host): + + 0 The Host requests that it handle length or size + considerations for the direction indicated by + the first parameter. + + 1 to 253 The Host requests that the remote end handle + the size or length considerations for the + direction indicated by the first parameter, but + suggests that the value indicated be used as + the size or length. + + 254 The Host requests that the remote end handle + the size or length considerations for the + direction indicated by the first parameter, but + suggests that the size or length be considered + to be infinity. + + 255 The Host requests that the remote end handle + the tabstop considerations, and suggests + nothing about what the value should be. + + If the Condition command is issued by the OPE, then the + roles of the Host and the remote end are reversed. + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 48] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + 2.3.4. Tabstop Options + + The Horizontal and Vertical Tabstops options require two + option specific parameters. The first is either DR or DS, + as was described previously. The second is a list of one or + more ASCII encoded numeric values separated by spaces which, + assuming the Condition command is issued by the Host, are + individually interpreted as: + + 0 The Host requests that it handle tabstops for + the direction indicated by the first parameter. + + 1 to 250 The Host requests that the remote end handle + the tabstop considerations for the direction + indicated by the first parameter, but suggests + that the value(s) indicated should be used as + the tabstops. + + 255 The Host requests that the remote end handle + the tabstop considerations for the direction + indicated by the first parameter, and suggests + nothing about what the value should be. + + If the Condition command is issued by the OPE, then the + roles of the Host and the remote end are reversed. + + 2.3.5. Character Disposition Options + + The Carriage Return Disposition option, the Horizontal Tab + Disposition option, the Formfeed Disposition option, the + Vertical Tab Disposition option, and the Linefeed + Disposition option are all considered character disposition + options from the perspective of H-FP. Two option-specific + parameters are required for the character disposition + options. The first is the DR or DS code, which was + described previously. The second is a single ASCII encoded + numeric value, which is interpreted as (assuming that the + Host issued the Condition command): + + 0 The Host requests that it handle the character + disposition for this connection. + + 1 to 250 The Host suggests that the remote end handle + the character disposition considerations, but + suggests that the value indicated should be + taken as the number of nulls which should be + + + +Lilienkamp & Mandell & Padlipsky [Page 49] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + inserted in the data stream following the + particular format character being + subnegotiated. + + 251 The Host suggests that the remote end handle + the character disposition considerations, but + recommends that it replace the character with + some simplified character similar to but not + identical with it (e.g., replace a tab with a + space, or a formfeed with a newline). + + 252 The Host suggests that the remote end handle + the character disposition considerations, but + recommends that it discard the character. + + 253 The Host suggests that the remote end handle + the character disposition, but recommends that + the effect of the character be simulated using + other characters such as spaces or linefeeds. + + 254 The Host suggests that the remote end handle + the character disposition considerations, but + recommends that it wait for additional data + before sending more data. + + 255 The Host suggests that the remote end handle + the tabstop considerations, and suggests + nothing about what the value should be. + + Some of the codes between 251 and 254 are not used with some + character disposition options. Refer to the ARPANET + documentation for additional details. + + If the Condition command is issued by the OPE, then the + roles of the Host and the remote end are reversed. + + 2.3.5.1. RCTE Option + + The Remote Controlled Transmission and Echoing option + requires parameters to indicate the sets of break + characters and transmit characters. There are two + option-idiosyncratic parameters for RCTE. The first is a + list of the character classes that make up the set of + break characters, as defined in the RCTE documentation. + The second is a list of character classes that make up + the set of transmit characters, as defined in the RCTE + documentation. Since the two classes are optional and + + +Lilienkamp & Mandell & Padlipsky [Page 50] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + can be of arbitrary length, it is necessary to precede + each list with a -bc (break characters) or -tc (transmit + characters). The character classes are defined as + + 1 Upper Case Letters A through Z + 2 Lower Case Letters a through z + 3 Digits 0 through 9 + 4 Format effectors <BS> <CR> <LF> <FF> <HT> <VT> + 5 Non-format control codes, plus <ESC> and <DEL> + 6 Punctuation . , ; : ? ! + 7 Grouping { [ ( < > ) ] } + 8 Misc ' ` " / \ % @ $ & + - * = ^ _ | ~ + 9 <space> + + 2.3.5.2. Extended Option List + + The Extended Option List option requires a parameter to + carry the number of the option on the extended list. + There is thus one option specific parameter to the + Condition command when used for this purpose, which is + the number of the option on the extended option list. It + can be expressed in ASCII using an octal, decimal, or + hexadecimal format. + + 2.3.5.3. Terminal Extension Options + + The Extended ASCII, SUPDUP, and Data Entry Terminal + options of Telnet were all attempts to extend the basic + capabilities of the Telnet data stream beyond the simple, + scroll mode terminal model that was the basis of the + original Telnet design. + + All of these options have limitations to their + effectiveness. The Extended ASCII option lacks a + standardized interpretation of the bit patterns into + extended ASCII characters. The SUPDUP effort was + actually an independent mode where a different virtual + terminal protocol was used, and the option was there + merely to switch to and from this protocol. The Data + Entry Terminal option requires the excessive overhead of + subnegotiation for each use of extended features. All of + these options lack the more valuable asset of widespread + implementation and use. + + The way these options should be handled is not detailed + in this appendix. It is clear that the Condition command + could be used for initiating and terminating the use of + + +Lilienkamp & Mandell & Padlipsky [Page 51] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + these options. The actual transmission of characters + related to the extended terminal features should be + provided by the Transmit command, either as part of the + normal Host-to-OPE data stream or by using + protocol-idiosyncratic parameters. + + A more recent option, the Terminal Type option, should be + mentioned here. It permits one end of a connection to + request information about the terminal at the other end + or send information about the terminal at the local end. + This is convenient for systems that provide a wide + variety of terminal support, but it clearly does not + follow the model of reducing the MxN problem by use of a + virtual terminal. Its use is very straightforward in the + H-FP context. It only requires sending the terminal type + to the other end, and activating the Binary Transmission + Option. + + 2.3.5.4. Status Option + + The Status option is enabled using the negotiation + mechanism of Telnet. However, the means to transfer + status information between OPE and the Host is provided + via the Status command. Therefore, details of status + negotiation are irrelevant to the interface to the + outboard Telnet. + + 2.3.6. Examples of the Command + + The following example shows the command issued by a Host to + the OPE, requesting that the OPE negotiate with the other + side so that remote echo is performed. + + C CO -pi DO 1 <nl> + + The numeral 1 is the option code for ECHO from the table + above. All of the simple options listed above use this same + basic format. + + The options with additional parameters use straightforward + extensions of this syntax. For example, a possible usage of + Condition by the Host to set the approximate message size + is: + + C CO -pi DO 4 DS 1024 + + + + +Lilienkamp & Mandell & Padlipsky [Page 52] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + The 4 is the Option Code for the Approximate Message Size + option, the DS indicates that Host's message size should be + set, and 1024 is the desired size. + + 2.4. The Signal Command + + The Signal command is used with Telnet to provide the Telnet + Interrupt Process and Abort Output services. + + 2.4.1. Specialized Usage + + The Signal command is used with an outboard Telnet + interpreter to interface to the Telnet synch mechanism. + This mechanism is used with a protocol-idiosyncratic + parameter, which indicates what particular command is being + "synched." It is expected that normally, this Signal + mechanism will only be used with the Interrupt Process and + Abort Output Telnet signals. When the Signal command is + issued by the Host, it goes through the Channel + (out-of-band) to the OPE, where the Telnet interpreter + issues the corresponding Telnet signal and synch sequence. + When such a sequence is received by the OPE, it immediately + issues a Signal to the Host. It is expected that a Host or + OPE would not, in general, reject the Signal command unless + it is badly formed. + + 2.4.2. Protocol-Idiosyncratic Parameters + + The Telnet protocol-idiosyncratic parameter used with the + Signal command identifies which Telnet signal is begin + issued. Normally, it would have the value of either "IP" or + "AO", for Interrupt Process or Abort Output. If absent, the + default value is "IP". + + 2.4.3. Examples of the Command + + An example of a Telnet Signal Command (in this case, to send + an Interrupt Process signal) is: + + C SI IP <nl> + + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 53] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + 2.5. The Status Command + + The Status command is used with Telnet to obtain information + about the Telnet connection and the options in effect. + + 2.5.1. Specialized Usage + + The Status command has one specialized aspect when used to + interface to an outboard Telnet interpreter. That is to + send and receive the Telnet Protocol status request + subnegotiation message to and from the data stream. In + order to invoke the status command for this purpose, + however, the user must have previously issued the Condition + Status command, which causes the ability to request status + to be negotiated. The OPE, when it receives a valid Status + request command, immediately responds to the user indicating + the status. The OPE can issue a status to request the + Host's negotiated positions. + + 2.5.2. Protocol-Idiosyncratic Parameters + + There are no protocol-idiosyncratic parameters to the Status + query command. The Status Response command has a single + protocol-idiosyncratic parameter. It is an ASCII string + containing the status of the various options (not at their + default values). + + 2.5.3. Examples of the Command + + An example of a Status Query command is: + + C ST Q + + An example of a Status Response command is: + + F ST R "WILL ECHO DO SUPPRESS-GO-AHEAD + L WILL STATUS DO STATUS" <nl> + + In the previous example, note the opening quote is in the + first chunk, and the closing quote is in the last chunk. + This technique permits parameters to span chunk boundaries. + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 54] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + 2.6. The End Command + + The End command is used to terminate the Telnet connection, + either gracefully or abruptly. + + 2.6.1. Specialized Usage + + The graceful termination of a Telnet requires End commands + to be issued by both the Host and the OPE. This specialized + usage is identical to that of the outboard TCP interface, + however. + + 2.6.2. Examples of the Command + + An example of the graceful End command is: + + C EN G <nl> + + The abrupt End command is similar. + + 2.7. The No-op Command + + The No-op command is used with Telnet so the Host can determine + if the OPE is active, and vice versa. + + 2.7.1. Specialized Usage + + The No-op command has one specialized usage when offloading + Telnet. This is to provide the Telnet Are You There (AYT) + feature. When an (AYT) message is received by the OPE, it + issues a No-op command to the Host. Upon receiving the + response from the Host, the appropriate response is sent + back in the data stream. + + 2.7.2. Protocol Idiosyncratic Parameters + + There are no protocol-idiosyncratic parameters to the No-op + command. + + 2.7.3. Examples of the Command + + An example of the No-op command is: + + C NO <nl> + + + + + +Lilienkamp & Mandell & Padlipsky [Page 55] + + + +RFC 929 December 1984 +Proposed Host-Front End Protocol + + + 3. FTP Offloading + + TBS + + 4. Mail Offloading + + TBS + + 5. Whatever Offloading + + TBS + + Where TBS nominally = To Be Supplied, but really means: We'll argue + through these once we get sufficiently positive feedback on the + others (and on the H-FP as a whole). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lilienkamp & Mandell & Padlipsky [Page 56] + |