    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
    IMPs).

    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.

                                     -1-

    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
    their research.

    7. Change in Format of Fake Host Addresses. The For/From IMP
    bit will be eliminated. The fake host addresses will be the four
    highest host numbers (e.g., IMP Teletype will be host 252).

    8. Addition of a Parameter to the IMP to Host NOP. The IMP to
    host NOP will have added to it a parameter specifying the address
    (IMP and host number) of the host.

    9. Backward Compatibility. The old and new formats will be
    supported in parallel in the IMPs for the foreseeable future to
    allow gradual phaseover of host software. A host will be able to
    specify to its IMP whether the old or new formats are to be used;
    thus, it will be possible for the host to specify switching back
    and forth between the two modes for debugging purposes. The

                                     -2-

    specification of the mode to be used will be possible via a
    proper choice of format in the host to IMP NOP message; the IMP
    will use the mode of the host to IMP NOP message the IMP has
    received. Further, a host may select to use either the old or
    new format without needing to know more about the other format
    messages than to discard them should they arrive. The IMP will
    initialize by sending several NOP messages of each type to give
    the hosts its choice. Although a host not implementing the new
    format will not be able to address hosts on IMPs with IMP-number
    greater than 63, the IMPs will wherever possible do the
    conversion necessary to permit hosts using the old format to
    communicate with hosts using the new format and the reverse.

    1O. Non-blocking Host Interface. A mechanism will be provided
    which allows the IMP to refuse a message from a host without
    blocking the host interface. This mechanism will permit the IMP
    to gather the necessary resources to send the refused message and
    then ask the host to resend the message. Finally, the host will
    be permitted to ask to be able to send a message and be notified
    when it is possible without requiring the message to actually be
    sent and refused. Again, as in point 5 above, this facility will
    be added after the other more basic changes have been
    implemented.

    11. Maximum Message Length. The maximum number of bits of data
    in a single-packet message may be reduced by a few bits.

    We are now producing a draft version of the necessary
    changes to Report 1822 and will circulate it so that host
    programmers can begin to make their preparations.

                                     -3-