RFC 745

RFC 745: JANUS Interface Specifications 🎀

okay bestie, the header is giving RFC 745, "JANUS Interface Specifications" 💅, with the subtitle (Symmetrical, 1822-like Interface). It's from the Network Working Group, written by Michael Beeler of BBN 🌸. It's marked as Request for Comments 745, NIC 43649, PRTN 245, and dated 30 March 1978 📅. The header doesn't name a category or status, and it doesn't list anything this RFC obsoletes or updates, so there's nothing to chase down there 🫶.

---

1. INTRODUCTION ✨

1.1. Motivation

So the Packet Radio project needed a spec for an interface between Packet Radio units and other equipment 📡. BBN had the job of supplying it, and this paper is that spec. they're hoping it finds a home in other areas too 🌈.

1.2. Historical Relationship to 1822

The ARPANET runs on a network of switching nodes called IMPs, and those connect user equipment called hosts 🖥️. The uniform way to hook a host up to an IMP is written up in BBN Report Number 1822, which is why people call it the 1822 interface 👑.

As more kinds of devices needed to talk to each other, it got really attractive to put an 1822-like interface on each end of any pair that needs to communicate 🔌. You wire them together, and they can still talk even when their processing speed, word length, signal levels and so on are different 🦋. Report 1822 even says this:

"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.]

Here's the plot twist though 😭. Report 1822 is not a fully symmetrical interface. It's super symmetrical, but some bits are IMP-specific and some are host-specific. So two interfaces built to connect to IMPs might not work when plugged into each other 🙈. This paper respecifies the unsymmetrical bits so everything is fully interchangeable 💖.

The interface defined here is called the JANUS interface, so it doesn't get mixed up with the Report 1822 one ✨.

1.3. Terminology

"IMP" and "host" don't really matter in this context 🙅‍♀️. Sections of Report 1822, like Appendix B, are easier to read if you swap in "foreign interface" for the IMP side and "home interface" for the host side 🧚.

---

2. SPECIFICATIONS 💅

Report 1822 covers two things: the hardware requirements and the software protocols 🔧. JANUS is going to get used for way more than the ARPANET, so the higher-level software protocols are out of scope here. Those belong in documentation for each application 📚. This paper is only about the electrical spec, and the bits that differ from Report 1822 are listed below 💜.

2.1. Low-level Protocol

Some parts of the JANUS interface and how it works MAY be implemented in hardware, in software, or in a mix of both 🛠️. These are called "low-level protocol" 🫧. They're different from "high-level protocol" stuff like 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 marker to mark the end of received data, the kind IMPs use, is NOT used 🚫. The mark bit hasn't proved very useful, although the ARPANET IMPs do use it to generate the message length field in the new format header 🤷‍♀️. Counts at one or another level of protocol are generally used instead, so the mark bit complication can just be eliminated ✨. The author's impression is that the ARPANET won't implement this part of symmetrical interfaces, so hosts talking through the ARPANET will keep seeing the marker one-bit appended by the source IMP, whether they have 1822 or JANUS interfaces 🫶.

2.1.2. Message Length

Requirement: A JANUS interface MUST accept messages up to and including 8160 bits long 📏.

