As per Relevance of the word software, we have this rfc below:
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
Network Working Group Michael
Request for Comments 745
NIC 43649 30 March 1978
PRTN 245
JANUS Interface
(Symmetrical, 1822-like Interface
1.
1.1.
A need arose in the Packet Radio project for specification of
interface between Packet Radio units and other equipment. This paper
to meet BBN's responsibility to supply that specification. It is
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,
provide interconnection among user equipment, called hosts. A
means of connecting a host to an IMP is specified in BBN Report
1822. Consequently, this interface has become known as an 1822
interface
As the need to interconnect new types of devices has grown, it
become attractive to implement an 1822-like interface on each end
pairs of devices which are to communicate. The devices are
connected electrically, and communication can take place in spite
differences in processing speed, word length, signal levels and so
in the two devices. A part of Report 1822 reads as follows
"The technique of transferring information between the Host and
IMP is identical in each direction; we will, therefore, refer to
sender and the receiver without specifying the Host or
explicitly."
[BBN Report Number 1822, 12/75 revision, page 4-2.]
Unfortunately, Report 1822 does not specify a completely
interface. Although there is a high degree of symmetry, some
are peculiar to the IMP side and some to the host side. Therefore,
interfaces constructed to connect to IMPs may not function connected
each other. In what follows, the unsymmetrical aspects are
in a way which will accomplish full interchangeability
The interface specified here is called the JANUS interface,
distinguish it from the Report 1822 interface
- 1 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
1.3.
The terms, "IMP" and "host," are not relevant in the present context
Sections of Report 1822 such as Appendix B are
re-interpreted by substituting "foreign interface" and "home interface,"
respectively
2.
Report 1822 addresses two aspects of the connection of a host to
ARPANET, the hardware requirements and the software protocols.
the JANUS interface will typically be used in applications other
connection to the ARPANET, the higher level software protocols
beyond the scope of this paper. They are properly addressed
documentation specific to each application. Concern here is only
electrical specification of the JANUS interface. The various
which differ from Report 1822 are as follows
2.1. Low-level
Certain aspects of the JANUS interface and its operation may
implemented in hardware, software of a mixture of the two. We refer
these aspects as "low-level protocol." They are to be
from such "high-level protocol" aspects as header definitions and
formats
2.1.1.
Requirement
Received messages are padded out to a full word (of the home device'
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
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'
impression that the ARPANET will not implement this aspect
symmetrical interfaces, so hosts communicating through the ARPANET
continue to see the marker one-bit appended by the source IMP
of whether the hosts have 1822 or JANUS interfaces
2.1.2. Message
Requirement
A JANUS interface must accept messages up to and including 8160
long
- 2 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
Exception
If the interface is absolutely never intended for use
ARPANET-compatible applications, this requirement may be relaxed in
of three ways. A smaller maximum length may be implemented; a
maximum lengthbe implemented; or the maximum length may be so large
to be in practice infinite
Discussion
A JANUS interface may discard messages longer than 8160 bits when
with the ARPANET. This constraint can be enforced in software
than in hardware, if desired
2.1.3. Four-way
Requirement
The interface must use the four-way handshake. That is, the
must wait until the incoming There's-Your-Bit drops before turning
Ready-For-Next-Bit
Discussion
The two-way handshake, presented as an option in Report 1822, must
be used. Experience has shown that it is vulnerable to
failures. First, if the off period in RFNB is not seen by the
(due to noise or its being too short), a deadlock occurs and no
data is transferred. Second, a two-way receiver cannot talk with
strictly four-way sender, since the sender's next assertion of TYB
depend on seeing the RFNB transition to on. And third, the two-
handshake is overly sensitive to transitions, and may be activated
noise pulses. Transitions in the two-way handshake may be
altogether in a sender implementation which samples the RFNB line
at certain intervals. The superiority of the more positive four-
handshake is important in applications where neither of
communicating interfaces is necessarily constructed to
standards
2.1.4. Contact
Requirement
Each interface, considered together with the software driving it,
prevent data from flowing across the interface in either direction
its Ready relay contacts may be bouncing. Thus, for 1/10 second
raising Ready, the outgoing signals There's-Your-Bit
Ready-For-Next-Bit must not be asserted
Discussion
This may be accomplished either in hardware or software, as discussed
Report 1822 section B.3. The delay of 1/10 second is specified here
resolve an ambiguity in Report 1822, concerning whether a shorter
was acceptable if the relay was known to solidly finish closing sooner
- 3 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
Report 1822 specified a 1/2 second delay, but modern reed
reliably finish closing in 1/10 second
2.1.5. RFNB, TYB Minimum Off
Requirement
Ready-For-Next-Bit must be off for at least 50 nanoseconds for
host connections, and at least 1 microsecond for distant
connections, as seen by the receiver of the signal (who is the sender
data). Note that this means that RFNB at the cable driver may have
be off for somewhat longer than this minimum if deterioration of
signal waveform along the cable is anticipated. There's-Your-Bit
similarly be off for at least 50 nanoseconds for local host connections
and at least 1 microsecond for distant host connections, as seen by
receiver of the signal
Discussion
This extends the Report 1822 requirements for signals received by
IMP, to both interfaces in a JANUS interface pair
2.1.6.
Requirement
The outgoing data bit must be on the line and the Last-Bit level
at least 500 nanoseconds before the sender turns on the There's-Your-
signal. The sender must turn off TYB before changing either the data
the LB
Discussion
The responsibility for deskewing signals rests with the sender in
interface. This applies the Report 1822 IMP sender behavior to
JANUS interface as a requirement. Note that the receiver may count
the Last-Bit signal being valid during, and only during, the
of There's-Your-Bit. Specifically, Last-Bit must be asserted
transmission of the last data bit. Report 1822 was slightly
in this regard
2.1.7. Transmission
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 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
bit 15, the leftmost bit of a 16-bit word. This is repeated here
bring it especially to the attention of designers
- 4 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
2.2. Distant Host Electrical
Discussion
The paragraphs below specify a Distant Host option of the
interface which differs substantially from the 1822 Distant
interface. Several considerations prompted this change. Report 1822
specifies transformer coupling at the receiver, so requirements
signal rise time and hold times were made. To relax these, and
achieve greater tolerance to differences in ground potential,
isolators are now often used, even in 1822 interfaces. Neither
Report 1822 Distant Host driver, nor the driver adopted for JANUS
generate more than 1.0 volt. Commonly available optical
require at least 1.1 volts to overcome their forward drop before
will operate. Thus an optical isolator driver is needed in both
1822 and the JANUS receivers. The ground potential difference
the communicating interface may exceed the maximum ratings of the
amplifier, so the input circuit must be powered from a floating
supply. Appropriate DC-DC converters for this purpose are available
reasonable cost
2.2.1. DH Signal
Requirement
Receiver circuits in distant host interfaces shall be implemented
optical isolators or other means which are not sensitive to rise
hold times, as transformer coupling is. Therefore, the requirements
rise and hold times on distant host signals appearing in Report 1822
suspended
2.2.2. DH Signal Levels and
Requirement
Signal levels and waveforms at the driver and the receiver shall
the specifications in EIA standard RS-422. In particular, the
must supply a differential of at least 2 and not more than 6 volts;
the receiver must operate correctly on as small a differential as 0.2
volts
2.2.3. DH Electrical
Requirement
The receiver circuit must operate correctly over a common mode
range of -100 to +100 volts, and must not be permanently damaged by
common mode voltage of from -300 to +300 volts
- 5 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
Exception
If the interface is absolutely never intended for use in an
where common mode voltage exceeds 7 volts in magnitude, or where
voltage from either signal wire to the signal ground exceeds 10 volts
magnitude, then the electrical isolation required in this paragraph
be suspended, and the corresponding requirements of EIA
RS-422 applied in its place. Such an implementation is explicitly
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
such as the Hewlett-Packard 5082-4360. The receivers and LED
for all input lines may be powered from one source, but this power
be floated with respect to ground of the home interface
2.2.4. DH Cable Shield
Requirement
At each end the cable shield in a distant host connection shall
connected through a circuit described below to signal ground.
circuit consists of two components connected in parallel. (1) A 100K
1/8 watt resistor provides a path to leak off slow accumulations
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
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,
undefined when the interface is symmetrical. Instead, the circuit
will be used
2.2.5. DH
Requirement
Cable requirements in EIA specification RS-422 must be followed
respect to quality and electrical characteristics, and those in
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
Discussion
A suitable cable is PE-39, described in REA Bulletin 345-67. This
is similar to that mass produced for telephone cable, which is of good
uniform quality, and readily available at reasonable cost. The
specified in Report 1822 is not as desirable. Note the change
specified characteristic impedance: Report 1822 specified 120 ohms
while the JANUS interfaces follow RS-422 with 100 ohms
2.2.6. DH Cable
Requirement
Termination shall be as specified in RS-422, in particular at
receiver. Termination as in Report 1822, at the driver, shall NOT
used
Discussion
The source-end termination specified in Report 1822 was to eliminate
voltage drop caused by the cable's series resistance. RS-422
allows for this sort of signal attenuation as a part of
specification
3. STRONG
3.1. Local Host Signal
Suggested voltage levels for local host drivers and receivers are
below. The levels below are a combination of Report 1822 levels
316/516 and Pluribus machines. The intent here is to be compatible
readily available TTL components. Suggested chips are the 7440 for
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-
logic. Such receivers should have a voltage divider on their inputs
driver output
with input = 0: - min, 0.35 max (0.07 typical
with input = 1: 3.5 min, 6.0 max (5.0 typical
receiver input
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
Cable impedance and termination circuits are covered in Report 1822.
With properly chosen cable and well designed circuits, and
impedances matched, local host connections may operate
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
cables have worked using 7440's as drivers, standard TTL gates
receivers, cable termination (on all signal lines) of a diode to
and a diode to +3 volts, and RG174/U cable. RG174/U is 50 ohm coax,
a 100 ohm coax is preferred, to reduce ringing
- 7 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
3.2. Use of the Ready
It is strongly recommended that the Ready Line provided by the
be used by the software in a manner similar or identical to
described in Report 1822. Report 1822 sections 3.2, 4.4 and Appendix
especially bear on this topic. In particular, the software
should provide for the following
(1) A ready indicator (relay) which tells the foreign interface
the home interface and software are ready to communicate
(2) An "error" flip-flop which tells the home software that
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
It is advisable to include adjustable delays whose function is to
the maximum bandwidth of transfers, as discussed in Report 1822.
when the details (such as cable characteristics, memory speed,
acceptable memory utilization) of a specific application guarantee
an unregulated transfer rate will be acceptable can these delays
omitted. Two delays are involved, one in the sender circuit and one
the receiver circuit. The sender delays up to 10
(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
and D in Report 1822 Fig. B-1.) The receiver delays up to 10
microseconds (adjustable) from when the foreign interface
There's-Your-Bit, before again turning on Ready-For-Next-Bit. (This
the sum of delays A and B in Report 1822 Fig. B-2.) When delivered
interfaces should have these delays set at approximately the
delay. The timing is shown below
- 8 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
_______ _______
sender's TYB _______! !_______! !___
_______ _______
foreign RFNB ___! !_______! !________
!<--delay-->!
_______ _______
foreign TYB _______! !_______! !___
_______ _______
receiver's RFNB ___! !_______! !________
!<--delay-->!
5. INTER-OPERABILITY WITH 1822
Protocol specifications have been chosen which are compatible
Report 1822. Actually, the protocol areas discussed above are
clarification of Report 1822, rather than any change from it.
electrical specifications differ only slightly from the 1822 interface
The local host levels chosen are 1822 compatible. The
difficulties in using a JANUS interface cabled to an 1822
arise with the distant host interface
The distant host cable for a JANUS interface is 100 ohms
impedance, compared to 120 ohms for the 1822 interface. This
is small enough that most applications will work with either cable,
even with some 100 ohm cable and some 120 ohm cable
The 1822 distant host interface does not provide as much
isolation as the standard JANUS distant host interface. Thus, in
of severe common mode noise or ground potential difference, two
interfaces might operate correctly, but an 1822 interface
misbehave or burn out
The JANUS distant host driver yields 2 to 6 volts output, and
receiver requires 0.2 volts input; the 1822 distant host driver
1.0 volt output, and its receiver requires 0.1 volt input. Unless
is a significant signal loss in the cable, the 1822 driver will drive
JANUS receiver acceptably. On the other hand, the maximum input to
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)
divider at the 1822 receiver, or at the JANUS driver. The
should cut down the maximum voltage from 6 volts to 4 volts, or
reduction of 1/3.
- 9 -
NWG/RFC# 745 MDB2 30-MAR-78 43649
JANUS Interface
The above differences are relatively minor, so in most applications
interconnected 1822 interface and a JANUS interface should
correctly. Attention must be paid to the electrical
susceptibility of the 1822, and to its maximum input voltage
6. MILITARY
The EIA specification RS-422 chosen as a base for the JANUS
distant host electrical characteristics is compatible with
specification MIL-188-114.
The common mode voltage tolerance of the JANUS interface
significant protection against widely varying ground potentials in
equipment separated by distances of thousands of feet
7.
"Specifications for the Interconnection of a Host and an IMP,"
Report 1822, revised January 1976; BBN Inc., 50 Moulton St., Cambridge
Ma. 02138.
"Electrical Characteristics of Balanced Voltage Digital
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.
Agriculture. Contains specification for PE-39 cable
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
