]> Orange

quentin.lampin@orange.com

Consultant

Rue de Rennes Cesson-Sevigne 35510 France anaminaburo@gmail.com

RISE AB

Isafjordsgatan 22 Kista 16440 Sweden marco.tiloca@ri.se

IMT Atlantique

CS 17607, 2 rue de la Chataigneraie Cesson-Sevigne Cedex 35576 France Laurent.Toutain@imt-atlantique.fr

Internet SCHC Working Group Internet-Draft The idea of keeping option identifiers in SCHC Rules simplifies the interoperability and the evolution of SCHC compression, when the protocol introduces new options, that can be unknown from the current SCHC implementation. This document discuss the augmentation of the current YANG Data Model, in order to add in the Rule options identifiers used by the protocol.

Introduction Static Context Header Compression (SCHC) provides an essential mechanism for efficient communication in constrained networks by compressing protocol headers using predefined Rules. Originally developed for Low Power Wide Area Networks (LPWANs), SCHC has proven effective in scenarios with limited bandwidth, power constraints, and predictable traffic patterns. The YANG Data Model defined in was designed primarily for LPWAN technologies, focusing on highly constrained devices such as sensors and actuators that generate predictable traffic patterns, which allowed for static compression rules. This model also incorporates CoAP parameters defined in , representing CoAP options as specific Field Identifiers (FIDs) within SCHC Rules. While this approach works well in controlled LPWAN environments, it presents interoperability challenges when SCHC is applied to more dynamic networks or when protocols evolve to incorporate new options. The primary issue arises from the disconnection between protocol option identifiers and SCHC Field Identifiers (FIDs), making it difficult to efficiently handle newly defined or private options without disrupting existing implementations. This document proposes a more flexible approach to representing protocol options in SCHC YANG Data Models. By preserving original protocol option identifiers within SCHC Rules, we aim to:

• Improve interoperability between SCHC implementations
• Enable more graceful handling of protocol evolution
• Simplify Rule management between SCHC endpoints
• Support compression of newly defined or private options without requiring updates to the SCHC implementation

The following sections examine the current challenges in detail, explore potential solutions including both semantic and syntactic compression approaches, and propose extensions to the YANG Data Model that preserve protocol option identifiers while maintaining efficient compression capabilities.

Current Challenges The fundamental challenge in SCHC compression for protocols with options stems from how options are represented in the SCHC Data Model. Unlike the relatively static headers of IPv6 or UDP, CoAP includes a flexible options mechanism that allows for protocol extension through new options.

Option Representation Problem In the current SCHC Data Model defined in , CoAP options are represented as predefined Field Identifiers (FIDs) that are included in SCHC Rules. Each option is essentially abstracted away from its original protocol identifier and assigned a new SCHC-specific identifier. While this approach works adequately in static LPWAN environments where the set of options is known in advance and rarely changes, it creates significant challenges in more dynamic networks or when protocols evolve. The core problem is that the mapping between protocol option identifiers (as defined in the protocol specification) and SCHC FIDs is not standardized or predictable. When a new CoAP option is defined after a SCHC implementation is deployed, there is no straightforward mechanism for the implementation to assign an appropriate FID to this option or to communicate this assignment to other SCHC implementations.

Rule Management Challenges This limitation becomes particularly problematic in scenarios involving rule management between two SCHC endpoints. The following scenario (cf. ) illustrates this issue:

Rule Management between two SCHC end-points S1 <~~~~~~> S2 <-----> B ]]>

In this scenario:

• Device A generates CoAP packets that may include various options, including newly defined ones.
• SCHC nodes S1 and S2 compress and decompress the traffic using Rules they share.
• When A uses a newly defined or private option, S1 can parse this option (as the CoAP header structure remains consistent) and could potentially derive a new Rule to optimize compression.
• However, S1 faces a critical problem: how to identify this new option in the Rule and communicate this identifier to S2 in a way that S2 can understand which option is involved and correctly reconstruct the header.

For example, suppose a Rule defines just a CoAP header, and S1 derives a more specific Rule including a URI-path. The entry shown in can be added to the derived Rule, and defines appropriate identityref values (respectively fid:coap-option-uri-path, di:up, mo:equal and cda:not-sent) that can be used to communicate this Rule description to S2.

