RObust Header Compression (ROHC): Context Replication for ROHC Profiles
Extracted elements (28)
Context replication is introduced to reduce the overhead of context establishment when multiple short-lived connections occur simultaneously. Because each new flow requires full header information during initialization, a multitude of short-lived connections can significantly reduce overall compression gain. Fields like IPv6 source/destination addresses (16 octets each) can be omitted when already present at the decompressor.
Support for context replication is added using the profile-specific part of the IR packet rather than defining an entirely new packet type. One bit (x) left in the IR header for 'Profile specific information' may be used as a flag to distinguish IR from IR-CR packets, preserving extensibility while reusing the existing IR packet structure.
The IR-CR packet contains two distinct CRCs with different purposes: an 8-bit CRC protecting the integrity of the IR-CR header itself (analogous to the IR packet's 8-bit CRC), and a 7-bit CRC over the original uncompressed header to verify that the replication process succeeded. With context replication mixing compressed and uncompressed data, this dual-CRC design is necessary because the distinction present in standard IR packets no longer applies.
The most reliable way to select a base context is to choose one for which at least the static part to be replicated has previously been acknowledged by the decompressor using the CRC option. This is necessary because RFC 3095 does not explicitly define context state management between compressor and decompressor, so no more than a high degree of confidence can be achieved.
A profile supporting context replication SHOULD define for each control field whether its value is replicated from the base context or reinitialized. Examples include NBO/RND flags and the mode-of-operation parameter. This ensures predictable behavior when the new context differs from the base context in control state.
Context replication is designed to operate only over links where a feedback channel is available. Without a feedback channel, the compressor cannot obtain the acknowledgement required to select a valid base context, and the mechanism cannot be used.
Inter-profile context replication (replicating from a base context belonging to a different ROHC profile) is not defined in this document. Existing profiles would need to be updated to export context data entries in a compatible representation before inter-profile replication could be supported.
A compressor MUST NOT initiate context replication while a control field that is not reinitialized by replication is being updated, e.g., during the handshake for a mode transition.
For profiles supporting context replication, only the decompressor is mandated to support context replication; the use of the IR-CR packet is optional for the compressor.
Profiles supporting context replication MUST define a CRC over the original uncompressed header as part of the profile-specific information in the IR-CR packet. This is necessary to allow the decompressor to verify that the replication process has succeeded.
The 7-bit CRC carried within the profile-specific part of the IR-CR header MUST be used by the decompressor to verify that decompression of the reconstructed header succeeded. If the reconstructed header fails the CRC check, changes to the context MUST NOT be performed.
The compressor MAY use sequencing information from the last acknowledgement received to determine which fields can safely be replicated, avoiding replication of fields that have changed significantly from the state corresponding to the acknowledged packet.
The decompressor SHOULD send an ACK when it successfully validates the context as a result of the decompression of one or more IR-CR packets, enabling the compressor to transition to a higher compression state.
The decompressor SHOULD use the CRC option when sending feedback corresponding to an IR or an IR-CR packet.
The static part of the base context to be replicated MUST have been acknowledged by the decompressor using the CRC option, and the base context MUST be valid at replication time. This implies a feedback channel is required; context replication cannot be used without one.
Upon reception of a STATIC-NACK, the compressor MUST transit back to its initial no-context state. The compressor SHOULD also refrain from sending IR-CR packets using the same base context until a subsequent acknowledgement makes that context suitable again, and SHOULD re-initialize the decompressor context using an IR packet.
Upon reception of an IR-CR packet, if the 8-bit CRC fails to verify the packet, the packet MUST be discarded by the decompressor.
When the decompressor fails to validate the context following decompression of one or more initial IR-CR packets, it MUST invalidate the context and remain in its initial state. The decompressor SHOULD send a STATIC-NACK, particularly when performing strict memory management such as deleting context state when a connection-oriented flow has terminated.
A base context is a context previously validated by both compressor and decompressor. The compressor uses a base context as the reference when building a new context via replication. Only contexts acknowledged by the decompressor (using the CRC option) are eligible as base contexts.
The Base Context Identifier (BCID) is the CID used to identify the base context from which information is extracted for replication. The BCID may differ from the CID of the new flow; if BCID equals CID, the base context is overwritten by the replication process.
The IR-CR (IR packet for Context Replication) is a new IR packet type that initializes a new context by referencing a base context. It contains a combination of uncompressed and compressed information plus a reference to the base context, omitting fields being replicated.
The Profile field in the IR-CR packet is abbreviated to the 8 least significant bits (LSBs) of the profile identifier. It selects the highest-number profile in the channel state parameter PROFILES that matches these 8 LSBs.
Context replication creates dependencies between multiple contexts, increasing the potential impact of attacks already identified in RFC 3095. Specifically, corruption of one context can prevent the compressor from initializing another context at the decompressor, or the corruption can propagate to a newly replicated context if the compressor uses a corrupted base context for replication.
The compressor state machine adds a Context Replication (CR) state between IR and higher-order states. From IR, the compressor transitions to CR when a suitable base context can be selected. From CR, it transitions upward via the optimistic approach or upon receiving an ACK. A STATIC-NACK from the decompressor drives a downward transition back to the IR no-context state.
The 7-bit CRC in the IR-CR packet is calculated over all octets of the entire original header before replication, using CRC polynomial C(x) = 1 + x + x^2 + x^3 + x^6 + x^7, with the CRC register preset to all 1's.
The 8-bit CRC in the IR-CR packet MUST cover the entire packet excluding the payload, including the CID or Add-CID octet and the Base CID field if present. It uses polynomial C(x) = 1 + x + x^2 + x^8, with the CRC register preset to all 1's.
The BCID field in the IR-CR packet is represented as a 4-bit field (values 0–15) when the channel uses small CIDs, and as 1–2 octets coded the same way as a large CID when large CIDs are used.
The IR-CR packet general format consists of: an optional Add-CID octet for small CIDs (if CID != 0), an IR type octet (1111110x), 0–2 octets of CID for large CIDs, a 1-octet Profile field (8 LSBs of profile identifier), a 1-octet 8-bit CRC field, variable-length profile-specific information (which MUST include a 7-bit CRC), and variable-length payload.