From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc642.txt | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc642.txt (limited to 'doc/rfc/rfc642.txt') diff --git a/doc/rfc/rfc642.txt b/doc/rfc/rfc642.txt new file mode 100644 index 0000000..0b9116d --- /dev/null +++ b/doc/rfc/rfc642.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group Jerry Burchfiel +Request for Comments: 642 BBN +NIC: 30872 July 5, 1974 + + + Ready Line Philosophy and Implementation + +I. Introduction + + BBN Report #1822, Specifications for the Interconnection of a Host + and an IMP, gives a complete specification of the Host-IMP interface. + However, the authors of this document bent over backward to avoid + issuing arbitrary dictatorial directives to host interface + implementors. They succeeded admirably in this goal by describing + the IMP implementation, and suggesting similar behavior on the part + of the host. + + ARPA has appointed a PDP-11 local host interface standardization + committee composed of myself, Dave Retz of SCRL, and Yuval Peduel of + MIT Lincoln Labs. During our review of various interfaces designed + by the ARPA community, we have found total chaos, confusion and + misunderstanding about the recommended host interface implementation. + + This note is an attempt to make explicit the recommendations which + are implicit in Report #1822. It provides a cookbook for interface + implementors, including a set of recommended do's and don't's in the + common problem areas. This document has been reviewed and approved + by the BBN IMP group. + +II. Ready-line Philosophy + + The following is an attempt to spell out in detail a consistent plan + for operation of the IMP ready line and host ready line with the + following objectives: + + 1. Reliably resynchronize and resume transmission after a + temporary lapse of service and possible loss of state + information by either system. + + 2. Make the programming of the host interface as simple as + possible. This will minimize bugs, and make it possible to + create a small ROM network-bootstrap loader. + + First, consider the IMP ready line. When it drops, the IMP has + suffered a possible loss of state, so the message in transit from the + IMP to the host (if any) is likely to be incomplete. Similarly, the + message in transit from the host to the IMP (if any) is likely to be + incomplete. Both the host and the IMP must recognize this explicitly + + + +Burchfiel [Page 1] + +RFC 642 Ready Line Philosophy and Implementation July 1974 + + + by sending a message intended to be thrown away* (which may he + appended to the current message) and throw away the message currently + being received. (Both the host - IMP message and the IMP - host + message). + + The simplest arrangement for the host's interface driver is a pair of + processes, one sending messages and the other receiving messages. + This drop of the IMP's ready line must be provided as an error status + bit to each process. However, the two processes will need to clear + this condition independently: the simplest implementation is an Input + Error flop and an Output Error flop. Both flops are set by a drop of + the IMP's ready line, and they are cleared independently under + program control. + + When the IMP raises its ready line, each contact bounce will again + set the Error flops in the host's interface. To insure that messages + are not flowing across the interface at this time, assertions of the + signals "there's your IMP bit" and "ready for next host bit" have + been delayed sufficiently in the IMP to guarantee that the IMP ready + line has stabilized. + +III. Programming + + The interface driver processes can be described simply: + + INPUT: Wait until an input buffer is available + Wait until IMP ready + Start input + Wait until input is complete + IF Input Error + THEN clear Input Error // Flush smashed message. Input + // buffer will be reused. + ELSE queue message on input queue + GOTO INPUT + + OUTPUT: Wait until a message is present on output queue + Wait until IMP ready + Start output + Wait until output is complete + IF Output Error + THEN clear Output Error // smashed message is flushed + ELSE deque message from output queue // Free up + // output buffer + GOTO 0UTPUT + + ---------- + *The standard convention uses the host-IMP NOP message. + + + + +Burchfiel [Page 2] + +RFC 642 Ready Line Philosophy and Implementation July 1974 + + + The only initialization required for system startup or restart is + clearing the host READY flop, waiting 1/2 second, and setting the + host READY flop. Simply starting (or restarting) the above processes + will properly resynchronize host-IMP communication. As explained in + RFC #636, the IMP ready line (and error flops) should only affect the + two processes above: this resynchronization should be invisible to + the NCP, and should have no effect on the connection data base. The + NCP will be resynchronized or reinitialized by the type 10 IMP-to- + host message "interface was reset." + + Actually, it is possible to share a single Error flop between the + input and output processes by implementing Input Error and Output + Error as software flags. A process testing for error must test both + the Error flop and its own flag. An interlock is required (e.g. a + mutual exclusion semaphore) to guarantee that only one process at a + time is testing and modifying the flags. If the Error flop is set, + the process must copy it into the other process' flag before clearing + the flop and its own flag. + +IV. Host Ready Line Implementation + + When the host drops and raises its ready line, the IMP behaves in a + fashion symmetric to that outlined above. Of course, this drop + indicates that the state of the host's interface driver, as well as + the current incoming and outgoing messages, are likely to be lost. + The appropriate action is triggered by setting the Error flop or + flops in the host interface, and the processes specified above will + correctly resynchronize message flow in both directions. Of course, + to guarantee that messages are not flowing across the interface while + the host ready line is undergoing contact bounce, the host must delay + transmission until its ready line has stabilized. This may be done + in two ways: + + Hardware: an integrating one-shot driven by the host ready line + flop is ANDed with "there's your host bit" and "ready for + next IMP bit" to guarantee that message transfer will not + start until the ready flop has been on for 1/2 second. + + Software: the initialization program executes a 1/2 second wait + after setting the host ready flop before permitting input or + output to begin. + + + + + + + + + + +Burchfiel [Page 3] + +RFC 642 Ready Line Philosophy and Implementation July 1974 + + +V. Summary + + This determines the specification READY line controls for the host's + interface to the IMP: + + 1. It contains a program settable/clearable host READY flop which + drives a relay closure to the IMP. + + 2. It detects the IMP's ready signal as a program-readable status + condition. (But not an interrupt condition) + + 3. It contains one or two ERROR flops set when either the host + READY flop is off or the IMP ready signal is off. The flop + (flops) is a program-readable and program-clearable status + condition. (But not an interrupt condition). These status + flops must not be cleared by system initialization. + + 4. If hardware stabilization of the host's READY line is + provided, it is a 1/2 second integrating one-shot driven by + the host READY flop. This signal is ANDed with "there's your + host bit" and "ready for next IMP bit". + + + + + + + + + + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Alex McKenzie with ] + [ support from GTE, formerly BBN Corp. 2/2000 ] + + + + + + + + + + + + + + + + +Burchfiel [Page 4] + -- cgit v1.2.3