idnits 2.17.1 draft-ietf-lpwan-schc-yang-data-model-10.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 228: '...odel, each field MUST be identified th...' RFC 2119 keyword, line 232: '...for this protocol MUST derive from the...' RFC 2119 keyword, line 410: '... Index values MUST start from 0 and...' RFC 2119 keyword, line 564: '...rk for a specific direction, they MUST...' RFC 2119 keyword, line 566: '...s, but bidirectional MUST NOT be used....' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1324 has weird spacing: '...w index uin...' == Line 1328 has weird spacing: '...w index uin...' == Line 1332 has weird spacing: '...w index uin...' -- The document date (19 May 2022) is 707 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 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: 20 November 2022 Institut MINES TELECOM; IMT Atlantique 6 19 May 2022 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-10 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 20 November 2022. 33 Copyright Notice 35 Copyright (c) 2022 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 Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 10 58 2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10 59 2.8.1. Matching Operator arguments . . . . . . . . . . . . . 12 60 2.9. Compression Decompression Actions . . . . . . . . . . . . 12 61 2.9.1. Compression Decompression Action arguments . . . . . 13 62 2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 13 63 2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 13 64 2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 14 65 2.10.3. Last fragment format . . . . . . . . . . . . . . . . 15 66 2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 24 72 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 29 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 30 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 76 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 53 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 80 1. Introduction 82 SCHC is a compression and fragmentation mechanism for constrained 83 networks defined in [RFC8724]. It is based on a static context 84 shared by two entities at the boundary of the constrained network. 85 [RFC8724] provides a non formal representation of the rules used 86 either for compression/decompression (or C/D) or fragmentation/ 87 reassembly (or F/R). The goal of this document is to formalize the 88 description of the rules to offer: 90 * the same definition on both ends, even if the internal 91 representation is different. 93 * an update of the other end to set up some specific values (e.g. 94 IPv6 prefix, Destination address,...) 96 * ... 98 This document defines a YANG module to represent both compression and 99 fragmentation rules, which leads to common representation for values 100 for all the rules elements. 102 2. SCHC rules 104 SCHC is a compression and fragmentation mechanism for constrained 105 networks defined in [RFC8724]. It is based on a static context 106 shared by two entities at the boundary of the constrained network. 107 [RFC8724] provides a non formal representation of the rules used 108 either for compression/decompression (or C/D) or fragmentation/ 109 reassembly (or F/R). The goal of this document is to formalize the 110 description of the rules to offer: 112 * the same definition on both ends, even if the internal 113 representation is different. 115 * an update of the other end to set up some specific values (e.g. 116 IPv6 prefix, Destination address,...) 118 * ... 120 This document defines a YANG module to represent both compression and 121 fragmentation rules, which leads to common representation for values 122 for all the rules elements. 124 SCHC compression is generic, the main mechanism does not refer to a 125 specific protocol. Any header field is abstracted through an ID, a 126 position, a direction, and a value that can be a numerical value or a 127 string. [RFC8724] and [RFC8824] specify fields for IPv6, UDP, CoAP 128 and OSCORE. 130 SCHC fragmentation requires a set of common parameters that are 131 included in a rule. These parameters are defined in [RFC8724]. 133 The YANG model allows to select the compression or the fragmentation 134 using the feature command. 136 feature compression { 137 description 138 "SCHC compression capabilities are taken into account"; 139 } 141 feature fragmentation { 142 description 143 "SCHC fragmentation capabilities are taken into account"; 144 } 146 Figure 1: Feature for compression and fragmentation. 148 2.1. Compression Rules 150 [RFC8724] proposes a non formal representation of the compression 151 rule. A compression context for a device is composed of a set of 152 rules. Each rule contains information to describe a specific field 153 in the header to be compressed. 155 +-----------------------------------------------------------------+ 156 | Rule N | 157 +-----------------------------------------------------------------+| 158 | Rule i || 159 +-----------------------------------------------------------------+|| 160 | (FID) Rule 1 ||| 161 |+-------+--+--+--+------------+-----------------+---------------+||| 162 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 163 |+-------+--+--+--+------------+-----------------+---------------+||| 164 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 165 |+-------+--+--+--+------------+-----------------+---------------+||| 166 ||... |..|..|..| ... | ... | ... |||| 167 |+-------+--+--+--+------------+-----------------+---------------+||/ 168 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 169 |+-------+--+--+--+------------+-----------------+---------------+|/ 170 | | 171 \-----------------------------------------------------------------/ 173 Figure 2: Compression Decompression Context 175 2.2. Identifier generation 177 Identifier used in the SCHC YANG Data Model are from the identityref 178 statement to ensure to be globally unique and be easily augmented if 179 needed. The principle to define a new type based on a group of 180 identityref is the following: 182 * define a main identity ending with the keyword base-type. 184 * derive all the identities used in the Data Model from this base 185 type. 187 * create a typedef from this base type. 189 The example (Figure 3) shows how an identityref is created for RCS 190 algorithms used during SCHC fragmentation. 192 // -- RCS algorithm types 194 identity rcs-algorithm-base-type { 195 description 196 "Identify which algorithm is used to compute RCS. 197 The algorithm also defines the size of the RCS field."; 198 } 200 identity rcs-RFC8724 { 201 base rcs-algorithm-base-type; 202 description 203 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 204 } 206 typedef rcs-algorithm-type { 207 type identityref { 208 base rcs-algorithm-base-type; 209 } 210 description 211 "type used in rules."; 212 } 214 Figure 3: Principle to define a type based on identityref. 216 2.3. Field Identifier 218 In the process of compression, the headers of the original packet are 219 first parsed to create a list of fields. This list of fields is 220 matched against the rules to find the appropriate rule and apply 221 compression. [RFC8724] does not state how the field ID value is 222 constructed. In examples, identification is done through a string 223 indexed by the protocol name (e.g. IPv6.version, CoAP.version,...). 225 The current YANG Data Model includes fields definitions found in 226 [RFC8724], [RFC8824]. 228 Using the YANG model, each field MUST be identified through a global 229 YANG identityref. A YANG field ID for the protocol always derives 230 from the fid-base-type. Then an identity for each protocol is 231 specified using the naming convention fid-<>-base- 232 type. All possible fields for this protocol MUST derive from the 233 protocol identity. The naming convention is "fid" followed by the 234 protocol name and the field name. If a field has to be divided into 235 sub-fields, the field identity serves as a base. 237 The full field-id definition is found in Section 7. The example 238 Figure 4 gives the first field ID definitions. A type is defined for 239 IPv6 protocol, and each field is based on it. Note that the DiffServ 240 bits derives from the Traffic Class identity. 242 identity fid-base-type { 243 description 244 "Field ID base type for all fields"; 245 } 247 identity fid-ipv6-base-type { 248 base fid-base-type; 249 description 250 "Field ID base type for IPv6 headers described in RFC 8200"; 251 } 253 identity fid-ipv6-version { 254 base fid-ipv6-base-type; 255 description 256 "IPv6 version field from RFC8200"; 257 } 259 identity fid-ipv6-trafficclass { 260 base fid-ipv6-base-type; 261 description 262 "IPv6 Traffic Class field from RFC8200"; 263 } 265 identity fid-ipv6-trafficclass-ds { 266 base fid-ipv6-trafficclass; 267 description 268 "IPv6 Traffic Class field from RFC8200, 269 DiffServ field from RFC3168"; 270 } 271 ... 273 Figure 4: Definition of identityref for field IDs 275 The type associated to this identity is fid-type (cf. Figure 5) 276 typedef fid-type { 277 type identityref { 278 base fid-base-type; 279 } 280 description 281 "Field ID generic type."; 282 } 284 Figure 5: Type definition for field IDs 286 2.4. Field length 288 Field length is either an integer giving the size of a field in bits 289 or a specific function. [RFC8724] defines the "var" function which 290 allows variable length fields (whose length is expressed in bytes) 291 and [RFC8824] defines the "tkl" function for managing the CoAP Token 292 length field. 294 The naming convention is "fl" followed by the function name. 296 identity fl-base-type { 297 description 298 "Used to extend field length functions."; 299 } 301 identity fl-variable { 302 base fl-base-type; 303 description 304 "Residue length in Byte is sent as defined 305 for CoAP in RFC 8824 (cf. 5.3)."; 306 } 308 identity fl-token-length { 309 base fl-base-type; 310 description 311 "Residue length in Byte is sent as defined 312 for CoAP in RFC 8824 (cf. 4.5)."; 313 } 315 Figure 6: Definition of identityref for Field Length 317 The field length function can be defined as an identityref as shown 318 in Figure 6. 320 Therefore, the type for field length is a union between an integer 321 giving in bits the size of the length and the identityref (cf. 322 Figure 7). 324 typedef fl-type { 325 type union { 326 type int64; /* positive integer, expressing length in bits */ 327 type identityref { /* function */ 328 base fl-base-type; 329 } 330 } 331 description 332 "Field length either a positive integer expressing the size in 333 bits or a function defined through an identityref."; 334 } 336 Figure 7: Type definition for field Length 338 2.5. Field position 340 Field position is a positive integer which gives the position of a 341 field, the default value is 1, and incremented at each repetition. 342 value 0 indicates that the position is not important and is not 343 considered during the rule selection process. 345 Field position is a positive integer. The type is an uint8. 347 2.6. Direction Indicator 349 The Direction Indicator (di) is used to tell if a field appears in 350 both direction (Bi) or only uplink (Up) or Downlink (Dw). 352 identity di-base-type { 353 description 354 "Used to extend direction indicators."; 355 } 357 identity di-bidirectional { 358 base di-base-type; 359 description 360 "Direction Indication of bidirectionality in 361 RFC 8724 (cf. 7.1)."; 362 } 364 identity di-up { 365 base di-base-type; 366 description 367 "Direction Indication of uplink defined in 368 RFC 8724 (cf. 7.1)."; 369 } 371 identity di-down { 372 base di-base-type; 373 description 374 "Direction Indication of downlink defined in 375 RFC 8724 (cf. 7.1)."; 376 } 378 Figure 8: Definition of identityref for direction indicators 380 Figure 8 gives the identityref for Direction Indicators. The naming 381 convention is "di" followed by the Direction Indicator name. 383 The type is "di-type" (cf. Figure 9). 385 typedef di-type { 386 type identityref { 387 base di-base-type; 388 } 389 description 390 "Direction in LPWAN network, up when emitted by the device, 391 down when received by the device, bi when emitted or 392 received by the device."; 393 } 395 Figure 9: Type definition for direction indicators 397 2.7. Target Value 399 The Target Value is a list of binary sequences of any length, aligned 400 to the left. Figure 10 shows the definition of a single element of a 401 Target Value. In the rule, the structure will be used as a list, 402 with index as a key. The highest index value is used to compute the 403 size of the index sent in residue for the match-mapping CDA. The 404 index allows to specify several values: 406 * For Equal and LSB, Target Value contains a single element. 407 Therefore, the index is set to 0. 409 * For match-mapping, Target Value can contain several elements. 410 Index values MUST start from 0 and MUST be contiguous. 412 grouping tv-struct { 413 description 414 "Defines the target value element. Always a binary type, 415 strings must be converted to binary. field-id allows the 416 conversion to the appropriate type."; 417 leaf value { 418 type binary; 419 description 420 "Target Value"; 421 } 422 leaf index { 423 type uint16; 424 description 425 "Index gives the position in the matching-list. If only one 426 element is present, index is 0. Otherwise, indicia is the 427 the order in the matching list, starting at 0."; 428 } 429 } 431 Figure 10: Definition of target value 433 2.8. Matching Operator 435 Matching Operator (MO) is a function applied between a field value 436 provided by the parsed header and the target value. [RFC8724] 437 defines 4 MO as listed in Figure 11. 439 identity mo-base-type { 440 description 441 "Used to extend Matching Operators with SID values"; 442 } 444 identity mo-equal { 445 base mo-base-type; 446 description 447 "Equal MO as defined in RFC 8724 (cf. 7.3)"; 448 } 450 identity mo-ignore { 451 base mo-base-type; 452 description 453 "Ignore MO as defined in RFC 8724 (cf. 7.3)"; 454 } 456 identity mo-msb { 457 base mo-base-type; 458 description 459 "MSB MO as defined in RFC 8724 (cf. 7.3)"; 460 } 462 identity mo-match-mapping { 463 base mo-base-type; 464 description 465 "match-mapping MO as defined in RFC 8724 (cf. 7.3)"; 466 } 468 Figure 11: Definition of identityref for Matching Operator 470 The naming convention is "mo" followed by the MO name. 472 The type is "mo-type" (cf. Figure 12) 474 typedef mo-type { 475 type identityref { 476 base mo-base-type; 477 } 478 description 479 "Matching Operator (MO) to compare fields values with 480 target values"; 481 } 483 Figure 12: Type definition for Matching Operator 485 2.8.1. Matching Operator arguments 487 They are viewed as a list, built with a tv-struct (see chapter 488 Section 2.7). 490 2.9. Compression Decompression Actions 492 Compression Decompression Action (CDA) identifies the function to use 493 for compression or decompression. [RFC8724] defines 6 CDA. 495 Figure 14 shows some CDA definition, the full definition is in 496 Section 7. 498 identity cda-base-type { 499 description 500 "Compression Decompression Actions."; 501 } 503 identity cda-not-sent { 504 base cda-base-type; 505 description 506 "not-sent CDA as defined in RFC 8724 (cf. 7.4)."; 507 } 509 identity cda-value-sent { 510 base cda-base-type; 511 description 512 "value-sent CDA as defined in RFC 8724 (cf. 7.4)."; 513 } 515 identity cda-lsb { 516 base cda-base-type; 517 description 518 "LSB CDA as defined in RFC 8724 (cf. 7.4)."; 519 } 521 identity cda-mapping-sent { 522 base cda-base-type; 523 description 524 "mapping-sent CDA as defined in RFC 8724 (cf. 7.4)."; 525 } 527 identity cda-compute { 528 base cda-base-type; 529 description 530 "compute-* CDA as defined in RFC 8724 (cf. 7.4)"; 531 } 532 .... 534 Figure 13: Definition of identityref for Compresion Decompression 535 Action 537 The naming convention is "cda" followed by the CDA name. 539 typedef cda-type { 540 type identityref { 541 base cda-base-type; 542 } 543 description 544 "Compression Decompression Action to compression or 545 decompress a field."; 546 } 548 Figure 14: Type definition for Compresion Decompression Action 550 2.9.1. Compression Decompression Action arguments 552 Currently no CDA requires arguments, but in the future some CDA may 553 require one or several arguments. They are viewed as a list, of 554 target-value type. 556 2.10. Fragmentation rule 558 Fragmentation is optional in the data model and depends on the 559 presence of the "fragmentation" feature. 561 Most of the fragmentation parameters are listed in Annex D of 562 [RFC8724]. 564 Since fragmentation rules work for a specific direction, they MUST 565 contain a mandatory direction indicator. The type is the same as the 566 one used in compression entries, but bidirectional MUST NOT be used. 568 2.10.1. Fragmentation mode 570 [RFC8724] defines 3 fragmentation modes: 572 * No Ack: this mode is unidirectionnal, no acknowledgment is sent 573 back. 575 * Ack Always: each fragmentation window must be explicitly 576 acknowledged before going to the next. 578 * Ack on Error: A window is acknowledged only when the receiver 579 detects some missing fragments. 581 Figure 15 shows the definition for identifiers from these three 582 modes. 584 identity fragmentation-mode-base-type { 585 description 586 "fragmentation mode."; 587 } 589 identity fragmentation-mode-no-ack { 590 base fragmentation-mode-base-type; 591 description 592 "No-ACK of RFC8724."; 593 } 595 identity fragmentation-mode-ack-always { 596 base fragmentation-mode-base-type; 597 description 598 "ACK-Always of RFC8724."; 599 } 601 identity fragmentation-mode-ack-on-error { 602 base fragmentation-mode-base-type; 603 description 604 "ACK-on-Error of RFC8724."; 605 } 607 typedef fragmentation-mode-type { 608 type identityref { 609 base fragmentation-mode-base-type; 610 } 611 description 612 "type used in rules"; 613 } 615 Figure 15: Definition of fragmentation mode identifer 617 The naming convention is "fragmentation-mode" followed by the 618 fragmentation mode name. 620 2.10.2. Fragmentation Header 622 A data fragment header, starting with the rule ID can be sent on the 623 fragmentation direction. The SCHC header may be composed of (cf. 624 Figure 16): 626 * a Datagram Tag (Dtag) identifying the datagram being fragmented if 627 the fragmentation applies concurrently on several datagrams. This 628 field in optional and its length is defined by the rule. 630 * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack- 631 Always, its size is 1. In Ack-on-Error, it depends on the rule. 632 This field is not needed in No-Ack mode. 634 * a Fragment Compressed Number (FCN) indicating the fragment/tile 635 position on the window. This field is mandatory on all modes 636 defined in [RFC8724], its size is defined by the rule. 638 |-- SCHC Fragment Header ----| 639 |-- T --|-M-|-- N --| 640 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 641 | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed) 642 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 644 Figure 16: Data fragment header from RFC8724 646 2.10.3. Last fragment format 648 The last fragment of a datagram is sent with an RCS (Reassembly Check 649 Sequence) field to detect residual transmission error and possible 650 losses in the last window. [RFC8724] defines a single algorithm 651 based on Ethernet CRC computation. The identity of the RCS algorithm 652 is shown in Figure 17. 654 identity rcs-algorithm-base-type { 655 description 656 "Identify which algorithm is used to compute RCS. 657 The algorithm also defines the size of the RCS field."; 658 } 660 identity rcs-RFC8724 { 661 base rcs-algorithm-base-type; 662 description 663 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 664 } 666 typedef rcs-algorithm-type { 667 type identityref { 668 base rcs-algorithm-base-type; 669 } 670 description 671 "type used in rules."; 672 } 674 Figure 17: type definition for RCS 676 The naming convention is "rcs" followed by the algorithm name. 678 For Ack-on-Error mode, the All-1 fragment may just contain the RCS or 679 can include a tile. The parameters defined in Figure 18 allows to 680 define the behavior: 682 * all1-data-no: the last fragment contains no data, just the RCS 684 * all1-data-yes: the last fragment includes a single tile and the 685 RCS 687 * all1-data-sender-choice: the last fragment may or may not contain 688 a single tile. The receiver can detect if a tile is present. 690 identity all1-data-base-type { 691 description 692 "Type to define when to send an Acknowledgment message."; 693 } 695 identity all1-data-no { 696 base all1-data-base-type; 697 description 698 "All1 contains no tiles."; 699 } 701 identity all1-data-yes { 702 base all1-data-base-type; 703 description 704 "All1 MUST contain a tile."; 705 } 707 identity all1-data-sender-choice { 708 base all1-data-base-type; 709 description 710 "Fragmentation process chooses to send tiles or not in all1."; 711 } 713 typedef all1-data-type { 714 type identityref { 715 base all1-data-base-type; 716 } 717 description 718 "Type used in rules."; 719 } 721 Figure 18: type definition for RCS 723 The naming convention is "all1-data" followed by the behavior 724 identifier. 726 2.10.4. Acknowledgment behavior 728 The acknowledgment fragment header goes in the opposite direction of 729 data. The header is composed of (see Figure 19): 731 * a Dtag (if present). 733 * a mandatory window as in the data fragment. 735 * a C bit giving the status of RCS validation. In case of failure, 736 a bitmap follows, indicating the received tile. 738 |--- SCHC ACK Header ----| 739 |-- T --|-M-| 1 | 740 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 741 | RuleID | DTag | W |C=1| padding as needed (success) 742 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 744 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 745 | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 746 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 748 Figure 19: Acknowledgment fragment header for RFC8724 750 For Ack-on-Error, SCHC defines when an acknowledgment can be sent. 751 This can be at any time defined by the layer 2, at the end of a 752 window (FCN All-0) or as a response to receiving the last fragment 753 (FCN All-1). The following identifiers (cf. Figure 20) define the 754 acknowledgment behavior. 756 identity ack-behavior-base-type { 757 description 758 "Define when to send an Acknowledgment ."; 759 } 761 identity ack-behavior-after-All0 { 762 base ack-behavior-base-type; 763 description 764 "Fragmentation expects Ack after sending All0 fragment."; 765 } 767 identity ack-behavior-after-All1 { 768 base ack-behavior-base-type; 769 description 770 "Fragmentation expects Ack after sending All1 fragment."; 771 } 773 identity ack-behavior-by-layer2 { 774 base ack-behavior-base-type; 775 description 776 "Layer 2 defines when to send an Ack."; 777 } 779 typedef ack-behavior-type { 780 type identityref { 781 base ack-behavior-base-type; 782 } 783 description 784 "Type used in rules."; 785 } 787 Figure 20: bitmap generation behavior 789 The naming convention is "ack-behavior" followed by the algorithm 790 name. 792 2.10.5. Fragmentation Parameters 794 The state machine requires some common values to handle 795 fragmentation: 797 * retransmission-timer expresses, in seconds, the duration before 798 sending an ack request (cf. section 8.2.2.4. of [RFC8724]). If 799 specified, value must be higher or equal to 1. 801 * inactivity-timer expresses, in seconds, the duration before 802 aborting a fragmentation session (cf. section 8.2.2.4. of 803 [RFC8724]). The value 0 explicitly indicates that this timer is 804 disabled. 806 * max-ack-requests expresses the number of attempts before aborting 807 (cf. section 8.2.2.4. of [RFC8724]). 809 * maximum-packet-size rexpresses, in bytes, the larger packet size 810 that can be reassembled. 812 They are defined as unsigned integers, see Section 7. 814 2.10.6. Layer 2 parameters 816 The data model includes two parameters needed for fragmentation: 818 * l2-word-size: [RFC8724] base fragmentation on a layer 2 word which 819 can be of any length. The default value is 8 and correspond to 820 the default value for byte aligned layer 2. A value of 1 will 821 indicate that there is no alignment and no need for padding. 823 * maximum-packet-size: defines the maximum size of a uncompressed 824 datagram. By default, the value is set to 1280 bytes. 826 They are defined as unsigned integer, see Section 7. 828 3. Rule definition 830 A rule is idenfied by a unique rule identifier (rule ID) comprising 831 both a Rule ID value and a Rule ID length. The YANG grouping rule- 832 id-type defines the structure used to represent a rule ID. A length 833 of 0 is allowed to represent an implicit rule. 835 Three types of rules are defined in [RFC8724]: 837 * Compression: a compression rule is associated with the rule ID. 839 * No compression: this identifies the default rule used to send a 840 packet in extenso when no compression rule was found (see 841 [RFC8724] section 6). 843 * Fragmentation: fragmentation parameters are associated with the 844 rule ID. Fragmentation is optional and feature "fragmentation" 845 should be set. 847 grouping rule-id-type { 848 leaf rule-id-value { 849 type uint32; 850 description 851 "Rule ID value, this value must be unique, considering its 852 length."; 853 } 854 leaf rule-id-length { 855 type uint8 { 856 range "0..32"; 857 } 858 description 859 "Rule ID length, in bits. The value 0 is for implicit 860 rules."; 861 } 862 description 863 "A rule ID is composed of a value and a length, expressed in 864 bits."; 865 } 867 // SCHC table for a specific device. 869 container schc { 870 list rule { 871 key "rule-id-value rule-id-length"; 872 uses rule-id-type; 873 choice nature { 874 case fragmentation { 875 if-feature "fragmentation"; 876 uses fragmentation-content; 877 } 878 case compression { 879 if-feature "compression"; 880 uses compression-content; 881 } 882 case no-compression { 883 description 884 "RFC8724 requires a rule for uncompressed headers."; 885 } 886 description 887 "A rule is for compression, for no-compression or for 888 fragmentation."; 889 } 890 description 891 "Set of rules compression, no compression or fragmentation 892 rules identified by their rule-id."; 893 } 894 description 895 "a SCHC set of rules is composed of a list of rules which are 896 used for compression, no-compression or fragmentation."; 897 } 898 } 900 Figure 21: Definition of a SCHC Context 902 To access a specific rule, the rule ID length and value are used as a 903 key. The rule is either a compression or a fragmentation rule. 905 3.1. Compression rule 907 A compression rule is composed of entries describing its processing 908 (cf. Figure 22). An entry contains all the information defined in 909 Figure 2 with the types defined above. 911 The compression rule described Figure 2 is defined by compression- 912 content. It defines a list of compression-rule-entry, indexed by 913 their field id, position and direction. The compression-rule-entry 914 element represent a line of the table Figure 2. Their type reflects 915 the identifier types defined in Section 2.1 917 Some checks are performed on the values: 919 * target value must be present for MO different from ignore. 921 * when MSB MO is specified, the matching-operator-value must be 922 present 924 grouping compression-rule-entry { 925 description 926 "These entries defines a compression entry (i.e. a line) 927 as defined in RFC 8724. 929 +-------+--+--+--+------------+-----------------+---------------+ 930 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 931 +-------+--+--+--+------------+-----------------+---------------+ 933 An entry in a compression rule is composed of 7 elements: 934 - Field ID: The header field to be compressed. The content 935 is a YANG identifer. 936 - Field Length : either a positive integer of a function 937 defined as a YANG id. 938 - Field Position: a positive (and possibly equal to 0) 939 integer. 940 - Direction Indicator: a YANG identifier giving the direction. 941 - Target value: a value against which the header Field is 942 compared. 944 - Matching Operator: a YANG id giving the operation, 945 parameters may be associated to that operator. 946 - Comp./Decomp. Action: A YANG id giving the compression or 947 decompression action, parameters may be associated to that 948 action. 949 "; 950 leaf field-id { 951 type schc:fid-type; 952 mandatory true; 953 description 954 "Field ID, identify a field in the header with a YANG 955 referenceid."; 956 } 957 leaf field-length { 958 type schc:fl-type; 959 mandatory true; 960 description 961 "Field Length, expressed in number of bits or through a 962 function defined as a YANG referenceid."; 963 } 964 leaf field-position { 965 type uint8; 966 mandatory true; 967 description 968 "Field position in the header is an integer. Position 1 969 matches the first occurence of a field in the header, 970 while incremented position values match subsequent 971 occurences. 972 Position 0 means that this entry matches a field 973 irrespective of its position of occurence in the 974 header. 975 Be aware that the decompressed header may have 976 position-0 fields ordered differently than they 977 appeared in the original packet."; 978 } 979 leaf direction-indicator { 980 type schc:di-type; 981 mandatory true; 982 description 983 "Direction Indicator, a YANG referenceid to say if the packet 984 is bidirectional, up or down"; 985 } 986 list target-value { 987 key "index"; 988 uses tv-struct; 989 description 990 "A list of value to compare with the header field value. 991 If target value is a singleton, position must be 0. 993 For use as a matching list for the mo-match-mapping matching 994 operator, positions should take consecutive values starting 995 from 1."; 996 } 997 leaf matching-operator { 998 type schc:mo-type; 999 must 1000 "../target-value or derived-from-or-self(., 'mo-ignore')" { 1001 error-message 1002 "mo-equal, mo-msb and mo-match-mapping need target-value"; 1003 description 1004 "target-value is not required for mo-ignore"; 1005 } 1006 must "not (derived-from-or-self(., 'mo-msb')) or 1007 ../matching-operator-value" { 1008 error-message "mo-msb requires length value"; 1009 } 1010 mandatory true; 1011 description 1012 "MO: Matching Operator"; 1013 } 1014 list matching-operator-value { 1015 key "index"; 1016 uses tv-struct; 1017 description 1018 "Matching Operator Arguments, based on TV structure to allow 1019 several arguments. 1020 In RFC 8724, only the MSB matching operator needs arguments 1021 (a single argument, which is the number of most significant 1022 bits to be matched)"; 1023 } 1024 leaf comp-decomp-action { 1025 type schc:cda-type; 1026 mandatory true; 1027 description 1028 "CDA: Compression Decompression Action."; 1029 } 1030 list comp-decomp-action-value { 1031 key "index"; 1032 uses tv-struct; 1033 description 1034 "CDA arguments, based on a TV structure, in order to allow 1035 for several arguments. The CDAs specified in RFC 8724 1036 require no argument."; 1037 } 1038 } 1040 grouping compression-content { 1041 list entry { 1042 key "field-id field-position direction-indicator"; 1043 uses compression-rule-entry; 1044 description 1045 "A compression rule is a list of rule entries, each 1046 describing a header field. An entry is identifed 1047 through a field-id, its position in the packet and 1048 its direction."; 1049 } 1050 description 1051 "Define a compression rule composed of a list of entries."; 1052 } 1054 Figure 22: Definition of a compression entry 1056 3.2. Fragmentation rule 1058 A Fragmentation rule is composed of entries describing the protocol 1059 behavior. Some on them are numerical entries, others are identifiers 1060 defined in Section 2.10. 1062 The definition of a Fragmentation rule is divided into three sub- 1063 parts (cf. Figure 24): 1065 * parameters such as the fragmentation-mode, the l2-word-size and 1066 the direction. Since Fragmentation rules are always defined for a 1067 specific direction, the value must be either di-up or di-down (di- 1068 bidirectional is not allowed). 1070 * parameters defining the Fragmentation header format (dtag-size, 1071 w-size, fcn-size and rcs-algorithm). 1073 * Protocol parameters for timers (inactivity-timer, retransmission- 1074 timer). [RFC8724] do not specified any range for these timers. 1075 [RFC9011] recommends a duration of 12 hours. In fact, the value 1076 range sould be between milli-seconds for real time systems to 1077 several days. Figure 23 shows the two parameters defined for 1078 timers: 1080 - the duration of a tick is computed through this formula 2^tick- 1081 duration/10^6. When tick-duration is set to 0, the unit is the 1082 micro-second. The default value of 20 leads to a unit of about 1083 1.05 second. A value of 32 leads to a tick duration of about 1084 1.19 hours. 1086 - the number of ticks in the predefined unit. With the default 1087 tick-duration value of 20, the timers can cover a range between 1088 1.0 sec and 19 hours covering [RFC9011] recommandation. 1090 * Protocol behavior (maximum-packet-size, max-interleaved-frames, 1091 max-ack-requests). If these parameters are specific to a single 1092 fragmentation mode, they are grouped in a structure dedicated to 1093 that Fragmentation mode. If some parameters can be found in 1094 several modes, typically ACK-Always and ACK-on-Error, they are 1095 defined in a common part and a when statement indicates which 1096 modes are allowed. 1098 grouping timer-duration { 1099 leaf ticks-duration { 1100 type uint8; 1101 default "20"; 1102 description 1103 "duration of one tick in micro-seconds: 1104 2^ticks-duration/10^6 = 1.048s"; 1105 } 1106 leaf ticks-numbers { 1107 type uint16; 1108 description 1109 "timer duration = ticks-numbers * 2^ticks / 10^6"; 1110 } 1111 description 1112 "used by inactivity and retransmission timer. Allows a 1113 precision from micro-second to year by sending the 1114 tick-duration value. 1115 For instance: 1117 tick-duration / smallest value highest value 1118 v 1119 20: 00y 000d 00h 00m 01s.048575<->00y 000d 19h 05m 18s.428159 1120 21: 00y 000d 00h 00m 02s.097151<->00y 001d 14h 10m 36s.856319 1121 22: 00y 000d 00h 00m 04s.194303<->00y 003d 04h 21m 13s.712639 1122 23: 00y 000d 00h 00m 08s.388607<->00y 006d 08h 42m 27s.425279 1123 24: 00y 000d 00h 00m 16s.777215<->00y 012d 17h 24m 54s.850559 1124 25: 00y 000d 00h 00m 33s.554431<->00y 025d 10h 49m 49s.701119 1126 Note that the smallest value is also the incrementation step, 1127 so the timer precision. 1128 "; 1129 } 1131 Figure 23: Timer duration values 1133 grouping fragmentation-content { 1134 description 1135 "This grouping defines the fragmentation parameters for 1136 all the modes (No-Ack, Ack-Always and Ack-on-Error) specified 1137 in RFC 8724."; 1138 leaf fragmentation-mode { 1139 type schc:fragmentation-mode-type; 1140 mandatory true; 1141 description 1142 "which fragmentation mode is used (noAck, AckAlways, 1143 AckonError)"; 1144 } 1145 leaf l2-word-size { 1146 type uint8; 1147 default "8"; 1148 description 1149 "Size, in bits, of the layer 2 word"; 1150 } 1151 leaf direction { 1152 type schc:di-type; 1153 must "derived-from-or-self(., 'di-up') or 1154 derived-from-or-self(., 'di-down')" { 1155 error-message 1156 "direction for fragmentation rules are up or down."; 1157 } 1158 mandatory true; 1159 description 1160 "Should be up or down, bidirectionnal is forbiden."; 1161 } 1162 // SCHC Frag header format 1163 leaf dtag-size { 1164 type uint8; 1165 default "0"; 1166 description 1167 "Size, in bits, of the DTag field (T variable from 1168 RFC8724)."; 1169 } 1170 leaf w-size { 1171 when "derived-from(../fragmentation-mode, 1172 'fragmentation-mode-ack-on-error') 1173 or 1174 derived-from(../fragmentation-mode, 1175 'fragmentation-mode-ack-always') "; 1176 type uint8; 1177 description 1178 "Size, in bits, of the window field (M variable from 1179 RFC8724)."; 1180 } 1181 leaf fcn-size { 1182 type uint8; 1183 mandatory true; 1184 description 1185 "Size, in bits, of the FCN field (N variable from RFC8724)."; 1186 } 1187 leaf rcs-algorithm { 1188 type rcs-algorithm-type; 1189 default "schc:rcs-RFC8724"; 1190 description 1191 "Algorithm used for RCS. The algorithm specifies the RCS 1192 size"; 1193 } 1194 // SCHC fragmentation protocol parameters 1195 leaf maximum-packet-size { 1196 type uint16; 1197 default "1280"; 1198 description 1199 "When decompression is done, packet size must not 1200 strictly exceed this limit, expressed in bytes."; 1201 } 1202 leaf window-size { 1203 type uint16; 1204 description 1205 "By default, if not specified 2^w-size - 1. Should not exceed 1206 this value. Possible FCN values are between 0 and 1207 window-size - 1."; 1208 } 1209 leaf max-interleaved-frames { 1210 type uint8; 1211 default "1"; 1212 description 1213 "Maximum of simultaneously fragmented frames. Maximum value 1214 is 2^dtag-size. All DTAG values can be used, but at most 1215 max-interleaved-frames must be active at any time."; 1216 } 1217 container inactivity-timer { 1218 uses timer-duration; 1219 description 1220 "Duration is seconds of the inactivity timer, 0 indicates 1221 that the timer is disabled."; 1222 } 1223 container retransmission-timer { 1224 uses timer-duration; 1225 when "derived-from(../fragmentation-mode, 1226 'fragmentation-mode-ack-on-error') 1227 or 1228 derived-from(../fragmentation-mode, 1229 'fragmentation-mode-ack-always') "; 1230 description 1231 "Duration in seconds of the retransmission timer."; 1232 } 1233 leaf max-ack-requests { 1234 when "derived-from(../fragmentation-mode, 1235 'fragmentation-mode-ack-on-error') 1236 or 1237 derived-from(../fragmentation-mode, 1238 'fragmentation-mode-ack-always') "; 1239 type uint8 { 1240 range "1..max"; 1241 } 1242 description 1243 "The maximum number of retries for a specific SCHC ACK."; 1244 } 1245 choice mode { 1246 case no-ack; 1247 case ack-always; 1248 case ack-on-error { 1249 leaf tile-size { 1250 when "derived-from(../fragmentation-mode, 1251 'fragmentation-mode-ack-on-error')"; 1252 type uint8; 1253 description 1254 "Size, in bits, of tiles. If not specified or set to 0, 1255 tiles fill the fragment."; 1256 } 1257 leaf tile-in-All1 { 1258 when "derived-from(../fragmentation-mode, 1259 'fragmentation-mode-ack-on-error')"; 1260 type schc:all1-data-type; 1261 description 1262 "Defines whether the sender and receiver expect a tile in 1263 All-1 fragments or not, or if it is left to the sender's 1264 choice."; 1265 } 1266 leaf ack-behavior { 1267 when "derived-from(../fragmentation-mode, 1268 'fragmentation-mode-ack-on-error')"; 1269 type schc:ack-behavior-type; 1270 description 1271 "Sender behavior to acknowledge, after All-0, All-1 or 1272 when the LPWAN allows it."; 1273 } 1274 } 1275 description 1276 "RFC 8724 defines 3 fragmentation modes."; 1278 } 1279 } 1281 Figure 24: Fragmentation Parameters 1283 3.3. YANG Tree 1285 module: ietf-schc 1286 +-rw schc 1287 +-rw rule* [rule-id-value rule-id-length] 1288 +--rw rule-id-value uint32 1289 +--rw rule-id-length uint8 1290 +--rw (nature)? 1291 +--:(fragmentation) {fragmentation}? 1292 | +--rw fragmentation-mode schc:fragmentation-mode-type 1293 | +--rw l2-word-size? uint8 1294 | +--rw direction schc:di-type 1295 | +--rw dtag-size? uint8 1296 | +--rw w-size? uint8 1297 | +--rw fcn-size uint8 1298 | +--rw rcs-algorithm? rcs-algorithm-type 1299 | +--rw maximum-packet-size? uint16 1300 | +--rw window-size? uint16 1301 | +--rw max-interleaved-frames? uint8 1302 | +--rw inactivity-timer 1303 | | +--rw ticks-duration? uint8 1304 | | +--rw ticks-numbers? uint16 1305 | +--rw retransmission-timer 1306 | | +--rw ticks-duration? uint8 1307 | | +--rw ticks-numbers? uint16 1308 | +--rw max-ack-requests? uint8 1309 | +--rw (mode)? 1310 | +--:(no-ack) 1311 | +--:(ack-always) 1312 | +--:(ack-on-error) 1313 | +--rw tile-size? uint8 1314 | +--rw tile-in-All1? schc:all1-data-type 1315 | +--rw ack-behavior? schc:ack-behavior-type 1316 +--:(compression) {compression}? 1317 | +--rw entry* [field-id field-position direction-indicator] 1318 | +--rw field-id schc:fid-type 1319 | +--rw field-length schc:fl-type 1320 | +--rw field-position uint8 1321 | +--rw direction-indicator schc:di-type 1322 | +--rw target-value* [index] 1323 | | +--rw value? binary 1324 | | +--rw index uint16 1325 | +--rw matching-operator schc:mo-type 1326 | +--rw matching-operator-value* [index] 1327 | | +--rw value? binary 1328 | | +--rw index uint16 1329 | +--rw comp-decomp-action schc:cda-type 1330 | +--rw comp-decomp-action-value* [index] 1331 | +--rw value? binary 1332 | +--rw index uint16 1333 +--:(no-compression) 1335 Figure 25 1337 4. IANA Considerations 1339 This document has no request to IANA. 1341 5. Security considerations 1343 This document does not have any more Security consideration than the 1344 ones already raised in [RFC8724] and [RFC8824]. 1346 6. Acknowledgements 1348 The authors would like to thank Dominique Barthel, Carsten Bormann, 1349 Alexander Pelov for their careful reading and valuable inputs. A 1350 special thanks for Carl Moberg for his patience and wise advices when 1351 building the model. 1353 7. YANG Module 1355 file ietf-schc@2022-02-15.yang 1356 module ietf-schc { 1357 yang-version 1.1; 1358 namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; 1359 prefix schc; 1361 organization 1362 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working 1363 group"; 1364 contact 1365 "WG Web: 1366 WG List: 1367 Editor: Laurent Toutain 1368 1369 Editor: Ana Minaburo 1370 "; 1371 description 1372 " 1373 Copyright (c) 2021 IETF Trust and the persons identified as 1374 authors of the code. All rights reserved. 1376 Redistribution and use in source and binary forms, with or 1377 without modification, is permitted pursuant to, and subject to 1378 the license terms contained in, the Simplified BSD License set 1379 forth in Section 4.c of the IETF Trust's Legal Provisions 1380 Relating to IETF Documents 1381 (https://trustee.ietf.org/license-info). 1383 This version of this YANG module is part of RFC XXXX 1384 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1385 for full legal notices. 1387 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1388 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1389 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1390 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1391 they appear in all capitals, as shown here. 1393 *************************************************************** 1395 Generic Data model for Static Context Header Compression Rule 1396 for SCHC, based on RFC 8724 and RFC8824. Include compression, 1397 no compression and fragmentation rules. 1399 This module is a YANG model for SCHC rules (RFC 8724 and 1400 RFC8824). RFC 8724 describes compression rules in a abstract 1401 way through a table. 1403 |-----------------------------------------------------------------| 1404 | (FID) Rule 1 | 1405 |+-------+--+--+--+------------+-----------------+---------------+| 1406 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1407 |+-------+--+--+--+------------+-----------------+---------------+| 1408 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1409 |+-------+--+--+--+------------+-----------------+---------------+| 1410 ||... |..|..|..| ... | ... | ... || 1411 |+-------+--+--+--+------------+-----------------+---------------+| 1412 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1413 |+-------+--+--+--+------------+-----------------+---------------+| 1414 |-----------------------------------------------------------------| 1416 This module proposes a global data model that can be used for 1417 rule exchanges or modification. It proposes both the data model 1418 format and the global identifiers used to describe some 1419 operations in fields. 1420 This data model applies to both compression and fragmentation."; 1422 revision 2022-02-15 { 1423 description 1424 "Initial version from RFC XXXX "; 1425 reference 1426 "RFC XXX: Data Model for Static Context Header Compression 1427 (SCHC)"; 1428 } 1430 feature compression { 1431 description 1432 "SCHC compression capabilities are taken into account"; 1433 } 1435 feature fragmentation { 1436 description 1437 "SCHC fragmentation capabilities are taken into account"; 1438 } 1440 // ------------------------- 1441 // Field ID type definition 1442 //-------------------------- 1443 // generic value TV definition 1445 identity fid-base-type { 1446 description 1447 "Field ID base type for all fields"; 1448 } 1450 identity fid-ipv6-base-type { 1451 base fid-base-type; 1452 description 1453 "Field ID base type for IPv6 headers described in RFC 8200"; 1454 } 1456 identity fid-ipv6-version { 1457 base fid-ipv6-base-type; 1458 description 1459 "IPv6 version field from RFC8200"; 1460 } 1462 identity fid-ipv6-trafficclass { 1463 base fid-ipv6-base-type; 1464 description 1465 "IPv6 Traffic Class field from RFC8200"; 1466 } 1468 identity fid-ipv6-trafficclass-ds { 1469 base fid-ipv6-trafficclass; 1470 description 1471 "IPv6 Traffic Class field from RFC8200, 1472 DiffServ field from RFC3168"; 1473 } 1475 identity fid-ipv6-trafficclass-ecn { 1476 base fid-ipv6-trafficclass; 1477 description 1478 "IPv6 Traffic Class field from RFC8200, 1479 ECN field from RFC3168"; 1480 } 1482 identity fid-ipv6-flowlabel { 1483 base fid-ipv6-base-type; 1484 description 1485 "IPv6 Flow Label field from RFC8200"; 1486 } 1488 identity fid-ipv6-payloadlength { 1489 base fid-ipv6-base-type; 1490 description 1491 "IPv6 Payload Length field from RFC8200"; 1492 } 1494 identity fid-ipv6-nextheader { 1495 base fid-ipv6-base-type; 1496 description 1497 "IPv6 Next Header field from RFC8200"; 1498 } 1500 identity fid-ipv6-hoplimit { 1501 base fid-ipv6-base-type; 1502 description 1503 "IPv6 Next Header field from RFC8200"; 1504 } 1506 identity fid-ipv6-devprefix { 1507 base fid-ipv6-base-type; 1508 description 1509 "corresponds to either the source address or the destination 1510 address prefix of RFC 8200. Depending if it is 1511 respectively an uplink or a downlink message."; 1512 } 1514 identity fid-ipv6-deviid { 1515 base fid-ipv6-base-type; 1516 description 1517 "corresponds to either the source address or the destination 1518 address prefix of RFC 8200. Depending if it is respectively 1519 an uplink or a downlink message."; 1520 } 1522 identity fid-ipv6-appprefix { 1523 base fid-ipv6-base-type; 1524 description 1525 "corresponds to either the source address or the destination 1526 address prefix of RFC 8200. Depending if it is respectively 1527 a downlink or an uplink message."; 1528 } 1530 identity fid-ipv6-appiid { 1531 base fid-ipv6-base-type; 1532 description 1533 "corresponds to either the source address or the destination 1534 address prefix of RFC 8200. Depending if it is respectively 1535 a downlink or an uplink message."; 1536 } 1538 identity fid-udp-base-type { 1539 base fid-base-type; 1540 description 1541 "Field ID base type for UDP headers described in RFC 768"; 1542 } 1544 identity fid-udp-dev-port { 1545 base fid-udp-base-type; 1546 description 1547 "UDP source or destination port from RFC 768, if uplink or 1548 downlink communication, respectively."; 1549 } 1551 identity fid-udp-app-port { 1552 base fid-udp-base-type; 1553 description 1554 "UDP destination or source port from RFC 768, if uplink or 1555 downlink communication, respectively."; 1556 } 1558 identity fid-udp-length { 1559 base fid-udp-base-type; 1560 description 1561 "UDP length from RFC 768"; 1562 } 1564 identity fid-udp-checksum { 1565 base fid-udp-base-type; 1566 description 1567 "UDP length from RFC 768"; 1568 } 1570 identity fid-coap-base-type { 1571 base fid-base-type; 1572 description 1573 "Field ID base type for UDP headers described in RFC 7252"; 1574 } 1576 identity fid-coap-version { 1577 base fid-coap-base-type; 1578 description 1579 "CoAP version from RFC 7252"; 1580 } 1582 identity fid-coap-type { 1583 base fid-coap-base-type; 1584 description 1585 "CoAP type from RFC 7252"; 1586 } 1588 identity fid-coap-tkl { 1589 base fid-coap-base-type; 1590 description 1591 "CoAP token length from RFC 7252"; 1592 } 1594 identity fid-coap-code { 1595 base fid-coap-base-type; 1596 description 1597 "CoAP code from RFC 7252"; 1598 } 1600 identity fid-coap-code-class { 1601 base fid-coap-code; 1602 description 1603 "CoAP code class from RFC 7252"; 1604 } 1606 identity fid-coap-code-detail { 1607 base fid-coap-code; 1608 description 1609 "CoAP code detail from RFC 7252"; 1610 } 1612 identity fid-coap-mid { 1613 base fid-coap-base-type; 1614 description 1615 "CoAP message ID from RFC 7252"; 1616 } 1618 identity fid-coap-token { 1619 base fid-coap-base-type; 1620 description 1621 "CoAP token from RFC 7252"; 1622 } 1624 identity fid-coap-option-if-match { 1625 base fid-coap-base-type; 1626 description 1627 "CoAP option If-Match from RFC 7252"; 1628 } 1630 identity fid-coap-option-uri-host { 1631 base fid-coap-base-type; 1632 description 1633 "CoAP option URI-Host from RFC 7252"; 1634 } 1636 identity fid-coap-option-etag { 1637 base fid-coap-base-type; 1638 description 1639 "CoAP option Etag from RFC 7252"; 1640 } 1642 identity fid-coap-option-if-none-match { 1643 base fid-coap-base-type; 1644 description 1645 "CoAP option if-none-match from RFC 7252"; 1646 } 1648 identity fid-coap-option-observe { 1649 base fid-coap-base-type; 1650 description 1651 "CoAP option Observe from RFC 7641"; 1652 } 1654 identity fid-coap-option-uri-port { 1655 base fid-coap-base-type; 1656 description 1657 "CoAP option Uri-Port from RFC 7252"; 1658 } 1660 identity fid-coap-option-location-path { 1661 base fid-coap-base-type; 1662 description 1663 "CoAP option Location-Path from RFC 7252"; 1664 } 1666 identity fid-coap-option-uri-path { 1667 base fid-coap-base-type; 1668 description 1669 "CoAP option Uri-Path from RFC 7252"; 1670 } 1672 identity fid-coap-option-content-format { 1673 base fid-coap-base-type; 1674 description 1675 "CoAP option Content Format from RFC 7252"; 1676 } 1678 identity fid-coap-option-max-age { 1679 base fid-coap-base-type; 1680 description 1681 "CoAP option Max-Age from RFC 7252"; 1682 } 1684 identity fid-coap-option-uri-query { 1685 base fid-coap-base-type; 1686 description 1687 "CoAP option Uri-Query from RFC 7252"; 1688 } 1690 identity fid-coap-option-accept { 1691 base fid-coap-base-type; 1692 description 1693 "CoAP option Accept from RFC 7252"; 1694 } 1696 identity fid-coap-option-location-query { 1697 base fid-coap-base-type; 1698 description 1699 "CoAP option Location-Query from RFC 7252"; 1700 } 1702 identity fid-coap-option-block2 { 1703 base fid-coap-base-type; 1704 description 1705 "CoAP option Block2 from RFC 7959"; 1706 } 1708 identity fid-coap-option-block1 { 1709 base fid-coap-base-type; 1710 description 1711 "CoAP option Block1 from RFC 7959"; 1712 } 1714 identity fid-coap-option-size2 { 1715 base fid-coap-base-type; 1716 description 1717 "CoAP option size2 from RFC 7959"; 1718 } 1720 identity fid-coap-option-proxy-uri { 1721 base fid-coap-base-type; 1722 description 1723 "CoAP option Proxy-Uri from RFC 7252"; 1724 } 1726 identity fid-coap-option-proxy-scheme { 1727 base fid-coap-base-type; 1728 description 1729 "CoAP option Proxy-scheme from RFC 7252"; 1730 } 1732 identity fid-coap-option-size1 { 1733 base fid-coap-base-type; 1734 description 1735 "CoAP option Size1 from RFC 7252"; 1736 } 1738 identity fid-coap-option-no-response { 1739 base fid-coap-base-type; 1740 description 1741 "CoAP option No response from RFC 7967"; 1742 } 1744 identity fid-coap-option-oscore-flags { 1745 base fid-coap-base-type; 1746 description 1747 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1748 } 1750 identity fid-coap-option-oscore-piv { 1751 base fid-coap-base-type; 1752 description 1753 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1754 } 1756 identity fid-coap-option-oscore-kid { 1757 base fid-coap-base-type; 1758 description 1759 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1760 } 1762 identity fid-coap-option-oscore-kidctx { 1763 base fid-coap-base-type; 1764 description 1765 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1766 } 1768 //---------------------------------- 1769 // Field Length type definition 1770 //---------------------------------- 1772 identity fl-base-type { 1773 description 1774 "Used to extend field length functions."; 1775 } 1777 identity fl-variable { 1778 base fl-base-type; 1779 description 1780 "Residue length in Byte is sent as defined 1781 for CoAP in RFC 8824 (cf. 5.3)."; 1782 } 1784 identity fl-token-length { 1785 base fl-base-type; 1786 description 1787 "Residue length in Byte is sent as defined 1788 for CoAP in RFC 8824 (cf. 4.5)."; 1789 } 1791 //--------------------------------- 1792 // Direction Indicator type 1793 //--------------------------------- 1795 identity di-base-type { 1796 description 1797 "Used to extend direction indicators."; 1798 } 1800 identity di-bidirectional { 1801 base di-base-type; 1802 description 1803 "Direction Indication of bidirectionality in 1804 RFC 8724 (cf. 7.1)."; 1805 } 1806 identity di-up { 1807 base di-base-type; 1808 description 1809 "Direction Indication of uplink defined in 1810 RFC 8724 (cf. 7.1)."; 1811 } 1813 identity di-down { 1814 base di-base-type; 1815 description 1816 "Direction Indication of downlink defined in 1817 RFC 8724 (cf. 7.1)."; 1818 } 1820 //---------------------------------- 1821 // Matching Operator type definition 1822 //---------------------------------- 1824 identity mo-base-type { 1825 description 1826 "Used to extend Matching Operators with SID values"; 1827 } 1829 identity mo-equal { 1830 base mo-base-type; 1831 description 1832 "Equal MO as defined in RFC 8724 (cf. 7.3)"; 1833 } 1835 identity mo-ignore { 1836 base mo-base-type; 1837 description 1838 "Ignore MO as defined in RFC 8724 (cf. 7.3)"; 1839 } 1841 identity mo-msb { 1842 base mo-base-type; 1843 description 1844 "MSB MO as defined in RFC 8724 (cf. 7.3)"; 1845 } 1847 identity mo-match-mapping { 1848 base mo-base-type; 1849 description 1850 "match-mapping MO as defined in RFC 8724 (cf. 7.3)"; 1851 } 1853 //------------------------------ 1854 // CDA type definition 1855 //------------------------------ 1857 identity cda-base-type { 1858 description 1859 "Compression Decompression Actions."; 1860 } 1862 identity cda-not-sent { 1863 base cda-base-type; 1864 description 1865 "not-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1866 } 1868 identity cda-value-sent { 1869 base cda-base-type; 1870 description 1871 "value-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1872 } 1874 identity cda-lsb { 1875 base cda-base-type; 1876 description 1877 "LSB CDA as defined in RFC 8724 (cf. 7.4)."; 1878 } 1880 identity cda-mapping-sent { 1881 base cda-base-type; 1882 description 1883 "mapping-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1884 } 1886 identity cda-compute { 1887 base cda-base-type; 1888 description 1889 "compute-length CDA as defined in RFC 8724 (cf. 7.4)"; 1890 } 1892 identity cda-deviid { 1893 base cda-base-type; 1894 description 1895 "deviid CDA as defined in RFC 8724 (cf. 7.4)"; 1896 } 1898 identity cda-appiid { 1899 base cda-base-type; 1900 description 1901 "appiid CDA as defined in RFC 8724 (cf. 7.4)"; 1903 } 1905 // -- type definition 1907 typedef fid-type { 1908 type identityref { 1909 base fid-base-type; 1910 } 1911 description 1912 "Field ID generic type."; 1913 } 1915 typedef fl-type { 1916 type union { 1917 type int64; /* positive integer, expressing length in bits */ 1918 type identityref { /* function */ 1919 base fl-base-type; 1920 } 1921 } 1922 description 1923 "Field length either a positive integer expressing the size in 1924 bits or a function defined through an identityref."; 1925 } 1927 typedef di-type { 1928 type identityref { 1929 base di-base-type; 1930 } 1931 description 1932 "Direction in LPWAN network, up when emitted by the device, 1933 down when received by the device, bi when emitted or 1934 received by the device."; 1935 } 1937 typedef mo-type { 1938 type identityref { 1939 base mo-base-type; 1940 } 1941 description 1942 "Matching Operator (MO) to compare fields values with 1943 target values"; 1944 } 1946 typedef cda-type { 1947 type identityref { 1948 base cda-base-type; 1949 } 1950 description 1951 "Compression Decompression Action to compression or 1952 decompress a field."; 1953 } 1955 // -- FRAGMENTATION TYPE 1956 // -- fragmentation modes 1958 identity fragmentation-mode-base-type { 1959 description 1960 "fragmentation mode."; 1961 } 1963 identity fragmentation-mode-no-ack { 1964 base fragmentation-mode-base-type; 1965 description 1966 "No-ACK of RFC8724."; 1967 } 1969 identity fragmentation-mode-ack-always { 1970 base fragmentation-mode-base-type; 1971 description 1972 "ACK-Always of RFC8724."; 1973 } 1975 identity fragmentation-mode-ack-on-error { 1976 base fragmentation-mode-base-type; 1977 description 1978 "ACK-on-Error of RFC8724."; 1979 } 1981 typedef fragmentation-mode-type { 1982 type identityref { 1983 base fragmentation-mode-base-type; 1984 } 1985 description 1986 "type used in rules"; 1987 } 1989 // -- Ack behavior 1991 identity ack-behavior-base-type { 1992 description 1993 "Define when to send an Acknowledgment ."; 1994 } 1996 identity ack-behavior-after-All0 { 1997 base ack-behavior-base-type; 1998 description 1999 "Fragmentation expects Ack after sending All0 fragment."; 2000 } 2002 identity ack-behavior-after-All1 { 2003 base ack-behavior-base-type; 2004 description 2005 "Fragmentation expects Ack after sending All1 fragment."; 2006 } 2008 identity ack-behavior-by-layer2 { 2009 base ack-behavior-base-type; 2010 description 2011 "Layer 2 defines when to send an Ack."; 2012 } 2014 typedef ack-behavior-type { 2015 type identityref { 2016 base ack-behavior-base-type; 2017 } 2018 description 2019 "Type used in rules."; 2020 } 2022 // -- All1 with data types 2024 identity all1-data-base-type { 2025 description 2026 "Type to define when to send an Acknowledgment message."; 2027 } 2029 identity all1-data-no { 2030 base all1-data-base-type; 2031 description 2032 "All1 contains no tiles."; 2033 } 2035 identity all1-data-yes { 2036 base all1-data-base-type; 2037 description 2038 "All1 MUST contain a tile."; 2039 } 2041 identity all1-data-sender-choice { 2042 base all1-data-base-type; 2043 description 2044 "Fragmentation process chooses to send tiles or not in all1."; 2045 } 2046 typedef all1-data-type { 2047 type identityref { 2048 base all1-data-base-type; 2049 } 2050 description 2051 "Type used in rules."; 2052 } 2054 // -- RCS algorithm types 2056 identity rcs-algorithm-base-type { 2057 description 2058 "Identify which algorithm is used to compute RCS. 2059 The algorithm also defines the size of the RCS field."; 2060 } 2062 identity rcs-RFC8724 { 2063 base rcs-algorithm-base-type; 2064 description 2065 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 2066 } 2068 typedef rcs-algorithm-type { 2069 type identityref { 2070 base rcs-algorithm-base-type; 2071 } 2072 description 2073 "type used in rules."; 2074 } 2076 // --------- TIMER DURATION ------------------- 2078 grouping timer-duration { 2079 leaf ticks-duration { 2080 type uint8; 2081 default "20"; 2082 description 2083 "duration of one tick in micro-seconds: 2084 2^ticks-duration/10^6 = 1.048s"; 2085 } 2086 leaf ticks-numbers { 2087 type uint16; 2088 description 2089 "timer duration = ticks-numbers * 2^ticks / 10^6"; 2090 } 2091 description 2092 "used by inactivity and retransmission timer. Allows a 2093 precision from micro-second to year by sending the 2094 tick-duration value. 2095 For instance: 2097 tick-duration / smallest value highest value 2098 v 2099 20: 00y 000d 00h 00m 01s.048575<->00y 000d 19h 05m 18s.428159 2100 21: 00y 000d 00h 00m 02s.097151<->00y 001d 14h 10m 36s.856319 2101 22: 00y 000d 00h 00m 04s.194303<->00y 003d 04h 21m 13s.712639 2102 23: 00y 000d 00h 00m 08s.388607<->00y 006d 08h 42m 27s.425279 2103 24: 00y 000d 00h 00m 16s.777215<->00y 012d 17h 24m 54s.850559 2104 25: 00y 000d 00h 00m 33s.554431<->00y 025d 10h 49m 49s.701119 2106 Note that the smallest value is also the incrementation step, 2107 so the timer precision. 2108 "; 2109 } 2111 // -------- RULE ENTRY DEFINITION ------------ 2113 grouping tv-struct { 2114 description 2115 "Defines the target value element. Always a binary type, 2116 strings must be converted to binary. field-id allows the 2117 conversion to the appropriate type."; 2118 leaf value { 2119 type binary; 2120 description 2121 "Target Value"; 2122 } 2123 leaf index { 2124 type uint16; 2125 description 2126 "Index gives the position in the matching-list. If only one 2127 element is present, index is 0. Otherwise, indicia is the 2128 the order in the matching list, starting at 0."; 2129 } 2130 } 2132 grouping compression-rule-entry { 2133 description 2134 "These entries defines a compression entry (i.e. a line) 2135 as defined in RFC 8724. 2137 +-------+--+--+--+------------+-----------------+---------------+ 2138 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 2139 +-------+--+--+--+------------+-----------------+---------------+ 2141 An entry in a compression rule is composed of 7 elements: 2143 - Field ID: The header field to be compressed. The content 2144 is a YANG identifer. 2145 - Field Length : either a positive integer of a function 2146 defined as a YANG id. 2147 - Field Position: a positive (and possibly equal to 0) 2148 integer. 2149 - Direction Indicator: a YANG identifier giving the direction. 2150 - Target value: a value against which the header Field is 2151 compared. 2152 - Matching Operator: a YANG id giving the operation, 2153 parameters may be associated to that operator. 2154 - Comp./Decomp. Action: A YANG id giving the compression or 2155 decompression action, parameters may be associated to that 2156 action. 2157 "; 2158 leaf field-id { 2159 type schc:fid-type; 2160 mandatory true; 2161 description 2162 "Field ID, identify a field in the header with a YANG 2163 referenceid."; 2164 } 2165 leaf field-length { 2166 type schc:fl-type; 2167 mandatory true; 2168 description 2169 "Field Length, expressed in number of bits or through a 2170 function defined as a YANG referenceid."; 2171 } 2172 leaf field-position { 2173 type uint8; 2174 mandatory true; 2175 description 2176 "Field position in the header is an integer. Position 1 2177 matches the first occurence of a field in the header, 2178 while incremented position values match subsequent 2179 occurences. 2180 Position 0 means that this entry matches a field 2181 irrespective of its position of occurence in the 2182 header. 2183 Be aware that the decompressed header may have 2184 position-0 fields ordered differently than they 2185 appeared in the original packet."; 2186 } 2187 leaf direction-indicator { 2188 type schc:di-type; 2189 mandatory true; 2190 description 2191 "Direction Indicator, a YANG referenceid to say if the packet 2192 is bidirectional, up or down"; 2193 } 2194 list target-value { 2195 key "index"; 2196 uses tv-struct; 2197 description 2198 "A list of value to compare with the header field value. 2199 If target value is a singleton, position must be 0. 2200 For use as a matching list for the mo-match-mapping matching 2201 operator, positions should take consecutive values starting 2202 from 1."; 2203 } 2204 leaf matching-operator { 2205 type schc:mo-type; 2206 must 2207 "../target-value or derived-from-or-self(., 'mo-ignore')" { 2208 error-message 2209 "mo-equal, mo-msb and mo-match-mapping need target-value"; 2210 description 2211 "target-value is not required for mo-ignore"; 2212 } 2213 must "not (derived-from-or-self(., 'mo-msb')) or 2214 ../matching-operator-value" { 2215 error-message "mo-msb requires length value"; 2216 } 2217 mandatory true; 2218 description 2219 "MO: Matching Operator"; 2220 } 2221 list matching-operator-value { 2222 key "index"; 2223 uses tv-struct; 2224 description 2225 "Matching Operator Arguments, based on TV structure to allow 2226 several arguments. 2227 In RFC 8724, only the MSB matching operator needs arguments 2228 (a single argument, which is the number of most significant 2229 bits to be matched)"; 2230 } 2231 leaf comp-decomp-action { 2232 type schc:cda-type; 2233 mandatory true; 2234 description 2235 "CDA: Compression Decompression Action."; 2236 } 2237 list comp-decomp-action-value { 2238 key "index"; 2239 uses tv-struct; 2240 description 2241 "CDA arguments, based on a TV structure, in order to allow 2242 for several arguments. The CDAs specified in RFC 8724 2243 require no argument."; 2244 } 2245 } 2247 grouping compression-content { 2248 list entry { 2249 key "field-id field-position direction-indicator"; 2250 uses compression-rule-entry; 2251 description 2252 "A compression rule is a list of rule entries, each 2253 describing a header field. An entry is identifed 2254 through a field-id, its position in the packet and 2255 its direction."; 2256 } 2257 description 2258 "Define a compression rule composed of a list of entries."; 2259 } 2261 grouping fragmentation-content { 2262 description 2263 "This grouping defines the fragmentation parameters for 2264 all the modes (No-Ack, Ack-Always and Ack-on-Error) specified 2265 in RFC 8724."; 2266 leaf fragmentation-mode { 2267 type schc:fragmentation-mode-type; 2268 mandatory true; 2269 description 2270 "which fragmentation mode is used (noAck, AckAlways, 2271 AckonError)"; 2272 } 2273 leaf l2-word-size { 2274 type uint8; 2275 default "8"; 2276 description 2277 "Size, in bits, of the layer 2 word"; 2278 } 2279 leaf direction { 2280 type schc:di-type; 2281 must "derived-from-or-self(., 'di-up') or 2282 derived-from-or-self(., 'di-down')" { 2283 error-message 2284 "direction for fragmentation rules are up or down."; 2285 } 2286 mandatory true; 2287 description 2288 "Should be up or down, bidirectionnal is forbiden."; 2289 } 2290 // SCHC Frag header format 2291 leaf dtag-size { 2292 type uint8; 2293 default "0"; 2294 description 2295 "Size, in bits, of the DTag field (T variable from 2296 RFC8724)."; 2297 } 2298 leaf w-size { 2299 when "derived-from(../fragmentation-mode, 2300 'fragmentation-mode-ack-on-error') 2301 or 2302 derived-from(../fragmentation-mode, 2303 'fragmentation-mode-ack-always') "; 2304 type uint8; 2305 description 2306 "Size, in bits, of the window field (M variable from 2307 RFC8724)."; 2308 } 2309 leaf fcn-size { 2310 type uint8; 2311 mandatory true; 2312 description 2313 "Size, in bits, of the FCN field (N variable from RFC8724)."; 2314 } 2315 leaf rcs-algorithm { 2316 type rcs-algorithm-type; 2317 default "schc:rcs-RFC8724"; 2318 description 2319 "Algorithm used for RCS. The algorithm specifies the RCS 2320 size"; 2321 } 2322 // SCHC fragmentation protocol parameters 2323 leaf maximum-packet-size { 2324 type uint16; 2325 default "1280"; 2326 description 2327 "When decompression is done, packet size must not 2328 strictly exceed this limit, expressed in bytes."; 2329 } 2330 leaf window-size { 2331 type uint16; 2332 description 2333 "By default, if not specified 2^w-size - 1. Should not exceed 2334 this value. Possible FCN values are between 0 and 2335 window-size - 1."; 2336 } 2337 leaf max-interleaved-frames { 2338 type uint8; 2339 default "1"; 2340 description 2341 "Maximum of simultaneously fragmented frames. Maximum value 2342 is 2^dtag-size. All DTAG values can be used, but at most 2343 max-interleaved-frames must be active at any time."; 2344 } 2345 container inactivity-timer { 2346 uses timer-duration; 2347 description 2348 "Duration is seconds of the inactivity timer, 0 indicates 2349 that the timer is disabled."; 2350 } 2351 container retransmission-timer { 2352 uses timer-duration; 2353 when "derived-from(../fragmentation-mode, 2354 'fragmentation-mode-ack-on-error') 2355 or 2356 derived-from(../fragmentation-mode, 2357 'fragmentation-mode-ack-always') "; 2358 description 2359 "Duration in seconds of the retransmission timer."; 2360 } 2361 leaf max-ack-requests { 2362 when "derived-from(../fragmentation-mode, 2363 'fragmentation-mode-ack-on-error') 2364 or 2365 derived-from(../fragmentation-mode, 2366 'fragmentation-mode-ack-always') "; 2367 type uint8 { 2368 range "1..max"; 2369 } 2370 description 2371 "The maximum number of retries for a specific SCHC ACK."; 2372 } 2373 choice mode { 2374 case no-ack; 2375 case ack-always; 2376 case ack-on-error { 2377 leaf tile-size { 2378 when "derived-from(../fragmentation-mode, 2379 'fragmentation-mode-ack-on-error')"; 2380 type uint8; 2381 description 2382 "Size, in bits, of tiles. If not specified or set to 0, 2383 tiles fill the fragment."; 2384 } 2385 leaf tile-in-All1 { 2386 when "derived-from(../fragmentation-mode, 2387 'fragmentation-mode-ack-on-error')"; 2388 type schc:all1-data-type; 2389 description 2390 "Defines whether the sender and receiver expect a tile in 2391 All-1 fragments or not, or if it is left to the sender's 2392 choice."; 2393 } 2394 leaf ack-behavior { 2395 when "derived-from(../fragmentation-mode, 2396 'fragmentation-mode-ack-on-error')"; 2397 type schc:ack-behavior-type; 2398 description 2399 "Sender behavior to acknowledge, after All-0, All-1 or 2400 when the LPWAN allows it."; 2401 } 2402 } 2403 description 2404 "RFC 8724 defines 3 fragmentation modes."; 2405 } 2406 } 2408 // Define rule ID. Rule ID is composed of a RuleID value and a 2409 // Rule ID Length 2411 grouping rule-id-type { 2412 leaf rule-id-value { 2413 type uint32; 2414 description 2415 "Rule ID value, this value must be unique, considering its 2416 length."; 2417 } 2418 leaf rule-id-length { 2419 type uint8 { 2420 range "0..32"; 2421 } 2422 description 2423 "Rule ID length, in bits. The value 0 is for implicit 2424 rules."; 2425 } 2426 description 2427 "A rule ID is composed of a value and a length, expressed in 2428 bits."; 2429 } 2430 // SCHC table for a specific device. 2432 container schc { 2433 list rule { 2434 key "rule-id-value rule-id-length"; 2435 uses rule-id-type; 2436 choice nature { 2437 case fragmentation { 2438 if-feature "fragmentation"; 2439 uses fragmentation-content; 2440 } 2441 case compression { 2442 if-feature "compression"; 2443 uses compression-content; 2444 } 2445 case no-compression { 2446 description 2447 "RFC8724 requires a rule for uncompressed headers."; 2448 } 2449 description 2450 "A rule is for compression, for no-compression or for 2451 fragmentation."; 2452 } 2453 description 2454 "Set of rules compression, no compression or fragmentation 2455 rules identified by their rule-id."; 2456 } 2457 description 2458 "a SCHC set of rules is composed of a list of rules which are 2459 used for compression, no-compression or fragmentation."; 2460 } 2461 } 2462 2464 Figure 26 2466 8. Normative References 2468 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2469 Zuniga, "SCHC: Generic Framework for Static Context Header 2470 Compression and Fragmentation", RFC 8724, 2471 DOI 10.17487/RFC8724, April 2020, 2472 . 2474 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 2475 Context Header Compression (SCHC) for the Constrained 2476 Application Protocol (CoAP)", RFC 8824, 2477 DOI 10.17487/RFC8824, June 2021, 2478 . 2480 [RFC9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context 2481 Header Compression and Fragmentation (SCHC) over LoRaWAN", 2482 RFC 9011, DOI 10.17487/RFC9011, April 2021, 2483 . 2485 Authors' Addresses 2487 Ana Minaburo 2488 Acklio 2489 1137A avenue des Champs Blancs 2490 35510 Cesson-Sevigne Cedex 2491 France 2492 Email: ana@ackl.io 2494 Laurent Toutain 2495 Institut MINES TELECOM; IMT Atlantique 2496 2 rue de la Chataigneraie 2497 CS 17607 2498 35576 Cesson-Sevigne Cedex 2499 France 2500 Email: Laurent.Toutain@imt-atlantique.fr