User Tools

Site Tools


====== The ROHC protocol ====== ===== Objectives ===== 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. ===== Main principles ===== The ROHC protocol compresses only network headers. It leaves the network payload unchanged. {{ wiki:rohc_only_headers_are_compressed.png | Only network headers are compressed }} In order to compress the network headers, 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). {{ wiki:rohc_redundancy.png | Intra- and inter-packets redundancy }} 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. {{ wiki:rohc_classification.png | Classification of incoming packets }} 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 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 [[|IANA]] is in charge of [[|ROHC protocol identifiers]] assignments for ROHC profiles. The [[|IANA]] also assigned the [[|Internet protocol number]] 142 to the ROHC protocol. The [[|IEEE]] maintains the [[|registry of Ethernet/802.3 protocol identification]]. The ROHC protocol is [[|registered with value 0x22F1]]. ===== The framework ===== ==== 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. {{ wiki:rohc_association.png |ROHC compressor/decompressor association}} 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. {{ wiki:rohc_umode.png |ROHC Unidirectional mode}} 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. {{ wiki:rohc_omode.png |ROHC Bidirectional Optimistic mode}} The R-mode makes use feedback information too. However it is stricter than the O-mode for context updates. {{ wiki:rohc_rmode.png |ROHC Bidirectional Reliable mode}} 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: * Initialization and Refresh (IR) State, * First Order (FO) State, * Second Order (SO) State. {{ wiki:rohc_comp_states.png |ROHC compressor's 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. The decompressor's state machine defines the following three states: * No Context State, * Static Context State, * Full Context State. {{ wiki:rohc_decomp_states.png |ROHC decompressor's states}} Transitions between the above states occur when the decompressor: * successfully decompresses a packet, * fails to decompress several packets. ==== Packet types ==== The Uncompressed profile defines the following ROHC packets: * IR, * Normal. The IP/UDP/RTP profile defines the following ROHC packets: * IR, * IR-DYN, * 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: * IR, * IR-DYN, * 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. ==== 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: ^ Scheme name ^ Scheme description ^ | 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. ===== 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 ROHC RFCs. You may also check the [[library-compliance-rfcs|compliance status of the ROHC library against RFCs]]. You may ask questions about the ROHC protocol and the ROHC RFCs on the mailing list of the [[|ROHC Working Group at the IETF]] or on the [[|mailing list of the ROHC library's project]].

rohc-protocol.txt · Last modified: 2018/04/23 13:55 by didier