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-