idnits 2.17.1 draft-ietf-lpwan-schc-yang-data-model-07.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 is 1 instance of too long lines in the document, the longest one being 2 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 233: '...or this protocol MUST derive from the ...' RFC 2119 keyword, line 697: '... "All1 MUST contain a tile.";...' RFC 2119 keyword, line 1960: '... "All1 MUST contain a tile.";...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1243 has weird spacing: '...osition uin...' == Line 1247 has weird spacing: '...osition uin...' == Line 1251 has weird spacing: '...osition uin...' -- The document date (28 February 2022) is 760 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: 1 September 2022 Institut MINES TELECOM; IMT Atlantique 6 28 February 2022 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-07 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 1 September 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 . . . . . . . . . . . . . . . . . . . 23 72 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 27 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 29 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 76 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 29 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 51 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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 identity 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 RSC. 197 The algorithm also defines the size if the RSC 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] do not state how the field ID value can be 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. 230 A YANG field ID for the protocol always derives from the fid-base- 231 type. Then an identity for each protocol is specified using the 232 naming convention fid-<>-base-type. All possible 233 fields for this protocol MUST derive from the protocol identity. The 234 naming convention is "fid" followed by the protocol name and the 235 field name. If a field has to be divided into sub-fields, the field 236 identity serves as a base. 238 The full field-id definition is found in Section 7. The example 239 Figure 4 gives the first field ID definitions. A type is defined for 240 IPv6 protocol, and each field is based on it. Note that the DiffServ 241 bits derives from the Traffic Class identity. 243 identity fid-base-type { 244 description 245 "Field ID base type for all fields"; 246 } 248 identity fid-ipv6-base-type { 249 base fid-base-type; 250 description 251 "Field ID base type for IPv6 headers described in RFC 8200"; 252 } 254 identity fid-ipv6-version { 255 base fid-ipv6-base-type; 256 description 257 "IPv6 version field from RFC8200"; 258 } 260 identity fid-ipv6-trafficclass { 261 base fid-ipv6-base-type; 262 description 263 "IPv6 Traffic Class field from RFC8200"; 264 } 266 identity fid-ipv6-trafficclass-ds { 267 base fid-ipv6-trafficclass; 268 description 269 "IPv6 Traffic Class field from RFC8200, 270 DiffServ field from RFC3168"; 271 } 272 ... 274 Figure 4: Definition of identityref for field IDs 276 The type associated to this identity is fid-type (cf. Figure 5) 277 typedef fid-type { 278 type identityref { 279 base fid-base-type; 280 } 281 description 282 "Field ID generic type."; 283 } 285 Figure 5: Type definition for field IDs 287 2.4. Field length 289 Field length is either an integer giving the size of a field in bits 290 or a specific function. [RFC8724] defines the "var" function which 291 allows variable length fields in byte and [RFC8824] defines the "tkl" 292 function for managing the CoAP Token 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 in 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 in 312 for CoAP in RFC 8824 (cf. 4.5)."; 313 } 315 Figure 6: Definition of identityref for Field Length 317 Field ID, field length function can be defined as an identityref as 318 shown 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 length in bits */ 327 type identityref { /* function */ 328 base fl-base-type; 329 } 330 } 331 description 332 "Field length either a positive integer giving the size in bits 333 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 bi directionality 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 on the left. Figure 10 gives the definition of a single element of a 401 Target Value. In the rule, this will be used as a list, with 402 position as a key. The highest position value is used to compute the 403 size of the index sent in residue for LSB CDA. The position allows 404 to specify several values: 406 * For Equal and LSB, a single value is used, such as for the equal 407 or LSB CDA, the position is set to 0. 409 * For match-mapping, several of these values can be contained in a 410 Target Value field. Position values must start from 0 and be 411 contiguous. 413 grouping tv-struct { 414 description 415 "Define the target value element. Always a binary type, strings 416 must be converted to binary. field-id allows the conversion 417 to the appropriate type."; 418 leaf value { 419 type binary; 420 description 421 "Target Value"; 422 } 423 leaf position { 424 type uint16; 425 description 426 "If only one element position is 0, otherwise position is the 427 the position in the matching list."; 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 RFC 8724 (cf. 7.3)"; 448 } 450 identity mo-ignore { 451 base mo-base-type; 452 description 453 "Ignore MO as defined RFC 8724 (cf. 7.3)"; 454 } 456 identity mo-msb { 457 base mo-base-type; 458 description 459 "MSB MO as defined RFC 8724 (cf. 7.3)"; 460 } 462 identity mo-match-mapping { 463 base mo-base-type; 464 description 465 "match-mapping MO as defined 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 of tv-struct. 489 2.9. Compression Decompression Actions 491 Compression Decompression Action (CDA) identified the function to use 492 either for compression or decompression. [RFC8724] defines 6 CDA. 494 Figure 14 gives some CDA definition, the full definition is in 495 Section 7. 497 identity cda-base-type { 498 description 499 "Compression Decompression Actions."; 500 } 502 identity cda-not-sent { 503 base cda-base-type; 504 description 505 "not-sent CDA as defines in RFC 8724 (cf. 7.4)."; 506 } 508 identity cda-value-sent { 509 base cda-base-type; 510 description 511 "value-sent CDA as defines in RFC 8724 (cf. 7.4)."; 512 } 514 identity cda-lsb { 515 base cda-base-type; 516 description 517 "LSB CDA as defines in RFC 8724 (cf. 7.4)."; 518 } 520 identity cda-mapping-sent { 521 base cda-base-type; 522 description 523 "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)."; 524 } 525 .... 527 Figure 13: Definition of identityref for Compresion Decompression 528 Action 530 The naming convention is "cda" followed by the CDA name. 532 typedef cda-type { 533 type identityref { 534 base cda-base-type; 535 } 536 description 537 "Compression Decompression Action to compression or 538 decompress a field."; 539 } 541 Figure 14: Type definition for Compresion Decompression Action 543 2.9.1. Compression Decompression Action arguments 545 Currently no CDA requires arguments, but the future some CDA may 546 require several arguments. They are viewed as a list of target- 547 values-type. 549 2.10. Fragmentation rule 551 Fragmentation is optional in the data model and depends on the 552 presence of the "fragmentation" feature. 554 Most of parameters for fragmentation are defined in Annex D of 555 [RFC8724]. 557 Since fragmentation rules work for a specific direction, they contain 558 a mandatory direction. The type is the same as the one used in 559 compression entries, but the use of bidirectional is forbidden. 561 2.10.1. Fragmentation mode 563 [RFC8724] defines 3 fragmentation modes: 565 * No Ack: this mode is unidirectionnal, no acknowledgment is sent 566 back. 568 * Ack Always: each fragmentation window must be explicitly 569 acknowledged before going to the next. 571 * Ack on Error: A window is acknowledged only when the receiver 572 detects some missing fragments. 574 Figure 15 give the definition for identifiers from these three modes. 576 identity fragmentation-mode-base-type { 577 description 578 "fragmentation mode."; 579 } 581 identity fragmentation-mode-no-ack { 582 base fragmentation-mode-base-type; 583 description 584 "No-ACK of RFC8724."; 585 } 587 identity fragmentation-mode-ack-always { 588 base fragmentation-mode-base-type; 589 description 590 "ACK-Always of RFC8724."; 591 } 593 identity fragmentation-mode-ack-on-error { 594 base fragmentation-mode-base-type; 595 description 596 "ACK-on-Error of RFC8724."; 597 } 599 typedef fragmentation-mode-type { 600 type identityref { 601 base fragmentation-mode-base-type; 602 } 603 description 604 "type used in rules"; 605 } 607 Figure 15: Definition of fragmentation mode identifer 609 The naming convention is "fragmentation-mode" followed by the 610 fragmentation mode name. 612 2.10.2. Fragmentation Header 614 A data fragment header, directly following the rule ID can be sent on 615 the fragmentation direction. The direction is mandatory and must be 616 up or down. bidirectional is forbidden. The SCHC header may be 617 composed of (cf. Figure 16): 619 * a Datagram Tag (Dtag) identifying the datagram being fragmented if 620 the fragmentation applies concurrently on several datagrams. This 621 field in optional and its length is defined by the rule. 623 * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack- 624 Always, its size is 1 and depends on the rule in Ack-on-Error. 625 This field is not need in No-Ack mode. 627 * a Fragment Compressed Number (FCN) indicating the fragment/tile 628 position on the window. This field is mandatory on all modes 629 defined in [RFC8724], its size is defined by the rule. 631 |-- SCHC Fragment Header ----| 632 |-- T --|-M-|-- N --| 633 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 634 | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed) 635 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 637 Figure 16: Data fragment header from RFC8724 639 2.10.3. Last fragment format 641 The last fragment of a datagram is sent with an RCS (Reassembly Check 642 Sequence) field to detect residual transmission error and possible 643 losses in the last window. [RFC8724] defines a single algorithm 644 based on Ethernet CRC computation. The identity of the RCS algorithm 645 is shown in Figure 17. 647 identity rcs-algorithm-base-type { 648 description 649 "Identify which algorithm is used to compute RSC. 650 The algorithm also defines the size if the RSC field."; 651 } 653 identity rcs-RFC8724 { 654 base rcs-algorithm-base-type; 655 description 656 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 657 } 659 typedef rcs-algorithm-type { 660 type identityref { 661 base rcs-algorithm-base-type; 662 } 663 description 664 "type used in rules."; 665 } 667 Figure 17: type definition for RCS 669 The naming convention is "rcs" followed by the algorithm name. 671 For Ack-on-Error mode, the All-1 fragment may just contain the RCS or 672 can include a tile. The parameters defined in Figure 18 allows to 673 define the behavior: 675 * all1-data-no: the last fragment contains no data, just the RCS 677 * all1-data-yes: the last fragment includes a single tile and the 678 RCS 680 * all1-data-sender-choice: the last fragment may or may not contain 681 a single tile. The receiver can detect if a tile is present. 683 identity all1-data-base-type { 684 description 685 "Type to define when to send an Acknowledgment message."; 686 } 688 identity all1-data-no { 689 base all1-data-base-type; 690 description 691 "All1 contains no tiles."; 692 } 694 identity all1-data-yes { 695 base all1-data-base-type; 696 description 697 "All1 MUST contain a tile."; 698 } 700 identity all1-data-sender-choice { 701 base all1-data-base-type; 702 description 703 "Fragmentation process choose to send tiles or not in all1."; 704 } 706 typedef all1-data-type { 707 type identityref { 708 base all1-data-base-type; 709 } 710 description 711 "Type used in rules."; 712 } 714 Figure 18: type definition for RCS 716 The naming convention is "all1-data" followed by the behavior 717 identifier. 719 2.10.4. Acknowledgment behavior 721 A cknowledgment fragment header goes in the opposite direction of 722 data. The header is composed of (see Figure 19): 724 * a Dtag (if present). 726 * a mandatory window as in the data fragment. 728 * a C bit giving the status of RCS validation. In case of failure, 729 a bitmap follows, indicating received fragment/tile. The size of 730 the bitmap is given by the FCN value. 732 NOTE: IN THE DATA MODEL THERE IS A max-window-size FIELD TO LIMIT THE 733 BITMAP SIZE, BUT IS NO MORE IN RFC8724! DO WE KEEP IT? 735 |--- SCHC ACK Header ----| 736 |-- T --|-M-| 1 | 737 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 738 | RuleID | DTag | W |C=1| padding as needed (success) 739 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 741 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 742 | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 743 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 745 Figure 19: Acknowledgment fragment header for RFC8724 747 For Ack-on-Error, SCHC defined when acknowledgment can be sent. This 748 can be at any time defined by the layer 2, at the end of a window 749 (FCN All-0) or at the end of the fragment (FCN All-1). The following 750 identifiers (cf. Figure 20) define the acknowledgment behavior. 752 identity ack-behavior-base-type { 753 description 754 "Define when to send an Acknowledgment ."; 755 } 757 identity ack-behavior-after-All0 { 758 base ack-behavior-base-type; 759 description 760 "Fragmentation expects Ack after sending All0 fragment."; 761 } 763 identity ack-behavior-after-All1 { 764 base ack-behavior-base-type; 765 description 766 "Fragmentation expects Ack after sending All1 fragment."; 767 } 769 identity ack-behavior-by-layer2 { 770 base ack-behavior-base-type; 771 description 772 "Layer 2 defines when to send an Ack."; 773 } 775 typedef ack-behavior-type { 776 type identityref { 777 base ack-behavior-base-type; 778 } 779 description 780 "Type used in rules."; 781 } 783 Figure 20: bitmap generation behavior 785 The naming convention is "ack-behavior" followed by the algorithm 786 name. 788 2.10.5. Fragmentation Parameters 790 The state machine requires some common values to handle 791 fragmentation: 793 * retransmission-timer gives in seconds the duration before sending 794 an ack request (cf. section 8.2.2.4. of [RFC8724]). If specified, 795 value must be higher or equal to 1. 797 * inactivity-timer gives in seconds the duration before aborting 798 (cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly 799 indicates that this timer is disabled. 801 * max-ack-requests gives the number of attempts before aborting (cf. 802 section 8.2.2.4. of [RFC8724]). 804 * maximum-packet-size gives in bytes the larger packet size that can 805 be reassembled. 807 The are defined as unsigned integer, see Section 7. 809 2.10.6. Layer 2 parameters 811 The data model includes two parameters needed for fragmentation: 813 * l2-word-size: [RFC8724] base fragmentation on a layer 2 word which 814 can be of any length. The default value is 8 and correspond to 815 the default value for byte aligned layer 2. A value of 1 will 816 indicate that there is no alignment and no need for padding. 818 * maximum-packet-size: defines the maximum size of a uncompressed 819 datagram. By default, the value is set to 1280 bytes. 821 They are defined as unsigned integer, see Section 7. 823 3. Rule definition 825 A rule is either a C/D or an F/R rule. A rule is identified by the 826 rule ID value and its associated length. The YANG grouping rule-id- 827 type defines the structure used to represent a rule ID. Length of 0 828 is allowed to represent an implicit rule. 830 Three types of rules are defined in [RFC8724]: 832 * Compression: a compression rule is associated to the rule ID. 834 * No compression: nothing is associated to the rule ID. 836 * Fragmentation: fragmentation parameters are associated to the rule 837 ID. Fragmentation is optional and feature "fragmentation" should 838 be set. 840 grouping rule-id-type { 841 leaf rule-id-value { 842 type uint32; 843 description 844 "Rule ID value, this value must be unique combined with 845 the length."; 846 } 847 leaf rule-id-length { 848 type uint8 { 849 range "0..32"; 850 } 851 description 852 "Rule ID length in bits, value 0 is for implicit rules."; 853 } 854 description 855 "A rule ID is composed of a value and a length in bit."; 856 } 858 // SCHC table for a specific device. 860 container schc { 861 list rule { 862 key "rule-id-value rule-id-length"; 863 uses rule-id-type; 864 choice nature { 865 case fragmentation { 866 if-feature "fragmentation"; 867 uses fragmentation-content; 868 } 869 case compression { 870 if-feature "compression"; 871 uses compression-content; 872 } 873 case no-compression { 874 description 875 "RFC8724 allows a rule for uncompressed headers."; 876 } 877 description 878 "A rule is either for compression, no compression or 879 fragmentation."; 880 } 881 description 882 "Set of rules compression, no compression or fragmentation 883 rules identified by their rule-id."; 884 } 885 description 886 "a SCHC set of rules is composed of a list of rule which are 887 either compression or fragmentation."; 888 } 889 } 891 Figure 21: Definition of a SCHC Context 893 To access to a specific rule, rule-id and its specific length is used 894 as a key. The rule is either a compression or a fragmentation rule. 896 Each context can be identified though a version id. 898 3.1. Compression rule 900 A compression rule is composed of entries describing its processing 901 (cf. Figure 22). An entry contains all the information defined in 902 Figure 2 with the types defined above. 904 The compression rule described Figure 2 is defined by compression- 905 content. It defines a list of compression-rule-entry, indexed by 906 their field id, position and direction. The compression-rule-entry 907 element represent a line of the table Figure 2. Their type reflects 908 the identifier types defined in Section 2.1 910 Some controls are made on the values: 912 * target value must be present for MO different from ignore. 914 * when MSB MO is specified, the matching-operator-value must be 915 present 917 grouping compression-rule-entry { 918 description 919 "These entries defines a compression entry (i.e. a line) 920 as defined in RFC 8724 and fragmentation parameters. 922 +-------+--+--+--+------------+-----------------+---------------+ 923 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 924 +-------+--+--+--+------------+-----------------+---------------+ 926 An entry in a compression rule is composed of 7 elements: 927 - Field ID: The header field to be compressed. The content is a 928 YANG identifer. 929 - Field Length : either a positive integer of a function defined 930 as a YANF id. 931 - Field Position: a positive (and possibly equal to 0) integer. 932 - Direction Indicator: a YANG identifier giving the direction. 933 - Target value: a value against which the header Field is 934 compared. 935 - Matching Operator: a YANG id giving the operation, paramters 936 may be associated to that operator. 937 - Comp./Decomp. Action: A YANG id giving the compression or 938 decompression action, paramters may be associated to that 939 action. 940 "; 941 leaf field-id { 942 type schc:fid-type; 943 mandatory true; 944 description 945 "Field ID, identify a field in the header with a YANG 946 referenceid."; 947 } 948 leaf field-length { 949 type schc:fl-type; 950 mandatory true; 951 description 952 "Field Length in bit or through a function defined as a 953 YANG referenceid."; 954 } 955 leaf field-position { 956 type uint8; 957 mandatory true; 958 description 959 "Field position in the header is a integer. If the field is not 960 repeated in the header the value is 1, and incremented for each 961 repetition of the field. Position 0 means that the position is 962 not important and order may change when decompressed"; 963 } 964 leaf direction-indicator { 965 type schc:di-type; 966 mandatory true; 967 description 968 "Direction Indicator, a YANG referenceid to say if the packet 969 is bidirectional, up or down"; 970 } 971 list target-value { 972 key "position"; 973 uses tv-struct; 974 description 975 "A list of value to compare with the header field value. 976 If target value is a singleton, position must be 0. 977 For matching-list, should be consecutive position 978 values starting from 1."; 979 } 980 leaf matching-operator { 981 type schc:mo-type; 982 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 983 error-message 984 "mo-equal, mo-msb and mo-match-mapping need target-value"; 985 description 986 "target-value is not required for mo-ignore"; 987 } 988 must "not (derived-from-or-self(., 'mo-msb')) or 989 ../matching-operator-value" { 990 error-message "mo-msb requires length value"; 991 } 992 mandatory true; 993 description 994 "MO: Matching Operator"; 995 } 996 list matching-operator-value { 997 key "position"; 998 uses tv-struct; 999 description 1000 "Matching Operator Arguments, based on TV structure to allow 1001 several arguments. 1002 In RFC 8724, only MSB define a single argument: length in 1003 bits"; 1004 } 1005 leaf comp-decomp-action { 1006 type schc:cda-type; 1007 mandatory true; 1008 description 1009 "CDA: Compression Decompression Action."; 1010 } 1011 list comp-decomp-action-value { 1012 key "position"; 1013 uses tv-struct; 1014 description 1015 "CDA Arguments, based on TV structure to allow several 1016 arguments. In RFC 8724, no argument is defined for CDA."; 1017 } 1018 } 1020 grouping compression-content { 1021 list entry { 1022 key "field-id field-position direction-indicator"; 1023 uses compression-rule-entry; 1024 description 1025 "A compression rule is a list of rule entry describing 1026 each header field. An entry is identifed through a field-id, 1027 its position in the packet and its direction."; 1028 } 1029 description 1030 "Define a compression rule composed of a list of entries."; 1031 } 1033 Figure 22: Definition of a compression entry 1035 3.2. Fragmentation rule 1037 A Fragmentation rule is composed of entries describing the protocol 1038 behavior. Some on them are numerical entries, others are identifiers 1039 defined in Section 2.10. 1041 The definition of a Fragmentation rule is divided into three sub- 1042 parts: 1044 * parameters such as the the fragmnetation-mode, the l2-word-size 1045 and the direction. Since Fragmentation rules are always defined 1046 for a specific direction, the value must be must be either di-up 1047 or di-down (bi-bidirectional is not allowed). 1049 * parameters defining the Fragmentation header format (dtag-size, 1050 w-size, fcn-size and rcs-algorithm). 1052 * Protocol parameters for timers (inactivity-timer, retransmission- 1053 timer) or behavior (maximum-packet-size, max-interleaved-frames, 1054 max-ack-requests). If these parameters are specific to a single 1055 fragmentation mode, they are regrouped in a choice structure 1056 dedicated to that Fragmentation mode. If some parameters can be 1057 find in several modes, typically ACK-Always and ACK-on-Error. 1058 They are defined in a common part and a when statement indicates 1059 which modes are allowed. 1061 grouping fragmentation-content { 1062 description 1063 "This grouping defines the fragmentation parameters for 1064 all the modes (No-ACK, ACK-Always and ACK-on-Error) specified in 1065 RFC 8724."; 1066 leaf fragmentation-mode { 1067 type schc:fragmentation-mode-type; 1068 mandatory true; 1069 description 1070 "which fragmentation mode is used (noAck, AckAlways, 1071 AckonError)"; 1072 } 1073 leaf l2-word-size { 1074 type uint8; 1075 default "8"; 1076 description 1077 "Size in bit of the layer 2 word"; 1078 } 1079 leaf direction { 1080 type schc:di-type; 1081 must "derived-from-or-self(., 'di-up') or 1082 derived-from-or-self(., 'di-down')" { 1083 error-message 1084 "direction for fragmentation rules are up or down."; 1085 } 1086 mandatory true; 1087 description 1088 "Should be up or down, bi directionnal is forbiden."; 1090 } 1091 // SCHC Frag header format 1092 leaf dtag-size { 1093 type uint8; 1094 default "0"; 1095 description 1096 "Size in bit of the DTag field (T variable from RFC8724)."; 1097 } 1098 leaf w-size { 1099 when "derived-from(../fragmentation-mode, 1100 'fragmentation-mode-ack-on-error') 1101 or 1102 derived-from(../fragmentation-mode, 1103 'fragmentation-mode-ack-always') "; 1104 type uint8; 1105 description 1106 "Size in bit of the window field (M variable from RFC8724)."; 1107 } 1108 leaf fcn-size { 1109 type uint8; 1110 mandatory true; 1111 description 1112 "Size in bit of the FCN field (M variable from RFC8724)."; 1113 } 1114 leaf rcs-algorithm { 1115 type rcs-algorithm-type; 1116 default "schc:rcs-RFC8724"; 1117 description 1118 "Algoritm used for RCS. The algorithm spedifies the RCS size"; 1119 } 1120 // SCHC fragmentation protocol paramters 1121 leaf maximum-packet-size { 1122 type uint16; 1123 default "1280"; 1124 description 1125 "When decompression is done, packet size must not 1126 strictly exceed this limit in Bytes."; 1127 } 1128 leaf window-size { 1129 type uint16; 1130 description 1131 "By default, if not specified 2^w-size - 1. Should not exceed 1132 this value. Possible FCN values are between 0 and 1133 window-size-1."; 1134 } 1135 leaf max-interleaved-frames { 1136 type uint8; 1137 default "1"; 1138 description 1139 "Maximum of simultaneously fragmented frames. Maximum value is 1140 2^dtag-size. All DTAG values can be used, but only 1141 max-interleaved-frames must be active."; 1142 } 1143 leaf inactivity-timer { 1144 type uint64; 1145 description 1146 "Duration is seconds of the inactivity timer, 0 indicates 1147 the timer is disabled."; 1148 } 1149 leaf retransmission-timer { 1150 when "derived-from(../fragmentation-mode, 1151 'fragmentation-mode-ack-on-error') 1152 or 1153 derived-from(../fragmentation-mode, 1154 'fragmentation-mode-ack-always') "; 1155 type uint64 { 1156 range "1..max"; 1157 } 1158 description 1159 "Duration in seconds of the retransmission timer."; 1160 } 1161 leaf max-ack-requests { 1162 when "derived-from(../fragmentation-mode, 1163 'fragmentation-mode-ack-on-error') 1164 or 1165 derived-from(../fragmentation-mode, 1166 'fragmentation-mode-ack-always') "; 1167 type uint8 { 1168 range "1..max"; 1169 } 1170 description 1171 "The maximum number of retries for a specific SCHC ACK."; 1172 } 1173 choice mode { 1174 case no-ack; 1175 case ack-always; 1176 case ack-on-error { 1177 leaf tile-size { 1178 when "derived-from(../fragmentation-mode, 1179 'fragmentation-mode-ack-on-error')"; 1180 type uint8; 1181 description 1182 "Size in bit of tiles, if not specified or set to 0, 1183 tile fills the fragment."; 1184 } 1185 leaf tile-in-All1 { 1186 when "derived-from(../fragmentation-mode, 1187 'fragmentation-mode-ack-on-error')"; 1188 type schc:all1-data-type; 1189 description 1190 "When true, sender and receiver except a tile in 1191 All-1 frag."; 1192 } 1193 leaf ack-behavior { 1194 when "derived-from(../fragmentation-mode, 1195 'fragmentation-mode-ack-on-error')"; 1196 type schc:ack-behavior-type; 1197 description 1198 "Sender behavior to acknowledge, after All-0, All-1 or 1199 when the LPWAN allows it (Always)."; 1200 } 1201 } 1202 description 1203 "RFC 8724 defines 3 fragmentation modes."; 1204 } 1205 } 1207 3.3. YANG Tree 1208 module: ietf-schc 1209 +--rw schc 1210 +--rw rule* [rule-id-value rule-id-length] 1211 +--rw rule-id-value uint32 1212 +--rw rule-id-length uint8 1213 +--rw (nature)? 1214 +--:(fragmentation) {fragmentation}? 1215 | +--rw fragmentation-mode schc:fragmentation-mode-type 1216 | +--rw l2-word-size? uint8 1217 | +--rw direction schc:di-type 1218 | +--rw dtag-size? uint8 1219 | +--rw w-size? uint8 1220 | +--rw fcn-size uint8 1221 | +--rw rcs-algorithm? rcs-algorithm-type 1222 | +--rw maximum-packet-size? uint16 1223 | +--rw window-size? uint16 1224 | +--rw max-interleaved-frames? uint8 1225 | +--rw inactivity-timer? uint64 1226 | +--rw retransmission-timer? uint64 1227 | +--rw max-ack-requests? uint8 1228 | +--rw (mode)? 1229 | +--:(no-ack) 1230 | +--:(ack-always) 1231 | +--:(ack-on-error) 1232 | +--rw tile-size? uint8 1233 | +--rw tile-in-All1? schc:all1-data-type 1234 | +--rw ack-behavior? schc:ack-behavior-type 1235 +--:(compression) {compression}? 1236 | +--rw entry* [field-id field-position direction-indicator] 1237 | +--rw field-id schc:fid-type 1238 | +--rw field-length schc:fl-type 1239 | +--rw field-position uint8 1240 | +--rw direction-indicator schc:di-type 1241 | +--rw target-value* [position] 1242 | | +--rw value? binary 1243 | | +--rw position uint16 1244 | +--rw matching-operator schc:mo-type 1245 | +--rw matching-operator-value* [position] 1246 | | +--rw value? binary 1247 | | +--rw position uint16 1248 | +--rw comp-decomp-action schc:cda-type 1249 | +--rw comp-decomp-action-value* [position] 1250 | +--rw value? binary 1251 | +--rw position uint16 1252 +--:(no-compression) 1254 Figure 23 1256 4. IANA Considerations 1258 This document has no request to IANA. 1260 5. Security considerations 1262 This document does not have any more Security consideration than the 1263 ones already raised on [RFC8724] 1265 6. Acknowledgements 1267 The authors would like to thank Dominique Barthel, Carsten Bormann, 1268 Alexander Pelov. 1270 7. YANG Module 1272 file ietf-schc@2022-02-15.yang 1273 module ietf-schc { 1274 yang-version 1.1; 1275 namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; 1276 prefix schc; 1278 organization 1279 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; 1280 contact 1281 "WG Web: 1282 WG List: 1283 Editor: Laurent Toutain 1284 1285 Editor: Ana Minaburo 1286 "; 1287 description 1288 " 1289 Copyright (c) 2021 IETF Trust and the persons identified as 1290 authors of the code. All rights reserved. 1292 Redistribution and use in source and binary forms, with or 1293 without modification, is permitted pursuant to, and subject to 1294 the license terms contained in, the Simplified BSD License set 1295 forth in Section 4.c of the IETF Trust's Legal Provisions 1296 Relating to IETF Documents 1297 (https://trustee.ietf.org/license-info). 1299 This version of this YANG module is part of RFC XXXX 1300 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1301 for full legal notices. 1303 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1304 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1305 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1306 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1307 they appear in all capitals, as shown here. 1309 ***************************************************************** 1311 Generic Data model for Static Context Header Compression Rule for 1312 SCHC, based on RFC 8724 and RFC8824. Include compression, no 1313 compression and fragmentation rules. 1315 This module is a YANG model for SCHC rules (RFc 8724). 1316 RFC 8724 describes compression rules in a abstract way through a 1317 table. 1319 |-----------------------------------------------------------------| 1320 | (FID) Rule 1 | 1321 |+-------+--+--+--+------------+-----------------+---------------+| 1322 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1323 |+-------+--+--+--+------------+-----------------+---------------+| 1324 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1325 |+-------+--+--+--+------------+-----------------+---------------+| 1326 ||... |..|..|..| ... | ... | ... || 1327 |+-------+--+--+--+------------+-----------------+---------------+| 1328 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1329 +-------+--+--+--+------------+-----------------+---------------+|| 1330 |-----------------------------------------------------------------| 1332 This module proposes a global data model that can be used for rule 1333 exchanges or modification. It proposes both the data model format 1334 and the global identifiers used to describe some operations in 1335 fields. 1336 This data model applies to both compression and fragmentation."; 1338 revision 2022-02-15 { 1339 description 1340 "Initial version from RFC XXXX "; 1341 reference 1342 "RFC XXX: Data Model for Static Context Header Compression 1343 (SCHC)"; 1344 } 1346 feature compression { 1347 description 1348 "SCHC compression capabilities are taken into account"; 1349 } 1351 feature fragmentation { 1352 description 1353 "SCHC fragmentation capabilities are taken into account"; 1354 } 1356 // ------------------------- 1357 // Field ID type definition 1358 //-------------------------- 1359 // generic value TV definition 1361 identity fid-base-type { 1362 description 1363 "Field ID base type for all fields"; 1364 } 1366 identity fid-ipv6-base-type { 1367 base fid-base-type; 1368 description 1369 "Field ID base type for IPv6 headers described in RFC 8200"; 1370 } 1372 identity fid-ipv6-version { 1373 base fid-ipv6-base-type; 1374 description 1375 "IPv6 version field from RFC8200"; 1376 } 1378 identity fid-ipv6-trafficclass { 1379 base fid-ipv6-base-type; 1380 description 1381 "IPv6 Traffic Class field from RFC8200"; 1382 } 1384 identity fid-ipv6-trafficclass-ds { 1385 base fid-ipv6-trafficclass; 1386 description 1387 "IPv6 Traffic Class field from RFC8200, 1388 DiffServ field from RFC3168"; 1389 } 1391 identity fid-ipv6-trafficclass-ecn { 1392 base fid-ipv6-trafficclass; 1393 description 1394 "IPv6 Traffic Class field from RFC8200, 1395 ECN field from RFC3168"; 1396 } 1398 identity fid-ipv6-flowlabel { 1399 base fid-ipv6-base-type; 1400 description 1401 "IPv6 Flow Label field from RFC8200"; 1402 } 1404 identity fid-ipv6-payloadlength { 1405 base fid-ipv6-base-type; 1406 description 1407 "IPv6 Payload Length field from RFC8200"; 1408 } 1410 identity fid-ipv6-nextheader { 1411 base fid-ipv6-base-type; 1412 description 1413 "IPv6 Next Header field from RFC8200"; 1414 } 1416 identity fid-ipv6-hoplimit { 1417 base fid-ipv6-base-type; 1418 description 1419 "IPv6 Next Header field from RFC8200"; 1420 } 1422 identity fid-ipv6-devprefix { 1423 base fid-ipv6-base-type; 1424 description 1425 "corresponds to either the source address or the destination 1426 address prefix of RFC 8200. Depending if it is 1427 respectively an uplink or a downklink message."; 1428 } 1430 identity fid-ipv6-deviid { 1431 base fid-ipv6-base-type; 1432 description 1433 "corresponds to either the source address or the destination 1434 address prefix of RFC 8200. Depending if it is respectively 1435 an uplink or a downklink message."; 1436 } 1438 identity fid-ipv6-appprefix { 1439 base fid-ipv6-base-type; 1440 description 1441 "corresponds to either the source address or the destination 1442 address prefix of RFC 8200. Depending if it is respectively 1443 a downlink or an uplink message."; 1444 } 1446 identity fid-ipv6-appiid { 1447 base fid-ipv6-base-type; 1448 description 1449 "corresponds to either the source address or the destination 1450 address prefix of RFC 8200. Depending if it is respectively 1451 a downlink or an uplink message."; 1452 } 1454 identity fid-udp-base-type { 1455 base fid-base-type; 1456 description 1457 "Field ID base type for UDP headers described in RFC 768"; 1458 } 1460 identity fid-udp-dev-port { 1461 base fid-udp-base-type; 1462 description 1463 "UDP source or destination port from RFC 768, if uplink or 1464 downlink communication, respectively."; 1465 } 1467 identity fid-udp-app-port { 1468 base fid-udp-base-type; 1469 description 1470 "UDP destination or source port from RFC 768, if uplink or 1471 downlink communication, respectively."; 1472 } 1474 identity fid-udp-length { 1475 base fid-udp-base-type; 1476 description 1477 "UDP length from RFC 768"; 1478 } 1480 identity fid-udp-checksum { 1481 base fid-udp-base-type; 1482 description 1483 "UDP length from RFC 768"; 1484 } 1486 identity fid-coap-base-type { 1487 base fid-base-type; 1488 description 1489 "Field ID base type for UDP headers described in RFC 7252"; 1490 } 1492 identity fid-coap-version { 1493 base fid-coap-base-type; 1494 description 1495 "CoAP version from RFC 7252"; 1497 } 1499 identity fid-coap-type { 1500 base fid-coap-base-type; 1501 description 1502 "CoAP type from RFC 7252"; 1503 } 1505 identity fid-coap-tkl { 1506 base fid-coap-base-type; 1507 description 1508 "CoAP token length from RFC 7252"; 1509 } 1511 identity fid-coap-code { 1512 base fid-coap-base-type; 1513 description 1514 "CoAP code from RFC 7252"; 1515 } 1517 identity fid-coap-code-class { 1518 base fid-coap-code; 1519 description 1520 "CoAP code class from RFC 7252"; 1521 } 1523 identity fid-coap-code-detail { 1524 base fid-coap-code; 1525 description 1526 "CoAP code detail from RFC 7252"; 1527 } 1529 identity fid-coap-mid { 1530 base fid-coap-base-type; 1531 description 1532 "CoAP message ID from RFC 7252"; 1533 } 1535 identity fid-coap-token { 1536 base fid-coap-base-type; 1537 description 1538 "CoAP token from RFC 7252"; 1539 } 1541 identity fid-coap-option-if-match { 1542 base fid-coap-base-type; 1543 description 1544 "CoAP option If-Match from RFC 7252"; 1546 } 1548 identity fid-coap-option-uri-host { 1549 base fid-coap-base-type; 1550 description 1551 "CoAP option URI-Host from RFC 7252"; 1552 } 1554 identity fid-coap-option-etag { 1555 base fid-coap-base-type; 1556 description 1557 "CoAP option Etag from RFC 7252"; 1558 } 1560 identity fid-coap-option-if-none-match { 1561 base fid-coap-base-type; 1562 description 1563 "CoAP option if-none-match from RFC 7252"; 1564 } 1566 identity fid-coap-option-observe { 1567 base fid-coap-base-type; 1568 description 1569 "CoAP option Observe from RFC 7641"; 1570 } 1572 identity fid-coap-option-uri-port { 1573 base fid-coap-base-type; 1574 description 1575 "CoAP option Uri-Port from RFC 7252"; 1576 } 1578 identity fid-coap-option-location-path { 1579 base fid-coap-base-type; 1580 description 1581 "CoAP option Location-Path from RFC 7252"; 1582 } 1584 identity fid-coap-option-uri-path { 1585 base fid-coap-base-type; 1586 description 1587 "CoAP option Uri-Path from RFC 7252"; 1588 } 1590 identity fid-coap-option-content-format { 1591 base fid-coap-base-type; 1592 description 1593 "CoAP option Content Format from RFC 7252"; 1595 } 1597 identity fid-coap-option-max-age { 1598 base fid-coap-base-type; 1599 description 1600 "CoAP option Max-Age from RFC 7252"; 1601 } 1603 identity fid-coap-option-uri-query { 1604 base fid-coap-base-type; 1605 description 1606 "CoAP option Uri-Query from RFC 7252"; 1607 } 1609 identity fid-coap-option-accept { 1610 base fid-coap-base-type; 1611 description 1612 "CoAP option Accept from RFC 7252"; 1613 } 1615 identity fid-coap-option-location-query { 1616 base fid-coap-base-type; 1617 description 1618 "CoAP option Location-Query from RFC 7252"; 1619 } 1621 identity fid-coap-option-block2 { 1622 base fid-coap-base-type; 1623 description 1624 "CoAP option Block2 from RFC 7959"; 1625 } 1627 identity fid-coap-option-block1 { 1628 base fid-coap-base-type; 1629 description 1630 "CoAP option Block1 from RFC 7959"; 1631 } 1633 identity fid-coap-option-size2 { 1634 base fid-coap-base-type; 1635 description 1636 "CoAP option size2 from RFC 7959"; 1637 } 1639 identity fid-coap-option-proxy-uri { 1640 base fid-coap-base-type; 1641 description 1642 "CoAP option Proxy-Uri from RFC 7252"; 1644 } 1646 identity fid-coap-option-proxy-scheme { 1647 base fid-coap-base-type; 1648 description 1649 "CoAP option Proxy-scheme from RFC 7252"; 1650 } 1652 identity fid-coap-option-size1 { 1653 base fid-coap-base-type; 1654 description 1655 "CoAP option Size1 from RFC 7252"; 1656 } 1658 identity fid-coap-option-no-response { 1659 base fid-coap-base-type; 1660 description 1661 "CoAP option No response from RFC 7967"; 1662 } 1664 identity fid-coap-option-oscore-flags { 1665 base fid-coap-base-type; 1666 description 1667 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1668 } 1670 identity fid-coap-option-oscore-piv { 1671 base fid-coap-base-type; 1672 description 1673 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1674 } 1676 identity fid-coap-option-oscore-kid { 1677 base fid-coap-base-type; 1678 description 1679 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1680 } 1682 identity fid-coap-option-oscore-kidctx { 1683 base fid-coap-base-type; 1684 description 1685 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1686 } 1688 //---------------------------------- 1689 // Field Length type definition 1690 //---------------------------------- 1691 identity fl-base-type { 1692 description 1693 "Used to extend field length functions."; 1694 } 1696 identity fl-variable { 1697 base fl-base-type; 1698 description 1699 "Residue length in Byte is sent as defined in 1700 for CoAP in RFC 8824 (cf. 5.3)."; 1701 } 1703 identity fl-token-length { 1704 base fl-base-type; 1705 description 1706 "Residue length in Byte is sent as defined in 1707 for CoAP in RFC 8824 (cf. 4.5)."; 1708 } 1710 //--------------------------------- 1711 // Direction Indicator type 1712 //--------------------------------- 1714 identity di-base-type { 1715 description 1716 "Used to extend direction indicators."; 1717 } 1719 identity di-bidirectional { 1720 base di-base-type; 1721 description 1722 "Direction Indication of bi directionality in 1723 RFC 8724 (cf. 7.1)."; 1724 } 1726 identity di-up { 1727 base di-base-type; 1728 description 1729 "Direction Indication of uplink defined in 1730 RFC 8724 (cf. 7.1)."; 1731 } 1733 identity di-down { 1734 base di-base-type; 1735 description 1736 "Direction Indication of downlink defined in 1737 RFC 8724 (cf. 7.1)."; 1738 } 1739 //---------------------------------- 1740 // Matching Operator type definition 1741 //---------------------------------- 1743 identity mo-base-type { 1744 description 1745 "Used to extend Matching Operators with SID values"; 1746 } 1748 identity mo-equal { 1749 base mo-base-type; 1750 description 1751 "Equal MO as defined RFC 8724 (cf. 7.3)"; 1752 } 1754 identity mo-ignore { 1755 base mo-base-type; 1756 description 1757 "Ignore MO as defined RFC 8724 (cf. 7.3)"; 1758 } 1760 identity mo-msb { 1761 base mo-base-type; 1762 description 1763 "MSB MO as defined RFC 8724 (cf. 7.3)"; 1764 } 1766 identity mo-match-mapping { 1767 base mo-base-type; 1768 description 1769 "match-mapping MO as defined RFC 8724 (cf. 7.3)"; 1770 } 1772 //------------------------------ 1773 // CDA type definition 1774 //------------------------------ 1776 identity cda-base-type { 1777 description 1778 "Compression Decompression Actions."; 1779 } 1781 identity cda-not-sent { 1782 base cda-base-type; 1783 description 1784 "not-sent CDA as defines in RFC 8724 (cf. 7.4)."; 1785 } 1786 identity cda-value-sent { 1787 base cda-base-type; 1788 description 1789 "value-sent CDA as defines in RFC 8724 (cf. 7.4)."; 1790 } 1792 identity cda-lsb { 1793 base cda-base-type; 1794 description 1795 "LSB CDA as defines in RFC 8724 (cf. 7.4)."; 1796 } 1798 identity cda-mapping-sent { 1799 base cda-base-type; 1800 description 1801 "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)."; 1802 } 1804 identity cda-compute-length { 1805 base cda-base-type; 1806 description 1807 "compute-length CDA as defines in RFC 8724 (cf. 7.4)"; 1808 } 1810 identity cda-compute-checksum { 1811 base cda-base-type; 1812 description 1813 "compute-checksum CDA as defines in RFC 8724 (cf. 7.4)"; 1814 } 1816 identity cda-deviid { 1817 base cda-base-type; 1818 description 1819 "deviid CDA as defines in RFC 8724 (cf. 7.4)"; 1820 } 1822 identity cda-appiid { 1823 base cda-base-type; 1824 description 1825 "appiid CDA as defines in RFC 8724 (cf. 7.4)"; 1826 } 1828 // -- type definition 1830 typedef fid-type { 1831 type identityref { 1832 base fid-base-type; 1833 } 1834 description 1835 "Field ID generic type."; 1836 } 1838 typedef fl-type { 1839 type union { 1840 type int64; /* positive length in bits */ 1841 type identityref { /* function */ 1842 base fl-base-type; 1843 } 1844 } 1845 description 1846 "Field length either a positive integer giving the size in bits 1847 or a function defined through an identityref."; 1848 } 1850 typedef di-type { 1851 type identityref { 1852 base di-base-type; 1853 } 1854 description 1855 "Direction in LPWAN network, up when emitted by the device, 1856 down when received by the device, bi when emitted or 1857 received by the device."; 1858 } 1860 typedef mo-type { 1861 type identityref { 1862 base mo-base-type; 1863 } 1864 description 1865 "Matching Operator (MO) to compare fields values with 1866 target values"; 1867 } 1869 typedef cda-type { 1870 type identityref { 1871 base cda-base-type; 1872 } 1873 description 1874 "Compression Decompression Action to compression or 1875 decompress a field."; 1876 } 1878 // -- FRAGMENTATION TYPE 1879 // -- fragmentation modes 1881 identity fragmentation-mode-base-type { 1882 description 1883 "fragmentation mode."; 1884 } 1886 identity fragmentation-mode-no-ack { 1887 base fragmentation-mode-base-type; 1888 description 1889 "No-ACK of RFC8724."; 1890 } 1892 identity fragmentation-mode-ack-always { 1893 base fragmentation-mode-base-type; 1894 description 1895 "ACK-Always of RFC8724."; 1896 } 1898 identity fragmentation-mode-ack-on-error { 1899 base fragmentation-mode-base-type; 1900 description 1901 "ACK-on-Error of RFC8724."; 1902 } 1904 typedef fragmentation-mode-type { 1905 type identityref { 1906 base fragmentation-mode-base-type; 1907 } 1908 description 1909 "type used in rules"; 1910 } 1912 // -- Ack behavior 1914 identity ack-behavior-base-type { 1915 description 1916 "Define when to send an Acknowledgment ."; 1917 } 1919 identity ack-behavior-after-All0 { 1920 base ack-behavior-base-type; 1921 description 1922 "Fragmentation expects Ack after sending All0 fragment."; 1923 } 1925 identity ack-behavior-after-All1 { 1926 base ack-behavior-base-type; 1927 description 1928 "Fragmentation expects Ack after sending All1 fragment."; 1929 } 1930 identity ack-behavior-by-layer2 { 1931 base ack-behavior-base-type; 1932 description 1933 "Layer 2 defines when to send an Ack."; 1934 } 1936 typedef ack-behavior-type { 1937 type identityref { 1938 base ack-behavior-base-type; 1939 } 1940 description 1941 "Type used in rules."; 1942 } 1944 // -- All1 with data types 1946 identity all1-data-base-type { 1947 description 1948 "Type to define when to send an Acknowledgment message."; 1949 } 1951 identity all1-data-no { 1952 base all1-data-base-type; 1953 description 1954 "All1 contains no tiles."; 1955 } 1957 identity all1-data-yes { 1958 base all1-data-base-type; 1959 description 1960 "All1 MUST contain a tile."; 1961 } 1963 identity all1-data-sender-choice { 1964 base all1-data-base-type; 1965 description 1966 "Fragmentation process choose to send tiles or not in all1."; 1967 } 1969 typedef all1-data-type { 1970 type identityref { 1971 base all1-data-base-type; 1972 } 1973 description 1974 "Type used in rules."; 1975 } 1977 // -- RCS algorithm types 1978 identity rcs-algorithm-base-type { 1979 description 1980 "Identify which algorithm is used to compute RSC. 1981 The algorithm also defines the size if the RSC field."; 1982 } 1984 identity rcs-RFC8724 { 1985 base rcs-algorithm-base-type; 1986 description 1987 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 1988 } 1990 typedef rcs-algorithm-type { 1991 type identityref { 1992 base rcs-algorithm-base-type; 1993 } 1994 description 1995 "type used in rules."; 1996 } 1998 // -------- RULE ENTRY DEFINITION ------------ 2000 grouping tv-struct { 2001 description 2002 "Define the target value element. Always a binary type, strings 2003 must be converted to binary. field-id allows the conversion 2004 to the appropriate type."; 2005 leaf value { 2006 type binary; 2007 description 2008 "Target Value"; 2009 } 2010 leaf position { 2011 type uint16; 2012 description 2013 "If only one element position is 0, otherwise position is the 2014 the position in the matching list."; 2015 } 2016 } 2018 grouping compression-rule-entry { 2019 description 2020 "These entries defines a compression entry (i.e. a line) 2021 as defined in RFC 8724 and fragmentation parameters. 2023 +-------+--+--+--+------------+-----------------+---------------+ 2024 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 2025 +-------+--+--+--+------------+-----------------+---------------+ 2026 An entry in a compression rule is composed of 7 elements: 2027 - Field ID: The header field to be compressed. The content is a 2028 YANG identifer. 2029 - Field Length : either a positive integer of a function defined 2030 as a YANF id. 2031 - Field Position: a positive (and possibly equal to 0) integer. 2032 - Direction Indicator: a YANG identifier giving the direction. 2033 - Target value: a value against which the header Field is 2034 compared. 2035 - Matching Operator: a YANG id giving the operation, paramters 2036 may be associated to that operator. 2037 - Comp./Decomp. Action: A YANG id giving the compression or 2038 decompression action, paramters may be associated to that 2039 action. 2040 "; 2041 leaf field-id { 2042 type schc:fid-type; 2043 mandatory true; 2044 description 2045 "Field ID, identify a field in the header with a YANG 2046 referenceid."; 2047 } 2048 leaf field-length { 2049 type schc:fl-type; 2050 mandatory true; 2051 description 2052 "Field Length in bit or through a function defined as a 2053 YANG referenceid."; 2054 } 2055 leaf field-position { 2056 type uint8; 2057 mandatory true; 2058 description 2059 "Field position in the header is a integer. If the field is not 2060 repeated in the header the value is 1, and incremented for each 2061 repetition of the field. Position 0 means that the position is 2062 not important and order may change when decompressed"; 2063 } 2064 leaf direction-indicator { 2065 type schc:di-type; 2066 mandatory true; 2067 description 2068 "Direction Indicator, a YANG referenceid to say if the packet 2069 is bidirectional, up or down"; 2070 } 2071 list target-value { 2072 key "position"; 2073 uses tv-struct; 2074 description 2075 "A list of value to compare with the header field value. 2076 If target value is a singleton, position must be 0. 2077 For matching-list, should be consecutive position 2078 values starting from 1."; 2079 } 2080 leaf matching-operator { 2081 type schc:mo-type; 2082 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 2083 error-message 2084 "mo-equal, mo-msb and mo-match-mapping need target-value"; 2085 description 2086 "target-value is not required for mo-ignore"; 2087 } 2088 must "not (derived-from-or-self(., 'mo-msb')) or 2089 ../matching-operator-value" { 2090 error-message "mo-msb requires length value"; 2091 } 2092 mandatory true; 2093 description 2094 "MO: Matching Operator"; 2095 } 2096 list matching-operator-value { 2097 key "position"; 2098 uses tv-struct; 2099 description 2100 "Matching Operator Arguments, based on TV structure to allow 2101 several arguments. 2102 In RFC 8724, only MSB define a single argument: length in 2103 bits"; 2104 } 2105 leaf comp-decomp-action { 2106 type schc:cda-type; 2107 mandatory true; 2108 description 2109 "CDA: Compression Decompression Action."; 2110 } 2111 list comp-decomp-action-value { 2112 key "position"; 2113 uses tv-struct; 2114 description 2115 "CDA Arguments, based on TV structure to allow several 2116 arguments. In RFC 8724, no argument is defined for CDA."; 2117 } 2118 } 2120 grouping compression-content { 2121 list entry { 2122 key "field-id field-position direction-indicator"; 2123 uses compression-rule-entry; 2124 description 2125 "A compression rule is a list of rule entry describing 2126 each header field. An entry is identifed through a field-id, 2127 its position in the packet and its direction."; 2128 } 2129 description 2130 "Define a compression rule composed of a list of entries."; 2131 } 2133 grouping fragmentation-content { 2134 description 2135 "This grouping defines the fragmentation parameters for 2136 all the modes (No ACK, ACK-Always and ACK-on-Error) specified in 2137 RFC 8724."; 2138 leaf fragmentation-mode { 2139 type schc:fragmentation-mode-type; 2140 mandatory true; 2141 description 2142 "which fragmentation mode is used (noAck, AckAlways, 2143 AckonError)"; 2144 } 2145 leaf l2-word-size { 2146 type uint8; 2147 default "8"; 2148 description 2149 "Size in bit of the layer 2 word"; 2150 } 2151 leaf direction { 2152 type schc:di-type; 2153 must "derived-from-or-self(., 'di-up') or 2154 derived-from-or-self(., 'di-down')" { 2155 error-message 2156 "direction for fragmentation rules are up or down."; 2157 } 2158 mandatory true; 2159 description 2160 "Should be up or down, bi directionnal is forbiden."; 2161 } 2162 // SCHC Frag header format 2163 leaf dtag-size { 2164 type uint8; 2165 default "0"; 2166 description 2167 "Size in bit of the DTag field (T variable from RFC8724)."; 2168 } 2169 leaf w-size { 2170 when "derived-from(../fragmentation-mode, 2171 'fragmentation-mode-ack-on-error') 2172 or 2173 derived-from(../fragmentation-mode, 2174 'fragmentation-mode-ack-always') "; 2175 type uint8; 2176 description 2177 "Size in bit of the window field (M variable from RFC8724)."; 2178 } 2179 leaf fcn-size { 2180 type uint8; 2181 mandatory true; 2182 description 2183 "Size in bit of the FCN field (M variable from RFC8724)."; 2184 } 2185 leaf rcs-algorithm { 2186 type rcs-algorithm-type; 2187 default "schc:rcs-RFC8724"; 2188 description 2189 "Algoritm used for RCS. The algorithm spedifies the RCS size"; 2190 } 2191 // SCHC fragmentation protocol paramters 2192 leaf maximum-packet-size { 2193 type uint16; 2194 default "1280"; 2195 description 2196 "When decompression is done, packet size must not 2197 strictly exceed this limit in Bytes."; 2198 } 2199 leaf window-size { 2200 type uint16; 2201 description 2202 "By default, if not specified 2^w-size - 1. Should not exceed 2203 this value. Possible FCN values are between 0 and 2204 window-size-1."; 2205 } 2206 leaf max-interleaved-frames { 2207 type uint8; 2208 default "1"; 2209 description 2210 "Maximum of simultaneously fragmented frames. Maximum value is 2211 2^dtag-size. All DTAG values can be used, but only 2212 max-interleaved-frames must be active."; 2213 } 2214 leaf inactivity-timer { 2215 type uint64; 2216 description 2217 "Duration is seconds of the inactivity timer, 0 indicates 2218 the timer is disabled."; 2219 } 2220 leaf retransmission-timer { 2221 when "derived-from(../fragmentation-mode, 2222 'fragmentation-mode-ack-on-error') 2223 or 2224 derived-from(../fragmentation-mode, 2225 'fragmentation-mode-ack-always') "; 2226 type uint64 { 2227 range "1..max"; 2228 } 2229 description 2230 "Duration in seconds of the retransmission timer."; 2231 } 2232 leaf max-ack-requests { 2233 when "derived-from(../fragmentation-mode, 2234 'fragmentation-mode-ack-on-error') 2235 or 2236 derived-from(../fragmentation-mode, 2237 'fragmentation-mode-ack-always') "; 2238 type uint8 { 2239 range "1..max"; 2240 } 2241 description 2242 "The maximum number of retries for a specific SCHC ACK."; 2243 } 2244 choice mode { 2245 case no-ack; 2246 case ack-always; 2247 case ack-on-error { 2248 leaf tile-size { 2249 when "derived-from(../fragmentation-mode, 2250 'fragmentation-mode-ack-on-error')"; 2251 type uint8; 2252 description 2253 "Size in bit of tiles, if not specified or set to 0, 2254 tile fills the fragment."; 2255 } 2256 leaf tile-in-All1 { 2257 when "derived-from(../fragmentation-mode, 2258 'fragmentation-mode-ack-on-error')"; 2259 type schc:all1-data-type; 2260 description 2261 "When true, sender and receiver except a tile in 2262 All-1 frag."; 2263 } 2264 leaf ack-behavior { 2265 when "derived-from(../fragmentation-mode, 2266 'fragmentation-mode-ack-on-error')"; 2267 type schc:ack-behavior-type; 2268 description 2269 "Sender behavior to acknowledge, after All-0, All-1 or 2270 when the LPWAN allows it (Always)."; 2271 } 2272 } 2273 description 2274 "RFC 8724 defines 3 fragmentation modes."; 2275 } 2276 } 2278 // Define rule ID. Rule ID is composed of a RuleID value and a 2279 // Rule ID Length 2281 grouping rule-id-type { 2282 leaf rule-id-value { 2283 type uint32; 2284 description 2285 "Rule ID value, this value must be unique combined with 2286 the length."; 2287 } 2288 leaf rule-id-length { 2289 type uint8 { 2290 range "0..32"; 2291 } 2292 description 2293 "Rule ID length in bits, value 0 is for implicit rules."; 2294 } 2295 description 2296 "A rule ID is composed of a value and a length in bit."; 2297 } 2299 // SCHC table for a specific device. 2301 container schc { 2302 list rule { 2303 key "rule-id-value rule-id-length"; 2304 uses rule-id-type; 2305 choice nature { 2306 case fragmentation { 2307 if-feature "fragmentation"; 2308 uses fragmentation-content; 2309 } 2310 case compression { 2311 if-feature "compression"; 2312 uses compression-content; 2313 } 2314 case no-compression { 2315 description 2316 "RFC8724 allows a rule for uncompressed headers."; 2317 } 2318 description 2319 "A rule is either for compression, no compression or 2320 fragmentation."; 2321 } 2322 description 2323 "Set of rules compression, no compression or fragmentation 2324 rules identified by their rule-id."; 2325 } 2326 description 2327 "a SCHC set of rules is composed of a list of rule which are 2328 either compression or fragmentation."; 2329 } 2330 } 2331 2333 Figure 24 2335 8. Normative References 2337 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2338 Zuniga, "SCHC: Generic Framework for Static Context Header 2339 Compression and Fragmentation", RFC 8724, 2340 DOI 10.17487/RFC8724, April 2020, 2341 . 2343 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 2344 Context Header Compression (SCHC) for the Constrained 2345 Application Protocol (CoAP)", RFC 8824, 2346 DOI 10.17487/RFC8824, June 2021, 2347 . 2349 Authors' Addresses 2351 Ana Minaburo 2352 Acklio 2353 1137A avenue des Champs Blancs 2354 35510 Cesson-Sevigne Cedex 2355 France 2356 Email: ana@ackl.io 2358 Laurent Toutain 2359 Institut MINES TELECOM; IMT Atlantique 2360 2 rue de la Chataigneraie 2361 CS 17607 2362 35576 Cesson-Sevigne Cedex 2363 France 2364 Email: Laurent.Toutain@imt-atlantique.fr