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