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/rfc660.txt | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 doc/rfc/rfc660.txt (limited to 'doc/rfc/rfc660.txt') 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- -- cgit v1.2.3