idnits 2.17.1 draft-ietf-lpwan-schc-yang-data-model-03.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 145: '...odel, each field MUST be identified th...' RFC 2119 keyword, line 736: '...agmentation-mode MUST be set with a sp...' RFC 2119 keyword, line 858: '...escription "All1 MUST contain a tile";...' RFC 2119 keyword, line 1497: '...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 911 has weird spacing: '...osition uin...' == Line 915 has weird spacing: '...osition uin...' == Line 919 has weird spacing: '...osition uin...' -- The document date (July 10, 2020) is 1384 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 1771, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-barthel-lpwan-oam-schc-01 ** Downref: Normative reference to an Informational draft: draft-barthel-lpwan-oam-schc (ref. 'I-D.barthel-lpwan-oam-schc') == Outdated reference: A later version (-19) exists of draft-ietf-lpwan-coap-static-context-hc-15 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: January 11, 2021 Institut MINES TELECOM; IMT Atlantique 6 July 10, 2020 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-03 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 January 11, 2021. 33 Copyright Notice 35 Copyright (c) 2020 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 abstract representation of the rules used 82 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 fields. A field is abstracted through an ID, a position, a 100 direction and a value that can be a numerical value or a string. 101 [RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc] specifies 102 fields for IPv6, UDP, CoAP and OSCORE. 104 SCHC fragmentation requires a set of common parameters that are 105 included in a rule. These parameters are defined in [RFC8724]. 107 2.1. Compression Rules 109 [RFC8724] proposes an abstract representation of the compression 110 rule. A compression context for a device is composed of a set of 111 rules. Each rule contains information to describe a specific field 112 in the header to be compressed. 114 +-----------------------------------------------------------------+ 115 | Rule N | 116 +-----------------------------------------------------------------+| 117 | Rule i || 118 +-----------------------------------------------------------------+|| 119 | (FID) Rule 1 ||| 120 |+-------+--+--+--+------------+-----------------+---------------+||| 121 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 122 |+-------+--+--+--+------------+-----------------+---------------+||| 123 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 124 |+-------+--+--+--+------------+-----------------+---------------+||| 125 ||... |..|..|..| ... | ... | ... |||| 126 |+-------+--+--+--+------------+-----------------+---------------+||/ 127 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 128 |+-------+--+--+--+------------+-----------------+---------------+|/ 129 | | 130 \-----------------------------------------------------------------/ 132 Figure 1: Compression Decompression Context 134 2.2. Field Identifier 136 In the process of compression, the headers of the original packet are 137 first parsed to create a list of fields. This list of fields is 138 matched against the rules to find the appropriate one and apply 139 compression. The link between the list given by the parsed fields 140 and the rules is done through a field ID. [RFC8724] do not state how 141 the field ID value can be constructed. In the examples, it was given 142 through a string indexed by the protocol name (e.g. IPv6.version, 143 CoAP.version,...). 145 Using the YANG model, each field MUST be identified through a global 146 YANG identityref. A YANG field ID derives from the field-id-base- 147 type. Figure 2 gives some field ID definitions. Note that some 148 field IDs can be splitted is smaller pieces. This is the case for 149 "fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are 150 a subset of "fid-ipv6-trafficclass-ds". 152 identity field-id-base-type { 153 description "Field ID with SID"; 154 } 156 identity fid-ipv6-version { 157 base field-id-base-type; 158 description "IPv6 version field from RFC8200"; 159 } 161 identity fid-ipv6-trafficclass { 162 base field-id-base-type; 163 description "IPv6 Traffic Class field from RFC8200"; 164 } 166 identity fid-ipv6-trafficclass-ds { 167 base field-id-base-type; 168 description "IPv6 Traffic Class field from RFC8200, 169 DiffServ field from RFC3168"; 170 } 172 identity fid-ipv6-trafficclass-ecn { 173 base field-id-base-type; 174 description "IPv6 Traffic Class field from RFC8200, 175 ECN field from RFC3168"; 176 } 178 ... 180 Figure 2: Definition of identityref for field IDs 182 Figure 2 gives an example of field ID identityref definitions. The 183 base identity is field-id-base-type, and field id are derived for it. 184 The naming convention is "fid" followed by the protocol name and the 185 field name. 187 The yang model in annex (see Section 7) gives the full definition of 188 the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc], 189 and [I-D.barthel-lpwan-oam-schc]. 191 The type associated to this identity is field-id-type (cf. Figure 3) 193 typedef field-id-type { 194 description "Field ID generic type."; 195 type identityref { 196 base field-id-base-type; 197 } 198 } 200 Figure 3: Type definition for field IDs 202 2.3. Field length 204 Field length is either an integer giving the size of a field in bits 205 or a specific function. [RFC8724] defines the "var" function which 206 allows variable length fields in byte and 207 [I-D.ietf-lpwan-coap-static-context-hc] defines the "tkl" function 208 for managing the CoAP Token length field. 210 identity field-length-base-type { 211 description "used to extend field length functions"; 212 } 214 identity fl-variable { 215 base field-length-base-type; 216 description "residue length in Byte is sent"; 217 } 219 identity fl-token-length { 220 base field-length-base-type; 221 description "residue length in Byte is sent"; 222 } 224 Figure 4: Definition of identityref for field ILength 226 As for field ID, field length function can be defined as a 227 identityref as shown in Figure 4. 229 Therefore the type for field length is a union between an integer 230 giving in bits the size of the length and the identityref (cf. 231 Figure 5). 233 typedef field-length-type { 234 description "Field length either a positive integer giving the size in bits 235 or a function defined through an identityref."; 236 type union { 237 type int64; /* positive length in bits */ 238 type identityref { /* function */ 239 base field-length-base-type; 240 } 241 } 242 } 244 Figure 5: Type definition for field Length 246 The naming convention is fl followed by the function name as defined 247 in SCHC specifications. 249 2.4. Field position 251 Field position is a positive integer which gives the position of a 252 field, the default value is 1, but if the field is repeated several 253 times, the value is higher. value 0 indicates that the position is 254 not important and is not taken into account during the rule selection 255 process. 257 Field position is a positive integer. The type is an uint8. 259 2.5. Direction Indicator 261 The Direction Indicator (DI) is used to tell if a field appears in 262 both direction (Bi) or only uplink (Up) or Downlink (Dw). 264 identity direction-indicator-base-type { 265 description "used to extend field length functions"; 266 } 268 identity di-bidirectional { 269 base direction-indicator-base-type; 270 description "Direction Indication of bi directionality"; 271 } 273 identity di-up { 274 base direction-indicator-base-type; 275 description "Direction Indication of upstream"; 276 } 278 identity di-down { 279 base direction-indicator-base-type; 280 description "Direction Indication of downstream"; 281 } 283 Figure 6: Definition of identityref for direction indicators 285 Figure 6 gives the identityref for Direction Indicators. 287 The type is "direction-indicator-type" (cf. Figure 7). 289 typedef direction-indicator-type { 290 description "direction in LPWAN network, up when emitted by the device, 291 down when received by the device, bi when emitted or received by the device."; 292 type identityref { 293 base direction-indicator-base-type; 294 } 295 } 297 Figure 7: Type definition for direction indicators 299 2.6. Target Value 301 Target Value may be either a string or binary sequence. For match- 302 mapping, several of these values can be contained in a Target Value 303 field. In the data model, this is generalized by adding a position, 304 which orders the list of values. By default the position is set to 305 0. 307 The leaf "value" is not mandatory to represent a non existing value 308 in a TV. 310 grouping target-values-struct { 311 description "defines the target value element. Can be either an arbitrary 312 binary or ascii element. All target values are considered as a matching lists. 313 Position is used to order values, by default position 0 is used when containing 314 a single element."; 316 leaf value { 317 type union { 318 type binary; 319 type string; 320 } 321 } 322 leaf position { 323 description "If only one element position is 0, otherwise position is the 324 matching list."; 325 type uint16; 326 } 327 } 329 Figure 8: Definition of target value 331 Figure 8 gives the definition of a single element of a Target Value. 332 In the rule, this will be used as a list, with position as a key. 333 The highest position value is used to compute the size of the index 334 sent in residue. 336 2.7. Matching Operator 338 Matching Operator (MO) is a function applied between a field value 339 provided by the parsed header and the target value. [RFC8724] 340 defines 4 MO. 342 identity matching-operator-base-type { 343 description "used to extend Matching Operators with SID values"; 344 } 346 identity mo-equal { 347 base matching-operator-base-type; 348 description "RFC 8724"; 349 } 351 identity mo-ignore { 352 base matching-operator-base-type; 353 description "RFC 8724"; 354 } 356 identity mo-msb { 357 base matching-operator-base-type; 358 description "RFC 8724"; 359 } 361 identity mo-matching { 362 base matching-operator-base-type; 363 description "RFC 8724"; 364 } 366 Figure 9: Definition of identityref for Matching Operator 368 the type is "matching-operator-type" (cf. Figure 10) 370 typedef matching-operator-type { 371 description "Matching Operator (MO) to compare fields values with target values"; 372 type identityref { 373 base matching-operator-base-type; 374 } 375 } 377 Figure 10: Type definition for Matching Operator 379 2.7.1. Matching Operator arguments 381 Some Matching Operator such as MSB can take some values. Even if 382 currently LSB is the only MO takes only one argument, in the future 383 some MO may require several arguments. They are viewed as a list of 384 target-values-type. 386 2.8. Compression Decompression Actions 388 Compression Decompression Action (CDA) identified the function to use 389 either for compression or decompression. [RFC8724] defines 6 CDA. 391 identity compression-decompression-action-base-type; 393 identity cda-not-sent { 394 base compression-decompression-action-base-type; 395 description "RFC 8724"; 396 } 398 identity cda-value-sent { 399 base compression-decompression-action-base-type; 400 description "RFC 8724"; 401 } 403 identity cda-lsb { 404 base compression-decompression-action-base-type; 405 description "RFC 8724"; 406 } 408 identity cda-mapping-sent { 409 base compression-decompression-action-base-type; 410 description "RFC 8724"; 411 } 413 identity cda-compute-length { 414 base compression-decompression-action-base-type; 415 description "RFC 8724"; 416 } 418 identity cda-compute-checksum { 419 base compression-decompression-action-base-type; 420 description "RFC 8724"; 421 } 423 identity cda-deviid { 424 base compression-decompression-action-base-type; 425 description "RFC 8724"; 426 } 428 identity cda-appiid { 429 base compression-decompression-action-base-type; 430 description "RFC 8724"; 431 } 433 Figure 11: Definition of identityref for Compresion Decompression 434 Action 436 The type is "comp-decomp-action-type" (cf. Figure 12) 437 typedef comp-decomp-action-type { 438 description "Compression Decompression Action to compression or decompress a field."; 439 type identityref { 440 base compression-decompression-action-base-type; 441 } 442 } 444 Figure 12: Type definition for Compresion Decompression Action 446 2.8.1. Compression Decompression Action arguments 448 Currently no CDA requires arguments, but the future some CDA may 449 require several arguments. They are viewed as a list of target- 450 values-type. 452 3. Rule definition 454 A rule is either a C/D or an F/R rule. A rule is identified by the 455 rule ID value and its associated length. The YANG grouping rule-id- 456 type defines the structure used to represent a rule ID. Length of 0 457 is allowed to represent an implicit rule. 459 // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length 461 grouping rule-id-type { 462 leaf rule-id { 463 type uint32; 464 description "rule ID value, this value must be unique combined with the length"; 465 } 466 leaf rule-length { 467 type uint8 { 468 range 0..32; 469 } 470 description "rule ID length in bits, value 0 is for implicit rules"; 471 } 472 } 474 // SCHC table for a specific device. 476 container schc { 477 leaf version{ 478 type uint64; 479 mandatory false; 480 description "used as an indication for versioning"; 481 } 482 list rule { 483 key "rule-id rule-length"; 484 uses rule-id-type; 485 choice nature { 486 case fragmentation { 487 uses fragmentation-content; 488 } 489 case compression { 490 uses compression-content; 491 } 492 } 493 } 494 } 496 Figure 13: Definition of a SCHC Context 498 To access to a specific rule, rule-id and its specific length is used 499 as a key. The rule is either a compression or a fragmentation rule. 501 Each context can be identify though a version id. 503 3.1. Compression rule 505 A compression rule is composed of entries describing its processing 506 (cf. Figure 14). An entry contains all the information defined in 507 Figure 1 with the types defined above. 509 3.1.1. Compression context representation. 511 The compression rule described Figure 1 is associated to a rule ID. 512 The compression rule entry is defined in Figure 14. Each column in 513 the table is either represented by a leaf or a list. Note that 514 Matching Operators and Compression Decompression actions can have 515 arguments. They are viewed a ordered list of strings and numbers as 516 in target values. 518 grouping compression-rule-entry { 519 description "These entries defines a compression entry (i.e. a line) 520 as defined in RFC 8724 and fragmentation parameters. 522 +-------+--+--+--+------------+-----------------+---------------+ 523 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 524 +-------+--+--+--+------------+-----------------+---------------+ 526 An entry in a compression rule is composed of 7 elements: 527 - Field ID: The header field to be compressed. The content is a YANG identifer. 528 - Field Length : either a positive integer of a function defined as a YANG id. 529 - Field Position: a positive (and possibly equal to 0) integer. 530 - Direction Indicator: a YANG identifier giving the direction. 531 - Target value: a value against which the header Field is compared. 532 - Matching Operator: a YANG id giving the operation, parameters may be 533 associated to that operator. 534 - Comp./Decomp. Action: A YANG id giving the compression or decompression 535 action, parameters may be associated to that action. 536 "; 538 leaf field-id { 539 description "Field ID, identify a field in the header with a YANG identityref."; 540 mandatory true; 541 type schc:field-id-type; 542 } 543 leaf field-length { 544 description "Field Length in bit or through a function defined as a YANG identityref"; 545 mandatory true; 546 type schc:field-length-type; 547 } 548 leaf field-position { 549 description "field position in the header is a integer. If the field is not repeated 550 in the header the value is 1, and incremented for each repetition of the field. Position 551 0 means that the position is not important and order may change when decompressed"; 552 mandatory true; 553 type uint8; 554 } 555 leaf direction-indicator { 556 description "Direction Indicator, a YANG identityref to say if the packet is bidirectionnal, 557 up or down"; 558 mandatory true; 559 type schc:direction-indicator-type; 560 } 561 list target-values { 562 description "a list of value to compare with the header field value. If target value 563 is a singleton, position must be 0. For matching-list, should be consecutive position 564 values starting from 1."; 565 key position; 566 uses target-values-struct; 567 } 568 leaf matching-operator { 569 mandatory true; 570 type schc:matching-operator-type; 571 } 572 list matching-operator-value { 573 key position; 574 uses target-values-struct; 575 } 576 leaf comp-decomp-action { 577 mandatory true; 578 type schc:comp-decomp-action-type; 579 } 580 list comp-decomp-action-value { 581 key position; 582 uses target-values-struct; 583 } 584 } 586 Figure 14: Definition of a compression entry 588 3.1.2. Rule definition 590 A compression rule is a list of entries. 592 grouping compression-content { 593 description "define a compression rule composed of a list of entries."; 594 list entry { 595 key "field-id field-position direction-indicator"; 596 uses compression-rule-entry; 597 } 598 } 600 Figure 15: Definition of a compression rule 602 To identify a specific entry Field ID, position and direction are 603 needed. 605 3.2. Fragmentation rule 607 Parameters for fragmentation are defined in Annex D of [RFC8724]. 609 Figure 16 gives the first elements found in this structure. It 610 starts with a direction. Since fragmentation rules are 611 unidirectional, they contain a mandatory direction. The type is the 612 same as the one used in compression entries, but the use of 613 bidirectionnal is forbidden. 615 The next elements describe size of SCHC fragmentation header fields. 616 Only the FCN size is mandatory and value must be higher or equal to 617 1. 619 grouping fragmentation-content { 620 description "This grouping defines the fragmentation parameters for 621 all the modes (No Ack, Ack Always and Ack on Error) specified in 622 RFC 8724."; 624 leaf direction { 625 type schc:direction-indicator-type; 626 description "should be up or down, bi directionnal is forbidden."; 627 mandatory true; 628 } 629 leaf dtagsize { 630 type uint8; 631 description "size in bit of the DTag field"; 633 } 634 leaf wsize { 635 type uint8; 636 description "size in bit of the window field"; 637 } 638 leaf fcnsize { 639 type uint8 { 640 range 1..max; 641 } 642 description "size in bit of the FCN field"; 643 mandatory true; 644 } 645 ... 647 Figure 16: Definition of a fragmentation parameters, SCHC header 649 RCS algorithm is defined (Figure 17), by default with the CRC 650 computation proposed in [RFC8724]. The algorithms are identified 651 through an identityref specified in the SCHC Data Model and with the 652 type RCS-algorithm-type (Figure 18). 654 ... 655 leaf RCS-algorithm { 656 type RCS-algorithm-type; 657 default schc:RFC8724-RCS; 658 description "Algoritm used for RCS"; 659 } 660 ... 662 Figure 17: Definition of a fragmentation parameters, RCS algorithm 663 identity RCS-algorithm-base-type { 664 description "identify which algorithm is used to compute RSC. 665 The algorithm defines also the size if the RSC field."; 666 } 668 identity RFC8724-RCS { 669 description "CRC 32 defined as default RCS in RFC8724."; 670 base RCS-algorithm-base-type; 671 } 673 typedef RCS-algorithm-type { 674 type identityref { 675 base RCS-algorithm-base-type; 676 } 677 } 679 Figure 18: Definition of identityref for RCS Algorithm 681 Figure 19 gives the parameters used by the state machine to handle 682 fragmentation: 684 o maximum-window-size contains the maximum FCN value that can be 685 used. 687 o retransmission-timer gives in seconds the duration before sending 688 an ack request (cf. section 8.2.2.4. of [RFC8724]). If specifed, 689 value must be higher or equal to 1. 691 o inactivity-timer gives in seconds the duration before aborting 692 (cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly 693 indicates that this timer is disabled. 695 o max-ack-requests gives the number of attempts before aborting (cf. 696 section 8.2.2.4. of [RFC8724]). 698 o maximum-packet-size gives in bytes the larger packet size that can 699 be reassembled. 701 ... 702 leaf maximum-window-size { 703 type uint16; 704 description "by default 2^wsize - 2"; 705 } 707 leaf retransmission-timer { 708 type uint64 { 709 range 1..max; 710 } 711 description "duration in seconds of the retransmission timer"; // Check the units 712 } 714 leaf inactivity-timer { 715 type uint64; 716 description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units 717 } 719 leaf max-ack-requests { 720 type uint8 { 721 range 1..max; 722 } 723 description "the maximum number of retries for a specific SCHC ACK."; 724 } 726 leaf maximum-packet-size { 727 type uint16; 728 default 1280; 729 description "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 730 } 731 ... 733 Figure 19: Definition of a fragmentation state machine parameters 735 Figure 20 gives information related to a specific compression mode: 736 fragmentation-mode MUST be set with a specific behavior. Identityref 737 are given Figure 21. 739 For Ack on Error some specific information may be provided: 741 o tile-size gives in bits the size of the tile; If set to 0 a single 742 tile is inserted inside a fragment. 744 o tile-in All1 indicates if All1 contains only the RCS (all1-data- 745 no) or may contain a single tile (all1-data-yes). Since the 746 reassembly process may detect this behavior, the choice can be 747 left to the fragmentation process. In that case identityref all1- 748 data-sender-choice as to be specified. All possible values are 749 given Figure 21. 751 o ack-behavior tells when the fragmentation process may send 752 acknowledgments. When ack-behavior-after-All0 is specified, the 753 ack may be sent after the reception of All-0 fragment. When ack- 754 behavior-after-All1 is specified, the ack may be sent after the 755 reception of All-1 fragment at the end of the fragmentation 756 process. ack-behavior-always do not impose a limitation at the 757 SCHC level. The constraint may come from the LPWAN technology. 758 All possible values are given Figure 21. 760 ... 761 leaf fragmentation-mode { 762 type schc:fragmentation-mode-type; 763 description "which fragmentation mode is used (noAck, AckAlways, AckonError)"; 764 mandatory true; 765 } 767 choice mode { 768 case no-ack; 769 case ack-always; 770 case ack-on-error { 771 leaf tile-size { 772 type uint8; 773 description "size in bit of tiles, if not specified or set to 0: tile fills the fragment."; 774 } 775 leaf tile-in-All1 { 776 type schc:all1-data-type; 777 description "When true, sender and receiver except a tile in All-1 frag"; 778 } 779 leaf ack-behavior { 780 type schc:ack-behavior-type; 781 description "Sender behavior to acknowledge, after All-0, All-1 or when the 782 LPWAN allows it (Always)"; 783 } 784 } 785 } 786 ... 788 Figure 20: Definition of a fragmentation specific information 790 // -- FRAGMENTATION TYPE 792 // -- fragmentation modes 794 identity fragmentation-mode-base-type { 795 description "fragmentation mode"; 797 } 799 identity fragmentation-mode-no-ack { 800 description "No Ack of RFC 8724."; 801 base fragmentation-mode-base-type; 802 } 804 identity fragmentation-mode-ack-always { 805 description "Ack Always of RFC8724."; 806 base fragmentation-mode-base-type; 807 } 808 identity fragmentation-mode-ack-on-error { 809 description "Ack on Error of RFC8724."; 810 base fragmentation-mode-base-type; 811 } 813 typedef fragmentation-mode-type { 814 type identityref { 815 base fragmentation-mode-base-type; 816 } 817 } 819 // -- Ack behavior 821 identity ack-behavior-base-type { 822 description "define when to send an Acknowledgment message"; 823 } 825 identity ack-behavior-after-All0 { 826 description "fragmentation expects Ack after sending All0 fragment."; 827 base ack-behavior-base-type; 828 } 830 identity ack-behavior-after-All1 { 831 description "fragmentation expects Ack after sending All1 fragment."; 832 base ack-behavior-base-type; 833 } 835 identity ack-behavior-always { 836 description "fragmentation expects Ack after sending every fragment."; 837 base ack-behavior-base-type; 838 } 840 typedef ack-behavior-type { 841 type identityref { 842 base ack-behavior-base-type; 843 } 844 } 846 // -- All1 with data types 848 identity all1-data-base-type { 849 description "type to define when to send an Acknowledgment message"; 850 } 852 identity all1-data-no { 853 description "All1 contains no tiles."; 854 base all1-data-base-type; 855 } 857 identity all1-data-yes { 858 description "All1 MUST contain a tile"; 859 base all1-data-base-type; 860 } 862 identity all1-data-sender-choice { 863 description "Fragmentation process choose to send tiles or not in all1."; 864 base all1-data-base-type; 865 } 867 typedef all1-data-type { 868 type identityref { 869 base all1-data-base-type; 870 } 871 } 873 Figure 21: Specific types for Ack On Error mode 875 ## YANG Tree 877 module: schc 878 +--rw schc 879 +--rw version? uint64 880 +--rw rule* [rule-id rule-length] 881 +--rw rule-id uint32 882 +--rw rule-length uint8 883 +--rw (nature)? 884 +--:(fragmentation) 885 | +--rw direction schc:direction-indicator-type 886 | +--rw dtagsize? uint8 887 | +--rw wsize? uint8 888 | +--rw fcnsize uint8 889 | +--rw RCS-algorithm? RCS-algorithm-type 890 | +--rw maximum-window-size? uint16 891 | +--rw retransmission-timer? uint64 892 | +--rw inactivity-timer? uint64 893 | +--rw max-ack-requests? uint8 894 | +--rw maximum-packet-size? uint16 895 | +--rw fragmentation-mode schc:fragmentation-mode-type 896 | +--rw (mode)? 897 | +--:(no-ack) 898 | +--:(ack-always) 899 | +--:(ack-on-error) 900 | +--rw tile-size? uint8 901 | +--rw tile-in-All1? schc:all1-data-type 902 | +--rw ack-behavior? schc:ack-behavior-type 903 +--:(compression) 904 +--rw entry* [field-id field-position direction-indicator] 905 +--rw field-id schc:field-id-type 906 +--rw field-length schc:field-length-type 907 +--rw field-position uint8 908 +--rw direction-indicator schc:direction-indicator-type 909 +--rw target-values* [position] 910 | +--rw value? union 911 | +--rw position uint16 912 +--rw matching-operator schc:matching-operator-type 913 +--rw matching-operator-value* [position] 914 | +--rw value? union 915 | +--rw position uint16 916 +--rw comp-decomp-action schc:comp-decomp-action-type 917 +--rw comp-decomp-action-value* [position] 918 +--rw value? union 919 +--rw position uint16 921 Figure 22 923 4. IANA Considerations 925 This document has no request to IANA. 927 5. Security considerations 929 This document does not have any more Security consideration than the 930 ones already raised on [RFC8724] 932 6. Acknowledgements 934 The authors would like to thank Dominique Barthel, Carsten Bormann, 935 Alexander Pelov. 937 7. YANG Module 939 file schc@2020-02-28.yang 940 module schc{ 941 yang-version "1"; 942 namespace "urn:ietf:lpwan:schc:rules-description"; 943 prefix "schc"; 945 description 946 "Generic Data model for Static Context Header Compression Rule for SCHC, 947 based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression 948 rules and fragmentation rules. 950 This module is a YANG model for SCHC rules (RFc 8724). 951 RFC 8724 describes a rule in a abstract way through a table. 953 |-----------------------------------------------------------------| 954 | (FID) Rule 1 | 955 |+-------+--+--+--+------------+-----------------+---------------+| 956 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 957 |+-------+--+--+--+------------+-----------------+---------------+| 958 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 959 |+-------+--+--+--+------------+-----------------+---------------+| 960 ||... |..|..|..| ... | ... | ... || 961 |+-------+--+--+--+------------+-----------------+---------------+| 962 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 963 +-------+--+--+--+------------+-----------------+---------------+|| 964 |-----------------------------------------------------------------| 966 This module proposes a global data model that can be used for rule 967 exchanges or modification. It proposes both the data model format and 968 the global identifiers used to describes some operations in fields. 969 This data model applies both to compression and fragmentation."; 970 revision 2020-06-15 { 971 description "clean up and add descriptions, merge schc-id to this file"; 972 } 974 revision 2020-02-28 { 975 description "Add Fragmentation parameters"; 976 } 978 revision 2020-01-23 { 979 description "Modified TV with binary and union"; 980 } 982 revision 2020-01-07 { 983 description "First version of the YANG model"; 984 } 986 // ------------------------- 987 // Field ID type definition 988 //-------------------------- 990 // generic value TV definition 992 identity field-id-base-type { 993 description "Field ID with SID"; 994 } 996 identity fid-ipv6-version { 997 base field-id-base-type; 998 description "IPv6 version field from RFC8200"; 999 } 1001 identity fid-ipv6-trafficclass { 1002 base field-id-base-type; 1003 description "IPv6 Traffic Class field from RFC8200"; 1004 } 1006 identity fid-ipv6-trafficclass-ds { 1007 base field-id-base-type; 1008 description "IPv6 Traffic Class field from RFC8200, 1009 DiffServ field from RFC3168"; 1010 } 1012 identity fid-ipv6-trafficclass-ecn { 1013 base field-id-base-type; 1014 description "IPv6 Traffic Class field from RFC8200, 1015 ECN field from RFC3168"; 1016 } 1017 identity fid-ipv6-flowlabel { 1018 base field-id-base-type; 1019 description "IPv6 Flow Label field from RFC8200"; 1020 } 1022 identity fid-ipv6-payloadlength { 1023 base field-id-base-type; 1024 description "IPv6 Payload Length field from RFC8200"; 1025 } 1027 identity fid-ipv6-nextheader { 1028 base field-id-base-type; 1029 description "IPv6 Next Header field from RFC8200"; 1030 } 1032 identity fid-ipv6-hoplimit { 1033 base field-id-base-type; 1034 description "IPv6 Next Header field from RFC8200"; 1035 } 1037 identity fid-ipv6-devprefix { 1038 base field-id-base-type; 1039 description "correspond either to the source address or the desdination 1040 address prefix of RFC 8200. Depending if it is respectively 1041 a uplink or an downklink message."; 1042 } 1044 identity fid-ipv6-deviid { 1045 base field-id-base-type; 1046 description "correspond either to the source address or the desdination 1047 address prefix of RFC 8200. Depending if it is respectively 1048 a uplink or an downklink message."; 1049 } 1051 identity fid-ipv6-appprefix { 1052 base field-id-base-type; 1053 description "correspond either to the source address or the desdination 1054 address prefix of RFC 768. Depending if it is respectively 1055 a downlink or an uplink message."; 1056 } 1058 identity fid-ipv6-appiid { 1059 base field-id-base-type; 1060 description "correspond either to the source address or the desdination 1061 address prefix of RFC 768. Depending if it is respectively 1062 a downlink or an uplink message."; 1063 } 1064 identity fid-udp-dev-port { 1065 base field-id-base-type; 1066 description "UDP length from RFC 768"; 1067 } 1069 identity fid-udp-app-port { 1070 base field-id-base-type; 1071 description "UDP length from RFC 768"; 1072 } 1074 identity fid-udp-length { 1075 base field-id-base-type; 1076 description "UDP length from RFC 768"; 1077 } 1079 identity fid-udp-checksum { 1080 base field-id-base-type; 1081 description "UDP length from RFC 768"; 1082 } 1084 identity fid-coap-version { 1085 base field-id-base-type; 1086 description "CoAP version from RFC 7252"; 1087 } 1089 identity fid-coap-type { 1090 base field-id-base-type; 1091 description "CoAP type from RFC 7252"; 1092 } 1094 identity fid-coap-tkl { 1095 base field-id-base-type; 1096 description "CoAP token length from RFC 7252"; 1097 } 1099 identity fid-coap-code { 1100 base field-id-base-type; 1101 description "CoAP code from RFC 7252"; 1102 } 1104 identity fid-coap-code-class { 1105 base field-id-base-type; 1106 description "CoAP code class from RFC 7252"; 1107 } 1109 identity fid-coap-code-detail { 1110 base field-id-base-type; 1111 description "CoAP code detail from RFC 7252"; 1113 } 1115 identity fid-coap-mid { 1116 base field-id-base-type; 1117 description "CoAP message ID from RFC 7252"; 1118 } 1120 identity fid-coap-token { 1121 base field-id-base-type; 1122 description "CoAP token from RFC 7252"; 1123 } 1125 identity fid-coap-option-if-match { 1126 base field-id-base-type; 1127 description "CoAP option If-Match from RFC 7252"; 1128 } 1130 identity fid-coap-option-uri-host { 1131 base field-id-base-type; 1132 description "CoAP option URI-Host from RFC 7252"; 1133 } 1135 identity fid-coap-option-etag { 1136 base field-id-base-type; 1137 description "CoAP option Etag from RFC 7252"; 1138 } 1140 identity fid-coap-option-if-none-match { 1141 base field-id-base-type; 1142 description "CoAP option if-none-match from RFC 7252"; 1143 } 1145 identity fid-coap-option-observe { 1146 base field-id-base-type; 1147 description "CoAP option Observe from RFC 7641"; 1148 } 1150 identity fid-coap-option-uri-port { 1151 base field-id-base-type; 1152 description "CoAP option Uri-Port from RFC 7252"; 1153 } 1155 identity fid-coap-option-location-path { 1156 base field-id-base-type; 1157 description "CoAP option Location-Path from RFC 7252"; 1158 } 1160 identity fid-coap-option-uri-path { 1161 base field-id-base-type; 1162 description "CoAP option Uri-Path from RFC 7252"; 1163 } 1165 identity fid-coap-option-content-format { 1166 base field-id-base-type; 1167 description "CoAP option Content Format from RFC 7252"; 1168 } 1170 identity fid-coap-option-max-age { 1171 base field-id-base-type; 1172 description "CoAP option Max-Age from RFC 7252"; 1173 } 1175 identity fid-coap-option-uri-query { 1176 base field-id-base-type; 1177 description "CoAP option Uri-Query from RFC 7252"; 1178 } 1180 identity fid-coap-option-accept { 1181 base field-id-base-type; 1182 description "CoAP option Max-Age from RFC 7252"; 1183 } 1185 identity fid-coap-option-location-query { 1186 base field-id-base-type; 1187 description "CoAP option Location-Query from RFC 7252"; 1188 } 1190 identity fid-coap-option-block2 { 1191 base field-id-base-type; 1192 description "CoAP option Block2 from RFC 7959"; 1193 } 1195 identity fid-coap-option-block1 { 1196 base field-id-base-type; 1197 description "CoAP option Block1 from RFC 7959"; 1198 } 1200 identity fid-coap-option-size2 { 1201 base field-id-base-type; 1202 description "CoAP option size2 from RFC 7959"; 1203 } 1205 identity fid-coap-option-proxy-uri { 1206 base field-id-base-type; 1207 description "CoAP option Proxy-Uri from RFC 7252"; 1208 } 1209 identity fid-coap-option-proxy-scheme { 1210 base field-id-base-type; 1211 description "CoAP option Proxy-scheme from RFC 7252"; 1212 } 1214 identity fid-coap-option-size1 { 1215 base field-id-base-type; 1216 description "CoAP option Size1 from RFC 7252"; 1217 } 1219 identity fid-coap-option-no-response { 1220 base field-id-base-type; 1221 description "CoAP option No response from RFC 7967"; 1222 } 1224 identity fid-coap-option-oscore-flags { 1225 base field-id-base-type; 1226 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1227 } 1229 identity fid-coap-option-oscore-piv { 1230 base field-id-base-type; 1231 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1232 } 1234 identity fid-coap-option-oscore-kid { 1235 base field-id-base-type; 1236 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1237 } 1239 identity fid-coap-option-oscore-kidctx { 1240 base field-id-base-type; 1241 description "CoAP option oscore flags (see draft schc coap, section 6.4)"; 1242 } 1244 identity fid-icmpv6-type { 1245 base field-id-base-type; 1246 description "ICMPv6 field (see draft OAM)"; 1247 } 1249 identity fid-icmpv6-code { 1250 base field-id-base-type; 1251 description "ICMPv6 field (see draft OAM)"; 1252 } 1254 identity fid-icmpv6-checksum { 1255 base field-id-base-type; 1256 description "ICMPv6 field (see draft OAM)"; 1258 } 1260 identity fid-icmpv6-identifier { 1261 base field-id-base-type; 1262 description "ICMPv6 field (see draft OAM)"; 1263 } 1265 identity fid-icmpv6-sequence { 1266 base field-id-base-type; 1267 description "ICMPv6 field (see draft OAM)"; 1268 } 1270 /// !!!!!!! See future CoAP extentions 1272 //---------------------------------- 1273 // Field Length type definition 1274 //---------------------------------- 1276 identity field-length-base-type { 1277 description "used to extend field length functions"; 1278 } 1280 identity fl-variable { 1281 base field-length-base-type; 1282 description "residue length in Byte is sent"; 1283 } 1285 identity fl-token-length { 1286 base field-length-base-type; 1287 description "residue length in Byte is sent"; 1288 } 1290 //--------------------------------- 1291 // Direction Indicator type 1292 //--------------------------------- 1294 identity direction-indicator-base-type { 1295 description "used to extend field length functions"; 1296 } 1298 identity di-bidirectional { 1299 base direction-indicator-base-type; 1300 description "Direction Indication of bi directionality"; 1301 } 1303 identity di-up { 1304 base direction-indicator-base-type; 1305 description "Direction Indication of upstream"; 1306 } 1308 identity di-down { 1309 base direction-indicator-base-type; 1310 description "Direction Indication of downstream"; 1311 } 1313 //---------------------------------- 1314 // Matching Operator type definition 1315 //---------------------------------- 1317 identity matching-operator-base-type { 1318 description "used to extend Matching Operators with SID values"; 1319 } 1321 identity mo-equal { 1322 base matching-operator-base-type; 1323 description "RFC 8724"; 1324 } 1326 identity mo-ignore { 1327 base matching-operator-base-type; 1328 description "RFC 8724"; 1329 } 1331 identity mo-msb { 1332 base matching-operator-base-type; 1333 description "RFC 8724"; 1334 } 1336 identity mo-matching { 1337 base matching-operator-base-type; 1338 description "RFC 8724"; 1339 } 1341 //------------------------------ 1342 // CDA type definition 1343 //------------------------------ 1345 identity compression-decompression-action-base-type; 1347 identity cda-not-sent { 1348 base compression-decompression-action-base-type; 1349 description "RFC 8724"; 1350 } 1352 identity cda-value-sent { 1353 base compression-decompression-action-base-type; 1354 description "RFC 8724"; 1355 } 1357 identity cda-lsb { 1358 base compression-decompression-action-base-type; 1359 description "RFC 8724"; 1360 } 1362 identity cda-mapping-sent { 1363 base compression-decompression-action-base-type; 1364 description "RFC 8724"; 1365 } 1367 identity cda-compute-length { 1368 base compression-decompression-action-base-type; 1369 description "RFC 8724"; 1370 } 1372 identity cda-compute-checksum { 1373 base compression-decompression-action-base-type; 1374 description "RFC 8724"; 1375 } 1377 identity cda-deviid { 1378 base compression-decompression-action-base-type; 1379 description "RFC 8724"; 1380 } 1382 identity cda-appiid { 1383 base compression-decompression-action-base-type; 1384 description "RFC 8724"; 1385 } 1387 // -- type definition 1389 typedef field-id-type { 1390 description "Field ID generic type."; 1391 type identityref { 1392 base field-id-base-type; 1393 } 1394 } 1396 typedef field-length-type { 1397 description "Field length either a positive integer giving the size in bits 1398 or a function defined through an identityref."; 1399 type union { 1400 type int64; /* positive length in bits */ 1401 type identityref { /* function */ 1402 base field-length-base-type; 1403 } 1404 } 1405 } 1407 typedef direction-indicator-type { 1408 description "direction in LPWAN network, up when emitted by the device, 1409 down when received by the device, bi when emitted or received by the device."; 1410 type identityref { 1411 base direction-indicator-base-type; 1412 } 1413 } 1415 typedef matching-operator-type { 1416 description "Matching Operator (MO) to compare fields values with target values"; 1417 type identityref { 1418 base matching-operator-base-type; 1419 } 1420 } 1422 typedef comp-decomp-action-type { 1423 description "Compression Decompression Action to compression or decompress a field."; 1424 type identityref { 1425 base compression-decompression-action-base-type; 1426 } 1427 } 1429 // -- FRAGMENTATION TYPE 1431 // -- fragmentation modes 1433 identity fragmentation-mode-base-type { 1434 description "fragmentation mode"; 1435 } 1437 identity fragmentation-mode-no-ack { 1438 description "No Ack of RFC 8724."; 1439 base fragmentation-mode-base-type; 1440 } 1442 identity fragmentation-mode-ack-always { 1443 description "Ack Always of RFC8724."; 1444 base fragmentation-mode-base-type; 1445 } 1446 identity fragmentation-mode-ack-on-error { 1447 description "Ack on Error of RFC8724."; 1448 base fragmentation-mode-base-type; 1450 } 1452 typedef fragmentation-mode-type { 1453 type identityref { 1454 base fragmentation-mode-base-type; 1455 } 1456 } 1458 // -- Ack behavior 1460 identity ack-behavior-base-type { 1461 description "define when to send an Acknowledgment message"; 1462 } 1464 identity ack-behavior-after-All0 { 1465 description "fragmentation expects Ack after sending All0 fragment."; 1466 base ack-behavior-base-type; 1467 } 1469 identity ack-behavior-after-All1 { 1470 description "fragmentation expects Ack after sending All1 fragment."; 1471 base ack-behavior-base-type; 1472 } 1474 identity ack-behavior-always { 1475 description "fragmentation expects Ack after sending every fragment."; 1476 base ack-behavior-base-type; 1477 } 1479 typedef ack-behavior-type { 1480 type identityref { 1481 base ack-behavior-base-type; 1482 } 1483 } 1485 // -- All1 with data types 1487 identity all1-data-base-type { 1488 description "type to define when to send an Acknowledgment message"; 1489 } 1491 identity all1-data-no { 1492 description "All1 contains no tiles."; 1493 base all1-data-base-type; 1494 } 1496 identity all1-data-yes { 1497 description "All1 MUST contain a tile"; 1498 base all1-data-base-type; 1499 } 1501 identity all1-data-sender-choice { 1502 description "Fragmentation process choose to send tiles or not in all1."; 1503 base all1-data-base-type; 1504 } 1506 typedef all1-data-type { 1507 type identityref { 1508 base all1-data-base-type; 1509 } 1510 } 1512 // -- RCS algorithm types 1514 identity RCS-algorithm-base-type { 1515 description "identify which algorithm is used to compute RSC. 1516 The algorithm defines also the size if the RSC field."; 1517 } 1519 identity RFC8724-RCS { 1520 description "CRC 32 defined as default RCS in RFC8724."; 1521 base RCS-algorithm-base-type; 1522 } 1524 typedef RCS-algorithm-type { 1525 type identityref { 1526 base RCS-algorithm-base-type; 1527 } 1528 } 1530 // -------- RULE ENTRY DEFINITION ------------ 1532 grouping target-values-struct { 1533 description "defines the target value element. Can be either an arbitrary 1534 binary or ascii element. All target values are considered as a matching lists. 1535 Position is used to order values, by default position 0 is used when containing 1536 a single element."; 1538 leaf value { 1539 type union { 1540 type binary; 1541 type string; 1542 } 1543 } 1544 leaf position { 1545 description "If only one element position is 0, otherwise position is the 1546 matching list."; 1547 type uint16; 1548 } 1549 } 1551 grouping compression-rule-entry { 1552 description "These entries defines a compression entry (i.e. a line) 1553 as defined in RFC 8724 and fragmentation parameters. 1555 +-------+--+--+--+------------+-----------------+---------------+ 1556 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 1557 +-------+--+--+--+------------+-----------------+---------------+ 1559 An entry in a compression rule is composed of 7 elements: 1560 - Field ID: The header field to be compressed. The content is a YANG identifer. 1561 - Field Length : either a positive integer of a function defined as a YANF id. 1562 - Field Position: a positive (and possibly equal to 0) integer. 1563 - Direction Indicator: a YANG identifier giving the direction. 1564 - Target value: a value against which the header Field is compared. 1565 - Matching Operator: a YANG id giving the operation, paramters may be 1566 associated to that operator. 1567 - Comp./Decomp. Action: A YANG id giving the compression or decompression 1568 action, paramters may be associated to that action. 1569 "; 1571 leaf field-id { 1572 description "Field ID, identify a field in the header with a YANG refenceid."; 1573 mandatory true; 1574 type schc:field-id-type; 1575 } 1576 leaf field-length { 1577 description "Field Length in bit or through a function defined as a YANG referenceid"; 1578 mandatory true; 1579 type schc:field-length-type; 1580 } 1581 leaf field-position { 1582 description "field position in the header is a integer. If the field is not repeated 1583 in the header the value is 1, and incremented for each repetition of the field. Position 1584 0 means that the position is not important and order may change when decompressed"; 1585 mandatory true; 1586 type uint8; 1587 } 1588 leaf direction-indicator { 1589 description "Direction Indicator, a YANG referenceid to say if the packet is bidirectionnal, 1590 up or down"; 1591 mandatory true; 1592 type schc:direction-indicator-type; 1593 } 1594 list target-values { 1595 description "a list of value to compare with the header field value. If target value 1596 is a singleton, position must be 0. For matching-list, should be consecutive position 1597 values starting from 1."; 1598 key position; 1599 uses target-values-struct; 1600 } 1601 leaf matching-operator { 1602 mandatory true; 1603 type schc:matching-operator-type; 1604 } 1605 list matching-operator-value { 1606 key position; 1607 uses target-values-struct; 1608 } 1609 leaf comp-decomp-action { 1610 mandatory true; 1611 type schc:comp-decomp-action-type; 1612 } 1613 list comp-decomp-action-value { 1614 key position; 1615 uses target-values-struct; 1616 } 1617 } 1619 grouping compression-content { 1620 description "define a compression rule composed of a list of entries."; 1621 list entry { 1622 key "field-id field-position direction-indicator"; 1623 uses compression-rule-entry; 1624 } 1625 } 1627 grouping fragmentation-content { 1628 description "This grouping defines the fragmentation parameters for 1629 all the modes (No Ack, Ack Always and Ack on Error) specified in 1630 RFC 8724."; 1632 leaf direction { 1633 type schc:direction-indicator-type; 1634 description "should be up or down, bi directionnal is forbiden."; 1635 mandatory true; 1636 } 1637 leaf dtagsize { 1638 type uint8; 1639 description "size in bit of the DTag field"; 1641 } 1642 leaf wsize { 1643 type uint8; 1644 description "size in bit of the window field"; 1645 } 1646 leaf fcnsize { 1647 type uint8; 1648 description "size in bit of the FCN field"; 1649 mandatory true; 1650 } 1651 leaf RCS-algorithm { 1652 type RCS-algorithm-type; 1653 default schc:RFC8724-RCS; 1654 description "Algoritm used for RCS"; 1655 } 1656 leaf maximum-window-size { 1657 type uint16; 1658 description "by default 2^wsize - 1"; 1659 } 1661 leaf retransmission-timer { 1662 type uint64 { 1663 range 1..max; 1664 } 1665 description "duration in seconds of the retransmission timer"; // Check the units 1666 } 1668 leaf inactivity-timer { 1669 type uint64; 1670 description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units 1671 } 1673 leaf max-ack-requests { 1674 type uint8 { 1675 range 1..max; 1676 } 1677 description "the maximum number of retries for a specific SCHC ACK."; 1678 } 1680 leaf maximum-packet-size { 1681 type uint16; 1682 default 1280; 1683 description "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 1684 } 1686 leaf fragmentation-mode { 1687 type schc:fragmentation-mode-type; 1688 description "which fragmentation mode is used (noAck, AckAlways, AckonError)"; 1689 mandatory true; 1690 } 1692 choice mode { 1693 case no-ack; 1694 case ack-always; 1695 case ack-on-error { 1696 leaf tile-size { 1697 type uint8; 1698 description "size in bit of tiles, if not specified or set to 0: tile fills the fragment."; 1699 } 1700 leaf tile-in-All1 { 1701 type schc:all1-data-type; 1702 description "When true, sender and receiver except a tile in All-1 frag"; 1703 } 1704 leaf ack-behavior { 1705 type schc:ack-behavior-type; 1706 description "Sender behavior to acknowledge, after All-0, All-1 or when the 1707 LPWAN allows it (Always)"; 1708 } 1709 } 1710 } 1711 } 1713 // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length 1715 grouping rule-id-type { 1716 leaf rule-id { 1717 type uint32; 1718 description "rule ID value, this value must be unique combined with the length"; 1719 } 1720 leaf rule-length { 1721 type uint8 { 1722 range 0..32; 1723 } 1724 description "rule ID length in bits, value 0 is for implicit rules"; 1725 } 1726 } 1728 // SCHC table for a specific device. 1730 container schc { 1731 leaf version{ 1732 type uint64; 1733 mandatory false; 1734 description "used as an indication for versioning"; 1736 } 1737 list rule { 1738 key "rule-id rule-length"; 1739 uses rule-id-type; 1740 choice nature { 1741 case fragmentation { 1742 uses fragmentation-content; 1743 } 1744 case compression { 1745 uses compression-content; 1746 } 1747 } 1748 } 1749 } 1751 } 1753 1755 Figure 23 1757 8. Normative References 1759 [I-D.barthel-lpwan-oam-schc] 1760 Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and 1761 J. Zuniga, "OAM for LPWAN using Static Context Header 1762 Compression (SCHC)", draft-barthel-lpwan-oam-schc-01 (work 1763 in progress), March 2020. 1765 [I-D.ietf-lpwan-coap-static-context-hc] 1766 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 1767 Context Header Compression (SCHC) for CoAP", draft-ietf- 1768 lpwan-coap-static-context-hc-15 (work in progress), July 1769 2020. 1771 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1772 Application Protocol (CoAP)", RFC 7252, 1773 DOI 10.17487/RFC7252, June 2014, 1774 . 1776 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1777 Zuniga, "SCHC: Generic Framework for Static Context Header 1778 Compression and Fragmentation", RFC 8724, 1779 DOI 10.17487/RFC8724, April 2020, 1780 . 1782 Authors' Addresses 1784 Ana Minaburo 1785 Acklio 1786 1137A avenue des Champs Blancs 1787 35510 Cesson-Sevigne Cedex 1788 France 1790 Email: ana@ackl.io 1792 Laurent Toutain 1793 Institut MINES TELECOM; IMT Atlantique 1794 2 rue de la Chataigneraie 1795 CS 17607 1796 35576 Cesson-Sevigne Cedex 1797 France 1799 Email: Laurent.Toutain@imt-atlantique.fr