IMP/Host and Host/IMP Protocol change
RFC 704

Document Type RFC - Unknown (September 1975; No errata)
Obsoletes RFC 687
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 704 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                Paul J. Santos, Jr.  (BBN)
Request for Comments 704                                              Sept 1975
NIC #33490

             IMP/Host and Host/IMP Protocol Change

This note is a revision of RFC 687 and sketches the design
of an expansion to the IMP/host and host/IMP protocol which will
include among other things the possibility of addressing hosts on
more than 63 IMPs. Our intention in this expansion is to correct
certain existing limits without fundamental changes in the
philosophy of the IMP/host protocol; i.e., while many issues
which would represent fundamental changes to the IMP/host
protocol are presently under discussion in the world-wide
packet-switching community, we are not able to undertake massive
fundamental changes on a time scale compatible with the short
term needs for network improvement (e.g., already there are 62

The following paragraphs cover each of the major
characteristics of the expanded protocol. A knowledge of Section
3 of BBN Report 1822 is assumed. As is discussed below, the
expanded protocol is backwards compatible.

1. Expanded Leader Size. The leader will be expanded from two
to six 16-bit words. This will provide space for necessary field
expansions and additions. The expansion of the IMP/host
(host/IMP) leader to 96 bits from 32 causes word-boundary
problems for some hosts. To be able to deliver messages between
two hosts of which one is using the old protocol and the other
the new, without shifting the data in the IMP words, it is
necessary that the data (i.e. the first bit of the host/host
leader) start at an even multiple of 8-bit bytes from the
beginning of the entire message. On the other hand, each host
prefers (in fact requires, if no shifting is to be performed by
the host) that the combined host/IMP (IMP/host) and host/host
leaders occupy some integral number of machine words (defined as
the smallest sequence of bits that can be independently accessed
by the host/IMP interface). With a total host/IMP (IMP/host) and
host/host leader of 136 bits, only machines with 8-, 16-, 32-,
and 64-bit words will find the leader size suitable. To simplify
things for machines with other word lengths, a provision of the
protocol permits each host to tell its IMP a number of 16-bit
padding words to be inserted between the host/IMP (IMP/host) and
host/host leaders. This padding will be stripped off during
host-to-IMP processing by the IMP, and added in during
IMP-to-host processing. Thus, for instance, 24-bit machines can
specify one 16-bit word of padding, and 10- and 36-bit machines
can specify five 16-bit words.

2. Expanded Address field. The address field will be expanded
to 32 bits, 16 bits of IMP address, 0 bits of host address, and 8
bits for (future) network address. This expansion is adequate
for any forseeable ARPA Network growth.


3. New Message Length Field. A new field will be added which
will allow the source host to optionally specify the message
length (in bits) to the IMP subnetwork. The IMP subnetwork may
be able to use this information (when available) to better
utilize network buffer storage. The destination host may also be
able to use this information to better utilize its buffer
storage. This field will be 16 bits wide. There will be
provision for expanding the maximum number of packets per message
to 16 from the present 8.

4. Expanded Handling Type Field. The handling type field which
now is used to distinguish between priority and non-priority
message streams, etc., will be expanded to eight bits. This
expanded field will provide for the possibility of a number of
parallel message streams having different handling
characteristics between pairs of hosts; e.g., priority,
non-priority, varying numbers of packets per message (see below),
a message stream requiring guaranteed capacity, etc. Only the
old-style priority and non-priority handling types will be
available in the initial implementation of the expanded protocol.

5. Source Host Control of Packets per Message. The possibility
will exist for the source host to specify a message stream which
will use a given number of packets per multi-packet message (e.g,
two packets per message or five packets per message). Since the
IMP network will not have to use eight packet-buffers for
reassembly purposes, as at present, this may result in better
services for such hosts. This will help users who need both low
delay and high throughput. Since this facility is orthogonal to
and of lower priority than the address expansion, it will be
implemented after the other proposed basic changes.

6. Unordered (type-3) Message Change. Unordered messages will
be indicated by a subtype of the type O message, rather than by a
separate message type as at present. This is compatible with the
need to check the host access control capabilities of all
messages. This will provide a slight backward incompatibility
for the three or so hosts which presently use type-3 messages in
Show full document text