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 4.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. 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. 4.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. 4.2.2. Endpoint 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. 4.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 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 4.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. 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 4.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 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 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, . [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, . [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, . [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, . [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, . [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, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . [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, . [RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, March 2023, . 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, . [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, . 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]