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