doc: Add RFC documents

1 files changed, 115 insertions, 0 deletions

diff --git a/doc/rfc/rfc660.txt b/doc/rfc/rfc660.txt
new file mode 100644
index 0000000..c435677
--- /dev/null
+++ b/doc/rfc/rfc660.txt
@@ -0,0 +1,115 @@
+Network Working Group                                       D. Walden (BBN-NET)
+Request for Comments: 660                                              Oct 1974
+NIC #31202
+
+
+       SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE
+
+In the next few weeks several changes will be made to the IMP
+software including changes to the IMP/Host software interface
+as specified in BBN Report No. 1822, Specifications for the
+Interconnection of a Host and an IMP. These changes come in
+four areas: a) decoupling of the message number sequences of
+Hosts; b) Host/Host access control; c) expansion of the
+message number window from four to eight; and d) provision for
+messages outside the normal message number mechanism. All changes
+are backward compatible with possible minor exceptions in timing.
+
+a. Decoupling of the Host/Host message number sequences:
+   Since 1972 the IMP system has provided for exactly four
+   messages to be outstanding at a time between any pair of
+   IMPs, and thus, a total of only four messages between
+   all the possible pairs of Hosts on the two IMPs. Because
+   all the pairs of Hosts on the two IMPs have had to share
+   the four outstanding messages, it has been quite possible
+   for the various Hosts to interfere with each other. To
+   remove this possibility of interference, the IMP's
+   message number logic will soon be changed to allow a
+   separate message number sequence between each pair of Hosts.
+
+   To keep manageable the space required to maintain the
+   Host/Host message sequences above that presently are required
+   for the IMP/IMP message sequences, the Host/Host sequences
+   will be taken dynamically from a limited pool of possible
+   sequences. The pool will be sufficiently large to seldom
+   interfere with a pair of Hosts wishing to communicate. In
+   no case will Hosts be prevented from communicating. In
+   the event that the Hosts on an IMP desire to simultaneously
+   communicate with so many other Hosts that the pool would
+   be exhausted, the space in the pool is quickly multiplexed
+   in time among all the desired Host/Host conversations
+   so that none is stopped although all are possibly slowed.
+
+b. Host/Host access control:
+   Upon instructions from ARPA, we will soon add a Host/Host
+   access control mechanism to the IMPs. Any pair of Hosts
+   wishing to communicate is checked (via bits in the IMP)
+   to verify that they have administrative permission to
+   communicate. This check normally is made whenever a pair
+   of Hosts attempts to communicate after not having
+   communicated for two minutes. If the pair of Hosts is
+   not allowed to communicate, a special type of Destination
+   Dead Message (sub-code 3) is returned to the source
+   Host. The default case initially will be to allow all
+   Hosts to communicate with each other.
+
+
+
+                              -1-
+
+
+c. Message number window.:
+   Once the message number sequences are on a Host/Host
+   rather than IMP/IMP basis, the number of messages that
+   will be permitted to be outstanding at a time between
+   a pair of Hosts will be expanded from four to eight,
+   permitting increased Host/Host throughput in some cases.
+
+d. Message outside the normal mechanism:.
+   For certain limited experiments which are being carried on
+   using the network, it is thought to be desirable
+   for specified Hosts to be able to communicate outside the
+   normal ordered, error controlled message sequences.
+   Thus, the following expansion to the IMP/Host protocol is being
+   provided.
+
+i. a single packet message coming from the source Host
+   to the source IMP with a (new) special message type,
+   3, will be put directly into the IMP store-and-forward
+   logic with a mark saying the packet is this special
+   kind of message. A multi-packet message of type 3
+   will be discarded.
+
+ii. such messages (packets) are routed normally to the
+   destination IMP, possibly arriving out of order.
+
+iii. at the destination IMP, messages of the special
+   type will be put directly on the destination Host
+   output queue skipping the reassembly logic and marked
+   with a special (new) IMP to Host message type, also 3.
+
+iv. there is no source-to-destination retransmission
+   logic, no reassembly, no RFNMs, no incomplete
+   transmissions, etc.
+
+v. if at any time there are insufficient resources in the
+   network to handle one of these special messages
+   (e.g., the destination Host won't take it), the
+   message will be discarded.
+
+vi. by using the special message type between the Host
+   and the IMP, the normal message number mechanism is
+   preserved for all the Host/Host transmissions which
+   presently depend on it.
+
+Because the uncontrolled use of this mechanism will degrade the
+performance of the network for all users, the set of Hosts permitted
+to use this mechanism will be regulated by the Network Control
+Center.
+
+Please file this note with your copy of BBN Report 1822 until
+that document is updated.
+
+
+
+                              -2-