RFC 263 UNKNOWN INFRASTRUCTURE · HOST INTERFACE

"Very Distant" Host interface

A preliminary design for connecting hosts to an IMP over long distances.

On rfc-editor.org ↗
PUBLISHED
December 1971
AUTHORS
A.M. McKenzie
STREAM
Legacy
LONG-DISTANCE THRESHOLD
More than 2,000 feet
CRC SIZE
24 bits
DOI
10.17487/RFC0263

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                             A. McKenzie
Request for Comments #263                         BBN
NIC #7811                                         17 December 1971
Categories:  B.1, C.2, I.1
Updates:  none
Obsoletes:  none

                     "VERY DISTANT" HOST INTERFACE

     The normal method of connecting a Host computer to the ARPA
Network is, and will continue to be, placing an IMP at the Host
site and making a short-distance hard-wire connection.  However,
during the past several months we have become increasingly aware
of the occasional desire to interface a Host to some IMP via a
long-distance connection (where long-distance, in this context,
is any cable run longer than 2000 feet but may typically be tens
of miles) via either a hard-wire or telephone circuit.  We believe
that any good solution to the general problem of interfacing Hosts
to IMPs must satisfy at least the following criteria:

     1)  The characteristics of the connection should be such
         that the undetected error rate can be expected to be
         extremely low.

     2)  The bandwidth of the connection should not be
         intrinsically limited to a low value.

     3)  The nature of the connection should be such that the
         Host may establish multiple network "conversations",
         i.e., it should have all the power of a normal Host
         connection.

These criteria were briefly discussed in our earlier RFC #241
(NIC #7671), "Connecting Computers to MLC Ports."

     After a careful review of the various possibilities for "very
distant" Host connection, we have arrived at a preliminary design
for this type of interface which we believe should prove
satisfactory with regard to the criteria above.  Although
detailed specifications will not be available for some time, the
basic elements of the design are as follows:

Transmissions will be full-duplex and will use the same
Binary Synchronous format that is presently used in inter-IMP
communication.  At the IMP end, a hardware interface identical
in type, but not necessarily in speed, to the usual IMP 50 kilobit
modem interface will be used.  This interface frames blocks of
outgoing data with special characters and appends a 24 bit cyclic
redundancy check (CRC).  It de-frames and checks incoming blocks
which must be of similar format.  The Host must provide mating
formatting, de-formatting and checking facilities at its end.

     In conjunction with the CRC creation and checking, the IMP
will be provided with a small amount of "retransmission" software
as a front (i.e., Host side) end for the usual Host/IMP interface
software. The retransmission scheme, although not presently
completely defined, will be based on positive acknowledgment/
timeout techniques.

     The Host will be required to provide a front (i.e. IMP side)
end to its NCP which can generate CRCs and test for CRC errors,
provide simple retransmission logic, etc.  This front end may be
implemented in Host software, by means of special purpose hardware,
in a minicomputer, or in any other way which the Host organization
finds reasonable.

     This new type of interface will be completely documented,
from both a hardware and software point of view, as soon as the
detailed design is completed.  This documentation will probably
take the form of an update to BBN report No. 1822.

     We will be happy to discuss this type of interface with any
interested organization, although it should be remembered that
detailed design is not yet completed.

AMcK:jm

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]

ISO Plain Language

On this page
PROBLEMSome sites wanted to connect a host to an IMP over a cable or telephone circuit longer than the usual short-distance hard-wire connection.
MECHANISMThe preliminary design uses full-duplex Binary Synchronous transmission, block framing, a 24-bit CRC and positive-acknowledgment and timeout retransmission methods.
PRELIMINARY DESIGNThe RFC outlines an approach but says detailed design and documentation were not yet complete.

§1Long-Distance Host Connections

The normal host connection placed an IMP at the host site and used a short hard-wire connection. BBN says some organizations wanted links longer than 2,000 feet, potentially tens of miles, using either cable or telephone circuits.

A suitable design should have an extremely low undetected error rate, avoid an inherently low bandwidth limit and preserve the host's ability to establish multiple network conversations.

Some hosts needed to connect to an IMP from far away. The link needed to be reliable, support useful bandwidth and preserve normal network conversations.

§2Transmission and Error Checking

The preliminary proposal uses full-duplex transmission in the Binary Synchronous format already used for inter-IMP communication. The IMP end would frame blocks with special characters and add a 24-bit cyclic redundancy check (CRC); the host would provide matching formatting and checking.

The IMP and host would also use retransmission software based on positive acknowledgements and timeouts. The exact retransmission scheme was not yet fully defined.

Both ends can send at once. They frame data in blocks, check each block for errors and use acknowledgements and timeouts to retransmit when needed.

§3Host Requirements and Documentation

The host needs a front end to its NCP that can generate and check CRCs and provide simple retransmission logic. This could be implemented in software, special-purpose hardware, a minicomputer or another way chosen by the host organization.

BBN planned to document the design when complete, probably as an update to Report 1822. The RFC invites discussion while noting that detailed design was unfinished.

Each host must provide the data-formatting and error-checking functions at its end. BBN planned to publish full specifications after completing the design.