RFC 241 UNKNOWN ARCHITECTURE · INFRASTRUCTURE

Connecting computers to MLC ports

BBN explains the limits of connecting a computer through a Terminal IMP MLC port.

On rfc-editor.org ↗
PUBLISHED
September 1971
AUTHORS
A.M. McKenzie
STREAM
Legacy
USUAL CABLE DISTANCE
Up to 30 feet, or up to 2000 feet with the Distant Host option
MLC ERROR CONTROL
None in hardware or software
DOI
10.17487/RFC0241

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                           A. McKenzie
RFC # 241                                       BBN
NIC # 7671                                      29 September 1971
Categories: B.1, C.1, I.1
Updates: none
Obsoletes:  Our Previous Verbal Comments



                   CONNECTING COMPUTERS TO MLC PORTS
                   ---------------------------------

        Several times we have been asked if computers can be con- nected
   through serial communication lines to ports on the Terminal IMP's
   Multi-Line Controller (MLC) [related questions about the level of
   software support provided by the Terminal IMP to such a connection,
   have also been raised].  In the past we have said, "Please don't!" We
   now say, "Sure, but will that really help you the way you think it
   will?"


        (1) Connections between computers and IMPs (i.e., the Host
   interfaces) have been assumed to be error-free.  This assumption is
   justifiable on the basis that the IMP and Host computers were
   expected to be either in the same room (up to 30 feet of cable) or,
   via the Distant Host option, within 2000 feet on well- controlled,
   shielded cables.  A connection through common carrier facilities is
   not comparably free of errors.  Usage of common- carrier lines for
   connecting a terminal to an IMP, including the assumption of a human
   at the terminal, is a situation in which the typical errors which do
   occur can be accommodated.  Usage of the same wire, with the same
   typical errors, for a computer-to- computer connection is likely to
   be a situation in which the errors are unacceptable.  The present
   version of the Terminal IMP does not provide error control either
   within its hardware or within its software on any ports of the
   Multi-Line Controller.  Further, we feel that computer-to-computer
   connections over common carrier circuits should employ strong error
   control, such as that

RFC # 241




   used on the IMP/IMP circuits, and that attempts to use minimal error
   control (e.g., character parity) is an undesirable technical choice.
   Strong error control, with its retransmission scheme, not only would
   imply significant changes in the Terminal IMP, but a non-trivial
   hardware/software implementation at the remote computer end of the
   circuit.


        (2) Because the Terminal IMP has many obligations, the share of
   its bandwidth which can be given to a Host coming in over the MLC
   will be small.


        (3) The command language provided at a port of the Multi- Line
   Controller was designed with terminals and people in mind.  It
   provides very few of the capabilities which a computer requires in
   order to effectively utilize the communication network.  For example,
   only a single pair of connections can be made from a given Terminal
   TMP port; Host computers generally desire a larger number of
   simultaneous connections to other Hosts on the network.  Assuming the
   present Host/Host protocols, such a Host could not conveniently act
   as a server.


        If, despite these potential difficulties, connection of a
   computer to the network through an MLC port appears to be useful, BBN
   has no objection.  In fact, we would be extremely interested in
   hearing about actual experience with this type of network connection.



   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   ]

ISO Plain Language

On this page
PROBLEMPeople asked whether a computer could connect through a Terminal IMP's Multi-Line Controller instead of using the usual Host-IMP interface.
MECHANISMBBN says this can be attempted but explains that MLC ports lack error control, offer limited bandwidth and use a command interface designed for terminals.
POSSIBLE, WITH LIMITSBBN invites real-world experience while warning that this path may not meet a host's needs.

§1The Connection Question

BBN had been asked whether computers could connect to serial ports on a Terminal IMP's Multi-Line Controller (MLC). The note changes the earlier response of “Please don't” to “Sure,” while asking whether the arrangement would help as expected.

Host-IMP interfaces were assumed to be error-free, based on short or controlled shielded cables. A common-carrier line does not have the same assumption, and the Terminal IMP does not provide error control on MLC ports.

The MLC can be used to attach a computer, but its serial lines may introduce errors. The usual Host-IMP connection was expected to be much more reliable.

§2Bandwidth and Host Features

The Terminal IMP has many obligations, so only a small share of its bandwidth can be offered to a host using an MLC port. The MLC command language was designed for terminals and people and provides few of the features a computer needs to use the network effectively.

For example, one MLC port can make only one pair of connections. A host generally wants several simultaneous connections and could not conveniently act as a server using the current Host-Host protocols.

The MLC gives a host limited network capacity and only one pair of connections. That may be too restrictive for a computer that needs to communicate with several other hosts.

§3BBN's Position

BBN says it has no objection if someone finds the connection useful despite these limitations. The note says strong error control would require changes to the Terminal IMP and a non-trivial implementation at the remote computer.

BBN asks users to share their experience with this type of connection.

BBN permits people to try the setup and asks them to report what happens. The RFC does not claim that the arrangement will work well for every use.