New entry added by management

However, when A uses a recently defined option or a private option that was not known when the SCHC implementation was created, S1 cannot represent this option using existing FIDs. While S1 can still parse the CoAP header and identify the new option, it has no predefined FID to use in the Rule, as shown in :

New entry added by management

Interoperability Consequences This disconnect between protocol option identifiers and SCHC FIDs creates several interoperability issues:

• Limited Protocol Evolution Support: New protocol options cannot be efficiently compressed without updates to the SCHC implementation.
• Incompatible Rule Exchanges: Different SCHC implementations may assign different FIDs to the same new option, making Rule exchange between them problematic.
• Implementation Complexity: SCHC implementations must maintain complex mappings between protocol options and FIDs, and these mappings may differ between implementations.
• Deployment Barriers: Deploying SCHC in environments with evolving protocols becomes difficult and requires frequent updates to SCHC implementations.

The fundamental issue is that the protocol option space and the SCHC FID space are disconnected, with no standardized or dynamic mapping between them. This disconnect seriously limits SCHC's applicability in dynamic environments and its ability to adapt to protocol evolution. In the following sections, we will explore two approaches to address this challenge. The first approach, termed 'syntactic,' aims to closely align with CoAP's native representation of options by defining three distinct fields: option delta type, option length, and option value. The second approach, called 'semantic,' abstracts away from the byte-level representation and introduces a generic option framework that eliminates the need for mapping between option values and Field IDs. This semantic approach focuses on the logical meaning rather than the protocol-specific encoding.

Syntactic compression

Overview of the Approach SCHC compression typically uses a semantic approach where protocol fields are abstracted into generic representations with Field IDs (FIDs) that don't directly correlate to the protocol's encoding format. While effective for static fields, this creates challenges for dynamic protocol options as previously discussed. Syntactic compression, as proposed in , takes a fundamentally different approach by aligning compression more closely with the protocol's wire format. Instead of abstracting away from the protocol's representation, syntactic compression preserves the original structure of protocol headers, including how options are encoded.

CoAP Option Encoding Background To understand syntactic compression for CoAP options, it's important to recall how CoAP encodes options in messages:

• Each CoAP option on the wire consists of three components:
  • Option Delta: The difference between the option number of the present option and the option number of the previous option (if any).
  • Option Length: The length of the option value in bytes.
  • Option Value: The actual option content.
• This encoding allows CoAP to efficiently represent options while maintaining extensibility.

Syntactic Representation of Options In the syntactic approach, instead of representing a CoAP option as a single abstract Field ID, each option is decomposed into its three constituent parts as shown in , where "x" in the Field Length of CoAP.value entry indicates the expected value:

representation of an elided option with syntactic representation

In this representation:

• 'CoAP.option' can represent either the absolute CoAP option number or the delta value as encoded in the CoAP message. While this choice affects how the parser is implemented, it has minimal impact on the overall performance of the compression approach being examined in this document.
• "CoAP.length" represents the option length field.
• "CoAP.value" contains the actual option value, noted "x".

This approach means that option identifiers remain in the CoAP numbering space rather than being converted to SCHC FIDs. This critical difference allows any option—existing, newly defined, or private—to be processed without requiring updates to the SCHC implementation's FID mapping. The syntactic approach offers several advantages. It provides robust support for protocol evolution, allowing new or private options to be compressed without requiring changes to SCHC implementations. It enhances interoperability since option identifiers remain in the protocol's numbering space, enabling different SCHC implementations to exchange rules for any option. Additionally, it simplifies implementation by eliminating the need for complex mappings between protocol option identifiers and SCHC FIDs. However, this approach also comes with notable disadvantages. It increases the number of entries required to describe each option by a factor of three, resulting in larger Rule representations. Furthermore, the syntactic approach may yield less efficient compression in certain scenarios, particularly when options must be sent rather than elided. For instance, in a semantic approach, only the value and potentially the length is sent as residue (cf. ):

representation of an option sent with semantic representation

The equivalent syntactic representation requires three entries, as shown in (cf. ):

