Browse Prior Art Database

Out-of-Band Control Signals in a Host-to-Host Protocol (RFC0721)

IP.com Disclosure Number: IPCOM000003767D
Original Publication Date: 1976-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 6 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

L.L. Garlick: AUTHOR

Abstract

This note addresses the problem of implementing a reliable out-of-band signal for use in a host-to-host protocol. It is motivated by the fact that such a satisfactory mechanism does not exist in the Transmission Control Protocol (TCP) of Cerf et. al. [reference 4, 6] In addition to discussing some requirements for such an out-of-band signal (interrupts) and the implications for the implementation of the requirements, a discussion of the problem for the TCP case will be presented.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 20% of the total text.

NWG/RFC 721 1 SEP 76 LLG 36636

Out-of-Band Control Signals

Network Working Group Larry Garlick

Request for Comments 721 SRI-ARC

NIC 36636 1 September 76

Out-of-Band Control Signals

in a

Host-to-Host Protocol

This note addresses the problem of implementing a reliable out-of-band

signal for use in a host-to-host protocol. It is motivated by the fact

that such a satisfactory mechanism does not exist in the Transmission

Control Protocol (TCP) of Cerf et. al. [reference 4, 6] In addition to

discussing some requirements for such an out-of-band signal (interrupts)

and the implications for the implementation of the requirements, a

discussion of the problem for the TCP case will be presented.

While the ARPANET host-to-host protocol does not support reliable

transmission of either data or controls, it does meet the other

requirements we have for an out-of-band control signal and will be drawn

upon to provide a solution for the TCP case.

The TCP currently handles all data and controls on the same logical

channel. To achieve reliable transmission, it provides positive

acknowledgement and retransmission of all data and most controls. Since

interrupts are on the same channel as data, the TCP must flush data

whenever an interrupt is sent so as not to be subject to flow control.

Functional Requirements

It is desirable to insure reliable delivery of an interrupt. The

sender must be assured that one and only one interrupt is delivered

at the destination for each interrupt it sends. The protocol need

not be concerned about the order of delivery of interrupts to the

user.

The interrupt signal must be independent of data flow control

mechanisms. An interrupt must be delivered whether or not there are

buffers provided for data, whether or not other controls are being

handled. The interrupt should not interfere with the reliable

delivery of other data and controls.

The host-to-host protocol need not provide synchronization between

the interrupt channel and the data-control channel. In fact, if

coupling of the channels relies on the advancement of sequence

numbers on the data-control channel, then the interrupt channel is no

longer independent of flow control as required above. The

synchronization with the data stream can be performed by the user by

1

NWG/RFC 721 1 SEP 76 LLG 36636

Out-of-Band Control...