rfc929.txt

RFC 相关的技术文档

      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