From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc704.txt | 172 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 doc/rfc/rfc704.txt (limited to 'doc/rfc/rfc704.txt') diff --git a/doc/rfc/rfc704.txt b/doc/rfc/rfc704.txt new file mode 100644 index 0000000..e7758f9 --- /dev/null +++ b/doc/rfc/rfc704.txt @@ -0,0 +1,172 @@ +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- -- cgit v1.2.3