home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 200s / rfc215.txt < prev    next >
Text File  |  1997-05-12  |  17KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      A. McKenzie
  8. Request for Comments: 215                                          BBN
  9. NIC #7545                                               30 August 1971
  10. Categories: C.2, D.1, D.3, G.1
  11. Updates: none
  12. Obsoletes: none
  13.  
  14.                          NCP, ICP, and TELNET:
  15.  
  16.                     The Terminal IMP Implementation
  17.  
  18.        By early December there will be six Terminal IMPs incorporated
  19. into the network, with additional Terminal IMPs scheduled for delivery
  20. at a rate of about one per month thereafter.  For this reason the
  21. implementation of network protocols (and deviations from them) may be of
  22. interest to the network community.  This note describes the choices made
  23. by the Terminal IMP system programmers where choices are permitted by
  24. the protocols, and documents some instances of non-compliance with
  25. protocols.
  26.  
  27.      Most of the choices made during protocol implementation on the
  28. Terminal IMP were influenced strongly by storage limitations.  The
  29. Terminal IMP has no bulk storage for buffering, and has only 8K of 16-
  30. bit words available for both device I/O buffers and program.  The
  31. program must drive up to 64 terminals which generally will include a
  32. variety of terminal types with differing code sets and communication
  33. protocols (e.g., the IBM 2741 terminals).  In addition, the Terminal IMP
  34. must include a rudimentary language processor which allows a terminal
  35. user to specify parameters affecting his network connections.  Since the
  36. Terminal IMP exists only to provide access to the network for 64
  37. terminals, it must be prepared to maintain 128 (simplex) network
  38. connections at any time; thus each word stored in the NCP tables on a
  39. per-connection basis consumes a significant portion of the Terminal IMP
  40. memory.
  41.  
  42.      It should be remembered that the Terminal IMP is designed to
  43. provide access to the network for its users, not to provide service to
  44. the rest of the network.  Thus the Terminal IMP does not contain
  45. programs to perform the "server" portion of the ICP; in fact, it does
  46. not have a "logger" socket.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC #215
  61.  
  62.  
  63.      The Terminal IMP program currently implements only the NCP, the
  64. ICP, and the TELNET protocol since these are of immediate interest to
  65. the sites with Terminal IMPs.  It is anticipated that portions of the
  66. data transfer protocol will be implemented in the future; the portions
  67. to be implemented are not yet clearly defined, but will probably include
  68. the infinite bit stream (first) and the "transparent" mode (later).
  69. Developments in the area of data transmission protocol will be
  70. documented in the future.
  71.  
  72.      The remainder of this note describes, and attempts to justify,
  73. deviations from the official protocols and other design choices of
  74. interest.  Although written in the present tense, there are some
  75. additional known instances of deviation from protocol which will be
  76. corrected in the near future.
  77.  
  78.    A)  Deviations from Protocols
  79.  
  80.       1)  The Terminal IMP does not guarantee correct response
  81.           to ECO commands.  If some Host A sends a control
  82.           message containing ECOs to the Terminal IMP, and the
  83.           message arrives at a time when
  84.  
  85.           a)  the Terminal IMP has a free buffer and
  86.  
  87.           b)  the control link from the Terminal IMP to Host A
  88.               is not blocked
  89.  
  90.           then the Terminal IMP will generate a correct ERP for
  91.           each ECO.  In all other cases the ECO commands will
  92.           be discarded.  (All control messages sent by the
  93.           Terminal IMP begin with a NOP control command, so if
  94.           Host A sends a control message consisting of 60 ECO
  95.           commands, the Terminal IMP will answer (if at all)
  96.           with a 121-byte message -- 1 NOP and 60 ERPs.)
  97.  
  98.           The reason for this method of implementation is that
  99.           to guarantee correct response to ECO in all cases
  100.           requires an infinite amount of storage.  For
  101.           example, suppose Host A sends control messages, each
  102.           containing an ECO command, to Host B at the rate of
  103.           one per second, but that Host A accepts messages from
  104.           the network as slowly as possible (one every 39
  105.           seconds, say).  Then Host B has only three choices
  106.           which do not violate protocol:
  107.  
  108.           a)  Declare itself dead to the network (i.e., turn
  109.               off its Ready line), thereby denying all its
  110.               users use of the network.
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. RFC #215
  117.  
  118.  
  119.           b)  Refuse to accept messages from the network
  120.               faster than the slowest possible foreign Host
  121.               (i.e., about one every 39 seconds).  If Host B is
  122.               a Terminal IMP, this is almost certainly slow
  123.               enough to soon reach a steady state of no users.
  124.  
  125.           c)  Implement "infinite" storage for buffering
  126.               messages.
  127.  
  128.           Since it is clear that none of the "legal" solutions
  129.           are possible, we have decided to do no buffering,
  130.           which should (we guess) satisfy the protocol well
  131.           over 99% of the time.
  132.  
  133.       2)  The Terminal IMP does not guarantee to issue CLS
  134.           commands in response to "unsolicited" RFCs.  There
  135.           are currently several ways to "solicit" an RFC, as
  136.           follows:
  137.  
  138.           a)  A terminal user can tell the Terminal IMP to
  139.               perform the ICP to the TELNET Logger at some
  140.               foreign Host.  This action "solicits" the RFCs
  141.               defined by the ICP.
  142.  
  143.           b)  A terminal user can send an RFC to any particular
  144.               Host and socket he chooses.  This "solicits" a
  145.               matching RFC.
  146.  
  147.           c)  A terminal user can set his own receive socket
  148.               "wild."  This action "solicits" an STR from
  149.               anyone to his socket.  Similarly, the user can
  150.               set his send socket "wild" to "solicit" an RTS.
  151.  
  152.           If the Terminal IMP receives a "solicited" RFC it
  153.           handles it in accordance with the protocol.  If the
  154.           Terminal IMP receives a control message containing
  155.           one or more "unsolicited" RFCs it will either issue
  156.           CLS commands or ignore the RFCs according to the
  157.           criteria described above for answering ECOs (and for
  158.           the same reasons).  Further, if the Terminal IMP
  159.           does issue a CLS in response to an unsolicited RFC
  160.           it will not wait for a matching CLS before
  161.           considering the sockets involved to be free for other
  162.           use.
  163.  
  164.       3)  After issuing a CLS for a connection, the Terminal
  165.           IMP will not wait forever for a matching CLS.
  166.           There are two cases:
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. RFC #215
  173.  
  174.  
  175.           a)  The Terminal IMP has sent an RFC, grown tired of
  176.               waiting for a matching RFC, and therefore issued
  177.               a CLS
  178.  
  179.           b)  The Terminal IMP has sent a CLS for an
  180.               established connection (matching RFCs exchanged)
  181.  
  182.           In either of these cases the Terminal IMP will wait
  183.           for a matching CLS for a "reasonable" time (probably
  184.           30 seconds to one minute) and will then "forget" the
  185.           connection.  After the connection is forgotten, the
  186.           Terminal IMP will consider both sockets involved to
  187.           be free for other use.
  188.  
  189.           Because of program size and table size restrictions,
  190.           the Terminal IMP assigns socket numbers to a terminal
  191.           as a direct function of the physical address of the
  192.           terminal.  Thus (given this socket assignment scheme)
  193.           the failure of some foreign Host to answer a CLS
  194.           could permanently "hang" a terminal.  It might be
  195.           argued that the Terminal IMP could issue a RST to the
  196.           offending Host, but this would also break the
  197.           connections of other terminal users who might be
  198.           performing useful work with that Host.
  199.  
  200.       4)  The Terminal IMP ignores all RET commands.  The
  201.           Terminal IMP cannot buffer very much input from the
  202.           network to a given terminal due to core size
  203.           limitations.  Accordingly, the Terminal IMP allocates
  204.           only one message and a very small number of bits
  205.           (currently 120 bits; eventually some number in the
  206.           range 8-4000, based on the terminal's speed) on each
  207.           connection for which the Terminal IMP is the
  208.           receiver.  Given such small allocations, the Terminal
  209.           IMP attempts to keep the usable bandwidth as high as
  210.           possible by sending a new allocation, which brings
  211.           the total allocation up to the maximum amount, each
  212.           time that:
  213.  
  214.           a)  one of the two buffers assigned to the terminal
  215.               is empty, and
  216.  
  217.           b)  the allocations are below the maxima.
  218.  
  219.           Thus, if a spontaneous RET were received, the
  220.           reasonable thing for the Terminal IMP to do would be
  221.           to immediately issue a new ALL.  However, if a
  222.           foreign Host had some reason for issuing a first
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228. RFC #215
  229.  
  230.  
  231.           spontaneous RET, it would probably issue a second RET
  232.           as soon as it received the ALL.  This would be likely
  233.           to lead to an infinite (and very rapid) RET-ALL loop
  234.           between the two machines, chewing up a considerable
  235.           portion of the Terminal IMP's bandwidth.  Since the
  236.           Terminal IMP can't "afford" to communicate with such
  237.           a Host, it ignores all RETs.
  238.  
  239.       5)  The Terminal IMP ignores all GVB commands.
  240.           Implementation of GVB appears to require an
  241.           unreasonable number of instructions and, at the
  242.           moment at least, no Host appears to use the GVB
  243.           command.  If we were to implement GVB we would always
  244.           RET all of both allocations and this doesn't seem
  245.           very useful.
  246.  
  247.       6)  The Terminal IMP does not handle a total bit-
  248.           allocation greater than 65,534 (2^16-2) correctly.
  249.           If the bit-allocation is ever raised above 65,534 the
  250.           Terminal IMP will treat the allocation as infinite.
  251.           This treatment allows the Terminal IMP to store the
  252.           bit allocation for each connection in a single word,
  253.           and to avoid double precision addition and
  254.           subtraction.  Our reasons for this decision are:
  255.  
  256.       a)  A saving of more than 100 words of memory which
  257.           would be required for allocation tables and for
  258.           double precision addition/subtraction routines.
  259.  
  260.       b)  Our experience, which indicates that very few
  261.           Hosts (probably one at most) ever raise their
  262.           total bit allocation above 65,534 bits.
  263.  
  264.       c)  Our expectation that any Host which ever raises
  265.           its bit allocation above 65,534 probably would be
  266.           willing to issue an infinite bit allocation if
  267.           one were provided by the protocol.  Once the bit
  268.           allocation is greater than about 16,000, the
  269.           message allocation (which the Terminal IMP
  270.           handles correctly) is a more powerful method of
  271.           controlling network loading of a Host system than
  272.           bit allocation.  We believe that Hosts which have
  273.           loading problems will recognize this.
  274.  
  275.       7)  The Terminal IMP ignores the "32-bit number" in the
  276.           ICP.  When the Terminal IMP (the "user site")
  277.           initiates the Initial Connection Protocol the actual
  278.           procedure is to send the required RTS to the logger
  279.  
  280.  
  281.  
  282.                                                                 [Page 5]
  283.  
  284. RFC #215
  285.  
  286.  
  287.           socket of the user-specified foreign Host and
  288.           simultaneously to set the terminal user's send and
  289.           receive sockets in a state where each will accept
  290.           any RFC from the specified Host.  The 32-bit socket
  291.           number transmitted over the logger connection is
  292.           ignored, and the first RTS and STR addressing the
  293.           user's sockets will be accepted (and answered with
  294.           matching RFCs).
  295.  
  296.           The ICP allows the foreign Host to transmit the RFCs
  297.           involving Terminal IMP sockets "U+2" and "U+3" at
  298.           any time after receipt of the RFC to the (foreign
  299.           Host's) logger socket.  In particular, the RFCs may
  300.           arrive at the Terminal IMP before the 32-bit
  301.           number.  In the case of a "normal" foreign Host, the
  302.           first incoming RFCs for sockets U+2 and U+3 will come
  303.           from the sockets indicated by the 32-bit number, so
  304.           it doesn't matter if the number is ignored.  In the
  305.           case of a pathologic foreign Host, a potentially
  306.           infinite number of "wrong" RFCs involving U+2 and
  307.           U+3 may arrive at the Terminal IMP before the 32-bit
  308.           number is sent.  The Terminal IMP would be required
  309.           to store this stream of RFCs pending arrival of the
  310.           32-bit number, then issue CLS commands for all
  311.           "wrong" RFCs.  However, the Terminal IMP does not
  312.           have infinite storage available for this purpose (it
  313.           is also doubtful that a terminal user really wants to
  314.           converse with a pathologic foreign Host) so the
  315.           Terminal IMP assumes that the foreign Host is
  316.           "normal" and ignores the 32-bit number.
  317.  
  318.    B)  Other Design Choices Related to Protocol
  319.  
  320.           1)  The Terminal IMP ignores incoming ERR commands and
  321.               does not output ERR commands.
  322.  
  323.           2)  The Terminal IMP assumes that incoming messages have
  324.               the format and contents demanded by the relevant
  325.               protocols.  For example, the byte size of incoming
  326.               TELNET messages is assumed to be 8.  The major checks
  327.               which the Terminal IMP does make are:
  328.  
  329.               a)  If an incoming control message has a byte count
  330.                   greater than 120 then it is discarded.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.                                                                 [Page 6]
  339.  
  340. RFC #215
  341.  
  342.  
  343.               b)  If a control command opcode greater than 13 is
  344.                   found during the processing of a control message
  345.                   then the remainder of the control message is
  346.                   discarded.
  347.  
  348.               c)  If an incoming data message has a byte count
  349.                   indicating that the bit allocation for the
  350.                   connection is exceeded (based on the assumed byte
  351.                   size) then the message is discarded.
  352.  
  353.           3)  If one control message contains several RST commands
  354.               only one RRP is transmitted.  If several control
  355.               messages, each containing RST commands, arrive "close
  356.               together" only one RST is returned.  [The actual
  357.               implementation is to set a bit each time a RST is
  358.               found (in "foreground") and to reset the bit when a
  359.               RRP is sent (in "background").]
  360.  
  361.           4)  Socket numbers are preassigned based on the hardware
  362.               "physical address" (in the terminal multiplexing
  363.               device) of the terminal.  The high order 16 bits of
  364.               the socket number give the device number (in the
  365.               range 0-63) and the low order bits are normally 2 or
  366.               3 depending on the socket's gender (zero is also used
  367.               during ICP).  [We would be pleased to see socket
  368.               number length reduced to 16 bits; in that case the
  369.               high order 8 bits would be mapped to the device and
  370.               the low order 8 bits would contain 2 or 3.]
  371.  
  372.           5)  During ICP, with the Terminal IMP as the user site,
  373.               the Terminal IMP follows the "Listen" option rather
  374.               than the "Init" option (as described at the top of
  375.               page 3, NIC #7170).  In other words, the Terminal IMP
  376.               does not issue the RFCs involving sockets U+2 and U+3
  377.               except in response to incoming RFCs involving those
  378.               sockets.  In this context, we will mention that the
  379.               "deadlock" mentioned in NWG-RFC #202 does not exist,
  380.               since the ICP does not give the server the "Listen"
  381.               option (see NIC #7170, page 2).
  382.  
  383.  
  384.           [ This RFC was put into machine readable form for entry ]
  385.             [ into the online RFC archives by Randy Dunlap 5/97 ]
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.                                                                 [Page 7]
  395.  
  396.