Dismiss
IP.com applications will be updated on Sunday, March 5, from 11 am to 2 pm ET, to add new functionality and content. You may experience brief service interruptions during this period. We apologize for any inconvenience.
Browse Prior Art Database

Proposed change to Host-Host Protocol: Resynchronization of connection status (RFC0467)

IP.com Disclosure Number: IPCOM000005388D
Original Publication Date: 1973-Feb-20
Included in the Prior Art Database: 2001-Sep-21
Document File: 8 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.D. Burchfiel: AUTHOR [+2]

Abstract

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 24% 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 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...