home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 700s / rfc705.txt < prev    next >
Text File  |  1992-10-14  |  71KB  |  2,145 lines
  1.  
  2.  
  3.  
  4. Network Working Group
  5. Request for Comments:  705
  6. NIC# 33644
  7.                                                          
  8.  
  9.  
  10.  
  11.  
  12.                          FRONT - END PROTOCOL
  13.     
  14.                             B6700 VERSION
  15.  
  16.  
  17.  
  18.  
  19.                            2 September 1975
  20.  
  21.  
  22. This is a working document which has been developed as the specification 
  23. and guideline for design of a Burroughs B6700 attachment to an ARPA-Style
  24. network.
  25.  
  26. The approach is to utilize a front-end processor with a new protocol for 
  27. network operation.  That protocol, described herein, has been built upon
  28. the concepts expressed by M.A. Padlipsky, et al, in NIC# 31117, RFC# 647.
  29.  
  30. This proposed, site-specific, FEP implementation is the work of Gerald 
  31. Bailey and Keith McCloghrie of NSA and of David Grothe of ACC.  It has 
  32. already sustained some corrections provided by MAP.  It will be helpful
  33. if interested networkers will review and provide comments to us.
  34.  
  35. Comments to BRYAN@ISI.
  36.  
  37. Roland Bryan - ACC                            1
  38.  
  39.  
  40.  
  41. Network Working Group
  42. Request for Comments:  705
  43. Front-End Protocol: B6700 Version
  44.  
  45.  
  46.  
  47.                         ***WORKING DOCUMENT***
  48.  
  49.  
  50.                           FRONT-END PROTOCOL
  51.  
  52.  
  53.                                PREFACE
  54.  
  55. This document describes the protocol to be used for connecting a general-
  56. purpose computer system (host) to an ARPANET-like network via a "front-end" 
  57. computer.  The main body of the document is aimed at a reader who is not 
  58. conversant with all the details of network protocols.  However, a paragraph
  59. marked with [n], refers a reader familiar with network protocols to the
  60. n-th item of Appendix A which will amplify that particular paragraph.  
  61. Further information on the network protocols referred to in this document 
  62. can be obtained from the Network Information Center.
  63.  
  64. Appendix B contains diagrams showing the transitions between the different
  65. connection states.  Appendices C and D give the implementation details of 
  66. this protocol in the Front-End and the Hosts.
  67.  
  68. This protocol is predicated upon the assumption that for each host, a line
  69. protocol, at a lower level, will be established between the device-driver
  70. modules in the Host and the Front-End, and that this line protocol provides
  71. Front-End Protocol with error-free transmissions.
  72.  
  73.  
  74.                              INTRODUCTION                2
  75.  
  76. A host computer may be connected to a network for a variety of reasons.  
  77. Network connection may be an attempt to expand the usefulness of the
  78. Host to the community of users which it serves by making network resources
  79. available to them.  Conversely, the services which the Host provides may 
  80. be made available to a larger community of users, with the network providing 
  81. the method of access to those services.
  82.  
  83. In order for members of a network community to communicate in an intelligent 
  84. way, there must exist a set of protocols.  The implementation of these 
  85. protocols in a host computer is typically called the Network Control Program
  86. (NCP).  The size and complexity of the NCP is proportional to the number and 
  87. complexity of protocols which it implements.  For an ARPANET like network,
  88. both the number and complexity are substantial.
  89.  
  90.  
  91.                        ***WORKING DOCUMENT***
  92.  
  93.  
  94.                                  1
  95.  
  96.  
  97.  
  98. RFC 705
  99. Front-End Protocol
  100.  
  101.  
  102.                         ***WORKING DOCUMENT***
  103.  
  104.  
  105. A host which directly connects into the network must assume the responsibility
  106. for implementing this set of protocols.  That is the "price of admission"
  107. to become a network host.  It is not necessary to implement every protocol
  108. and every option in every host, but even in the simplest case -- implementation
  109. of an NCP is not a small task.  The intrusion into the normal operating
  110. environment of the host is also not small.
  111.  
  112. An alternative method for network connection is to connect the host to some
  113. intermediate processor, and in turn, directly connect that processor to the
  114. network.  This approach is called "Front-Ending."  There are many arguments
  115. which may be posed to justify a host connection to a network through a front-
  116. end processor.  The most obvious being that the responsibility for 
  117. implementation of the network protocols (the NCP) can be delegated to the
  118. front-end (FE), thereby reducing the impact on the host.
  119.  
  120. The purpose of this document is not to justify Front-Ending as a philosophy,
  121. but rather, to introduce a protocol for communications between a host and
  122. a front-end processor which is providing it network access.  The Front End
  123. Protocol (FEP) is intended to permit the host to make use of the network 
  124. through existing protocols, without requiring that it be cognizant of the 
  125. complexities and implementation detail inherent in their execution.
  126.  
  127. The FEP is sufficiently general to permit its implementation in the host 
  128. to be in terms of the function the host is performing, or the services
  129. which it is providing.  Of primary consideration in specification of FEP
  130. was that it must provide the host with a sufficiently robust command 
  131. repertoire to perform its network tasks, while buffering it from the
  132. details of network protocols.
  133.  
  134.  
  135.                                CONCEPTS                    3
  136.  
  137. Introduction                                3a
  138.  
  139. Before a detailed description of the command structures is undertaken it 
  140. seems appropriate to introduce several of the concepts upon which the FEP
  141. is predicated.
  142.  
  143. The following section serves to briefly describe the FEP commands, and to
  144. elaborate on the concepts of addressing and types of connections provided.
  145.  
  146.  
  147.  
  148.                        ***WORKING DOCUMENT***
  149.  
  150.  
  151.                                   2
  152.  
  153. RFC 705
  154. Front-End Protocol
  155.  
  156.  
  157.                         ***WORKING DOCUMENT***
  158.  
  159.  
  160. Commands  (General)                            3b
  161.  
  162. 1.  BEGIN Command
  163.  
  164. This command is sent from the host to the front-end processor.  Its function
  165. is to direct the establishment of one or more network connections.  The type
  166. and number of connections is specified in the BEGIN command string.
  167.  
  168. 2.  LISTEN Command
  169.  
  170. Through this command the host indicates its willingness to accept requests
  171. for connection arriving from other hosts.  It directs the front-end processor
  172. to LISTEN for any such connection requests.  The number and type of 
  173. connections are specified in the command string.
  174.  
  175. 3.  RESPONSE Command
  176.  
  177. The front-end processor uses the RESPONSE command to indicate to the host that
  178. a particular path specified in a BEGIN or LISTEN command is now open or that
  179. the open attempt failed.
  180.  
  181. 4.  MESSAGE Command
  182.  
  183. Message text passing between the host and its front-end processor is sent in
  184. this command string.  The MESSAGE command is bi-directional, and is the same 
  185. for host or front-end.
  186.  
  187. 5.  INTERRUPT Command
  188.  
  189. The INTERRUPT command is sent by either the host of FE.  Its most common use is
  190. to convey that the user wishes to terminate what he is doing - i.e., he has 
  191. depressed the Control-C, ATTN, or INT key.
  192.  
  193. 6.  END Command
  194.  
  195. One or more connections may be closed by either the FE or the host issuing
  196. this command.  The connection(s) which are affected by the action of the END  
  197. are specified in the command string.
  198.  
  199. 7.  REPLY Command
  200.  
  201. This command is required to be sent by both the host and FE to acknowledge
  202. receipt of all command types (except REPLY).  The success or failure of the
  203. command being acknowledged is conveyed in the REPLY command string.
  204.  
  205.  
  206.  
  207.                        ***WORKING DOCUMENT***
  208.                                  
  209.  
  210.                                  3
  211.  
  212.  
  213. RFC 705
  214. Front-End Protocol
  215.  
  216.  
  217.                         ***WORKING DOCUMENT***
  218.  
  219.  
  220.  
  221. Connections                                  3c
  222.  
  223. In order to engage in a meaningful conversation, the parties involved must
  224. be connected.  A network connection is defined by the ARPA Host-Host Protocol
  225. document (Nic #8246) as follows : "A connection couples two processes so
  226. that output from one process is input to the other.  Connections are defined
  227. to be unidirectional, so two connections are necessary if a pair of processes
  228. are to converse in both directions."  The components of a connection, the
  229. sockets, are defined: "... a socket forms the  reference for one end of a
  230. connection, and a connection is fully specified by a pair of sockets.  A 
  231. socket is identified by a Host number and a 32-bit socket number.  The same
  232. number in different Hosts represents different sockets."
  233.  
  234. The existing network protocols incorporate prescribed strategies for 
  235. selecting socket assignments, pairing sockets to form connections, and in 
  236. the number of connections required to implement the protocol.
  237.  
  238. Conversations, in most cases, are bi-directional.  Thus to simplify the
  239. Host's procedures in these cases, FEP permits duplex connections on which
  240. the Host can both send and receive.  Send only and Receive only connections 
  241. are also available for those situations where communication is one-way.
  242.  
  243. Thus, FEP provides the flexibility to reduce complexity in the Host, in
  244. addition to accommodating existing protocols and allowing for the 
  245. development of new protocols.
  246.  
  247. Addressing                                3d
  248.  
  249. Conversations in FEP are uniquely identified at initiation by some combination
  250. of Host address, Index number, Path number and Socket assignment.  The Host 
  251. address and Socket assignment are required to form the connection(s); there-
  252. after the Index and Path are sufficient to identify the conversation.
  253.  
  254. Host Address
  255.  
  256. If, through the BEGIN command, the local Host explicitly directs the creation
  257. of network connection(s), it must specify the address of the foreign host to
  258. which it desires communication.  If the local host indicates a willingness to
  259. communicate, through the LISTEN command, the Front-End processor will supply 
  260. the address of the connecting foreign host(s) in its RESPONSE command(s).
  261.  
  262.  
  263.                      ***WORKING DOCUMENT***
  264.  
  265.  
  266.                                  4
  267.  
  268.  
  269. RFC 705
  270. Front-End Protocol
  271.  
  272.  
  273.                      ***WORKING DOCUMENT***
  274.  
  275.     
  276. Socket
  277.  
  278. A socket is either a send socket or a receive socket.  This property is 
  279. called the socket's gender.  The sockets at either end of a network 
  280. connection must be of opposite gender.  As previously defined a socket
  281. forms the reference for one end of a network connection.  To the extent
  282. possible, the FEP shields the Host from the responsibility of assigning
  283. sockets for individual conversations.  However, because the 
  284. socket is a fundamental part of the addressing mechanism of the network,
  285. the Host may need to be aware of socket assignments when establishing
  286. connections.
  287.  
  288. It is through a "well-advertised" socket that a host provides services
  289. to other members of the network community.  The Initial Connection 
  290. Protocol (ICP) [1] is used to first connect to the well-advertised socket
  291. in order to exchange the number of a presently unused socket which is then
  292. used for the connections required so that the well-advertised socket can
  293. be freed for others attempting to connect.
  294.  
  295. When establishing a conversation (with a BEGIN or LISTEN command) the 
  296. Host indicates in the value of the CONN-TYPE field whether the socket 
  297. specified is to be employed directly, or to be used as an initial 
  298. connection socket.
  299.  
  300. Index/Path Addressing                            3e
  301.  
  302. Indexes are values assigned by the local Host to identify network con-
  303. versations.  When conversations are established (with the BEGIN or LISTEN 
  304. commands) the Host must specify an index value.  This value will be
  305. associated with the resultant conversations for their duration.
  306.  
  307. It is often necessary to affiliate conversations [2].  To accommodate this, 
  308. data paths are defined such that each index has one or more path(s) 
  309. associated with it (a path can not exist except as a subordinate to an
  310. index) and all network communication is transmitted on some path.
  311.  
  312. The maximum number of indexes which may be in use at any one time, and the
  313. maximum number of paths within one index are installation parameters.
  314.  
  315. Index 0 is reserved for controlling other indexes, and logically represent the
  316. "pipe" through which all other indexes "flow."
  317.  
  318.  
  319.  
  320.                        ***WORKING DOCUMENT***
  321.  
  322.  
  323.                                  5
  324.  
  325.  
  326.  
  327. RFC 705
  328. Front-End Protocol
  329.  
  330.  
  331.                         ***WORKING DOCUMENT***
  332.  
  333.  
  334. Addresses in FEP command strings are conveyed by the pair of fields "INDEX"
  335. and "PATH."  In commands which cause new indexes to be opened, or new data 
  336. paths to be added to an existing index (BEGIN or LISTEN), the PATH field 
  337. indicates the first path to be acted upon by this command.  For those
  338. commands which do not create new paths or indexes, if PATH is 0, then all
  339. paths associated with this INDEX are addressed; if PATH is non-zero, only the 
  340. specific path within the specified INDEX is addressed.
  341.  
  342. Path Types                                3f
  343.  
  344. A path can be one of three types:
  345.  
  346.     a.  DUPLEX - both the Host and the FE can issue MESSAGE commands
  347.         on the path.
  348.  
  349.     b.  SEND - only the Host can issue MESSAGE commands on the path.
  350.  
  351.     c.  RECEIVE - only the FE can issue MESSAGE commands on the path.
  352.  
  353. The paths within an index may be a mixture of path types but one BEGIN/
  354. LISTEN must be used for each contiguous set of the same type.
  355.  
  356. An FEP path is analogous to a network connection with the following exception.
  357. Network connections are always simplex.  This is true for paths of type SEND
  358. or RECEIVE.  However, a DUPLEX path is formed by the FE connecting two local
  359. sockets to two foreign sockets.  This is a "duplex connection" which is
  360. composed of two network (simplex) connections.
  361.  
  362. Modes of Establishing a Path                        3g
  363.  
  364. One or more paths are established by the action of a single BEGIN or LISTEN
  365. command, with the mode specified in the CONN-TYPE field of the command.
  366. Each of the path types is established in one of two modes - directly or via 
  367. ICP.  The gender of the path (its ability to receive or send or both) is not
  368. affected by the mode.
  369.  
  370. When any of the path types is specified with the ICP mode, the socket value
  371. in the SOCKET field is used as the "well-advertised" socket and an actual
  372. working socket will be exchanged according to the Initial Connection Protocol.
  373. When the direct mode is indicated, the specified socket is used as the working
  374. socket.
  375.  
  376.  
  377.  
  378.                         ***WORKING DOCUMENT***
  379.  
  380.  
  381.                                  6
  382.  
  383. RFC 705
  384. Front-End Protocol
  385.  
  386.  
  387.                         ***WORKING DOCUMENT***
  388.  
  389.  
  390.  
  391. In either mode, when multiple paths are indicated, the next higher socket
  392. number values of the appropriate gender are selected for each path. [3]
  393.  
  394. Translation                                3h
  395.  
  396. When the Host sets up a path(s) (with a BEGIN or LISTEN command) it identifies
  397. what type of translation or data-mapping it requires the FE to perform on all
  398. data transmitted on this path(s).  This is specified by two values - one
  399. giving the format of the data transmitted between the FE and the network,
  400. the other giving the format of the data between the Host and the FE. [4]
  401.  
  402. Flow Control                                3i
  403.  
  404. All commands (except REPLYs) must be REPLYED to by the receiver.  The sender
  405. is blocked from sending more commands on the same path until a REPLY has been
  406. received.  The REPLY command serves two functions:  it indicates the
  407. success/failure of the last transmission on the path, and it also indicates
  408. a willingness of the receiver to accept more data on that path.  Receipt of
  409. any valid REPLY on an open path is sufficient to unblock it for END or
  410. INTERRUPT commands.  Thus a receiver who will not (or can not) accept more
  411. data (MESSAGE commands) on a given path need not block the sender from
  412. ENDing the path if he desires.  An indication of "READY" in the reply serves
  413. to unblock the path for MESSAGE commands also.
  414.  
  415. In the normal case, the REPLY performs both functions concurrently.  However,
  416. when the receiver is not ready to accept more data, he can REPLY indicating
  417. only success/failure of the last command which should be sufficient to
  418. allow the sender to free the transmission buffer, requeue the command for
  419. retransmission if necessary, etc. and wait for another REPLY command 
  420. announcing the receiver's ability to accept more data.
  421.  
  422. Exceptional Conditions                            3j
  423.  
  424. When a command is received and can not be executed, the REPLY command is used
  425. to notify the sender of the command.  To do this, the bits of CODE field of
  426. the REPLY are set to show the CATEGORY of the error and its TYPE within that
  427. category (see Section 3h).
  428.  
  429.  
  430.  
  431.                         ***WORKING DOCUMENT***
  432.  
  433.  
  434.                                  7
  435.  
  436.  
  437. RFC 705
  438. Front-End Protocol
  439.  
  440.  
  441.                         ***WORKING DOCUMENT***
  442.  
  443.  
  444.  
  445.                                COMMANDS                    4
  446.  
  447.  
  448. Introduction                                4a
  449.  
  450. All communications between the Host and the FE is performed by means of
  451. commands.  The commands are given names for documentation purposes but are
  452. distinguished by the binary value of the first field of the command string.
  453. Command strings will be padded with zeros up to the next multiple of an
  454. installation defined parameter.  (This value will be dependent on the 
  455. capabilities of the hardware interface between the Host and the FE.)
  456.  
  457. Field lengths within a command string are specified as some number of bits.
  458. These information bits will be right-justified within the least number of
  459. bytes needed to hold them.  The size of a byte will be an installation
  460. parameter which will normally be 8 bits but other values will be accommodated
  461. as necessary.
  462.  
  463. The values and meanings of the CODE field of the REPLY command are given for
  464. each command within the following descriptions:
  465.  
  466. 1:  BEGIN                                4b
  467.  
  468. Format
  469.  
  470.            BEGIN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHS
  471.  
  472. Use
  473.  
  474. This command is sent only from the Host to the FE.  Its function is to direct
  475. the FE to establish one or more logical connections (paths) on the specified
  476. index between the Host and the FE.
  477.  
  478. Its use has three different modes (depending on the value of the PATH field) :
  479.  
  480.     mode (a) - to set up a new index and to direct the FE to attempt
  481.     to establish network connections for the one or more paths
  482.     specified within this index.
  483.  
  484.  
  485.  
  486.                        ***WORKING DOCUMENTS***
  487.  
  488.  
  489.                                  8
  490.  
  491.  
  492. RFC 705
  493. Front-End Protocol
  494.  
  495.  
  496.                         ***WORKING DOCUMENT***
  497.  
  498.  
  499.  
  500.     mode (b) - to attempt to establish network connections for an
  501.     existing (but at present closed) path within the already set-up
  502.     index.
  503.  
  504.     Mode (c) - to attempt to establish network connections for
  505.     one or more new paths within the already set-up index.
  506.  
  507. Parameters
  508.  
  509.     a)  BEGIN is an 8-bit field with the value 1.
  510.  
  511.     b)  INDEX is a 16-bit field, specifying the index.  Note that
  512.             the value 0 is reserved for special use (see Section 4).
  513.  
  514.     c)  PATH is an 8-bit field, specifying the path(s) which are
  515.         to be established.  Its value identifies the mode of the
  516.         BEGIN (see above) :
  517.  
  518.         mode (a) - its value must be 1.
  519.  
  520.         mode (b) - its value must be that of the path to be
  521.         "re-opened."
  522.  
  523.         mode (c) - its value must be exactly one greater than
  524.         the current number of paths defined within this index.
  525.  
  526.     d)  HOST is a 32-bit field specifying the foreign host with
  527.         which connections are to be established.
  528.  
  529.     e)  SOCKET is a 32-bit field, specifying the first or only
  530.         socket at the foreign host to which connections are to 
  531.         be made.
  532.  
  533.           f)  TRANS-TYPE is a 16-bit field which directs the FE to
  534.         perform this type of translation on all data (i.e. TEXT
  535.         in the MESSAGE command string) sent on every path being
  536.         established by this command.  The first 8 bits specify
  537.         the format of the data on the network side; the second 
  538.         8 bits specify the format of the data on the Host side.     
  539.         The values assigned to the particular formats (eq. ASCII,
  540.         EBCDIC etc.) are installation parameters; however, the
  541.  
  542.  
  543.                         ***WORKING DOCUMENT***
  544.  
  545.  
  546.                                  9
  547.  
  548.  
  549. RFC 705
  550. Front-End Protocol
  551.  
  552.  
  553.                         ***WORKING DOCUMENT***
  554.  
  555.  
  556.         value 0 will always mean "bit string" and thus if either
  557.         of the 8-bit sub-fields contains 0, then no mapping will
  558.         be performed.
  559.  
  560.         g)  CONN-TYPE is an 16-bit field, specifying the type and mode
  561.         of connection(s) to be established for the specified path(s).
  562.         Its value informs the FE how to associate sockets with
  563.         indexes/paths (see Sections 2f and 2g).
  564.  
  565.         Value         Type         Mode
  566.  
  567.           7        Duplex        via ICP
  568.           6        Duplex        direct
  569.           5        Receive        via ICP
  570.           4        Receive        direct
  571.           3        Send        via ICP
  572.           2        Send        direct
  573.  
  574.         h)  NPATHS is an 8-bit field, specifying the number of paths which
  575.     this command directs the FE to attempt to establish connections
  576.     for.  If the BEGIN is of mode (b) then its value must be 1.
  577.     Otherwise the sum of its value and the value of the PATH field
  578.     is the new current number of paths plus one.
  579.  
  580. Error CODES in REPLY
  581.  
  582.     Category   Type            Meaning
  583.             
  584.        3         1        PATH invalid for new index
  585.        3         2        PATH invalid for old index
  586.        3         3        PATH already open
  587.        3         4        HOST unknown
  588.        3         5      TRANSLATION-TYPE invalid
  589.        3         6        CONNECTION-TYPE invalid
  590.        3         7        NPATHS invalid for old path on old index
  591.        3         8        Specified socket inconsistent with CONN-TYPE
  592.        3         9        INDEX invalid, not ready for business
  593.        4         1        No new connections - FE full
  594.        4         2        No new connections - closing down soon
  595.  
  596.  
  597.                         ***WORKING DOCUMENT***
  598.  
  599.  
  600.                                   10
  601.  
  602.  
  603. RFC 705
  604. Front-End Protocol
  605.  
  606.  
  607.                         ***WORKING DOCUMENT***
  608.  
  609.  
  610. 2:  LISTEN                                4c
  611.  
  612. Format
  613.  
  614.     LISTEN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHS
  615.  
  616. Use
  617.  
  618. This command is sent only from the Host to the FE.
  619.  
  620. Its function is to direct the FE to "listen," i.e., to hold the specified paths
  621. pending until such time as a request for connection (RFC) is received from the 
  622. network to the specified local socket. then to set up connections and to 
  623. respond with a RESPONSE command for each path.
  624.  
  625. Its use has three different modes (depending on the value of the PATH field) :
  626.  
  627.     mode (a) - to set up a new index and to listen on the specified local
  628.     socket in order to establish connections for the specified paths.
  629.  
  630.     mode (b) - to listen on the specified socket in order to establish
  631.     connections for the specified, existing (but at present closed)
  632.     path within the already set-up index.
  633.  
  634.     mode (c) - to listen on the specified socket in order to establish
  635.     connections for the specified new path(s) within the already set-up
  636.     index.
  637.  
  638. By use of the HOST parameter, the FE can be directed to accept RFCs from any
  639. host or only from the specified host.
  640.  
  641. Parameters
  642.  
  643.     a)  LISTEN is an 8-bit field with value 2.
  644.  
  645.     b)  INDEX is a 16-bit field specifying the index.
  646.  
  647.     c)  PATH is an 8-bit field specifying the first of the one or more
  648.         paths which are to be held pending receipt of a RFC.  Its 
  649.         value identifies the mode of the LISTEN (see above) :
  650.  
  651.  
  652.  
  653.                         ***WORKING DOCUMENT***
  654.  
  655.  
  656.                                   11
  657.  
  658.  
  659. RFC 705
  660. Front-End Protocol
  661.  
  662.  
  663.                         ***WORKING DOCUMENT***
  664.  
  665.  
  666.         mode (a) - its value must be 1.
  667.  
  668.         mode (b) - its value must be that of the existing path.
  669.         
  670.         mode (c) - its value must be exactly one greater than
  671.         the current number of paths within this index.
  672.  
  673.     d)  HOST is a 32-bit field specifying the host from which RFCs
  674.         are to be accepted; a value of 0 implies from any host.
  675.  
  676.     e)  SOCKET is a 32-bit field specifying the local socket on which
  677.         the FE is to listen for RFCs.
  678.  
  679.     f)  TRANS-TYPE is a 16-bit field specifying the type of translation
  680.         the FE is to perform on all data sent on every path established
  681.         as a result of this command.  Its values are the same as in the
  682.         BEGIN command.
  683.  
  684.     g)  CONN-TYPE is an 16-bit field specifying the type and mode of the
  685.         connection(s) to be established for the specified path(s) when
  686.         an RFC is received.  Its values are the same as in the BEGIN
  687.         command.
  688.  
  689.     h)  NPATHS is an 8-bit field specifying the number of paths which
  690.         this command associates with the specified index and which are
  691.         to be established.  If the LISTEN is of mode (b) then its value 
  692.         must be 1.  Otherwise the sum of its value and the value of the
  693.         PATH field is the new current number of paths plus one, within
  694.         this index.  Thus its value is the number of extra RFCs for
  695.         which the FE is listening on this socket.
  696.  
  697. Error CODEs in REPLY
  698.  
  699.     Category      Type            Meaning
  700.  
  701.        3        1    PATH invalid for new index
  702.        3        2    PATH invalid for old index
  703.        3        3    PATH already open
  704.        3        4    HOST unknown
  705.        3            5    TRANSLATION-TYPE invalid
  706.     
  707.  
  708.                         ***WORKING DOCUMENT***
  709.  
  710.  
  711.                                   12
  712.  
  713.  
  714. RFC 705
  715. Front-End Protocol
  716.  
  717.  
  718.                         ***WORKING DOCUMENT***
  719.  
  720.  
  721.        3        6    CONNECTION-TYPE INVALID
  722.        3        7    NPATHS invalid for old path on old index
  723.        3        8    Specified socket inconsistent with CONN-TYPE
  724.        3        9    INDEX invalid, not ready for business
  725.        3           10    Socket already in use.
  726.        4        1    No new listens - FE full
  727.        4        2    No new listens - closing down soon
  728.  
  729. 3:  RESPONSE                                4d
  730.  
  731. Format
  732.  
  733.     RESPONSE INDEX PATH CODE HOST SOCKET
  734.  
  735. Use
  736.  
  737. This command is sent only from the FE to the Host - once per path specified in
  738. a BEGIN or a LISTEN command.
  739.  
  740. For paths specified in a BEGIN, it is sent to indicate the success or failure
  741. of the connection attempt.  For paths specified in a LISTEN, it is sent at
  742. the time when the FE has received a matching RFC and has established the
  743. connection.
  744.  
  745. The HOST and SOCKET parameters are purely informational which the Host can 
  746. ignore if it so desires.  Their contents are only guaranteed if the connection
  747. attempt succeeded.
  748.  
  749. Parameters
  750.  
  751.     a)  RESPONSE is an 8-bit field with value 3.
  752.  
  753.     b)  INDEX is a 16-bit field specifying the index.
  754.  
  755.     c)  PATH is an 8-bit field specifying the particular path.
  756.  
  757.     d)  CODE is a 16-bit field indicating the outcome of the
  758.         connection attempt:
  759.  
  760.  
  761.                         ***WORKING DOCUMENT***
  762.  
  763.  
  764.                                   13
  765.  
  766.  
  767. RFC 705
  768. Front-End Protocol
  769.  
  770.  
  771.                         ***WORKING DOCUMENT***
  772.  
  773.  
  774.         Value            Meaning
  775.  
  776.           0        Path successfully established.
  777.           1        Local IMP dead.
  778.           2        Foreign IMP inaccessible.
  779.           3        Foreign Host dead.
  780.           4        Foreign Host not responding.
  781.           5        Connection refused.
  782.  
  783.     e)  HOST is a 32-bit field specifying the foreign host to which the
  784.         connection has been made.
  785.  
  786.     f)  SOCKET is a 32-bit field specifying the socket at the foreign
  787.         host.  If the connection type is simplex, then it is the only
  788.         foreign socket for this path; if duplex, then it is the lower
  789.         of the two foreign sockets.
  790.  
  791. Error CODES in REPLY
  792.  
  793.         Category    Type       Meaning
  794.  
  795.            3         11    INDEX unknown
  796.            3         12    PATH unknown
  797.            3         13    CODE invalid
  798.  
  799. 4:  MESSAGE                                4e
  800.  
  801. Format
  802.  
  803.     MESSAGE INDEX PATH COUNT PAD TEXT
  804.  
  805. Use
  806.  
  807. This command is sent by either the Host or the FE to transmit data on the
  808. specified path and index.
  809.  
  810. Parameters
  811.  
  812.     a)  MESSAGE is an 8-bit field with value 4.
  813.  
  814.     b)  INDEX is a 16-bit field specifying the index.
  815.  
  816.  
  817.                         ***WORKING DOCUMENT***
  818.  
  819.  
  820.                                   14
  821.  
  822.  
  823. RFC 705
  824. Front-End Protocol
  825.  
  826.  
  827.                         ***WORKING DOCUMENT***
  828.  
  829.  
  830.     c)  PATH is an 8-bit field specifying the path.  Note that the value
  831.         0 is used in the broadcast option (see Section 3j).
  832.  
  833.     d)  COUNT is a 16-bit field specifying the number of bits of data
  834.         in the TEXT field.
  835.  
  836.     e)  PAD is an n-bit field, where n is an installation parameter.
  837.         It contains only padding (in the present protocol specification)
  838.         and can be used to enable the host to have the TEXT field start
  839.         on a convenient boundary.
  840.  
  841.     f)  TEXT is a field containing COUNT bits of data being transmitted
  842.         on this path.
  843.  
  844. Error CODES in REPLY
  845.  
  846.     Category    Type        Meaning
  847.  
  848.        2          1    This option not implemented       
  849.            3         12    PATH unknown
  850.        3         14    No connection opened in this direction
  851.        3         15    PATH blocked at this time, resent later
  852.        3         16    PATH suspended at this time, resent later
  853.        3         17    PATH closed
  854.        3         17    COUNT too large
  855.        4          3    Error in transmitting data, resend command
  856.        4          4    Data lost, resent command.
  857.  
  858. 5:  INTERRUPT                                4f
  859. Format
  860.  
  861.     INTERRUPT INDEX PATH CODE
  862. Use
  863.  
  864. This command is sent by either the Host or the FE.
  865.  
  866. Its most common use is to pass the information that a terminal user has
  867. pressed his INT (or ATTN or Control-C) key, thereby requesting his 
  868. applications program to quit what it is doing for him.[5]
  869.  
  870.  
  871.                         ***WORKING DOCUMENT***
  872.  
  873.  
  874.                                   15
  875.  
  876.  
  877. RFC 705
  878. Front-End Protocol
  879.  
  880.  
  881.                         ***WORKING DOCUMENT***
  882.  
  883.  
  884. Parameters
  885.  
  886.     a)  INTERRUPT is a 8-bit field with value 5.
  887.  
  888.     b)  INDEX is a 16-bit field specifying the index.
  889.  
  890.     c)  PATH is an 8-bit field specifying the path on which the
  891.         INTERRUPT is transmitted.  Note that the value 0 is used in
  892.         the broadcast option (see Section 3j).
  893.  
  894.     d)  CODE is a 16-bit field.  It has no defined meanings as yet
  895.         and should contain 0.
  896.  
  897. Error CODES in REPLY
  898.  
  899.     Category    Type        Meaning
  900.  
  901.        2          1    This option not implemented
  902.        3         11    INDEX unknown
  903.        3         12    PATH unknown
  904.        3         14    No connection opened in this direction
  905.        3         15     PATH blocked at this time, resend later
  906.        3         17    PATH closed.
  907.  
  908. 6:  END                                      4g
  909.  
  910. Format
  911.  
  912.     END INDEX PATH CODE
  913.  
  914. Use
  915.  
  916. This command is sent by either the Host or the FE, to terminate a connection.
  917. If PATH is 0, then the index and all its paths are terminated, otherwise just
  918. the specified path of the index is terminated.
  919.  
  920. Parameters
  921.  
  922.     a)  END is an 8-bit field with value 6.
  923.  
  924.     b)  INDEX is a 16-bit field specifying the index.
  925.  
  926.  
  927.                        ***WORKING PARAMETER***
  928.  
  929.  
  930.                                   16
  931.  
  932.  
  933. RFC 705
  934. Front-End Protocol
  935.  
  936.  
  937.                         ***WORKING DOCUMENT***
  938.  
  939.  
  940.     c)  PATH is an 8-bit field containing the path to be closed, or 0 if
  941.         the whole index is to be closed.
  942.  
  943.     d)  CODE is a 16-bit field indicating the reason for the closure:
  944.  
  945.         Value         Meaning
  946.  
  947.           0    Normal close
  948.           1    Retries exhausted
  949.           2    Foreign Host failure
  950.           3    Foreign IMP failure
  951.           4    Network failure
  952.           5    Local IMP failure.
  953.  
  954.         The "Retries exhausted" code indicates that the FE has been 
  955.         retrying a transmission to the foreign host without success.
  956.  
  957. Error CODES in REPLY
  958.  
  959.     Category    Type        Meaning
  960.  
  961.        3         11    INDEX unknown
  962.        3         12    PATH unknown
  963.        3         13    CODE unknown
  964.        3         15    PATH blocked at this time, resend later
  965.        3         17    PATH closed.
  966.  
  967. 7:  REPLY                                   4h
  968.  
  969. Format
  970.  
  971.     REPLY INDEX PATH CODE
  972.  
  973. Use
  974.  
  975. This command is sent by both the Host and the FE to acknowledge receipt of 
  976. every other type of command (including those on index 0, see Section 4) and/or
  977. to unblock that particular direction of an opened path for the transmission
  978. of another command.
  979.  
  980. Note that the INDEX and PATH fields contain exactly the same as those of the
  981. command being replied to.
  982.  
  983.  
  984.                         ***WORKING DOCUMENT***
  985.  
  986.  
  987.                                   17
  988.  
  989.  
  990. RFC 705
  991. Front-End Protocol
  992.  
  993.  
  994.                         ***WORKING DOCUMENT***
  995.  
  996. Parameters
  997.  
  998.     a)  REPLY is an 8-bit field with value 7.
  999.  
  1000.     b)  INDEX is a 16-bit field specifying the index.
  1001.  
  1002.     c)  PATH is a 8-bit field specifying the path.
  1003.  
  1004.     d)  CODE is a 16-bit field indicating the success/failure of the
  1005.         command being REPLYed to, and the sender's readiness for more
  1006.         commands on the same path.  It is divided into four subfields -
  1007.         STATUS, COMMAND, CATEGORY, and TYPE.    
  1008.  
  1009.         1)  STATUS is 4 bits wide
  1010.             
  1011.             bit 0 (right-most) - READY
  1012.             bit 1           - NOT-READY
  1013.             bit 2              - ACK
  1014.             bit 3           - NAK
  1015.  
  1016.             ACK=1 indicates that the sender (of the REPLY) has accepted
  1017.         the command (being REPLYed to).  NAK=1 indicates that the
  1018.         sender has discarded the command (with the reason given by
  1019.         the settings of the other bits of the CODE field).
  1020.  
  1021.         NOT-READY=1 indicates that the sender (of the REPLY) is
  1022.         willing to receive an END or INTERRUPT on this path.  
  1023.         READY=1 indicates that MESSAGE commands will also be received.
  1024.  
  1025.         Normally only one REPLY command will be sent for each
  1026.         other command.  However MESSAGE, INTERRUPT, RESPONSE and
  1027.         invalid END commands can be replied to by a REPLY with
  1028.         ACK (or NAK)=1 and NOT-READY=1 and another REPLY, some
  1029.         time later, with READY=1. [6]
  1030.  
  1031.         The ACK and NAK bits are mutually exclusive and should
  1032.         never both be on simultaneously, and similarly the READY
  1033.         and NOT-READY bits.
  1034.  
  1035.         Note that the READY/NOT-READY bit settings are only
  1036.          relevant when a path is open.
  1037.  
  1038.  
  1039.                         ***WORKING DOCUMENT***
  1040.  
  1041.  
  1042.                                   18
  1043.  
  1044.  
  1045. RFC 705
  1046. Front-End Protocol
  1047.  
  1048.  
  1049.                         ***WORKING DOCUMENT***
  1050.  
  1051.         
  1052.         2)  COMMAND is 4 bits wide.  It indicates the command for
  1053.                     which this is a REPLY :
  1054.  
  1055.             Value         Meaning
  1056.  
  1057.               0    any of the following
  1058.               1    BEGIN
  1059.               2    LISTEN
  1060.               3    RESPONSE
  1061.               4    MESSAGE
  1062.               5    INTERRUPT
  1063.               6    END
  1064.  
  1065.             The value 0 is defined for cases where a Host does not
  1066.             wish to incur any overhead required to fill in the
  1067.             non-zero value.
  1068.  
  1069.             3)  CATEGORY is 3 bits wide.  It specifies the category of 
  1070.             the error indicated by the ACK bit being off :
  1071.  
  1072.             Value         Meaning
  1073.  
  1074.               1    Command not recognized
  1075.               2    Option not implemented
  1076.               3    Invalid
  1077.               4    Action failed.
  1078.  
  1079.             Its value is relevant only when NAK=1.
  1080.  
  1081.         4)  TYPE is 5 bits wide.  It specifies which error occurred.
  1082.             Its value is relevant only when NAK=1.  The possible values
  1083.             and meanings for the various errors and their corresponding
  1084.             CATEGORY subfield values are given under the description
  1085.             of each command.
  1086.  
  1087. Sequencing                                  4i
  1088.  
  1089. Once communication between the Host and the FE has been established and each 
  1090. side is "Ready for Business" (see Section 4b) the Host may at any time send
  1091. BEGIN or LISTEN commands for new indexes.  The FE will acknowledge a BEGIN or
  1092.  
  1093.  
  1094.                         ***WORKING DOCUMENT***
  1095.  
  1096.  
  1097.                                   19
  1098.  
  1099.  
  1100. RFC 705
  1101. Front-End Protocol
  1102.  
  1103.  
  1104.                         ***WORKING DOCUMENT***
  1105.  
  1106.  
  1107. LISTEN with a REPLY and the index is then set-up providing that the REPLY
  1108. indicates no errors.  Other BEGIN or LISTEN commands for the new paths on the
  1109. same index may be sent at any time after the index is set-up.
  1110.  
  1111. The FE will send a RESPONSE command for each path on completion of its attempts
  1112. to fulfill the Host's instructions.  If an attempt failed (indicated by the
  1113. CODE field) then the path remains closed and another BEGIN or LISTEN for that 
  1114. path can be sent.  If the attempt was successful, then MESSAGE or INTERRUPT 
  1115. commands can be sent after the Host has REPLYED to the RESPONSE.
  1116.  
  1117. An INTERRUPT or END command may be sent on any opened path after receiving
  1118. a REPLY for the previous command on the same path in the same direction.  A
  1119. MESSAGE command may be sent if in addition the READY bit was on in the last
  1120. REPLY command.
  1121.  
  1122. New paths on the same index may be opened at any time after the index has
  1123. been set-up, or particular paths may be ENDed and then have new BEGINs or
  1124. LISTENs for them issued.  An index remains set-up, even if all its paths are
  1125. closed, until an END command with PATH=0 is issued for the index.
  1126.  
  1127. Communication between the Host and the FE is terminated by an END with INDEX=0
  1128. and this will abort any remaining open paths and indexes.
  1129.  
  1130. Broadcasting                                  4j
  1131.  
  1132. Broadcasting is an optional feature of the protocol.  If it has been enabled
  1133. by the installation parameter, then the Host may send a MESSAGE or INTERRUPT 
  1134. command on a particular index with PATH=0.  This instructs the FE to send the 
  1135. data contained in the TEXT field of the MESSAGE command (or an interrupt) on
  1136. every network connection corresponding to an open path of the specified index.
  1137.  
  1138. This feature will only occur on MESSAGEs from the Host to the FE (since no
  1139. utilization of it in the other direction is envisaged).
  1140.  
  1141. A broadcast MESSAGE is replied to with one or two REPLYs in the same way
  1142. as any other MESSAGE command.  Flow control within the index is maintained
  1143. as if broadcast MESSAGEs were sent on a separate path, i.e., flow control
  1144. on other paths is not directly affected.
  1145.  
  1146.  
  1147.                         ***WORKING DOCUMENT***
  1148.  
  1149.  
  1150.                                   20
  1151.  
  1152.  
  1153. RFC 705
  1154. Front-End Protocol
  1155.  
  1156.  
  1157.                         ***WORKING DOCUMENT***
  1158.  
  1159.  
  1160. Note that for a broadcast MESSAGE command the FE will perform translation
  1161. on the data for each path in accordance with the BEGIN or LISTEN which
  1162. initiated that path.  Thus, care must be taken when all paths of the
  1163. particular index do not have the same format on the Host side specified in 
  1164. their TRANS-TYPE (see Section 6b).
  1165.  
  1166. Index 0                                      5
  1167.  
  1168. Introduction                                  5a
  1169.  
  1170. Index 0 provides a control link between the Host and the FE, and thus has no
  1171. network connections directly associated with it.  The commands on this index
  1172. are used to establish and terminate the connection between Host and FE and to
  1173. control other indexes.
  1174.  
  1175. Path 0                                      5b
  1176.  
  1177. Path 0 of Index 0 is used to pass global commands - i.e., those which do not
  1178. refer to any particular index or path.  The currently defined commands are :
  1179.  
  1180.     MESSAGE INDEX=0 COUNT PAD TEXT
  1181.  
  1182.         where TEXT = COMMAND [PARM1] [PARM2]
  1183.         COMMAND is 8 bits long
  1184.         PARM1 and PARM2 are 16 bits long
  1185.  
  1186.     a)  COMMAND=1 , PARM1=Hostid
  1187.  
  1188.     This is the "Ready for Business" command which must be sent by both 
  1189.     Host and FE to establish communication between them.  Count gives the
  1190.     length of the TEXT field as usual.  If COUNT=8, then just the COMMAND
  1191.     field is present.  If COUNT=24, then both the COMMAND and Hostid are
  1192.     present.
  1193.  
  1194.     The FE will never send a Hostid.  The Host may send its Hostid in the
  1195.     event that the FE is connected to more than one IMP or if alternate
  1196.     routes to the network exist (e.g., via patch panels).
  1197.  
  1198.     Until both sides have sent this command no other command is valid.
  1199.  
  1200.     b)  COMMAND=2 , PARM1=M , PARM2=N
  1201.  
  1202.  
  1203.                         ***WORKING DOCUMENT***
  1204.  
  1205.  
  1206.                                   21
  1207.  
  1208.  
  1209. RFC 705
  1210. Front-End Protocol
  1211.  
  1212.  
  1213.                         ***WORKING DOCUMENT***
  1214.  
  1215.  
  1216.     This is the "CLOSING" command which is a purely information indication
  1217.     that the sender's FEP module has been told that communication will be
  1218.     terminated in M minutes for a period of N minutes (N=0 implies
  1219.     unknown).
  1220.  
  1221.     No action is required of the receiver, however he may be able to
  1222.     distribute the information to his users.
  1223.  
  1224.     c)  COMMAND=3
  1225.  
  1226.     This is the "CONTINUE" command which indicates that any previous
  1227.     CLOSING command is now no longer true.
  1228.  
  1229.         END INDEX=0 PATH+0 CODE
  1230.  
  1231.     This command terminates the connection between the HOST and FE.  All
  1232.     other paths/indexes are automatically aborted and the FE will close
  1233.     all network connections.  The values of the CODE field are the same
  1234.     as in the general END command.
  1235.  
  1236. Path 1                                      5c
  1237.  
  1238. Path 1 is reserved for commands specific to a particular path or index.  No
  1239. commands are presently defined; they will be at a later date when more
  1240. experience has been gained on the need for them.
  1241.  
  1242. Path 2                                      5d
  1243.  
  1244. Path 2 of Index 0 is used for Operator-to-Operator communication between the
  1245. Host and the FE.  It is an optional feature which is enabled by an installation
  1246. parameter.
  1247.  
  1248. MESSAGE commands are formatted in the normal manner with the sender requesting
  1249. that the TEXT field be displayed to the receiver's system operator.
  1250.  
  1251. Scenarios                                    6    
  1252.  
  1253. The following scenarios are included to provide the reader with a "feeling" for
  1254. FEP in a varied set of applications.  The examples selected relate to existing
  1255. ARPANET protocols or other networking applications, and do not represent an
  1256. exhaustive list of capabilities.                        6a
  1257.  
  1258.  
  1259.                        ***WORKING DOCUMENT***
  1260.  
  1261.  
  1262.                                   22
  1263.  
  1264.  
  1265. RFC 705
  1266. Front-End Protocol
  1267.  
  1268.  
  1269.                         ***WORKING DOCUMENT***
  1270.  
  1271.  
  1272. Fields which are variable or not relevant are not shown (for purposes of 
  1273. clarity) in the command strings in the following examples.          6b
  1274.  
  1275. Host Implementation of User TELNET                      6c
  1276.  
  1277.     BEGIN ndxa,PATH=1,host,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=1
  1278.  
  1279. The User TELNET process in the Host causes the BEGIN command to be issued.  
  1280. When a successful RESPONSE has been returned by the FE, a typical duplex
  1281. TELNET connection will have been made to the Host specified in the BEGIN.
  1282.  
  1283. Host is Providing Server TELNET                          6d
  1284.  
  1285.     LISTEN ndxa,PATH-1,HOST=0,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=32
  1286.  
  1287.  
  1288. With this one command the Server TELNET process in the Host has conditioned
  1289. the FE to LISTEN on Socket 1 (the well-advertised TELNET socket) and to
  1290. establish as many as 32 duplex data paths.  The FE, through the RESPONSE
  1291. command, will report each connection as it occurs.  Path 1 will represent
  1292. the first such duplex connection, etc.  The Host may then manage the data
  1293. paths individually.  Individual paths may be ended and placed back into a
  1294. LISTENing state by the Host.  If at any time an END command specifying this
  1295. INDEX with a PATH of 0 were to be sent by the Host, all connections would
  1296. be dissolved, and for all practical purposes, the Host is no longer willing
  1297. to provide Server TELNET services.
  1298.  
  1299. Host is Providing Server FTP                          6e
  1300.  
  1301.     LISTEN ndxa,PATH=1,HOST=0,SKT=3,,CONN-TYPE=duplex+ICP,NPATH=1
  1302.  
  1303. As soon as a RESPONSE for this LISTEN comes from the FE, the Host Server FTP
  1304. process should select a new INDEX and issue a new LISTEN for ndxb on socket 3.
  1305. The duplex connection which has been made is the control path for the file
  1306. transfer.  Based upon control information passed between server and user on
  1307. ndxa (path 1) the server FTP will either:
  1308.  
  1309.     BEGIN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
  1310.     OR
  1311.     LISTEN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
  1312.  
  1313.  
  1314.                         ***WORKING DOCUMENT***
  1315.  
  1316.  
  1317.                                   23
  1318.  
  1319.  
  1320. RFC 705
  1321. Front-End Protocol
  1322.  
  1323.  
  1324.                         ***WORKING DOCUMENT***
  1325.  
  1326.  
  1327. When a RESPONSE command has been received to the previous command, the data
  1328. connection (PATH 2) will have been made and transfer of data may begin.  The
  1329. values for TRANS-TYPE and CONN-TYPE for the LISTEN or BEGIN will be derived
  1330. from the exchange of information on the control path.
  1331.  
  1332. Host Is User FTP                              6f
  1333.  
  1334.     BEGIN NDXA,PATH=1,HOSTID,SKT-3,,CONN-TYPE-duplex+ICP,NPATH=1
  1335.  
  1336. when a RESPONSE to this command has been returned by the FE the control path
  1337. will have been connected.  The Host, after exchanging information on the 
  1338. control path, may then proceed by issuing a BEGIN or LISTEN as in the Server 
  1339. FTP example.
  1340.  
  1341. Teleconferencing                              6g
  1342.  
  1343. An INDEX with n PATHs permits up to n otherwise disassociated conversations
  1344. to be affiliated.  Each path can be manipulated individually, or all paths as
  1345. a group.  With the broadcast option -- a MESSAGE command specifying INDEX but
  1346. not specifying PATH will be broadcast to all open paths on that index.  Thus
  1347. each host may direct its messages to any or all parties.
  1348.  
  1349. A "conference" may be initiated by any host who issues a LISTEN with multiple
  1350. duplex paths on an agreed upon (but not necessarily well advertised) socket. 
  1351. When some foreign host connects, an ordinary TELNET connection exists.  If,
  1352. however, a third or forth or more parties connect, the hosts already engaged
  1353. in the conversation may elect to inform the late comers of the members already
  1354. involved.  Each host may then elect to connect to as many other hosts as he 
  1355. desires.  (The parties could agree as to who would BEGIN and who would LISTEN).
  1356. Following this scheme [it is not a protocol] all parties participate equally,
  1357. there is no moderator.  Each host decides to whom he will speak.  Using the 
  1358. initial LISTEN, a variation on this would permit the LISTENer to be moderator 
  1359. and require that he relay messages to other parties, as desired.
  1360.  
  1361. In summary, the data path mechanism permits a group of users to select an
  1362. agreed upon socket, appoint a "moderator," and at a prescribed time engage in
  1363. a conference without benefit of special protocol implementations in the FE
  1364. or in any of the hosts (except possibly the moderator).
  1365.  
  1366.  
  1367.                         ***WORKING DOCUMENT***
  1368.  
  1369.  
  1370.                                   24
  1371.  
  1372.  
  1373. RFC 705
  1374. Front-End Protocol
  1375.  
  1376.  
  1377.                         ***WORKING DOCUMENT***
  1378.  
  1379.  
  1380. Example of the Use of Simplex Connections                    6h
  1381.  
  1382. The Simplex connection types permits a host to LISTEN on a group of simplex
  1383. sockets of a particular gender.  If the host supported a group of line 
  1384. printers, for example, the Line Printer Applications Program could perform a 
  1385. LISTEN on a socket advertised to be his "Printing Socket," specifying as many
  1386. receive paths as he had printers.  Foreign hosts could then connect (via ICP) 
  1387. to his print socket.  They would be given an appropriate working socket value
  1388. and then connect to an available printer.  In this way up to n foreign hosts
  1389. may be connected to his n printers at all times.  All that any needs to know
  1390. to avail themselves of printing services is the server host's print socket.
  1391. [1]
  1392.  
  1393. Host Implementation                              7
  1394.  
  1395. Concepts                                  7a
  1396.  
  1397. The Front-End Protocol permits a Host to make use of the network through
  1398. existing low-level protocols, without requiring that it be cognizant of the
  1399. implementation details of those protocols.
  1400.  
  1401. Implementation of FEP in the Host is in terms of the function it is performing
  1402. or the service it is providing.  Information regarding sockets is available
  1403. to the sophisticated user, but can be ignored if not relevant to the problem
  1404. at hand.
  1405.  
  1406. The Host should provide the equivalent of a BEGIN, LISTEN, MESSAGE, INTERRUPT,
  1407. and END command.  In other words, the human user or applications level process
  1408. has at its disposal the full power of FEP.
  1409.  
  1410. The FEP module in the Host serves as a control mechanism to multiplex/
  1411. demultiplex traffic between itself and the FE.  In appearance and function it 
  1412. is much like any multi-line interface driver.  It handles REPLYS, reports 
  1413. errors, etc.  The FEP module must also assume the responsibility for assignment
  1414. of indexes.  This could easily be implemented as a "GETINDEX" subroutine
  1415. which would allow a user to ask for an index to be assigned to him.  The
  1416. user could then proceed to do BEGINs, LISTENs, etc. on that index.
  1417.  
  1418. A server process makes itself available to the network at large by issuing an 
  1419. appropriate LISTEN.  The Host FEP module would not have to be aware of what
  1420. servers were implemented or in operation.  The server process, when it was 
  1421.  
  1422.  
  1423.                         ***WORKING DOCUMENT***
  1424.  
  1425.  
  1426.                                   25
  1427.  
  1428.  
  1429. RFC 705
  1430. Front-End Protocol
  1431.  
  1432.  
  1433.                         ***WORKING DOCUMENT***
  1434.  
  1435.  
  1436. activated, could do a "GETINDEX," followed by a LISTEN on its well-advertised
  1437. socket, and then proceed from there.  The Host FEP module simply associates
  1438. indexes to processes and passes the incoming traffic to the appropriate process
  1439. for analysis and response.  It maintains flow between itself and the FE through
  1440. the generation and receipt of REPLYs.
  1441.  
  1442. The type of data structures, or format of information employed in the 
  1443. implementation of the FEP commands in the Host is, of course, up to the
  1444. implementor.  BEGIN could be a macro call, with the various information
  1445. passed as parameters to the Host FEP module -- which would then arrange it
  1446. into a command for delivery to the Front-End processor.  The important
  1447. consideration is not how the commands are implemented, but simply that their 
  1448. function is provided.  It might be desirable, for instance, to implement the
  1449. Host such that the front-end processor looks like a special I/O device.  In
  1450. this case, it may be appropriate to implement a form of OPEN [for BEGIN or 
  1451. LISTEN], a GET or PUT [for MESSAGE], CLOSE [for END], etc...
  1452.  
  1453. Regardless of the implementation details, it appears that, while it is the
  1454. responsibility of one control module to assign and manage INDEXes, data paths
  1455. are entirely the responsibility of the process which "owns" the INDEX.
  1456.  
  1457. Installation Parameters                              7b
  1458.  
  1459. To package the software for the FE for a given Host, that Host supplies a
  1460. number of parameters defining what FE capabilities it requires.  These
  1461. parameters are input to a system-generation procedure to produce the particular
  1462. FE code.
  1463.  
  1464. The parameters are:
  1465.  
  1466.     Byte Size
  1467.  
  1468.     This gives the size in bits, into a multiple of which each and every
  1469.     field of a command string will be right-justified (i.e., the
  1470.     information bits come last, preceded by as many padding bits as are
  1471.     needed to complete the least integral number of bytes).
  1472.  
  1473.     Its value will normally be 8 but other values will be accommodated
  1474.     as necessary.
  1475.  
  1476.  
  1477.                         ***WORKING DOCUMENT***
  1478.  
  1479.  
  1480.                                   26
  1481.  
  1482.  
  1483. RFC 705
  1484. Front-End Protocol
  1485.  
  1486.  
  1487.                         ***WORKING DOCUMENT***
  1488.  
  1489.  
  1490.     Command String Padding
  1491.  
  1492.     This gives the size in bits of the width of the hardware interface
  1493.     between the Host and the FE, such that every command string
  1494.     transmitted in either direction will have padding appended to
  1495.     complete the least multiple of this width.
  1496.  
  1497.     In the typical implementation, this parameter will be 0 and any
  1498.     padding required will be appended/discarded by the line protocol
  1499.     underlying FEP.
  1500.  
  1501.     Pad Field Length
  1502.  
  1503.     This gives the size in bits of the PAD field in the MESSAGE command.
  1504.     This enable a Host to have the TEXT field start on a convenient
  1505.     boundary.
  1506.  
  1507.     Its value can be anywhere in the range 0 to 64.
  1508.  
  1509.     Maximum of MESSAGE
  1510.  
  1511.     This gives the maximum length of a MESSAGE command string.
  1512.  
  1513.     Because buffer allocation in the FE is based on this parameter,
  1514.     its value should be chosen with care.
  1515.  
  1516.     Maximum number of Indexes
  1517.  
  1518.     This gives the maximum number of indexes which may be set-up at any one
  1519.     time.
  1520.  
  1521.     Maximum Number of Paths
  1522.  
  1523.     This gives the maximum number of paths within one index which may be
  1524.     open at any one time.
  1525.  
  1526.     Translation Types
  1527.  
  1528.     This gives the set of required values and meanings of the TRANS-TYPE
  1529.     field of the BEGIN/LISTEN commands.  The TRANS-TYPE field is divided
  1530.     into two 8-bit subfields; the first giving the format of data on the
  1531.  
  1532.  
  1533.                         ***WORKING DOCUMENT***
  1534.  
  1535.  
  1536.                                   27
  1537.  
  1538.  
  1539. RFC 705
  1540. Front-End Protocol
  1541.  
  1542.  
  1543.                         ***WORKING DOCUMENT***
  1544.  
  1545.  
  1546.     network side; the second giving the format of data on the Host side.
  1547.     The FE is required to translate between these formats all data
  1548.     contained in the TEXT field of MESSAGE commands.
  1549.  
  1550.     This parameter specifies the required formats and their values in the
  1551.     8-bit subfields.  The value 0 is reserved to mean "bit-string" and
  1552.     when it appears as either (or both) of the subfields it implies no 
  1553.     translation is to be done.
  1554.  
  1555.     Broadcast Option
  1556.  
  1557.     This specifies whether the Host wants to be able to use the Broadcast
  1558.     feature (see Section 3j).
  1559.  
  1560.     Operator-to-Operator Communication Option
  1561.  
  1562.     This specifies whether the Host wants the ability to send messages
  1563.     to the FE operator or to have the Host's operator receive messages
  1564.     from the FE.
  1565.  
  1566. Other options may be included in the protocol at some later date and these will
  1567. be available through installation parameters similar to the Broadcast option.
  1568.  
  1569. Note that all of these parameters affect the size and complexity of the FE 
  1570. code.  Thus it is important that their values be chosen carefully so as to 
  1571. maximize FE efficiency while minimizing Host implementation effort.
  1572.  
  1573. For descriptions of individual Host implementations and a list of the options
  1574. available so far, see Appendix D.
  1575.  
  1576. FE Implementation                              8
  1577.  
  1578. FEP is device independent.  For the present however, an initial implementation
  1579. will be accomplished using the DEC PDP/11 computer as the FE device and the
  1580. front-end software is to be based upon an extended version of the original ELF
  1581. system developed at SCRL.
  1582.  
  1583. For more detailed information, see Appendix C.
  1584.  
  1585.     by :                                  9
  1586.         G. W. Bailey    (BAILEY@OFFICE-1)
  1587.         K. McCloghrie   (MCCLOGHRIE@OFFICE-1)
  1588.  
  1589.  
  1590.                         ***WORKING DOCUMENT***
  1591.  
  1592.  
  1593.                                   28
  1594.  
  1595.  
  1596. RFC 705
  1597. Front-End Protocol
  1598.  
  1599.  
  1600.                         ***WORKING DOCUMENT***
  1601.  
  1602.  
  1603.                               APPENDIX A                  10
  1604.  
  1605.                               References
  1606.  
  1607.  
  1608. [1]    ICP is used in this document in a less strict manner than specified
  1609.     in NIC 7101, in that it is not necessarily two simplex connections
  1610.     that are set up as the result of the exchange of the socket number
  1611.     on the initial connection.
  1612.  
  1613. [2]    An example of connections needing to be affiliated, is in the
  1614.     implementation of FTP, where the control connection and the data
  1615.     connection have a defined relationship in their socket assignments.
  1616.  
  1617. [3]    Note that a range of socket numbers is reserved for use by an index
  1618.     when it is set-up (cf. AEN).
  1619.  
  1620.     However, socket numbers for the paths of an index are not necessarily
  1621.     contiguous.  For instance, when the next path opened after a SEND
  1622.     path is another SEND path, or when a path other than the first of an
  1623.     index is opened with ICP specified.  Nevertheless, if a protocol
  1624.     requires contiguous sockets, then the opening of the paths in a logical
  1625.     manner will provide the contiguity.
  1626.  
  1627. [4]    One possible translation will be from a Network Virtual Terminal on
  1628.     the network side to a local terminal type on the Host side.
  1629.  
  1630. [5]    The FE will directly equate the INTERRUPT command with the Host-Host
  1631.     protocol INR/INS commands.
  1632.  
  1633. [6]    Note that the READY indication in a REPLY is, in the general case,
  1634.     not directly related to a network RFNM; unless it is heavily loaded, 
  1635.     the FE will be buffering possibly more than one message (in either
  1636.     direction) until flow control mechanism allow the messages to be sent
  1637.     on.
  1638.  
  1639.     However, it is possible that a particular Host might wish to have
  1640.     knowledge of receipt of a previous message before transmitting the
  1641.     next.  In this case, the FEP implementation could be set up to only
  1642.     indicate READY after receiving the RFNM and possibly only send RFNMs
  1643.     after receiving a REPLY containing an ACK.
  1644.  
  1645.  
  1646.                         ***WORKING DOCUMENT***
  1647.  
  1648.  
  1649.                                   29
  1650.  
  1651.  
  1652. RFC 705
  1653. Front-End Protocol
  1654.  
  1655.  
  1656.                         ***WORKING DOCUMENT***
  1657.  
  1658.  
  1659.                               APPENDIX B                  11
  1660.  
  1661.                             State Diagrams
  1662.  
  1663.  
  1664.  
  1665. In the state diagrams below the following notation is used:
  1666.  
  1667.     REPLY(A)    - REPLY with ACK=1, READY/NOT-READY irrelevant
  1668.     REPLY(N)    - REPLY with NAK=1, READY/NOT-READY irrelevant
  1669.     REPLY(R)    - REPLY with ACK=0, NAK=0, READY=1
  1670.     REPLY(A+R)  - REPLY with ACK=1, READY=1
  1671.     REPLY(N+R)  - REPLY with NAK=1, READY=1
  1672.     REPLY(A+NR) - REPLY with ACK=1, NOT-READY=1
  1673.     REPLY(N+NR) - REPLY with NAK=1, NOT-READY=1
  1674.  
  1675.  
  1676.  
  1677.                        State Diagram for INDEX
  1678.  
  1679.  
  1680.  
  1681.     / ------\                   /-------\           /-----\
  1682.     !       !BEGIN(new index)   !       !           !     !
  1683.     !       !->--------------->-!Index  !           !     !
  1684.     !Index  !LISTEN(new index)  !Open   !           !     !
  1685.     !Closed !                   !Pending!           !Index!
  1686.     !       !           REPLY(N)!       !REPLY(A)   !Open !
  1687.     !       !-<---------------<-!       !->------->-!     !
  1688.     !       !                   \-------/           !     !
  1689.     !       !                                       !     !
  1690.     !       !             /-------\      END(Path=0)!     !
  1691.     !       !             !       !-<-------------<-!     !
  1692.     !       !     REPLY(A)!Index  !                 !     !
  1693.     !       !-<---------<-!Close  !REPLY(N)         !     !
  1694.     !       !             !Pending!->------------->-!     !
  1695.         \-------/             \-------/                 \-----/
  1696.  
  1697.  
  1698.  
  1699.                         ***WORKING DOCUMENT***
  1700.  
  1701.  
  1702.                                   30
  1703.  
  1704.  
  1705. RFC 705
  1706. Front-End Protocol
  1707.  
  1708.  
  1709.                         ***WORKING DOCUMENT***
  1710.  
  1711.  
  1712.                         APPENDIX B (continued)
  1713.  
  1714.                      State Diagram for Whole Path
  1715.  
  1716.  
  1717.     /------\BEGIN       /----------\
  1718.     !      !->-------->-!          !
  1719.     !      !LISTEN      !Connection!               
  1720.     !Path  !            !Pending   !REPLY(A)        /-------\
  1721.     !Closed!    REPLY(N)!          !->------------>-!       !
  1722.     !      !-<--------<-!          !                !       !
  1723.     !      !            \----------/                !Path   !
  1724.     !      !                                        !Conn-  !
  1725.     !      !            /-----\     RESPONSE(CODE>0)! ecting!
  1726.     !      !            !     !-<-----------------<-!       !
  1727.     !      !            !Path !                     !       !
  1728.     !      !    REPLY(A)!Abort!          END(PATH>0)!       !
  1729.     !      !-<--------<-!Pend-!-<-----------------<-!       !
  1730.     !      !            ! ing !                     !       !
  1731.     !      !            !     !REPLY(N)             !       !
  1732.     \------/            !     !->----------------->-!       !
  1733.                             \-----/                     !       !
  1734.                                                         !       !
  1735.                              /-------\                  !       !
  1736.                              !       !  RESPONSE(CODE=0)!       !
  1737.            /----\            !Path   !-<--------------<-!       !
  1738.        !    !            !Open   !                  !       !
  1739.        !Path!            !Pending!REPLY(N)          !       !
  1740.            !Open!    REPLY(A)!       !->-------------->-!       !
  1741.        !    !-<--------<-!       !                  \-------/
  1742.        \----/            \-------/
  1743.  
  1744.  
  1745.  
  1746.  
  1747.  
  1748.  
  1749.  
  1750.  
  1751.  
  1752.                         ***WORKING DOCUMENT***
  1753.  
  1754.  
  1755.                                   31
  1756.  
  1757.  
  1758. RFC 705
  1759. Front-End protocol
  1760.  
  1761.  
  1762.                         ***WORKING DOCUMENT***
  1763.  
  1764.  
  1765.  
  1766.                         APPENDIX B (continued)
  1767.  
  1768.                State Diagram for Each Direction of Path
  1769.  
  1770.  
  1771.  
  1772.  
  1773.     /----\MESSAGE             /-------\             /-------\
  1774.     !    !->---------------->-!       !REPLY(A+NR)  !       !
  1775.     !Path!INTERRUPT           !Command!->--------->-!Message!
  1776.     !Open!                    !Blocked!REPLY(N+NR)  !Blocked!
  1777.     !    !                    !       !             !       !
  1778.     !    !          REPLY(A+R)!       !    INTERRUPT!       !
  1779.     !    !-<----------------<-!       !-<---------<-!       !
  1780.     !    !          REPLY(N+R)\-------/             !       !
  1781.     !    !                                  REPLY(R)!       !
  1782.     !    !-<----------------------<---------------<-!       !
  1783.     !    !                                          !       !
  1784.     !    !END(PATH>0)         /-------\  END(PATH>0)!       !
  1785.     !    !->---------------->-!       !-<---------<-!       !
  1786.     !    !                    !       !             !       !
  1787.     !    !          REPLY(N+R)!Path   !REPLY(N)     !       !
  1788.     !    !-<----------------<-!Close  !->--------->-!       !
  1789.     \----/                    !Pending!             \-------/
  1790.                                   !       !
  1791.     /------\          REPLY(A)!       !
  1792.     !Path  !-<--------------<-!       !
  1793.     !Closed!                  !       !
  1794.     !      !                  \-------/
  1795.     \------/
  1796.  
  1797.  
  1798.  
  1799.  
  1800.  
  1801.  
  1802.  
  1803.  
  1804.  
  1805.  
  1806.                         ***WORKING DOCUMENT***
  1807.  
  1808.  
  1809.                                   32
  1810.  
  1811.  
  1812. RFC 705
  1813. Front-End Protocol
  1814.  
  1815.  
  1816.                         ***WORKING DOCUMENT***
  1817.  
  1818.  
  1819.                               APPENDIX C
  1820.  
  1821.                        Front-End Implementation
  1822.  
  1823.  
  1824. Introduction
  1825.  
  1826. A Network Access System (NAS), developed for a DEC PDP/11 computer, supports
  1827. the current Imp-Host, Host-Host and ICP protocols.  The implementation of
  1828. these protocols facilitate process-process communications across the network
  1829. and multi-user TELNET access to foreign hosts.  This NAS provides the FE 
  1830. environment in which FEP is implemented.
  1831.  
  1832. The NAS system is comprised of a Kernel or executive section and a Network
  1833. Control Program (NCP) plus a collection of modules to support device
  1834. interfaces, handle terminals, and implement applications, as appropriate.  The
  1835. software is modular and extensible.
  1836.  
  1837. The KERNEL
  1838.  
  1839. The Kernel of the system consists of a set of functional modules which perform
  1840. the task of resource management in a multiprocessing environment.  This allows
  1841. processes to be created, vie for processor service according to priority, 
  1842. intercommunicate, and be terminated.  System primitives exist for various
  1843. tasks such as process creation and synchronization, storage allocation, and
  1844. sharing of the interval timer.
  1845.  
  1846. The term process used here describes an autonomous sequence of states brought
  1847. about by the PDP-11 processor; a process' state is characterized by the set of
  1848. processor registers, a stock, and process-owned storage areas.  Process share 
  1849. storage areas which are accessed only (eq. pure code).  Processes also share
  1850. storage areas which may be updated (eq. control tables).  In this case an
  1851. allocation mechanism is utilized to prevent simultaneous ownership of an 
  1852. updatable storage area.  The storage area is thus viewed as a sequentially 
  1853. sharable resource which is allocated by the process, modified, and then
  1854. released.
  1855.  
  1856. Processes are given control of the processor by a single procedure called the
  1857. Dispatcher.  Processes are said to be in a ready state or in a waiting state.
  1858. When a process blocks itself, control is given to the highest priority ready
  1859. process.
  1860.  
  1861.  
  1862.                         ***WORKING DOCUMENT***
  1863.  
  1864.  
  1865.                                   33
  1866.  
  1867.  
  1868. RFC 705
  1869. Front-End Protocol
  1870.  
  1871.  
  1872.                         ***WORKING DOCUMENT***
  1873.  
  1874.  
  1875. Each process has an associated input message queue.  This queue is the vehicle
  1876. for interprocess communication.  A process is blocked (put into a wait state)
  1877. when its input message queue becomes empty (voluntary wait), or when an 
  1878. interrupt occurs (involuntary wait) because a higher priority process is to
  1879. receive control of the processor.  A process may voluntarily block itself
  1880. waiting for any signal, or it may block itself for a specific event to be
  1881. posted to its input message queue.
  1882.  
  1883. The Network Control Program
  1884.  
  1885. The NCP provides "third level" protocol functions to local processes.  It
  1886. contains a process which decodes and passes messages which have been received
  1887. from the IMP and placed on the IMP-Host queue.  This process interacts with
  1888. other processes which call the NCP to establish connections or to transmit
  1889. data.  Thus the NCP is essentially divided into two parts:
  1890.  
  1891.     1)    a process which handles incoming messages from the network,
  1892.     interprets IMP-Host and Host-Host control messages, and forwards
  1893.     regular messages on established connections; and 
  1894.  
  1895.     2)    a set of primitives which allow local processes to establish
  1896.     connections to other processes across the network, and to perform
  1897.     requests for data to be transferred on these connections.
  1898.  
  1899. There are two primary data structures used by the NCP to monitor the status
  1900. of network connections.  The first is called the Host Table, and describes
  1901. that which is peculiar to each given host; the second is referred to as a
  1902. Connection Table and contains all information on the state of a local NCP 
  1903. socket (connection).  Connection Tables may be created either through
  1904. external requests (e.q., an RFC is received from a remote host) or through
  1905. internal requests (e.g., a local process performs a LISTEN).
  1906.  
  1907. Flow control is that portion of the NCP which governs the flow of data on
  1908. connections.  There are two procedures which perform this task; one which 
  1909. handles receive connections and one which handles send connections.  These
  1910. procedures receive control when an event has occurred which may now make it 
  1911. possible to transfer data on a connection.
  1912.  
  1913. Both send and receive flow control procedures have the responsibility of moving
  1914. data between local process buffers and messages being received or transmitted
  1915. over the network.  In addition, they handle the formatting and unpacking of
  1916.  
  1917.  
  1918.                         ***WORKING DOCUMENT***
  1919.  
  1920.  
  1921.                                   34
  1922.  
  1923.  
  1924. RFC 705
  1925. Front-End Protocol
  1926.  
  1927.  
  1928.                         ***WORKING DOCUMENT***
  1929.  
  1930.  
  1931. messages received.  Local processes are unaware that data is being transmitted
  1932. as discrete messages.
  1933.  
  1934. The NCP watchdog process monitors the state of network connections, checking
  1935. for error conditions and performing garbage collection tasks.  It receives 
  1936. control at periodic intervals and scans the list of known hosts, looking for
  1937. existing connections.  For each host to which an input or output connection
  1938. exists, the Watchdog causes a Host-Host NOP message to be sent.  Thus if a
  1939. remote Host crashes while data is being awaited, local processes are informed
  1940. of the error condition.  The NCP takes notice of the remote crash when it
  1941. receives a IMP--Host type 7 control message (Destination Host Dead).  It then
  1942. automatically closes all connections to that Host, and notifies using processes
  1943. of that fact.
  1944.  
  1945. A second function of the NCP Watchdog is to check for connections hung because
  1946. of an outstanding RFNM.  If a RFNM is not received for a specified interval,
  1947. the message is discarded, and the associated connection closed.
  1948.  
  1949. The FEP Handler
  1950.  
  1951. The Front-End Protocol is implemented as a collection of related, but
  1952. specialized processes which manage network connections on the one side, and
  1953. manage FEP paths and indexes on the other.  Some FEP processes are NCP users.
  1954. They cause network connections to be made, rule on incoming RFCs, and both
  1955. accept and generate network data.  Other FEP processes support the Host.
  1956. These processes parse incoming commands, create indexes and paths, control
  1957. the generation of replies and generally manage the paths.  Certain FEP 
  1958. processes control specialized tasks such as translation of data, servicing of 
  1959. LISTEN commands and generation of RESPONSE commands.
  1960.  
  1961. Two data structures provide control information for FEP activities.  An Index
  1962. Table exists for each active index.  Each Index Table associates one or more
  1963. Path Table entries.  Information in the Path Table reflects the state of the
  1964. path, the translation type specified for data on this path, and necessary
  1965. information to associate the path to any appropriate NCP Connection Tables.
  1966. The Path Table is the common interface for all of the FEP modules.  Most FEP
  1967. processes are activated to service some event which is usually associated to
  1968. a path.  The action of the process will likely be dictated by the state of the
  1969. path as indicated by the Path Table entry, and may result in altering the state
  1970. of the path or the activation of one or more other FEP processes.
  1971.  
  1972.  
  1973.                         ***WORKING DOCUMENT***
  1974.  
  1975.  
  1976.                                   35
  1977.  
  1978.  
  1979. RFC 705
  1980. Front-End Protocol
  1981.  
  1982.  
  1983.                         ***WORKING DOCUMENT***
  1984.  
  1985.  
  1986. Two message queues provide Host input and output to the FEP modules.  A line
  1987. protocol mechanism services these queues.  Commands from the Host are placed
  1988. on the FEP Input queue by the line protocol process and the FEP Host Input 
  1989. process is signaled. When an FEP Host Output module places a Command for the
  1990. Host on the host Output queue it signals the line protocol process.
  1991.  
  1992. The FEP implementation is basically Host independent down to the level of the
  1993. Host Input and Host Output queues.
  1994.  
  1995. The Line Protocol Mechanism
  1996.  
  1997. The device interface and the line protocol between the FE and the Host are
  1998. installation dependent.  Because of this dependency, only a general discussion
  1999. of the Line Protocol Mechanism is possible in this context.  Detailed 
  2000. descriptions of the specific line protocols are included in the section for
  2001. each Host.
  2002.  
  2003. The communications discipline and physical device characteristics may vary
  2004. considerably from host to host.  All FEP line protocols, however, will show
  2005. certain common characteristics.  The interface between the FEP handler and the
  2006. Line Protocol Mechanism will always be Host Input and Host Output queues.  All
  2007. line protocol mechanisms will be expected to guarantee the integrity of the
  2008. data.  This implies some form of flow control, error detection/correction and
  2009. retransmission capability, as well as normal transmit/receive responsibilities.
  2010. The Line Protocol Mechanism will be expected to report failure after
  2011. unsuccessfully attempting to perform an I/O operation.  The number of retries
  2012. etc. before reporting failure is an installation parameter.  The FEP Handler
  2013. works only in terms of FEP commands.  The line protocol may provide for block
  2014. transfers where each physical block is comprised of one or more FEP commands.
  2015. If such is the case, it is encumbent upon the Line Protocol Mechanism to 
  2016. deblock the incoming Host commands before placing them in the Host Input queue.
  2017.  
  2018. The Line Protocol Mechanism will, in the general case, not manage any buffers. 
  2019. After successfully transmitting a command to the Host it is responsible for 
  2020. reporting the I/O complete, but the buffer space is freed or reused only by
  2021. the FEP process which "owns" that space.  The FEP Handler might use buffer
  2022. assignment to control the rate of incoming traffic.  When the FEP Host Input 
  2023. queue is ready to accept an additional command, it would acquire a buffer and
  2024. signal the Line Protocol Mechanism, passing it a pointer to a buffer.  This
  2025.  
  2026.  
  2027.                         ***WORKING DOCUMENT***
  2028.  
  2029.  
  2030.                                   36
  2031.  
  2032.  
  2033. RFC 705
  2034. Front-End Protocol
  2035.  
  2036.  
  2037.                         ***WORKING DOCUMENT***
  2038.  
  2039.  
  2040. is effectively a "read" request.  When the line protocol handler has filled
  2041. the buffer, it adds it to the Host Input queue and signals I/O complete to 
  2042. the appropriate FEP process.
  2043.  
  2044. If the nature of the physical connection is such that the FE must accept 
  2045. unsolicited input, it may be necessary for the Line Protocol Mechanism to
  2046. have its own buffer pool, in addition.  If this is the case, it must be 
  2047. entirely managed by the line handler and transparent to the FEP Handler.
  2048.  
  2049. Data Translations
  2050.  
  2051. The TRANS-TYPE provisions in FeP may be employed for at least two general
  2052. services.  First, it can be used for normal character set substitutions.  This
  2053. is where, in the general case, there is a one-to-one relationship between the
  2054. two character sets.
  2055.  
  2056. The second service addresses the problem of data transformation.  In this case,
  2057. there need not be a one-to-one relationship between incoming data and outgoing
  2058. data.
  2059.  
  2060. The translation mechanism uses a token (e.g., a character) from the incoming
  2061. data stream to index into a translation table.  The result may be one of the
  2062. following:
  2063.  
  2064.     a)  do nothing, drop the character
  2065.     b)  output the character unchanged
  2066.     c)  substitute input character by output character
  2067.     d)  substitute input character by output string
  2068.     e)  activate a procedure indicated by the table
  2069.     f)  change the translation 
  2070.     g)  test the translation mode and do any of the above depending 
  2071.         on the result.
  2072.  
  2073. For each translation/transformation required by the Host a translation table 
  2074. must be defined.  For simplicity and clarity the TRANS-TYPE field in the FEP
  2075. commands allows the user to specify Host side and Network side as independent
  2076. entities.  In actual execution the Host/Network pair addresses a translation
  2077. table which must have been previously defined.  Note that for a duplex path
  2078. two translation tables are necessary (A->B is not the same as A<-B).
  2079.  
  2080. A collection of "standard" character sets will be addressed initially (EBCDIC,
  2081. ASC117, ASCII8, BCD, etc.) and at least NVT.  As new requirements are defined
  2082. these will be added to a library which will then be available to subsequent
  2083. users.
  2084.  
  2085.  
  2086.                         ***WORKING DOCUMENT***
  2087.  
  2088.  
  2089.                                   37
  2090.  
  2091.  
  2092. RFC 705
  2093. Front-End Protocol
  2094.  
  2095.  
  2096. ***WORKING DOCUMENT***
  2097.  
  2098.  
  2099.                               APPENDIX D
  2100.  
  2101.                          Host Implementations
  2102.  
  2103.  
  2104.  
  2105. To be written at a later date.
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.  
  2117.  
  2118.  
  2119.  
  2120.  
  2121.  
  2122.  
  2123.  
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129.  
  2130.  
  2131.  
  2132.  
  2133.  
  2134.  
  2135.  
  2136.  
  2137.  
  2138.  
  2139.  
  2140.  
  2141.  
  2142.                         ***WORKING DOCUMENT***
  2143.  
  2144.  
  2145.                                   38