THINK Home Digital Archive Search Feedback

 

THINK  ARPANET

 

A Technical History of the ARPANET -
A Technical Tour

Source IMP-to-Destination IMP


Overview of Source IMP-to-Destination IMP protocols

Details of Source IMP-to-Destination IMP protocols

The message processing plan forumlated by the ARPANET designers included factors of the store-and-forward subnetwork which led to the development of message processing techniques used in all the IMPs. The designers also noted factors specific to the source IMP and destination IMP that required additional message transmission procedures be used at the source and destination IMPs.

Factors related specifically to message processing in the source and destination IMPs:

  1. Finite storage in the IMPs
  2. Differing bandwidths at the source and destination, which was largely a property of the Hosts.

Factor 1:
The finite storage in the source IMP and destination IMP made it necessary for each to exercise control over its use. In the initial ARPANET design (1970-1972), the source IMP sent packets to the destination without holding a copy of the packet. The packets were accepted at the destination IMP if there was storage available, otherwise they were rejected without sending an acknowledgement to the previous IMP. The previous IMP would eventually time out and retransmit the packet. This method led to storage-based deadlock called reassembly lock-ups. In mid-1972 the reassembly lock-ups were fixed by forcing the source IMP to explicitely reserve reassembly storage at the destination IMP.

Factor 2:
The differing bandwidths at the source and destination caused the need for flow control rules to prevent the network from becoming congested when the destination is slower than the source. The original ARPANET implementation (1970 - 1972) left flow control in the domain of the Hosts. Hosts were allowed to communicate over a set of logical links, with only one message allowed per link and no limit on the number of links that could be used. The one-message-per-link rule tied the rate at which the source could send to the rate at which the destination could receive. However, if the Hosts used too many links, there were no adequate flow control measures. In 1972 the ARPANET designers changed the flow control mechanism, giving the source and destination IMPs complete control over message processing.


Detailed tour of the protocols specific to the source IMP and destination IMP

  • Flow Control - The IMPs used a 1-bit sliding window protocol in cooperation with a 3-bit logical channel number.
  • Connection Management - The source and destination IMPs maintained connection information for the communicating Host pair for the duration of the connection.
  • Fragmentation and Reassembly - To keep the subnet free from Host intervention and to maintain strict control of the subnet, the source and destination IMPs were responsible for fragmenting messages into packets at the source and reassembling the packets at the destination.
  • Evolution of source-to-destination protocols. Discusses the motivations and progression of the source-to-destination transmission procedures.


<< IMP-TO-IMP

RETURN TO TOP

 

Written by the THINK Protocols team, CS Dept, UT Austin
Please direct comments to Chris Edmondson-Yurkanan.