< draft-ietf-lpwan-schc-yang-data-model-05.txt   draft-ietf-lpwan-schc-yang-data-model-06.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: 13 March 2022 Institut MINES TELECOM; IMT Atlantique Expires: 28 May 2022 Institut MINES TELECOM; IMT Atlantique
9 September 2021 24 November 2021
Data Model for Static Context Header Compression (SCHC) Data Model for Static Context Header Compression (SCHC)
draft-ietf-lpwan-schc-yang-data-model-05 draft-ietf-lpwan-schc-yang-data-model-06
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 13 March 2022. This Internet-Draft will expire on 28 May 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised 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. Identifier generation . . . . . . . . . . . . . . . . . . 4 2.2. Identifier generation . . . . . . . . . . . . . . . . . . 4
2.3. Field Identifier . . . . . . . . . . . . . . . . . . . . 5 2.3. Field Identifier . . . . . . . . . . . . . . . . . . . . 5
2.4. Field length . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Field length . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Field position . . . . . . . . . . . . . . . . . . . . . 8 2.5. Field position . . . . . . . . . . . . . . . . . . . . . 8
2.6. Direction Indicator . . . . . . . . . . . . . . . . . . . 8 2.6. Direction Indicator . . . . . . . . . . . . . . . . . . . 8
2.7. Target Value . . . . . . . . . . . . . . . . . . . . . . 9 2.7. Target Value . . . . . . . . . . . . . . . . . . . . . . 9
2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10 2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10
2.8.1. Matching Operator arguments . . . . . . . . . . . . . 11 2.8.1. Matching Operator arguments . . . . . . . . . . . . . 11
2.9. Compression Decompression Actions . . . . . . . . . . . . 11 2.9. Compression Decompression Actions . . . . . . . . . . . . 11
2.9.1. Compression Decompression Action arguments . . . . . 12 2.9.1. Compression Decompression Action arguments . . . . . 13
2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 12 2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 13
2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 12 2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 13
2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 13 2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 14
2.10.3. Last fragment format . . . . . . . . . . . . . . . . 14 2.10.3. Last fragment format . . . . . . . . . . . . . . . . 15
2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 16 2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 17
2.10.5. Fragmentation Parameters . . . . . . . . . . . . . . 18 2.10.5. Fragmentation Parameters . . . . . . . . . . . . . . 18
2.10.6. Layer 2 parameters . . . . . . . . . . . . . . . . . 19 2.10.6. Layer 2 parameters . . . . . . . . . . . . . . . . . 19
3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 19 3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 21 3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 21
3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 23 3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 24
3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5. Security considerations . . . . . . . . . . . . . . . . . . . 28 5. Security considerations . . . . . . . . . . . . . . . . . . . 28
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Normative References . . . . . . . . . . . . . . . . . . . . 50 8. Normative References . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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 of the constrained network.
Draft [RFC8724] provides a non formal representation of the rules [RFC8724] provides a non formal representation of the rules used
used either for compression/decompression (or C/D) or fragmentation/ 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:
* 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.
* an update the other end to set up some specific values (e.g. IPv6 * an update of the other end to set up some specific values (e.g.
prefix, Destination address,...) IPv6 prefix, Destination address,...)
* ... * ...
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 does not refer 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 [RFC8824] specifies fields for IPv6, UDP, CoAP string. [RFC8724] and [RFC8824] specify fields for IPv6, UDP, CoAP
and OSCORE. [I-D.barthel-lpwan-oam-schc] describes ICMPv6 header and OSCORE.
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 a 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.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
|+-------+--+--+--+------------+-----------------+---------------+||/ |+-------+--+--+--+------------+-----------------+---------------+||/
||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. Identifier generation 2.2. Identifier generation
Identifier used un the SCHC YANG Data Model are from the identityref Identifier used in the SCHC YANG Data Model are from the identityref
statement to ensure to be globally unique and be easily augmented if 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 needed. The principle to define a new type based on a group of
identityref is the following: identityref is the following:
* define a main identity ending with the keyword base-type. * define a main identity ending with the keyword base-type.
* derive all the identity used in the Data Model from this base * derive all the identity used in the Data Model from this base
type. type.
* create a typedef from this base type. * create a typedef from this base type.
The example (Figure 2) shows how an identityref is created for RCS The example (Figure 2) shows how an identityref is created for RCS
algorithms used during SCHC fragmentation. algorithms used during SCHC fragmentation.
// -- RCS algorithm types // -- RCS algorithm types
identity rcs-algorithm-base-type { identity rcs-algorithm-base-type {
description description
"identify which algorithm is used to compute RSC. "Identify which algorithm is used to compute RSC.
The algorithm also defines the size if the RSC field."; The algorithm also defines the size if the RSC field.";
} }
identity rcs-RFC8724 { identity rcs-RFC8724 {
base rcs-algorithm-base-type; base rcs-algorithm-base-type;
description description
"CRC 32 defined as default RCS in RFC8724."; "CRC 32 defined as default RCS in RFC8724.";
} }
typedef rcs-algorithm-type { typedef rcs-algorithm-type {
skipping to change at page 5, line 9 skipping to change at page 5, line 9
description description
"type used in rules"; "type used in rules";
} }
Figure 2: Principle to define a type based on identityref. Figure 2: Principle to define a type based on identityref.
2.3. Field Identifier 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 rule and apply
compression. The link between the list given by the parsed fields compression. [RFC8724] do not state how the field ID value can be
and the rules is done through a field ID. [RFC8724] do not state how constructed. In examples, identification is done through a string
the field ID value can be constructed. In examples, identification indexed by the protocol name (e.g. IPv6.version, CoAP.version,...).
is done through a string indexed by the protocol name (e.g.
IPv6.version, CoAP.version,...).
The current YANG Data Model includes fields definitions found in The current YANG Data Model includes fields definitions found in
[RFC8724], [RFC8824], and [I-D.barthel-lpwan-oam-schc]. [RFC8724], [RFC8824].
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 for the protocol always derives YANG identityref. A YANG field ID for the protocol always derives
from the fid-base-type. Then an identity for each protocol is from the fid-base-type. Then an identity for each protocol is
specified using the naming convention fid-<<protocol name>>-base- specified using the naming convention fid-<<protocol name>>-base-
type. All possible fields for this protocol MUST derive from the type. All possible fields for this protocol MUST derive from the
protocol identity. The naming convention is "fid" followed by the protocol identity. The naming convention is "fid" followed by the
protocol name and the field name. If a field has to be divided into protocol name and the field name. If a field has to be divided into
sub-fields, the field identity serves as a base. sub-fields, the field identity serves as a base.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
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 [RFC8824] defines the "tkl" allows variable length fields in byte and [RFC8824] defines the "tkl"
function for managing the CoAP Token length field. function for managing the CoAP Token length field.
The naming convention is "fl" followed by the function name. The naming convention is "fl" followed by the function name.
identity fl-base-type { identity fl-base-type {
description description
"Used to extend field length functions"; "Used to extend field length functions.";
} }
identity fl-variable { identity fl-variable {
base fl-base-type; base fl-base-type;
description description
"Residue length in Byte is sent defined in "Residue length in Byte is sent as defined in
for CoAP in RFC 8824 (cf. 5.3)"; for CoAP in RFC 8824 (cf. 5.3).";
} }
identity fl-token-length { identity fl-token-length {
base fl-base-type; base fl-base-type;
description description
"Residue length in Byte is sent defined in "Residue length in Byte is sent as defined in
for CoAP in RFC 8824 (cf. 4.5)"; for CoAP in RFC 8824 (cf. 4.5).";
} }
Figure 5: Definition of identityref for Field Length Figure 5: Definition of identityref for Field Length
As for field ID, field length function can be defined as an Field ID, field length function can be defined as an identityref as
identityref as shown in Figure 5. 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 6). Figure 6).
typedef fl-type { typedef fl-type {
type union { type union {
type int64; /* positive length in bits */ type int64; /* positive length in bits */
type identityref { /* function */ type identityref { /* function */
base fl-base-type; base fl-base-type;
skipping to change at page 8, line 9 skipping to change at page 8, line 9
} }
description description
"Field length either a positive integer giving the size in bits "Field length either a positive integer giving the size in bits
or a function defined through an identityref."; or a function defined through an identityref.";
} }
Figure 6: Type definition for field Length Figure 6: Type definition for field Length
2.5. 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, and incremented at each repetition.
times, the value is higher. value 0 indicates that the position is value 0 indicates that the position is not important and is not
not important and is not considered during the rule selection 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.6. 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 di-base-type { identity di-base-type {
description description
"Used to extend field length functions"; "Used to extend direction indicators.";
} }
identity di-bidirectional { identity di-bidirectional {
base di-base-type; base di-base-type;
description description
"Direction Indication of bi directionality in "Direction Indication of bi directionality in
RFC 8724 (cf. 7.1)"; RFC 8724 (cf. 7.1).";
} }
identity di-up { identity di-up {
base di-base-type; base di-base-type;
description description
"Direction Indication of upstream defined in "Direction Indication of upstream defined in
RFC 8724 (cf. 7.1)"; RFC 8724 (cf. 7.1).";
} }
identity di-down { identity di-down {
base di-base-type; base di-base-type;
description description
"Direction Indication of downstream defined in "Direction Indication of downstream defined in
RFC 8724 (cf. 7.1)"; RFC 8724 (cf. 7.1).";
} }
Figure 7: Definition of identityref for direction indicators Figure 7: Definition of identityref for direction indicators
Figure 7 gives the identityref for Direction Indicators. The naming Figure 7 gives the identityref for Direction Indicators. The naming
convention is "di" followed by the Direction Indicator name. convention is "di" followed by the Direction Indicator name.
The type is "direction-indicator-type" (cf. Figure 8). The type is "di-type" (cf. Figure 8).
typedef di-type { typedef di-type {
type identityref { type identityref {
base di-base-type; base di-base-type;
} }
description description
"Direction in LPWAN network, up when emitted by the device, "Direction in LPWAN network, up when emitted by the device,
down when received by the device, bi when emitted or received by the device."; down when received by the device, bi when emitted or
} received by the device.";
}
Figure 8: Type definition for direction indicators Figure 8: Type definition for direction indicators
2.7. Target Value 2.7. Target Value
The Target Value is a list of binary sequences of any length, aligned The Target Value is a list of binary sequences of any length, aligned
on the left. Figure 9 gives the definition of a single element of a on the left. Figure 9 gives the definition of a single element of a
Target Value. In the rule, this will be used as a list, with 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 position as a key. The highest position value is used to compute the
size of the index sent in residue for LSB CDA. The position allows size of the index sent in residue for LSB CDA. The position allows
to specify several values: to specify several values:
* For Equal and LSB, a single value is used, such as for the equal * For Equal and LSB, a single value is used, such as for the equal
or LSB CDA, the position is set to 0. or LSB CDA, the position is set to 0.
* For match-mapping, several of these values can be contained in a * For match-mapping, several of these values can be contained in a
Target Value field. In the data model, this is generalized by Target Value field. Position values must start from 0 and be
adding a position, which orders the list of values. Position contiguous.
values must start from 0 and be contiguous.
grouping tv-struct {
description
"Define the target value element. Always a binary type, strings
must be converted to binary. field-id allows the conversion to the appropriate
type.";
leaf value {
type binary;
}
leaf position {
type uint16;
description
"If only one element position is 0, otherwise position is the
matching list.";
}
}
Figure 9: Definition of target value grouping tv-struct {
description
"Define the target value element. Always a binary type, strings
must be converted to binary. field-id allows the conversion
to the appropriate type.";
leaf value {
type binary;
description
"Target Value";
}
leaf position {
type uint16;
description
"If only one element position is 0, otherwise position is the
the position in the matching list.";
}
}
Figure 9: Definition of target value
2.8. 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 as listed in Figure 10. defines 4 MO as listed in Figure 10.
identity mo-base-type { identity mo-base-type {
description description
"Used to extend Matching Operators with SID values"; "Used to extend Matching Operators with SID values";
skipping to change at page 10, line 34 skipping to change at page 10, line 35
description description
"Ignore MO as defined RFC 8724 (cf. 7.3)"; "Ignore MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-msb { identity mo-msb {
base mo-base-type; base mo-base-type;
description description
"MSB MO as defined RFC 8724 (cf. 7.3)"; "MSB MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-matching { identity mo-match-mapping {
base mo-base-type; base mo-base-type;
description description
"match-mapping MO as defined RFC 8724 (cf. 7.3)"; "match-mapping MO as defined RFC 8724 (cf. 7.3)";
} }
Figure 10: Definition of identityref for Matching Operator Figure 10: Definition of identityref for Matching Operator
The naming convention is "mo" followed by the MO name. The naming convention is "mo" followed by the MO name.
The type is "matching-operator-type" (cf. Figure 11) The type is "mo-type" (cf. Figure 11)
typedef mo-type {
type identityref {
base mo-base-type;
}
description
"Matching Operator (MO) to compare fields values with
target values";
}
typedef mo-type { Figure 11: Type definition for Matching Operator
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.8.1. Matching Operator arguments 2.8.1. Matching Operator arguments
Some Matching Operator such as MSB can take some values. Even if They are viewed as a list of tv-struct.
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
target-values-type.
2.9. 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.
Figure 13 gives some CDA definition, the full definition is in Figure 13 gives some CDA definition, the full definition is in
Section 7. Section 7.
identity cda-base-type { identity cda-base-type {
description description
"Compression Decompression Actions"; "Compression Decompression Actions.";
} }
identity cda-not-sent { identity cda-not-sent {
base cda-base-type; base cda-base-type;
description description
"not-sent CDA as defines in RFC 8724 (cf. 7.4)"; "not-sent CDA as defines in RFC 8724 (cf. 7.4).";
} }
identity cda-value-sent { identity cda-value-sent {
base cda-base-type; base cda-base-type;
description description
"value-sent CDA as defines in RFC 8724 (cf. 7.4)"; "value-sent CDA as defines in RFC 8724 (cf. 7.4).";
} }
identity cda-lsb { identity cda-lsb {
base cda-base-type; base cda-base-type;
description description
"LSB CDA as defines in RFC 8724 (cf. 7.4)"; "LSB CDA as defines in RFC 8724 (cf. 7.4).";
} }
identity cda-mapping-sent { identity cda-mapping-sent {
base cda-base-type; base cda-base-type;
description description
"mapping-sent CDA as defines in RFC 8724 (cf. 7.4)"; "mapping-sent CDA as defines in RFC 8724 (cf. 7.4).";
} }
.... ....
Figure 12: Definition of identityref for Compresion Decompression Figure 12: Definition of identityref for Compresion Decompression
Action Action
The naming convention is "cda" followed by the CDA name. The naming convention is "cda" followed by the CDA name.
typedef cda-type { typedef cda-type {
type identityref { type identityref {
base cda-base-type; base cda-base-type;
} }
description description
"Compression Decompression Action to compression or decompress a field."; "Compression Decompression Action to compression or
} decompress a field.";
}
Figure 13: Type definition for Compresion Decompression Action Figure 13: Type definition for Compresion Decompression Action
2.9.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.
2.10. Fragmentation rule 2.10. Fragmentation rule
Fragmentation is optional in the data model and depends on the Fragmentation is optional in the data model and depends on the
skipping to change at page 13, line 5 skipping to change at page 14, line 5
back. back.
* Ack Always: each fragmentation window must be explicitly * Ack Always: each fragmentation window must be explicitly
acknowledged before going to the next. acknowledged before going to the next.
* Ack on Error: A window is acknowledged only when the receiver * Ack on Error: A window is acknowledged only when the receiver
detects some missing fragments. detects some missing fragments.
Figure 14 give the definition for identifiers from these three modes. Figure 14 give the definition for identifiers from these three modes.
identity fragmentation-mode-base-type { identity fragmentation-mode-base-type {
description description
"Fragmentation mode"; "fragmentation mode.";
} }
identity fragmentation-mode-no-ack { identity fragmentation-mode-no-ack {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
description description
"No Ack of RFC 8724."; "No Ack of RFC 8724.";
} }
identity fragmentation-mode-ack-always { identity fragmentation-mode-ack-always {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
skipping to change at page 14, line 19 skipping to change at page 15, line 19
* a Fragment Compressed Number (FCN) indicating the fragment/tile * a Fragment Compressed Number (FCN) indicating the fragment/tile
position on the window. This field is mandatory on all modes position on the window. This field is mandatory on all modes
defined in [RFC8724], its size is defined by the rule. defined in [RFC8724], its size is defined by the rule.
|-- SCHC Fragment Header ----| |-- SCHC Fragment Header ----|
|-- T --|-M-|-- N --| |-- T --|-M-|-- N --|
+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W | FCN | Fragment Payload | padding (as needed) | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed)
+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
Figure 15: Data fragment header from RFC8724 Figure 15: Data fragment header from RFC8724
2.10.3. Last fragment format 2.10.3. Last fragment format
The last fragment of a datagram is sent with an RCS (Reassembly Check The last fragment of a datagram is sent with an RCS (Reassembly Check
Sequence) field to detect residual transmission error and possible Sequence) field to detect residual transmission error and possible
losses in the last window. [RFC8724] defines a single algorithm losses in the last window. [RFC8724] defines a single algorithm
based on Ethernet CRC computation. The identity of the RCS algorithm based on Ethernet CRC computation. The identity of the RCS algorithm
is shown in Figure 16. is shown in Figure 16.
// -- RCS algorithm types // -- RCS algorithm types
identity rcs-algorithm-base-type { identity rcs-algorithm-base-type {
description description
"Identify which algorithm is used to compute RSC. "Identify which algorithm is used to compute RSC.
The algorithm defines also the size if the RSC field."; The algorithm also defines the size if the RSC field.";
} }
identity rcs-RFC8724 { identity rcs-RFC8724 {
base rcs-algorithm-base-type; base rcs-algorithm-base-type;
description description
"CRC 32 defined as default RCS in RFC8724."; "CRC 32 defined as default RCS in RFC8724.";
} }
typedef rcs-algorithm-type { typedef rcs-algorithm-type {
type identityref { type identityref {
base rcs-algorithm-base-type; base rcs-algorithm-base-type;
} }
description description
"type used in rules"; "type used in rules.";
} }
Figure 16: type definition for RCS Figure 16: type definition for RCS
The naming convention is "rcs" followed by the algorithm name. The naming convention is "rcs" followed by the algorithm name.
For Ack-on-Error mode, the All-1 fragment may just contain the RCS or For Ack-on-Error mode, the All-1 fragment may just contain the RCS or
can include a tile. The parameters defined in Figure 17 allows to can include a tile. The parameters defined in Figure 17 allows to
define the behavior: define the behavior:
skipping to change at page 15, line 23 skipping to change at page 16, line 23
* all1-data-yes: the last fragment includes a single tile and the * all1-data-yes: the last fragment includes a single tile and the
RCS RCS
* all1-data-sender-choice: the last fragment may or may not contain * all1-data-sender-choice: the last fragment may or may not contain
a single tile. The receiver can detect if a tile is present. a single tile. The receiver can detect if a tile is present.
// -- All1 with data types // -- All1 with data types
identity all1-data-base-type { identity all1-data-base-type {
description description
"Type to define when to send an Acknowledgment message"; "Type to define when to send an Acknowledgment message.";
} }
identity all1-data-no { identity all1-data-no {
base all1-data-base-type; base all1-data-base-type;
description description
"All1 contains no tiles."; "All1 contains no tiles.";
} }
identity all1-data-yes { identity all1-data-yes {
base all1-data-base-type; base all1-data-base-type;
description description
"All1 MUST contain a tile"; "All1 MUST contain a tile.";
} }
identity all1-data-sender-choice { identity all1-data-sender-choice {
base all1-data-base-type; base all1-data-base-type;
description description
"Fragmentation process choose to send tiles or not in all1."; "Fragmentation process choose to send tiles or not in all1.";
} }
typedef all1-data-type { typedef all1-data-type {
type identityref { type identityref {
base all1-data-base-type; base all1-data-base-type;
} }
description description
"Type used in rules"; "Type used in rules.";
} }
Figure 17: type definition for RCS Figure 17: type definition for RCS
The naming convention is "all1-data" followed by the behavior The naming convention is "all1-data" followed by the behavior
identifier. identifier.
2.10.4. Acknowledgment behavior 2.10.4. Acknowledgment behavior
A cknowledgment fragment header goes in the opposite direction of A cknowledgment fragment header goes in the opposite direction of
skipping to change at page 16, line 34 skipping to change at page 17, line 34
|--- SCHC ACK Header ----| |--- SCHC ACK Header ----|
|-- T --|-M-| 1 | |-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W |C=1| padding as needed (success) | RuleID | DTag | W |C=1| padding as needed (success)
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
| RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
Figure 18: Acknowledgment fragment header for RFC8724 Figure 18: Acknowledgment fragment header for RFC8724
For Ack-on-Error, SCHC defined when acknowledgment can be sent. This 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 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 (FCN All-0) or at the end of the fragment (FCN All-1). The following
identifiers (cf. Figure 19) define the acknowledgment behavior. identifiers (cf. Figure 19) define the acknowledgment behavior.
// -- Ack behavior // -- Ack behavior
identity ack-behavior-base-type { identity ack-behavior-base-type {
description description
"Define when to send an Acknowledgment message"; "Define when to send an Acknowledgment .";
} }
identity ack-behavior-after-All0 { identity ack-behavior-after-All0 {
base ack-behavior-base-type; base ack-behavior-base-type;
description description
"Fragmentation expects Ack after sending All0 fragment."; "Fragmentation expects Ack after sending All0 fragment.";
} }
identity ack-behavior-after-All1 { identity ack-behavior-after-All1 {
base ack-behavior-base-type; base ack-behavior-base-type;
skipping to change at page 17, line 35 skipping to change at page 18, line 35
base ack-behavior-base-type; base ack-behavior-base-type;
description description
"Fragmentation expects Ack after sending every fragment."; "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 description
"Type used in rules"; "Type used in rules.";
} }
Figure 19: bitmap generation behavior Figure 19: bitmap generation behavior
The naming convention is "ack-behavior" followed by the algorithm The naming convention is "ack-behavior" followed by the algorithm
name. 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 20: bitmap generation behavior
The naming convention is "bitmap" followed by the algorithm name.
2.10.5. Fragmentation Parameters 2.10.5. Fragmentation Parameters
The state machine requires some common values to handle The state machine requires some common values to handle
fragmentation: fragmentation:
* retransmission-timer gives in seconds the duration before sending * retransmission-timer gives in seconds the duration before sending
an ack request (cf. section 8.2.2.4. of [RFC8724]). If specified, 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.
* inactivity-timer gives in seconds the duration before aborting * inactivity-timer gives in seconds the duration before aborting
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Three types of rules are defined in [RFC8724]: Three types of rules are defined in [RFC8724]:
* Compression: a compression rule is associated to the rule ID. * Compression: a compression rule is associated to the rule ID.
* No compression: nothing is associated to the rule ID. * No compression: nothing is associated to the rule ID.
* Fragmentation: fragmentation parameters are associated to the rule * Fragmentation: fragmentation parameters are associated to the rule
ID. Fragmentation is optional and feature "fragmentation" should ID. Fragmentation is optional and feature "fragmentation" should
be set. be set.
grouping rule-id-type { grouping rule-id-type {
leaf rule-id-value { leaf rule-id-value {
type uint32; type uint32;
description description
"Rule ID value, this value must be unique combined with the length"; "Rule ID value, this value must be unique combined with
} the length.";
leaf rule-id-length { }
type uint8 { leaf rule-id-length {
range "0..32"; type uint8 {
} range "0..32";
description }
"Rule ID length in bits, value 0 is for implicit rules"; 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"; 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 { container schc {
list rule { list rule {
key "rule-id-value rule-id-length"; key "rule-id-value rule-id-length";
uses rule-id-type; uses rule-id-type;
choice nature { choice nature {
case fragmentation { case fragmentation {
if-feature "fragmentation"; //if-feature "fragmentation";
uses fragmentation-content; uses fragmentation-content;
} }
case compression { case compression {
uses compression-content; uses compression-content;
} }
case no-compression { case no-compression {
description description
"RFC8724 allows a rule for uncompressed headers"; "RFC8724 allows a rule for uncompressed headers.";
} }
description description
"A rule is either for compression, no compression or fragmentation"; "A rule is either for compression, no compression or
} fragmentation.";
description }
"Set of rules compression, no compression or fragmentation rules description
identified by their rule-id "; "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 description
compression or fragmentation"; "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
}
Figure 20: Definition of a SCHC Context
To access to a specific rule, rule-id and its specific length is used To access to a specific rule, rule-id and its specific length is used
as a key. The rule is either a compression or a fragmentation rule. as a key. The rule is either a compression or a fragmentation rule.
Each context can be identified though a version id. Each context can be identified though a version id.
3.1. Compression rule 3.1. Compression rule
A compression rule is composed of entries describing its processing A compression rule is composed of entries describing its processing
(cf. Figure 22). An entry contains all the information defined in (cf. Figure 21). An entry contains all the information defined in
Figure 1 with the types defined above. Figure 1 with the types defined above.
The compression rule described Figure 1 is defined by compression- The compression rule described Figure 1 is defined by compression-
content. It defines a list of compression-rule-entry, indexed by content. It defines a list of compression-rule-entry, indexed by
their field id, position and direction. The compression-rule-entry their field id, position and direction. The compression-rule-entry
element represent a line of the table Figure 1. Their type reflects element represent a line of the table Figure 1. Their type reflects
the identifier types defined in Section 2.1 the identifier types defined in Section 2.1
Some controls are made on the values: Some controls are made on the values:
* target value must be present for MO different from ignore. * target value must be present for MO different from ignore.
* when MSB MO is specified, the matching-operator-value must be * when MSB MO is specified, the matching-operator-value must be
present present
grouping compression-rule-entry { grouping compression-rule-entry {
description description
"These entries defines a compression entry (i.e. a line) "These entries defines a compression entry (i.e. a line)
as defined in RFC 8724 and fragmentation parameters. as defined in RFC 8724 and fragmentation parameters.
+-------+--+--+--+------------+-----------------+---------------+ +-------+--+--+--+------------+-----------------+---------------+
|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
+-------+--+--+--+------------+-----------------+---------------+ +-------+--+--+--+------------+-----------------+---------------+
An entry in a compression rule is composed of 7 elements: 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 ID: The header field to be compressed. The content is a
- Field Length : either a positive integer of a function defined as a YANF id. YANG identifer.
- Field Position: a positive (and possibly equal to 0) integer. - Field Length : either a positive integer of a function
- Direction Indicator: a YANG identifier giving the direction. defined as a YANF id.
- Target value: a value against which the header Field is compared. - Field Position: a positive (and possibly equal to 0) integer.
- Matching Operator: a YANG id giving the operation, paramters may be - Direction Indicator: a YANG identifier giving the direction.
associated to that operator. - Target value: a value against which the header Field is
- Comp./Decomp. Action: A YANG id giving the compression or decompression compared.
action, paramters may be associated to that action. - Matching Operator: a YANG id giving the operation, paramters
"; may be associated to that operator.
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";
}
}
grouping compression-content { - Comp./Decomp. Action: A YANG id giving the compression or
list entry { decompression action, paramters may be associated to that
key "field-id field-position direction-indicator"; action.
uses compression-rule-entry; ";
description leaf field-id {
"A compression rule is a list of rule entry describing type schc:fid-type;
each header field. An entry is identifed through a field-id, its position mandatory true;
in the packet and its direction"; description
} "Field ID, identify a field in the header with a YANG
description referenceid.";
"Define a compression rule composed of a list of entries."; }
} 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 need target-value";
Figure 22: Definition of a compression entry 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.";
}
}
grouping compression-content {
list entry {
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.";
}
Figure 21: Definition of a compression entry
3.2. Fragmentation rule 3.2. Fragmentation rule
A Fragmentation rule is composed of entries describing the protocol A Fragmentation rule is composed of entries describing the protocol
behavior. Some on them are numerical entries, others are identifiers behavior. Some on them are numerical entries, others are identifiers
defined in Section 2.10. defined in Section 2.10.
The data model defines some relations between the entries: The data model defines some relations between the entries:
* direction must be either up or down (not bidirectional). * direction must be either up or down (not bidirectional).
* W size is only needed for Ack Always and Ack on Error modes. * W size is only needed for Ack Always and Ack on Error modes.
grouping fragmentation-content { grouping fragmentation-content {
description description
"This grouping defines the fragmentation parameters for "This grouping defines the fragmentation parameters for
all the modes (No Ack, Ack Always and Ack on Error) specified in all the modes (No Ack, Ack Always and Ack on Error) specified in
RFC 8724."; RFC 8724.";
leaf l2-word-size { leaf l2-word-size {
type uint8; type uint8;
default "8"; default "8";
description description
"Size in bit of the layer 2 word"; "Size in bit of the layer 2 word";
} }
leaf direction { leaf direction {
must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" { type schc:di-type;
error-message "direction for fragmentation rules is up or down"; must "derived-from-or-self(., 'di-up') or
} derived-from-or-self(., 'di-down')" {
type schc:direction-indicator-type; error-message
mandatory true; "direction for fragmentation rules are up or down.";
description }
"Should be up or down, bi directionnal is forbiden."; mandatory true;
} description
leaf dtag-size { "Should be up or down, bi directionnal is forbiden.";
type uint8; }
default "0"; leaf dtag-size {
description type uint8;
"Size in bit of the DTag field"; default "0";
} description
leaf w-size { "Size in bit of the DTag field (T variable from RFC8724).";
when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))"; }
type uint8; leaf w-size {
description when "not(derived-from(../fragmentation-mode,
"Size in bit of the window field"; 'fragmentation-mode-no-ack'))";
} type uint8;
leaf fcn-size { description
type uint8; "Size in bit of the window field (M variable from RFC8724).";
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";
} }
leaf retransmission-timer { leaf fcn-size {
type uint64 { type uint8;
range "1..max"; mandatory true;
} description
description "Size in bit of the FCN field (M variable from RFC8724).";
"Duration in seconds of the retransmission timer"; // Check the units }
} leaf rcs-algorithm {
leaf inactivity-timer { type rcs-algorithm-type;
type uint64; default "schc:rcs-RFC8724";
description description
"Duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units "Algoritm used for RCS";
} }
leaf max-ack-requests { leaf maximum-window-size {
type uint8 { type uint16;
range "1..max"; description
} "By default 2^wsize - 1";
description }
"The maximum number of retries for a specific SCHC ACK."; leaf retransmission-timer {
} type uint64 {
leaf maximum-packet-size { range "1..max";
type uint16; }
default "1280"; description
description "Duration in seconds of the retransmission timer.";
"When decompression is done, packet size must not strictly exceed this limit in Bytes"; }
} leaf inactivity-timer {
leaf fragmentation-mode { type uint64;
type schc:fragmentation-mode-type; description
mandatory true; "Duration is seconds of the inactivity timer,
description 0 indicates the timer is disabled.";
"Which fragmentation mode is used (noAck, AckAlways, AckonError)"; }
} leaf max-ack-requests {
choice mode { type uint8 {
case no-ack; range "1..max";
case ack-always; }
case ack-on-error { description
leaf tile-size { "The maximum number of retries for a specific SCHC ACK.";
type uint8; }
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; leaf maximum-packet-size {
description type uint16;
"Size in bit of tiles, if not specified or set to 0: tile fills the fragment."; default "1280";
} description
leaf tile-in-All1 { "When decompression is done, packet size must not
type schc:all1-data-type; strictly exceed this limit in Bytes.";
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; }
description leaf fragmentation-mode {
"When true, sender and receiver except a tile in All-1 frag"; type schc:fragmentation-mode-type;
} mandatory true;
leaf ack-behavior { description
type schc:ack-behavior-type; "which fragmentation mode is used (noAck, AckAlways,
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; AckonError)";
description }
"Sender behavior to acknowledge, after All-0, All-1 or when the choice mode {
LPWAN allows it (Always)"; case no-ack;
} case ack-always;
leaf bitmap-format { case ack-on-error {
type schc:bitmap-format-type; leaf tile-size {
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; when "derived-from(../fragmentation-mode,
default "schc:bitmap-RFC8724"; 'fragmentation-mode-ack-on-error')";
description type uint8;
"How the bitmaps are included in the Ack message."; description
} "Size in bit of tiles, if not specified or set to 0,
} tile fills the fragment.";
description }
"RFC 8724 defines 3 fragmentation modes"; leaf tile-in-All1 {
} when "derived-from(../fragmentation-mode,
} 'fragmentation-mode-ack-on-error')";
type schc:all1-data-type;
description
"When true, sender and receiver except a tile in
All-1 frag.";
}
leaf ack-behavior {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')";
type schc:ack-behavior-type;
description
"Sender behavior to acknowledge, after All-0, All-1 or
when the LPWAN allows it (Always).";
}
}
description
"RFC 8724 defines 3 fragmentation modes.";
}
}
3.3. YANG Tree 3.3. YANG Tree
module: ietf-schc module: ietf-schc
+--rw schc +--rw schc
+--rw rule* [rule-id-value rule-id-length] +--rw rule* [rule-id-value rule-id-length]
+--rw rule-id-value uint32 +--rw rule-id-value uint32
+--rw rule-id-length uint8 +--rw rule-id-length uint8
+--rw (nature)? +--rw (nature)?
+--:(fragmentation) {fragmentation}? +--:(fragmentation)
| +--rw l2-word-size? uint8 | +--rw l2-word-size? uint8
| +--rw direction schc:di-type | +--rw direction schc:di-type
| +--rw dtag-size? uint8 | +--rw dtag-size? uint8
| +--rw w-size? uint8 | +--rw w-size? uint8
| +--rw fcn-size uint8 | +--rw fcn-size uint8
| +--rw rcs-algorithm? rcs-algorithm-type | +--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:fid-type | +--rw field-id schc:fid-type
| +--rw field-length schc:fl-type | +--rw field-length schc:fl-type
| +--rw field-position uint8 | +--rw field-position uint8
| +--rw direction-indicator schc:di-type | +--rw direction-indicator schc:di-type
| +--rw target-value* [position] | +--rw target-value* [position]
| | +--rw value? binary | | +--rw value? binary
| | +--rw position uint16 | | +--rw position uint16
| +--rw matching-operator schc:mo-type | +--rw matching-operator schc:mo-type
| +--rw matching-operator-value* [position] | +--rw matching-operator-value* [position]
| | +--rw value? binary | | +--rw value? binary
| | +--rw position uint16 | | +--rw position uint16
| +--rw comp-decomp-action schc:cda-type | +--rw comp-decomp-action schc:cda-type
| +--rw comp-decomp-action-value* [position] | +--rw comp-decomp-action-value* [position]
| +--rw value? binary | +--rw value? binary
| +--rw position uint16 | +--rw position uint16
+--:(no-compression) +--:(no-compression)
Figure 23 Figure 22
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 ietf-schc@2021-08-17.yang <code begins> file ietf-schc@2021-11-10.yang
module ietf-schc { module ietf-schc {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; namespace "urn:ietf:params:xml:ns:yang:ietf-schc";
prefix schc; prefix schc;
organization organization
"IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/lpwan/about/> "WG Web: <https://datatracker.ietf.org/wg/lpwan/about/>
WG List: <mailto:p-wan@ietf.org> WG List: <mailto:p-wan@ietf.org>
skipping to change at page 29, line 9 skipping to change at page 29, line 9
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices. for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
************************************************************************* *****************************************************************
Generic Data model for Static Context Header Compression Rule for SCHC, Generic Data model for Static Context Header Compression Rule for
based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression SCHC, based on RFC 8724 and RFC8824. Include compression, no
rules and fragmentation rules. compression and fragmentation rules.
This module is a YANG model for SCHC rules (RFc 8724). This module is a YANG model for SCHC rules (RFc 8724).
RFC 8724 describes a rule in a abstract way through a table. RFC 8724 describes a rule in a abstract way through a table.
|-----------------------------------------------------------------| |-----------------------------------------------------------------|
| (FID) Rule 1 | | (FID) Rule 1 |
|+-------+--+--+--+------------+-----------------+---------------+| |+-------+--+--+--+------------+-----------------+---------------+|
||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| ||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 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
|+-------+--+--+--+------------+-----------------+---------------+| |+-------+--+--+--+------------+-----------------+---------------+|
||... |..|..|..| ... | ... | ... || ||... |..|..|..| ... | ... | ... ||
|+-------+--+--+--+------------+-----------------+---------------+| |+-------+--+--+--+------------+-----------------+---------------+|
||Field N|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 This module proposes a global data model that can be used for rule
exchanges or modification. It proposes both the data model format and exchanges or modification. It proposes both the data model format
the global identifiers used to describes some operations in fields. and the global identifiers used to describes some operations in
fields.
This data model applies both to compression and fragmentation."; This data model applies both to compression and fragmentation.";
revision 2021-08-17 { revision 2021-11-10 {
description description
"Initial version from RFC XXXX "; "Initial version from RFC XXXX ";
reference reference
"RFC XXX: Data Model for Static Context Header Compression (SCHC)"; "RFC XXX: Data Model for Static Context Header Compression
(SCHC)";
} }
feature fragmentation { feature fragmentation {
description description
"Fragmentation is usually required only at the transportation level."; "Fragmentation is usually required only at the transportation
level.";
} }
// ------------------------- // -------------------------
// Field ID type definition // Field ID type definition
//-------------------------- //--------------------------
// generic value TV definition // generic value TV definition
identity fid-base-type { identity fid-base-type {
description description
"Field ID base type for all fields"; "Field ID base type for all fields";
} }
identity fid-ipv6-base-type { identity fid-ipv6-base-type {
base fid-base-type; base fid-base-type;
description description
"Field IP base type for IPv6 headers described in RFC 8200"; "Field IP base type for IPv6 headers described in RFC 8200";
} }
skipping to change at page 31, line 4 skipping to change at page 31, line 8
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"IPv6 Flow Label field from RFC8200"; "IPv6 Flow Label field from RFC8200";
} }
identity fid-ipv6-payloadlength { identity fid-ipv6-payloadlength {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"IPv6 Payload Length field from RFC8200"; "IPv6 Payload Length field from RFC8200";
} }
identity fid-ipv6-nextheader { identity fid-ipv6-nextheader {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"IPv6 Next Header field from RFC8200"; "IPv6 Next Header field from RFC8200";
} }
identity fid-ipv6-hoplimit { identity fid-ipv6-hoplimit {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"IPv6 Next Header field from RFC8200"; "IPv6 Next Header field from RFC8200";
} }
identity fid-ipv6-devprefix { identity fid-ipv6-devprefix {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"correspond either to the source address or the desdination "correspond either to the source address or the desdination
address prefix of RFC 8200. Depending if it is respectively address prefix of RFC 8200. Depending if it is
a uplink or an downklink message."; respectively a uplink or an downklink message.";
} }
identity fid-ipv6-deviid { identity fid-ipv6-deviid {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"correspond either to the source address or the desdination "correspond either to the source address or the desdination
address prefix of RFC 8200. Depending if it is respectively address prefix of RFC 8200. Depending if it is respectively
a uplink or an downklink message."; a uplink or an downklink message.";
} }
identity fid-ipv6-appprefix { identity fid-ipv6-appprefix {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"correspond either to the source address or the desdination "correspond either to the source address or the desdination
address prefix of RFC 768. Depending if it is respectively address prefix of RFC 768. Depending if it is respectively
a downlink or an uplink message."; a downlink or an uplink message.";
} }
identity fid-ipv6-appiid { identity fid-ipv6-appiid {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"correspond either to the source address or the desdination "correspond either to the source address or the desdination
address prefix of RFC 768. Depending if it is respectively address prefix of RFC 768. Depending if it is respectively
a downlink or an uplink message."; a downlink or an uplink message.";
} }
identity fid-udp-base-type { identity fid-udp-base-type {
base fid-base-type; base fid-base-type;
description description
"Field IP base type for UDP headers described in RFC 768"; "Field IP base type for UDP headers described in RFC 768";
} }
identity fid-udp-dev-port { identity fid-udp-dev-port {
base fid-udp-base-type; base fid-udp-base-type;
description description
"UDP length from RFC 768"; "UDP length from RFC 768";
} }
identity fid-udp-app-port { identity fid-udp-app-port {
base fid-udp-base-type; base fid-udp-base-type;
skipping to change at page 36, line 37 skipping to change at page 36, line 40
description description
"CoAP option oscore flags (see draft schc coap, section 6.4)"; "CoAP option oscore flags (see draft schc coap, section 6.4)";
} }
identity fid-coap-option-oscore-kidctx { identity fid-coap-option-oscore-kidctx {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option oscore flags (see draft schc coap, section 6.4)"; "CoAP option oscore flags (see draft schc coap, section 6.4)";
} }
identity fid-icmpv6-base-type {
base fid-base-type;
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-code {
base fid-icmpv6-base-type;
description
"ICMPv6 field (see draft OAM)";
}
identity fid-icmpv6-checksum {
base fid-icmpv6-base-type;
description
"ICMPv6 field (see draft OAM)";
}
identity fid-icmpv6-identifier {
base fid-icmpv6-base-type;
description
"ICMPv6 field (see draft OAM)";
}
identity fid-icmpv6-sequence {
base fid-icmpv6-base-type;
description
"ICMPv6 field (see draft OAM)";
}
//---------------------------------- //----------------------------------
// Field Length type definition // Field Length type definition
//---------------------------------- //----------------------------------
identity fl-base-type { identity fl-base-type {
description description
"Used to extend field length functions"; "Used to extend field length functions.";
} }
identity fl-variable { identity fl-variable {
base fl-base-type; base fl-base-type;
description description
"Residue length in Byte is sent defined in "Residue length in Byte is sent as defined in
for CoAP in RFC 8824 (cf. 5.3)"; for CoAP in RFC 8824 (cf. 5.3).";
} }
identity fl-token-length { identity fl-token-length {
base fl-base-type; base fl-base-type;
description description
"Residue length in Byte is sent defined in "Residue length in Byte is sent as defined in
for CoAP in RFC 8824 (cf. 4.5)"; for CoAP in RFC 8824 (cf. 4.5).";
} }
//--------------------------------- //---------------------------------
// Direction Indicator type // Direction Indicator type
//--------------------------------- //---------------------------------
identity di-base-type { identity di-base-type {
description description
"Used to extend field length functions"; "Used to extend direction indicators.";
} }
identity di-bidirectional { identity di-bidirectional {
base di-base-type; base di-base-type;
description description
"Direction Indication of bi directionality in "Direction Indication of bi directionality in
RFC 8724 (cf. 7.1)"; RFC 8724 (cf. 7.1).";
} }
identity di-up { identity di-up {
base di-base-type; base di-base-type;
description description
"Direction Indication of upstream defined in "Direction Indication of upstream defined in
RFC 8724 (cf. 7.1)"; RFC 8724 (cf. 7.1).";
} }
identity di-down { identity di-down {
base di-base-type; base di-base-type;
description description
"Direction Indication of downstream defined in "Direction Indication of downstream defined in
RFC 8724 (cf. 7.1)"; RFC 8724 (cf. 7.1).";
} }
//---------------------------------- //----------------------------------
// Matching Operator type definition // Matching Operator type definition
//---------------------------------- //----------------------------------
identity mo-base-type { identity mo-base-type {
description description
"Used to extend Matching Operators with SID values"; "Used to extend Matching Operators with SID values";
} }
skipping to change at page 39, line 8 skipping to change at page 38, line 25
description description
"Ignore MO as defined RFC 8724 (cf. 7.3)"; "Ignore MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-msb { identity mo-msb {
base mo-base-type; base mo-base-type;
description description
"MSB MO as defined RFC 8724 (cf. 7.3)"; "MSB MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-matching { identity mo-match-mapping {
base mo-base-type; base mo-base-type;
description description
"match-mapping MO as defined RFC 8724 (cf. 7.3)"; "match-mapping MO as defined RFC 8724 (cf. 7.3)";
} }
//------------------------------ //------------------------------
// CDA type definition // CDA type definition
//------------------------------ //------------------------------
identity cda-base-type { identity cda-base-type {
description description
"Compression Decompression Actions"; "Compression Decompression Actions.";
} }
identity cda-not-sent { identity cda-not-sent {
base cda-base-type; base cda-base-type;
description description
"not-sent CDA as defines in RFC 8724 (cf. 7.4)"; "not-sent CDA as defines in RFC 8724 (cf. 7.4).";
} }
identity cda-value-sent { identity cda-value-sent {
base cda-base-type; base cda-base-type;
description description
"value-sent CDA as defines in RFC 8724 (cf. 7.4)"; "value-sent CDA as defines in RFC 8724 (cf. 7.4).";
} }
identity cda-lsb { identity cda-lsb {
base cda-base-type; base cda-base-type;
description description
"LSB CDA as defines in RFC 8724 (cf. 7.4)"; "LSB CDA as defines in RFC 8724 (cf. 7.4).";
} }
identity cda-mapping-sent { identity cda-mapping-sent {
base cda-base-type; base cda-base-type;
description description
"mapping-sent CDA as defines in RFC 8724 (cf. 7.4)"; "mapping-sent CDA as defines in RFC 8724 (cf. 7.4).";
} }
identity cda-compute-length { identity cda-compute-length {
base cda-base-type; base cda-base-type;
description description
"compute-length CDA as defines in RFC 8724 (cf. 7.4)"; "compute-length CDA as defines in RFC 8724 (cf. 7.4)";
} }
identity cda-compute-checksum { identity cda-compute-checksum {
base cda-base-type; base cda-base-type;
description description
"compute-checksum CDA as defines in RFC 8724 (cf. 7.4)"; "compute-checksum CDA as defines in RFC 8724 (cf. 7.4)";
} }
identity cda-deviid { identity cda-deviid {
base cda-base-type; base cda-base-type;
description description
"deviid CDA as defines in RFC 8724 (cf. 7.4)"; "deviid CDA as defines in RFC 8724 (cf. 7.4)";
skipping to change at page 40, line 50 skipping to change at page 40, line 20
"Field length either a positive integer giving the size in bits "Field length either a positive integer giving the size in bits
or a function defined through an identityref."; or a function defined through an identityref.";
} }
typedef di-type { typedef di-type {
type identityref { type identityref {
base di-base-type; base di-base-type;
} }
description description
"Direction in LPWAN network, up when emitted by the device, "Direction in LPWAN network, up when emitted by the device,
down when received by the device, bi when emitted or received by the device."; down when received by the device, bi when emitted or
received by the device.";
} }
typedef mo-type { typedef mo-type {
type identityref { type identityref {
base mo-base-type; base mo-base-type;
} }
description description
"Matching Operator (MO) to compare fields values with target values"; "Matching Operator (MO) to compare fields values with
target values";
} }
typedef cda-type { typedef cda-type {
type identityref { type identityref {
base cda-base-type; base cda-base-type;
} }
description description
"Compression Decompression Action to compression or decompress a field."; "Compression Decompression Action to compression or
decompress a field.";
} }
// -- FRAGMENTATION TYPE // -- FRAGMENTATION TYPE
// -- fragmentation modes // -- fragmentation modes
identity fragmentation-mode-base-type { identity fragmentation-mode-base-type {
description description
"fragmentation mode"; "fragmentation mode.";
} }
identity fragmentation-mode-no-ack { identity fragmentation-mode-no-ack {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
description description
"No Ack of RFC 8724."; "No Ack of RFC 8724.";
} }
identity fragmentation-mode-ack-always { identity fragmentation-mode-ack-always {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
skipping to change at page 42, line 4 skipping to change at page 41, line 26
description description
"Ack on Error of RFC8724."; "Ack on Error of RFC8724.";
} }
typedef fragmentation-mode-type { typedef fragmentation-mode-type {
type identityref { type identityref {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
} }
description description
"type used in rules"; "type used in rules";
} }
// -- Ack behavior // -- Ack behavior
identity ack-behavior-base-type { identity ack-behavior-base-type {
description description
"Define when to send an Acknowledgment message"; "Define when to send an Acknowledgment .";
} }
identity ack-behavior-after-All0 { identity ack-behavior-after-All0 {
base ack-behavior-base-type; base ack-behavior-base-type;
description description
"Fragmentation expects Ack after sending All0 fragment."; "Fragmentation expects Ack after sending All0 fragment.";
} }
identity ack-behavior-after-All1 { identity ack-behavior-after-All1 {
base ack-behavior-base-type; base ack-behavior-base-type;
skipping to change at page 42, line 31 skipping to change at page 42, line 4
base ack-behavior-base-type; base ack-behavior-base-type;
description description
"Fragmentation expects Ack after sending All1 fragment."; "Fragmentation expects Ack after sending All1 fragment.";
} }
identity ack-behavior-always { identity ack-behavior-always {
base ack-behavior-base-type; base ack-behavior-base-type;
description description
"Fragmentation expects Ack after sending every fragment."; "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 description
"Type used in rules"; "Type used in rules.";
} }
// -- All1 with data types // -- All1 with data types
identity all1-data-base-type { identity all1-data-base-type {
description description
"Type to define when to send an Acknowledgment message"; "Type to define when to send an Acknowledgment message.";
} }
identity all1-data-no { identity all1-data-no {
base all1-data-base-type; base all1-data-base-type;
description description
"All1 contains no tiles."; "All1 contains no tiles.";
} }
identity all1-data-yes { identity all1-data-yes {
base all1-data-base-type; base all1-data-base-type;
description description
"All1 MUST contain a tile"; "All1 MUST contain a tile.";
} }
identity all1-data-sender-choice { identity all1-data-sender-choice {
base all1-data-base-type; base all1-data-base-type;
description description
"Fragmentation process choose to send tiles or not in all1."; "Fragmentation process choose to send tiles or not in all1.";
} }
typedef all1-data-type { typedef all1-data-type {
type identityref { type identityref {
base all1-data-base-type; base all1-data-base-type;
} }
description description
"Type used in rules"; "Type used in rules.";
} }
// -- RCS algorithm types // -- RCS algorithm types
identity rcs-algorithm-base-type { identity rcs-algorithm-base-type {
description description
"Identify which algorithm is used to compute RSC. "Identify which algorithm is used to compute RSC.
The algorithm also defines the size if the RSC field."; The algorithm also defines the size if the RSC field.";
} }
identity rcs-RFC8724 { identity rcs-RFC8724 {
base rcs-algorithm-base-type; base rcs-algorithm-base-type;
description description
"CRC 32 defined as default RCS in RFC8724."; "CRC 32 defined as default RCS in RFC8724.";
} }
typedef rcs-algorithm-type { typedef rcs-algorithm-type {
type identityref { type identityref {
base rcs-algorithm-base-type; base rcs-algorithm-base-type;
} }
description description
"type used in rules"; "type used in rules.";
}
// --- Bitmap format
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";
} }
// -------- RULE ENTRY DEFINITION ------------ // -------- RULE ENTRY DEFINITION ------------
grouping tv-struct { grouping tv-struct {
description description
"Define the target value element. Always a binary type, strings "Define the target value element. Always a binary type, strings
must be converted to binary. field-id allows the conversion to the appropriate must be converted to binary. field-id allows the conversion
type."; to the appropriate type.";
leaf value { leaf value {
type binary; type binary;
description
"Target Value";
} }
leaf position { leaf position {
type uint16; type uint16;
description description
"If only one element position is 0, otherwise position is the "If only one element position is 0, otherwise position is the
matching list."; the position in the matching list.";
} }
} }
grouping compression-rule-entry { grouping compression-rule-entry {
description description
"These entries defines a compression entry (i.e. a line) "These entries defines a compression entry (i.e. a line)
as defined in RFC 8724 and fragmentation parameters. as defined in RFC 8724 and fragmentation parameters.
+-------+--+--+--+------------+-----------------+---------------+ +-------+--+--+--+------------+-----------------+---------------+
|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
+-------+--+--+--+------------+-----------------+---------------+ +-------+--+--+--+------------+-----------------+---------------+
An entry in a compression rule is composed of 7 elements: 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 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. - Field Position: a positive (and possibly equal to 0) integer.
- Direction Indicator: a YANG identifier giving the direction. - Direction Indicator: a YANG identifier giving the direction.
- Target value: a value against which the header Field is compared. - Target value: a value against which the header Field is
- Matching Operator: a YANG id giving the operation, paramters may be compared.
associated to that operator. - Matching Operator: a YANG id giving the operation, paramters
- Comp./Decomp. Action: A YANG id giving the compression or decompression may be associated to that operator.
action, paramters may be associated to that action. - Comp./Decomp. Action: A YANG id giving the compression or
decompression action, paramters may be associated to that
action.
"; ";
leaf field-id { leaf field-id {
type schc:fid-type; type schc:fid-type;
mandatory true; mandatory true;
description description
"Field ID, identify a field in the header with a YANG refenceid."; "Field ID, identify a field in the header with a YANG
referenceid.";
} }
leaf field-length { leaf field-length {
type schc:fl-type; type schc:fl-type;
mandatory true; mandatory true;
description description
"Field Length in bit or through a function defined as a YANG referenceid"; "Field Length in bit or through a function defined as a
YANG referenceid.";
} }
leaf field-position { leaf field-position {
type uint8; type uint8;
mandatory true; mandatory true;
description description
"Field position in the header is a integer. If the field is not repeated "Field position in the header is a integer. If the field is not
in the header the value is 1, and incremented for each repetition of the field. Position repeated in the header the value is 1, and incremented for each
0 means that the position is not important and order may change when decompressed"; repetition of the field. Position 0 means that the position is
not important and order may change when decompressed";
} }
leaf direction-indicator { leaf direction-indicator {
type schc:di-type; type schc:di-type;
mandatory true; mandatory true;
description description
"Direction Indicator, a YANG referenceid to say if the packet is bidirectional, "Direction Indicator, a YANG referenceid to say if the packet
up or down"; is bidirectional, up or down";
} }
list target-value { list target-value {
key "position"; key "position";
uses tv-struct; uses tv-struct;
description description
"A list of value to compare with the header field value. If target value "A list of value to compare with the header field value.
is a singleton, position must be 0. For matching-list, should be consecutive position If target value is a singleton, position must be 0.
For matching-list, should be consecutive position
values starting from 1."; values starting from 1.";
} }
leaf matching-operator { leaf matching-operator {
type schc:mo-type; type schc:mo-type;
must "../target-value or derived-from-or-self(., 'mo-ignore')" { must "../target-value or derived-from-or-self(., 'mo-ignore')" {
error-message "mo-equal, mo-msb and mo-match-mapping require target-value"; error-message
"mo-equal, mo-msb and mo-match-mapping need target-value";
description description
"target-value is not required for mo-ignore"; "target-value is not required for mo-ignore";
} }
must "not (derived-from-or-self(., 'mo-msb')) or ../matching-operator-value" { must "not (derived-from-or-self(., 'mo-msb')) or
../matching-operator-value" {
error-message "mo-msb requires length value"; error-message "mo-msb requires length value";
} }
mandatory true; mandatory true;
description description
"MO: Matching Operator"; "MO: Matching Operator";
} }
list matching-operator-value { list matching-operator-value {
key "position"; key "position";
uses tv-struct; uses tv-struct;
description description
"Matching Operator Arguments, based on TV structure to allow several arguments. "Matching Operator Arguments, based on TV structure to allow
In RFC 8724, only MSB define a single argument: length in bits "; several arguments.
In RFC 8724, only MSB define a single argument: length in
bits";
} }
leaf comp-decomp-action { leaf comp-decomp-action {
type schc:cda-type; type schc:cda-type;
mandatory true; mandatory true;
description description
"CDA: Compression Decompression Action"; "CDA: Compression Decompression Action.";
} }
list comp-decomp-action-value { list comp-decomp-action-value {
key "position"; key "position";
uses tv-struct; uses tv-struct;
description description
"CDA Arguments, based on TV structure to allow several arguments. "CDA Arguments, based on TV structure to allow several
In RFC 8724, no argument is defined for CDA"; arguments. In RFC 8724, no argument is defined for CDA.";
} }
} }
grouping compression-content { grouping compression-content {
list entry { list entry {
key "field-id field-position direction-indicator"; key "field-id field-position direction-indicator";
uses compression-rule-entry; uses compression-rule-entry;
description description
"A compression rule is a list of rule entry describing "A compression rule is a list of rule entry describing
each header field. An entry is identifed through a field-id, its position each header field. An entry is identifed through a field-id,
in the packet and its direction"; its position in the packet and its direction.";
} }
description description
"Define a compression rule composed of a list of entries."; "Define a compression rule composed of a list of entries.";
} }
grouping fragmentation-content { grouping fragmentation-content {
description description
"This grouping defines the fragmentation parameters for "This grouping defines the fragmentation parameters for
all the modes (No Ack, Ack Always and Ack on Error) specified in all the modes (No Ack, Ack Always and Ack on Error) specified in
RFC 8724."; RFC 8724.";
leaf l2-word-size { leaf l2-word-size {
type uint8; type uint8;
default "8"; default "8";
description description
"Size in bit of the layer 2 word"; "Size in bit of the layer 2 word";
} }
leaf direction { 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; type schc:di-type;
must "derived-from-or-self(., 'di-up') or
derived-from-or-self(., 'di-down')" {
error-message
"direction for fragmentation rules are up or down.";
}
mandatory true; mandatory true;
description description
"Should be up or down, bi directionnal is forbiden."; "Should be up or down, bi directionnal is forbiden.";
} }
leaf dtag-size { leaf dtag-size {
type uint8; type uint8;
default "0"; default "0";
description description
"Size in bit of the DTag field"; "Size in bit of the DTag field (T variable from RFC8724).";
} }
leaf w-size { leaf w-size {
when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))"; when "not(derived-from(../fragmentation-mode,
'fragmentation-mode-no-ack'))";
type uint8; type uint8;
description description
"Size in bit of the window field"; "Size in bit of the window field (M variable from RFC8724).";
} }
leaf fcn-size { leaf fcn-size {
type uint8; type uint8;
mandatory true; mandatory true;
description description
"Size in bit of the FCN field"; "Size in bit of the FCN field (M variable from RFC8724).";
} }
leaf rcs-algorithm { leaf rcs-algorithm {
type rcs-algorithm-type; type rcs-algorithm-type;
default "schc:rcs-RFC8724"; default "schc:rcs-RFC8724";
description description
"Algoritm used for RCS"; "Algoritm used for RCS";
} }
leaf maximum-window-size { leaf maximum-window-size {
type uint16; type uint16;
description description
"By default 2^wsize - 1"; "By default 2^wsize - 1";
} }
leaf retransmission-timer { leaf retransmission-timer {
type uint64 { type uint64 {
range "1..max"; range "1..max";
} }
description description
"Duration in seconds of the retransmission timer"; // Check the units "Duration in seconds of the retransmission timer.";
} }
leaf inactivity-timer { leaf inactivity-timer {
type uint64; type uint64;
description description
"Duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units "Duration is seconds of the inactivity timer,
0 indicates the timer is disabled.";
} }
leaf max-ack-requests { leaf max-ack-requests {
type uint8 { type uint8 {
range "1..max"; range "1..max";
} }
description description
"The maximum number of retries for a specific SCHC ACK."; "The maximum number of retries for a specific SCHC ACK.";
} }
leaf maximum-packet-size { leaf maximum-packet-size {
type uint16; type uint16;
default "1280"; default "1280";
description description
"When decompression is done, packet size must not strictly exceed this limit in Bytes"; "When decompression is done, packet size must not
strictly exceed this limit in Bytes.";
} }
leaf fragmentation-mode { leaf fragmentation-mode {
type schc:fragmentation-mode-type; type schc:fragmentation-mode-type;
mandatory true; mandatory true;
description description
"which fragmentation mode is used (noAck, AckAlways, AckonError)"; "which fragmentation mode is used (noAck, AckAlways,
AckonError)";
} }
choice mode { choice mode {
case no-ack; case no-ack;
case ack-always; case ack-always;
case ack-on-error { case ack-on-error {
leaf tile-size { leaf tile-size {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')";
type uint8; type uint8;
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
description description
"Size in bit of tiles, if not specified or set to 0: tile fills the fragment."; "Size in bit of tiles, if not specified or set to 0,
tile fills the fragment.";
} }
leaf tile-in-All1 { leaf tile-in-All1 {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')";
type schc:all1-data-type; type schc:all1-data-type;
when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
description description
"When true, sender and receiver except a tile in All-1 frag"; "When true, sender and receiver except a tile in
All-1 frag.";
} }
leaf ack-behavior { leaf ack-behavior {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')";
type schc:ack-behavior-type; 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 description
"How the bitmaps are included in the Ack message."; "Sender behavior to acknowledge, after All-0, All-1 or
when the LPWAN allows it (Always).";
} }
} }
description description
"RFC 8724 defines 3 fragmentation modes"; "RFC 8724 defines 3 fragmentation modes.";
} }
} }
// 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-value { leaf rule-id-value {
type uint32; type uint32;
description description
"Rule ID value, this value must be unique combined with the length"; "Rule ID value, this value must be unique combined with
the length.";
} }
leaf rule-id-length { leaf rule-id-length {
type uint8 { type uint8 {
range "0..32"; range "0..32";
} }
description description
"Rule ID length in bits, value 0 is for implicit rules"; "Rule ID length in bits, value 0 is for implicit rules.";
} }
description description
"A rule ID is composed of a value and a length in bit"; "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 { container schc {
list rule { list rule {
key "rule-id-value rule-id-length"; key "rule-id-value rule-id-length";
uses rule-id-type; uses rule-id-type;
choice nature { choice nature {
case fragmentation { case fragmentation {
if-feature "fragmentation"; //if-feature "fragmentation";
uses fragmentation-content; uses fragmentation-content;
} }
case compression { case compression {
uses compression-content; uses compression-content;
} }
case no-compression { case no-compression {
description description
"RFC8724 allows a rule for uncompressed headers"; "RFC8724 allows a rule for uncompressed headers.";
} }
description description
"A rule is either for compression, no compression or fragmentation"; "A rule is either for compression, no compression or
fragmentation.";
} }
description description
"Set of rules compression, no compression or fragmentation rules "Set of rules compression, no compression or fragmentation
identified by their rule-id "; rules identified by their rule-id.";
} }
description description
"a SCHC set of rules is composed of a list of rule which are either "a SCHC set of rules is composed of a list of rule which are
compression or fragmentation"; either compression or fragmentation.";
} }
} }
<code ends> <code ends>
Figure 24 Figure 23
8. Normative References 8. Normative References
[I-D.barthel-lpwan-oam-schc]
Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and
J. C. Zuniga, "OAM for LPWAN using Static Context Header
Compression (SCHC)", Work in Progress, Internet-Draft,
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-schc-compound-ack]
Zuniga, J. C., Gomez, C., Aguilar, S., Toutain, L.,
Cespedes, S., and D. Wistuba, "SCHC Compound ACK", Work in
Progress, Internet-Draft, draft-ietf-lpwan-schc-compound-
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
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<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.
Zúñiga, "SCHC: Generic Framework for Static Context Header Zuniga, "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 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824, Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021, DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/info/rfc8824>. <https://www.rfc-editor.org/info/rfc8824>.
 End of changes. 164 change blocks. 
620 lines changed or deleted 545 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/