Network Working Group David C. Walden (WALDEN@BBN)
Request for Comments: 687 Jun 1975
NIC #32654
IMP/Host and Host/IMP Protocol Change
- This note 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 com unity, 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 almost 60 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 five 16-bit words. This will provide space for necessary
-
- field expansions and additions.
-
- 2. Expanded Address Field. The address field will be expanded
-
- to 24 bits, 16 bits of IMP address and 8 bits of host address.
-
- This expansion is more than adequate for any foreseeable 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 13 bits wide.
-
- 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),
-
- unordered messages (i.e., the present type-3 messages), a message
-
- stream requiring guaranteed capacity, etc. Note that only some
-
- of these facilities will be available in the near term.
-
- 5. Source Host Control of Packets per Message. The possibility
-
- will exist for the source host to specify a message stream which
-
-1-
-
- 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 messages. This will help users who need both
-
- low delay and high throughput.
-
- 6. Unordered (type-3) Message Change. Unordered messages will
-
- be indicated by a handling type rather than by a 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
-
- 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
-
- com unicate with hosts using the new format and the reverse.
-
- Finally, it will be possible to convert the leader format from
-
- old to new or the reverse without knowledge of the message type.
-
- 11. 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.
-
- 12. Maximum Message Length. The maximum number of bits of data
-
- in a message may be reduced by a few bits.
-
-2-
-
- implementation plan for making the above changes to the IMP
-
- software. We will distribute an implementation schedule and
-
- other necessary information (e.g., format details) in plenty of
-
- time for hosts desiring to use the new protocol as soon as it is
-
- available to implement in time.
-
-3-