representation of an option sent with syntactic representation

In this case, both the option number and length (which may be encoded in just 4 bits in the CoAP message) are treated as 16-bit fields that must be sent as residue. Additionally, the option length is effectively sent twice: once in the CoAP.length field and again as part of the value's residue. For example, a 4-byte option value would be encoded as follows in the syntactic approach:

• 0 bytes for the option number
• 2 bytes for the length field
• 0.5 bytes for the header of the value (in SCHC compressed format)
• 4 bytes for the actual value

This totals 6.5 bytes, compared to a more efficient representation in the semantic approach with 4.5 bytes. One potential optimization would be to define a new length function that links the length of the value to the content of the CoAP.length field, avoiding the duplicate transmission of length information. However, this would add complexity to the compression mechanism. Extending the Data Model to support the syntactic approach essentially involves creating three new Field Identifiers (FIDs) that correspond to the components of the option structure.

Conclusion While syntactic compression offers a more generic approach that can handle protocol evolution without requiring implementation updates, it may lead to suboptimal compression efficiency and larger Rule representations. The tradeoff between flexibility and efficiency must be carefully considered based on the specific deployment scenario and requirements. The syntactic approach demonstrates that staying too close to the byte-level representation of a protocol can compromise compression efficiency. This insight leads us to consider a hybrid approach that preserves the protocol's option identifiers while maintaining the efficiency of semantic compression, as discussed in the next section.

Semantic compression

The Proposed Approach Having examined the syntactic approach, which closely follows the byte-level representation of CoAP options, we now explore an alternative solution that maintains the efficiency of semantic compression while addressing the interoperability challenges. This approach preserves protocol option identifiers directly within SCHC Rules, eliminating the need for mapping between protocol-specific option numbers and SCHC Field Identifiers (FIDs). The core idea is to incorporate the original protocol identifiers into the compression Rules. Since multiple protocols may reuse the same option identifier for different purposes (for example, option 8 refers to Location-Path in CoAP but Timestamp in TCP), this approach associates each option value with its protocol namespace to avoid ambiguity.

Technical Solution The solution involves defining within SCHC an identity that references the protocol (creating a "protocol space"), followed by the specific option identifier used by that protocol. This preserves the protocol's native numbering scheme while allowing SCHC to differentiate between options from different protocols that might share the same option identifier. Using this approach, a Rule that includes various CoAP options would directly reference the CoAP option numbers rather than abstract FIDs. For instance, the representation of a URI with two path elements (option 11) and two query elements (option 15) might look like (cf. ):

Rule including options ID.

In this example, option identifiers 11 (URI-Path) and 15 (URI-Query) are directly specified, along with their position and direction, providing clear identification of which CoAP options are being compressed without requiring predefined FIDs for each option type.

Data Model Implementation Challenges While this approach offers clear advantages for interoperability and protocol evolution, implementing it within the current YANG Data Model defined in presents challenges. The current model defines Rule entries with a key composed of field-id, field-position, and direction-indicator, as shown in :

Rule entry defined by [RFC 9363].

The example shown in is not valid under this model because the combination of FID, position, and direction is repeated multiple times, which violates the key constraints. We cannot simply include the option value as part of the key in the existing structure. Furthermore, it's not possible to augment the model defined in RFC 9363 to add a new leaf to the key of the list. Adding option identifiers to all entries would also be inefficient, as many fields (such as IPv6 or UDP fields) don't require this additional context.

Proposed YANG Data Model Extension A more effective solution is to augment the current compression data model with a new list specifically designed for entries describing protocol options:

Augmentation of SCHC Data Model to include options ID.

In this augmented model:

• The space-id defines the protocol namespace (e.g., CoAP, TCP), with values provided by the SCHC Working Group
• The option-id contains the actual option identifier as defined in the protocol's IANA registry
• The remaining elements (field-length, field-position, etc.) function as they do in the standard entry structure, but they will be diffently identified.

This approach maintains the semantic efficiency of SCHC while eliminating the need for protocol-to-FID mappings.

Implications for Residue Serialization This design has implications for how residues are serialized. To ensure consistent interpretation, both SCHC endpoints must process entries in the same order. Therefore:

