Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN
Network Working Group                                       D. Walden (BBN-NET)Request for Comments: 660                                              Oct 1974NIC #31202SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACEIn the next few weeks several changes will be made to the IMPsoftware including changes to the IMP/Host software interfaceas specified in BBN Report No. 1822, Specifications for theInterconnection of a Host and an IMP. These changes come infour areas: a) decoupling of the message number sequences ofHosts; b) Host/Host access control; c) expansion of themessage number window from four to eight; and d) provision formessages outside the normal message number mechanism. All changesare 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 theperformance of the network for all users, the set of Hosts permittedto use this mechanism will be regulated by the Network ControlCenter.Please file this note with your copy of BBN Report 1822 untilthat document is updated.                              -2-

[8]ページ先頭

©2009-2025 Movatter.jp