Options representation in SCHC YANG Data Models
draft-toutain-schc-universal-option-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Ana Minaburo , Marco Tiloca , Laurent Toutain | ||
| Last updated | 2025-01-23 | ||
| Replaced by | draft-ietf-schc-universal-option | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-toutain-schc-universal-option-00
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,
<https://www.rfc-editor.org/rfc/rfc8724>.
[RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static
Context Header Compression (SCHC)", RFC 9363,
DOI 10.17487/RFC9363, March 2023,
<https://www.rfc-editor.org/rfc/rfc9363>.
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, <https://datatracker.ietf.org/doc/html/
draft-ietf-lpwan-architecture-02>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-schc-8824-update-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-lampin-lpwan-
schc-considerations-00>.
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,
<https://www.rfc-editor.org/rfc/rfc8824>.
Appendix A. YANG Data Model
This appendix defines the work in progress YANG Data Model to extend
the Data Model defined in [RFC9363].
<CODE BEGINS> 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: <https://datatracker.ietf.org/wg/lpwan/about/>
WG List: <mailto:p-wan@ietf.org>
Editor: Laurent Toutain
<mailto:laurent.toutain@imt-atlantique.fr>
Editor: Ana Minaburo
<mailto:ana@ackl.io>";
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.";
}
}
}
}
<CODE ENDS>
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]