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

Initial Connection Protocol - Reviewed (RFC0197)

IP.com Disclosure Number: IPCOM000004191D
Original Publication Date: 1971-Jul-14
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Shoshani: AUTHOR [+2]

Abstract

------------

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

Network Working Group A.Shoshani, SDC

Request for Comment # 197 E. Harslem, Rand

NIC # 7142 14 July 1971

Categories: C.3, D.1

Updates: None

Obsoletes: None

INITIAL CONNECTION PROTOCOL--REVIEWED

INTRODUCTION

------------

At the Network meeting preceding the SJCC '71, an

"ICP Committee" was established. It's purpose was to get

"something" working fast with minimum modifications to the

current ICP so as to minimize complaints. (This seems like

a good definition for almost everything!) Consequently,

those who had objections to the current ICP were interviewed

and a compromise was reached in the form of RFC #165. The

ICP committee didn't have a chance to think about an alter-

native because of the above mentioned constraints. In this

note we attempted a simple version of an ICP assuming that

we can add commands to Host-Host protocol. We hope that this

will be useful in the design of the next version of the

Host-Host protocol.

ICP COMMANDS

------------

To establish a regular connection one party can issue

an INIT (NCP sends RTS or STR commands), then the other

party can accept the request for connection by responding

with an INIT or refusing it with a CLOSE. We think that

a similar, simple mechanism is desirable for the ICP.

Furthermore, the ICP should allow for simplex as well as

duplex connections from user to server.

The following commands are necessary for simplex

connections:

ISC - Initiate Simplex Connection

ASC - Accept Simplex Connection

RSC - Refuse Simplex Connection

The notation for parameters is similar to that

of RFC #165:

L - Server socket name, in one special case the

server is "logger".

U - User socket.

S - Socket assigned by server for the connection

with user.

X - Is the byte size if U is odd and is the link

number if U is even.

- -

X - Is the complement of X (X is the link number

if U is odd and byte size if U is even.

To initiate a simplex connection the user's NCP

issues:

ISC, L, U, X

To refuse this connection the server's NCP issues:

RSC, L, U

To accept this connection the server's NCP issues:

-

ASC, L, U, S, X

Similarly, for duplex connections, we have:

IDC, L, U1, X1, U2, X2

RDC, L, U1, U2

- -

ADC, L, U1, S1, X1, U2, S2, X2

where (U1,U2), (S1,S2), (U1,S1) and (U2,S2)...