< draft-ietf-lpwan-schc-yang-data-model-06.txt   draft-ietf-lpwan-schc-yang-data-model-07.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: 28 May 2022 Institut MINES TELECOM; IMT Atlantique Expires: 1 September 2022 Institut MINES TELECOM; IMT Atlantique
24 November 2021 28 February 2022
Data Model for Static Context Header Compression (SCHC) Data Model for Static Context Header Compression (SCHC)
draft-ietf-lpwan-schc-yang-data-model-06 draft-ietf-lpwan-schc-yang-data-model-07
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 28 May 2022. This Internet-Draft will expire on 1 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as extracted from this document must include Revised BSD License text 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 Revised 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3 2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . 10
2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10 2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10
2.8.1. Matching Operator arguments . . . . . . . . . . . . . 11 2.8.1. Matching Operator arguments . . . . . . . . . . . . . 12
2.9. Compression Decompression Actions . . . . . . . . . . . . 11 2.9. Compression Decompression Actions . . . . . . . . . . . . 12
2.9.1. Compression Decompression Action arguments . . . . . 13 2.9.1. Compression Decompression Action arguments . . . . . 13
2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 13 2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 13
2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 13 2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 13
2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 14 2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 14
2.10.3. Last fragment format . . . . . . . . . . . . . . . . 15 2.10.3. Last fragment format . . . . . . . . . . . . . . . . 15
2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 24 3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 23
3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 27
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
5. Security considerations . . . . . . . . . . . . . . . . . . . 28 5. Security considerations . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Normative References . . . . . . . . . . . . . . . . . . . . 49 8. Normative References . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
SCHC is a compression and fragmentation mechanism for constrained
networks defined in [RFC8724]. It is based on a static context
shared by two entities at the boundary of the constrained network.
[RFC8724] provides a non formal representation of the rules used
either for compression/decompression (or C/D) or fragmentation/
reassembly (or F/R). The goal of this document is to formalize the
description of the rules to offer:
* the same definition on both ends, even if the internal
representation is different.
* an update of the other end to set up some specific values (e.g.
IPv6 prefix, Destination address,...)
* ...
This document defines a YANG module to represent both compression and
fragmentation rules, which leads to common representation for values
for all the rules elements.
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 of the constrained network. shared by two entities at the boundary of the constrained network.
[RFC8724] provides a non formal representation of the rules used [RFC8724] provides a non formal representation of the rules 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:
skipping to change at page 3, line 23 skipping to change at page 3, line 42
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] specify fields for IPv6, UDP, CoAP string. [RFC8724] and [RFC8824] specify fields for IPv6, UDP, CoAP
and OSCORE. and OSCORE.
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].
The YANG model allows to select the compression or the fragmentation
using the feature command.
feature compression {
description
"SCHC compression capabilities are taken into account";
}
feature fragmentation {
description
"SCHC fragmentation capabilities are taken into account";
}
Figure 1: Feature for compression and fragmentation.
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.
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| Rule N | | Rule N |
+-----------------------------------------------------------------+| +-----------------------------------------------------------------+|
skipping to change at page 3, line 48 skipping to change at page 4, line 42
|+-------+--+--+--+------------+-----------------+---------------+||| |+-------+--+--+--+------------+-----------------+---------------+|||
||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|||
|+-------+--+--+--+------------+-----------------+---------------+|/ |+-------+--+--+--+------------+-----------------+---------------+|/
| | | |
\-----------------------------------------------------------------/ \-----------------------------------------------------------------/
Figure 1: Compression Decompression Context Figure 2: Compression Decompression Context
2.2. Identifier generation 2.2. Identifier generation
Identifier used in 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 3) 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. RCS is 4 byte-long";
} }
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 2: Principle to define a type based on identityref. Figure 3: 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 rule and apply matched against the rules to find the appropriate rule and apply
compression. [RFC8724] do not state how the field ID value can be compression. [RFC8724] do not state how the field ID value can be
constructed. In examples, identification is done through a string constructed. In examples, identification is done through a string
indexed by the protocol name (e.g. IPv6.version, CoAP.version,...). 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]. [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.
from the fid-base-type. Then an identity for each protocol is A YANG field ID for the protocol always derives from the fid-base-
specified using the naming convention fid-<<protocol name>>-base- type. Then an identity for each protocol is specified using the
type. All possible fields for this protocol MUST derive from the naming convention fid-<<protocol name>>-base-type. All possible
protocol identity. The naming convention is "fid" followed by the fields for this protocol MUST derive from the protocol identity. The
protocol name and the field name. If a field has to be divided into naming convention is "fid" followed by the protocol name and the
sub-fields, the field identity serves as a base. field name. If a field has to be divided into sub-fields, the field
identity serves as a base.
The full field-id definition is found in Section 7. The example The full field-id definition is found in Section 7. The example
Figure 3 gives the first field ID definitions. A type is defined for Figure 4 gives the first field ID definitions. A type is defined for
IPv6 protocol, and each field is based on it. Note that the DiffServ IPv6 protocol, and each field is based on it. Note that the DiffServ
bits derives from the Traffic Class identity. bits derives from the Traffic Class identity.
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 ID base type for IPv6 headers described in RFC 8200";
} }
identity fid-ipv6-version { identity fid-ipv6-version {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"IPv6 version field from RFC8200"; "IPv6 version field from RFC8200";
} }
identity fid-ipv6-trafficclass { identity fid-ipv6-trafficclass {
base fid-ipv6-base-type; base fid-ipv6-base-type;
skipping to change at page 6, line 36 skipping to change at page 6, line 46
} }
identity fid-ipv6-trafficclass-ds { identity fid-ipv6-trafficclass-ds {
base fid-ipv6-trafficclass; base fid-ipv6-trafficclass;
description description
"IPv6 Traffic Class field from RFC8200, "IPv6 Traffic Class field from RFC8200,
DiffServ field from RFC3168"; DiffServ field from RFC3168";
} }
... ...
Figure 3: Definition of identityref for field IDs Figure 4: Definition of identityref for field IDs
The type associated to this identity is fid-type (cf. Figure 4)
The type associated to this identity is fid-type (cf. Figure 5)
typedef fid-type { typedef fid-type {
type identityref { type identityref {
base fid-base-type; base fid-base-type;
} }
description description
"Field ID generic type."; "Field ID generic type.";
} }
Figure 4: Type definition for field IDs Figure 5: Type definition for field IDs
2.4. Field length 2.4. Field length
Field length is either an integer giving the size of a field in bits Field length is either an integer giving the size of a field in bits
or a specific function. [RFC8724] defines the "var" function which or a specific function. [RFC8724] defines the "var" function which
allows variable length fields in byte and [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.
skipping to change at page 7, line 33 skipping to change at page 7, line 42
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 as 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 6: Definition of identityref for Field Length
Field ID, field length function can be defined as an identityref as Field ID, field length function can be defined as an identityref as
shown in Figure 5. shown in Figure 6.
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 7).
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;
} }
} }
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 7: 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, and incremented at each repetition. field, the default value is 1, and incremented at each repetition.
value 0 indicates that the position is not important and is not value 0 indicates that the position is not important and is not
considered during the rule selection process. considered during the rule selection process.
Field position is a positive integer. The type is an uint8. Field position is a positive integer. The type is an uint8.
skipping to change at page 8, line 35 skipping to change at page 9, line 20
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 uplink 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 downlink defined in
RFC 8724 (cf. 7.1)."; RFC 8724 (cf. 7.1).";
} }
Figure 7: Definition of identityref for direction indicators Figure 8: Definition of identityref for direction indicators
Figure 7 gives the identityref for Direction Indicators. The naming Figure 8 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 "di-type" (cf. Figure 8). The type is "di-type" (cf. Figure 9).
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 down when received by the device, bi when emitted or
received by the device."; received by the device.";
} }
Figure 8: Type definition for direction indicators Figure 9: 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 10 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. Position values must start from 0 and be Target Value field. Position values must start from 0 and be
skipping to change at page 10, line 4 skipping to change at page 10, line 38
description description
"Target Value"; "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
the position in the matching list."; the position in the matching list.";
} }
} }
Figure 9: Definition of target value
Figure 10: 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 11.
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";
} }
identity mo-equal { identity mo-equal {
base mo-base-type; base mo-base-type;
description description
"Equal MO as defined RFC 8724 (cf. 7.3)"; "Equal MO as defined RFC 8724 (cf. 7.3)";
skipping to change at page 10, line 41 skipping to change at page 11, line 34
description description
"MSB MO as defined RFC 8724 (cf. 7.3)"; "MSB MO as defined RFC 8724 (cf. 7.3)";
} }
identity mo-match-mapping { 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 11: 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 "mo-type" (cf. Figure 11) The type is "mo-type" (cf. Figure 12)
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 "Matching Operator (MO) to compare fields values with
target values"; target values";
} }
Figure 11: Type definition for Matching Operator Figure 12: Type definition for Matching Operator
2.8.1. Matching Operator arguments 2.8.1. Matching Operator arguments
They are viewed as a list of tv-struct. They are viewed as a list of tv-struct.
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 14 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
skipping to change at page 12, line 33 skipping to change at page 12, line 45
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 13: 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 "Compression Decompression Action to compression or
decompress a field."; decompress a field.";
} }
Figure 13: Type definition for Compresion Decompression Action Figure 14: 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 36 skipping to change at page 13, line 47
* No Ack: this mode is unidirectionnal, no acknowledgment is sent * No Ack: this mode is unidirectionnal, no acknowledgment is sent
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 15 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 RFC8724.";
} }
identity fragmentation-mode-ack-always { identity fragmentation-mode-ack-always {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
description description
"Ack Always of RFC8724."; "ACK-Always of RFC8724.";
} }
identity fragmentation-mode-ack-on-error { identity fragmentation-mode-ack-on-error {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
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";
} }
Figure 14: Definition of fragmentation mode identifer Figure 15: Definition of fragmentation mode identifer
The naming convention is "fragmentation-mode" followed by the The naming convention is "fragmentation-mode" followed by the
fragmentation mode name. fragmentation mode name.
2.10.2. Fragmentation Header 2.10.2. Fragmentation Header
A data fragment header, directly following the rule ID can be sent on A data fragment header, directly following the rule ID can be sent on
the fragmentation direction. The direction is mandatory and must be the fragmentation direction. The direction is mandatory and must be
up or down. bidirectional is forbidden. The SCHC header may be up or down. bidirectional is forbidden. The SCHC header may be
composed of (cf. Figure 15): composed of (cf. Figure 16):
* a Datagram Tag (Dtag) identifying the datagram being fragmented if * a Datagram Tag (Dtag) identifying the datagram being fragmented if
the fragmentation applies concurrently on several datagrams. This the fragmentation applies concurrently on several datagrams. This
field in optional and its length is defined by the rule. field in optional and its length is defined by the rule.
* a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack- * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack-
Always, its size is 1 and depends on the rule in Ack-on-Error. Always, its size is 1 and depends on the rule in Ack-on-Error.
This field is not need in No-Ack mode. This field is not need in No-Ack mode.
* 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 16: 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 17.
// -- 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. RCS is 4 byte-long";
} }
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 17: 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 18 allows to
define the behavior: define the behavior:
* all1-data-no: the last fragment contains no data, just the RCS * all1-data-no: the last fragment contains no data, just the RCS
* 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
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.";
} }
skipping to change at page 16, line 52 skipping to change at page 16, line 48
} }
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 18: 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
data. The header is composed of (see Figure 18): data. The header is composed of (see Figure 19):
* a Dtag (if present). * a Dtag (if present).
* a mandatory window as in the data fragment. * a mandatory window as in the data fragment.
* a C bit giving the status of RCS validation. In case of failure, * a C bit giving the status of RCS validation. In case of failure,
a bitmap follows, indicating received fragment/tile. The size of a bitmap follows, indicating received fragment/tile. The size of
the bitmap is given by the FCN value. the bitmap is given by the FCN value.
NOTE: IN THE DATA MODEL THERE IS A max-window-size FIELD TO LIMIT THE NOTE: IN THE DATA MODEL THERE IS A max-window-size FIELD TO LIMIT THE
skipping to change at page 17, line 34 skipping to change at page 17, line 31
|--- 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 19: 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 20) define the acknowledgment behavior.
// -- Ack behavior
identity ack-behavior-base-type { identity ack-behavior-base-type {
description description
"Define when to send an Acknowledgment ."; "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;
description description
"Fragmentation expects Ack after sending All1 fragment."; "Fragmentation expects Ack after sending All1 fragment.";
} }
identity ack-behavior-always { identity ack-behavior-by-layer2 {
base ack-behavior-base-type; base ack-behavior-base-type;
description description
"Fragmentation expects Ack after sending every fragment."; "Layer 2 defines when to send an Ack.";
} }
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 20: 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.
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
skipping to change at page 20, line 10 skipping to change at page 19, line 49
* 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 "Rule ID value, this value must be unique combined with
the length."; 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 {
if-feature "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 "A rule is either for compression, no compression or
fragmentation."; fragmentation.";
} }
description description
"Set of rules compression, no compression or fragmentation "Set of rules compression, no compression or fragmentation
rules 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 "a SCHC set of rules is composed of a list of rule which are
either compression or fragmentation."; either compression or fragmentation.";
} }
} }
Figure 20: Definition of a SCHC Context Figure 21: 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 21). An entry contains all the information defined in (cf. Figure 22). An entry contains all the information defined in
Figure 1 with the types defined above. Figure 2 with the types defined above.
The compression rule described Figure 1 is defined by compression- The compression rule described Figure 2 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 2. 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|
+-------+--+--+--+------------+-----------------+---------------+
An entry in a compression rule is composed of 7 elements: +-------+--+--+--+------------+-----------------+---------------+
- Field ID: The header field to be compressed. The content is a |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
YANG identifer. +-------+--+--+--+------------+-----------------+---------------+
- Field Length : either a positive integer of a function
defined as a YANF id.
- Field Position: a positive (and possibly equal to 0) integer.
- Direction Indicator: a YANG identifier giving the direction.
- Target value: a value against which the header Field is
compared.
- Matching Operator: a YANG id giving the operation, paramters
may be associated to that operator.
- Comp./Decomp. Action: A YANG id giving the compression or An entry in a compression rule is composed of 7 elements:
decompression action, paramters may be associated to that - Field ID: The header field to be compressed. The content is a
action. YANG identifer.
"; - Field Length : either a positive integer of a function defined
leaf field-id { as a YANF id.
type schc:fid-type; - Field Position: a positive (and possibly equal to 0) integer.
mandatory true; - Direction Indicator: a YANG identifier giving the direction.
description - Target value: a value against which the header Field is
"Field ID, identify a field in the header with a YANG compared.
referenceid."; - Matching Operator: a YANG id giving the operation, paramters
} may be associated to that operator.
leaf field-length { - Comp./Decomp. Action: A YANG id giving the compression or
type schc:fl-type; decompression action, paramters may be associated to that
mandatory true; action.
description ";
"Field Length in bit or through a function defined as a leaf field-id {
type schc:fid-type;
mandatory true;
description
"Field ID, identify a field in the header with a YANG
referenceid.";
}
leaf field-length {
type schc:fl-type;
mandatory true;
description
"Field Length in bit or through a function defined as a
YANG referenceid."; 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 "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 repeated in the header the value is 1, and incremented for each
repetition of the field. Position 0 means that the position is repetition of the field. Position 0 means that the position is
not important and order may change when decompressed"; 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 "Direction Indicator, a YANG referenceid to say if the packet
is bidirectional, 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. "A list of value to compare with the header field value.
If target value is a singleton, position must be 0. If target value is a singleton, position must be 0.
For matching-list, should be consecutive position 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 error-message
"mo-equal, mo-msb and mo-match-mapping need target-value"; "mo-equal, mo-msb and mo-match-mapping need target-value";
description
"target-value is not required for mo-ignore";
}
must "not (derived-from-or-self(., 'mo-msb')) or
../matching-operator-value" {
error-message "mo-msb requires length value";
}
mandatory true;
description
"MO: Matching Operator";
}
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.";
}
}
description grouping compression-content {
"target-value is not required for mo-ignore"; list entry {
} key "field-id field-position direction-indicator";
must "not (derived-from-or-self(., 'mo-msb')) or uses compression-rule-entry;
../matching-operator-value" { description
error-message "mo-msb requires length value"; "A compression rule is a list of rule entry describing
} each header field. An entry is identifed through a field-id,
mandatory true; its position in the packet and its direction.";
description }
"MO: Matching Operator"; description
} "Define a compression rule composed of a list of entries.";
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 { Figure 22: Definition of a compression entry
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 definition of a Fragmentation rule is divided into three sub-
parts:
* direction must be either up or down (not bidirectional). * parameters such as the the fragmnetation-mode, the l2-word-size
and the direction. Since Fragmentation rules are always defined
for a specific direction, the value must be must be either di-up
or di-down (bi-bidirectional is not allowed).
* W size is only needed for Ack Always and Ack on Error modes. * parameters defining the Fragmentation header format (dtag-size,
w-size, fcn-size and rcs-algorithm).
* Protocol parameters for timers (inactivity-timer, retransmission-
timer) or behavior (maximum-packet-size, max-interleaved-frames,
max-ack-requests). If these parameters are specific to a single
fragmentation mode, they are regrouped in a choice structure
dedicated to that Fragmentation mode. If some parameters can be
find in several modes, typically ACK-Always and ACK-on-Error.
They are defined in a common part and a when statement indicates
which modes are allowed.
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 fragmentation-mode {
type schc:fragmentation-mode-type;
mandatory true;
description
"which fragmentation mode is used (noAck, AckAlways,
AckonError)";
}
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 {
type schc:di-type; type schc:di-type;
must "derived-from-or-self(., 'di-up') or must "derived-from-or-self(., 'di-up') or
derived-from-or-self(., 'di-down')" { derived-from-or-self(., 'di-down')" {
error-message error-message
"direction for fragmentation rules are up or down."; "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.";
} }
// SCHC Frag header format
leaf dtag-size { leaf dtag-size {
type uint8; type uint8;
default "0"; default "0";
description description
"Size in bit of the DTag field (T variable from RFC8724)."; "Size in bit of the DTag field (T variable from RFC8724).";
} }
leaf w-size { leaf w-size {
when "not(derived-from(../fragmentation-mode, when "derived-from(../fragmentation-mode,
'fragmentation-mode-no-ack'))"; 'fragmentation-mode-ack-on-error')
or
derived-from(../fragmentation-mode,
'fragmentation-mode-ack-always') ";
type uint8; type uint8;
description description
"Size in bit of the window field (M variable from RFC8724)."; "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 (M variable from RFC8724)."; "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. The algorithm spedifies the RCS size";
} }
leaf maximum-window-size { // SCHC fragmentation protocol paramters
leaf maximum-packet-size {
type uint16; type uint16;
default "1280";
description description
"By default 2^wsize - 1"; "When decompression is done, packet size must not
strictly exceed this limit in Bytes.";
}
leaf window-size {
type uint16;
description
"By default, if not specified 2^w-size - 1. Should not exceed
this value. Possible FCN values are between 0 and
window-size-1.";
}
leaf max-interleaved-frames {
type uint8;
default "1";
description
"Maximum of simultaneously fragmented frames. Maximum value is
2^dtag-size. All DTAG values can be used, but only
max-interleaved-frames must be active.";
}
leaf inactivity-timer {
type uint64;
description
"Duration is seconds of the inactivity timer, 0 indicates
the timer is disabled.";
} }
leaf retransmission-timer { leaf retransmission-timer {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')
or
derived-from(../fragmentation-mode,
'fragmentation-mode-ack-always') ";
type uint64 { type uint64 {
range "1..max"; range "1..max";
} }
description description
"Duration in seconds of the retransmission timer."; "Duration in seconds of the retransmission timer.";
} }
leaf inactivity-timer {
type uint64;
description
"Duration is seconds of the inactivity timer,
0 indicates the timer is disabled.";
}
leaf max-ack-requests { leaf max-ack-requests {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')
or
derived-from(../fragmentation-mode,
'fragmentation-mode-ack-always') ";
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 {
type uint16;
default "1280";
description
"When decompression is done, packet size must not
strictly exceed this limit in Bytes.";
}
leaf fragmentation-mode {
type schc:fragmentation-mode-type;
mandatory true;
description
"which fragmentation mode is used (noAck, AckAlways,
AckonError)";
}
choice mode { 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, when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')"; 'fragmentation-mode-ack-on-error')";
type uint8; type uint8;
description description
"Size in bit of tiles, if not specified or set to 0, "Size in bit of tiles, if not specified or set to 0,
tile fills the fragment."; tile fills the fragment.";
} }
leaf tile-in-All1 { leaf tile-in-All1 {
when "derived-from(../fragmentation-mode, when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')"; 'fragmentation-mode-ack-on-error')";
type schc:all1-data-type; type schc:all1-data-type;
description description
"When true, sender and receiver except a tile in "When true, sender and receiver except a tile in
All-1 frag."; All-1 frag.";
} }
leaf ack-behavior { leaf ack-behavior {
when "derived-from(../fragmentation-mode, when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')"; 'fragmentation-mode-ack-on-error')";
type schc:ack-behavior-type; type schc:ack-behavior-type;
description description
"Sender behavior to acknowledge, after All-0, All-1 or "Sender behavior to acknowledge, after All-0, All-1 or
when the LPWAN allows it (Always)."; when the LPWAN allows it (Always).";
} }
} }
description description
"RFC 8724 defines 3 fragmentation modes."; "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 fragmentation-mode schc:fragmentation-mode-type
| +--rw direction schc:di-type | +--rw l2-word-size? uint8
| +--rw dtag-size? uint8 | +--rw direction schc:di-type
| +--rw w-size? uint8 | +--rw dtag-size? uint8
| +--rw fcn-size uint8 | +--rw w-size? uint8
| +--rw rcs-algorithm? rcs-algorithm-type | +--rw fcn-size uint8
| +--rw maximum-window-size? uint16 | +--rw rcs-algorithm? rcs-algorithm-type
| +--rw retransmission-timer? uint64 | +--rw maximum-packet-size? uint16
| +--rw inactivity-timer? uint64 | +--rw window-size? uint16
| +--rw max-ack-requests? uint8 | +--rw max-interleaved-frames? uint8
| +--rw maximum-packet-size? uint16 | +--rw inactivity-timer? uint64
| +--rw fragmentation-mode schc:fragmentation-mode-type | +--rw retransmission-timer? uint64
| +--rw max-ack-requests? uint8
| +--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
+--:(compression) +--:(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 22 Figure 23
4. IANA Considerations 4. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
5. Security considerations 5. Security considerations
This document does not have any more Security consideration than the This document does not have any more Security consideration than the
ones already raised on [RFC8724] ones already raised on [RFC8724]
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Dominique Barthel, Carsten Bormann, The authors would like to thank Dominique Barthel, Carsten Bormann,
Alexander Pelov. Alexander Pelov.
7. YANG Module 7. YANG Module
<code begins> file ietf-schc@2021-11-10.yang <code begins> file ietf-schc@2022-02-15.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 16 skipping to change at page 30, line 16
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 Generic Data model for Static Context Header Compression Rule for
SCHC, based on RFC 8724 and RFC8824. Include compression, no SCHC, based on RFC 8724 and RFC8824. Include compression, no
compression 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 compression rules 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 exchanges or modification. It proposes both the data model format
and the global identifiers used to describes some operations in and the global identifiers used to describe some operations in
fields. fields.
This data model applies both to compression and fragmentation."; This data model applies to both compression and fragmentation.";
revision 2021-11-10 { revision 2022-02-15 {
description description
"Initial version from RFC XXXX "; "Initial version from RFC XXXX ";
reference reference
"RFC XXX: Data Model for Static Context Header Compression "RFC XXX: Data Model for Static Context Header Compression
(SCHC)"; (SCHC)";
}
feature compression {
description
"SCHC compression capabilities are taken into account";
} }
feature fragmentation { feature fragmentation {
description description
"Fragmentation is usually required only at the transportation "SCHC fragmentation capabilities are taken into account";
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 ID base type for IPv6 headers described in RFC 8200";
} }
identity fid-ipv6-version { identity fid-ipv6-version {
base fid-ipv6-base-type; base fid-ipv6-base-type;
description description
"IPv6 version field from RFC8200"; "IPv6 version field from RFC8200";
} }
identity fid-ipv6-trafficclass { identity fid-ipv6-trafficclass {
base fid-ipv6-base-type; base fid-ipv6-base-type;
skipping to change at page 31, line 24 skipping to change at page 32, line 29
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 "corresponds to either the source address or the destination
address prefix of RFC 8200. Depending if it is address prefix of RFC 8200. Depending if it is
respectively a uplink or an downklink message."; respectively an uplink or a 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 "corresponds to either the source address or the destination
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."; an uplink or a 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 "corresponds to either the source address or the destination
address prefix of RFC 768. Depending if it is respectively address prefix of RFC 8200. 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 "corresponds to either the source address or the destination
address prefix of RFC 768. Depending if it is respectively address prefix of RFC 8200. 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 ID 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 source or destination port from RFC 768, if uplink or
downlink communication, respectively.";
} }
identity fid-udp-app-port { identity fid-udp-app-port {
base fid-udp-base-type; base fid-udp-base-type;
description description
"UDP length from RFC 768"; "UDP destination or source port from RFC 768, if uplink or
downlink communication, respectively.";
} }
identity fid-udp-length { identity fid-udp-length {
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-checksum { identity fid-udp-checksum {
base fid-udp-base-type; base fid-udp-base-type;
description description
"UDP length from RFC 768"; "UDP length from RFC 768";
} }
identity fid-coap-base-type { identity fid-coap-base-type {
base fid-base-type; base fid-base-type;
description description
"Field IP base type for UDP headers described in RFC 768"; "Field ID base type for UDP headers described in RFC 7252";
} }
identity fid-coap-version { identity fid-coap-version {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP version from RFC 7252"; "CoAP version from RFC 7252";
} }
identity fid-coap-type { identity fid-coap-type {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP type from RFC 7252"; "CoAP type from RFC 7252";
} }
identity fid-coap-tkl { identity fid-coap-tkl {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP token length from RFC 7252"; "CoAP token length from RFC 7252";
} }
identity fid-coap-code { identity fid-coap-code {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP code from RFC 7252"; "CoAP code from RFC 7252";
skipping to change at page 34, line 44 skipping to change at page 36, line 4
identity fid-coap-option-uri-path { identity fid-coap-option-uri-path {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Uri-Path from RFC 7252"; "CoAP option Uri-Path from RFC 7252";
} }
identity fid-coap-option-content-format { identity fid-coap-option-content-format {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Content Format from RFC 7252"; "CoAP option Content Format from RFC 7252";
} }
identity fid-coap-option-max-age { identity fid-coap-option-max-age {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Max-Age from RFC 7252"; "CoAP option Max-Age from RFC 7252";
} }
identity fid-coap-option-uri-query { identity fid-coap-option-uri-query {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Uri-Query from RFC 7252"; "CoAP option Uri-Query from RFC 7252";
} }
identity fid-coap-option-accept { identity fid-coap-option-accept {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Max-Age from RFC 7252"; "CoAP option Accept from RFC 7252";
} }
identity fid-coap-option-location-query { identity fid-coap-option-location-query {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Location-Query from RFC 7252"; "CoAP option Location-Query from RFC 7252";
} }
identity fid-coap-option-block2 { identity fid-coap-option-block2 {
base fid-coap-base-type; base fid-coap-base-type;
skipping to change at page 35, line 44 skipping to change at page 37, line 4
identity fid-coap-option-size2 { identity fid-coap-option-size2 {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option size2 from RFC 7959"; "CoAP option size2 from RFC 7959";
} }
identity fid-coap-option-proxy-uri { identity fid-coap-option-proxy-uri {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Proxy-Uri from RFC 7252"; "CoAP option Proxy-Uri from RFC 7252";
} }
identity fid-coap-option-proxy-scheme { identity fid-coap-option-proxy-scheme {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Proxy-scheme from RFC 7252"; "CoAP option Proxy-scheme from RFC 7252";
} }
identity fid-coap-option-size1 { identity fid-coap-option-size1 {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option Size1 from RFC 7252"; "CoAP option Size1 from RFC 7252";
} }
identity fid-coap-option-no-response { identity fid-coap-option-no-response {
base fid-coap-base-type; base fid-coap-base-type;
description description
"CoAP option No response from RFC 7967"; "CoAP option No response from RFC 7967";
} }
identity fid-coap-option-oscore-flags { identity fid-coap-option-oscore-flags {
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 RFC 8824, section 6.4)";
} }
identity fid-coap-option-oscore-piv { identity fid-coap-option-oscore-piv {
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 RFC 8824, section 6.4)";
} }
identity fid-coap-option-oscore-kid { identity fid-coap-option-oscore-kid {
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 RFC 8824, 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 RFC 8824, section 6.4)";
} }
//---------------------------------- //----------------------------------
// 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 as 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).";
skipping to change at page 37, line 35 skipping to change at page 38, line 42
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 uplink 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 downlink 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";
} }
identity mo-equal { identity mo-equal {
skipping to change at page 40, line 30 skipping to change at page 41, line 36
down when received by the device, bi when emitted or down when received by the device, bi when emitted or
received by the device."; 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 "Matching Operator (MO) to compare fields values with
target values"; 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 "Compression Decompression Action to compression or
decompress a field."; 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 RFC8724.";
} }
identity fragmentation-mode-ack-always { identity fragmentation-mode-ack-always {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
description description
"Ack Always of RFC8724."; "ACK-Always of RFC8724.";
} }
identity fragmentation-mode-ack-on-error { identity fragmentation-mode-ack-on-error {
base fragmentation-mode-base-type; base fragmentation-mode-base-type;
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";
} }
skipping to change at page 41, line 46 skipping to change at page 43, line 4
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;
description description
"Fragmentation expects Ack after sending All1 fragment."; "Fragmentation expects Ack after sending All1 fragment.";
} }
identity ack-behavior-by-layer2 {
identity ack-behavior-always {
base ack-behavior-base-type; base ack-behavior-base-type;
description description
"Fragmentation expects Ack after sending every fragment."; "Layer 2 defines when to send an Ack.";
} }
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
skipping to change at page 42, line 46 skipping to change at page 44, line 4
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. RCS is 4 byte-long";
} }
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.";
} }
skipping to change at page 43, line 43 skipping to change at page 44, line 49
"If only one element position is 0, otherwise position is the "If only one element position is 0, otherwise position is the
the position in 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 - Field ID: The header field to be compressed. The content is a
YANG identifer. YANG identifer.
- Field Length : either a positive integer of a function defined - Field Length : either a positive integer of a function defined
as a YANF id. 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 - Target value: a value against which the header Field is
compared. compared.
- Matching Operator: a YANG id giving the operation, paramters - Matching Operator: a YANG id giving the operation, paramters
may be associated to that operator. may be associated to that operator.
- Comp./Decomp. Action: A YANG id giving the compression or - Comp./Decomp. Action: A YANG id giving the compression or
decompression action, paramters may be associated to that decompression action, paramters may be associated to that
action. action.
"; ";
skipping to change at page 44, line 27 skipping to change at page 45, line 31
mandatory true; mandatory true;
description description
"Field ID, identify a field in the header with a YANG "Field ID, identify a field in the header with a YANG
referenceid."; 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 "Field Length in bit or through a function defined as a
YANG referenceid."; 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 "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 repeated in the header the value is 1, and incremented for each
repetition of the field. Position 0 means that the position is repetition of the field. Position 0 means that the position is
not important and order may change when decompressed"; 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 "Direction Indicator, a YANG referenceid to say if the packet
is bidirectional, 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. "A list of value to compare with the header field value.
If target value is a singleton, position must be 0. If target value is a singleton, position must be 0.
For matching-list, should be consecutive position 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 error-message
"mo-equal, mo-msb and mo-match-mapping need target-value"; "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 must "not (derived-from-or-self(., 'mo-msb')) or
../matching-operator-value" { ../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";
skipping to change at page 46, line 13 skipping to change at page 47, line 18
each header field. An entry is identifed through a field-id, each header field. An entry is identifed through a field-id,
its position 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 fragmentation-mode {
type schc:fragmentation-mode-type;
mandatory true;
description
"which fragmentation mode is used (noAck, AckAlways,
AckonError)";
}
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 {
type schc:di-type; type schc:di-type;
must "derived-from-or-self(., 'di-up') or must "derived-from-or-self(., 'di-up') or
derived-from-or-self(., 'di-down')" { derived-from-or-self(., 'di-down')" {
error-message error-message
"direction for fragmentation rules are up or down."; "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.";
} }
// SCHC Frag header format
leaf dtag-size { leaf dtag-size {
type uint8; type uint8;
default "0"; default "0";
description description
"Size in bit of the DTag field (T variable from RFC8724)."; "Size in bit of the DTag field (T variable from RFC8724).";
} }
leaf w-size { leaf w-size {
when "not(derived-from(../fragmentation-mode, when "derived-from(../fragmentation-mode,
'fragmentation-mode-no-ack'))"; 'fragmentation-mode-ack-on-error')
or
derived-from(../fragmentation-mode,
'fragmentation-mode-ack-always') ";
type uint8; type uint8;
description description
"Size in bit of the window field (M variable from RFC8724)."; "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 (M variable from RFC8724)."; "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. The algorithm spedifies the RCS size";
} }
leaf maximum-window-size { // SCHC fragmentation protocol paramters
leaf maximum-packet-size {
type uint16; type uint16;
default "1280";
description description
"By default 2^wsize - 1"; "When decompression is done, packet size must not
strictly exceed this limit in Bytes.";
}
leaf window-size {
type uint16;
description
"By default, if not specified 2^w-size - 1. Should not exceed
this value. Possible FCN values are between 0 and
window-size-1.";
}
leaf max-interleaved-frames {
type uint8;
default "1";
description
"Maximum of simultaneously fragmented frames. Maximum value is
2^dtag-size. All DTAG values can be used, but only
max-interleaved-frames must be active.";
}
leaf inactivity-timer {
type uint64;
description
"Duration is seconds of the inactivity timer, 0 indicates
the timer is disabled.";
} }
leaf retransmission-timer { leaf retransmission-timer {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')
or
derived-from(../fragmentation-mode,
'fragmentation-mode-ack-always') ";
type uint64 { type uint64 {
range "1..max"; range "1..max";
} }
description description
"Duration in seconds of the retransmission timer."; "Duration in seconds of the retransmission timer.";
} }
leaf inactivity-timer {
type uint64;
description
"Duration is seconds of the inactivity timer,
0 indicates the timer is disabled.";
}
leaf max-ack-requests { leaf max-ack-requests {
when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')
or
derived-from(../fragmentation-mode,
'fragmentation-mode-ack-always') ";
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 {
type uint16;
default "1280";
description
"When decompression is done, packet size must not
strictly exceed this limit in Bytes.";
}
leaf fragmentation-mode {
type schc:fragmentation-mode-type;
mandatory true;
description
"which fragmentation mode is used (noAck, AckAlways,
AckonError)";
}
choice mode { 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, when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')"; 'fragmentation-mode-ack-on-error')";
type uint8; type uint8;
description description
"Size in bit of tiles, if not specified or set to 0, "Size in bit of tiles, if not specified or set to 0,
tile fills the fragment."; tile fills the fragment.";
} }
leaf tile-in-All1 { leaf tile-in-All1 {
when "derived-from(../fragmentation-mode, when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')"; 'fragmentation-mode-ack-on-error')";
type schc:all1-data-type; type schc:all1-data-type;
description description
"When true, sender and receiver except a tile in "When true, sender and receiver except a tile in
All-1 frag."; All-1 frag.";
} }
leaf ack-behavior { leaf ack-behavior {
when "derived-from(../fragmentation-mode, when "derived-from(../fragmentation-mode,
'fragmentation-mode-ack-on-error')"; 'fragmentation-mode-ack-on-error')";
type schc:ack-behavior-type; type schc:ack-behavior-type;
description description
"Sender behavior to acknowledge, after All-0, All-1 or "Sender behavior to acknowledge, after All-0, All-1 or
when the LPWAN allows it (Always)."; when the LPWAN allows it (Always).";
} }
} }
skipping to change at page 48, line 42 skipping to change at page 50, line 24
} }
// Define rule ID. Rule ID is composed of a RuleID value and a // Define rule ID. Rule ID is composed of a RuleID value and a
// Rule ID Length // 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 "Rule ID value, this value must be unique combined with
the length."; 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 {
if-feature "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 "A rule is either for compression, no compression or
fragmentation."; fragmentation.";
} }
description description
"Set of rules compression, no compression or fragmentation "Set of rules compression, no compression or fragmentation
rules 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 "a SCHC set of rules is composed of a list of rule which are
either compression or fragmentation."; either compression or fragmentation.";
} }
} }
<code ends> <code ends>
Figure 23 Figure 24
8. Normative References 8. Normative References
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header 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
 End of changes. 175 change blocks. 
339 lines changed or deleted 444 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/