idnits 2.17.00 (12 Aug 2021) /tmp/idnits22999/draft-ietf-lpwan-schc-yang-data-model-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 111 instances of too long lines in the document, the longest one being 48 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 146: '...odel, each field MUST be identified th...' RFC 2119 keyword, line 738: '...agmentation-mode MUST be set with a sp...' RFC 2119 keyword, line 860: '...escription "All1 MUST contain a tile";...' RFC 2119 keyword, line 1499: '...escription "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 913 has weird spacing: '...osition uin...' == Line 917 has weird spacing: '...osition uin...' == Line 921 has weird spacing: '...osition uin...' -- The document date (February 02, 2021) is 473 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7252' is defined on line 1773, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-barthel-lpwan-oam-schc-02 ** Downref: Normative reference to an Informational draft: draft-barthel-lpwan-oam-schc (ref. 'I-D.barthel-lpwan-oam-schc') == Outdated reference: draft-ietf-lpwan-coap-static-context-hc has been published as RFC 8824 Summary: 3 errors (**), 0 flaws (~~), 7 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: August 6, 2021 Institut MINES TELECOM; IMT Atlantique 6 February 02, 2021 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-04 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 August 6, 2021. 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 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Field Identifier . . . . . . . . . . . . . . . . . . . . 3 54 2.3. Field length . . . . . . . . . . . . . . . . . . . . . . 5 55 2.4. Field position . . . . . . . . . . . . . . . . . . . . . 6 56 2.5. Direction Indicator . . . . . . . . . . . . . . . . . . . 6 57 2.6. Target Value . . . . . . . . . . . . . . . . . . . . . . 7 58 2.7. Matching Operator . . . . . . . . . . . . . . . . . . . . 8 59 2.7.1. Matching Operator arguments . . . . . . . . . . . . . 9 60 2.8. Compression Decompression Actions . . . . . . . . . . . . 10 61 2.8.1. Compression Decompression Action arguments . . . . . 12 62 3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 12 63 3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 14 64 3.1.1. Compression context representation. . . . . . . . . . 14 65 3.1.2. Rule definition . . . . . . . . . . . . . . . . . . . 15 66 3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 16 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 68 5. Security considerations . . . . . . . . . . . . . . . . . . . 24 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 70 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 24 71 8. Normative References . . . . . . . . . . . . . . . . . . . . 41 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 74 1. Introduction 76 2. SCHC rules 78 SCHC is a compression and fragmentation mechanism for constrained 79 networks defined in [RFC8724]. It is based on a static context 80 shared by two entities at the boundary this constrained network. 81 Draft [RFC8724] provides an non formal representation of the rules 82 used either for compression/decompression (or C/D) or fragmentation/ 83 reassembly (or F/R). The goal of this document is to formalize the 84 description of the rules to offer: 86 o the same definition on both ends, even if the internal 87 representation is different. 89 o an update the other end to set up some specific values (e.g. IPv6 90 prefix, Destination address,...) 92 o ... 94 This document defines a YANG module to represent both compression and 95 fragmentation rules, which leads to common representation for values 96 for all the rules elements. 98 SCHC compression is generic, the main mechanism do no refers to a 99 specific protocol. Any header field is abstracted through an ID, a 100 position, a direction and a value that can be a numerical value or a 101 string. [RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc] 102 specifies fields for IPv6, UDP, CoAP and OSCORE. 103 [I-D.barthel-lpwan-oam-schc] decribes ICMPv6 header compression. 105 SCHC fragmentation requires a set of common parameters that are 106 included in a rule. These parameters are defined in [RFC8724]. 108 2.1. Compression Rules 110 [RFC8724] proposes an non formal representation of the compression 111 rule. A compression context for a device is composed of a set of 112 rules. Each rule contains information to describe a specific field 113 in the header to be compressed. 115 +-----------------------------------------------------------------+ 116 | Rule N | 117 +-----------------------------------------------------------------+| 118 | Rule i || 119 +-----------------------------------------------------------------+|| 120 | (FID) Rule 1 ||| 121 |+-------+--+--+--+------------+-----------------+---------------+||| 122 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 123 |+-------+--+--+--+------------+-----------------+---------------+||| 124 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 125 |+-------+--+--+--+------------+-----------------+---------------+||| 126 ||... |..|..|..| ... | ... | ... |||| 127 |+-------+--+--+--+------------+-----------------+---------------+||/ 128 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 129 |+-------+--+--+--+------------+-----------------+---------------+|/ 130 | | 131 \-----------------------------------------------------------------/ 133 Figure 1: Compression Decompression Context 135 2.2. Field Identifier 137 In the process of compression, the headers of the original packet are 138 first parsed to create a list of fields. This list of fields is 139 matched against the rules to find the appropriate one and apply 140 compression. The link between the list given by the parsed fields 141 and the rules is done through a field ID. [RFC8724] do not state how 142 the field ID value can be constructed. In examples, identification 143 is done through a string indexed by the protocol name (e.g. 144 IPv6.version, CoAP.version,...). 146 Using the YANG model, each field MUST be identified through a global 147 YANG identityref. A YANG field ID derives from the field-id-base- 148 type. Figure 2 gives some field ID definitions. Note that some 149 field IDs can be splitted is smaller pieces. This is the case for 150 "fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are 151 a subset of "fid-ipv6-trafficclass-ds". 153 identity field-id-base-type { 154 description "Field ID with SID"; 155 } 157 identity fid-ipv6-version { 158 base field-id-base-type; 159 description "IPv6 version field from RFC8200"; 160 } 162 identity fid-ipv6-trafficclass { 163 base field-id-base-type; 164 description "IPv6 Traffic Class field from RFC8200"; 165 } 167 identity fid-ipv6-trafficclass-ds { 168 base field-id-base-type; 169 description "IPv6 Traffic Class field from RFC8200, 170 DiffServ field from RFC3168"; 171 } 173 identity fid-ipv6-trafficclass-ecn { 174 base field-id-base-type; 175 description "IPv6 Traffic Class field from RFC8200, 176 ECN field from RFC3168"; 177 } 179 ... 181 Figure 2: Definition of identityref for field IDs 183 Figure 2 gives some examples of field ID identityref definitions. 184 The base identity is field-id-base-type, and field id are derived for 185 it. 187 The naming convention is "fid" followed by the protocol name and the 188 field name. 189 The yang model in annex (see Section 7) gives the full definition of 190 the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc], 191 and [I-D.barthel-lpwan-oam-schc]. 193 The type associated to this identity is field-id-type (cf. Figure 3) 195 typedef field-id-type { 196 description "Field ID generic type."; 197 type identityref { 198 base field-id-base-type; 199 } 200 } 202 Figure 3: Type definition for field IDs 204 2.3. Field length 206 Field length is either an integer giving the size of a field in bits 207 or a specific function. [RFC8724] defines the "var" function which 208 allows variable length fields in byte and 209 [I-D.ietf-lpwan-coap-static-context-hc] defines the "tkl" function 210 for managing the CoAP Token length field. 212 identity field-length-base-type { 213 description "used to extend field length functions"; 214 } 216 identity fl-variable { 217 base field-length-base-type; 218 description "residue length in Byte is sent"; 219 } 221 identity fl-token-length { 222 base field-length-base-type; 223 description "residue length in Byte is sent"; 224 } 226 Figure 4: Definition of identityref for field ILength 228 As for field ID, field length function can be defined as a 229 identityref as shown in Figure 4. 231 Therefore the type for field length is a union between an integer 232 giving in bits the size of the length and the identityref (cf. 233 Figure 5). 235 typedef field-length-type { 236 description "Field length either a positive integer giving the size in bits 237 or a function defined through an identityref."; 238 type union { 239 type int64; /* positive length in bits */ 240 type identityref { /* function */ 241 base field-length-base-type; 242 } 243 } 244 } 246 Figure 5: Type definition for field Length 248 The naming convention is fl followed by the function name as defined 249 in SCHC specifications. 251 2.4. Field position 253 Field position is a positive integer which gives the position of a 254 field, the default value is 1, but if the field is repeated several 255 times, the value is higher. value 0 indicates that the position is 256 not important and is not taken into account during the rule selection 257 process. 259 Field position is a positive integer. The type is an uint8. 261 2.5. Direction Indicator 263 The Direction Indicator (DI) is used to tell if a field appears in 264 both direction (Bi) or only uplink (Up) or Downlink (Dw). 266 identity direction-indicator-base-type { 267 description "used to extend field length functions"; 268 } 270 identity di-bidirectional { 271 base direction-indicator-base-type; 272 description "Direction Indication of bi directionality"; 273 } 275 identity di-up { 276 base direction-indicator-base-type; 277 description "Direction Indication of upstream"; 278 } 280 identity di-down { 281 base direction-indicator-base-type; 282 description "Direction Indication of downstream"; 283 } 285 Figure 6: Definition of identityref for direction indicators 287 Figure 6 gives the identityref for Direction Indicators. 289 The type is "direction-indicator-type" (cf. Figure 7). 291 typedef direction-indicator-type { 292 description "direction in LPWAN network, up when emitted by the device, 293 down when received by the device, bi when emitted or received by the device."; 294 type identityref { 295 base direction-indicator-base-type; 296 } 297 } 299 Figure 7: Type definition for direction indicators 301 2.6. Target Value 303 Target Value may be either a string or binary sequence. For match- 304 mapping, several of these values can be contained in a Target Value 305 field. In the data model, this is generalized by adding a position, 306 which orders the list of values. By default the position is set to 307 0. 309 The leaf "value" is not mandatory to represent a non existing value 310 in a TV. 312 grouping target-values-struct { 313 description "defines the target value element. Can be either an arbitrary 314 binary or ascii element. All target values are considered as a matching lists. 315 Position is used to order values, by default position 0 is used when containing 316 a single element."; 318 leaf value { 319 type union { 320 type binary; 321 type string; 322 } 323 } 324 leaf position { 325 description "If only one element position is 0, otherwise position is the 326 matching list."; 327 type uint16; 328 } 329 } 331 Figure 8: Definition of target value 333 Figure 8 gives the definition of a single element of a Target Value. 334 In the rule, this will be used as a list, with position as a key. 335 The highest position value is used to compute the size of the index 336 sent in residue. 338 2.7. Matching Operator 340 Matching Operator (MO) is a function applied between a field value 341 provided by the parsed header and the target value. [RFC8724] 342 defines 4 MO. 344 identity matching-operator-base-type { 345 description "used to extend Matching Operators with SID values"; 346 } 348 identity mo-equal { 349 base matching-operator-base-type; 350 description "RFC 8724"; 351 } 353 identity mo-ignore { 354 base matching-operator-base-type; 355 description "RFC 8724"; 356 } 358 identity mo-msb { 359 base matching-operator-base-type; 360 description "RFC 8724"; 361 } 363 identity mo-matching { 364 base matching-operator-base-type; 365 description "RFC 8724"; 366 } 368 Figure 9: Definition of identityref for Matching Operator 370 the type is "matching-operator-type" (cf. Figure 10) 372 typedef matching-operator-type { 373 description "Matching Operator (MO) to compare fields values with target values"; 374 type identityref { 375 base matching-operator-base-type; 376 } 377 } 379 Figure 10: Type definition for Matching Operator 381 2.7.1. Matching Operator arguments 383 Some Matching Operator such as MSB can take some values. Even if 384 currently LSB is the only MO takes only one argument, in the future 385 some MO may require several arguments. They are viewed as a list of 386 target-values-type. 388 2.8. Compression Decompression Actions 390 Compression Decompression Action (CDA) identified the function to use 391 either for compression or decompression. [RFC8724] defines 6 CDA. 393 identity compression-decompression-action-base-type; 395 identity cda-not-sent { 396 base compression-decompression-action-base-type; 397 description "RFC 8724"; 398 } 400 identity cda-value-sent { 401 base compression-decompression-action-base-type; 402 description "RFC 8724"; 403 } 405 identity cda-lsb { 406 base compression-decompression-action-base-type; 407 description "RFC 8724"; 408 } 410 identity cda-mapping-sent { 411 base compression-decompression-action-base-type; 412 description "RFC 8724"; 413 } 415 identity cda-compute-length { 416 base compression-decompression-action-base-type; 417 description "RFC 8724"; 418 } 420 identity cda-compute-checksum { 421 base compression-decompression-action-base-type; 422 description "RFC 8724"; 423 } 425 identity cda-deviid { 426 base compression-decompression-action-base-type; 427 description "RFC 8724"; 428 } 430 identity cda-appiid { 431 base compression-decompression-action-base-type; 432 description "RFC 8724"; 433 } 435 Figure 11: Definition of identityref for Compresion Decompression 436 Action 438 The type is "comp-decomp-action-type" (cf. Figure 12) 439 typedef comp-decomp-action-type { 440 description "Compression Decompression Action to compression or decompress a field."; 441 type identityref { 442 base compression-decompression-action-base-type; 443 } 444 } 446 Figure 12: Type definition for Compresion Decompression Action 448 2.8.1. Compression Decompression Action arguments 450 Currently no CDA requires arguments, but the future some CDA may 451 require several arguments. They are viewed as a list of target- 452 values-type. 454 3. Rule definition 456 A rule is either a C/D or an F/R rule. A rule is identified by the 457 rule ID value and its associated length. The YANG grouping rule-id- 458 type defines the structure used to represent a rule ID. Length of 0 459 is allowed to represent an implicit rule. 461 // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length 463 grouping rule-id-type { 464 leaf rule-id { 465 type uint32; 466 description "rule ID value, this value must be unique combined with the length"; 467 } 468 leaf rule-length { 469 type uint8 { 470 range 0..32; 471 } 472 description "rule ID length in bits, value 0 is for implicit rules"; 473 } 474 } 476 // SCHC table for a specific device. 478 container schc { 479 leaf version{ 480 type uint64; 481 mandatory false; 482 description "used as an indication for versioning"; 483 } 484 list rule { 485 key "rule-id rule-length"; 486 uses rule-id-type; 487 choice nature { 488 case fragmentation { 489 uses fragmentation-content; 490 } 491 case compression { 492 uses compression-content; 493 } 494 } 495 } 496 } 498 Figure 13: Definition of a SCHC Context 500 To access to a specific rule, rule-id and its specific length is used 501 as a key. The rule is either a compression or a fragmentation rule. 503 Each context can be identified though a version id. 505 3.1. Compression rule 507 A compression rule is composed of entries describing its processing 508 (cf. Figure 14). An entry contains all the information defined in 509 Figure 1 with the types defined above. 511 3.1.1. Compression context representation. 513 The compression rule described Figure 1 is associated to a rule ID. 514 The compression rule entry is defined in Figure 14. Each column in 515 the table is either represented by a leaf or a list. Note that 516 Matching Operators and Compression Decompression actions can have 517 arguments. They are viewed a ordered list of strings and numbers as 518 in target values. 520 grouping compression-rule-entry { 521 description "These entries defines a compression entry (i.e. a line) 522 as defined in RFC 8724 and fragmentation parameters. 524 +-------+--+--+--+------------+-----------------+---------------+ 525 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 526 +-------+--+--+--+------------+-----------------+---------------+ 528 An entry in a compression rule is composed of 7 elements: 529 - Field ID: The header field to be compressed. The content is a YANG identifer. 530 - Field Length : either a positive integer of a function defined as a YANG id. 531 - Field Position: a positive (and possibly equal to 0) integer. 532 - Direction Indicator: a YANG identifier giving the direction. 533 - Target value: a value against which the header Field is compared. 534 - Matching Operator: a YANG id giving the operation, parameters may be 535 associated to that operator. 536 - Comp./Decomp. Action: A YANG id giving the compression or decompression 537 action, parameters may be associated to that action. 538 "; 540 leaf field-id { 541 description "Field ID, identify a field in the header with a YANG identityref."; 542 mandatory true; 543 type schc:field-id-type; 544 } 545 leaf field-length { 546 description "Field Length in bit or through a function defined as a YANG identityref"; 547 mandatory true; 548 type schc:field-length-type; 549 } 550 leaf field-position { 551 description "field position in the header is a integer. If the field is not repeated 552 in the header the value is 1, and incremented for each repetition of the field. Position 553 0 means that the position is not important and order may change when decompressed"; 554 mandatory true; 555 type uint8; 556 } 557 leaf direction-indicator { 558 description "Direction Indicator, a YANG identityref to say if the packet is bidirectionnal, 559 up or down"; 560 mandatory true; 561 type schc:direction-indicator-type; 562 } 563 list target-values { 564 description "a list of value to compare with the header field value. If target value 565 is a singleton, position must be 0. For matching-list, should be consecutive position 566 values starting from 1."; 567 key position; 568 uses target-values-struct; 569 } 570 leaf matching-operator { 571 mandatory true; 572 type schc:matching-operator-type; 573 } 574 list matching-operator-value { 575 key position; 576 uses target-values-struct; 577 } 578 leaf comp-decomp-action { 579 mandatory true; 580 type schc:comp-decomp-action-type; 581 } 582 list comp-decomp-action-value { 583 key position; 584 uses target-values-struct; 585 } 586 } 588 Figure 14: Definition of a compression entry 590 3.1.2. Rule definition 592 A compression rule is a list of entries. 594 grouping compression-content { 595 description "define a compression rule composed of a list of entries."; 596 list entry { 597 key "field-id field-position direction-indicator"; 598 uses compression-rule-entry; 599 } 600 } 602 Figure 15: Definition of a compression rule 604 To identify a specific entry Field ID, position and direction are 605 needed. 607 3.2. Fragmentation rule 609 Parameters for fragmentation are defined in Annex D of [RFC8724]. 611 Figure 16 gives the first elements found in this structure. It 612 starts with a direction. Since fragmentation rules work for a 613 specific direction, they contain a mandatory direction. The type is 614 the same as the one used in compression entries, but the use of 615 bidirectionnal is forbidden. 617 The next elements describe size of SCHC fragmentation header fields. 618 Only the FCN size is mandatory and value must be higher or equal to 619 1. 621 grouping fragmentation-content { 622 description "This grouping defines the fragmentation parameters for 623 all the modes (No Ack, Ack Always and Ack on Error) specified in 624 RFC 8724."; 626 leaf direction { 627 type schc:direction-indicator-type; 628 description "should be up or down, bi directionnal is forbidden."; 629 mandatory true; 630 } 631 leaf dtagsize { 632 type uint8; 633 description "size in bit of the DTag field"; 635 } 636 leaf wsize { 637 type uint8; 638 description "size in bit of the window field"; 639 } 640 leaf fcnsize { 641 type uint8 { 642 range 1..max; 643 } 644 description "size in bit of the FCN field"; 645 mandatory true; 646 } 647 ... 649 Figure 16: Definition of a fragmentation parameters, SCHC header 651 RCS algorithm is defined (Figure 17), by default with the CRC 652 computation proposed in [RFC8724]. The algorithms are identified 653 through an identityref specified in the SCHC Data Model and with the 654 type RCS-algorithm-type (Figure 18). 656 ... 657 leaf RCS-algorithm { 658 type RCS-algorithm-type; 659 default schc:RFC8724-RCS; 660 description "Algoritm used for RCS"; 661 } 662 ... 664 Figure 17: Definition of a fragmentation parameters, RCS algorithm 665 identity RCS-algorithm-base-type { 666 description "identify which algorithm is used to compute RSC. 667 The algorithm defines also the size if the RSC field."; 668 } 670 identity RFC8724-RCS { 671 description "CRC 32 defined as default RCS in RFC8724."; 672 base RCS-algorithm-base-type; 673 } 675 typedef RCS-algorithm-type { 676 type identityref { 677 base RCS-algorithm-base-type; 678 } 679 } 681 Figure 18: Definition of identityref for RCS Algorithm 683 Figure 19 gives the parameters used by the state machine to handle 684 fragmentation: 686 o maximum-window-size contains the maximum FCN value that can be 687 used. 689 o retransmission-timer gives in seconds the duration before sending 690 an ack request (cf. section 8.2.2.4. of [RFC8724]). If specifed, 691 value must be higher or equal to 1. 693 o inactivity-timer gives in seconds the duration before aborting 694 (cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly 695 indicates that this timer is disabled. 697 o max-ack-requests gives the number of attempts before aborting (cf. 698 section 8.2.2.4. of [RFC8724]). 700 o maximum-packet-size gives in bytes the larger packet size that can 701 be reassembled. 703 ... 704 leaf maximum-window-size { 705 type uint16; 706 description "by default 2^wsize - 2"; 707 } 709 leaf retransmission-timer { 710 type uint64 { 711 range 1..max; 712 } 713 description "duration in seconds of the retransmission timer"; // Check the units 714 } 716 leaf inactivity-timer { 717 type uint64; 718 description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units 719 } 721 leaf max-ack-requests { 722 type uint8 { 723 range 1..max; 724 } 725 description "the maximum number of retries for a specific SCHC ACK."; 726 } 728 leaf maximum-packet-size { 729 type uint16; 730 default 1280; 731 description "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 732 } 733 ... 735 Figure 19: Definition of a fragmentation state machine parameters 737 Figure 20 gives information related to a specific compression mode: 738 fragmentation-mode MUST be set with a specific behavior. Identityref 739 are given Figure 21. 741 For Ack on Error some specific information may be provided: 743 o tile-size gives in bits the size of the tile; If set to 0 a single 744 tile is inserted inside a fragment. 746 o tile-in-All1 indicates if All1 contains only the RCS (all1-data- 747 no) or may contain a single tile (all1-data-yes). Since the 748 reassembly process may detect this behavior, the choice can be 749 left to the fragmentation process. In that case identityref all1- 750 data-sender-choice as to be specified. All possible values are 751 given Figure 21. 753 o ack-behavior tells when the fragmentation process may send 754 acknowledgments. When ack-behavior-after-All0 is specified, the 755 ack may be sent after the reception of All-0 fragment. When ack- 756 behavior-after-All1 is specified, the ack may be sent after the 757 reception of All-1 fragment at the end of the fragmentation 758 process. ack-behavior-always do not impose a limitation at the 759 SCHC level. The constraint may come from the LPWAN technology. 760 All possible values are given Figure 21. 762 ... 763 leaf fragmentation-mode { 764 type schc:fragmentation-mode-type; 765 description "which fragmentation mode is used (noAck, AckAlways, AckonError)"; 766 mandatory true; 767 } 769 choice mode { 770 case no-ack; 771 case ack-always; 772 case ack-on-error { 773 leaf tile-size { 774 type uint8; 775 description "size in bit of tiles, if not specified or set to 0: tile fills the fragment."; 776 } 777 leaf tile-in-All1 { 778 type schc:all1-data-type; 779 description "When true, sender and receiver except a tile in All-1 frag"; 780 } 781 leaf ack-behavior { 782 type schc:ack-behavior-type; 783 description "Sender behavior to acknowledge, after All-0, All-1 or when the 784 LPWAN allows it (Always)"; 785 } 786 } 787 } 788 ... 790 Figure 20: Definition of a fragmentation specific information 792 // -- FRAGMENTATION TYPE 794 // -- fragmentation modes 796 identity fragmentation-mode-base-type { 797 description "fragmentation mode"; 799 } 801 identity fragmentation-mode-no-ack { 802 description "No Ack of RFC 8724."; 803 base fragmentation-mode-base-type; 804 } 806 identity fragmentation-mode-ack-always { 807 description "Ack Always of RFC8724."; 808 base fragmentation-mode-base-type; 809 } 810 identity fragmentation-mode-ack-on-error { 811 description "Ack on Error of RFC8724."; 812 base fragmentation-mode-base-type; 813 } 815 typedef fragmentation-mode-type { 816 type identityref { 817 base fragmentation-mode-base-type; 818 } 819 } 821 // -- Ack behavior 823 identity ack-behavior-base-type { 824 description "define when to send an Acknowledgment message"; 825 } 827 identity ack-behavior-after-All0 { 828 description "fragmentation expects Ack after sending All0 fragment."; 829 base ack-behavior-base-type; 830 } 832 identity ack-behavior-after-All1 { 833 description "fragmentation expects Ack after sending All1 fragment."; 834 base ack-behavior-base-type; 835 } 837 identity ack-behavior-always { 838 description "fragmentation expects Ack after sending every fragment."; 839 base ack-behavior-base-type; 840 } 842 typedef ack-behavior-type { 843 type identityref { 844 base ack-behavior-base-type; 845 } 846 } 848 // -- All1 with data types 850 identity all1-data-base-type { 851 description "type to define when to send an Acknowledgment message"; 852 } 854 identity all1-data-no { 855 description "All1 contains no tiles."; 856 base all1-data-base-type; 857 } 859 identity all1-data-yes { 860 description "All1 MUST contain a tile"; 861 base all1-data-base-type; 862 } 864 identity all1-data-sender-choice { 865 description "Fragmentation process choose to send tiles or not in all1."; 866 base all1-data-base-type; 867 } 869 typedef all1-data-type { 870 type identityref { 871 base all1-data-base-type; 872 } 873 } 875 Figure 21: Specific types for Ack On Error mode 877 ## YANG Tree 879 module: schc 880 +--rw schc 881 +--rw version? uint64 882 +--rw rule* [rule-id rule-length] 883 +--rw rule-id uint32 884 +--rw rule-length uint8 885 +--rw (nature)? 886 +--:(fragmentation) 887 | +--rw direction schc:direction-indicator-type 888 | +--rw dtagsize? uint8 889 | +--rw wsize? uint8 890 | +--rw fcnsize uint8 891 | +--rw RCS-algorithm? RCS-algorithm-type 892 | +--rw maximum-window-size? uint16 893 | +--rw retransmission-timer? uint64 894 | +--rw inactivity-timer? uint64 895 | +--rw max-ack-requests? uint8 896 | +--rw maximum-packet-size? uint16 897 | +--rw fragmentation-mode schc:fragmentation-mode-type 898 | +--rw (mode)? 899 | +--:(no-ack) 900 | +--:(ack-always) 901 | +--:(ack-on-error) 902 | +--rw tile-size? uint8 903 | +--rw tile-in-All1? schc:all1-data-type 904 | +--rw ack-behavior? schc:ack-behavior-type 905 +--:(compression) 906 +--rw entry* [field-id field-position direction-indicator] 907 +--rw field-id schc:field-id-type 908 +--rw field-length schc:field-length-type 909 +--rw field-position uint8 910 +--rw direction-indicator schc:direction-indicator-type 911 +--rw target-values* [position] 912 | +--rw value? union 913 | +--rw position uint16 914 +--rw matching-operator schc:matching-operator-type 915 +--rw matching-operator-value* [position] 916 | +--rw value? union 917 | +--rw position uint16 918 +--rw comp-decomp-action schc:comp-decomp-action-type 919 +--rw comp-decomp-action-value* [position] 920 +--rw value? union 921 +--rw position uint16 923 Figure 22 925 4. IANA Considerations 927 This document has no request to IANA. 929 5. Security considerations 931 This document does not have any more Security consideration than the 932 ones already raised on [RFC8724] 934 6. Acknowledgements 936 The authors would like to thank Dominique Barthel, Carsten Bormann, 937 Alexander Pelov. 939 7. YANG Module 941 file schc@2020-02-28.yang 942 module schc{ 943 yang-version "1"; 944 namespace "urn:ietf:lpwan:schc:rules-description"; 945 prefix "schc"; 947 description 948 "Generic Data model for Static Context Header Compression Rule for SCHC, 949 based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression 950 rules and fragmentation rules. 952 This module is a YANG model for SCHC rules (RFc 8724). 953 RFC 8724 describes a rule in a abstract way through a table. 955 |-----------------------------------------------------------------| 956 | (FID) Rule 1 | 957 |+-------+--+--+--+------------+-----------------+---------------+| 958 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 959 |+-------+--+--+--+------------+-----------------+---------------+| 960 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 961 |+-------+--+--+--+------------+-----------------+---------------+| 962 ||... |..|..|..| ... | ... | ... || 963 |+-------+--+--+--+------------+-----------------+---------------+| 964 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 965 +-------+--+--+--+------------+-----------------+---------------+|| 966 |-----------------------------------------------------------------| 968 This module proposes a global data model that can be used for rule 969 exchanges or modification. It proposes both the data model format and 970 the global identifiers used to describes some operations in fields. 971 This data model applies both to compression and fragmentation."; 972 revision 2020-06-15 { 973 description "clean up and add descriptions, merge schc-id to this file"; 974 } 976 revision 2020-02-28 { 977 description "Add Fragmentation parameters"; 978 } 980 revision 2020-01-23 { 981 description "Modified TV with binary and union"; 982 } 984 revision 2020-01-07 { 985 description "First version of the YANG model"; 986 } 988 // ------------------------- 989 // Field ID type definition 990 //-------------------------- 992 // generic value TV definition 994 identity field-id-base-type { 995 description "Field ID with SID"; 996 } 998 identity fid-ipv6-version { 999 base field-id-base-type; 1000 description "IPv6 version field from RFC8200"; 1001 } 1003 identity fid-ipv6-trafficclass { 1004 base field-id-base-type; 1005 description "IPv6 Traffic Class field from RFC8200"; 1006 } 1008 identity fid-ipv6-trafficclass-ds { 1009 base field-id-base-type; 1010 description "IPv6 Traffic Class field from RFC8200, 1011 DiffServ field from RFC3168"; 1012 } 1014 identity fid-ipv6-trafficclass-ecn { 1015 base field-id-base-type; 1016 description "IPv6 Traffic Class field from RFC8200, 1017 ECN field from RFC3168"; 1018 } 1019 identity fid-ipv6-flowlabel { 1020 base field-id-base-type; 1021 description "IPv6 Flow Label field from RFC8200"; 1022 } 1024 identity fid-ipv6-payloadlength { 1025 base field-id-base-type; 1026 description "IPv6 Payload Length field from RFC8200"; 1027 } 1029 identity fid-ipv6-nextheader { 1030 base field-id-base-type; 1031 description "IPv6 Next Header field from RFC8200"; 1032 } 1034 identity fid-ipv6-hoplimit { 1035 base field-id-base-type; 1036 description "IPv6 Next Header field from RFC8200"; 1037 } 1039 identity fid-ipv6-devprefix { 1040 base field-id-base-type; 1041 description "correspond either to the source address or the desdination 1042 address prefix of RFC 8200. Depending if it is respectively 1043 a uplink or an downklink message."; 1044 } 1046 identity fid-ipv6-deviid { 1047 base field-id-base-type; 1048 description "correspond either to the source address or the desdination 1049 address prefix of RFC 8200. Depending if it is respectively 1050 a uplink or an downklink message."; 1051 } 1053 identity fid-ipv6-appprefix { 1054 base field-id-base-type; 1055 description "correspond either to the source address or the desdination 1056 address prefix of RFC 768. Depending if it is respectively 1057 a downlink or an uplink message."; 1058 } 1060 identity fid-ipv6-appiid { 1061 base field-id-base-type; 1062 description "correspond either to the source address or the desdination 1063 address prefix of RFC 768. Depending if it is respectively 1064 a downlink or an uplink message."; 1065 } 1066 identity fid-udp-dev-port { 1067 base field-id-base-type; 1068 description "UDP length from RFC 768"; 1069 } 1071 identity fid-udp-app-port { 1072 base field-id-base-type; 1073 description "UDP length from RFC 768"; 1074 } 1076 identity fid-udp-length { 1077 base field-id-base-type; 1078 description "UDP length from RFC 768"; 1079 } 1081 identity fid-udp-checksum { 1082 base field-id-base-type; 1083 description "UDP length from RFC 768"; 1084 } 1086 identity fid-coap-version { 1087 base field-id-base-type; 1088 description "CoAP version from RFC 7252"; 1089 } 1091 identity fid-coap-type { 1092 base field-id-base-type; 1093 description "CoAP type from RFC 7252"; 1094 } 1096 identity fid-coap-tkl { 1097 base field-id-base-type; 1098 description "CoAP token length from RFC 7252"; 1099 } 1101 identity fid-coap-code { 1102 base field-id-base-type; 1103 description "CoAP code from RFC 7252"; 1104 } 1106 identity fid-coap-code-class { 1107 base field-id-base-type; 1108 description "CoAP code class from RFC 7252"; 1109 } 1111 identity fid-coap-code-detail { 1112 base field-id-base-type; 1113 description "CoAP code detail from RFC 7252"; 1115 } 1117 identity fid-coap-mid { 1118 base field-id-base-type; 1119 description "CoAP message ID from RFC 7252"; 1120 } 1122 identity fid-coap-token { 1123 base field-id-base-type; 1124 description "CoAP token from RFC 7252"; 1125 } 1127 identity fid-coap-option-if-match { 1128 base field-id-base-type; 1129 description "CoAP option If-Match from RFC 7252"; 1130 } 1132 identity fid-coap-option-uri-host { 1133 base field-id-base-type; 1134 description "CoAP option URI-Host from RFC 7252"; 1135 } 1137 identity fid-coap-option-etag { 1138 base field-id-base-type; 1139 description "CoAP option Etag from RFC 7252"; 1140 } 1142 identity fid-coap-option-if-none-match { 1143 base field-id-base-type; 1144 description "CoAP option if-none-match from RFC 7252"; 1145 } 1147 identity fid-coap-option-observe { 1148 base field-id-base-type; 1149 description "CoAP option Observe from RFC 7641"; 1150 } 1152 identity fid-coap-option-uri-port { 1153 base field-id-base-type; 1154 description "CoAP option Uri-Port from RFC 7252"; 1155 } 1157 identity fid-coap-option-location-path { 1158 base field-id-base-type; 1159 description "CoAP option Location-Path from RFC 7252"; 1160 } 1162 identity fid-coap-option-uri-path { 1163 base field-id-base-type; 1164 description "CoAP option Uri-Path from RFC 7252"; 1165 } 1167 identity fid-coap-option-content-format { 1168 base field-id-base-type; 1169 description "CoAP option Content Format from RFC 7252"; 1170 } 1172 identity fid-coap-option-max-age { 1173 base field-id-base-type; 1174 description "CoAP option Max-Age from RFC 7252"; 1175 } 1177 identity fid-coap-option-uri-query { 1178 base field-id-base-type; 1179 description "CoAP option Uri-Query from RFC 7252"; 1180 } 1182 identity fid-coap-option-accept { 1183 base field-id-base-type; 1184 description "CoAP option Max-Age from RFC 7252"; 1185 } 1187 identity fid-coap-option-location-query { 1188 base field-id-base-type; 1189 description "CoAP option Location-Query from RFC 7252"; 1190 } 1192 identity fid-coap-option-block2 { 1193 base field-id-base-type; 1194 description "CoAP option Block2 from RFC 7959"; 1195 } 1197 identity fid-coap-option-block1 { 1198 base field-id-base-type; 1199 description "CoAP option Block1 from RFC 7959"; 1200 } 1202 identity fid-coap-option-size2 { 1203 base field-id-base-type; 1204 description "CoAP option size2 from RFC 7959"; 1205 } 1207 identity fid-coap-option-proxy-uri { 1208 base field-id-base-type; 1209 description "CoAP option Proxy-Uri from RFC 7252"; 1210 } 1211 identity fid-coap-option-proxy-scheme { 1212 base field-id-base-type; 1213 description "CoAP option Proxy-scheme from RFC 7252"; 1214 } 1216 identity fid-coap-option-size1 { 1217 base field-id-base-type; 1218 description "CoAP option Size1 from RFC 7252"; 1219 } 1221 identity fid-coap-option-no-response { 1222 base field-id-base-type; 1223 description "CoAP option No response from RFC 7967"; 1224 } 1226 identity fid-coap-option-oscore-flags { 1227 base field-id-base-type; 1228 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1229 } 1231 identity fid-coap-option-oscore-piv { 1232 base field-id-base-type; 1233 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1234 } 1236 identity fid-coap-option-oscore-kid { 1237 base field-id-base-type; 1238 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1239 } 1241 identity fid-coap-option-oscore-kidctx { 1242 base field-id-base-type; 1243 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1244 } 1246 identity fid-icmpv6-type { 1247 base field-id-base-type; 1248 description "ICMPv6 field (see draft OAM)"; 1249 } 1251 identity fid-icmpv6-code { 1252 base field-id-base-type; 1253 description "ICMPv6 field (see draft OAM)"; 1254 } 1256 identity fid-icmpv6-checksum { 1257 base field-id-base-type; 1258 description "ICMPv6 field (see draft OAM)"; 1260 } 1262 identity fid-icmpv6-identifier { 1263 base field-id-base-type; 1264 description "ICMPv6 field (see draft OAM)"; 1265 } 1267 identity fid-icmpv6-sequence { 1268 base field-id-base-type; 1269 description "ICMPv6 field (see draft OAM)"; 1270 } 1272 /// !!!!!!! See future CoAP extentions 1274 //---------------------------------- 1275 // Field Length type definition 1276 //---------------------------------- 1278 identity field-length-base-type { 1279 description "used to extend field length functions"; 1280 } 1282 identity fl-variable { 1283 base field-length-base-type; 1284 description "residue length in Byte is sent"; 1285 } 1287 identity fl-token-length { 1288 base field-length-base-type; 1289 description "residue length in Byte is sent"; 1290 } 1292 //--------------------------------- 1293 // Direction Indicator type 1294 //--------------------------------- 1296 identity direction-indicator-base-type { 1297 description "used to extend field length functions"; 1298 } 1300 identity di-bidirectional { 1301 base direction-indicator-base-type; 1302 description "Direction Indication of bi directionality"; 1303 } 1305 identity di-up { 1306 base direction-indicator-base-type; 1307 description "Direction Indication of upstream"; 1308 } 1310 identity di-down { 1311 base direction-indicator-base-type; 1312 description "Direction Indication of downstream"; 1313 } 1315 //---------------------------------- 1316 // Matching Operator type definition 1317 //---------------------------------- 1319 identity matching-operator-base-type { 1320 description "used to extend Matching Operators with SID values"; 1321 } 1323 identity mo-equal { 1324 base matching-operator-base-type; 1325 description "RFC 8724"; 1326 } 1328 identity mo-ignore { 1329 base matching-operator-base-type; 1330 description "RFC 8724"; 1331 } 1333 identity mo-msb { 1334 base matching-operator-base-type; 1335 description "RFC 8724"; 1336 } 1338 identity mo-matching { 1339 base matching-operator-base-type; 1340 description "RFC 8724"; 1341 } 1343 //------------------------------ 1344 // CDA type definition 1345 //------------------------------ 1347 identity compression-decompression-action-base-type; 1349 identity cda-not-sent { 1350 base compression-decompression-action-base-type; 1351 description "RFC 8724"; 1352 } 1354 identity cda-value-sent { 1355 base compression-decompression-action-base-type; 1356 description "RFC 8724"; 1357 } 1359 identity cda-lsb { 1360 base compression-decompression-action-base-type; 1361 description "RFC 8724"; 1362 } 1364 identity cda-mapping-sent { 1365 base compression-decompression-action-base-type; 1366 description "RFC 8724"; 1367 } 1369 identity cda-compute-length { 1370 base compression-decompression-action-base-type; 1371 description "RFC 8724"; 1372 } 1374 identity cda-compute-checksum { 1375 base compression-decompression-action-base-type; 1376 description "RFC 8724"; 1377 } 1379 identity cda-deviid { 1380 base compression-decompression-action-base-type; 1381 description "RFC 8724"; 1382 } 1384 identity cda-appiid { 1385 base compression-decompression-action-base-type; 1386 description "RFC 8724"; 1387 } 1389 // -- type definition 1391 typedef field-id-type { 1392 description "Field ID generic type."; 1393 type identityref { 1394 base field-id-base-type; 1395 } 1396 } 1398 typedef field-length-type { 1399 description "Field length either a positive integer giving the size in bits 1400 or a function defined through an identityref."; 1401 type union { 1402 type int64; /* positive length in bits */ 1403 type identityref { /* function */ 1404 base field-length-base-type; 1405 } 1406 } 1407 } 1409 typedef direction-indicator-type { 1410 description "direction in LPWAN network, up when emitted by the device, 1411 down when received by the device, bi when emitted or received by the device."; 1412 type identityref { 1413 base direction-indicator-base-type; 1414 } 1415 } 1417 typedef matching-operator-type { 1418 description "Matching Operator (MO) to compare fields values with target values"; 1419 type identityref { 1420 base matching-operator-base-type; 1421 } 1422 } 1424 typedef comp-decomp-action-type { 1425 description "Compression Decompression Action to compression or decompress a field."; 1426 type identityref { 1427 base compression-decompression-action-base-type; 1428 } 1429 } 1431 // -- FRAGMENTATION TYPE 1433 // -- fragmentation modes 1435 identity fragmentation-mode-base-type { 1436 description "fragmentation mode"; 1437 } 1439 identity fragmentation-mode-no-ack { 1440 description "No Ack of RFC 8724."; 1441 base fragmentation-mode-base-type; 1442 } 1444 identity fragmentation-mode-ack-always { 1445 description "Ack Always of RFC8724."; 1446 base fragmentation-mode-base-type; 1447 } 1448 identity fragmentation-mode-ack-on-error { 1449 description "Ack on Error of RFC8724."; 1450 base fragmentation-mode-base-type; 1452 } 1454 typedef fragmentation-mode-type { 1455 type identityref { 1456 base fragmentation-mode-base-type; 1457 } 1458 } 1460 // -- Ack behavior 1462 identity ack-behavior-base-type { 1463 description "define when to send an Acknowledgment message"; 1464 } 1466 identity ack-behavior-after-All0 { 1467 description "fragmentation expects Ack after sending All0 fragment."; 1468 base ack-behavior-base-type; 1469 } 1471 identity ack-behavior-after-All1 { 1472 description "fragmentation expects Ack after sending All1 fragment."; 1473 base ack-behavior-base-type; 1474 } 1476 identity ack-behavior-always { 1477 description "fragmentation expects Ack after sending every fragment."; 1478 base ack-behavior-base-type; 1479 } 1481 typedef ack-behavior-type { 1482 type identityref { 1483 base ack-behavior-base-type; 1484 } 1485 } 1487 // -- All1 with data types 1489 identity all1-data-base-type { 1490 description "type to define when to send an Acknowledgment message"; 1491 } 1493 identity all1-data-no { 1494 description "All1 contains no tiles."; 1495 base all1-data-base-type; 1496 } 1498 identity all1-data-yes { 1499 description "All1 MUST contain a tile"; 1500 base all1-data-base-type; 1501 } 1503 identity all1-data-sender-choice { 1504 description "Fragmentation process choose to send tiles or not in all1."; 1505 base all1-data-base-type; 1506 } 1508 typedef all1-data-type { 1509 type identityref { 1510 base all1-data-base-type; 1511 } 1512 } 1514 // -- RCS algorithm types 1516 identity RCS-algorithm-base-type { 1517 description "identify which algorithm is used to compute RSC. 1518 The algorithm defines also the size if the RSC field."; 1519 } 1521 identity RFC8724-RCS { 1522 description "CRC 32 defined as default RCS in RFC8724."; 1523 base RCS-algorithm-base-type; 1524 } 1526 typedef RCS-algorithm-type { 1527 type identityref { 1528 base RCS-algorithm-base-type; 1529 } 1530 } 1532 // -------- RULE ENTRY DEFINITION ------------ 1534 grouping target-values-struct { 1535 description "defines the target value element. Can be either an arbitrary 1536 binary or ascii element. All target values are considered as a matching lists. 1537 Position is used to order values, by default position 0 is used when containing 1538 a single element."; 1540 leaf value { 1541 type union { 1542 type binary; 1543 type string; 1544 } 1545 } 1546 leaf position { 1547 description "If only one element position is 0, otherwise position is the 1548 matching list."; 1549 type uint16; 1550 } 1551 } 1553 grouping compression-rule-entry { 1554 description "These entries defines a compression entry (i.e. a line) 1555 as defined in RFC 8724 and fragmentation parameters. 1557 +-------+--+--+--+------------+-----------------+---------------+ 1558 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 1559 +-------+--+--+--+------------+-----------------+---------------+ 1561 An entry in a compression rule is composed of 7 elements: 1562 - Field ID: The header field to be compressed. The content is a YANG identifer. 1563 - Field Length : either a positive integer of a function defined as a YANF id. 1564 - Field Position: a positive (and possibly equal to 0) integer. 1565 - Direction Indicator: a YANG identifier giving the direction. 1566 - Target value: a value against which the header Field is compared. 1567 - Matching Operator: a YANG id giving the operation, paramters may be 1568 associated to that operator. 1569 - Comp./Decomp. Action: A YANG id giving the compression or decompression 1570 action, paramters may be associated to that action. 1571 "; 1573 leaf field-id { 1574 description "Field ID, identify a field in the header with a YANG refenceid."; 1575 mandatory true; 1576 type schc:field-id-type; 1577 } 1578 leaf field-length { 1579 description "Field Length in bit or through a function defined as a YANG referenceid"; 1580 mandatory true; 1581 type schc:field-length-type; 1582 } 1583 leaf field-position { 1584 description "field position in the header is a integer. If the field is not repeated 1585 in the header the value is 1, and incremented for each repetition of the field. Position 1586 0 means that the position is not important and order may change when decompressed"; 1587 mandatory true; 1588 type uint8; 1589 } 1590 leaf direction-indicator { 1591 description "Direction Indicator, a YANG referenceid to say if the packet is bidirectionnal, 1592 up or down"; 1593 mandatory true; 1594 type schc:direction-indicator-type; 1595 } 1596 list target-values { 1597 description "a list of value to compare with the header field value. If target value 1598 is a singleton, position must be 0. For matching-list, should be consecutive position 1599 values starting from 1."; 1600 key position; 1601 uses target-values-struct; 1602 } 1603 leaf matching-operator { 1604 mandatory true; 1605 type schc:matching-operator-type; 1606 } 1607 list matching-operator-value { 1608 key position; 1609 uses target-values-struct; 1610 } 1611 leaf comp-decomp-action { 1612 mandatory true; 1613 type schc:comp-decomp-action-type; 1614 } 1615 list comp-decomp-action-value { 1616 key position; 1617 uses target-values-struct; 1618 } 1619 } 1621 grouping compression-content { 1622 description "define a compression rule composed of a list of entries."; 1623 list entry { 1624 key "field-id field-position direction-indicator"; 1625 uses compression-rule-entry; 1626 } 1627 } 1629 grouping fragmentation-content { 1630 description "This grouping defines the fragmentation parameters for 1631 all the modes (No Ack, Ack Always and Ack on Error) specified in 1632 RFC 8724."; 1634 leaf direction { 1635 type schc:direction-indicator-type; 1636 description "should be up or down, bi directionnal is forbiden."; 1637 mandatory true; 1638 } 1639 leaf dtagsize { 1640 type uint8; 1641 description "size in bit of the DTag field"; 1643 } 1644 leaf wsize { 1645 type uint8; 1646 description "size in bit of the window field"; 1647 } 1648 leaf fcnsize { 1649 type uint8; 1650 description "size in bit of the FCN field"; 1651 mandatory true; 1652 } 1653 leaf RCS-algorithm { 1654 type RCS-algorithm-type; 1655 default schc:RFC8724-RCS; 1656 description "Algoritm used for RCS"; 1657 } 1658 leaf maximum-window-size { 1659 type uint16; 1660 description "by default 2^wsize - 1"; 1661 } 1663 leaf retransmission-timer { 1664 type uint64 { 1665 range 1..max; 1666 } 1667 description "duration in seconds of the retransmission timer"; // Check the units 1668 } 1670 leaf inactivity-timer { 1671 type uint64; 1672 description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units 1673 } 1675 leaf max-ack-requests { 1676 type uint8 { 1677 range 1..max; 1678 } 1679 description "the maximum number of retries for a specific SCHC ACK."; 1680 } 1682 leaf maximum-packet-size { 1683 type uint16; 1684 default 1280; 1685 description "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 1686 } 1688 leaf fragmentation-mode { 1689 type schc:fragmentation-mode-type; 1690 description "which fragmentation mode is used (noAck, AckAlways, AckonError)"; 1691 mandatory true; 1692 } 1694 choice mode { 1695 case no-ack; 1696 case ack-always; 1697 case ack-on-error { 1698 leaf tile-size { 1699 type uint8; 1700 description "size in bit of tiles, if not specified or set to 0: tile fills the fragment."; 1701 } 1702 leaf tile-in-All1 { 1703 type schc:all1-data-type; 1704 description "When true, sender and receiver except a tile in All-1 frag"; 1705 } 1706 leaf ack-behavior { 1707 type schc:ack-behavior-type; 1708 description "Sender behavior to acknowledge, after All-0, All-1 or when the 1709 LPWAN allows it (Always)"; 1710 } 1711 } 1712 } 1713 } 1715 // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length 1717 grouping rule-id-type { 1718 leaf rule-id { 1719 type uint32; 1720 description "rule ID value, this value must be unique combined with the length"; 1721 } 1722 leaf rule-length { 1723 type uint8 { 1724 range 0..32; 1725 } 1726 description "rule ID length in bits, value 0 is for implicit rules"; 1727 } 1728 } 1730 // SCHC table for a specific device. 1732 container schc { 1733 leaf version{ 1734 type uint64; 1735 mandatory false; 1736 description "used as an indication for versioning"; 1738 } 1739 list rule { 1740 key "rule-id rule-length"; 1741 uses rule-id-type; 1742 choice nature { 1743 case fragmentation { 1744 uses fragmentation-content; 1745 } 1746 case compression { 1747 uses compression-content; 1748 } 1749 } 1750 } 1751 } 1753 } 1755 1757 Figure 23 1759 8. Normative References 1761 [I-D.barthel-lpwan-oam-schc] 1762 Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and 1763 J. Zuniga, "OAM for LPWAN using Static Context Header 1764 Compression (SCHC)", draft-barthel-lpwan-oam-schc-02 (work 1765 in progress), November 2020. 1767 [I-D.ietf-lpwan-coap-static-context-hc] 1768 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 1769 Context Header Compression (SCHC) for CoAP", draft-ietf- 1770 lpwan-coap-static-context-hc-18 (work in progress), 1771 January 2021. 1773 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1774 Application Protocol (CoAP)", RFC 7252, 1775 DOI 10.17487/RFC7252, June 2014, 1776 . 1778 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1779 Zuniga, "SCHC: Generic Framework for Static Context Header 1780 Compression and Fragmentation", RFC 8724, 1781 DOI 10.17487/RFC8724, April 2020, 1782 . 1784 Authors' Addresses 1786 Ana Minaburo 1787 Acklio 1788 1137A avenue des Champs Blancs 1789 35510 Cesson-Sevigne Cedex 1790 France 1792 Email: ana@ackl.io 1794 Laurent Toutain 1795 Institut MINES TELECOM; IMT Atlantique 1796 2 rue de la Chataigneraie 1797 CS 17607 1798 35576 Cesson-Sevigne Cedex 1799 France 1801 Email: Laurent.Toutain@imt-atlantique.fr