SCHC Working Group A. Minaburo Internet-Draft Consultant Intended status: Standards Track M. Tiloca Expires: 27 July 2025 RISE AB L. Toutain IMT Atlantique 23 January 2025 Options representation in SCHC YANG Data Models draft-toutain-schc-universal-option-00 Abstract 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. Status of This Memo 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 27 July 2025. Copyright Notice 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 Minaburo, et al. Expires 27 July 2025 [Page 1] Internet-Draft SCHC for CoAP January 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Current Challenges . . . . . . . . . . . . . . . . . . . . . 2 3. Syntactic compression . . . . . . . . . . . . . . . . . . . . 4 4. Options ID . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Impact on current standards . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. YANG Data Model . . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. 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 [RFC9363] was written based on LPWAN technologies while the working group was developing a solution for those devices. When the [RFC9363] 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 [RFC8824]. 2. 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. Minaburo, et al. Expires 27 July 2025 [Page 2] Internet-Draft SCHC for CoAP January 2025 The following scenario (cf. Figure 1) illustrates this issue and assumes that the traffic is CoAP based, even if this can be extended to other protocols with options. rule mngt +----------+ | | v v A <-------> S1 <~~~~~~> S2 <-----> B Figure 1: Rule Management between two SCHC end-points 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. Figure 2) is present in the derived Rule. [RFC9363] 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. +--------------+-----+---+----+-------+-------+---------+ | FID | FL | FP| DI | TV | MO | CDA | +==============+=====+===+====+=======+=======+=========+ | ... | ... |...|... | ... | ... | ... | |CoAP.Uri-path | len | 1 | up | value | equal | not-sent| +--------------+-----+---+----+-------+-------+---------+ Figure 2: 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 Figure 3) and what is the value for reconstructing the header. Minaburo, et al. Expires 27 July 2025 [Page 3] Internet-Draft SCHC for CoAP January 2025 +---------------+-----+---+----+-------+-------+---------+ | FID | FL | FP| DI | TV | MO | CDA | +===============+=====+===+====+=======+=======+=========+ | ... | ... |...|... | ... | ... | ... | |CoAP.new-option| len | 1 | up | value | equal | not-sent| +---------------+-----+---+----+-------+-------+---------+ Figure 3: 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. 3. 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 [I-D.lampin-lpwan-schc-considerations] 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. Figure 4): +------------+-----+---+----+-------+-------+---------+ | FID | FL | FP| DI | TV | MO | CDA | +============+=====+===+====+=======+=======+=========+ |CoAP.option | 16 | 1 | up | opt or| equal | not-sent| | | | | | delta | | | |CoAP.length | 16 | 1 | up | value | equal | not-sent| |CoAP.value | len | 1 | up | value | equal | not-sent| +------------+-----+---+----+-------+-------+---------+ Minaburo, et al. Expires 27 July 2025 [Page 4] Internet-Draft SCHC for CoAP January 2025 Figure 4: 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. Figure 5): +---------------+---+---+--+-----+------+----------+ | FID |FL |FP |DI| TV | MO | CDA | +===============+===+===+==+=====+======+==========+ |CoAP.new-option|var| 1 |up|value|equal |value-sent| +---------------+---+---+--+-----+------+----------+ Figure 5: representation of an option sent with semantic representation will be transformed into (cf. Figure 6): +------------+---+--+--+--+------+----------+ | FID |FL |FP|DI|TV| MO | CDA | +============+===+==+==+==+======+==========+ |CoAP.option |16 |1 |up| |ignore|value-sent| |CoAP.length |16 |1 |up| |ignore|value-sent| |CoAP.value |var|1 |up| |ignore|value-sent| +------------+---+--+--+--+------+----------+ Figure 6: 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. Minaburo, et al. Expires 27 July 2025 [Page 5] Internet-Draft SCHC for CoAP January 2025 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. 4. 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. Figure 7) shows how compression rules are defined in the YANG Data Model [RFC9363]: +--:(compression) {compression}? +--rw entry* [field-id field-position direction-indicator] +--rw field-id schc:fid-type +--rw field-length union +--rw field-position uint8 +--rw direction-indicator schc:di-type . . . Figure 7: 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): Minaburo, et al. Expires 27 July 2025 [Page 6] Internet-Draft SCHC for CoAP January 2025 +---------------+---+--+--+-----+------+----------+ | FID |FL |FP|DI| TV | MO | CDA | +===============+===+==+==+=====+======+==========+ |CoAP.option(11)|len|1 |up|value|equal |not-sent | |CoAP.option(11)|len|2 |up| |ignore|value-sent| |CoAP.option(15)|len|1 |up|value|equal |not-sent | |CoAP.option(15)|len|2 |up|value|equal |not-sent | +---------------+---+--+--+-----+------+----------+ Figure 8: 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. +--rw schc-opt:entry-option-space* \ [space-id option-value field-position direction-indicator] +--rw schc-opt:space-id space-type +--rw schc-opt:option-value uint32 +--rw schc-opt:field-length union +--rw schc-opt:field-position uint8 +--rw schc-opt:direction-indicator schc:di-type . . . Figure 9: 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”. 5. Impact on current standards [RFC9363] and [I-D.ietf-schc-8824-update] define some FID for CoAP options. This leads to have similar Rule but they are incompatible. CoAP option identifier should be deprecated. Minaburo, et al. Expires 27 July 2025 [Page 7] Internet-Draft SCHC for CoAP January 2025 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 [I-D.ietf-lpwan-architecture] 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 [RFC8724] to keep Field Descriptors (aka entries) listed in the order they appear in the packet header. 6. References 6.1. Normative References [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, March 2023, . 6.2. Informative References [I-D.ietf-lpwan-architecture] Pelov, A., Thubert, P., and A. Minaburo, "LPWAN Static Context Header Compression (SCHC) Architecture", Work in Progress, Internet-Draft, draft-ietf-lpwan-architecture- 02, 30 June 2022, . [I-D.ietf-schc-8824-update] Tiloca, M., Toutain, L., Martinez, I., and A. Minaburo, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-schc-8824-update-03, 21 October 2024, . [I-D.lampin-lpwan-schc-considerations] Lampin, Q., "SCHC design and implementation considerations", Work in Progress, Internet-Draft, draft- lampin-lpwan-schc-considerations-00, 10 November 2022, . Minaburo, et al. Expires 27 July 2025 [Page 8] Internet-Draft SCHC for CoAP January 2025 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, . Appendix A. YANG Data Model This appendix defines the work in progress YANG Data Model to extend the Data Model defined in [RFC9363]. 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. Minaburo, et al. Expires 27 July 2025 [Page 9] Internet-Draft SCHC for CoAP January 2025 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" { Minaburo, et al. Expires 27 July 2025 [Page 10] Internet-Draft SCHC for CoAP January 2025 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"; Minaburo, et al. Expires 27 July 2025 [Page 11] Internet-Draft SCHC for CoAP January 2025 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"; Minaburo, et al. Expires 27 July 2025 [Page 12] Internet-Draft SCHC for CoAP January 2025 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 Authors' Addresses Ana Minaburo Consultant Rue de Rennes 35510 Cesson-Sevigne France Email: anaminaburo@gmail.com Marco Tiloca RISE AB Isafjordsgatan 22 SE-16440 Kista Sweden Email: marco.tiloca@ri.se Minaburo, et al. Expires 27 July 2025 [Page 13] Internet-Draft SCHC for CoAP January 2025 Laurent Toutain IMT Atlantique CS 17607, 2 rue de la Chataigneraie 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@imt-atlantique.fr Minaburo, et al. Expires 27 July 2025 [Page 14]