| Internet-Draft | Context Lifecycle | May 2025 |
| Dumay | Expires 24 November 2025 | [Page] |
Static Context Header Compression and fragmentation (SCHC) framework provides both a header compression mechanism and an optional fragmentation mechanism.¶
SCHC operation is based on a common static Context stored at the two (or more) ends of a communication. As the scope of SCHC becomes broader, the static Context needs to evolve towards a more dynamic Context.¶
This purpose of this document is to initiate a discussion on the lifecycle of a Context. It describes the main steps in the lifecycle of a SCHC Context, and more broadly, it aims at documenting the related Requirements and Terminology for the proper use of SCHC. These goals are in line with the Working Group's objectives, as set out in the Charter:¶
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 24 November 2025.¶
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 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.¶
The SCHC Working Group is tasked with extending the benefits of the [RFC8724] SCHC technology beyond Low-Power Wide-Area (LPWA) networks for which it was originally designed. The compression and fragmentation mechanisms described in [RFC8724] are based on a shared static Context between entities participating in the same communication.¶
A Context contains a set of rules that specify how messages are to be compressed/decompressed and/or fragmented/reassembled.¶
The new SCHC roadmap requires an evolution in the concept of Context, which must be able to adapt to a dynamic environment.¶
This brings new challenges, in particular maintaining Context synchronization between end-points. Indeed, Context synchronization is a prerequisite for ensuring proper communication between two (or more) SCHC end-points.¶
This document provides a starting point for discussion on how to manage the various steps in a dynamic Context's lifecycle:¶
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. and indicate requirement levels for compliant SCHC implementations.¶
This section defines terminology and abbreviations used in this document. It extends the terminology of [RFC8724].¶
Rule : A description of the header fields to be compressed/decompressed or fragmented/reassembled, and the operations to be performed on the fields.¶
Context / Set of Rules : A context, also known as Set of Rules, contains one or more Rules of various types such as compression, no compression, fragmentation, and management.¶
Profile: A Profile indicates a particular set of parameters. Both ends of a SCHC communication must be provisioned with the same Profile information and with the same Context before the communication starts, so that there is no ambiguity in how they expect to communicate. Profile parameters are for example the RuleID numbering scheme (fixed-size or variable-size RuleIDs), the fragmentation-related settings, the list of protocols to be processed within the present SCHC Session, and the associated data model(s).¶
Instance: The SCHC Instance is defined by a Profile and Context pair, selected and parameterized for a given communication. In particular, the Context includes customized Target Values needed to compress/decompress headers, or to fragment/reassemble a packet.¶
Instance Manager: The Instance Manager is in charge of creating a SCHC Instance, i.e. loading a Profile and a Context with the appropriate initial parameters/values for a given communication.¶
Session: The SCHC Session is an active relationship between hosts sharing the same Instance. The session between two end-points whose Instances are static is implicit. Otherwise, a Session is a dynamic space with a beginning and an end.¶
Context Manager: The Context Manager is in charge of managing the Context within a SCHC Instance, in particular handling Rule modifications during a SCHC Session.¶
Parser : A parser analyzes and interprets packets. Its main role is to break them down into understandable and structured elements such as fields, allowing for the processing or extraction of relevant information. A given protocol can be broken down in different manners depending on the Parser used, and/or the underlying data model, potentially leading to different SCHC processing (different Rules).¶
Data Model : A Data Model allows a formal description of the format of packets to be processed with SCHC, as well as a formal description of Rules. Relying on formal models facilitates Context provisioning and interoperability between SCHC nodes.¶
The SCHC Context is the foundation on which all SCHC operations are based. In this document, we describe the different lifecycle steps of a Context, in a static and dynamic environment, and we aim to identify the key elements for the efficient operation of SCHC, in particular to ensure that the Context remains synchronized between end-points. We study the interactions of the Context with related entities (Profile, Data Models) and how the Context Manager enables updates so the Context remains adapted to the target communication.¶
In this section, we take a closer look at the notions of Profile, Context and Data Model, as well as the relationships between these entities.¶
A SCHC Profile defines the features, scope, and parameters, of the SCHC operation for a communication between two (or more) end-points. The parameters that are present in the SCHC Profile are for example the RuleID numbering scheme (fixed-size or variable-size RuleIDs), the fragmentation-related settings, the list of protocols to be processed within the present SCHC Session (scope), and the associated Header Data Model(s). The SCHC Profile then serves as the basis for setting up an adequate Context, i.e., for selecting and adapting relevant Rules for the communication.¶
The Context contains the Rules that define SCHC operation for a given communication.
These Rules can be of different natures such as compression, no compression,
fragmentation, and management.
Compression Rules all have the same format: a Rule is a list of Field Descriptors
composed of a Field Identifier (FID), a Field Length (FL), a Field Position (FP),
a Direction Indicator (DI), a Target Value (TV), a Matching Operator (MO),
and a Compression/Decompression Action (CDA).
However, the content of compression Rules is specific to the protocols to which compression applies.
Prior to the SCHC operation, a protocol Parser identifies the fields encountered in the headers to be
compressed and labels them with a Field ID. The way the Parser analyzes header fields
(e.g. semantic or syntactic) depends on the Data Model(s) considered in the Profile and it results in a specific list of FieldsIDs.
Within a Rule, Field Descriptors are listed in the order in which fields are returned by the Parser,
and indicate their length and position, the functions to be applied to these fields for
compression and decompression, etc.¶
Data Models are an important part of the SCHC ecosystem, to ensure interoperability
between SCHC end-points, in particular the compatibility of Parsing at both ends of
the communication. Data Models serve as a common reference to indicate how the header of
a given protocol should be represented, and consequently the structure of the associated Rules.
In addition, [RFC9363] defines a Data Model for SCHC Rules.
It allows to check the validity of the format of Rules in a Context.
The name and version of the Data Models used are provided in the Profile.¶
Figure 1 shows the relationship between Data Models, Context, Profile, and how they feed the Parser and the SCHC Engine to achieve the Compression of incoming Packets. The targeted protocol stack is IP/UDP/CoAP, we assume that the header structure of each protocol is described in separate Data Models. This modularity allows to select the desired Data Model for each protocol, for example a syntactic or a semantic model for CoAP representation.¶
+-------------+
| CoAP Header |
| Data Model |
+-------------+ |
| UDP Header | |
| Data Model | |
+-------------+ +-------------+ |-+
| SCHC Rules | | IP Header | |
| Data Model | | Data Model | |
| | | |-+
| | | |
| | | | *-*-*-*-*-*
+-------------+ +-------------+ | Packets |
| | | | *-*-*-*-*-*
v v | | |
+---------------+ | | |
| Generic Rules | | +------------+ |
+---------------+ | | |
| | | |
v v v v
+---------+ +---------+ ============
| Context | | Profile |----> = Parsing =
+---------+ +---------+ ============
| | |
| | v
| | *-*-*-*-*-*-*-*-*-*-*-*
| | | Parsed Header Fields|
| | *-*-*-*-*-*-*-*-*-*-*-*
| | |
v v v
=================================
= Rule Matching and Compression =
=================================
|
v
*-*-*-*-*-*-*-*-*-*-*
| Compressed Packets|
*-*-*-*-*-*-*-*-*-*-*
This section explains how a SCHC Instance is initialized before a communication is started.¶
In the context of LPWANs, the expectation is that SCHC Rules are associated with a physical device that is deployed in a network, the traffic flows to be processed are known in advance. Pre-configured Profile and Context are loaded on both end-points (for example statically on the Device side and dynamically on the SCHC gateway side), which contain the same parameters.¶
In an unconstrained environment, Profile and Context may be loaded either statically or dynamically, e.g. from an online library where generic or specific Profiles and Contexts are published to a reachable repository, and uniquely identified using Uniform Resource Names and versionned. Generic Profiles and Contexts must be adapted to the communication, in particular by customizing Target Values.¶
According to the application/communication needs, the Instance Manager of the end-point initiating the communication may select a corresponding Profile and Context. They are obtained either locally or online, or they can retrieve the Profile and Context directly from the partner end-point. An end-point can advertise the support of SCHC, as well as the Profile(s) and Context(s) it owns, and/or intends to use.¶
A three-way handshake is performed, similarly to the TCP handshake,
in order to synchronize the Profile and Context information.
Figure 2 shows the generic steps of this handshake.
The first step consists of one end-point sending an advertisement message with its SCHC preferences or capabilities.
The other end-point may reply with an acknowledgement and additional parameters so that the interlocutor can fine-tune his Context.
Finally, the end-point that initiated the handshake concludes the transaction with an acknowledgement, then the SCHC operation can start.
The handshake may include additional steps corresponding to the loading of a Context on a given end-point from a remote location,
for example from an external repository or directly from the other end-point.
This loading procedure can take place before or during the advertisement phase and may happen twice,
once for each end-point.¶
In Figure 2, a Profile and a Context have already been loaded on end-point A.¶
End-point A End-point B Repository
| | |
| SCHC Profile | |
| Advertisement | |
|============================>| |
| | |
| +---------------------------------+
| | |Opt | |
| | | | |
| | | Retrieve Profile | |
| | | and Context | |
| | |============================>| |
| | | | |
| | | Content | |
| | |<============================| |
| | | | |
| Acknowledgement, +---------------------------------+
| Additional Parameters | |
|<============================| |
| | |
| Acknowledgement | |
|============================>| |
| | |
| | |
Once the end-points have agreed on the Profile, Context and parameters, an identical SCHC Instance exists on both sides. Since several SCHC Instances can co-exist within the same end-point, each instance has an Instance ID.¶
In the case of a static Instance or when an Instance is resumed, the Instance ID is sent in theadverstisement. This allows you to check the validity of an instance without having to send all the Profile parameters.¶
An empty advertisement may also be sent in order to ask for the capabilities of the second end-point. It responds by sending the parameters of its preferred Profile and the associated Context parameters. Finally, the first end-point concludes the handshake by sending an Acknowledgement, and additional parameters if necessary.¶
This section describes the normal operation of SCHC when no rule modification is needed.¶
At the sender side, the Parser analyzes packets to be sent and creates a list of fields that is processed by the SCHC Engine, i.e. the Context is browsed to find matching Rules. When several Rules match the field list, implementation must choose one (this is not specified in the standard). The selected matching Rule is used to compress and/or fragment the packet, the rule identifier (RuleID) is transmitted together with the compression residue or fragments to the recipient. When no Rule matches the field list, the No Compression Rule is used (the corresponding RuleID is added in front of the original packet).¶
Based on the RuleID and the residue/fragments received, the recevier uses the SCHC Decompression or Reassembly functions to rebuild the original packet and forwards it in its uncompressed form to the Application or to the next layer or next hop.¶
This section explains how a Context can be modified to fit the traffic all along the communication process.¶
A Context should be dynamically configurable using a network management protocols in order to adapt to in order to adapt to changing traffic patterns and characteristics. Netconf, Restconf and Coreconf are candidate management protocols, suited for specific use cases.¶
Common operations on a SCHC Context are:¶
The Context Manager is also responsible for:¶
Verifying and respecting the rights specified in the related ACLs¶
Checking for compliance with the Data Model¶
Handling errors¶
Management traffic can also be compressed with SCHC using OAM Rules that are part of the Context (see section Management Rules).¶
SCHC Instance (Profile and Context) end-of-life¶
The end of a SCHC Session can be explicit (by sending a SCHC control message) or implicit (reset message received from another layer, timeout).¶
All data associated with this instance should be deleted on all end-points.¶
Signaling (control), configuration, and error messages are exchanged between SCHC end-points in order to allow proper SCHC operation. These messages may use CORECONF which is based on YANG data models, uses CoAP for message exchange and CBOR encoding.¶
Specific OAM Sets of Rules should be locally installed on SCHC end-points or available on an online library, to define how to compress the management traffic (e.g. CORECONF messages).¶
(This appendix to be deleted by the RFC editor.)¶