summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc263.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc263.txt')
-rw-r--r--doc/rfc/rfc263.txt112
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]
+