< draft-ietf-lpwan-schc-yang-data-model-04.txt   draft-ietf-lpwan-schc-yang-data-model-05.txt >
lpwan Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Standards Track L. Toutain Intended status: Standards Track L. Toutain
Expires: August 6, 2021 Institut MINES TELECOM; IMT Atlantique Expires: 13 March 2022 Institut MINES TELECOM; IMT Atlantique
February 02, 2021 9 September 2021
Data Model for Static Context Header Compression (SCHC) Data Model for Static Context Header Compression (SCHC)
draft-ietf-lpwan-schc-yang-data-model-04 draft-ietf-lpwan-schc-yang-data-model-05
Abstract Abstract
This document describes a YANG data model for the SCHC (Static This document describes a YANG data model for the SCHC (Static
Context Header Compression) compression and fragmentation rules. Context Header Compression) compression and fragmentation rules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2021. This Internet-Draft will expire on 13 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3 2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3
2.2. Field Identifier . . . . . . . . . . . . . . . . . . . . 3 2.2. Identifier generation . . . . . . . . . . . . . . . . . . 4
2.3. Field length . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Field Identifier . . . . . . . . . . . . . . . . . . . . 5
2.4. Field position . . . . . . . . . . . . . . . . . . . . . 6 2.4. Field length . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Direction Indicator . . . . . . . . . . . . . . . . . . . 6 2.5. Field position . . . . . . . . . . . . . . . . . . . . . 8
2.6. Target Value . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Direction Indicator . . . . . . . . . . . . . . . . . . . 8
2.7. Matching Operator . . . . . . . . . . . . . . . . . . . . 8 2.7. Target Value . . . . . . . . . . . . . . . . . . . . . . 9
2.7.1. Matching Operator arguments . . . . . . . . . . . . . 9 2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10
2.8. Compression Decompression Actions . . . . . . . . . . . . 10 2.8.1. Matching Operator arguments . . . . . . . . . . . . . 11
2.8.1. Compression Decompression Action arguments . . . . . 12 2.9. Compression Decompression Actions . . . . . . . . . . . . 11
3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 12 2.9.1. Compression Decompression Action arguments . . . . . 12
3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 14 2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 12
3.1.1. Compression context representation. . . . . . . . . . 14 2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 12
3.1.2. Rule definition . . . . . . . . . . . . . . . . . . . 15 2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 13
3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 16 2.10.3. Last fragment format . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 16
5. Security considerations . . . . . . . . . . . . . . . . . . . 24 2.10.5. Fragmentation Parameters . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 2.10.6. Layer 2 parameters . . . . . . . . . . . . . . . . . 19
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 24 3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 19
8. Normative References . . . . . . . . . . . . . . . . . . . . 41 3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 23
3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5. Security considerations . . . . . . . . . . . . . . . . . . . 28
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Normative References . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
2. SCHC rules 2. SCHC rules
SCHC is a compression and fragmentation mechanism for constrained SCHC is a compression and fragmentation mechanism for constrained
networks defined in [RFC8724]. It is based on a static context networks defined in [RFC8724]. It is based on a static context
shared by two entities at the boundary this constrained network. shared by two entities at the boundary this constrained network.
Draft [RFC8724] provides an non formal representation of the rules Draft [RFC8724] provides a non formal representation of the rules
used either for compression/decompression (or C/D) or fragmentation/ used either for compression/decompression (or C/D) or fragmentation/
reassembly (or F/R). The goal of this document is to formalize the reassembly (or F/R). The goal of this document is to formalize the
description of the rules to offer: description of the rules to offer:
o the same definition on both ends, even if the internal * the same definition on both ends, even if the internal
representation is different. representation is different.
o an update the other end to set up some specific values (e.g. IPv6 * an update the other end to set up some specific values (e.g. IPv6
prefix, Destination address,...) prefix, Destination address,...)
o ... * ...
This document defines a YANG module to represent both compression and This document defines a YANG module to represent both compression and
fragmentation rules, which leads to common representation for values fragmentation rules, which leads to common representation for values
for all the rules elements. for all the rules elements.
SCHC compression is generic, the main mechanism do no refers to a SCHC compression is generic, the main mechanism does not refer to a
specific protocol. Any header field is abstracted through an ID, a specific protocol. Any header field is abstracted through an ID, a
position, a direction and a value that can be a numerical value or a position, a direction, and a value that can be a numerical value or a
string. [RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc] string. [RFC8724] and [RFC8824] specifies fields for IPv6, UDP, CoAP
specifies fields for IPv6, UDP, CoAP and OSCORE. and OSCORE. [I-D.barthel-lpwan-oam-schc] describes ICMPv6 header
[I-D.barthel-lpwan-oam-schc] decribes ICMPv6 header compression. compression and [I-D.ietf-lpwan-schc-compound-ack] includes a new
fragmentation behavior.
SCHC fragmentation requires a set of common parameters that are SCHC fragmentation requires a set of common parameters that are
included in a rule. These parameters are defined in [RFC8724]. included in a rule. These parameters are defined in [RFC8724].
2.1. Compression Rules 2.1. Compression Rules
[RFC8724] proposes an non formal representation of the compression [RFC8724] proposes a non formal representation of the compression
rule. A compression context for a device is composed of a set of rule. A compression context for a device is composed of a set of
rules. Each rule contains information to describe a specific field rules. Each rule contains information to describe a specific field
in the header to be compressed. in the header to be compressed.
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| Rule N | | Rule N |
+-----------------------------------------------------------------+| +-----------------------------------------------------------------+|
| Rule i || | Rule i ||
+-----------------------------------------------------------------+|| +-----------------------------------------------------------------+||
| (FID) Rule 1 ||| | (FID) Rule 1 |||
skipping to change at page 3, line 46 skipping to change at page 4, line 5
|+-------+--+--+--+------------+-----------------+---------------+||| |+-------+--+--+--+------------+-----------------+---------------+|||
||... |..|..|..| ... | ... | ... |||| ||... |..|..|..| ... | ... | ... ||||
|+-------+--+--+--+------------+-----------------+---------------+||/ |+-------+--+--+--+------------+-----------------+---------------+||/
||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||
|+-------+--+--+--+------------+-----------------+---------------+|/ |+-------+--+--+--+------------+-----------------+---------------+|/
| | | |
\-----------------------------------------------------------------/ \-----------------------------------------------------------------/
Figure 1: Compression Decompression Context Figure 1: Compression Decompression Context
2.2. Field Identifier 2.2. Identifier generation
Identifier used un the SCHC YANG Data Model are from the identityref
statement to ensure to be globally unique and be easily augmented if
needed. The principle to define a new type based on a group of
identityref is the following:
* define a main identity ending with the keyword base-type.
* derive all the identity used in the Data Model from this base
type.
* create a typedef from this base type.
The example (Figure 2) shows how an identityref is created for RCS
algorithms used during SCHC fragmentation.
// -- RCS algorithm types
identity rcs-algorithm-base-type {
description
"identify which algorithm is used to compute RSC.
The algorithm also defines the size if the RSC field.";
}
identity rcs-RFC8724 {
base rcs-algorithm-base-type;
description
"CRC 32 defined as default RCS in RFC8724.";
}
typedef rcs-algorithm-type {
type identityref {
base rcs-algorithm-base-type;
}
description
"type used in rules";
}
Figure 2: Principle to define a type based on identityref.
2.3. Field Identifier
In the process of compression, the headers of the original packet are In the process of compression, the headers of the original packet are
first parsed to create a list of fields. This list of fields is first parsed to create a list of fields. This list of fields is
matched against the rules to find the appropriate one and apply matched against the rules to find the appropriate one and apply
compression. The link between the list given by the parsed fields compression. The link between the list given by the parsed fields
and the rules is done through a field ID. [RFC8724] do not state how and the rules is done through a field ID. [RFC8724] do not state how
the field ID value can be constructed. In examples, identification the field ID value can be constructed. In examples, identification
is done through a string indexed by the protocol name (e.g. is done through a string indexed by the protocol name (e.g.
IPv6.version, CoAP.version,...). IPv6.version, CoAP.version,...).
The current YANG Data Model includes fields definitions found in
[RFC8724], [RFC8824], and [I-D.barthel-lpwan-oam-schc].
Using the YANG model, each field MUST be identified through a global Using the YANG model, each field MUST be identified through a global
YANG identityref. A YANG field ID derives from the field-id-base- YANG identityref. A YANG field ID for the protocol always derives
type. Figure 2 gives some field ID definitions. Note that some from the fid-base-type. Then an identity for each protocol is
field IDs can be splitted is smaller pieces. This is the case for specified using the naming convention fid-<<protocol name>>-base-
"fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are type. All possible fields for this protocol MUST derive from the
a subset of "fid-ipv6-trafficclass-ds". protocol identity. The naming convention is "fid" followed by the
protocol name and the field name. If a field has to be divided into
sub-fields, the field identity serves as a base.
identity field-id-base-type { The full field-id definition is found in Section 7. The example
description "Field ID with SID"; Figure 3 gives the first field ID definitions. A type is defined for
} IPv6 protocol, and each field is based on it. Note that the DiffServ
bits derives from the Traffic Class identity.
identity fid-ipv6-version { identity fid-base-type {
base field-id-base-type; description
description "IPv6 version field from RFC8200"; "Field ID base type for all fields";
} }
identity fid-ipv6-base-type {
base fid-base-type;
description
"Field IP base type for IPv6 headers described in RFC 8200";
}
identity fid-ipv6-version {
base fid-ipv6-base-type;
description
"IPv6 version field from RFC8200";
}
identity fid-ipv6-trafficclass { identity fid-ipv6-trafficclass {
base field-id-base-type; base fid-ipv6-base-type;
description "IPv6 Traffic Class field from RFC8200"; description
"IPv6 Traffic Class field from RFC8200";
} }
identity fid-ipv6-trafficclass-ds { identity fid-ipv6-trafficclass-ds {
base field-id-base-type; base fid-ipv6-trafficclass;
description "IPv6 Traffic Class field from RFC8200, description
"IPv6 Traffic Class field from RFC8200,
DiffServ field from RFC3168"; DiffServ field from RFC3168";
} }
identity fid-ipv6-trafficclass-ecn {
base field-id-base-type;
description "IPv6 Traffic Class field from RFC8200,
ECN field from RFC3168";
}
... ...
Figure 2: Definition of identityref for field IDs Figure 3: Definition of identityref for field IDs
Figure 2 gives some examples of field ID identityref definitions.
The base identity is field-id-base-type, and field id are derived for
it.
The naming convention is "fid" followed by the protocol name and the
field name.
The yang model in annex (see Section 7) gives the full definition of
the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc],
and [I-D.barthel-lpwan-oam-schc].
The type associated to this identity is field-id-type (cf. Figure 3) The type associated to this identity is fid-type (cf. Figure 4)
typedef field-id-type { typedef fid-type {
description "Field ID generic type."; type identityref {
type identityref { base fid-base-type;
base field-id-base-type;
}
} }
description
"Field ID generic type.";
}
Figure 3: Type definition for field IDs Figure 4: Type definition for field IDs
2.3. Field length 2.4. Field length
Field length is either an integer giving the size of a field in bits Field length is either an integer giving the size of a field in bits
or a specific function. [RFC8724] defines the "var" function which or a specific function. [RFC8724] defines the "var" function which
allows variable length fields in byte and allows variable length fields in byte and [RFC8824] defines the "tkl"
[I-D.ietf-lpwan-coap-static-context-hc] defines the "tkl" function function for managing the CoAP Token length field.
for managing the CoAP Token length field.
identity field-length-base-type { The naming convention is "fl" followed by the function name.
description "used to extend field length functions";
identity fl-base-type {
description
"Used to extend field length functions";
} }
identity fl-variable { identity fl-variable {
base field-length-base-type; base fl-base-type;
description "residue length in Byte is sent"; description
"Residue length in Byte is sent defined in
for CoAP in RFC 8824 (cf. 5.3)";
} }
identity fl-token-length { identity fl-token-length {
base field-length-base-type; base fl-base-type;
description "residue length in Byte is sent"; description
"Residue length in Byte is sent defined in
for CoAP in RFC 8824 (cf. 4.5)";
} }
Figure 4: Definition of identityref for field ILength Figure 5: Definition of identityref for Field Length
As for field ID, field length function can be defined as a As for field ID, field length function can be defined as an
identityref as shown in Figure 4. identityref as shown in Figure 5.
Therefore the type for field length is a union between an integer Therefore, the type for field length is a union between an integer
giving in bits the size of the length and the identityref (cf. giving in bits the size of the length and the identityref (cf.
Figure 5). Figure 6).
typedef field-length-type {
description "Field length either a positive integer giving the size in bits
or a function defined through an identityref.";
type union {
type int64; /* positive length in bits */
type identityref { /* function */
base field-length-base-type;
}
}
}
Figure 5: Type definition for field Length
The naming convention is fl followed by the function name as defined typedef fl-type {
in SCHC specifications. type union {
type int64; /* positive length in bits */
type identityref { /* function */
base fl-base-type;
}
}
description
"Field length either a positive integer giving the size in bits
or a function defined through an identityref.";
}
Figure 6: Type definition for field Length
2.4. Field position 2.5. Field position
Field position is a positive integer which gives the position of a Field position is a positive integer which gives the position of a
field, the default value is 1, but if the field is repeated several field, the default value is 1, but if the field is repeated several
times, the value is higher. value 0 indicates that the position is times, the value is higher. value 0 indicates that the position is
not important and is not taken into account during the rule selection not important and is not considered during the rule selection
process. process.
Field position is a positive integer. The type is an uint8. Field position is a positive integer. The type is an uint8.
2.5. Direction Indicator 2.6. Direction Indicator
The Direction Indicator (DI) is used to tell if a field appears in The Direction Indicator (di) is used to tell if a field appears in
both direction (Bi) or only uplink (Up) or Downlink (Dw). both direction (Bi) or only uplink (Up) or Downlink (Dw).
identity direction-indicator-base-type { identity di-base-type {
description "used to extend field length functions"; description
"Used to extend field length functions";
} }
identity di-bidirectional { identity di-bidirectional {
base direction-indicator-base-type; base di-base-type;
description "Direction Indication of bi directionality"; description
"Direction Indication of bi directionality in
RFC 8724 (cf. 7.1)";
} }
identity di-up { identity di-up {
base direction-indicator-base-type; base di-base-type;
description "Direction Indication of upstream"; description
"Direction Indication of upstream defined in
RFC 8724 (cf. 7.1)";
} }
identity di-down { identity di-down {
base direction-indicator-base-type; base di-base-type;
description "Direction Indication of downstream"; description
"Direction Indication of downstream defined in
RFC 8724 (cf. 7.1)";
} }
Figure 6: Definition of identityref for direction indicators Figure 7: Definition of identityref for direction indicators
Figure 6 gives the identityref for Direction Indicators. Figure 7 gives the identityref for Direction Indicators. The naming
convention is "di" followed by the Direction Indicator name.
The type is "direction-indicator-type" (cf. Figure 7). The type is "direction-indicator-type" (cf. Figure 8).
typedef direction-indicator-type { typedef di-type {
description "direction in LPWAN network, up when emitted by the device, type identityref {
down when received by the device, bi when emitted or received by the device."; base di-base-type;
type identityref {
base direction-indicator-base-type;
}
} }
description
"Direction in LPWAN network, up when emitted by the device,
down when received by the device, bi when emitted or received by the device.";
}
Figure 7: Type definition for direction indicators Figure 8: Type definition for direction indicators
2.6. Target Value 2.7. Target Value
Target Value may be either a string or binary sequence. For match- The Target Value is a list of binary sequences of any length, aligned
mapping, several of these values can be contained in a Target Value on the left. Figure 9 gives the definition of a single element of a
field. In the data model, this is generalized by adding a position, Target Value. In the rule, this will be used as a list, with
which orders the list of values. By default the position is set to position as a key. The highest position value is used to compute the
0. size of the index sent in residue for LSB CDA. The position allows
to specify several values:
The leaf "value" is not mandatory to represent a non existing value * For Equal and LSB, a single value is used, such as for the equal
in a TV. or LSB CDA, the position is set to 0.
grouping target-values-struct { * For match-mapping, several of these values can be contained in a
description "defines the target value element. Can be either an arbitrary Target Value field. In the data model, this is generalized by
binary or ascii element. All target values are considered as a matching lists. adding a position, which orders the list of values. Position
Position is used to order values, by default position 0 is used when containing values must start from 0 and be contiguous.
a single element.";
leaf value { grouping tv-struct {
type union { description
type binary; "Define the target value element. Always a binary type, strings
type string; must be converted to binary. field-id allows the conversion to the appropriate
} type.";
} leaf value {
leaf position { type binary;
description "If only one element position is 0, otherwise position is the
matching list.";
type uint16;
}
} }
leaf position {
type uint16;
description
"If only one element position is 0, otherwise position is the
matching list.";
}
}
Figure 8: Definition of target value Figure 9: Definition of target value
Figure 8 gives the definition of a single element of a Target Value.
In the rule, this will be used as a list, with position as a key.
The highest position value is used to compute the size of the index
sent in residue.
2.7. Matching Operator 2.8. Matching Operator
Matching Operator (MO) is a function applied between a field value Matching Operator (MO) is a function applied between a field value
provided by the parsed header and the target value. [RFC8724] provided by the parsed header and the target value. [RFC8724]
defines 4 MO. defines 4 MO as listed in Figure 10.
identity matching-operator-base-type { identity mo-base-type {
description "used to extend Matching Operators with SID values"; description
"Used to extend Matching Operators with SID values";
} }
identity mo-equal { identity mo-equal {
base matching-operator-base-type; base mo-base-type;
description "RFC 8724"; description
"Equal MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-ignore { identity mo-ignore {
base matching-operator-base-type; base mo-base-type;
description "RFC 8724"; description
"Ignore MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-msb { identity mo-msb {
base matching-operator-base-type; base mo-base-type;
description "RFC 8724"; description
"MSB MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-matching { identity mo-matching {
base matching-operator-base-type; base mo-base-type;
description "RFC 8724"; description
"match-mapping MO as defined RFC 8724 (cf. 7.3)";
} }
Figure 9: Definition of identityref for Matching Operator Figure 10: Definition of identityref for Matching Operator
the type is "matching-operator-type" (cf. Figure 10) The naming convention is "mo" followed by the MO name.
typedef matching-operator-type { The type is "matching-operator-type" (cf. Figure 11)
description "Matching Operator (MO) to compare fields values with target values";
type identityref {
base matching-operator-base-type;
}
}
Figure 10: Type definition for Matching Operator typedef mo-type {
type identityref {
base mo-base-type;
}
description
"Matching Operator (MO) to compare fields values with target values";
}
Figure 11: Type definition for Matching Operator
2.7.1. Matching Operator arguments 2.8.1. Matching Operator arguments
Some Matching Operator such as MSB can take some values. Even if Some Matching Operator such as MSB can take some values. Even if
currently LSB is the only MO takes only one argument, in the future currently LSB is the only MO takes only one argument, in the future
some MO may require several arguments. They are viewed as a list of some MO may require several arguments. They are viewed as a list of
target-values-type. target-values-type.
2.8. Compression Decompression Actions 2.9. Compression Decompression Actions
Compression Decompression Action (CDA) identified the function to use Compression Decompression Action (CDA) identified the function to use
either for compression or decompression. [RFC8724] defines 6 CDA. either for compression or decompression. [RFC8724] defines 6 CDA.
identity compression-decompression-action-base-type; Figure 13 gives some CDA definition, the full definition is in
Section 7.
identity cda-not-sent {
base compression-decompression-action-base-type;
description "RFC 8724";
}
identity cda-value-sent { identity cda-base-type {
base compression-decompression-action-base-type; description
description "RFC 8724"; "Compression Decompression Actions";
} }
identity cda-lsb { identity cda-not-sent {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "not-sent CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-mapping-sent { identity cda-value-sent {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "value-sent CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-compute-length { identity cda-lsb {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "LSB CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-compute-checksum { identity cda-mapping-sent {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-deviid { ....
base compression-decompression-action-base-type;
description "RFC 8724";
}
identity cda-appiid { Figure 12: Definition of identityref for Compresion Decompression
base compression-decompression-action-base-type; Action
description "RFC 8724";
}
Figure 11: Definition of identityref for Compresion Decompression The naming convention is "cda" followed by the CDA name.
Action
The type is "comp-decomp-action-type" (cf. Figure 12) typedef cda-type {
typedef comp-decomp-action-type { type identityref {
description "Compression Decompression Action to compression or decompress a field."; base cda-base-type;
type identityref {
base compression-decompression-action-base-type;
}
} }
description
"Compression Decompression Action to compression or decompress a field.";
}
Figure 12: Type definition for Compresion Decompression Action Figure 13: Type definition for Compresion Decompression Action
2.8.1. Compression Decompression Action arguments 2.9.1. Compression Decompression Action arguments
Currently no CDA requires arguments, but the future some CDA may Currently no CDA requires arguments, but the future some CDA may
require several arguments. They are viewed as a list of target- require several arguments. They are viewed as a list of target-
values-type. values-type.
3. Rule definition 2.10. Fragmentation rule
A rule is either a C/D or an F/R rule. A rule is identified by the Fragmentation is optional in the data model and depends on the
rule ID value and its associated length. The YANG grouping rule-id- presence of the "fragmentation" feature.
type defines the structure used to represent a rule ID. Length of 0
is allowed to represent an implicit rule.
// Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length Most of parameters for fragmentation are defined in Annex D of
[RFC8724].
grouping rule-id-type { Since fragmentation rules work for a specific direction, they contain
leaf rule-id { a mandatory direction. The type is the same as the one used in
type uint32; compression entries, but the use of bidirectional is forbidden.
description "rule ID value, this value must be unique combined with the length";
}
leaf rule-length {
type uint8 {
range 0..32;
}
description "rule ID length in bits, value 0 is for implicit rules";
}
}
// SCHC table for a specific device. 2.10.1. Fragmentation mode
container schc { [RFC8724] defines 3 fragmentation modes:
leaf version{
type uint64;
mandatory false;
description "used as an indication for versioning";
}
list rule {
key "rule-id rule-length";
uses rule-id-type;
choice nature {
case fragmentation {
uses fragmentation-content;
}
case compression {
uses compression-content;
}
}
}
}
Figure 13: Definition of a SCHC Context * No Ack: this mode is unidirectionnal, no acknowledgment is sent
back.
To access to a specific rule, rule-id and its specific length is used * Ack Always: each fragmentation window must be explicitly
as a key. The rule is either a compression or a fragmentation rule. acknowledged before going to the next.
Each context can be identified though a version id. * Ack on Error: A window is acknowledged only when the receiver
detects some missing fragments.
3.1. Compression rule Figure 14 give the definition for identifiers from these three modes.
A compression rule is composed of entries describing its processing identity fragmentation-mode-base-type {
(cf. Figure 14). An entry contains all the information defined in description
Figure 1 with the types defined above. "Fragmentation mode";
}
3.1.1. Compression context representation. identity fragmentation-mode-no-ack {
base fragmentation-mode-base-type;
description
"No Ack of RFC 8724.";
}
The compression rule described Figure 1 is associated to a rule ID. identity fragmentation-mode-ack-always {
The compression rule entry is defined in Figure 14. Each column in base fragmentation-mode-base-type;
the table is either represented by a leaf or a list. Note that description
Matching Operators and Compression Decompression actions can have "Ack Always of RFC8724.";
arguments. They are viewed a ordered list of strings and numbers as }
in target values.
grouping compression-rule-entry { identity fragmentation-mode-ack-on-error {
description "These entries defines a compression entry (i.e. a line) base fragmentation-mode-base-type;
as defined in RFC 8724 and fragmentation parameters. description
"Ack on Error of RFC8724.";
}
+-------+--+--+--+------------+-----------------+---------------+ typedef fragmentation-mode-type {
|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| type identityref {
+-------+--+--+--+------------+-----------------+---------------+ base fragmentation-mode-base-type;
}
description
"type used in rules";
}
An entry in a compression rule is composed of 7 elements: Figure 14: Definition of fragmentation mode identifer
- Field ID: The header field to be compressed. The content is a YANG identifer.
- Field Length : either a positive integer of a function defined as a YANG id.
- Field Position: a positive (and possibly equal to 0) integer.
- Direction Indicator: a YANG identifier giving the direction.
- Target value: a value against which the header Field is compared.
- Matching Operator: a YANG id giving the operation, parameters may be
associated to that operator.
- Comp./Decomp. Action: A YANG id giving the compression or decompression
action, parameters may be associated to that action.
";
leaf field-id { The naming convention is "fragmentation-mode" followed by the
description "Field ID, identify a field in the header with a YANG identityref."; fragmentation mode name.
mandatory true;
type schc:field-id-type;
}
leaf field-length {
description "Field Length in bit or through a function defined as a YANG identityref";
mandatory true;
type schc:field-length-type;
}
leaf field-position {
description "field position in the header is a integer. If the field is not repeated
in the header the value is 1, and incremented for each repetition of the field. Position
0 means that the position is not important and order may change when decompressed";
mandatory true;
type uint8;
}
leaf direction-indicator {
description "Direction Indicator, a YANG identityref to say if the packet is bidirectionnal,
up or down";
mandatory true;
type schc:direction-indicator-type;
}
list target-values {
description "a list of value to compare with the header field value. If target value
is a singleton, position must be 0. For matching-list, should be consecutive position
values starting from 1.";
key position;
uses target-values-struct;
}
leaf matching-operator {
mandatory true;
type schc:matching-operator-type;
}
list matching-operator-value {
key position;
uses target-values-struct;
}
leaf comp-decomp-action {
mandatory true;
type schc:comp-decomp-action-type;
}
list comp-decomp-action-value {
key position;
uses target-values-struct;
}
}
Figure 14: Definition of a compression entry 2.10.2. Fragmentation Header
3.1.2. Rule definition A data fragment header, directly following the rule ID can be sent on
the fragmentation direction. The direction is mandatory and must be
up or down. bidirectional is forbidden. The SCHC header may be
composed of (cf. Figure 15):
A compression rule is a list of entries. * a Datagram Tag (Dtag) identifying the datagram being fragmented if
the fragmentation applies concurrently on several datagrams. This
field in optional and its length is defined by the rule.
grouping compression-content { * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack-
description "define a compression rule composed of a list of entries."; Always, its size is 1 and depends on the rule in Ack-on-Error.
list entry { This field is not need in No-Ack mode.
key "field-id field-position direction-indicator";
uses compression-rule-entry;
}
}
Figure 15: Definition of a compression rule * a Fragment Compressed Number (FCN) indicating the fragment/tile
position on the window. This field is mandatory on all modes
defined in [RFC8724], its size is defined by the rule.
To identify a specific entry Field ID, position and direction are |-- SCHC Fragment Header ----|
needed. |-- T --|-M-|-- N --|
+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W | FCN | Fragment Payload | padding (as needed)
+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
3.2. Fragmentation rule Figure 15: Data fragment header from RFC8724
Parameters for fragmentation are defined in Annex D of [RFC8724]. 2.10.3. Last fragment format
Figure 16 gives the first elements found in this structure. It The last fragment of a datagram is sent with an RCS (Reassembly Check
starts with a direction. Since fragmentation rules work for a Sequence) field to detect residual transmission error and possible
specific direction, they contain a mandatory direction. The type is losses in the last window. [RFC8724] defines a single algorithm
the same as the one used in compression entries, but the use of based on Ethernet CRC computation. The identity of the RCS algorithm
bidirectionnal is forbidden. is shown in Figure 16.
The next elements describe size of SCHC fragmentation header fields. // -- RCS algorithm types
Only the FCN size is mandatory and value must be higher or equal to
1.
grouping fragmentation-content { identity rcs-algorithm-base-type {
description "This grouping defines the fragmentation parameters for description
all the modes (No Ack, Ack Always and Ack on Error) specified in "Identify which algorithm is used to compute RSC.
RFC 8724."; The algorithm defines also the size if the RSC field.";
}
leaf direction { identity rcs-RFC8724 {
type schc:direction-indicator-type; base rcs-algorithm-base-type;
description "should be up or down, bi directionnal is forbidden."; description
mandatory true; "CRC 32 defined as default RCS in RFC8724.";
} }
leaf dtagsize {
type uint8;
description "size in bit of the DTag field";
} typedef rcs-algorithm-type {
leaf wsize { type identityref {
type uint8; base rcs-algorithm-base-type;
description "size in bit of the window field"; }
} description
leaf fcnsize { "type used in rules";
type uint8 { }
range 1..max;
}
description "size in bit of the FCN field";
mandatory true;
}
...
Figure 16: Definition of a fragmentation parameters, SCHC header Figure 16: type definition for RCS
RCS algorithm is defined (Figure 17), by default with the CRC The naming convention is "rcs" followed by the algorithm name.
computation proposed in [RFC8724]. The algorithms are identified
through an identityref specified in the SCHC Data Model and with the
type RCS-algorithm-type (Figure 18).
... For Ack-on-Error mode, the All-1 fragment may just contain the RCS or
leaf RCS-algorithm { can include a tile. The parameters defined in Figure 17 allows to
type RCS-algorithm-type; define the behavior:
default schc:RFC8724-RCS;
description "Algoritm used for RCS";
}
...
Figure 17: Definition of a fragmentation parameters, RCS algorithm * all1-data-no: the last fragment contains no data, just the RCS
identity RCS-algorithm-base-type {
description "identify which algorithm is used to compute RSC. * all1-data-yes: the last fragment includes a single tile and the
The algorithm defines also the size if the RSC field."; RCS
* all1-data-sender-choice: the last fragment may or may not contain
a single tile. The receiver can detect if a tile is present.
// -- All1 with data types
identity all1-data-base-type {
description
"Type to define when to send an Acknowledgment message";
}
identity all1-data-no {
base all1-data-base-type;
description
"All1 contains no tiles.";
}
identity all1-data-yes {
base all1-data-base-type;
description
"All1 MUST contain a tile";
}
identity all1-data-sender-choice {
base all1-data-base-type;
description
"Fragmentation process choose to send tiles or not in all1.";
}
typedef all1-data-type {
type identityref {
base all1-data-base-type;
} }
description
"Type used in rules";
}
identity RFC8724-RCS { Figure 17: type definition for RCS
description "CRC 32 defined as default RCS in RFC8724.";
base RCS-algorithm-base-type; The naming convention is "all1-data" followed by the behavior
identifier.
2.10.4. Acknowledgment behavior
A cknowledgment fragment header goes in the opposite direction of
data. The header is composed of (see Figure 18):
* a Dtag (if present).
* a mandatory window as in the data fragment.
* a C bit giving the status of RCS validation. In case of failure,
a bitmap follows, indicating received fragment/tile. The size of
the bitmap is given by the FCN value.
NOTE: IN THE DATA MODEL THERE IS A max-window-size FIELD TO LIMIT THE
BITMAP SIZE, BUT IS NO MORE IN RFC8724! DO WE KEEP IT?
|--- SCHC ACK Header ----|
|-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W |C=1| padding as needed (success)
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
| RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
Figure 18: Acknowledgment fragment header for RFC8724
For Ack-on-Error, SCHC defined when acknowledgment can be sent. This
can be at any time defined by the layer 2, at the end of a window
(FCN All-0) or at the end of the fragment (FCN All-1). The following
identifiers (cf. Figure 19) define the acknowledgment behavior.
// -- Ack behavior
identity ack-behavior-base-type {
description
"Define when to send an Acknowledgment message";
}
identity ack-behavior-after-All0 {
base ack-behavior-base-type;
description
"Fragmentation expects Ack after sending All0 fragment.";
}
identity ack-behavior-after-All1 {
base ack-behavior-base-type;
description
"Fragmentation expects Ack after sending All1 fragment.";
}
identity ack-behavior-always {
base ack-behavior-base-type;
description
"Fragmentation expects Ack after sending every fragment.";
}
typedef ack-behavior-type {
type identityref {
base ack-behavior-base-type;
} }
description
"Type used in rules";
}
typedef RCS-algorithm-type { Figure 19: bitmap generation behavior
type identityref {
base RCS-algorithm-base-type; The naming convention is "ack-behavior" followed by the algorithm
} name.
For Ack-onError, [RFC8724] allows a single bitmap in an acknowledment
fragment, and [I-D.ietf-lpwan-schc-compound-ack] proposes to
acknowledge several windows on a single ack fragment. The following
identifiers (cf. Figure 20) define the behavior.
identity bitmap-format-base-type {
description
"Define how the bitmap is defined in ACK messages.";
}
identity bitmap-RFC8724 {
base bitmap-format-base-type;
description
"Bitmap as defined in RFC8724.";
}
identity bitmap-compound-ack {
base bitmap-format-base-type;
description
"Compound Ack.";
}
typedef bitmap-format-type {
type identityref {
base bitmap-format-base-type;
} }
description
"type used in rules";
}
Figure 18: Definition of identityref for RCS Algorithm Figure 20: bitmap generation behavior
Figure 19 gives the parameters used by the state machine to handle The naming convention is "bitmap" followed by the algorithm name.
fragmentation:
o maximum-window-size contains the maximum FCN value that can be 2.10.5. Fragmentation Parameters
used.
o retransmission-timer gives in seconds the duration before sending The state machine requires some common values to handle
an ack request (cf. section 8.2.2.4. of [RFC8724]). If specifed, fragmentation:
* retransmission-timer gives in seconds the duration before sending
an ack request (cf. section 8.2.2.4. of [RFC8724]). If specified,
value must be higher or equal to 1. value must be higher or equal to 1.
o inactivity-timer gives in seconds the duration before aborting * inactivity-timer gives in seconds the duration before aborting
(cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly (cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly
indicates that this timer is disabled. indicates that this timer is disabled.
o max-ack-requests gives the number of attempts before aborting (cf. * max-ack-requests gives the number of attempts before aborting (cf.
section 8.2.2.4. of [RFC8724]). section 8.2.2.4. of [RFC8724]).
o maximum-packet-size gives in bytes the larger packet size that can * maximum-packet-size gives in bytes the larger packet size that can
be reassembled. be reassembled.
... The are defined as unsigned integer, see Section 7.
leaf maximum-window-size {
type uint16;
description "by default 2^wsize - 2";
}
leaf retransmission-timer { 2.10.6. Layer 2 parameters
type uint64 {
range 1..max;
}
description "duration in seconds of the retransmission timer"; // Check the units
}
leaf inactivity-timer { The data model includes two parameters needed for fragmentation:
type uint64;
description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units
}
leaf max-ack-requests { * l2-word-size: [RFC8724] base fragmentation on a layer 2 word which
type uint8 { can be of any length. The default value is 8 and correspond to
range 1..max; the default value for byte aligned layer 2. A value of 1 will
} indicate that there is no alignment and no need for padding.
description "the maximum number of retries for a specific SCHC ACK.";
}
leaf maximum-packet-size { * maximum-packet-size: defines the maximum size of a uncompressed
type uint16; datagram. By default, the value is set to 1280 bytes.
default 1280;
description "When decompression is done, packet size must not strictly exceed this limit in Bytes";
}
...
Figure 19: Definition of a fragmentation state machine parameters They are defined as unsigned integer, see Section 7.
Figure 20 gives information related to a specific compression mode: 3. Rule definition
fragmentation-mode MUST be set with a specific behavior. Identityref
are given Figure 21.
For Ack on Error some specific information may be provided: A rule is either a C/D or an F/R rule. A rule is identified by the
rule ID value and its associated length. The YANG grouping rule-id-
type defines the structure used to represent a rule ID. Length of 0
is allowed to represent an implicit rule.
o tile-size gives in bits the size of the tile; If set to 0 a single Three types of rules are defined in [RFC8724]:
tile is inserted inside a fragment.
o tile-in-All1 indicates if All1 contains only the RCS (all1-data- * Compression: a compression rule is associated to the rule ID.
no) or may contain a single tile (all1-data-yes). Since the
reassembly process may detect this behavior, the choice can be
left to the fragmentation process. In that case identityref all1-
data-sender-choice as to be specified. All possible values are
given Figure 21.
o ack-behavior tells when the fragmentation process may send * No compression: nothing is associated to the rule ID.
acknowledgments. When ack-behavior-after-All0 is specified, the
ack may be sent after the reception of All-0 fragment. When ack-
behavior-after-All1 is specified, the ack may be sent after the
reception of All-1 fragment at the end of the fragmentation
process. ack-behavior-always do not impose a limitation at the
SCHC level. The constraint may come from the LPWAN technology.
All possible values are given Figure 21.
... * Fragmentation: fragmentation parameters are associated to the rule
leaf fragmentation-mode { ID. Fragmentation is optional and feature "fragmentation" should
type schc:fragmentation-mode-type; be set.
description "which fragmentation mode is used (noAck, AckAlways, AckonError)";
mandatory true; grouping rule-id-type {
leaf rule-id-value {
type uint32;
description
"Rule ID value, this value must be unique combined with the length";
}
leaf rule-id-length {
type uint8 {
range "0..32";
}
description
"Rule ID length in bits, value 0 is for implicit rules";
}
description
"A rule ID is composed of a value and a length in bit";
}
// SCHC table for a specific device.
container schc {
list rule {
key "rule-id-value rule-id-length";
uses rule-id-type;
choice nature {
case fragmentation {
if-feature "fragmentation";
uses fragmentation-content;
}
case compression {
uses compression-content;
}
case no-compression {
description
"RFC8724 allows a rule for uncompressed headers";
} }
description
"A rule is either for compression, no compression or fragmentation";
}
description
"Set of rules compression, no compression or fragmentation rules
identified by their rule-id ";
}
description
"a SCHC set of rules is composed of a list of rule which are either
compression or fragmentation";
}
}
Figure 21: Definition of a SCHC Context
choice mode { To access to a specific rule, rule-id and its specific length is used
case no-ack; as a key. The rule is either a compression or a fragmentation rule.
case ack-always;
case ack-on-error {
leaf tile-size {
type uint8;
description "size in bit of tiles, if not specified or set to 0: tile fills the fragment.";
}
leaf tile-in-All1 {
type schc:all1-data-type;
description "When true, sender and receiver except a tile in All-1 frag";
}
leaf ack-behavior {
type schc:ack-behavior-type;
description "Sender behavior to acknowledge, after All-0, All-1 or when the
LPWAN allows it (Always)";
}
}
}
...
Figure 20: Definition of a fragmentation specific information Each context can be identified though a version id.
// -- FRAGMENTATION TYPE 3.1. Compression rule
// -- fragmentation modes A compression rule is composed of entries describing its processing
(cf. Figure 22). An entry contains all the information defined in
Figure 1 with the types defined above.
identity fragmentation-mode-base-type { The compression rule described Figure 1 is defined by compression-
description "fragmentation mode"; content. It defines a list of compression-rule-entry, indexed by
their field id, position and direction. The compression-rule-entry
element represent a line of the table Figure 1. Their type reflects
the identifier types defined in Section 2.1
} Some controls are made on the values:
identity fragmentation-mode-no-ack { * target value must be present for MO different from ignore.
description "No Ack of RFC 8724.";
base fragmentation-mode-base-type;
}
identity fragmentation-mode-ack-always { * when MSB MO is specified, the matching-operator-value must be
description "Ack Always of RFC8724."; present
base fragmentation-mode-base-type;
}
identity fragmentation-mode-ack-on-error {
description "Ack on Error of RFC8724.";
base fragmentation-mode-base-type;
}
typedef fragmentation-mode-type { grouping compression-rule-entry {
type identityref { description
base fragmentation-mode-base-type; "These entries defines a compression entry (i.e. a line)
} as defined in RFC 8724 and fragmentation parameters.
}
// -- Ack behavior +-------+--+--+--+------------+-----------------+---------------+
|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
+-------+--+--+--+------------+-----------------+---------------+
identity ack-behavior-base-type { An entry in a compression rule is composed of 7 elements:
description "define when to send an Acknowledgment message"; - Field ID: The header field to be compressed. The content is a YANG identifer.
- Field Length : either a positive integer of a function defined as a YANF id.
- Field Position: a positive (and possibly equal to 0) integer.
- Direction Indicator: a YANG identifier giving the direction.
- Target value: a value against which the header Field is compared.
- Matching Operator: a YANG id giving the operation, paramters may be
associated to that operator.
- Comp./Decomp. Action: A YANG id giving the compression or decompression
action, paramters may be associated to that action.
";
leaf field-id {
type schc:fid-type;
mandatory true;
description
"Field ID, identify a field in the header with a YANG refenceid.";
} }
leaf field-length {
identity ack-behavior-after-All0 { type schc:fl-type;
description "fragmentation expects Ack after sending All0 fragment."; mandatory true;
base ack-behavior-base-type; description
"Field Length in bit or through a function defined as a YANG referenceid";
} }
leaf field-position {
identity ack-behavior-after-All1 { type uint8;
description "fragmentation expects Ack after sending All1 fragment."; mandatory true;
base ack-behavior-base-type; description
"Field position in the header is a integer. If the field is not repeated
in the header the value is 1, and incremented for each repetition of the field. Position
0 means that the position is not important and order may change when decompressed";
} }
leaf direction-indicator {
identity ack-behavior-always { type schc:di-type;
description "fragmentation expects Ack after sending every fragment."; mandatory true;
base ack-behavior-base-type; description
"Direction Indicator, a YANG referenceid to say if the packet is bidirectional,
up or down";
}
list target-value {
key "position";
uses tv-struct;
description
"A list of value to compare with the header field value. If target value
is a singleton, position must be 0. For matching-list, should be consecutive position
values starting from 1.";
}
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 require 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";
}
list matching-operator-value {
key "position";
uses tv-struct;
description
"Matching Operator Arguments, based on TV structure to allow several arguments.
In RFC 8724, only MSB define a single argument: length in bits ";
} }
leaf comp-decomp-action {
type schc:cda-type;
mandatory true;
description
"CDA: Compression Decompression Action";
}
list comp-decomp-action-value {
key "position";
uses tv-struct;
description
"CDA Arguments, based on TV structure to allow several arguments.
In RFC 8724, no argument is defined for CDA";
}
}
typedef ack-behavior-type { grouping compression-content {
type identityref { list entry {
base ack-behavior-base-type; key "field-id field-position direction-indicator";
} uses compression-rule-entry;
description
"A compression rule is a list of rule entry describing
each header field. An entry is identifed through a field-id, its position
in the packet and its direction";
} }
description
"Define a compression rule composed of a list of entries.";
}
// -- All1 with data types Figure 22: Definition of a compression entry
identity all1-data-base-type { 3.2. Fragmentation rule
description "type to define when to send an Acknowledgment message";
}
identity all1-data-no { A Fragmentation rule is composed of entries describing the protocol
description "All1 contains no tiles."; behavior. Some on them are numerical entries, others are identifiers
base all1-data-base-type; defined in Section 2.10.
}
identity all1-data-yes { The data model defines some relations between the entries:
description "All1 MUST contain a tile";
base all1-data-base-type;
}
identity all1-data-sender-choice { * direction must be either up or down (not bidirectional).
description "Fragmentation process choose to send tiles or not in all1.";
base all1-data-base-type; * W size is only needed for Ack Always and Ack on Error modes.
grouping fragmentation-content {
description
"This grouping defines the fragmentation parameters for
all the modes (No Ack, Ack Always and Ack on Error) specified in
RFC 8724.";
leaf l2-word-size {
type uint8;
default "8";
description
"Size in bit of the layer 2 word";
}
leaf direction {
must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" {
error-message "direction for fragmentation rules is up or down";
}
type schc:direction-indicator-type;
mandatory true;
description
"Should be up or down, bi directionnal is forbiden.";
}
leaf dtag-size {
type uint8;
default "0";
description
"Size in bit of the DTag field";
}
leaf w-size {
when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))";
type uint8;
description
"Size in bit of the window field";
}
leaf fcn-size {
type uint8;
mandatory true;
description
"Size in bit of the FCN field";
}
leaf rcs-algorithm {
type rcs-algorithm-type;
default "schc:rcs-RFC8724";
description
"Algorithm used for RCS";
} }
leaf maximum-window-size {
type uint16;
description
"By default 2^wsize - 1";
typedef all1-data-type { }
type identityref { leaf retransmission-timer {
base all1-data-base-type; type uint64 {
range "1..max";
}
description
"Duration in seconds of the retransmission timer"; // Check the units
}
leaf inactivity-timer {
type uint64;
description
"Duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units
}
leaf max-ack-requests {
type uint8 {
range "1..max";
}
description
"The maximum number of retries for a specific SCHC ACK.";
}
leaf maximum-packet-size {
type uint16;
default "1280";
description
"When decompression is done, packet size must not strictly exceed this limit in Bytes";
}
leaf fragmentation-mode {
type schc:fragmentation-mode-type;
mandatory true;
description
"Which fragmentation mode is used (noAck, AckAlways, AckonError)";
}
choice mode {
case no-ack;
case ack-always;
case ack-on-error {
leaf tile-size {
type uint8;
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
description
"Size in bit of tiles, if not specified or set to 0: tile fills the fragment.";
} }
leaf tile-in-All1 {
type schc:all1-data-type;
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
description
"When true, sender and receiver except a tile in All-1 frag";
}
leaf ack-behavior {
type schc:ack-behavior-type;
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
description
"Sender behavior to acknowledge, after All-0, All-1 or when the
LPWAN allows it (Always)";
}
leaf bitmap-format {
type schc:bitmap-format-type;
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
default "schc:bitmap-RFC8724";
description
"How the bitmaps are included in the Ack message.";
}
}
description
"RFC 8724 defines 3 fragmentation modes";
} }
}
Figure 21: Specific types for Ack On Error mode 3.3. YANG Tree
module: ietf-schc
## YANG Tree
module: schc
+--rw schc +--rw schc
+--rw version? uint64 +--rw rule* [rule-id-value rule-id-length]
+--rw rule* [rule-id rule-length] +--rw rule-id-value uint32
+--rw rule-id uint32 +--rw rule-id-length uint8
+--rw rule-length uint8
+--rw (nature)? +--rw (nature)?
+--:(fragmentation) +--:(fragmentation) {fragmentation}?
| +--rw direction schc:direction-indicator-type | +--rw l2-word-size? uint8
| +--rw dtagsize? uint8 | +--rw direction schc:di-type
| +--rw wsize? uint8 | +--rw dtag-size? uint8
| +--rw fcnsize uint8 | +--rw w-size? uint8
| +--rw RCS-algorithm? RCS-algorithm-type | +--rw fcn-size uint8
| +--rw rcs-algorithm? rcs-algorithm-type
| +--rw maximum-window-size? uint16 | +--rw maximum-window-size? uint16
| +--rw retransmission-timer? uint64 | +--rw retransmission-timer? uint64
| +--rw inactivity-timer? uint64 | +--rw inactivity-timer? uint64
| +--rw max-ack-requests? uint8 | +--rw max-ack-requests? uint8
| +--rw maximum-packet-size? uint16 | +--rw maximum-packet-size? uint16
| +--rw fragmentation-mode schc:fragmentation-mode-type | +--rw fragmentation-mode schc:fragmentation-mode-type
| +--rw (mode)? | +--rw (mode)?
| +--:(no-ack) | +--:(no-ack)
| +--:(ack-always) | +--:(ack-always)
| +--:(ack-on-error) | +--:(ack-on-error)
| +--rw tile-size? uint8 | +--rw tile-size? uint8
| +--rw tile-in-All1? schc:all1-data-type | +--rw tile-in-All1? schc:all1-data-type
| +--rw ack-behavior? schc:ack-behavior-type | +--rw ack-behavior? schc:ack-behavior-type
| +--rw bitmap-format? schc:bitmap-format-type
+--:(compression) +--:(compression)
+--rw entry* [field-id field-position direction-indicator] | +--rw entry* [field-id field-position direction-indicator]
+--rw field-id schc:field-id-type | +--rw field-id schc:fid-type
+--rw field-length schc:field-length-type | +--rw field-length schc:fl-type
+--rw field-position uint8 | +--rw field-position uint8
+--rw direction-indicator schc:direction-indicator-type | +--rw direction-indicator schc:di-type
+--rw target-values* [position] | +--rw target-value* [position]
| +--rw value? union | | +--rw value? binary
| +--rw position uint16 | | +--rw position uint16
+--rw matching-operator schc:matching-operator-type | +--rw matching-operator schc:mo-type
+--rw matching-operator-value* [position] | +--rw matching-operator-value* [position]
| +--rw value? union | | +--rw value? binary
| +--rw position uint16 | | +--rw position uint16
+--rw comp-decomp-action schc:comp-decomp-action-type | +--rw comp-decomp-action schc:cda-type
+--rw comp-decomp-action-value* [position] | +--rw comp-decomp-action-value* [position]
+--rw value? union | +--rw value? binary
+--rw position uint16 | +--rw position uint16
+--:(no-compression)
Figure 22 Figure 23
4. IANA Considerations 4. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
5. Security considerations 5. Security considerations
This document does not have any more Security consideration than the This document does not have any more Security consideration than the
ones already raised on [RFC8724] ones already raised on [RFC8724]
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Dominique Barthel, Carsten Bormann, The authors would like to thank Dominique Barthel, Carsten Bormann,
Alexander Pelov. Alexander Pelov.
7. YANG Module 7. YANG Module
<code begins> file schc@2020-02-28.yang <code begins> file ietf-schc@2021-08-17.yang
module schc{ module ietf-schc {
yang-version "1"; yang-version 1.1;
namespace "urn:ietf:lpwan:schc:rules-description"; namespace "urn:ietf:params:xml:ns:yang:ietf-schc";
prefix "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.
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.
*************************************************************************
Generic Data model for Static Context Header Compression Rule for SCHC,
based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression
rules and fragmentation rules.
This module is a YANG model for SCHC rules (RFc 8724).
RFC 8724 describes a rule in a abstract way through a table.
|-----------------------------------------------------------------|
| (FID) Rule 1 |
|+-------+--+--+--+------------+-----------------+---------------+|
||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
|+-------+--+--+--+------------+-----------------+---------------+|
||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
|+-------+--+--+--+------------+-----------------+---------------+|
||... |..|..|..| ... | ... | ... ||
|+-------+--+--+--+------------+-----------------+---------------+|
||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
+-------+--+--+--+------------+-----------------+---------------+||
|-----------------------------------------------------------------|
This module proposes a global data model that can be used for rule
exchanges or modification. It proposes both the data model format and
the global identifiers used to describes some operations in fields.
This data model applies both to compression and fragmentation.";
revision 2021-08-17 {
description description
"Generic Data model for Static Context Header Compression Rule for SCHC, "Initial version from RFC XXXX ";
based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression reference
rules and fragmentation rules. "RFC XXX: Data Model for Static Context Header Compression (SCHC)";
}
This module is a YANG model for SCHC rules (RFc 8724). feature fragmentation {
RFC 8724 describes a rule in a abstract way through a table. description
"Fragmentation is usually required only at the transportation level.";
}
|-----------------------------------------------------------------| // -------------------------
| (FID) Rule 1 | // Field ID type definition
|+-------+--+--+--+------------+-----------------+---------------+| //--------------------------
||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| // generic value TV definition
|+-------+--+--+--+------------+-----------------+---------------+| identity fid-base-type {
||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| description
|+-------+--+--+--+------------+-----------------+---------------+| "Field ID base type for all fields";
||... |..|..|..| ... | ... | ... || }
|+-------+--+--+--+------------+-----------------+---------------+|
||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
+-------+--+--+--+------------+-----------------+---------------+||
|-----------------------------------------------------------------|
This module proposes a global data model that can be used for rule identity fid-ipv6-base-type {
exchanges or modification. It proposes both the data model format and base fid-base-type;
the global identifiers used to describes some operations in fields. description
This data model applies both to compression and fragmentation."; "Field IP base type for IPv6 headers described in RFC 8200";
revision 2020-06-15 { }
description "clean up and add descriptions, merge schc-id to this file";
}
revision 2020-02-28 { identity fid-ipv6-version {
description "Add Fragmentation parameters"; base fid-ipv6-base-type;
} description
"IPv6 version field from RFC8200";
}
revision 2020-01-23 { identity fid-ipv6-trafficclass {
description "Modified TV with binary and union"; base fid-ipv6-base-type;
} description
"IPv6 Traffic Class field from RFC8200";
}
revision 2020-01-07 { identity fid-ipv6-trafficclass-ds {
description "First version of the YANG model"; base fid-ipv6-trafficclass;
} description
"IPv6 Traffic Class field from RFC8200,
DiffServ field from RFC3168";
}
// ------------------------- identity fid-ipv6-trafficclass-ecn {
// Field ID type definition base fid-ipv6-trafficclass;
//-------------------------- description
"IPv6 Traffic Class field from RFC8200,
ECN field from RFC3168";
}
// generic value TV definition identity fid-ipv6-flowlabel {
base fid-ipv6-base-type;
description
"IPv6 Flow Label field from RFC8200";
}
identity field-id-base-type { identity fid-ipv6-payloadlength {
description "Field ID with SID"; base fid-ipv6-base-type;
} description
"IPv6 Payload Length field from RFC8200";
}
identity fid-ipv6-nextheader {
base fid-ipv6-base-type;
description
"IPv6 Next Header field from RFC8200";
}
identity fid-ipv6-version { identity fid-ipv6-hoplimit {
base field-id-base-type; base fid-ipv6-base-type;
description "IPv6 version field from RFC8200"; description
} "IPv6 Next Header field from RFC8200";
}
identity fid-ipv6-trafficclass { identity fid-ipv6-devprefix {
base field-id-base-type; base fid-ipv6-base-type;
description "IPv6 Traffic Class field from RFC8200"; description
} "correspond either to the source address or the desdination
address prefix of RFC 8200. Depending if it is respectively
a uplink or an downklink message.";
}
identity fid-ipv6-trafficclass-ds { identity fid-ipv6-deviid {
base field-id-base-type; base fid-ipv6-base-type;
description "IPv6 Traffic Class field from RFC8200, description
DiffServ field from RFC3168"; "correspond either to the source address or the desdination
} address prefix of RFC 8200. Depending if it is respectively
a uplink or an downklink message.";
}
identity fid-ipv6-trafficclass-ecn { identity fid-ipv6-appprefix {
base field-id-base-type; base fid-ipv6-base-type;
description "IPv6 Traffic Class field from RFC8200, description
ECN field from RFC3168"; "correspond either to the source address or the desdination
} address prefix of RFC 768. Depending if it is respectively
identity fid-ipv6-flowlabel { a downlink or an uplink message.";
base field-id-base-type; }
description "IPv6 Flow Label field from RFC8200";
}
identity fid-ipv6-payloadlength { identity fid-ipv6-appiid {
base field-id-base-type; base fid-ipv6-base-type;
description "IPv6 Payload Length field from RFC8200"; description
} "correspond either to the source address or the desdination
address prefix of RFC 768. Depending if it is respectively
a downlink or an uplink message.";
}
identity fid-ipv6-nextheader { identity fid-udp-base-type {
base field-id-base-type; base fid-base-type;
description "IPv6 Next Header field from RFC8200"; description
} "Field IP base type for UDP headers described in RFC 768";
identity fid-ipv6-hoplimit { }
base field-id-base-type;
description "IPv6 Next Header field from RFC8200";
}
identity fid-ipv6-devprefix { identity fid-udp-dev-port {
base field-id-base-type; base fid-udp-base-type;
description "correspond either to the source address or the desdination description
address prefix of RFC 8200. Depending if it is respectively "UDP length from RFC 768";
a uplink or an downklink message."; }
}
identity fid-ipv6-deviid { identity fid-udp-app-port {
base field-id-base-type; base fid-udp-base-type;
description "correspond either to the source address or the desdination description
address prefix of RFC 8200. Depending if it is respectively "UDP length from RFC 768";
a uplink or an downklink message."; }
}
identity fid-ipv6-appprefix { identity fid-udp-length {
base field-id-base-type; base fid-udp-base-type;
description "correspond either to the source address or the desdination description
address prefix of RFC 768. Depending if it is respectively "UDP length from RFC 768";
a downlink or an uplink message."; }
}
identity fid-ipv6-appiid { identity fid-udp-checksum {
base field-id-base-type; base fid-udp-base-type;
description "correspond either to the source address or the desdination description
address prefix of RFC 768. Depending if it is respectively "UDP length from RFC 768";
a downlink or an uplink message."; }
}
identity fid-udp-dev-port {
base field-id-base-type;
description "UDP length from RFC 768";
}
identity fid-udp-app-port { identity fid-coap-base-type {
base field-id-base-type; base fid-base-type;
description "UDP length from RFC 768"; description
} "Field IP base type for UDP headers described in RFC 768";
}
identity fid-udp-length { identity fid-coap-version {
base field-id-base-type; base fid-coap-base-type;
description "UDP length from RFC 768"; description
} "CoAP version from RFC 7252";
}
identity fid-udp-checksum { identity fid-coap-type {
base field-id-base-type; base fid-coap-base-type;
description "UDP length from RFC 768"; description
} "CoAP type from RFC 7252";
}
identity fid-coap-version { identity fid-coap-tkl {
base field-id-base-type; base fid-coap-base-type;
description "CoAP version from RFC 7252"; description
} "CoAP token length from RFC 7252";
identity fid-coap-type { }
base field-id-base-type;
description "CoAP type from RFC 7252";
}
identity fid-coap-tkl { identity fid-coap-code {
base field-id-base-type; base fid-coap-base-type;
description "CoAP token length from RFC 7252"; description
} "CoAP code from RFC 7252";
}
identity fid-coap-code { identity fid-coap-code-class {
base field-id-base-type; base fid-coap-code;
description "CoAP code from RFC 7252"; description
} "CoAP code class from RFC 7252";
}
identity fid-coap-code-class { identity fid-coap-code-detail {
base field-id-base-type; base fid-coap-code;
description "CoAP code class from RFC 7252"; description
} "CoAP code detail from RFC 7252";
}
identity fid-coap-code-detail { identity fid-coap-mid {
base field-id-base-type; base fid-coap-base-type;
description "CoAP code detail from RFC 7252"; description
"CoAP message ID from RFC 7252";
}
} identity fid-coap-token {
base fid-coap-base-type;
description
"CoAP token from RFC 7252";
}
identity fid-coap-mid { identity fid-coap-option-if-match {
base field-id-base-type; base fid-coap-base-type;
description "CoAP message ID from RFC 7252"; description
} "CoAP option If-Match from RFC 7252";
}
identity fid-coap-token { identity fid-coap-option-uri-host {
base field-id-base-type; base fid-coap-base-type;
description "CoAP token from RFC 7252"; description
} "CoAP option URI-Host from RFC 7252";
}
identity fid-coap-option-if-match { identity fid-coap-option-etag {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option If-Match from RFC 7252"; description
} "CoAP option Etag from RFC 7252";
identity fid-coap-option-uri-host { }
base field-id-base-type;
description "CoAP option URI-Host from RFC 7252";
}
identity fid-coap-option-etag { identity fid-coap-option-if-none-match {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Etag from RFC 7252"; description
} "CoAP option if-none-match from RFC 7252";
}
identity fid-coap-option-if-none-match { identity fid-coap-option-observe {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option if-none-match from RFC 7252"; description
} "CoAP option Observe from RFC 7641";
}
identity fid-coap-option-observe { identity fid-coap-option-uri-port {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Observe from RFC 7641"; description
} "CoAP option Uri-Port from RFC 7252";
}
identity fid-coap-option-uri-port { identity fid-coap-option-location-path {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Uri-Port from RFC 7252"; description
} "CoAP option Location-Path from RFC 7252";
}
identity fid-coap-option-location-path { identity fid-coap-option-uri-path {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Location-Path from RFC 7252"; description
} "CoAP option Uri-Path from RFC 7252";
}
identity fid-coap-option-uri-path { identity fid-coap-option-content-format {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Uri-Path from RFC 7252"; description
} "CoAP option Content Format from RFC 7252";
}
identity fid-coap-option-content-format { identity fid-coap-option-max-age {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Content Format from RFC 7252"; description
} "CoAP option Max-Age from RFC 7252";
}
identity fid-coap-option-max-age { identity fid-coap-option-uri-query {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Max-Age from RFC 7252"; description
} "CoAP option Uri-Query from RFC 7252";
identity fid-coap-option-uri-query { }
base field-id-base-type;
description "CoAP option Uri-Query from RFC 7252";
}
identity fid-coap-option-accept { identity fid-coap-option-accept {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Max-Age from RFC 7252"; description
} "CoAP option Max-Age from RFC 7252";
}
identity fid-coap-option-location-query { identity fid-coap-option-location-query {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Location-Query from RFC 7252"; description
} "CoAP option Location-Query from RFC 7252";
}
identity fid-coap-option-block2 { identity fid-coap-option-block2 {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Block2 from RFC 7959"; description
} "CoAP option Block2 from RFC 7959";
}
identity fid-coap-option-block1 { identity fid-coap-option-block1 {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Block1 from RFC 7959"; description
} "CoAP option Block1 from RFC 7959";
}
identity fid-coap-option-size2 { identity fid-coap-option-size2 {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option size2 from RFC 7959"; description
} "CoAP option size2 from RFC 7959";
}
identity fid-coap-option-proxy-uri { identity fid-coap-option-proxy-uri {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Proxy-Uri from RFC 7252"; description
} "CoAP option Proxy-Uri from RFC 7252";
identity fid-coap-option-proxy-scheme { }
base field-id-base-type;
description "CoAP option Proxy-scheme from RFC 7252";
}
identity fid-coap-option-size1 { identity fid-coap-option-proxy-scheme {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option Size1 from RFC 7252"; description
} "CoAP option Proxy-scheme from RFC 7252";
}
identity fid-coap-option-no-response { identity fid-coap-option-size1 {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option No response from RFC 7967"; description
} "CoAP option Size1 from RFC 7252";
identity fid-coap-option-oscore-flags { }
base field-id-base-type;
description "CoAP option oscore flags (see draft schc coap, section 6.4)";
}
identity fid-coap-option-oscore-piv { identity fid-coap-option-no-response {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option oscore flags (see draft schc coap, section 6.4)"; description
} "CoAP option No response from RFC 7967";
}
identity fid-coap-option-oscore-kid { identity fid-coap-option-oscore-flags {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option oscore flags (see draft schc coap, section 6.4)"; description
} "CoAP option oscore flags (see draft schc coap, section 6.4)";
}
identity fid-coap-option-oscore-kidctx { identity fid-coap-option-oscore-piv {
base field-id-base-type; base fid-coap-base-type;
description "CoAP option oscore flags (see draft schc coap, section 6.4)"; description
} "CoAP option oscore flags (see draft schc coap, section 6.4)";
}
identity fid-icmpv6-type { identity fid-coap-option-oscore-kid {
base field-id-base-type; base fid-coap-base-type;
description "ICMPv6 field (see draft OAM)"; description
} "CoAP option oscore flags (see draft schc coap, section 6.4)";
}
identity fid-icmpv6-code { identity fid-coap-option-oscore-kidctx {
base field-id-base-type; base fid-coap-base-type;
description "ICMPv6 field (see draft OAM)"; description
} "CoAP option oscore flags (see draft schc coap, section 6.4)";
}
identity fid-icmpv6-checksum { identity fid-icmpv6-base-type {
base field-id-base-type; base fid-base-type;
description "ICMPv6 field (see draft OAM)"; description
"Field IP base type for UDP headers described in RFC 768";
}
} identity fid-icmpv6-type {
base fid-icmpv6-base-type;
description
"ICMPv6 field (see draft OAM)";
}
identity fid-icmpv6-identifier { identity fid-icmpv6-code {
base field-id-base-type; base fid-icmpv6-base-type;
description "ICMPv6 field (see draft OAM)"; description
} "ICMPv6 field (see draft OAM)";
identity fid-icmpv6-sequence { }
base field-id-base-type;
description "ICMPv6 field (see draft OAM)";
}
/// !!!!!!! See future CoAP extentions identity fid-icmpv6-checksum {
base fid-icmpv6-base-type;
description
"ICMPv6 field (see draft OAM)";
}
//---------------------------------- identity fid-icmpv6-identifier {
// Field Length type definition base fid-icmpv6-base-type;
//---------------------------------- description
"ICMPv6 field (see draft OAM)";
}
identity field-length-base-type { identity fid-icmpv6-sequence {
description "used to extend field length functions"; base fid-icmpv6-base-type;
description
"ICMPv6 field (see draft OAM)";
}
//----------------------------------
// Field Length type definition
//----------------------------------
identity fl-base-type {
description
"Used to extend field length functions";
} }
identity fl-variable { identity fl-variable {
base field-length-base-type; base fl-base-type;
description "residue length in Byte is sent"; description
"Residue length in Byte is sent defined in
for CoAP in RFC 8824 (cf. 5.3)";
} }
identity fl-token-length { identity fl-token-length {
base field-length-base-type; base fl-base-type;
description "residue length in Byte is sent"; description
"Residue length in Byte is sent defined in
for CoAP in RFC 8824 (cf. 4.5)";
} }
//--------------------------------- //---------------------------------
// Direction Indicator type // Direction Indicator type
//--------------------------------- //---------------------------------
identity direction-indicator-base-type { identity di-base-type {
description "used to extend field length functions"; description
"Used to extend field length functions";
} }
identity di-bidirectional { identity di-bidirectional {
base direction-indicator-base-type; base di-base-type;
description "Direction Indication of bi directionality"; description
"Direction Indication of bi directionality in
RFC 8724 (cf. 7.1)";
} }
identity di-up { identity di-up {
base direction-indicator-base-type; base di-base-type;
description "Direction Indication of upstream"; description
"Direction Indication of upstream defined in
RFC 8724 (cf. 7.1)";
} }
identity di-down { identity di-down {
base direction-indicator-base-type; base di-base-type;
description "Direction Indication of downstream"; description
"Direction Indication of downstream defined in
RFC 8724 (cf. 7.1)";
} }
//---------------------------------- //----------------------------------
// Matching Operator type definition // Matching Operator type definition
//---------------------------------- //----------------------------------
identity matching-operator-base-type {
description "used to extend Matching Operators with SID values";
}
identity mo-equal { identity mo-base-type {
base matching-operator-base-type; description
description "RFC 8724"; "Used to extend Matching Operators with SID values";
} }
identity mo-ignore { identity mo-equal {
base matching-operator-base-type; base mo-base-type;
description "RFC 8724"; description
} "Equal MO as defined RFC 8724 (cf. 7.3)";
}
identity mo-msb { identity mo-ignore {
base matching-operator-base-type; base mo-base-type;
description "RFC 8724"; description
} "Ignore MO as defined RFC 8724 (cf. 7.3)";
}
identity mo-matching { identity mo-msb {
base matching-operator-base-type; base mo-base-type;
description "RFC 8724"; description
} "MSB MO as defined RFC 8724 (cf. 7.3)";
}
//------------------------------ identity mo-matching {
// CDA type definition base mo-base-type;
//------------------------------ description
"match-mapping MO as defined RFC 8724 (cf. 7.3)";
}
identity compression-decompression-action-base-type; //------------------------------
// CDA type definition
//------------------------------
identity cda-not-sent { identity cda-base-type {
base compression-decompression-action-base-type; description
description "RFC 8724"; "Compression Decompression Actions";
} }
identity cda-value-sent { identity cda-not-sent {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "not-sent CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-lsb { identity cda-value-sent {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "value-sent CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-mapping-sent { identity cda-lsb {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "LSB CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-compute-length { identity cda-mapping-sent {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-compute-checksum { identity cda-compute-length {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "compute-length CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-compute-checksum {
base cda-base-type;
description
"compute-checksum CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-deviid { identity cda-deviid {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "deviid CDA as defines in RFC 8724 (cf. 7.4)";
}
identity cda-appiid { identity cda-appiid {
base compression-decompression-action-base-type; base cda-base-type;
description "RFC 8724"; description
} "appiid CDA as defines in RFC 8724 (cf. 7.4)";
}
// -- type definition // -- type definition
typedef field-id-type { typedef fid-type {
description "Field ID generic type."; type identityref {
type identityref { base fid-base-type;
base field-id-base-type;
}
} }
description
"Field ID generic type.";
}
typedef field-length-type { typedef fl-type {
description "Field length either a positive integer giving the size in bits type union {
or a function defined through an identityref."; type int64; /* positive length in bits */
type union { type identityref { /* function */
type int64; /* positive length in bits */ base fl-base-type;
type identityref { /* function */ }
base field-length-base-type;
}
}
} }
description
"Field length either a positive integer giving the size in bits
or a function defined through an identityref.";
}
typedef direction-indicator-type { typedef di-type {
description "direction in LPWAN network, up when emitted by the device, type identityref {
down when received by the device, bi when emitted or received by the device."; base di-base-type;
type identityref {
base direction-indicator-base-type;
}
} }
description
typedef matching-operator-type { "Direction in LPWAN network, up when emitted by the device,
description "Matching Operator (MO) to compare fields values with target values"; down when received by the device, bi when emitted or received by the device.";
type identityref { }
base matching-operator-base-type; typedef mo-type {
} type identityref {
base mo-base-type;
} }
description
"Matching Operator (MO) to compare fields values with target values";
}
typedef comp-decomp-action-type { typedef cda-type {
description "Compression Decompression Action to compression or decompress a field."; type identityref {
type identityref { base cda-base-type;
base compression-decompression-action-base-type;
}
} }
description
"Compression Decompression Action to compression or decompress a field.";
}
// -- FRAGMENTATION TYPE // -- FRAGMENTATION TYPE
// -- fragmentation modes
// -- fragmentation modes identity fragmentation-mode-base-type {
description
"fragmentation mode";
}
identity fragmentation-mode-base-type { identity fragmentation-mode-no-ack {
description "fragmentation mode"; base fragmentation-mode-base-type;
} description
"No Ack of RFC 8724.";
}
identity fragmentation-mode-no-ack { identity fragmentation-mode-ack-always {
description "No Ack of RFC 8724."; base fragmentation-mode-base-type;
base fragmentation-mode-base-type; description
} "Ack Always of RFC8724.";
}
identity fragmentation-mode-ack-always { identity fragmentation-mode-ack-on-error {
description "Ack Always of RFC8724."; base fragmentation-mode-base-type;
base fragmentation-mode-base-type; description
} "Ack on Error of RFC8724.";
identity fragmentation-mode-ack-on-error { }
description "Ack on Error of RFC8724.";
base fragmentation-mode-base-type;
typedef fragmentation-mode-type {
type identityref {
base fragmentation-mode-base-type;
} }
description
"type used in rules";
typedef fragmentation-mode-type { }
type identityref {
base fragmentation-mode-base-type;
}
}
// -- Ack behavior // -- Ack behavior
identity ack-behavior-base-type { identity ack-behavior-base-type {
description "define when to send an Acknowledgment message"; description
} "Define when to send an Acknowledgment message";
}
identity ack-behavior-after-All0 { identity ack-behavior-after-All0 {
description "fragmentation expects Ack after sending All0 fragment."; base ack-behavior-base-type;
base ack-behavior-base-type; description
} "Fragmentation expects Ack after sending All0 fragment.";
}
identity ack-behavior-after-All1 { identity ack-behavior-after-All1 {
description "fragmentation expects Ack after sending All1 fragment."; base ack-behavior-base-type;
base ack-behavior-base-type; description
} "Fragmentation expects Ack after sending All1 fragment.";
}
identity ack-behavior-always { identity ack-behavior-always {
description "fragmentation expects Ack after sending every fragment."; base ack-behavior-base-type;
base ack-behavior-base-type; description
} "Fragmentation expects Ack after sending every fragment.";
}
typedef ack-behavior-type { typedef ack-behavior-type {
type identityref { type identityref {
base ack-behavior-base-type; base ack-behavior-base-type;
}
} }
description
"Type used in rules";
}
// -- All1 with data types // -- All1 with data types
identity all1-data-base-type { identity all1-data-base-type {
description "type to define when to send an Acknowledgment message"; description
} "Type to define when to send an Acknowledgment message";
}
identity all1-data-no { identity all1-data-no {
description "All1 contains no tiles."; base all1-data-base-type;
base all1-data-base-type; description
} "All1 contains no tiles.";
}
identity all1-data-yes {
base all1-data-base-type;
description
"All1 MUST contain a tile";
}
identity all1-data-yes { identity all1-data-sender-choice {
description "All1 MUST contain a tile"; base all1-data-base-type;
base all1-data-base-type; description
} "Fragmentation process choose to send tiles or not in all1.";
}
identity all1-data-sender-choice { typedef all1-data-type {
description "Fragmentation process choose to send tiles or not in all1."; type identityref {
base all1-data-base-type; base all1-data-base-type;
} }
description
"Type used in rules";
}
typedef all1-data-type { // -- RCS algorithm types
type identityref {
base all1-data-base-type;
}
}
// -- RCS algorithm types identity rcs-algorithm-base-type {
description
"Identify which algorithm is used to compute RSC.
The algorithm also defines the size if the RSC field.";
}
identity RCS-algorithm-base-type { identity rcs-RFC8724 {
description "identify which algorithm is used to compute RSC. base rcs-algorithm-base-type;
The algorithm defines also the size if the RSC field."; description
} "CRC 32 defined as default RCS in RFC8724.";
}
identity RFC8724-RCS { typedef rcs-algorithm-type {
description "CRC 32 defined as default RCS in RFC8724."; type identityref {
base RCS-algorithm-base-type; base rcs-algorithm-base-type;
} }
description
"type used in rules";
}
typedef RCS-algorithm-type { // --- Bitmap format
type identityref {
base RCS-algorithm-base-type;
}
}
// -------- RULE ENTRY DEFINITION ------------ identity bitmap-format-base-type {
description
"Define how the bitmap is defined in ACK messages.";
}
identity bitmap-RFC8724 {
base bitmap-format-base-type;
description
"Bitmap as defined in RFC8724.";
}
grouping target-values-struct { identity bitmap-compound-ack {
description "defines the target value element. Can be either an arbitrary base bitmap-format-base-type;
binary or ascii element. All target values are considered as a matching lists. description
Position is used to order values, by default position 0 is used when containing "Compound Ack.";
a single element."; }
leaf value { typedef bitmap-format-type {
type union { type identityref {
type binary; base bitmap-format-base-type;
type string;
}
}
leaf position {
description "If only one element position is 0, otherwise position is the
matching list.";
type uint16;
}
} }
description
"type used in rules";
}
grouping compression-rule-entry { // -------- RULE ENTRY DEFINITION ------------
description "These entries defines a compression entry (i.e. a line)
as defined in RFC 8724 and fragmentation parameters.
+-------+--+--+--+------------+-----------------+---------------+
|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
+-------+--+--+--+------------+-----------------+---------------+
An entry in a compression rule is composed of 7 elements:
- Field ID: The header field to be compressed. The content is a YANG identifer.
- Field Length : either a positive integer of a function defined as a YANF id.
- Field Position: a positive (and possibly equal to 0) integer.
- Direction Indicator: a YANG identifier giving the direction.
- Target value: a value against which the header Field is compared.
- Matching Operator: a YANG id giving the operation, paramters may be
associated to that operator.
- Comp./Decomp. Action: A YANG id giving the compression or decompression
action, paramters may be associated to that action.
";
leaf field-id { grouping tv-struct {
description "Field ID, identify a field in the header with a YANG refenceid."; description
mandatory true; "Define the target value element. Always a binary type, strings
type schc:field-id-type; must be converted to binary. field-id allows the conversion to the appropriate
} type.";
leaf field-length { leaf value {
description "Field Length in bit or through a function defined as a YANG referenceid"; type binary;
mandatory true;
type schc:field-length-type;
}
leaf field-position {
description "field position in the header is a integer. If the field is not repeated
in the header the value is 1, and incremented for each repetition of the field. Position
0 means that the position is not important and order may change when decompressed";
mandatory true;
type uint8;
}
leaf direction-indicator {
description "Direction Indicator, a YANG referenceid to say if the packet is bidirectionnal,
up or down";
mandatory true;
type schc:direction-indicator-type;
}
list target-values {
description "a list of value to compare with the header field value. If target value
is a singleton, position must be 0. For matching-list, should be consecutive position
values starting from 1.";
key position;
uses target-values-struct;
}
leaf matching-operator {
mandatory true;
type schc:matching-operator-type;
}
list matching-operator-value {
key position;
uses target-values-struct;
}
leaf comp-decomp-action {
mandatory true;
type schc:comp-decomp-action-type;
}
list comp-decomp-action-value {
key position;
uses target-values-struct;
}
} }
leaf position {
grouping compression-content { type uint16;
description "define a compression rule composed of a list of entries."; description
list entry { "If only one element position is 0, otherwise position is the
key "field-id field-position direction-indicator"; matching list.";
uses compression-rule-entry;
}
} }
}
grouping fragmentation-content { grouping compression-rule-entry {
description "This grouping defines the fragmentation parameters for description
all the modes (No Ack, Ack Always and Ack on Error) specified in "These entries defines a compression entry (i.e. a line)
RFC 8724."; as defined in RFC 8724 and fragmentation parameters.
leaf direction { +-------+--+--+--+------------+-----------------+---------------+
type schc:direction-indicator-type; |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
description "should be up or down, bi directionnal is forbiden."; +-------+--+--+--+------------+-----------------+---------------+
mandatory true;
}
leaf dtagsize {
type uint8;
description "size in bit of the DTag field";
} An entry in a compression rule is composed of 7 elements:
leaf wsize {
type uint8;
description "size in bit of the window field";
}
leaf fcnsize {
type uint8;
description "size in bit of the FCN field";
mandatory true;
}
leaf RCS-algorithm {
type RCS-algorithm-type;
default schc:RFC8724-RCS;
description "Algoritm used for RCS";
}
leaf maximum-window-size {
type uint16;
description "by default 2^wsize - 1";
}
leaf retransmission-timer { - Field ID: The header field to be compressed. The content is a YANG identifer.
type uint64 { - Field Length : either a positive integer of a function defined as a YANF id.
range 1..max; - Field Position: a positive (and possibly equal to 0) integer.
} - Direction Indicator: a YANG identifier giving the direction.
description "duration in seconds of the retransmission timer"; // Check the units - Target value: a value against which the header Field is compared.
} - Matching Operator: a YANG id giving the operation, paramters may be
associated to that operator.
- Comp./Decomp. Action: A YANG id giving the compression or decompression
action, paramters may be associated to that action.
";
leaf field-id {
type schc:fid-type;
mandatory true;
description
"Field ID, identify a field in the header with a YANG refenceid.";
}
leaf field-length {
type schc:fl-type;
mandatory true;
description
"Field Length in bit or through a function defined as a YANG referenceid";
}
leaf field-position {
type uint8;
mandatory true;
description
"Field position in the header is a integer. If the field is not repeated
in the header the value is 1, and incremented for each repetition of the field. Position
0 means that the position is not important and order may change when decompressed";
}
leaf direction-indicator {
type schc:di-type;
mandatory true;
description
"Direction Indicator, a YANG referenceid to say if the packet is bidirectional,
up or down";
}
list target-value {
key "position";
uses tv-struct;
description
"A list of value to compare with the header field value. If target value
is a singleton, position must be 0. For matching-list, should be consecutive position
values starting from 1.";
}
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 require 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";
}
list matching-operator-value {
key "position";
uses tv-struct;
description
"Matching Operator Arguments, based on TV structure to allow several arguments.
In RFC 8724, only MSB define a single argument: length in bits ";
}
leaf comp-decomp-action {
type schc:cda-type;
mandatory true;
description
"CDA: Compression Decompression Action";
}
list comp-decomp-action-value {
key "position";
uses tv-struct;
description
"CDA Arguments, based on TV structure to allow several arguments.
In RFC 8724, no argument is defined for CDA";
}
}
leaf inactivity-timer { grouping compression-content {
type uint64; list entry {
description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units key "field-id field-position direction-indicator";
} uses compression-rule-entry;
description
"A compression rule is a list of rule entry describing
each header field. An entry is identifed through a field-id, its position
in the packet and its direction";
}
description
"Define a compression rule composed of a list of entries.";
}
leaf max-ack-requests { grouping fragmentation-content {
type uint8 { description
range 1..max; "This grouping defines the fragmentation parameters for
} all the modes (No Ack, Ack Always and Ack on Error) specified in
description "the maximum number of retries for a specific SCHC ACK."; RFC 8724.";
leaf l2-word-size {
type uint8;
default "8";
description
"Size in bit of the layer 2 word";
}
leaf direction {
must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" {
error-message "direction for fragmentation rules are up or down";
}
type schc:di-type;
mandatory true;
description
"Should be up or down, bi directionnal is forbiden.";
}
leaf dtag-size {
type uint8;
default "0";
description
"Size in bit of the DTag field";
}
leaf w-size {
when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))";
type uint8;
description
"Size in bit of the window field";
}
leaf fcn-size {
type uint8;
mandatory true;
description
"Size in bit of the FCN field";
}
leaf rcs-algorithm {
type rcs-algorithm-type;
default "schc:rcs-RFC8724";
description
"Algoritm used for RCS";
}
leaf maximum-window-size {
type uint16;
description
"By default 2^wsize - 1";
}
leaf retransmission-timer {
type uint64 {
range "1..max";
}
description
"Duration in seconds of the retransmission timer"; // Check the units
}
leaf inactivity-timer {
type uint64;
description
"Duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units
}
leaf max-ack-requests {
type uint8 {
range "1..max";
}
description
"The maximum number of retries for a specific SCHC ACK.";
}
leaf maximum-packet-size {
type uint16;
default "1280";
description
"When decompression is done, packet size must not strictly exceed this limit in Bytes";
}
leaf fragmentation-mode {
type schc:fragmentation-mode-type;
mandatory true;
description
"which fragmentation mode is used (noAck, AckAlways, AckonError)";
}
choice mode {
case no-ack;
case ack-always;
case ack-on-error {
leaf tile-size {
type uint8;
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
description
"Size in bit of tiles, if not specified or set to 0: tile fills the fragment.";
} }
leaf tile-in-All1 {
leaf maximum-packet-size { type schc:all1-data-type;
type uint16; when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
default 1280; description
description "When decompression is done, packet size must not strictly exceed this limit in Bytes"; "When true, sender and receiver except a tile in All-1 frag";
} }
leaf ack-behavior {
leaf fragmentation-mode { type schc:ack-behavior-type;
type schc:fragmentation-mode-type; when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
description "which fragmentation mode is used (noAck, AckAlways, AckonError)"; description
mandatory true; "Sender behavior to acknowledge, after All-0, All-1 or when the
LPWAN allows it (Always)";
} }
leaf bitmap-format {
choice mode { type schc:bitmap-format-type;
case no-ack; when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
case ack-always; default "schc:bitmap-RFC8724";
case ack-on-error { description
leaf tile-size { "How the bitmaps are included in the Ack message.";
type uint8; }
description "size in bit of tiles, if not specified or set to 0: tile fills the fragment."; }
} description
leaf tile-in-All1 { "RFC 8724 defines 3 fragmentation modes";
type schc:all1-data-type;
description "When true, sender and receiver except a tile in All-1 frag";
}
leaf ack-behavior {
type schc:ack-behavior-type;
description "Sender behavior to acknowledge, after All-0, All-1 or when the
LPWAN allows it (Always)";
}
}
}
} }
}
// Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length
grouping rule-id-type { grouping rule-id-type {
leaf rule-id { leaf rule-id-value {
type uint32; type uint32;
description "rule ID value, this value must be unique combined with the length"; description
} "Rule ID value, this value must be unique combined with the length";
leaf rule-length {
type uint8 {
range 0..32;
}
description "rule ID length in bits, value 0 is for implicit rules";
}
} }
leaf rule-id-length {
type uint8 {
range "0..32";
}
description
"Rule ID length in bits, value 0 is for implicit rules";
}
description
"A rule ID is composed of a value and a length in bit";
}
// SCHC table for a specific device. // SCHC table for a specific device.
container schc {
leaf version{
type uint64;
mandatory false;
description "used as an indication for versioning";
container schc {
list rule {
key "rule-id-value rule-id-length";
uses rule-id-type;
choice nature {
case fragmentation {
if-feature "fragmentation";
uses fragmentation-content;
} }
list rule { case compression {
key "rule-id rule-length"; uses compression-content;
uses rule-id-type; }
choice nature { case no-compression {
case fragmentation { description
uses fragmentation-content; "RFC8724 allows a rule for uncompressed headers";
}
case compression {
uses compression-content;
}
}
} }
description
"A rule is either for compression, no compression or fragmentation";
}
description
"Set of rules compression, no compression or fragmentation rules
identified by their rule-id ";
} }
description
"a SCHC set of rules is composed of a list of rule which are either
compression or fragmentation";
}
} }
<code ends> <code ends>
Figure 23 Figure 24
8. Normative References 8. Normative References
[I-D.barthel-lpwan-oam-schc] [I-D.barthel-lpwan-oam-schc]
Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and
J. Zuniga, "OAM for LPWAN using Static Context Header J. C. Zuniga, "OAM for LPWAN using Static Context Header
Compression (SCHC)", draft-barthel-lpwan-oam-schc-02 (work Compression (SCHC)", Work in Progress, Internet-Draft,
in progress), November 2020. draft-barthel-lpwan-oam-schc-02, 2 November 2020,
<https://www.ietf.org/archive/id/draft-barthel-lpwan-oam-
schc-02.txt>.
[I-D.ietf-lpwan-coap-static-context-hc] [I-D.ietf-lpwan-schc-compound-ack]
Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static Zuniga, J. C., Gomez, C., Aguilar, S., Toutain, L.,
Context Header Compression (SCHC) for CoAP", draft-ietf- Cespedes, S., and D. Wistuba, "SCHC Compound ACK", Work in
lpwan-coap-static-context-hc-18 (work in progress), Progress, Internet-Draft, draft-ietf-lpwan-schc-compound-
January 2021. ack-00, 9 July 2021, <https://www.ietf.org/archive/id/
draft-ietf-lpwan-schc-compound-ack-00.txt>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header Zúñiga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724, Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020, DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>. <https://www.rfc-editor.org/info/rfc8724>.
[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/info/rfc8824>.
Authors' Addresses Authors' Addresses
Ana Minaburo Ana Minaburo
Acklio Acklio
1137A avenue des Champs Blancs 1137A avenue des Champs Blancs
35510 Cesson-Sevigne Cedex 35510 Cesson-Sevigne Cedex
France France
Email: ana@ackl.io Email: ana@ackl.io
 End of changes. 331 change blocks. 
1255 lines changed or deleted 1797 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/