THINK Home Digital Archive Search Feedback

 

THINK  ARPANET

 

A Technical History of the ARPANET -
A Technical Tour

IMP-to-IMP


Protocol Data Unit

The PDU for the IMP-IMP layer is the packet.  It is a variable length PDU, with maximum length 1008 bits.  The data in the packet is generated from fragmented messages sent from the Host-IMP layer. The packet header format is shown in the clickable figure 1, below.


Figure 1: Format of a data Packet Header.
Click on each field, for details.

Descriptions for each field in the packet header:

Seq: The 1-bit sequence number used by the stop-and-wait sliding window protocol between IMPs.

Hi/Lo: Indicates which end of the line the packet originates from.  If the phone company has to take an IMP's line out of service for maintenance, then the IMPs line is normally looped back to itself during the maintenance.  When the line is looped back, an IMP will receive all of the packets it sends.  This bit tells the IMP when it is receiving it's own packets, so that the IMP can behave appropriately under these rare circumstances

Logical Channel Number: Indicates the stop-and-wait sliding window channel the packet belongs too.

Version: Indicates the version number of the IMP where the packet was generated.  This bit is necessary for the IMP's ability to update their software during normal operation.

Priority: Used by the Hosts to indicate to the IMP-subnet which messages it thinks are important.

Trace: Causes the subnet to trace the packet for network management, measurement, and debugging purposes.

Leader Flags: Passed by verbatim from the Host-IMP layer's message.

Acknowledgment bits: The sequence number of the last packet received on each of the eight sliding window channels.  These bits are piggybacked.

Software Checksum: Computed at the source IMP, and verified at each IMP along the path to the destination IMP.  Used to indicate IMP memory errors as well as transmission errors.

Source IMP: indicates the IMP where the packet originates.

Message Number: Assigned by the source IMP.  Messages between two Hosts are numbered consecutively.  This number is used in the RFNMs.

Message Block Number: Used by the destination host as an index into it's tables of variables pertaining to traffic on this Host-Host pair.

S/M: Indicates single or multiple packet message..

Last Pkt: If this packet is part of a multiple packet message, this indicates that this packet is the last packet in this message.

Message Block Use Number: Counter for each message block.  Used to determine if a dormant transport pair is becoming active again.

Packet Number: Numbers the packets in a message.

Packet Code: Indicates the type of packet:
   

1Request for buffer allocation at destination IMP.  Before a message is sent, the Source IMP requests the buffer space from the destination IMP.  The destination IMP will reserve the required buffer space for the mutlipacket or single packet message.

   

2.  Source IMP returning buffer allocated space it does not need

   

3'Incomplete message?' query from the source IMP to destination IMP when no RFNM, Dead Destination, or other response has arrived within the appropriate timeout period.

   

4Request for Next Message (RFNM).  From destination host to source IMP, acknowledging a message.

   

5RFNM + ALLOCATE.  Acknowledges message, and Indicates to source host that it can immediately send another packet of the same kind (buffer space is already allocated).

   

6Dead Destination.  Informs the source IMP, that the destination Host is not picking up the reassembled message.

   

7Incomplete Reply.  Response to packet code 3 query.

Destination IMP: Tells where to send the packet.

Virtual Circuit Number: From Host-IMP layer message.  The destination host needs this to demultiplex the many virtual circuits entering it.

Subtype: Used to distinguish normal packets from datagrams.  Datagrams do not use the source IMP to destination IMP protocol, are not delivered in order, and are not flow controlled.


<< IMP-to-IMP

BACK TO TOP

 

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