What is the ROHC protocol?
The RObust Header Compression (ROHC) protocol aims at reducing bandwidth usage on network links with limited capacity or expensive costs, such as mobile networks or satellite links. It defines a lossless compression scheme for network headers. It does not act on the network payload in any way.
The ROHC protocol is able to compress IPv4, IPv6, UDP, UDP-Lite, ESP, RTP and TCP headers of Internet packets.
Table of content:
- Main principles
- Modes of operation
- Compressor/decompressor states
- Packet types
- Encoding schemes
- A step further…
The ROHC protocol compresses only network headers. It leaves the network payload unchanged.
The ROHC protocol takes advantage of the information redundancy in the different headers of:
- one single network packet (eg. the payload lengths in IP and UDP headers),
- several network packets that belongs to one single stream (eg. the IP addresses).
Redundant information is transmitted in first packets only (and eventually at regular interval of time later on). Next packets contain variable information only, eg. identifiers or sequence numbers. Theses fields are furthermore transmitted in a adequate compressed form to save some more bits. This behaviour is similar to video compression mechanisms that define reference frames, then compute deltas from the last reference frame for every frame.
For better performances, the packets must be classified into streams before being compressed. This is a requirement to take advantage of inter-packet redundancy. The classification algorithm is not defined by the ROHC protocol itself but left to the implementations.
Once a stream of packets was identified, 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: Uncompressed, IP-only, IP/UDP, IP/UDP-Lite, IP/ESP, IP/UDP/RTP, IP/UDP-Lite/RTP and IP/TCP.
The ROHC protocol is standardized by the IETF. A Working Group was formed to specify a "common compression protocol platform". Several RFCs were published to define the ROHC framework and a number of compression profiles. The RFCs are listed on the right side of the page.
The IEEE maintains the registry of Ethernet/802.3 protocol identification. The ROHC protocol is registered with value 0x22F1.
A ROHC compressor parses uncompressed packets, associate them to a stream, builds the corresponding ROHC packets and transmits them to its associated ROHC decompressor at the other end of the network link.
A ROHC decompressor parses ROHC packets transmitted by its associated ROHC compressor, decodes the packet fields according to the ROHC algorithms and then builds the corresponding uncompressed packets.
One compressor is associated with only one decompressor. One decompressor is associated with only one compressor.
Both the compressor and the decompressor store some information bits for every network stream they handle. This information is called a stream context. The compressor and the decompressor do not store the same data in their context. The compressor uses uses its contexts to associate a received packet to a stream and to detect the fields that change over time. The decompressor uses its contexts to retrieve the fields that are not transmitted in all the packets.
Modes of operation
The ROHC protocol proposes 3 modes of operations:
- the Unidirectional mode (U-mode),
- the Bidirectional Optimistic mode (O-mode),
- the Bidirectional Reliable mode (R-mode).
In U-mode, packets are transmitted in one direction only: from the compressor to the decompressor. This is useful for network links with no or undesirable return path. In order to handle potential decompression errors, the compressor sends periodic refreshes of the stream context to the decompressor.
The O-mode works the same way as the U-mode. However feedback packets are transmitted by the decompressor on the return path for reporting errors or acknowledging successful decompression to the compressor.
The R-mode makes use feedback information too. However it is stricter than the O-mode for context updates.
Both the compressor and the decompressor starts in U-mode. They may then operate a transition to O-mode if a usable return link is available and the decompressor sends to the compressor a positive acknowledgement with O-mode specified. The transition to R-mode is achieved the same way.
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 compressor's state machine defines the following three states:
- Initialization and Refresh (IR) State,
- First Order (FO) State,
- Second Order (SO) State.
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.
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.
The Uncompressed profile defines the following ROHC packets:
The IP/UDP/RTP profile defines the following ROHC packets:
- Type 0: UO-0, R-0, R-0-CRC,
- Type 1: UO-1, UO-1-ID, UO-1-TS, R-1, R-1-ID, R-1-TS,
- Type 2: UOR-2.
The IP-only, non-RTP IP/UDP and IP/ESP profiles define the following ROHC packets:
- Type 0: UO-0, R-0, R-0-CRC,
- Type 1: UO-1 (different from RTP profile), R-1 (different from RTP profile).
- Type 2: UOR-2 (different from RTP profile).
Other profiles may define other packets. Please refers to the related RFCs for more details.
The IP-only, IP/UDP, IP/ESP and IP/UDP/RTP profiles uses the following schemes in order to efficiently compress the various header fields:
- Least Significant Bits (LSB)
- Transmit only the k least significant bits of the field value. Used for header fields that are usually subject to small changes. The decompressor computes the uncompressed value from a reference value and the transmitted bits according to an interpretation interval around the reference value that depends of the field behaviour.
- Window-based Least Significant Bits (W-LSB)
- LSB algorithm modified to achieve robustness. Indeed the LSB algorithm fails to decode the correct value if the reference value at decompressor is not the same as at compressor. To achieve robustness, a sliding window of the successive reference values is maintained at compressor. The number of k least significant bits to transmit to decompressor is then computed such that no matter which reference value the decompressor uses (if in window) the correct value is decoded.
- Scaled RTP Timestamp
- A compression scheme defined for the RTP Timestamp (TS). The TS value does not increase by an arbitrary value from packet to packet. It increases by a multiple of some unit that depends on the audio/video sample rate and frame duration. The compressor can therefore transmit only the multiplication factor once the increment unit is known at the decompressor.
- Timer-based RTP Timestamp
- A scheme that compresses RTP Timestamp (TS) further than the Scaled RTP Timestamp. If the sampling rate of the source is constant, then the TS value closely approximates a linear function of the time of day. So, by using a local clock the decompressor can obtain an approximation of the scaled TS in the header to be decompressed by considering its arrival time. Some LSB bits of scaled TS are transmitted in the packets to refine the approximation and handle jitter.
- Offset IP-ID
- A compression scheme dedicated to IPv4 Identification field. The RTP SN increases by one from one packet to another. If the IP-ID behaves similarly, it is more efficient to transmit the offset between the two values instead of the IP-ID itself.
- Self-describing variable-length (SDVL)
- Not really a compression scheme, SDVL is a field format that transmits values between 0 and 536 870 911 in a minimal number of bytes. Only 1 byte is used for values up to 127, 2 bytes for values up to 16 383… The first bits of the field are used to encode the field length, hence the scheme's name.
- List encoding
- List encoding is used to transmit in an efficient way different types of lists. They are used for CSRC lists in RTP packets and extension header chains in IP packets.
Other profiles may define other encoding schemes. Please refers to the related RFCs for more details.
A step further…
This page is only an introduction to the ROHC protocol, not a full explanation of every small details. For more information, read the RFCs listed on the right side of the page.
If you speak French, you may also be interested in the following talks about ROHC:
- Talk ROHC: compress your VoIP traffic given on 07/07/2014 at RMLL 2014:
- Talk ROHC: compression of IP, UDP, RTP, TCP headers given on 17/11/2018 at Capitole du Libre 2018:
ROHC version 1 (standards):
- RFC 3095 - Framework and four profiles: RTP, UDP, ESP, and uncompressed
- RFC 3843 - A Compression Profile for IP
- RFC 4019 - Profiles for UDP Lite
- RFC 4164 - Context Replication for ROHC Profiles
- RFC 4815 - Corrections and Clarifications to RFC 3095
- RFC 4995 - The ROHC Framework
- RFC 4996 - A Profile for TCP/IP (ROHC-TCP)
- RFC 4997 - Formal Notation (ROHC-FN)
- RFC 5795 - The ROHC Framework
- RFC 6846 - A Profile for TCP/IP (ROHC-TCP)
ROHC version 1 (informational):
- RFC 3096 - Requirements for robust IP/UDP/RTP header compression
- RFC 3759 - Terminology and Channel Mapping Examples
- RFC 4163 - Requirements on TCP/IP Header Compression
- RFC 4224 - ROHC over Channels That Can Reorder Packets
ROHC version 2 (standards):
- RFC 5225 - ROHCv2: Profiles for RTP, UDP, IP, ESP and UDP-Lite
ROHC version 2 (informational):
- RFC 3241 - ROHC over PPP
- RFC 3242 - A Link-Layer Assisted Profile for IP/UDP/RTP
- RFC 3243 - Requirements and Assumptions for 0-byte IP/UDP/RTP Compression
- RFC 3408 - Zero-byte Support for R-mode in Extended Link-Layer Assisted ROHC Profile
- RFC 3409 - Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
- RFC 4362 - A Link-Layer Assisted Profile for IP/UDP/RTP
- RFC 5856 - Integration of ROHC over IPsec Security Associations
- RFC 5857 - IKEv2 Extensions to Support ROHC over IPsec
- RFC 5858 - IPsec Extensions to Support ROHC over IPsec
- RFC 3816 - Definitions of Managed Objects (SNMP MIB) for ROHC