Ready line philosophy and implementation
RFC 642

Document Type RFC - Unknown (July 1974; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 642 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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

   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
Show full document text