SCHC Context Management Extensions

Introduction Static Context Header Compression (SCHC), defined in , provides a mechanism for compressing protocol headers over constrained networks by defining rules in a context shared between sender and receiver. SCHC was initially designed for low-power wide-area networks serving a small number of devices with small, static contexts. As the framework evolved to support scalable deployments, diverse technologies (cellular traffic, space communication), and multi-layer protocol stacks, several limitations emerged:

As the number and heterogeneity of devices increase, the context size grows. Dynamic approaches such as payload compression further increase the number of rules, potentially adding duplicate or partially duplicate field descriptions. Context updates become frequent, increasing protocol overhead and energy consumption.
As the rule set grows, rule matching time increases, potentially creating bottlenecks and additional latency.
Compressing multiple protocol layers (e.g., IPv6/UDP/RTP) in combined rules forces duplication of lower-layer field descriptions across rules, creating a combinatorial explosion. Supporting N variants of IPv6 addresses with M upper-layer protocols requires N*M rules.
Protocols with variable or optional headers (e.g., IPv6 extension headers) cannot be efficiently compressed, as each combination requires its own rule.

This document addresses these limitations by defining:

Rule referencing CDAs () that allow rules to reference and compose other rules, reducing duplication.
A rule fragment branching mechanism () that enables dynamic selection of rule fragments based on packet content, eliminating combinatorial explosion.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology The following terms are used in this document:

Adjacent Field Descriptors:: A set of field descriptions within one rule that belong to a single protocol layer.
Deprecated Rule:: A rule (or subset of a rule) that has been selected to be merged into a new rule using referencing CDAs.
Merged Rule:: A rule that includes at least one of the referencing CDAs defined in this document.
Rule Fragment:: A rule designed to compress a portion of a packet (e.g., a single protocol layer) and intended to be composed with other rule fragments via branching.

Rule Referencing This section defines two novel Compression/Decompression Actions (CDAs) that enable SCHC rules to reference other rules in the context. These CDAs reduce context storage requirements and enable composable rule definitions.

The ref(N) CDA The "ref" CDA references an existing rule within the SCHC context. When a field description uses ref(N), the compressor/decompressor MUST suspend processing of the current rule and apply Rule N to the corresponding portion of the packet. Once Rule N has been fully processed, the compressor/decompressor MUST resume processing the next field description in the original rule. The argument N is the Rule ID of the referenced rule. When ref(N) is used, the Target Value (TV) and Field Length (FL) fields in the referencing field description are not used for compression. Instead, the TVs and FLs of the referenced Rule N apply. The following example illustrates the use of ref(N). Consider a dedicated IPv6 compression rule (Rule 2):

Dedicated IPv6 Compression Rule A UDP compression rule can then reference Rule 2 for the IPv6 portion:

UDP Rule Referencing IPv6 Rule 2 via ref(N) Similarly, a TCP compression rule can reuse the same IPv6 rule. However, since Rule 2 specifies Next Header = 17 (UDP) with MO = equal, a TCP rule cannot use ref(2) directly — the Next Header value would fail to match TCP packets (Next Header = 6). Instead, Rule 4 uses ref-edit(2,1) to override the Next Header field description, demonstrating why ref-edit is necessary when a referenced rule contains a field value that differs for the referencing protocol:

TCP Rule Referencing IPv6 Rule 2 via ref-edit(N,M) In both cases, when the compressor/decompressor encounters a referencing CDA, it loads Rule 2 and applies it to the IPv6 header portion of the packet before resuming with the transport layer fields. For Rule 4, the ref-edit(2,1) CDA first replaces the IPv6 Next Header field description in Rule 2 with the override (TV = 6), then applies the modified rule.

The ref-edit(N,M) CDA The "ref-edit" CDA extends ref(N) by allowing modification of specific field descriptions in the referenced rule. The argument N is the Rule ID of the referenced rule, and M indicates the number of field descriptions immediately following the ref-edit field that specify modifications. When processing ref-edit(N,M), the compressor/decompressor MUST:

Load the referenced Rule N.
For each of the next M field descriptions in the current rule, find the field description in Rule N with a matching Field ID (FID).
Replace the matched field description in Rule N with the one from the current rule.
Apply the modified Rule N to the packet.

