idnits 2.17.1 draft-ietf-lpwan-schc-yang-data-model-05.txt: -(2315): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 88 instances of too long lines in the document, the longest one being 32 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 197: '...odel, each field MUST be identified th...' RFC 2119 keyword, line 201: '...for this protocol MUST derive from the...' RFC 2119 keyword, line 670: '... "All1 MUST contain a tile";...' RFC 2119 keyword, line 1935: '... "All1 MUST contain a tile";...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1193 has weird spacing: '...osition uin...' == Line 1197 has weird spacing: '...osition uin...' == Line 1201 has weird spacing: '...osition uin...' -- The document date (9 September 2021) is 960 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7252' is defined on line 2309, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-barthel-lpwan-oam-schc-02 ** Downref: Normative reference to an Informational draft: draft-barthel-lpwan-oam-schc (ref. 'I-D.barthel-lpwan-oam-schc') == Outdated reference: A later version (-17) exists of draft-ietf-lpwan-schc-compound-ack-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Standards Track L. Toutain 5 Expires: 13 March 2022 Institut MINES TELECOM; IMT Atlantique 6 9 September 2021 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-05 11 Abstract 13 This document describes a YANG data model for the SCHC (Static 14 Context Header Compression) compression and fragmentation rules. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 13 March 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3 52 2.2. Identifier generation . . . . . . . . . . . . . . . . . . 4 53 2.3. Field Identifier . . . . . . . . . . . . . . . . . . . . 5 54 2.4. Field length . . . . . . . . . . . . . . . . . . . . . . 7 55 2.5. Field position . . . . . . . . . . . . . . . . . . . . . 8 56 2.6. Direction Indicator . . . . . . . . . . . . . . . . . . . 8 57 2.7. Target Value . . . . . . . . . . . . . . . . . . . . . . 9 58 2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10 59 2.8.1. Matching Operator arguments . . . . . . . . . . . . . 11 60 2.9. Compression Decompression Actions . . . . . . . . . . . . 11 61 2.9.1. Compression Decompression Action arguments . . . . . 12 62 2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 12 63 2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 12 64 2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 13 65 2.10.3. Last fragment format . . . . . . . . . . . . . . . . 14 66 2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 16 67 2.10.5. Fragmentation Parameters . . . . . . . . . . . . . . 18 68 2.10.6. Layer 2 parameters . . . . . . . . . . . . . . . . . 19 69 3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 19 70 3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 21 71 3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 23 72 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 26 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 28 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 76 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 50 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 80 1. Introduction 82 2. SCHC rules 84 SCHC is a compression and fragmentation mechanism for constrained 85 networks defined in [RFC8724]. It is based on a static context 86 shared by two entities at the boundary this constrained network. 87 Draft [RFC8724] provides a non formal representation of the rules 88 used either for compression/decompression (or C/D) or fragmentation/ 89 reassembly (or F/R). The goal of this document is to formalize the 90 description of the rules to offer: 92 * the same definition on both ends, even if the internal 93 representation is different. 95 * an update the other end to set up some specific values (e.g. IPv6 96 prefix, Destination address,...) 98 * ... 100 This document defines a YANG module to represent both compression and 101 fragmentation rules, which leads to common representation for values 102 for all the rules elements. 104 SCHC compression is generic, the main mechanism does not refer to a 105 specific protocol. Any header field is abstracted through an ID, a 106 position, a direction, and a value that can be a numerical value or a 107 string. [RFC8724] and [RFC8824] specifies fields for IPv6, UDP, CoAP 108 and OSCORE. [I-D.barthel-lpwan-oam-schc] describes ICMPv6 header 109 compression and [I-D.ietf-lpwan-schc-compound-ack] includes a new 110 fragmentation behavior. 112 SCHC fragmentation requires a set of common parameters that are 113 included in a rule. These parameters are defined in [RFC8724]. 115 2.1. Compression Rules 117 [RFC8724] proposes a non formal representation of the compression 118 rule. A compression context for a device is composed of a set of 119 rules. Each rule contains information to describe a specific field 120 in the header to be compressed. 122 +-----------------------------------------------------------------+ 123 | Rule N | 124 +-----------------------------------------------------------------+| 125 | Rule i || 126 +-----------------------------------------------------------------+|| 127 | (FID) Rule 1 ||| 128 |+-------+--+--+--+------------+-----------------+---------------+||| 129 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 130 |+-------+--+--+--+------------+-----------------+---------------+||| 131 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 132 |+-------+--+--+--+------------+-----------------+---------------+||| 133 ||... |..|..|..| ... | ... | ... |||| 134 |+-------+--+--+--+------------+-----------------+---------------+||/ 135 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 136 |+-------+--+--+--+------------+-----------------+---------------+|/ 137 | | 138 \-----------------------------------------------------------------/ 140 Figure 1: Compression Decompression Context 142 2.2. Identifier generation 144 Identifier used un the SCHC YANG Data Model are from the identityref 145 statement to ensure to be globally unique and be easily augmented if 146 needed. The principle to define a new type based on a group of 147 identityref is the following: 149 * define a main identity ending with the keyword base-type. 151 * derive all the identity used in the Data Model from this base 152 type. 154 * create a typedef from this base type. 156 The example (Figure 2) shows how an identityref is created for RCS 157 algorithms used during SCHC fragmentation. 159 // -- RCS algorithm types 161 identity rcs-algorithm-base-type { 162 description 163 "identify which algorithm is used to compute RSC. 164 The algorithm also defines the size if the RSC field."; 165 } 167 identity rcs-RFC8724 { 168 base rcs-algorithm-base-type; 169 description 170 "CRC 32 defined as default RCS in RFC8724."; 171 } 173 typedef rcs-algorithm-type { 174 type identityref { 175 base rcs-algorithm-base-type; 176 } 177 description 178 "type used in rules"; 179 } 181 Figure 2: Principle to define a type based on identityref. 183 2.3. Field Identifier 185 In the process of compression, the headers of the original packet are 186 first parsed to create a list of fields. This list of fields is 187 matched against the rules to find the appropriate one and apply 188 compression. The link between the list given by the parsed fields 189 and the rules is done through a field ID. [RFC8724] do not state how 190 the field ID value can be constructed. In examples, identification 191 is done through a string indexed by the protocol name (e.g. 192 IPv6.version, CoAP.version,...). 194 The current YANG Data Model includes fields definitions found in 195 [RFC8724], [RFC8824], and [I-D.barthel-lpwan-oam-schc]. 197 Using the YANG model, each field MUST be identified through a global 198 YANG identityref. A YANG field ID for the protocol always derives 199 from the fid-base-type. Then an identity for each protocol is 200 specified using the naming convention fid-<>-base- 201 type. All possible fields for this protocol MUST derive from the 202 protocol identity. The naming convention is "fid" followed by the 203 protocol name and the field name. If a field has to be divided into 204 sub-fields, the field identity serves as a base. 206 The full field-id definition is found in Section 7. The example 207 Figure 3 gives the first field ID definitions. A type is defined for 208 IPv6 protocol, and each field is based on it. Note that the DiffServ 209 bits derives from the Traffic Class identity. 211 identity fid-base-type { 212 description 213 "Field ID base type for all fields"; 214 } 216 identity fid-ipv6-base-type { 217 base fid-base-type; 218 description 219 "Field IP base type for IPv6 headers described in RFC 8200"; 220 } 222 identity fid-ipv6-version { 223 base fid-ipv6-base-type; 224 description 225 "IPv6 version field from RFC8200"; 226 } 228 identity fid-ipv6-trafficclass { 229 base fid-ipv6-base-type; 230 description 231 "IPv6 Traffic Class field from RFC8200"; 232 } 234 identity fid-ipv6-trafficclass-ds { 235 base fid-ipv6-trafficclass; 236 description 237 "IPv6 Traffic Class field from RFC8200, 238 DiffServ field from RFC3168"; 239 } 241 ... 243 Figure 3: Definition of identityref for field IDs 245 The type associated to this identity is fid-type (cf. Figure 4) 247 typedef fid-type { 248 type identityref { 249 base fid-base-type; 250 } 251 description 252 "Field ID generic type."; 253 } 255 Figure 4: Type definition for field IDs 257 2.4. Field length 259 Field length is either an integer giving the size of a field in bits 260 or a specific function. [RFC8724] defines the "var" function which 261 allows variable length fields in byte and [RFC8824] defines the "tkl" 262 function for managing the CoAP Token length field. 264 The naming convention is "fl" followed by the function name. 266 identity fl-base-type { 267 description 268 "Used to extend field length functions"; 269 } 271 identity fl-variable { 272 base fl-base-type; 273 description 274 "Residue length in Byte is sent defined in 275 for CoAP in RFC 8824 (cf. 5.3)"; 276 } 278 identity fl-token-length { 279 base fl-base-type; 280 description 281 "Residue length in Byte is sent defined in 282 for CoAP in RFC 8824 (cf. 4.5)"; 283 } 285 Figure 5: Definition of identityref for Field Length 287 As for field ID, field length function can be defined as an 288 identityref as shown in Figure 5. 290 Therefore, the type for field length is a union between an integer 291 giving in bits the size of the length and the identityref (cf. 292 Figure 6). 294 typedef fl-type { 295 type union { 296 type int64; /* positive length in bits */ 297 type identityref { /* function */ 298 base fl-base-type; 299 } 300 } 301 description 302 "Field length either a positive integer giving the size in bits 303 or a function defined through an identityref."; 304 } 305 Figure 6: Type definition for field Length 307 2.5. Field position 309 Field position is a positive integer which gives the position of a 310 field, the default value is 1, but if the field is repeated several 311 times, the value is higher. value 0 indicates that the position is 312 not important and is not considered during the rule selection 313 process. 315 Field position is a positive integer. The type is an uint8. 317 2.6. Direction Indicator 319 The Direction Indicator (di) is used to tell if a field appears in 320 both direction (Bi) or only uplink (Up) or Downlink (Dw). 322 identity di-base-type { 323 description 324 "Used to extend field length functions"; 325 } 327 identity di-bidirectional { 328 base di-base-type; 329 description 330 "Direction Indication of bi directionality in 331 RFC 8724 (cf. 7.1)"; 332 } 334 identity di-up { 335 base di-base-type; 336 description 337 "Direction Indication of upstream defined in 338 RFC 8724 (cf. 7.1)"; 339 } 341 identity di-down { 342 base di-base-type; 343 description 344 "Direction Indication of downstream defined in 345 RFC 8724 (cf. 7.1)"; 346 } 348 Figure 7: Definition of identityref for direction indicators 350 Figure 7 gives the identityref for Direction Indicators. The naming 351 convention is "di" followed by the Direction Indicator name. 353 The type is "direction-indicator-type" (cf. Figure 8). 355 typedef di-type { 356 type identityref { 357 base di-base-type; 358 } 359 description 360 "Direction in LPWAN network, up when emitted by the device, 361 down when received by the device, bi when emitted or received by the device."; 362 } 364 Figure 8: Type definition for direction indicators 366 2.7. Target Value 368 The Target Value is a list of binary sequences of any length, aligned 369 on the left. Figure 9 gives the definition of a single element of a 370 Target Value. In the rule, this will be used as a list, with 371 position as a key. The highest position value is used to compute the 372 size of the index sent in residue for LSB CDA. The position allows 373 to specify several values: 375 * For Equal and LSB, a single value is used, such as for the equal 376 or LSB CDA, the position is set to 0. 378 * For match-mapping, several of these values can be contained in a 379 Target Value field. In the data model, this is generalized by 380 adding a position, which orders the list of values. Position 381 values must start from 0 and be contiguous. 383 grouping tv-struct { 384 description 385 "Define the target value element. Always a binary type, strings 386 must be converted to binary. field-id allows the conversion to the appropriate 387 type."; 388 leaf value { 389 type binary; 390 } 391 leaf position { 392 type uint16; 393 description 394 "If only one element position is 0, otherwise position is the 395 matching list."; 396 } 397 } 399 Figure 9: Definition of target value 401 2.8. Matching Operator 403 Matching Operator (MO) is a function applied between a field value 404 provided by the parsed header and the target value. [RFC8724] 405 defines 4 MO as listed in Figure 10. 407 identity mo-base-type { 408 description 409 "Used to extend Matching Operators with SID values"; 410 } 412 identity mo-equal { 413 base mo-base-type; 414 description 415 "Equal MO as defined RFC 8724 (cf. 7.3)"; 416 } 418 identity mo-ignore { 419 base mo-base-type; 420 description 421 "Ignore MO as defined RFC 8724 (cf. 7.3)"; 422 } 424 identity mo-msb { 425 base mo-base-type; 426 description 427 "MSB MO as defined RFC 8724 (cf. 7.3)"; 428 } 430 identity mo-matching { 431 base mo-base-type; 432 description 433 "match-mapping MO as defined RFC 8724 (cf. 7.3)"; 434 } 436 Figure 10: Definition of identityref for Matching Operator 438 The naming convention is "mo" followed by the MO name. 440 The type is "matching-operator-type" (cf. Figure 11) 442 typedef mo-type { 443 type identityref { 444 base mo-base-type; 445 } 446 description 447 "Matching Operator (MO) to compare fields values with target values"; 448 } 449 Figure 11: Type definition for Matching Operator 451 2.8.1. Matching Operator arguments 453 Some Matching Operator such as MSB can take some values. Even if 454 currently LSB is the only MO takes only one argument, in the future 455 some MO may require several arguments. They are viewed as a list of 456 target-values-type. 458 2.9. Compression Decompression Actions 460 Compression Decompression Action (CDA) identified the function to use 461 either for compression or decompression. [RFC8724] defines 6 CDA. 463 Figure 13 gives some CDA definition, the full definition is in 464 Section 7. 466 identity cda-base-type { 467 description 468 "Compression Decompression Actions"; 469 } 471 identity cda-not-sent { 472 base cda-base-type; 473 description 474 "not-sent CDA as defines in RFC 8724 (cf. 7.4)"; 475 } 477 identity cda-value-sent { 478 base cda-base-type; 479 description 480 "value-sent CDA as defines in RFC 8724 (cf. 7.4)"; 481 } 483 identity cda-lsb { 484 base cda-base-type; 485 description 486 "LSB CDA as defines in RFC 8724 (cf. 7.4)"; 487 } 489 identity cda-mapping-sent { 490 base cda-base-type; 491 description 492 "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)"; 493 } 495 .... 497 Figure 12: Definition of identityref for Compresion Decompression 498 Action 500 The naming convention is "cda" followed by the CDA name. 502 typedef cda-type { 503 type identityref { 504 base cda-base-type; 505 } 506 description 507 "Compression Decompression Action to compression or decompress a field."; 508 } 510 Figure 13: Type definition for Compresion Decompression Action 512 2.9.1. Compression Decompression Action arguments 514 Currently no CDA requires arguments, but the future some CDA may 515 require several arguments. They are viewed as a list of target- 516 values-type. 518 2.10. Fragmentation rule 520 Fragmentation is optional in the data model and depends on the 521 presence of the "fragmentation" feature. 523 Most of parameters for fragmentation are defined in Annex D of 524 [RFC8724]. 526 Since fragmentation rules work for a specific direction, they contain 527 a mandatory direction. The type is the same as the one used in 528 compression entries, but the use of bidirectional is forbidden. 530 2.10.1. Fragmentation mode 532 [RFC8724] defines 3 fragmentation modes: 534 * No Ack: this mode is unidirectionnal, no acknowledgment is sent 535 back. 537 * Ack Always: each fragmentation window must be explicitly 538 acknowledged before going to the next. 540 * Ack on Error: A window is acknowledged only when the receiver 541 detects some missing fragments. 543 Figure 14 give the definition for identifiers from these three modes. 545 identity fragmentation-mode-base-type { 546 description 547 "Fragmentation mode"; 548 } 550 identity fragmentation-mode-no-ack { 551 base fragmentation-mode-base-type; 552 description 553 "No Ack of RFC 8724."; 554 } 556 identity fragmentation-mode-ack-always { 557 base fragmentation-mode-base-type; 558 description 559 "Ack Always of RFC8724."; 560 } 562 identity fragmentation-mode-ack-on-error { 563 base fragmentation-mode-base-type; 564 description 565 "Ack on Error of RFC8724."; 566 } 568 typedef fragmentation-mode-type { 569 type identityref { 570 base fragmentation-mode-base-type; 571 } 572 description 573 "type used in rules"; 574 } 576 Figure 14: Definition of fragmentation mode identifer 578 The naming convention is "fragmentation-mode" followed by the 579 fragmentation mode name. 581 2.10.2. Fragmentation Header 583 A data fragment header, directly following the rule ID can be sent on 584 the fragmentation direction. The direction is mandatory and must be 585 up or down. bidirectional is forbidden. The SCHC header may be 586 composed of (cf. Figure 15): 588 * a Datagram Tag (Dtag) identifying the datagram being fragmented if 589 the fragmentation applies concurrently on several datagrams. This 590 field in optional and its length is defined by the rule. 592 * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack- 593 Always, its size is 1 and depends on the rule in Ack-on-Error. 594 This field is not need in No-Ack mode. 596 * a Fragment Compressed Number (FCN) indicating the fragment/tile 597 position on the window. This field is mandatory on all modes 598 defined in [RFC8724], its size is defined by the rule. 600 |-- SCHC Fragment Header ----| 601 |-- T --|-M-|-- N --| 602 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 603 | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed) 604 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 606 Figure 15: Data fragment header from RFC8724 608 2.10.3. Last fragment format 610 The last fragment of a datagram is sent with an RCS (Reassembly Check 611 Sequence) field to detect residual transmission error and possible 612 losses in the last window. [RFC8724] defines a single algorithm 613 based on Ethernet CRC computation. The identity of the RCS algorithm 614 is shown in Figure 16. 616 // -- RCS algorithm types 618 identity rcs-algorithm-base-type { 619 description 620 "Identify which algorithm is used to compute RSC. 621 The algorithm defines also the size if the RSC field."; 622 } 624 identity rcs-RFC8724 { 625 base rcs-algorithm-base-type; 626 description 627 "CRC 32 defined as default RCS in RFC8724."; 628 } 630 typedef rcs-algorithm-type { 631 type identityref { 632 base rcs-algorithm-base-type; 633 } 634 description 635 "type used in rules"; 636 } 638 Figure 16: type definition for RCS 640 The naming convention is "rcs" followed by the algorithm name. 642 For Ack-on-Error mode, the All-1 fragment may just contain the RCS or 643 can include a tile. The parameters defined in Figure 17 allows to 644 define the behavior: 646 * all1-data-no: the last fragment contains no data, just the RCS 648 * all1-data-yes: the last fragment includes a single tile and the 649 RCS 651 * all1-data-sender-choice: the last fragment may or may not contain 652 a single tile. The receiver can detect if a tile is present. 654 // -- All1 with data types 656 identity all1-data-base-type { 657 description 658 "Type to define when to send an Acknowledgment message"; 659 } 661 identity all1-data-no { 662 base all1-data-base-type; 663 description 664 "All1 contains no tiles."; 665 } 667 identity all1-data-yes { 668 base all1-data-base-type; 669 description 670 "All1 MUST contain a tile"; 671 } 673 identity all1-data-sender-choice { 674 base all1-data-base-type; 675 description 676 "Fragmentation process choose to send tiles or not in all1."; 677 } 679 typedef all1-data-type { 680 type identityref { 681 base all1-data-base-type; 682 } 683 description 684 "Type used in rules"; 685 } 687 Figure 17: type definition for RCS 689 The naming convention is "all1-data" followed by the behavior 690 identifier. 692 2.10.4. Acknowledgment behavior 694 A cknowledgment fragment header goes in the opposite direction of 695 data. The header is composed of (see Figure 18): 697 * a Dtag (if present). 699 * a mandatory window as in the data fragment. 701 * a C bit giving the status of RCS validation. In case of failure, 702 a bitmap follows, indicating received fragment/tile. The size of 703 the bitmap is given by the FCN value. 705 NOTE: IN THE DATA MODEL THERE IS A max-window-size FIELD TO LIMIT THE 706 BITMAP SIZE, BUT IS NO MORE IN RFC8724! DO WE KEEP IT? 708 |--- SCHC ACK Header ----| 709 |-- T --|-M-| 1 | 710 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 711 | RuleID | DTag | W |C=1| padding as needed (success) 712 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 714 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 715 | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 716 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 718 Figure 18: Acknowledgment fragment header for RFC8724 720 For Ack-on-Error, SCHC defined when acknowledgment can be sent. This 721 can be at any time defined by the layer 2, at the end of a window 722 (FCN All-0) or at the end of the fragment (FCN All-1). The following 723 identifiers (cf. Figure 19) define the acknowledgment behavior. 725 // -- Ack behavior 727 identity ack-behavior-base-type { 728 description 729 "Define when to send an Acknowledgment message"; 730 } 732 identity ack-behavior-after-All0 { 733 base ack-behavior-base-type; 734 description 735 "Fragmentation expects Ack after sending All0 fragment."; 736 } 738 identity ack-behavior-after-All1 { 739 base ack-behavior-base-type; 740 description 741 "Fragmentation expects Ack after sending All1 fragment."; 742 } 744 identity ack-behavior-always { 745 base ack-behavior-base-type; 746 description 747 "Fragmentation expects Ack after sending every fragment."; 748 } 750 typedef ack-behavior-type { 751 type identityref { 752 base ack-behavior-base-type; 753 } 754 description 755 "Type used in rules"; 756 } 758 Figure 19: bitmap generation behavior 760 The naming convention is "ack-behavior" followed by the algorithm 761 name. 763 For Ack-onError, [RFC8724] allows a single bitmap in an acknowledment 764 fragment, and [I-D.ietf-lpwan-schc-compound-ack] proposes to 765 acknowledge several windows on a single ack fragment. The following 766 identifiers (cf. Figure 20) define the behavior. 768 identity bitmap-format-base-type { 769 description 770 "Define how the bitmap is defined in ACK messages."; 771 } 773 identity bitmap-RFC8724 { 774 base bitmap-format-base-type; 775 description 776 "Bitmap as defined in RFC8724."; 777 } 779 identity bitmap-compound-ack { 780 base bitmap-format-base-type; 781 description 782 "Compound Ack."; 783 } 785 typedef bitmap-format-type { 786 type identityref { 787 base bitmap-format-base-type; 788 } 789 description 790 "type used in rules"; 791 } 793 Figure 20: bitmap generation behavior 795 The naming convention is "bitmap" followed by the algorithm name. 797 2.10.5. Fragmentation Parameters 799 The state machine requires some common values to handle 800 fragmentation: 802 * retransmission-timer gives in seconds the duration before sending 803 an ack request (cf. section 8.2.2.4. of [RFC8724]). If specified, 804 value must be higher or equal to 1. 806 * inactivity-timer gives in seconds the duration before aborting 807 (cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly 808 indicates that this timer is disabled. 810 * max-ack-requests gives the number of attempts before aborting (cf. 811 section 8.2.2.4. of [RFC8724]). 813 * maximum-packet-size gives in bytes the larger packet size that can 814 be reassembled. 816 The are defined as unsigned integer, see Section 7. 818 2.10.6. Layer 2 parameters 820 The data model includes two parameters needed for fragmentation: 822 * l2-word-size: [RFC8724] base fragmentation on a layer 2 word which 823 can be of any length. The default value is 8 and correspond to 824 the default value for byte aligned layer 2. A value of 1 will 825 indicate that there is no alignment and no need for padding. 827 * maximum-packet-size: defines the maximum size of a uncompressed 828 datagram. By default, the value is set to 1280 bytes. 830 They are defined as unsigned integer, see Section 7. 832 3. Rule definition 834 A rule is either a C/D or an F/R rule. A rule is identified by the 835 rule ID value and its associated length. The YANG grouping rule-id- 836 type defines the structure used to represent a rule ID. Length of 0 837 is allowed to represent an implicit rule. 839 Three types of rules are defined in [RFC8724]: 841 * Compression: a compression rule is associated to the rule ID. 843 * No compression: nothing is associated to the rule ID. 845 * Fragmentation: fragmentation parameters are associated to the rule 846 ID. Fragmentation is optional and feature "fragmentation" should 847 be set. 849 grouping rule-id-type { 850 leaf rule-id-value { 851 type uint32; 852 description 853 "Rule ID value, this value must be unique combined with the length"; 854 } 855 leaf rule-id-length { 856 type uint8 { 857 range "0..32"; 858 } 859 description 860 "Rule ID length in bits, value 0 is for implicit rules"; 861 } 862 description 863 "A rule ID is composed of a value and a length in bit"; 864 } 866 // SCHC table for a specific device. 868 container schc { 869 list rule { 870 key "rule-id-value rule-id-length"; 871 uses rule-id-type; 872 choice nature { 873 case fragmentation { 874 if-feature "fragmentation"; 875 uses fragmentation-content; 876 } 877 case compression { 878 uses compression-content; 879 } 880 case no-compression { 881 description 882 "RFC8724 allows a rule for uncompressed headers"; 883 } 884 description 885 "A rule is either for compression, no compression or fragmentation"; 886 } 887 description 888 "Set of rules compression, no compression or fragmentation rules 889 identified by their rule-id "; 890 } 891 description 892 "a SCHC set of rules is composed of a list of rule which are either 893 compression or fragmentation"; 894 } 895 } 896 Figure 21: Definition of a SCHC Context 898 To access to a specific rule, rule-id and its specific length is used 899 as a key. The rule is either a compression or a fragmentation rule. 901 Each context can be identified though a version id. 903 3.1. Compression rule 905 A compression rule is composed of entries describing its processing 906 (cf. Figure 22). An entry contains all the information defined in 907 Figure 1 with the types defined above. 909 The compression rule described Figure 1 is defined by compression- 910 content. It defines a list of compression-rule-entry, indexed by 911 their field id, position and direction. The compression-rule-entry 912 element represent a line of the table Figure 1. Their type reflects 913 the identifier types defined in Section 2.1 915 Some controls are made on the values: 917 * target value must be present for MO different from ignore. 919 * when MSB MO is specified, the matching-operator-value must be 920 present 922 grouping compression-rule-entry { 923 description 924 "These entries defines a compression entry (i.e. a line) 925 as defined in RFC 8724 and fragmentation parameters. 927 +-------+--+--+--+------------+-----------------+---------------+ 928 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 929 +-------+--+--+--+------------+-----------------+---------------+ 931 An entry in a compression rule is composed of 7 elements: 932 - Field ID: The header field to be compressed. The content is a YANG identifer. 933 - Field Length : either a positive integer of a function defined as a YANF id. 934 - Field Position: a positive (and possibly equal to 0) integer. 935 - Direction Indicator: a YANG identifier giving the direction. 936 - Target value: a value against which the header Field is compared. 937 - Matching Operator: a YANG id giving the operation, paramters may be 938 associated to that operator. 939 - Comp./Decomp. Action: A YANG id giving the compression or decompression 940 action, paramters may be associated to that action. 941 "; 942 leaf field-id { 943 type schc:fid-type; 944 mandatory true; 945 description 946 "Field ID, identify a field in the header with a YANG refenceid."; 947 } 948 leaf field-length { 949 type schc:fl-type; 950 mandatory true; 951 description 952 "Field Length in bit or through a function defined as a YANG referenceid"; 953 } 954 leaf field-position { 955 type uint8; 956 mandatory true; 957 description 958 "Field position in the header is a integer. If the field is not repeated 959 in the header the value is 1, and incremented for each repetition of the field. Position 960 0 means that the position is not important and order may change when decompressed"; 961 } 962 leaf direction-indicator { 963 type schc:di-type; 964 mandatory true; 965 description 966 "Direction Indicator, a YANG referenceid to say if the packet is bidirectional, 967 up or down"; 968 } 969 list target-value { 970 key "position"; 971 uses tv-struct; 972 description 973 "A list of value to compare with the header field value. If target value 974 is a singleton, position must be 0. For matching-list, should be consecutive position 975 values starting from 1."; 976 } 977 leaf matching-operator { 978 type schc:mo-type; 979 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 980 error-message "mo-equal, mo-msb and mo-match-mapping require target-value"; 981 description 982 "target-value is not required for mo-ignore"; 983 } 984 must "not (derived-from-or-self(., 'mo-msb')) or ../matching-operator-value" { 985 error-message "mo-msb requires length value"; 986 } 987 mandatory true; 988 description 989 "MO: Matching Operator"; 990 } 991 list matching-operator-value { 992 key "position"; 993 uses tv-struct; 994 description 995 "Matching Operator Arguments, based on TV structure to allow several arguments. 996 In RFC 8724, only MSB define a single argument: length in bits "; 997 } 998 leaf comp-decomp-action { 999 type schc:cda-type; 1000 mandatory true; 1001 description 1002 "CDA: Compression Decompression Action"; 1003 } 1004 list comp-decomp-action-value { 1005 key "position"; 1006 uses tv-struct; 1007 description 1008 "CDA Arguments, based on TV structure to allow several arguments. 1009 In RFC 8724, no argument is defined for CDA"; 1010 } 1011 } 1013 grouping compression-content { 1014 list entry { 1015 key "field-id field-position direction-indicator"; 1016 uses compression-rule-entry; 1017 description 1018 "A compression rule is a list of rule entry describing 1019 each header field. An entry is identifed through a field-id, its position 1020 in the packet and its direction"; 1021 } 1022 description 1023 "Define a compression rule composed of a list of entries."; 1024 } 1026 Figure 22: Definition of a compression entry 1028 3.2. Fragmentation rule 1030 A Fragmentation rule is composed of entries describing the protocol 1031 behavior. Some on them are numerical entries, others are identifiers 1032 defined in Section 2.10. 1034 The data model defines some relations between the entries: 1036 * direction must be either up or down (not bidirectional). 1038 * W size is only needed for Ack Always and Ack on Error modes. 1040 grouping fragmentation-content { 1041 description 1042 "This grouping defines the fragmentation parameters for 1043 all the modes (No Ack, Ack Always and Ack on Error) specified in 1044 RFC 8724."; 1045 leaf l2-word-size { 1046 type uint8; 1047 default "8"; 1048 description 1049 "Size in bit of the layer 2 word"; 1050 } 1051 leaf direction { 1052 must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" { 1053 error-message "direction for fragmentation rules is up or down"; 1054 } 1055 type schc:direction-indicator-type; 1056 mandatory true; 1057 description 1058 "Should be up or down, bi directionnal is forbiden."; 1059 } 1060 leaf dtag-size { 1061 type uint8; 1062 default "0"; 1063 description 1064 "Size in bit of the DTag field"; 1065 } 1066 leaf w-size { 1067 when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))"; 1068 type uint8; 1069 description 1070 "Size in bit of the window field"; 1071 } 1072 leaf fcn-size { 1073 type uint8; 1074 mandatory true; 1075 description 1076 "Size in bit of the FCN field"; 1077 } 1078 leaf rcs-algorithm { 1079 type rcs-algorithm-type; 1080 default "schc:rcs-RFC8724"; 1081 description 1082 "Algorithm used for RCS"; 1083 } 1084 leaf maximum-window-size { 1085 type uint16; 1086 description 1087 "By default 2^wsize - 1"; 1089 } 1090 leaf retransmission-timer { 1091 type uint64 { 1092 range "1..max"; 1093 } 1094 description 1095 "Duration in seconds of the retransmission timer"; // Check the units 1096 } 1097 leaf inactivity-timer { 1098 type uint64; 1099 description 1100 "Duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units 1101 } 1102 leaf max-ack-requests { 1103 type uint8 { 1104 range "1..max"; 1105 } 1106 description 1107 "The maximum number of retries for a specific SCHC ACK."; 1108 } 1109 leaf maximum-packet-size { 1110 type uint16; 1111 default "1280"; 1112 description 1113 "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 1114 } 1115 leaf fragmentation-mode { 1116 type schc:fragmentation-mode-type; 1117 mandatory true; 1118 description 1119 "Which fragmentation mode is used (noAck, AckAlways, AckonError)"; 1120 } 1121 choice mode { 1122 case no-ack; 1123 case ack-always; 1124 case ack-on-error { 1125 leaf tile-size { 1126 type uint8; 1127 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 1128 description 1129 "Size in bit of tiles, if not specified or set to 0: tile fills the fragment."; 1130 } 1131 leaf tile-in-All1 { 1132 type schc:all1-data-type; 1133 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 1134 description 1135 "When true, sender and receiver except a tile in All-1 frag"; 1136 } 1137 leaf ack-behavior { 1138 type schc:ack-behavior-type; 1139 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 1140 description 1141 "Sender behavior to acknowledge, after All-0, All-1 or when the 1142 LPWAN allows it (Always)"; 1143 } 1144 leaf bitmap-format { 1145 type schc:bitmap-format-type; 1146 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 1147 default "schc:bitmap-RFC8724"; 1148 description 1149 "How the bitmaps are included in the Ack message."; 1150 } 1151 } 1152 description 1153 "RFC 8724 defines 3 fragmentation modes"; 1154 } 1155 } 1157 3.3. YANG Tree 1158 module: ietf-schc 1159 +--rw schc 1160 +--rw rule* [rule-id-value rule-id-length] 1161 +--rw rule-id-value uint32 1162 +--rw rule-id-length uint8 1163 +--rw (nature)? 1164 +--:(fragmentation) {fragmentation}? 1165 | +--rw l2-word-size? uint8 1166 | +--rw direction schc:di-type 1167 | +--rw dtag-size? uint8 1168 | +--rw w-size? uint8 1169 | +--rw fcn-size uint8 1170 | +--rw rcs-algorithm? rcs-algorithm-type 1171 | +--rw maximum-window-size? uint16 1172 | +--rw retransmission-timer? uint64 1173 | +--rw inactivity-timer? uint64 1174 | +--rw max-ack-requests? uint8 1175 | +--rw maximum-packet-size? uint16 1176 | +--rw fragmentation-mode schc:fragmentation-mode-type 1177 | +--rw (mode)? 1178 | +--:(no-ack) 1179 | +--:(ack-always) 1180 | +--:(ack-on-error) 1181 | +--rw tile-size? uint8 1182 | +--rw tile-in-All1? schc:all1-data-type 1183 | +--rw ack-behavior? schc:ack-behavior-type 1184 | +--rw bitmap-format? schc:bitmap-format-type 1185 +--:(compression) 1186 | +--rw entry* [field-id field-position direction-indicator] 1187 | +--rw field-id schc:fid-type 1188 | +--rw field-length schc:fl-type 1189 | +--rw field-position uint8 1190 | +--rw direction-indicator schc:di-type 1191 | +--rw target-value* [position] 1192 | | +--rw value? binary 1193 | | +--rw position uint16 1194 | +--rw matching-operator schc:mo-type 1195 | +--rw matching-operator-value* [position] 1196 | | +--rw value? binary 1197 | | +--rw position uint16 1198 | +--rw comp-decomp-action schc:cda-type 1199 | +--rw comp-decomp-action-value* [position] 1200 | +--rw value? binary 1201 | +--rw position uint16 1202 +--:(no-compression) 1204 Figure 23 1206 4. IANA Considerations 1208 This document has no request to IANA. 1210 5. Security considerations 1212 This document does not have any more Security consideration than the 1213 ones already raised on [RFC8724] 1215 6. Acknowledgements 1217 The authors would like to thank Dominique Barthel, Carsten Bormann, 1218 Alexander Pelov. 1220 7. YANG Module 1222 file ietf-schc@2021-08-17.yang 1223 module ietf-schc { 1224 yang-version 1.1; 1225 namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; 1226 prefix schc; 1228 organization 1229 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; 1230 contact 1231 "WG Web: 1232 WG List: 1233 Editor: Laurent Toutain 1234 1235 Editor: Ana Minaburo 1236 "; 1237 description 1238 " 1239 Copyright (c) 2021 IETF Trust and the persons identified as 1240 authors of the code. All rights reserved. 1242 Redistribution and use in source and binary forms, with or 1243 without modification, is permitted pursuant to, and subject to 1244 the license terms contained in, the Simplified BSD License set 1245 forth in Section 4.c of the IETF Trust's Legal Provisions 1246 Relating to IETF Documents 1247 (https://trustee.ietf.org/license-info). 1249 This version of this YANG module is part of RFC XXXX 1250 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1251 for full legal notices. 1253 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1254 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1255 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1256 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1257 they appear in all capitals, as shown here. 1259 ************************************************************************* 1261 Generic Data model for Static Context Header Compression Rule for SCHC, 1262 based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression 1263 rules and fragmentation rules. 1265 This module is a YANG model for SCHC rules (RFc 8724). 1266 RFC 8724 describes a rule in a abstract way through a table. 1268 |-----------------------------------------------------------------| 1269 | (FID) Rule 1 | 1270 |+-------+--+--+--+------------+-----------------+---------------+| 1271 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1272 |+-------+--+--+--+------------+-----------------+---------------+| 1273 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1274 |+-------+--+--+--+------------+-----------------+---------------+| 1275 ||... |..|..|..| ... | ... | ... || 1276 |+-------+--+--+--+------------+-----------------+---------------+| 1277 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1278 +-------+--+--+--+------------+-----------------+---------------+|| 1279 |-----------------------------------------------------------------| 1281 This module proposes a global data model that can be used for rule 1282 exchanges or modification. It proposes both the data model format and 1283 the global identifiers used to describes some operations in fields. 1284 This data model applies both to compression and fragmentation."; 1286 revision 2021-08-17 { 1287 description 1288 "Initial version from RFC XXXX "; 1289 reference 1290 "RFC XXX: Data Model for Static Context Header Compression (SCHC)"; 1291 } 1293 feature fragmentation { 1294 description 1295 "Fragmentation is usually required only at the transportation level."; 1296 } 1298 // ------------------------- 1299 // Field ID type definition 1300 //-------------------------- 1301 // generic value TV definition 1302 identity fid-base-type { 1303 description 1304 "Field ID base type for all fields"; 1305 } 1307 identity fid-ipv6-base-type { 1308 base fid-base-type; 1309 description 1310 "Field IP base type for IPv6 headers described in RFC 8200"; 1311 } 1313 identity fid-ipv6-version { 1314 base fid-ipv6-base-type; 1315 description 1316 "IPv6 version field from RFC8200"; 1317 } 1319 identity fid-ipv6-trafficclass { 1320 base fid-ipv6-base-type; 1321 description 1322 "IPv6 Traffic Class field from RFC8200"; 1323 } 1325 identity fid-ipv6-trafficclass-ds { 1326 base fid-ipv6-trafficclass; 1327 description 1328 "IPv6 Traffic Class field from RFC8200, 1329 DiffServ field from RFC3168"; 1330 } 1332 identity fid-ipv6-trafficclass-ecn { 1333 base fid-ipv6-trafficclass; 1334 description 1335 "IPv6 Traffic Class field from RFC8200, 1336 ECN field from RFC3168"; 1337 } 1339 identity fid-ipv6-flowlabel { 1340 base fid-ipv6-base-type; 1341 description 1342 "IPv6 Flow Label field from RFC8200"; 1343 } 1345 identity fid-ipv6-payloadlength { 1346 base fid-ipv6-base-type; 1347 description 1348 "IPv6 Payload Length field from RFC8200"; 1349 } 1350 identity fid-ipv6-nextheader { 1351 base fid-ipv6-base-type; 1352 description 1353 "IPv6 Next Header field from RFC8200"; 1354 } 1356 identity fid-ipv6-hoplimit { 1357 base fid-ipv6-base-type; 1358 description 1359 "IPv6 Next Header field from RFC8200"; 1360 } 1362 identity fid-ipv6-devprefix { 1363 base fid-ipv6-base-type; 1364 description 1365 "correspond either to the source address or the desdination 1366 address prefix of RFC 8200. Depending if it is respectively 1367 a uplink or an downklink message."; 1368 } 1370 identity fid-ipv6-deviid { 1371 base fid-ipv6-base-type; 1372 description 1373 "correspond either to the source address or the desdination 1374 address prefix of RFC 8200. Depending if it is respectively 1375 a uplink or an downklink message."; 1376 } 1378 identity fid-ipv6-appprefix { 1379 base fid-ipv6-base-type; 1380 description 1381 "correspond either to the source address or the desdination 1382 address prefix of RFC 768. Depending if it is respectively 1383 a downlink or an uplink message."; 1384 } 1386 identity fid-ipv6-appiid { 1387 base fid-ipv6-base-type; 1388 description 1389 "correspond either to the source address or the desdination 1390 address prefix of RFC 768. Depending if it is respectively 1391 a downlink or an uplink message."; 1392 } 1394 identity fid-udp-base-type { 1395 base fid-base-type; 1396 description 1397 "Field IP base type for UDP headers described in RFC 768"; 1399 } 1401 identity fid-udp-dev-port { 1402 base fid-udp-base-type; 1403 description 1404 "UDP length from RFC 768"; 1405 } 1407 identity fid-udp-app-port { 1408 base fid-udp-base-type; 1409 description 1410 "UDP length from RFC 768"; 1411 } 1413 identity fid-udp-length { 1414 base fid-udp-base-type; 1415 description 1416 "UDP length from RFC 768"; 1417 } 1419 identity fid-udp-checksum { 1420 base fid-udp-base-type; 1421 description 1422 "UDP length from RFC 768"; 1423 } 1425 identity fid-coap-base-type { 1426 base fid-base-type; 1427 description 1428 "Field IP base type for UDP headers described in RFC 768"; 1429 } 1431 identity fid-coap-version { 1432 base fid-coap-base-type; 1433 description 1434 "CoAP version from RFC 7252"; 1435 } 1437 identity fid-coap-type { 1438 base fid-coap-base-type; 1439 description 1440 "CoAP type from RFC 7252"; 1441 } 1443 identity fid-coap-tkl { 1444 base fid-coap-base-type; 1445 description 1446 "CoAP token length from RFC 7252"; 1448 } 1450 identity fid-coap-code { 1451 base fid-coap-base-type; 1452 description 1453 "CoAP code from RFC 7252"; 1454 } 1456 identity fid-coap-code-class { 1457 base fid-coap-code; 1458 description 1459 "CoAP code class from RFC 7252"; 1460 } 1462 identity fid-coap-code-detail { 1463 base fid-coap-code; 1464 description 1465 "CoAP code detail from RFC 7252"; 1466 } 1468 identity fid-coap-mid { 1469 base fid-coap-base-type; 1470 description 1471 "CoAP message ID from RFC 7252"; 1472 } 1474 identity fid-coap-token { 1475 base fid-coap-base-type; 1476 description 1477 "CoAP token from RFC 7252"; 1478 } 1480 identity fid-coap-option-if-match { 1481 base fid-coap-base-type; 1482 description 1483 "CoAP option If-Match from RFC 7252"; 1484 } 1486 identity fid-coap-option-uri-host { 1487 base fid-coap-base-type; 1488 description 1489 "CoAP option URI-Host from RFC 7252"; 1490 } 1492 identity fid-coap-option-etag { 1493 base fid-coap-base-type; 1494 description 1495 "CoAP option Etag from RFC 7252"; 1497 } 1499 identity fid-coap-option-if-none-match { 1500 base fid-coap-base-type; 1501 description 1502 "CoAP option if-none-match from RFC 7252"; 1503 } 1505 identity fid-coap-option-observe { 1506 base fid-coap-base-type; 1507 description 1508 "CoAP option Observe from RFC 7641"; 1509 } 1511 identity fid-coap-option-uri-port { 1512 base fid-coap-base-type; 1513 description 1514 "CoAP option Uri-Port from RFC 7252"; 1515 } 1517 identity fid-coap-option-location-path { 1518 base fid-coap-base-type; 1519 description 1520 "CoAP option Location-Path from RFC 7252"; 1521 } 1523 identity fid-coap-option-uri-path { 1524 base fid-coap-base-type; 1525 description 1526 "CoAP option Uri-Path from RFC 7252"; 1527 } 1529 identity fid-coap-option-content-format { 1530 base fid-coap-base-type; 1531 description 1532 "CoAP option Content Format from RFC 7252"; 1533 } 1535 identity fid-coap-option-max-age { 1536 base fid-coap-base-type; 1537 description 1538 "CoAP option Max-Age from RFC 7252"; 1539 } 1541 identity fid-coap-option-uri-query { 1542 base fid-coap-base-type; 1543 description 1544 "CoAP option Uri-Query from RFC 7252"; 1546 } 1548 identity fid-coap-option-accept { 1549 base fid-coap-base-type; 1550 description 1551 "CoAP option Max-Age from RFC 7252"; 1552 } 1554 identity fid-coap-option-location-query { 1555 base fid-coap-base-type; 1556 description 1557 "CoAP option Location-Query from RFC 7252"; 1558 } 1560 identity fid-coap-option-block2 { 1561 base fid-coap-base-type; 1562 description 1563 "CoAP option Block2 from RFC 7959"; 1564 } 1566 identity fid-coap-option-block1 { 1567 base fid-coap-base-type; 1568 description 1569 "CoAP option Block1 from RFC 7959"; 1570 } 1572 identity fid-coap-option-size2 { 1573 base fid-coap-base-type; 1574 description 1575 "CoAP option size2 from RFC 7959"; 1576 } 1578 identity fid-coap-option-proxy-uri { 1579 base fid-coap-base-type; 1580 description 1581 "CoAP option Proxy-Uri from RFC 7252"; 1582 } 1584 identity fid-coap-option-proxy-scheme { 1585 base fid-coap-base-type; 1586 description 1587 "CoAP option Proxy-scheme from RFC 7252"; 1588 } 1590 identity fid-coap-option-size1 { 1591 base fid-coap-base-type; 1592 description 1593 "CoAP option Size1 from RFC 7252"; 1595 } 1597 identity fid-coap-option-no-response { 1598 base fid-coap-base-type; 1599 description 1600 "CoAP option No response from RFC 7967"; 1601 } 1603 identity fid-coap-option-oscore-flags { 1604 base fid-coap-base-type; 1605 description 1606 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1607 } 1609 identity fid-coap-option-oscore-piv { 1610 base fid-coap-base-type; 1611 description 1612 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1613 } 1615 identity fid-coap-option-oscore-kid { 1616 base fid-coap-base-type; 1617 description 1618 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1619 } 1621 identity fid-coap-option-oscore-kidctx { 1622 base fid-coap-base-type; 1623 description 1624 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1625 } 1627 identity fid-icmpv6-base-type { 1628 base fid-base-type; 1629 description 1630 "Field IP base type for UDP headers described in RFC 768"; 1631 } 1633 identity fid-icmpv6-type { 1634 base fid-icmpv6-base-type; 1635 description 1636 "ICMPv6 field (see draft OAM)"; 1637 } 1639 identity fid-icmpv6-code { 1640 base fid-icmpv6-base-type; 1641 description 1642 "ICMPv6 field (see draft OAM)"; 1644 } 1646 identity fid-icmpv6-checksum { 1647 base fid-icmpv6-base-type; 1648 description 1649 "ICMPv6 field (see draft OAM)"; 1650 } 1652 identity fid-icmpv6-identifier { 1653 base fid-icmpv6-base-type; 1654 description 1655 "ICMPv6 field (see draft OAM)"; 1656 } 1658 identity fid-icmpv6-sequence { 1659 base fid-icmpv6-base-type; 1660 description 1661 "ICMPv6 field (see draft OAM)"; 1662 } 1664 //---------------------------------- 1665 // Field Length type definition 1666 //---------------------------------- 1668 identity fl-base-type { 1669 description 1670 "Used to extend field length functions"; 1671 } 1673 identity fl-variable { 1674 base fl-base-type; 1675 description 1676 "Residue length in Byte is sent defined in 1677 for CoAP in RFC 8824 (cf. 5.3)"; 1678 } 1680 identity fl-token-length { 1681 base fl-base-type; 1682 description 1683 "Residue length in Byte is sent defined in 1684 for CoAP in RFC 8824 (cf. 4.5)"; 1685 } 1687 //--------------------------------- 1688 // Direction Indicator type 1689 //--------------------------------- 1691 identity di-base-type { 1692 description 1693 "Used to extend field length functions"; 1694 } 1696 identity di-bidirectional { 1697 base di-base-type; 1698 description 1699 "Direction Indication of bi directionality in 1700 RFC 8724 (cf. 7.1)"; 1701 } 1703 identity di-up { 1704 base di-base-type; 1705 description 1706 "Direction Indication of upstream defined in 1707 RFC 8724 (cf. 7.1)"; 1708 } 1710 identity di-down { 1711 base di-base-type; 1712 description 1713 "Direction Indication of downstream defined in 1714 RFC 8724 (cf. 7.1)"; 1715 } 1717 //---------------------------------- 1718 // Matching Operator type definition 1719 //---------------------------------- 1721 identity mo-base-type { 1722 description 1723 "Used to extend Matching Operators with SID values"; 1724 } 1726 identity mo-equal { 1727 base mo-base-type; 1728 description 1729 "Equal MO as defined RFC 8724 (cf. 7.3)"; 1730 } 1732 identity mo-ignore { 1733 base mo-base-type; 1734 description 1735 "Ignore MO as defined RFC 8724 (cf. 7.3)"; 1736 } 1738 identity mo-msb { 1739 base mo-base-type; 1740 description 1741 "MSB MO as defined RFC 8724 (cf. 7.3)"; 1742 } 1744 identity mo-matching { 1745 base mo-base-type; 1746 description 1747 "match-mapping MO as defined RFC 8724 (cf. 7.3)"; 1748 } 1750 //------------------------------ 1751 // CDA type definition 1752 //------------------------------ 1754 identity cda-base-type { 1755 description 1756 "Compression Decompression Actions"; 1757 } 1759 identity cda-not-sent { 1760 base cda-base-type; 1761 description 1762 "not-sent CDA as defines in RFC 8724 (cf. 7.4)"; 1763 } 1765 identity cda-value-sent { 1766 base cda-base-type; 1767 description 1768 "value-sent CDA as defines in RFC 8724 (cf. 7.4)"; 1769 } 1771 identity cda-lsb { 1772 base cda-base-type; 1773 description 1774 "LSB CDA as defines in RFC 8724 (cf. 7.4)"; 1775 } 1777 identity cda-mapping-sent { 1778 base cda-base-type; 1779 description 1780 "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)"; 1781 } 1783 identity cda-compute-length { 1784 base cda-base-type; 1785 description 1786 "compute-length CDA as defines in RFC 8724 (cf. 7.4)"; 1787 } 1788 identity cda-compute-checksum { 1789 base cda-base-type; 1790 description 1791 "compute-checksum CDA as defines in RFC 8724 (cf. 7.4)"; 1792 } 1794 identity cda-deviid { 1795 base cda-base-type; 1796 description 1797 "deviid CDA as defines in RFC 8724 (cf. 7.4)"; 1798 } 1800 identity cda-appiid { 1801 base cda-base-type; 1802 description 1803 "appiid CDA as defines in RFC 8724 (cf. 7.4)"; 1804 } 1806 // -- type definition 1808 typedef fid-type { 1809 type identityref { 1810 base fid-base-type; 1811 } 1812 description 1813 "Field ID generic type."; 1814 } 1816 typedef fl-type { 1817 type union { 1818 type int64; /* positive length in bits */ 1819 type identityref { /* function */ 1820 base fl-base-type; 1821 } 1822 } 1823 description 1824 "Field length either a positive integer giving the size in bits 1825 or a function defined through an identityref."; 1826 } 1828 typedef di-type { 1829 type identityref { 1830 base di-base-type; 1831 } 1832 description 1833 "Direction in LPWAN network, up when emitted by the device, 1834 down when received by the device, bi when emitted or received by the device."; 1835 } 1836 typedef mo-type { 1837 type identityref { 1838 base mo-base-type; 1839 } 1840 description 1841 "Matching Operator (MO) to compare fields values with target values"; 1842 } 1844 typedef cda-type { 1845 type identityref { 1846 base cda-base-type; 1847 } 1848 description 1849 "Compression Decompression Action to compression or decompress a field."; 1850 } 1852 // -- FRAGMENTATION TYPE 1853 // -- fragmentation modes 1855 identity fragmentation-mode-base-type { 1856 description 1857 "fragmentation mode"; 1858 } 1860 identity fragmentation-mode-no-ack { 1861 base fragmentation-mode-base-type; 1862 description 1863 "No Ack of RFC 8724."; 1864 } 1866 identity fragmentation-mode-ack-always { 1867 base fragmentation-mode-base-type; 1868 description 1869 "Ack Always of RFC8724."; 1870 } 1872 identity fragmentation-mode-ack-on-error { 1873 base fragmentation-mode-base-type; 1874 description 1875 "Ack on Error of RFC8724."; 1876 } 1878 typedef fragmentation-mode-type { 1879 type identityref { 1880 base fragmentation-mode-base-type; 1881 } 1882 description 1883 "type used in rules"; 1885 } 1887 // -- Ack behavior 1889 identity ack-behavior-base-type { 1890 description 1891 "Define when to send an Acknowledgment message"; 1892 } 1894 identity ack-behavior-after-All0 { 1895 base ack-behavior-base-type; 1896 description 1897 "Fragmentation expects Ack after sending All0 fragment."; 1898 } 1900 identity ack-behavior-after-All1 { 1901 base ack-behavior-base-type; 1902 description 1903 "Fragmentation expects Ack after sending All1 fragment."; 1904 } 1906 identity ack-behavior-always { 1907 base ack-behavior-base-type; 1908 description 1909 "Fragmentation expects Ack after sending every fragment."; 1910 } 1912 typedef ack-behavior-type { 1913 type identityref { 1914 base ack-behavior-base-type; 1915 } 1916 description 1917 "Type used in rules"; 1918 } 1920 // -- All1 with data types 1922 identity all1-data-base-type { 1923 description 1924 "Type to define when to send an Acknowledgment message"; 1925 } 1927 identity all1-data-no { 1928 base all1-data-base-type; 1929 description 1930 "All1 contains no tiles."; 1931 } 1932 identity all1-data-yes { 1933 base all1-data-base-type; 1934 description 1935 "All1 MUST contain a tile"; 1936 } 1938 identity all1-data-sender-choice { 1939 base all1-data-base-type; 1940 description 1941 "Fragmentation process choose to send tiles or not in all1."; 1942 } 1944 typedef all1-data-type { 1945 type identityref { 1946 base all1-data-base-type; 1947 } 1948 description 1949 "Type used in rules"; 1950 } 1952 // -- RCS algorithm types 1954 identity rcs-algorithm-base-type { 1955 description 1956 "Identify which algorithm is used to compute RSC. 1957 The algorithm also defines the size if the RSC field."; 1958 } 1960 identity rcs-RFC8724 { 1961 base rcs-algorithm-base-type; 1962 description 1963 "CRC 32 defined as default RCS in RFC8724."; 1964 } 1966 typedef rcs-algorithm-type { 1967 type identityref { 1968 base rcs-algorithm-base-type; 1969 } 1970 description 1971 "type used in rules"; 1972 } 1974 // --- Bitmap format 1976 identity bitmap-format-base-type { 1977 description 1978 "Define how the bitmap is defined in ACK messages."; 1979 } 1980 identity bitmap-RFC8724 { 1981 base bitmap-format-base-type; 1982 description 1983 "Bitmap as defined in RFC8724."; 1984 } 1986 identity bitmap-compound-ack { 1987 base bitmap-format-base-type; 1988 description 1989 "Compound Ack."; 1990 } 1992 typedef bitmap-format-type { 1993 type identityref { 1994 base bitmap-format-base-type; 1995 } 1996 description 1997 "type used in rules"; 1998 } 2000 // -------- RULE ENTRY DEFINITION ------------ 2002 grouping tv-struct { 2003 description 2004 "Define the target value element. Always a binary type, strings 2005 must be converted to binary. field-id allows the conversion to the appropriate 2006 type."; 2007 leaf value { 2008 type binary; 2009 } 2010 leaf position { 2011 type uint16; 2012 description 2013 "If only one element position is 0, otherwise position is the 2014 matching list."; 2015 } 2016 } 2018 grouping compression-rule-entry { 2019 description 2020 "These entries defines a compression entry (i.e. a line) 2021 as defined in RFC 8724 and fragmentation parameters. 2023 +-------+--+--+--+------------+-----------------+---------------+ 2024 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 2025 +-------+--+--+--+------------+-----------------+---------------+ 2027 An entry in a compression rule is composed of 7 elements: 2029 - Field ID: The header field to be compressed. The content is a YANG identifer. 2030 - Field Length : either a positive integer of a function defined as a YANF id. 2031 - Field Position: a positive (and possibly equal to 0) integer. 2032 - Direction Indicator: a YANG identifier giving the direction. 2033 - Target value: a value against which the header Field is compared. 2034 - Matching Operator: a YANG id giving the operation, paramters may be 2035 associated to that operator. 2036 - Comp./Decomp. Action: A YANG id giving the compression or decompression 2037 action, paramters may be associated to that action. 2038 "; 2039 leaf field-id { 2040 type schc:fid-type; 2041 mandatory true; 2042 description 2043 "Field ID, identify a field in the header with a YANG refenceid."; 2044 } 2045 leaf field-length { 2046 type schc:fl-type; 2047 mandatory true; 2048 description 2049 "Field Length in bit or through a function defined as a YANG referenceid"; 2050 } 2051 leaf field-position { 2052 type uint8; 2053 mandatory true; 2054 description 2055 "Field position in the header is a integer. If the field is not repeated 2056 in the header the value is 1, and incremented for each repetition of the field. Position 2057 0 means that the position is not important and order may change when decompressed"; 2058 } 2059 leaf direction-indicator { 2060 type schc:di-type; 2061 mandatory true; 2062 description 2063 "Direction Indicator, a YANG referenceid to say if the packet is bidirectional, 2064 up or down"; 2065 } 2066 list target-value { 2067 key "position"; 2068 uses tv-struct; 2069 description 2070 "A list of value to compare with the header field value. If target value 2071 is a singleton, position must be 0. For matching-list, should be consecutive position 2072 values starting from 1."; 2073 } 2074 leaf matching-operator { 2075 type schc:mo-type; 2076 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 2077 error-message "mo-equal, mo-msb and mo-match-mapping require target-value"; 2078 description 2079 "target-value is not required for mo-ignore"; 2080 } 2081 must "not (derived-from-or-self(., 'mo-msb')) or ../matching-operator-value" { 2082 error-message "mo-msb requires length value"; 2083 } 2084 mandatory true; 2085 description 2086 "MO: Matching Operator"; 2087 } 2088 list matching-operator-value { 2089 key "position"; 2090 uses tv-struct; 2091 description 2092 "Matching Operator Arguments, based on TV structure to allow several arguments. 2093 In RFC 8724, only MSB define a single argument: length in bits "; 2094 } 2095 leaf comp-decomp-action { 2096 type schc:cda-type; 2097 mandatory true; 2098 description 2099 "CDA: Compression Decompression Action"; 2100 } 2101 list comp-decomp-action-value { 2102 key "position"; 2103 uses tv-struct; 2104 description 2105 "CDA Arguments, based on TV structure to allow several arguments. 2106 In RFC 8724, no argument is defined for CDA"; 2107 } 2108 } 2110 grouping compression-content { 2111 list entry { 2112 key "field-id field-position direction-indicator"; 2113 uses compression-rule-entry; 2114 description 2115 "A compression rule is a list of rule entry describing 2116 each header field. An entry is identifed through a field-id, its position 2117 in the packet and its direction"; 2118 } 2119 description 2120 "Define a compression rule composed of a list of entries."; 2121 } 2123 grouping fragmentation-content { 2124 description 2125 "This grouping defines the fragmentation parameters for 2126 all the modes (No Ack, Ack Always and Ack on Error) specified in 2127 RFC 8724."; 2128 leaf l2-word-size { 2129 type uint8; 2130 default "8"; 2131 description 2132 "Size in bit of the layer 2 word"; 2133 } 2134 leaf direction { 2135 must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" { 2136 error-message "direction for fragmentation rules are up or down"; 2137 } 2138 type schc:di-type; 2139 mandatory true; 2140 description 2141 "Should be up or down, bi directionnal is forbiden."; 2142 } 2143 leaf dtag-size { 2144 type uint8; 2145 default "0"; 2146 description 2147 "Size in bit of the DTag field"; 2148 } 2149 leaf w-size { 2150 when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))"; 2151 type uint8; 2152 description 2153 "Size in bit of the window field"; 2154 } 2155 leaf fcn-size { 2156 type uint8; 2157 mandatory true; 2158 description 2159 "Size in bit of the FCN field"; 2160 } 2161 leaf rcs-algorithm { 2162 type rcs-algorithm-type; 2163 default "schc:rcs-RFC8724"; 2164 description 2165 "Algoritm used for RCS"; 2166 } 2167 leaf maximum-window-size { 2168 type uint16; 2169 description 2170 "By default 2^wsize - 1"; 2171 } 2172 leaf retransmission-timer { 2173 type uint64 { 2174 range "1..max"; 2175 } 2176 description 2177 "Duration in seconds of the retransmission timer"; // Check the units 2178 } 2179 leaf inactivity-timer { 2180 type uint64; 2181 description 2182 "Duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units 2183 } 2184 leaf max-ack-requests { 2185 type uint8 { 2186 range "1..max"; 2187 } 2188 description 2189 "The maximum number of retries for a specific SCHC ACK."; 2190 } 2191 leaf maximum-packet-size { 2192 type uint16; 2193 default "1280"; 2194 description 2195 "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 2196 } 2197 leaf fragmentation-mode { 2198 type schc:fragmentation-mode-type; 2199 mandatory true; 2200 description 2201 "which fragmentation mode is used (noAck, AckAlways, AckonError)"; 2202 } 2203 choice mode { 2204 case no-ack; 2205 case ack-always; 2206 case ack-on-error { 2207 leaf tile-size { 2208 type uint8; 2209 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 2210 description 2211 "Size in bit of tiles, if not specified or set to 0: tile fills the fragment."; 2212 } 2213 leaf tile-in-All1 { 2214 type schc:all1-data-type; 2215 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 2216 description 2217 "When true, sender and receiver except a tile in All-1 frag"; 2218 } 2219 leaf ack-behavior { 2220 type schc:ack-behavior-type; 2221 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 2222 description 2223 "Sender behavior to acknowledge, after All-0, All-1 or when the 2224 LPWAN allows it (Always)"; 2225 } 2226 leaf bitmap-format { 2227 type schc:bitmap-format-type; 2228 when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; 2229 default "schc:bitmap-RFC8724"; 2230 description 2231 "How the bitmaps are included in the Ack message."; 2232 } 2233 } 2234 description 2235 "RFC 8724 defines 3 fragmentation modes"; 2236 } 2237 } 2239 // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length 2241 grouping rule-id-type { 2242 leaf rule-id-value { 2243 type uint32; 2244 description 2245 "Rule ID value, this value must be unique combined with the length"; 2246 } 2247 leaf rule-id-length { 2248 type uint8 { 2249 range "0..32"; 2250 } 2251 description 2252 "Rule ID length in bits, value 0 is for implicit rules"; 2253 } 2254 description 2255 "A rule ID is composed of a value and a length in bit"; 2256 } 2258 // SCHC table for a specific device. 2260 container schc { 2261 list rule { 2262 key "rule-id-value rule-id-length"; 2263 uses rule-id-type; 2264 choice nature { 2265 case fragmentation { 2266 if-feature "fragmentation"; 2267 uses fragmentation-content; 2268 } 2269 case compression { 2270 uses compression-content; 2271 } 2272 case no-compression { 2273 description 2274 "RFC8724 allows a rule for uncompressed headers"; 2275 } 2276 description 2277 "A rule is either for compression, no compression or fragmentation"; 2278 } 2279 description 2280 "Set of rules compression, no compression or fragmentation rules 2281 identified by their rule-id "; 2282 } 2283 description 2284 "a SCHC set of rules is composed of a list of rule which are either 2285 compression or fragmentation"; 2286 } 2287 } 2288 2290 Figure 24 2292 8. Normative References 2294 [I-D.barthel-lpwan-oam-schc] 2295 Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and 2296 J. C. Zuniga, "OAM for LPWAN using Static Context Header 2297 Compression (SCHC)", Work in Progress, Internet-Draft, 2298 draft-barthel-lpwan-oam-schc-02, 2 November 2020, 2299 . 2302 [I-D.ietf-lpwan-schc-compound-ack] 2303 Zuniga, J. C., Gomez, C., Aguilar, S., Toutain, L., 2304 Cespedes, S., and D. Wistuba, "SCHC Compound ACK", Work in 2305 Progress, Internet-Draft, draft-ietf-lpwan-schc-compound- 2306 ack-00, 9 July 2021, . 2309 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2310 Application Protocol (CoAP)", RFC 7252, 2311 DOI 10.17487/RFC7252, June 2014, 2312 . 2314 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2315 Zúñiga, "SCHC: Generic Framework for Static Context Header 2316 Compression and Fragmentation", RFC 8724, 2317 DOI 10.17487/RFC8724, April 2020, 2318 . 2320 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 2321 Context Header Compression (SCHC) for the Constrained 2322 Application Protocol (CoAP)", RFC 8824, 2323 DOI 10.17487/RFC8824, June 2021, 2324 . 2326 Authors' Addresses 2328 Ana Minaburo 2329 Acklio 2330 1137A avenue des Champs Blancs 2331 35510 Cesson-Sevigne Cedex 2332 France 2334 Email: ana@ackl.io 2336 Laurent Toutain 2337 Institut MINES TELECOM; IMT Atlantique 2338 2 rue de la Chataigneraie 2339 CS 17607 2340 35576 Cesson-Sevigne Cedex 2341 France 2343 Email: Laurent.Toutain@imt-atlantique.fr