Browse Prior Art Database

Proposed change to Host-Host Protocol: Resynchronization of connection status (RFC0467) Disclosure Number: IPCOM000005388D
Original Publication Date: 1973-Feb-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 7 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.D. Burchfiel: AUTHOR [+1]

Related Documents

10.17487/RFC0467: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 25% of the total text.

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 N...