"Very Distant" Host interface
Connecting a host computer to the network from a long distance away
McKenzie, A.M., ""Very Distant" Host interface", RFC 263, DOI 10.17487/RFC0263, December 1971, <https://www.rfc-editor.org/info/rfc263>.
@misc{rfc263,
series = {Request for Comments},
number = 263,
howpublished = {RFC 263},
publisher = {RFC Editor},
doi = {10.17487/RFC0263},
url = {https://www.rfc-editor.org/info/rfc263},
author = {A.M. McKenzie},
title = {{"Very Distant" Host interface}},
pagetotal = 2,
year = 1971,
month = dec,
} RFC text
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 ]
AI ELI5
On this page
§1Introduction
RFC 263 addresses the problem of connecting a host computer to an IMP over long-distance connections, beyond about 2,000 feet and potentially tens of miles. The normal connection is a short hard-wire link, but long-distance connections—whether via dedicated cables or telephone circuits—require a different design to maintain reliability and performance.
Network computers usually sit next to their network box. This RFC asks how to connect them from far away.
§2Design Criteria
Any solution must satisfy three key criteria. First, the connection must have an extremely low undetected error rate to maintain data integrity over distance. Second, bandwidth should not be intrinsically limited to a low value, preserving the host's ability to send useful amounts of data. Third, the connection must allow the host to establish multiple network conversations with all the capabilities of a normal short-distance connection.
The long-distance connection must not lose data, must be fast enough, and must let the computer do everything a normal connection can do.
§3The Technical Approach
The design uses full-duplex transmission with Binary Synchronous format, the same format used for inter-IMP communication. The IMP end uses a hardware interface similar to its standard 50-kilobit modem interface, which frames outgoing data blocks with special characters and appends a 24-bit cyclic redundancy check (CRC). The host must provide matching formatting, de-formatting and checking facilities. Both the IMP and host receive retransmission software implementing positive acknowledgment and timeout techniques for reliability.
The connection sends data in both directions at once, uses error-checking codes on each chunk, and resends anything that gets lost.
§4Implementation and Specification
The host must provide a software or hardware front-end to its NCP that generates CRCs, tests for CRC errors, and provides retransmission logic. This front-end may be implemented in host software, special-purpose hardware, a minicomputer, or any other method the host organization finds suitable. Detailed specifications will be documented once the design is complete, likely as an update to BBN report number 1822. BBN is open to discussing this interface with interested organizations, though detailed design specifications were not yet finalized at the time of this RFC.
Each host will need its own code or hardware to handle error checking and resending. BBN will publish full instructions later.