RFC660 - Some changes to the IMP and the IMP/Host interface

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航