rohc_protocol

NAME
DESCRIPTION
MAIN PRINCIPLES
STANDARDIZATION
FRAMEWORK
SEE ALSO
COLOPHON

NAME

rohc_protocol - The ROHC protocol

DESCRIPTION

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 very efficient for compressing VoIP streams that use RTP as transport protocol. ROHC is also suitable for compressing IPv4, IPv6, UDP, UDP−Lite, ESP, and TCP headers of Internet packets.

MAIN PRINCIPLES

The ROHC protocol compresses only network headers. It leaves the network payload unchanged.

non−compressed
packet ROHC packet
+-----------+ +-------------+
| | | |
| header #1 |--=-+--=-->| ROHC header |
| | | | |
+-----------+ : +-------------+
| | | | |
| header #2 |-=--+ +=->| payload |
| | | | | |
+-----------+ : | +-------------+
| | | |
| header #3 |-=--+ |
| | |
+-----------+ :
| | |
| payload |-=-----+
| |
+-----------+

In order to compress the network headers, the ROHC protocol takes advantage of the information redundancy in the different headers of:

	o		one single network packet (eg. the payload lengths in IP and UDP headers),
	o		several network packets that belongs to one single stream (eg. the IP addresses).

packet #1 packet #2
+-----------+ +-----------+
header #1 | NN| | OO|
+-----------+ +-----------+
header #2 | L NN | | P OO |
+-----------+ +-----------+
header #3 | L MMM | | P MMM |
+-----------+ +-----------+
payload | | | |
+-----------+ +-----------+

Redundant information is transmitted in first packets only. 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.

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.

+-----------+
+---> | stream #1 |
| +-----------+
|
| +-----------+
incoming packets ------+---> | stream #2 |
| +-----------+
| ...
| +-----------+
+---> | stream #n |
+-----------+

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.

STANDARDIZATION

The ROHC protocol is mainly standardized by the IETF, but some protocol numbers are defined by other organisms.
IETF - Internet Engineering Task Force

The ROHC protocol is standardized by the IETF. The ROHC Working Group was formed to specify a common compression protocol platform. Several Requests For Comments (RFC) were published to define the ROHC framework and a number of compression profiles. The RFCs are listed on the SEE ALSO section of this document.

IANA - Internet Assigned Numbers Authority

The IANA is in charge of ROHC protocol identifiers assignments for ROHC profiles, but also the Internet protocol number 142 to the ROHC protocol.

IEEE - Institute of Electrical and Electronics Engineers

The IEEE maintains the registry of Ethernet/802.3 protocol identification. The ROHC protocol is registered with value 0x22F1.

FRAMEWORK

The ROHC protocol defines an extensible ROHC framework capable of compressing different kinds of streams (IP, UDP, TCP, RTP...). The framework is generic. The profiles then define how the different kinds of streams are compressed. A profile is a set of encoding schemes and packet formats.

Definitions
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.

uncompressed ROHC uncompressed
packets +------------+ packets +--------------+ packets
-----------> | Compressor | -------> | Decompressor | ----------->
+------------+ +--------------+

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:

	o		the Unidirectional mode (U−mode),
	o		the Bidirectional Optimistic mode (O−mode),
	o		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.

+------------+ +--------------+
| | ROHC packets | |
| Compressor | ----------------> | 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.

+------------+ ROHC packets +--------------+
| | ----------------> | |
| Compressor | | Decompressor |
| | <---------------- | |
+------------+ ROHC feedback +--------------+

The R−mode makes use feedback information too. However it is stricter than the O−mode for context updates.

+------------+ ROHC packets +--------------+
| | ----------------> | |
| Compressor | | Decompressor |
| | <---------------- | |
+------------+ ROHC feedback +--------------+

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.

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 compressor’s state machine defines the following three states:

	o		Initialization and Refresh (IR) State,
	o		First Order (FO) State,
	o		Second Order (SO) State.

+----------+ +----------+ +----------+
| IR State | <-----> | FO State | <-----> | SO State |
+----------+ +----------+ +----------+

Transitions between the above states occur when the compressor:

	o		compresses a packet that contains too many variations,
	o		receives a positive/negative feedback from the decompressor,
	o		periodically refreshes the context.

The decompressor’s state machine defines the following three states:

	o		No Context State,
	o		Static Context State,
	o		Full Context State.

+--------------+ +----------------+ +--------------+
| No Context | <---> | Static Context | <---> | Full Context |
+--------------+ +----------------+ +--------------+

Transitions between the above states occur when the decompressor:

	o		successfully decompresses a packet,
	o		fails to decompress several packets.

Packet types
The Uncompressed profile defines the following ROHC packets:

	o		IR,
	o		Normal.

The IP/UDP/RTP profile defines the following ROHC packets:

	o		IR,
	o		IR−DYN,
	o		Type 0: UO−0, R−0, R−0−CRC,
	o		Type 1: UO−1, UO−1−ID, UO−1−TS, R−1, R−1−ID, R−1−TS,
	o		Type 2: UOR−2.

The IP−only, non−RTP IP/UDP and IP/ESP profiles define the following ROHC packets:

	o		IR,
	o		IR−DYN,
	o		Type 0: UO−0, R−0, R−0−CRC,
	o		Type 1: UO−1 (different from RTP profile), R−1 (different from RTP profile).
	o		Type 2: UOR−2 (different from RTP profile).

Other profiles may define other packets. Please refers to the related RFCs for more details.

Encoding schemes
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 scheme. Please refers to the related RFCs for more details.

COLOPHON

This page is part of release 2.1.0 of the ROHC library project. A description of the project, and information about reporting bugs, can be found at http://rohc-lib.org/.