Robust Header Compression (ROHC) is a standardized method to compress the IP, UDP,

UDP-Lite UDP-Lite (Lightweight User Datagram Protocol) is a connectionless protocol that allows a potentially damaged data payload to be delivered to an application rather than being discarded by the receiving station. This is useful as it allows decisi ...

, RTP, and TCP headers of

Internet The Internet (or internet) is the global system of interconnected computer networks that uses the Internet protocol suite (TCP/IP) to communicate between networks and devices. It is a '' network of networks'' that consists of private, pub ...

packets.

The need for header compression

In streaming applications, the overhead of IP, UDP, and RTP is 40

bytes The byte is a unit of digital information that most commonly consists of eight bits. Historically, the byte was the number of bits used to encode a single character of text in a computer and for this reason it is the smallest addressable unit ...

for

IPv4 Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP). It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 was the first version de ...

, or 60 bytes for

IPv6 Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communication protocol, communications protocol that provides an identification and location system for computers on networks and routes traffic ...

. For

VoIP Voice over Internet Protocol (VoIP), also called IP telephony, is a method and group of technologies for the delivery of voice communications and multimedia sessions over Internet Protocol (IP) networks, such as the Internet. The terms Internet t ...

, this corresponds to around 60% of the total amount of data sent. Such large overheads may be tolerable in local wired links where capacity is often not an issue, but are excessive for

wide area network A wide area network (WAN) is a telecommunications network that extends over a large geographic area. Wide area networks are often established with leased telecommunication circuits. Businesses, as well as schools and government entities, us ...

s and wireless systems where bandwidth is scarce. ROHC compresses these 40 bytes or 60 bytes of overhead typically into only one or three bytes, by placing a compressor before the link that has limited capacity, and a decompressor after that link. The compressor converts the large overhead to only a few bytes, while the decompressor does the opposite. The ROHC compression scheme differs from other compression schemes, such as IETF and , by the fact that it performs well over links where the packet loss rate is high, such as wireless links.

Main ROHC compression principles

The ROHC protocol takes advantage of information redundancy in the headers of the following: * one single network packet (e.g. the payload lengths in IP and UDP headers) * several network packets that belong to one single stream (e.g. the IP addresses) Redundant information is transmitted in the first packets only. The next packets contain variable information, e.g. identifiers or sequence numbers. These fields are transmitted in a compressed form to save more bits. For better performance, the packets are classified into streams before being compressed. This classification takes advantage of inter-packet redundancy. The classification algorithm is not defined by the ROHC protocol itself but left to the equipment vendor's implementation. Once a stream of packets is classified, it is compressed according to the compression profile that fits best. A compression profile defines the way to compress the different fields in the network headers. Several compression profiles are available, including the following: * Uncompressed * IP-only * UDP/IP * UDP-Lite/IP * ESP/IP * RTP/UDP/IP * RTP/UDP-Lite/IP * TCP/IP

Modes of operation

According to RFC 3095, the ROHC scheme has three modes of operation, as follows: * the Unidirectional mode (U-mode) * the Bidirectional Optimistic mode (O-mode) * the Bidirectional Reliable mode (R-mode) Both the compressor and the decompressor start in U-mode. They may then transition to O-mode if a usable return link is available, and the decompressor sends a positive acknowledgement, with O-mode specified, to the compressor. The transition to R-mode is achieved in the same way.

Unidirectional Mode (U-Mode)

In the Unidirectional mode of operation, packets are only sent in one direction: from compressor to decompressor. This mode therefore makes ROHC usable over links where a return path from decompressor to compressor is unavailable or undesirable. In order to handle potential decompression errors, the compressor sends periodic refreshes of the stream context to the decompressor.

Bidirectional Optimistic Mode (O-Mode)

The Bidirectional Optimistic mode is similar to the Unidirectional mode, except that a feedback channel is used to send error recovery requests and (optionally) acknowledgments of significant context updates from the decompressor to compressor. The O-mode aims to maximize compression efficiency and aims for sparse usage of the feedback channel.

Bidirectional Reliable Mode (R-Mode)

