idnits 2.17.1 draft-ietf-lpwan-schc-yang-data-model-02.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 32 instances of too long lines in the document, the longest one being 39 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 688 has weird spacing: '...dicator sch...' == Line 691 has weird spacing: '...osition uin...' == Line 695 has weird spacing: '...osition uin...' == Line 699 has weird spacing: '...osition uin...' -- The document date (February 28, 2020) is 1518 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 1409, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lpwan-coap-static-context-hc-12 Summary: 1 error (**), 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 31, 2020 Institut MINES TELECOM; IMT Atlantique 6 February 28, 2020 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-02 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 31, 2020. 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 . . . . . . . . . . . . . . . . . . . . 4 54 2.3. Field length . . . . . . . . . . . . . . . . . . . . . . 6 55 2.4. Field position . . . . . . . . . . . . . . . . . . . . . 7 56 2.5. Direction Indicator . . . . . . . . . . . . . . . . . . . 7 57 2.6. Target Value . . . . . . . . . . . . . . . . . . . . . . 8 58 2.7. Matching Operator . . . . . . . . . . . . . . . . . . . . 9 59 2.7.1. Matching Operator arguments . . . . . . . . . . . . . 10 60 2.8. Compression Decompresison 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 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 17 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 5. Security considerations . . . . . . . . . . . . . . . . . . . 19 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 71 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 33 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 75 1. Introduction 77 2. SCHC rules 79 SCHC is a compression and fragmentation mechanism for constrained 80 networks defined in [I-D.ietf-lpwan-ipv6-static-context-hc] it is 81 based on a static context shared by two entities at the boundary this 82 contrained network. Draft [I-D.ietf-lpwan-ipv6-static-context-hc] 83 provides an abstract representation of the rules used either for 84 compression/decompression (or C/D) or fragmentation/reassembly (or F/ 85 R). The goal of this document is to formalize the description of the 86 rules to offer: 88 o universal representation of the rule to allow the same rule 89 represention on both ends. For instance; a device can provide the 90 rule it uses to store them in the core SCHC C/D and F/R. 92 o a device or the core SCHC instance may update the other end to set 93 upsome specific values (e.g. IPv6 prefix, Destination 94 address,...) 96 o ... 98 This document defines a YANG module to represent both compression and 99 fragmentation rules, which leads to common representation and values 100 for the elements of the rules. SCHC compression is generic, the main 101 mechanism do no refers to a specific fields. A field is abstractedh 102 through an ID, a position, a direction and a value that can be a 103 numerical value or a string. 105 [I-D.ietf-lpwan-ipv6-static-context-hc] and 106 [I-D.ietf-lpwan-coap-static-context-hc] specifies fields for IPv6, 107 UDP, CoAP and OSCORE. 109 Fragmentation requires a set of common parameters that are included 110 in a rule. 112 2.1. Compression Rules 114 [I-D.ietf-lpwan-ipv6-static-context-hc] proposes an abstract 115 representation of the compression rule. A compression context for a 116 device is composed of a set of rules. Each rule contains information 117 to describe a specific field in the header to be compressed. 119 +-----------------------------------------------------------------+ 120 | Rule N | 121 +-----------------------------------------------------------------+| 122 | Rule i || 123 +-----------------------------------------------------------------+|| 124 | (FID) Rule 1 ||| 125 |+-------+--+--+--+------------+-----------------+---------------+||| 126 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 127 |+-------+--+--+--+------------+-----------------+---------------+||| 128 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 129 |+-------+--+--+--+------------+-----------------+---------------+||| 130 ||... |..|..|..| ... | ... | ... |||| 131 |+-------+--+--+--+------------+-----------------+---------------+||/ 132 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 133 |+-------+--+--+--+------------+-----------------+---------------+|/ 134 | | 135 \-----------------------------------------------------------------/ 137 Figure 1: Compression Decompression Context 139 2.2. Field Identifier 141 In the process of compression, the headers of the original packet are 142 first parsed to create a list of fields. This list of fields is 143 matched again the rules to find the appropriate one and apply 144 compression. The link between the list given by the parsed fields 145 and the rules is doen through a field ID. 146 [I-D.ietf-lpwan-ipv6-static-context-hc] do not state how the field ID 147 value can be constructed. In the given example, it was given through 148 a string indexed by the protocol name (e.g. IPv6.version, 149 CoAP.version,...). 151 Using the YANG model, each field can be identified through a global 152 YANG identityref. A YANG field ID derives from the field-id-base- 153 type. Figure 2 gives some field ID definitions. Note that some 154 field IDs can be splitted is smaller pieces. This is the case for 155 "fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are 156 a subset of "fid-ipv6-trafficclass-ds". 158 identity field-id-base-type { 159 description "Field ID with SID"; 160 } 162 identity fid-ipv6-version { 163 base field-id-base-type; 164 description "IPv6 version field from RFC8200"; 165 } 167 identity fid-ipv6-trafficclass { 168 base field-id-base-type; 169 description "IPv6 Traffic Class field from RFC8200"; 170 } 172 identity fid-ipv6-trafficclass-ds { 173 base field-id-base-type; 174 description "IPv6 Traffic Class field from RFC8200, 175 DiffServ field from RFC3168"; 176 } 178 identity fid-ipv6-trafficclass-ecn { 179 base field-id-base-type; 180 description "IPv6 Traffic Class field from RFC8200, 181 ECN field from RFC3168"; 182 } 184 ... 186 identity fid-coap-option-if-match { 187 base field-id-base-type; 188 description "CoAP option If-Match from RFC 7252"; 189 } 191 identity fid-coap-option-uri-host { 192 base field-id-base-type; 193 description "CoAP option URI-Host from RFC 7252"; 194 } 196 ... 198 Figure 2: Definition of indentityref for field IDs 200 Figure 2 gives an example of field ID identityref definitions. The 201 base identity is field-id-base-type, and field id are derived for it. 202 The naming convention is "fid" followed by the protocol name and the 203 field name. 205 The yang model in annex gives the full definition of the field ID for 206 [I-D.ietf-lpwan-ipv6-static-context-hc] and 207 [I-D.ietf-lpwan-coap-static-context-hc]. 209 The type associated to this identity is field-id-type (cf. Figure 3) 211 typedef field-id-type { 212 description "Field ID generic type."; 213 type identityref { 214 base field-id-base-type; 215 } 216 } 218 Figure 3: Definition of indentityref for field IDs 220 2.3. Field length 222 Field length is either an integer giving the size of a field in bits 223 or a function. [I-D.ietf-lpwan-ipv6-static-context-hc] defines the 224 "var" function which allows variable length fields in byte and 225 [I-D.ietf-lpwan-coap-static-context-hc] defines the "tkl" function 226 for managing the CoAP Token length field. 228 identity field-length-base-type { 229 description "used to extend field length functions"; 230 } 232 identity fl-variable { 233 base field-length-base-type; 234 description "residue length in Byte is sent"; 235 } 237 identity fl-token-length { 238 base field-length-base-type; 239 description "residue length in Byte is sent"; 240 } 242 Figure 4: Definition of indetntyref for field IDs 244 As for field ID, field length function can be defined as a 245 identityref as shown in Figure 4. 247 Therefore the type for field length is a union between an integer 248 giving in bits the size of the length and the identityref (cf. 249 Figure 5). 251 typedef field-length-type { 252 type union { 253 type int64; /* positive length */ 254 type identityref { /* function */ 255 base field-length-base-type; 256 } 257 } 258 } 260 Figure 5: Definition of indetntyref for field IDs 262 The naming convention is fl followed by the function name as defined 263 in SCHC specifications. 265 2.4. Field position 267 Field position is a positive integer which gives the position of a 268 field, the default value is 1, but if the field is repeated several 269 times, the value is higher. value 0 indicates that the position is 270 not important and is not taken into account during the rule selection 271 process. 273 Field position is a positive integer. The type is an uint8. 275 2.5. Direction Indicator 277 The Direction Indicator (DI) is used to tell if a field appears in 278 both direction (Bi) or only uplink (Up) or Downlink (Dw). 280 identity direction-indicator-base-type { 281 description "used to extend field length functions"; 282 } 284 identity di-bidirectional { 285 base direction-indicator-base-type; 286 description "Direction Indication of bi directionality"; 287 } 289 identity di-up { 290 base direction-indicator-base-type; 291 description "Direction Indication of upstream"; 292 } 294 identity di-down { 295 base direction-indicator-base-type; 296 description "Direction Indication of downstream"; 297 } 299 Figure 6: Definition of identityref for direction indicators 301 Figure 6 gives the identityref for Direction Indicators. 303 The type is "direction-indicator-type" (cf. Figure 7). 305 typedef direction-indicator-type { 306 type identityref { 307 base direction-indicator-base-type; 308 } 309 } 311 Figure 7: Definition of identityref for direction indicators 313 2.6. Target Value 315 Target Value may be either a string or binary sequence. For match- 316 mapping, several of these values can be contained in a Target Value 317 field. In the data model, this is generalized by adding a position, 318 which orders the list of values. By default the position is set to 319 0. 321 The leaf "value" is not mandatory to represent a non existing value 322 in a TV. 324 grouping target-values-struct { 325 leaf value { 326 type union { 327 type binary; 328 type string; 329 } 330 } 331 leaf position { 332 type uint16; 333 } 334 } 336 Figure 8: Definition of target value 338 Figure 8 gives the definition of a single element of a Target Value. 339 In the rule, this will be used as a list, with position as a key. 341 2.7. Matching Operator 343 Matching Operator (MO) is a function applied between a field value 344 provided by the parsed header and the target value. 345 [I-D.ietf-lpwan-ipv6-static-context-hc] defines 4 MO. 347 identity matching-operator-base-type { 348 description "used to extend Matching Operators with SID values"; 349 } 351 identity mo-equal { 352 base matching-operator-base-type; 353 description "SCHC draft"; 354 } 356 identity mo-ignore { 357 base matching-operator-base-type; 358 description "SCHC draft"; 359 } 361 identity mo-msb { 362 base matching-operator-base-type; 363 description "SCHC draft"; 364 } 366 identity mo-matching { 367 base matching-operator-base-type; 368 description "SCHC draft"; 369 } 371 Figure 9: Definition of Matching Operator identity 373 the type is "matching-operator-type" (cf. Figure 10) 375 typedef matching-operator-type { 376 type identityref { 377 base matching-operator-base-type; 378 } 379 } 381 Figure 10: Definition of Matching Operator type 383 2.7.1. Matching Operator arguments 385 Some Matching Operator such as MSB can take some values. Even if 386 currently LSB is the only MO takes only one argument, in the future 387 some MO may require several arguments. They are viewed as a list of 388 target-values-type. 390 2.8. Compression Decompresison Actions 392 Compresion Decompression Action (CDA) idenfied the function to use 393 either for compression or decompression. 394 [I-D.ietf-lpwan-ipv6-static-context-hc] defines 6 CDA. 396 identity compression-decompression-action-base-type; 398 identity cda-not-sent { 399 base compression-decompression-action-base-type; 400 description "from SCHC draft"; 401 } 403 identity cda-value-sent { 404 base compression-decompression-action-base-type; 405 description "from SCHC draft"; 406 } 408 identity cda-lsb { 409 base compression-decompression-action-base-type; 410 description "from SCHC draft"; 411 } 413 identity cda-mapping-sent { 414 base compression-decompression-action-base-type; 415 description "from SCHC draft"; 416 } 418 identity cda-compute-length { 419 base compression-decompression-action-base-type; 420 description "from SCHC draft"; 421 } 423 identity cda-compute-checksum { 424 base compression-decompression-action-base-type; 425 description "from SCHC draft"; 426 } 428 identity cda-deviid { 429 base compression-decompression-action-base-type; 430 description "from SCHC draft"; 431 } 433 identity cda-appiid { 434 base compression-decompression-action-base-type; 435 description "from SCHC draft"; 436 } 438 Figure 11: Definition of Compresion Decompression Action identity 440 The type is "comp-decomp-action-type" (cf. Figure 12) 441 typedef comp-decomp-action-type { 442 type identityref { 443 base compression-decompression-action-base-type; 444 } 445 } 447 Figure 12: Definition of Compresion Decompression Action type 449 2.8.1. Compression Decompression Action arguments 451 Currently no CDA requires argumetns, but the future some CDA may 452 require several arguments. They are viewed as a list of target- 453 values-type. 455 3. Rule definition 457 A rule is either a C/D or an F/R rule. A rule is identified by the 458 rule ID value and its associated length. The YANG grouping rule-id- 459 type defines the structure used to represent a rule ID. Length of 0 460 is allowed to represent an implicit rule. 462 // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length 464 grouping rule-id-type { 465 leaf rule-id { 466 type uint32; 467 description "rule ID value, this value must be unique combined with the length"; 468 } 469 leaf rule-length { 470 type uint8 { 471 range 0..32; 472 } 473 description "rule ID length in bits, value 0 is for implicit rules"; 474 } 475 } 477 // SCHC table for a specific device. 479 container schc { 480 leaf version{ 481 type uint64; 482 mandatory false; 483 description "used as an indication for versioning"; 484 } 485 list rule { 486 key "rule-id rule-length"; 487 uses rule-id-type; 488 choice nature { 489 case fragmentation { 490 uses fragmentation-content; 491 } 492 case compression { 493 uses compression-content; 494 } 495 } 496 } 497 } 499 Figure 13: Definition of a SCHC Context 501 To access to a specfic rule, rule-id and its specific length is used 502 as a key. The rule is either a compression or a fragmentation rule. 504 Each context can be identify though a version id. 506 3.1. Compression rule 508 A compression rule is composed of entries describing its processing 509 (cf. Figure 14). An entry contains all the information defined in 510 Figure 1 with the types defined above. 512 3.1.1. Compression context representation. 514 The compression rule described Figure 1 is associated to a rule ID. 515 The compression rule entry is defined in Figure 14. Each column in 516 the table is either represented by a leaf or a list. Note that 517 Matching Operators and Compression Decompression actions can have 518 arguments. They are viewed a ordered list of strings and numbers as 519 in target values. 521 grouping compression-rule-entry { 522 leaf field-id { 523 mandatory true; 524 type schc-id:field-id-type; 525 } 526 leaf field-length { 527 mandatory true; 528 type schc-id:field-length-type; 529 } 530 leaf field-position { 531 mandatory true; 532 type uint8; 533 } 534 leaf direction-indicator { 535 mandatory true; 536 type schc-id:direction-indicator-type; 537 } 538 list target-values { 539 key position; 540 uses target-values-struct; 541 } 542 leaf mo { 543 mandatory true; 544 type schc-id:matching-operator-type; 545 } 546 list mo-value { 547 key position; 548 uses target-values-struct; 549 } 550 leaf cda { 551 mandatory true; 552 type schc-id:comp-decomp-action-type; 553 } 554 list cda-value { 555 key position; 556 uses target-values-struct; 557 } 558 } 560 Figure 14: Definition of a compression entry 562 3.1.2. Rule definition 564 A compression rule is a list of entries. 566 grouping compression-content { 567 list entry { 568 key "field-id field-position direction-indicator"; 569 uses compression-rule-entry; 570 } 571 } 573 Figure 15: Definition of a compression rule 575 To identify a specific entry Field ID, position and direction are 576 needed. 578 3.2. Fragmentation rule 580 Parameters for fragmentation are defined in Annex D of 581 [I-D.ietf-lpwan-ipv6-static-context-hc]. Two new types are defined 582 for Ack on Error acknowlement behavior (ack-behavior-type) and the 583 RCS algorithm (RCS-algorithm-type). 585 grouping fragmentation-content { 586 leaf direction { 587 type schc-id:direction-indicator-type; 588 description "should be up or down"; 589 } 591 leaf dtagsize { 592 type uint8; 593 description "size in bit of the DTag field"; 594 } 595 leaf wsize { 596 type uint8; 597 description "size in bit of the window field"; 598 } 599 leaf fcnsize { 600 type uint8; 601 description "size in bit of the FCN field"; 602 } 603 leaf RCS-algorithm { 604 type RCS-algorithm-type; 605 default schc-id:RFC8724-RCS; 606 description "Algoritm used for RCS"; 607 } 608 leaf maximum-window-size { 609 type uint16; 610 description "by default 2^wsize - 1"; 611 } 613 leaf retransmission-timer { 614 type uint64; 615 description "duration in seconds of the retransmission timer"; // Check the units 616 } 618 leaf inactivity-timer { 619 type uint64; 620 description "duration is seconds of the inactivity timer"; // check units 621 } 623 leaf max-ack-requests { 624 type uint8; 625 } 627 leaf maximum-packet-size { 628 type uint16; 629 mandatory true; 630 default 1280; 631 description "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 632 } 634 choice mode { 635 case no-ack; 636 case ack-always; 637 case ack-on-error { 638 leaf tile-size { 639 type uint8; 640 description "size in bit of tiles"; 641 } 642 leaf tile-in-All1 { 643 type boolean; 644 description "When true, sender and receiver except a tile in All-1 frag"; 645 } 646 leaf ack-behavior { 647 type schc-id:ack-behavior-type; 648 mandatory true; 649 } 651 } 652 } 653 } 655 Figure 16: Definition of a fragmentation rule 657 3.3. YANG Tree 658 module: schc 659 +--rw schc 660 +--rw version? uint64 661 +--rw rule* [rule-id rule-length] 662 +--rw rule-id uint32 663 +--rw rule-length uint8 664 +--rw (nature)? 665 +--:(fragmentation) 666 | +--rw direction? schc-id:direction-indicator-type 667 | +--rw dtagsize? uint8 668 | +--rw wsize? uint8 669 | +--rw fcnsize? uint8 670 | +--rw RCS-algorithm? RCS-algorithm-type 671 | +--rw maximum-window-size? uint16 672 | +--rw retransmission-timer? uint64 673 | +--rw inactivity-timer? uint64 674 | +--rw max-ack-requests? uint8 675 | +--rw maximum-packet-size uint16 676 | +--rw (mode) 677 | +--:(no-ack) 678 | +--:(ack-always) 679 | +--:(ack-on-error) 680 | +--rw tile-size? uint8 681 | +--rw tile-in-All1? boolean 682 | +--rw ack-behavior schc-id:ack-behavior-type 683 +--:(compression) 684 +--rw entry* [field-id field-position direction-indicator] 685 +--rw field-id schc-id:field-id-type 686 +--rw field-length schc-id:field-length-type 687 +--rw field-position uint8 688 +--rw direction-indicator schc-id:direction-indicator-type 689 +--rw target-values* [position] 690 | +--rw value? union 691 | +--rw position uint16 692 +--rw mo schc-id:matching-operator-type 693 +--rw mo-value* [position] 694 | +--rw value? union 695 | +--rw position uint16 696 +--rw cda schc-id:comp-decomp-action-type 697 +--rw cda-value* [position] 698 +--rw value? union 699 +--rw position uint16 701 Figure 17 703 4. IANA Considerations 705 This document has no request to IANA. 707 5. Security considerations 709 This document does not have any more Security consideration than the 710 ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc] 712 6. Acknowledgements 714 The authors would like to thank Dominique Barthel, Carsten Bormann, 715 Alexander Pelov. 717 7. YANG Module 719 Currently the data model is split into two parts. The first one is 720 dedicated to SCHC identifiers and the second one contains the rules 721 definition. The goal is to allow some stabilities in the rule 722 identifiers if new SCHC identfiers are added. When the model will be 723 stable, these two files will be merged. 725 file schc-id@2020-02-28.yang 726 module schc-id{ 727 yang-version "1"; 728 namespace "urn:ietf:lpwan:schc:schc-id"; 729 prefix "schc-id"; 731 description 732 "Identifiers used in SCHC data model."; 734 revision 2020-02-28 { 735 description "Add fragmentation identifiers"; 736 } 737 revision 2020-02-11 { 738 description "Clean up"; 739 } 740 revision 2020-01-07 { 741 description "First version of the SCHC identifiers"; 742 } 744 // ------------------------- 745 // Field ID type definition 746 //-------------------------- 748 // generic value TV definition 750 identity field-id-base-type { 751 description "Field ID with SID"; 752 } 754 identity fid-ipv6-version { 755 base field-id-base-type; 756 description "IPv6 version field from RFC8200"; 757 } 759 identity fid-ipv6-trafficclass { 760 base field-id-base-type; 761 description "IPv6 Traffic Class field from RFC8200"; 762 } 764 identity fid-ipv6-trafficclass-ds { 765 base field-id-base-type; 766 description "IPv6 Traffic Class field from RFC8200, 767 DiffServ field from RFC3168"; 768 } 770 identity fid-ipv6-trafficclass-ecn { 771 base field-id-base-type; 772 description "IPv6 Traffic Class field from RFC8200, 773 ECN field from RFC3168"; 774 } 776 identity fid-ipv6-flowlabel { 777 base field-id-base-type; 778 description "IPv6 Flow Label field from RFC8200"; 779 } 781 identity fid-ipv6-payloadlength { 782 base field-id-base-type; 783 description "IPv6 Payload Length field from RFC8200"; 784 } 786 identity fid-ipv6-nextheader { 787 base field-id-base-type; 788 description "IPv6 Next Header field from RFC8200"; 789 } 791 identity fid-ipv6-hoplimit { 792 base field-id-base-type; 793 description "IPv6 Next Header field from RFC8200"; 794 } 796 identity fid-ipv6-devprefix { 797 base field-id-base-type; 798 description "correspond either to the source address or the desdination 799 address prefix of RFC 8200. Depending if it is respectively 800 a uplink or an downklink message."; 801 } 803 identity fid-ipv6-deviid { 804 base field-id-base-type; 805 description "correspond either to the source address or the desdination 806 address prefix of RFC 8200. Depending if it is respectively 807 a uplink or an downklink message."; 808 } 810 identity fid-ipv6-appprefix { 811 base field-id-base-type; 812 description "correspond either to the source address or the desdination 813 address prefix of RFC 768. Depending if it is respectively 814 a downlink or an uplink message."; 815 } 817 identity fid-ipv6-appiid { 818 base field-id-base-type; 819 description "correspond either to the source address or the desdination 820 address prefix of RFC 768. Depending if it is respectively 821 a downlink or an uplink message."; 822 } 824 identity fid-udp-dev-port { 825 base field-id-base-type; 826 description "UDP length from RFC 768"; 827 } 829 identity fid-udp-app-port { 830 base field-id-base-type; 831 description "UDP length from RFC 768"; 832 } 834 identity fid-udp-length { 835 base field-id-base-type; 836 description "UDP length from RFC 768"; 837 } 839 identity fid-udp-checksum { 840 base field-id-base-type; 841 description "UDP length from RFC 768"; 842 } 844 identity fid-coap-version { 845 base field-id-base-type; 846 description "CoAP version from RFC 7252"; 848 } 850 identity fid-coap-type { 851 base field-id-base-type; 852 description "CoAP type from RFC 7252"; 853 } 855 identity fid-coap-tkl { 856 base field-id-base-type; 857 description "CoAP token length from RFC 7252"; 858 } 860 identity fid-coap-code { 861 base field-id-base-type; 862 description "CoAP code from RFC 7252"; 863 } 865 identity fid-coap-code-class { 866 base field-id-base-type; 867 description "CoAP code from RFC 7252"; 868 } 870 identity fid-coap-code-detail { 871 base field-id-base-type; 872 description "CoAP code from RFC 7252"; 873 } 875 identity fid-coap-mid { 876 base field-id-base-type; 877 description "CoAP message ID from RFC 7252"; 878 } 880 identity fid-coap-token { 881 base field-id-base-type; 882 description "CoAP token from RFC 7252"; 883 } 885 identity fid-coap-option-if-match { 886 base field-id-base-type; 887 description "CoAP option If-Match from RFC 7252"; 888 } 890 identity fid-coap-option-uri-host { 891 base field-id-base-type; 892 description "CoAP option URI-Host from RFC 7252"; 893 } 895 identity fid-coap-option-etag { 896 base field-id-base-type; 897 description "CoAP option Etag from RFC 7252"; 898 } 900 identity fid-coap-option-if-none-match { 901 base field-id-base-type; 902 description "CoAP option if-none-match from RFC 7252"; 903 } 905 identity fid-coap-option-observe { 906 base field-id-base-type; 907 description "CoAP option Observe from RFC 7641"; 908 } 910 identity fid-coap-option-uri-port { 911 base field-id-base-type; 912 description "CoAP option Uri-Port from RFC 7252"; 913 } 915 identity fid-coap-option-location-path { 916 base field-id-base-type; 917 description "CoAP option Location-Path from RFC 7252"; 918 } 920 identity fid-coap-option-uri-path { 921 base field-id-base-type; 922 description "CoAP option Uri-Path from RFC 7252"; 923 } 925 identity fid-coap-option-content-format { 926 base field-id-base-type; 927 description "CoAP option Content Format from RFC 7252"; 928 } 930 identity fid-coap-option-max-age { 931 base field-id-base-type; 932 description "CoAP option Max-Age from RFC 7252"; 933 } 935 identity fid-coap-option-uri-query { 936 base field-id-base-type; 937 description "CoAP option Uri-Query from RFC 7252"; 938 } 940 identity fid-coap-option-accept { 941 base field-id-base-type; 942 description "CoAP option Max-Age from RFC 7252"; 943 } 944 identity fid-coap-option-location-query { 945 base field-id-base-type; 946 description "CoAP option Location-Query from RFC 7252"; 947 } 949 identity fid-coap-option-block2 { 950 base field-id-base-type; 951 description "CoAP option Block2 from RFC 7959"; 952 } 954 identity fid-coap-option-block1 { 955 base field-id-base-type; 956 description "CoAP option Block1 from RFC 7959"; 957 } 959 identity fid-coap-option-size2 { 960 base field-id-base-type; 961 description "CoAP option size2 from RFC 7959"; 962 } 964 identity fid-coap-option-proxy-uri { 965 base field-id-base-type; 966 description "CoAP option Proxy-Uri from RFC 7252"; 967 } 969 identity fid-coap-option-proxy-scheme { 970 base field-id-base-type; 971 description "CoAP option Proxy-scheme from RFC 7252"; 972 } 974 identity fid-coap-option-size1 { 975 base field-id-base-type; 976 description "CoAP option Size1 from RFC 7252"; 977 } 979 identity fid-coap-option-no-response { 980 base field-id-base-type; 981 description "CoAP option No response from RFC 7967"; 982 } 984 identity fid-coap-option-end-option { 985 base field-id-base-type; 986 description "CoAP End Option from RFC 7967"; 987 } 989 //---------------------------------- 990 // Field Length type definition 991 //---------------------------------- 993 identity field-length-base-type { 994 description "used to extend field length functions"; 995 } 997 identity fl-variable { 998 base field-length-base-type; 999 description "residue length in Byte is sent"; 1000 } 1002 identity fl-token-length { 1003 base field-length-base-type; 1004 description "residue length in Byte is sent"; 1005 } 1007 //--------------------------------- 1008 // Direction Indicator type 1009 //--------------------------------- 1011 identity direction-indicator-base-type { 1012 description "used to extend field length functions"; 1013 } 1015 identity di-bidirectional { 1016 base direction-indicator-base-type; 1017 description "Direction Indication of bi directionality"; 1018 } 1020 identity di-up { 1021 base direction-indicator-base-type; 1022 description "Direction Indication of upstream"; 1023 } 1025 identity di-down { 1026 base direction-indicator-base-type; 1027 description "Direction Indication of downstream"; 1028 } 1030 //---------------------------------- 1031 // Matching Operator type definition 1032 //---------------------------------- 1034 identity matching-operator-base-type { 1035 description "used to extend Matching Operators with SID values"; 1036 } 1038 identity mo-equal { 1039 base matching-operator-base-type; 1040 description "SCHC draft"; 1041 } 1043 identity mo-ignore { 1044 base matching-operator-base-type; 1045 description "SCHC draft"; 1046 } 1048 identity mo-msb { 1049 base matching-operator-base-type; 1050 description "SCHC draft"; 1051 } 1053 identity mo-matching { 1054 base matching-operator-base-type; 1055 description "SCHC draft"; 1056 } 1058 //------------------------------ 1059 // CDA type definition 1060 //------------------------------ 1062 identity compression-decompression-action-base-type; 1064 identity cda-not-sent { 1065 base compression-decompression-action-base-type; 1066 description "from SCHC draft"; 1067 } 1069 identity cda-value-sent { 1070 base compression-decompression-action-base-type; 1071 description "from SCHC draft"; 1072 } 1074 identity cda-lsb { 1075 base compression-decompression-action-base-type; 1076 description "from SCHC draft"; 1077 } 1079 identity cda-mapping-sent { 1080 base compression-decompression-action-base-type; 1081 description "from SCHC draft"; 1082 } 1084 identity cda-compute-length { 1085 base compression-decompression-action-base-type; 1086 description "from SCHC draft"; 1088 } 1090 identity cda-compute-checksum { 1091 base compression-decompression-action-base-type; 1092 description "from SCHC draft"; 1093 } 1095 identity cda-deviid { 1096 base compression-decompression-action-base-type; 1097 description "from SCHC draft"; 1098 } 1100 identity cda-appiid { 1101 base compression-decompression-action-base-type; 1102 description "from SCHC draft"; 1103 } 1105 // -- type definition 1107 typedef field-id-type { 1108 description "Field ID generic type."; 1109 type identityref { 1110 base field-id-base-type; 1111 } 1112 } 1114 typedef field-length-type { 1115 type union { 1116 type int64; /* positive length */ 1117 type identityref { /* function */ 1118 base field-length-base-type; 1119 } 1120 } 1121 } 1123 typedef direction-indicator-type { 1124 type identityref { 1125 base direction-indicator-base-type; 1126 } 1127 } 1129 typedef matching-operator-type { 1130 type identityref { 1131 base matching-operator-base-type; 1132 } 1133 } 1135 typedef comp-decomp-action-type { 1136 type identityref { 1137 base compression-decompression-action-base-type; 1138 } 1139 } 1141 // -- fragmentation types 1143 identity ack-behavior-base-type { 1144 description "type to define when to send an Acknowledgment message"; 1145 } 1147 identity ack-behavior-after-All0 { 1148 description "fragmentor expect Ack after sending All0 fragment."; 1149 base ack-behavior-base-type; 1150 } 1152 identity ack-behavior-after-All1 { 1153 description "fragmentor expect Ack after sending All1 fragment."; 1154 base ack-behavior-base-type; 1155 } 1157 identity ack-behavior-after-Always { 1158 description "fragmentor expect Ack after sending every fragment."; 1159 base ack-behavior-base-type; 1160 } 1162 typedef ack-behavior-type { 1163 type identityref { 1164 base ack-behavior-base-type; 1165 } 1166 } 1168 // -- fragmentation types 1170 identity RCS-algorithm-base-type { 1171 description "identify which algorithm is used to compute RSC. 1172 The algorithm defines also the size if the RSC field."; 1173 } 1175 identity RFC8724-RCS { 1176 description "CRC 32 defined as default RCS in RFC8724."; 1177 base RCS-algorithm-base-type; 1178 } 1180 typedef RCS-algorithm-type { 1181 type identityref { 1182 base RCS-algorithm-base-type; 1183 } 1185 } 1187 } 1188 1190 Figure 18 1192 file schc@2020-02-28.yang 1193 module schc{ 1194 yang-version "1"; 1195 namespace "urn:ietf:lpwan:schc:rules-description"; 1196 prefix "schc"; 1198 import schc-id { 1199 prefix "schc-id"; 1200 } 1202 description 1203 "Generic Data model for Static Context Header Compression Rule for SCHC, 1204 based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression 1205 rules and fragmentation rules."; 1207 revision 2020-02-28 { 1208 description "Add Fragmentation parameters"; 1209 } 1211 revision 2020-01-23 { 1212 description "Modified TV with binary and union"; 1213 } 1215 revision 2020-01-07 { 1216 description "First version of the YANG model"; 1217 } 1219 // -------- RULE DEFINITION ------------ 1221 grouping target-values-struct { 1222 leaf value { 1223 type union { 1224 type binary; 1225 type string; 1226 } 1227 } 1228 leaf position { 1229 type uint16; 1230 } 1232 } 1234 grouping compression-rule-entry { 1235 leaf field-id { 1236 mandatory true; 1237 type schc-id:field-id-type; 1238 } 1239 leaf field-length { 1240 mandatory true; 1241 type schc-id:field-length-type; 1242 } 1243 leaf field-position { 1244 mandatory true; 1245 type uint8; 1246 } 1247 leaf direction-indicator { 1248 mandatory true; 1249 type schc-id:direction-indicator-type; 1250 } 1251 list target-values { 1252 key position; 1253 uses target-values-struct; 1254 } 1255 leaf mo { 1256 mandatory true; 1257 type schc-id:matching-operator-type; 1258 } 1259 list mo-value { 1260 key position; 1261 uses target-values-struct; 1262 } 1263 leaf cda { 1264 mandatory true; 1265 type schc-id:comp-decomp-action-type; 1266 } 1267 list cda-value { 1268 key position; 1269 uses target-values-struct; 1270 } 1271 } 1273 grouping fragmentation-content { 1274 leaf direction { 1275 type schc-id:direction-indicator-type; 1276 description "should be up or down"; 1277 } 1279 leaf dtagsize { 1280 type uint8; 1281 description "size in bit of the DTag field"; 1282 } 1283 leaf wsize { 1284 type uint8; 1285 description "size in bit of the window field"; 1286 } 1287 leaf fcnsize { 1288 type uint8; 1289 description "size in bit of the FCN field"; 1290 } 1291 leaf RCS-algorithm { 1292 type RCS-algorithm-type; 1293 default schc-id:RFC8724-RCS; 1294 description "Algoritm used for RCS"; 1295 } 1296 leaf maximum-window-size { 1297 type uint16; 1298 description "by default 2^wsize - 1"; 1299 } 1301 leaf retransmission-timer { 1302 type uint64; 1303 description "duration in seconds of the retransmission timer"; // Check the units 1304 } 1306 leaf inactivity-timer { 1307 type uint64; 1308 description "duration is seconds of the inactivity timer"; // check units 1309 } 1311 leaf max-ack-requests { 1312 type uint8; 1313 } 1315 leaf maximum-packet-size { 1316 type uint16; 1317 mandatory true; 1318 default 1280; 1319 description "When decompression is done, packet size must not strictly exceed this limit in Bytes"; 1320 } 1322 choice mode { 1323 mandatory true; 1324 case no-ack; 1325 case ack-always; 1326 case ack-on-error { 1327 leaf tile-size { 1328 type uint8; 1329 description "size in bit of tiles"; 1330 } 1331 leaf tile-in-All1 { 1332 type boolean; 1333 description "When true, sender and receiver except a tile in All-1 frag"; 1334 } 1335 leaf ack-behavior { 1336 type schc-id:ack-behavior-type; 1337 mandatory true; 1338 } 1340 } 1341 } 1342 } 1344 grouping compression-content { 1345 list entry { 1346 key "field-id field-position direction-indicator"; 1347 uses compression-rule-entry; 1348 } 1349 } 1351 // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length 1353 grouping rule-id-type { 1354 leaf rule-id { 1355 type uint32; 1356 description "rule ID value, this value must be unique combined with the length"; 1357 } 1358 leaf rule-length { 1359 type uint8 { 1360 range 0..32; 1361 } 1362 description "rule ID length in bits, value 0 is for implicit rules"; 1363 } 1364 } 1366 // SCHC table for a specific device. 1368 container schc { 1369 leaf version{ 1370 type uint64; 1371 mandatory false; 1372 description "used as an indication for versioning"; 1373 } 1374 list rule { 1375 key "rule-id rule-length"; 1376 uses rule-id-type; 1377 choice nature { 1378 case fragmentation { 1379 uses fragmentation-content; 1380 } 1381 case compression { 1382 uses compression-content; 1383 } 1384 } 1385 } 1386 } 1388 } 1390 1392 Figure 19 1394 8. Normative References 1396 [I-D.ietf-lpwan-coap-static-context-hc] 1397 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 1398 Context Header Compression (SCHC) for CoAP", draft-ietf- 1399 lpwan-coap-static-context-hc-12 (work in progress), 1400 December 2019. 1402 [I-D.ietf-lpwan-ipv6-static-context-hc] 1403 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 1404 Zuniga, "Static Context Header Compression (SCHC) and 1405 fragmentation for LPWAN, application to UDP/IPv6", draft- 1406 ietf-lpwan-ipv6-static-context-hc-24 (work in progress), 1407 December 2019. 1409 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1410 Application Protocol (CoAP)", RFC 7252, 1411 DOI 10.17487/RFC7252, June 2014, 1412 . 1414 Authors' Addresses 1416 Ana Minaburo 1417 Acklio 1418 1137A avenue des Champs Blancs 1419 35510 Cesson-Sevigne Cedex 1420 France 1422 Email: ana@ackl.io 1423 Laurent Toutain 1424 Institut MINES TELECOM; IMT Atlantique 1425 2 rue de la Chataigneraie 1426 CS 17607 1427 35576 Cesson-Sevigne Cedex 1428 France 1430 Email: Laurent.Toutain@imt-atlantique.fr