by Darius Kazemi, August 3 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

TIP tips

RFC-215 is titled “NCP, ICP, and TELNET: The Terminal IMP Implementation”.

The technical content

Let's back up and do some review. I'd like to talk about the Interface Message Processor (IMP) and the Terminal Interface Message Processor (TIP).

The IMP is a modem-like-thing that acts as the bridge between the computers at ARPANET host sites and the nationwide telephone infrastructure. I say “modem-like-thing” because that is what a present-day modem does for a computer: allows it to connect to telecommunication infrastructure. The IMP is what made the ARPANET possible, and RFC-1 was entirely about answering the question, “How do we connect our computers to the IMPs?”

The typical setup with an IMP is what you see in the diagram here from RFC-1:

flowchart showing a terminal connected to a computer connected to an IMP, flowing through the telecommunications network, then to an IMP, to a computer, and to another terminal

A human sits at a terminal. A terminal is a device that is not a full computer; instead it's either a teletype (a typewriter that can receive information and type it back to you), or, if you're lucky, a keyboard connected to a monitor but lacking things like an operating system, significant memory, all that good stuff. The point is that a terminal can't do anything on its own, and its purpose is to be a device that connects to a big powerful computer in a closet somewhere.

The big computer in a closet it what talks to the IMP, which lets you access the ARPANET.

But at some point BBN decides that they could do one better and ship a new kind of IMP: the Terminal IMP, or TIP. In this 1972 paper, BBN engineers note that the ARPANET IMP infrastructure as a whole

constitutes a nationwide resource which could be made available to users who have no special facilities of their own to contribute to the resource pool. Such a user might be at a site either with no Host computer or where the existing computer might not be a terminal-oriented time-sharing system. [emphasis theirs]

The idea is that a user with a terminal (far, far cheaper than a computer) could connect directly to an IMP and access network resources without needing a computer.

According to Fenwick McKelvey and Kevin Driscoll, this new Terminal IMP

allowed up to sixty-three simultaneous connections from teleprinter or video terminals wired directly to one of sixty-four RS-232C serial ports or linked by telephone to one of sixteen optional modems[.]

So. This RFC is about the new Terminal IMP that BBN has recently been installing across the network. (According to shipping and installation manifests I found at the Charles Babbage Institute, the first TIPs shipped earlier in 1971.)

Specifically this RFC is about how TIPs handle the Host-Host Protocol, the Initial Connection Protocol, and the TELNET protocol. The author says that the biggest bottleneck for implementation was the highly limited memory on the TIP, combined with the fact that they want the TIP to support up to 64 terminals.

Since the TIP is just for connecting to the ARPANET, it has no sockets to which an external user can connect. This is because it's strictly a client rather than a server.

The TIP deviates from protocol standards in a few ways, but all of them boil down to: there is not that much memory on the TIP, and the TIP is never going to act as a server, so the TIP ignores a huge chunk of the existing protocols in order to save memory.

Further reading

For a great paper on the Interface Message Processor and its role as a broker between computers and the telecom infrastructure, see McKelvey and Driscoll's “ARPANET and its boundary devices” paper.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.