The RFC Archive
 The RFC Archive   RFC 660   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 660

Some changes to the IMP and the IMP/Host interface

Last modified on Thursday, October 15th, 1992

Permanent link to RFC 660
Search GitHub Wiki for RFC 660
Show other RFCs mentioning RFC 660

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- Some changes to the IMP and the IMP/Host interface RFC TOTAL SIZE: 4991 bytes PUBLICATION DATE: Thursday, October 15th, 1992 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 660: The IETF Trust, Thursday, October 15th, 1992
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement