doc: Add RFC documents

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]
+