diff options
Diffstat (limited to 'doc/rfc/rfc263.txt')
-rw-r--r-- | doc/rfc/rfc263.txt | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/doc/rfc/rfc263.txt b/doc/rfc/rfc263.txt new file mode 100644 index 0000000..74e532c --- /dev/null +++ b/doc/rfc/rfc263.txt @@ -0,0 +1,112 @@ + + + + + + +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: + + + + + + + + + + + [Page 1] + +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 ] + + + + + + + + + + + + + + [Page 2] + |