The Terminal IMP implementation(1)

　　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 accessto 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.

　　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.

　　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.