idnits 2.17.00 (12 Aug 2021) /tmp/idnits36356/draft-ietf-lpwan-schc-yang-data-model-08.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 5 instances of too long lines in the document, the longest one being 29 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 228: '...odel, each field MUST be identified th...' RFC 2119 keyword, line 232: '...for this protocol MUST derive from the...' RFC 2119 keyword, line 410: '...t start from 1 and MUST be contiguous....' RFC 2119 keyword, line 563: '...rk for a specific direction, they MUST...' RFC 2119 keyword, line 565: '...s, but bidirectional MUST NOT be used....' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1256 has weird spacing: '...osition uin...' == Line 1260 has weird spacing: '...osition uin...' == Line 1264 has weird spacing: '...osition uin...' -- The document date (6 May 2022) is 8 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 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: 7 November 2022 Institut MINES TELECOM; IMT Atlantique 6 6 May 2022 8 Data Model for Static Context Header Compression (SCHC) 9 draft-ietf-lpwan-schc-yang-data-model-08 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 7 November 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 4 52 2.2. Identifier generation . . . . . . . . . . . . . . . . . . 4 53 2.3. Field Identifier . . . . . . . . . . . . . . . . . . . . 5 54 2.4. Field length . . . . . . . . . . . . . . . . . . . . . . 7 55 2.5. Field position . . . . . . . . . . . . . . . . . . . . . 8 56 2.6. Direction Indicator . . . . . . . . . . . . . . . . . . . 8 57 2.7. Target Value . . . . . . . . . . . . . . . . . . . . . . 10 58 2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10 59 2.8.1. Matching Operator arguments . . . . . . . . . . . . . 12 60 2.9. Compression Decompression Actions . . . . . . . . . . . . 12 61 2.9.1. Compression Decompression Action arguments . . . . . 13 62 2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 13 63 2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 13 64 2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 14 65 2.10.3. Last fragment format . . . . . . . . . . . . . . . . 15 66 2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 17 67 2.10.5. Fragmentation Parameters . . . . . . . . . . . . . . 18 68 2.10.6. Layer 2 parameters . . . . . . . . . . . . . . . . . 19 69 3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 19 70 3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 21 71 3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 24 72 3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 27 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 29 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 76 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 29 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 51 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 80 1. Introduction 82 SCHC is a compression and fragmentation mechanism for constrained 83 networks defined in [RFC8724]. It is based on a static context 84 shared by two entities at the boundary of the constrained network. 85 [RFC8724] provides a non formal representation of the rules used 86 either for compression/decompression (or C/D) or fragmentation/ 87 reassembly (or F/R). The goal of this document is to formalize the 88 description of the rules to offer: 90 * the same definition on both ends, even if the internal 91 representation is different. 93 * an update of the other end to set up some specific values (e.g. 94 IPv6 prefix, Destination address,...) 96 * ... 98 This document defines a YANG module to represent both compression and 99 fragmentation rules, which leads to common representation for values 100 for all the rules elements. 102 2. SCHC rules 104 SCHC is a compression and fragmentation mechanism for constrained 105 networks defined in [RFC8724]. It is based on a static context 106 shared by two entities at the boundary of the constrained network. 107 [RFC8724] provides a non formal representation of the rules used 108 either for compression/decompression (or C/D) or fragmentation/ 109 reassembly (or F/R). The goal of this document is to formalize the 110 description of the rules to offer: 112 * the same definition on both ends, even if the internal 113 representation is different. 115 * an update of the other end to set up some specific values (e.g. 116 IPv6 prefix, Destination address,...) 118 * ... 120 This document defines a YANG module to represent both compression and 121 fragmentation rules, which leads to common representation for values 122 for all the rules elements. 124 SCHC compression is generic, the main mechanism does not refer to a 125 specific protocol. Any header field is abstracted through an ID, a 126 position, a direction, and a value that can be a numerical value or a 127 string. [RFC8724] and [RFC8824] specify fields for IPv6, UDP, CoAP 128 and OSCORE. 130 SCHC fragmentation requires a set of common parameters that are 131 included in a rule. These parameters are defined in [RFC8724]. 133 The YANG model allows to select the compression or the fragmentation 134 using the feature command. 136 feature compression { 137 description 138 "SCHC compression capabilities are taken into account"; 139 } 141 feature fragmentation { 142 description 143 "SCHC fragmentation capabilities are taken into account"; 144 } 146 Figure 1: Feature for compression and fragmentation. 148 2.1. Compression Rules 150 [RFC8724] proposes a non formal representation of the compression 151 rule. A compression context for a device is composed of a set of 152 rules. Each rule contains information to describe a specific field 153 in the header to be compressed. 155 +-----------------------------------------------------------------+ 156 | Rule N | 157 +-----------------------------------------------------------------+| 158 | Rule i || 159 +-----------------------------------------------------------------+|| 160 | (FID) Rule 1 ||| 161 |+-------+--+--+--+------------+-----------------+---------------+||| 162 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 163 |+-------+--+--+--+------------+-----------------+---------------+||| 164 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 165 |+-------+--+--+--+------------+-----------------+---------------+||| 166 ||... |..|..|..| ... | ... | ... |||| 167 |+-------+--+--+--+------------+-----------------+---------------+||/ 168 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 169 |+-------+--+--+--+------------+-----------------+---------------+|/ 170 | | 171 \-----------------------------------------------------------------/ 173 Figure 2: Compression Decompression Context 175 2.2. Identifier generation 177 Identifier used in the SCHC YANG Data Model are from the identityref 178 statement to ensure to be globally unique and be easily augmented if 179 needed. The principle to define a new type based on a group of 180 identityref is the following: 182 * define a main identity ending with the keyword base-type. 184 * derive all the identities used in the Data Model from this base 185 type. 187 * create a typedef from this base type. 189 The example (Figure 3) shows how an identityref is created for RCS 190 algorithms used during SCHC fragmentation. 192 // -- RCS algorithm types 194 identity rcs-algorithm-base-type { 195 description 196 "Identify which algorithm is used to compute RCS. 197 The algorithm also defines the size of the RCS field."; 198 } 200 identity rcs-RFC8724 { 201 base rcs-algorithm-base-type; 202 description 203 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 204 } 206 typedef rcs-algorithm-type { 207 type identityref { 208 base rcs-algorithm-base-type; 209 } 210 description 211 "type used in rules."; 212 } 214 Figure 3: Principle to define a type based on identityref. 216 2.3. Field Identifier 218 In the process of compression, the headers of the original packet are 219 first parsed to create a list of fields. This list of fields is 220 matched against the rules to find the appropriate rule and apply 221 compression. [RFC8724] does not state how the field ID value is 222 constructed. In examples, identification is done through a string 223 indexed by the protocol name (e.g. IPv6.version, CoAP.version,...). 225 The current YANG Data Model includes fields definitions found in 226 [RFC8724], [RFC8824]. 228 Using the YANG model, each field MUST be identified through a global 229 YANG identityref. A YANG field ID for the protocol always derives 230 from the fid-base-type. Then an identity for each protocol is 231 specified using the naming convention fid-<>-base- 232 type. All possible fields for this protocol MUST derive from the 233 protocol identity. The naming convention is "fid" followed by the 234 protocol name and the field name. If a field has to be divided into 235 sub-fields, the field identity serves as a base. 237 The full field-id definition is found in Section 7. The example 238 Figure 4 gives the first field ID definitions. A type is defined for 239 IPv6 protocol, and each field is based on it. Note that the DiffServ 240 bits derives from the Traffic Class identity. 242 identity fid-base-type { 243 description 244 "Field ID base type for all fields"; 245 } 247 identity fid-ipv6-base-type { 248 base fid-base-type; 249 description 250 "Field ID base type for IPv6 headers described in RFC 8200"; 251 } 253 identity fid-ipv6-version { 254 base fid-ipv6-base-type; 255 description 256 "IPv6 version field from RFC8200"; 257 } 259 identity fid-ipv6-trafficclass { 260 base fid-ipv6-base-type; 261 description 262 "IPv6 Traffic Class field from RFC8200"; 263 } 265 identity fid-ipv6-trafficclass-ds { 266 base fid-ipv6-trafficclass; 267 description 268 "IPv6 Traffic Class field from RFC8200, 269 DiffServ field from RFC3168"; 270 } 271 ... 273 Figure 4: Definition of identityref for field IDs 275 The type associated to this identity is fid-type (cf. Figure 5) 276 typedef fid-type { 277 type identityref { 278 base fid-base-type; 279 } 280 description 281 "Field ID generic type."; 282 } 284 Figure 5: Type definition for field IDs 286 2.4. Field length 288 Field length is either an integer giving the size of a field in bits 289 or a specific function. [RFC8724] defines the "var" function which 290 allows variable length fields (whose length is expressed in bytes) 291 and [RFC8824] defines the "tkl" function for managing the CoAP Token 292 length field. 294 The naming convention is "fl" followed by the function name. 296 identity fl-base-type { 297 description 298 "Used to extend field length functions."; 299 } 301 identity fl-variable { 302 base fl-base-type; 303 description 304 "Residue length in Byte is sent as defined 305 for CoAP in RFC 8824 (cf. 5.3)."; 306 } 308 identity fl-token-length { 309 base fl-base-type; 310 description 311 "Residue length in Byte is sent as defined 312 for CoAP in RFC 8824 (cf. 4.5)."; 313 } 315 Figure 6: Definition of identityref for Field Length 317 The field length function can be defined as an identityref as shown 318 in Figure 6. 320 Therefore, the type for field length is a union between an integer 321 giving in bits the size of the length and the identityref (cf. 322 Figure 7). 324 typedef fl-type { 325 type union { 326 type int64; /* positive integer, expressing length in bits */ 327 type identityref { /* function */ 328 base fl-base-type; 329 } 330 } 331 description 332 "Field length either a positive integer expressing the size in 333 bits or a function defined through an identityref."; 334 } 336 Figure 7: Type definition for field Length 338 2.5. Field position 340 Field position is a positive integer which gives the position of a 341 field, the default value is 1, and incremented at each repetition. 342 value 0 indicates that the position is not important and is not 343 considered during the rule selection process. 345 Field position is a positive integer. The type is an uint8. 347 2.6. Direction Indicator 349 The Direction Indicator (di) is used to tell if a field appears in 350 both direction (Bi) or only uplink (Up) or Downlink (Dw). 352 identity di-base-type { 353 description 354 "Used to extend direction indicators."; 355 } 357 identity di-bidirectional { 358 base di-base-type; 359 description 360 "Direction Indication of bidirectionality in 361 RFC 8724 (cf. 7.1)."; 362 } 364 identity di-up { 365 base di-base-type; 366 description 367 "Direction Indication of uplink defined in 368 RFC 8724 (cf. 7.1)."; 369 } 371 identity di-down { 372 base di-base-type; 373 description 374 "Direction Indication of downlink defined in 375 RFC 8724 (cf. 7.1)."; 376 } 378 Figure 8: Definition of identityref for direction indicators 380 Figure 8 gives the identityref for Direction Indicators. The naming 381 convention is "di" followed by the Direction Indicator name. 383 The type is "di-type" (cf. Figure 9). 385 typedef di-type { 386 type identityref { 387 base di-base-type; 388 } 389 description 390 "Direction in LPWAN network, up when emitted by the device, 391 down when received by the device, bi when emitted or 392 received by the device."; 393 } 395 Figure 9: Type definition for direction indicators 397 2.7. Target Value 399 The Target Value is a list of binary sequences of any length, aligned 400 to the left. Figure 10 shows the definition of a single element of a 401 Target Value. In the rule, the structure will be used as a list, 402 with position as a key. The highest position value is used to 403 compute the size of the index sent in residue for the match-mapping 404 CDA. The position allows to specify several values: 406 * For Equal and LSB, Target Value contains a single element. 407 Therefore, the position is set to 0. 409 * For match-mapping, Target Value can contain several elements. 410 Position values must start from 1 and MUST be contiguous. 412 grouping tv-struct { 413 description 414 "Defines the target value element. Always a binary type, strings 415 must be converted to binary. field-id allows the conversion 416 to the appropriate type."; 417 leaf value { 418 type binary; 419 description 420 "Target Value"; 421 } 422 leaf position { 423 type uint16; 424 description 425 "If only one element, position is 0. Otherwise, position is the 426 the order in the matching list, starting at 1."; 427 } 428 } 430 Figure 10: Definition of target value 432 2.8. Matching Operator 434 Matching Operator (MO) is a function applied between a field value 435 provided by the parsed header and the target value. [RFC8724] 436 defines 4 MO as listed in Figure 11. 438 identity mo-base-type { 439 description 440 "Used to extend Matching Operators with SID values"; 441 } 443 identity mo-equal { 444 base mo-base-type; 445 description 446 "Equal MO as defined in RFC 8724 (cf. 7.3)"; 447 } 449 identity mo-ignore { 450 base mo-base-type; 451 description 452 "Ignore MO as defined in RFC 8724 (cf. 7.3)"; 453 } 455 identity mo-msb { 456 base mo-base-type; 457 description 458 "MSB MO as defined in RFC 8724 (cf. 7.3)"; 459 } 461 identity mo-match-mapping { 462 base mo-base-type; 463 description 464 "match-mapping MO as defined in RFC 8724 (cf. 7.3)"; 465 } 467 Figure 11: Definition of identityref for Matching Operator 469 The naming convention is "mo" followed by the MO name. 471 The type is "mo-type" (cf. Figure 12) 473 typedef mo-type { 474 type identityref { 475 base mo-base-type; 476 } 477 description 478 "Matching Operator (MO) to compare fields values with 479 target values"; 480 } 482 Figure 12: Type definition for Matching Operator 484 2.8.1. Matching Operator arguments 486 They are viewed as a list, built with a tv-struct (see chapter 487 Section 2.7). 489 2.9. Compression Decompression Actions 491 Compression Decompression Action (CDA) identifies the function to use 492 for compression or decompression. [RFC8724] defines 6 CDA. 494 Figure 14 shows some CDA definition, the full definition is in 495 Section 7. 497 identity cda-base-type { 498 description 499 "Compression Decompression Actions."; 500 } 502 identity cda-not-sent { 503 base cda-base-type; 504 description 505 "not-sent CDA as defined in RFC 8724 (cf. 7.4)."; 506 } 508 identity cda-value-sent { 509 base cda-base-type; 510 description 511 "value-sent CDA as defined in RFC 8724 (cf. 7.4)."; 512 } 514 identity cda-lsb { 515 base cda-base-type; 516 description 517 "LSB CDA as defined in RFC 8724 (cf. 7.4)."; 518 } 520 identity cda-mapping-sent { 521 base cda-base-type; 522 description 523 "mapping-sent CDA as defined in RFC 8724 (cf. 7.4)."; 524 } 526 identity cda-compute { 527 base cda-base-type; 528 description 529 "compute-* CDA as defined in RFC 8724 (cf. 7.4)"; 530 } 531 .... 533 Figure 13: Definition of identityref for Compresion Decompression 534 Action 536 The naming convention is "cda" followed by the CDA name. 538 typedef cda-type { 539 type identityref { 540 base cda-base-type; 541 } 542 description 543 "Compression Decompression Action to compression or 544 decompress a field."; 545 } 547 Figure 14: Type definition for Compresion Decompression Action 549 2.9.1. Compression Decompression Action arguments 551 Currently no CDA requires arguments, but in the future some CDA may 552 require one or several arguments. They are viewed as a list, of 553 target-value type. 555 2.10. Fragmentation rule 557 Fragmentation is optional in the data model and depends on the 558 presence of the "fragmentation" feature. 560 Most of the fragmentation parameters are listed in Annex D of 561 [RFC8724]. 563 Since fragmentation rules work for a specific direction, they MUST 564 contain a mandatory direction indicator. The type is the same as the 565 one used in compression entries, but bidirectional MUST NOT be used. 567 2.10.1. Fragmentation mode 569 [RFC8724] defines 3 fragmentation modes: 571 * No Ack: this mode is unidirectionnal, no acknowledgment is sent 572 back. 574 * Ack Always: each fragmentation window must be explicitly 575 acknowledged before going to the next. 577 * Ack on Error: A window is acknowledged only when the receiver 578 detects some missing fragments. 580 Figure 15 shows the definition for identifiers from these three 581 modes. 583 identity fragmentation-mode-base-type { 584 description 585 "fragmentation mode."; 586 } 588 identity fragmentation-mode-no-ack { 589 base fragmentation-mode-base-type; 590 description 591 "No-ACK of RFC8724."; 592 } 594 identity fragmentation-mode-ack-always { 595 base fragmentation-mode-base-type; 596 description 597 "ACK-Always of RFC8724."; 598 } 600 identity fragmentation-mode-ack-on-error { 601 base fragmentation-mode-base-type; 602 description 603 "ACK-on-Error of RFC8724."; 604 } 606 typedef fragmentation-mode-type { 607 type identityref { 608 base fragmentation-mode-base-type; 609 } 610 description 611 "type used in rules"; 612 } 614 Figure 15: Definition of fragmentation mode identifer 616 The naming convention is "fragmentation-mode" followed by the 617 fragmentation mode name. 619 2.10.2. Fragmentation Header 621 A data fragment header, starting with the rule ID can be sent on the 622 fragmentation direction. The SCHC header may be composed of (cf. 623 Figure 16): 625 * a Datagram Tag (Dtag) identifying the datagram being fragmented if 626 the fragmentation applies concurrently on several datagrams. This 627 field in optional and its length is defined by the rule. 629 * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack- 630 Always, its size is 1. In Ack-on-Error, it depends on the rule. 631 This field is not needed in No-Ack mode. 633 * a Fragment Compressed Number (FCN) indicating the fragment/tile 634 position on the window. This field is mandatory on all modes 635 defined in [RFC8724], its size is defined by the rule. 637 |-- SCHC Fragment Header ----| 638 |-- T --|-M-|-- N --| 639 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 640 | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed) 641 +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ 643 Figure 16: Data fragment header from RFC8724 645 2.10.3. Last fragment format 647 The last fragment of a datagram is sent with an RCS (Reassembly Check 648 Sequence) field to detect residual transmission error and possible 649 losses in the last window. [RFC8724] defines a single algorithm 650 based on Ethernet CRC computation. The identity of the RCS algorithm 651 is shown in Figure 17. 653 identity rcs-algorithm-base-type { 654 description 655 "Identify which algorithm is used to compute RCS. 656 The algorithm also defines the size of the RCS field."; 657 } 659 identity rcs-RFC8724 { 660 base rcs-algorithm-base-type; 661 description 662 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 663 } 665 typedef rcs-algorithm-type { 666 type identityref { 667 base rcs-algorithm-base-type; 668 } 669 description 670 "type used in rules."; 671 } 673 Figure 17: type definition for RCS 675 The naming convention is "rcs" followed by the algorithm name. 677 For Ack-on-Error mode, the All-1 fragment may just contain the RCS or 678 can include a tile. The parameters defined in Figure 18 allows to 679 define the behavior: 681 * all1-data-no: the last fragment contains no data, just the RCS 683 * all1-data-yes: the last fragment includes a single tile and the 684 RCS 686 * all1-data-sender-choice: the last fragment may or may not contain 687 a single tile. The receiver can detect if a tile is present. 689 identity all1-data-base-type { 690 description 691 "Type to define when to send an Acknowledgment message."; 692 } 694 identity all1-data-no { 695 base all1-data-base-type; 696 description 697 "All1 contains no tiles."; 698 } 700 identity all1-data-yes { 701 base all1-data-base-type; 702 description 703 "All1 MUST contain a tile."; 704 } 706 identity all1-data-sender-choice { 707 base all1-data-base-type; 708 description 709 "Fragmentation process chooses to send tiles or not in all1."; 710 } 712 typedef all1-data-type { 713 type identityref { 714 base all1-data-base-type; 715 } 716 description 717 "Type used in rules."; 718 } 720 Figure 18: type definition for RCS 722 The naming convention is "all1-data" followed by the behavior 723 identifier. 725 2.10.4. Acknowledgment behavior 727 The acknowledgment fragment header goes in the opposite direction of 728 data. The header is composed of (see Figure 19): 730 * a Dtag (if present). 732 * a mandatory window as in the data fragment. 734 * a C bit giving the status of RCS validation. In case of failure, 735 a bitmap follows, indicating the received tile. 737 |--- SCHC ACK Header ----| 738 |-- T --|-M-| 1 | 739 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 740 | RuleID | DTag | W |C=1| padding as needed (success) 741 +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 743 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 744 | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 745 +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 747 Figure 19: Acknowledgment fragment header for RFC8724 749 For Ack-on-Error, SCHC defines when an acknowledgment can be sent. 750 This can be at any time defined by the layer 2, at the end of a 751 window (FCN All-0) or as a response to receiving the last fragment 752 (FCN All-1). The following identifiers (cf. Figure 20) define the 753 acknowledgment behavior. 755 identity ack-behavior-base-type { 756 description 757 "Define when to send an Acknowledgment ."; 758 } 760 identity ack-behavior-after-All0 { 761 base ack-behavior-base-type; 762 description 763 "Fragmentation expects Ack after sending All0 fragment."; 764 } 766 identity ack-behavior-after-All1 { 767 base ack-behavior-base-type; 768 description 769 "Fragmentation expects Ack after sending All1 fragment."; 770 } 772 identity ack-behavior-by-layer2 { 773 base ack-behavior-base-type; 774 description 775 "Layer 2 defines when to send an Ack."; 776 } 778 typedef ack-behavior-type { 779 type identityref { 780 base ack-behavior-base-type; 781 } 782 description 783 "Type used in rules."; 784 } 786 Figure 20: bitmap generation behavior 788 The naming convention is "ack-behavior" followed by the algorithm 789 name. 791 2.10.5. Fragmentation Parameters 793 The state machine requires some common values to handle 794 fragmentation: 796 * retransmission-timer expresses, in seconds, the duration before 797 sending an ack request (cf. section 8.2.2.4. of [RFC8724]). If 798 specified, value must be higher or equal to 1. 800 * inactivity-timer expresses, in seconds, the duration before 801 aborting a fragmentation session (cf. section 8.2.2.4. of 802 [RFC8724]). The value 0 explicitly indicates that this timer is 803 disabled. 805 * max-ack-requests expresses the number of attempts before aborting 806 (cf. section 8.2.2.4. of [RFC8724]). 808 * maximum-packet-size rexpresses, in bytes, the larger packet size 809 that can be reassembled. 811 They are defined as unsigned integers, see Section 7. 813 2.10.6. Layer 2 parameters 815 The data model includes two parameters needed for fragmentation: 817 * l2-word-size: [RFC8724] base fragmentation on a layer 2 word which 818 can be of any length. The default value is 8 and correspond to 819 the default value for byte aligned layer 2. A value of 1 will 820 indicate that there is no alignment and no need for padding. 822 * maximum-packet-size: defines the maximum size of a uncompressed 823 datagram. By default, the value is set to 1280 bytes. 825 They are defined as unsigned integer, see Section 7. 827 3. Rule definition 829 A rule is idenfied by a unique rule identifier (rule ID) comprising 830 both a Rule ID value and a Rule ID length. The YANG grouping rule- 831 id-type defines the structure used to represent a rule ID. A length 832 of 0 is allowed to represent an implicit rule. 834 Three types of rules are defined in [RFC8724]: 836 * Compression: a compression rule is associated with the rule ID. 838 * No compression: this identifies the default rule used to send a 839 packet in extenso when no compression rule was found (see 840 [RFC8724] section 6). 842 * Fragmentation: fragmentation parameters are associated with the 843 rule ID. Fragmentation is optional and feature "fragmentation" 844 should be set. 846 grouping rule-id-type { 847 leaf rule-id-value { 848 type uint32; 849 description 850 "Rule ID value, this value must be unique, considering its 851 length."; 852 } 853 leaf rule-id-length { 854 type uint8 { 855 range "0..32"; 856 } 857 description 858 "Rule ID length, in bits. The value 0 is for implicit rules."; 859 } 860 description 861 "A rule ID is composed of a value and a length, expressed in 862 bits."; 863 } 865 // SCHC table for a specific device. 867 container schc { 868 list rule { 869 key "rule-id-value rule-id-length"; 870 uses rule-id-type; 871 choice nature { 872 case fragmentation { 873 if-feature "fragmentation"; 874 uses fragmentation-content; 875 } 876 case compression { 877 if-feature "compression"; 878 uses compression-content; 879 } 880 case no-compression { 881 description 882 "RFC8724 requires a rule for uncompressed headers."; 883 } 884 description 885 "A rule is for compression, for no-compression or for 886 fragmentation."; 887 } 888 description 889 "Set of rules compression, no compression or fragmentation 890 rules identified by their rule-id."; 891 } 892 description 893 "a SCHC set of rules is composed of a list of rules which are 894 used for compression, no-compression or fragmentation."; 895 } 896 } 898 Figure 21: Definition of a SCHC Context 900 To access a specific rule, the rule ID length and value are used as a 901 key. The rule is either a compression or a fragmentation rule. 903 3.1. Compression rule 905 A compression rule is composed of entries describing its processing 906 (cf. Figure 22). An entry contains all the information defined in 907 Figure 2 with the types defined above. 909 The compression rule described Figure 2 is defined by compression- 910 content. It defines a list of compression-rule-entry, indexed by 911 their field id, position and direction. The compression-rule-entry 912 element represent a line of the table Figure 2. Their type reflects 913 the identifier types defined in Section 2.1 915 Some checks are performed on the values: 917 * target value must be present for MO different from ignore. 919 * when MSB MO is specified, the matching-operator-value must be 920 present 922 grouping compression-rule-entry { 923 description 924 "These entries defines a compression entry (i.e. a line) 925 as defined in RFC 8724. 927 +-------+--+--+--+------------+-----------------+---------------+ 928 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 929 +-------+--+--+--+------------+-----------------+---------------+ 931 An entry in a compression rule is composed of 7 elements: 932 - Field ID: The header field to be compressed. The content is a 933 YANG identifer. 934 - Field Length : either a positive integer of a function defined 935 as a YANG id. 936 - Field Position: a positive (and possibly equal to 0) integer. 937 - Direction Indicator: a YANG identifier giving the direction. 938 - Target value: a value against which the header Field is 939 compared. 940 - Matching Operator: a YANG id giving the operation, parameters 941 may be associated to that operator. 943 - Comp./Decomp. Action: A YANG id giving the compression or 944 decompression action, parameters may be associated to that 945 action. 946 "; 947 leaf field-id { 948 type schc:fid-type; 949 mandatory true; 950 description 951 "Field ID, identify a field in the header with a YANG 952 referenceid."; 953 } 954 leaf field-length { 955 type schc:fl-type; 956 mandatory true; 957 description 958 "Field Length, expressed in number of bits or through a function defined as a 959 YANG referenceid."; 960 } 961 leaf field-position { 962 type uint8; 963 mandatory true; 964 description 965 "Field position in the header is an integer. Position 1 matches 966 the first occurence of a field in the header, while incremented 967 position values match subsequent occurences. 968 Position 0 means that this entry matches a field irrespective 969 of its position of occurence in the header. 970 Be aware that the decompressed header may have position-0 971 fields ordered differently than they appeared in the original 972 packet."; 973 } 974 leaf direction-indicator { 975 type schc:di-type; 976 mandatory true; 977 description 978 "Direction Indicator, a YANG referenceid to say if the packet 979 is bidirectional, up or down"; 980 } 981 list target-value { 982 key "position"; 983 uses tv-struct; 984 description 985 "A list of value to compare with the header field value. 986 If target value is a singleton, position must be 0. 987 For use as a matching list for the mo-match-mapping matching 988 operator, positions should take consecutive values starting 989 from 1."; 990 } 991 leaf matching-operator { 992 type schc:mo-type; 993 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 994 error-message 995 "mo-equal, mo-msb and mo-match-mapping need target-value"; 996 description 997 "target-value is not required for mo-ignore"; 998 } 999 must "not (derived-from-or-self(., 'mo-msb')) or 1000 ../matching-operator-value" { 1001 error-message "mo-msb requires length value"; 1002 } 1003 mandatory true; 1004 description 1005 "MO: Matching Operator"; 1006 } 1007 list matching-operator-value { 1008 key "position"; 1009 uses tv-struct; 1010 description 1011 "Matching Operator Arguments, based on TV structure to allow 1012 several arguments. 1013 In RFC 8724, only the MSB matching operator needs arguments (a single argument, which is the 1014 number of most significant bits to be matched)"; 1015 } 1016 leaf comp-decomp-action { 1017 type schc:cda-type; 1018 mandatory true; 1019 description 1020 "CDA: Compression Decompression Action."; 1021 } 1022 list comp-decomp-action-value { 1023 key "position"; 1024 uses tv-struct; 1025 description 1026 "CDA arguments, based on a TV structure, in order to allow for 1027 several arguments. The CDAs specified in RFC 8724 require no 1028 argument."; 1029 } 1030 } 1032 grouping compression-content { 1033 list entry { 1034 key "field-id field-position direction-indicator"; 1035 uses compression-rule-entry; 1036 description 1037 "A compression rule is a list of rule entries, each describing 1038 a header field. An entry is identifed through a field-id, 1039 its position in the packet and its direction."; 1040 } 1041 description 1042 "Define a compression rule composed of a list of entries."; 1043 } 1045 Figure 22: Definition of a compression entry 1047 3.2. Fragmentation rule 1049 A Fragmentation rule is composed of entries describing the protocol 1050 behavior. Some on them are numerical entries, others are identifiers 1051 defined in Section 2.10. 1053 The definition of a Fragmentation rule is divided into three sub- 1054 parts: 1056 * parameters such as the fragmentation-mode, the l2-word-size and 1057 the direction. Since Fragmentation rules are always defined for a 1058 specific direction, the value must be either di-up or di-down (di- 1059 bidirectional is not allowed). 1061 * parameters defining the Fragmentation header format (dtag-size, 1062 w-size, fcn-size and rcs-algorithm). 1064 * Protocol parameters for timers (inactivity-timer, retransmission- 1065 timer) or behavior (maximum-packet-size, max-interleaved-frames, 1066 max-ack-requests). If these parameters are specific to a single 1067 fragmentation mode, they are grouped in a structure dedicated to 1068 that Fragmentation mode. If some parameters can be found in 1069 several modes, typically ACK-Always and ACK-on-Error, they are 1070 defined in a common part and a when statement indicates which 1071 modes are allowed. 1073 grouping fragmentation-content { 1074 description 1075 "This grouping defines the fragmentation parameters for 1076 all the modes (No-Ack, Ack-Always and Ack-on-Error) specified in 1077 RFC 8724."; 1078 leaf fragmentation-mode { 1079 type schc:fragmentation-mode-type; 1080 mandatory true; 1081 description 1082 "which fragmentation mode is used (noAck, AckAlways, 1083 AckonError)"; 1084 } 1085 leaf l2-word-size { 1086 type uint8; 1087 default "8"; 1088 description 1089 "Size, in bits, of the layer 2 word"; 1090 } 1091 leaf direction { 1092 type schc:di-type; 1093 must "derived-from-or-self(., 'di-up') or 1094 derived-from-or-self(., 'di-down')" { 1095 error-message 1096 "direction for fragmentation rules are up or down."; 1097 } 1098 mandatory true; 1099 description 1100 "Should be up or down, bidirectionnal is forbiden."; 1101 } 1102 // SCHC Frag header format 1103 leaf dtag-size { 1104 type uint8; 1105 default "0"; 1106 description 1107 "Size, in bits, of the DTag field (T variable from RFC8724)."; 1108 } 1109 leaf w-size { 1110 when "derived-from(../fragmentation-mode, 1111 'fragmentation-mode-ack-on-error') 1112 or 1113 derived-from(../fragmentation-mode, 1114 'fragmentation-mode-ack-always') "; 1115 type uint8; 1116 description 1117 "Size, in bits, of the window field (M variable from RFC8724)."; 1118 } 1119 leaf fcn-size { 1120 type uint8; 1121 mandatory true; 1122 description 1123 "Size, in bits, of the FCN field (N variable from RFC8724)."; 1124 } 1125 leaf rcs-algorithm { 1126 type rcs-algorithm-type; 1127 default "schc:rcs-RFC8724"; 1128 description 1129 "Algorithm used for RCS. The algorithm specifies the RCS size"; 1130 } 1131 // SCHC fragmentation protocol parameters 1132 leaf maximum-packet-size { 1133 type uint16; 1134 default "1280"; 1135 description 1136 "When decompression is done, packet size must not 1137 strictly exceed this limit, expressed in bytes."; 1138 } 1139 leaf window-size { 1140 type uint16; 1141 description 1142 "By default, if not specified 2^w-size - 1. Should not exceed 1143 this value. Possible FCN values are between 0 and 1144 window-size - 1."; 1145 } 1146 leaf max-interleaved-frames { 1147 type uint8; 1148 default "1"; 1149 description 1150 "Maximum of simultaneously fragmented frames. Maximum value is 1151 2^dtag-size. All DTAG values can be used, but at most 1152 max-interleaved-frames must be active at any time."; 1153 } 1154 leaf inactivity-timer { 1155 type uint64; 1156 description 1157 "Duration is seconds of the inactivity timer, 0 indicates 1158 that the timer is disabled."; 1159 } 1160 leaf retransmission-timer { 1161 when "derived-from(../fragmentation-mode, 1162 'fragmentation-mode-ack-on-error') 1163 or 1164 derived-from(../fragmentation-mode, 1165 'fragmentation-mode-ack-always') "; 1166 type uint64 { 1167 range "1..max"; 1168 } 1169 description 1170 "Duration in seconds of the retransmission timer."; 1171 } 1172 leaf max-ack-requests { 1173 when "derived-from(../fragmentation-mode, 1174 'fragmentation-mode-ack-on-error') 1175 or 1176 derived-from(../fragmentation-mode, 1177 'fragmentation-mode-ack-always') "; 1178 type uint8 { 1179 range "1..max"; 1180 } 1181 description 1182 "The maximum number of retries for a specific SCHC ACK."; 1184 } 1185 choice mode { 1186 case no-ack; 1187 case ack-always; 1188 case ack-on-error { 1189 leaf tile-size { 1190 when "derived-from(../fragmentation-mode, 1191 'fragmentation-mode-ack-on-error')"; 1192 type uint8; 1193 description 1194 "Size, in bits, of tiles. If not specified or set to 0, 1195 tiles fill the fragment."; 1196 } 1197 leaf tile-in-All1 { 1198 when "derived-from(../fragmentation-mode, 1199 'fragmentation-mode-ack-on-error')"; 1200 type schc:all1-data-type; 1201 description 1202 "Defines whether the sender and receiver expect a tile in 1203 All-1 fragments or not, or if it is left to the sender's 1204 choice."; 1205 } 1206 leaf ack-behavior { 1207 when "derived-from(../fragmentation-mode, 1208 'fragmentation-mode-ack-on-error')"; 1209 type schc:ack-behavior-type; 1210 description 1211 "Sender behavior to acknowledge, after All-0, All-1 or 1212 when the LPWAN allows it."; 1213 } 1214 } 1215 description 1216 "RFC 8724 defines 3 fragmentation modes."; 1217 } 1218 } 1220 3.3. YANG Tree 1221 module: ietf-schc 1222 +--rw schc 1223 +--rw rule* [rule-id-value rule-id-length] 1224 +--rw rule-id-value uint32 1225 +--rw rule-id-length uint8 1226 +--rw (nature)? 1227 +--:(fragmentation) {fragmentation}? 1228 | +--rw fragmentation-mode schc:fragmentation-mode-type 1229 | +--rw l2-word-size? uint8 1230 | +--rw direction schc:di-type 1231 | +--rw dtag-size? uint8 1232 | +--rw w-size? uint8 1233 | +--rw fcn-size uint8 1234 | +--rw rcs-algorithm? rcs-algorithm-type 1235 | +--rw maximum-packet-size? uint16 1236 | +--rw window-size? uint16 1237 | +--rw max-interleaved-frames? uint8 1238 | +--rw inactivity-timer? uint64 1239 | +--rw retransmission-timer? uint64 1240 | +--rw max-ack-requests? uint8 1241 | +--rw (mode)? 1242 | +--:(no-ack) 1243 | +--:(ack-always) 1244 | +--:(ack-on-error) 1245 | +--rw tile-size? uint8 1246 | +--rw tile-in-All1? schc:all1-data-type 1247 | +--rw ack-behavior? schc:ack-behavior-type 1248 +--:(compression) {compression}? 1249 | +--rw entry* [field-id field-position direction-indicator] 1250 | +--rw field-id schc:fid-type 1251 | +--rw field-length schc:fl-type 1252 | +--rw field-position uint8 1253 | +--rw direction-indicator schc:di-type 1254 | +--rw target-value* [position] 1255 | | +--rw value? binary 1256 | | +--rw position uint16 1257 | +--rw matching-operator schc:mo-type 1258 | +--rw matching-operator-value* [position] 1259 | | +--rw value? binary 1260 | | +--rw position uint16 1261 | +--rw comp-decomp-action schc:cda-type 1262 | +--rw comp-decomp-action-value* [position] 1263 | +--rw value? binary 1264 | +--rw position uint16 1265 +--:(no-compression) 1267 Figure 23 1269 4. IANA Considerations 1271 This document has no request to IANA. 1273 5. Security considerations 1275 This document does not have any more Security consideration than the 1276 ones already raised in [RFC8724] and [RFC8824]. 1278 6. Acknowledgements 1280 The authors would like to thank Dominique Barthel, Carsten Bormann, 1281 Alexander Pelov. 1283 7. YANG Module 1285 file ietf-schc@2022-02-15.yang 1286 module ietf-schc { 1287 yang-version 1.1; 1288 namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; 1289 prefix schc; 1291 organization 1292 "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; 1293 contact 1294 "WG Web: 1295 WG List: 1296 Editor: Laurent Toutain 1297 1298 Editor: Ana Minaburo 1299 "; 1300 description 1301 " 1302 Copyright (c) 2021 IETF Trust and the persons identified as 1303 authors of the code. All rights reserved. 1305 Redistribution and use in source and binary forms, with or 1306 without modification, is permitted pursuant to, and subject to 1307 the license terms contained in, the Simplified BSD License set 1308 forth in Section 4.c of the IETF Trust's Legal Provisions 1309 Relating to IETF Documents 1310 (https://trustee.ietf.org/license-info). 1312 This version of this YANG module is part of RFC XXXX 1313 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1314 for full legal notices. 1316 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1317 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1318 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1319 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1320 they appear in all capitals, as shown here. 1322 ***************************************************************** 1324 Generic Data model for Static Context Header Compression Rule for 1325 SCHC, based on RFC 8724 and RFC8824. Include compression, no 1326 compression and fragmentation rules. 1328 This module is a YANG model for SCHC rules (RFC 8724 and RFC8824). 1329 RFC 8724 describes compression rules in a abstract way through a 1330 table. 1332 |-----------------------------------------------------------------| 1333 | (FID) Rule 1 | 1334 |+-------+--+--+--+------------+-----------------+---------------+| 1335 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1336 |+-------+--+--+--+------------+-----------------+---------------+| 1337 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1338 |+-------+--+--+--+------------+-----------------+---------------+| 1339 ||... |..|..|..| ... | ... | ... || 1340 |+-------+--+--+--+------------+-----------------+---------------+| 1341 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| 1342 +-------+--+--+--+------------+-----------------+---------------+|| 1343 |-----------------------------------------------------------------| 1345 This module proposes a global data model that can be used for rule 1346 exchanges or modification. It proposes both the data model format 1347 and the global identifiers used to describe some operations in 1348 fields. 1349 This data model applies to both compression and fragmentation."; 1351 revision 2022-02-15 { 1352 description 1353 "Initial version from RFC XXXX "; 1354 reference 1355 "RFC XXX: Data Model for Static Context Header Compression 1356 (SCHC)"; 1357 } 1359 feature compression { 1360 description 1361 "SCHC compression capabilities are taken into account"; 1362 } 1364 feature fragmentation { 1365 description 1366 "SCHC fragmentation capabilities are taken into account"; 1367 } 1369 // ------------------------- 1370 // Field ID type definition 1371 //-------------------------- 1372 // generic value TV definition 1374 identity fid-base-type { 1375 description 1376 "Field ID base type for all fields"; 1377 } 1379 identity fid-ipv6-base-type { 1380 base fid-base-type; 1381 description 1382 "Field ID base type for IPv6 headers described in RFC 8200"; 1383 } 1385 identity fid-ipv6-version { 1386 base fid-ipv6-base-type; 1387 description 1388 "IPv6 version field from RFC8200"; 1389 } 1391 identity fid-ipv6-trafficclass { 1392 base fid-ipv6-base-type; 1393 description 1394 "IPv6 Traffic Class field from RFC8200"; 1395 } 1397 identity fid-ipv6-trafficclass-ds { 1398 base fid-ipv6-trafficclass; 1399 description 1400 "IPv6 Traffic Class field from RFC8200, 1401 DiffServ field from RFC3168"; 1402 } 1404 identity fid-ipv6-trafficclass-ecn { 1405 base fid-ipv6-trafficclass; 1406 description 1407 "IPv6 Traffic Class field from RFC8200, 1408 ECN field from RFC3168"; 1409 } 1411 identity fid-ipv6-flowlabel { 1412 base fid-ipv6-base-type; 1413 description 1414 "IPv6 Flow Label field from RFC8200"; 1415 } 1417 identity fid-ipv6-payloadlength { 1418 base fid-ipv6-base-type; 1419 description 1420 "IPv6 Payload Length field from RFC8200"; 1421 } 1423 identity fid-ipv6-nextheader { 1424 base fid-ipv6-base-type; 1425 description 1426 "IPv6 Next Header field from RFC8200"; 1427 } 1429 identity fid-ipv6-hoplimit { 1430 base fid-ipv6-base-type; 1431 description 1432 "IPv6 Next Header field from RFC8200"; 1433 } 1435 identity fid-ipv6-devprefix { 1436 base fid-ipv6-base-type; 1437 description 1438 "corresponds to either the source address or the destination 1439 address prefix of RFC 8200. Depending if it is 1440 respectively an uplink or a downlink message."; 1441 } 1443 identity fid-ipv6-deviid { 1444 base fid-ipv6-base-type; 1445 description 1446 "corresponds to either the source address or the destination 1447 address prefix of RFC 8200. Depending if it is respectively 1448 an uplink or a downlink message."; 1449 } 1451 identity fid-ipv6-appprefix { 1452 base fid-ipv6-base-type; 1453 description 1454 "corresponds to either the source address or the destination 1455 address prefix of RFC 8200. Depending if it is respectively 1456 a downlink or an uplink message."; 1457 } 1459 identity fid-ipv6-appiid { 1460 base fid-ipv6-base-type; 1461 description 1462 "corresponds to either the source address or the destination 1463 address prefix of RFC 8200. Depending if it is respectively 1464 a downlink or an uplink message."; 1465 } 1467 identity fid-udp-base-type { 1468 base fid-base-type; 1469 description 1470 "Field ID base type for UDP headers described in RFC 768"; 1471 } 1473 identity fid-udp-dev-port { 1474 base fid-udp-base-type; 1475 description 1476 "UDP source or destination port from RFC 768, if uplink or 1477 downlink communication, respectively."; 1478 } 1480 identity fid-udp-app-port { 1481 base fid-udp-base-type; 1482 description 1483 "UDP destination or source port from RFC 768, if uplink or 1484 downlink communication, respectively."; 1485 } 1487 identity fid-udp-length { 1488 base fid-udp-base-type; 1489 description 1490 "UDP length from RFC 768"; 1491 } 1493 identity fid-udp-checksum { 1494 base fid-udp-base-type; 1495 description 1496 "UDP length from RFC 768"; 1497 } 1499 identity fid-coap-base-type { 1500 base fid-base-type; 1501 description 1502 "Field ID base type for UDP headers described in RFC 7252"; 1503 } 1505 identity fid-coap-version { 1506 base fid-coap-base-type; 1507 description 1508 "CoAP version from RFC 7252"; 1510 } 1512 identity fid-coap-type { 1513 base fid-coap-base-type; 1514 description 1515 "CoAP type from RFC 7252"; 1516 } 1518 identity fid-coap-tkl { 1519 base fid-coap-base-type; 1520 description 1521 "CoAP token length from RFC 7252"; 1522 } 1524 identity fid-coap-code { 1525 base fid-coap-base-type; 1526 description 1527 "CoAP code from RFC 7252"; 1528 } 1530 identity fid-coap-code-class { 1531 base fid-coap-code; 1532 description 1533 "CoAP code class from RFC 7252"; 1534 } 1536 identity fid-coap-code-detail { 1537 base fid-coap-code; 1538 description 1539 "CoAP code detail from RFC 7252"; 1540 } 1542 identity fid-coap-mid { 1543 base fid-coap-base-type; 1544 description 1545 "CoAP message ID from RFC 7252"; 1546 } 1548 identity fid-coap-token { 1549 base fid-coap-base-type; 1550 description 1551 "CoAP token from RFC 7252"; 1552 } 1554 identity fid-coap-option-if-match { 1555 base fid-coap-base-type; 1556 description 1557 "CoAP option If-Match from RFC 7252"; 1559 } 1561 identity fid-coap-option-uri-host { 1562 base fid-coap-base-type; 1563 description 1564 "CoAP option URI-Host from RFC 7252"; 1565 } 1567 identity fid-coap-option-etag { 1568 base fid-coap-base-type; 1569 description 1570 "CoAP option Etag from RFC 7252"; 1571 } 1573 identity fid-coap-option-if-none-match { 1574 base fid-coap-base-type; 1575 description 1576 "CoAP option if-none-match from RFC 7252"; 1577 } 1579 identity fid-coap-option-observe { 1580 base fid-coap-base-type; 1581 description 1582 "CoAP option Observe from RFC 7641"; 1583 } 1585 identity fid-coap-option-uri-port { 1586 base fid-coap-base-type; 1587 description 1588 "CoAP option Uri-Port from RFC 7252"; 1589 } 1591 identity fid-coap-option-location-path { 1592 base fid-coap-base-type; 1593 description 1594 "CoAP option Location-Path from RFC 7252"; 1595 } 1597 identity fid-coap-option-uri-path { 1598 base fid-coap-base-type; 1599 description 1600 "CoAP option Uri-Path from RFC 7252"; 1601 } 1603 identity fid-coap-option-content-format { 1604 base fid-coap-base-type; 1605 description 1606 "CoAP option Content Format from RFC 7252"; 1608 } 1610 identity fid-coap-option-max-age { 1611 base fid-coap-base-type; 1612 description 1613 "CoAP option Max-Age from RFC 7252"; 1614 } 1616 identity fid-coap-option-uri-query { 1617 base fid-coap-base-type; 1618 description 1619 "CoAP option Uri-Query from RFC 7252"; 1620 } 1622 identity fid-coap-option-accept { 1623 base fid-coap-base-type; 1624 description 1625 "CoAP option Accept from RFC 7252"; 1626 } 1628 identity fid-coap-option-location-query { 1629 base fid-coap-base-type; 1630 description 1631 "CoAP option Location-Query from RFC 7252"; 1632 } 1634 identity fid-coap-option-block2 { 1635 base fid-coap-base-type; 1636 description 1637 "CoAP option Block2 from RFC 7959"; 1638 } 1640 identity fid-coap-option-block1 { 1641 base fid-coap-base-type; 1642 description 1643 "CoAP option Block1 from RFC 7959"; 1644 } 1646 identity fid-coap-option-size2 { 1647 base fid-coap-base-type; 1648 description 1649 "CoAP option size2 from RFC 7959"; 1650 } 1652 identity fid-coap-option-proxy-uri { 1653 base fid-coap-base-type; 1654 description 1655 "CoAP option Proxy-Uri from RFC 7252"; 1657 } 1659 identity fid-coap-option-proxy-scheme { 1660 base fid-coap-base-type; 1661 description 1662 "CoAP option Proxy-scheme from RFC 7252"; 1663 } 1665 identity fid-coap-option-size1 { 1666 base fid-coap-base-type; 1667 description 1668 "CoAP option Size1 from RFC 7252"; 1669 } 1671 identity fid-coap-option-no-response { 1672 base fid-coap-base-type; 1673 description 1674 "CoAP option No response from RFC 7967"; 1675 } 1677 identity fid-coap-option-oscore-flags { 1678 base fid-coap-base-type; 1679 description 1680 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1681 } 1683 identity fid-coap-option-oscore-piv { 1684 base fid-coap-base-type; 1685 description 1686 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1687 } 1689 identity fid-coap-option-oscore-kid { 1690 base fid-coap-base-type; 1691 description 1692 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1693 } 1695 identity fid-coap-option-oscore-kidctx { 1696 base fid-coap-base-type; 1697 description 1698 "CoAP option oscore flags (see RFC 8824, section 6.4)"; 1699 } 1701 //---------------------------------- 1702 // Field Length type definition 1703 //---------------------------------- 1704 identity fl-base-type { 1705 description 1706 "Used to extend field length functions."; 1707 } 1709 identity fl-variable { 1710 base fl-base-type; 1711 description 1712 "Residue length in Byte is sent as defined 1713 for CoAP in RFC 8824 (cf. 5.3)."; 1714 } 1716 identity fl-token-length { 1717 base fl-base-type; 1718 description 1719 "Residue length in Byte is sent as defined 1720 for CoAP in RFC 8824 (cf. 4.5)."; 1721 } 1723 //--------------------------------- 1724 // Direction Indicator type 1725 //--------------------------------- 1727 identity di-base-type { 1728 description 1729 "Used to extend direction indicators."; 1730 } 1732 identity di-bidirectional { 1733 base di-base-type; 1734 description 1735 "Direction Indication of bidirectionality in 1736 RFC 8724 (cf. 7.1)."; 1737 } 1739 identity di-up { 1740 base di-base-type; 1741 description 1742 "Direction Indication of uplink defined in 1743 RFC 8724 (cf. 7.1)."; 1744 } 1746 identity di-down { 1747 base di-base-type; 1748 description 1749 "Direction Indication of downlink defined in 1750 RFC 8724 (cf. 7.1)."; 1751 } 1752 //---------------------------------- 1753 // Matching Operator type definition 1754 //---------------------------------- 1756 identity mo-base-type { 1757 description 1758 "Used to extend Matching Operators with SID values"; 1759 } 1761 identity mo-equal { 1762 base mo-base-type; 1763 description 1764 "Equal MO as defined in RFC 8724 (cf. 7.3)"; 1765 } 1767 identity mo-ignore { 1768 base mo-base-type; 1769 description 1770 "Ignore MO as defined in RFC 8724 (cf. 7.3)"; 1771 } 1773 identity mo-msb { 1774 base mo-base-type; 1775 description 1776 "MSB MO as defined in RFC 8724 (cf. 7.3)"; 1777 } 1779 identity mo-match-mapping { 1780 base mo-base-type; 1781 description 1782 "match-mapping MO as defined in RFC 8724 (cf. 7.3)"; 1783 } 1785 //------------------------------ 1786 // CDA type definition 1787 //------------------------------ 1789 identity cda-base-type { 1790 description 1791 "Compression Decompression Actions."; 1792 } 1794 identity cda-not-sent { 1795 base cda-base-type; 1796 description 1797 "not-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1798 } 1799 identity cda-value-sent { 1800 base cda-base-type; 1801 description 1802 "value-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1803 } 1805 identity cda-lsb { 1806 base cda-base-type; 1807 description 1808 "LSB CDA as defined in RFC 8724 (cf. 7.4)."; 1809 } 1811 identity cda-mapping-sent { 1812 base cda-base-type; 1813 description 1814 "mapping-sent CDA as defined in RFC 8724 (cf. 7.4)."; 1815 } 1817 identity cda-compute { 1818 base cda-base-type; 1819 description 1820 "compute-length CDA as defined in RFC 8724 (cf. 7.4)"; 1821 } 1823 identity cda-deviid { 1824 base cda-base-type; 1825 description 1826 "deviid CDA as defined in RFC 8724 (cf. 7.4)"; 1827 } 1829 identity cda-appiid { 1830 base cda-base-type; 1831 description 1832 "appiid CDA as defined in RFC 8724 (cf. 7.4)"; 1833 } 1835 // -- type definition 1837 typedef fid-type { 1838 type identityref { 1839 base fid-base-type; 1840 } 1841 description 1842 "Field ID generic type."; 1843 } 1845 typedef fl-type { 1846 type union { 1847 type int64; /* positive integer, expressing length in bits */ 1848 type identityref { /* function */ 1849 base fl-base-type; 1850 } 1851 } 1852 description 1853 "Field length either a positive integer expressing the size in 1854 bits or a function defined through an identityref."; 1855 } 1857 typedef di-type { 1858 type identityref { 1859 base di-base-type; 1860 } 1861 description 1862 "Direction in LPWAN network, up when emitted by the device, 1863 down when received by the device, bi when emitted or 1864 received by the device."; 1865 } 1867 typedef mo-type { 1868 type identityref { 1869 base mo-base-type; 1870 } 1871 description 1872 "Matching Operator (MO) to compare fields values with 1873 target values"; 1874 } 1876 typedef cda-type { 1877 type identityref { 1878 base cda-base-type; 1879 } 1880 description 1881 "Compression Decompression Action to compression or 1882 decompress a field."; 1883 } 1885 // -- FRAGMENTATION TYPE 1886 // -- fragmentation modes 1888 identity fragmentation-mode-base-type { 1889 description 1890 "fragmentation mode."; 1891 } 1893 identity fragmentation-mode-no-ack { 1894 base fragmentation-mode-base-type; 1895 description 1896 "No-ACK of RFC8724."; 1897 } 1899 identity fragmentation-mode-ack-always { 1900 base fragmentation-mode-base-type; 1901 description 1902 "ACK-Always of RFC8724."; 1903 } 1905 identity fragmentation-mode-ack-on-error { 1906 base fragmentation-mode-base-type; 1907 description 1908 "ACK-on-Error of RFC8724."; 1909 } 1911 typedef fragmentation-mode-type { 1912 type identityref { 1913 base fragmentation-mode-base-type; 1914 } 1915 description 1916 "type used in rules"; 1917 } 1919 // -- Ack behavior 1921 identity ack-behavior-base-type { 1922 description 1923 "Define when to send an Acknowledgment ."; 1924 } 1926 identity ack-behavior-after-All0 { 1927 base ack-behavior-base-type; 1928 description 1929 "Fragmentation expects Ack after sending All0 fragment."; 1930 } 1932 identity ack-behavior-after-All1 { 1933 base ack-behavior-base-type; 1934 description 1935 "Fragmentation expects Ack after sending All1 fragment."; 1936 } 1938 identity ack-behavior-by-layer2 { 1939 base ack-behavior-base-type; 1940 description 1941 "Layer 2 defines when to send an Ack."; 1942 } 1943 typedef ack-behavior-type { 1944 type identityref { 1945 base ack-behavior-base-type; 1946 } 1947 description 1948 "Type used in rules."; 1949 } 1951 // -- All1 with data types 1953 identity all1-data-base-type { 1954 description 1955 "Type to define when to send an Acknowledgment message."; 1956 } 1958 identity all1-data-no { 1959 base all1-data-base-type; 1960 description 1961 "All1 contains no tiles."; 1962 } 1964 identity all1-data-yes { 1965 base all1-data-base-type; 1966 description 1967 "All1 MUST contain a tile."; 1968 } 1970 identity all1-data-sender-choice { 1971 base all1-data-base-type; 1972 description 1973 "Fragmentation process chooses to send tiles or not in all1."; 1974 } 1976 typedef all1-data-type { 1977 type identityref { 1978 base all1-data-base-type; 1979 } 1980 description 1981 "Type used in rules."; 1982 } 1984 // -- RCS algorithm types 1986 identity rcs-algorithm-base-type { 1987 description 1988 "Identify which algorithm is used to compute RCS. 1989 The algorithm also defines the size of the RCS field."; 1990 } 1991 identity rcs-RFC8724 { 1992 base rcs-algorithm-base-type; 1993 description 1994 "CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long"; 1995 } 1997 typedef rcs-algorithm-type { 1998 type identityref { 1999 base rcs-algorithm-base-type; 2000 } 2001 description 2002 "type used in rules."; 2003 } 2005 // -------- RULE ENTRY DEFINITION ------------ 2007 grouping tv-struct { 2008 description 2009 "Defines the target value element. Always a binary type, strings 2010 must be converted to binary. field-id allows the conversion 2011 to the appropriate type."; 2012 leaf value { 2013 type binary; 2014 description 2015 "Target Value"; 2016 } 2017 leaf position { 2018 type uint16; 2019 description 2020 "If only one element, position is 0. Otherwise, position is the 2021 the order in the matching list, starting at 1."; 2022 } 2023 } 2025 grouping compression-rule-entry { 2026 description 2027 "These entries defines a compression entry (i.e. a line) 2028 as defined in RFC 8724. 2030 +-------+--+--+--+------------+-----------------+---------------+ 2031 |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| 2032 +-------+--+--+--+------------+-----------------+---------------+ 2034 An entry in a compression rule is composed of 7 elements: 2035 - Field ID: The header field to be compressed. The content is a 2036 YANG identifer. 2037 - Field Length : either a positive integer of a function defined 2038 as a YANG id. 2040 - Field Position: a positive (and possibly equal to 0) integer. 2041 - Direction Indicator: a YANG identifier giving the direction. 2042 - Target value: a value against which the header Field is 2043 compared. 2044 - Matching Operator: a YANG id giving the operation, parameters 2045 may be associated to that operator. 2046 - Comp./Decomp. Action: A YANG id giving the compression or 2047 decompression action, parameters may be associated to that 2048 action. 2049 "; 2050 leaf field-id { 2051 type schc:fid-type; 2052 mandatory true; 2053 description 2054 "Field ID, identify a field in the header with a YANG 2055 referenceid."; 2056 } 2057 leaf field-length { 2058 type schc:fl-type; 2059 mandatory true; 2060 description 2061 "Field Length, expressed in number of bits or through a function defined as a 2062 YANG referenceid."; 2063 } 2064 leaf field-position { 2065 type uint8; 2066 mandatory true; 2067 description 2068 "Field position in the header is an integer. Position 1 matches 2069 the first occurence of a field in the header, while incremented 2070 position values match subsequent occurences. 2071 Position 0 means that this entry matches a field irrespective 2072 of its position of occurence in the header. 2073 Be aware that the decompressed header may have position-0 2074 fields ordered differently than they appeared in the original 2075 packet."; 2076 } 2077 leaf direction-indicator { 2078 type schc:di-type; 2079 mandatory true; 2080 description 2081 "Direction Indicator, a YANG referenceid to say if the packet 2082 is bidirectional, up or down"; 2083 } 2084 list target-value { 2085 key "position"; 2086 uses tv-struct; 2087 description 2088 "A list of value to compare with the header field value. 2089 If target value is a singleton, position must be 0. 2090 For use as a matching list for the mo-match-mapping matching 2091 operator, positions should take consecutive values starting 2092 from 1."; 2093 } 2094 leaf matching-operator { 2095 type schc:mo-type; 2096 must "../target-value or derived-from-or-self(., 'mo-ignore')" { 2097 error-message 2098 "mo-equal, mo-msb and mo-match-mapping need target-value"; 2099 description 2100 "target-value is not required for mo-ignore"; 2101 } 2102 must "not (derived-from-or-self(., 'mo-msb')) or 2103 ../matching-operator-value" { 2104 error-message "mo-msb requires length value"; 2105 } 2106 mandatory true; 2107 description 2108 "MO: Matching Operator"; 2109 } 2110 list matching-operator-value { 2111 key "position"; 2112 uses tv-struct; 2113 description 2114 "Matching Operator Arguments, based on TV structure to allow 2115 several arguments. 2116 In RFC 8724, only the MSB matching operator needs arguments (a single argument, which is the 2117 number of most significant bits to be matched)"; 2118 } 2119 leaf comp-decomp-action { 2120 type schc:cda-type; 2121 mandatory true; 2122 description 2123 "CDA: Compression Decompression Action."; 2124 } 2125 list comp-decomp-action-value { 2126 key "position"; 2127 uses tv-struct; 2128 description 2129 "CDA arguments, based on a TV structure, in order to allow for 2130 several arguments. The CDAs specified in RFC 8724 require no 2131 argument."; 2132 } 2133 } 2135 grouping compression-content { 2136 list entry { 2137 key "field-id field-position direction-indicator"; 2138 uses compression-rule-entry; 2139 description 2140 "A compression rule is a list of rule entries, each describing 2141 a header field. An entry is identifed through a field-id, 2142 its position in the packet and its direction."; 2143 } 2144 description 2145 "Define a compression rule composed of a list of entries."; 2146 } 2148 grouping fragmentation-content { 2149 description 2150 "This grouping defines the fragmentation parameters for 2151 all the modes (No-Ack, Ack-Always and Ack-on-Error) specified in 2152 RFC 8724."; 2153 leaf fragmentation-mode { 2154 type schc:fragmentation-mode-type; 2155 mandatory true; 2156 description 2157 "which fragmentation mode is used (noAck, AckAlways, 2158 AckonError)"; 2159 } 2160 leaf l2-word-size { 2161 type uint8; 2162 default "8"; 2163 description 2164 "Size, in bits, of the layer 2 word"; 2165 } 2166 leaf direction { 2167 type schc:di-type; 2168 must "derived-from-or-self(., 'di-up') or 2169 derived-from-or-self(., 'di-down')" { 2170 error-message 2171 "direction for fragmentation rules are up or down."; 2172 } 2173 mandatory true; 2174 description 2175 "Should be up or down, bidirectionnal is forbiden."; 2176 } 2177 // SCHC Frag header format 2178 leaf dtag-size { 2179 type uint8; 2180 default "0"; 2181 description 2182 "Size, in bits, of the DTag field (T variable from RFC8724)."; 2183 } 2184 leaf w-size { 2185 when "derived-from(../fragmentation-mode, 2186 'fragmentation-mode-ack-on-error') 2187 or 2188 derived-from(../fragmentation-mode, 2189 'fragmentation-mode-ack-always') "; 2190 type uint8; 2191 description 2192 "Size, in bits, of the window field (M variable from RFC8724)."; 2193 } 2194 leaf fcn-size { 2195 type uint8; 2196 mandatory true; 2197 description 2198 "Size, in bits, of the FCN field (N variable from RFC8724)."; 2199 } 2200 leaf rcs-algorithm { 2201 type rcs-algorithm-type; 2202 default "schc:rcs-RFC8724"; 2203 description 2204 "Algorithm used for RCS. The algorithm specifies the RCS size"; 2205 } 2206 // SCHC fragmentation protocol parameters 2207 leaf maximum-packet-size { 2208 type uint16; 2209 default "1280"; 2210 description 2211 "When decompression is done, packet size must not 2212 strictly exceed this limit, expressed in bytes."; 2213 } 2214 leaf window-size { 2215 type uint16; 2216 description 2217 "By default, if not specified 2^w-size - 1. Should not exceed 2218 this value. Possible FCN values are between 0 and 2219 window-size - 1."; 2220 } 2221 leaf max-interleaved-frames { 2222 type uint8; 2223 default "1"; 2224 description 2225 "Maximum of simultaneously fragmented frames. Maximum value is 2226 2^dtag-size. All DTAG values can be used, but at most 2227 max-interleaved-frames must be active at any time."; 2228 } 2229 leaf inactivity-timer { 2230 type uint64; 2231 description 2232 "Duration is seconds of the inactivity timer, 0 indicates 2233 that the timer is disabled."; 2234 } 2235 leaf retransmission-timer { 2236 when "derived-from(../fragmentation-mode, 2237 'fragmentation-mode-ack-on-error') 2238 or 2239 derived-from(../fragmentation-mode, 2240 'fragmentation-mode-ack-always') "; 2241 type uint64 { 2242 range "1..max"; 2243 } 2244 description 2245 "Duration in seconds of the retransmission timer."; 2246 } 2247 leaf max-ack-requests { 2248 when "derived-from(../fragmentation-mode, 2249 'fragmentation-mode-ack-on-error') 2250 or 2251 derived-from(../fragmentation-mode, 2252 'fragmentation-mode-ack-always') "; 2253 type uint8 { 2254 range "1..max"; 2255 } 2256 description 2257 "The maximum number of retries for a specific SCHC ACK."; 2258 } 2259 choice mode { 2260 case no-ack; 2261 case ack-always; 2262 case ack-on-error { 2263 leaf tile-size { 2264 when "derived-from(../fragmentation-mode, 2265 'fragmentation-mode-ack-on-error')"; 2266 type uint8; 2267 description 2268 "Size, in bits, of tiles. If not specified or set to 0, 2269 tiles fill the fragment."; 2270 } 2271 leaf tile-in-All1 { 2272 when "derived-from(../fragmentation-mode, 2273 'fragmentation-mode-ack-on-error')"; 2274 type schc:all1-data-type; 2275 description 2276 "Defines whether the sender and receiver expect a tile in 2277 All-1 fragments or not, or if it is left to the sender's 2278 choice."; 2279 } 2280 leaf ack-behavior { 2281 when "derived-from(../fragmentation-mode, 2282 'fragmentation-mode-ack-on-error')"; 2283 type schc:ack-behavior-type; 2284 description 2285 "Sender behavior to acknowledge, after All-0, All-1 or 2286 when the LPWAN allows it."; 2287 } 2288 } 2289 description 2290 "RFC 8724 defines 3 fragmentation modes."; 2291 } 2292 } 2294 // Define rule ID. Rule ID is composed of a RuleID value and a 2295 // Rule ID Length 2297 grouping rule-id-type { 2298 leaf rule-id-value { 2299 type uint32; 2300 description 2301 "Rule ID value, this value must be unique, considering its 2302 length."; 2303 } 2304 leaf rule-id-length { 2305 type uint8 { 2306 range "0..32"; 2307 } 2308 description 2309 "Rule ID length, in bits. The value 0 is for implicit rules."; 2310 } 2311 description 2312 "A rule ID is composed of a value and a length, expressed in 2313 bits."; 2314 } 2316 // SCHC table for a specific device. 2318 container schc { 2319 list rule { 2320 key "rule-id-value rule-id-length"; 2321 uses rule-id-type; 2322 choice nature { 2323 case fragmentation { 2324 if-feature "fragmentation"; 2325 uses fragmentation-content; 2326 } 2327 case compression { 2328 if-feature "compression"; 2329 uses compression-content; 2330 } 2331 case no-compression { 2332 description 2333 "RFC8724 requires a rule for uncompressed headers."; 2334 } 2335 description 2336 "A rule is for compression, for no-compression or for 2337 fragmentation."; 2338 } 2339 description 2340 "Set of rules compression, no compression or fragmentation 2341 rules identified by their rule-id."; 2342 } 2343 description 2344 "a SCHC set of rules is composed of a list of rules which are 2345 used for compression, no-compression or fragmentation."; 2346 } 2347 } 2348 2350 Figure 24 2352 8. Normative References 2354 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 2355 Zuniga, "SCHC: Generic Framework for Static Context Header 2356 Compression and Fragmentation", RFC 8724, 2357 DOI 10.17487/RFC8724, April 2020, 2358 . 2360 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 2361 Context Header Compression (SCHC) for the Constrained 2362 Application Protocol (CoAP)", RFC 8824, 2363 DOI 10.17487/RFC8824, June 2021, 2364 . 2366 Authors' Addresses 2368 Ana Minaburo 2369 Acklio 2370 1137A avenue des Champs Blancs 2371 35510 Cesson-Sevigne Cedex 2372 France 2373 Email: ana@ackl.io 2374 Laurent Toutain 2375 Institut MINES TELECOM; IMT Atlantique 2376 2 rue de la Chataigneraie 2377 CS 17607 2378 35576 Cesson-Sevigne Cedex 2379 France 2380 Email: Laurent.Toutain@imt-atlantique.fr