idnits 2.17.1 draft-ietf-lpwan-schc-yang-data-model-01.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 10 instances of too long lines in the document, the longest one being 26 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 635 has weird spacing: '...dicator sch...' == Line 638 has weird spacing: '...osition uin...' == Line 642 has weird spacing: '...osition uin...' == Line 646 has weird spacing: '...osition uin...' -- The document date (January 23, 2020) is 1555 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 681, 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: July 26, 2020 Institut MINES TELECOM; IMT Atlantique 6 January 23, 2020 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-01 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 July 26, 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 . . . . . . . . . . . . . . . . . . . 16 66 3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 16 67 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 17 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 5. Security considerations . . . . . . . . . . . . . . . . . . . 17 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 71 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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. {{Fig-field-id-type}}) 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; 541 uses target-values-struct; 542 } 543 leaf mo { 544 mandatory true; 545 type schc-id:matching-operator-type; 546 } 547 // /!\ Not always good, it allows to give several arguments to a MO, but 548 // theses arguments are only int or strings, cannot be arrays. Is it necessary? 549 list mo-value { 550 key position; 551 uses target-values-struct; 552 } 553 leaf cda { 554 mandatory true; 555 type schc-id:cda-type; 556 } 557 list cda-value { 558 key position; 559 uses target-values-struct; 560 } 561 } 563 Figure 14: Definition of a compression entry 565 3.1.2. Rule definition 567 A compression rule is a list of entries. 569 grouping compression-content { 570 list entry { 571 key "field-id field-position direction-indicator"; // field-position direction-indicator"; 572 uses compression-rule-entry; 573 } 574 } 576 Figure 15: Definition of a compression rule 578 To identify a specific entry Field ID, position and direction is 579 needed. 581 3.2. Fragmentation rule 583 TBD 585 grouping fragmentation-content { 586 leaf dtagsize { 587 type uint8; 588 } 589 leaf wsize { 590 type uint8; 591 } 592 leaf fcnsize { 593 type uint8; 594 } 595 choice mode { 596 case no-ack; 597 case ack-always; 598 case ack-on-error { 599 leaf ack-method { 600 type enumeration { 601 enum afterAll0; 602 enum afterAll1; 603 enum always; 604 } 605 } 606 } 607 } 608 } 610 Figure 16: Definition of a fragmentation rule 612 3.3. YANG Tree 614 module: schc 615 +--rw schc 616 +--rw version? uint64 617 +--rw rule* [rule-id rule-length] 618 +--rw rule-id uint32 619 +--rw rule-length uint8 620 +--rw (nature)? 621 +--:(fragmentation) 622 | +--rw dtagsize? uint8 623 | +--rw wsize? uint8 624 | +--rw fcnsize? uint8 625 | +--rw (mode)? 626 | +--:(no-ack) 627 | +--:(ack-always) 628 | +--:(ack-on-error) 629 | +--rw ack-method? enumeration 630 +--:(compression) 631 +--rw entry* [field-id field-position direction-indicator] 632 +--rw field-id schc-id:field-id-type 633 +--rw field-length schc-id:field-length-type 634 +--rw field-position uint8 635 +--rw direction-indicator schc-id:direction-indicator-type 636 +--rw target-values* [position] 637 | +--rw value? union 638 | +--rw position uint16 639 +--rw mo schc-id:matching-operator-type 640 +--rw mo-value* [position] 641 | +--rw value? union 642 | +--rw position uint16 643 +--rw cda schc-id:comp-decomp-action-type 644 +--rw cda-value* [position] 645 +--rw value? union 646 +--rw position uint16 648 Figure 17 650 4. IANA Considerations 652 This document has no request to IANA. 654 5. Security considerations 656 This document does not have any more Security consideration than the 657 ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc] 659 6. Acknowledgements 661 The authors would like to thank Dominique Barthel, Carsten Bormann, 662 Alexander Pelov. 664 7. YANG Module 666 8. Normative References 668 [I-D.ietf-lpwan-coap-static-context-hc] 669 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 670 Context Header Compression (SCHC) for CoAP", draft-ietf- 671 lpwan-coap-static-context-hc-12 (work in progress), 672 December 2019. 674 [I-D.ietf-lpwan-ipv6-static-context-hc] 675 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 676 Zuniga, "Static Context Header Compression (SCHC) and 677 fragmentation for LPWAN, application to UDP/IPv6", draft- 678 ietf-lpwan-ipv6-static-context-hc-24 (work in progress), 679 December 2019. 681 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 682 Application Protocol (CoAP)", RFC 7252, 683 DOI 10.17487/RFC7252, June 2014, 684 . 686 Authors' Addresses 688 Ana Minaburo 689 Acklio 690 1137A avenue des Champs Blancs 691 35510 Cesson-Sevigne Cedex 692 France 694 Email: ana@ackl.io 696 Laurent Toutain 697 Institut MINES TELECOM; IMT Atlantique 698 2 rue de la Chataigneraie 699 CS 17607 700 35576 Cesson-Sevigne Cedex 701 France 703 Email: Laurent.Toutain@imt-atlantique.fr