The RFC Archive
 The RFC Archive   RFC 197   « 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 197

Initial Connection Protocol - Reviewed

Last modified on Wednesday, March 5th, 1997

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







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


















                                                             PAGE 1 top


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 PAGE 2 top

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) are pairs of opposite gender. After the server accepts the connection(s), it (they) goes immediately to a "connected state", and the appropriate ALL command(s) must be sent. ADVANTAGES ---------- The main advantage to this approach is that it mini- mizes the dialog between user and server. The server socket L is used only as an address, not a socket to connect to, therefore eliminating the need to establish a connection to L, choose a byte size, send an ALL command, send and receive data on it and CLOSE it. Race conditions as mentioned in RFC #143 do not arise. Socket L is the server and should be in a "Listening for ICP" state when an ISC or IDC is received. If socket L is not in that state, the serving NCP should refuse to ICP request. The serving NCP should _not_ queue ICP requests. In the current ICP, when the user choses socket U, he has to reserve sockets U+2 and U+3. In the above described approach no restrictions exist for U1 and U2 (except that they are of opposite gender); the same is true for S1 and S2. We think that duplex commands are necessary since both connections are to be connected to the same server process. Their separation by using two ISCs, will add complications of correlating the two ISCs with the same process. Also, if two ISCs are used, the first might be accepted and the second refused. This leads to uncertainty on the user's part. This condition cannot occur with the duplex commands. PAGE 3 top

MINIMUM MODIFICATION TO CURRENT ICP ----------------------------------- The minimum change we can think of to make the current ICP look similar to the above is to add one NCP level com- mand -- accept: ACC, L, U, S The exchange between NCPs in the notation of RFC #165 is now: <where the original uses a script lowercase "L" we use "l"> <where the original uses subscripts we use {} so that A-subscript-B is printed A{B} > Server NCP User NCP ---------- -------- Listen for connection on L RST,U,L,l{A} ACC,L,U,S S is passed by NCP to the user and connection from U to L is closed. STR,S+1,U+2,B{s} STR,U+3,S,B{u} RTS,S,U+3,l{B} RTS,U+2,S+1,l{c} Wait for connection Wait for connection ALL,l{B},m{B},b{B} ALL,l{c},m{c},b{c} An alternative way to the ACC command is a CLS command with an additional parameter (32 bits long). If parameter is zero the request for connection by the user is refused; if the parameter is non-zero, the request is accepted and socket S is the value of the parameter. All suggested changes improve the ICP dialog both from the aesthetic and efficiency points of view. We lean strongly, however, to the first, more major ICP modification. PAGE 4 top

A COMMENT ABOUT CLS COMMAND --------------------------- It seems appropriate to mention here for the purpose of the next version of the Host-Host protocol that the CLS command has more than one function. We think that the CLS command should be reserved to close connections in the "connected state" only (i.e., "open" connections). Two additional commands can be used for "refusing" and "reject- ing" requests for connections: REJ<mysocket><yoursocket> -- when a request for connection is rejected unconditionally. REF<mysocket><yoursocket><reason> -- when a request for connection is refused temporarily because the NCP could not handle it. For example: no process LISTENed to it and it was timed-out, or NCP tables are full in which case the user process may try again. The reason for refusing is indicated in the parameter "reason". [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 12/96 ] PAGE 5 top

Initial Connection Protocol - Reviewed RFC TOTAL SIZE: 7094 bytes PUBLICATION DATE: Wednesday, March 5th, 1997 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 197: The IETF Trust, Wednesday, March 5th, 1997
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement