RFC 263

"VERY DISTANT" HOST INTERFACE 🦋

Okay bestie, this is RFC 263 💖 written by A. McKenzie at BBN on 17 December 1971 (NIC #7811). It's filed under categories B.1, C.2, and I.1, it updates nothing, and it obsoletes nothing. Fresh start, no drama 💅

The normal way to hook a Host computer up to the ARPA Network is, and will keep being, putting an IMP at the Host site with a short-distance hard-wire connection 🔌. But over the last several months we've noticed people really wanting a long-distance link between a Host and some IMP ✨. In this context, long-distance means any cable run longer than 2000 feet, which can typically be tens of miles, whether it's hard-wire or a telephone circuit 📞. We think any good solution to the general problem of connecting Hosts to IMPs MUST satisfy at least these 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 got a quick mention in our earlier RFC #241 (NIC #7671), "Connecting Computers to MLC Ports" 🧚

After a careful look at the options for "very distant" Host connections, we landed on a preliminary design 🎀 that we think should prove satisfactory against the criteria above. The detailed specs won't be ready for a while, but the basic elements are:

Transmissions will be full-duplex and will use the same Binary Synchronous format that's currently used in inter-IMP communication 🔁. On the IMP end, a hardware interface identical in type (though 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 matching formatting, de-formatting, and checking facilities on its end 🫶.

Alongside the CRC creation and checking, the IMP gets a small amount of "retransmission" software 🌸. It acts as a front (Host side) end for the usual Host/IMP interface software. The retransmission scheme isn't completely defined yet, but it'll be based on positive acknowledgment/timeout techniques ⏱️.

The Host will be required to provide a front (IMP side) end to its NCP that can generate CRCs, test for CRC errors, provide simple retransmission logic, and so on 👑. This front end can be implemented in Host software, with special-purpose hardware, in a minicomputer, or any other way the Host organization finds reasonable 🍓.

Once the detailed design is done, this new interface will be completely documented, from both a hardware and a software point of view ✨. That documentation will probably take the form of an update to BBN report No. 1822 📄.

We'd be happy to talk through this interface with any interested organization! Just remember that the detailed design isn't finished yet 🙈

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 ]