The Bidirectional Reliable mode differs in many ways from the previous two modes. The most important differences are a more intensive usage of the feedback channel, and a stricter logic at both the compressor and the decompressor that prevents loss of context synchronization between compressor and decompressor, except for very high residual bit error rates.

Compressor/decompressor states

The notion of compressor/decompressor states is orthogonal to the operational modes. Whatever the mode is, both the compressor and the decompressor work in one of their three states. They are basically finite state machines. Every incoming packet may cause the compressor/decompressor to change its internal state. Every state refers to a defined behaviour and compression level. The ROHC algorithm is similar to video compression, in that a base frame and then several difference frames are sent to represent an IP packet flow. This has the advantage of allowing ROHC to survive many packet losses in its highest compression state, as long as the base frames are not lost.

Compressor states

The compressor's state machine defines the following three states: * Initialization and Refresh (IR) state * First Order (FO) state * Second Order (SO) state

Operations in the different compressor states

In Initialization and Refresh (IR) state, the compressor has just been created or reset, and full packet headers are sent. In First-Order (FO) state, the compressor has detected and stored the static fields (such as IP addresses and port numbers) on both sides of the connection. The compressor is also sending dynamic packet field differences in FO state. Thus, FO state is essentially static and pseudo-dynamic compression. In Second-Order (SO) state, the compressor is suppressing all dynamic fields such as RTP sequence numbers, and sending only a logical sequence number and partial checksum to cause the other side to predictively generate and verify the headers of the next expected packet. In general, FO state compresses all static fields and most dynamic fields. SO state is compressing all dynamic fields predictively using a sequence number and checksum.

Transitions between compressor states

Transitions between the above states occur when the compressor: * compresses a packet that contains too many variations * receives a positive/negative feedback from the decompressor * periodically refreshes the context

Second-Order ROHC headers – 1-byte headers

A typical ROHC implementation will aim to get the terminal into Second-Order state, where a 1-byte ROHC header can be substituted for the 40-byte IPv4/UDP/RTP or the 60-byte IPv6/UDP/RTP (i.e. VoIP) header. In this state, the 8-bit ROHC header contains three fields: * a 1-bit packet-type flag (set to '1' only for longer ROHC headers) * a 4-bit sequence number (with a range of −1 ... +14 packets from the base frame) * a 3-bit CRC

Decompressor states

The decompressor's state machine defines the following three states: * No Context State * Static Context State * Full Context State Transitions between the above states occur when the decompressor: * successfully decompresses a packet * fails to decompress several packets

Robustness

The size of the sequence number (SN) field governs the number of packets that ROHC can lose before the compressor must be reset to continue. The W-LSB algorithm is used to compress the SN in a robust way. The size of the sequence number in 1 and 2 byte ROHC packets is either 4 bits ( −1/+14 frame offset ), or 6 bits ( −1/+62 frame offset ), respectively, so ROHC can tolerate at most 62 lost frames with a 1-2 byte header.

Additional compression profiles

The defines a generic compression mechanism. It may be extended by defining new compression profiles dedicated to specific protocol headers. New RFCs were published to compress new protocols: * The defines a compression profile for IP headers or IP tunnels. * The defines a compression profile for UDP-Lite/IP and RTP/UDP-Lite/IP headers. * The defines a compression profile for TCP/IP headers.

Newer ROHC RFCs

There have been two new RFCs published and to address the confusion some have encountered when attempting to interpret and implement ROHC. The first document defines a ROHC framework, while the second defines newer versions of the established ROHC profiles.

References

External links

Official charter of the ROHC IETF working group
* - "ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed" * - "ROHC Terminology and Channel Mapping Examples" * - "Corrections and Clarifications to " * - "The RObust Header Compression (ROHC) Framework" (obsoleted by RFC 5795) * - "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)" (obsoleted by RFC 6846) * - "Formal Notation for ROHC" * - "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite". Second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019. It supersedes their definition, but does not obsolete them. * - "The RObust Header Compression (ROHC) Framework" (obsoletes RFC 4995) * {{IETF RFC, 6846, link=no - "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)" (obsoletes RFC 4996)
A free implementation of ROHC on sourceforge.net

A free and efficient library implementing the ROHC standard
Data compression Internet Standards