idnits 2.17.00 (12 Aug 2021) /tmp/idnits40710/draft-ietf-lpwan-ipv6-static-context-hc-17.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 1307 days in the past. Is this intentional? 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: April 25, 2019 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 D. Barthel 9 Orange Labs 10 JC. Zuniga 11 SIGFOX 12 October 22, 2018 14 LPWAN Static Context Header Compression (SCHC) and fragmentation for 15 IPv6 and UDP 16 draft-ietf-lpwan-ipv6-static-context-hc-17 18 Abstract 20 This document defines the Static Context Header Compression (SCHC) 21 framework, which provides both header compression and fragmentation 22 functionalities. SCHC has been designed for Low Power Wide Area 23 Networks (LPWAN). 25 SCHC compression is based on a common static context stored in both 26 the LPWAN device and the network side. This document defines a 27 header compression mechanism and its application to compress IPv6/UDP 28 headers. 30 This document also specifies a fragmentation and reassembly mechanism 31 that is used to support the IPv6 MTU requirement over the LPWAN 32 technologies. Fragmentation is needed for IPv6 datagrams that, after 33 SCHC compression or when such compression was not possible, still 34 exceed the layer-2 maximum payload size. 36 The SCHC header compression and fragmentation mechanisms are 37 independent of the specific LPWAN technology over which they are 38 used. This document defines generic functionalities and offers 39 flexibility with regard to parameter settings and mechanism choices. 40 Technology-specific and product-specific settings and choices are 41 expected to be grouped into Profiles specified in other documents. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on April 25, 2019. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 79 3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5 80 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10 83 5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 11 84 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12 86 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12 87 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14 88 7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15 89 7.4. Matching operators . . . . . . . . . . . . . . . . . . . 16 90 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 17 91 7.5.1. processing variable-length fields . . . . . . . . . . 17 92 7.5.2. not-sent CDA . . . . . . . . . . . . . . . . . . . . 18 93 7.5.3. value-sent CDA . . . . . . . . . . . . . . . . . . . 18 94 7.5.4. mapping-sent CDA . . . . . . . . . . . . . . . . . . 18 95 7.5.5. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 19 96 7.5.6. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 19 97 7.5.7. Compute-* . . . . . . . . . . . . . . . . . . . . . . 19 98 8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 20 99 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 100 8.2. SCHC F/R Tools . . . . . . . . . . . . . . . . . . . . . 20 101 8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 20 102 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 21 103 8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 23 104 8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 24 105 8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 26 106 8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 26 107 8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 27 108 8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 30 109 8.3.4. SCHC Abort formats . . . . . . . . . . . . . . . . . 31 110 8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 33 111 8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 33 112 8.4.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 36 113 8.4.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 42 114 9. Padding management . . . . . . . . . . . . . . . . . . . . . 49 115 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 50 116 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 50 117 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 51 118 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 51 119 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 51 120 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 52 121 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 52 122 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 52 123 10.7.1. IPv6 source and destination prefixes . . . . . . . . 52 124 10.7.2. IPv6 source and destination IID . . . . . . . . . . 53 125 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 53 126 10.9. UDP source and destination port . . . . . . . . . . . . 53 127 10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 54 128 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 54 129 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 130 12. Security considerations . . . . . . . . . . . . . . . . . . . 55 131 12.1. Security considerations for SCHC 132 Compression/Decompression . . . . . . . . . . . . . . . 55 133 12.2. Security considerations for SCHC 134 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 55 135 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 136 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 137 14.1. Normative References . . . . . . . . . . . . . . . . . . 57 138 14.2. Informative References . . . . . . . . . . . . . . . . . 57 139 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 58 140 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 61 141 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 68 142 Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 75 143 Appendix E. Supporting multiple window sizes for fragmentation . 77 144 Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 77 145 Appendix G. Note . . . . . . . . . . . . . . . . . . . . . . . . 78 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 148 1. Introduction 150 This document defines the Static Context Header Compression (SCHC) 151 framework, which provides both header compression and fragmentation 152 functionalities. SCHC has been designed for Low Power Wide Area 153 Networks (LPWAN). 155 Header compression is needed for efficient Internet connectivity to 156 the node within an LPWAN network. Some LPWAN networks properties can 157 be exploited to get an efficient header compression: 159 o The network topology is star-oriented, which means that all 160 packets between the same source-destination pair follow the same 161 path. For the needs of this document, the architecture can simply 162 be described as Devices (Dev) exchanging information with LPWAN 163 Application Servers (App) through a Network Gateway (NGW). 165 o Because devices embed built-in applications, the traffic flows to 166 be compressed are known in advance. Indeed, new applications are 167 less frequently installed in an LPWAN device, as they are in a 168 computer or smartphone. 170 SCHC compression uses a context in which information about header 171 fields is stored. This context is static: the values of the header 172 fields do not change over time. This avoids complex 173 resynchronization mechanisms. Indeed, downlink is often more 174 restricted/expensive, perhaps completely unavailable [RFC8376]. A 175 compression protocol that relies on feedback is not compatible with 176 the characteristics of such LPWANs. 178 In most cases, a small context identifier is enough to represent the 179 full IPv6/UDP headers. The SCHC header compression mechanism is 180 independent of the specific LPWAN technology over which it is used. 182 LPWAN technologies impose some strict limitations on traffic. For 183 instance, devices are sleeping most of the time and may receive data 184 during short periods of time after transmission to preserve battery. 185 LPWAN technologies are also characterized by a greatly reduced data 186 unit and/or payload size (see [RFC8376]). However, some LPWAN 187 technologies do not provide fragmentation functionality; to support 188 the IPv6 MTU requirement of 1280 bytes [RFC8200], they require a 189 fragmentation protocol at the adaptation layer below IPv6. 190 Accordingly, this document defines an fragmentation/reassembly 191 mechanism for LPWAN technologies to supports the IPv6 MTU. Its 192 implementation is optional. If not interested, the reader can safely 193 skip its description. 195 This document defines generic functionality and offers flexibility 196 with regard to parameters settings and mechanism choices. 197 Technology-specific settings and product-specific and choices are 198 expected to be grouped into Profiles specified in other documents. 200 2. Requirements Notation 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described in BCP 205 14 [RFC2119] [RFC8174] when, and only when, they appear in all 206 capitals, as shown here. 208 3. LPWAN Architecture 210 LPWAN technologies have similar network architectures but different 211 terminologies. Using the terminology defined in [RFC8376], we can 212 identify different types of entities in a typical LPWAN network, see 213 Figure 1: 215 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 216 actuators, etc.). There can be a very high density of devices per 217 radio gateway. 219 o The Radio Gateway (RGW), which is the end point of the constrained 220 link. 222 o The Network Gateway (NGW) is the interconnection node between the 223 Radio Gateway and the Internet. 225 o LPWAN-AAA Server, which controls the user authentication and the 226 applications. 228 o Application Server (App) 229 +------+ 230 () () () | |LPWAN-| 231 () () () () / \ +---------+ | AAA | 232 () () () () () () / \======| ^ |===|Server| +-----------+ 233 () () () | | <--|--> | +------+ |APPLICATION| 234 () () () () / \==========| v |=============| (App) | 235 () () () / \ +---------+ +-----------+ 236 Dev Radio Gateways NGW 238 Figure 1: LPWAN Architecture 240 4. Terminology 242 This section defines the terminology and acronyms used in this 243 document. 245 Note that the SCHC acronym is pronounced like "sheek" in English (or 246 "chic" in French). Therefore, this document writes "a SCHC Packet" 247 instead of "an SCHC Packet". 249 o App: LPWAN Application. An application sending/receiving IPv6 250 packets to/from the Device. 252 o AppIID: Application Interface Identifier. The IID that identifies 253 the application server interface. 255 o Bi: Bidirectional. Characterises a Field Descriptor that applies 256 to headers of packets travelling in either direction (Up and Dw, 257 see this glossary). 259 o CDA: Compression/Decompression Action. Describes the reciprocal 260 pair of actions that are performed at the compressor to compress a 261 header field and at the decompressor to recover the original 262 header field value. 264 o Compression Residue. The bits that need to be sent (beyond the 265 Rule ID itself) after applying the SCHC compression over each 266 header field. 268 o Context: A set of Rules used to compress/decompress headers. 270 o Dev: Device. A node connected to an LPWAN. A Dev SHOULD 271 implement SCHC. 273 o DevIID: Device Interface Identifier. The IID that identifies the 274 Dev interface. 276 o DI: Direction Indicator. This field tells which direction of 277 packet travel (Up, Dw or Bi) a Rule applies to. This allows for 278 assymmetric processing. 280 o Dw: Downlink direction for compression/decompression in both 281 sides, from SCHC C/D in the network to SCHC C/D in the Dev. 283 o Field Description. A line in the Rule table. 285 o FID: Field Identifier. This is an index to describe the header 286 fields in a Rule. 288 o FL: Field Length is the length of the packet header field. It is 289 expressed in bits for header fields of fixed lengths or as a type 290 (e.g. variable, token length, ...) for field lengths that are 291 unknown at the time of Rule creation. The length of a header 292 field is defined in the corresponding protocol specification (such 293 as IPv6 or UDP). 295 o FP: Field Position is a value that is used to identify the 296 position where each instance of a field appears in the header. 298 o IID: Interface Identifier. See the IPv6 addressing architecture 299 [RFC7136] 301 o L2: Layer two. The immediate lower layer SCHC interfaces with. 302 It is provided by an underlying LPWAN technology. It does not 303 necessarily correspond to the OSI model definition of Layer 2. 305 o L2 Word: this is the minimum subdivision of payload data that the 306 L2 will carry. In most L2 technologies, the L2 Word is an octet. 307 In bit-oriented radio technologies, the L2 Word might be a single 308 bit. The L2 Word size is assumed to be constant over time for 309 each device. 311 o MO: Matching Operator. An operator used to match a value 312 contained in a header field with a value contained in a Rule. 314 o Padding (P). Extra bits that may be appended by SCHC to a data 315 unit that it passes to the underlying Layer 2 for transmission. 316 SCHC itself operates on bits, not bytes, and does not have any 317 alignment prerequisite. See Section 9. 319 o Profile: SCHC offers variations in the way it is operated, with a 320 number of parameters listed in Appendix D. A Profile indicates a 321 particular setting of all these parameters. Both ends of a SCHC 322 session must be provisioned with the same Profile information and 323 with the same set of Rules before the session starts, so that 324 there is no ambiguity in how they expect to communicate. 326 o Rule: A set of header field values. 328 o Rule ID: An identifier for a Rule. SCHC C/D on both sides share 329 the same Rule ID for a given packet. A set of Rule IDs are used 330 to support SCHC F/R functionality. 332 o SCHC C/D: Static Context Header Compression Compressor/ 333 Decompressor. A mechanism used on both sides, at the Dev and at 334 the network, to achieve Compression/Decompression of headers. 335 SCHC C/D uses Rules to perform compression and decompression. 337 o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been 338 compressed as per the header compression mechanism defined in this 339 document. If the header compression process is unable to actually 340 compress the packet header, the packet with the uncompressed 341 header is still called a SCHC Packet (in this case, a Rule ID is 342 used to indicate that the packet header has not been compressed). 343 See Section 7 for more details. 345 o TV: Target value. A value contained in a Rule that will be 346 matched with the value of a header field. 348 o Up: Uplink direction for compression/decompression in both sides, 349 from the Dev SCHC C/D to the network SCHC C/D. 351 Additional terminology for the optional SCHC Fragmentation / 352 Reassembly mechanism (SCHC F/R) is found in Section 8.2. 354 5. SCHC overview 356 SCHC can be characterized as an adaptation layer between IPv6 and the 357 underlying LPWAN technology. SCHC comprises two sublayers (i.e. the 358 Compression sublayer and the Fragmentation sublayer), as shown in 359 Figure 2. 361 +----------------+ 362 | IPv6 | 363 +- +----------------+ 364 | | Compression | 365 SCHC < +----------------+ 366 | | Fragmentation | 367 +- +----------------+ 368 |LPWAN technology| 369 +----------------+ 371 Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN 372 technology 374 As per this document, when a packet (e.g. an IPv6 packet) needs to be 375 transmitted, header compression is first applied to the packet. The 376 resulting packet after header compression (whose header may or may 377 not actually be smaller than that of the original packet) is called a 378 SCHC Packet. If the SCHC Packet needs to be fragmented by the 379 optional SCHC Fragmentation, fragmentation is then applied to the 380 SCHC Packet. The SCHC Packet or the SCHC Fragments are then 381 transmitted over the LPWAN. The reciprocal operations take place at 382 the receiver. This process is illustrated in Figure 3. 384 A packet (e.g. an IPv6 packet) 385 | ^ 386 v | 387 +------------------+ +--------------------+ 388 | SCHC Compression | | SCHC Decompression | 389 +------------------+ +--------------------+ 390 | ^ 391 | If no fragmentation (*) | 392 +-------------- SCHC Packet -------------->| 393 | | 394 v | 395 +--------------------+ +-----------------+ 396 | SCHC Fragmentation | | SCHC Reassembly | 397 +--------------------+ +-----------------+ 398 | ^ | ^ 399 | | | | 400 | +-------------- SCHC ACK -------------+ | 401 | | 402 +-------------- SCHC Fragments -------------------+ 404 SENDER RECEIVER 406 *: the decision to use Fragmentation or not is left to each Profile. 408 Figure 3: SCHC operations at the SENDER and the RECEIVER 410 5.1. SCHC Packet format 412 The SCHC Packet is composed of the Compressed Header followed by the 413 payload from the original packet (see Figure 4). The Compressed 414 Header itself is composed of the Rule ID and a Compression Residue, 415 which is the output of the compression actions of the Rule that was 416 applied (see Section 7). The Compression Residue may be empty. Both 417 the Rule ID and the Compression Residue potentially have a variable 418 size, and generally are not a mutiple of bytes in size. 420 | Rule ID + Compression Residue | 421 +---------------------------------+--------------------+ 422 | Compressed Header | Payload | 423 +---------------------------------+--------------------+ 425 Figure 4: SCHC Packet 427 5.2. Functional mapping 429 Figure 5 below maps the functional elements of Figure 3 onto the 430 LPWAN architecture elements of Figure 1. 432 Dev App 433 +----------------+ +--------------+ 434 | APP1 APP2 APP3 | |APP1 APP2 APP3| 435 | | | | 436 | UDP | | UDP | 437 | IPv6 | | IPv6 | 438 | | | | 439 |SCHC C/D and F/R| | | 440 +--------+-------+ +-------+------+ 441 | +--+ +----+ +-----------+ . 442 +~~ |RG| === |NGW | === | SCHC |... Internet .. 443 +--+ +----+ |F/R and C/D| 444 +-----------+ 446 Figure 5: Architecture 448 SCHC C/D and SCHC F/R are located on both sides of the LPWAN 449 transmission, i.e. on the Dev side and on the Network side. 451 The operation in the Uplink direction is as follows. The Device 452 application uses IPv6 or IPv6/UDP protocols. Before sending the 453 packets, the Dev compresses their headers using SCHC C/D and, if the 454 SCHC Packet resulting from the compression needs to be fragmented by 455 SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC 456 Fragments are sent to an LPWAN Radio Gateway (RG) which forwards them 457 to a Network Gateway (NGW). The NGW sends the data to a SCHC F/R for 458 re-assembly (if needed) and then to the SCHC C/D for decompression. 459 After decompression, the packet can be sent over the Internet to one 460 or several LPWAN Application Servers (App). 462 The SCHC F/R and C/D on the Network side can be located in the NGW, 463 or somewhere else as long as a tunnel is established between them and 464 the NGW. Note that, for some LPWAN technologies, it MAY be suitable 465 to locate the SCHC F/R functionality nearer the NGW, in order to 466 better deal with time constraints of such technologies. 468 The SCHC C/D and F/R on both sides MUST share the same set of Rules. 470 The SCHC C/D and F/R process is symmetrical, therefore the 471 description of the Downlink direction is symmetrical to the one 472 above. 474 6. Rule ID 476 Rule IDs are identifiers used to select the correct context either 477 for Compression/Decompression or for Fragmentation/Reassembly. 479 The size of the Rule IDs is not specified in this document, as it is 480 implementation-specific and can vary according to the LPWAN 481 technology and the number of Rules, among others. It is defined in 482 Profiles. 484 The Rule IDs are used: 486 o In the SCHC C/D context, to identify the Rule (i.e., the set of 487 Field Descriptions) that is used to compress a packet header. 489 o At least one Rule ID MAY be allocated to tagging packets for which 490 SCHC compression was not possible (no matching Rule was found). 492 o In SCHC F/R, to identify the specific modes and settings of SCHC 493 Fragments being transmitted, and to identify the SCHC ACKs, 494 including their modes and settings. Note that when F/R is used 495 for both communication directions, at least two Rule ID values are 496 therefore needed for F/R. 498 7. Compression/Decompression 500 Compression with SCHC is based on using context, i.e. a set of Rules 501 to compress or decompress headers. SCHC avoids context 502 synchronization, which consumes considerable bandwidth in other 503 header compression mechanisms such as RoHC [RFC5795]. Since the 504 content of packets is highly predictable in LPWAN networks, static 505 contexts MAY be stored beforehand to omit transmitting some 506 information over the air. The contexts MUST be stored at both ends, 507 and they can be learned by a provisioning protocol or by out of band 508 means, or they can be pre-provisioned. The way the contexts are 509 provisioned is out of the scope of this document. 511 7.1. SCHC C/D Rules 513 The main idea of the SCHC compression scheme is to transmit the Rule 514 ID to the other end instead of sending known field values. This Rule 515 ID identifies a Rule that provides the closest match to the original 516 packet values. Hence, when a value is known by both ends, it is only 517 necessary to send the corresponding Rule ID over the LPWAN network. 518 The manner by which Rules are generated is out of the scope of this 519 document. The Rules MAY be changed at run-time but the mechanism is 520 out of scope of this document. 522 The context contains a list of Rules (see Figure 6). Each Rule 523 itself contains a list of Field Descriptions composed of a Field 524 Identifier (FID), a Field Length (FL), a Field Position (FP), a 525 Direction Indicator (DI), a Target Value (TV), a Matching Operator 526 (MO) and a Compression/Decompression Action (CDA). 528 /-----------------------------------------------------------------\ 529 | Rule N | 530 /-----------------------------------------------------------------\| 531 | Rule i || 532 /-----------------------------------------------------------------\|| 533 | (FID) Rule 1 ||| 534 |+-------+--+--+--+------------+-----------------+---------------+||| 535 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 536 |+-------+--+--+--+------------+-----------------+---------------+||| 537 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 538 |+-------+--+--+--+------------+-----------------+---------------+||| 539 ||... |..|..|..| ... | ... | ... |||| 540 |+-------+--+--+--+------------+-----------------+---------------+||/ 541 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 542 |+-------+--+--+--+------------+-----------------+---------------+|/ 543 | | 544 \-----------------------------------------------------------------/ 546 Figure 6: A Compression/Decompression Context 548 A Rule does not describe how to parse a packet header to find each 549 field. This MUST be known from the compressor/decompressor. Rules 550 only describe the compression/decompression behavior for each header 551 field. In a Rule, the Field Descriptions are listed in the order in 552 which the fields appear in the packet header. 554 A Rule also describes what is sent in the Compression Residue. The 555 Compression Residue is assembled by concatenating the residues for 556 each field, in the order the Field Descriptions appear in the Rule. 558 The Context describes the header fields and its values with the 559 following entries: 561 o Field ID (FID) is a unique value to define the header field. 563 o Field Length (FL) represents the length of the field. It can be 564 either a fixed value (in bits) if the length is known when the 565 Rule is created or a type if the length is variable. The length 566 of a header field is defined in the corresponding protocol 567 specification. The type defines the process to compute the 568 length, its unit (bits, bytes,...) and the value to be sent before 569 the Compression Residue. 571 o Field Position (FP): most often, a field only occurs once in a 572 packet header. Some fields may occur multiple times in a header. 573 FP indicates which occurrence this Field Description applies to. 574 The default value is 1 (first occurence). 576 o A Direction Indicator (DI) indicates the packet direction(s) this 577 Field Description applies to. Three values are possible: 579 * UPLINK (Up): this Field Description is only applicable to 580 packets sent by the Dev to the App, 582 * DOWNLINK (Dw): this Field Description is only applicable to 583 packets sent from the App to the Dev, 585 * BIDIRECTIONAL (Bi): this Field Description is applicable to 586 packets travelling both Up and Dw. 588 o Target Value (TV) is the value used to match against the packet 589 header field. The Target Value can be of any type (integer, 590 strings, etc.). It can be a single value or a more complex 591 structure (array, list, etc.), such as a JSON or a CBOR structure. 593 o Matching Operator (MO) is the operator used to match the Field 594 Value and the Target Value. The Matching Operator may require 595 some parameters. MO is only used during the compression phase. 596 The set of MOs defined in this document can be found in 597 Section 7.4. 599 o Compression Decompression Action (CDA) describes the compression 600 and decompression processes to be performed after the MO is 601 applied. Some CDAs MAY require parameter values for their 602 operation. CDAs are used in both the compression and the 603 decompression functions. The set of CDAs defined in this document 604 can be found in Section 7.5. 606 7.2. Rule ID for SCHC C/D 608 Rule IDs are sent by the compression function in one side and are 609 received for the decompression function in the other side. In SCHC 610 C/D, the Rule IDs are specific to a Dev. Hence, multiple Dev 611 instances MAY use the same Rule ID to define different header 612 compression contexts. To identify the correct Rule ID, the SCHC C/D 613 needs to associate the Rule ID with the Dev identifier to find the 614 appropriate Rule to be applied. 616 7.3. Packet processing 618 The compression/decompression process follows several steps: 620 o Compression Rule selection: The goal is to identify which Rule(s) 621 will be used to compress the packet's headers. When performing 622 decompression, on the network side the SCHC C/D needs to find the 623 correct Rule based on the L2 address; in this way, it can use the 624 DevIID and the Rule ID. On the Dev side, only the Rule ID is 625 needed to identify the correct Rule since the Dev typically only 626 holds Rules that apply to itself. The Rule will be selected by 627 matching the Fields Descriptions to the packet header as described 628 below. When the selection of a Rule is done, this Rule is used to 629 compress the header. The detailed steps for compression Rule 630 selection are the following: 632 * The first step is to choose the Field Descriptions by their 633 direction, using the Direction Indicator (DI). A Field 634 Description that does not correspond to the appropriate DI will 635 be ignored. If all the fields of the packet do not have a 636 Field Description with the correct DI, the Rule is discarded 637 and SCHC C/D proceeds to consider the next Rule. 639 * When the DI has matched, then the next step is to identify the 640 fields according to Field Position (FP). If FP does not 641 correspond, the Rule is not used and the SCHC C/D proceeds to 642 consider the next Rule. 644 * Once the DI and the FP correspond to the header information, 645 each packet field's value is then compared to the corresponding 646 Target Value (TV) stored in the Rule for that specific field 647 using the matching operator (MO). 649 If all the fields in the packet's header satisfy all the 650 matching operators (MO) of a Rule (i.e. all MO results are 651 True), the fields of the header are then compressed according 652 to the Compression/Decompression Actions (CDAs) and a 653 compressed header (with possibly a Compression Residue) SHOULD 654 be obtained. Otherwise, the next Rule is tested. 656 * If no eligible compression Rule is found, then the header MUST 657 be sent without compression, using a Rule ID dedicated to this 658 purpose. Sending the header uncompressed but may require the 659 use of the SCHC F/R process. 661 o Sending: The Rule ID is sent to the other end followed by the 662 Compression Residue (which could be empty) or the uncompressed 663 header, and directly followed by the payload. The Compression 664 Residue is the concatenation of the Compression Residues for each 665 field according to the CDAs for that Rule. The way the Rule ID is 666 sent depends on the Profile. For example, it can be either 667 included in an L2 header or sent in the first byte of the L2 668 payload. (see Figure 4). This process will be specified in the 669 Profile and is out of the scope of the present document. On LPWAN 670 technologies that are byte-oriented, the compressed header 671 concatenated with the original packet payload is padded to a 672 multiple of 8 bits, if needed. See Section 9 for details. 674 o Decompression: When doing decompression, on the network side the 675 SCHC C/D needs to find the correct Rule based on the L2 address 676 and in this way, it can use the DevIID and the Rule ID. On the 677 Dev side, only the Rule ID is needed to identify the correct Rule 678 since the Dev only holds Rules that apply to itself. 680 The receiver identifies the sender through its device-id or source 681 identifier (e.g. MAC address, if it exists) and selects the Rule 682 using the Rule ID. This Rule describes the compressed header 683 format and associates the received Compression Residue to each of 684 the header fields. For each field in the header, the receiver 685 applies the CDA action associated to that field in order to 686 reconstruct the original header field value. The CDA application 687 order can be different from the order in which the fields are 688 listed in the Rule. In particular, Compute-* MUST be applied 689 after the application of the CDAs of all the fields it computes 690 on. 692 7.4. Matching operators 694 Matching Operators (MOs) are functions used by both SCHC C/D 695 endpoints involved in the header compression/decompression. They are 696 not typed and can be applied to integer, string or any other data 697 type. The result of the operation can either be True or False. MOs 698 are defined as follows: 700 o equal: The match result is True if the field value in the packet 701 matches the TV. 703 o ignore: No check is done between the field value in the packet and 704 the TV in the Rule. The result of the matching is always true. 706 o MSB(x): A match is obtained if the most significant x bits of the 707 packet header field value are equal to the TV in the Rule. The x 708 parameter of the MSB MO indicates how many bits are involved in 709 the comparison. If the FL is described as variable, the length 710 must be a multiple of the unit. For example, x must be multiple 711 of 8 if the unit of the variable length is in bytes. 713 o match-mapping: With match-mapping, the Target Value is a list of 714 values. Each value of the list is identified by a short ID (or 715 index). Compression is achieved by sending the index instead of 716 the original header field value. This operator matches if the 717 header field value is equal to one of the values in the target 718 list. 720 7.5. Compression Decompression Actions (CDA) 722 The Compression Decompression Action (CDA) describes the actions 723 taken during the compression of headers fields, and inversely, the 724 action taken by the decompressor to restore the original value. 726 /--------------------+-------------+----------------------------\ 727 | Action | Compression | Decompression | 728 | | | | 729 +--------------------+-------------+----------------------------+ 730 |not-sent |elided |use value stored in context | 731 |value-sent |send |build from received value | 732 |mapping-sent |send index |value from index on a table | 733 |LSB |send LSB |TV, received value | 734 |compute-length |elided |compute length | 735 |compute-checksum |elided |compute UDP checksum | 736 |DevIID |elided |build IID from L2 Dev addr | 737 |AppIID |elided |build IID from L2 App addr | 738 \--------------------+-------------+----------------------------/ 740 Figure 7: Compression and Decompression Actions 742 Figure 7 summarizes the basic actions that can be used to compress 743 and decompress a field. The first column shows the action's name. 744 The second and third columns show the reciprocal compression/ 745 decompression behavior for each action. 747 Compression is done in the order that the Field Descriptions appear 748 in a Rule. The result of each Compression/Decompression Action is 749 appended to the accumulated Compression Residue in that same order. 750 The receiver knows the size of each compressed field, which can be 751 given by the Rule or MAY be sent with the compressed header. 753 7.5.1. processing variable-length fields 755 If the field is identified in the Field Description as being of 756 variable size, then the size of the Compression Residue value (using 757 the unit defined in the FL) MUST first be sent as follows: 759 o If the size is between 0 and 14, it is sent as a 4-bits unsigned 760 integer. 762 o For values between 15 and 254, 0b1111 is transmitted and then the 763 size is sent as an 8 bits unsigned integer. 765 o For larger values of the size, 0xfff is transmitted and then the 766 next two bytes contain the size value as a 16 bits unsigned 767 integer. 769 If a field is not present in the packet but exists in the Rule and 770 its FL is specified as being variable, size 0 MUST be sent to denote 771 its absence. 773 7.5.2. not-sent CDA 775 The not-sent action is generally used when the field value is 776 specified in a Rule and therefore known by both the Compressor and 777 the Decompressor. This action SHOULD be used with the "equal" MO. 778 If MO is "ignore", there is a risk to have a decompressed field value 779 different from the original field that was compressed. 781 The compressor does not send any Compression Residue for a field on 782 which not-sent compression is applied. 784 The decompressor restores the field value with the Target Value 785 stored in the matched Rule identified by the received Rule ID. 787 7.5.3. value-sent CDA 789 The value-sent action is generally used when the field value is not 790 known by both the Compressor and the Decompressor. The value is sent 791 as a residue in the compressed message header. Both Compressor and 792 Decompressor MUST know the size of the field, either implicitly (the 793 size is known by both sides) or by explicitly indicating the length 794 in the Compression Residue, as defined in Section 7.5.1. This action 795 is generally used with the "ignore" MO. 797 7.5.4. mapping-sent CDA 799 The mapping-sent action is used to send an index (the index into the 800 Target Value list of values) instead of the original value. This 801 action is used together with the "match-mapping" MO. 803 On the compressor side, the match-mapping Matching Operator searches 804 the TV for a match with the header field value and the mapping-sent 805 CDA appends the corresponding index to the Compression Residue to be 806 sent. On the decompressor side, the CDA uses the received index to 807 restore the field value by looking up the list in the TV. 809 The number of bits sent is the minimal size for coding all the 810 possible indices. 812 7.5.5. LSB CDA 814 The LSB action is used together with the "MSB(x)" MO to avoid sending 815 the most significant part of the packet field if that part is already 816 known by the receiving end. The number of bits sent is the original 817 header field length minus the length specified in the MSB(x) MO. 819 The compressor sends the Least Significant Bits (e.g. LSB of the 820 length field). The decompressor concatenates the x most significant 821 bits of Target Value and the received residue. 823 If this action needs to be done on a variable length field, the size 824 of the Compression Residue in bytes MUST be sent as described in 825 Section 7.5.1. 827 7.5.6. DevIID, AppIID CDA 829 These actions are used to process respectively the Dev and the App 830 Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. 831 AppIID CDA is less common since most current LPWAN technologies 832 frames contain a single L2 address, which is the Dev's address. 834 The IID value MAY be computed from the Device ID present in the L2 835 header, or from some other stable identifier. The computation is 836 specific to each Profile and MAY depend on the Device ID size. 838 In the downlink direction (Dw), at the compressor, the DevIID CDA may 839 be used to generate the L2 addresses on the LPWAN, based on the 840 packet's Destination Address. 842 7.5.7. Compute-* 844 Some fields may be elided during compression and reconstructed during 845 decompression. This is the case for length and checksum, so: 847 o compute-length: computes the length assigned to this field. This 848 CDA MAY be used to compute IPv6 length or UDP length. 850 o compute-checksum: computes a checksum from the information already 851 received by the SCHC C/D. This field MAY be used to compute UDP 852 checksum. 854 8. Fragmentation/Reassembly 856 8.1. Overview 858 In LPWAN technologies, the L2 MTU typically ranges from tens to 859 hundreds of bytes. Some of these technologies do not have an 860 internal fragmentation/reassembly mechanism. 862 The SCHC Fragmentation/Reassembly (SCHC F/R) functionality is offered 863 as an option for such LPWAN technologies to cope with the IPv6 MTU 864 requirement of 1280 bytes [RFC8200]. It is optional to implement. 865 If it is not needed, its description can be safely ignored. 867 This specification includes several SCHC F/R modes, which allow for a 868 range of reliability options such as optional SCHC Fragment 869 retransmission. More modes may be defined in the future. 871 The same SCHC F/R mode MUST be used for all SCHC Fragments of the 872 same fragmented SCHC Packet. This document does not make any 873 decision with regard to which mode(s) will be used over a specific 874 LPWAN technology. This will be defined in Profiles. 876 SCHC F/R uses the knowledge of the L2 Word size (see Section 4) to 877 encode some messages. Therefore, SCHC MUST know the L2 Word size. 878 SCHC F/R usually generates SCHC Fragments and SCHC ACKs that are 879 multiples of L2 Words. The padding overhead is kept to the absolute 880 minimum (see Section 9). 882 8.2. SCHC F/R Tools 884 This subsection describes the different tools that are used to enable 885 the SCHC F/R functionality defined in this document. These tools 886 include the SCHC F/R messages, tiles, windows, counters, timers and 887 header fields. 889 The tools are described here in a generic manner. Their application 890 to each SCHC F/R mode is found in Section 8.4. 892 8.2.1. Messages 894 The messages that can be used by SCHC F/R are the following: 896 o SCHC Fragment: A data unit that carries a piece of a SCHC Packet 897 from the sender to the receiver. 899 o SCHC ACK: An acknowledgement for fragmentation, by the receiver to 900 the sender. This message is used to report on the successful 901 reception of pieces of, or the whole of the fragmented SCHC 902 Packet. 904 o SCHC ACK REQ: An explicit request for a SCHC ACK. By the sender 905 to the receiver. 907 o SCHC Sender-Abort: A message by the sender telling the receiver 908 that it has aborted the transmission of a fragmented SCHC Packet. 910 o SCHC Receiver-Abort: A message by the receiver to tell the sender 911 to abort the transmission of a fragmented SCHC Packet. 913 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 915 8.2.2.1. Tiles 917 The SCHC Packet is fragmented into pieces, hereafter called tiles. 918 The tiles MUST be contiguous. 920 See Figure 8 for an example. 922 SCHC Packet 923 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 924 Tiles | | | | | | | | | | | | | | 925 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 927 Figure 8: a SCHC Packet fragmented in tiles 929 Each SCHC Fragment message carries at least one tile in its Payload, 930 if the Payload field is present. 932 8.2.2.2. Windows 934 Some SCHC F/R modes may handle successive tiles in groups, called 935 windows. 937 If windows are used 939 o all the windows of a SCHC Packet, except the last one, MUST 940 contain the same number of tiles. This number is WINDOW_SIZE. 942 o WINDOW_SIZE MUST be specified in a Profile. 944 o the windows are numbered. 946 o their numbers MUST increase from 0 upward, from the start of the 947 SCHC Packet to its end. 949 o the last window MUST contain WINDOW_SIZE tiles or less. 951 o tiles are numbered within each window. 953 o the tile numbers MUST decrement from WINDOW_SIZE - 1 downward, 954 looking from the start of the SCHC Packet toward its end. 956 o each tile of a SCHC Packet is therefore uniquely identified by a 957 window number and a tile number within this window. 959 See Figure 9 for an example. 961 +---------------------------------------------...-------------+ 962 | SCHC Packet | 963 +---------------------------------------------...-------------+ 965 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 | 966 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -| 968 Figure 9: a SCHC Packet fragmented in tiles grouped in 28 windows, 969 with WINDOW_SIZE = 5 971 When windows are used 973 o information on the correct reception of the tiles belonging to the 974 same window MUST be grouped together. 976 o it is RECOMMENDED that this information is kept in Bitmaps. 978 o Bitmaps MAY be sent back to the sender in a SCHC ACK message. 980 o Each window has a Bitmap. 982 8.2.2.3. Bitmaps 984 Each bit in the Bitmap for a window corresponds to a tile in the 985 window. Each Bitmap has therefore WINDOW_SIZE bits. The bit at the 986 left-most position corresponds to the tile numbered WINDOW_SIZE - 1. 987 Consecutive bits, going right, correspond to sequentially decreasing 988 tile numbers. In Bitmaps for windows that are not the last one of a 989 SCHC Packet, the bit at the right-most position corresponds to the 990 tile numbered 0. In the Bitmap for the last window, the bit at the 991 right-most position corresponds either to the tile numbered 0 or to a 992 tile that is sent/received as "the last one of the SCHC Packet" 993 without explicitely stating its number (see Section 8.3.1.2). 995 At the receiver 996 o a bit set to 1 in the Bitmap indicates that a tile associated with 997 that bit position has been correctly received for that window. 999 o a bit set to 0 in the Bitmap indicates that no tile associated 1000 with that bit position has been correctly received for that 1001 window. 1003 WINDOW_SIZE finely controls the size of the Bitmap sent in the SCHC 1004 ACK message, which may be critical to some LPWAN technologies. 1006 8.2.2.4. Timers and counters 1008 Some SCHC F/R modes can use the following timers and counters 1010 o Inactivity Timer: this timer can be used to unlock a SCHC Fragment 1011 receiver that is not receiving a SCHC F/R message while it is 1012 expecting one. 1014 o Retransmission Timer: this timer can be used by a SCHC Fragment 1015 sender to set a timeout on expecting a SCHC ACK. 1017 o Attempts: this counter counts the requests for SCHC ACKs. 1018 MAX_ACK_REQUESTS is the threshold at which an exception is raised. 1020 8.2.3. Integrity Checking 1022 The reassembled SCHC Packet is checked for integrity at the receive 1023 end. Integrity checking is performed by computing a MIC at the 1024 sender side and transmitting it to the receiver for comparison with 1025 the locally computed MIC. 1027 The MIC supports UDP checksum elision by SCHC C/D (see 1028 Section 10.11). 1030 The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of 1031 the polynomial used e.g. in the Ethernet standard [RFC3385]) is 1032 RECOMMENDED as the default algorithm for computing the MIC. 1033 Nevertheless, other MIC lengths or other algorithms MAY be required 1034 by the Profile. 1036 Note that the concatenation of the complete SCHC Packet and the 1037 potential padding bits of the last SCHC Fragment does not generally 1038 constitute an integer number of bytes. For implementers to be able 1039 to use byte-oriented CRC libraries, it is RECOMMENDED that the 1040 concatenation of the complete SCHC Packet and the last fragment 1041 potential padding bits be zero-extended to the next byte boundary and 1042 that the MIC be computed on that byte array. A Profile MAY specify 1043 another behaviour. 1045 8.2.4. Header Fields 1047 The SCHC F/R messages use the following fields (see the related 1048 formats in Section 8.3): 1050 o Rule ID: this field is present in all the SCHC F/R messages. It 1051 is used to identify 1053 * that a SCHC F/R message is being carried, as opposed to an 1054 unfragmented SCHC Packet, 1056 * which SCHC F/R mode is used 1058 * and among this mode 1060 + if windows are used and what the value of WINDOW_SIZE is, 1062 + what other optional fields are present and what the field 1063 sizes are. 1065 Therefore, the Rule ID allows SCHC F/R interleaving non-fragmented 1066 SCHC Packets and SCHC Fragments that carry other SCHC Packets, or 1067 interleaving SCHC Fragments that use different SCHC F/R modes or 1068 different parameters. 1070 o Datagram Tag (DTag). The DTag field is optional. Its presence 1071 and size (called T, in bits) is defined by each Profile for each 1072 Rule ID. 1074 When there is no DTag, there can be only one fragmented SCHC 1075 Packet in transit for a given Rule ID. 1077 If present, DTag 1079 * MUST be set to the same value for all the SCHC F/R messages 1080 related to the same fragmented SCHC Packet, 1082 * MUST be set to different values for SCHC F/R messages related 1083 to different SCHC Packets that are being fragmented under the 1084 same Rule ID and that may overlap during the fragmented 1085 transmission. 1087 A sequence counter that is incremented for each new fragmented 1088 SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to 1089 0 is RECOMMENDED for maximum traceability and replay avoidance. 1091 o W: The W field is optional. It is only present if windows are 1092 used. Its presence and size (called M, in bits) is defined by 1093 each SCHC F/R mode and each Profile for each Rule ID. 1095 This field carries information pertaining to the window a SCHC F/R 1096 message relates to. If present, W MUST carry the same value for 1097 all the SCHC F/R messages related to the same window. Depending 1098 on the mode and Profile, W may carry the full window number, or 1099 just the least significant bit or any other partial representation 1100 of the window number. 1102 o Fragment Compressed Number (FCN). The FCN field is present in the 1103 SCHC Fragment Header. Its size (called N, in bits) is defined by 1104 each Profile for each Rule ID. 1106 This field conveys information about the progress in the sequence 1107 of tiles being transmitted by SCHC Fragment messages. For 1108 example, it can contain a partial, efficient representation of a 1109 larger-sized tile number. The description of the exact use of the 1110 FCN field is left to each SCHC F/R mode. However, two values are 1111 reserved for special purposes. They help control the SCHC F/R 1112 process: 1114 * The FCN value with all the bits equal to 1 (called All-1) 1115 signals the very last tile of a SCHC Packet. By extension, if 1116 windows are used, the last window of a packet is called the 1117 All-1 window. 1119 * If windows are used, the FCN value with all the bits equal to 0 1120 (called All-0) signals the last tile of a window that is not 1121 the last one of the SCHC packet. By extension, such a window 1122 is called an All-0 window. 1124 The highest value of FCN (an unsigned integer) is called 1125 MAX_WIND_FCN. Since All-1 is reserved, MAX_WIND_FCN MUST be 1126 stricly less that (2^N)-1. 1128 o Message Integrity Check (MIC). This field only appears in the 1129 All-1 SCHC Fragments. Its size (called T, in bits) is defined by 1130 each Profile for each Rule ID. 1132 See Section 8.2.3 for the MIC default size, default polynomials 1133 and details on its computation. 1135 o C (integrity Check): C is a 1-bit field. This field is used in 1136 the SCHC ACK message to report on the reassembled SCHC Packet 1137 integrity check (see Section 8.2.3). 1139 A value of 1 tells that the integrity check was performed and is 1140 successful. A value of 0 tells that the integrity check was not 1141 performed, or that is was a failure. 1143 o Compressed Bitmap. The Compressed Bitmap is used together with 1144 windows and Bitmaps (see Section 8.2.2.3). Its presence and size 1145 is defined for each F/R mode for each Rule ID. 1147 This field appears in the SCHC ACK message to report on the 1148 receiver Bitmap (see Section 8.3.2.1). 1150 8.3. SCHC F/R Message Formats 1152 This section defines the SCHC Fragment formats, the SCHC ACK format, 1153 the SCHC ACK REQ format and the SCHC Abort formats. 1155 8.3.1. SCHC Fragment format 1157 A SCHC Fragment conforms to the general format shown in Figure 10. 1158 It comprises a SCHC Fragment Header and a SCHC Fragment Payload. The 1159 SCHC Fragment Payload carries one or several tile(s). 1161 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1162 | Fragment Header | Fragment Payload | padding (as needed) 1163 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1165 Figure 10: SCHC Fragment general format. Presence of a padding field 1166 is optional 1168 8.3.1.1. Regular SCHC Fragment 1170 The Regular SCHC Fragment format is shown in Figure 11. Regular SCHC 1171 Fragments are generally used to carry tiles that are not the last one 1172 of a SCHC Packet. The DTag field and the W field are optional. 1174 |--- SCHC Fragment Header ----| 1175 |-- T --|-M-|-- N --| 1176 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1177 | Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed) 1178 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1180 Figure 11: Detailed Header Format for Regular SCHC Fragments 1182 The FCN field MUST NOT contain all bits set to 1. 1184 If the size of the SCHC Fragment Payload does not nicely complement 1185 the SCHC Header size in a way that would make the SCHC Fragment a 1186 multiple of the L2 Word, then padding bits MUST be added. 1188 The Fragment Payload of a SCHC Fragment with FCN == 0 (called an 1189 All-0 SCHC Fragment) MUST be at least the size of an L2 Word. The 1190 rationale is that, even in the presence of padding, an All-0 SCHC 1191 Fragment needs to be distinguishable from the SCHC ACK REQ message, 1192 which has the same header but has no payload (see Section 8.3.3). 1194 8.3.1.2. All-1 SCHC Fragment 1196 The All-1 SCHC Fragment format is shown in Figure 12. The All-1 SCHC 1197 Fragment is generally used to carry the very last tile of a SCHC 1198 Packet and a MIC, or a MIC only. The DTag field, the W field and the 1199 Payload are optional. 1201 |-------- SCHC Fragment Header -------| 1202 |-- T --|-M-|-- N --| 1203 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1204 | Rule ID | DTag | W | 11..1 | MIC | Frag Payload | pad. (as needed) 1205 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1206 (FCN) 1208 Figure 12: Detailed format for the All-1 SCHC Fragment 1210 If the size of the SCHC Fragment Payload does not nicely complement 1211 the SCHC Header size in a way that would make the SCHC Fragment a 1212 multiple of the L2 Word, then padding bits MUST be added. 1214 The All-1 SCHC Fragment message MUST be distinguishable by size from 1215 a SCHC Sender-Abort message (see Section 8.3.4.1) that has the same 1216 T, M and N values. This is trivially achieved by having the MIC 1217 larger than an L2 Word, or by having the Payload larger than an L2 1218 Word. This is also naturally achieved if the SCHC Sender-Abort 1219 Header is a multiple of L2 Words. 1221 8.3.2. SCHC ACK format 1223 The SCHC ACK message MUST obey the format shown in Figure 13. The 1224 DTag field, the W field and the Compressed Bitmap field are optional. 1225 The Compressed Bitmap field can only be present in SCHC F/R modes 1226 that use windows. 1228 |---- SCHC ACK Header ----| 1229 |-- T --|-M-|1| 1230 +---- ... --+- ... -+---+-+~~~~~~~~~~~~~~~~~~ 1231 | Rule ID | DTag | W |1| padding as needed (success) 1232 +---- ... --+- ... -+---+-+~~~~~~~~~~~~~~~~~~ 1234 +---- ... --+- ... -+---+-+------ ... ------+~~~~~~~~~~~~~~~ 1235 | Rule ID | DTag | W |0|Compressed Bitmap| pad. as needed (failure) 1236 +---- ... --+- ... -+---+-+------ ... ------+~~~~~~~~~~~~~~~ 1237 C 1239 Figure 13: Format of the SCHC ACK message 1241 The SCHC ACK Header contains a C bit (see Section 8.2.4). 1243 If the C bit is set to 1 (integrity check successful), no Bitmap is 1244 carried and padding bits MUST be appended as needed to fill up the 1245 last L2 Word. 1247 If the C bit is set to 0 (integrity check not performed or failed) 1248 and if windows are used, 1250 o a representation of the Bitmap for the window referred to by the W 1251 field MUST follow the C bit 1253 o padding bits MUST be appended as needed to fill up the last L2 1254 Word 1256 If the C bit is 1 or windows are not used, the C bit MUST be followed 1257 by padding bits as needed to fill up the last L2 Word. 1259 See Section 8.2.2.3 for a description of the Bitmap. 1261 The representation of the Bitmap that is transmitted MUST be the 1262 compressed version specified in Section 8.3.2.1, in order to reduce 1263 the SCHC ACK message size. 1265 8.3.2.1. Bitmap Compression 1267 For transmission, the Compressed Bitmap in the SCHC ACK message is 1268 defined by the following algorithm (see Figure 14 for a follow-along 1269 example): 1271 o Build a temporary SCHC ACK message that contains the Header 1272 followed by the original Bitmap. 1274 o Positioning scissors at the end of the Bitmap, after its last bit. 1276 o While the bit on the left of the scissors is 1 and belongs to the 1277 Bitmap, keep moving left, then stop. When this is done, 1279 o While the scissors are not on an L2 Word boundary of the SCHC ACK 1280 message and there is a Bitmap bit on the right of the scissors, 1281 keep moving right, then stop. 1283 o At this point, cut and drop off any bits to the right of the 1284 scissors 1286 When one or more bits have effectively been dropped off as a result 1287 of the above algorithm, the SCHC ACK message is a multiple of L2 1288 Words, no padding bits will be appended. 1290 Because the SCHC Fragment sender knows the size of the original 1291 Bitmap, it can reconstruct the original Bitmap from the Compressed 1292 Bitmap received in the SCH ACK message. 1294 Figure 14 shows an example where L2 Words are actually bytes and 1295 where the original Bitmap contains 17 bits, the last 15 of which are 1296 all set to 1. 1298 |---- SCHC ACK Header ----|-------- Bitmap --------| 1299 |-- T --|-M-|1| 1300 +---- ... --+- ... -+---+-+---------------------------------+ 1301 | Rule ID | DTag | W |0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| 1302 +---- ... --+- ... -+---+-+---------------------------------+ 1303 C | 1304 next L2 Word boundary ->| 1306 Figure 14: Tentative SCHC ACK message with Bitmap before compression 1308 Figure 15 shows that the last 14 bits are not sent. 1310 |---- SCHC ACK Header ----|CpBmp| 1311 |-- T --|-M-|1| 1312 +---- ... --+- ... -+---+-+-----+ 1313 | Rule ID | DTag | W |0|1 0 1| 1314 +---- ... --+- ... -+---+-+-----+ 1315 C | 1316 next L2 Word boundary ->| 1318 Figure 15: Actual SCHC ACK message with Compressed Bitmap, no padding 1320 Figure 16 shows an example of a SCHC ACK with tile numbers ranging 1321 from 6 down to 0, where the Bitmap indicates that the second and the 1322 fourth tile of the window have not been correctly received. 1324 |---- SCHC ACK Header ----|--- Bitmap --| 1325 |-- T --|-M-|1|6 5 4 3 2 1 0| (tile #) 1326 +-----------+-------+---+-+-------------+ 1327 | Rule ID | DTag | W |0|1 0 1 0 1 1 1| with Original Bitmap 1328 +-----------+-------+---+-+-------------+ 1329 C 1330 next L2 Word boundary ->|<-- L2 Word -->| 1332 +-----------+-------+---+-+-------------+~~~+ 1333 | Rule ID | DTag | W |0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK 1334 +-----------+-------+---+-+-------------+~~~+ 1335 C 1336 next L2 Word boundary ->|<-- L2 Word -->| 1338 Figure 16: Example of a SCHC ACK message, missing tiles, with padding 1340 Figure 17 shows an example of a SCHC ACK with FCN ranging from 6 down 1341 to 0, where integrity check has not been performed or has failed and 1342 the Bitmap indicates that there is no missing tile in that window. 1344 |---- SCHC ACK Header ----|--- Bitmap --| 1345 |-- T --|-M-|1|6 5 4 3 2 1 0| (tile #) 1346 +-----------+-------+---+-+-------------+ 1347 | Rule ID | DTag | W |0|1 1 1 1 1 1 1| with Original Bitmap 1348 +-----------+-------+---+-+-------------+ 1349 C 1350 next L2 Word boundary ->| 1352 +---- ... --+- ... -+---+-+-+ 1353 | Rule ID | DTag | W |0|1| transmitted SCHC ACK 1354 +---- ... --+- ... -+---+-+-+ 1355 C 1356 next L2 Word boundary ->| 1358 Figure 17: Example of a SCHC ACK message, no missing tile, no padding 1360 8.3.3. SCHC ACK REQ format 1362 The SCHC ACK REQ is used by a sender to explicitely request a SCHC 1363 ACK from the receiver. Its format is described in Figure 18. The 1364 DTag field and the W field are optional. 1366 |---- SCHC ACK REQ Header ----| 1367 |-- T --|-M-|-- N --| 1368 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1369 | Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) 1370 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1372 Figure 18: SCHC ACK REQ detailed format 1374 The size of the SCHC ACK REQ header is generally not a multiple of 1375 the L2 Word size. Therefore, a SCHC ACK REQ generally needs padding 1376 bits. 1378 Note that the SCHC ACK REQ has the same header as an All-0 SCHC 1379 Fragment (see Section 8.3.1.1) but it doesn't have a payload. A 1380 receiver can distinguish the former form the latter by the message 1381 length, even in the presence of padding. This is possible because 1383 o the padding bits are always stricly less than an L2 Word. 1385 o the size of an All-0 SCHC Fragment Payload is at least the size of 1386 an L2 Word, 1388 8.3.4. SCHC Abort formats 1390 8.3.4.1. SCHC Sender-Abort 1392 When a SCHC Fragment sender needs to abort an on-going fragmented 1393 SCHC Packet transmission, it sends a SCHC Sender-Abort message to the 1394 SCHC Fragment receiver. 1396 The SCHC Sender-Abort format is described in Figure 19. The DTag 1397 field and the W field are optional. 1399 |---- Sender-Abort Header ----| 1400 |-- T --|-M-|-- N --| 1401 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1402 | Rule ID | DTag | W | 11..1 | padding (as needed) 1403 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1405 Figure 19: SCHC Sender-Abort format 1407 If the W field is present, 1409 o the fragment sender MUST set it to all 1's. Other values are 1410 RESERVED. 1412 o the fragment receiver MUST check its value. If the value is 1413 different from all 1's, the message MUST be ignored. 1415 The size of the SCHC Sender-Abort header is generally not a multiple 1416 of the L2 Word size. Therefore, a SCHC Sender-Abort generally needs 1417 padding bits. 1419 Note that the SCHC Sender-Abort has the same header as an All-1 SCHC 1420 Fragment (see Section 8.3.1.2), but that it does not include a MIC 1421 nor a payload. The receiver distinguishes the former from the latter 1422 by the message length, even in the presence of padding. This is 1423 possible through different combinations 1425 o the size of the Sender-Abort Header may be made such that it is 1426 not padded 1428 o or the total size of the MIC and the Payload of an All-1 SCHC 1429 Fragment is at least the size of an L2 Word 1431 o or through other alignment and size combinations 1433 The SCHC Sender-Abort MUST NOT be acknowledged. 1435 8.3.4.2. SCHC Receiver-Abort 1437 When a SCHC Fragment receiver needs to abort an on-going fragmented 1438 SCHC Packet transmission, it transmits a SCHC Receiver-Abort message 1439 to the SCHC Fragment sender. 1441 The SCHC Receiver-Abort format is described in Figure 20. The DTag 1442 field and the W field are optional. 1444 |--- Receiver-Abort Header ---| 1445 |--- T ---|-M-|1| 1446 +---- ... ----+-- ... --+---+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Rule ID | DTag | W |1| 1..1| 1..1 | 1448 +---- ... ----+-- ... --+---+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 C 1450 next L2 Word boundary ->|<-- L2 Word -->| 1452 Figure 20: SCHC Receiver-Abort format 1454 If the W field is present, 1456 o the fragment receiver MUST set it to all 1's. Other values are 1457 RESERVED. 1459 o the fragment sender MUST check its value. If the value is 1460 different from all 1's, the message MUST be ignored. 1462 Note that the SCHC Receiver-Abort has the same header as a SCHC ACK 1463 message. The bits that follow the SCHC Receiver-Abort Header MUST be 1464 as follows 1466 o if the Header does not end at an L2 Word boundary, append bits set 1467 to 1 as needed to reach the next L2 Word boundary 1469 o append exactly one more L2 Word with bits all set to 1's 1471 Such a bit pattern never occurs in a regular SCHC ACK. This is how 1472 the fragment sender recognizes a SCHC Receiver-Abort. 1474 A SCHC Receiver-Abort is aligned to L2 Words, by design. Therefore, 1475 padding MUST NOT be appended. 1477 The SCHC Receiver-Abort MUST NOT be acknowledged. 1479 8.4. SCHC F/R modes 1481 This specification includes several SCHC F/R modes, which allow for 1483 o a range of reliability options, such as optional SCHC Fragment 1484 retransmission 1486 o support of different LPWAN characteristics, such as variable MTU. 1488 More modes may be defined in the future. 1490 8.4.1. No-ACK mode 1492 The No-ACK mode has been designed under the assumption that data unit 1493 out-of-sequence delivery does not occur between the entity performing 1494 fragmentation and the entity performing reassembly. This mode 1495 supports LPWAN technologies that have a variable MTU. 1497 In No-ACK mode, there is no feedback communication from the fragment 1498 receiver to the fragment sender. The sender just transmits all the 1499 SCHC Fragments blindly. 1501 Padding is kept to a minimum: only the last SCHC Fragment is padded 1502 as needed. 1504 The tile sizes are not required to be uniform. Windows are not used. 1505 The Retransmission Timer is not used. The Attempts counter is not 1506 used. 1508 Each Profile MUST specify which Rule ID value(s) is (are) allocated 1509 to this mode. For brevity, the rest of Section 8.4.1 only refers to 1510 Rule ID values that are allocated to this mode. 1512 The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK 1513 MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort 1514 MAY be sent. SCHC Receiver-Abort MUST NOT be sent. 1516 The value of N (size of the FCN field) is RECOMMENDED to be 1. 1518 Each Profile, for each Rule ID value, MUST define 1520 o the presence or absence of the DTag field in the SCHC F/R 1521 messages, as well as its size if it is present, 1523 o the size and algorithm for the MIC field in the SCHC F/R messages, 1524 if different from the default, 1526 o the expiration time of the Inactivity Timer 1528 Each Profile, for each Rule ID value, MAY define 1530 o a value of N different from the recommend one, 1532 o what values will be sent in the FCN field, for values different 1533 from the All-1 value. 1535 The receiver, for each pair of Rule ID and optional DTag values, MUST 1536 maintain 1538 o one Inactivity Timer 1540 8.4.1.1. Sender behaviour 1542 At the beginning of the fragmentation of a new SCHC Packet, the 1543 fragment sender MUST select a Rule ID and optional DTag value pair 1544 for this SCHC Packet. For brevity, the rest of Section 8.4.1 only 1545 refers to SCHC F/R messages bearing the Rule ID and optional DTag 1546 values hereby selected. 1548 Each SCHC Fragment MUST contain exactly one tile in its Payload. The 1549 tile MUST be at least the size of an L2 Word. The sender MUST 1550 transmit the SCHC Fragments messages in the order that the tiles 1551 appear in the SCHC Packet. Except for the last tile of a SCHC 1552 Packet, each tile MUST be of a size that complements the SCHC 1553 Fragment Header so that the SCHC Fragment is a multiple of L2 Words 1554 without the need for padding bits. Except for the last one, the SCHC 1555 Fragments MUST use the Regular SCHC Fragment format specified in 1556 Section 8.3.1.1. The last SCHC Fragment MUST use the All-1 format 1557 specified in Section 8.3.1.2. 1559 The MIC MUST be computed on the reassembled SCHC Packet concatenated 1560 with the padding bits of the last SCHC Fragment. The rationale is 1561 that the SCHC Reassembler has no way of knowing where the payload of 1562 the last SCHC Fragment ends. Indeed, this requires decompressing the 1563 SCHC Packet, which is out of the scope of the SCHC Reassembler. 1565 The sender MAY transmit a SCHC Sender-Abort. 1567 Figure 35 shows an example of a corresponding state machine. 1569 8.4.1.2. Receiver behaviour 1571 On receiving Regular SCHC Fragments, 1573 o the receiver MUST reset the Inactivity Timer, 1575 o the receiver assembles the payloads of the SCHC Fragments 1577 On receiving an All-1 SCHC Fragment, 1579 o the receiver MUST append the All-1 SCHC Fragment Payload and the 1580 padding bits to the previously received SCHC Fragment Payloads for 1581 this SCHC Packet 1583 o if an integrity checking is specified in the Profile, 1585 * the receiver MUST perform the integrity check 1587 * if integrity checking fails, the receiver MUST drop the 1588 reassembled SCHC Packet and it MUST release all resources 1589 associated with this Rule ID and optional DTag values. 1591 o the reassembly operation concludes. 1593 On expiration of the Inactivity Timer, the receiver MUST drop the 1594 SCHC Packet being reassembled and it MUST release all resources 1595 associated with this Rule ID and optional DTag values. 1597 On receiving a SCHC Sender-Abort, the receiver MAY release all 1598 resources associated with this Rule ID and optional DTag values. 1600 The MIC computed at the receiver MUST be computed over the 1601 reassembled SCHC Packet and over the padding bits that were received 1602 in the SCHC Fragment carrying the last tile. 1604 Figure 36 shows an example of a corresponding state machine. 1606 8.4.2. ACK-Always 1608 The ACK-Always mode has been designed under the following assumptions 1610 o Data unit out-of-sequence delivery does not occur between the 1611 entity performing fragmentation and the entity performing 1612 reassembly 1614 o The L2 MTU value does not change while a fragmented SCHC Packet is 1615 being transmitted. 1617 In ACK-Always mode, windows are used. An acknowledgement, positive 1618 or negative, is fed by the fragment receiver back to the fragment 1619 sender at the end of the transmission of each window of SCHC 1620 Fragments. 1622 The tiles are not required to be of uniform size. Padding is kept to 1623 a minimum: only the last SCHC Fragment is padded as needed. 1625 In a nutshell, the algorithm is the following: after a first blind 1626 transmission of all the tiles of a window, the fragment sender 1627 iterates retransmitting the tiles that are reported missing until the 1628 fragment receiver reports that all the tiles belonging to the window 1629 have been correctly received, or until too many attempts were made. 1630 The fragment sender only advances to the next window of tiles when it 1631 has ascertained that all the tiles belonging to the current window 1632 have been fully and correctly received. This results in a lock-step 1633 behaviour between the sender and the receiver, at the window 1634 granularity. 1636 Each Profile MUST specify which Rule ID value(s) is (are) allocated 1637 to this mode. For brevity, the rest of Section 8.4.1 only refers to 1638 Rule ID values that are allocated to this mode. 1640 The W field MUST be present and its size M MUST be 1 bit. 1641 WINDOW_SIZE MUST be equal to MAX_WIND_FCN + 1. 1643 Each Profile, for each Rule ID value, MUST define 1645 o the value of N (size of the FCN field), 1647 o the value of MAX_WIND_FCN 1649 o the size and algorithm for the MIC field in the SCHC F/R messages, 1650 if different from the default, 1652 o the presence or absence of the DTag field in the SCHC F/R 1653 messages, as well as its size if it is present, 1655 o the value of MAX_ACK_REQUESTS, 1657 o the expiration time of the Retransmission Timer 1659 o the expiration time of the Inactivity Timer 1661 The sender, for each active pair of Rule ID and optional DTag values, 1662 MUST maintain 1664 o one Attempts counter 1666 o one Retransmission Timer 1668 The receiver, for each pair of Rule ID and optional DTag values, MUST 1669 maintain 1671 o one Inactivity Timer 1673 8.4.2.1. Sender behaviour 1675 At the beginning of the fragmentation of a new SCHC Packet, the 1676 fragment sender MUST select a Rule ID and DTag value pair for this 1677 SCHC Packet. For brevity, the rest of Section 8.4.2 only refers to 1678 SCHC F/R messages bearing the Rule ID and optional DTag values hereby 1679 selected. 1681 Each SCHC Fragment MUST contain exactly one tile in its Payload. All 1682 tiles with the number 0 in their window, as well as the last tile, 1683 MUST be at least the size of an L2 Word. 1685 In all SCHC Fragment messages, the W field MUST be filled with the 1686 least significant bit of the window number that the sender is 1687 currently processing. 1689 If a SCHC Fragment carries a tile that is not the last one of the 1690 SCHC Packet, 1692 o it MUST be of the Regular type specified in Section 8.3.1.1 1694 o the FCN field MUST contain the tile number 1696 o each tile MUST be of a size that complements the SCHC Fragment 1697 Header so that the SCHC Fragment is a multiple of L2 Words without 1698 the need for padding bits. 1700 The SCHC Fragment that carries the last tile MUST be an All-1 SCHC 1701 Fragment, described in Section 8.3.1.2. 1703 The bits on which the MIC is computed MUST be the SCHC Packet 1704 concatenated with the potential padding bits that are appended to the 1705 Payload of the SCHC Fragment that carries the last tile. 1707 The fragment sender MUST start by processing the window numbered 0. 1709 In a "blind transmission" phase, it MUST transmit all the tiles 1710 composing the window, in decreasing tile number. 1712 Then, it enters an "equalization phase" in which it MUST initialize 1713 an Attempts counter to 0, it MUST start a Retransmission Timer and it 1714 MUST expect to receive a SCHC ACK. Then, 1716 o on receiving a SCHC ACK, 1718 * if the SCHC ACK indicates that some tiles are missing at the 1719 receiver, then the sender MUST transmit all the tiles that have 1720 been reported missing, it MUST increment Attempts, it MUST 1721 reset the Retransmission Timer and MUST expect to receive a 1722 SCHC ACK again. 1724 * if the current window is not the last one and the SCHC ACK 1725 indicates that all tiles were correctly received, the sender 1726 MUST stop the Retransmission Timer, it MUST advance to the next 1727 fragmentation window and it MUST start a blind transmission 1728 phase as described above. 1730 * if the current window is the last one and the SCHC ACK 1731 indicates that more tiles were received than the sender 1732 actually sent, the fragment sender MUST send a SCHC Sender- 1733 Abort, it MUST release all resource associated with this SCHC 1734 Packet and it MAY exit with an error condition. 1736 * if the current window is the last one and the SCHC ACK 1737 indicates that all tiles were correctly received yet integrity 1738 check was a failure, the fragment sender MUST send a SCHC 1739 Sender-Abort, it MUST release all resource associated with this 1740 SCHC Packet and it MAY exit with an error condition. 1742 * if the current window is the last one and the SCHC ACK 1743 indicates that integrity checking was successful, the sender 1744 exits successfully. 1746 o on Retransmission Timer expiration, 1747 * if Attempts is strictly less that MAX_ACK_REQUESTS, the 1748 fragment sender MUST send a SCHC ACK REQ and MUST increment the 1749 Attempts counter. 1751 * otherwise the fragment sender MUST send a SCHC Sender-Abort, it 1752 MUST release all resource associated with this SCHC Packet and 1753 it MAY exit with an error condition. 1755 At any time, 1757 o on receiving a SCHC Receiver-Abort, the fragment sender MUST 1758 release all resource associated with this SCHC Packet and it MAY 1759 exit with an error condition. 1761 o on receiving a SCHC ACK that bears a W value different from the W 1762 value that it currently uses, the fragment sender MUST silently 1763 discard and ignore that SCHC ACK. 1765 Figure 37 shows an example of a corresponding state machine. 1767 8.4.2.2. Receiver behaviour 1769 On receiving a SCHC Fragment with a Rule ID and optional DTag pair 1770 not being processed at that time 1772 o the receiver MAY check if the optional DTag value has not recently 1773 been used for that Rule ID value, thereby ensuring that the 1774 received SCHC Fragment is not a remnant of a prior fragmented SCHC 1775 Packet transmission. If the SCHC Fragment is determined to be 1776 such a remant, the receiver MAY silently ignore it and discard it. 1778 o the receiver MUST start a process to assemble a new SCHC Packet 1779 with that Rule ID and DTag value pair. That process MUST only 1780 examine received SCHC F/R messages with that Rule ID and DTag 1781 value pair and MUST only transmit SCHC F/R messages with that Rule 1782 ID and DTag value pair. 1784 o the receiver MUST start an Inactivity Timer. It MUST initialise 1785 an Attempts counter to 0. It MUST initialise a window counter to 1786 0. 1788 In the rest of this section, "local W bit" means the least 1789 significant bit of the window counter of the receiver. 1791 On reception of any SCHC F/R message, the receiver MUST reset the 1792 Inactivity Timer. 1794 Entering an "acceptance phase", the receiver MUST first initialise an 1795 empty Bitmap for this window, then 1797 o on receiving a SCHC Fragment or SCHC ACK REQ with the W bit 1798 different from the local W bit, the receiver MUST silently ignore 1799 and discard that message. 1801 o on receiving a SCHC Fragment with the W bit equal to the local W 1802 bit, the receiver MUST assemble the received tile based on the 1803 window counter and on the FCN field in the SCHC Fragment and it 1804 MUST update the Bitmap. 1806 * if the SCHC Fragment received is an All-0 SCHC Fragment, the 1807 current window is determined to be a not-last window, and the 1808 receiver MUST send a SCHC ACK for this window. Then, 1810 + If the Bitmap indicates that all the tiles of the current 1811 window have been correctly received, the receiver MUST 1812 increment its window counter and it enters the "acceptance 1813 phase" for that new window. 1815 + If the Bitmap indicates that at least one tile is missing in 1816 the current window, the receiver enters the "equalization 1817 phase" for this window. 1819 * if the SCHC Fragment received is an All-1 SCHC Fragment, the 1820 padding bits of the All-1 SCHC Fragment MUST be assembled after 1821 the received tile, the current window is determined to be the 1822 last window, the receiver MUST perform the integrity check and 1823 it MUST send a SCHC ACK for this window. Then, 1825 + If the integrity check indicates that the full SCHC Packet 1826 has been correctly reassembled, the receiver MUST enter the 1827 "clean-up phase". 1829 + If the integrity check indicates that the full SCHC Packet 1830 has not been correctly reassembled, the receiver enters the 1831 "equalization phase" for this window. 1833 o on receiving a SCHC ACK REQ with the W bit equal to the local W 1834 bit, the receiver has not yet determined if the current window is 1835 a not-last one or the last one, the receiver MUST send a SCHC ACK 1836 for this window, and it keeps accepting incoming messages. 1838 In the "equalization phase": 1840 o if the window is a not-last window 1841 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1842 different from the local W bit the receiver MUST silently 1843 ignore and discard that message. 1845 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1846 bit, the receiver MUST send a SCHC ACK for this window. 1848 * on receiving a SCHC Fragment with a W bit equal to the local W 1849 bit, 1851 + if the SCHC Fragment received is an All-1 SCHC Fragment, the 1852 receiver MUST silently ignore it and discard it. 1854 + otherwise, the receiver MUST update the Bitmap and it MUST 1855 assemble the tile received. 1857 * on the Bitmap becoming fully populated with 1's, the receiver 1858 MUST send a SCHC ACK for this window, it MUST increment its 1859 window counter and it enters the "acceptance phase" for the new 1860 window. 1862 o if the window is the last window 1864 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1865 different from the local W bit the receiver MUST silently 1866 ignore and discard that message. 1868 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1869 bit, the receiver MUST send a SCHC ACK for this window. 1871 * on receiving a SCHC Fragment with a W bit equal to the local W 1872 bit, 1874 + if the SCHC Fragment received is an All-0 SCHC Fragment, the 1875 receiver MUST silently ignore it and discard it. 1877 + otherwise, the receiver MUST update the Bitmap and it MUST 1878 assemble the tile received. If the SCHC Fragment received 1879 is an All-1 SCHC Fragment, the receiver MUST assemble the 1880 padding bits of the All-1 SCHC Fragment after the received 1881 tile. It MUST perform the integrity check. Then 1883 - if the integrity check indicates that the full SCHC 1884 Packet has been correctly reassembled, the receiver MUST 1885 send a SCHC ACK and it enters the "clean-up phase". 1887 - if the integrity check indicates that the full SCHC 1888 Packet has not been correctly reassembled, 1889 o if the SCHC Fragment received was an All-1 SCHC 1890 Fragment, the receiver MUST send a SCHC ACK for this 1891 window 1893 o it keeps accepting incoming messages. 1895 In the "clean-up phase": 1897 o Any received SCHC F/R message with a W bit different from the 1898 local W bit MUST be silently ignored and discarded. 1900 o Any received SCHC F/R message different from an All-1 SCHC 1901 Fragment or a SCHC ACK REQ MUST be silently ignored and discarded. 1903 o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, the 1904 receiver MUST send a SCHC ACK. 1906 o On expiration of the Inactivity Timer, the receive process for 1907 that SCHC Packet MAY exit 1909 At any time, on expiration of the Inactivity Timer, on receiving a 1910 SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the 1911 receiver MUST send a SCHC Receiver-Abort, it MUST release all 1912 resource associated with this SCHC Packet and it MAY exit the receive 1913 process for that SCHC Packet. 1915 The MIC computed at the receiver MUST be computed over the 1916 reassembled SCHC Packet and over the padding bits that were received 1917 in the SCHC Fragment carrying the last tile. 1919 Figure 38 shows an example of a corresponding state machine. 1921 8.4.3. ACK-on-Error 1923 The ACK-on-Error mode supports LPWAN technologies that have variable 1924 MTU and out-of-order delivery. 1926 In ACK-on-Error mode, windows are used. All tiles MUST be of equal 1927 size, except for the last one, which MUST be of the same size or 1928 smaller than the preceding ones. WINDOW_SIZE MUST be equal to 1929 MAX_WIND_FCN + 1. 1931 A SCHC Fragment message carries one or more tiles, which may span 1932 multiple windows. A SCHC ACK reports on the reception of exactly one 1933 window of tiles. 1935 See Figure 21 for an example. 1937 +---------------------------------------------...-----------+ 1938 | SCHC Packet | 1939 +---------------------------------------------...-----------+ 1941 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| 1942 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| 1944 SCHC Fragment msg |-----------| 1946 Figure 21: a SCHC Packet fragmented in tiles, Ack-on-Error mode 1948 The W field is wide enough that it unambiguously represents an 1949 absolute window number. The fragment receiver feeds SCHC ACKs back 1950 to the fragment sender about windows that it misses tiles of. No 1951 SCHC ACK is fed back by the fragment receiver for windows that it 1952 knows have been fully received. 1954 The fragment sender retransmits SCHC Fragments for tiles that are 1955 reported missing. It can advance to next windows even before it has 1956 ascertained that all tiles belonging to previous windows have been 1957 correctly received, and can still later retransmit SCHC Fragments 1958 with tiles belonging to previous windows. Therefore, the sender and 1959 the receiver may operate in a fully decoupled fashion. The 1960 fragmented SCHC Packet transmission concludes when 1962 o integrity checking shows that the fragmented SCHC Packet has been 1963 correctly reassembled at the receive end, and this information has 1964 been conveyed back to the sender, 1966 o or too many retransmission attempts were made, 1968 o or the receiver determines that the transmission of this 1969 fragmented SCHC Packet has been inactive for too long. 1971 Each Profile MUST specify which Rule ID value(s) is (are) allocated 1972 to this ACK-on-Error mode. For brevity, the rest of Section 8.4.3 1973 only refers to SCHC F/R messages with Rule ID values that are 1974 allocated to this mode. 1976 The W field MUST be present in the SCHC F/R messages. 1978 Each Profile, for each Rule ID value, MUST define 1980 o the tile size (a tile does not need to be multiple of an L2 Word, 1981 but it MUST be at least the size of an L2 Word) 1983 o the value of M (size of the W field), 1984 o the value of N (size of the FCN field), 1986 o the value of MAX_WIND_FCN 1988 o the size and algorithm for the MIC field in the SCHC F/R messages, 1989 if different from the default, 1991 o the presence or absence of the DTag field in the SCHC F/R 1992 messages, as well as its size if it is present, 1994 o the value of MAX_ACK_REQUESTS, 1996 o the expiration time of the Retransmission Timer 1998 o the expiration time of the Inactivity Timer 2000 The sender, for each active pair of Rule ID and optional DTag values, 2001 MUST maintain 2003 o one Attempts counter 2005 o one Retransmission Timer 2007 The receiver, for each pair of Rule ID and optional DTag values, MUST 2008 maintain 2010 o one Inactivity Timer 2012 8.4.3.1. Sender behaviour 2014 At the beginning of the fragmentation of a new SCHC Packet, 2016 o the fragment sender MUST select a Rule ID and DTag value pair for 2017 this SCHC Packet. A Rule MUST NOT be selected if the values of M 2018 and MAX_WIND_FCN for that Rule are such that the SCHC Packet 2019 cannot be fragmented in (2ˆM) * (MAX_WIND_FCN+1) tiles or 2020 less. 2022 o the fragment sender MUST initialize the Attempts counter to 0 for 2023 that Rule ID and DTag value pair. 2025 For brevity, the rest of Section 8.4.3 only refers to SCHC F/R 2026 messages bearing the Rule ID and optional DTag values hereby 2027 selected. 2029 A SCHC Fragment message carries in its payload one or more tiles. If 2030 more than one tile is carried in one SCHC Fragment 2031 o the selected tiles MUST be consecutive in the original SCHC Packet 2033 o they MUST be placed in the SCHC Fragment Payload adjacent to one 2034 another, in the order they appear in the SCHC Packet, from the 2035 start of the SCHC Packet toward its end. 2037 In a SCHC Fragment message, the sender MUST fill the W field with the 2038 window number of the first tile sent in that SCHC Fragment. 2040 If a SCHC Fragment carries more than one tile, or carries one tile 2041 that is not the last one of the SCHC Packet, 2043 o it MUST be of the Regular type specified in Section 8.3.1.1 2045 o the FCN field MUST contain the tile number of the first tile sent 2046 in that SCHC Fragment 2048 o padding bits are appended to the tiles as needed to fit the 2049 Payload size constraint of Regular SCHC Fragments 2051 The bits on which the MIC is computed MUST be the SCHC Packet 2052 concatenated with the padding bits that are appended to the Payload 2053 of the SCHC Fragment that carries the last tile. 2055 The fragment sender MAY send the last tile as the Payload of an All-1 2056 SCHC Fragment. 2058 The fragment sender MUST send SCHC Fragments such that, all together, 2059 they contain all the tiles of the fragmented SCHC Packet. 2061 The fragment sender MUST send at least one All-1 SCHC Fragment. 2063 Note that the last tile of a SCHC Packet can be sent in different 2064 ways, depending on Profiles and implementations 2066 o in a Regular SCHC Fragment, either alone or as part of multiple 2067 tiles Payload 2069 o in an All-1 SCHC Fragment 2071 However, the last tile MUST NOT have ever been sent both in a Regular 2072 SCHC Fragment and in a All-1 SCHC Fragment. 2074 The fragment sender MUST listen for SCHC ACK messages after having 2075 sent 2077 o an All-1 SCHC Fragment 2078 o or a SCHC ACK REQ with the W field corresponding to the last 2079 window. 2081 A Profile MAY specify other times at which the fragment sender MUST 2082 listen for SCHC ACK messages. 2084 Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC 2085 ACK REQ, 2087 o it MUST increment the Attempts counter 2089 o it MUST reset the Retransmission Timer 2091 On Retransmission Timer expiration 2093 o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment 2094 sender MUST send a SCHC ACK REQ with the W field corresponding to 2095 the last window and it MUST increment the Attempts counter 2097 o otherwise the fragment sender MUST send a SCHC Sender-Abort and it 2098 MUST release all resource associated with this SCHC Packet. 2100 On receiving a SCHC ACK, 2102 o if the W field in the SCHC ACK corresponds to the last window of 2103 the SCHC Packet, 2105 * if the C bit is set, the sender MAY release all resource 2106 associated with this SCHC Packet and MAY exit successfully 2108 * otherwise, 2110 + if the SCHC ACK shows no missing tile at the receiver, the 2111 sender 2113 - MUST send a SCHC Sender-Abort 2115 - MUST release all resource associated with this SCHC 2116 Packet 2118 - MAY exit with an error condition 2120 + otherwise 2122 - the fragment sender MUST send SCHC Fragment messages 2123 containing all the tiles that are reported missing in the 2124 SCHC ACK. 2126 - if the last message in this sequence of SCHC Fragment 2127 messages is not an All-1 SCHC Fragment, then the fragment 2128 sender MUST send a SCHC ACK REQ with the W field 2129 corresponding to the last window after the sequence. 2131 o otherwise, the fragment sender 2133 * MUST send SCHC Fragment messages containing the tiles that are 2134 reported missing in the SCHC ACK 2136 * then it MAY send a SCHC ACK REQ with the W field corresponding 2137 to the last window 2139 See Figure 39 for one among several possible examples of a Finite 2140 State Machine implementing a sender behaviour obeying this 2141 specification. 2143 8.4.3.2. Receiver behaviour 2145 On receiving a SCHC Fragment with a Rule ID and optional DTag pair 2146 not being processed at that time 2148 o the receiver MAY check if the optional DTag value has not recently 2149 been used for that Rule ID value, thereby ensuring that the 2150 received SCHC Fragment is not a remnant of a prior fragmented SCHC 2151 Packet transmission. If the SCHC Fragment is determined to be 2152 such a remant, the receiver MAY silently ignore it and discard it. 2154 o the receiver MUST start a process to assemble a new SCHC Packet 2155 with that Rule ID and DTag value pair. That process MUST only 2156 examine received SCHC F/R messages with that Rule ID and DTag 2157 value pair and MUST only transmit SCHC F/R messages with that Rule 2158 ID and DTag value pair. 2160 o the receiver MUST start an Inactivity Timer. It MUST initialise 2161 an Attempts counter to 0. 2163 On reception of any SCHC F/R message, the receiver MUST reset the 2164 Inactivity Timer. 2166 On reception of a SCHC Fragment message, the receiver MUST assemble 2167 the received tiles based on the W and FCN fields of the SCHC 2168 Fragment. 2170 o if the FCN is All-1, if a Payload is present, the full SCHC 2171 Fragment Payload MUST be assembled including the padding bits. 2172 This is because the size of the last tile is not known by the 2173 receiver, therefore padding bits are indistinguishable from the 2174 tile data bits, at this stage. They will be removed by the SCHC 2175 C/D sublayer. If the size of the SCHC Fragment Payload exceeds or 2176 equals the size of one regular tile plus the size of an L2 Word, 2177 this SHOULD raise an error flag. 2179 o otherwise, tiles MUST be assembled based on the a priori known 2180 size and padding bits MUST be discarded. The latter is possible 2181 because 2183 * the size of the tiles is known a priori, 2185 * tiles are larger than an L2 Word 2187 * padding bits are always strictly less than an L2 Word 2189 On reception of a SCHC ACK REQ or of an All-1 SCHC Fragment, 2191 o if the receiver has at least one window that it knows has tiles 2192 missing, it MUST return a SCHC ACK for the lowest-numbered such 2193 window, 2195 o otherwise, 2197 * if it has received at least one tile, it MUST return a SCHC ACK 2198 for the highest-numbered window it currently has tiles for 2200 * otherwise it MUST return a SCHC ACK for window numbered 0 2202 A Profile MAY specify other times and circumstances at which a 2203 receiver sends a SCHC ACK, and which window the SCHC ACK reports 2204 about in these circumstances. 2206 On sending a SCHC ACK, the receiver MUST increase the Attempts 2207 counter. 2209 From reception of an All-1 SCHC Fragment onward, a receiver MUST 2210 check the integrity of the reassembled SCHC Packet at least every 2211 time it prepares for sending a SCHC ACK for the last window. 2213 On reception of a SCHC Sender-Abort, the receiver MUST release all 2214 resource associated with this SCHC Packet. 2216 On expiration of the Inactivity Timer, the receiver MUST send a SCHC 2217 Receiver-Abort and it MUST release all resource associated with this 2218 SCHC Packet. 2220 On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST 2221 send a SCHC Receiver-Abort and it MUST release all resource 2222 associated with this SCHC Packet. 2224 Reassembly of the SCHC Packet concludes when 2226 o a Sender-Abort has been received 2228 o or the Inactivity Timer has expired 2230 o or the Attempts counter has exceeded MAX_ACK_REQUESTS 2232 o or when at least an All-1 SCHC Fragment has been received and 2233 integrity checking of the reassembled SCHC Packet is successful. 2235 The MIC computed at the receiver MUST be computed over the 2236 reassembled SCHC Packet and over the padding bits that were received 2237 in the SCHC Fragment carrying the last tile. 2239 See Figure 40 for one among several possible examples of a Finite 2240 State Machine implementing a receiver behaviour obeying this 2241 specification, and that is meant to match the sender Finite State 2242 Machine of Figure 39. 2244 9. Padding management 2246 SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does 2247 not have any alignment prerequisite. The size of SCHC Packets can be 2248 any number of bits. If the layer below SCHC constrains the payload 2249 to align to some boundary, called L2 Words (for example, bytes), SCHC 2250 will meet that constraint and produce messages with the correct 2251 alignement. This may entail adding extra bits, called padding bits. 2253 When padding occurs, the number of appended bits MUST be strictly 2254 less than the L2 Word size. 2256 Padding happens at most once for each Packet during SCHC Compression 2257 and optional SCHC Fragmentation (see Figure 2). If a SCHC Packet is 2258 sent unfragmented (see Figure 22), it is padded as needed for 2259 transmission. If a SCHC Packet is fragmented, it is not padded in 2260 itself, only the SCHC Fragments are padded as needed for 2261 transmission. Some SCHC F/R modes only pad the very last SCHC 2262 Fragment. 2264 A packet (e.g. an IPv6 packet) 2265 | ^ (padding bits 2266 v | dropped) 2267 +------------------+ +--------------------+ 2268 | SCHC Compression | | SCHC Decompression | 2269 +------------------+ +--------------------+ 2270 | ^ 2271 | If no fragmentation | 2272 +---- SCHC Packet + padding as needed ----->| 2273 | | (MIC checked 2274 v | and removed) 2275 +--------------------+ +-----------------+ 2276 | SCHC Fragmentation | | SCHC Reassembly | 2277 +--------------------+ +-----------------+ 2278 | ^ | ^ 2279 | | | | 2280 | +------------- SCHC ACK ------------+ | 2281 | | 2282 +------- SCHC Fragments + padding as needed---------+ 2284 SENDER RECEIVER 2286 Figure 22: SCHC operations, including padding as needed 2288 Each Profile MUST specify the size of the L2 Word. The L2 Word might 2289 actually be a single bit, in which case at most zero bits of padding 2290 will be appended to any message, i.e. no padding will take place at 2291 all. 2293 A Profile MAY define the value of the padding bits. The RECOMMENDED 2294 value is 0. 2296 10. SCHC Compression for IPv6 and UDP headers 2298 This section lists the different IPv6 and UDP header fields and how 2299 they can be compressed. 2301 10.1. IPv6 version field 2303 This field always holds the same value. Therefore, in the Rule, TV 2304 is set to 6, MO to "equal" and CDA to "not-sent". 2306 10.2. IPv6 Traffic class field 2308 If the DiffServ field does not vary and is known by both sides, the 2309 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2310 value, an "equal" MO and a "not-sent" CDA. 2312 Otherwise (e.g. ECN bits are to be transmitted), two possibilities 2313 can be considered depending on the variability of the value: 2315 o One possibility is to not compress the field and send the original 2316 value. In the Rule, TV is not set to any particular value, MO is 2317 set to "ignore" and CDA is set to "value-sent". 2319 o If some upper bits in the field are constant and known, a better 2320 option is to only send the LSBs. In the Rule, TV is set to a 2321 value with the stable known upper part, MO is set to MSB(x) and 2322 CDA to LSB. 2324 10.3. Flow label field 2326 If the Flow Label field does not vary and is known by both sides, the 2327 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2328 value, an "equal" MO and a "not-sent" CDA. 2330 Otherwise, two possibilities can be considered: 2332 o One possibility is to not compress the field and send the original 2333 value. In the Rule, TV is not set to any particular value, MO is 2334 set to "ignore" and CDA is set to "value-sent". 2336 o If some upper bits in the field are constant and known, a better 2337 option is to only send the LSBs. In the Rule, TV is set to a 2338 value with the stable known upper part, MO is set to MSB(x) and 2339 CDA to LSB. 2341 10.4. Payload Length field 2343 This field can be elided for the transmission on the LPWAN network. 2344 The SCHC C/D recomputes the original payload length value. In the 2345 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 2346 "compute-IPv6-length". 2348 If the payload length needs to be sent and does not need to be coded 2349 in 16 bits, the TV can be set to 0x0000, the MO set to MSB(16-s) 2350 where 's' is the number of bits to code the maximum length, and CDA 2351 is set to LSB. 2353 10.5. Next Header field 2355 If the Next Header field does not vary and is known by both sides, 2356 the Field Descriptor in the Rule SHOULD contain a TV with this Next 2357 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 2358 sent". 2360 Otherwise, TV is not set in the Field Descriptor, MO is set to 2361 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 2362 list MAY also be used. 2364 10.6. Hop Limit field 2366 The field behavior for this field is different for Uplink and 2367 Downlink. In Uplink, since there is no IP forwarding between the Dev 2368 and the SCHC C/D, the value is relatively constant. On the other 2369 hand, the Downlink value depends of Internet routing and MAY change 2370 more frequently. One neat way of processing this field is to use the 2371 Direction Indicator (DI) to distinguish both directions: 2373 o in the Uplink, elide the field: the TV in the Field Descriptor is 2374 set to the known constant value, the MO is set to "equal" and the 2375 CDA is set to "not-sent". 2377 o in the Downlink, send the value: TV is not set, MO is set to 2378 "ignore" and CDA is set to "value-sent". 2380 10.7. IPv6 addresses fields 2382 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 2383 long fields; one for the prefix and one for the Interface Identifier 2384 (IID). These fields SHOULD be compressed. To allow for a single 2385 Rule being used for both directions, these values are identified by 2386 their role (DEV or APP) and not by their position in the header 2387 (source or destination). 2389 10.7.1. IPv6 source and destination prefixes 2391 Both ends MUST be synchronized with the appropriate prefixes. For a 2392 specific flow, the source and destination prefixes can be unique and 2393 stored in the context. It can be either a link-local prefix or a 2394 global prefix. In that case, the TV for the source and destination 2395 prefixes contain the values, the MO is set to "equal" and the CDA is 2396 set to "not-sent". 2398 If the Rule is intended to compress packets with different prefix 2399 values, match-mapping SHOULD be used. The different prefixes are 2400 listed in the TV, the MO is set to "match-mapping" and the CDA is set 2401 to "mapping-sent". See Figure 24 2403 Otherwise, the TV contains the prefix, the MO is set to "equal" and 2404 the CDA is set to "value-sent". 2406 10.7.2. IPv6 source and destination IID 2408 If the DEV or APP IID are based on an LPWAN address, then the IID can 2409 be reconstructed with information coming from the LPWAN header. In 2410 that case, the TV is not set, the MO is set to "ignore" and the CDA 2411 is set to "DevIID" or "AppIID". Note that the LPWAN technology 2412 generally carries a single identifier corresponding to the DEV. 2413 Therefore AppIID cannot be used. 2415 For privacy reasons or if the DEV address is changing over time, a 2416 static value that is not equal to the DEV address SHOULD be used. In 2417 that case, the TV contains the static value, the MO operator is set 2418 to "equal" and the CDA is set to "not-sent". [RFC7217] provides some 2419 methods that MAY be used to derive this static identifier. 2421 If several IIDs are possible, then the TV contains the list of 2422 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 2423 "mapping-sent". 2425 It MAY also happen that the IID variability only expresses itself on 2426 a few bytes. In that case, the TV is set to the stable part of the 2427 IID, the MO is set to "MSB" and the CDA is set to "LSB". 2429 Finally, the IID can be sent in extenso on the LPWAN. In that case, 2430 the TV is not set, the MO is set to "ignore" and the CDA is set to 2431 "value-sent". 2433 10.8. IPv6 extensions 2435 No Rule is currently defined that processes IPv6 extensions. If such 2436 extensions are needed, their compression/decompression Rules can be 2437 based on the MOs and CDAs described above. 2439 10.9. UDP source and destination port 2441 To allow for a single Rule being used for both directions, the UDP 2442 port values are identified by their role (DEV or APP) and not by 2443 their position in the header (source or destination). The SCHC C/D 2444 MUST be aware of the traffic direction (Uplink, Downlink) to select 2445 the appropriate field. The following Rules apply for DEV and APP 2446 port numbers. 2448 If both ends know the port number, it can be elided. The TV contains 2449 the port number, the MO is set to "equal" and the CDA is set to "not- 2450 sent". 2452 If the port variation is on few bits, the TV contains the stable part 2453 of the port number, the MO is set to "MSB" and the CDA is set to 2454 "LSB". 2456 If some well-known values are used, the TV can contain the list of 2457 these values, the MO is set to "match-mapping" and the CDA is set to 2458 "mapping-sent". 2460 Otherwise the port numbers are sent over the LPWAN. The TV is not 2461 set, the MO is set to "ignore" and the CDA is set to "value-sent". 2463 10.10. UDP length field 2465 The UDP length can be computed from the received data. In that case, 2466 the TV is not set, the MO is set to "ignore" and the CDA is set to 2467 "compute-length". 2469 If the payload is small, the TV can be set to 0x0000, the MO set to 2470 "MSB" and the CDA to "LSB". 2472 In other cases, the length SHOULD be sent and the CDA is replaced by 2473 "value-sent". 2475 10.11. UDP Checksum field 2477 The UDP checksum operation is mandatory with IPv6 [RFC8200] for most 2478 packets but recognizes that there are exceptions to that default 2479 behavior. 2481 For instance, protocols that use UDP as a tunnel encapsulation may 2482 enable zero-checksum mode for a specific port (or set of ports) for 2483 sending and/or receiving. [RFC8200] also stipulates that any node 2484 implementing zero-checksum mode must follow the requirements 2485 specified in "Applicability Statement for the Use of IPv6 UDP 2486 Datagrams with Zero Checksums" [RFC6936]. 2488 6LoWPAN Header Compression [RFC6282] also authorizes to send UDP 2489 datagram that are deprived of the checksum protection when an upper 2490 layer guarantees the integrity of the UDP payload and pseudo-header 2491 all the way between the compressor that elides the UDP checksum and 2492 the decompressor that computes again it. A specific example of this 2493 is when a Message Integrity Check (MIC) protects the compressed 2494 message all along that path with a strength that is identical or 2495 better to the UDP checksum. 2497 In a similar fashion, this specification allows a SCHC compressor to 2498 elide the UDP checks when another layer guarantees an identical or 2499 better integrity protection for the UDP payload and the pseudo- 2500 header. In this case, the TV is not set, the MO is set to "ignore" 2501 and the CDA is set to "compute-checksum". 2503 In particular, when SCHC fragmentation is used, a fragmentation MIC 2504 of 2 bytes or more provides equal or better protection than the UDP 2505 checksum; in that case, if the compressor is collocated with the 2506 fragmentation point and the decompressor is collocated with the 2507 packet reassembly point, then compressor MAY elide the UDP checksum. 2508 Whether and when the UDP Checksum is elided is to be specified in the 2509 Profile. 2511 Since the compression happens before the fragmentation, implementors 2512 should understand the risks when dealing with unprotected data below 2513 the transport layer and take special care when manipulating that 2514 data. 2516 In other cases, the checksum SHOULD be explicitly sent. The TV is 2517 not set, the MO is set to "ignore" and the CDA is set to "value- 2518 sent". 2520 11. IANA Considerations 2522 This document has no request to IANA. 2524 12. Security considerations 2526 12.1. Security considerations for SCHC Compression/Decompression 2528 A malicious header compression could cause the reconstruction of a 2529 wrong packet that does not match with the original one. Such a 2530 corruption MAY be detected with end-to-end authentication and 2531 integrity mechanisms. Header Compression does not add more security 2532 problem than what is already needed in a transmission. For instance, 2533 to avoid an attack, never re-construct a packet bigger than some 2534 configured size (with 1500 bytes as generic default). 2536 12.2. Security considerations for SCHC Fragmentation/Reassembly 2538 This subsection describes potential attacks to LPWAN SCHC F/R and 2539 suggests possible countermeasures. 2541 A node can perform a buffer reservation attack by sending a first 2542 SCHC Fragment to a target. Then, the receiver will reserve buffer 2543 space for the IPv6 packet. Other incoming fragmented SCHC Packets 2544 will be dropped while the reassembly buffer is occupied during the 2545 reassembly timeout. Once that timeout expires, the attacker can 2546 repeat the same procedure, and iterate, thus creating a denial of 2547 service attack. The (low) cost to mount this attack is linear with 2548 the number of buffers at the target node. However, the cost for an 2549 attacker can be increased if individual SCHC Fragments of multiple 2550 packets can be stored in the reassembly buffer. To further increase 2551 the attack cost, the reassembly buffer can be split into SCHC 2552 Fragment-sized buffer slots. Once a packet is complete, it is 2553 processed normally. If buffer overload occurs, a receiver can 2554 discard packets based on the sender behavior, which MAY help identify 2555 which SCHC Fragments have been sent by an attacker. 2557 In another type of attack, the malicious node is required to have 2558 overhearing capabilities. If an attacker can overhear a SCHC 2559 Fragment, it can send a spoofed duplicate (e.g. with random payload) 2560 to the destination. If the LPWAN technology does not support 2561 suitable protection (e.g. source authentication and frame counters to 2562 prevent replay attacks), a receiver cannot distinguish legitimate 2563 from spoofed SCHC Fragments. Therefore, the original IPv6 packet 2564 will be considered corrupt and will be dropped. To protect resource- 2565 constrained nodes from this attack, it has been proposed to establish 2566 a binding among the SCHC Fragments to be transmitted by a node, by 2567 applying content-chaining to the different SCHC Fragments, based on 2568 cryptographic hash functionality. The aim of this technique is to 2569 allow a receiver to identify illegitimate SCHC Fragments. 2571 Further attacks MAY involve sending overlapped fragments (i.e. 2572 comprising some overlapping parts of the original IPv6 datagram). 2573 Implementers SHOULD make sure that the correct operation is not 2574 affected by such event. 2576 In ACK-on-Error, a malicious node MAY force a SCHC Fragment sender to 2577 resend a SCHC Fragment a number of times, with the aim to increase 2578 consumption of the SCHC Fragment sender's resources. To this end, 2579 the malicious node MAY repeatedly send a fake ACK to the SCHC 2580 Fragment sender, with a Bitmap that reports that one or more SCHC 2581 Fragments have been lost. In order to mitigate this possible attack, 2582 MAX_ACK_RETRIES MAY be set to a safe value which allows to limit the 2583 maximum damage of the attack to an acceptable extent. However, note 2584 that a high setting for MAX_ACK_RETRIES benefits SCHC Fragment 2585 reliability modes, therefore the trade-off needs to be carefully 2586 considered. 2588 13. Acknowledgements 2590 Thanks to Carsten Bormann, Philippe Clavier, Diego Dujovne, Eduardo 2591 Ingles Sanchez, Arunprabhu Kandasamy, Rahul Jadhav, Sergio Lopez 2592 Bernal, Antony Markovski, Alexander Pelov, Charles Perkins, Edgar 2593 Ramos, Shoichi Sakane, and Pascal Thubert for useful design 2594 consideration and comments. 2596 14. References 2598 14.1. Normative References 2600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2601 Requirement Levels", BCP 14, RFC 2119, 2602 DOI 10.17487/RFC2119, March 1997, 2603 . 2605 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2606 Interface Identifiers with IPv6 Stateless Address 2607 Autoconfiguration (SLAAC)", RFC 7217, 2608 DOI 10.17487/RFC7217, April 2014, 2609 . 2611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2613 May 2017, . 2615 14.2. Informative References 2617 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 2618 "Internet Protocol Small Computer System Interface (iSCSI) 2619 Cyclic Redundancy Check (CRC)/Checksum Considerations", 2620 RFC 3385, DOI 10.17487/RFC3385, September 2002, 2621 . 2623 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2624 "Transmission of IPv6 Packets over IEEE 802.15.4 2625 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2626 . 2628 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2629 Header Compression (ROHC) Framework", RFC 5795, 2630 DOI 10.17487/RFC5795, March 2010, 2631 . 2633 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2634 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2635 DOI 10.17487/RFC6282, September 2011, 2636 . 2638 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2639 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2640 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2641 . 2643 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2644 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2645 February 2014, . 2647 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2648 (IPv6) Specification", STD 86, RFC 8200, 2649 DOI 10.17487/RFC8200, July 2017, 2650 . 2652 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2653 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2654 . 2656 Appendix A. SCHC Compression Examples 2658 This section gives some scenarios of the compression mechanism for 2659 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2661 The most common case using the mechanisms defined in this document 2662 will be a LPWAN Dev that embeds some applications running over CoAP. 2663 In this example, three flows are considered. The first flow is for 2664 the device management based on CoAP using Link Local IPv6 addresses 2665 and UDP ports 123 and 124 for Dev and App, respectively. The second 2666 flow will be a CoAP server for measurements done by the Device (using 2667 ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to 2668 beta::1/64. The last flow is for legacy applications using different 2669 ports numbers, the destination IPv6 address prefix is gamma::1/64. 2671 Figure 23 presents the protocol stack for this Device. IPv6 and UDP 2672 are represented with dotted lines since these protocols are 2673 compressed on the radio link. 2675 Management Data 2676 +----------+---------+---------+ 2677 | CoAP | CoAP | legacy | 2678 +----||----+---||----+---||----+ 2679 . UDP . UDP | UDP | 2680 ................................ 2681 . IPv6 . IPv6 . IPv6 . 2682 +------------------------------+ 2683 | SCHC Header compression | 2684 | and fragmentation | 2685 +------------------------------+ 2686 | LPWAN L2 technologies | 2687 +------------------------------+ 2688 DEV or NGW 2690 Figure 23: Simplified Protocol Stack for LP-WAN 2692 Note that in some LPWAN technologies, only the Devs have a device ID. 2693 Therefore, when such technologies are used, it is necessary to 2694 statically define an IID for the Link Local address for the SCHC C/D. 2696 Rule 0 2697 +----------------+--+--+--+---------+--------+------------++------+ 2698 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 2699 | | | | | | Opera. | Action ||[bits]| 2700 +----------------+--+--+--+---------+---------------------++------+ 2701 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2702 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2703 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2704 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2705 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2706 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2707 |IPv6 DEVprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2708 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2709 |IPv6 APPprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2710 |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | 2711 +================+==+==+==+=========+========+============++======+ 2712 |UDP DEVport |16|1 |Bi|123 | equal | not-sent || | 2713 |UDP APPport |16|1 |Bi|124 | equal | not-sent || | 2714 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2715 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2716 +================+==+==+==+=========+========+============++======+ 2718 Rule 1 2719 +----------------+--+--+--+---------+--------+------------++------+ 2720 | Field |FL|FP|DI| Value | Match | Action || Sent | 2721 | | | | | | Opera. | Action ||[bits]| 2722 +----------------+--+--+--+---------+--------+------------++------+ 2723 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2724 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2725 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2726 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2727 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2728 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2729 |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 | 2730 | | | | |fe80::/64] mapping| || | 2731 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2732 |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 | 2733 | | | | |alpha/64,| mapping| || | 2734 | | | | |fe80::64]| | || | 2735 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2736 +================+==+==+==+=========+========+============++======+ 2737 |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | 2738 |UDP APPport |16|1 |Bi|5683 | equal | not-sent || | 2739 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2740 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2741 +================+==+==+==+=========+========+============++======+ 2743 Rule 2 2744 +----------------+--+--+--+---------+--------+------------++------+ 2745 | Field |FL|FP|DI| Value | Match | Action || Sent | 2746 | | | | | | Opera. | Action ||[bits]| 2747 +----------------+--+--+--+---------+--------+------------++------+ 2748 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2749 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2750 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2751 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2752 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2753 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2754 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 | 2755 |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2756 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2757 |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2758 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2759 +================+==+==+==+=========+========+============++======+ 2760 |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2761 |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2762 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2763 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2764 +================+==+==+==+=========+========+============++======+ 2766 Figure 24: Context Rules 2768 All the fields described in the three Rules depicted on Figure 24 are 2769 present in the IPv6 and UDP headers. The DevIID-DID value is found 2770 in the L2 header. 2772 The second and third Rules use global addresses. The way the Dev 2773 learns the prefix is not in the scope of the document. 2775 The third Rule compresses port numbers to 4 bits. 2777 Appendix B. Fragmentation Examples 2779 This section provides examples for the different fragment reliability 2780 modes specified in this document. 2782 Figure 25 illustrates the transmission in No-ACK mode of a SCHC 2783 Packet that needs 11 SCHC Fragments. FCN is 1 bit wide. 2785 Sender Receiver 2786 |-------FCN=0-------->| 2787 |-------FCN=0-------->| 2788 |-------FCN=0-------->| 2789 |-------FCN=0-------->| 2790 |-------FCN=0-------->| 2791 |-------FCN=0-------->| 2792 |-------FCN=0-------->| 2793 |-------FCN=0-------->| 2794 |-------FCN=0-------->| 2795 |-------FCN=0-------->| 2796 |-----FCN=1 + MIC --->| Integrity check: success 2797 (End) 2799 Figure 25: Transmission in No-ACK mode of a SCHC Packet carried by 11 2800 SCHC Fragments 2802 In the following examples, N (the size of the FCN field) is 3 bits. 2803 Therefore, the All-1 FCN value is 7. 2805 Figure 26 illustrates the transmission in ACK-on-Error mode of a SCHC 2806 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2807 MAX_WIND_FCN=6 and no lost SCHC Fragment. 2809 Sender Receiver 2810 |-----W=0, FCN=6----->| 2811 |-----W=0, FCN=5----->| 2812 |-----W=0, FCN=4----->| 2813 |-----W=0, FCN=3----->| 2814 |-----W=0, FCN=2----->| 2815 |-----W=0, FCN=1----->| 2816 |-----W=0, FCN=0----->| 2817 (no ACK) 2818 |-----W=1, FCN=6----->| 2819 |-----W=1, FCN=5----->| 2820 |-----W=1, FCN=4----->| 2821 |--W=1, FCN=7 + MIC-->| Integrity check: success 2822 |<-- ACK, W=1, C=1 ---| C=1 2823 (End) 2825 Figure 26: Transmission in ACK-on-Error mode of a SCHC Packet 2826 fragmented in 11 tiles, with one tile per SCHC Fragment, 2827 MAX_WIND_FCN=6 and no lost SCHC Fragment. 2829 Figure 27 illustrates the transmission in ACK-on-Error mode of a SCHC 2830 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2831 MAX_WIND_FCN=6 and three lost SCHC Fragments. 2833 Sender Receiver 2834 |-----W=0, FCN=6----->| 2835 |-----W=0, FCN=5----->| 2836 |-----W=0, FCN=4--X-->| 2837 |-----W=0, FCN=3----->| 2838 |-----W=0, FCN=2--X-->| 2839 |-----W=0, FCN=1----->| 2840 |-----W=0, FCN=0----->| 6543210 2841 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2842 |-----W=0, FCN=4----->| 2843 |-----W=0, FCN=2----->| 2844 (no ACK) 2845 |-----W=1, FCN=6----->| 2846 |-----W=1, FCN=5----->| 2847 |-----W=1, FCN=4--X-->| 2848 |- W=1, FCN=7 + MIC ->| Integrity check: failure 2849 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 2850 |-----W=1, FCN=4----->| Integrity check: success 2851 |<-- ACK, W=1, C=1 ---| C=1 2852 (End) 2854 Figure 27: Transmission in ACK-on-Error mode of a SCHC Packet 2855 fragmented in 11 tiles, with one tile per SCHC Fragment, 2856 MAX_WIND_FCN=6 and three lost SCHC Fragments. 2858 Figure 28 shows an example of a transmission in ACK-on-Error mode of 2859 a SCHC Packet fragmented in 73 tiles, with N=5, MAX_WIND_FCN=27, M=2 2860 and 3 lost SCHC Fragments. 2862 Sender Receiver 2863 |-----W=0, FCN=27----->| 4 tiles sent 2864 |-----W=0, FCN=23----->| 4 tiles sent 2865 |-----W=0, FCN=19----->| 4 tiles sent 2866 |-----W=0, FCN=15--X-->| 4 tiles sent (not received) 2867 |-----W=0, FCN=11----->| 4 tiles sent 2868 |-----W=0, FCN=7 ----->| 4 tiles sent 2869 |-----W=0, FCN=3 ----->| 4 tiles sent 2870 |-----W=1, FCN=27----->| 4 tiles sent 2871 |-----W=1, FCN=23----->| 4 tiles sent 2872 |-----W=1, FCN=19----->| 4 tiles sent 2873 |-----W=1, FCN=15----->| 4 tiles sent 2874 |-----W=1, FCN=11----->| 4 tiles sent 2875 |-----W=1, FCN=7 ----->| 4 tiles sent 2876 |-----W=1, FCN=3 --X-->| 4 tiles sent (not received) 2877 |-----W=2, FCN=27----->| 4 tiles sent 2878 |-----W=2, FCN=23----->| 4 tiles sent 2879 ^ |-----W=2, FCN=19----->| 1 tile sent 2880 | |-----W=2, FCN=18----->| 1 tile sent 2881 | |-----W=2, FCN=17----->| 1 tile sent 2882 |-----W=2, FCN=16----->| 1 tile sent 2883 s |-----W=2, FCN=15----->| 1 tile sent 2884 m |-----W=2, FCN=14----->| 1 tile sent 2885 a |-----W=2, FCN=13--X-->| 1 tile sent (not received) 2886 l |-----W=2, FCN=12----->| 1 tile sent 2887 l |---W=2, FCN=31 + MIC->| Integrity check: failure 2888 e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 2889 r |-----W=0, FCN=15----->| 1 tile sent 2890 |-----W=0, FCN=14----->| 1 tile sent 2891 L |-----W=0, FCN=13----->| 1 tile sent 2892 2 |-----W=0, FCN=12----->| 1 tile sent 2893 |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 2894 M |-----W=1, FCN=3 ----->| 1 tile sent 2895 T |-----W=1, FCN=2 ----->| 1 tile sent 2896 U |-----W=1, FCN=1 ----->| 1 tile sent 2897 |-----W=1, FCN=0 ----->| 1 tile sent 2898 | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 2899 | |-----W=2, FCN=13----->| Integrity check: success 2900 V |<--- ACK, W=2, C=1 ---| C=1 2901 (End) 2903 Figure 28: ACK-on-Error mode with variable MTU. 2905 In this example, the L2 MTU becomes reduced just before sending the 2906 "W=2, FCN=19" fragment, leaving space for only 1 tile in each 2907 forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are 2908 carried by a total of 25 SCHC Fragments, the last 9 being of smaller 2909 size. 2911 Note 1: Bitmaps are shown prior to compression for transmission 2913 Note 2: other sequences of events (e.g. regarding when ACKs are sent 2914 by the Receiver) are also allowed by this specification. Profiles 2915 may restrict this flexibility. 2917 Figure 29 illustrates the transmission in ACK-Always mode of a SCHC 2918 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with 2919 N=3, MAX_WIND_FCN=6 and no loss. 2921 Sender Receiver 2922 |-----W=0, FCN=6----->| 2923 |-----W=0, FCN=5----->| 2924 |-----W=0, FCN=4----->| 2925 |-----W=0, FCN=3----->| 2926 |-----W=0, FCN=2----->| 2927 |-----W=0, FCN=1----->| 2928 |-----W=0, FCN=0----->| 2929 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2930 |-----W=1, FCN=6----->| 2931 |-----W=1, FCN=5----->| 2932 |-----W=1, FCN=4----->| 2933 |--W=1, FCN=7 + MIC-->| Integrity check: success 2934 |<-- ACK, W=1, C=1 ---| C=1 2935 (End) 2937 Figure 29: Transmission in ACK-Always mode of a SCHC Packet 2938 fragmented in 11 tiles, with one tile per SCHC Fragment, with N=3, 2939 MAX_WIND_FCN=6 and no loss. 2941 Figure 30 illustrates the transmission in ACK-Always mode of a SCHC 2942 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, 2943 MAX_WIND_FCN=6 and three lost SCHC Fragments. 2945 Sender Receiver 2946 |-----W=0, FCN=6----->| 2947 |-----W=0, FCN=5----->| 2948 |-----W=0, FCN=4--X-->| 2949 |-----W=0, FCN=3----->| 2950 |-----W=0, FCN=2--X-->| 2951 |-----W=0, FCN=1----->| 2952 |-----W=0, FCN=0----->| 6543210 2953 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2954 |-----W=0, FCN=4----->| 2955 |-----W=0, FCN=2----->| 2956 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2957 |-----W=1, FCN=6----->| 2958 |-----W=1, FCN=5----->| 2959 |-----W=1, FCN=4--X-->| 2960 |--W=1, FCN=7 + MIC-->| Integrity check: failure 2961 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001 2962 |-----W=1, FCN=4----->| Integrity check: success 2963 |<-- ACK, W=1, C=1 ---| C=1 2964 (End) 2966 Figure 30: Transmission in ACK-Always mode of a SCHC Packet 2967 fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, 2968 MAX_WIND_FCN=6 and three lost SCHC Fragments. 2970 Figure 31 illustrates the transmission in ACK-Always mode of a SCHC 2971 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2972 MAX_WIND_FCN=6, three lost SCHC Fragments and only one retry needed 2973 to recover each lost SCHC Fragment. 2975 Sender Receiver 2976 |-----W=0, FCN=6----->| 2977 |-----W=0, FCN=5----->| 2978 |-----W=0, FCN=4--X-->| 2979 |-----W=0, FCN=3--X-->| 2980 |-----W=0, FCN=2--X-->| 2981 |--W=0, FCN=7 + MIC-->| Integrity check: failure 2982 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2983 |-----W=0, FCN=4----->| Integrity check: failure 2984 |-----W=0, FCN=3----->| Integrity check: failure 2985 |-----W=0, FCN=2----->| Integrity check: success 2986 |<-- ACK, W=0, C=1 ---| C=1 2987 (End) 2989 Figure 31: Transmission in ACK-Always mode of a SCHC Packet 2990 fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2991 MAX_WIND_FCN=6, three lost SCHC Fragments. 2993 Figure 32 illustrates the transmission in ACK-Always mode of a SCHC 2994 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2995 MAX_WIND_FCN=6, three lost SCHC Fragments, and the second SCHC ACK 2996 lost. 2998 Sender Receiver 2999 |-----W=0, FCN=6----->| 3000 |-----W=0, FCN=5----->| 3001 |-----W=0, FCN=4--X-->| 3002 |-----W=0, FCN=3--X-->| 3003 |-----W=0, FCN=2--X-->| 3004 |--W=0, FCN=7 + MIC-->| Integrity check: failure 3005 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 3006 |-----W=0, FCN=4----->| Integrity check: failure 3007 |-----W=0, FCN=3----->| Integrity check: failure 3008 |-----W=0, FCN=2----->| Integrity check: success 3009 |<-X-ACK, W=0, C=1 ---| C=1 3010 timeout | | 3011 |--- W=0, ACK REQ --->| ACK REQ 3012 |<-- ACK, W=0, C=1 ---| C=1 3013 (End) 3015 Figure 32: Transmission in ACK-Always mode of a SCHC Packet 3016 fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 3017 MAX_WIND_FCN=6, three lost SCHC Fragments, and the second SCHC ACK 3018 lost. 3020 Figure 33 illustrates the transmission in ACK-Always mode of a SCHC 3021 Packet fragmented in 6 tiles, with N=3, MAX_WIND_FCN=6, with three 3022 lost SCHC Fragments, and one retransmitted SCHC Fragment lost again. 3024 Sender Receiver 3025 |-----W=0, FCN=6----->| 3026 |-----W=0, FCN=5----->| 3027 |-----W=0, FCN=4--X-->| 3028 |-----W=0, FCN=3--X-->| 3029 |-----W=0, FCN=2--X-->| 3030 |--W=0, FCN=7 + MIC-->| Integrity check: failure 3031 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 3032 |-----W=0, FCN=4----->| Integrity check: failure 3033 |-----W=0, FCN=3----->| Integrity check: failure 3034 |-----W=0, FCN=2--X-->| 3035 timeout| | 3036 |--- W=0, ACK REQ --->| ACK REQ 3037 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 3038 |-----W=0, FCN=2----->| Integrity check: success 3039 |<-- ACK, W=0, C=1 ---| C=1 3040 (End) 3042 Figure 33: Transmission in ACK-Always mode of a SCHC Packet 3043 fragmented in 6 tiles, with N=3, MAX_WIND_FCN=6, with three lost SCHC 3044 Fragments, and one retransmitted SCHC Fragment lost again. 3046 Figure 34 illustrates the transmission in ACK-Always mode of a SCHC 3047 Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, 3048 MAX_WIND_FCN=23 and two lost SCHC Fragments. 3050 Sender Receiver 3051 |-----W=0, FCN=23----->| 3052 |-----W=0, FCN=22----->| 3053 |-----W=0, FCN=21--X-->| 3054 |-----W=0, FCN=20----->| 3055 |-----W=0, FCN=19----->| 3056 |-----W=0, FCN=18----->| 3057 |-----W=0, FCN=17----->| 3058 |-----W=0, FCN=16----->| 3059 |-----W=0, FCN=15----->| 3060 |-----W=0, FCN=14----->| 3061 |-----W=0, FCN=13----->| 3062 |-----W=0, FCN=12----->| 3063 |-----W=0, FCN=11----->| 3064 |-----W=0, FCN=10--X-->| 3065 |-----W=0, FCN=9 ----->| 3066 |-----W=0, FCN=8 ----->| 3067 |-----W=0, FCN=7 ----->| 3068 |-----W=0, FCN=6 ----->| 3069 |-----W=0, FCN=5 ----->| 3070 |-----W=0, FCN=4 ----->| 3071 |-----W=0, FCN=3 ----->| 3072 |-----W=0, FCN=2 ----->| 3073 |-----W=0, FCN=1 ----->| 3074 |-----W=0, FCN=0 ----->| 3075 | | 3076 |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 3077 |-----W=0, FCN=21----->| 3078 |-----W=0, FCN=10----->| 3079 |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 3080 |-----W=1, FCN=23----->| 3081 |-----W=1, FCN=22----->| 3082 |-----W=1, FCN=21----->| 3083 |--W=1, FCN=31 + MIC-->| Integrity check: success 3084 |<--- ACK, W=1, C=1 ---| C=1 3085 (End) 3087 Figure 34: Transmission in ACK-Always mode of a SCHC Packet 3088 fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, 3089 MAX_WIND_FCN=23 and two lost SCHC Fragments. 3091 Appendix C. Fragmentation State Machines 3093 The fragmentation state machines of the sender and the receiver, one 3094 for each of the different reliability modes, are described in the 3095 following figures: 3097 +===========+ 3098 +------------+ Init | 3099 | FCN=0 +===========+ 3100 | No Window 3101 | No Bitmap 3102 | +-------+ 3103 | +========+==+ | More Fragments 3104 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 3105 +--------> | Send | send Fragment (FCN=0) 3106 +===+=======+ 3107 | last fragment 3108 | ~~~~~~~~~~~~ 3109 | FCN = 1 3110 v send fragment+MIC 3111 +============+ 3112 | END | 3113 +============+ 3115 Figure 35: Sender State Machine for the No-ACK Mode 3117 +------+ Not All-1 3118 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 3119 | + <--+ set Inactivity Timer 3120 | RCV Frag +-------+ 3121 +=+===+======+ |All-1 & 3122 All-1 & | | |MIC correct 3123 MIC wrong | |Inactivity | 3124 | |Timer Exp. | 3125 v | | 3126 +==========++ | v 3127 | Error |<-+ +========+==+ 3128 +===========+ | END | 3129 +===========+ 3131 Figure 36: Receiver State Machine for the No-ACK Mode 3132 +=======+ 3133 | INIT | FCN!=0 & more frags 3134 | | ~~~~~~~~~~~~~~~~~~~~~~ 3135 +======++ +--+ send Window + frag(FCN) 3136 W=0 | | | FCN- 3137 Clear lcl_bm | | v set lcl_bm 3138 FCN=max value | ++==+========+ 3139 +> | | 3140 +---------------------> | SEND | 3141 | +==+===+=====+ 3142 | FCN==0 & more frags | | last frag 3143 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 3144 | set lcl_bm | | set lcl_bm 3145 | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC 3146 | set Retrans_Timer | | set Retrans_Timer 3147 | | | 3148 |Recv_wnd == wnd & | | 3149 |lcl_bm==recv_bm & | | +-----------------------+ 3150 |more frag | | | lcl_bm!=rcv-bm | 3151 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 3152 |Stop Retrans_Timer | | | Attempt++ v 3153 |clear lcl_bm v v | +=====+=+ 3154 |window=next_window +====+===+==+===+ |Resend | 3155 +---------------------+ | |Missing| 3156 +----+ Wait | |Frag | 3157 not expected wnd | | Bitmap | +=======+ 3158 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 3159 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 3160 | | | ^ ^ |reSend(empty)All-* | 3161 | | | | | |Set Retrans_Timer | 3162 | | | | +--+Attempt++ | 3163 MIC_bit==1 & | | | +-------------------------+ 3164 Recv_window==window & | | | all missing frags sent 3165 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 3166 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 3167 Stop Retrans_Timer| | | 3168 +=============+ | | | 3169 | END +<--------+ | | 3170 +=============+ | | Attempt > MAX_ACK_REQUESTS 3171 All-1 Window & | | ~~~~~~~~~~~~~~~~~~ 3172 MIC_bit ==0 & | v Send Abort 3173 lcl_bm==recv_bm | +=+===========+ 3174 ~~~~~~~~~~~~ +>| ERROR | 3175 Send Abort +=============+ 3177 Figure 37: Sender State Machine for the ACK-Always Mode 3179 Not All- & w=expected +---+ +---+w = Not expected 3180 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 3181 Set lcl_bm(FCN) | v v |discard 3182 ++===+===+===+=+ 3183 +---------------------+ Rcv +--->* ABORT 3184 | +------------------+ Window | 3185 | | +=====+==+=====+ 3186 | | All-0 & w=expect | ^ w =next & not-All 3187 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 3188 | | set lcl_bm(FCN) | |expected = next window 3189 | | send lcl_bm | |Clear lcl_bm 3190 | | | | 3191 | | w=expected & not-All | | 3192 | | ~~~~~~~~~~~~~~~~~~ | | 3193 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0 3194 | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~ 3195 | | send lcl_bm | | | | | | expected = nxt wnd 3196 | | v | v | | | Clear lcl_bm 3197 | |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN) 3198 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm 3199 | | discard +--| Next | 3200 | | All-0 +---------+ Window +--->* ABORT 3201 | | ~~~~~ +-------->+========+=++ 3202 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 3203 | | & MIC wrong| | & MIC right 3204 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 3205 | | set lcl_bm(FCN)| |set lcl_bm(FCN) 3206 | | send lcl_bm| |send lcl_bm 3207 | | | +----------------------+ 3208 | |All-1 & w=expected | | 3209 | |& MIC wrong v +---+ w=expected & | 3210 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong | 3211 | |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ | 3212 | |send lcl_bm | Wait End | set lcl_bm(FCN)| 3213 | +--------------------->+ +--->* ABORT | 3214 | +===+====+=+-+ All-1&MIC wrong| 3215 | | ^ | ~~~~~~~~~~~~~~~| 3216 | w=expected & MIC right | +---+ send lcl_bm | 3217 | ~~~~~~~~~~~~~~~~~~~~~~ | | 3218 | set lcl_bm(FCN) | +-+ Not All-1 | 3219 | send lcl_bm | | | ~~~~~~~~~ | 3220 | | | | discard | 3221 |All-1&w=expected & MIC right | | | | 3222 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 3223 |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 3224 |send lcl_bm | +<+Send lcl_bm | 3225 +-------------------------->+ END | | 3226 +==========+<---------------+ 3228 --->* ABORT 3229 ~~~~~~~ 3230 Inactivity_Timer = expires 3231 When DWL 3232 IF Inactivity_Timer expires 3233 Send DWL Request 3234 Attempt++ 3236 Figure 38: Receiver State Machine for the ACK-Always Mode 3238 +=======+ 3239 | | 3240 | INIT | 3241 | | FCN!=0 & more frags 3242 +======++ ~~~~~~~~~~~~~~~~~~~~~~ 3243 Frag RuleID trigger | +--+ Send cur_W + frag(FCN); 3244 ~~~~~~~~~~~~~~~~~~~ | | | FCN--; 3245 cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp] 3246 clear [cur_W, Bmp_n];| | v 3247 clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND 3248 +->+ | cur_W==rcv_W & 3249 **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp 3250 +-------------------------->+ | & more frags 3251 | +----------------------->+ | ~~~~~~~~~~~~ 3252 | | ++===+=========+ cur_W++; 3253 | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] 3254 | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~ 3255 | | set cur_Bmp; | |set [cur_W, Bmp_n]; 3256 | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+MIC; 3257 | | set Retrans_Timer| |set Retrans_Timer 3258 | | | | +-----------------------------------+ 3259 | |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| 3260 | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ | 3261 | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W | 3262 | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &| 3263 | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp| 3264 | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| 3265 | +-------------------+ | | Resend | Attempts++;| 3266 +----------------------+ Wait x ACK | | Missing | W=Wn | 3267 +--------------------->+ | | Frags(W) +<-------------+ 3268 | rcv_W==Wn &+-+ | +======+====+ 3269 | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ | 3270 | ~~~~~~~~~~~~~~| ^ | | | ^ | 3271 | send (cur_W,+--+ | | | +-------------+ 3272 | ALL-0-empty) | | | all missing frag sent(W) 3273 | | | | ~~~~~~~~~~~~~~~~~ 3274 | Retrans_Timer expires &| | | set Retrans_Timer 3275 | No more Frags| | | 3276 | ~~~~~~~~~~~~~~| | | 3277 | stop Retrans_Timer;| | | 3278 |(re)send frag(All-1)+MIC | | | 3279 +-------------------------+ | | 3280 cur_W==rcv_W&| | 3281 [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS 3282 No more Frags & MIC flag==OK| | ~~~~~~~~~~ 3283 ~~~~~~~~~~~~~~~~~~| | send Abort 3284 +=========+stop Retrans_Timer| | +===========+ 3285 | END +<-----------------+ +->+ ERROR | 3286 +=========+ +===========+ 3288 Figure 39: Sender State Machine for the ACK-on-Error Mode 3290 This is an example only. The specification in Section 8.4.3.1 is 3291 open to very different sequencing of operations. 3293 +=======+ New frag RuleID received 3294 | | ~~~~~~~~~~~~~ 3295 | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); 3296 +=======+ |sync=0 3297 | 3298 Not All* & rcv_W==cur_W+---+ | +---+ 3299 ~~~~~~~~~~~~~~~~~~~~ | | | | (E) 3300 set[cur_W,Bmp_n(FCN)]| v v v | 3301 ++===+=+=+===+=+ 3302 +----------------------+ +--+ All-0&Full[cur_W,Bmp_n] 3303 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~ 3304 | +-------------------+ +<-+ cur_W++;set Inact_timer; 3305 | | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n] 3306 | | All-0 empty(Wn)| | | | ^ ^ 3307 | | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0; 3308 | | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n]) 3309 | | | | | |& All* || last_miss_frag 3310 | | | | | |~~~~~~~~~~~~~~~~~~~~~~ 3311 | | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); 3312 | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) 3313 | |&no_full([cur_W,Bmp_n])| |(E)| 3314 | | ~~~~~~~~~~~~~~~~ | | | | +========+ 3315 | | sendACK([cur_W,Bmp_n])| | | | | Error/ | 3316 | | | | | | +----+ | Abort | 3317 | | v v | | | | +===+====+ 3318 | | +===+=+=+=+===+=+ (D) ^ 3319 | | +--+ Wait x | | | 3320 | | All-0 empty(Wn)+->| Missing Frags |<-+ | 3321 | | ~~~~~~~~~~~~~~ +=============+=+ | 3322 | | sendACK([Wn,Bmp_n]) +--------------+ 3323 | | *ABORT 3324 v v 3325 (A)(B) 3326 (D) All* || last_miss_frag 3327 (C) All* & sync>0 & rcv_W!=cur_W & sync>0 3328 ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) 3329 Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ 3330 sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; 3331 sendACK([Wn,Bmp_n]);sync-- 3333 ABORT-->* Uplink Only & 3334 Inact_Timer expires 3335 (E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS 3336 ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ 3337 sync++; cur_W=rcv_W; send Abort 3338 set[cur_W,Bmp_n(FCN)] 3340 (A)(B) 3341 | | 3342 | | All-1 & rcv_W==cur_W & MIC!=OK All-0 empty(Wn) 3343 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~ 3344 | | sendACK([cur_W,Bmp_n],MIC=0) | v sendACK([Wn,Bmp_n]) 3345 | | +===========+=++ 3346 | +--------------------->+ Wait End +-+ 3347 | +=====+=+====+=+ | All-1 3348 | rcv_W==cur_W & MIC==OK | | ^ | & rcv_W==cur_W 3349 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & MIC!=OK 3350 | sendACK([cur_W,Bmp_n],MIC=1) | | ~~~~~~~~~~~~~~~~~~~ 3351 | | | sendACK([cur_W,Bmp_n],MIC=0); 3352 | | | Attempts++ 3353 |All-1 & Full([cur_W,Bmp_n]) | | 3354 |& MIC==OK & sync==0 | +-->* ABORT 3355 |~~~~~~~~~~~~~~~~~~~ v 3356 |sendACK([cur_W,Bmp_n],MIC=1) +=+=========+ 3357 +---------------------------->+ END | 3358 +===========+ 3360 ABORT -->* Uplink Only & 3361 Inact_Timer = expires 3362 || Attempts > MAX_ACK_REQUESTS 3363 ~~~~~~~~~~~~~~~~~~~~~ 3364 send Abort 3366 Figure 40: Receiver State Machine for the ACK-on-Error Mode 3368 Appendix D. SCHC Parameters 3370 This section lists the information that need to be provided in the 3371 LPWAN technology-specific documents. 3373 o Most common uses cases, deployment scenarios 3375 o Mapping of the SCHC architectural elements onto the LPWAN 3376 architecture 3378 o Assessment of LPWAN integrity checking 3380 o Various potential channel conditions for the technology and the 3381 corresponding recommended use of SCHC C/D and F/R 3383 This section lists the parameters that need to be defined in the 3384 Profile. 3386 o Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs, 3387 number of Rules, the way the Rule ID is transmitted 3389 o Padding: size of the L2 Word (for most LPWAN technologies, this 3390 would be a byte; for some technologies, a bit) 3392 o Decision to use SCHC fragmentation mechanism or not. If yes: 3394 * reliability mode(s) used, in which cases (e.g. based on link 3395 channel condition) 3397 * Rule ID values assigned to each mode in use 3399 * presence and number of bits for DTag (T) for each Rule ID value 3401 * support for interleaved packet transmission, to what extent 3403 * WINDOW_SIZE, for modes that use windows 3405 * number of bits for W (M) for each Rule ID value, for modes that 3406 use windows 3408 * number of bits for FCN (N) for each Rule ID value 3410 * value of MAX_WIND_FCN and use of FCN values, if applicable to 3411 the SCHC F/R mode. 3413 * size of MIC and algorithm for its computation, for each Rule 3414 ID, if different from the default CRC32. Byte fill-up with 3415 zeroes or other mechanism, to be specified. 3417 * Retransmission Timer duration for each Rule ID value, if 3418 applicable to the SCHC F/R mode 3420 * Inactivity Timer duration for each Rule ID value, if applicable 3421 to the SCHC F/R mode 3423 * MAX_ACK_REQUEST value for each Rule ID value, if applicable to 3424 the SCHC F/R mode 3426 o if L2 Word is wider than a bit and SCHC fragmentation is used, 3427 value of the padding bits (0 or 1). This is needed because the 3428 padding bits of the last fragment are included in the MIC 3429 computation. 3431 A Profile MAY define a delay to be added between each SCHC message 3432 transmission to respect local regulations or other constraints 3433 imposed by the applications. 3435 o Note on soliciting downlink transmissions: In some LPWAN 3436 technologies, as part of energy-saving techniques, downlink 3437 transmission is only possible immediately after an uplink 3438 transmission. In order to avoid potentially high delay in the 3439 downlink transmission of a fragmented SCHC Packet, the SCHC 3440 Fragment receiver may want to perform an uplink transmission as 3441 soon as possible after reception of a SCHC Fragment that is not 3442 the last one. Such uplink transmission may be triggered by the L2 3443 (e.g. an L2 ACK sent in response to a SCHC Fragment encapsulated 3444 in a L2 PDU that requires an L2 ACK) or it may be triggered from 3445 an upper layer. 3447 o the following parameters need to be addressed in documents other 3448 than this one but not forcely in the LPWAN technology-specific 3449 documents: 3451 * The way the contexts are provisioned 3453 * The way the Rules as generated 3455 Appendix E. Supporting multiple window sizes for fragmentation 3457 For ACK-Always or ACK-on-Error, implementers MAY opt to support a 3458 single window size or multiple window sizes. The latter, when 3459 feasible, may provide performance optimizations. For example, a 3460 large window size SHOULD be used for packets that need to be carried 3461 by a large number of SCHC Fragments. However, when the number of 3462 SCHC Fragments required to carry a packet is low, a smaller window 3463 size, and thus a shorter Bitmap, MAY be sufficient to provide 3464 feedback on all SCHC Fragments. If multiple window sizes are 3465 supported, the Rule ID MAY be used to signal the window size in use 3466 for a specific packet transmission. 3468 Note that the same window size MUST be used for the transmission of 3469 all SCHC Fragments that belong to the same SCHC Packet. 3471 Appendix F. Downlink SCHC Fragment transmission 3473 For downlink transmission of a fragmented SCHC Packet in ACK-Always 3474 mode, the SCHC Fragment receiver MAY support timer-based SCHC ACK 3475 retransmission. In this mechanism, the SCHC Fragment receiver 3476 initializes and starts a timer (the Inactivity Timer is used) after 3477 the transmission of a SCHC ACK, except when the SCHC ACK is sent in 3478 response to the last SCHC Fragment of a packet (All-1 fragment). In 3479 the latter case, the SCHC Fragment receiver does not start a timer 3480 after transmission of the SCHC ACK. 3482 If, after transmission of a SCHC ACK that is not an All-1 fragment, 3483 and before expiration of the corresponding Inactivity timer, the SCHC 3484 Fragment receiver receives a SCHC Fragment that belongs to the 3485 current window (e.g. a missing SCHC Fragment from the current window) 3486 or to the next window, the Inactivity timer for the SCHC ACK is 3487 stopped. However, if the Inactivity timer expires, the SCHC ACK is 3488 resent and the Inactivity timer is reinitialized and restarted. 3490 The default initial value for the Inactivity timer, as well as the 3491 maximum number of retries for a specific SCHC ACK, denoted 3492 MAX_ACK_RETRIES, are not defined in this document, and need to be 3493 defined in a Profile. The initial value of the Inactivity timer is 3494 expected to be greater than that of the Retransmission timer, in 3495 order to make sure that a (buffered) SCHC Fragment to be 3496 retransmitted can find an opportunity for that transmission. 3498 When the SCHC Fragment sender transmits the All-1 fragment, it starts 3499 its Retransmission Timer with a large timeout value (e.g. several 3500 times that of the initial Inactivity timer). If a SCHC ACK is 3501 received before expiration of this timer, the SCHC Fragment sender 3502 retransmits any lost SCHC Fragments reported by the SCHC ACK, or if 3503 the SCHC ACK confirms successful reception of all SCHC Fragments of 3504 the last window, the transmission of the fragmented SCHC Packet is 3505 considered complete. If the timer expires, and no SCHC ACK has been 3506 received since the start of the timer, the SCHC Fragment sender 3507 assumes that the All-1 fragment has been successfully received (and 3508 possibly, the last SCHC ACK has been lost: this mechanism assumes 3509 that the retransmission timer for the All-1 fragment is long enough 3510 to allow several SCHC ACK retries if the All-1 fragment has not;been 3511 received by the SCHC Fragment receiver, and it also assumes that it 3512 is unlikely that several ACKs become all lost). 3514 Appendix G. Note 3516 Carles Gomez has been funded in part by the Spanish Government 3517 (Ministerio de Educacion, Cultura y Deporte) through the Jose 3518 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 3519 Government through project TEC2016-79988-P. Part of his contribution 3520 to this work has been carried out during his stay as a visiting 3521 scholar at the Computer Laboratory of the University of Cambridge. 3523 Authors' Addresses 3524 Ana Minaburo 3525 Acklio 3526 1137A avenue des Champs Blancs 3527 35510 Cesson-Sevigne Cedex 3528 France 3530 Email: ana@ackl.io 3532 Laurent Toutain 3533 IMT-Atlantique 3534 2 rue de la Chataigneraie 3535 CS 17607 3536 35576 Cesson-Sevigne Cedex 3537 France 3539 Email: Laurent.Toutain@imt-atlantique.fr 3541 Carles Gomez 3542 Universitat Politecnica de Catalunya 3543 C/Esteve Terradas, 7 3544 08860 Castelldefels 3545 Spain 3547 Email: carlesgo@entel.upc.edu 3549 Dominique Barthel 3550 Orange Labs 3551 28 chemin du Vieux Chene 3552 38243 Meylan 3553 France 3555 Email: dominique.barthel@orange.com 3557 Juan Carlos Zuniga 3558 SIGFOX 3559 425 rue Jean Rostand 3560 Labege 31670 3561 France 3563 Email: JuanCarlos.Zuniga@sigfox.com