RFC 467 (rfc467) - Page 2 of 7


Proposed change to Host-Host Protocol: Resynchronization of connection status



Alternative Format: Original Text Document



RFC 467                                                    February 1973


II. The RCR and RCS Commands

   To achieve resynchronization of allocation, we propose the addition
   of the following two commands to the host-host protocol.

         8           8
   +-----------+-----------+
   |    RCS    |   link    |   Reset connection by sender
   +-----------+-----------+

         8           8
   +-----------+-----------+
   |    RCR    |   link    |   Reset connection by receiver
   +-----------+-----------+

   The RCS command is sent from the host sending on "link" to the host
   receiving on "link".  This command may be sent whenever the sending
   host desires to re-synch the status information associated with the
   connection.  Some circumstances in which the sending Host may choose
   to do this are:

      1.) After a timeout when there is traffic to move but no
      allocation. (Assumes that an allocation has been lost)

      2.) When an inconsistent event occurs associated with that
      connection (e.g. an outstanding allocation in excess of 2^32 bits
      or 2^16 messages.

   The mechanics of re-synchronizing the allocations is simply:

      1.) Empty all messages and allocates from the "pipeline".

      2.) Zero the variables at both ends indicating bit and message
      allocation.

      3.) Restart allocate/message exchanges in the normal way.

   This resynchronization scheme is race-free because the RCS and RCR
   commands are used as a positive acknowledgement pair.

III. Resynchronization by Sender

   To initiate resynchronization, the sending NCP should:

      1.) Put the connection in a "waiting-for-RCR-reply" state.  No
      more regular messages may be transmitted over this connection
      until the RCR reply is received.




Burchfiel