• Fields from the standard "entry" list MUST be serialized before those defined in the new "entry-option-space" list

*This constraint should be documented in to ensure interoperability This approach preserves the guideline from that Field Descriptors (entries) should be listed in the order they appear in the packet header.

Advantages of this Approach The proposed approach offers several significant benefits compared to both the current SCHC model and the syntactic approach:

• It maintains the efficiency of semantic compression while eliminating the mapping problem between protocol options and SCHC FIDs
• It enables straightforward handling of newly defined or private options without requiring updates to SCHC implementations
• It allows for cleaner Rule exchange between SCHC endpoints, improving interoperability in heterogeneous environments

This approach represents a balanced solution that addresses the interoperability challenges while preserving the compression efficiency that makes SCHC valuable in constrained environments.

Impact on Current Standards

Compatibility with Existing Standards The proposed extension to preserve protocol option identifiers in SCHC Rules has important implications for existing standards. Both and define specific Field Identifiers (FIDs) for CoAP options. These predefined FIDs and the proposed approach represent two different methods for identifying the same protocol elements, which creates potential compatibility issues.

Deprecation of Predefined CoAP Option FIDs To maintain consistency and avoid confusion between the two approaches, the predefined CoAP option identifiers in the current standards should be deprecated in favor of the more flexible option identifier approach proposed in this document. This deprecation should be handled carefully to ensure backward compatibility with existing implementations while enabling a clear migration path to the new approach.

Entry Order Requirements The proposed approach also highlights a constraint that was not explicitly included in the current Data Model. YANG does not impose a specific position for elements in a list, which has no impact on the compression process itself. However, the order becomes critical for the serialization of residues. When transmitting Rules from one endpoint to another, the order of Field Descriptors must be preserved to ensure consistent handling of residues. This requirement should be explicitly documented in to clarify that:

• The order of entries should not be changed when transmitted between endpoints This ordering preserves the guidance in that Field Descriptors (entries) should be listed in the order they appear in the packet header
• This ordering requirement becomes particularly important with the introduction of the new "entry-option-space" list, as both types of entries (standard and option-space) must be processed in a consistent sequence across all implementations.

The statement "ordered-by user;" MUST be included in a revision of .

References Normative References This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules. This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules. Informative References This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. Orange Taking the opportunity of a fresh implementation of SCHC by a newcomer to SCHC to reflect on the design principles and the implications on the implication of SCHC. Topics addressed: * The parser, as described in SCHC specification. * A discussion on parsing and interpretation. * Practical implications of the specification of the parser of SCHC. * the challenge and opportunity of a generic parser implementation able to handle any protocol stack and rules design to enable it. RISE AB IMT Atlantique Nokia Bell Labs Consultant This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document replaces and obsoletes RFC 8824. Acklio Cisco Systems Acklio This document defines the LPWAN SCHC architecture. GlobalPlatform n.d.

