< draft-ietf-lpwan-schc-yang-data-model-00.txt   draft-ietf-lpwan-schc-yang-data-model-01.txt >
Network Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Informational L. Toutain Intended status: Standards Track L. Toutain
Expires: October 23, 2019 Institut MINES TELECOM ; IMT Atlantique Expires: July 26, 2020 Institut MINES TELECOM; IMT Atlantique
April 21, 2019 January 23, 2020
Data Model for Static Context Header Compression (SCHC) Data Model for Static Context Header Compression (SCHC)
draft-ietf-lpwan-schc-yang-data-model-00 draft-ietf-lpwan-schc-yang-data-model-01
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). A generic module is defined, that can Context Header Compression) compression and fragmentation rules.
be applied for any headers and also a specific model for the IPv6 UDP
protocol stack is also proposed. Note that this draft is a first
attempt to define a YANG data module for SCHC, more work is needed to
use all the YANG facilities.
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.
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 October 23, 2019. This Internet-Draft will expire on July 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3
2.2. Field Identifier . . . . . . . . . . . . . . . . . . . . 4
2.3. Field length . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Field position . . . . . . . . . . . . . . . . . . . . . 7
2.5. Direction Indicator . . . . . . . . . . . . . . . . . . . 7
2.6. Target Value . . . . . . . . . . . . . . . . . . . . . . 8
2.7. Matching Operator . . . . . . . . . . . . . . . . . . . . 9
2.7.1. Matching Operator arguments . . . . . . . . . . . . . 10
2.8. Compression Decompresison Actions . . . . . . . . . . . . 10
2.8.1. Compression Decompression Action arguments . . . . . 12
3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Compression context representation. . . . . . . . . . 14
3.1.2. Rule definition . . . . . . . . . . . . . . . . . . . 16
3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 16
3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
SCHC [I-D.ietf-lpwan-ipv6-static-context-hc] defines a compression 2. SCHC rules
technique for LPWAN networks based on static context. The context
contains a list of rules (cf. Figure 1). Each rule contains itself SCHC is a compression and fragmentation mechanism for constrained
a list of field descriptions composed of a field identifier (FID), a networks defined in [I-D.ietf-lpwan-ipv6-static-context-hc] it is
field length (FID), a field position (FP), a field direction (DI), a based on a static context shared by two entities at the boundary this
target value (TV), a matching operator (MO) and a Compression/ contrained network. Draft [I-D.ietf-lpwan-ipv6-static-context-hc]
Decompression Action (CDA). provides an abstract 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:
o universal representation of the rule to allow the same rule
represention on both ends. For instance; a device can provide the
rule it uses to store them in the core SCHC C/D and F/R.
o a device or the core SCHC instance may update the other end to set
upsome specific values (e.g. IPv6 prefix, Destination
address,...)
o ...
This document defines a YANG module to represent both compression and
fragmentation rules, which leads to common representation and values
for the elements of the rules. SCHC compression is generic, the main
mechanism do no refers to a specific fields. A field is abstractedh
through an ID, a position, a direction and a value that can be a
numerical value or a string.
[I-D.ietf-lpwan-ipv6-static-context-hc] and
[I-D.ietf-lpwan-coap-static-context-hc] specifies fields for IPv6,
UDP, CoAP and OSCORE.
Fragmentation requires a set of common parameters that are included
in a rule.
2.1. Compression Rules
[I-D.ietf-lpwan-ipv6-static-context-hc] proposes an abstract
representation of the compression rule. A compression context for a
device is composed of a set of rules. Each rule contains information
to describe a specific field in the header to be compressed.
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| Rule N | | Rule N |
+-----------------------------------------------------------------+| +-----------------------------------------------------------------+|
| Rule i || | Rule i ||
+-----------------------------------------------------------------+|| +-----------------------------------------------------------------+||
| (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||||
|+-------+--+--+--+------------+-----------------+---------------+||| |+-------+--+--+--+------------+-----------------+---------------+|||
skipping to change at page 2, line 37 skipping to change at page 4, line 5
|+-------+--+--+--+------------+-----------------+---------------+||| |+-------+--+--+--+------------+-----------------+---------------+|||
||... |..|..|..| ... | ... | ... |||| ||... |..|..|..| ... | ... | ... ||||
|+-------+--+--+--+------------+-----------------+---------------+||/ |+-------+--+--+--+------------+-----------------+---------------+||/
||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||
|+-------+--+--+--+------------+-----------------+---------------+|/ |+-------+--+--+--+------------+-----------------+---------------+|/
| | | |
\-----------------------------------------------------------------/ \-----------------------------------------------------------------/
Figure 1: Compression Decompression Context Figure 1: Compression Decompression Context
The goal of this document is to provide an YANG data model to 2.2. Field Identifier
represent SCHC Compression and Fragmentation rules, to allow
management over a LPWAN network. The main constraints are:
o since the device may be managed through the LPWAN network, In the process of compression, the headers of the original packet are
management messages must be compact. COREconf offers a first parsed to create a list of fields. This list of fields is
representation based on CBOR. matched again the rules to find the appropriate one and apply
compression. The link between the list given by the parsed fields
and the rules is doen through a field ID.
[I-D.ietf-lpwan-ipv6-static-context-hc] do not state how the field ID
value can be constructed. In the given example, it was given through
a string indexed by the protocol name (e.g. IPv6.version,
CoAP.version,...).
o this data model can be extended with new values, such as new field Using the YANG model, each field can be identified through a global
id, new MO or CDA. YANG identityref. A YANG field ID derives from the field-id-base-
type. Figure 2 gives some field ID definitions. Note that some
field IDs can be splitted is smaller pieces. This is the case for
"fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are
a subset of "fid-ipv6-trafficclass-ds".
2. YANG types identity field-id-base-type {
description "Field ID with SID";
}
2.1. Field Identifier identity fid-ipv6-version {
base field-id-base-type;
description "IPv6 version field from RFC8200";
}
The field identifier is used to identify a specific field. It is identity fid-ipv6-trafficclass {
viewed as an uint32. base field-id-base-type;
description "IPv6 Traffic Class field from RFC8200";
}
2.2. Target Value field identity fid-ipv6-trafficclass-ds {
base field-id-base-type;
description "IPv6 Traffic Class field from RFC8200,
DiffServ field from RFC3168";
}
A value may be associated for each field in a rule. The value's type identity fid-ipv6-trafficclass-ecn {
depends on the field. It can be an integer, a prefix, a string, or base field-id-base-type;
any other type carried by the field. The LPWA-types regroups all the description "IPv6 Traffic Class field from RFC8200,
possibles values. Figure 2 gives its definition. ECN field from RFC3168";
}
typedef lpwan-types { ...
identity fid-coap-option-if-match {
base field-id-base-type;
description "CoAP option If-Match from RFC 7252";
}
identity fid-coap-option-uri-host {
base field-id-base-type;
description "CoAP option URI-Host from RFC 7252";
}
...
Figure 2: Definition of indentityref for field IDs
Figure 2 gives an example of field ID identityref definitions. The
base identity is field-id-base-type, and field id are derived for it.
The naming convention is "fid" followed by the protocol name and the
field name.
The yang model in annex gives the full definition of the field ID for
[I-D.ietf-lpwan-ipv6-static-context-hc] and
[I-D.ietf-lpwan-coap-static-context-hc].
The type associated to this identity is field-id-type (cf. {{Fig-field-id-type}})
typedef field-id-type {
description "Field ID generic type.";
type identityref {
base field-id-base-type;
}
}
Figure 3: Definition of indentityref for field IDs
2.3. Field length
Field length is either an integer giving the size of a field in bits
or a function. [I-D.ietf-lpwan-ipv6-static-context-hc] defines the
"var" function which allows variable length fields in byte and
[I-D.ietf-lpwan-coap-static-context-hc] defines the "tkl" function
for managing the CoAP Token length field.
identity field-length-base-type {
description "used to extend field length functions";
}
identity fl-variable {
base field-length-base-type;
description "residue length in Byte is sent";
}
identity fl-token-length {
base field-length-base-type;
description "residue length in Byte is sent";
}
Figure 4: Definition of indetntyref for field IDs
As for field ID, field length function can be defined as a
identityref as shown in Figure 4.
Therefore the type for field length is a union between an integer
giving in bits the size of the length and the identityref (cf.
Figure 5).
typedef field-length-type {
type union {
type int64; /* positive length */
type identityref { /* function */
base field-length-base-type;
}
}
}
Figure 5: Definition of indetntyref for field IDs
The naming convention is fl followed by the function name as defined
in SCHC specifications.
2.4. Field position
Field position is a positive integer which gives the position of a
field, the default value is 1, but if the field is repeated several
times, the value is higher. value 0 indicates that the position is
not important and is not taken into account during the rule selection
process.
Field position is a positive integer. The type is an uint8.
2.5. Direction Indicator
The Direction Indicator (DI) is used to tell if a field appears in
both direction (Bi) or only uplink (Up) or Downlink (Dw).
identity direction-indicator-base-type {
description "used to extend field length functions";
}
identity di-bidirectional {
base direction-indicator-base-type;
description "Direction Indication of bi directionality";
}
identity di-up {
base direction-indicator-base-type;
description "Direction Indication of upstream";
}
identity di-down {
base direction-indicator-base-type;
description "Direction Indication of downstream";
}
Figure 6: Definition of identityref for direction indicators
Figure 6 gives the identityref for Direction Indicators.
The type is "direction-indicator-type" (cf. Figure 7).
typedef direction-indicator-type {
type identityref {
base direction-indicator-base-type;
}
}
Figure 7: Definition of identityref for direction indicators
2.6. Target Value
Target Value may be either a string or binary sequence. For match-
mapping, several of these values can be contained in a Target Value
field. In the data model, this is generalized by adding a position,
which orders the list of values. By default the position is set to
0.
The leaf "value" is not mandatory to represent a non existing value
in a TV.
grouping target-values-struct {
leaf value {
type union { type union {
type uint8; type binary;
type uint16;
type uint32;
type uint64;
type inet:ipv6-prefix;
type string; type string;
} }
} }
leaf position {
type uint16;
}
}
Figure 2: Value types Figure 8: Definition of target value
Note that as defined in [I-D.ietf-lpwan-ipv6-static-context-hc], Dev Figure 8 gives the definition of a single element of a Target Value.
and App Prefixes can be of type inet:ipv6-prefix-type, but this type In the rule, this will be used as a list, with position as a key.
derives from ASCII characters, a binary representation such as uint64
will be more compact.
2.3. Matching Operators 2.7. Matching Operator
A matching operator is used to check the field value stored in the Matching Operator (MO) is a function applied between a field value
rule against the value contained in the header field. If there is no provided by the parsed header and the target value.
matching the rule is not selected. Two instances of matching [I-D.ietf-lpwan-ipv6-static-context-hc] defines 4 MO.
operator are defined to allow the rule selection from informations
contained either in the compressed header or the uncompressed header.
The SCHC document [I-D.ietf-lpwan-ipv6-static-context-hc] defines
four operators:
o equal: The rule's value must be equal to the packet header value identity matching-operator-base-type {
for a specific field. description "used to extend Matching Operators with SID values";
}
o ignore: There is no check for this field. identity mo-equal {
base matching-operator-base-type;
description "SCHC draft";
}
o MSB(x): This operator compare the most significant bits. The identity mo-ignore {
operator takes one argument representing the length of least base matching-operator-base-type;
significant bit part, which will be ignored during the matching description "SCHC draft";
but sent if the rule matches. }
o match-mapping: From the list of values of the Target Value, This identity mo-msb {
operator will match if one of those values is equal to the field base matching-operator-base-type;
value and will send the index of the list representing this value. description "SCHC draft";
}
/**********************************/ identity mo-matching {
/* Matching operator type */ base matching-operator-base-type;
/**********************************/ description "SCHC draft";
typedef matching-operator-type { }
type enumeration {
enum equal; Figure 9: Definition of Matching Operator identity
enum ignore;
enum msb; the type is "matching-operator-type" (cf. Figure 10)
enum match-mapping;
typedef matching-operator-type {
type identityref {
base matching-operator-base-type;
} }
} }
Figure 3: Matching operators Figure 10: Definition of Matching Operator type
Figure 3 represents the Matching Operator type definition. 2.7.1. Matching Operator arguments
2.4. Compression Decompression Actions Some Matching Operator such as MSB can take some values. Even if
currently LSB is the only MO takes only one argument, in the future
some MO may require several arguments. They are viewed as a list of
target-values-type.
The SCHC document [I-D.ietf-lpwan-ipv6-static-context-hc] defines 2.8. Compression Decompresison Actions
some compression decompression actions (CDA). The CDA tells how to
compress and decompress the field. They are defined in Figure 4.
they are coded the same way as MO.
/***********************************************/ Compresion Decompression Action (CDA) idenfied the function to use
/* Compression-Decompression action type */ either for compression or decompression.
/***********************************************/ [I-D.ietf-lpwan-ipv6-static-context-hc] defines 6 CDA.
typedef compression-decompression-action-type {
type enumeration {
enum not-sent;
enum value-sent;
enum lsb;
enum mapping-sent;
enum compute-length;
enum compute-checksum;
enum esiid-did;
enum laiid-did;
}
}
Figure 4: Action functions identity compression-decompression-action-base-type;
3. Generic rule definition identity cda-not-sent {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
Each rule's row is defined by several leaves, composed of: identity cda-value-sent {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
o a field key which will be used as a key, identity cda-lsb {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
o a field name that can be used for debugging purpose, identity cda-mapping-sent {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
o a field length that containing the length of the field, identity cda-compute-length {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
o a field position that gives the number of instances, identity cda-compute-checksum {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
o a field direction indicates the packet direction, identity cda-deviid {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
o a field target value containing the value that will be compared, identity cda-appiid {
base compression-decompression-action-base-type;
description "from SCHC draft";
}
o a matching operators for rule selection Figure 11: Definition of Compresion Decompression Action identity
o an compression/decompression action to compress/decompress the The type is "comp-decomp-action-type" (cf. Figure 12)
field. typedef comp-decomp-action-type {
type identityref {
base compression-decompression-action-base-type;
}
}
Figure 5 defines the format. Figure 12: Definition of Compresion Decompression Action type
grouping rule-entry { 2.8.1. Compression Decompression Action arguments
leaf field-id {
type int32;
description "Field ID unique value representing the Field";
}
leaf field-length {
type uint8;
description "size in bits of the field";
}
leaf field-position { Currently no CDA requires argumetns, but the future some CDA may
type uint8; require several arguments. They are viewed as a list of target-
description "For repeated fields, we need to be able to values-type.
distinguish between successive occurences";
}
leaf direction { 3. Rule definition
type direction-type;
}
list target-values {
key tv-key;
leaf tv-key {
type int8;
}
leaf target-value {
type lpwan-types;
}
description "Target Values can be a list of value, for
match-mapping. For other MO, only one entry is specified";
}
leaf matching-operator {
type matching-operator-type;
}
leaf matching-operator-parameter { A rule is either a C/D or an F/R rule. A rule is identified by the
type lpwan-types; rule ID value and its associated length. The YANG grouping rule-id-
description "If the matching operator requires a parameter type defines the structure used to represent a rule ID. Length of 0
(for example lsb or msb), the value is provided here."; is allowed to represent an implicit rule.
}
leaf compression-decompression-action { // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length
type compression-decompression-action-type;
}
leaf compression-decompression-action-parameter { grouping rule-id-type {
type lpwan-types; leaf rule-id {
description "If the matching operator requires a parameter type uint32;
(for example lsb or msb), the value is provided here."; description "rule ID value, this value must be unique combined with the length";
} }
leaf rule-length {
type uint8 {
range 0..32;
} }
description "rule ID length in bits, value 0 is for implicit rules";
}
}
Figure 5: Action functions // SCHC table for a specific device.
4. YANG static context model container schc {
leaf version{
type uint64;
mandatory false;
description "used as an indication for versioning";
}
list rule {
key "rule-id rule-length";
uses rule-id-type;
choice nature {
case fragmentation {
uses fragmentation-content;
}
case compression {
uses compression-content;
}
}
}
}
This lead to the generic rule definition, represented Figure 7. It Figure 13: Definition of a SCHC Context
defines a set of rules.
grouping compression-rule { To access to a specfic rule, rule-id and its specific length is used
as a key. The rule is either a compression or a fragmentation rule.
leaf rule-id { Each context can be identify though a version id.
type uint8;
description "The number of the context rule that should be applied.";
}
leaf rule-id-length {
type uint8;
}
list rule-fields { 3.1. Compression rule
key "field-id field-position direction";
uses rule-entry;
}
A compression rule is composed of entries describing its processing
(cf. Figure 14). An entry contains all the information defined in
Figure 1 with the types defined above.
3.1.1. Compression context representation.
The compression rule described Figure 1 is associated to a rule ID.
The compression rule entry is defined in Figure 14. Each column in
the table is either represented by a leaf or a list. Note that
Matching Operators and Compression Decompression actions can have
arguments. They are viewed a ordered list of strings and numbers as
in target values.
grouping compression-rule-entry {
leaf field-id {
mandatory true;
type schc-id:field-id-type;
}
leaf field-length {
mandatory true;
type schc-id:field-length-type;
}
leaf field-position {
mandatory true;
type uint8;
}
leaf direction-indicator {
mandatory true;
type schc-id:direction-indicator-type;
}
list target-values {
key position;
uses target-values-struct;
}
leaf mo {
mandatory true;
type schc-id:matching-operator-type;
}
// /!\ Not always good, it allows to give several arguments to a MO, but
// theses arguments are only int or strings, cannot be arrays. Is it necessary?
list mo-value {
key position;
uses target-values-struct;
}
leaf cda {
mandatory true;
type schc-id:cda-type;
}
list cda-value {
key position;
uses target-values-struct;
}
} }
Figure 6: YANG definition of the generic module Figure 14: Definition of a compression entry
module: ietf-lpwan-schc-rule 3.1.2. Rule definition
+--rw rule-id? uint8
+--rw rule-id-length? uint8
+--rw rule-fields* [field-id field-position direction]
+--rw field-id int32
+--rw field-length? uint8
+--rw field-position uint8
+--rw direction direction-type
+--rw target-values* [tv-key]
| +--rw tv-key int8
| +--rw target-value? lpwan-types
+--rw matching-operator? m.-o.-type
+--rw matching-operator-parameter? lpwan-types
+--rw compression-decompression-action? c.-d.-a.-type
+--rw compression-decompression-action-parameter? lpwan-types
Figure 7: Generic module tree A compression rule is a list of entries.
The YANG tree is given Figure 7. grouping compression-content {
list entry {
key "field-id field-position direction-indicator"; // field-position direction-indicator";
uses compression-rule-entry;
}
}
SID Assigned to Figure 15: Definition of a compression rule
--------- --------------------------------------------------
60000 node /rule-fields
60001 node /rule-fields/compression-decompression-action
60002 node /rule-fields/compression-decompression-action-parameter
60003 node /rule-fields/direction
60004 node /rule-fields/field-id
60005 node /rule-fields/field-length
60006 node /rule-fields/field-position
60007 node /rule-fields/matching-operator
60008 node /rule-fields/matching-operator-parameter
60009 node /rule-fields/target-values
60010 node /rule-fields/target-values/target-value
60011 node /rule-fields/target-values/tv-key
60012 node /rule-id
60013 node /rule-id-length
File ietf-lpwan-schc-rule@2016-10-31.sid created To identify a specific entry Field ID, position and direction is
Number of SIDs available : 100 needed.
Number of SIDs assigned : 14
Figure 8: Example of SID allocation 3.2. Fragmentation rule
Figure 8 gives a simple allocation for SID value. SID values from TBD
100 to 113 are used for /generic-rules/context-rules/rule-fields/
field-compression-decompression-action. SID value from 1009 to 1012
are used in /generic-rules/context-rules/rule-fields/field-matching-
operator.
5. Acknowledgement grouping fragmentation-content {
leaf dtagsize {
type uint8;
}
leaf wsize {
type uint8;
}
leaf fcnsize {
type uint8;
}
choice mode {
case no-ack;
case ack-always;
case ack-on-error {
leaf ack-method {
type enumeration {
enum afterAll0;
enum afterAll1;
enum always;
}
}
}
}
}
The authors would like to thank Michel Veillette, Alexander Pelov, Figure 16: Definition of a fragmentation rule
Antoni Markovski for their help on COMI/CoOL and YANG.
6. Normative References 3.3. YANG Tree
[I-D.ietf-core-comi] module: schc
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP +--rw schc
Management Interface", draft-ietf-core-comi-04 (work in +--rw version? uint64
progress), November 2018. +--rw rule* [rule-id rule-length]
+--rw rule-id uint32
+--rw rule-length uint8
+--rw (nature)?
+--:(fragmentation)
| +--rw dtagsize? uint8
| +--rw wsize? uint8
| +--rw fcnsize? uint8
| +--rw (mode)?
| +--:(no-ack)
| +--:(ack-always)
| +--:(ack-on-error)
| +--rw ack-method? enumeration
+--:(compression)
+--rw entry* [field-id field-position direction-indicator]
+--rw field-id schc-id:field-id-type
+--rw field-length schc-id:field-length-type
+--rw field-position uint8
+--rw direction-indicator schc-id:direction-indicator-type
+--rw target-values* [position]
| +--rw value? union
| +--rw position uint16
+--rw mo schc-id:matching-operator-type
+--rw mo-value* [position]
| +--rw value? union
| +--rw position uint16
+--rw cda schc-id:comp-decomp-action-type
+--rw cda-value* [position]
+--rw value? union
+--rw position uint16
Figure 17
4. IANA Considerations
This document has no request to IANA.
5. Security considerations
This document does not have any more Security consideration than the
ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]
6. Acknowledgements
The authors would like to thank Dominique Barthel, Carsten Bormann,
Alexander Pelov.
7. YANG Module
8. Normative References
[I-D.ietf-lpwan-coap-static-context-hc]
Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
Context Header Compression (SCHC) for CoAP", draft-ietf-
lpwan-coap-static-context-hc-12 (work in progress),
December 2019.
[I-D.ietf-lpwan-ipv6-static-context-hc] [I-D.ietf-lpwan-ipv6-static-context-hc]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
Zuniga, "LPWAN Static Context Header Compression (SCHC) Zuniga, "Static Context Header Compression (SCHC) and
and fragmentation for IPv6 and UDP", draft-ietf-lpwan- fragmentation for LPWAN, application to UDP/IPv6", draft-
ipv6-static-context-hc-18 (work in progress), December ietf-lpwan-ipv6-static-context-hc-24 (work in progress),
2018. December 2019.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
Authors' Addresses Authors' Addresses
Ana Minaburo Ana Minaburo
Acklio Acklio
1137A Avenue des Champs Blancs 1137A avenue des Champs Blancs
35510 Cesson-Sevigne Cedex 35510 Cesson-Sevigne Cedex
France France
Email: ana@ackl.io Email: ana@ackl.io
Laurent Toutain Laurent Toutain
Institut MINES TELECOM ; IMT Atlantique Institut MINES TELECOM; IMT Atlantique
2 rue de la Chataigneraie 2 rue de la Chataigneraie
CS 17607 CS 17607
35576 Cesson-Sevigne Cedex 35576 Cesson-Sevigne Cedex
France France
Email: Laurent.Toutain@imt-atlantique.fr Email: Laurent.Toutain@imt-atlantique.fr
 End of changes. 75 change blocks. 
227 lines changed or deleted 555 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/