idnits 2.17.00 (12 Aug 2021) /tmp/idnits33817/draft-ietf-lpwan-schc-yang-data-model-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 193: '...odel, each field MUST be identified th...' RFC 2119 keyword, line 197: '...for this protocol MUST derive from the...' RFC 2119 keyword, line 664: '... "All1 MUST contain a tile.";...' RFC 2119 keyword, line 1876: '... "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 1173 has weird spacing: '...osition uin...' == Line 1177 has weird spacing: '...osition uin...' == Line 1181 has weird spacing: '...osition uin...' -- The document date (24 November 2021) is 178 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Standards Track L. Toutain 5 Expires: 28 May 2022 Institut MINES TELECOM; IMT Atlantique 6 24 November 2021 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-06 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 28 May 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3 52 2.2. Identifier generation . . . . . . . . . . . . . . . . . . 4 53 2.3. Field Identifier . . . . . . . . . . . . . . . . . . . . 5 54 2.4. Field length . . . . . . . . . . . . . . . . . . . . . . 7 55 2.5. Field position . . . . . . . . . . . . . . . . . . . . . 8 56 2.6. Direction Indicator . . . . . . . . . . . . . . . . . . . 8 57 2.7. Target Value . . . . . . . . . . . . . . . . . . . . . . 9 58 2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10 59 2.8.1. Matching Operator arguments . . . . . . . . . . . . . 11 60 2.9. Compression Decompression Actions . . . . . . . . . . . . 11 61 2.9.1. Compression Decompression Action arguments . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 26 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 28 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 76 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 49 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 80 1. Introduction 82 2. SCHC rules 84 SCHC is a compression and fragmentation mechanism for constrained 85 networks defined in [RFC8724]. It is based on a static context 86 shared by two entities at the boundary of the constrained network. 87 [RFC8724] provides a non formal representation of the rules used 88 either for compression/decompression (or C/D) or fragmentation/ 89 reassembly (or F/R). The goal of this document is to formalize the 90 description of the rules to offer: 92 * the same definition on both ends, even if the internal 93 representation is different. 95 * an update of the other end to set up some specific values (e.g. 96 IPv6 prefix, Destination address,...) 98 * ... 100 This document defines a YANG module to represent both compression and 101 fragmentation rules, which leads to common representation for values 102 for all the rules elements. 104 SCHC compression is generic, the main mechanism does not refer to a 105 specific protocol. Any header field is abstracted through an ID, a 106 position, a direction, and a value that can be a numerical value or a 107 string. [RFC8724] and [RFC8824] specify fields for IPv6, UDP, CoAP 108 and OSCORE. 110 SCHC fragmentation requires a set of common parameters that are 111 included in a rule. These parameters are defined in [RFC8724]. 113 2.1. Compression Rules 115 [RFC8724] proposes a non formal representation of the compression 116 rule. A compression context for a device is composed of a set of 117 rules. Each rule contains information to describe a specific field 118 in the header to be compressed. 120 +-----------------------------------------------------------------+ 121 | Rule N | 122 +-----------------------------------------------------------------+| 123 | Rule i || 124 +-----------------------------------------------------------------+|| 125 | (FID) Rule 1 ||| 126 |+-------+--+--+--+------------+-----------------+---------------+||| 127 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 128 |+-------+--+--+--+------------+-----------------+---------------+||| 129 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 130 |+-------+--+--+--+------------+-----------------+---------------+||| 131 ||... |..|..|..| ... | ... | ... |||| 132 |+-------+--+--+--+------------+-----------------+---------------+||/ 133 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 134 |+-------+--+--+--+------------+-----------------+---------------+|/ 135 | | 136 \-----------------------------------------------------------------/ 138 Figure 1: Compression Decompression Context 140 2.2. Identifier generation 142 Identifier used in the SCHC YANG Data Model are from the identityref 143 statement to ensure to be globally unique and be easily augmented if 144 needed. The principle to define a new type based on a group of 145 identityref is the following: 147 * define a main identity ending with the keyword base-type. 149 * derive all the identity used in the Data Model from this base 150 type. 152 * create a typedef from this base type. 154 The example (Figure 2) shows how an identityref is created for RCS 155 algorithms used during SCHC fragmentation. 157 // -- RCS algorithm types 159 identity rcs-algorithm-base-type { 160 description 161 "Identify which algorithm is used to compute RSC. 162 The algorithm also defines the size if the RSC field."; 163 } 165 identity rcs-RFC8724 { 166 base rcs-algorithm-base-type; 167 description 168 "CRC 32 defined as default RCS in RFC8724."; 169 } 171 typedef rcs-algorithm-type { 172 type identityref { 173 base rcs-algorithm-base-type; 174 } 175 description 176 "type used in rules"; 177 } 179 Figure 2: Principle to define a type based on identityref. 181 2.3. Field Identifier 183 In the process of compression, the headers of the original packet are 184 first parsed to create a list of fields. This list of fields is 185 matched against the rules to find the appropriate rule and apply 186 compression. [RFC8724] do not state how the field ID value can be 187 constructed. In examples, identification is done through a string 188 indexed by the protocol name (e.g. IPv6.version, CoAP.version,...). 190 The current YANG Data Model includes fields definitions found in 191 [RFC8724], [RFC8824]. 193 Using the YANG model, each field MUST be identified through a global 194 YANG identityref. A YANG field ID for the protocol always derives 195 from the fid-base-type. Then an identity for each protocol is 196 specified using the naming convention fid-<>-base- 197 type. All possible fields for this protocol MUST derive from the 198 protocol identity. The naming convention is "fid" followed by the 199 protocol name and the field name. If a field has to be divided into 200 sub-fields, the field identity serves as a base. 202 The full field-id definition is found in Section 7. The example 203 Figure 3 gives the first field ID definitions. A type is defined for 204 IPv6 protocol, and each field is based on it. Note that the DiffServ 205 bits derives from the Traffic Class identity. 207 identity fid-base-type { 208 description 209 "Field ID base type for all fields"; 210 } 212 identity fid-ipv6-base-type { 213 base fid-base-type; 214 description 215 "Field IP base type for IPv6 headers described in RFC 8200"; 216 } 218 identity fid-ipv6-version { 219 base fid-ipv6-base-type; 220 description 221 "IPv6 version field from RFC8200"; 222 } 224 identity fid-ipv6-trafficclass { 225 base fid-ipv6-base-type; 226 description 227 "IPv6 Traffic Class field from RFC8200"; 228 } 230 identity fid-ipv6-trafficclass-ds { 231 base fid-ipv6-trafficclass; 232 description 233 "IPv6 Traffic Class field from RFC8200, 234 DiffServ field from RFC3168"; 235 } 236 ... 238 Figure 3: Definition of identityref for field IDs 240 The type associated to this identity is fid-type (cf. Figure 4) 242 typedef fid-type { 243 type identityref { 244 base fid-base-type; 245 } 246 description 247 "Field ID generic type."; 248 } 250 Figure 4: Type definition for field IDs 252 2.4. Field length 254 Field length is either an integer giving the size of a field in bits 255 or a specific function. [RFC8724] defines the "var" function which 256 allows variable length fields in byte and [RFC8824] defines the "tkl" 257 function for managing the CoAP Token length field. 259 The naming convention is "fl" followed by the function name. 261 identity fl-base-type { 262 description 263 "Used to extend field length functions."; 264 } 266 identity fl-variable { 267 base fl-base-type; 268 description 269 "Residue length in Byte is sent as defined in 270 for CoAP in RFC 8824 (cf. 5.3)."; 271 } 273 identity fl-token-length { 274 base fl-base-type; 275 description 276 "Residue length in Byte is sent as defined in 277 for CoAP in RFC 8824 (cf. 4.5)."; 278 } 280 Figure 5: Definition of identityref for Field Length 282 Field ID, field length function can be defined as an identityref as 283 shown in Figure 5. 285 Therefore, the type for field length is a union between an integer 286 giving in bits the size of the length and the identityref (cf. 287 Figure 6). 289 typedef fl-type { 290 type union { 291 type int64; /* positive length in bits */ 292 type identityref { /* function */ 293 base fl-base-type; 294 } 295 } 296 description 297 "Field length either a positive integer giving the size in bits 298 or a function defined through an identityref."; 299 } 300 Figure 6: Type definition for field Length 302 2.5. Field position 304 Field position is a positive integer which gives the position of a 305 field, the default value is 1, and incremented at each repetition. 306 value 0 indicates that the position is not important and is not 307 considered during the rule selection process. 309 Field position is a positive integer. The type is an uint8. 311 2.6. Direction Indicator 313 The Direction Indicator (di) is used to tell if a field appears in 314 both direction (Bi) or only uplink (Up) or Downlink (Dw). 316 identity di-base-type { 317 description 318 "Used to extend direction indicators."; 319 } 321 identity di-bidirectional { 322 base di-base-type; 323 description 324 "Direction Indication of bi directionality in 325 RFC 8724 (cf. 7.1)."; 326 } 328 identity di-up { 329 base di-base-type; 330 description 331 "Direction Indication of upstream defined in 332 RFC 8724 (cf. 7.1)."; 333 } 335 identity di-down { 336 base di-base-type; 337 description 338 "Direction Indication of downstream defined in 339 RFC 8724 (cf. 7.1)."; 340 } 342 Figure 7: Definition of identityref for direction indicators 344 Figure 7 gives the identityref for Direction Indicators. The naming 345 convention is "di" followed by the Direction Indicator name. 347 The type is "di-type" (cf. Figure 8). 349 typedef di-type { 350 type identityref { 351 base di-base-type; 352 } 353 description 354 "Direction in LPWAN network, up when emitted by the device, 355 down when received by the device, bi when emitted or 356 received by the device."; 357 } 359 Figure 8: Type definition for direction indicators 361 2.7. Target Value 363 The Target Value is a list of binary sequences of any length, aligned 364 on the left. Figure 9 gives the definition of a single element of a 365 Target Value. In the rule, this will be used as a list, with 366 position as a key. The highest position value is used to compute the 367 size of the index sent in residue for LSB CDA. The position allows 368 to specify several values: 370 * For Equal and LSB, a single value is used, such as for the equal 371 or LSB CDA, the position is set to 0. 373 * For match-mapping, several of these values can be contained in a 374 Target Value field. Position values must start from 0 and be 375 contiguous. 377 grouping tv-struct { 378 description 379 "Define the target value element. Always a binary type, strings 380 must be converted to binary. field-id allows the conversion 381 to the appropriate type."; 382 leaf value { 383 type binary; 384 description 385 "Target Value"; 386 } 387 leaf position { 388 type uint16; 389 description 390 "If only one element position is 0, otherwise position is the 391 the position in the matching list."; 392 } 393 } 394 Figure 9: Definition of target value 396 2.8. Matching Operator 398 Matching Operator (MO) is a function applied between a field value 399 provided by the parsed header and the target value. [RFC8724] 400 defines 4 MO as listed in Figure 10. 402 identity mo-base-type { 403 description 404 "Used to extend Matching Operators with SID values"; 405 } 407 identity mo-equal { 408 base mo-base-type; 409 description 410 "Equal MO as defined RFC 8724 (cf. 7.3)"; 411 } 413 identity mo-ignore { 414 base mo-base-type; 415 description 416 "Ignore MO as defined RFC 8724 (cf. 7.3)"; 417 } 419 identity mo-msb { 420 base mo-base-type; 421 description 422 "MSB MO as defined RFC 8724 (cf. 7.3)"; 423 } 425 identity mo-match-mapping { 426 base mo-base-type; 427 description 428 "match-mapping MO as defined RFC 8724 (cf. 7.3)"; 429 } 431 Figure 10: Definition of identityref for Matching Operator 433 The naming convention is "mo" followed by the MO name. 435 The type is "mo-type" (cf. Figure 11) 436 typedef mo-type { 437 type identityref { 438 base mo-base-type; 439 } 440 description 441 "Matching Operator (MO) to compare fields values with 442 target values"; 443 } 445 Figure 11: Type definition for Matching Operator 447 2.8.1. Matching Operator arguments 449 They are viewed as a list of tv-struct. 451 2.9. Compression Decompression Actions 453 Compression Decompression Action (CDA) identified the function to use 454 either for compression or decompression. [RFC8724] defines 6 CDA. 456 Figure 13 gives some CDA definition, the full definition is in 457 Section 7. 459 identity cda-base-type { 460 description 461 "Compression Decompression Actions."; 462 } 464 identity cda-not-sent { 465 base cda-base-type; 466 description 467 "not-sent CDA as defines in RFC 8724 (cf. 7.4)."; 468 } 470 identity cda-value-sent { 471 base cda-base-type; 472 description 473 "value-sent CDA as defines in RFC 8724 (cf. 7.4)."; 474 } 476 identity cda-lsb { 477 base cda-base-type; 478 description 479 "LSB CDA as defines in RFC 8724 (cf. 7.4)."; 480 } 482 identity cda-mapping-sent { 483 base cda-base-type; 484 description 485 "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)."; 486 } 488 .... 490 Figure 12: Definition of identityref for Compresion Decompression 491 Action 493 The naming convention is "cda" followed by the CDA name. 495 typedef cda-type { 496 type identityref { 497 base cda-base-type; 498 } 499 description 500 "Compression Decompression Action to compression or 501 decompress a field."; 502 } 504 Figure 13: Type definition for Compresion Decompression Action 506 2.9.1. Compression Decompression Action arguments 508 Currently no CDA requires arguments, but the future some CDA may 509 require several arguments. They are viewed as a list of target- 510 values-type. 512 2.10. Fragmentation rule 514 Fragmentation is optional in the data model and depends on the 515 presence of the "fragmentation" feature. 517 Most of parameters for fragmentation are defined in Annex D of 518 [RFC8724]. 520 Since fragmentation rules work for a specific direction, they contain 521 a mandatory direction. The type is the same as the one used in 522 compression entries, but the use of bidirectional is forbidden. 524 2.10.1. Fragmentation mode 526 [RFC8724] defines 3 fragmentation modes: 528 * No Ack: this mode is unidirectionnal, no acknowledgment is sent 529 back. 531 * Ack Always: each fragmentation window must be explicitly 532 acknowledged before going to the next. 534 * Ack on Error: A window is acknowledged only when the receiver 535 detects some missing fragments. 537 Figure 14 give the definition for identifiers from these three modes. 539 identity fragmentation-mode-base-type { 540 description 541 "fragmentation mode."; 542 } 544 identity fragmentation-mode-no-ack { 545 base fragmentation-mode-base-type; 546 description 547 "No Ack of RFC 8724."; 548 } 550 identity fragmentation-mode-ack-always { 551 base fragmentation-mode-base-type; 552 description 553 "Ack Always of RFC8724."; 554 } 556 identity fragmentation-mode-ack-on-error { 557 base fragmentation-mode-base-type; 558 description 559 "Ack on Error of RFC8724."; 560 } 562 typedef fragmentation-mode-type { 563 type identityref { 564 base fragmentation-mode-base-type; 565 } 566 description 567 "type used in rules"; 568 } 570 Figure 14: Definition of fragmentation mode identifer 572 The naming convention is "fragmentation-mode" followed by the 573 fragmentation mode name. 575 2.10.2. Fragmentation Header 577 A data fragment header, directly following the rule ID can be sent on 578 the fragmentation direction. The direction is mandatory and must be 579 up or down. bidirectional is forbidden. The SCHC header may be 580 composed of (cf. Figure 15): 582 * a Datagram Tag (Dtag) identifying the datagram being fragmented if 583 the fragmentation applies concurrently on several datagrams. This 584 field in optional and its length is defined by the rule. 586 * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack- 587 Always, its size is 1 and depends on the rule in Ack-on-Error. 588 This field is not need in No-Ack mode. 590 * a Fragment Compressed Number (FCN) indicating the fragment/tile 591 position on the window. This field is mandatory on all modes 592 defined in [RFC8724], its size is defined by the rule. 594 |-- SCHC Fragment Header ----| 595 |-- T --|-M-|-- N --| 596 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 597 | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed) 598 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 600 Figure 15: Data fragment header from RFC8724 602 2.10.3. Last fragment format 604 The last fragment of a datagram is sent with an RCS (Reassembly Check 605 Sequence) field to detect residual transmission error and possible 606 losses in the last window. [RFC8724] defines a single algorithm 607 based on Ethernet CRC computation. The identity of the RCS algorithm 608 is shown in Figure 16. 610 // -- RCS algorithm types 612 identity rcs-algorithm-base-type { 613 description 614 "Identify which algorithm is used to compute RSC. 615 The algorithm also defines the size if the RSC field."; 616 } 618 identity rcs-RFC8724 { 619 base rcs-algorithm-base-type; 620 description 621 "CRC 32 defined as default RCS in RFC8724."; 622 } 624 typedef rcs-algorithm-type { 625 type identityref { 626 base rcs-algorithm-base-type; 627 } 628 description 629 "type used in rules."; 630 } 632 Figure 16: type definition for RCS 634 The naming convention is "rcs" followed by the algorithm name. 636 For Ack-on-Error mode, the All-1 fragment may just contain the RCS or 637 can include a tile. The parameters defined in Figure 17 allows to 638 define the behavior: 640 * all1-data-no: the last fragment contains no data, just the RCS 642 * all1-data-yes: the last fragment includes a single tile and the 643 RCS 645 * all1-data-sender-choice: the last fragment may or may not contain 646 a single tile. The receiver can detect if a tile is present. 648 // -- All1 with data types 650 identity all1-data-base-type { 651 description 652 "Type to define when to send an Acknowledgment message."; 653 } 655 identity all1-data-no { 656 base all1-data-base-type; 657 description 658 "All1 contains no tiles."; 659 } 661 identity all1-data-yes { 662 base all1-data-base-type; 663 description 664 "All1 MUST contain a tile."; 665 } 667 identity all1-data-sender-choice { 668 base all1-data-base-type; 669 description 670 "Fragmentation process choose to send tiles or not in all1."; 671 } 673 typedef all1-data-type { 674 type identityref { 675 base all1-data-base-type; 676 } 677 description 678 "Type used in rules."; 679 } 681 Figure 17: type definition for RCS 683 The naming convention is "all1-data" followed by the behavior 684 identifier. 686 2.10.4. Acknowledgment behavior 688 A cknowledgment fragment header goes in the opposite direction of 689 data. The header is composed of (see Figure 18): 691 * a Dtag (if present). 693 * a mandatory window as in the data fragment. 695 * a C bit giving the status of RCS validation. In case of failure, 696 a bitmap follows, indicating received fragment/tile. The size of 697 the bitmap is given by the FCN value. 699 NOTE: IN THE DATA MODEL THERE IS A max-window-size FIELD TO LIMIT THE 700 BITMAP SIZE, BUT IS NO MORE IN RFC8724! DO WE KEEP IT? 702 |--- SCHC ACK Header ----| 703 |-- T --|-M-| 1 | 704 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 705 | RuleID | DTag | W |C=1| padding as needed (success) 706 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 708 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 709 | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 710 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 712 Figure 18: Acknowledgment fragment header for RFC8724 714 For Ack-on-Error, SCHC defined when acknowledgment can be sent. This 715 can be at any time defined by the layer 2, at the end of a window 716 (FCN All-0) or at the end of the fragment (FCN All-1). The following 717 identifiers (cf. Figure 19) define the acknowledgment behavior. 719 // -- Ack behavior 721 identity ack-behavior-base-type { 722 description 723 "Define when to send an Acknowledgment ."; 724 } 726 identity ack-behavior-after-All0 { 727 base ack-behavior-base-type; 728 description 729 "Fragmentation expects Ack after sending All0 fragment."; 730 } 732 identity ack-behavior-after-All1 { 733 base ack-behavior-base-type; 734 description 735 "Fragmentation expects Ack after sending All1 fragment."; 736 } 738 identity ack-behavior-always { 739 base ack-behavior-base-type; 740 description 741 "Fragmentation expects Ack after sending every fragment."; 742 } 744 typedef ack-behavior-type { 745 type identityref { 746 base ack-behavior-base-type; 747 } 748 description 749 "Type used in rules."; 750 } 752 Figure 19: bitmap generation behavior 754 The naming convention is "ack-behavior" followed by the algorithm 755 name. 757 2.10.5. Fragmentation Parameters 759 The state machine requires some common values to handle 760 fragmentation: 762 * retransmission-timer gives in seconds the duration before sending 763 an ack request (cf. section 8.2.2.4. of [RFC8724]). If specified, 764 value must be higher or equal to 1. 766 * inactivity-timer gives in seconds the duration before aborting 767 (cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly 768 indicates that this timer is disabled. 770 * max-ack-requests gives the number of attempts before aborting (cf. 771 section 8.2.2.4. of [RFC8724]). 773 * maximum-packet-size gives in bytes the larger packet size that can 774 be reassembled. 776 The are defined as unsigned integer, see Section 7. 778 2.10.6. Layer 2 parameters 780 The data model includes two parameters needed for fragmentation: 782 * l2-word-size: [RFC8724] base fragmentation on a layer 2 word which 783 can be of any length. The default value is 8 and correspond to 784 the default value for byte aligned layer 2. A value of 1 will 785 indicate that there is no alignment and no need for padding. 787 * maximum-packet-size: defines the maximum size of a uncompressed 788 datagram. By default, the value is set to 1280 bytes. 790 They are defined as unsigned integer, see Section 7. 792 3. Rule definition 794 A rule is either a C/D or an F/R rule. A rule is identified by the 795 rule ID value and its associated length. The YANG grouping rule-id- 796 type defines the structure used to represent a rule ID. Length of 0 797 is allowed to represent an implicit rule. 799 Three types of rules are defined in [RFC8724]: 801 * Compression: a compression rule is associated to the rule ID. 803 * No compression: nothing is associated to the rule ID. 805 * Fragmentation: fragmentation parameters are associated to the rule 806 ID. Fragmentation is optional and feature "fragmentation" should 807 be set. 809 grouping rule-id-type { 810 leaf rule-id-value { 811 type uint32; 812 description 813 "Rule ID value, this value must be unique combined with 814 the length."; 815 } 816 leaf rule-id-length { 817 type uint8 { 818 range "0..32"; 819 } 820 description 821 "Rule ID length in bits, value 0 is for implicit rules."; 822 } 823 description 824 "A rule ID is composed of a value and a length in bit."; 825 } 827 // SCHC table for a specific device. 829 container schc { 830 list rule { 831 key "rule-id-value rule-id-length"; 832 uses rule-id-type; 833 choice nature { 834 case fragmentation { 835 //if-feature "fragmentation"; 836 uses fragmentation-content; 837 } 838 case compression { 839 uses compression-content; 840 } 841 case no-compression { 842 description 843 "RFC8724 allows a rule for uncompressed headers."; 844 } 845 description 846 "A rule is either for compression, no compression or 847 fragmentation."; 848 } 849 description 850 "Set of rules compression, no compression or fragmentation 851 rules identified by their rule-id."; 852 } 853 description 854 "a SCHC set of rules is composed of a list of rule which are 855 either compression or fragmentation."; 856 } 858 } 860 Figure 20: Definition of a SCHC Context 862 To access to a specific rule, rule-id and its specific length is used 863 as a key. The rule is either a compression or a fragmentation rule. 865 Each context can be identified though a version id. 867 3.1. Compression rule 869 A compression rule is composed of entries describing its processing 870 (cf. Figure 21). An entry contains all the information defined in 871 Figure 1 with the types defined above. 873 The compression rule described Figure 1 is defined by compression- 874 content. It defines a list of compression-rule-entry, indexed by 875 their field id, position and direction. The compression-rule-entry 876 element represent a line of the table Figure 1. Their type reflects 877 the identifier types defined in Section 2.1 879 Some controls are made on the values: 881 * target value must be present for MO different from ignore. 883 * when MSB MO is specified, the matching-operator-value must be 884 present 886 grouping compression-rule-entry { 887 description 888 "These entries defines a compression entry (i.e. a line) 889 as defined in RFC 8724 and fragmentation parameters. 891 +-------+--+--+--+------------+-----------------+---------------+ 892 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 893 +-------+--+--+--+------------+-----------------+---------------+ 895 An entry in a compression rule is composed of 7 elements: 896 - Field ID: The header field to be compressed. The content is a 897 YANG identifer. 898 - Field Length : either a positive integer of a function 899 defined as a YANF id. 900 - Field Position: a positive (and possibly equal to 0) integer. 901 - Direction Indicator: a YANG identifier giving the direction. 902 - Target value: a value against which the header Field is 903 compared. 904 - Matching Operator: a YANG id giving the operation, paramters 905 may be associated to that operator. 907 - Comp./Decomp. Action: A YANG id giving the compression or 908 decompression action, paramters may be associated to that 909 action. 910 "; 911 leaf field-id { 912 type schc:fid-type; 913 mandatory true; 914 description 915 "Field ID, identify a field in the header with a YANG 916 referenceid."; 917 } 918 leaf field-length { 919 type schc:fl-type; 920 mandatory true; 921 description 922 "Field Length in bit or through a function defined as a 923 YANG referenceid."; 924 } 925 leaf field-position { 926 type uint8; 927 mandatory true; 928 description 929 "Field position in the header is a integer. If the field is not 930 repeated in the header the value is 1, and incremented for each 931 repetition of the field. Position 0 means that the position is 932 not important and order may change when decompressed"; 933 } 934 leaf direction-indicator { 935 type schc:di-type; 936 mandatory true; 937 description 938 "Direction Indicator, a YANG referenceid to say if the packet 939 is bidirectional, up or down"; 940 } 941 list target-value { 942 key "position"; 943 uses tv-struct; 944 description 945 "A list of value to compare with the header field value. 946 If target value is a singleton, position must be 0. 947 For matching-list, should be consecutive position 948 values starting from 1."; 949 } 950 leaf matching-operator { 951 type schc:mo-type; 952 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 953 error-message 954 "mo-equal, mo-msb and mo-match-mapping need target-value"; 956 description 957 "target-value is not required for mo-ignore"; 958 } 959 must "not (derived-from-or-self(., 'mo-msb')) or 960 ../matching-operator-value" { 961 error-message "mo-msb requires length value"; 962 } 963 mandatory true; 964 description 965 "MO: Matching Operator"; 966 } 967 list matching-operator-value { 968 key "position"; 969 uses tv-struct; 970 description 971 "Matching Operator Arguments, based on TV structure to allow 972 several arguments. 973 In RFC 8724, only MSB define a single argument: length in 974 bits"; 975 } 976 leaf comp-decomp-action { 977 type schc:cda-type; 978 mandatory true; 979 description 980 "CDA: Compression Decompression Action."; 981 } 982 list comp-decomp-action-value { 983 key "position"; 984 uses tv-struct; 985 description 986 "CDA Arguments, based on TV structure to allow several 987 arguments. In RFC 8724, no argument is defined for CDA."; 988 } 989 } 991 grouping compression-content { 992 list entry { 993 key "field-id field-position direction-indicator"; 994 uses compression-rule-entry; 995 description 996 "A compression rule is a list of rule entry describing 997 each header field. An entry is identifed through a field-id, 998 its position in the packet and its direction."; 999 } 1000 description 1001 "Define a compression rule composed of a list of entries."; 1002 } 1003 Figure 21: Definition of a compression entry 1005 3.2. Fragmentation rule 1007 A Fragmentation rule is composed of entries describing the protocol 1008 behavior. Some on them are numerical entries, others are identifiers 1009 defined in Section 2.10. 1011 The data model defines some relations between the entries: 1013 * direction must be either up or down (not bidirectional). 1015 * W size is only needed for Ack Always and Ack on Error modes. 1017 grouping fragmentation-content { 1018 description 1019 "This grouping defines the fragmentation parameters for 1020 all the modes (No Ack, Ack Always and Ack on Error) specified in 1021 RFC 8724."; 1022 leaf l2-word-size { 1023 type uint8; 1024 default "8"; 1025 description 1026 "Size in bit of the layer 2 word"; 1027 } 1028 leaf direction { 1029 type schc:di-type; 1030 must "derived-from-or-self(., 'di-up') or 1031 derived-from-or-self(., 'di-down')" { 1032 error-message 1033 "direction for fragmentation rules are up or down."; 1034 } 1035 mandatory true; 1036 description 1037 "Should be up or down, bi directionnal is forbiden."; 1038 } 1039 leaf dtag-size { 1040 type uint8; 1041 default "0"; 1042 description 1043 "Size in bit of the DTag field (T variable from RFC8724)."; 1044 } 1045 leaf w-size { 1046 when "not(derived-from(../fragmentation-mode, 1047 'fragmentation-mode-no-ack'))"; 1048 type uint8; 1049 description 1050 "Size in bit of the window field (M variable from RFC8724)."; 1052 } 1053 leaf fcn-size { 1054 type uint8; 1055 mandatory true; 1056 description 1057 "Size in bit of the FCN field (M variable from RFC8724)."; 1058 } 1059 leaf rcs-algorithm { 1060 type rcs-algorithm-type; 1061 default "schc:rcs-RFC8724"; 1062 description 1063 "Algoritm used for RCS"; 1064 } 1065 leaf maximum-window-size { 1066 type uint16; 1067 description 1068 "By default 2^wsize - 1"; 1069 } 1070 leaf retransmission-timer { 1071 type uint64 { 1072 range "1..max"; 1073 } 1074 description 1075 "Duration in seconds of the retransmission timer."; 1076 } 1077 leaf inactivity-timer { 1078 type uint64; 1079 description 1080 "Duration is seconds of the inactivity timer, 1081 0 indicates the timer is disabled."; 1082 } 1083 leaf max-ack-requests { 1084 type uint8 { 1085 range "1..max"; 1086 } 1087 description 1088 "The maximum number of retries for a specific SCHC ACK."; 1089 } 1090 leaf maximum-packet-size { 1091 type uint16; 1092 default "1280"; 1093 description 1094 "When decompression is done, packet size must not 1095 strictly exceed this limit in Bytes."; 1096 } 1097 leaf fragmentation-mode { 1098 type schc:fragmentation-mode-type; 1099 mandatory true; 1100 description 1101 "which fragmentation mode is used (noAck, AckAlways, 1102 AckonError)"; 1103 } 1104 choice mode { 1105 case no-ack; 1106 case ack-always; 1107 case ack-on-error { 1108 leaf tile-size { 1109 when "derived-from(../fragmentation-mode, 1110 'fragmentation-mode-ack-on-error')"; 1111 type uint8; 1112 description 1113 "Size in bit of tiles, if not specified or set to 0, 1114 tile fills the fragment."; 1115 } 1116 leaf tile-in-All1 { 1117 when "derived-from(../fragmentation-mode, 1118 'fragmentation-mode-ack-on-error')"; 1119 type schc:all1-data-type; 1120 description 1121 "When true, sender and receiver except a tile in 1122 All-1 frag."; 1123 } 1124 leaf ack-behavior { 1125 when "derived-from(../fragmentation-mode, 1126 'fragmentation-mode-ack-on-error')"; 1127 type schc:ack-behavior-type; 1128 description 1129 "Sender behavior to acknowledge, after All-0, All-1 or 1130 when the LPWAN allows it (Always)."; 1131 } 1132 } 1133 description 1134 "RFC 8724 defines 3 fragmentation modes."; 1135 } 1136 } 1138 3.3. YANG Tree 1139 module: ietf-schc 1140 +--rw schc 1141 +--rw rule* [rule-id-value rule-id-length] 1142 +--rw rule-id-value uint32 1143 +--rw rule-id-length uint8 1144 +--rw (nature)? 1145 +--:(fragmentation) 1146 | +--rw l2-word-size? uint8 1147 | +--rw direction schc:di-type 1148 | +--rw dtag-size? uint8 1149 | +--rw w-size? uint8 1150 | +--rw fcn-size uint8 1151 | +--rw rcs-algorithm? rcs-algorithm-type 1152 | +--rw maximum-window-size? uint16 1153 | +--rw retransmission-timer? uint64 1154 | +--rw inactivity-timer? uint64 1155 | +--rw max-ack-requests? uint8 1156 | +--rw maximum-packet-size? uint16 1157 | +--rw fragmentation-mode schc:fragmentation-mode-type 1158 | +--rw (mode)? 1159 | +--:(no-ack) 1160 | +--:(ack-always) 1161 | +--:(ack-on-error) 1162 | +--rw tile-size? uint8 1163 | +--rw tile-in-All1? schc:all1-data-type 1164 | +--rw ack-behavior? schc:ack-behavior-type 1165 +--:(compression) 1166 | +--rw entry* [field-id field-position direction-indicator] 1167 | +--rw field-id schc:fid-type 1168 | +--rw field-length schc:fl-type 1169 | +--rw field-position uint8 1170 | +--rw direction-indicator schc:di-type 1171 | +--rw target-value* [position] 1172 | | +--rw value? binary 1173 | | +--rw position uint16 1174 | +--rw matching-operator schc:mo-type 1175 | +--rw matching-operator-value* [position] 1176 | | +--rw value? binary 1177 | | +--rw position uint16 1178 | +--rw comp-decomp-action schc:cda-type 1179 | +--rw comp-decomp-action-value* [position] 1180 | +--rw value? binary 1181 | +--rw position uint16 1182 +--:(no-compression) 1184 Figure 22 1186 4. IANA Considerations 1188 This document has no request to IANA. 1190 5. Security considerations 1192 This document does not have any more Security consideration than the 1193 ones already raised on [RFC8724] 1195 6. Acknowledgements 1197 The authors would like to thank Dominique Barthel, Carsten Bormann, 1198 Alexander Pelov. 1200 7. YANG Module 1202 file ietf-schc@2021-11-10.yang 1203 module ietf-schc { 1204 yang-version 1.1; 1205 namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; 1206 prefix schc; 1208 organization 1209 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; 1210 contact 1211 "WG Web: 1212 WG List: 1213 Editor: Laurent Toutain 1214 1215 Editor: Ana Minaburo 1216 "; 1217 description 1218 " 1219 Copyright (c) 2021 IETF Trust and the persons identified as 1220 authors of the code. All rights reserved. 1222 Redistribution and use in source and binary forms, with or 1223 without modification, is permitted pursuant to, and subject to 1224 the license terms contained in, the Simplified BSD License set 1225 forth in Section 4.c of the IETF Trust's Legal Provisions 1226 Relating to IETF Documents 1227 (https://trustee.ietf.org/license-info). 1229 This version of this YANG module is part of RFC XXXX 1230 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1231 for full legal notices. 1233 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1234 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1235 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1236 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1237 they appear in all capitals, as shown here. 1239 ***************************************************************** 1241 Generic Data model for Static Context Header Compression Rule for 1242 SCHC, based on RFC 8724 and RFC8824. Include compression, no 1243 compression and fragmentation rules. 1245 This module is a YANG model for SCHC rules (RFc 8724). 1246 RFC 8724 describes a rule in a abstract way through a table. 1248 |-----------------------------------------------------------------| 1249 | (FID) Rule 1 | 1250 |+-------+--+--+--+------------+-----------------+---------------+| 1251 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1252 |+-------+--+--+--+------------+-----------------+---------------+| 1253 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1254 |+-------+--+--+--+------------+-----------------+---------------+| 1255 ||... |..|..|..| ... | ... | ... || 1256 |+-------+--+--+--+------------+-----------------+---------------+| 1257 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1258 +-------+--+--+--+------------+-----------------+---------------+|| 1259 |-----------------------------------------------------------------| 1261 This module proposes a global data model that can be used for rule 1262 exchanges or modification. It proposes both the data model format 1263 and the global identifiers used to describes some operations in 1264 fields. 1265 This data model applies both to compression and fragmentation."; 1267 revision 2021-11-10 { 1268 description 1269 "Initial version from RFC XXXX "; 1270 reference 1271 "RFC XXX: Data Model for Static Context Header Compression 1272 (SCHC)"; 1273 } 1275 feature fragmentation { 1276 description 1277 "Fragmentation is usually required only at the transportation 1278 level."; 1279 } 1281 // ------------------------- 1282 // Field ID type definition 1283 //-------------------------- 1284 // generic value TV definition 1286 identity fid-base-type { 1287 description 1288 "Field ID base type for all fields"; 1289 } 1291 identity fid-ipv6-base-type { 1292 base fid-base-type; 1293 description 1294 "Field IP base type for IPv6 headers described in RFC 8200"; 1295 } 1297 identity fid-ipv6-version { 1298 base fid-ipv6-base-type; 1299 description 1300 "IPv6 version field from RFC8200"; 1301 } 1303 identity fid-ipv6-trafficclass { 1304 base fid-ipv6-base-type; 1305 description 1306 "IPv6 Traffic Class field from RFC8200"; 1307 } 1309 identity fid-ipv6-trafficclass-ds { 1310 base fid-ipv6-trafficclass; 1311 description 1312 "IPv6 Traffic Class field from RFC8200, 1313 DiffServ field from RFC3168"; 1314 } 1316 identity fid-ipv6-trafficclass-ecn { 1317 base fid-ipv6-trafficclass; 1318 description 1319 "IPv6 Traffic Class field from RFC8200, 1320 ECN field from RFC3168"; 1321 } 1323 identity fid-ipv6-flowlabel { 1324 base fid-ipv6-base-type; 1325 description 1326 "IPv6 Flow Label field from RFC8200"; 1327 } 1329 identity fid-ipv6-payloadlength { 1330 base fid-ipv6-base-type; 1331 description 1332 "IPv6 Payload Length field from RFC8200"; 1333 } 1335 identity fid-ipv6-nextheader { 1336 base fid-ipv6-base-type; 1337 description 1338 "IPv6 Next Header field from RFC8200"; 1339 } 1341 identity fid-ipv6-hoplimit { 1342 base fid-ipv6-base-type; 1343 description 1344 "IPv6 Next Header field from RFC8200"; 1345 } 1347 identity fid-ipv6-devprefix { 1348 base fid-ipv6-base-type; 1349 description 1350 "correspond either to the source address or the desdination 1351 address prefix of RFC 8200. Depending if it is 1352 respectively a uplink or an downklink message."; 1353 } 1355 identity fid-ipv6-deviid { 1356 base fid-ipv6-base-type; 1357 description 1358 "correspond either to the source address or the desdination 1359 address prefix of RFC 8200. Depending if it is respectively 1360 a uplink or an downklink message."; 1361 } 1363 identity fid-ipv6-appprefix { 1364 base fid-ipv6-base-type; 1365 description 1366 "correspond either to the source address or the desdination 1367 address prefix of RFC 768. Depending if it is respectively 1368 a downlink or an uplink message."; 1369 } 1371 identity fid-ipv6-appiid { 1372 base fid-ipv6-base-type; 1373 description 1374 "correspond either to the source address or the desdination 1375 address prefix of RFC 768. Depending if it is respectively 1376 a downlink or an uplink message."; 1377 } 1378 identity fid-udp-base-type { 1379 base fid-base-type; 1380 description 1381 "Field IP base type for UDP headers described in RFC 768"; 1382 } 1384 identity fid-udp-dev-port { 1385 base fid-udp-base-type; 1386 description 1387 "UDP length from RFC 768"; 1388 } 1390 identity fid-udp-app-port { 1391 base fid-udp-base-type; 1392 description 1393 "UDP length from RFC 768"; 1394 } 1396 identity fid-udp-length { 1397 base fid-udp-base-type; 1398 description 1399 "UDP length from RFC 768"; 1400 } 1402 identity fid-udp-checksum { 1403 base fid-udp-base-type; 1404 description 1405 "UDP length from RFC 768"; 1406 } 1408 identity fid-coap-base-type { 1409 base fid-base-type; 1410 description 1411 "Field IP base type for UDP headers described in RFC 768"; 1412 } 1414 identity fid-coap-version { 1415 base fid-coap-base-type; 1416 description 1417 "CoAP version from RFC 7252"; 1418 } 1420 identity fid-coap-type { 1421 base fid-coap-base-type; 1422 description 1423 "CoAP type from RFC 7252"; 1424 } 1425 identity fid-coap-tkl { 1426 base fid-coap-base-type; 1427 description 1428 "CoAP token length from RFC 7252"; 1429 } 1431 identity fid-coap-code { 1432 base fid-coap-base-type; 1433 description 1434 "CoAP code from RFC 7252"; 1435 } 1437 identity fid-coap-code-class { 1438 base fid-coap-code; 1439 description 1440 "CoAP code class from RFC 7252"; 1441 } 1443 identity fid-coap-code-detail { 1444 base fid-coap-code; 1445 description 1446 "CoAP code detail from RFC 7252"; 1447 } 1449 identity fid-coap-mid { 1450 base fid-coap-base-type; 1451 description 1452 "CoAP message ID from RFC 7252"; 1453 } 1455 identity fid-coap-token { 1456 base fid-coap-base-type; 1457 description 1458 "CoAP token from RFC 7252"; 1459 } 1461 identity fid-coap-option-if-match { 1462 base fid-coap-base-type; 1463 description 1464 "CoAP option If-Match from RFC 7252"; 1465 } 1467 identity fid-coap-option-uri-host { 1468 base fid-coap-base-type; 1469 description 1470 "CoAP option URI-Host from RFC 7252"; 1471 } 1472 identity fid-coap-option-etag { 1473 base fid-coap-base-type; 1474 description 1475 "CoAP option Etag from RFC 7252"; 1476 } 1478 identity fid-coap-option-if-none-match { 1479 base fid-coap-base-type; 1480 description 1481 "CoAP option if-none-match from RFC 7252"; 1482 } 1484 identity fid-coap-option-observe { 1485 base fid-coap-base-type; 1486 description 1487 "CoAP option Observe from RFC 7641"; 1488 } 1490 identity fid-coap-option-uri-port { 1491 base fid-coap-base-type; 1492 description 1493 "CoAP option Uri-Port from RFC 7252"; 1494 } 1496 identity fid-coap-option-location-path { 1497 base fid-coap-base-type; 1498 description 1499 "CoAP option Location-Path from RFC 7252"; 1500 } 1502 identity fid-coap-option-uri-path { 1503 base fid-coap-base-type; 1504 description 1505 "CoAP option Uri-Path from RFC 7252"; 1506 } 1508 identity fid-coap-option-content-format { 1509 base fid-coap-base-type; 1510 description 1511 "CoAP option Content Format from RFC 7252"; 1512 } 1514 identity fid-coap-option-max-age { 1515 base fid-coap-base-type; 1516 description 1517 "CoAP option Max-Age from RFC 7252"; 1518 } 1519 identity fid-coap-option-uri-query { 1520 base fid-coap-base-type; 1521 description 1522 "CoAP option Uri-Query from RFC 7252"; 1523 } 1525 identity fid-coap-option-accept { 1526 base fid-coap-base-type; 1527 description 1528 "CoAP option Max-Age from RFC 7252"; 1529 } 1531 identity fid-coap-option-location-query { 1532 base fid-coap-base-type; 1533 description 1534 "CoAP option Location-Query from RFC 7252"; 1535 } 1537 identity fid-coap-option-block2 { 1538 base fid-coap-base-type; 1539 description 1540 "CoAP option Block2 from RFC 7959"; 1541 } 1543 identity fid-coap-option-block1 { 1544 base fid-coap-base-type; 1545 description 1546 "CoAP option Block1 from RFC 7959"; 1547 } 1549 identity fid-coap-option-size2 { 1550 base fid-coap-base-type; 1551 description 1552 "CoAP option size2 from RFC 7959"; 1553 } 1555 identity fid-coap-option-proxy-uri { 1556 base fid-coap-base-type; 1557 description 1558 "CoAP option Proxy-Uri from RFC 7252"; 1559 } 1561 identity fid-coap-option-proxy-scheme { 1562 base fid-coap-base-type; 1563 description 1564 "CoAP option Proxy-scheme from RFC 7252"; 1565 } 1566 identity fid-coap-option-size1 { 1567 base fid-coap-base-type; 1568 description 1569 "CoAP option Size1 from RFC 7252"; 1570 } 1572 identity fid-coap-option-no-response { 1573 base fid-coap-base-type; 1574 description 1575 "CoAP option No response from RFC 7967"; 1576 } 1578 identity fid-coap-option-oscore-flags { 1579 base fid-coap-base-type; 1580 description 1581 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1582 } 1584 identity fid-coap-option-oscore-piv { 1585 base fid-coap-base-type; 1586 description 1587 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1588 } 1590 identity fid-coap-option-oscore-kid { 1591 base fid-coap-base-type; 1592 description 1593 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1594 } 1596 identity fid-coap-option-oscore-kidctx { 1597 base fid-coap-base-type; 1598 description 1599 "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1600 } 1602 //---------------------------------- 1603 // Field Length type definition 1604 //---------------------------------- 1606 identity fl-base-type { 1607 description 1608 "Used to extend field length functions."; 1609 } 1611 identity fl-variable { 1612 base fl-base-type; 1613 description 1614 "Residue length in Byte is sent as defined in 1615 for CoAP in RFC 8824 (cf. 5.3)."; 1616 } 1618 identity fl-token-length { 1619 base fl-base-type; 1620 description 1621 "Residue length in Byte is sent as defined in 1622 for CoAP in RFC 8824 (cf. 4.5)."; 1623 } 1625 //--------------------------------- 1626 // Direction Indicator type 1627 //--------------------------------- 1629 identity di-base-type { 1630 description 1631 "Used to extend direction indicators."; 1632 } 1634 identity di-bidirectional { 1635 base di-base-type; 1636 description 1637 "Direction Indication of bi directionality in 1638 RFC 8724 (cf. 7.1)."; 1639 } 1641 identity di-up { 1642 base di-base-type; 1643 description 1644 "Direction Indication of upstream defined in 1645 RFC 8724 (cf. 7.1)."; 1646 } 1648 identity di-down { 1649 base di-base-type; 1650 description 1651 "Direction Indication of downstream defined in 1652 RFC 8724 (cf. 7.1)."; 1653 } 1655 //---------------------------------- 1656 // Matching Operator type definition 1657 //---------------------------------- 1659 identity mo-base-type { 1660 description 1661 "Used to extend Matching Operators with SID values"; 1662 } 1664 identity mo-equal { 1665 base mo-base-type; 1666 description 1667 "Equal MO as defined RFC 8724 (cf. 7.3)"; 1668 } 1670 identity mo-ignore { 1671 base mo-base-type; 1672 description 1673 "Ignore MO as defined RFC 8724 (cf. 7.3)"; 1674 } 1676 identity mo-msb { 1677 base mo-base-type; 1678 description 1679 "MSB MO as defined RFC 8724 (cf. 7.3)"; 1680 } 1682 identity mo-match-mapping { 1683 base mo-base-type; 1684 description 1685 "match-mapping MO as defined RFC 8724 (cf. 7.3)"; 1686 } 1688 //------------------------------ 1689 // CDA type definition 1690 //------------------------------ 1692 identity cda-base-type { 1693 description 1694 "Compression Decompression Actions."; 1695 } 1697 identity cda-not-sent { 1698 base cda-base-type; 1699 description 1700 "not-sent CDA as defines in RFC 8724 (cf. 7.4)."; 1701 } 1703 identity cda-value-sent { 1704 base cda-base-type; 1705 description 1706 "value-sent CDA as defines in RFC 8724 (cf. 7.4)."; 1707 } 1708 identity cda-lsb { 1709 base cda-base-type; 1710 description 1711 "LSB CDA as defines in RFC 8724 (cf. 7.4)."; 1712 } 1714 identity cda-mapping-sent { 1715 base cda-base-type; 1716 description 1717 "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)."; 1718 } 1720 identity cda-compute-length { 1721 base cda-base-type; 1722 description 1723 "compute-length CDA as defines in RFC 8724 (cf. 7.4)"; 1724 } 1726 identity cda-compute-checksum { 1727 base cda-base-type; 1728 description 1729 "compute-checksum CDA as defines in RFC 8724 (cf. 7.4)"; 1730 } 1732 identity cda-deviid { 1733 base cda-base-type; 1734 description 1735 "deviid CDA as defines in RFC 8724 (cf. 7.4)"; 1736 } 1738 identity cda-appiid { 1739 base cda-base-type; 1740 description 1741 "appiid CDA as defines in RFC 8724 (cf. 7.4)"; 1742 } 1744 // -- type definition 1746 typedef fid-type { 1747 type identityref { 1748 base fid-base-type; 1749 } 1750 description 1751 "Field ID generic type."; 1752 } 1754 typedef fl-type { 1755 type union { 1756 type int64; /* positive length in bits */ 1757 type identityref { /* function */ 1758 base fl-base-type; 1759 } 1760 } 1761 description 1762 "Field length either a positive integer giving the size in bits 1763 or a function defined through an identityref."; 1764 } 1766 typedef di-type { 1767 type identityref { 1768 base di-base-type; 1769 } 1770 description 1771 "Direction in LPWAN network, up when emitted by the device, 1772 down when received by the device, bi when emitted or 1773 received by the device."; 1774 } 1776 typedef mo-type { 1777 type identityref { 1778 base mo-base-type; 1779 } 1780 description 1781 "Matching Operator (MO) to compare fields values with 1782 target values"; 1783 } 1785 typedef cda-type { 1786 type identityref { 1787 base cda-base-type; 1788 } 1789 description 1790 "Compression Decompression Action to compression or 1791 decompress a field."; 1792 } 1794 // -- FRAGMENTATION TYPE 1795 // -- fragmentation modes 1797 identity fragmentation-mode-base-type { 1798 description 1799 "fragmentation mode."; 1800 } 1802 identity fragmentation-mode-no-ack { 1803 base fragmentation-mode-base-type; 1804 description 1805 "No Ack of RFC 8724."; 1806 } 1808 identity fragmentation-mode-ack-always { 1809 base fragmentation-mode-base-type; 1810 description 1811 "Ack Always of RFC8724."; 1812 } 1814 identity fragmentation-mode-ack-on-error { 1815 base fragmentation-mode-base-type; 1816 description 1817 "Ack on Error of RFC8724."; 1818 } 1820 typedef fragmentation-mode-type { 1821 type identityref { 1822 base fragmentation-mode-base-type; 1823 } 1824 description 1825 "type used in rules"; 1826 } 1828 // -- Ack behavior 1830 identity ack-behavior-base-type { 1831 description 1832 "Define when to send an Acknowledgment ."; 1833 } 1835 identity ack-behavior-after-All0 { 1836 base ack-behavior-base-type; 1837 description 1838 "Fragmentation expects Ack after sending All0 fragment."; 1839 } 1841 identity ack-behavior-after-All1 { 1842 base ack-behavior-base-type; 1843 description 1844 "Fragmentation expects Ack after sending All1 fragment."; 1845 } 1847 identity ack-behavior-always { 1848 base ack-behavior-base-type; 1849 description 1850 "Fragmentation expects Ack after sending every fragment."; 1851 } 1852 typedef ack-behavior-type { 1853 type identityref { 1854 base ack-behavior-base-type; 1855 } 1856 description 1857 "Type used in rules."; 1858 } 1860 // -- All1 with data types 1862 identity all1-data-base-type { 1863 description 1864 "Type to define when to send an Acknowledgment message."; 1865 } 1867 identity all1-data-no { 1868 base all1-data-base-type; 1869 description 1870 "All1 contains no tiles."; 1871 } 1873 identity all1-data-yes { 1874 base all1-data-base-type; 1875 description 1876 "All1 MUST contain a tile."; 1877 } 1879 identity all1-data-sender-choice { 1880 base all1-data-base-type; 1881 description 1882 "Fragmentation process choose to send tiles or not in all1."; 1883 } 1885 typedef all1-data-type { 1886 type identityref { 1887 base all1-data-base-type; 1888 } 1889 description 1890 "Type used in rules."; 1891 } 1893 // -- RCS algorithm types 1895 identity rcs-algorithm-base-type { 1896 description 1897 "Identify which algorithm is used to compute RSC. 1898 The algorithm also defines the size if the RSC field."; 1899 } 1900 identity rcs-RFC8724 { 1901 base rcs-algorithm-base-type; 1902 description 1903 "CRC 32 defined as default RCS in RFC8724."; 1904 } 1906 typedef rcs-algorithm-type { 1907 type identityref { 1908 base rcs-algorithm-base-type; 1909 } 1910 description 1911 "type used in rules."; 1912 } 1914 // -------- RULE ENTRY DEFINITION ------------ 1916 grouping tv-struct { 1917 description 1918 "Define the target value element. Always a binary type, strings 1919 must be converted to binary. field-id allows the conversion 1920 to the appropriate type."; 1921 leaf value { 1922 type binary; 1923 description 1924 "Target Value"; 1925 } 1926 leaf position { 1927 type uint16; 1928 description 1929 "If only one element position is 0, otherwise position is the 1930 the position in the matching list."; 1931 } 1932 } 1934 grouping compression-rule-entry { 1935 description 1936 "These entries defines a compression entry (i.e. a line) 1937 as defined in RFC 8724 and fragmentation parameters. 1939 +-------+--+--+--+------------+-----------------+---------------+ 1940 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 1941 +-------+--+--+--+------------+-----------------+---------------+ 1943 An entry in a compression rule is composed of 7 elements: 1944 - Field ID: The header field to be compressed. The content is a 1945 YANG identifer. 1946 - Field Length : either a positive integer of a function defined 1947 as a YANF id. 1949 - Field Position: a positive (and possibly equal to 0) integer. 1950 - Direction Indicator: a YANG identifier giving the direction. 1951 - Target value: a value against which the header Field is 1952 compared. 1953 - Matching Operator: a YANG id giving the operation, paramters 1954 may be associated to that operator. 1955 - Comp./Decomp. Action: A YANG id giving the compression or 1956 decompression action, paramters may be associated to that 1957 action. 1958 "; 1959 leaf field-id { 1960 type schc:fid-type; 1961 mandatory true; 1962 description 1963 "Field ID, identify a field in the header with a YANG 1964 referenceid."; 1965 } 1966 leaf field-length { 1967 type schc:fl-type; 1968 mandatory true; 1969 description 1970 "Field Length in bit or through a function defined as a 1971 YANG referenceid."; 1972 } 1973 leaf field-position { 1974 type uint8; 1975 mandatory true; 1976 description 1977 "Field position in the header is a integer. If the field is not 1978 repeated in the header the value is 1, and incremented for each 1979 repetition of the field. Position 0 means that the position is 1980 not important and order may change when decompressed"; 1981 } 1982 leaf direction-indicator { 1983 type schc:di-type; 1984 mandatory true; 1985 description 1986 "Direction Indicator, a YANG referenceid to say if the packet 1987 is bidirectional, up or down"; 1988 } 1989 list target-value { 1990 key "position"; 1991 uses tv-struct; 1992 description 1993 "A list of value to compare with the header field value. 1994 If target value is a singleton, position must be 0. 1995 For matching-list, should be consecutive position 1996 values starting from 1."; 1998 } 1999 leaf matching-operator { 2000 type schc:mo-type; 2001 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 2002 error-message 2003 "mo-equal, mo-msb and mo-match-mapping need target-value"; 2004 description 2005 "target-value is not required for mo-ignore"; 2006 } 2007 must "not (derived-from-or-self(., 'mo-msb')) or 2008 ../matching-operator-value" { 2009 error-message "mo-msb requires length value"; 2010 } 2011 mandatory true; 2012 description 2013 "MO: Matching Operator"; 2014 } 2015 list matching-operator-value { 2016 key "position"; 2017 uses tv-struct; 2018 description 2019 "Matching Operator Arguments, based on TV structure to allow 2020 several arguments. 2021 In RFC 8724, only MSB define a single argument: length in 2022 bits"; 2023 } 2024 leaf comp-decomp-action { 2025 type schc:cda-type; 2026 mandatory true; 2027 description 2028 "CDA: Compression Decompression Action."; 2029 } 2030 list comp-decomp-action-value { 2031 key "position"; 2032 uses tv-struct; 2033 description 2034 "CDA Arguments, based on TV structure to allow several 2035 arguments. In RFC 8724, no argument is defined for CDA."; 2036 } 2037 } 2039 grouping compression-content { 2040 list entry { 2041 key "field-id field-position direction-indicator"; 2042 uses compression-rule-entry; 2043 description 2044 "A compression rule is a list of rule entry describing 2045 each header field. An entry is identifed through a field-id, 2046 its position in the packet and its direction."; 2047 } 2048 description 2049 "Define a compression rule composed of a list of entries."; 2050 } 2052 grouping fragmentation-content { 2053 description 2054 "This grouping defines the fragmentation parameters for 2055 all the modes (No Ack, Ack Always and Ack on Error) specified in 2056 RFC 8724."; 2057 leaf l2-word-size { 2058 type uint8; 2059 default "8"; 2060 description 2061 "Size in bit of the layer 2 word"; 2062 } 2063 leaf direction { 2064 type schc:di-type; 2065 must "derived-from-or-self(., 'di-up') or 2066 derived-from-or-self(., 'di-down')" { 2067 error-message 2068 "direction for fragmentation rules are up or down."; 2069 } 2070 mandatory true; 2071 description 2072 "Should be up or down, bi directionnal is forbiden."; 2073 } 2074 leaf dtag-size { 2075 type uint8; 2076 default "0"; 2077 description 2078 "Size in bit of the DTag field (T variable from RFC8724)."; 2079 } 2080 leaf w-size { 2081 when "not(derived-from(../fragmentation-mode, 2082 'fragmentation-mode-no-ack'))"; 2083 type uint8; 2084 description 2085 "Size in bit of the window field (M variable from RFC8724)."; 2086 } 2087 leaf fcn-size { 2088 type uint8; 2089 mandatory true; 2090 description 2091 "Size in bit of the FCN field (M variable from RFC8724)."; 2092 } 2093 leaf rcs-algorithm { 2094 type rcs-algorithm-type; 2095 default "schc:rcs-RFC8724"; 2096 description 2097 "Algoritm used for RCS"; 2098 } 2099 leaf maximum-window-size { 2100 type uint16; 2101 description 2102 "By default 2^wsize - 1"; 2103 } 2104 leaf retransmission-timer { 2105 type uint64 { 2106 range "1..max"; 2107 } 2108 description 2109 "Duration in seconds of the retransmission timer."; 2110 } 2111 leaf inactivity-timer { 2112 type uint64; 2113 description 2114 "Duration is seconds of the inactivity timer, 2115 0 indicates the timer is disabled."; 2116 } 2117 leaf max-ack-requests { 2118 type uint8 { 2119 range "1..max"; 2120 } 2121 description 2122 "The maximum number of retries for a specific SCHC ACK."; 2123 } 2124 leaf maximum-packet-size { 2125 type uint16; 2126 default "1280"; 2127 description 2128 "When decompression is done, packet size must not 2129 strictly exceed this limit in Bytes."; 2130 } 2131 leaf fragmentation-mode { 2132 type schc:fragmentation-mode-type; 2133 mandatory true; 2134 description 2135 "which fragmentation mode is used (noAck, AckAlways, 2136 AckonError)"; 2137 } 2138 choice mode { 2139 case no-ack; 2140 case ack-always; 2141 case ack-on-error { 2142 leaf tile-size { 2143 when "derived-from(../fragmentation-mode, 2144 'fragmentation-mode-ack-on-error')"; 2145 type uint8; 2146 description 2147 "Size in bit of tiles, if not specified or set to 0, 2148 tile fills the fragment."; 2149 } 2150 leaf tile-in-All1 { 2151 when "derived-from(../fragmentation-mode, 2152 'fragmentation-mode-ack-on-error')"; 2153 type schc:all1-data-type; 2154 description 2155 "When true, sender and receiver except a tile in 2156 All-1 frag."; 2157 } 2158 leaf ack-behavior { 2159 when "derived-from(../fragmentation-mode, 2160 'fragmentation-mode-ack-on-error')"; 2161 type schc:ack-behavior-type; 2162 description 2163 "Sender behavior to acknowledge, after All-0, All-1 or 2164 when the LPWAN allows it (Always)."; 2165 } 2166 } 2167 description 2168 "RFC 8724 defines 3 fragmentation modes."; 2169 } 2170 } 2172 // Define rule ID. Rule ID is composed of a RuleID value and a 2173 // Rule ID Length 2175 grouping rule-id-type { 2176 leaf rule-id-value { 2177 type uint32; 2178 description 2179 "Rule ID value, this value must be unique combined with 2180 the length."; 2181 } 2182 leaf rule-id-length { 2183 type uint8 { 2184 range "0..32"; 2185 } 2186 description 2187 "Rule ID length in bits, value 0 is for implicit rules."; 2188 } 2189 description 2190 "A rule ID is composed of a value and a length in bit."; 2191 } 2193 // SCHC table for a specific device. 2195 container schc { 2196 list rule { 2197 key "rule-id-value rule-id-length"; 2198 uses rule-id-type; 2199 choice nature { 2200 case fragmentation { 2201 //if-feature "fragmentation"; 2202 uses fragmentation-content; 2203 } 2204 case compression { 2205 uses compression-content; 2206 } 2207 case no-compression { 2208 description 2209 "RFC8724 allows a rule for uncompressed headers."; 2210 } 2211 description 2212 "A rule is either for compression, no compression or 2213 fragmentation."; 2214 } 2215 description 2216 "Set of rules compression, no compression or fragmentation 2217 rules identified by their rule-id."; 2218 } 2219 description 2220 "a SCHC set of rules is composed of a list of rule which are 2221 either compression or fragmentation."; 2222 } 2223 } 2224 2226 Figure 23 2228 8. Normative References 2230 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2231 Zuniga, "SCHC: Generic Framework for Static Context Header 2232 Compression and Fragmentation", RFC 8724, 2233 DOI 10.17487/RFC8724, April 2020, 2234 . 2236 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 2237 Context Header Compression (SCHC) for the Constrained 2238 Application Protocol (CoAP)", RFC 8824, 2239 DOI 10.17487/RFC8824, June 2021, 2240 . 2242 Authors' Addresses 2244 Ana Minaburo 2245 Acklio 2246 1137A avenue des Champs Blancs 2247 35510 Cesson-Sevigne Cedex 2248 France 2250 Email: ana@ackl.io 2252 Laurent Toutain 2253 Institut MINES TELECOM; IMT Atlantique 2254 2 rue de la Chataigneraie 2255 CS 17607 2256 35576 Cesson-Sevigne Cedex 2257 France 2259 Email: Laurent.Toutain@imt-atlantique.fr