doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc215.txt b/doc/rfc/rfc215.txt
new file mode 100644
index 0000000..2e24976
--- /dev/null
+++ b/doc/rfc/rfc215.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                      A. McKenzie
+Request for Comments: 215                                          BBN
+NIC #7545                                               30 August 1971
+Categories: C.2, D.1, D.3, G.1
+Updates: none
+Obsoletes: none
+
+                         NCP, ICP, and TELNET:
+
+                    The Terminal IMP Implementation
+
+       By early December there will be six Terminal IMPs incorporated
+into the network, with additional Terminal IMPs scheduled for delivery
+at a rate of about one per month thereafter.  For this reason the
+implementation of network protocols (and deviations from them) may be of
+interest to the network community.  This note describes the choices made
+by the Terminal IMP system programmers where choices are permitted by
+the protocols, and documents some instances of non-compliance with
+protocols.
+
+     Most of the choices made during protocol implementation on the
+Terminal IMP were influenced strongly by storage limitations.  The
+Terminal IMP has no bulk storage for buffering, and has only 8K of 16-
+bit words available for both device I/O buffers and program.  The
+program must drive up to 64 terminals which generally will include a
+variety of terminal types with differing code sets and communication
+protocols (e.g., the IBM 2741 terminals).  In addition, the Terminal IMP
+must include a rudimentary language processor which allows a terminal
+user to specify parameters affecting his network connections.  Since the
+Terminal IMP exists only to provide access to the network for 64
+terminals, it must be prepared to maintain 128 (simplex) network
+connections at any time; thus each word stored in the NCP tables on a
+per-connection basis consumes a significant portion of the Terminal IMP
+memory.
+
+     It should be remembered that the Terminal IMP is designed to
+provide access to the network for its users, not to provide service to
+the rest of the network.  Thus the Terminal IMP does not contain
+programs to perform the "server" portion of the ICP; in fact, it does
+not have a "logger" socket.
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+RFC #215
+
+
+     The Terminal IMP program currently implements only the NCP, the
+ICP, and the TELNET protocol since these are of immediate interest to
+the sites with Terminal IMPs.  It is anticipated that portions of the
+data transfer protocol will be implemented in the future; the portions
+to be implemented are not yet clearly defined, but will probably include
+the infinite bit stream (first) and the "transparent" mode (later).
+Developments in the area of data transmission protocol will be
+documented in the future.
+
+     The remainder of this note describes, and attempts to justify,
+deviations from the official protocols and other design choices of
+interest.  Although written in the present tense, there are some
+additional known instances of deviation from protocol which will be
+corrected in the near future.
+
+   A)  Deviations from Protocols
+
+      1)  The Terminal IMP does not guarantee correct response
+          to ECO commands.  If some Host A sends a control
+          message containing ECOs to the Terminal IMP, and the
+          message arrives at a time when
+
+          a)  the Terminal IMP has a free buffer and
+
+          b)  the control link from the Terminal IMP to Host A
+              is not blocked
+
+          then the Terminal IMP will generate a correct ERP for
+          each ECO.  In all other cases the ECO commands will
+          be discarded.  (All control messages sent by the
+          Terminal IMP begin with a NOP control command, so if
+          Host A sends a control message consisting of 60 ECO
+          commands, the Terminal IMP will answer (if at all)
+          with a 121-byte message -- 1 NOP and 60 ERPs.)
+
+          The reason for this method of implementation is that
+          to guarantee correct response to ECO in all cases
+          requires an infinite amount of storage.  For
+          example, suppose Host A sends control messages, each
+          containing an ECO command, to Host B at the rate of
+          one per second, but that Host A accepts messages from
+          the network as slowly as possible (one every 39
+          seconds, say).  Then Host B has only three choices
+          which do not violate protocol:
+
+          a)  Declare itself dead to the network (i.e., turn
+              off its Ready line), thereby denying all its
+              users use of the network.
+
+
+
+                                                                [Page 2]
+
+RFC #215
+
+
+          b)  Refuse to accept messages from the network
+              faster than the slowest possible foreign Host
+              (i.e., about one every 39 seconds).  If Host B is
+              a Terminal IMP, this is almost certainly slow
+              enough to soon reach a steady state of no users.
+
+          c)  Implement "infinite" storage for buffering
+              messages.
+
+          Since it is clear that none of the "legal" solutions
+          are possible, we have decided to do no buffering,
+          which should (we guess) satisfy the protocol well
+          over 99% of the time.
+
+      2)  The Terminal IMP does not guarantee to issue CLS
+          commands in response to "unsolicited" RFCs.  There
+          are currently several ways to "solicit" an RFC, as
+          follows:
+
+          a)  A terminal user can tell the Terminal IMP to
+              perform the ICP to the TELNET Logger at some
+              foreign Host.  This action "solicits" the RFCs
+              defined by the ICP.
+
+          b)  A terminal user can send an RFC to any particular
+              Host and socket he chooses.  This "solicits" a
+              matching RFC.
+
+          c)  A terminal user can set his own receive socket
+              "wild."  This action "solicits" an STR from
+              anyone to his socket.  Similarly, the user can
+              set his send socket "wild" to "solicit" an RTS.
+
+          If the Terminal IMP receives a "solicited" RFC it
+          handles it in accordance with the protocol.  If the
+          Terminal IMP receives a control message containing
+          one or more "unsolicited" RFCs it will either issue
+          CLS commands or ignore the RFCs according to the
+          criteria described above for answering ECOs (and for
+          the same reasons).  Further, if the Terminal IMP
+          does issue a CLS in response to an unsolicited RFC
+          it will not wait for a matching CLS before
+          considering the sockets involved to be free for other
+          use.
+
+      3)  After issuing a CLS for a connection, the Terminal
+          IMP will not wait forever for a matching CLS.
+          There are two cases:
+
+
+
+                                                                [Page 3]
+
+RFC #215
+
+
+          a)  The Terminal IMP has sent an RFC, grown tired of
+              waiting for a matching RFC, and therefore issued
+              a CLS
+
+          b)  The Terminal IMP has sent a CLS for an
+              established connection (matching RFCs exchanged)
+
+          In either of these cases the Terminal IMP will wait
+          for a matching CLS for a "reasonable" time (probably
+          30 seconds to one minute) and will then "forget" the
+          connection.  After the connection is forgotten, the
+          Terminal IMP will consider both sockets involved to
+          be free for other use.
+
+          Because of program size and table size restrictions,
+          the Terminal IMP assigns socket numbers to a terminal
+          as a direct function of the physical address of the
+          terminal.  Thus (given this socket assignment scheme)
+          the failure of some foreign Host to answer a CLS
+          could permanently "hang" a terminal.  It might be
+          argued that the Terminal IMP could issue a RST to the
+          offending Host, but this would also break the
+          connections of other terminal users who might be
+          performing useful work with that Host.
+
+      4)  The Terminal IMP ignores all RET commands.  The
+          Terminal IMP cannot buffer very much input from the
+          network to a given terminal due to core size
+          limitations.  Accordingly, the Terminal IMP allocates
+          only one message and a very small number of bits
+          (currently 120 bits; eventually some number in the
+          range 8-4000, based on the terminal's speed) on each
+          connection for which the Terminal IMP is the
+          receiver.  Given such small allocations, the Terminal
+          IMP attempts to keep the usable bandwidth as high as
+          possible by sending a new allocation, which brings
+          the total allocation up to the maximum amount, each
+          time that:
+
+          a)  one of the two buffers assigned to the terminal
+              is empty, and
+
+          b)  the allocations are below the maxima.
+
+          Thus, if a spontaneous RET were received, the
+          reasonable thing for the Terminal IMP to do would be
+          to immediately issue a new ALL.  However, if a
+          foreign Host had some reason for issuing a first
+
+
+
+                                                                [Page 4]
+
+RFC #215
+
+
+          spontaneous RET, it would probably issue a second RET
+          as soon as it received the ALL.  This would be likely
+          to lead to an infinite (and very rapid) RET-ALL loop
+          between the two machines, chewing up a considerable
+          portion of the Terminal IMP's bandwidth.  Since the
+          Terminal IMP can't "afford" to communicate with such
+          a Host, it ignores all RETs.
+
+      5)  The Terminal IMP ignores all GVB commands.
+          Implementation of GVB appears to require an
+          unreasonable number of instructions and, at the
+          moment at least, no Host appears to use the GVB
+          command.  If we were to implement GVB we would always
+          RET all of both allocations and this doesn't seem
+          very useful.
+
+      6)  The Terminal IMP does not handle a total bit-
+          allocation greater than 65,534 (2^16-2) correctly.
+          If the bit-allocation is ever raised above 65,534 the
+          Terminal IMP will treat the allocation as infinite.
+          This treatment allows the Terminal IMP to store the
+          bit allocation for each connection in a single word,
+          and to avoid double precision addition and
+          subtraction.  Our reasons for this decision are:
+
+      a)  A saving of more than 100 words of memory which
+          would be required for allocation tables and for
+          double precision addition/subtraction routines.
+
+      b)  Our experience, which indicates that very few
+          Hosts (probably one at most) ever raise their
+          total bit allocation above 65,534 bits.
+
+      c)  Our expectation that any Host which ever raises
+          its bit allocation above 65,534 probably would be
+          willing to issue an infinite bit allocation if
+          one were provided by the protocol.  Once the bit
+          allocation is greater than about 16,000, the
+          message allocation (which the Terminal IMP
+          handles correctly) is a more powerful method of
+          controlling network loading of a Host system than
+          bit allocation.  We believe that Hosts which have
+          loading problems will recognize this.
+
+      7)  The Terminal IMP ignores the "32-bit number" in the
+          ICP.  When the Terminal IMP (the "user site")
+          initiates the Initial Connection Protocol the actual
+          procedure is to send the required RTS to the logger
+
+
+
+                                                                [Page 5]
+
+RFC #215
+
+
+          socket of the user-specified foreign Host and
+          simultaneously to set the terminal user's send and
+          receive sockets in a state where each will accept
+          any RFC from the specified Host.  The 32-bit socket
+          number transmitted over the logger connection is
+          ignored, and the first RTS and STR addressing the
+          user's sockets will be accepted (and answered with
+          matching RFCs).
+
+          The ICP allows the foreign Host to transmit the RFCs
+          involving Terminal IMP sockets "U+2" and "U+3" at
+          any time after receipt of the RFC to the (foreign
+          Host's) logger socket.  In particular, the RFCs may
+          arrive at the Terminal IMP before the 32-bit
+          number.  In the case of a "normal" foreign Host, the
+          first incoming RFCs for sockets U+2 and U+3 will come
+          from the sockets indicated by the 32-bit number, so
+          it doesn't matter if the number is ignored.  In the
+          case of a pathologic foreign Host, a potentially
+          infinite number of "wrong" RFCs involving U+2 and
+          U+3 may arrive at the Terminal IMP before the 32-bit
+          number is sent.  The Terminal IMP would be required
+          to store this stream of RFCs pending arrival of the
+          32-bit number, then issue CLS commands for all
+          "wrong" RFCs.  However, the Terminal IMP does not
+          have infinite storage available for this purpose (it
+          is also doubtful that a terminal user really wants to
+          converse with a pathologic foreign Host) so the
+          Terminal IMP assumes that the foreign Host is
+          "normal" and ignores the 32-bit number.
+
+   B)  Other Design Choices Related to Protocol
+
+          1)  The Terminal IMP ignores incoming ERR commands and
+              does not output ERR commands.
+
+          2)  The Terminal IMP assumes that incoming messages have
+              the format and contents demanded by the relevant
+              protocols.  For example, the byte size of incoming
+              TELNET messages is assumed to be 8.  The major checks
+              which the Terminal IMP does make are:
+
+              a)  If an incoming control message has a byte count
+                  greater than 120 then it is discarded.
+
+
+
+
+
+
+
+                                                                [Page 6]
+
+RFC #215
+
+
+              b)  If a control command opcode greater than 13 is
+                  found during the processing of a control message
+                  then the remainder of the control message is
+                  discarded.
+
+              c)  If an incoming data message has a byte count
+                  indicating that the bit allocation for the
+                  connection is exceeded (based on the assumed byte
+                  size) then the message is discarded.
+
+          3)  If one control message contains several RST commands
+              only one RRP is transmitted.  If several control
+              messages, each containing RST commands, arrive "close
+              together" only one RST is returned.  [The actual
+              implementation is to set a bit each time a RST is
+              found (in "foreground") and to reset the bit when a
+              RRP is sent (in "background").]
+
+          4)  Socket numbers are preassigned based on the hardware
+              "physical address" (in the terminal multiplexing
+              device) of the terminal.  The high order 16 bits of
+              the socket number give the device number (in the
+              range 0-63) and the low order bits are normally 2 or
+              3 depending on the socket's gender (zero is also used
+              during ICP).  [We would be pleased to see socket
+              number length reduced to 16 bits; in that case the
+              high order 8 bits would be mapped to the device and
+              the low order 8 bits would contain 2 or 3.]
+
+          5)  During ICP, with the Terminal IMP as the user site,
+              the Terminal IMP follows the "Listen" option rather
+              than the "Init" option (as described at the top of
+              page 3, NIC #7170).  In other words, the Terminal IMP
+              does not issue the RFCs involving sockets U+2 and U+3
+              except in response to incoming RFCs involving those
+              sockets.  In this context, we will mention that the
+              "deadlock" mentioned in NWG-RFC #202 does not exist,
+              since the ICP does not give the server the "Listen"
+              option (see NIC #7170, page 2).
+
+
+          [ This RFC was put into machine readable form for entry ]
+            [ into the online RFC archives by Randy Dunlap 5/97 ]
+
+
+
+
+
+
+
+
+                                                                [Page 7]
+