idnits 2.17.1 draft-ietf-lpwan-schc-yang-data-model-09.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 29 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 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: '... Indicia 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 1294 has weird spacing: '...indicia uin...' == Line 1298 has weird spacing: '...indicia uin...' == Line 1302 has weird spacing: '...indicia uin...' -- The document date (16 May 2022) is 703 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: 2 errors (**), 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: 17 November 2022 Institut MINES TELECOM; IMT Atlantique 6 16 May 2022 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-09 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 17 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 . . . . . . . . . . . . . . . . . . . . . . . . 28 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 29 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 76 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 52 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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 position as a key. The highest position value is used to 403 compute the size of the index sent in residue for the match-mapping 404 CDA. The position allows to specify several values: 406 * For Equal and LSB, Target Value contains a single element. 407 Therefore, the indicia is set to 0. 409 * For match-mapping, Target Value can contain several elements. 410 Indicia 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, strings 415 must be converted to binary. field-id allows the conversion 416 to the appropriate type."; 417 leaf value { 418 type binary; 419 description 420 "Target Value"; 421 } 422 leaf indicia { 423 type uint16; 424 description 425 "Indicia gives the position in the matching-list. If only one 426 element is present, indicia 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 rules."; 860 } 861 description 862 "A rule ID is composed of a value and a length, expressed in 863 bits."; 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 if-feature "compression"; 879 uses compression-content; 880 } 881 case no-compression { 882 description 883 "RFC8724 requires a rule for uncompressed headers."; 884 } 885 description 886 "A rule is for compression, for no-compression or for 887 fragmentation."; 888 } 889 description 890 "Set of rules compression, no compression or fragmentation 891 rules identified by their rule-id."; 892 } 893 description 894 "a SCHC set of rules is composed of a list of rules which are 895 used for compression, no-compression or fragmentation."; 896 } 897 } 899 Figure 21: Definition of a SCHC Context 901 To access a specific rule, the rule ID length and value are used as a 902 key. The rule is either a compression or a fragmentation rule. 904 3.1. Compression rule 906 A compression rule is composed of entries describing its processing 907 (cf. Figure 22). An entry contains all the information defined in 908 Figure 2 with the types defined above. 910 The compression rule described Figure 2 is defined by compression- 911 content. It defines a list of compression-rule-entry, indexed by 912 their field id, position and direction. The compression-rule-entry 913 element represent a line of the table Figure 2. Their type reflects 914 the identifier types defined in Section 2.1 916 Some checks are performed on the values: 918 * target value must be present for MO different from ignore. 920 * when MSB MO is specified, the matching-operator-value must be 921 present 923 grouping compression-rule-entry { 924 description 925 "These entries defines a compression entry (i.e. a line) 926 as defined in RFC 8724. 928 +-------+--+--+--+------------+-----------------+---------------+ 929 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 930 +-------+--+--+--+------------+-----------------+---------------+ 932 An entry in a compression rule is composed of 7 elements: 933 - Field ID: The header field to be compressed. The content is a 934 YANG identifer. 935 - Field Length : either a positive integer of a function defined 936 as a YANG id. 937 - Field Position: a positive (and possibly equal to 0) integer. 938 - Direction Indicator: a YANG identifier giving the direction. 939 - Target value: a value against which the header Field is 940 compared. 941 - Matching Operator: a YANG id giving the operation, parameters 942 may be associated to that operator. 944 - Comp./Decomp. Action: A YANG id giving the compression or 945 decompression action, parameters may be associated to that 946 action. 947 "; 948 leaf field-id { 949 type schc:fid-type; 950 mandatory true; 951 description 952 "Field ID, identify a field in the header with a YANG 953 referenceid."; 954 } 955 leaf field-length { 956 type schc:fl-type; 957 mandatory true; 958 description 959 "Field Length, expressed in number of bits or through a function defined as a 960 YANG referenceid."; 961 } 962 leaf field-position { 963 type uint8; 964 mandatory true; 965 description 966 "Field position in the header is an integer. Position 1 matches 967 the first occurence of a field in the header, while incremented 968 position values match subsequent occurences. 969 Position 0 means that this entry matches a field irrespective 970 of its position of occurence in the header. 971 Be aware that the decompressed header may have position-0 972 fields ordered differently than they appeared in the original 973 packet."; 974 } 975 leaf direction-indicator { 976 type schc:di-type; 977 mandatory true; 978 description 979 "Direction Indicator, a YANG referenceid to say if the packet 980 is bidirectional, up or down"; 981 } 982 list target-value { 983 key "position"; 984 uses tv-struct; 985 description 986 "A list of value to compare with the header field value. 987 If target value is a singleton, position must be 0. 988 For use as a matching list for the mo-match-mapping matching 989 operator, positions should take consecutive values starting 990 from 1."; 991 } 992 leaf matching-operator { 993 type schc:mo-type; 994 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 995 error-message 996 "mo-equal, mo-msb and mo-match-mapping need target-value"; 997 description 998 "target-value is not required for mo-ignore"; 999 } 1000 must "not (derived-from-or-self(., 'mo-msb')) or 1001 ../matching-operator-value" { 1002 error-message "mo-msb requires length value"; 1003 } 1004 mandatory true; 1005 description 1006 "MO: Matching Operator"; 1007 } 1008 list matching-operator-value { 1009 key "position"; 1010 uses tv-struct; 1011 description 1012 "Matching Operator Arguments, based on TV structure to allow 1013 several arguments. 1014 In RFC 8724, only the MSB matching operator needs arguments (a single argument, which is the 1015 number of most significant bits to be matched)"; 1016 } 1017 leaf comp-decomp-action { 1018 type schc:cda-type; 1019 mandatory true; 1020 description 1021 "CDA: Compression Decompression Action."; 1022 } 1023 list comp-decomp-action-value { 1024 key "position"; 1025 uses tv-struct; 1026 description 1027 "CDA arguments, based on a TV structure, in order to allow for 1028 several arguments. The CDAs specified in RFC 8724 require no 1029 argument."; 1030 } 1031 } 1033 grouping compression-content { 1034 list entry { 1035 key "field-id field-position direction-indicator"; 1036 uses compression-rule-entry; 1037 description 1038 "A compression rule is a list of rule entries, each describing 1039 a header field. An entry is identifed through a field-id, 1040 its position in the packet and its direction."; 1041 } 1042 description 1043 "Define a compression rule composed of a list of entries."; 1044 } 1046 Figure 22: Definition of a compression entry 1048 3.2. Fragmentation rule 1050 A Fragmentation rule is composed of entries describing the protocol 1051 behavior. Some on them are numerical entries, others are identifiers 1052 defined in Section 2.10. 1054 The definition of a Fragmentation rule is divided into three sub- 1055 parts (cf. figure Figure 24): 1057 * parameters such as the fragmentation-mode, the l2-word-size and 1058 the direction. Since Fragmentation rules are always defined for a 1059 specific direction, the value must be either di-up or di-down (di- 1060 bidirectional is not allowed). 1062 * parameters defining the Fragmentation header format (dtag-size, 1063 w-size, fcn-size and rcs-algorithm). 1065 * Protocol parameters for timers (inactivity-timer, retransmission- 1066 timer). [RFC8724] do not specified any range for these timers. 1067 [RFC9011] recommends a duration of 12 hours. In fact, the value 1068 range sould be between milli-seconds for real time systems to 1069 several days. Figure Figure 23 shows the two parameters defined 1070 for timers: 1072 - the duration of a tick is computed through this formula 2^tick- 1073 duration/10^6. When tick-duration is set to 0, the unit is the 1074 micro-second. The default value of 20 leads to a unit of about 1075 1.05 second. A value of 32 leads to a tick duration of about 1076 1.19 hours. 1078 - the number of ticks in the predefined unit. With the default 1079 tick-duration value of 20, the timers can cover a range between 1080 1.0 sec and 19 hours covering [RFC9011] recommandation. 1082 * Protocol behavior (maximum-packet-size, max-interleaved-frames, 1083 max-ack-requests). If these parameters are specific to a single 1084 fragmentation mode, they are grouped in a structure dedicated to 1085 that Fragmentation mode. If some parameters can be found in 1086 several modes, typically ACK-Always and ACK-on-Error, they are 1087 defined in a common part and a when statement indicates which 1088 modes are allowed. 1090 grouping timer-duration { 1091 leaf ticks-duration { 1092 type uint8; 1093 default 20; 1094 description "duration of one tick in micro-seconds, 2^ticks-duration/10^6 = 1.048s"; 1095 } 1096 leaf ticks-numbers { 1097 type uint16; 1098 description "timer duration = ticks-numbers * 2^ticks-duration / 10^6"; 1099 } 1100 } 1102 Figure 23: Timer duration values 1104 grouping fragmentation-content { 1105 description 1106 "This grouping defines the fragmentation parameters for 1107 all the modes (No-Ack, Ack-Always and Ack-on-Error) specified in 1108 RFC 8724."; 1109 leaf fragmentation-mode { 1110 type schc:fragmentation-mode-type; 1111 mandatory true; 1112 description 1113 "which fragmentation mode is used (noAck, AckAlways, 1114 AckonError)"; 1115 } 1116 leaf l2-word-size { 1117 type uint8; 1118 default "8"; 1119 description 1120 "Size, in bits, of the layer 2 word"; 1121 } 1122 leaf direction { 1123 type schc:di-type; 1124 must "derived-from-or-self(., 'di-up') or 1125 derived-from-or-self(., 'di-down')" { 1126 error-message 1127 "direction for fragmentation rules are up or down."; 1128 } 1129 mandatory true; 1130 description 1131 "Should be up or down, bidirectionnal is forbiden."; 1132 } 1133 // SCHC Frag header format 1134 leaf dtag-size { 1135 type uint8; 1136 default "0"; 1137 description 1138 "Size, in bits, of the DTag field (T variable from RFC8724)."; 1139 } 1140 leaf w-size { 1141 when "derived-from(../fragmentation-mode, 1142 'fragmentation-mode-ack-on-error') 1143 or 1144 derived-from(../fragmentation-mode, 1145 'fragmentation-mode-ack-always') "; 1146 type uint8; 1147 description 1148 "Size, in bits, of the window field (M variable from RFC8724)."; 1149 } 1150 leaf fcn-size { 1151 type uint8; 1152 mandatory true; 1153 description 1154 "Size, in bits, of the FCN field (N variable from RFC8724)."; 1155 } 1156 leaf rcs-algorithm { 1157 type rcs-algorithm-type; 1158 default "schc:rcs-RFC8724"; 1159 description 1160 "Algorithm used for RCS. The algorithm specifies the RCS size"; 1161 } 1162 // SCHC fragmentation protocol parameters 1163 leaf maximum-packet-size { 1164 type uint16; 1165 default "1280"; 1166 description 1167 "When decompression is done, packet size must not 1168 strictly exceed this limit, expressed in bytes."; 1169 } 1170 leaf window-size { 1171 type uint16; 1172 description 1173 "By default, if not specified 2^w-size - 1. Should not exceed 1174 this value. Possible FCN values are between 0 and 1175 window-size - 1."; 1176 } 1177 leaf max-interleaved-frames { 1178 type uint8; 1179 default "1"; 1180 description 1181 "Maximum of simultaneously fragmented frames. Maximum value is 1182 2^dtag-size. All DTAG values can be used, but at most 1183 max-interleaved-frames must be active at any time."; 1184 } 1185 leaf inactivity-timer { 1186 type uint64; 1187 description 1188 "Duration is seconds of the inactivity timer, 0 indicates 1189 that the timer is disabled."; 1190 } 1191 leaf retransmission-timer { 1192 when "derived-from(../fragmentation-mode, 1193 'fragmentation-mode-ack-on-error') 1194 or 1195 derived-from(../fragmentation-mode, 1196 'fragmentation-mode-ack-always') "; 1197 type uint64 { 1198 range "1..max"; 1199 } 1200 description 1201 "Duration in seconds of the retransmission timer."; 1202 } 1203 leaf max-ack-requests { 1204 when "derived-from(../fragmentation-mode, 1205 'fragmentation-mode-ack-on-error') 1206 or 1207 derived-from(../fragmentation-mode, 1208 'fragmentation-mode-ack-always') "; 1209 type uint8 { 1210 range "1..max"; 1211 } 1212 description 1213 "The maximum number of retries for a specific SCHC ACK."; 1214 } 1215 choice mode { 1216 case no-ack; 1217 case ack-always; 1218 case ack-on-error { 1219 leaf tile-size { 1220 when "derived-from(../fragmentation-mode, 1221 'fragmentation-mode-ack-on-error')"; 1222 type uint8; 1223 description 1224 "Size, in bits, of tiles. If not specified or set to 0, 1225 tiles fill the fragment."; 1227 } 1228 leaf tile-in-All1 { 1229 when "derived-from(../fragmentation-mode, 1230 'fragmentation-mode-ack-on-error')"; 1231 type schc:all1-data-type; 1232 description 1233 "Defines whether the sender and receiver expect a tile in 1234 All-1 fragments or not, or if it is left to the sender's 1235 choice."; 1236 } 1237 leaf ack-behavior { 1238 when "derived-from(../fragmentation-mode, 1239 'fragmentation-mode-ack-on-error')"; 1240 type schc:ack-behavior-type; 1241 description 1242 "Sender behavior to acknowledge, after All-0, All-1 or 1243 when the LPWAN allows it."; 1244 } 1245 } 1246 description 1247 "RFC 8724 defines 3 fragmentation modes."; 1248 } 1249 } 1251 Figure 24: Fragmentation Parameters 1253 3.3. YANG Tree 1255 module: ietf-schc 1256 +--rw schc 1257 +--rw rule* [rule-id-value rule-id-length] 1258 +--rw rule-id-value uint32 1259 +--rw rule-id-length uint8 1260 +--rw (nature)? 1261 +--:(fragmentation) {fragmentation}? 1262 | +--rw fragmentation-mode schc:fragmentation-mode-type 1263 | +--rw l2-word-size? uint8 1264 | +--rw direction schc:di-type 1265 | +--rw dtag-size? uint8 1266 | +--rw w-size? uint8 1267 | +--rw fcn-size uint8 1268 | +--rw rcs-algorithm? rcs-algorithm-type 1269 | +--rw maximum-packet-size? uint16 1270 | +--rw window-size? uint16 1271 | +--rw max-interleaved-frames? uint8 1272 | +--rw inactivity-timer 1273 | | +--rw ticks-duration? uint8 1274 | | +--rw ticks-numbers? uint16 1275 | +--rw retransmission-timer 1276 | | +--rw ticks-duration? uint8 1277 | | +--rw ticks-numbers? uint16 1278 | +--rw max-ack-requests? uint8 1279 | +--rw (mode)? 1280 | +--:(no-ack) 1281 | +--:(ack-always) 1282 | +--:(ack-on-error) 1283 | +--rw tile-size? uint8 1284 | +--rw tile-in-All1? schc:all1-data-type 1285 | +--rw ack-behavior? schc:ack-behavior-type 1286 +--:(compression) {compression}? 1287 | +--rw entry* [field-id field-position direction-indicator] 1288 | +--rw field-id schc:fid-type 1289 | +--rw field-length schc:fl-type 1290 | +--rw field-position uint8 1291 | +--rw direction-indicator schc:di-type 1292 | +--rw target-value* [indicia] 1293 | | +--rw value? binary 1294 | | +--rw indicia uint16 1295 | +--rw matching-operator schc:mo-type 1296 | +--rw matching-operator-value* [indicia] 1297 | | +--rw value? binary 1298 | | +--rw indicia uint16 1299 | +--rw comp-decomp-action schc:cda-type 1300 | +--rw comp-decomp-action-value* [indicia] 1301 | +--rw value? binary 1302 | +--rw indicia uint16 1303 +--:(no-compression) 1305 Figure 25 1307 4. IANA Considerations 1309 This document has no request to IANA. 1311 5. Security considerations 1313 This document does not have any more Security consideration than the 1314 ones already raised in [RFC8724] and [RFC8824]. 1316 6. Acknowledgements 1318 The authors would like to thank Dominique Barthel, Carsten Bormann, 1319 Alexander Pelov for their careful reading and valuable inputs. A 1320 special thanks for Carl Moberg for his patience and wise advices when 1321 building the model. 1323 7. YANG Module 1325 file ietf-schc@2022-02-15.yang 1326 module ietf-schc { 1327 yang-version 1.1; 1328 namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; 1329 prefix schc; 1331 organization 1332 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; 1333 contact 1334 "WG Web: 1335 WG List: 1336 Editor: Laurent Toutain 1337 1338 Editor: Ana Minaburo 1339 "; 1340 description 1341 " 1342 Copyright (c) 2021 IETF Trust and the persons identified as 1343 authors of the code. All rights reserved. 1345 Redistribution and use in source and binary forms, with or 1346 without modification, is permitted pursuant to, and subject to 1347 the license terms contained in, the Simplified BSD License set 1348 forth in Section 4.c of the IETF Trust's Legal Provisions 1349 Relating to IETF Documents 1350 (https://trustee.ietf.org/license-info). 1352 This version of this YANG module is part of RFC XXXX 1353 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1354 for full legal notices. 1356 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1357 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1358 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1359 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1360 they appear in all capitals, as shown here. 1362 ***************************************************************** 1364 Generic Data model for Static Context Header Compression Rule for 1365 SCHC, based on RFC 8724 and RFC8824. Include compression, no 1366 compression and fragmentation rules. 1368 This module is a YANG model for SCHC rules (RFC 8724 and RFC8824). 1369 RFC 8724 describes compression rules in a abstract way through a 1370 table. 1372 |-----------------------------------------------------------------| 1373 | (FID) Rule 1 | 1374 |+-------+--+--+--+------------+-----------------+---------------+| 1375 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1376 |+-------+--+--+--+------------+-----------------+---------------+| 1377 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1378 |+-------+--+--+--+------------+-----------------+---------------+| 1379 ||... |..|..|..| ... | ... | ... || 1380 |+-------+--+--+--+------------+-----------------+---------------+| 1381 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1382 +-------+--+--+--+------------+-----------------+---------------+|| 1383 |-----------------------------------------------------------------| 1385 This module proposes a global data model that can be used for rule 1386 exchanges or modification. It proposes both the data model format 1387 and the global identifiers used to describe some operations in 1388 fields. 1389 This data model applies to both compression and fragmentation."; 1391 revision 2022-02-15 { 1392 description 1393 "Initial version from RFC XXXX "; 1394 reference 1395 "RFC XXX: Data Model for Static Context Header Compression 1396 (SCHC)"; 1397 } 1399 feature compression { 1400 description 1401 "SCHC compression capabilities are taken into account"; 1402 } 1404 feature fragmentation { 1405 description 1406 "SCHC fragmentation capabilities are taken into account"; 1407 } 1409 // ------------------------- 1410 // Field ID type definition 1411 //-------------------------- 1412 // generic value TV definition 1414 identity fid-base-type { 1415 description 1416 "Field ID base type for all fields"; 1417 } 1419 identity fid-ipv6-base-type { 1420 base fid-base-type; 1421 description 1422 "Field ID base type for IPv6 headers described in RFC 8200"; 1423 } 1425 identity fid-ipv6-version { 1426 base fid-ipv6-base-type; 1427 description 1428 "IPv6 version field from RFC8200"; 1429 } 1431 identity fid-ipv6-trafficclass { 1432 base fid-ipv6-base-type; 1433 description 1434 "IPv6 Traffic Class field from RFC8200"; 1435 } 1437 identity fid-ipv6-trafficclass-ds { 1438 base fid-ipv6-trafficclass; 1439 description 1440 "IPv6 Traffic Class field from RFC8200, 1441 DiffServ field from RFC3168"; 1442 } 1444 identity fid-ipv6-trafficclass-ecn { 1445 base fid-ipv6-trafficclass; 1446 description 1447 "IPv6 Traffic Class field from RFC8200, 1448 ECN field from RFC3168"; 1449 } 1451 identity fid-ipv6-flowlabel { 1452 base fid-ipv6-base-type; 1453 description 1454 "IPv6 Flow Label field from RFC8200"; 1455 } 1457 identity fid-ipv6-payloadlength { 1458 base fid-ipv6-base-type; 1459 description 1460 "IPv6 Payload Length field from RFC8200"; 1461 } 1463 identity fid-ipv6-nextheader { 1464 base fid-ipv6-base-type; 1465 description 1466 "IPv6 Next Header field from RFC8200"; 1467 } 1468 identity fid-ipv6-hoplimit { 1469 base fid-ipv6-base-type; 1470 description 1471 "IPv6 Next Header field from RFC8200"; 1472 } 1474 identity fid-ipv6-devprefix { 1475 base fid-ipv6-base-type; 1476 description 1477 "corresponds to either the source address or the destination 1478 address prefix of RFC 8200. Depending if it is 1479 respectively an uplink or a downlink message."; 1480 } 1482 identity fid-ipv6-deviid { 1483 base fid-ipv6-base-type; 1484 description 1485 "corresponds to either the source address or the destination 1486 address prefix of RFC 8200. Depending if it is respectively 1487 an uplink or a downlink message."; 1488 } 1490 identity fid-ipv6-appprefix { 1491 base fid-ipv6-base-type; 1492 description 1493 "corresponds to either the source address or the destination 1494 address prefix of RFC 8200. Depending if it is respectively 1495 a downlink or an uplink message."; 1496 } 1498 identity fid-ipv6-appiid { 1499 base fid-ipv6-base-type; 1500 description 1501 "corresponds to either the source address or the destination 1502 address prefix of RFC 8200. Depending if it is respectively 1503 a downlink or an uplink message."; 1504 } 1506 identity fid-udp-base-type { 1507 base fid-base-type; 1508 description 1509 "Field ID base type for UDP headers described in RFC 768"; 1510 } 1512 identity fid-udp-dev-port { 1513 base fid-udp-base-type; 1514 description 1515 "UDP source or destination port from RFC 768, if uplink or 1516 downlink communication, respectively."; 1517 } 1519 identity fid-udp-app-port { 1520 base fid-udp-base-type; 1521 description 1522 "UDP destination or source port from RFC 768, if uplink or 1523 downlink communication, respectively."; 1524 } 1526 identity fid-udp-length { 1527 base fid-udp-base-type; 1528 description 1529 "UDP length from RFC 768"; 1530 } 1532 identity fid-udp-checksum { 1533 base fid-udp-base-type; 1534 description 1535 "UDP length from RFC 768"; 1536 } 1538 identity fid-coap-base-type { 1539 base fid-base-type; 1540 description 1541 "Field ID base type for UDP headers described in RFC 7252"; 1542 } 1544 identity fid-coap-version { 1545 base fid-coap-base-type; 1546 description 1547 "CoAP version from RFC 7252"; 1548 } 1550 identity fid-coap-type { 1551 base fid-coap-base-type; 1552 description 1553 "CoAP type from RFC 7252"; 1554 } 1556 identity fid-coap-tkl { 1557 base fid-coap-base-type; 1558 description 1559 "CoAP token length from RFC 7252"; 1560 } 1562 identity fid-coap-code { 1563 base fid-coap-base-type; 1564 description 1565 "CoAP code from RFC 7252"; 1566 } 1568 identity fid-coap-code-class { 1569 base fid-coap-code; 1570 description 1571 "CoAP code class from RFC 7252"; 1572 } 1574 identity fid-coap-code-detail { 1575 base fid-coap-code; 1576 description 1577 "CoAP code detail from RFC 7252"; 1578 } 1580 identity fid-coap-mid { 1581 base fid-coap-base-type; 1582 description 1583 "CoAP message ID from RFC 7252"; 1584 } 1586 identity fid-coap-token { 1587 base fid-coap-base-type; 1588 description 1589 "CoAP token from RFC 7252"; 1590 } 1592 identity fid-coap-option-if-match { 1593 base fid-coap-base-type; 1594 description 1595 "CoAP option If-Match from RFC 7252"; 1596 } 1598 identity fid-coap-option-uri-host { 1599 base fid-coap-base-type; 1600 description 1601 "CoAP option URI-Host from RFC 7252"; 1602 } 1604 identity fid-coap-option-etag { 1605 base fid-coap-base-type; 1606 description 1607 "CoAP option Etag from RFC 7252"; 1608 } 1610 identity fid-coap-option-if-none-match { 1611 base fid-coap-base-type; 1612 description 1613 "CoAP option if-none-match from RFC 7252"; 1614 } 1616 identity fid-coap-option-observe { 1617 base fid-coap-base-type; 1618 description 1619 "CoAP option Observe from RFC 7641"; 1620 } 1622 identity fid-coap-option-uri-port { 1623 base fid-coap-base-type; 1624 description 1625 "CoAP option Uri-Port from RFC 7252"; 1626 } 1628 identity fid-coap-option-location-path { 1629 base fid-coap-base-type; 1630 description 1631 "CoAP option Location-Path from RFC 7252"; 1632 } 1634 identity fid-coap-option-uri-path { 1635 base fid-coap-base-type; 1636 description 1637 "CoAP option Uri-Path from RFC 7252"; 1638 } 1640 identity fid-coap-option-content-format { 1641 base fid-coap-base-type; 1642 description 1643 "CoAP option Content Format from RFC 7252"; 1644 } 1646 identity fid-coap-option-max-age { 1647 base fid-coap-base-type; 1648 description 1649 "CoAP option Max-Age from RFC 7252"; 1650 } 1652 identity fid-coap-option-uri-query { 1653 base fid-coap-base-type; 1654 description 1655 "CoAP option Uri-Query from RFC 7252"; 1656 } 1658 identity fid-coap-option-accept { 1659 base fid-coap-base-type; 1660 description 1661 "CoAP option Accept from RFC 7252"; 1662 } 1664 identity fid-coap-option-location-query { 1665 base fid-coap-base-type; 1666 description 1667 "CoAP option Location-Query from RFC 7252"; 1668 } 1670 identity fid-coap-option-block2 { 1671 base fid-coap-base-type; 1672 description 1673 "CoAP option Block2 from RFC 7959"; 1674 } 1676 identity fid-coap-option-block1 { 1677 base fid-coap-base-type; 1678 description 1679 "CoAP option Block1 from RFC 7959"; 1680 } 1682 identity fid-coap-option-size2 { 1683 base fid-coap-base-type; 1684 description 1685 "CoAP option size2 from RFC 7959"; 1686 } 1688 identity fid-coap-option-proxy-uri { 1689 base fid-coap-base-type; 1690 description 1691 "CoAP option Proxy-Uri from RFC 7252"; 1692 } 1694 identity fid-coap-option-proxy-scheme { 1695 base fid-coap-base-type; 1696 description 1697 "CoAP option Proxy-scheme from RFC 7252"; 1698 } 1700 identity fid-coap-option-size1 { 1701 base fid-coap-base-type; 1702 description 1703 "CoAP option Size1 from RFC 7252"; 1704 } 1706 identity fid-coap-option-no-response { 1707 base fid-coap-base-type; 1708 description 1709 "CoAP option No response from RFC 7967"; 1710 } 1712 identity fid-coap-option-oscore-flags { 1713 base fid-coap-base-type; 1714 description 1715 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1716 } 1718 identity fid-coap-option-oscore-piv { 1719 base fid-coap-base-type; 1720 description 1721 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1722 } 1724 identity fid-coap-option-oscore-kid { 1725 base fid-coap-base-type; 1726 description 1727 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1728 } 1730 identity fid-coap-option-oscore-kidctx { 1731 base fid-coap-base-type; 1732 description 1733 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1734 } 1736 //---------------------------------- 1737 // Field Length type definition 1738 //---------------------------------- 1740 identity fl-base-type { 1741 description 1742 "Used to extend field length functions."; 1743 } 1745 identity fl-variable { 1746 base fl-base-type; 1747 description 1748 "Residue length in Byte is sent as defined 1749 for CoAP in RFC 8824 (cf. 5.3)."; 1750 } 1752 identity fl-token-length { 1753 base fl-base-type; 1754 description 1755 "Residue length in Byte is sent as defined 1756 for CoAP in RFC 8824 (cf. 4.5)."; 1757 } 1759 //--------------------------------- 1760 // Direction Indicator type 1761 //--------------------------------- 1763 identity di-base-type { 1764 description 1765 "Used to extend direction indicators."; 1766 } 1768 identity di-bidirectional { 1769 base di-base-type; 1770 description 1771 "Direction Indication of bidirectionality in 1772 RFC 8724 (cf. 7.1)."; 1773 } 1775 identity di-up { 1776 base di-base-type; 1777 description 1778 "Direction Indication of uplink defined in 1779 RFC 8724 (cf. 7.1)."; 1780 } 1782 identity di-down { 1783 base di-base-type; 1784 description 1785 "Direction Indication of downlink defined in 1786 RFC 8724 (cf. 7.1)."; 1787 } 1789 //---------------------------------- 1790 // Matching Operator type definition 1791 //---------------------------------- 1793 identity mo-base-type { 1794 description 1795 "Used to extend Matching Operators with SID values"; 1796 } 1798 identity mo-equal { 1799 base mo-base-type; 1800 description 1801 "Equal MO as defined in RFC 8724 (cf. 7.3)"; 1802 } 1803 identity mo-ignore { 1804 base mo-base-type; 1805 description 1806 "Ignore MO as defined in RFC 8724 (cf. 7.3)"; 1807 } 1809 identity mo-msb { 1810 base mo-base-type; 1811 description 1812 "MSB MO as defined in RFC 8724 (cf. 7.3)"; 1813 } 1815 identity mo-match-mapping { 1816 base mo-base-type; 1817 description 1818 "match-mapping MO as defined in RFC 8724 (cf. 7.3)"; 1819 } 1821 //------------------------------ 1822 // CDA type definition 1823 //------------------------------ 1825 identity cda-base-type { 1826 description 1827 "Compression Decompression Actions."; 1828 } 1830 identity cda-not-sent { 1831 base cda-base-type; 1832 description 1833 "not-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1834 } 1836 identity cda-value-sent { 1837 base cda-base-type; 1838 description 1839 "value-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1840 } 1842 identity cda-lsb { 1843 base cda-base-type; 1844 description 1845 "LSB CDA as defined in RFC 8724 (cf. 7.4)."; 1846 } 1848 identity cda-mapping-sent { 1849 base cda-base-type; 1850 description 1851 "mapping-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1852 } 1854 identity cda-compute { 1855 base cda-base-type; 1856 description 1857 "compute-length CDA as defined in RFC 8724 (cf. 7.4)"; 1858 } 1860 identity cda-deviid { 1861 base cda-base-type; 1862 description 1863 "deviid CDA as defined in RFC 8724 (cf. 7.4)"; 1864 } 1866 identity cda-appiid { 1867 base cda-base-type; 1868 description 1869 "appiid CDA as defined in RFC 8724 (cf. 7.4)"; 1870 } 1872 // -- type definition 1874 typedef fid-type { 1875 type identityref { 1876 base fid-base-type; 1877 } 1878 description 1879 "Field ID generic type."; 1880 } 1882 typedef fl-type { 1883 type union { 1884 type int64; /* positive integer, expressing length in bits */ 1885 type identityref { /* function */ 1886 base fl-base-type; 1887 } 1888 } 1889 description 1890 "Field length either a positive integer expressing the size in 1891 bits or a function defined through an identityref."; 1892 } 1894 typedef di-type { 1895 type identityref { 1896 base di-base-type; 1897 } 1898 description 1899 "Direction in LPWAN network, up when emitted by the device, 1900 down when received by the device, bi when emitted or 1901 received by the device."; 1902 } 1904 typedef mo-type { 1905 type identityref { 1906 base mo-base-type; 1907 } 1908 description 1909 "Matching Operator (MO) to compare fields values with 1910 target values"; 1911 } 1913 typedef cda-type { 1914 type identityref { 1915 base cda-base-type; 1916 } 1917 description 1918 "Compression Decompression Action to compression or 1919 decompress a field."; 1920 } 1922 // -- FRAGMENTATION TYPE 1923 // -- fragmentation modes 1925 identity fragmentation-mode-base-type { 1926 description 1927 "fragmentation mode."; 1928 } 1930 identity fragmentation-mode-no-ack { 1931 base fragmentation-mode-base-type; 1932 description 1933 "No-ACK of RFC8724."; 1934 } 1936 identity fragmentation-mode-ack-always { 1937 base fragmentation-mode-base-type; 1938 description 1939 "ACK-Always of RFC8724."; 1940 } 1942 identity fragmentation-mode-ack-on-error { 1943 base fragmentation-mode-base-type; 1944 description 1945 "ACK-on-Error of RFC8724."; 1946 } 1947 typedef fragmentation-mode-type { 1948 type identityref { 1949 base fragmentation-mode-base-type; 1950 } 1951 description 1952 "type used in rules"; 1953 } 1955 // -- Ack behavior 1957 identity ack-behavior-base-type { 1958 description 1959 "Define when to send an Acknowledgment ."; 1960 } 1962 identity ack-behavior-after-All0 { 1963 base ack-behavior-base-type; 1964 description 1965 "Fragmentation expects Ack after sending All0 fragment."; 1966 } 1968 identity ack-behavior-after-All1 { 1969 base ack-behavior-base-type; 1970 description 1971 "Fragmentation expects Ack after sending All1 fragment."; 1972 } 1974 identity ack-behavior-by-layer2 { 1975 base ack-behavior-base-type; 1976 description 1977 "Layer 2 defines when to send an Ack."; 1978 } 1980 typedef ack-behavior-type { 1981 type identityref { 1982 base ack-behavior-base-type; 1983 } 1984 description 1985 "Type used in rules."; 1986 } 1988 // -- All1 with data types 1990 identity all1-data-base-type { 1991 description 1992 "Type to define when to send an Acknowledgment message."; 1993 } 1994 identity all1-data-no { 1995 base all1-data-base-type; 1996 description 1997 "All1 contains no tiles."; 1998 } 2000 identity all1-data-yes { 2001 base all1-data-base-type; 2002 description 2003 "All1 MUST contain a tile."; 2004 } 2006 identity all1-data-sender-choice { 2007 base all1-data-base-type; 2008 description 2009 "Fragmentation process chooses to send tiles or not in all1."; 2010 } 2012 typedef all1-data-type { 2013 type identityref { 2014 base all1-data-base-type; 2015 } 2016 description 2017 "Type used in rules."; 2018 } 2020 // -- RCS algorithm types 2022 identity rcs-algorithm-base-type { 2023 description 2024 "Identify which algorithm is used to compute RCS. 2025 The algorithm also defines the size of the RCS field."; 2026 } 2028 identity rcs-RFC8724 { 2029 base rcs-algorithm-base-type; 2030 description 2031 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 2032 } 2034 typedef rcs-algorithm-type { 2035 type identityref { 2036 base rcs-algorithm-base-type; 2037 } 2038 description 2039 "type used in rules."; 2040 } 2041 // --------- TIMER DURATION ------------------- 2043 grouping timer-duration { 2044 leaf ticks-duration { 2045 type uint8; 2046 default 20; 2047 description "duration of one tick in micro-seconds, 2^ticks-duration/10^6 = 1.048s"; 2048 } 2049 leaf ticks-numbers { 2050 type uint16; 2051 description "timer duration = ticks-numbers * 2^ticks / 10^6"; 2052 } 2053 } 2055 // -------- RULE ENTRY DEFINITION ------------ 2057 grouping tv-struct { 2058 description 2059 "Defines the target value element. Always a binary type, strings 2060 must be converted to binary. field-id allows the conversion 2061 to the appropriate type."; 2062 leaf value { 2063 type binary; 2064 description 2065 "Target Value"; 2066 } 2067 leaf indicia { 2068 type uint16; 2069 description 2070 "Indicia gives the position in the matching-list. If only one 2071 element is present, indicia is 0. Otherwise, indicia is the 2072 the order in the matching list, starting at 0."; 2073 } 2074 } 2076 grouping compression-rule-entry { 2077 description 2078 "These entries defines a compression entry (i.e. a line) 2079 as defined in RFC 8724. 2081 +-------+--+--+--+------------+-----------------+---------------+ 2082 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 2083 +-------+--+--+--+------------+-----------------+---------------+ 2085 An entry in a compression rule is composed of 7 elements: 2086 - Field ID: The header field to be compressed. The content is a 2087 YANG identifer. 2088 - Field Length : either a positive integer of a function defined 2089 as a YANG id. 2090 - Field Position: a positive (and possibly equal to 0) integer. 2091 - Direction Indicator: a YANG identifier giving the direction. 2092 - Target value: a value against which the header Field is 2093 compared. 2094 - Matching Operator: a YANG id giving the operation, parameters 2095 may be associated to that operator. 2096 - Comp./Decomp. Action: A YANG id giving the compression or 2097 decompression action, parameters may be associated to that 2098 action. 2099 "; 2100 leaf field-id { 2101 type schc:fid-type; 2102 mandatory true; 2103 description 2104 "Field ID, identify a field in the header with a YANG 2105 referenceid."; 2106 } 2107 leaf field-length { 2108 type schc:fl-type; 2109 mandatory true; 2110 description 2111 "Field Length, expressed in number of bits or through a function defined as a 2112 YANG referenceid."; 2113 } 2114 leaf field-position { 2115 type uint8; 2116 mandatory true; 2117 description 2118 "Field position in the header is an integer. Position 1 matches 2119 the first occurence of a field in the header, while incremented 2120 position values match subsequent occurences. 2121 Position 0 means that this entry matches a field irrespective 2122 of its position of occurence in the header. 2123 Be aware that the decompressed header may have position-0 2124 fields ordered differently than they appeared in the original 2125 packet."; 2126 } 2127 leaf direction-indicator { 2128 type schc:di-type; 2129 mandatory true; 2130 description 2131 "Direction Indicator, a YANG referenceid to say if the packet 2132 is bidirectional, up or down"; 2133 } 2134 list target-value { 2135 key "indicia"; 2136 uses tv-struct; 2137 description 2138 "A list of value to compare with the header field value. 2139 If target value is a singleton, position must be 0. 2140 For use as a matching list for the mo-match-mapping matching 2141 operator, positions should take consecutive values starting 2142 from 1."; 2143 } 2144 leaf matching-operator { 2145 type schc:mo-type; 2146 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 2147 error-message 2148 "mo-equal, mo-msb and mo-match-mapping need target-value"; 2149 description 2150 "target-value is not required for mo-ignore"; 2151 } 2152 must "not (derived-from-or-self(., 'mo-msb')) or 2153 ../matching-operator-value" { 2154 error-message "mo-msb requires length value"; 2155 } 2156 mandatory true; 2157 description 2158 "MO: Matching Operator"; 2159 } 2160 list matching-operator-value { 2161 key "indicia"; 2162 uses tv-struct; 2163 description 2164 "Matching Operator Arguments, based on TV structure to allow 2165 several arguments. 2166 In RFC 8724, only the MSB matching operator needs arguments (a single argument, which is the 2167 number of most significant bits to be matched)"; 2168 } 2169 leaf comp-decomp-action { 2170 type schc:cda-type; 2171 mandatory true; 2172 description 2173 "CDA: Compression Decompression Action."; 2174 } 2175 list comp-decomp-action-value { 2176 key "indicia"; 2177 uses tv-struct; 2178 description 2179 "CDA arguments, based on a TV structure, in order to allow for 2180 several arguments. The CDAs specified in RFC 8724 require no 2181 argument."; 2182 } 2183 } 2184 grouping compression-content { 2185 list entry { 2186 key "field-id field-position direction-indicator"; 2187 uses compression-rule-entry; 2188 description 2189 "A compression rule is a list of rule entries, each describing 2190 a header field. An entry is identifed through a field-id, 2191 its position in the packet and its direction."; 2192 } 2193 description 2194 "Define a compression rule composed of a list of entries."; 2195 } 2197 grouping fragmentation-content { 2198 description 2199 "This grouping defines the fragmentation parameters for 2200 all the modes (No-Ack, Ack-Always and Ack-on-Error) specified in 2201 RFC 8724."; 2202 leaf fragmentation-mode { 2203 type schc:fragmentation-mode-type; 2204 mandatory true; 2205 description 2206 "which fragmentation mode is used (noAck, AckAlways, 2207 AckonError)"; 2208 } 2209 leaf l2-word-size { 2210 type uint8; 2211 default "8"; 2212 description 2213 "Size, in bits, of the layer 2 word"; 2214 } 2215 leaf direction { 2216 type schc:di-type; 2217 must "derived-from-or-self(., 'di-up') or 2218 derived-from-or-self(., 'di-down')" { 2219 error-message 2220 "direction for fragmentation rules are up or down."; 2221 } 2222 mandatory true; 2223 description 2224 "Should be up or down, bidirectionnal is forbiden."; 2225 } 2226 // SCHC Frag header format 2227 leaf dtag-size { 2228 type uint8; 2229 default "0"; 2230 description 2231 "Size, in bits, of the DTag field (T variable from RFC8724)."; 2233 } 2234 leaf w-size { 2235 when "derived-from(../fragmentation-mode, 2236 'fragmentation-mode-ack-on-error') 2237 or 2238 derived-from(../fragmentation-mode, 2239 'fragmentation-mode-ack-always') "; 2240 type uint8; 2241 description 2242 "Size, in bits, of the window field (M variable from RFC8724)."; 2243 } 2244 leaf fcn-size { 2245 type uint8; 2246 mandatory true; 2247 description 2248 "Size, in bits, of the FCN field (N variable from RFC8724)."; 2249 } 2250 leaf rcs-algorithm { 2251 type rcs-algorithm-type; 2252 default "schc:rcs-RFC8724"; 2253 description 2254 "Algorithm used for RCS. The algorithm specifies the RCS size"; 2255 } 2256 // SCHC fragmentation protocol parameters 2257 leaf maximum-packet-size { 2258 type uint16; 2259 default "1280"; 2260 description 2261 "When decompression is done, packet size must not 2262 strictly exceed this limit, expressed in bytes."; 2263 } 2264 leaf window-size { 2265 type uint16; 2266 description 2267 "By default, if not specified 2^w-size - 1. Should not exceed 2268 this value. Possible FCN values are between 0 and 2269 window-size - 1."; 2270 } 2271 leaf max-interleaved-frames { 2272 type uint8; 2273 default "1"; 2274 description 2275 "Maximum of simultaneously fragmented frames. Maximum value is 2276 2^dtag-size. All DTAG values can be used, but at most 2277 max-interleaved-frames must be active at any time."; 2278 } 2279 container inactivity-timer { 2280 uses timer-duration; 2281 description 2282 "Duration is seconds of the inactivity timer, 0 indicates 2283 that the timer is disabled."; 2284 } 2285 container retransmission-timer { 2286 uses timer-duration; 2287 when "derived-from(../fragmentation-mode, 2288 'fragmentation-mode-ack-on-error') 2289 or 2290 derived-from(../fragmentation-mode, 2291 'fragmentation-mode-ack-always') "; 2292 description 2293 "Duration in seconds of the retransmission timer."; 2294 } 2295 leaf max-ack-requests { 2296 when "derived-from(../fragmentation-mode, 2297 'fragmentation-mode-ack-on-error') 2298 or 2299 derived-from(../fragmentation-mode, 2300 'fragmentation-mode-ack-always') "; 2301 type uint8 { 2302 range "1..max"; 2303 } 2304 description 2305 "The maximum number of retries for a specific SCHC ACK."; 2306 } 2307 choice mode { 2308 case no-ack; 2309 case ack-always; 2310 case ack-on-error { 2311 leaf tile-size { 2312 when "derived-from(../fragmentation-mode, 2313 'fragmentation-mode-ack-on-error')"; 2314 type uint8; 2315 description 2316 "Size, in bits, of tiles. If not specified or set to 0, 2317 tiles fill the fragment."; 2318 } 2319 leaf tile-in-All1 { 2320 when "derived-from(../fragmentation-mode, 2321 'fragmentation-mode-ack-on-error')"; 2322 type schc:all1-data-type; 2323 description 2324 "Defines whether the sender and receiver expect a tile in 2325 All-1 fragments or not, or if it is left to the sender's 2326 choice."; 2327 } 2328 leaf ack-behavior { 2329 when "derived-from(../fragmentation-mode, 2330 'fragmentation-mode-ack-on-error')"; 2331 type schc:ack-behavior-type; 2332 description 2333 "Sender behavior to acknowledge, after All-0, All-1 or 2334 when the LPWAN allows it."; 2335 } 2336 } 2337 description 2338 "RFC 8724 defines 3 fragmentation modes."; 2339 } 2340 } 2342 // Define rule ID. Rule ID is composed of a RuleID value and a 2343 // Rule ID Length 2345 grouping rule-id-type { 2346 leaf rule-id-value { 2347 type uint32; 2348 description 2349 "Rule ID value, this value must be unique, considering its 2350 length."; 2351 } 2352 leaf rule-id-length { 2353 type uint8 { 2354 range "0..32"; 2355 } 2356 description 2357 "Rule ID length, in bits. The value 0 is for implicit rules."; 2358 } 2359 description 2360 "A rule ID is composed of a value and a length, expressed in 2361 bits."; 2362 } 2364 // SCHC table for a specific device. 2366 container schc { 2367 list rule { 2368 key "rule-id-value rule-id-length"; 2369 uses rule-id-type; 2370 choice nature { 2371 case fragmentation { 2372 if-feature "fragmentation"; 2373 uses fragmentation-content; 2374 } 2375 case compression { 2376 if-feature "compression"; 2377 uses compression-content; 2378 } 2379 case no-compression { 2380 description 2381 "RFC8724 requires a rule for uncompressed headers."; 2382 } 2383 description 2384 "A rule is for compression, for no-compression or for 2385 fragmentation."; 2386 } 2387 description 2388 "Set of rules compression, no compression or fragmentation 2389 rules identified by their rule-id."; 2390 } 2391 description 2392 "a SCHC set of rules is composed of a list of rules which are 2393 used for compression, no-compression or fragmentation."; 2394 } 2395 } 2396 2398 Figure 26 2400 8. Normative References 2402 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2403 Zuniga, "SCHC: Generic Framework for Static Context Header 2404 Compression and Fragmentation", RFC 8724, 2405 DOI 10.17487/RFC8724, April 2020, 2406 . 2408 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 2409 Context Header Compression (SCHC) for the Constrained 2410 Application Protocol (CoAP)", RFC 8824, 2411 DOI 10.17487/RFC8824, June 2021, 2412 . 2414 [RFC9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context 2415 Header Compression and Fragmentation (SCHC) over LoRaWAN", 2416 RFC 9011, DOI 10.17487/RFC9011, April 2021, 2417 . 2419 Authors' Addresses 2420 Ana Minaburo 2421 Acklio 2422 1137A avenue des Champs Blancs 2423 35510 Cesson-Sevigne Cedex 2424 France 2425 Email: ana@ackl.io 2427 Laurent Toutain 2428 Institut MINES TELECOM; IMT Atlantique 2429 2 rue de la Chataigneraie 2430 CS 17607 2431 35576 Cesson-Sevigne Cedex 2432 France 2433 Email: Laurent.Toutain@imt-atlantique.fr