Initial Connection Protocol - Reviewed
RFC 197

Document Type RFC - Unknown (July 1971; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 197 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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



     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.


     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]
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

     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
           ISC, L, U, X

     To refuse this connection the server's NCP issues:

           RSC, L, U

                                                                [Page 2]
     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.


     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

     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]

     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
Show full document text