YANG Data Model This appendix defines the work in progress YANG Data Model to extend the Data Model defined in . WG List: Editor: Laurent Toutain Editor: Ana Minaburo "; description " Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. ************************************************************************* This module extends the ietf-schc module to include the compound-ack behavior for Ack On Error as defined in RFC YYYY. It introduces a new leaf for Ack on Error defining the format of the SCHC Ack and add the possibility to send several bitmaps in a single answer."; revision 2024-12-19 { description "Initial version for RFC YYYY "; reference "RFC YYYY: OAM"; } identity space-id-base-type { description "Field ID base type for all fields."; } identity space-id-coap { base space-id-base-type; description "Field ID base type for IPv6 headers described in RFC 8200."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } typedef space-type { type identityref { base space-id-base-type; } description "Field ID generic type."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } augment "/schc:schc/schc:rule/schc:nature/schc:compression" { list entry-option-space { key "space-id option-id field-position direction-indicator"; leaf space-id { type space-type; mandatory true; description ""; } leaf option-id { type uint32; } leaf field-length { type schc:fl-type; mandatory true; description "Field Length, expressed in number of bits if the length is known when the Rule is created or through a specific function if the length is variable."; } leaf field-position { type uint8; mandatory true; description "Field Position in the header is an integer. Position 1 matches the first occurrence of a field in the header, while incremented position values match subsequent occurrences. Position 0 means that this entry matches a field irrespective of its position of occurrence in the header. Be aware that the decompressed header may have position-0 fields ordered differently than they appeared in the original packet."; } leaf direction-indicator { type schc:di-type; mandatory true; description "Direction Indicator, indicate if this field must be considered for Rule selection or ignored based on the direction (bidirectional, only uplink, or only downlink)."; } list target-value { key "index"; uses schc:tv-struct; description "A list of values to compare with the header field value. If Target Value is a singleton, position must be 0. For use as a matching list for the mo-match-mapping Matching Operator, index should take consecutive values starting from 0."; } leaf matching-operator { type schc:mo-type; must "../target-value or derived-from-or-self(., 'mo-ignore')" { error-message "mo-equal, mo-msb, and mo-match-mapping need target-value"; description "target-value is not required for mo-ignore."; } must "not (derived-from-or-self(., 'mo-msb')) or ../matching-operator-value" { error-message "mo-msb requires length value"; } mandatory true; description "MO: Matching Operator."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see Section 7.3)"; } list matching-operator-value { key "index"; uses schc:tv-struct; description "Matching Operator Arguments, based on TV structure to allow several arguments. In RFC 8724, only the MSB Matching Operator needs arguments (a single argument, which is the number of most significant bits to be matched)."; } leaf comp-decomp-action { type schc:cda-type; must "../target-value or derived-from-or-self(., 'cda-value-sent') or derived-from-or-self(., 'cda-compute') or derived-from-or-self(., 'cda-appiid') or derived-from-or-self(., 'cda-deviid')" { error-message "cda-not-sent, cda-lsb, and cda-mapping-sent need target-value"; description "target-value is not required for some CDA."; } mandatory true; description "CDA: Compression Decompression Action."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see Section 7.4)"; } list comp-decomp-action-value { key "index"; uses schc:tv-struct; description "CDA arguments, based on a TV structure, in order to allow for several arguments. The CDAs specified in RFC 8724 require no argument."; } } } } ]]>

Examples This appendix provides practical examples that compare different approaches to representing protocol options in SCHC. The purpose of these examples is to demonstrate the operational implications of each approach in terms of Rule size, compression efficiency, and query performance.

Test Scenario and Methodology To provide a consistent basis for comparison, we use a common CoAP message containing various standard options along with one non-standard option (SCP82-Param). This example was chosen to illustrate how each approach handles both well-known and recently defined options. The following CoAP message serves as our reference example:

Example of a CoAP packet with options. Uri-path : b'accelerometers' > Uri-path : b'maximum' > Uri-query : b'date=today' > Uri-query : b'unit=m/s^2' > Accept : 60 > No-Response : 2 > SCP82-Param : b'TLV' ]]>

For each approach, we will evaluate three key metrics:

• Rule Size: The size of the CBOR-serialized compression rule in bytes
• Query Size: The size of the CORECONF query payload needed to access specific values in the rule
• Compressed Packet Size: The size of the resulting SCHC-compressed packet in bytes

In all examples, our compression rule will send residues for the Uri-Path, Uri-Query, and SCP82-Param options, while eliding the rest. This allows us to compare how different approaches handle both sent and not-sent options.

Approaches Compared We evaluate the following approaches to option representation:

• Semantic Compression with RFC 9363: The current approach using predefined Field IDs for known options
• Universal Options: Our proposed approach preserving protocol option identifiers Merged Data Model: A combined approach that integrates both methods into a single data model
• Ordered SID Allocation: An optimized version with carefully arranged SID values
• Syntactic Compression: The approach using delta-type, length, and value fields

Each approach represents a different balance between compatibility, flexibility, and efficiency. The examples will demonstrate these trade-offs quantitatively. Let's examine each approach in detail:

Semantic compression Semantic compression is the approach currently defined in , where each protocol field is assigned an abstract Field Identifier (FID) that represents its semantic meaning rather than its wire format. This section examines how this approach handles our example CoAP message.

Rule Definition Using RFC 8724's informal notation, a rule matching our sample packet would be structured as follows:

