SCHC Working Group A. Pelov
Internet-Draft IMT Atlantique
Intended status: Informational P. Thubert
Expires: 7 January 2027
A. Minaburo
Consultant
Q. Lampin
M. Dumay
Orange
6 July 2026
Static Context Header Compression (SCHC) Architecture
draft-ietf-schc-architecture-06
Abstract
The Static Context Header Compression and fragmentation (SCHC)
framework provides both a header compression mechanism and an
optional fragmentation mechanism. This document defines a minimal
architecture for SCHC deployments, providing guidance for
implementers and operators on the essential components and their
interactions required for effective SCHC operation.
The architecture defines the components of a SCHC deployment -
Endpoints, Instances, Contexts, Sessions, and Domains - their
management, the framing of SCHC Datagrams, and considerations for
technology-specific profiles.
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 January 2027.
Pelov, et al. Expires 7 January 2027 [Page 1]
Internet-Draft SCHC Architecture July 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overview of a Basic Architecture . . . . . . . . . . . . 6
4.1.1. SCHC: Quick Reminders . . . . . . . . . . . . . . . . 6
4.1.2. Basic SCHC Architecture . . . . . . . . . . . . . . . 6
4.2. Focus on core components . . . . . . . . . . . . . . . . 9
4.2.1. Instance . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Session . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.4. Domain . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.5. Datagram Format . . . . . . . . . . . . . . . . . . . 15
5. Deployment Profiles . . . . . . . . . . . . . . . . . . . . . 16
6. Operational considerations . . . . . . . . . . . . . . . . . 16
6.1. Error handling . . . . . . . . . . . . . . . . . . . . . 17
6.2. Context consistency . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Examples - To Be Validated . . . . . . . . . . . . . 20
A.1. Control Header Examples . . . . . . . . . . . . . . . . . 20
A.2. Deployment Models . . . . . . . . . . . . . . . . . . . . 21
A.2.1. LPWAN deployment . . . . . . . . . . . . . . . . . . 21
A.2.2. PPP deployment . . . . . . . . . . . . . . . . . . . 25
A.2.3. Direct transport over Ethernet, IPv6, and UDP . . . . 26
A.3. Compatible Partial Contexts . . . . . . . . . . . . . . . 27
Appendix B. Future Work - To Be Decided by the Working Group . . 28
B.1. C/D Engine Interface . . . . . . . . . . . . . . . . . . 28
B.2. Other Open Items . . . . . . . . . . . . . . . . . . . . 28
Pelov, et al. Expires 7 January 2027 [Page 2]
Internet-Draft SCHC Architecture July 2026
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 header compression and fragmentation, based on a static context
that is pre-installed on the SCHC endpoints.
While SCHC was designed to address the severe constraints of LPWAN
technologies, the framework itself is generic: 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.
This document details the constitutive elements of a SCHC-based
solution and how the solution can be deployed. It provides a general
architecture for SCHC deployments, describing the essential
components and their interactions, the possible deployment types, and
the models whereby Contexts can be distributed and installed to
enable reliable and scalable operations.
SCHC as defined in [RFC8724] assumes that the Context is static and
provisioned before use, and that no negotiation takes place between
the compressing and decompressing entities. These assumptions remain
the foundation of this architecture. Other assumptions inherited
from the LPWAN environment - severely constrained devices and links,
intermittent connectivity, star topologies - are relaxed in richer
environments, where Contexts may be fetched on demand, multiple
Instances may coexist on an Endpoint, and topologies may be
arbitrary.
This document does not replace or update [RFC8724]: the SCHC
compression and fragmentation mechanisms are used as defined there.
This document does not define new wire formats -- the formats shown
in the figures are illustrative -- and does not specify a new
protocol; where a new protocol or format appears necessary, it is
identified as future work (Appendix B).
Pelov, et al. Expires 7 January 2027 [Page 3]
Internet-Draft SCHC Architecture July 2026
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.
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.
SCHC: A Generic Framework, as defined in [RFC8724], that performs
compression/decompression of protocol headers and, optionally,
fragmentation/reassembly of SCHC Packets, based on a Static
Context shared between two or more Instances. 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 Instance Configuration.
Rule: A structured description, identified by a RuleID, of how SCHC
processes a packet or a SCHC message. Depending on its type, a
Rule defines C/D field descriptors, F/R mode and parameters, or
no-compression behavior.
Set of Rules (SoR): The collection of C/D, F/R, and no-compression
Rules available to an Instance.
Context: A SoR together with metadata, shared by two or more
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
Pelov, et al. Expires 7 January 2027 [Page 4]
Internet-Draft SCHC Architecture July 2026
Instance that define how SCHC operations are performed, e.g. role
of the Instance, matching policy, dispatcher configuration,
supported SCHC features.
SCHClet: A self-contained modular unit within the SCHC framework
that implements a specific SCHC function or a subset of SCHC
operations; see [DRAFT-SCHCLET].
Session: A communication session between two or more Instances that
share a common Context for SCHC operations.
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.
Dispatcher: A logical component of the Endpoint that routes packets
to the appropriate Instances based on defined admission rules. It
can be integrated into the network stack or implemented as a
separate component.
Discriminator: An optional information element used by the
Dispatcher to route SCHC Datagrams to the appropriate Instance.
The discriminator can be a combination of several criteria.
Parser: A software tool or component that dissects and analyzes
network packets, to extract meaningful information such as source
and destination addresses, port numbers, and payload data.
Domain: A logical grouping of Instances that share a common set of
Contexts for SCHC operations.
Stratum: A background concept that identifies a portion of the
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.
Datagram: The unit exchanged between SCHC Instances. A Datagram
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 Payload.
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
Pelov, et al. Expires 7 January 2027 [Page 5]
Internet-Draft SCHC Architecture July 2026
configuration of Instances within an Endpoint. It is responsible
for creating, updating, and deleting Instances as needed,
synchronizing Contexts, and managing Instance Configurations.
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.
MO: Matching Operator, as defined in [RFC8724].
CDA: Compression/Decompression Action, as defined in [RFC8724].
4. Architecture
4.1. Overview of a Basic Architecture
4.1.1. SCHC: Quick Reminders
SCHC is a framework designed to efficiently compress headers of
network packets. It reduces payload 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 Datagram. The receiver of
this SCHC Datagram matches the RuleID against its own Context and
applies decompression actions to reconstruct the original header.
4.1.2. 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.
Pelov, et al. Expires 7 January 2027 [Page 6]
Internet-Draft SCHC Architecture July 2026
Each host runs an Endpoint that implements SCHC functions that are
executed by an Instance. 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.
Important notice: 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].
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.
Identifiers for Instances, Contexts, and Sessions are unique within
the scope of their Domain.
Pelov, et al. Expires 7 January 2027 [Page 7]
Internet-Draft SCHC Architecture July 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 Datagrams exchanged inside a Session
Figure 1: Overview of two simple Endpoints exchanging SCHC Datagrams
Pelov, et al. Expires 7 January 2027 [Page 8]
Internet-Draft SCHC Architecture July 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 the functions of the Domain Manager
4.2. Focus on core components
Pelov, et al. Expires 7 January 2027 [Page 9]
Internet-Draft SCHC Architecture July 2026
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.
4.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., Upside or Downside for asymmetric
Rules).
* 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 is typically derived from extrinsic
properties. In star-oriented deployments, the hub and the spokes
derive their respective roles from the network configuration, and
SCHC does not need to signal which end plays which role. When
Instances of equivalent capabilities communicate in a peer-to-peer
fashion, the role cannot be inferred from the topology; in that case,
by convention, the Instance that initiates the connection plays the
role of the Device in [RFC8724]. This convention can be reversed,
Pelov, et al. Expires 7 January 2027 [Page 10]
Internet-Draft SCHC Architecture July 2026
e.g., by configuration, but proper SCHC operation requires that the
method used ensures that all Instances of a Session are aware of
their role.
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.
A logical entity providing SCHC functionalities, and hosting the
Instances that consist of a specific execution of one or more of
these aforementioned functionalities.
4.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);
* generates the compressed SCHC Datagram. 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;
Pelov, et al. Expires 7 January 2027 [Page 11]
Internet-Draft SCHC Architecture July 2026
* reconstructs and returns the original packet from the decompressed
header and payload.
4.2.2.2. Fragmentation and Reassembly (F/R)
This component is responsible for fragmenting SCHC Packets into SCHC
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.
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 Instance Configuration.
4.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. Datagrams are routed to the appropriate Instance
by the Dispatcher using the Discriminator and admission rules based
on information provided in the Instance Configuration. The
Dispatcher is a single point of decision for packet forwarding within
the Endpoint.
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. For example,
Datagrams can be encapsulated in a light transport protocol whose
header contains a Session, Context, or Instance identifier, and can
provide additional services such as integrity checking (CRC).
Pelov, et al. Expires 7 January 2027 [Page 12]
Internet-Draft SCHC Architecture July 2026
The following figure illustrates the main components of an Endpoint
supporting multiple Instances and their interactions:
+-------------------+ +----------------+
| 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
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.
A Domain may support multiple simultaneous Sessions; a Session is one
specific communication among a subset of the Instances of the Domain.
The Domain defines which Instances share Contexts, while the Session
identifies which Instances are actually communicating.
Pelov, et al. Expires 7 January 2027 [Page 13]
Internet-Draft SCHC Architecture July 2026
Endpoint A Endpoint B
+--------------+ +--------------+
| Instance | <---- ----> | Instance |
+--------------+ \ / +--------------+
\ /
Session
/ \
+--------------+ / \ +--------------+
| Instance | <---- ----> | Instance |
+--------------+ +--------------+
Endpoint C Endpoint D
Figure 4: Session between multiple Instances
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 Datagrams
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 January 2027 [Page 14]
Internet-Draft SCHC Architecture July 2026
Figure 5: Overview of multiple Domains
4.2.5. Datagram Format
A Datagram is the unit exchanged between SCHC Instances.
A Datagram starts with a RuleID. The Rule identified by that RuleID
determines the format and interpretation of the remaining bits. A
Datagram may be an unfragmented SCHC Packet or a SCHC F/R message,
such as a SCHC Fragment, SCHC ACK, SCHC ACK Request, SCHC Sender-
Abort, or SCHC Receiver-Abort.
+--------+------------------------------------+
| RuleID | Rule-dependent fields and payload |
+--------+------------------------------------+
Figure 6: Datagram Format
4.2.5.1. Control Header for Advanced Use Cases
In some deployments, it may be necessary to add information to the
Datagram, for example so that it can be properly routed to the
correct Instance. This information may be carried in a Control
Header.
The placement of the Control Header must be explicitly defined. For
example, it may be placed after the RuleID:
+--------+----------------+------------------------------------+
| RuleID | Control Header | Rule-dependent fields and payload |
+--------+----------------+------------------------------------+
Figure 7: Control Header placed after the RuleID
or before the RuleID:
+----------------+--------+------------------------------------+
| Control Header | RuleID | Rule-dependent fields and payload |
+----------------+--------+------------------------------------+
Figure 8: Control Header placed before the RuleID
The presence, placement, and format of the Control Header must be
clearly identified, e.g., by a SCHC profile or other specification
that defines the framing used by the deployment.
Pelov, et al. Expires 7 January 2027 [Page 15]
Internet-Draft SCHC Architecture July 2026
The information needed to locate and decode the Control Header must
be known before that information is used. For example, a profile may
define a fixed RuleID size and specify that RuleID values in a
particular range are followed by a Control Header having a known
format. Those framing semantics are independent of the C/D or F/R
Rule selected by the RuleID. The Control Header can therefore remain
decodable when that Rule is unknown or cannot be applied.
If a Control Header is needed to select the Instance or Context, the
fields needed for that selection must be decodable before any
Context-dependent portion of the Datagram is interpreted.
The Control Header may itself be a SCHC-compressed structure
piggybacked on the Datagram, or an explicit protocol providing
services such as:
* Multiplexing (Session, Instance, Context Identifier)
* Protection (Integrity)
* Metadata (retain information that is lost when performing the SCHC
operation, e.g., save the initial value of the EtherType field
when it is changed to EtherType=SCHC)
When a Control Header is compressed with SCHC, the Rules needed to
decode it must be available before the header is decoded. Those
Rules cannot depend on information obtainable only from that Control
Header.
Illustrative Control Header formats are collected in Appendix A.1.
5. Deployment Profiles
The adaptation of SCHC to a specific technology may be specified in a
profile. Appendix D of [RFC8724] lists the parameters that a
technology-specific document must provide, and [RFC9011] is an
example of such a profile for LoRaWAN networks.
Deployment examples that have not yet been validated are collected in
Appendix A.2.
6. Operational considerations
Pelov, et al. Expires 7 January 2027 [Page 16]
Internet-Draft SCHC Architecture July 2026
6.1. Error handling
When an Instance receives a Datagram that references a RuleID unknown
in its Context, or when decompression or reassembly fails, the
resulting behavior is deployment-specific: the Datagram 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; this is identified as future
work (see Appendix B).
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 Datagram is unknown or cannot
be applied. For example, a profile can define a fixed RuleID size
and reserve a RuleID range for Datagrams followed by a known Control
Header format. This document does not define the error messages or
procedures.
6.2. Context consistency
In Section 4, 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.
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.
An illustration of compatible partial Contexts is provided in
Appendix A.3. That example has not yet been validated.
7. 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]
Pelov, et al. Expires 7 January 2027 [Page 17]
Internet-Draft SCHC Architecture July 2026
defines an access control model for SCHC Rules.
Beyond Context integrity, the synchronization of the SoR and SoV
between Instances is itself a sensitive process: an attacker able to
delay or desynchronize Context updates can cause packets to be
dropped or misrouted, resulting in a denial of service. Deployments
should log and audit changes to the Contexts, and should be able to
restore a previous, known-good Context when an update proves
incorrect.
A more complete analysis of the risks specific to the SCHC
architecture is to be provided in a future revision.
8. IANA Considerations
This document has no IANA actions.
9. References
9.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>.
9.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-00, 30 January 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-schc-
schclet-00>.
[I-D.ietf-6lo-schc-15dot4]
Gomez, C. and A. Minaburo, "Transmission of SCHC-
compressed packets over IEEE 802.15.4 networks", Work in
Pelov, et al. Expires 7 January 2027 [Page 18]
Internet-Draft SCHC Architecture July 2026
Progress, Internet-Draft, draft-ietf-6lo-schc-15dot4-13, 4
July 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-6lo-schc-15dot4-13>.
[I-D.ietf-core-comi]
Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
and C. Bormann, "CoAP Management Interface (CORECONF)",
Work in Progress, Internet-Draft, draft-ietf-core-comi-21,
2 March 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-comi-21>.
[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>.
[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-00, 13 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-schc-
access-control-00>.
[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>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[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>.
[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>.
Pelov, et al. Expires 7 January 2027 [Page 19]
Internet-Draft SCHC Architecture July 2026
[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>.
[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. Examples - To Be Validated
The examples in this appendix are illustrative. They have not yet
been validated by the SCHC Working Group and do not define protocol
behavior or interoperability requirements.
A.1. Control Header Examples
The examples in this section have not yet been validated.
A Datagram may be encapsulated in a transport structure that carries
control information outside the SCHC Datagram:
+-------------+-----+---------------+
| Instance ID | CRC | SCHC Datagram |
+-------------+-----+---------------+
Figure 9: SCHC Datagram encapsulated in a transport structure
The following example illustrates a Control Header that is itself
compressed with SCHC. In its uncompressed form, the Control Header
carries an Instance ID, a Protocol ID, and a CRC:
Pelov, et al. Expires 7 January 2027 [Page 20]
Internet-Draft SCHC Architecture July 2026
Uncompressed Control Header:
+-------------+-------------+-----+
| Instance ID | Protocol ID | CRC |
+-------------+-------------+-----+
Compressed Control Header:
+--------+---------------------+
| RuleID | Compression Residue |
+--------+---------------------+
Rule used to compress the Control Header:
+------------+--+---+--+-----+------+-----------+
| FID |FL|POS|DI| TV | MO | CDA |
+------------+--+---+--+-----+------+-----------+
| SCHC.insid |10| 1 |Bi|0x00 |MSB(7)| LSB |
| SCHC.proto | 8| 1 |Bi|value|equal | not-sent |
| SCHC.crc | 8| 1 |Bi| |ignore| value-sent|
+------------+--+---+--+-----+------+-----------+
Figure 10: Example of a compressed Control Header and its Rule
In this example, the Rule defines:
* an Instance ID of 10 bits, compressed by sending only its 3 least
significant bits (MO MSB(7), CDA LSB), used to identify the
Instance and the Context that apply to the Datagram;
* a Protocol ID of 8 bits, identifying the protocol stack that was
compressed; its value is known in the Rule and elided (CDA not-
sent);
* a CRC of 8 bits, always carried in the residue (CDA value-sent),
protecting the Control Header and the Datagram.
A.2. Deployment Models
The deployment models in this section have not yet been validated.
A.2.1. LPWAN deployment
Section 3 of [RFC8724] depicts a typical network architecture for an
LPWAN network, simplified from that shown in [RFC8376] and reproduced
in Figure 11.
Pelov, et al. Expires 7 January 2027 [Page 21]
Internet-Draft SCHC Architecture July 2026
() () () |
() () () () / \ +---------+
() () () () () () / \======| ^ | +-----------+
() () () | | <--|--> | |Application|
() () () () / \==========| v |=============| Server |
() () () / \ +---------+ +-----------+
Dev RGWs NGW App
Figure 11: Typical LPWAN Network Architecture
Typically, an LPWAN network topology is star-oriented: all packets
between the same source-destination pair follow the same path from/to
a central point. Highly constrained Devices (Dev) exchange
information with LPWAN Application Servers (App) through a central
Network Gateway (NGW), which can be powered and is typically a lot
less constrained than the Devices. Because Devices embed built-in
applications, the traffic flows to be compressed are known in
advance, and the Endpoints, Instances, and associated Contexts can be
provisioned in the system before use.
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 is used to
compress the CoAP, UDP, and IPv6 headers before sending the datagrams
over the LPWAN link layer. SCHC is used as an adaptation layer
between the IPv6 layer and the LPWAN link layer to compress the
headers of the datagrams such that they fit within the constraints of
the LPWAN link layer.
In this setup, each device features a single SCHC Instance in a
single SCHC Endpoint. Each Instance is pre-configured with a static
Context.
The Discriminator is a field value within the LPWAN API or Link
Layer, e.g. the LoRaWAN [RFC9011] DevEUI (DevEUI) and/or function
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.
The Device hosts a SCHC Endpoint containing a single SCHC Instance.
The SCHC Gateway also hosts a SCHC Endpoint and maintains a
corresponding SCHC Instance for the Device. The two Instances
participate in an implicit point-to-point SCHC Session and share a
pre-configured Context. The Session does not require explicit
signaling. On the Device, because a single SCHC Instance is present,
Instance selection is implicit and the Dispatcher may be integrated
directly into the network stack. On the SCHC Gateway, the LPWAN
network or its API provides metadata identifying the Device from
Pelov, et al. Expires 7 January 2027 [Page 22]
Internet-Draft SCHC Architecture July 2026
which an uplink Datagram was received. This device identity is used
as a Discriminator by the Dispatcher to select the corresponding SCHC
Instance. For example, in a LoRaWAN deployment, the Network Server/
Application Server interface may expose a device identifier such as
the DevEUI. The Discriminator selects the SCHC Instance, whereas the
RuleID selects a Rule within the Context associated with that
Instance. In the SCHC-over-LoRaWAN profile defined in [RFC9011], the
LoRaWAN FPort carries the 8-bit SCHC RuleID and forms part of the
SCHC Message. Therefore, FPort is not, in the simple deployment
considered here, the primary Discriminator used to identify the SCHC
Instance.
When a Device communicates with several SCHC Gateway Instances,
[RFC9011] assigns a distinct set of FPort values to each SCHC Gateway
Instance. In that case, membership of an FPort value in a predefined
set may additionally contribute to Instance selection.
Host A, IoT Device Host B, SCHC Gateway
+------------------+ +-----------------------+
| Application A | | Application B |
+------------------+ +-----------------------+
| CoAP | | CoAP |
+------------------+ +-----------------------+
| UDP | | UDP |
+------------------+ +-----------------------+
| IPv6 | | IPv6 |
+------------------+ +-----------------------+
| | | Dispatcher |
| SCHC Instance A1 | | | |
| Context C1 | | SCHC Instance B1 |
| | | Context C1 |
+------------------+ +-----------------------+
| LPWAN Link Layer | | LPWAN/API Interface |
+------------------+ +-----------------------+
| Physical Layer | | |
+------------------+ +-----------------------+
| |
+---------------------------+
Instance A1 <------ implicit SCHC Session ------> Instance B1
Figure 12: SCHC in a typical LPWAN deployment
The SCHC Gateway may use a single SCHC Instance to handle the
Sessions established with multiple Devices. In this case, each
Device participates in a distinct Session, and each Session has its
own SoV, while all Sessions use the same Context and SoR.
Pelov, et al. Expires 7 January 2027 [Page 23]
Internet-Draft SCHC Architecture July 2026
+===============+==========================+=====================+
| Core Element | Device | SCHC Gateway |
+===============+==========================+=====================+
| Domain | Single | Single |
+---------------+--------------------------+---------------------+
| Endpoint | One | One |
+---------------+--------------------------+---------------------+
| Instance | One | One shared Instance |
+---------------+--------------------------+---------------------+
| Session | One implicit P2P Session | One P2P Session per |
| | | Device |
+---------------+--------------------------+---------------------+
| Context | Pre-configured | One shared Context |
+---------------+--------------------------+---------------------+
| SoR | Pre-configured | Same SoR for all |
| | | Sessions |
+---------------+--------------------------+---------------------+
| SoV | One per Session | One per Session |
+---------------+--------------------------+---------------------+
| Discriminator | Implicit | LPWAN/API device |
| | | identity |
+---------------+--------------------------+---------------------+
| Dispatcher | Hardcoded or integrated | LPWAN/API-based |
| | in the stack | |
+---------------+--------------------------+---------------------+
| RuleID | Profile-specific; FPort | Profile-specific; |
| | in [RFC9011] | FPort in [RFC9011] |
+---------------+--------------------------+---------------------+
Table 1
Alternatively, the SCHC Gateway may maintain a distinct SCHC Instance
for each Session. This may be useful when Sessions use different
Contexts or when an implementation chooses to isolate SCHC processing
and state on a per-Session basis. The Instances may nevertheless use
the same Context and SoR. Each Session maintains its own SoV.
Pelov, et al. Expires 7 January 2027 [Page 24]
Internet-Draft SCHC Architecture July 2026
+===============+==========================+====================+
| Core Element | Device | SCHC Gateway |
+===============+==========================+====================+
| Domain | Single | Single |
+---------------+--------------------------+--------------------+
| Endpoint | One | One |
+---------------+--------------------------+--------------------+
| Instance | One | One per Session |
+---------------+--------------------------+--------------------+
| Session | One implicit P2P Session | One P2P Session |
| | | per Device |
+---------------+--------------------------+--------------------+
| Context | Pre-configured | One per Instance; |
| | | may be shared |
+---------------+--------------------------+--------------------+
| SoR | Pre-configured | May be the same |
| | | for all Instances |
+---------------+--------------------------+--------------------+
| SoV | One per Session | One per Session |
+---------------+--------------------------+--------------------+
| Discriminator | Implicit | LPWAN/API device |
| | | identity |
+---------------+--------------------------+--------------------+
| Dispatcher | Hardcoded or integrated | LPWAN/API-based |
| | in the stack | |
+---------------+--------------------------+--------------------+
| RuleID | Profile-specific; FPort | Profile-specific; |
| | in [RFC9011] | FPort in [RFC9011] |
+---------------+--------------------------+--------------------+
Table 2
A.2.2. 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
Pelov, et al. Expires 7 January 2027 [Page 25]
Internet-Draft SCHC Architecture July 2026
Figure 13: 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. Following the convention described in
Section 4, the Instance that initiated the PPP connection plays the
role of the Device in [RFC8724].
+===============+====================================+
| Core Element | Notes |
+===============+====================================+
| Domain | single |
+---------------+------------------------------------+
| Endpoint | 1 per peer |
+---------------+------------------------------------+
| Instance | 1 per PPP connection, per Endpoint |
+---------------+------------------------------------+
| Context | fetched on demand |
+---------------+------------------------------------+
| Discriminator | PPP connection |
+---------------+------------------------------------+
| Dispatcher | PPP demultiplexing |
+---------------+------------------------------------+
Table 3
A.2.3. Direct transport over Ethernet, IPv6, and UDP
SCHC was designed to operate directly on top of native MAC frames of
LPWAN technologies such as LoRaWAN [RFC9011], Sigfox [RFC9442], and
IEEE Std 802.15.4 [I-D.ietf-6lo-schc-15dot4]. To operate SCHC
directly over Ethernet, IPv6, or UDP, the definition of,
respectively, an EtherType, an IP Protocol Number, and a UDP Port
Number is necessary; see [I-D.ietf-intarea-schc-protocol-numbers].
That value serves as the Discriminator: it indicates that the frame
or packet carries a SCHC Datagram, and the Dispatcher uses it,
together with lower-layer context (e.g., addresses or ports), to
route the Datagram to the appropriate Instance.
In these deployments, an optional Control Header can retain the
information that is overwritten when the lower layer designates SCHC,
e.g., the original EtherType or Next Header value identifying the
compressed protocol. The wire format and the placement of the
Control Header needs to be fixed in an interoperable way, e.g. in an
RFC, through IANA registry, YANG Data Model, or other means.
Pelov, et al. Expires 7 January 2027 [Page 26]
Internet-Draft SCHC Architecture July 2026
One such example could be over Ethernet, where the SCHC Datagram
should use a Control Header it an EtherType=SCHC is used.
|-------------- SCHC Datagram ---------------|
+------------------+----------------------+---------+-----------+
| IEEE 802 Header | Control Header | Rule ID | Compressed|
| Ethertype = SCHC | OrigEtherType = IPv6 | | Residue |
+------------------+----------------------+---------+-----------+
Figure 14: SCHC over Ethernet with a Control Header before the RuleID
or alternatively:
|-------------- SCHC Datagram ----------------|
+------------------+----------+----------------------+-----------+
| IEEE 802 Header | Rule ID | Control Header | Compressed|
| Ethertype = SCHC | | OrigEtherType = IPv6 | Residue |
+------------------+----------+----------------------+-----------+
Figure 15: SCHC over Ethernet with a Control Header after the RuleID
A typical way to resolve this is to have an RFC defining the SCHC-
over-Ethernet format, which provides for a standard and interoperable
way of operating when the EtherType=SCHC is used. Note, that this
does not constrain other uses of SCHC over different EtherTypes, e.g.
if a manufacturer wants to use a point-to-point SCHC with no Control
Header, they can do so in their implementations. That could be the
case if Ethernet framing is used over a point-to-point link for
example.
The same considerations are applicable to IPv6 Next Header, or UDP
ports.
A.3. Compatible Partial Contexts
The example in this section has not yet been validated.
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.
Pelov, et al. Expires 7 January 2027 [Page 27]
Internet-Draft SCHC Architecture July 2026
+--------------+
| Root |
| +----------+ |
| | Rule 1 | |
| | Rule 2 | |
| | Rule 3 | |
| +----------+ |
+------|-------+
|
+----------------|-----------------+
| | |
+-------|------+ +------|-------+ +------|-------+
| Node A | | Node B | | Node C |
| +----------+ | | +----------+ | | +----------+ |
| | Rule 1 | | | | Rule 2 | | | | Rule 3 | |
| +----------+ | | +----------+ | | +----------+ |
+--------------+ +--------------+ +--------------+
Figure 16: Example of compatible partial Contexts
Appendix B. Future Work - To Be Decided by the Working Group
The SCHC Architecture Design Team has discussed the items collected
in this appendix, but they have not yet reached consensus. They are
recorded here as input for future revisions of this document, and are
to be decided by the Working Group.
B.1. C/D Engine Interface
The Design Team discussed whether this document should place
normative requirements on the interface exposed by implementations.
The proposed text was:
The C/D engine MUST expose the following interface:
* compress(buffer, context, config): Compresses the provided buffer
using the Context and the Instance Configuration.
* decompress(buffer, context, config): Decompresses the provided
buffer using the Context and the Instance Configuration.
B.2. Other Open Items
* Definition of the Endpoint Manager.
* Additional deployment models remain to be documented, e.g., 6Lo
[I-D.ietf-6lo-schc-15dot4].
Pelov, et al. Expires 7 January 2027 [Page 28]
Internet-Draft SCHC Architecture July 2026
* The Data Models, Lifecycle, and Management sections of the
Operational considerations remain to be developed, building on
YANG [RFC7950], the SCHC YANG data model [RFC9363], and management
protocols such as CORECONF [I-D.ietf-core-comi].
* The integration of SCHClets, specified in [DRAFT-SCHCLET], remains
to be detailed.
* The Role model of the Instance, in particular the relationship
between the Upside and Downside roles and the Device and
Application roles of [RFC8724], remains to be defined.
* An architectural mechanism for signaling decompression errors
between Instances and for triggering Context resynchronization
remains to be defined.
* The Security Considerations analysis remains to be completed.
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
Pelov, et al. Expires 7 January 2027 [Page 29]
Internet-Draft SCHC Architecture July 2026
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 January 2027 [Page 30]