Exception: If the interface is absolutely never intended for ARPANET-compatible applications, this requirement MAY be relaxed in any of three ways. A smaller maximum length MAY be implemented; a larger maximum length be 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 it's used with the ARPANET 🗑️. This limit can be enforced in software instead of hardware, if that's what you want 💅.

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, which Report 1822 presents as an option, MUST NOT be used 🙅‍♀️. Experience has shown it's vulnerable to a bunch of failures 💀. First, if the off period in RFNB isn't seen by the sender (because of noise or because it's too short), a deadlock happens and no more data gets transferred 😱. Second, a two-way receiver can't talk to 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 set off by noise pulses 📳. Transitions in the two-way handshake may get missed altogether in a sender implementation that only samples the RFNB line at certain intervals 👀. The more positive four-way handshake is the superior choice, and it matters most in applications where neither of the communicating interfaces is necessarily built 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 🛑. So, 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 in hardware or in software, as discussed in Report 1822 section B.3 🔧. The 1/10 second delay is specified here to clear up an ambiguity in Report 1822 💅. The ambiguity was whether a shorter delay was OK if the relay was known to finish closing sooner, solidly 🤔.

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 RFNB at the cable driver may have to be off for somewhat longer than that minimum if the signal waveform is expected to deteriorate along the cable 📉. 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, with 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 📋. 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 about this, so this clears it up 💅.

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, units like bits 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 💖. It's repeated here so designers don't miss it 👀.

---

2.2. Distant Host Electrical Requirements 🌍

Discussion: The paragraphs below specify a Distant Host option of the JANUS interface, and it's pretty different from the 1822 Distant Host interface 🔄. A few things pushed for the change 💭. Report 1822 specifies transformer coupling at the receiver, so it has requirements on signal rise time and hold times 📐. To relax those, and to get more tolerance for 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 generates more than 1.0 volt ⚡. Commonly available optical isolators need at least 1.1 volts to overcome their forward drop before they'll operate 😤. So an optical isolator driver is needed in both the 1822 and the JANUS receivers 🫶. The ground potential difference between the communicating interfaces 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 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 that aren't sensitive to rise and hold times, the way 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 it MUST NOT be permanently damaged by a common mode voltage of from -300 to +300 volts 🛡️.

Exception: If the interface is absolutely never intended for 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 🫧. The corresponding requirements of EIA specification RS-422 get applied in its place 📜. Such an implementation is explicitly an exceptional JANUS interface, and it is not the standard JANUS interface 🚫.

Discussion: A suggested way to get this isolation is an RS-422 receiver chip, like the Motorola MC3487 or the Advanced Micro Devices Am26LS32 💻. It's followed by an LED driver as needed, and then 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 that power MUST be floated with respect to the 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) A 100K, 1/8 watt resistor gives slow buildups of static charge a path to leak off 🍓✨ (2) A .01 mfd, 600 V ceramic capacitor soaks up 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 🫠 So instead, the circuit above will be used 🎀

2.2.5. DH Cable 🌈

Requirement: Cable requirements in EIA specification RS-422 must be followed for quality and electrical characteristics 💖 and the ones in Report 1822 for number of conductors 🧚 Specifically, at least 10 twisted pairs with impedance of approximately 100 ohms must be supplied 🦋

Discussion: A suitable cable is PE-39, described in REA Bulletin 345-67 ✨ It's similar to the cable mass produced for telephone use, so it's of good, uniform quality and readily available at reasonable cost 💜 The cable specified in Report 1822 is not as desirable 🙃 Also, 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 in Report 1822 was meant to cancel out the voltage drop caused by the cable's series resistance 🧃 RS-422 explicitly allows for this sort of signal attenuation as 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 💖 They're a combination of Report 1822 levels for 316/516 and Pluribus machines ⭐ The goal is to be compatible with readily available TTL components 🎀 Suggested chips are the 7440 for a driver and the 7420 for a receiver 🧚 Heads up: signals may go up to 6 volts, which may damage receiving circuits built from 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, well-designed circuits, and matched impedances, local host connections can 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, but a 100 ohm coax is preferred to reduce ringing 🌈

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 of a specific application (such as cable characteristics, memory speed, and acceptable memory utilization) guarantee that an unregulated transfer rate will be acceptable can these delays be omitted 🙈 There are two delays 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 👇

                            _______         _______
      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 💖 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 come up 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 🧵 That difference is small enough that most applications will work with either cable, or even with some 100 ohm cable mixed with some 120 ohm cable 🫶

The 1822 distant host interface doesn't provide as much electrical isolation as the standard JANUS distant host interface 😬 So 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's 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 😳 So a JANUS driver might overdrive an 1822 receiver 🫣 The simplest fix is to put a (balanced) voltage divider at the 1822 receiver, or at the JANUS driver 🧁 The divider should cut the maximum voltage from 6 volts to 4 volts, a reduction of 1/3 ✨

The above differences are relatively minor, so in most applications an interconnected 1822 interface and 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 the 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.