RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP
obsoletes
- rfc-3242 — RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP
updated by
- rfc-4815 — RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095
Extracted elements (26)
The CCP is introduced to carry an optional context-verification CRC for synchronized physical links that must send at fixed intervals even when no compressed data is available, avoiding the need to send a full RHP in such cases.
The CSP is introduced to handle the case where a packet stream overruns channel bandwidth: by sending only the header and discarding the payload, decompressor context synchronization is maintained without wasting bandwidth on data that would be dropped anyway.
The purpose of the LLA profile is to provide efficient matching of existing speech applications to existing link technologies (e.g., GSM/IS-95-based air interfaces with fixed payload sizes), not to achieve general compression efficiency. The last byte of the ROHC header is eliminated for most packets to avoid requiring the next higher fixed packet size.
The CSP format defined in RFC 3242 was non-interoperable when carrying an RHP header with a 3-bit or 7-bit CRC because payload length was not included; RFC 4362 corrects this by adding a 2-octet RTP Payload Length field to the CSP.
The LLA profile is not applicable when the UDP checksum is enabled; this is always the case for IPv6/UDP. For IPv4/UDP, the sender may choose to disable the UDP checksum to use the LLA profile.
After an IR packet with D=0 (dynamic chain absent, payload discarded) has been processed by the decompressor, the packet MUST be discarded.
All documents describing LLA profile implementation over a specific link technology are REQUIRED to define how the optimistic approach is agreed upon between the compressing and decompressing sides.
All interface parameters (RRP, CSP, CCP, RTP Sequence Number, and segmentation flags), except NHP, MUST always be delivered from the compressor to the assisting layer. The RTP SN MUST be delivered for each packet.
An implementation of ROHC LLA MUST save INFERRED header field values (IPv4 total length, IPv6 payload length, UDP length, IPv4 header checksum) in the decompressor context to successfully verify CCP packets carrying a 7-bit CRC.
An LLA decompressor MUST use optimistic approach knowledge to detect possible context loss events; if context loss is suspected it MUST invalidate the context and not forward any packets until the context has been re-synchronized.
For NHP operation, the assisting layer MUST guarantee in-order delivery over the link, and at the receiving side MUST provide an indication for each packet loss over the link.
If a CSP carries two non-equal CID values, the packet MUST be discarded. After a CSP is received and processed, the packet (including any data following the encapsulated compressed header) MUST be discarded.
If the assisting layer receives CCPs with C=1 from the compressor, it MUST use the last CCP received (corresponding to the last non-CCP packet sent) if a CCP is to be transmitted. A CCP MUST always be made available to the assisting layer.
NHP packets can only be used for CID=0. If the decompressor receives an NHP packet, it is assumed to belong to CID=0 regardless of which CID size has been negotiated.
Periodic context verification SHOULD be performed even when the compressor logic allows NHP packets, to provide an additional guarantee for transparency and catch unexpected errors such as faulty implementations.
The assisting layer MUST provide packet type identification to distinguish RHP packets (those with a compressed header) from NHP packets (header-free packets), since NHP carries no packet type identifier field.
The decompressor is REQUIRED to handle a CCP with C=1 and perform context verification. The received CRC MUST be applied to the last decompressed packet unless a packet loss indication was previously received. Upon CRC failure, actions in RFC 3095 Section 5.3.2.2.3 steps a-d MUST be taken. A CCP with C=0 MUST be ignored.
The decompressor MUST receive from the assisting layer: (1) an indication for each packet loss over the link for CID=0, and (2) each received packet with an indication of whether it is an NHP.
A No-Header Packet (NHP) consists solely of the original packet's payload with no compressed header. It may be used when all header fields are unchanged or follow the established change pattern, and is only valid for CID=0 and only in U/O-mode (not R-mode).
The CV-REQUEST feedback option (Opt Type=8, Opt Len=0) may be used by the decompressor to request an RRP or CSP for context verification when only NHPs have been received for a long time.
The LLA profile (0x0005) extends ROHC RTP (profile 0x0001) with three additional packet types: NHP (No-Header Packet), CSP (Context Synchronization Packet), and CCP (Context Check Packet), plus an interface to an assisting lower layer.
IANA has reserved ROHC profile identifier 0x0005 for the IP/UDP/RTP link-layer-assisted (LLA) profile defined in this document.
All security considerations of ROHC RTP (RFC 3095, Section 7) apply. An additional threat is a denial-of-service attack where an intruder injects bogus CCP packets with random CRC values, causing unnecessary context invalidation, feedback messages, and refresh packets at the decompressor.
The Context Check Packet (CCP) has a 1-octet packet type identifier (11111011), followed by a second octet containing a C bit (bit 0) and a 7-bit CRC field. C=0 means CRC unused; C=1 means a valid 7-bit CRC is present.
The Context Synchronization Packet (CSP) has a 1-octet packet type identifier (11111010), followed by a 2-octet RTP Payload Length field in network byte order, followed by the ROHC header without padding as defined in RFC 3095 Section 5.7.
The LLA IR packet redefines the D-bit from ROHC RTP: D=0 means no dynamic chain is present AND the payload has been discarded. D=1 retains the original ROHC RTP meaning (dynamic chain and payload present). All other IR fields remain as defined in RFC 3095.