doc: Add RFC documents

1 files changed, 590 insertions, 0 deletions

diff --git a/doc/rfc/rfc745.txt b/doc/rfc/rfc745.txt
new file mode 100644
index 0000000..a16095b
--- /dev/null
+++ b/doc/rfc/rfc745.txt
@@ -0,0 +1,590 @@
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+Network Working Group                                     Michael Beeler
+Request for Comments 745                                             BBN
+NIC 43649                                                  30 March 1978
+PRTN 245
+
+                     JANUS Interface Specifications
+
+                   (Symmetrical, 1822-like Interface)
+
+1.  INTRODUCTION
+1.1.  Motivation
+
+A need arose in the Packet Radio project for specification of an
+interface between Packet Radio units and other equipment.  This paper is
+to meet BBN's responsibility to supply that specification.  It is our
+hope that it will find application in other areas as well.
+
+1.2.  Historical Relationship to 1822
+
+The ARPANET employs a network of switching nodes, called IMPs, to
+provide interconnection among user equipment, called hosts.  A uniform
+means of connecting a host to an IMP is specified in BBN Report Number
+1822.  Consequently, this interface has become known as an 1822
+interface.
+
+As the need to interconnect new types of devices has grown, it has
+become attractive to implement an 1822-like interface on each end of
+pairs of devices which are to communicate.  The devices are then
+connected electrically, and communication can take place in spite of
+differences in processing speed, word length, signal levels and so forth
+in the two devices.  A part of Report 1822 reads as follows.
+
+   "The technique of transferring information between the Host and the
+   IMP is identical in each direction; we will, therefore, refer to the
+   sender and the receiver without specifying the Host or IMP
+   explicitly."
+   [BBN Report Number 1822, 12/75 revision, page 4-2.]
+
+Unfortunately, Report 1822 does not specify a completely symmetrical
+interface.  Although there is a high degree of symmetry, some aspects
+are peculiar to the IMP side and some to the host side.  Therefore, two
+interfaces constructed to connect to IMPs may not function connected to
+each other.  In what follows, the unsymmetrical aspects are respecified
+in a way which will accomplish full interchangeability.
+
+The interface specified here is called the JANUS interface, to
+distinguish it from the Report 1822 interface.
+
+
+
+
+
+                                 - 1 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+1.3.  Terminology
+
+The terms, "IMP" and "host," are not relevant in the present context.
+Sections of Report 1822 such as Appendix B are conveniently
+re-interpreted by substituting "foreign interface" and "home interface,"
+respectively.
+
+2.  SPECIFICATIONS
+
+Report 1822 addresses two aspects of the connection of a host to the
+ARPANET, the hardware requirements and the software protocols.  Since
+the JANUS interface will typically be used in applications other than
+connection to the ARPANET, the higher level software protocols are
+beyond the scope of this paper. They are properly addressed by
+documentation specific to each application.  Concern here is only for
+electrical specification of the JANUS interface.  The various areas
+which differ from Report 1822 are as follows.
+
+2.1.  Low-level Protocol
+
+Certain aspects of the JANUS interface and its operation may be
+implemented in hardware, software of a mixture of the two.  We refer to
+these aspects as "low-level protocol."  They are to be distinguished
+from such "high-level protocol" aspects as header definitions and data
+formats.
+
+2.1.1.  Padding
+
+Requirement:
+Received messages are padded out to a full word (of the home device's
+size), if necessary, with zeros only.
+
+Discussion:
+A one-bit to mark the end of received data, as IMPs employ, is NOT used.
+The mark bit has not proved very useful, although the ARPANET IMPs do
+use it to generate the message length field in the new format header.
+Rather, counts at one or another level of protocol are generally used,
+so the complication of a mark bit can be eliminated.  It is the author's
+impression that the ARPANET will not implement this aspect of
+symmetrical interfaces, so hosts communicating through the ARPANET will
+continue to see the marker one-bit appended by the source IMP regardless
+of whether the hosts have 1822 or JANUS interfaces.
+
+2.1.2.  Message Length
+
+Requirement:
+A JANUS interface must accept messages up to and including 8160 bits
+long.
+
+
+
+
+                                 - 2 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+Exception:
+If the interface is absolutely never intended for use in
+ARPANET-compatible applications, this requirement may be relaxed in any
+of three ways.  A smaller maximum length may be implemented;  a larger
+maximum lengthbe implemented; or the maximum length may be so large as
+to be in practice infinite.
+
+Discussion:
+A JANUS interface may discard messages longer than 8160 bits when used
+with the ARPANET.  This constraint can be enforced in software rather
+than in hardware, if desired.
+
+2.1.3.  Four-way Handshake
+
+Requirement:
+The interface must use the four-way handshake.  That is, the receiver
+must wait until the incoming There's-Your-Bit drops before turning on
+Ready-For-Next-Bit.
+
+Discussion:
+The two-way handshake, presented as an option in Report 1822, must not
+be used.  Experience has shown that it is vulnerable to various
+failures.  First, if the off period in RFNB is not seen by the sender
+(due to noise or its being too short), a deadlock occurs and no more
+data is transferred.  Second, a two-way receiver cannot talk with a
+strictly four-way sender, since the sender's next assertion of TYB may
+depend on seeing the RFNB transition to on.  And third, the two-way
+handshake is overly sensitive to transitions, and may be activated by
+noise pulses. Transitions in the two-way handshake may be missed
+altogether in a sender implementation which samples the RFNB line only
+at certain intervals.  The superiority of the more positive four-way
+handshake is important in applications where neither of the
+communicating interfaces is necessarily constructed to particular
+standards.
+
+2.1.4.  Contact Bounce
+
+Requirement:
+Each interface, considered together with the software driving it, must
+prevent data from flowing across the interface in either direction while
+its Ready relay contacts may be bouncing.  Thus, for 1/10 second after
+raising Ready, the outgoing signals There's-Your-Bit and
+Ready-For-Next-Bit must not be asserted.
+
+Discussion:
+This may be accomplished either in hardware or software, as discussed in
+Report 1822 section B.3.  The delay of 1/10 second is specified here to
+resolve an ambiguity in Report 1822, concerning whether a shorter delay
+was acceptable if the relay was known to solidly finish closing sooner.
+
+
+
+                                 - 3 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+Report 1822 specified a 1/2 second delay, but modern reed relays
+reliably finish closing in 1/10 second.
+
+2.1.5.  RFNB, TYB Minimum Off Time
+
+Requirement:
+Ready-For-Next-Bit must be off for at least 50 nanoseconds for local
+host connections, and at least 1 microsecond for distant host
+connections, as seen by the receiver of the signal (who is the sender of
+data).  Note that this means that RFNB at the cable driver may have to
+be off for somewhat longer than this minimum if deterioration of the
+signal waveform along the cable is anticipated.  There's-Your-Bit must
+similarly be off for at least 50 nanoseconds for local host connections,
+and at least 1 microsecond for distant host connections, as seen by the
+receiver of the signal.
+
+Discussion:
+This extends the Report 1822 requirements for signals received by the
+IMP, to both interfaces in a JANUS interface pair.
+
+2.1.6.  Deskewing
+
+Requirement:
+The outgoing data bit must be on the line and the Last-Bit level correct
+at least 500 nanoseconds before the sender turns on the There's-Your-Bit
+signal.  The sender must turn off TYB before changing either the data or
+the LB.
+
+Discussion:
+The responsibility for deskewing signals rests with the sender in each
+interface.  This applies the Report 1822 IMP sender behavior to each
+JANUS interface as a requirement.  Note that the receiver may count on
+the Last-Bit signal being valid during, and only during, the assertion
+of There's-Your-Bit.  Specifically, Last-Bit must be asserted during
+transmission of the last data bit.  Report 1822 was slightly ambiguous
+in this regard.
+
+2.1.7.  Transmission Order
+
+Requirement:
+"The high-order bit of each word is transmitted first."  (Report 1822,
+section 4.1.)
+
+Discussion:
+If a computer has addressing modes other than word addressing, such
+units or bytes are not used as units of transmission by the interface.
+For example, the first bit transmitted from or received into a PDP-11 is
+bit 15, the leftmost bit of a 16-bit word.  This is repeated here to
+bring it especially to the attention of designers.
+
+
+
+                                 - 4 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+2.2.  Distant Host Electrical Requirements
+
+Discussion:
+The paragraphs below specify a Distant Host option of the JANUS
+interface which differs substantially from the 1822 Distant Host
+interface.  Several considerations prompted this change.  Report 1822
+specifies transformer coupling at the receiver, so requirements on
+signal rise time and hold times were made.  To relax these, and to
+achieve greater tolerance to differences in ground potential, optical
+isolators are now often used, even in 1822 interfaces.  Neither the
+Report 1822 Distant Host driver, nor the driver adopted for JANUS,
+generate more than 1.0 volt. Commonly available optical isolators
+require at least 1.1 volts to overcome their forward drop before they
+will operate.  Thus an optical isolator driver is needed in both the
+1822 and the JANUS receivers.  The ground potential difference between
+the communicating interface may exceed the maximum ratings of the input
+amplifier, so the input circuit must be powered from a floating power
+supply.  Appropriate DC-DC converters for this purpose are available at
+reasonable cost.
+
+2.2.1.  DH Signal Timing
+
+Requirement:
+Receiver circuits in distant host interfaces shall be implemented with
+optical isolators or other means which are not sensitive to rise and
+hold times, as transformer coupling is.  Therefore, the requirements for
+rise and hold times on distant host signals appearing in Report 1822 are
+suspended.
+
+2.2.2.  DH Signal Levels and Waveforms
+
+Requirement:
+Signal levels and waveforms at the driver and the receiver shall follow
+the specifications in EIA standard RS-422.  In particular, the driver
+must supply a differential of at least 2 and not more than 6 volts;  and
+the receiver must operate correctly on as small a differential as 0.2
+volts.
+
+2.2.3.  DH Electrical Isolation
+
+Requirement:
+The receiver circuit must operate correctly over a common mode voltage
+range of -100 to +100 volts, and must not be permanently damaged by a
+common mode voltage of from -300 to +300 volts.
+
+
+
+
+
+
+
+
+                                 - 5 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+Exception:
+If the interface is absolutely never intended for use in an environment
+where common mode voltage exceeds 7 volts in magnitude, or where the
+voltage from either signal wire to the signal ground exceeds 10 volts in
+magnitude, then the electrical isolation required in this paragraph may
+be suspended, and the corresponding requirements of EIA specification
+RS-422 applied in its place.  Such an implementation is explicitly an
+exceptional JANUS interface, and is not the standard JANUS interface.
+
+Discussion:
+A suggested way to achieve this isolation is an RS-422 receiver chip,
+such as the Motorola MC3487 or the Advanced Micro Devices Am26LS32,
+followed by an LED driver as needed, followed by an optical isolator
+such as the Hewlett-Packard 5082-4360.  The receivers and LED drivers
+for all input lines may be powered from one source, but this power must
+be floated with respect to ground of the home interface.
+
+2.2.4.  DH Cable Shield Grounding
+
+Requirement:
+At each end the cable shield in a distant host connection shall be
+connected through a circuit described below to signal ground. The
+circuit consists of two components connected in parallel. (1) A 100K,
+1/8 watt resistor provides a path to leak off slow accumulations of
+static charge.
+(2) A .01 mfd, 600 V ceramic capacitor bypasses sharp noise spikes.
+
+Exception:
+In cases of severe noise, one end of the shield or the other (but not
+both!) may have to be tied directly to ground, sacrificing the symmetry.
+
+Discussion:
+Grounding the cable shield only at the host end, as in Report 1822, is
+undefined when the interface is symmetrical.  Instead, the circuit above
+will be used.
+
+2.2.5.  DH Cable
+
+Requirement:
+Cable requirements in EIA specification RS-422 must be followed with
+respect to quality and electrical characteristics, and those in Report
+1822 with respect to number of conductors.  In particular, at least 10
+twisted pairs with impedance of approximately 100 ohms must be supplied.
+
+
+
+
+
+
+
+
+
+                                 - 6 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+Discussion:
+A suitable cable is PE-39, described in REA Bulletin 345-67. This cable
+is similar to that mass produced for telephone cable, which is of good,
+uniform quality, and readily available at reasonable cost.  The cable
+specified in Report 1822 is not as desirable.  Note the change in
+specified characteristic impedance:  Report 1822 specified 120 ohms,
+while the JANUS interfaces follow RS-422 with 100 ohms.
+
+2.2.6.  DH Cable Termination
+
+Requirement:
+Termination shall be as specified in RS-422, in particular at the
+receiver.  Termination as in Report 1822, at the driver, shall NOT be
+used.
+
+Discussion:
+The source-end termination specified in Report 1822 was to eliminate the
+voltage drop caused by the cable's series resistance.  RS-422 explicitly
+allows for this sort of signal attenuation as a part of the
+specification.
+
+3.  STRONG RECOMMENDATIONS
+3.1.  Local Host Signal Levels
+
+Suggested voltage levels for local host drivers and receivers are given
+below.  The levels below are a combination of Report 1822 levels for
+316/516 and Pluribus machines.  The intent here is to be compatible with
+readily available TTL components.  Suggested chips are the 7440 for a
+driver and the 7420 for a receiver. Note that signals may go up to 6
+volts, which may damage receiving circuits constructed of normal 5-volt
+logic.  Such receivers should have a voltage divider on their inputs.
+
+   driver output voltage
+        with input = 0:    -   min,  0.35 max  (0.07 typical)
+        with input = 1:   3.5  min,  6.0  max  (5.0  typical)
+   receiver input voltage
+        to assume a binary 0:   0.6  min  (0.9  typical)
+        to assume a binary 1:   2.5  max  (1.7  typical)
+        maximum input rating:   6.0  max
+
+Cable impedance and termination circuits are covered in Report 1822.
+With properly chosen cable and well designed circuits, and with
+impedances matched, local host connections may operate considerably
+farther than the 30 feet given in Report 1822. Cables as long as 300
+feet are in use communicating with ARPANET IMPs.  For example, 300 foot
+cables have worked using 7440's as drivers, standard TTL gates as
+receivers, cable termination (on all signal lines) of a diode to ground
+and a diode to +3 volts, and RG174/U cable.  RG174/U is 50 ohm coax, and
+a 100 ohm coax is preferred, to reduce ringing.
+
+
+
+                                 - 7 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+3.2.  Use of the Ready Line
+
+It is strongly recommended that the Ready Line provided by the hardware
+be used by the software in a manner similar or identical to that
+described in Report 1822.  Report 1822 sections 3.2, 4.4 and Appendix B
+especially bear on this topic.  In particular, the software design
+should provide for the following:
+
+   (1) A ready indicator (relay) which tells the foreign interface that
+       the home interface and software are ready to communicate.
+
+   (2) An "error" flip-flop which tells the home software that the
+       foreign interface has been not ready.
+
+   (3) NOP messages which are used to purge the communication "pipe"
+       after the ready line has "flapped" down and back up.
+
+4.  ADVICE ON DELAYS TO LIMIT BANDWIDTH
+
+It is advisable to include adjustable delays whose function is to limit
+the maximum bandwidth of transfers, as discussed in Report 1822.  Only
+when the details (such as cable characteristics, memory speed, and
+acceptable memory utilization) of a specific application guarantee that
+an unregulated transfer rate will be acceptable can these delays be
+omitted.  Two delays are involved, one in the sender circuit and one in
+the receiver circuit.  The sender delays up to 10 microseconds
+(adjustable) from when the foreign interface drops Ready-For-Next-Bit,
+before again turning on There's-Your-Bit.  (This is the sum of delays C
+and D in Report 1822 Fig. B-1.)  The receiver delays up to 10
+microseconds (adjustable) from when the foreign interface asserts
+There's-Your-Bit, before again turning on Ready-For-Next-Bit. (This is
+the sum of delays A and B in Report 1822 Fig. B-2.) When delivered,
+interfaces should have these delays set at approximately the maximum
+delay.  The timing is shown below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                 - 8 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+   
+                            _______         _______
+      sender's TYB  _______!       !_______!       !___
+
+                        _______         _______
+      foreign RFNB  ___!       !_______!       !________
+                               !<--delay-->!
+
+                            _______         _______
+       foreign TYB  _______!       !_______!       !___
+
+                        _______         _______
+   receiver's RFNB  ___!       !_______!       !________
+                           !<--delay-->!
+
+5.  INTER-OPERABILITY WITH 1822 INTERFACES
+
+Protocol specifications have been chosen which are compatible with
+Report 1822.  Actually, the protocol areas discussed above are further
+clarification of Report 1822, rather than any change from it.  The
+electrical specifications differ only slightly from the 1822 interface.
+The local host levels chosen are 1822 compatible.  The potential
+difficulties in using a JANUS interface cabled to an 1822 interface
+arise with the distant host interface.
+
+The distant host cable for a JANUS interface is 100 ohms nominal
+impedance, compared to 120 ohms for the 1822 interface.  This difference
+is small enough that most applications will work with either cable, or
+even with some 100 ohm cable and some 120 ohm cable.
+
+The 1822 distant host interface does not provide as much electrical
+isolation as the standard JANUS distant host interface.  Thus, in cases
+of severe common mode noise or ground potential difference, two JANUS
+interfaces might operate correctly, but an 1822 interface might
+misbehave or burn out.
+
+The JANUS distant host driver yields 2 to 6 volts output, and its
+receiver requires 0.2 volts input; the 1822 distant host driver yields
+1.0 volt output, and its receiver requires 0.1 volt input. Unless there
+is a significant signal loss in the cable, the 1822 driver will drive a
+JANUS receiver acceptably.  On the other hand, the maximum input to an
+1822 receiver is 4.0 volts.  Thus a JANUS driver might overdrive an 1822
+receiver.  The simplest fix for this is to put a (balanced) voltage
+divider at the 1822 receiver, or at the JANUS driver.  The divider
+should cut down the maximum voltage from 6 volts to 4 volts, or a
+reduction of 1/3.
+
+
+
+
+
+
+                                 - 9 -
+
+NWG/RFC# 745                                        MDB2 30-MAR-78 43649
+JANUS Interface Specifications
+
+
+
+The above differences are relatively minor, so in most applications an
+interconnected 1822 interface and a JANUS interface should operate
+correctly.  Attention must be paid to the electrical isolation
+susceptibility of the 1822, and to its maximum input voltage.
+
+6.  MILITARY COMPATIBILITY
+
+The EIA specification RS-422 chosen as a base for the JANUS interface
+distant host electrical characteristics is compatible with military
+specification MIL-188-114.
+
+The common mode voltage tolerance of the JANUS interface provides
+significant protection against widely varying ground potentials in field
+equipment separated by distances of thousands of feet.
+
+7.  REFERENCES
+
+"Specifications for the Interconnection of a Host and an IMP," BBN
+Report 1822, revised January 1976; BBN Inc., 50 Moulton St., Cambridge,
+Ma. 02138.
+
+"Electrical Characteristics of Balanced Voltage Digital Interface
+Circuits, EIA standard RS-422," April 1975; Engineering Dept.,
+Electronic Industries Assn., 2001 Eye St., N.W., Washington, D.C.,
+20006.
+
+REA bulletin 345-67, Rural Electrification Admin., U.S. Dept. of
+Agriculture.  Contains specification for PE-39 cable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                 - 10 -
\ No newline at end of file