1 files changed, 170 insertions, 0 deletions
diff --git a/doc/rfc/rfc687.txt b/doc/rfc/rfc687.txt
new file mode 100644
index 0000000..e5d86b9
--- /dev/null
+++ b/doc/rfc/rfc687.txt
@@ -0,0 +1,170 @@
+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-
+
+
+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 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-
+
+
+     We are presently working out the details of an
+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-