Target rule.

Implementation with RFC 9363 When implementing this rule using the RFC 9363 Data Model, we encounter a fundamental limitation: there is no identity reference (identityref) defined for the CoAP SCP82-Param option in the current standard. This illustrates the core problem addressed in this document – the inability to represent new or protocol-specific options without updating the SCHC implementation. For the purpose of this comparison, we'll assume that a theoretical extension to RFC 9363 has been created that defines identityrefs for the options in , with corresponding SID ranges: RFC 9363 SIDs starting at 5000 and SIDs starting at 10000.

CBOR Serialization With these assumptions, the rule can be serialized in CBOR format. The resulting message is 357 bytes long .

CBOR serialisation.

The diagnostic representation provides insight into the structure of this serialized rule:

CBOR diagnostic notation.

Note that the encoding of rule-id-value, rule-id-length, and rule-nature is not optimal because the delta values are higher than 23, requiring 2 bytes each in the CBOR encoding.

CORECONF Query Example To access the target value of the Accept option in this rule, a CORECONF query would be structured as follows. The size of the CoAP payload for this query is 14 bytes:

CORECONF query to Accept TV. (Content-Format: application/yang-identifiers+cbor-seq) [5115, / .../target-value/value 1, / rule-id-value 8, / rule-id-length 5028, / fid-coap-option-accept 1, / field-position 5019, / direction-indicator 0] / target-value/index ]]>

Compressed Packet When applied to our sample CoAP message, the semantic compression approach produces a SCHC packet of 389 bits (49 bytes with byte alignment):

SCHC compressed packet.

Analysis The semantic compression approach demonstrates both significant strengths and notable limitations. On the positive side, it achieves an efficient compressed packet size of only 49 bytes, making it suitable for constrained networks where bandwidth is at a premium. The query size is also relatively small at 14 bytes, which enables efficient rule management operations. Additionally, the semantic representation of fields provides clarity by abstracting protocol details into meaningful identifiers. However, this approach faces important limitations that impact its flexibility. Most critically, it cannot handle new options without predefined Field Identifiers, which creates a dependency on standards updates. When new protocol options emerge, the approach requires formal extension of the standard to define appropriate identifiers, creating potential delays and compatibility issues. While the rule serialization size is moderate at 357 bytes, this still represents significant overhead in highly constrained environments. These limitations illustrate why semantic compression works well in static, predictable environments but presents challenges for protocol evolution and interoperability in more dynamic contexts where protocols frequently evolve.

Universal Options The Universal Options approach preserves protocol option identifiers directly within SCHC Rules, eliminating the need for predefined Field Identifiers for each option type. This section examines how this approach handles our example CoAP message.

Implementation Approach In this approach, we assign SIDs starting from 7000 to the YANG Data Model augmentation defined in this document. All CoAP options are represented by a combination of a space ID (indicating the protocol namespace, in this case CoAP) and the option identifier as used in the CoAP protocol. This allows the SCP82-Param option to be processed like any other option, regardless of whether it was defined when the SCHC implementation was created.

CBOR Serialization The CBOR serialization of the rule using the Universal Options approach is 481 bytes long:

CBOR serialisation.

The diagnostic representation of the CBOR message is the following:

CBOR serialisation.

It's important to note that in the CoAP options part, the delta values are very large and require 3 bytes each for CBOR encoding. This is because we've used a separate range of SIDs for the augmentation, following the standard allocation procedure where each YANG Data Model has its own SID range.

CORECONF Query Example A CORECONF query to access the target value of the Accept option in this approach would be structured as follows. The size of the CoAP payload is 15 bytes:

CORECONF query to Accept TV. (Content-Format: application/yang-identifiers+cbor-seq) [7019, / .../target-value/value 1, / rule-id-value 8, / rule-id-length 7002, / space-id-value 17, / option-id 1, / field-position 5019, / direction-indicator 0] / target-value/index ]]>

Compressed Packet When applied to our sample CoAP message, the Universal Options approach produces a SCHC packet with the same size as the semantic approach: 49 bytes with byte alignment.

