Movatterモバイル変換

Network Working Group                              David C. Walden (WALDEN@BBN)Request for Comments: 687                                              Jun 1975NIC #32654IMP/Host and Host/IMP Protocol ChangeThis note sketches the design of an expansion to theIMP/host and host/IMP protocol which will include among otherthings the possibility of addressing hosts on more than 63 IMPs.Our intention in this expansion is to correct certain existinglimits without fundamental changes in the philosophy of theIMP/host protocol; i.e., while many issues which would representfundamental changes to the IMP/host protocol are presently underdiscussion in the world-wide packet-switching com unity, we arenot able to undertake massive fundamental changes on a time scalecompatible with the short term needs for network improvement(e.g., already there are almost 60 IMPs).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 five 16-bit words. This will provide space for necessaryfield expansions and additions.2. Expanded Address Field. The address field will be expandedto 24 bits, 16 bits of IMP address and 8 bits of host address.This expansion is more than adequate for any foreseeable ARPANetwork growth.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 13 bits wide.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),unordered messages (i.e., the present type-3 messages), a messagestream requiring guaranteed capacity, etc. Note that only someof these facilities will be available in the near term.5. Source Host Control of Packets per Message. The possibilitywill exist for the source host to specify a message stream which                                -1-

will 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 messages. This will help users who need bothlow delay and high throughput.6.    Unordered (type-3) Message Change. Unordered messages willbe indicated by a handling type rather than by a message type asat present. This is compatible with the need to check the hostaccess control capabilities of all messages. This will provide aslight backward incompatibility for the three or so hosts whichpresently use type-3 messages in their 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. Thespecification 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 tocom unicate with hosts using the new format and the reverse.Finally, it will be possible to convert the leader format fromold to new or the reverse without knowledge of the message type.11.    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.12.   Maximum Message Length. The maximum number of bits of datain a message may be reduced by a few bits.                                -2-

     We are presently working out the details of animplementation plan for making the above changes to the IMPsoftware. We will distribute an implementation schedule andother necessary information (e.g., format details) in plenty oftime for hosts desiring to use the new protocol as soon as it isavailable to implement in time.                                  -3-