rfc:rfc467
Network Working Group J. Burchfiel Request for Comments: 467 R. Tomlinson NIC: 14741 Bolt Beranek and Newman
20 February 1973
Proposed Change To Host-Host Protocol
Resynchronization Of Connection Status
I. Introduction
The current Host-Host protocol (NIC #8246) contains no provisions for resynchronizing the status information kept at the two ends of each connection. In particular, if either host suffers a service interruption, or if a control message is lost or corrupted in an interface or in the subnet, the status information at the two ends of the connection will be inconsistent.
Since the current protocol provides no way to correct this condition, the NCP's at the two ends stay "confused" forever. A frequent and frustrating symptom of this effect is the "lost allocate" phenomenon, where the receiving NCP believes that it has bit and message allocations outstanding, while the sending NCP believes that it does not have any allocation. As a result, information flow over that connection can never be restarted.
Use of the Host-Host RST (reset) command is inappropriate here, as it destroys all connections between the two hosts. What is needed is a way to reset only the affected connection without disturbing any others.
A second troublesome symptom of inconsistency in status information
is the "half-closed" connection: after a service interruption or
network partitioning, one NCP may believe that a connection is still
open, while the other believes that the connection is closed. (Does
not exist.) When such an inconsistency is discovered, the "open" end
of the connection should be closed.
Burchfiel [Page 1] 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 [Page 2] RFC 467 February 1973
2.) Wait until the message pipeline is empty, i.e. until a RFNM
has been received for each regular message sent over this
connection. This synchronizes the control and data activity, and
also assures that the data stream will not be corrupted during the
control re-synchronization exchange.
3.) Send the RCS command.
4.) Continue to process allocates normally, updating the variables
which indicate outstanding bit and message allocation.
When the receiving NCP receives the RCS, it should:
1.) Zero the variables indicating outstanding bit and message
allocation.
2.) Reset the connection to the state which indicates readiness to
accept a message.
3.) Confirm the re-synchronization by sending the RCR reply.
4.) Reconsider bit and message allocation, and send an ALL command
for any allocation it cares to do.
When the sending host receives the RCR reply, it should:
1.) Zero the variables indicating outstanding bit and message
allocate.
2.) Put the connection into the "ready-to-send-message" state in
preparation for any forthcoming ALL commands.
At this point, the "pipeline" contains no messages and no allocates, and the outstanding allocation variables at both ends are in agreement. (With value zero)
IV. Resynchronization By Receiver
The re-synchronization sequence may be triggered by the receiving NCP. Such resynchronization could be initiated manually by TIP and TELNET users who are expecting output but receiving none. Again assuming that allocation has been lost, the appropriate action is to reset the connection by sending an RCR command. This action is also appropriate if an inconsistent event occurs with respect to the connection. (e.g. arrival of a message which exceeds allocation).
Burchfiel [Page 3] RFC 467 February 1973
To initiate re-synchronization, the receiving NCP should:
1.) Put the connection into a "waiting-for-RCS-reply" state. No
more allocates may be transmitted for this connection until the
RCS reply is received.
2.) Send the RCR command.
3.) Continue to process regular messages normally, updating the
variables which indicate outstanding bit and message allocation.
When the sending NCP receives the RCR command, it should:
1.) Wait until the message pipeline is empty, i.e. until the RFNM
has been received for each regular message sent over the
connection. This synchronizes the control and data activity, and
also assures that the data stream will not be corrupted during the
control re-synchronization exchange.
2.) Zero the variables indicating outstanding bit and message
allocation.
3.) Put the connection into the "ready-to-send-message" state in
preparation for any forthcoming ALL commands.
4.) Confirm the re-synchronization by sending the RCS reply.
When the receiving host receives the RCS reply, it should:
1.) Zero the variables indicating outstanding bit and message
allocation.
2.) Reset the connection to the state which indicates readiness to
accept a message.
3.) Reconsider bit and message allocation, and send an ALL command
for any allocation it cares to do.
V. Simultaneous Resynchronization
This specification for a re-synchronization exchange is guaranteed to restore the allocation information at the two ends to a consistent state. This happens correctly whether the re-synchronization is triggered by the sender, the receiver, or both at the same time. When both ends initiate a command at the same time, (the RCS and RCR commands cross in the pipeline) each interprets the other's command as a confirmation reply; thus, the resynchronization happens correctly independent of the relative timing.
Burchfiel [Page 4] RFC 467 February 1973
The essential factor here is that when either end receives the reset request, it is sure that the other end will take no further actions which could affect the allocation variables. The activity which occurs during simultaneous resynchronization by both ends is as follows:
The sending NCP:
1. Puts the connection into a "waiting-for-RCR-reply" state. No
more regular messages may be transmitted over this connection
until the RCR reply is received.
2. Waits until the message pipeline is empty, i.e. until a RFNM
has been received for each regular message sent over this
connection. This synchronizes the control and data activity, and
also assures that the data stream will not be corrupted during the
control re-synchronization exchange.
3. Sends the RCS command.
4. Continues to process allocates normally, updating the variables
which indicate outstanding bit and message allocation.
Concurrently with 1, 2, 3 and 4 above, the receiving NCP:
5. Puts the connection into a "waiting-for-RCS-reply" state. No
more allocates may be transmitted for this connection until the
RCS reply is received.
6. Sends the RCR command.
7. Continues to process regular messages normally.
The RCS and RCR commands cross somewhere in the pipeline. When the sender receives the RCR command, it interprets it as a reply to its own RCS command. It then:
8. Zeroes the variables indicating outstanding bit and message
allocation.
9. Puts the connection into the "ready-to-send-message" state in
preparation for any forthcoming ALL commands.
Concurrently with 8 and 9 above, the receiving NCP will receive the RCS command. It will interpret it as a reply to its own RCR command. It then:
Burchfiel [Page 5] RFC 467 February 1973
10. Zeroes the variables indicating outstanding bit and message
allocation.
11. Resets the connection to the state which indicates readiness
to accept a message.
12. Reconsiders bit and message allocation, and sends an ALL
command for any allocation it cares to do.
VI. The Problem Of Half-closed Connections
The above procedures provide a way to resynchronize a connection after a brief lapse by a communications component, which results in lost messages or allocates for an open connection.
A longer and more severe interruption of communication may result from a partitioning of the subnet or from a service interruption on one of the communicating hosts. It is undesirable to tie up resources indefinitely under such circumstances, so the user is provided with the option of freeing up these resources (including himself) by unilaterally dissolving the connection. Here "unilaterally" means sending the CLS command and closing the connection without receiving the CLS acknowledgement. Note that this is legal only if the subnet indicates that the destination is dead.
When service is restored after such an interruption, the status
information at the two ends of the connection is out of
synchronization. One end believes that the connection is open, and
may proceed to use the connection. The disconnecting end believes
that the connection is closed (does not exist), and may proceed to
re-initialize communication by opening a new connection (RTS or STR
command) using the same local socket.
The re-synchronization needed here is to properly close the open end of the connection when the inconsistency is detected. We propose to accomplish this by changing the semantics of three existing host-host protocol commands.
VII. Redefinition of RTS, STR, ERR (link) to Handle Half-closed
Connections
The "missing CLS" situation described above can manifest itself in two ways. The first way involves action taken by the NCP at the "open" end of the connection. It may continue to send regular messages on the link of the half-closed connection, or control messages referencing its link. The NCP at the "closed" end should respond with the ERR message, specifying that the link is unknown. (Error code = 5 does not correspond to an open connection). On
Burchfiel [Page 6] RFC 467 February 1973
receipt of such an ERR message, the NCP at the "open" end should close the connection by modifying its tables, (without sending any CLS command) thereby bringing both ends into agreement.
The second way this inconsistency can show up involves actions initiated by the NCP at the "closed" end. It may (thinking the connection is closed) send an STR or RTS to reopen the connection. The NCP at the "open" end will detect an inconsistency when it receives such an RTS or STR command, because it specifies the same foreign socket as an existing open connection. In this case, the NCP at the "open" end should close the connection (without sending any CLS command) to bring the two ends into agreement before responding to the RTS/STR.
VIII. Conclusions
The scheme presented in Section II to resynchronize allocation has one very important property: the data stream is preserved through the exchange. Since no data is lost, it is safe to initiate re- synchronization from either end at any time. When in doubt, re- synchronize.
The changes in the semantics of RTS, STR, and ERR(code 5) commands provide the synchronization needed to complete the closing of "half- closed" connections.
The protocol changes above will make the host-host protocol far more robust, in that useful work can continue in spite of lapses by the communications components.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie 08/00]
Burchfiel [Page 7]
/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc467.txt · Last modified: 2001/09/19 23:16 by 127.0.0.1