draft-ietf-lpwan-schc-yang-data-model-03.txt   draft-ietf-lpwan-schc-yang-data-model-04.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: January 11, 2021 Institut MINES TELECOM; IMT Atlantique Expires: August 6, 2021 Institut MINES TELECOM; IMT Atlantique
July 10, 2020 February 02, 2021
Data Model for Static Context Header Compression (SCHC) Data Model for Static Context Header Compression (SCHC)
draft-ietf-lpwan-schc-yang-data-model-03 draft-ietf-lpwan-schc-yang-data-model-04
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 January 11, 2021. This Internet-Draft will expire on August 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
8. Normative References . . . . . . . . . . . . . . . . . . . . 41 8. Normative References . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
2. SCHC rules 2. SCHC rules
SCHC is a compression and fragmentation mechanism for constrained SCHC is a compression and fragmentation mechanism for constrained
networks defined in [RFC8724]. It is based on a static context networks defined in [RFC8724]. It is based on a static context
shared by two entities at the boundary this constrained network. shared by two entities at the boundary this constrained network.
Draft [RFC8724] provides an abstract representation of the rules used Draft [RFC8724] provides an non formal representation of the rules
either for compression/decompression (or C/D) or fragmentation/ used either for compression/decompression (or C/D) or fragmentation/
reassembly (or F/R). The goal of this document is to formalize the reassembly (or F/R). The goal of this document is to formalize the
description of the rules to offer: description of the rules to offer:
o the same definition on both ends, even if the internal o the same definition on both ends, even if the internal
representation is different. representation is different.
o an update the other end to set up some specific values (e.g. IPv6 o an update the other end to set up some specific values (e.g. IPv6
prefix, Destination address,...) prefix, Destination address,...)
o ... o ...
This document defines a YANG module to represent both compression and This document defines a YANG module to represent both compression and
fragmentation rules, which leads to common representation for values fragmentation rules, which leads to common representation for values
for all the rules elements. for all the rules elements.
SCHC compression is generic, the main mechanism do no refers to a SCHC compression is generic, the main mechanism do no refers to a
specific fields. A field is abstracted through an ID, a position, a specific protocol. Any header field is abstracted through an ID, a
direction and a value that can be a numerical value or a string. position, a direction and a value that can be a numerical value or a
[RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc] specifies string. [RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc]
fields for IPv6, UDP, CoAP and OSCORE. specifies fields for IPv6, UDP, CoAP and OSCORE.
[I-D.barthel-lpwan-oam-schc] decribes ICMPv6 header compression.
SCHC fragmentation requires a set of common parameters that are SCHC fragmentation requires a set of common parameters that are
included in a rule. These parameters are defined in [RFC8724]. included in a rule. These parameters are defined in [RFC8724].
2.1. Compression Rules 2.1. Compression Rules
[RFC8724] proposes an abstract representation of the compression [RFC8724] proposes an non formal representation of the compression
rule. A compression context for a device is composed of a set of rule. A compression context for a device is composed of a set of
rules. Each rule contains information to describe a specific field rules. Each rule contains information to describe a specific field
in the header to be compressed. in the header to be compressed.
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| Rule N | | Rule N |
+-----------------------------------------------------------------+| +-----------------------------------------------------------------+|
| Rule i || | Rule i ||
+-----------------------------------------------------------------+|| +-----------------------------------------------------------------+||
| (FID) Rule 1 ||| | (FID) Rule 1 |||
skipping to change at page 4, line 4 skipping to change at page 4, line 5
Figure 1: Compression Decompression Context Figure 1: Compression Decompression Context
2.2. Field Identifier 2.2. Field Identifier
In the process of compression, the headers of the original packet are In the process of compression, the headers of the original packet are
first parsed to create a list of fields. This list of fields is first parsed to create a list of fields. This list of fields is
matched against the rules to find the appropriate one and apply matched against the rules to find the appropriate one and apply
compression. The link between the list given by the parsed fields compression. The link between the list given by the parsed fields
and the rules is done through a field ID. [RFC8724] do not state how and the rules is done through a field ID. [RFC8724] do not state how
the field ID value can be constructed. In the examples, it was given the field ID value can be constructed. In examples, identification
through a string indexed by the protocol name (e.g. IPv6.version, is done through a string indexed by the protocol name (e.g.
CoAP.version,...). IPv6.version, CoAP.version,...).
Using the YANG model, each field MUST be identified through a global Using the YANG model, each field MUST be identified through a global
YANG identityref. A YANG field ID derives from the field-id-base- YANG identityref. A YANG field ID derives from the field-id-base-
type. Figure 2 gives some field ID definitions. Note that some type. Figure 2 gives some field ID definitions. Note that some
field IDs can be splitted is smaller pieces. This is the case for field IDs can be splitted is smaller pieces. This is the case for
"fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are "fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are
a subset of "fid-ipv6-trafficclass-ds". a subset of "fid-ipv6-trafficclass-ds".
identity field-id-base-type { identity field-id-base-type {
description "Field ID with SID"; description "Field ID with SID";
skipping to change at page 4, line 45 skipping to change at page 4, line 46
identity fid-ipv6-trafficclass-ecn { identity fid-ipv6-trafficclass-ecn {
base field-id-base-type; base field-id-base-type;
description "IPv6 Traffic Class field from RFC8200, description "IPv6 Traffic Class field from RFC8200,
ECN field from RFC3168"; ECN field from RFC3168";
} }
... ...
Figure 2: Definition of identityref for field IDs Figure 2: Definition of identityref for field IDs
Figure 2 gives an example of field ID identityref definitions. The Figure 2 gives some examples of field ID identityref definitions.
base identity is field-id-base-type, and field id are derived for it. 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 The naming convention is "fid" followed by the protocol name and the
field name. field name.
The yang model in annex (see Section 7) gives the full definition of The yang model in annex (see Section 7) gives the full definition of
the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc], the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc],
and [I-D.barthel-lpwan-oam-schc]. and [I-D.barthel-lpwan-oam-schc].
The type associated to this identity is field-id-type (cf. Figure 3) The type associated to this identity is field-id-type (cf. Figure 3)
typedef field-id-type { typedef field-id-type {
description "Field ID generic type."; description "Field ID generic type.";
type identityref { type identityref {
base field-id-base-type; base field-id-base-type;
skipping to change at page 13, line 47 skipping to change at page 13, line 47
} }
} }
} }
} }
Figure 13: Definition of a SCHC Context Figure 13: 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 identify 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 14). An entry contains all the information defined in (cf. Figure 14). An entry contains all the information defined in
Figure 1 with the types defined above. Figure 1 with the types defined above.
3.1.1. Compression context representation. 3.1.1. Compression context representation.
The compression rule described Figure 1 is associated to a rule ID. The compression rule described Figure 1 is associated to a rule ID.
skipping to change at page 16, line 23 skipping to change at page 16, line 23
Figure 15: Definition of a compression rule Figure 15: Definition of a compression rule
To identify a specific entry Field ID, position and direction are To identify a specific entry Field ID, position and direction are
needed. needed.
3.2. Fragmentation rule 3.2. Fragmentation rule
Parameters for fragmentation are defined in Annex D of [RFC8724]. Parameters for fragmentation are defined in Annex D of [RFC8724].
Figure 16 gives the first elements found in this structure. It Figure 16 gives the first elements found in this structure. It
starts with a direction. Since fragmentation rules are starts with a direction. Since fragmentation rules work for a
unidirectional, they contain a mandatory direction. The type is the specific direction, they contain a mandatory direction. The type is
same as the one used in compression entries, but the use of the same as the one used in compression entries, but the use of
bidirectionnal is forbidden. bidirectionnal is forbidden.
The next elements describe size of SCHC fragmentation header fields. The next elements describe size of SCHC fragmentation header fields.
Only the FCN size is mandatory and value must be higher or equal to Only the FCN size is mandatory and value must be higher or equal to
1. 1.
grouping fragmentation-content { grouping fragmentation-content {
description "This grouping defines the fragmentation parameters for description "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.";
skipping to change at page 19, line 48 skipping to change at page 19, line 48
Figure 20 gives information related to a specific compression mode: Figure 20 gives information related to a specific compression mode:
fragmentation-mode MUST be set with a specific behavior. Identityref fragmentation-mode MUST be set with a specific behavior. Identityref
are given Figure 21. are given Figure 21.
For Ack on Error some specific information may be provided: For Ack on Error some specific information may be provided:
o tile-size gives in bits the size of the tile; If set to 0 a single o tile-size gives in bits the size of the tile; If set to 0 a single
tile is inserted inside a fragment. tile is inserted inside a fragment.
o tile-in All1 indicates if All1 contains only the RCS (all1-data- o tile-in-All1 indicates if All1 contains only the RCS (all1-data-
no) or may contain a single tile (all1-data-yes). Since the no) or may contain a single tile (all1-data-yes). Since the
reassembly process may detect this behavior, the choice can be reassembly process may detect this behavior, the choice can be
left to the fragmentation process. In that case identityref all1- left to the fragmentation process. In that case identityref all1-
data-sender-choice as to be specified. All possible values are data-sender-choice as to be specified. All possible values are
given Figure 21. given Figure 21.
o ack-behavior tells when the fragmentation process may send o ack-behavior tells when the fragmentation process may send
acknowledgments. When ack-behavior-after-All0 is specified, the acknowledgments. When ack-behavior-after-All0 is specified, the
ack may be sent after the reception of All-0 fragment. When ack- ack may be sent after the reception of All-0 fragment. When ack-
behavior-after-All1 is specified, the ack may be sent after the behavior-after-All1 is specified, the ack may be sent after the
skipping to change at page 41, line 31 skipping to change at page 41, line 31
<code ends> <code ends>
Figure 23 Figure 23
8. Normative References 8. Normative References
[I-D.barthel-lpwan-oam-schc] [I-D.barthel-lpwan-oam-schc]
Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and
J. Zuniga, "OAM for LPWAN using Static Context Header J. Zuniga, "OAM for LPWAN using Static Context Header
Compression (SCHC)", draft-barthel-lpwan-oam-schc-01 (work Compression (SCHC)", draft-barthel-lpwan-oam-schc-02 (work
in progress), March 2020. in progress), November 2020.
[I-D.ietf-lpwan-coap-static-context-hc] [I-D.ietf-lpwan-coap-static-context-hc]
Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
Context Header Compression (SCHC) for CoAP", draft-ietf- Context Header Compression (SCHC) for CoAP", draft-ietf-
lpwan-coap-static-context-hc-15 (work in progress), July lpwan-coap-static-context-hc-18 (work in progress),
2020. January 2021.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header 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,
 End of changes. 15 change blocks. 
27 lines changed or deleted 29 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/