Эффективная компрессия заголовков IP-пакетов ROHC

Robust Header Compression (ROHC) is a standardized method to compress the IP, UDP, UDP Lite, RTP, and TCP 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 and , by the fact that it performs well over links where the packet loss rate is high, such as wireless links.

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.

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.

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.

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.

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.

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.

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.

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.