doc: Add RFC documents

1 files changed, 172 insertions, 0 deletions

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-