The following example modifies the AppIID field from Rule 2:

Using ref-edit to Override AppIID in Rule 2 Here, the decompressor loads Rule 2, locates the IPv6 AppIID field description, replaces its TV with ::3, and then applies the modified rule.

Context Compression Procedure The ref(N) and ref-edit(N,M) CDAs enable context compression procedures that merge rules sharing common field descriptions. One way to realize this is a procedure that operates as follows:

Iterate all rules in the context. For each rule, identify sets of adjacent field descriptions (field descriptions belonging to the same protocol layer).
Group identical sets of adjacent field descriptions that appear in multiple rules.
For each group exceeding a configured threshold of occurrences: a. Create a new rule containing the shared adjacent field descriptions. b. For each original rule containing the group, create a merged rule that uses ref(N) to reference the new rule, plus any remaining field descriptions.
Signal the new rules to all SCHC endpoints. Once confirmed, deprecated rules MAY be removed from the context.

Rule Fragment Branching This section defines a novel Compression/Decompression Action (CDA) and a novel Matching Operator (MO) that enable dynamic composition of SCHC rule fragments at compression time. These mechanisms allow a single rule to branch into different rule fragments based on packet content, solving the combinatorial explosion problem when compressing multi-layer protocol stacks or protocols with optional/variable headers.

The branch CDA The "branch" CDA encodes a selection among alternative rule fragments into the compression residual. branch takes as argument either a Rule ID identifying the next rule fragment to apply, or NULL indicating that no further rule processing follows. A field description using branch contains a mapping table where each entry associates:

A Target Value (TV)
A Rule ID (or NULL) to apply next
A residual value to encode in the compressed packet

The number of bits in the residual is determined by the number of entries in the mapping table. When the compressor encounters a field with branch CDA, it MUST:

Encode the residual value corresponding to the matched entry.
Queue the associated Rule ID for subsequent processing.

When the decompressor encounters a branch residual, it MUST:

Decode the residual to determine the index into the mapping table.
Use the corresponding Rule ID to decompress the next portion of the packet.

A branch to NULL indicates that no further rule processing follows after the current rule completes. Two mechanisms determine which branch to take:

Explicit field matching (match-mapping MO, see ): Used when a protocol header field directly indicates what follows. For example, the IPv6 Next Header field value 17 explicitly identifies UDP as the next protocol. This also applies to IPv6 extension headers (Fragment, Destination Options, Hop-by-Hop), each of which carries its own Next Header field — enabling a chain of branch decisions through successive extension headers until the transport layer is reached. The branch selection is encoded as a residual derived from matching the field value against a mapping table.
Implicit matching (match-rule MO, see ): Used when no single header field identifies what follows. For example, after a UDP header, there is no field indicating whether the payload is RTP, CoAP, or something else. The compressor must attempt to match each candidate rule against the payload content — for instance, checking whether the payload starts with RTP version = 2 and valid SSRC fields. The branch selection is encoded as a residual indicating which rule succeeded.

Field Length Semantics The Field Length (FL) value of a field description using branch determines its usage:

FL > 0: The field corresponds to an actual packet header field of the indicated length. The branch is determined by the field value present in the packet (used with match-mapping MO).
FL = 0: There is no corresponding field in the packet. The branch residual encodes which rule fragment is used to compress the remainder of the packet after the current rule completes. This is used when the next protocol is implicit (used with match-rule MO).

Processing Order When a rule contains multiple field descriptions with branch CDA, the Field Position (FP) determines the invocation order. Rule fragments are processed depth-first: a loaded rule fragment, including any branch within it, MUST be fully processed before the next queued branch from the parent rule is invoked. Specifically, the compressor maintains a branch queue per rule. After completing all CDAs in the current rule, the compressor processes the queue starting with the lowest invocation number. Each dequeued Rule ID is loaded and its matching and compression operations are performed. The packet pointer (Current_Location) advances as each rule fragment is processed. This sequential processing imposes a constraint on rule fragment design: rule fragments MUST be split at protocol boundaries where different subsequent processing of the packet can occur. A branch decision point can only appear at a location where the preceding fields have been fully compressed by the current rule fragment. Placing a branch mid-way through a protocol header is not supported, as the queue processes complete rule fragments in order.

