SCHC Context lifecycle and management

Terminology This section defines terminology and abbreviations used in this document. It extends the terminology of . 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.

SCHC Context Lifecycle Overview 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.

Relationship between Context, Profile and Data Model 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, 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. 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.

= Parsing = +---------+ +---------+ ============ | | | | | v | | *-*-*-*-*-*-*-*-*-*-*-* | | | Parsed Header Fields| | | *-*-*-*-*-*-*-*-*-*-*-* | | | v v v ================================= = Rule Matching and Compression = ================================= | v *-*-*-*-*-*-*-*-*-*-* | Compressed Packets| *-*-*-*-*-*-*-*-*-*-* ]]>

Instance Initialization and Context Provisionning 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. 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 , a Profile and a Context have already been loaded on end-point A.

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

Normal SCHC Operation 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.

Context modification 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: Rule addition Rule modification Rule deletion 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 RuleID not found Error during decompression (examples?) No valid Instance Detection of Context desynchronization and recovery ... Management traffic can also be compressed with SCHC using OAM Rules that are part of the Context (see section Management Rules).

SCHC Session end 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.

Management Rules 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).