SCHC Working Group Q. Lampin Internet-Draft M. Dumay Intended status: Standards Track P. Surbayrole Expires: 31 January 2026 Orange 30 July 2025 SCHC Minimal Architecture draft-lampin-schc-minimal-architecture-00 Abstract This document investigates the requirements of a minimal architecture for the Static Context Header Compression (and fragmentation) protocol (SCHC). The intent is to identify the essential components their relationships and interfaces. To do so, the document considers scenarios of increasing complexity involving the use of SCHC, from a simple point-to-point communication to a more complex deployment involving multiple SCHC Instances communicating with each other. In this process, the authors hope to identify the essential components of a SCHC architecture and their relationships. 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 31 January 2026. Copyright Notice Copyright (c) 2025 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 Lampin, et al. Expires 31 January 2026 [Page 1] Internet-Draft SCHC Minimal Architecture July 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Minimal Architecture Components, a case study & discussions . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. The simplest deployment scenario . . . . . . . . . . . . 4 4.2. The three endpoints deployment scenario . . . . . . . . . 7 4.3. The dynamic traffic scenario . . . . . . . . . . . . . . 9 4.4. Multiple SCHC Instances in the same Endpoint . . . . . . 11 4.5. Heterogeneous Endpoints . . . . . . . . . . . . . . . . . 13 4.6. The cold boot scenario . . . . . . . . . . . . . . . . . 15 4.7. Core Components Illustrated . . . . . . . . . . . . . . . 16 4.7.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 16 4.7.2. Instance . . . . . . . . . . . . . . . . . . . . . . 17 4.7.3. SCHC Session . . . . . . . . . . . . . . . . . . . . 19 4.7.4. SCHC Domain & Domain Manager . . . . . . . . . . . . 19 4.7.5. Dispatcher . . . . . . . . . . . . . . . . . . . . . 20 4.7.6. Context Management . . . . . . . . . . . . . . . . . 22 4.7.7. Context Repository . . . . . . . . . . . . . . . . . 22 4.7.8. Management Interface . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 8. Bits and pieces . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction The SCHC Working Group has developed the [RFC8724] SCHC protocol for Low-Power Wide-Area (LPWA) networks, providing efficient header compression and fragmentation mechanisms. As SCHC adoption expands beyond its original scope, there is a need to define a minimal architecture that identifies only the essential elements required for proper SCHC operation. This document does not aim to replace the SCHC architecture defined in [DRAFT-ARCH], but rather to investigate the minimal set of components and their relationships that are Lampin, et al. Expires 31 January 2026 [Page 2] Internet-Draft SCHC Minimal Architecture July 2025 necessary for SCHC to function effectively in various deployment scenarios. This document provides: * A definition of the minimal components required for SCHC operation * The essential interactions between these components * Problems and challenges addressed by each component 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [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. It borrows from the terminology of [RFC8724] and [DRAFT-ARCH]. In the following, terms used in the terminology are assumed to be defined in the context of the SCHC protocol unless specified otherwise, _.e.g_ Endpoint refers to a SCHC Endpoint, Instance refers to a SCHC Instance, and so on. *Endpoint*: A network host capable of compressing and decompressing headers and optionally fragmenting and reassembling packets. *Instance*: A logical component of an Endpoint that implements the SCHC protocol, including header compression, fragmentation, and context management. *Context*: A set of rules and parameters that define how SCHC operations are performed by Instances that implement this Context. It includes the Set of Rules (SoR) and the parser ID. *Endpoint 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 Profiles, and managing the Dispatcher. Lampin, et al. Expires 31 January 2026 [Page 3] Internet-Draft SCHC Minimal Architecture July 2025 *Session*: A communication session between two Instances that share a common context for compression and fragmentation operations. Whenever the Context is updated, a new or updated Session is established. *Domain*: A logical grouping of Instances that share a common set of Contexts for compression and fragmentation operations. *Dispatcher*: A logical component 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. *Profile*: A set of configurations that define how SCHC operations are performed within a specific Instance. It includes parameters for the different SCHC components. *Domain Manager*: A logical component that manages the Domain, including context synchronization and profile distribution. *Context Repository*: A logical component that stores and manages the Contexts used by its Domain. 4. Minimal Architecture Components, a case study & discussions In this section, we investigate the minimal components required for SCHC operation in the context of typical deployment scenarios. 4.1. The simplest deployment scenario This section considers a simple point-to-point deployment scenario where two Endpoints communicate with each other using SCHC. The devices are assumed to have a very simple network stack, as shown in the figure below: Lampin, et al. Expires 31 January 2026 [Page 4] Internet-Draft SCHC Minimal Architecture July 2025 Endpoint A Endpoint B +------------------+ +------------------+ | Application A | | Application B | +------------------+ +------------------+ | CoAP | | CoAP | +------------------+ +------------------+ | UDP | | UDP | +------------------+ +------------------+ | IPv6 | | IPv6 | +------------------+ +------------------+ | SCHC Instance | | SCHC Instance | +------------------+ +------------------+ | LPWAN Link Layer | | LPWAN Link Layer | +------------------+ +------------------+ | Physical Layer | | Physical Layer | +------------------+ +------------------+ | | +---------------------------+ In this scenario, * Both Endpoint A and Endpoint B implement the SCHC protocol for header compression and decompression. * Both Endpoints feature a single application and all traffic is sent and received using the CoAP protocol over UDP over IPv6. * The SCHC protocol is used to compress the CoAP, UDP, and IPv6 headers before sending the packets over the LPWAN link layer. * The SCHC protocol is implemented as a single Instance on each Endpoint. * The Instance is hardwired into the protocol stack of each Endpoint, meaning that it is not dynamically loaded or unloaded. * All of the traffic is compressed and decompressed using those Instances. In this simplistic scenario, which is representative of some LPWAN deployments, the requirements for the minimal architecture are as follows: Lampin, et al. Expires 31 January 2026 [Page 5] Internet-Draft SCHC Minimal Architecture July 2025 * The Set Of Rules (SoR) of Endpoint A MUST be compatible with the SoR of Endpoint B. Such compatitibility requires that rules IDs and Rule Descriptors are consistent between the two Instances. Parsers of both Instances MUST be compatible, meaning that they MUST delineate the same header fields in the same order and with the same semantics. * Whenever Endpoint A compresses a packet, it MUST use the same Context as Endpoint B. This means that the Context MUST be synchronized between the two Instances. This communication session is referred to as a Session. *Why Instance?* Here we use the term Instance to refer to the SCHC protocol routine that is running on each endpoint. This is different from the SCHC Instance defined in [DRAFT-ARCH], which refers to a pair of SCHC endpoints that communicate through SCHC. The rationale for this terminology is that the term Instance is often used to refer to a specific realization of a class in object-oriented programming, and in this case, the SCHC Instance is a specific realization of the SCHC protocol that is running on each endpoint. *Session vs Instance*: In this document, we use the term Session to refer to a communication session between two (or more) Instances that are communicating with each other using SCHC, using the same Context. The rationale for this is that the term Session is often used to refer to a specific communication session between two endpoints and this definition extends this concept to all Instances that maintain a common context. *Why not use the terminology of [DRAFT-ARCH]?* We believe that version -04 introduced changes in the terminology that are prone to confusion. In particular, the term Instance is defined as: SCHC Instance. The **session** between SCHC end points in two or more peer nodes operating SCHC to communicate using a common SoR and a matching SoV. There are 2 SCHC Instances or more involved per SCHC stratum, one for the SCHC Stratum Header and one or more for the SCHC payload, i.e., the SCHC-compressed data. while the end point is defined as: SCHC end point. An entity (e.g., Device, Application and Network Gateway) involved in the SCHC process. Each SCHC end point will have its Set of Rules (SoR), based on the profile, the protocols, the device, the behaviour and a Set of Variables (SoV). Lampin, et al. Expires 31 January 2026 [Page 6] Internet-Draft SCHC Minimal Architecture July 2025 Those definitions are confusing as they do not clearly identify the components which they are referring to. For example, the term Instance can be used to refer to session between two applications that are using SCHC, or to refer to two hardware devices that are using SCHC, etc. The proposed terminology in this document aims to clarify the definitions of the architecture components by calling a session a Session and therefore reuses the term Instance to refer to the SCHC protocol routine that is running on an endpoint. This terminology is consistent with prior versions of the architecture document, such as version -03, which had the following definitions: * SCHC Instance. The different stages of SCHC in a host. Each instance will have its Set of Rules (SoR), based on the profile, the protocols, the device, the behaviour and a Set of Variables (SoV). There are 2 SCHC Instances involved per SCHC stratum, one for the SCHC header and one for the SCHC payload, i.e., the SCHC- compressed data. * SCHC Session. The association of SCHC Instances in two or more peer nodes operating SCHC to communicate using a common SoR and a matching SoV. 4.2. The three endpoints deployment scenario In this section, we consider a more complex deployment scenario where two or more endpoints communicate with the same SCHC Instance/ Endpoint. This scenario is common in IoT deployments where multiple sensors or devices communicate with a central gateway or server using SCHC. Lampin, et al. Expires 31 January 2026 [Page 7] Internet-Draft SCHC Minimal Architecture July 2025 Endpoint A Endpoint B Endpoint C +------------------+ +------------------+ +------------------+ | Application A | | Application B | | Application A | +------------------+ +------------------+ +------------------+ | CoAP | | CoAP | | CoAP | +------------------+ +------------------+ +------------------+ | UDP | | UDP | | UDP | +------------------+ +------------------+ +------------------+ | IPv6 | | IPv6 | | IPv6 | +------------------+ +------------------+ +------------------+ | SCHC Instance | | SCHC Instance | | SCHC Instance | +------------------+ +------------------+ +------------------+ | LPWAN Link Layer | | LPWAN Link Layer | | LPWAN Link Layer | +------------------+ +------------------+ +------------------+ | Physical Layer | | Physical Layer | | Physical Layer | +------------------+ +------------------+ +------------------+ | | | | +--------------------+ +-------------------+ In this scenario, we have three Endpoints, Endpoint A, Endpoint B, and Endpoint C, that communicate with each other using SCHC. Here, Endpoint A and Endpoint C are typically sensors or devices that send data to Endpoint B, which is a gateway or server that collects and processes the data. We further assume that Endpoints A and C have very similar traffic patterns, meaning that they send similar packets to Endpoint B. This allows the SCHC Instances on Host A, B and C to share the same Context, which reduces the complexity of administration and management of this deployment. In the following, we refer to Instances that share the same Contexts as a Domain. In this typical IoT deployment scenario, the requirements for the minimal architecture are as follows: * The Context of all three Endpoints MUST be compatible. This means that the SoR, parsers, and rule IDs are consistent between the three Instances. * The Context *MUST* be synchronized between the three Instances. This means that an updated Session between all three Instances is established whenever the Context is updated or modified. * The Domain *MUST* be able to manage the Contexts of all Instances that belong to it. This includes the Endpoints enrollment, provisioning of Contexts and synchronization. This role is assumed by a logical component of the Domain, referred to as the Domain Manager. Lampin, et al. Expires 31 January 2026 [Page 8] Internet-Draft SCHC Minimal Architecture July 2025 *Why synchronize the Contexts of A and C?* Synchronizing the Contexts of Endpoint A and Endpoint C is desirable. This reduces the complexity of managing multiple Contexts at Endpoint B and eventually reduces the size the Rules IDs, impacting the SCHC packet size. *Domain Manager, why introduce a new entity?* In a first approach, the Domain Manager could be implemented as a component of the Instance that is running on an Endpoint, here B. However, this would require distinguishing between different types of Instances: those capable of managing other instances from those that are not, those that are in charge of managing others from those that are not. By separating the Domain Manager from the Instance, we allow for a more flexible and modular architecture that can be adapted to different deployment scenarios. *Context compatibility or equality?* While not strictly required, it is desirable that the Contexts of all Instances that belong to the same Domain are equal, meaning that they share the same SoR, parsers, and rule IDs. This simplifies the management of the Contexts and reduces the risk of misconfiguration or incompatibility between Instances. However, this is not strictly required, as long as the Contexts are compatible, meaning that they can be used interchangeably without causing issues in compression or fragmentation operations. 4.3. The dynamic traffic scenario In this section, we consider a deployment scenario where multiple Endpoints communicate with each other using SCHC, but the traffic patterns of these Endpoints are dynamic and change over time. This scenario typically occurs in Smart Buildings applications, where different configurations are deployed based on the current season, occupancy, etc. For example, thermostats setpoints are set differently in winter and summer. In this scenario, we have three Endpoints A, B and C. A, B feature a temperature and thermostat functionality, while C is a server that collects and processes the data from A and B. We further assume that the Endpoints A, B and C are first registered with the Domain Manager of the domain which they are part of, and that they are provisioned with an initial Context. This Context is used to compress the temperature and thermostat data sent by A and B to C, and is tailored to the specifics of the temperatures recorded during winter, and the thermostat setpoints used during this season, as shown in the figure below: Lampin, et al. Expires 31 January 2026 [Page 9] Internet-Draft SCHC Minimal Architecture July 2025 +----------------+ | Domain Manager | +----------------+ ^ | 1. Endpoints | | registered | | | | 2. Context v1 deployed for winter | +-----------------+-----------------+ | | | | | | | | | v v v +--------------+ +--------------+ +--------------+ | Endpoint A | | Endpoint B | | Endpoint C | +--------------+ +--------------+ +--------------+ Then comes the spring, and the temperature and thermostat setpoints change. The Domain Manager is responsible for updating the Context of all Instances that belong to the domain, i.e. A, B and C. This update is done dynamically, meaning that the Context is updated without interrupting the communication between the Endpoints. +--------------------+ | Application Server | +--------------------+ | | 1. Submission of a new Context (v2) | | +----------------+ Context v2 +--------------------+ +------>| Domain Manager | <----------> | Context Repository | +----------------+ stored +--------------------+ | | | | 2. Context v2 deployed +-----------------+-----------------+ | | | | | | v v v +--------------+ +--------------+ +--------------+ | Endpoint A | | Endpoint B | | Endpoint C | +--------------+ +--------------+ +--------------+ This scenario highlights the need for a dynamic context update mechanism that allows the Domain Manager to update the Context of all Instances belonging to the Domain. This raises a number of questions, such as: Lampin, et al. Expires 31 January 2026 [Page 10] Internet-Draft SCHC Minimal Architecture July 2025 * How to ensure that all Instances are updated with the new Context? * How to process packets sent before the Context update but received after? Answering those specific questions is critical for the proper operation of SCHC in this scenario as unsynchronized Contexts can lead to packet loss or misinterpretation at the receiving end. It is worth noting that the same questions arise in the context of configuration management and are possibly addressed by existing IETF protocols. Nevertheless, we can already identify the need for the following: * A Context Repository that is responsible for storing the Contexts of the domain. In case of disagreement between Instances, the Context Repository is used to resolve the disagreement. Having one identified source of truth for the Contexts helps to maintain consistency across the domain. This is also useful when (new) nodes join the domain later, as the Context Repository can provide the necessary Context information to new or existing Instances. * A mechanism for versioning Contexts, allowing the Domain Manager to manage multiple versions of a Context and facilitate rollbacks if needed. * A mechanism for notifying Endpoints of Context updates, ensuring that all Endpoints are aware of the latest Context version and can adapt their behavior accordingly. 4.4. Multiple SCHC Instances in the same Endpoint In this scenario, a single Endpoint that hosts multiple Instances is considered. This scenario involves each Instance being configured with different Contexts. This can be useful for supporting multiple applications or services with distinct traffic patterns. One such use-case arises when a single Endpoint needs to handle different types of traffic, potentially sent and received on different network interfaces, each requiring its own Instance with tailored compression and fragmentation settings. Lampin, et al. Expires 31 January 2026 [Page 11] Internet-Draft SCHC Minimal Architecture July 2025 Endpoint A Endpoint B +------------------------------+ +------------------------------+ | App. 1 | App. 2 | | App. 1 | App. 2 | +------------------------------+ +------------------------------+ | CoAP | HTTP | | CoAP | HTTP | +------------------------------+ +------------------------------+ | UDP | UDP/QUIC | | UDP | UDP/QUIC | +------------------------------+ +------------------------------+ | IPv6 | | IPv6 | +------------------------------+ +------------------------------+ | SCHC | SCHC | | SCHC | SCHC | | Instance A1 | Instance A2 | | Instance B1 | Instance B2 | +------------------------------+ +------------------------------+ | Link Layer | | Link Layer | +------------------------------+ +------------------------------+ | Physical Layer | | Physical Layer | +------------------------------+ +------------------------------+ | | +-------------------------------------+ In the above example, two Endpoints, A and B, each host two Instances. Endpoint A hosts Instance A1 and Instance A2, while Endpoint B hosts Instance B1 and Instance B2. Instance A1 and Instance B1 are configured to handle CoAP traffic and share a common Context C1 while Instance A2 and Instance B2 are configured to handle HTTP traffic and share a common Context C2. This new scenario introduces the following challenges: * *Datagram Dispatch*: The Endpoint must be able to dispatch packets to the appropriate Instance based on the protocol or application in use. This requires an additional functional entity, the Dispatcher, that can identify and dispatch packets to the correct Instance for compression and fragmentation. Conversely, the Dispatcher must also be able to route inbound compressed and fragmented packets to the correct Instance for decompression and reassembly. In the above example, uncompressed CoAP/UDP packets must be dispatched to Instances A1 and B1, while uncompressed HTTP/QUIC packets must be dispatched to Instances A2 and B2. Additionally, compressed CoAP/UDP packets must be dispatched to Instances A1 and B1, while compressed HTTP/QUIC packets must be dispatched to Instances A2 and B2 for decompression. The criteria for dispatching compressed packets to the correct Instance is called the Discriminator in [DRAFT-ARCH]. Those challenges are discussed further in section Section 4.7.5. Lampin, et al. Expires 31 January 2026 [Page 12] Internet-Draft SCHC Minimal Architecture July 2025 * *Instance/Context Identification*: In addition to the need for a Dispatch mechanism, which addresses the routing of packets to the correct Instance, each Instance or Context must be uniquely identifiable to allow the Domain Manager to update the Context of a specific Instance. *Dispatcher and Discriminator* In [DRAFT-ARCH], the authors introduce the concept of a Discriminator that is used to identify the Instance or Context that must be used to decompress a packet. As explained in the document, the Discriminator is a criterion that is used to select the appropriate Instance or Context for decompression. The Dispatcher is different from the Discriminator in that it is the functional unit responsible for routing packets to the correct Instance based on: * the Discriminator value for decompression and reassembly. * the Matching Operators and Target Values of the Contextes for compression and fragmentation. 4.5. Heterogeneous Endpoints This additional scenario introduces heterogeneous Endpoints that feature different hardware and software configurations. These differences may include the Operating System (OS) or the hardware on which the Instance is run. Those differences are the source of a challenge in the deployment of Instances in configurations. To illustrate this challenge, we consider the following example, illustrated in the figure below, where two Endpoints A and B are both running the same OS, here a Linux-based distribution using udev for device management, but on two different hardware platforms. Lampin, et al. Expires 31 January 2026 [Page 13] Internet-Draft SCHC Minimal Architecture July 2025 Endpoint A Endpoint B +------------------------------+ +------------------------------+ | Application | | Application | +------------------------------+ +------------------------------+ | CoAP | | CoAP | +------------------------------+ +------------------------------+ | UDP | | UDP | +------------------------------+ +------------------------------+ | IPv6 | | IPv6 | +------------------------------+ +------------------------------+ | SCHC | | SCHC | | Instance | | Instance | +------------------------------+ +------------------------------+ | eno0 | | enp2s0 | | Ethernet, onboard device, | | Ethernet, PCI device | | index 0 | | bus 2, slot 0 | +------------------------------+ +------------------------------+ | Physical Interface | | Physical Interface | +------------------------------+ +------------------------------+ | | +----------------------------------+ Endpoint A features an Ethernet interface which is located on the mainboard and is referred to as eno0: _en_ standing for "Ethernet", _o_ for "onboard", and _0_ for "index 0" in the udev naming convention. Endpoint B features an Ethernet interface which is located on a PCI bus and is referred to as enp2s0: _en_ standing for "Ethernet", _p_ for "PCI", _2_ for "bus 2", and _s0_ for "slot 0" in the same naming convention. In this scenario, the Context which contains the Set of Rules (SoR) and parser ID, i.e. the configuration which is shared by all Instances of a Domain, provides no information on how to instruct the Dispatcher to route packets from the appropriate Network Interface to the appropriate Instance. Without further configuration and unless the Dispatcher intercepts all packets from all network interfaces, we cannot guarantee the correct dispatching of packets to the appropriate Instances. Obviously, intercepting traffic from all network interfaces is not a viable solution, as it would require the inspection of all packets, regardless of their destination, which requires significant processing power and may introduce unacceptable latency on high-speed links. Lampin, et al. Expires 31 January 2026 [Page 14] Internet-Draft SCHC Minimal Architecture July 2025 Additionally, different OSes may use different filtering/dispatch frameworks, e.g. Netfilter on Linux, BPF on FreeBSD, PF on OpenBSD and macOS etc. This means that the foundation on which the Dispatcher implementation relies may vary significantly between different platforms and could require different configurations to dispatch packets to Instances based on the same Context but running on different Endpoints. This assessment advocates for the introduction of a device-specific configuration that is independent of the Context, which we name Profile. Such Profiles are Endpoint specific so their actual content is out of scope of this document. However, the Profile *SHALL* include the following: * The configuration of the Dispatcher, i.e. the admission rules for compression and decompression. * The rule matching policy, i.e. the policy used to select the appropriate compression or decompression rule based on the SCHC packet and the Context. As the Profile is Endpoint specific, it is not shared between Instances of different Endpoints. However, the Profile required for a given Instance may need to change when the Context is updated, e.g. the filtering rules may need to be adjusted to account for the new traffic patterns and C/D rules. This means that the Profile may need to be updated whenever the Context is updated, and that the Domain Manager *SHALL* therefore be responsible for managing the Profile delivery to Instances and their synchronization with the Context. 4.6. The cold boot scenario In this scenario, we consider the case where an Endpoint A is powered on and needs to establish a SCHC Session with another Endpoint B. Endpoint A does not have any Context or Profile stored in memory, and it needs to retrieve or negotiate this information before establishing the session. Two hypothetical scenarios are considered here: * _S1_. Endpoint A is provisioned on the appropriate Domain and is configured with the address/URI of the Domain Manager and Context Repository. Lampin, et al. Expires 31 January 2026 [Page 15] Internet-Draft SCHC Minimal Architecture July 2025 * _S2_. Endpoint A is provisioned on the appropriate Domain but is not configured with the address/URI of the Domain Manager and Context Repository. In this scenario, the Domain Manager is in charge of advertising its presence and push the context to Endpoint A. In scenario _S1_, Endpoint A initiates the configuration phase, effectively pulling the Context and Profile from the Domain Manager and the Context Repository. This scenario implies that the Domain Manager exposes a management interface that allows Endpoints to retrieve the necessary configuration information. Additionally, a logical component referred to as Endpoint Manager is required to manage the Instances of the Endpoint. In scenario _S2_, the Domain Manager is in charge of advertising its presence and Endpoint A is pulling the Contexts and Profiles from it. The advertisement can be done using a discovery mechanism, such as DNS-SD or a predefined multicast address. This scenario implies that Endpoints are capable of discovering the Domain Manager and retrieving the necessary configuration information. This further requires that Endpoints feature a service discovery mechanism and a Management Protocol that enables them to interact with the Domain Manager and request the required Context and Profile. In both scenarios, a management protocol is required to enable the retrieval of the Context and Profile from the Domain Manager. [DRAFT-CORECONF] provides initial ideas on how to implement such a management protocol for SCHC in a Constrained Environment, e.g. IoT devices. 4.7. Core Components Illustrated This section provides an overview of the SCHC Core components their interactions and key functionalities and interfaces. 4.7.1. Endpoint An Endpoint is a network host capable of compressing and decompressing headers and optionally fragmenting and reassembling packets. It implements the SCHC protocol as defined in [RFC8724]. An Endpoint can host multiple Instances, each with its own Context and Profile. Lampin, et al. Expires 31 January 2026 [Page 16] Internet-Draft SCHC Minimal Architecture July 2025 retrieves, synchronizes +------------+ contexts | Endpoint | retrieves, synchronizes +---------| Manager |-------------+---------------+ | +------------+ | | | | manages v v | | lifecycle +------------+ +------------+ | | of Instances | Profile P1 | | Context Pk | | | +------------+ +------------+ | | configures | |configures | | | | | | compresses, decompresses +-----+ | | | +------------------------+ | | v v | fragments, reassembles | | | +------------+ +-------------+ | | | | Context C1 |--| Instance I1 |<--+ v v v +------------+ +-------------+ | +---------------+ ... ... +<----------| Dispatcher |----+ ... ... | | +---------------+ | +------------+ +-------------+ | dispatch ^ | | | Context Ck |--| Instance Ik |<--+ packets - | reinject configures +------------+ +-------------+ | | | | v v +-------------------------------+ | OS/firmware | | network stack | +-------------------------------+ 4.7.2. Instance An Instance is the fundamental component that implements the SCHC protocol as defined in [RFC8724]. An Endpoint MAY execute several Instances in its protocol stack. Each Instance operates independently, with its own context and profile. An Instance MUST implement the following components: * Header Compression and Decompression (C/D) engine * Context Manager * Profile Manager Its configuration MUST include: * a SCHC Context, which defines the set of C/D and F/R rules - or Set of Rules - and the parser to be used to delineate the header field. Lampin, et al. Expires 31 January 2026 [Page 17] Internet-Draft SCHC Minimal Architecture July 2025 * a SCHC Profile, which defines the configuration of the Dispatch Engine, the rule matching policy, and the device-specific configuration. A SCHC Instance MAY implement: * Fragmentation and Reassembly (F/R) functionality. * Dynamic context update mechanisms. * Performance monitoring and reporting. 4.7.2.1. Header Compression and Decompression (C/D) engine This component is responsible for compressing and decompressing headers using the SCHC protocol, as described in [RFC8724]. It applies the rules defined in the SCHC Context. The C/D engine MUST expose the following interface: * compress(buffer, context, profile): Compresses the provided buffer using the SCHC Context and the profile. * decompress(buffer, context, profile): Decompresses the provided buffer using the SCHC Context and the profile. Internally, on compression, the C/D engine: * delineates the fields using the parser identified in the SCHC Context. * chooses the appropriate compression rule based on the SCHC Context and the matching policy defined in the profile. * applies the compression rule to the fields of the header. * generates the compressed SCHC packet. On decompression, the C/D engine: * identifies the C/D rule based on the SCHC compressed packet. * applies the decompression rules to reconstruct the original header. * reconstructs the original packet from the decompressed header and payload. Lampin, et al. Expires 31 January 2026 [Page 18] Internet-Draft SCHC Minimal Architecture July 2025 4.7.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 optional in the minimal architecture but recommended for scenarios where packet sizes exceed the maximum transmission unit (MTU) of the underlying network. 4.7.3. SCHC 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. It is established whenever the Context is updated or modified. Endpoint A Endpoint B +------------------+ +------------------+ | SCHC Instance | <--- ----> | SCHC Instance | +------------------+ \ / +------------------+ \ / Session / \ +------------------+ / \ +------------------+ | SCHC Instance | <--- ---> | SCHC Instance | +------------------+ +------------------+ Endpoint C Endpoint D 4.7.4. SCHC Domain & Domain Manager The SCHC Domain is an administrative unit, whose role is to manage the SCHC Contexts of all Instances that belong to it. The Domain Manager is the component responsible for this management. It handles Endpoints Enrollment, and Context synchronization. Lampin, et al. Expires 31 January 2026 [Page 19] Internet-Draft SCHC Minimal Architecture July 2025 Domain Manager +----------------------------+ | | | +----------+ +----------+ | | | Endpoint | | Context | | +-------+>| Manager | | Manager | | | | +----------+ +----------+ | | +--------------------+-------+ Register | | Endpoint | +------------------------+ | | synchronize Context(es) v v +-----------------+ +------------------+ +----------------+ | Endpoint A | | Endpoint B | | Endpoint ... | +-----------------+ +------------------+ +----------------+ SCHC Domain, different illutration. +------------------------------------------------------------+ | | +-+ +-------------+ +-+ i | | p | Context | e | | i n | | r +--| Repository |-+ n | | n t | | o +-------------+ | +-------------+ | +----------+ d | | t e | | v | |-+ +-------------+ +--| Endpoint | p | | e r | | i | Provisioner |----| Profile |----| Manager | o | | r f | | s | |-+ | Repository | +-| | i | | f a | | i +-------------+ | +-------------+ | +----------+ n | | a c | | o | +-------------+ | t | | c e | | n +--| Endpoints |--+ | | e +-+ | Registry | +-+ | +-------------+ | | | +------------------------------------------------------------+ 4.7.5. Dispatcher The Dispatcher is responsible for delivering compressed packets to the correct SCHC Instance. It ensures that the compressed packets are sent to the appropriate destination and that the decompressed packets are delivered to the correct application or protocol routine. Lampin, et al. Expires 31 January 2026 [Page 20] Internet-Draft SCHC Minimal Architecture July 2025 The Dispatcher is a key component that enables the coexistence of multiple SCHC Instances on the same network host, allowing different protocols or applications to use SCHC compression and decompression mechanisms. It also allows regular traffic to coexist with SCHC- compressed traffic. Dispatcher is illustrated in the figure below, where two SCHC Instances are running on the same Endpoint. The Dispatcher is responsible for routing packets to the appropriate Instance based on admission criteria defined in the Profiles and the Contexts. reinject +------------------------------------------------------------------+ | | | Profile1 Context1 | | | | | | +-----+----+ | | | | | +- - - - - - -+ Instance 1 | | | Packet p+1 | + - - - - - -+ | | +-------------+ + - - - - - - - - - -+ |- compress | | +->| Packet p | + -| chain_inst1_comp | + - - - - - -+ | +-------------+ | + - - - - - - - - - -+ |- decompress| | | Packet p-1 | + -| chain_inst1_decomp | + - - - - - -+ | +- - - - - - -+ | +--------------------+ | Packet +->| chain_inst2_comp |--+ | Queue | +--------------------+ | +------------+ | + -| chain_inst2_decomp | +-->|- compress |---+ + - - - - - - - - - -+ +------------+ | . . . | |- decompress| + - - - - - - - - - -+ + - - - - - -+ Dispatcher Instance 2 | +-----+----+ | | Profile2 Context2 There are two types of admission criteria that are used by the Dispatcher: 1. Discriminator values for decompression and reassembly. Those criteria are used to identify packets that should be decompressed and reassembled by SCHC. The Discriminator is a value that is either included in the packet, such as a field in the packet headers (MPLS label, UDP port) or is derived from the metadata associated with the packet, such as the Network Interface ID, as described in [DRAFT-ARCH]. Lampin, et al. Expires 31 January 2026 [Page 21] Internet-Draft SCHC Minimal Architecture July 2025 2. Matching Operators and Target Values of the Contexts for compression and fragmentation. Those criteria are used to identify packets that should be compressed and fragmented by SCHC. The Matching Operators and Target Values are defined in the SCHC Contexts and are used to match specific header fields or values in the packet headers. The Dispatcher uses these criteria to determine whether a packet should be compressed or fragmented by a given Instance. *TODO: LINK between discriminator, MO/TV and filter chains.* *What follows is WIP, needs to be completed.* 4.7.6. Context Management Context management is responsible for maintaining the shared state between SCHC entities. This includes: * Context synchronization between entities * Rule lifecycle management * Profile distribution and updates 4.7.7. Context Repository A Context Repository provides centralized storage and management of SCHC contexts and profiles. While not mandatory for minimal deployments, it becomes essential for larger deployments requiring centralized management. 4.7.8. Management Interface A Management Interface provides operational control and monitoring capabilities for SCHC deployments. This may include: * Configuration management * Performance monitoring * Troubleshooting tools 5. Security Considerations Security considerations for SCHC minimal architecture include: * Context integrity and authenticity * Profile distribution security Lampin, et al. Expires 31 January 2026 [Page 22] Internet-Draft SCHC Minimal Architecture July 2025 * Protection against context manipulation attacks 6. IANA Considerations This document has no IANA actions. 7. Acknowledgments The authors would like to thank the SCHC Working Group for their contributions and feedback on this document. 8. Bits and pieces *THIS SECTION IS NOT PART OF THE DOCUMENT, IT IS A COLLECTION OF IDEAS, CONCEPTS AND ILLUSTRATIONS THAT ARE NOT YET FULLY DEVELOPED OR INTEGRATED INTO THE DOCUMENT. IT IS PROVIDED FOR REFERENCE AND DISCUSSION PURPOSES ONLY.* Endpoint +------------------------------------------------+ | +-------------+ +---------------+ | | | Instance I1 |-----+- Context C1 | +-+ | +-------------+ +- Context C2 | | | i | +-------------+ / | ... | d | | n | | Instance I2 |__/ +---------------+ o | | t | +-------------+ Domain D1 m | | e | ... ... a | | r | +-------------+ +---------------+ i | | f | | Instance Ik |-----+- Context Ck | n | | a | +-------------+ ... +- Context Ck+1 | | | c | +-------------+ __| ... | | | e | | Instance .. |__/ +---------------+ +-+ | +-------------+ Domain Dn | +------------------------------------------------+ Lampin, et al. Expires 31 January 2026 [Page 23] Internet-Draft SCHC Minimal Architecture July 2025 Endpoint +-------------------------------------------------------------------+ | | | Domain D1 | | +--------------+ +--------------------+ | | +---| Instance I1 |-----|- Context/Profile 1 | +-+ | | +--------------+ +|- Context/Profile 2 | | | i | | +--------------+ / | ... | d| | n | +--|---| Instance I2 |__/ +------------+-------+ o| | t | | | +--------------+ ... | m| | e | | | ... Domain Dn a| | r | | | +--------------+ +---------------------+ i| | f | | | | Instance Ij |-----|- Context/Profile j | n| | a | | | +--------------+ ... | ... | | | c | | | +--------------+ --|- Context/Profile k | | | e | +--|--|---| Instance Ik |__/ +------+--------------+ +-+ | | | | +--------------+ | | | | | | | | | Dispatcher | | | | | | | | +-----------------------+ | | | | | | | | | | | | | | | | | | | | +----------------+ +-+ | | | | | | | | +---|--|-- Inst. 1 Cb | | |--+ | | | | | +------|--|-- Inst. 2 Cb | | |----+ | | | | | | | ... | | |- - - + | | | +---------|--|-- Inst. k Cb | | |--------+ | | | +----------------+ | | | | | +-+ | | +-----------------------+ | +---------------------+-----------------------+---------------------+ | Net. Stack 1 | ... | Net. Stack l | +---------------------+-----------------------+---------------------+ Lampin, et al. Expires 31 January 2026 [Page 24] Internet-Draft SCHC Minimal Architecture July 2025 Endpoint +------------------------------------------------------------------+ | | | Dispatcher | | +--------------+ +-------------+ +--------------------+ | | | Disp. Filter1| | Instance I1 |-----+- Context/Profile 1 | +-+ | +--------------+ +-------------+ +- Context/Profile 2 | | | i | +--------------+ +-------------+ / | ... | d| | n | | Disp. Filter2| | Instance I2 |__/ +--------------------+ o| | t | +--------------+ +-------------+ Domain D1 m| | e | ... ... a| | r | +--------------+ +-------------+ +---------------------+ i| | f | | Disp. Filterk| | Instance Ik |-----+- Context/Profile k | n| | a | +--------------+ +-------------+ ... +- Context/Profile k+1| | | c | +--------------+ +-------------+ __| ... | | | e | |Disp. Filter..| | Instance .. |__/ +---------------------+ +-+ | +--------------+ +-------------+ Domain Dn | | | | | | | | | | | +---------------------+----------------------+---------------------+ | Net. Interface 1 | ... | Net. Interface l | +---------------------+----------------------+---------------------+ Domain D1 +------------------------------------------------------------+ | | +-+ +-------------+ +-+ i | | p | Context | e | | i n | | r +--| Repository |-+ n | | n t | | o +-------------+ | +-------------+ | +----------+ d | | t e | | v | |-+ +-------------+ +--| Endpoint | p | | e r | | i | Provisioner |----| Profile |----| Manager | o | | r f | | s | |-+ | Repository | +-| | i | | f a | | i +-------------+ | +-------------+ | +----------+ n | | a c | | o | +-------------+ | t | | c e | | n +--| Endpoints |--+ | | e +-+ | Registry | +-+ | +-------------+ | | | +------------------------------------------------------------+ *Dispatch scenarios*: Case 1: The Dispatch Engine is integrated into the network stack and a single SCHC Instance is used. Lampin, et al. Expires 31 January 2026 [Page 25] Internet-Draft SCHC Minimal Architecture July 2025 Endpoint 1 Endpoint 2 +-------------+-------------+ +-------------+-------------+ | App. A | App. B | | App. A | App. B | +-------------+-------------+ +-------------+-------------+ | HTTP | CoAP | | HTTP | CoAP | +-------------+-------------+ +-------------+-------------+ | QUIC/UDP | UDP | | QUIC/UDP | UDP | +-------------+-------------+ +-------------+-------------+ | IPv6 | | IPv6 | +-----+-------+-------------+ +-------------+-------------+ | ^ ^ | | | ^ ^ | | | | Dispatch | UDP Dest| | | Dispatch | UDP Src | | | Engine | Port 5678| | | Engine | Port 5678| | | | | | | | | | | +----+-----------+------+---+ +----+-----------+----------+ IPv6 | IPv6 IPv6 | IPv6 datagram | datagram datagram | datagram | +---------+------+-----+ | +---------+------+-----+ | | SCHC Instance | | | SCHC Instance | | +---------+------+-----+ | +---------+------+-----+ | | | | | | | | | | | |+------------+ | | | |+------------+ | | | || SCHC Inst. | | | | || SCHC Inst. | | | | || Decompress.| | | | || Decompress.| | | | |+------------+ V | | |+------------+ V | | | ^ +------------+ | | | ^ +------------+ | | | | | SCHC Inst. | | | | | | SCHC Inst. | | | | | | Compress. | | | | | | Compress. | | | | | +------------+ | | | | +------------+ | | | | | | | | | | | | +----+--------+--------+ | +----+--------+--------+ | SCHC SCHC | SCHC SCHC | Packet packet | Packet packet | | | | | | v | V V | V +---------------------------+ +---------------------------+ | Ethertype Ethertype | | Ethertype Ethertype | | == SCHC := SCHC | | == SCHC := SCHC | | | | | | Link layer, e.g. Ethernet | | Link layer, e.g. Ethernet | +---------------------------+ +---------------------------+ | Network Interface Card | | Network Interface Card | +---------------------------+ +---------------------------+ | Physical Layer | | Physical Layer | +---------------------------+ +---------------------------+ | | | | | | | | | +----------------------------------+ | Lampin, et al. Expires 31 January 2026 [Page 26] Internet-Draft SCHC Minimal Architecture July 2025 +--------------------------------------+ In this simple scenario, the Dispatch Engine is integrated into the network stack and there is a unique predefined SCHC Instance for a specific protocol stack, such as CoAP over UDP over IPv6. This is the classic case for SCHC over LPWAN networks, as described in [RFC8724], [RFC8824], [RFC9363]. The dispatching is done based on a identified header field, such as the an ethertype, the IPv6 Next Header field, a specific UDP port, etc. This implementation scenario therefore assumes that the endpoint Operating System (OS) implements the SCHC protocol as part of its network stack and that SCHC is allocated the appropriate ethertype, IPv6 Next Header value or UDP port from IANA. In the example above, * On Endpoint 1, the Dispatch "intercepts" outbound packets whose UDP destination port is 5678, which is used by CoAP. It then routes these packets to the SCHC Instance for CoAP over UDP over IPv6. The SCHC instance then compresses the CoAP, UDP and IPv6 headers, and calls the Link Layer interface to send the compressed packet over the network, setting the appropriate SCHC ethertype in the link layer header. * On Endpoint 2, incoming packets whose SCHC ethertype is set to the SCHC value are routed to the SCHC Instance for CoAP over UDP over IPv6. The SCHC Instance decompresses the SCHC packets and delivers them to the IPv6 layer. Note that in this example, regular HTTP over QUIC traffic is also present on the same Endpoint. The Dispatch Engine is able to discriminate those packets from packets that are compressed by SCHC, as the HTTP over QUIC packets do not not match the admission rules defined in the SCHC profile, here UDP Destination Port == 5678. Case 2: The Dispatch engine lives outside of the network stack. In this case, the Dispatch Engine is a separate component that interacts with multiple SCHC Instances. It is responsible for routing packets to the appropriate SCHC Instance based on the packet type and supplied admission rules. * On Linux, this can be implemented using netfilter hooks or similar mechanisms to intercept packets and route them to and from the appropriate SCHC Instance. Lampin, et al. Expires 31 January 2026 [Page 27] Internet-Draft SCHC Minimal Architecture July 2025 * On macOS, the Dispatch Engine can be implemented as a kernel extension or user-space application that make use of PF, the native packet filter. The exact implementation details of the Dispatch Engine will depend on the Operating System, which therefore is not specified in this document. However, a description of packets criteria and admission rules is provided in the SCHC profile, which is used by the Dispatch Engine to determine how to route packets. Endpoint +------------------------------------------+ | App. A | App. B | App. C | +--------------+-------------+-------------+ | QUIC | CoAP | HTTP | +--------------|-------------+-------------| | Dispatch Dispatch | | Hooks | Hook 1 . Hook 3 | + | | (dport 443) (dport 5768) | | | | . | | +------------------+ | UDP | TCP | | Dispatch Engine | +----------------------------+-------------+ +------------------+ | IPv6 | IPv4 | 1 . . 2 +----------------------------+-------------+ . . | Dispatch . Dispatch | | +------------+ | Hook 2 Hook 4 | | |SCHC Inst.#1| | label . label | | +------------+ | 0xabcd0180 0xabce0180 | | | . . | | | | | v . | | MPLS | | |compress . | +----------------------------+ | | v | | Ethertype | | decompress| | == | +------------+ | 0x8847 | | Ethernet | +------------------------------------------+ In the example above, the Dispatch Engine is implemented as a filter that intercepts packets based on their UDP destination port. In this instance, it routes packets with a destination port of 5768 to the SCHC Instance for CoAP over UDP over IPv6. The Dispatch Engine then compresses the CoAP, UDP, and IPv6 headers, adds a MPLS header with appropriate tag and sends the compressed packet over the network. When receiving packets, the Dispatch Engine checks the SCHC ethertype and MPLS label and routes matching packets (MPLS label == 0xabcd0180 && UDP destination port == 5768) them to the appropriate SCHC Instance based on the defined admission rules in the profile. Lampin, et al. Expires 31 January 2026 [Page 28] Internet-Draft SCHC Minimal Architecture July 2025 9. References 9.1. Normative References [DRAFT-ARCH] Pelov, A., Thubert, P., and A. Minaburo, "SCHC Architecture", Work in Progress, Internet-Draft, draft- ietf-schc-architecture-04, February 2025, . [DRAFT-CORECONF] Minaburo, A., Toutain, L., Banier, C., and M. Dumay, "CORECONF Rule management for SCHC", Work in Progress, Internet-Draft, draft-toutain-schc-coreconf-management-00, May 2025, . [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, . [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, . 9.2. Informative References [RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, March 2023, . Appendix A. Change Log Lampin, et al. Expires 31 January 2026 [Page 29] Internet-Draft SCHC Minimal Architecture July 2025 A.1. Changes from -00 to -01 * Initial version Authors' Addresses 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 Philippe Surbayrole Orange Orange 3 Massifs - 22 Chemin du Vieux Chene 38240 Meylan France Email: philippe.surbayrole@orange.com Lampin, et al. Expires 31 January 2026 [Page 30]