*** Welcome to piglix ***

Robust Header Compression


Robust Header Compression (ROHC) is a standardized method to compress the , , UDP-Lite, , and headers of Internet packets.

In streaming applications, the overhead of IP, UDP, and RTP is 40 bytes for IPv4, or 60 bytes for IPv6. For VoIP, 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 networks 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 RFC 1144 and RFC 2508, by the fact that it performs well over links where the packet loss rate is high, such as wireless links.

The ROHC protocol takes advantage of information redundancy in the headers of the following:

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:

According to RFC 3095, the ROHC scheme has three modes of operation, as follows:

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.


...
Wikipedia

...