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]
`
`Ex.1009.001
`
`DELL
`
`

`

`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]
`
`Ex.1009.002
`
`DELL
`
`

`

`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]
`
`Ex.1009.003
`
`DELL
`
`

`

`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]
`
`Ex.1009.004
`
`DELL
`
`

`

`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]
`
`Ex.1009.005
`
`DELL
`
`

`

`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]
`
`Ex.1009.006
`
`DELL
`
`

`

`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]
`
`Ex.1009.007
`
`DELL
`
`

`

`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]
`
`Ex.1009.008
`
`DELL
`
`

`

`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]
`
`Ex.1009.009
`
`DELL
`
`

`

`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]
`
`Ex.1009.010
`
`DELL
`
`

`

`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]
`
`Ex.1009.011
`
`DELL
`
`

`

`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]
`
`Ex.1009.012
`
`DELL
`
`

`

`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