SCHC Minimal Architecture

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:¶

                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:¶

• 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). ¶

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.¶

     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.¶

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:¶

      +----------------+
      | 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:¶

• 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.¶

            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.¶

• 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.¶

           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.¶

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.¶

• 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.¶

        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       |
                                    +-------------------------------+

   Endpoint A                                  Endpoint B
+------------------+                      +------------------+
|  SCHC Instance   | <---           ----> |  SCHC Instance   |
+------------------+     \         /      +------------------+
                          \       /
                           Session
                          /       \
+------------------+     /         \      +------------------+
|  SCHC Instance   | <---           --->  |  SCHC Instance   |
+------------------+                      +------------------+
   Endpoint C                                  Endpoint D

                           Domain Manager
                   +----------------------------+
                   |                            |
                   | +----------+  +----------+ |
                   | | Endpoint |  |  Context | |
           +-------+>|  Manager |  |  Manager | |
           |       | +----------+  +----------+ |
           |       +--------------------+-------+
  Register |                            |
  Endpoint |   +------------------------+
           |   |  synchronize Context(es)
           v   v
  +-----------------+   +------------------+   +----------------+
  |    Endpoint A   |   |    Endpoint B    |   |   Endpoint ... |
  +-----------------+   +------------------+   +----------------+

   +------------------------------------------------------------+
   |                                                            |
  +-+                       +-------------+                    +-+
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  |                    +-+
   |                        +-------------+                     |
   |                                                            |
   +------------------------------------------------------------+

                               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

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, <https://datatracker.ietf.org/doc/html/draft-ietf-schc-architecture-04>.

[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, <https://datatracker.ietf.org/doc/html/draft-toutain-schc-coreconf-management-00>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8724]

Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, <https://www.rfc-editor.org/info/rfc8724>.

[RFC8824]

Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, <https://www.rfc-editor.org/info/rfc8824>.

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, <https://www.rfc-editor.org/info/rfc9363>.

A.1. Changes from -00 to -01

• Initial version¶