Failure Handling If a loaded rule fragment fails to match the packet at the current location, the entire compression operation for this packet MUST fail. The compressor MUST transmit the packet uncompressed (using Rule ID 0). A branch to NULL terminates further processing, even if there are queued invocations in parent rules. As a consequence, when the packet content following a branch point may be unknown or not covered by any rule fragment, the branch mapping SHOULD include a branch(NULL) entry as a fallback. Without it, an unrecognized field value (in match-mapping) or a payload matching no candidate rule (in match-rule) will cause complete compression failure. Including branch(NULL) allows the compressor to gracefully terminate rule processing at that point, leaving the remainder of the packet uncompressed in the SCHC residual.

The match-mapping MO with branch When branch is used with a non-zero FL, the existing match-mapping MO (defined in ) is used to determine which branch to take. The TV field contains an array of values. The MO matches when the packet field value equals one of the TV entries, and the index of the matching entry selects the corresponding branch argument. The following example shows an IPv6 rule using match-mapping with branch on the Next Header field:

IPv6 Rule with branch on Next Header The mapping table for the Next Header field is: Next Header Branch Mapping

TV	Next Rule	Residual
17	Rule 3 (UDP)	0b000
6	Rule 4 (TCP)	0b001
44	Rule 5 (Fragment)	0b010
60	Rule 6 (Dest Opts)	0b011
41	Rule 7 (IPv6-in-6)	0b100
59	NULL (No Next Hdr)	0b101

When compressing, if the IPv6 Next Header field contains 17 (UDP), the compressor encodes 0b000 as residual and queues Rule 3 for processing after the current rule completes.

The match-rule MO The "match-rule" MO is a novel Matching Operator for use with branch when FL = 0 (no corresponding packet field). It determines which rule fragment matches the remainder of the packet by attempting to match each referenced rule in order. The match-rule MO takes a list of Rule IDs as argument. For each referenced Rule ID, in list order, the compressor MUST:

Save the current packet location.
Load the referenced rule and perform all its matching operations starting at the current location.
If all fields match successfully, return the index of this rule.
If any field fails to match, reset the packet location and proceed to the next Rule ID in the list.

If no rule matches and no NULL entry exists, the match-rule MO fails. If the list contains a NULL entry, it automatically matches when reached. Therefore, a NULL entry SHOULD be placed last in the list; any entries after NULL will never be evaluated. The following example shows match-rule used in a UDP rule to branch into RTP or CoAP compression:

UDP Rule with match-rule Branching to RTP/CoAP Here, after compressing the UDP header, the compressor attempts to match Rule 8 (RTP) against the UDP payload. If RTP matching succeeds, 0b00 is encoded and Rule 8 is used. Otherwise, Rule 9 (CoAP) is attempted. If neither matches, the NULL entry matches and no further compression is applied to the payload.

Interaction Between branch and ref(N) The branch CDA and the ref(N) CDA (defined in ) are complementary mechanisms:

ref(N) provides static rule composition: the referenced rule is always applied unconditionally.
branch provides dynamic rule composition: the referenced rule fragment is selected based on packet content or rule matching at compression time.

Both mechanisms MAY be used within the same context. A rule fragment referenced by branch MAY itself contain ref(N) references to other rules.

Examples This section provides comprehensive examples demonstrating the mechanisms defined in this document.

IPv6/UDP/TCP Rule Composition Using ref(N) and ref-edit(N,M) This example shows how ref(N) and ref-edit(N,M) eliminate duplication when multiple transport protocols share the same IPv6 compression rule. Without referencing CDAs, compressing IPv6/UDP and IPv6/TCP requires two complete rules, each repeating 10 IPv6 field descriptions. With referencing CDAs, a single IPv6 rule (Rule 2 in ) is defined once and referenced by the UDP rule (Rule 3 in ) using ref(2), and the TCP rule (Rule 4 in ) using ref-edit(2,1) to override the Next Header value from 17 to 6. For a context with 3 IPv6 address variants and 4 transport/application protocols, the traditional approach requires 12 rules with 10 duplicated IPv6 field descriptions each (120 total IPv6 field descriptions). Using referencing CDAs, only 3 IPv6 rules plus 4 transport rules are needed (3 + 4 = 7 rules, 30 IPv6 field descriptions).

