Protocol Notes
RFC 36

Document Type RFC - Unknown (March 1970; No errata)
Updated by RFC 39, RFC 44
Updates RFC 33
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 36 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          S. Crocker
Request for Comments: 36                                    16 March 1970

                             Protocol Notes

I Overview

   The network protocol provides three facilities:

         1.  Connection establishment

         2.  Flow control

         3.  Reconnection

   Reconnection is considered separately from connection establishment
   partly because of the complexity of reconnection and partly because I
   don't have enough experience with the protocol to present these
   concepts in an integrated fashion.

   Connection Establishment

   Connection establishment works essentially the same as in NWG/RFC
   #33.  The major change is that a more general form of switching is
   provided independently of establishment, so establishment is
   simplified by not including switching procedures.

   A rough scenario for connection establishment follows:

   1.  Process PA in host A grabs socket SA and requests connection with
       socket SB.  Process PA accomplishes this through a system call.

   2.  Concurrently with the above, process PB in host B grabs socket SB
       and requests connection with socket SA.

   3.  In response to process PA's request, the network control program
       in host A (referred to as NCPA) sends a Request-for-Connection
       (RFC) command to host B.  NCPB in host B sends a similar command
       to host A.  No ordering is implied: NCPB may send the command to
       NCPA before or after receiving the command from NCPA.

   4.  NCPA and NCPB are both aware the connection is established when
       each has received a RFC command and each has received the RFNM
       for the one it has sent.  They then notify processes PA and PB,
       respectively, that the connection is established.

Crocker                                                         [Page 1]
RFC 36                       Protocol Notes                   March 1970

   One of the rules adhered to is that either SA is a send socket and SB
   is a receive socket or vice versa.  This condition is sometimes
   stated as "SA and SB must be  a send/receive pair."

   5.  The sending process may now send.

   Flow Control

   In order to prevent a sending process from flooding a receiving
   processes it is necessary for the receiving process to be able to
   stop the flow(*).  Flow control is integrated into the network RFNM
   handling.  When a receiving host wishes to inhibit flow on a
   particular link, the host sends a special message to its IMP which
   causes the next RFNM on that link to be modified.  The sending host
   interprets this message as a RFNM and as a request to stop sending.
   A confirming control command is returned.

   When the receiving host is ready to receive again, it sends a command
   (RSM) telling the sending host to resume sending.


   For a great many reasons it is desirable to be able to switch one (or
   both) ends of a connection from one socket to another.  Depending
   upon the restrictions placed upon the switching process, it may be
   easy or hard to implement.  To achieve maximum generality, I present
   here a scheme for dynamic reconnection, which means that reconnection
   can take place even after flow has started.  It may turn out that for
   the majority of cases, this scheme is much more expensive than it
   needs to be; however, the following virtues are claimed:

      1. All various forms of switching connections are provided.

      2. Reconnection introduces no overhead in the processing of
         messages sent over a connection i.e., the whole cost is borne
         in processing the protocol.

   *BB&N argues that unlimited buffering should be provided.  It is
   possible that this would be a proper strategy: but it is foreign to
   my way of thinking, and I have based the protocol design on the
   assumption that only a small buffer is provided on the receive end of
   each connection.

Crocker                                                         [Page 2]
RFC 36                       Protocol Notes                   March 1970

II  Data Structures

    1.  Connection Table
    2.  Process Table
    3.  Input Link Table
    4.  Output Link Table
    5.  Link Assignment Table

   Connection Table

   This holds all information pertaining to local sockets, particularly
   whether a socket is engaged in a connection, and if so, what state
   the connection is in.  Entries are keyed by local socket, but other
   tables have pointers into this table also.  (See the Process Table,
   Input Link Table, and Output Link Table.)

   Each entry contains the following information:

         a)  local socket (key)
         b)  foreign socket
         c)  link
         d)  connection state
         e)  flow state and buffer control
Show full document text