Analysis The Universal Options approach demonstrates several important characteristics when compared to the semantic approach. The primary advantage of this approach is its flexibility and future-proofing. By preserving the protocol's native option identifiers, it can handle any option—including newly defined or private options—without requiring updates to the SCHC implementation. This is particularly evident in how it handles the SCP82-Param option (2055) without requiring predefined Field Identifiers. The compressed packet size remains efficient at 49 bytes, identical to the semantic approach, demonstrating that flexibility doesn't come at the cost of compression efficiency at the packet level. However, there are trade-offs. The CBOR serialization of the rule is significantly larger at 481 bytes compared to 357 bytes for the semantic approach. This increased size is primarily due to the additional information needed to represent both protocol space identifiers and option values, along with less efficient delta encoding due to SID allocation in separate ranges. The query size is also slightly larger (15 bytes vs. 14 bytes), though this difference is minimal. Overall, the Universal Options approach provides significantly improved flexibility and interoperability at the cost of larger rule serialization size. This trade-off may be acceptable in many applications, particularly where protocol evolution and interoperability are more critical than rule storage efficiency.

Merged Data Model Approach The Merged approach combines elements from both the semantic compression and Universal Options approaches into a single, unified YANG Data Model. This section examines how this integrated approach handles our example CoAP message.

Implementation Approach Instead of maintaining two separate Data Models (RFC 9363 and Universal Options), this approach merges them into a single model, which we'll refer to as "9363bis." The SID allocation process remains unchanged, with SIDs allocated automatically based on alphabetical ordering of nodes in the YANG model. The key advantage of this approach is that it provides a unified framework that can represent both predefined fields using semantic compression and protocol-specific options using the Universal Options approach.

CBOR Serialization The CBOR serialization of the rule using the Merged approach is 400 bytes in size:

CBOR serialisation.

The diagnostic representation reveals the structure of this serialized rule:

CBOR serialisation.

It can be observed that some delta values are higher than 23, requiring 2 bytes for their encoding in CBOR. This is a result of the automatic SID allocation based on alphabetical ordering, which doesn't optimize for efficient deltas.

CORECONF Query and Compressed Packet The CORECONF query and compressed packet sizes remain consistent with previous approaches. The query size is 15 bytes (similar to the Universal Options approach), and the compressed packet size remains at 49 bytes.

Analysis The Merged Data Model approach offers an interesting middle ground between the semantic and Universal Options approaches. By combining both approaches in a single model, it provides the benefits of compatibility with existing semantic compression while adding the flexibility to handle new or protocol-specific options. The CBOR serialization size (400 bytes) falls between the semantic approach (357 bytes) and the Universal Options approach (481 bytes), reflecting its hybrid nature. This represents a reasonable compromise that balances compatibility, flexibility, and efficiency. A key advantage of this approach is its unified framework, which eliminates the need to choose between different compression approaches. Implementations can leverage semantic compression for well-known fields while still maintaining the ability to handle any new protocol options through the Universal Options mechanism. However, the automatic SID allocation based on alphabetical ordering leads to some inefficiency in delta encoding. As shown in the diagnostic representation, some delta values require 2 bytes for encoding, which increases the serialization size. This suggests that further optimization of SID allocation could improve efficiency, which is explored in the next approach. Overall, the Merged approach offers a pragmatic solution that balances the strengths of both semantic and Universal Options approaches while mitigating some of their respective limitations. It provides a path forward that maintains backward compatibility while enabling future extensibility.

Ordered SID Allocation Approach The Ordered approach represents a further optimization of the Merged approach through strategic manual allocation of SIDs. While it uses the exact same YANG Data Model as the Merged approach, it differs in how SIDs are assigned to the nodes in the model.

Implementation Approach In standard YANG Data Models, SIDs are typically allocated automatically based on alphabetical ordering of nodes or through sequential assignment. This automatic allocation, while convenient, often produces suboptimal delta values when serializing CBOR-encoded rules. The Ordered approach intervenes in this process by manually editing the SID file to optimize delta values specifically for CBOR encoding efficiency. By carefully arranging SIDs to ensure that frequently used nodes have closely related values, this approach minimizes the number of bytes required to encode the deltas between adjacent SIDs in the CBOR representation.

