Movatterモバイル変換

Network Working Group                                Paul J. Santos, Jr.  (BBN)Request for Comments 704                                              Sept 1975NIC #33490             IMP/Host and Host/IMP Protocol ChangeThis note is a revision ofRFC 687 and sketches the designof an expansion to the IMP/host and host/IMP protocol which willinclude among other things the possibility of addressing hosts onmore than 63 IMPs. Our intention in this expansion is to correctcertain existing limits without fundamental changes in thephilosophy of the IMP/host protocol; i.e., while many issueswhich would represent fundamental changes to the IMP/hostprotocol are presently under discussion in the world-widepacket-switching community, we are not able to undertake massivefundamental changes on a time scale compatible with the shortterm needs for network improvement (e.g., already there are 62IMPs).The following paragraphs cover each of the majorcharacteristics of the expanded protocol. A knowledge of Section3 of BBN Report 1822 is assumed. As is discussed below, theexpanded protocol is backwards compatible.1. Expanded Leader Size. The leader will be expanded from twoto six 16-bit words. This will provide space for necessary fieldexpansions and additions. The expansion of the IMP/host(host/IMP) leader to 96 bits from 32 causes word-boundaryproblems for some hosts. To be able to deliver messages betweentwo hosts of which one is using the old protocol and the otherthe new, without shifting the data in the IMP words, it isnecessary that the data (i.e. the first bit of the host/hostleader) start at an even multiple of 8-bit bytes from thebeginning of the entire message. On the other hand, each hostprefers (in fact requires, if no shifting is to be performed bythe host) that the combined host/IMP (IMP/host) and host/hostleaders occupy some integral number of machine words (defined asthe smallest sequence of bits that can be independently accessedby the host/IMP interface). With a total host/IMP (IMP/host) andhost/host leader of 136 bits, only machines with 8-, 16-, 32-,and 64-bit words will find the leader size suitable. To simplifythings for machines with other word lengths, a provision of theprotocol permits each host to tell its IMP a number of 16-bitpadding words to be inserted between the host/IMP (IMP/host) andhost/host leaders. This padding will be stripped off duringhost-to-IMP processing by the IMP, and added in duringIMP-to-host processing. Thus, for instance, 24-bit machines canspecify one 16-bit word of padding, and 10- and 36-bit machinescan specify five 16-bit words.2. Expanded Address field. The address field will be expandedto 32 bits, 16 bits of IMP address, 0 bits of host address, and 8bits for (future) network address. This expansion is adequatefor any forseeable ARPA Network growth.                                 -1-

3. New Message Length Field. A new field will be added whichwill allow the source host to optionally specify the messagelength (in bits) to the IMP subnetwork. The IMP subnetwork maybe able to use this information (when available) to betterutilize network buffer storage. The destination host may also beable to use this information to better utilize its bufferstorage. This field will be 16 bits wide. There will beprovision for expanding the maximum number of packets per messageto 16 from the present 8.4. Expanded Handling Type Field. The handling type field whichnow is used to distinguish between priority and non-prioritymessage streams, etc., will be expanded to eight bits. Thisexpanded field will provide for the possibility of a number ofparallel message streams having different handlingcharacteristics 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 theold-style priority and non-priority handling types will beavailable in the initial implementation of the expanded protocol.5. Source Host Control of Packets per Message. The possibilitywill exist for the source host to specify a message stream whichwill use a given number of packets per multi-packet message (e.g,two packets per message or five packets per message). Since theIMP network will not have to use eight packet-buffers forreassembly purposes, as at present, this may result in betterservices for such hosts. This will help users who need both lowdelay and high throughput. Since this facility is orthogonal toand of lower priority than the address expansion, it will beimplemented after the other proposed basic changes.6. Unordered (type-3) Message Change. Unordered messages willbe indicated by a subtype of the type O message, rather than by aseparate message type as at present. This is compatible with theneed to check the host access control capabilities of allmessages. This will provide a slight backward incompatibilityfor the three or so hosts which presently use type-3 messages intheir research.7. Change in Format of Fake Host Addresses. The For/From IMPbit will be eliminated. The fake host addresses will be the fourhighest host numbers (e.g., IMP Teletype will be host 252).8. Addition of a Parameter to the IMP to Host NOP. The IMP tohost 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 besupported in parallel in the IMPs for the foreseeable future toallow gradual phaseover of host software. A host will be able tospecify to its IMP whether the old or new formats are to be used;thus, it will be possible for the host to specify switching backand forth between the two modes for debugging purposes. The                                 -2-

specification of the mode to be used will be possible via aproper choice of format in the host to IMP NOP message; the IMPwill use the mode of the host to IMP NOP message the IMP hasreceived. Further, a host may select to use either the old ornew format without needing to know more about the other formatmessages than to discard them should they arrive. The IMP willinitialize by sending several NOP messages of each type to givethe hosts its choice. Although a host not implementing the newformat will not be able to address hosts on IMPs with IMP-numbergreater than 63, the IMPs will wherever possible do theconversion necessary to permit hosts using the old format tocommunicate with hosts using the new format and the reverse.1O. Non-blocking Host Interface. A mechanism will be providedwhich allows the IMP to refuse a message from a host withoutblocking the host interface. This mechanism will permit the IMPto gather the necessary resources to send the refused message andthen ask the host to resend the message. Finally, the host willbe permitted to ask to be able to send a message and be notifiedwhen it is possible without requiring the message to actually besent and refused. Again, as in point 5 above, this facility willbe added after the other more basic changes have beenimplemented.11. Maximum Message Length. The maximum number of bits of datain a single-packet message may be reduced by a few bits.We are now producing a draft version of the necessarychanges to Report 1822 and will circulate it so that hostprogrammers can begin to make their preparations.                                 -3-