Multi-Protocol Branching with branch This example demonstrates branch used with match-mapping to handle IPv6 packets with different next headers. Rule 2 in uses the IPv6 Next Header field to branch into different rule fragments for UDP, TCP, IPv6 Fragment Header, Destination Options, and IPv6-in-IPv6 tunneling. The following rule fragments are referenced by the branch entries:

UDP Rule Fragment (Rule 3)

UDP Rule Fragment with Payload Branching Rule 3 compresses the UDP header and then uses match-rule to determine whether the payload is RTP (Rule 8), CoAP (Rule 9), or unknown (NULL).

TCP Rule Fragment (Rule 4)

TCP Rule Fragment

IPv6 Fragment Header Rule Fragment (Rule 5) This rule handles the first fragment of a fragmented IPv6 packet. The Next Header field in the fragment header uses branch to determine what protocol follows.

IPv6 First Fragment Rule Fragment

IPv6-in-IPv6 Tunneling Rule Fragment (Rule 7) For IPv6-in-IPv6 tunneling, the inner header may use different address prefixes than the outer header. This rule does not include IPv6-in-IPv6 as a further nesting option.

Inner IPv6 Header Rule Fragment

RTP Rule Fragment (Rule 8)

RTP Base Header Rule Fragment

Compression Walkthrough Consider an IPv6/UDP/RTP packet with the following header values:

IPv6 Next Header: 17 (UDP)
UDP Source Port: 1123 (downlink)
UDP Destination Port: 1124 (downlink)
RTP Version: 2

The compression proceeds as follows:

The compressor iterates through the rule set and attempts to match each rule against the packet. Rule 2 () is selected as the initial rule because its IPv6 field descriptions (Version, Diffserv, Flow Label, Hop Limit, prefixes, IIDs) all match the packet. Note that Rule 2 here uses branch rather than a fixed Next Header value, so matching succeeds regardless of the transport protocol.
IPv6 fields are matched and compressed. The Next Header field (value 17) matches the first mapping entry. The compressor encodes residual 0b000 and queues Rule 3 for processing.
After completing Rule 2, the compressor loads Rule 3 (). UDP fields are matched and compressed.
The match-rule MO at the end of Rule 3 loads Rule 8 and attempts matching against the UDP payload. RTP version = 2 matches the first field. All other RTP fields match. The compressor encodes residual 0b00 and processes Rule 8.
Rule 8 () compresses the RTP header fields.

The resulting compressed packet contains: Rule ID + IPv6 branch residual (3 bits) + UDP payload branch residual (2 bits) + RTP residual fields (Extension, csrc-count LSB, marker, payloadType LSB, SeqNr, SSRC).

Security Considerations The mechanisms defined in this document introduce new attack surfaces related to context provisioning and rule processing.

Circular Reference Attacks The ref(N), ref-edit(N,M), and branch CDAs create directed references between rules. If not validated, a malicious or misconfigured context could contain circular references (e.g., Rule A references Rule B which references Rule A), causing the compressor or decompressor to enter an infinite loop. Implementations MUST detect circular references when a context is provisioned or updated. A simple approach is to verify that the rule reference graph is a directed acyclic graph (DAG). Alternatively, implementations MAY enforce a maximum reference depth and abort processing if exceeded.

Resource Exhaustion Attacks Deeply nested rule references, large branch mapping tables, or extensive match-rule candidate lists can consume significant processing time and memory on constrained devices. An attacker able to provision or influence context content could craft rules designed to exhaust device resources. Implementations SHOULD enforce limits on:

Maximum reference chain depth (number of nested ref/ref-edit/branch invocations).
Maximum number of entries in a branch mapping table.
Maximum number of candidate rules evaluated by match-rule.
Total processing time for a single packet compression/decompression operation.

If any limit is exceeded, the implementation MUST abort processing and transmit the packet uncompressed.

Context Integrity The security of these mechanisms depends on the integrity of the shared context. Unauthorized modification of rules (e.g., redirecting a ref(N) to a different rule, or altering branch mappings) could cause incorrect compression or decompression, leading to data corruption or information disclosure. Context provisioning and update mechanisms MUST ensure integrity and authenticity of rule definitions.

IANA Considerations TODO