Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Comments on Network Protocol from NWG/RFC #36 (RFC0038)

IP.com Disclosure Number: IPCOM000003562D
Original Publication Date: 1970-Mar-20
Included in the Prior Art Database: 2000-Sep-13
Document File: 1 page(s) / 2K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S.M. Wolfe: AUTHOR

Abstract

The proposed protocol does not allow for the possible multiplexing of connections over links.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 100% of the total text.

Network Working Group Stephen M. Wolfe

Request for Comments: 38 UCLA CCN

20 March 1970

Comments on Network Protocol

from NWG/RFC #36

The proposed protocol does not allow for the possible multiplexing of

connections over links.

Generally, this presents no problem, but it might cause loading

restrictions in the future. Two cases where routing multiple

connections over the same link are apparent:

a) Where a user has several high speed connections, such as

between processes that transmit files over the network.

Assigning these connections to the same link limits the

percentage of network resources that may be used by that

user. This becomes particularly important when several

store-and-forward IMP's are used by the network to effect

the communication.

b) When two hosts each have their own independent network and

desire to allow access to the other hosts's network over

the ARPA net, a shortage of links may develop. Again, the

assignment of several connections to the same link could

help solve the problem.

The following changes in the protocol would make possible the future

use of multiplexed links. It is not necessary to add the

multiplexing, itself, to the protocol at this time.

a) The END and RDY must specify relevant sockets in addition to

the link number. Only the local socket name need be

supplied.

b) Problems arise with the RSM and SPD commands. Should they

refer to an entire link, or just to a given connection?

Since there is a proposal to modify the RFNM to accommodate

these commands, it might be better to add another set of

commands to block and unblock a connection, but I am not

convinced that that is the best solution.

c) The destintation socket must be added to the header of each

message on the data link. Presumably this would consist of

32 bits immediately after the header and before the marking.

[ This RFC was put into machine readable form for entry ]

[ into the online RFC archives by Karl Reinsch 1/97 ]