]> 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) enables efficient communication in constrained networks by compressing protocol headers using predefined Rules. This document proposes improvements to how SCHC handles protocol options, as for CoAP (Constrained Application Protocol). The Data Model defined in was written based on LPWAN technologies while the working group was developing a solution for those devices. When the was developed, the group targeted devices such as sensors and actuators with very constrained resources but these devices have very predictable traffic leading to very static rules. Also, the data model includes CoAP parameters defined in .

Current Challenges Since CoAP is a more flexible protocol compared to IPv6 (without extensions) or UDP, given that CoAP includes options. The data model redefined these options as identifiers that are included in SCHC Rules as Field ID (FID). If this approach was acceptable for LPWAN technologies that have a static and controlled environment, the generalization of SCHC to more dynamic environment is a source of interoperability issues. Even though, this solution will become more accurate when rule management between two end-points in a SCHC instance is used to optimize compression. The following scenario (cf. ) illustrates this issue and assumes that the traffic is CoAP based, even if this can be extended to other protocols with options.

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

In this scenario: * Device A generates CoAP packets with various options. * SCHC nodes S1 and S2 compress and decompress the traffic using shared Rules. * When A uses a newly defined or private option, S1 can derive new Rules to optimize compression, including this option. * The challenge lies in communicating these new Field IDs (FIDs) to S2 Suppose that a Rule defines just a CoAP header, and a more specific Rule is derived including a URI-path. The entry (cf. ) is present in the derived Rule. defines identityref for several elements, (respectively fid:coap-option-uri-path, di:up, mo:equal and cda:not-sent) that can be used to send the Rule description to the other side.

New entry added by management

Now suppose that A uses a recently defined option or a private option. In S1, nothing is changed, the CoAP header is parsed, the new option is discovered, and a Rule is derived to compress the option. The only blocking element is the identification of this new FID in the Rule and how S1 sends it to the other end-point to understand which option is involved (cf ) and what is the value for reconstructing the header.

New entry added by management

In fact, the way FIDs are allocated using a YANG Data Model cannot be used when some fields are defined after the SCHC implementation. The Parser will identify this new option since the structure in the header remains the same. The compression and decompression do not need to be modified, since it is based in generic procedure. The problem is related to FID allocation, internally to the SCHC implementation and to the Data Model to exchange Rules with other implementations. The protocol option space and the SCHC FID space are not correlated, this leads to an interoperability issue.

Syntactic compression SCHC compression is semantic, field ID are abstracted in a generic representation composed of a field ID, a position, and a direction. For instance, when a CoAP option is sent on the wire, the option is coded as a delta option, a length value and the value. All these information is found in the abstract description. The delta option allows to find the option number which is turned into a SCHC FID, the length is taken from the option as the associated value. As stated before, the mapping between the option number and the FID must be known and failed if the option is new to the SCHC implementation. To avoid the mapping between a protocol ID and a SCHC ID proposed, to stay closer to the protocol syntax and define Rules that will take into account the option format. So, an option will be described in 3 fields (cf. ):

representation of an elided option with syntactic representation

Where option could be either the absolute CoAP option number or the delta as it appears in the CoAP message. This way, the option remains in the CoAP numbering space and every option is processed the same way and upcoming options will also be compressed. Nevertheless, this encoding multiply by three the number of entries to describe an option, leading to a larger representation of the Rule. If this description works well when the field is elided with not-sent CDA, the compression is more complex when the option must be sent. For instance (cf. ):

representation of an option sent with semantic representation

will be transformed into (cf. ):

representation of an option sent with syntactic representation

In that case, the option or the length coded from 4 bits to 16 bits may be viewed as a 16-bit field that has to be sent as residue. The option length has to be sent twice, the first time in the CoAP.length field and a second time in the residue of the value. To avoid this, one option could have been to define a new length function, linking the length of the value to the content of the CoAP.length field. Without this optimization, if we want to keep it generic, an option of 4 bytes, will be coded 2+2+0.5+3 = 7.5 bytes. Having generic compression schemes is interesting and this work needs to continue to be investigated, but going too close to the byte representation may lead to suboptimal compression and Rule representation.

Options ID The idea of keeping protocol identifiers in SCHC Rules simplify the interoperability and the evolution of SCHC compression, when the protocol evolves. One solution is to use these identifiers in the compression Rules. Since several protocols may reuse the same values. For instance, option 8 refers to Location-Path in CoAP and Timestamp in TCP. The value must be associated with the protocol to avoid ambiguities. One solution could be to define in SCHC an identity referring to the protocol, followed by the value used by this protocol. The tree (cf. ) shows how compression rules are defined in the YANG Data Model :

Rule entry defined by [RFC 9363].

An entry is defined by a key composed of the field-id, a field-position and the direction indicator. This branch of the tree cannot be augmented with a new leaf containing the option value and the field-id set to an identifier specifying the CoAP options. For instance, the representation of an URI with two path elements (11) and two query elements (15):

Rule including options ID.

Is not valid regarding the Data Model, since the key FID, position, direction is repeated four times on the example. The option itself must be included as a key. It is not possible to augment the model defined in RFC 9363 and add this leaf to the key of the list. Having this element on all entries is not also optimal. It looks better to augment the current compression data model with another list containing entries describing options.

Augmentation of SCHC Data Model to include options ID.

The space-id defines the protocol space, this value may be provided by the SCHC WG and option-value is taken from the protocol space maintained by IANA. This will have an impact on the serialization of residues. Both ends must have the entry in the same order. So Field from “entry” list MUST be serialized before the ones defined in “entry-option-space”.

Impact on current standards and define some FID for CoAP options. This leads to have similar Rule but they are incompatible. CoAP option identifier should be deprecated. This leads also to a constraint that has not been included for the Data Model. The order of the Field Descriptors is not specified as YANG do not impose a position in a list. This has no impact on the compression process but is important for the serialization. The should document the fact that entry ordrer should not be changed when transmitted from one end-point to the other. So, this allow to keep the indication of to keep Field Descriptors (aka entries) listed in the order they appear in the packet header.

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.

YANG Data Model This appendix defines the work in progress YANG Data Model to extend the Data Model defined in . file "ietf-schc-opt@2024-12-19.yang" module ietf-schc-opt { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-schc-opt"; prefix schc-opt; import ietf-schc { prefix schc; } organization "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; contact "WG Web: 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-value field-position direction-indicator"; leaf space-id { type space-type; mandatory true; description ""; } leaf option-value { type uint32; } leaf field-length { type union { type uint8; 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."; } } } } ]]>

Acknowledgments The authors sincerely thank