RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite
Extracted elements (30)
ROHCv2 compresses extension headers using the same chaining mechanism as other protocol headers, rather than RFC 3095's list compression. This simplifies the algorithm but requires that extension headers not be added or removed during the lifetime of a context; if they are, compression must be restarted for the flow.
ROHCv2 eliminates the IR-DYN packet type found in RFC 3095. Instead, each profile defines a CO header (co_repair) with a 7-bit CRC that can perform robust context repair. This also means only the IR header can change the association between a CID and its profile, simplifying the state machine.
ROHCv2 mandates a CRC in the FEEDBACK-2 format (optional in RFC 3095) and uses a different set of feedback options. This ensures feedback integrity so that a compressor can reliably trust decompressor state reports and avoid sending unnecessary context refreshes once bidirectional operation is established.
The 3-bit CRC over control fields (control_crc3) protects updates to control fields in co_common and co_repair headers because these updated values are not always used to decompress the header that carries them and thus are not covered by the CRC-7 over the uncompressed header. Without this CRC, a successful CRC-7 verification could mask an incorrectly updated control field.
There is an inherent tradeoff between robustness to packet loss and to reordering in the LSB encoding of the MSN: the interpretation interval offset p determines the maximum tolerated reordering depth, while (2^k - 1) - p determines the maximum tolerated consecutive losses. The reorder_ratio control field allows the compressor to adjust this split dynamically based on observed channel characteristics.
IPv6 headers using the jumbo payload option of RFC 2675 are not compressible using the inferred_ip_v6_length encoding method, because the payload length field value does not match the actual packet length under that option.
ROHCv2 profiles supersede but do not obsolete the RFC 3095 (RTP/UDP/IP, UDP/IP, IP, ESP/IP), RFC 3843 (IP), and RFC 4019 (UDP-Lite) profiles. The two sets of profiles can coexist on the same ROHC channel; the profile identifier in the IR header selects which set of rules applies for a given context.
For profiles where the MSN is created by the compressor (0x0102, 0x0104, 0x0108), the MSN SHOULD be incremented by one for each packet sent for a specific CID, and MUST be initialized to a random value when the context is first created or when the associated profile changes.
If an index is received in a compressed CSRC list without an accompanying Item and the decompressor has no context for that index, the decompressor MUST NOT deliver the packet to upper layers.
In a compressed list that is part of the dynamic chain, all X-bits in the XI list MUST be set (all items must be present). Previously established item table entries not present in the current list MUST also be retained in the decompressor context.
Once the decompressor has established a feedback channel for a specific context (CID), it is REQUIRED to continue sending feedback for the lifetime of that context (until an IR packet associates the CID to a different profile), in order to send error recovery requests and optional acknowledgments.
ROHCv2 profiles MUST NOT assign a sequential IP-ID behavior (network byte order or byte-swapped) to any IP-ID except the one in the innermost IP header when compressing more than one level of IP headers. A compressor MUST assign either constant-zero or random IP-ID behavior to tunneling (outer) headers.
The compressor MUST NOT use ROHC segmentation (i.e., the MRRU MUST be set to 0) if the ROHC channel configuration includes at least one ROHCv2 profile and the channel cannot guarantee in-order delivery of packets between compression endpoints.
The decompressor MUST always validate the integrity of the control fields covered by the 3-bit CRC when processing a co_common or co_repair compressed header. Failure to validate should be treated as a decompression failure, though the decompressor MAY still forward the packet if the CRC-7 over the uncompressed header succeeds.
The decompressor MUST always validate the IR header using the 8-bit CRC it carries. If validation fails, the context MUST NOT be updated and the IR header MUST NOT be delivered to upper layers.
The decompressor MUST always verify the decompression of every CO header using the CRC it carries. If CRC verification fails, context updates MUST NOT be performed, and the packet MUST NOT be delivered to upper layers.
The time_stride_value parameter MUST be set to zero unless the compressor has received a feedback message with the CLOCK_RESOLUTION option set to a non-zero value, preventing erroneous activation of timer-based compression.
Until the decompressor has established a feedback channel for a context, the compressor SHOULD periodically send IR packets, because decompression failure is possible without sufficient information at the decompressor.
When the compressor detects that the scaled RTP timestamp residue (ts_offset) has changed, it MUST NOT select a compressed header format that uses scaled timestamp encoding before re-establishing the residue. If a decompressor receives scaled timestamp bits while ts_stride equals zero, it MUST NOT deliver the packet and SHOULD treat this as a CRC verification failure.
ROHCv2 compressed headers use three types of chains that group fields by characteristic: a static chain (IR only) for invariant fields, a dynamic chain (IR and co_repair) for slowly changing fields, and an irregular chain (all CO except co_repair) for per-packet changing fields. Each chain contains one item per compressed protocol header in order from outermost to innermost.
Scaled RTP Timestamp Compression uses the ts_stride control field (default 160) as a scaling factor: timestamp = delta_msn * ts_stride + reference_timestamp. The compressor must re-establish the residue (ts_offset) before using scaled encoding whenever it changes. Use of scaling is OPTIONAL and indicated by the tsc_indicator control field.
The Master Sequence Number (MSN) is a per-context control field that either reuses an existing protocol field (e.g., RTP SN) or is created by the compressor. It is present in every ROHCv2 header: sent in full in IR headers and LSB-encoded in CO headers. It is used to differentiate reference headers in feedback and to infer incrementing fields such as the IPv4 Identifier.
The reorder_ratio control field specifies how much reordering is accommodated by the LSB encoding of the MSN, allowing the compressor to adjust the distribution of the interpretation interval between negative (reordering) and positive (loss) deltas on links with varying reordering characteristics.
The timer_based_lsb encoding method compresses a field whose change pattern approximates a linear function of time, using the local clock to obtain an approximated reference value (tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride), then applying LSB encoding relative to that approximation. Usage is OPTIONAL and controlled by the time_stride control field.
This document registers six ROHCv2 profile identifiers with IANA under the ROHC Profile Identifiers registry: 0x0101 (RTP/UDP/IP), 0x0102 (UDP/IP), 0x0103 (ESP/IP), 0x0104 (IP), 0x0107 (RTP/UDP-Lite/IP), and 0x0108 (UDP-Lite/IP). These supersede the corresponding RFC 3095, RFC 3843, and RFC 4019 profile definitions.
ROHCv2 profiles inherit the security considerations of the ROHC framework (RFC 4995). Header compression reduces the information available for per-packet inspection at intermediate nodes; if the compression channel itself can be tampered with, an attacker could cause decompression failures or corrupt reconstructed headers. The CRC mechanisms in IR and CO headers provide integrity verification of the decompressed result but do not replace link-layer or end-to-end security.
The decompressor operates as a three-state machine: No Context (NC), Repair Context (RC), and Full Context (FC). The decompressor starts in NC, moves to FC upon successful CRC-8 validation of an IR header, drops to RC upon context damage detection, and drops to NC upon static context damage detection. Only in FC may all CO header types be decompressed.
Compressed lists of RTP CSRC identifiers use a 1-byte header with a PS bit (0 = 4-bit XI fields, 1 = 8-bit XI fields) and a 4-bit count m, followed by m XI items each containing an X presence bit and an Index into the item table, followed by the items whose X bit is set. Reserved bits MUST be zero; the decompressor MUST discard packets where they are non-zero.
Inferred encoding methods transmit zero bits for several computable fields: inferred_udp_length (UDP length inferred from payload size), inferred_ip_v4_header_checksum (IPv4 checksum recomputed at decompressor), inferred_ip_v4_length (IPv4 total length counted from decompressed packet), and inferred_ip_v6_length (IPv6 payload length counted from decompressed packet).
The control_crc3_encoding method produces a 3-bit CRC (polynomial 0x06, initial value 0x07) over a concatenated list of control fields: reorder_ratio (2 bits, 6-bit padded), ts_stride (32 bits, RTP profiles only), time_stride (32 bits, RTP profiles only), msn (16 bits, non-RTP/ESP profiles), coverage_behavior (2 bits, UDP-Lite profiles), and ip_id_behavior (one padded octet per IP header).