 | ||
The Interface Message Processor (IMP) was the packet switching node used to interconnect participant networks to the ARPANET from the late 1960s to 1989. It was the first generation of gateways, which are known today as routers. An IMP was a ruggedized Honeywell DDP-516 minicomputer with special-purpose interfaces and software. In later years the IMPs were made from the non-ruggedized Honeywell 316 which could handle two-thirds of the communication traffic at approximately one-half the cost. An IMP requires the connection to a host computer via a special bit-serial interface, defined in BBN Report 1822. The IMP software and the ARPA network communications protocol running on the IMPs was discussed in RFC 1, the first of a series of standardization documents published by the Internet Engineering Task Force (IETF).
Contents
History
The idea of the IMP was first publicly discussed in early 1967 at a meeting of principal investigators for the Department of Defense's Advanced Research Projects Agency (ARPA) to discuss interconnecting machines across the country. Larry Roberts, who led the ARPANET implementation, initially proposed a network of host computers. Wes Clark suggested inserting "a small computer between each host computer and the network of transmission lines", i.e. making the IMP a separate computer.
The IMPs were built by the Massachusetts-based company Bolt Beranek and Newman (BBN) in 1969. BBN was contracted to build four IMPs, the first being due at UCLA by Labor Day; the remaining three were to be delivered in one-month intervals thereafter, completing the entire network in a total of twelve months. When Massachusetts Senator Edward Kennedy learned of BBN's accomplishment in signing this million-dollar agreement, he sent a telegram congratulating the company for being contracted to build the "Interfaith Message Processor".
The team working on the IMP called themselves the "IMP Guys":
BBN began programming work in February 1969 on modified Honeywell DDP-516s. The completed code was six thousand words long, and was written in the Honeywell 516 assembly language. The IMP software was produced primarily on a PDP-1, where the IMP code was written and edited, then run on the Honeywell.
BBN designed the IMP simply as "a messenger" that would only "store-and-forward". BBN designed only the host-to-IMP specification, leaving host sites to build individual host-to-host interfaces. The IMP had an error-control mechanism that discarded packets with errors without acknowledging receipt; the source IMP, upon not receiving an acknowledging receipt, would subsequently re-send a duplicate packet. Based on the requirements of ARPA's request for proposal, the IMP used a 24-bit checksum for error correction. BBN chose to make the IMP hardware calculate the checksum, because it was a faster option than using a software calculation. The IMP was initially conceived as being connected to one host computer per site, but at the insistence of researchers and students from the host sites, each IMP was ultimately designed to connect to multiple host computers.
The first IMP was delivered to Leonard Kleinrock's group at UCLA on August 30, 1969. It used an SDS Sigma-7 host computer. Douglas Engelbart's group at the Stanford Research Institute (SRI) received the second IMP on October 1, 1969. It was attached to an SDS-940 host. The third IMP was installed in University of California, Santa Barbara on November 1, 1969. The fourth and final IMP was installed in the University of Utah in December 1969. The first communication test between two systems (UCLA and SRI) took place on October 29, 1969, when a login to the SRI machine was attempted, but only the first two letters could be transmitted. The SRI machine crashed upon reception of the 'g' character. A few minutes later, the bug was fixed and the login attempt was successfully completed.
BBN developed a program to test the performance of the communication circuits. According to a report filed by Heart, a preliminary test in late 1969 based on a 27-hour period of activity on the UCSB-SRI line found "approximately one packet per 20,000 in error;" subsequent tests "uncovered a 100% variation in this number - apparently due to many unusually long periods of time (on the order of hours) with no detected errors."
A variant of the IMP existed, called the TIP, which connected terminals instead of computers to the network; it was based on the 316. Initially, some Honeywell-based IMPs were replaced with multiprocessing BBN Pluribus IMPs, but ultimately BBN developed a microprogrammed clone of the Honeywell processor.
IMPs were at the heart of the ARPANET until DARPA decommissioned ARPANET in 1989. Most IMPs were either taken apart, junked or transferred to MILNET. Some became artifacts in museums; Kleinrock placed IMP Number One on public view at UCLA. The last IMP on the ARPANET was the one at the University of Maryland.
BBN Report 1822
BBN Report 1822 specifies the method for connecting a host computer to an IMP. This connection and protocol is generally referred to as 1822, the report number.
The initial version of the 1822 protocol was developed in 1969: since it predates the OSI model by a decade, 1822 does not map cleanly into the OSI layers. However, it is accurate to say that the 1822 protocol incorporates the physical layer, the data link layer, and the network layer. The interface visible to the host system passes network layer addresses directly to a physical layer device.
To transmit data, the host constructs a message containing the numeric address of another host on the network (similar to an IP address on the Internet) and a data field, and transmits the message across the 1822 interface to the IMP. The IMP routes the message to the destination host using protocols that were eventually adopted by Internet routers. Messages could store a total length of 8159 Bits, of which the first 96 were reserved for the header (“leader”).
While packets transmitted across the Internet are assumed to be unreliable, 1822 messages were guaranteed to be transmitted reliably to the addressed destination. If the message could not be delivered, the IMP sent to the originating host a message indicating that the delivery failed. In practice, however, there were (rare) conditions under which the host could miss a report of a message being lost, or under which the IMP could report a message as lost when it had in fact been received.