Static Context Header Compression (SCHC) Architecture
draft-ietf-schc-architecture-07
| Document | Type | Active Internet-Draft (schc WG) | |
|---|---|---|---|
| Authors | Alexander Pelov , Pascal Thubert , Ana Minaburo , Quentin Lampin , Marion Dumay | ||
| Last updated | 2026-11-02 | ||
| Replaces | draft-ietf-lpwan-architecture | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-schc-architecture-07
SCHC Working Group A. Pelov
Internet-Draft IMT Atlantique
Intended status: Informational P. Thubert
Expires: 7 May 2027
A. Minaburo
Consultant
Q. Lampin
M. Dumay
Orange
3 November 2026
Static Context Header Compression (SCHC) Architecture
draft-ietf-schc-architecture-07
Abstract
The Static Context Header Compression and fragmentation (SCHC)
framework provides both a header compression mechanism and an
optional fragmentation mechanism. This document defines an
architecture for SCHC deployments, providing guidance for
implementers and operators on the essential components and their
interactions required for effective SCHC operation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pelov, et al. Expires 7 May 2027 [Page 1]
Internet-Draft SCHC Architecture November 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. SCHC: Primer . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Overview of a Basic Architecture . . . . . . . . . . . . 8
5.1.1. Basic SCHC Architecture . . . . . . . . . . . . . . . 8
5.2. Focus on core components . . . . . . . . . . . . . . . . 10
5.2.1. Instance . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3. Session . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.4. Domain . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.5. SCHC Data Unit Format . . . . . . . . . . . . . . . . 17
6. Deployment models . . . . . . . . . . . . . . . . . . . . . . 19
6.1. LPWAN deployment . . . . . . . . . . . . . . . . . . . . 19
6.2. 6Lo deployments . . . . . . . . . . . . . . . . . . . . . 20
7. Operational considerations . . . . . . . . . . . . . . . . . 21
7.1. Role of an Instance in a SCHC communication . . . . . . . 21
7.2. Context consistency . . . . . . . . . . . . . . . . . . . 21
7.3. Data Models and Parsing . . . . . . . . . . . . . . . . . 22
7.4. Management . . . . . . . . . . . . . . . . . . . . . . . 23
7.4.1. Context Provisioning . . . . . . . . . . . . . . . . 23
7.5. Error handling . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. PPP deployment . . . . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Pelov, et al. Expires 7 May 2027 [Page 2]
Internet-Draft SCHC Architecture November 2026
1. Introduction
The IETF LPWAN Working Group defined the necessary operations to
enable IPv6 over selected Low-Power Wide-Area Networking (LPWAN)
radio technologies; [RFC8376] presents an overview of those
technologies. The Static Context Header Compression (SCHC) framework
[RFC8724] is the core product of that effort and was the basis to
form the SCHC Working Group. [RFC8724] defines a generic framework
for compressing and decompressing protocol headers and, optionally,
fragmenting and reassembling packets. Although SCHC was initially
developed for constrained LPWAN environments, the framework itself is
generic: its mechanisms can also be used over other network
technologies and in a wider range of deployment models. The
architecture defined in this document is applicable to LPWAN and non-
LPWAN environments alike, from highly constrained devices and links
to more capable ones. Assumptions that stem from the LPWAN
environment, such as extreme bandwidth scarcity, very small frames,
or intermittent connectivity, apply where that environment does and
are not required by this architecture.
This document does not replace or update [RFC8724]: it does not
modify the mechanisms that [RFC8724] specifies, and it does not
define new Rule formats, SCHC Data Unit formats, or protocols. It
provides an architectural entry point to SCHC and a common
understanding that helps tie together SCHC-related specifications.
This broader approach aligns with the objective defined by the SCHC
Working Group Charter, which is to extend the benefits of SCHC to
both LPWAN and non-LPWAN environments.
This document details the constitutive elements of a SCHC-based
solution as well as guidance on SCHC deployment and operation. It
provides a common terminology as well as a general architecture for
SCHC deployments, describing the essential components and their
interactions, possible deployment types, and some operational and
security considerations.
2. Requirements Language
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
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document is Informational. It places no requirements on
implementations of [RFC8724], and nothing in it contradicts [RFC8724]
or the Profiles built on it. In some cases, terminology was
clarified for contexts or uses which were not initially in scope of
Pelov, et al. Expires 7 May 2027 [Page 3]
Internet-Draft SCHC Architecture November 2026
SCHC. Where this document uses BCP 14 keywords, they apply to
documents that specify an element this architecture leaves open, such
as a Control Header (Section 5.2.5.1), and they state what such a
document has to provide for the architecture to hold.
3. Terminology
This section defines terminology and abbreviations used in this
document. In the following, terms are assumed to be defined in the
context of the SCHC ecosystem, unless specified otherwise, e.g.,
Endpoint refers to a SCHC Endpoint, Instance refers to a SCHC
Instance, and so on.
This document uses the following terms as defined in Section 4 of
[RFC8724]: App, Compression Residue, Dev, Downlink, RuleID, SCHC
Packet, and Uplink. It also uses SCHC Fragment and Fragment Header,
as defined in Sections 8.2.1 and 8.3.1 of [RFC8724].
SCHC: Static Context Header Compression and fragmentation, a generic
framework defined in [RFC8724], that performs compression/
decompression and, optionally, fragmentation/reassembly, based on
a Static Context shared between two or more Endpoints. The SCHC
acronym is pronounced like "sheek" in English (or "chic" in
French).
Endpoint: A logical entity that provides SCHC functionality by
hosting the SCHC processing code, rather than a physical device.
Multiple SCHC Endpoints can operate on the same physical
equipment, for example to serve different Domains, tenants,
strata.
Instance: A logical component of an Endpoint that executes the
actual SCHC operations, e.g. compressing and decompressing
headers, fragmenting and reassembling packets. Multiple Instances
can coexist on the same Endpoint but each Instance operates
independently, with its own Context and Configuration.
Rule: Part of the Context that describes how a packet is compressed
and decompressed, or fragmented and reassembled, as defined in
Section 4 of [RFC8724]. A compression Rule is a structured set of
header fields and matching conditions used by SCHC to process
packets in accordance with specified actions.
Set of Rules (SoR): A collection of Rule entries that define how
specific header fields are processed by an Instance.
Context: A SoR together with metadata, shared by two or more
Pelov, et al. Expires 7 May 2027 [Page 4]
Internet-Draft SCHC Architecture November 2026
Instances. Metadata may, for example, refer to a data model or a
parser compatible with the rule format.
Instance Configuration: A set of configurations specific to an
Instance that define how SCHC operations are performed, e.g. role
of the Instance, matching policy, dispatcher configuration,
supported SCHC features.
Manifest: The part of an Instance Configuration that lists the SCHC
functionalities (C/D, F/R, SCHClets) which should be provided by
an Instance.
Profile: SCHC offers variations in the way it is operated, with a
number of parameters listed in Appendix D of [RFC8724]. A Profile
indicates a particular setting of all these parameters, which
should be shared by the communicating parties, together with
guidelines on how SCHC operates for a given network technology or
deployment.
Set of Variables (SoV): Runtime parameters and session variables,
such as fragmentation-related timers, retransmission counters,
state flags, and other per-session values that may change during
operation.
Session: A communication session between two or more Instances that
share a common Context for SCHC operations. The runtime state of
a Session is held in a Set of Variables (SoV).
Dispatcher: A logical component that routes packets and SCHC Data
Units to the appropriate Instance based on defined admission
criteria. The Dispatcher can be integrated into the network stack
or as a separate component.
Discriminator: An optional information element used by the
Dispatcher to enable the selection of the correct Instance. The
Discriminator can be a combination of several criteria.
Parser: A software tool or component that dissects and analyzes
network packets, to extract header fields such as source and
destination addresses, port numbers, and payload data.
Data Model: A formal description of the Rules and of the header
fields they refer to, that allows an Instance to interpret those
fields and to exchange Contexts in an interoperable way.
Stratum: A background concept that identifies a portion of the
Pelov, et al. Expires 7 May 2027 [Page 5]
Internet-Draft SCHC Architecture November 2026
network protocol stack targeted by SCHC, i.e., the contiguous
layers within which SCHC processing can be applied. The Stratum
defines the scope of the protocol headers that the SCHC Rules in
the associated Context can address.
SCHC Data Unit: The unit exchanged between SCHC Instances. A SCHC
Data Unit consists of a Rule Identifier (RuleID) and the result of
the SCHC operation (if non-empty), such as a compression residue
or a packet fragment. It may be followed by a SCHC Payload
(Section 5.2.5).
Control Header: A structure that precedes the RuleID of a SCHC Data
Unit and provides one or more control information elements for
that SCHC Data Unit whenever necessary. For example, it may
contain a Discriminator to route a SCHC Data Unit to the correct
Instance. The Control Header is not part of the SCHC Data Unit
(Section 5.2.5.1).
Domain: A logical grouping of Instances that share a common set of
Contexts for SCHC operations.
Domain Manager: A logical component that manages the Domain,
including context synchronization and configuration distribution.
Instance Manager: A logical component that manages the lifecycle and
configuration of Instances within an Endpoint. It is responsible
for creating, updating, and deleting Instances as needed,
synchronizing Contexts, and managing Instance Configurations.
SCHClet: A self-contained unit that implements a specific SCHC
function or a subset of SCHC operations. A SCHClet can be
combined with other SCHClets within an Instance.
Context Repository: A logical component that stores and manages the
Contexts used by its Domain.
C/D: SCHC function that performs the Compression and Decompression
of headers.
F/R: SCHC function that performs the Fragmentation and Reassembly of
SCHC Packets, as defined in Section 8 of [RFC8724].
MO: Matching Operator, as defined in Section 7.3 of [RFC8724].
CDA: Compression/Decompression Action, as defined in Section 7.4 of
[RFC8724].
Pelov, et al. Expires 7 May 2027 [Page 6]
Internet-Draft SCHC Architecture November 2026
4. SCHC: Primer
This section briefly recalls the SCHC concepts previously defined in
[RFC8724] needed to understand the architecture.
SCHC is a framework designed to efficiently compress headers of
network packets. It provides compression/decompression (C/D) and
optional fragmentation/reassembly (F/R) functions. The compression/
decompression mechanism reduces header overhead by exploiting the
predictable nature of network flows. Instead of transmitting full
headers, both the sending and receiving Instances store synchronized,
static information about expected headers: the Context, which
contains Rules. Using a Rule that matches the headers of a packet to
be transmitted, the sender replaces the known header fields with a
short RuleID which identifies the rule that applies, and a
compression residue if any, forming a SCHC Data Unit. The receiver
of this SCHC Data Unit matches the RuleID against its own Context and
applies decompression actions to reconstruct the original header.
A C/D Rule describes how to process identified header fields. Its
Field Descriptors specify, among other things, the field, the value
or condition to be matched, the Matching Operator (MO), and the
Compression/Decompression Action (CDA). A parser identifies the
fields in the packet; the Rule defines how those fields are matched
and encoded. The compressor selects a matching Rule and sends its
RuleID together with any resulting Compression Residue. The
decompressor uses the corresponding Rule to reconstruct the header.
Fields that need not be transmitted can be recovered from the Rule or
computed during decompression; other fields may contribute bits to
the Compression Residue. The resulting SCHC Data Unit consists of a
compressed header (the RuleID and, when present, the Compression
Residue) followed by the original packet payload.
When required by the underlying link or deployment, F/R operates on
the SCHC Packet produced by C/D. The receiver reassembles the SCHC
Packet before applying C/D. F/R is optional, and its use and
operating parameters depend on the applicable Profile. C/D and F/R
are distinct SCHC functions and use Rules for different purposes,
even though their RuleIDs may share a namespace within their scope.
5. Architecture
Some of the terms used in this architecture, such as Endpoint,
Instance, Dispatcher, and Discriminator, name components that every
deployment conforming to [RFC8724] already has; the others, such as
Domain, Session, or Control Header, describe more complex deployments
and are not required for operation as specified in [RFC8724].
Pelov, et al. Expires 7 May 2027 [Page 7]
Internet-Draft SCHC Architecture November 2026
5.1. Overview of a Basic Architecture
5.1.1. Basic SCHC Architecture
Figure 1 illustrates how messages are exchanged between applications
running on two remote hosts using SCHC Compression/Decompression and
optionally Fragmentation/Reassembly.
Each host features an Endpoint that hosts the Instance executing the
SCHC functions. The Instance stores a Context that may have been
obtained from an entity called the Context Repository. The same
Context is shared between the two Endpoints. The Instance
Configuration specifies the required SCHC functions and parameters
necessary for the Instance to operate properly: which packets to
intercept, the rule-matching policy (e.g., first-match, best-match),
the Instance's role (in the case of asymmetric processing), etc.
Having the same Context is not sufficient to guarantee the
interoperability of SCHC operations between two Instances: the header
fields also have to be delineated in the same way on each Endpoint
(Section 7.3).
Instances sharing a common set of Contexts form a Domain. The Domain
Manager is responsible for managing the Contexts of all Instances
that belong to it. A communication between two Instances or more
that share a common Context is called a Session. Each Instance,
Context, and Session must be uniquely identifiable to allow the
Domain Manager to update the Context of a specific Instance.
Pelov, et al. Expires 7 May 2027 [Page 8]
Internet-Draft SCHC Architecture November 2026
+-----------------------+ +-----------------------+
| Endpoint | | Endpoint |
| | | |
| +-------------------+ | | +-------------------+ |
| | Instance | | | | Instance | |
| | | | | | | |
| | +---------------+ | | | | +---------------+ | |
| | | Instance | | | | | | Instance | | |
| | | Configuration | | | | | | Configuration | | |
| | +---------------+ | | | | +---------------+ | |
| | +---------+ | | | | +---------+ | |
| | | Context |< - - - - - - - - - - - - - - - >| Context | | |
| | +---------+ | | Shared | | +---------+ | |
| +-------------------+ | Context | +-------------------+ |
| +-------------------+ | | +-------------------+ |
| |SCHC Functions | | | SCHC Functions | |
| | | | | | |
| | +-----+ +-----+ | | | | +-----+ +-----+ | |
| | | C/D | | F/R | | | | | | C/D | | F/R | | |
| | +-----+ +-----+ | | | | +-----+ +-----+ | |
| +-------------------+ | | +-------------------+ |
+-----------------------+ +-----------------------+
^ ^
| |
---------------------------------------------
SCHC Data Units exchanged inside a Session
Figure 1: Overview of two simple Endpoints exchanging SCHC Data Units
Pelov, et al. Expires 7 May 2027 [Page 9]
Internet-Draft SCHC Architecture November 2026
+-----------------------------------------------------+
| Domain Manager |
| |
| +-------------+ +--------------+ +--------------+ |
| |Endpoint | |Context | |Instance | |
| |Manager | |Manager | |Configuration | |
| | | |+------------+| |Manager | |
| | | || Context || | | |
| | | || Repository || | | |
| | | |+------------+| | | |
| +-------------+ +--------------+ +--------------+ |
| ^ ^ ^ |
+------|-----------------------|-------|--------------+
| | |
Registration| Context Provisioning| |Configuration
+-| and Synchronization| |Distribution
| | | |
v | | |
+---------------|-------------------+ | |
| Endpoint | | | |
| v | | |
| +------------------------+ | | |
| | Instance Manager | | | |
| +------------------------+ | | |
| ^ ^ | | |
| | | +--------------------+ | | |
| | +--->| Instance 1 | | | |
| | | | | | |
| | | +--------------+ | | | |
| | | |Context |<--------+ |
| | | +--------------+ | | |
| | | +--------------+ | | |
| | | |Instance |<----------------+
| | | |Configuration | | |
| | | +--------------+ | |
| | +--------------------+ |
| | +--------------------+ |
| +------>| Instance 2 | |
| +--------------------+ |
+-----------------------------------+
Figure 2: Overview of Endpoint, Instance, and Domain
configuration and management
5.2. Focus on core components
Pelov, et al. Expires 7 May 2027 [Page 10]
Internet-Draft SCHC Architecture November 2026
5.2.1. Instance
An Instance is the fundamental component that runs a set of SCHC
functionalities as defined in [RFC8724] hosted on an Endpoint. Its
operation is defined by an Instance Configuration and a Context. An
Endpoint may execute several Instances. Each Instance operates
independently, with its own Context and Instance Configuration.
Instances may execute dynamic Context update mechanisms and
performance monitoring and reporting in complex scenarios.
5.2.1.1. Instance Configuration
The Instance Configuration specifies the local parameters of the
Instance.
The Instance Configuration may indicate in a Manifest the set of
required SCHC functionalities, such as:
* Header Compression and Decompression (C/D)
* Fragmentation and Reassembly (F/R)
* SCHClets (modular subfunctions)
The Instance Configuration may also include the following parameters:
* Role of the Instance (e.g., App or Dev for asymmetric Rules) to
determine which direction the rule applies to (Up, Dw, Bi).
* Matching policy (e.g., first-match, best-match, etc.) to apply
when multiple rules match a packet.
* Packet interception criteria (e.g., Stratum - the protocol headers
that the SCHC Rules in the associated Context can address, Filters
based on specific values or characteristics of packets, etc.)
* Dispatch information (e.g., how to identify the Instance for
incoming packets, how to route packets to the appropriate
Instance, etc.).
The Role of an Instance may depend on the topology of the deployment.
For example, in star-oriented deployments, the hub and the spokes may
derive their respective roles from the network configuration (e.g.,
the hub acts as the App and the spokes as the Dev, or vice versa);
SCHC then does not need to signal which end plays which role, and the
assignment can be stated in the associated Profile. In other
topologies, such as a mesh, an Instance may play a different role
towards each of its peers; for example, in a 6LoWPAN mesh, the roles
Pelov, et al. Expires 7 May 2027 [Page 11]
Internet-Draft SCHC Architecture November 2026
are provisioned for each pair of peer nodes, and with Pointer-based
Route-Over the destination node takes the role of the Dev
[I-D.ietf-6lo-schc-15dot4]. On a point-to-point link between two
peers, the role can be fixed when the link is set up; for example,
over PPP, the peer that initiates the PPP session plays the role of
the Dev [I-D.ietf-schc-over-ppp]. In all cases, the Instances of a
Session need to know their role (App or Dev) towards each other
before they communicate. A Profile, or a document that specifies a
deployment, MUST assign the roles so that they are complementary:
every SCHC Data Unit emitted by an App is processed only by Dev
Instances, and every SCHC Data Unit emitted by a Dev is processed
only by App Instances.
5.2.1.2. Context
The Context contains operational information shared between two or
more Instances.
For example, for Header Compression and Decompression (C/D) or
Fragmentation and Reassembly (F/R), the Context defines the set of C/
D and F/R Rules - or Set of Rules - describing the specific actions
to be performed on the packets using the corresponding SCHC
functionalities, and, optionally, the Parser and the Data Model to
delineate and dissect the header fields.
5.2.2. Endpoint
An Endpoint is a logical entity that hosts one or more Instances and
the components that manage them together, such as the Instance
Manager and the Dispatcher. The SCHC operations themselves are
performed by the Instances.
5.2.2.1. Header Compression and Decompression (C/D)
This component is responsible for compressing and decompressing
headers using the SCHC framework, as described in [RFC8724]. It
applies the rules defined in the Context.
Internally, on compression, the C/D engine:
* delineates the fields using the Parser and/or Data Model provided
in the Context;
* chooses the appropriate compression Rule among candidate Rules
from the Context based on the matching policy defined in the
Instance Configuration;
* applies the compression Rule to the fields of the header(s);
Pelov, et al. Expires 7 May 2027 [Page 12]
Internet-Draft SCHC Architecture November 2026
* generates the compressed SCHC Data Unit. In [RFC8724], a packet
whose header has been compressed is called a SCHC Packet.
On decompression, the C/D engine:
* identifies the appropriate decompression Rule based on the RuleID
stored in the SCHC Packet;
* applies the decompression Rule to reconstruct the original header;
* reconstructs and returns the original packet from the decompressed
header and payload.
5.2.2.2. Fragmentation and Reassembly (F/R)
This component is responsible for fragmenting larger packets into
smaller fragments and reassembling them at the receiving end. It is
an optional feature but recommended for scenarios where packet sizes
may exceed the maximum transmission unit (MTU) of the underlying
network. In [RFC8724], the pieces of a SCHC Packet that has been
fragmented are called SCHC Fragments.
[RFC8724] defines three reliability modes for fragmentation: No-ACK,
ACK-Always, and ACK-on-Error. The choice of mode and of its
parameters depends on the characteristics of the underlying
technology and is typically fixed by the deployment or by a
technology-specific Profile. [RFC9441] defines a Compound ACK format
and procedure that can be used with applicable fragmentation modes,
including ACK-on-Error.
5.2.2.3. SCHClets
A SCHClet is a self-contained unit within the SCHC framework that
implements a specific SCHC function or a subset of SCHC operations.
A SCHClet may implement aspects defined in [RFC8724] or functions
from other related SCHC RFCs, and may be combined with other SCHClets
within an Instance, as specified in the Manifest in the Instance
Configuration. SCHClets are specified in [DRAFT-SCHCLET].
5.2.2.4. Multiple Instances
An Endpoint can host multiple Instances, each with its own Context
and Instance Configuration.
When an Endpoint is supporting multiple Instances, the Instance
Manager is responsible for managing the lifecycle and configuration
of these Instances. SCHC Data Units are routed to the appropriate
Instance by the Dispatcher using the Discriminator and admission
Pelov, et al. Expires 7 May 2027 [Page 13]
Internet-Draft SCHC Architecture November 2026
criteria based on information provided in the Instance Configuration.
The Dispatcher is a single point of decision for packet forwarding
within the Endpoint.
The Dispatcher runs ahead of the selection of an Instance. At the
moment it makes its decision, no Context has been selected, no
Session has been identified, and no SCHC state is available for the
packet at hand: those are consequences of the decision, not inputs to
it. The Dispatcher therefore does not require SCHC Rules, a Context,
or per-Session SCHC state to operate. It uses the Discriminator to
route the SCHC Data Units to the correct Instance; the Discriminator
therefore has to be locatable and interpretable without knowledge of
the SCHC Static Contexts. A design in which the Dispatcher would
have to consult SCHC Rules or state to find the Instance that owns
those very Rules and that state cannot be resolved, and is outside
this architecture.
In some deployments, the Discriminator is derived entirely from
lower-layer context (e.g., a specific PPP link, an IPv6 address, or a
UDP port). If external context is insufficient or unavailable, the
Dispatcher may need an explicit Discriminator. The explicit
Discriminator, for example a Session Identifier, is then carried in a
Control Header placed before the RuleID (Section 5.2.5.1), which can
also provide additional services, such as integrity checking (CRC).
Such a Control Header can be, for example, the header of a light
transport protocol in which the SCHC Data Units are encapsulated, or
a structure that is itself compressed with SCHC, as in
[I-D.ietf-6lo-schc-15dot4].
The following figure illustrates the main components of an Endpoint
supporting multiple Instances and the interaction between the Network
Stack, the Dispatcher, and the Instances.
Pelov, et al. Expires 7 May 2027 [Page 14]
Internet-Draft SCHC Architecture November 2026
+-------------------+ +----------------+
| Instance Manager | | SCHC Functions |
+-------------------+ +----------------+
manages lifecycle | | ^
of Instances, | | | compresses,
retrieve Contexts | +--------------------+ | decompresses,
and Configs | | | etc.
v v v
+-------------+ +-------------+
+->| Instance I1 | ... | Instance Ik |<--------+
| +-------------+ +-------------+ |
| | | | | |
| | | +------------+ | | +------------+ |
| | +--| Context C1 | ... | +--| Context Ck | |
| | +------------+ | +------------+ |
| | +------------+ | +------------+ |
| +----| Config G1 | ... +----| Config Gk | |
| +------------+ +------------+ |
| | | |
| is applied | | is applied |
| to | +-------------+ | to |
| +---->| |<----+ |
+------------------->| Dispatcher |<------------------+
dispatch packets | | dispatch packets
+-------------+
^ |
admit | | reinject
| v
+---------------+
| Network stack |
+---------------+
Figure 3: Overview of an Endpoint hosting multiple Instances
5.2.3. Session
As illustrated in the figure below, the Session is a communication
session between two or more Instances that share a common Context,
i.e. they are part of the same Domain.
Pelov, et al. Expires 7 May 2027 [Page 15]
Internet-Draft SCHC Architecture November 2026
Endpoint A Endpoint B
+--------------+ +--------------+
| Instance | <---- ----> | Instance |
+--------------+ \ / +--------------+
\ /
Session
/ \
+--------------+ / \ +--------------+
| Instance | <---- ----> | Instance |
+--------------+ +--------------+
Endpoint C Endpoint D
Figure 4: Session between multiple Instances
5.2.4. Domain
In the figure below, two Domains are represented, where Endpoint A
and Endpoint B host Instances belonging to Domain 1, and Endpoint B
and Endpoint C host Instances belonging to Domain 2. Instances from
the same Domain communicate through a Session. A Session Identifier,
or Session ID, may be used as a Discriminator to route the SCHC Data
Units to the correct Instance (e.g., to distinguish between the two
Instances of Endpoint B), and/or for management purpose.
+------------------------------+ +------------------------------+
| Domain Manager 1 | | Domain Manager 2 |
+------------------------------+ +------------------------------+
^ ^ ^ ^
| | | |
v v v v
+----------------+ +-------------------+ +---------------+
| Endpoint A | | Endpoint B | | Endpoint C |
+-----------------------------------------------+ | |
| | +-----------+ | | +-----------+ | | | |
| | | Instance |<----------->| Instance | | | | |
| | +-----------+ | | +-----------+ | | | |
+--------------------|--------------------------+ | |
| | | +----------------------------------------------+
| | | | | +-----------+ | | +-----------+ | |
| | | | | | Instance |<---------->| Instance | | |
| | | | | +-----------+ | | +-----------+ | |
| | | +-------------------------|--------------------+
| | | | | | | |
+----------------+ | +-------------------+ | +---------------+
| |
| |
+---> Domain 1 +-> Domain 2
Pelov, et al. Expires 7 May 2027 [Page 16]
Internet-Draft SCHC Architecture November 2026
Figure 5: Overview of multiple Domains
5.2.5. SCHC Data Unit Format
A SCHC Data Unit is the unit exchanged between SCHC Instances.
It provides a unified representation for:
* compressed packets;
* SCHC F/R messages of Section 8.2.1 of [RFC8724]: SCHC Fragment,
SCHC ACK, SCHC ACK REQ, SCHC Sender-Abort, and SCHC Receiver-
Abort.
A SCHC Data Unit begins with a RuleID, and the result of the SCHC
operation follows the RuleID immediately. The interpretation of that
result depends on the Rule that the RuleID identifies, so nothing
that a receiver has to parse independently of the Context can be
placed between the two.
A SCHC Data Unit is composed of a SCHC Header and a SCHC Payload.
The SCHC Header is the RuleID followed by the result of the SCHC
operation, such as a Compression Residue or the fragmentation fields;
it never includes the Control Header. The SCHC Payload is the part
that follows the SCHC Header and that the SCHC operation carries
unmodified: the payload of the original packet for a SCHC Packet, or
the Fragment Payload for a SCHC Fragment. The result of the SCHC
operation and the SCHC Payload may be empty.
As stated in [RFC8724], a SCHC Data Unit resulting from a compression
operation is called a SCHC Packet, and a SCHC Data Unit resulting
from a fragmentation operation is called a SCHC Fragment. When a
Control Header (Section 5.2.5.1) precedes the SCHC Data Unit, the
whole is a SCHC Extended Data Unit.
The following figure illustrates the general SCHC Data Unit format
and the SCHC Header format of SCHC Packets and SCHC Fragments.
Pelov, et al. Expires 7 May 2027 [Page 17]
Internet-Draft SCHC Architecture November 2026
|<------------ SCHC Data Unit ------------>|
| | |
|<--- SCHC Header --->| |
| | |
+----------------+--------+------------+--------------------+
| Control Header | RuleID | SCHC | SCHC Payload |
| (optional) | | operation | (may be empty) |
| | | result | |
+----------------+--------+------------+--------------------+
SCHC Header, compression case (Compressed Header, RFC 8724 5.1):
+--------+---------------------+
| RuleID | Compression Residue | SCHC Payload = payload of the
+--------+---------------------+ original packet
SCHC Header, fragmentation case (Fragment Header, RFC 8724 8.3.1):
+--------+-----------------------+
| RuleID | DTag | W | FCN | RCS | SCHC Payload = Fragment
+--------+-----------------------+ Payload (tiles)
Figure 6: SCHC Data Unit, SCHC Header, and SCHC Payload
5.2.5.1. Control Header
In some deployments, information has to be carried alongside a SCHC
Data Unit, for example so that it can be routed to the correct
Instance. This information may be carried in a Control Header, which
precedes the SCHC Data Unit and is not part of it. An Instance that
is handed a SCHC Data Unit is unaffected by a Control Header which
was removed before the SCHC Data Unit reached it, typically by the
Dispatcher. The requirements of this section therefore apply to the
specifications that define a Control Header, and place no new
requirement on implementations of [RFC8724].
This document describes the Control Header as an architectural slot:
where it sits with respect to the SCHC Data Unit, and what a
specification that fills the slot has to provide. It does not define
a Control Header format, and it does not mandate or endorse any
particular one. The architecture admits more than one: different
specifications may define different Control Headers for different
environments or deployments. Deployments that need no Control Header
carry none, and that remains the common case. A Control Header, when
present, precedes the RuleID, as represented in Figure 6.
This position follows from the purpose of the Control Header rather
than from convention. A Control Header exists so that a node can act
on a SCHC Data Unit before the Instance, and hence the Context, has
been selected; that is the reason for carrying the information
Pelov, et al. Expires 7 May 2027 [Page 18]
Internet-Draft SCHC Architecture November 2026
outside the SCHC operation at all. A Control Header placed after the
RuleID could be delineated only by a node that already holds the
Context, which is precisely the node that does not need the Control
Header. A specification that defines a Control Header for use with
SCHC therefore MUST place it before the RuleID, and MUST NOT insert
any element between the RuleID and the result of the SCHC operation.
The format of a Control Header must be clearly defined in a
specification, for example a Profile such as
[I-D.ietf-6lo-schc-15dot4] or a dedicated Control Header
specification.
A Control Header may itself be compressed with SCHC using its own
Context and Instance, as illustrated in Section 4.1.2 of
[I-D.ietf-6lo-schc-15dot4].
6. Deployment models
In this section, we review the deployment scenarios considered in the
SCHC Working Group and match the terminology with the scenario
characteristics. A point-to-point PPP deployment example appears in
Appendix A.
6.1. LPWAN deployment
This section considers a typical LPWAN deployment where an IoT device
communicates with a gateway or server using SCHC for header
compression and decompression. In this scenario, SCHC compresses the
CoAP, UDP, and IPv6 headers, and the resulting SCHC Data Units are
carried over the LPWAN link layer. SCHC acts as an adaptation layer
between IPv6 and the LPWAN link layer, reducing header overhead to
accommodate the link's constraints.
In this setup, each device features a single SCHC Instance I1 in a
single SCHC Endpoint. Each Instance is pre-configured with a static
Context. The parameters that a given LPWAN technology fixes for SCHC
form a Profile in the sense of Section 4 of [RFC8724]. SCHC over
LoRaWAN [RFC9011], SCHC over NB-IoT [RFC9391], and SCHC over Sigfox
[RFC9442] each define such a Profile.
The Discriminator is a field value within the LPWAN link layer, e.g.,
the LoRaWAN [RFC9011] frame port (fPort), and the Dispatcher is
hardcoded in the network stack: all traffic with pre-defined fPort or
device ID are dispatched to the SCHC Instance.
Pelov, et al. Expires 7 May 2027 [Page 19]
Internet-Draft SCHC Architecture November 2026
Host A, IoT Device Host B, Gateway/Server
+------------------+ +------------------+
| Application A | | Application B |
+- +------------------+ +------------------+
| | CoAP | | CoAP |
| +------------------+ +------------------+
I1 Stratum | | UDP | | UDP |
| +------------------+ +------------------+
| | IPv6 | | IPv6 |
+- +------------------+ +------------------+
| SCHC | | SCHC |
+------------------+ +------------------+
Discriminator: | LPWAN Link Layer | | LPWAN Link Layer |
fPort = xxx +------------------+ +------------------+
| Physical Layer | | Physical Layer |
+------------------+ +------------------+
| |
+---------------------------+
Figure 7: LPWAN deployment
6.2. 6Lo deployments
In a first deployment example, a 6Lo Node (6LN) in a SCHC-Lo network
communicates with an external host on the Internet.
In this scenario, the 6LN is in direct communication with the 6Lo
Border Router (6LBR). SCHC Data Units are only carried over the
SCHC-Lo network, between the 6LN and the 6LBR. The CoAP header and
payload are sent in clear (no encryption), and we assume that the
SCHC Data Unit is small enough to fit in a single 802.15.4 frame.
6LN 6LBR External host
+- +--------+ +--------+
| | CoAP | | CoAP |
| +--------+ +--------+
I1 stratum | | UDP | | UDP |
| +--------+ +----------------+ +--------+
| | IPv6 | | IPv6 | | IPv6 |
+- +--------+ +----------------+ +--------+
Discriminator: | 6lo | | 6lo | . . .
6Lo Dispatch +--------+ +--------+ . . .
0b01000100 |802.15.4| |802.15.4| . . .
+--------+ +----------------+ ..........
| | | |
+---------------+ +---------------+
SCHC-Lo network Internet
Pelov, et al. Expires 7 May 2027 [Page 20]
Internet-Draft SCHC Architecture November 2026
Figure 8: 6Lo deployment: 6Lo Node connected to an external host
through a 6Lo Border Router
In this scenario, the 6LN endpoint features a single Instance I1 that
compresses the IPv6, UDP and CoAP stratum. The Discriminator for the
SCHC instance is located at the 6Lo adaptation and is materialized by
the dispatch byte.
A datagram compressed by SCHC results in the following frame format:
+- - - - - -+------------------------+--------------+
| | 01000100 | Rule ID | Residue |
+- - - - - -+------------------------+--------------+
802.15.4 | 6Lo Dispatch | SCHC Data Unit |
header | (1 byte) | |
Figure 9: SCHC-Lo Data Unit
7. Operational considerations
7.1. Role of an Instance in a SCHC communication
SCHC Rules include a Direction Indicator (DI) that allows for
asymmetric processing using the same Rule (e.g., to compress in one
rule a request and the corresponding acknowledgment). Three values
are possible:
* Up: for packets traveling Uplink;
* Dw: for packets traveling Downlink;
* Bi: for both Uplink and Downlink packets.
The direction is determined by the App or Dev role assigned to the
Instance for the Session, as specified by the applicable Profile or
deployment document (see Instance Configuration).
In [RFC8724], two roles were defined: App and Dev, which refer to the
LPWAN server and the devices, respectively. By convention, packets
from App to Dev are Downlink, and packets from Dev to App are Uplink.
7.2. Context consistency
In Section 5, we have established that a Session is a communication
session between two or more Instances that share a common Context.
For a packet to be properly decompressed, the receiver must know the
rule that the sender used to compress the packet headers.
Pelov, et al. Expires 7 May 2027 [Page 21]
Internet-Draft SCHC Architecture November 2026
To facilitate the provisioning and synchronization of Contexts within
a Domain for a given Session, it is recommended to deploy the same
Context (with identical SoR) on all Instances participating in a
given Session. However, it is possible for one or more Instances to
have only a subset of the SoR, as long as the Contexts of the
Instances participating in a given session remain compatible.
In the following example of a deployment using a star topology where
leaf nodes only communicate with the root, rather than creating a
separate Instance for each link, or storing the entire SoR on each
node, leaf nodes only store the rules necessary for their
communication with the root. It should be noted that there may be a
risk that the root uses a rule that is unknown to the recipient,
leading to an error.
+--------------+
| Root |
| +----------+ |
| | Rule 1 | |
| | Rule 2 | |
| | Rule 3 | |
| +----------+ |
+------|-------+
|
+----------------|-----------------+
| | |
+-------|------+ +------|-------+ +------|-------+
| Node A | | Node B | | Node C |
| +----------+ | | +----------+ | | +----------+ |
| | Rule 1 | | | | Rule 2 | | | | Rule 3 | |
| +----------+ | | +----------+ | | +----------+ |
+--------------+ +--------------+ +--------------+
Figure 10: Example of compatible partial Contexts
7.3. Data Models and Parsing
Having the same Context is not sufficient to guarantee the
interoperability of SCHC operations between two Instances. The
format of the data obtained from the Parser when processing the
headers must be consistent on each Endpoint to allow the successful
decompression. To ensure interoperability, the Context may specify
which Parser to use to delineate the header fields, and/or which Data
Model, such as the one defined in [RFC9363].
Pelov, et al. Expires 7 May 2027 [Page 22]
Internet-Draft SCHC Architecture November 2026
7.4. Management
7.4.1. Context Provisioning
A SCHC Context needs to be provisioned at, or made available to, the
SCHC Instances that use it. [RFC8724] does not define a negotiation
protocol for establishing and synchronizing the Context. The Context
can be configured and stored before the communication begins. It can
be pre-provisioned, or installed by a provisioning protocol. Any
protocol used to provision SCHC Contexts needs to ensure that the
communicating SCHC Instances use compatible configuration when
processing SCHC Data Units.
7.5. Error handling
When an Instance receives a SCHC Data Unit that references a RuleID
unknown in its Context, or when decompression or reassembly fails,
the resulting behavior is deployment-specific: the SCHC Data Unit may
be silently discarded, logged, or reported to the Instance Manager.
This document does not define an architectural mechanism to signal
such errors between Instances or to trigger the resynchronization of
Contexts through the Domain Manager.
A deployment may define a separate error-signaling protocol or carry
error information in a Control Header. If a Control Header is used
for this purpose, its presence and format must remain determinable
when the Rule referenced by the failed SCHC Data Unit is unknown or
cannot be applied. This document does not define the error messages
or procedures.
8. Security Considerations
SCHC operation is sensitive to the integrity of the Contexts.
Corrupted or tampered Rules could be abused to form arbitrarily long
messages or as a form of attack against the C/D and/or F/R functions,
e.g., to generate a buffer overflow and either modify the behavior of
an Endpoint or crash it. It is thus critical that Contexts be
distributed in a fashion that is protected against tampering, e.g.,
encrypted and signed. The entities that manage Contexts and Instance
Configurations, such as the Domain Manager and the Instance Manager,
must be authenticated and authorized; [I-D.ietf-schc-access-control]
defines an access control model for SCHC Rules.
A more complete analysis of the risks specific to the SCHC
architecture is to be provided in a future revision.
Pelov, et al. Expires 7 May 2027 [Page 23]
Internet-Draft SCHC Architecture November 2026
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/rfc/rfc8724>.
10.2. Informative References
[DRAFT-SCHCLET]
Pelov, A., Lampin, Q., and M. Dumay, "SCHClet - Modular
Use of the SCHC Framework", Work in Progress, Internet-
Draft, draft-ietf-schc-schclet-01, 29 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-schc-
schclet-01>.
[I-D.ietf-6lo-schc-15dot4]
Gomez, C. and A. Minaburo, "Transmission of SCHC-
compressed packets over IEEE 802.15.4 networks", Work in
Progress, Internet-Draft, draft-ietf-6lo-schc-15dot4-14,
31 October 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-6lo-schc-15dot4-14>.
[I-D.ietf-intarea-schc-protocol-numbers]
Moskowitz, R., Card, S. W., Wiethuechter, A., and P.
Thubert, "Protocol Numbers for SCHC", Work in Progress,
Internet-Draft, draft-ietf-intarea-schc-protocol-numbers-
02, 8 April 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-intarea-schc-protocol-numbers-02>.
Pelov, et al. Expires 7 May 2027 [Page 24]
Internet-Draft SCHC Architecture November 2026
[I-D.ietf-schc-access-control]
Minaburo, A., Toutain, L., and I. Martinez, "SCHC Access
Control", Work in Progress, Internet-Draft, draft-ietf-
schc-access-control-01, 29 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-schc-
access-control-01>.
[I-D.ietf-schc-over-ppp]
Thubert, P., "SCHC over PPP", Work in Progress, Internet-
Draft, draft-ietf-schc-over-ppp-00, 25 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-schc-
over-ppp-00>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/rfc/rfc8376>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/rfc/rfc8824>.
[RFC9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context
Header Compression and Fragmentation (SCHC) over LoRaWAN",
RFC 9011, DOI 10.17487/RFC9011, April 2021,
<https://www.rfc-editor.org/rfc/rfc9011>.
[RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static
Context Header Compression (SCHC)", RFC 9363,
DOI 10.17487/RFC9363, March 2023,
<https://www.rfc-editor.org/rfc/rfc9363>.
[RFC9391] Ramos, E. and A. Minaburo, "Static Context Header
Compression over Narrowband Internet of Things", RFC 9391,
DOI 10.17487/RFC9391, April 2023,
<https://www.rfc-editor.org/rfc/rfc9391>.
[RFC9441] Zuniga, J., Gomez, C., Aguilar, S., Toutain, L., Cespedes,
S., and D. Wistuba, "Static Context Header Compression
(SCHC) Compound Acknowledgement (ACK)", RFC 9441,
DOI 10.17487/RFC9441, July 2023,
<https://www.rfc-editor.org/rfc/rfc9441>.
Pelov, et al. Expires 7 May 2027 [Page 25]
Internet-Draft SCHC Architecture November 2026
[RFC9442] Zuniga, J., Gomez, C., Aguilar, S., Toutain, L., Cespedes,
S., Wistuba, D., and J. Boite, "Static Context Header
Compression (SCHC) over Sigfox Low-Power Wide Area Network
(LPWAN)", RFC 9442, DOI 10.17487/RFC9442, July 2023,
<https://www.rfc-editor.org/rfc/rfc9442>.
Appendix A. PPP deployment
[I-D.ietf-schc-over-ppp] describes a type of deployment where the C/D
and/or F/R operations are performed between peers of equal
capabilities over a PPP connection. In this scenario, the protocols
that are compressed can be discovered dynamically, and the Context
can be fetched on demand, ensuring that the Instances use the exact
same Set of Rules.
+----------+ Wi-Fi / +----------+ ....
| IP | Ethernet | IP | .. )
| Host +-----/------+ Router +----------( Internet )
| SCHC C/D | Serial | SCHC C/D | ( )
+----------+ +----------+ ...
<-- SCHC -->
over PPP
Figure 11: PPP-based SCHC Deployment
Each Endpoint associates one Instance with each PPP connection: the
Discriminator is derived entirely from the connection itself, and all
the traffic of that Instance, and only that traffic, is exchanged
within the PPP connection. The peer that initiates the PPP session
plays the role of the Dev [I-D.ietf-schc-over-ppp].
+===============+======================+
| Core Element | Notes |
+===============+======================+
| Domain | single |
+---------------+----------------------+
| Endpoint | 1 per peer |
+---------------+----------------------+
| Instance | 1 per PPP connection |
+---------------+----------------------+
| Context | fetched on demand |
+---------------+----------------------+
| Discriminator | PPP connection |
+---------------+----------------------+
| Dispatcher | PPP demultiplexing |
+---------------+----------------------+
Table 1
Pelov, et al. Expires 7 May 2027 [Page 26]
Internet-Draft SCHC Architecture November 2026
Acknowledgments
The authors would like to thank (in alphabetic order): Carles Gomez,
Carsten Bormann, Edgar Ramos, Eric Vyncke, Javier Alejandro
Fernandez, Laurent Toutain, Marco Tiloca, Rodrigo Munoz, and Sandra
Cespedes, as well as all participants of the SCHC Working Group.
Authors' Addresses
Alexander Pelov
IMT Atlantique
rue de la Chataigneraie
35576 Cesson-Sevigne Cedex
France
Email: alexander.pelov@imt-atlantique.fr
Pascal Thubert
06330 Roquefort les Pins
France
Email: pascal.thubert@gmail.com
Ana Minaburo
Consultant
35510 Cesson-Sevigne Cedex
France
Email: anaminaburo@gmail.com
Quentin Lampin
Orange
Orange 3 Massifs - 22 Chemin du Vieux Chene
38240 Meylan
France
Email: quentin.lampin@orange.com
Marion Dumay
Orange
Orange 3 Massifs - 22 Chemin du Vieux Chene
38240 Meylan
France
Email: marion.dumay@orange.com
Pelov, et al. Expires 7 May 2027 [Page 27]