CBOR Serialization The CBOR serialization of the rule using the Ordered approach is 376 bytes in size:

CBOR serialisation.

The diagnostic representation shows how this approach affects the delta values:

CBOR serialisation.

The key innovation in this approach is visible in the diagnostic representation: by carefully arranging SIDs, many of the delta values are now negative numbers with small absolute values. In CBOR, small integers (both positive and negative) can be encoded in a single byte, leading to significant space savings compared to the larger deltas in the Merged approach.

SID Allocation Strategy The SID allocation file was manually edited to optimize delta values, as shown in the excerpt below:

CBOR serialisation.

The allocation strategy focuses on several key principles:

• Grouping related nodes with consecutive SIDs to minimize delta values
• Positioning frequently used nodes strategically to ensure small deltas
• Using both positive and negative deltas to maximize single-byte encoding opportunities
• Arranging rule-related fields to minimize the encoding size of rule metadata

CORECONF Query and Compressed Packet As with previous approaches, the CORECONF query size (15 bytes) and compressed packet size (49 bytes) remain consistent. The optimization affects only the rule serialization size, not the operational efficiency of queries or the compression ratio of actual packets.

Analysis The Ordered SID Allocation approach demonstrates the significant impact that strategic SID assignment can have on rule serialization efficiency. By reducing the CBOR serialization size from 400 bytes in the Merged approach to 376 bytes, it achieves a 6% reduction in size while maintaining identical functionality and compatibility. This approach is particularly noteworthy because it achieves this efficiency gain without any changes to the YANG Data Model itself—only the SID allocation is modified. This makes it a non-invasive optimization that can be applied to existing models without affecting their structure or semantics. The resulting serialization size (376 bytes) is only slightly larger than the original semantic approach (357 bytes), while maintaining all the flexibility benefits of the Universal Options approach. This represents an excellent compromise that nearly eliminates the size penalty of the more flexible approach. The Ordered approach demonstrates that thoughtful SID allocation can significantly improve encoding efficiency for CBOR-serialized SCHC Rules. This optimization technique could be valuable in constrained environments where rule transmission and storage efficiency are critical concerns.

Syntatic compression The syntactic approach processes all options uniformly by decomposing each CoAP option into its constituent components. Rather than treating an entire option as a single field, this approach treats the delta type, length, and value components that make up a CoAP option as separate fields. While the core compression algorithm remains unchanged, the parsing phase must be modified to accommodate this decomposed representation of the header. From a Data Model perspective, three new Field Identifiers (FIDs) need to be defined. The specific SID values assigned have minimal impact since they function purely as identifiers without CORECONF delta encoding considerations.

Rule specification As shown in the transition from to , the Field Position (FP) parameter plays a crucial role in maintaining the proper ordering of these option components.

Target rule.

A notable limitation of this approach concerns the SCHC Field Length of the 'CoAP Length' fields, which restricts the rule's applicability. For example, the first Uri-path option requires 8 bits, instead of 4, for its Field Length because the value 'accelerometers' is 14 bytes long, necessitating the escape value 0xD to encode the length on an additional byte. Consequently, if shorter values need to be handled, separate rules would be required.

Compressed packet The compression residue with the rule ID is 409 bit-long or 52 byte-long with the alignment (see ).

SCHC compressed packet.

The increased size of the syntactic approach is primarily due to redundant transmission of option lengths. The length information must be sent twice: first to reconstruct the 'CoAP Length' field in the option header, and again to specify the size of the 'CoAP Value' residue. This duplication contributes significantly to the lower compression efficiency compared to other approaches.

CORECONF Query Example A CORECONF query to access the target value of the Accept with is in fith position. The size of the CoAP payload is also 14 bytes:

CORECONF query to Accept TV. (Content-Format: application/yang-identifiers+cbor-seq) [5115, / .../target-value/value 9, / rule-id-value 8, / rule-id-length 8003, / fid-coap-value (from another YANG DM) 5, / field-position 5019, / direction-indicator 0] / target-value/index ]]>

CBOR Serialization The serialization uses the manually assigned sid to minize the representation. The result is 718 byte-long.

Summary

Acknowledgments The authors sincerely thank This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.