Network Working Group                                         E. HarslemRequest for Comments: 80                                      J. HeafnerNIC: 5608                                                           RAND                                                         1 December 1970                       PROTOCOLS AND DATA FORMATS   Because of recent discussions of protocols and data formats we issue   this note to highlight our current attitudes and investigations in   those regards.  We first discuss some specific sequences, and then   offer some thoughts on two general implementation approaches that   will handle these and other specifics.  We wish to place emphasis on   the _general solutions_ and not on the specifics.INITIAL CONNECTION PROTOCOLS   We wish to make two points concerning specific Initial Connection   Protocols (IPCs).  Firstly, the IPC described in NEW/RFC #66--its   generality and a restatement of that ICP.  Secondly, a proposal for a   variant ICP using basically the same logic as NWG/RFC #66.I. NWG/RFC #66   The only technical error in this IPC is that as diagrammed both the   Server and User send ALL messages before the connections are   established which is inconsistent with Network Document No. 1.  This   can easily be remedied as will be shown in the restatement below.   In terms of generality, any ICP that is adopted as a standard should   apply to more situations than a process calling a logger.  That is,   some Network service processes that hook directly to a user process,   independent of logger action, could perhaps use a standard ICP.   Thus, as is shown below, the process name field of the server socket   should be a parameter with a value of zero being a special case for   loggers.   Restatement of NWG/RFC #66 (using the same wording where appropriate)      1. To initiate contact, the using process attaches a receive         socket (US) and requests connection to process SERV socket #1         in the serving HOST.  (SERV = 0 for ICP to the logger.)  As a         result the using NCP sends:Harslem, et. al.                                                [Page 1]RFC 80                 Protocols and Data Formats        1 December 1970            1              4                 3          1     1         +-----+---------------------+---------------+-----+-----+         | RTS |          US         |      SERV     |  1  |  P  |         +-----+---------------------+---------------+-----+-----+         over link 1, where P is the receive link.      2. The serving process (SERV) may decide to refuse to the call, in         which case it closes the connection.  If it accepts the call,         the serving process completes the connection (via an INIT         system call, hence an STR).            1           3          1            4         +-----+----------------+-----+--------------------+         | STR |      SERV      |  1  |         US         |         +-----+----------------+-----+--------------------+      3. When the connection is completed, the user process allocates a         nominal amount of space to the connection, resulting in the NCP         sending:            1     1            4         +-----+-----+--------------------+         | ALL |  P  |       SPACE        |         +-----+-----+--------------------+         where SPACE is the amount.      4. The serving process then selects the socket pair it wishes to         assign this user.  It sends exactly an even 32 bit number over         the connection.  This even 32 bit number (SS) is the receive         socket in the serving HOST.  This socket and the next higher         numbered socket are reserved for the using process.      5. It then closes the connection.  The serving NCP sends (step 4):                    4         +---------------------+         |         SS          |         +---------------------+         on link P, and (step 5):Harslem, et. al.                                                [Page 2]RFC 80                 Protocols and Data Formats        1 December 1970            1            3         1             4         +-----+----------------+-----+--------------------+         | CLS |       SERV     |  1  |         US         |         +-----+----------------+-----+--------------------+         on the control link (which is echoed by the using NCP).      6. Now that both server and user are aware of the remote socket         pair for the duplex connection, <STR, RTS>s can be exchanged.         _Sever sends User_            1            4                     4         +-----+--------------------+--------------------+         | STR |      SS + 1        |          US        |         +-----+--------------------+--------------------+---+         | RTS |         SS         |        SS + 1      | Q |         +-----+--------------------+--------------------+---+         where Q is the Server's receive link.         _User sends Server_            1             4                    4         +-----+--------------------+--------------------+         | STR |       US + 1       |         SS         |         +-----+--------------------+--------------------+---+         | RTS |          US        |       SS + 1       | R |         +-----+--------------------+--------------------+---+         where R is the User's receive link.         ALLocates may then be sent and transmission begun.II.  A Variation of NWG/RFC #66   This variation reduces Network messages and eliminates duplication of   information transfer.   Steps 3 and 4 above are deleted.  The user process is not notified   directly which of the Server's sockets it will be assigned.  The user   process, however, will listen on sockets US and US + 1 for calls from   SERV after step 5 above.  It can reject any spurious calls.  In   accepting the calls from SERV, the connection is established.   The following sample sequence illustrates this ICP.  (The notation is   as above).Harslem, et. al.                                                [Page 3]RFC 80                 Protocols and Data Formats        1 December 1970   1. User --> Server         1            4                    3         1     1      +-----+--------------------+----------------+-----+-----+      | RTS |         US         |       SERV     |  1  |  P  |      +-----+--------------------+----------------+-----+-----+   2. Server --> User      If accepted:         1           3          1             4      +-----+----------------+-----+---------------------+      | STR |      SERV      |  1  |         US          |      +-----+----------------+-----+---------------------+      | CLS |      SERV      |  1  |         US          |      +-----+----------------+-----+---------------------+      If rejected:         1           3          1             4      +-----+----------------+-----+---------------------+      | CLS |      SERV      |  1  |         US          |      +-----+----------------+-----+---------------------+   3. If accepted, user listens on US and US + 1.   4. Server --> User         1             4                     4      +-----+--------------------+---------------------+      | STR |       SS + 1       |          US         |      +-----+--------------------+---------------------+---+      | RTS |         SS         |        US + 1       | Q |      +-----+--------------------+---------------------+---+   5. User accepts the calls, hence:      User --> Sender         1              4                     4      +-----+---------------------+--------------------+      | STR |        US + 1       |        SS + 1      |      +-----+---------------------+--------------------+---+      | RTS |        US + 1       |          SS        | R |      +-----+---------------------+--------------------+---+      and the connection is established.Harslem, et. al.                                                [Page 4]RFC 80                 Protocols and Data Formats        1 December 1970   This reduces the number of network messages by two and only passes   the information regarding the Server's sockets once via RTS and STR.   PRE-SPECIFIED DATA FORMATS   We would like to adopt those suggestions for data formats in NWG/RFC   #42 and #63.  We subscribe to multiple standards as solutions to   particular problem classes.   AN ADAPTABLE MECHANISM      We would like to adapt to Network use, problem programs that were      not planned with the Network in mind, and which, no doubt, will      not easily succumb to Network standards existing at the time of      their inclusion.  This incompatibility problem is just as      fundamental a part of the research underlying the Network as is      different Host hardware.  To require extensive front-ends on each      such program is not a reasonable goal.  We view the Network as an      amalgamation of a) Hosts that provide services; b) parasite Hosts      that interface terminals to the services, and c) a spectrum of      Hosts that behave as both users and providers of services.  To      require that each parasite Host handle different protocols and      data formats for all services that its users need is not a      reasonable goal.  The result is programs and terminals that wish