Out-of-band data

Example case

Consider a networking application that tunnels data from a remote data source to a remote destination. The data being tunneled may consist of any bit patterns. The sending end of the tunnel may at times have conditions that it needs to notify the receiving end about. However, it cannot simply insert a message to the receiving end because that end will not be able to distinguish the message from data sent by the data source. By using an out-of-band mechanism, the sending end can send the message to the receiving end out of band. The receiving end will be notified in some fashion of the arrival of out-of-band data, and it can read the out of band data and know that this is a message intended for it from the sending end, independent of the data from the data source.

Implementations

It is possible to implement out-of-band data transmission using a physically separate channel, but most commonly out-of-band data is a feature provided by a transmission protocol using the same channel as normal data. A typical protocol might divide the data to be transmitted into blocks, with each block having a header word that identifies the type of data being sent, and a count of the data bytes or words to be sent in the block. The header will identify the data as being in-band or out-of-band, along with other identification and routing information. At the receiving end, the protocol looks at the header and routes the data to the normal reception endpoint if it is in-band, and to a separate mechanism if it is out-of-band. Depending on the implementation, there may be some mechanism for notifying or interrupting the receiving application when out-of-band data has arrived.

The most commonly used protocol containing an out-of-band data mechanism is the Internet's Transmission Control Protocol. It implements out-of-band data using an "urgent pointer," which marks certain data in the transmitted data stream as out-of-band. Unfortunately, a long-existing discrepancy between RFC 793 and RFC 1122 limits the usability of this feature of TCP; nonetheless, it is used by certain standard application protocols, notably the Telnet protocol.

On Unix-like computers, out-of-band data can be read with the recv() system call. A process or process group can be configured to receive SIGURG signals when out-of-band data is available for reading on a socket, by using the F_SETOWN command of the fcntl() system call. This is a form of asynchronous I/O.

The Serial Advanced Technology Attachment (SATA) protocol commonly used to connect disk drives to computers implements an out-of-band data protocol.

The Consultative Committee for Space Data Systems' Space Data Link Protocol implements an out-of-band mechanism via the "command" flag. When set, the received data is to be interpreted and acted on by the data link receiver, rather than being telemetry/telecommand information to be passed to the destination.

Issues

Some sources define "out-of-band data" as including the characteristic that out-of-band data should be prioritized ahead of queued in-band data. This is reinforced by TCP's (RFC 793) referring to the out-of-band data mechanism as "urgent data." However, prioritization is neither an essential nor a necessarily desirable characteristic of out-of-band data; moreover, TCP implementations vary greatly on how they treat the urgency of out-of-band data.

References

References

1. Len. (October 20, 2011). "Out of band data, TCP Urgent mode and overlapped I/O". Serverframework.com.
2. "Chapter 11: Signaling Systems". George Mason University.
3. "On the implementation of the TCP urgent mechanism".
4. "TELNET PROTOCOL SPECIFICATION".
5. Altera Corporation. "AN-635-1.0 Application Note Implementing SATA and SAS Protocols in Altera Devices".
6. "TC Space Data Link Protocol". Consultative Committee for Space Data Systems.
7. Stevens, W. Richard. (2005). "Advanced Programming in the Unix Environment: Second Edition". Addison-Wesley Professional.