home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 200s / rfc263.txt < prev    next >
Text File  |  1997-03-04  |  4KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                             A. McKenzie
  8. Request for Comments #263                         BBN
  9. NIC #7811                                         17 December 1971
  10. Categories:  B.1, C.2, I.1
  11. Updates:  none
  12. Obsoletes:  none
  13.  
  14.                      "VERY DISTANT" HOST INTERFACE
  15.  
  16.      The normal method of connecting a Host computer to the ARPA
  17. Network is, and will continue to be, placing an IMP at the Host
  18. site and making a short-distance hard-wire connection.  However,
  19. during the past several months we have become increasingly aware
  20. of the occasional desire to interface a Host to some IMP via a
  21. long-distance connection (where long-distance, in this context,
  22. is any cable run longer than 2000 feet but may typically be tens
  23. of miles) via either a hard-wire or telephone circuit.  We believe
  24. that any good solution to the general problem of interfacing Hosts
  25. to IMPs must satisfy at least the following criteria:
  26.  
  27.      1)  The characteristics of the connection should be such
  28.          that the undetected error rate can be expected to be
  29.          extremely low.
  30.  
  31.      2)  The bandwidth of the connection should not be
  32.          intrinsically limited to a low value.
  33.  
  34.      3)  The nature of the connection should be such that the
  35.          Host may establish multiple network "conversations",
  36.          i.e., it should have all the power of a normal Host
  37.          connection.
  38.  
  39. These criteria were briefly discussed in our earlier RFC #241
  40. (NIC #7671), "Connecting Computers to MLC Ports."
  41.  
  42.      After a careful review of the various possibilities for "very
  43. distant" Host connection, we have arrived at a preliminary design
  44. for this type of interface which we believe should prove
  45. satisfactory with regard to the criteria above.  Although
  46. detailed specifications will not be available for some time, the
  47. basic elements of the design are as follows:
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. Transmissions will be full-duplex and will use the same
  61. Binary Synchronous format that is presently used in inter-IMP
  62. communication.  At the IMP end, a hardware interface identical
  63. in type, but not necessarily in speed, to the usual IMP 50 kilobit
  64. modem interface will be used.  This interface frames blocks of
  65. outgoing data with special characters and appends a 24 bit cyclic
  66. redundancy check (CRC).  It de-frames and checks incoming blocks
  67. which must be of similar format.  The Host must provide mating
  68. formatting, de-formatting and checking facilities at its end.
  69.  
  70.      In conjunction with the CRC creation and checking, the IMP
  71. will be provided with a small amount of "retransmission" software
  72. as a front (i.e., Host side) end for the usual Host/IMP interface
  73. software. The retransmission scheme, although not presently
  74. completely defined, will be based on positive acknowledgment/
  75. timeout techniques.
  76.  
  77.      The Host will be required to provide a front (i.e. IMP side)
  78. end to its NCP which can generate CRCs and test for CRC errors,
  79. provide simple retransmission logic, etc.  This front end may be
  80. implemented in Host software, by means of special purpose hardware,
  81. in a minicomputer, or in any other way which the Host organization
  82. finds reasonable.
  83.  
  84.      This new type of interface will be completely documented,
  85. from both a hardware and software point of view, as soon as the
  86. detailed design is completed.  This documentation will probably
  87. take the form of an update to BBN report No. 1822.
  88.  
  89.      We will be happy to discuss this type of interface with any
  90. interested organization, although it should be remembered that
  91. detailed design is not yet completed.
  92.  
  93. AMcK:jm
  94.  
  95.        [ This RFC was put into machine readable form for entry ]
  96.        [ into the online RFC archives by BBN Corp. under the   ]
  97.        [ direction of Alex McKenzie.                   12/96   ]
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.