idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-18.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 (December 14, 2018) is 1959 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: June 17, 2019 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 D. Barthel 9 Orange Labs 10 JC. Zuniga 11 SIGFOX 12 December 14, 2018 14 LPWAN Static Context Header Compression (SCHC) and fragmentation for 15 IPv6 and UDP 16 draft-ietf-lpwan-ipv6-static-context-hc-18 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 This document standardizes the exchange over the LPWAN between two 41 SCHC entities. Settings and choices specific to a technology or a 42 product are expected to be grouped into profiles, which are specified 43 in other documents. Data models for the context and profiles are out 44 of scope. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on June 17, 2019. 63 Copyright Notice 65 Copyright (c) 2018 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 82 3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5 83 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10 86 5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 10 87 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12 89 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12 90 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14 91 7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15 92 7.4. Matching operators . . . . . . . . . . . . . . . . . . . 16 93 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 17 94 7.5.1. processing fixed-length fields . . . . . . . . . . . 17 95 7.5.2. processing variable-length fields . . . . . . . . . . 18 96 7.5.3. not-sent CDA . . . . . . . . . . . . . . . . . . . . 18 97 7.5.4. value-sent CDA . . . . . . . . . . . . . . . . . . . 19 98 7.5.5. mapping-sent CDA . . . . . . . . . . . . . . . . . . 19 99 7.5.6. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 19 100 7.5.7. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 20 101 7.5.8. Compute-* . . . . . . . . . . . . . . . . . . . . . . 20 102 8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 20 103 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 104 8.2. SCHC F/R Protocol Elements . . . . . . . . . . . . . . . 21 105 8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 21 106 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 21 107 8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 24 108 8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 24 109 8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 27 110 8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 27 111 8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 28 112 8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 31 113 8.3.4. SCHC Sender-Abort format . . . . . . . . . . . . . . 31 114 8.3.5. SCHC Receiver-Abort format . . . . . . . . . . . . . 31 115 8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 32 116 8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 33 117 8.4.2. ACK-Always mode . . . . . . . . . . . . . . . . . . . 35 118 8.4.3. ACK-on-Error mode . . . . . . . . . . . . . . . . . . 41 119 9. Padding management . . . . . . . . . . . . . . . . . . . . . 47 120 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 48 121 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 48 122 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 48 123 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 49 124 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 49 125 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 49 126 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 50 127 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 50 128 10.7.1. IPv6 source and destination prefixes . . . . . . . . 50 129 10.7.2. IPv6 source and destination IID . . . . . . . . . . 51 130 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 51 131 10.9. UDP source and destination port . . . . . . . . . . . . 51 132 10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 52 133 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 52 134 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 135 12. Security considerations . . . . . . . . . . . . . . . . . . . 53 136 12.1. Security considerations for SCHC 137 Compression/Decompression . . . . . . . . . . . . . . . 53 138 12.2. Security considerations for SCHC 139 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 53 140 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 141 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 142 14.1. Normative References . . . . . . . . . . . . . . . . . . 55 143 14.2. Informative References . . . . . . . . . . . . . . . . . 55 144 Appendix A. Compression Examples . . . . . . . . . . . . . . . . 56 145 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 59 146 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 66 147 Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 72 148 Appendix E. Supporting multiple window sizes for fragmentation . 74 149 Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 74 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 152 1. Introduction 154 This document defines the Static Context Header Compression (SCHC) 155 framework, which provides both header compression and fragmentation 156 functionalities. SCHC has been designed for Low Power Wide Area 157 Networks (LPWAN). 159 Header compression is needed for efficient Internet connectivity to 160 the node within an LPWAN network. Some LPWAN networks properties can 161 be exploited to get an efficient header compression: 163 o The network topology is star-oriented, which means that all 164 packets between the same source-destination pair follow the same 165 path. For the needs of this document, the architecture can simply 166 be described as Devices (Dev) exchanging information with LPWAN 167 Application Servers (App) through a Network Gateway (NGW). 169 o Because devices embed built-in applications, the traffic flows to 170 be compressed are known in advance. Indeed, new applications are 171 less frequently installed in an LPWAN device, as they are in a 172 computer or smartphone. 174 SCHC compression uses a Context (a set of Rules) in which information 175 about header fields is stored. This Context is static: the values of 176 the header fields and the actions to do compression/decompression do 177 not change over time. This avoids complex resynchronization 178 mechanisms. Indeed, downlink is often more restricted/expensive, 179 perhaps completely unavailable [RFC8376]. A compression protocol 180 that relies on feedback is not compatible with the characteristics of 181 such LPWANs. 183 In most cases, a small Rule identifier is enough to represent the 184 full IPv6/UDP headers. The SCHC header compression mechanism is 185 independent of the specific LPWAN technology over which it is used. 187 LPWAN technologies impose some strict limitations on traffic. For 188 instance, devices are sleeping most of the time and may receive data 189 during short periods of time after transmission to preserve battery. 191 LPWAN technologies are also characterized by a greatly reduced data 192 unit and/or payload size (see [RFC8376]). However, some LPWAN 193 technologies do not provide fragmentation functionality; to support 194 the IPv6 MTU requirement of 1280 bytes [RFC8200], they require a 195 fragmentation protocol at the adaptation layer below IPv6. 196 Accordingly, this document defines an optional fragmentation/ 197 reassembly mechanism for LPWAN technologies to support the IPv6 MTU 198 requirement. 200 This document defines generic functionality and offers flexibility 201 with regard to parameters settings and mechanism choices. 202 Technology-specific settings and product-specific choices are 203 expected to be grouped into Profiles specified in other documents. 205 2. Requirements Notation 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 209 "OPTIONAL" in this document are to be interpreted as described in BCP 210 14 [RFC2119] [RFC8174] when, and only when, they appear in all 211 capitals, as shown here. 213 3. LPWAN Architecture 215 LPWAN technologies have similar network architectures but different 216 terminologies. Using the terminology defined in [RFC8376], we can 217 identify different types of entities in a typical LPWAN network, see 218 Figure 1: 220 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 221 actuators, etc.). There can be a very high density of devices per 222 radio gateway. 224 o The Radio Gateway (RGW), which is the end point of the constrained 225 link. 227 o The Network Gateway (NGW) is the interconnection node between the 228 Radio Gateway and the Internet. 230 o Application Server (App) 231 +------+ 232 () () () | |LPWAN-| 233 () () () () / \ +---------+ | AAA | 234 () () () () () () / \======| ^ |===|Server| +-----------+ 235 () () () | | <--|--> | +------+ |Application| 236 () () () () / \==========| v |=============| (App) | 237 () () () / \ +---------+ +-----------+ 238 Dev Radio Gateways NGW 240 Figure 1: LPWAN Architecture as shown in RFC8376 242 4. Terminology 244 This section defines the terminology and acronyms used in this 245 document. It extends the terminology of [RFC8376]. 247 The SCHC acronym is pronounced like "sheek" in English (or "chic" in 248 French). Therefore, this document writes "a SCHC Packet" instead of 249 "an SCHC Packet". 251 o App: LPWAN Application, as defined by [RFC8376]. An application 252 sending/receiving packets to/from the Dev. 254 o AppIID: Application Interface Identifier. The IID that identifies 255 the application server interface. 257 o Bi: Bidirectional. Characterizes a Field Descriptor that applies 258 to headers of packets traveling in either direction (Up and Dw, 259 see this glossary). 261 o CDA: Compression/Decompression Action. Describes the pair of 262 inverse actions that are performed at the compressor to compress a 263 header field and at the decompressor to recover the original 264 header field value. 266 o Compression Residue. The bits that remain to be sent (beyond the 267 Rule ID itself) after applying the SCHC compression. 269 o Context: A set of Rules used to compress/decompress headers. 271 o Dev: Device, as defined by [RFC8376]. 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 Field Description applies to. This 278 allows for asymmetric processing, using the same Rule. 280 o Dw: Downlink direction for compression/decompression, from SCHC C/ 281 D in the network to SCHC C/D in the Dev. 283 o Field Description. A tuple containing identifier, value, matching 284 operator and actions to be applied to a field. 286 o FID: Field Identifier. This identifies the protocol and field a 287 Field Description applies to. 289 o FL: Field Length is the length of the packet header field. It is 290 expressed in bits for header fields of fixed lengths or as a type 291 (e.g. variable, token length, ...) for field lengths that are 292 unknown at the time of Rule creation. The length of a header 293 field is defined in the corresponding protocol specification (such 294 as IPv6 or UDP). 296 o FP: Field Position is a value that is used to identify the 297 position where each instance of a field appears in the header. 299 o IID: Interface Identifier. See the IPv6 addressing architecture 300 [RFC7136] 302 o L2: Layer two. The immediate lower layer SCHC interfaces with. 303 It is provided by an underlying LPWAN technology. It does not 304 necessarily correspond to the OSI model definition of Layer 2. 306 o L2 Word: this is the minimum subdivision of payload data that the 307 L2 will carry. In most L2 technologies, the L2 Word is an octet. 308 In bit-oriented radio technologies, the L2 Word might be a single 309 bit. The L2 Word size is assumed to be constant over time for 310 each device. 312 o MO: Matching Operator. An operator used to match a value 313 contained in a header field with a value contained in a Rule. 315 o Padding (P). Extra bits that may be appended by SCHC to a data 316 unit that it passes to the underlying Layer 2 for transmission. 317 SCHC itself operates on bits, not bytes, and does not have any 318 alignment prerequisite. See Section 9. 320 o Profile: SCHC offers variations in the way it is operated, with a 321 number of parameters listed in Appendix D. A Profile indicates a 322 particular setting of all these parameters. Both ends of a SCHC 323 communication must be provisioned with the same Profile 324 information and with the same set of Rules before the 325 communication starts, so that there is no ambiguity in how they 326 expect to communicate. 328 o Rule: A set of Field Descriptions. 330 o Rule ID (Rule Identifier): An identifier for a Rule. SCHC C/D on 331 both sides share the same Rule ID for a given packet. A set of 332 Rule IDs are used to support SCHC F/R functionality. 334 o SCHC C/D: Static Context Header Compression Compressor/ 335 Decompressor. A mechanism used on both sides, at the Dev and at 336 the network, to achieve Compression/Decompression of headers. 338 o SCHC F/R: SCHC Fragmentation / Reassembly. A mechanism used on 339 both sides, at the Dev and at the network, to achieve 340 Fragmentation / Reassembly of SCHC Packets. 342 o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been 343 compressed as per the header compression mechanism defined in this 344 document. If the header compression process is unable to actually 345 compress the packet header, the packet with the uncompressed 346 header is still called a SCHC Packet (in this case, a Rule ID is 347 used to indicate that the packet header has not been compressed). 348 See Section 7 for more details. 350 o TV: Target value. A value contained in a Rule that will be 351 matched with the value of a header field. 353 o Up: Uplink direction for compression/decompression, from the Dev 354 SCHC C/D to the network SCHC C/D. 356 Additional terminology for the optional SCHC Fragmentation / 357 Reassembly mechanism (SCHC F/R) is found in Section 8.2. 359 5. SCHC overview 361 SCHC can be characterized as an adaptation layer between IPv6 and the 362 underlying LPWAN technology. SCHC comprises two sublayers (i.e. the 363 Compression sublayer and the Fragmentation sublayer), as shown in 364 Figure 2. 366 +----------------+ 367 | IPv6 | 368 +- +----------------+ 369 | | Compression | 370 SCHC < +----------------+ 371 | | Fragmentation | 372 +- +----------------+ 373 |LPWAN technology| 374 +----------------+ 376 Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN 377 technology 379 Before a packet (e.g. an IPv6 packet) is transmitted, header 380 compression is first applied. The resulting packet is called a SCHC 381 Packet, whether or not any compression is performed. If the SCHC 382 Packet is to be fragmented, the optional SCHC Fragmentation MAY be 383 applied to the SCHC Packet. The inverse operations take place at the 384 receiver. This process is illustrated in Figure 3. 386 A packet (e.g. an IPv6 packet) 387 | ^ 388 v | 389 +------------------+ +--------------------+ 390 | SCHC Compression | | SCHC Decompression | 391 +------------------+ +--------------------+ 392 | ^ 393 | If no fragmentation (*) | 394 +-------------- SCHC Packet -------------->| 395 | | 396 v | 397 +--------------------+ +-----------------+ 398 | SCHC Fragmentation | | SCHC Reassembly | 399 +--------------------+ +-----------------+ 400 | ^ | ^ 401 | | | | 402 | +-------------- SCHC ACK -------------+ | 403 | | 404 +-------------- SCHC Fragments -------------------+ 406 SENDER RECEIVER 408 *: the decision to use Fragmentation or not is left to each Profile. 410 Figure 3: SCHC operations at the SENDER and the RECEIVER 412 5.1. SCHC Packet format 414 The SCHC Packet is composed of the Compressed Header followed by the 415 payload from the original packet (see Figure 4). The Compressed 416 Header itself is composed of the Rule ID and a Compression Residue, 417 which is the output of compressing the packet header with that Rule 418 (see Section 7). The Compression Residue may be empty. Both the 419 Rule ID and the Compression Residue potentially have a variable size, 420 and are not necessarily a multiple of bytes in size. 422 |------- Compressed Header -------| 423 +---------------------------------+--------------------+ 424 | Rule ID | Compression Residue | Payload | 425 +---------------------------------+--------------------+ 427 Figure 4: SCHC Packet 429 5.2. Functional mapping 431 Figure 5 below maps the functional elements of Figure 3 onto the 432 LPWAN architecture elements of Figure 1. 434 Dev App 435 +----------------+ +----+ +----+ +----+ 436 | App1 App2 App3 | |App1| |App2| |App3| 437 | | | | | | | | 438 | UDP | |UDP | |UDP | |UDP | 439 | IPv6 | |IPv6| |IPv6| |IPv6| 440 | | | | | | | | 441 |SCHC C/D and F/R| | | | | | | 442 +--------+-------+ +----+ +----+ +----+ 443 | +--+ +----+ +----+ +----+ . . . 444 +~ |RG| === |NGW | == |SCHC| == |SCHC|...... Internet .... 445 +--+ +----+ |F/R | |C/D | 446 +----+ +----+ 448 Figure 5: Architecture 450 SCHC C/D and SCHC F/R are located on both sides of the LPWAN 451 transmission, i.e. on the Dev side and on the Network side. 453 The operation in the Uplink direction is as follows. The Device 454 application uses IPv6 or IPv6/UDP protocols. Before sending the 455 packets, the Dev compresses their headers using SCHC C/D and, if the 456 SCHC Packet resulting from the compression needs to be fragmented by 457 SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC 458 Fragments are sent to an LPWAN Radio Gateway (RG) which forwards them 459 to a Network Gateway (NGW). The NGW sends the data to a SCHC F/R for 460 re-assembly (if needed) and then to the SCHC C/D for decompression. 461 After decompression, the packet can be sent over the Internet to one 462 or several LPWAN Application Servers (App). 464 The SCHC F/R and C/D on the Network side can be located in the NGW, 465 or somewhere else as long as a tunnel is established between them and 466 the NGW. For some LPWAN technologies, it MAY be suitable to locate 467 the SCHC F/R functionality nearer the NGW, in order to better deal 468 with time constraints of such technologies. 470 The SCHC C/Ds on both sides MUST share the same set of Rules. So do 471 the SCHC F/Rs on both sides. 473 The SCHC C/D and F/R process is symmetrical, therefore the 474 description of the Downlink direction is symmetrical to the one 475 above. 477 6. Rule ID 479 Rule IDs are identifiers used for Compression/Decompression or for 480 Fragmentation/Reassembly. 482 The size of the Rule IDs is not specified in this document, as it is 483 implementation-specific and can vary according to the LPWAN 484 technology and the number of Rules, among others. It is defined in 485 Profiles. 487 The Rule IDs are used: 489 o For SCHC C/D, to identify the Rule (i.e., the set of Field 490 Descriptions) that is used to compress a packet header. 492 * At least one Rule ID MAY be allocated to tagging packets for 493 which SCHC compression was not possible (no matching Rule was 494 found). 496 o In SCHC F/R, to identify the specific mode and settings of F/R for 497 one direction of traffic (Up or Dw). 499 * When F/R is used for both communication directions, at least 500 two Rule ID values are needed for F/R, one per direction of 501 traffic. 503 7. Compression/Decompression 505 Compression with SCHC is based on using a set of Rules, called the 506 Context, to compress or decompress headers. SCHC avoids Context 507 synchronization, which consumes considerable bandwidth in other 508 header compression mechanisms such as RoHC [RFC5795]. Since the 509 content of packets is highly predictable in LPWAN networks, static 510 Contexts MAY be stored beforehand to omit transmitting some 511 information over the air. The Contexts MUST be stored at both ends, 512 and they can be learned by a provisioning protocol or by out of band 513 means, or they can be pre-provisioned. The way the Contexts are 514 provisioned is out of the scope of this document. 516 7.1. SCHC C/D Rules 518 The main idea of the SCHC compression scheme is to transmit the Rule 519 ID to the other end instead of sending known field values. This Rule 520 ID identifies a Rule that matches the original packet values. Hence, 521 when a value is known by both ends, it is only necessary to send the 522 corresponding Rule ID over the LPWAN network. The manner by which 523 Rules are generated is out of the scope of this document. The Rules 524 MAY be changed at run-time but the mechanism is out of scope of this 525 document. 527 The Context is a set of Rules. See Figure 6 for a high level, 528 abstract representation of the Context. The formal specification of 529 the representation of the Rules is outside the scope of this 530 document. 532 Each Rule itself contains a list of Field Descriptions composed of a 533 Field Identifier (FID), a Field Length (FL), a Field Position (FP), a 534 Direction Indicator (DI), a Target Value (TV), a Matching Operator 535 (MO) and a Compression/Decompression Action (CDA). 537 /-----------------------------------------------------------------\ 538 | Rule N | 539 /-----------------------------------------------------------------\| 540 | Rule i || 541 /-----------------------------------------------------------------\|| 542 | (FID) Rule 1 ||| 543 |+-------+--+--+--+------------+-----------------+---------------+||| 544 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 545 |+-------+--+--+--+------------+-----------------+---------------+||| 546 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 547 |+-------+--+--+--+------------+-----------------+---------------+||| 548 ||... |..|..|..| ... | ... | ... |||| 549 |+-------+--+--+--+------------+-----------------+---------------+||/ 550 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 551 |+-------+--+--+--+------------+-----------------+---------------+|/ 552 | | 553 \-----------------------------------------------------------------/ 555 Figure 6: A Compression/Decompression Context 557 A Rule does not describe how the compressor parses a packet header to 558 find and identify each field (e.g. the IPv6 Source Address, the UDP 559 Destination Port or a CoAP URI path option). This MUST be known from 560 the compressor/decompressor. Rules only describe the compression/ 561 decompression behavior for each header field. The header fields must 562 have been identified by the compressor prior to testing for a Rule 563 match. 565 In a Rule, the Field Descriptions are listed in the order in which 566 the fields appear in the packet header. The Field Descriptions 567 describe the header fields with the following entries: 569 o Field ID (FID) designates a protocol and field (e.g. UDP 570 Destination Port), unambiguously among all protocols that a SCHC 571 compressor processes. 573 o Field Length (FL) represents the length of the field. It can be 574 either a fixed value (in bits) if the length is known when the 575 Rule is created or a type if the length is variable. The length 576 of a header field is defined by its own protocol specification 577 (e.g. IPv6 or UDP). If the length is variable, the type defines 578 the process to compute the length and its unit (bits, bytes...). 580 o Field Position (FP): most often, a field only occurs once in a 581 packet header. Some fields may occur multiple times in a header. 582 FP indicates which occurrence this Field Description applies to. 583 The default value is 1 (first occurrence). 585 o A Direction Indicator (DI) indicates the packet direction(s) this 586 Field Description applies to. Three values are possible: 588 * UPLINK (Up): this Field Description is only applicable to 589 packets sent by the Dev to the App, 591 * DOWNLINK (Dw): this Field Description is only applicable to 592 packets sent from the App to the Dev, 594 * BIDIRECTIONAL (Bi): this Field Description is applicable to 595 packets traveling both Up and Dw. 597 o Target Value (TV) is the value used to match against the packet 598 header field. The Target Value can be a scalar value of any type 599 (integer, strings, etc.) or a more complex structure (array, list, 600 etc.). The types and representations are out of scope for this 601 document. 603 o Matching Operator (MO) is the operator used to match the Field 604 Value and the Target Value. The Matching Operator may require 605 some parameters. MO is only used during the compression phase. 606 The set of MOs defined in this document can be found in 607 Section 7.4. 609 o Compression Decompression Action (CDA) describes the compression 610 and decompression processes to be performed after the MO is 611 applied. Some CDAs might use parameter values for their 612 operation. CDAs are used in both the compression and the 613 decompression functions. The set of CDAs defined in this document 614 can be found in Section 7.5. 616 7.2. Rule ID for SCHC C/D 618 Rule IDs are sent by the compression function in one side and are 619 received for the decompression function in the other side. In SCHC 620 C/D, the Rule IDs are specific to the Context related to one Dev. 621 Hence, multiple Dev instances, which refer to different header 622 compression Contexts, MAY reuse the same Rule ID for different Rules. 623 On the network side, in order to identify the correct Rule to be 624 applied, the SCHC Decompressor needs to associate the Rule ID with 625 the Dev identifier. Similarly, the SCHC Compressor on the network 626 side first identifies the destination Dev before looking for the 627 appropriate compression Rule (and associated Rule ID) in the Context 628 of that Dev. 630 7.3. Packet processing 632 The compression/decompression process follows several steps: 634 o Compression Rule selection: the set of Rules is browsed to 635 identify which Rule will be used to compress the packet header. 636 The Rule is selected by matching the Fields Descriptions to the 637 packet header. The detailed steps are the following: 639 * The first step is to check the Field Identifiers (FID). If any 640 header field of the packet being examined cannot be matched 641 with a Field Description with the correct FID, the Rule MUST be 642 disregarded. If any Field Description in the Rule has a FID 643 that cannot be matched to one of the header fields of the 644 packet being examined, the Rule MUST be disregarded. 646 * The next step is to match the Field Descriptions by their 647 direction, using the Direction Indicator (DI). If any field of 648 the packet header cannot be matched with a Field Description 649 with the correct FID and DI, the Rule MUST be disregarded. 651 * Then the Field Descriptions are further selected according to 652 Field Position (FP). If any field of the packet header cannot 653 be matched with a Field Description with the correct FID, DI 654 and FP, the Rule MUST be disregarded. 656 * Once each header field has been associated with a Field 657 Description with matching FID, DI and FP, each packet field's 658 value is then compared to the corresponding Target Value (TV) 659 stored in the Rule for that specific field, using the matching 660 operator (MO). If every field in the packet header satisfies 661 the corresponding matching operators (MO) of a Rule (i.e. all 662 MO results are True), that Rule is used for compressing the 663 header. Otherwise, the Rule MUST be disregarded. 665 * If no eligible compression Rule is found, then the header MUST 666 be sent in its entirety using a Rule ID dedicated to this 667 purpose. Sending an uncompressed header may require SCHC F/R. 669 o Compression: each field of the header is compressed according to 670 the Compression/Decompression Actions (CDAs). The fields are 671 compressed in the order that the Field Descriptions appear in the 672 Rule. The compression of each field results in a residue, which 673 may be empty. The Compression Residue for the packet header is 674 the concatenation of the non-empty residues for each field of the 675 header, in the order the Field Descriptions appear in the Rule. 677 |------------------- Compression Residue -------------------| 678 +-----------------+-----------------+-----+-----------------+ 679 | field 1 residue | field 2 residue | ... | field N residue | 680 +-----------------+-----------------+-----+-----------------+ 682 Figure 7: Compression Residue structure 684 o Sending: The Rule ID is sent to the other end followed by the 685 Compression Residue (which could be empty) or the uncompressed 686 header, and directly followed by the payload (see Figure 4). The 687 way the Rule ID is sent will be specified in the Profile and is 688 out of the scope of the present document. For example, it could 689 be included in an L2 header or sent as part of the L2 payload. 691 o Decompression: when decompressing, on the network side the SCHC C/ 692 D needs to find the correct Rule based on the L2 address; in this 693 way, it can use the DevIID and the Rule ID. On the Dev side, only 694 the Rule ID is needed to identify the correct Rule since the Dev 695 typically only holds Rules that apply to itself. 697 The receiver identifies the sender through its device-id or source 698 identifier (e.g. MAC address, if it exists) and selects the Rule 699 using the Rule ID. This Rule describes the compressed header 700 format and associates the received residues to each of the header 701 fields. For each field in the header, the receiver applies the 702 CDA action associated to that field in order to reconstruct the 703 original header field value. The CDA application order can be 704 different from the order in which the fields are listed in the 705 Rule. In particular, Compute-* MUST be applied after the 706 application of the CDAs of all the fields it computes on. 708 7.4. Matching operators 710 Matching Operators (MOs) are functions used by both SCHC C/D 711 endpoints. They are not typed and can be applied to integer, string 712 or any other data type. The result of the operation can either be 713 True or False. MOs are defined as follows: 715 o equal: The match result is True if the field value in the packet 716 matches the TV. 718 o ignore: No matching is attempted between the field value in the 719 packet and the TV in the Rule. The result is always true. 721 o MSB(x): A match is obtained if the most significant x bits of the 722 packet header field value are equal to the TV in the Rule. The x 723 parameter of the MSB MO indicates how many bits are involved in 724 the comparison. If the FL is described as variable, the length 725 must be a multiple of the unit. For example, x must be multiple 726 of 8 if the unit of the variable length is in bytes. 728 o match-mapping: With match-mapping, the Target Value is a list of 729 values. Each value of the list is identified by a short ID (or 730 index). Compression is achieved by sending the index instead of 731 the original header field value. This operator matches if the 732 header field value is equal to one of the values in the target 733 list. 735 7.5. Compression Decompression Actions (CDA) 737 The Compression Decompression Action (CDA) describes the actions 738 taken during the compression of headers fields and the inverse action 739 taken by the decompressor to restore the original value. 741 /--------------------+-------------+----------------------------\ 742 | Action | Compression | Decompression | 743 | | | | 744 +--------------------+-------------+----------------------------+ 745 |not-sent |elided |use value stored in Context | 746 |value-sent |send |build from received value | 747 |mapping-sent |send index |value from index on a table | 748 |LSB |send LSB |TV, received value | 749 |compute-length |elided |compute length | 750 |compute-checksum |elided |compute UDP checksum | 751 |DevIID |elided |build IID from L2 Dev addr | 752 |AppIID |elided |build IID from L2 App addr | 753 \--------------------+-------------+----------------------------/ 755 Figure 8: Compression and Decompression Actions 757 Figure 8 summarizes the basic actions that can be used to compress 758 and decompress a field. The first column shows the action's name. 759 The second and third columns show the compression and decompression 760 behaviors for each action. 762 7.5.1. processing fixed-length fields 764 If the field is identified in the Field Description as being of fixed 765 length, then aplying the CDA to compress this field results in a 766 fixed amount of bits. The residue for that field is simply the bits 767 resulting from applying the CDA to the field. This value may be 768 empty (e.g. not-sent CDA), in which case the field residue is absent 769 from the Compression Residue. 771 |- field residue -| 772 +-----------------+ 773 | value | 774 +-----------------+ 776 Figure 9: fixed sized field residue structure 778 7.5.2. processing variable-length fields 780 If the field is identified in the Field Description as being of 781 variable length, then aplying the CDA to compress this field may 782 result in a value of fixed size (e.g. not-sent or mapping-sent) or of 783 variable size (e.g. value-sent or LSB). In the latter case, the 784 residue for that field is the bits that result from applying the CDA 785 to the field, preceded with the size of the value. 787 |--- field residue ---| 788 +-------+-------------+ 789 | size | value | 790 +-------+-------------+ 792 Figure 10: variable sized field residue structure 794 The size (using the unit defined in the FL) is encoded as follows: 796 o If the size is between 0 and 14, it is sent as a 4-bits unsigned 797 integer. 799 o For values between 15 and 254, 0b1111 is transmitted and then the 800 size is sent as an 8 bits unsigned integer. 802 o For larger values of the size, 0xfff is transmitted and then the 803 next two bytes contain the size value as a 16 bits unsigned 804 integer. 806 If the field is identified in the Field Description as being of 807 variable length and this field is not present in the packet header 808 being compressed, size 0 MUST be sent to denote its absence. 810 7.5.3. not-sent CDA 812 The not-sent action can be used when the field value is specified in 813 a Rule and therefore known by both the Compressor and the 814 Decompressor. This action SHOULD be used with the "equal" MO. If MO 815 is "ignore", there is a risk to have a decompressed field value 816 different from the original field that was compressed. 818 The compressor does not send any residue for a field on which not- 819 sent compression is applied. 821 The decompressor restores the field value with the Target Value 822 stored in the matched Rule identified by the received Rule ID. 824 7.5.4. value-sent CDA 826 The value-sent action can be used when the field value is not known 827 by both the Compressor and the Decompressor. The value is sent in 828 its entirety. 830 If this action is performed on a variable length field, the size of 831 the residue value (using the units defined in FL) MUST be sent as 832 described in Section 7.5.2. 834 This action is generally used with the "ignore" MO. 836 7.5.5. mapping-sent CDA 838 The mapping-sent action is used to send an index (the index into the 839 Target Value list of values) instead of the original value. This 840 action is used together with the "match-mapping" MO. 842 On the compressor side, the match-mapping Matching Operator searches 843 the TV for a match with the header field value and the mapping-sent 844 CDA sends the corresponding index as the field residue. On the 845 decompressor side, the CDA uses the received index to restore the 846 field value by looking up the list in the TV. 848 The number of bits sent is the minimal size for coding all the 849 possible indices. 851 7.5.6. LSB CDA 853 The LSB action is used together with the "MSB(x)" MO to avoid sending 854 the most significant part of the packet field if that part is already 855 known by the receiving end. 857 The compressor sends the Least Significant Bits as the field residue 858 value. The number of bits sent is the original header field length 859 minus the length specified in the MSB(x) MO. 861 The decompressor concatenates the x most significant bits of Target 862 Value and the received residue value. 864 If this action is performed on a variable length field, the size of 865 the residue value (using the units defined in FL) MUST be sent as 866 described in Section 7.5.2. 868 7.5.7. DevIID, AppIID CDA 870 These actions are used to process respectively the Dev and the App 871 Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. 872 AppIID CDA is less common since most current LPWAN technologies 873 frames contain a single L2 address, which is the Dev's address. 875 The IID value MAY be computed from the Device ID present in the L2 876 header, or from some other stable identifier. The computation is 877 specific to each Profile and MAY depend on the Device ID size. 879 In the downlink direction (Dw), at the compressor, the DevIID CDA may 880 be used to generate the L2 addresses on the LPWAN, based on the 881 packet's Destination Address. 883 7.5.8. Compute-* 885 Some fields may be elided during compression and reconstructed during 886 decompression. This is the case for length and checksum, so: 888 o compute-length: computes the length assigned to this field. This 889 CDA MAY be used to compute IPv6 length or UDP length. 891 o compute-checksum: computes a checksum from the information already 892 received by the SCHC C/D. This field MAY be used to compute UDP 893 checksum. 895 8. Fragmentation/Reassembly 897 8.1. Overview 899 In LPWAN technologies, the L2 MTU typically ranges from tens to 900 hundreds of bytes. Some of these technologies do not have an 901 internal fragmentation/reassembly mechanism. 903 The optional SCHC Fragmentation/Reassembly (SCHC F/R) functionality 904 enables such LPWAN technologies to comply with the IPv6 MTU 905 requirement of 1280 bytes [RFC8200]. It is optional to implement. 906 If it is not needed, its description can be safely ignored. 908 This specification includes several SCHC F/R modes, which allow for a 909 range of reliability options such as optional SCHC Fragment 910 retransmission. More modes may be defined in the future. 912 The same SCHC F/R mode MUST be used for all SCHC Fragments of a SCHC 913 Packet. This document does not specify which mode(s) are to be used 914 over a specific LPWAN technology. That information will be given in 915 Profiles. 917 The L2 Word size (see Section 4) determines the encoding of some 918 messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs 919 that are multiples of L2 Words. 921 8.2. SCHC F/R Protocol Elements 923 This subsection describes the different elements that are used to 924 enable the SCHC F/R functionality defined in this document. These 925 elements include the SCHC F/R messages, tiles, windows, bitmaps, 926 counters, timers and header fields. 928 The elements are described here in a generic manner. Their 929 application to each SCHC F/R mode is found in Section 8.4. 931 8.2.1. Messages 933 SCHC F/R defines the following messages: 935 o SCHC Fragment: A message that carries part of a SCHC Packet from 936 the sender to the receiver. 938 o SCHC ACK: An acknowledgement for fragmentation, by the receiver to 939 the sender. This message is used to indicate whether or not the 940 reception of pieces of, or the whole of the fragmented SCHC 941 Packet, was successful. 943 o SCHC ACK REQ: A request by the sender for a SCHC ACK from the 944 receiver. 946 o SCHC Sender-Abort: A message by the sender telling the receiver 947 that it has aborted the transmission of a fragmented SCHC Packet. 949 o SCHC Receiver-Abort: A message by the receiver to tell the sender 950 to abort the transmission of a fragmented SCHC Packet. 952 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 954 8.2.2.1. Tiles 956 The SCHC Packet is fragmented into pieces, hereafter called tiles. 957 The tiles MUST be non-empty and pairwise disjoint. Their union MUST 958 be equal to the SCHC Packet. 960 See Figure 11 for an example. 962 SCHC Packet 963 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 964 Tiles | | | | | | | | | | | | | | 965 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 967 Figure 11: a SCHC Packet fragmented in tiles 969 Each SCHC Fragment message carries at least one tile in its Payload, 970 if the Payload field is present. 972 8.2.2.2. Windows 974 Some SCHC F/R modes may handle successive tiles in groups, called 975 windows. 977 If windows are used 979 o all the windows of a SCHC Packet, except the last one, MUST 980 contain the same number of tiles. This number is WINDOW_SIZE. 982 o WINDOW_SIZE MUST be specified in a Profile. 984 o the windows are numbered. 986 o their numbers MUST increase from 0 upward, from the start of the 987 SCHC Packet to its end. 989 o the last window MUST contain WINDOW_SIZE tiles or less. 991 o tiles are numbered within each window. 993 o the tile indices MUST decrement from WINDOW_SIZE - 1 downward, 994 looking from the start of the SCHC Packet toward its end. 996 o each tile of a SCHC Packet is therefore uniquely identified by a 997 window number and a tile index within this window. 999 See Figure 12 for an example. 1001 +---------------------------------------------...-------------+ 1002 | SCHC Packet | 1003 +---------------------------------------------...-------------+ 1005 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 | 1006 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -| 1008 Figure 12: a SCHC Packet fragmented in tiles grouped in 28 windows, 1009 with WINDOW_SIZE = 5 1011 When windows are used 1013 o Bitmaps (see Section 8.2.2.3) MAY be sent back by the receiver to 1014 the sender in a SCHC ACK message. 1016 o A Bitmap corresponds to exactly one Window. 1018 8.2.2.3. Bitmaps 1020 Each bit in the Bitmap for a window corresponds to a tile in the 1021 window. Each Bitmap has therefore WINDOW_SIZE bits. The bit at the 1022 left-most position corresponds to the tile numbered WINDOW_SIZE - 1. 1023 Consecutive bits, going right, correspond to sequentially decreasing 1024 tile indices. In Bitmaps for windows that are not the last one of a 1025 SCHC Packet, the bit at the right-most position corresponds to the 1026 tile numbered 0. In the Bitmap for the last window, the bit at the 1027 right-most position corresponds either to the tile numbered 0 or to a 1028 tile that is sent/received as "the last one of the SCHC Packet" 1029 without explicitly stating its number (see Section 8.3.1.2). 1031 At the receiver 1033 o a bit set to 1 in the Bitmap indicates that a tile associated with 1034 that bit position has been correctly received for that window. 1036 o a bit set to 0 in the Bitmap indicates that no tile associated 1037 with that bit position has been correctly received for that 1038 window. 1040 8.2.2.4. Timers and counters 1042 Some SCHC F/R modes can use the following timers and counters 1044 o Inactivity Timer: a SCHC Fragment receiver uses this timer to 1045 abort waiting for a SCHC F/R message. 1047 o Retransmission Timer: a SCHC Fragment sender uses this timer to 1048 abort waiting for an expected SCHC ACK. 1050 o Attempts: this counter counts the requests for SCHC ACKs, up to 1051 MAX_ACK_REQUESTS. 1053 8.2.3. Integrity Checking 1055 The reassembled SCHC Packet MUST be checked for integrity at the 1056 receive end. By default, integrity checking is performed by 1057 computing a MIC at the sender side and transmitting it to the 1058 receiver for comparison with the locally computed MIC. 1060 The MIC supports UDP checksum elision by SCHC C/D (see 1061 Section 10.11). 1063 The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of 1064 the polynomial used e.g. in the Ethernet standard [RFC3385]) is 1065 RECOMMENDED as the default algorithm for computing the MIC. 1066 Nevertheless, other MIC lengths or other algorithms MAY be required 1067 by the Profile. 1069 The MIC MUST be computed on the full SCHC Packet concatenated with 1070 the padding bits, if any, of the SCHC Fragment carrying the last 1071 tile. The rationale is that the SCHC reassembler has no way of 1072 knowing the boundary between the last tile and the padding bits. 1073 Indeed, this requires decompressing the SCHC Packet, which is out of 1074 the scope of the SCHC reassembler. 1076 Note that the concatenation of the complete SCHC Packet and the 1077 potential padding bits of the last SCHC Fragment does not generally 1078 constitute an integer number of bytes. For implementers to be able 1079 to use byte-oriented CRC libraries, it is RECOMMENDED that the 1080 concatenation of the complete SCHC Packet and the last fragment 1081 potential padding bits be zero-extended to the next byte boundary and 1082 that the MIC be computed on that byte array. A Profile MAY specify 1083 another behavior. 1085 8.2.4. Header Fields 1087 The SCHC F/R messages contain the following fields (see the formats 1088 in Section 8.3): 1090 o Rule ID: this field is present in all the SCHC F/R messages. It 1091 is used to identify 1093 * that a SCHC F/R message is being carried, as opposed to an 1094 unfragmented SCHC Packet, 1096 * which SCHC F/R mode is used 1098 * and for this mode 1100 + if windows are used and what the value of WINDOW_SIZE is, 1102 + what other optional fields are present and what the field 1103 sizes are. 1105 The Rule ID allows SCHC F/R interleaving non-fragmented SCHC 1106 Packets and SCHC Fragments that carry other SCHC Packets, or 1107 interleaving SCHC Fragments that use different SCHC F/R modes or 1108 different parameters. 1110 o Datagram Tag (DTag). Its size (called T, in bits) is defined by 1111 each Profile for each Rule ID. When T is 0, the DTag field does 1112 not appear in the SCHC F/R messages and the DTag value is defined 1113 as 0. 1115 When T is 0, there can be only one fragmented SCHC Packet in 1116 transit for a given Rule ID. 1118 If T is not 0, DTag 1120 * MUST be set to the same value for all the SCHC F/R messages 1121 related to the same fragmented SCHC Packet, 1123 * MUST be set to different values for SCHC F/R messages related 1124 to different SCHC Packets that are being fragmented under the 1125 same Rule ID and the transmission of which may overlap. 1127 A sequence counter that is incremented for each new fragmented 1128 SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to 1129 0 is RECOMMENDED for maximum traceability and avoidance of 1130 ambiguity. 1132 A flow of SCHC F/R messages with a given Rule ID and DTag value 1133 pair MUST NOT interfere with the operation of a SCHC F/R instance 1134 that uses another Rule ID and DTag value pair. 1136 o W: The W field is optional. It is only present if windows are 1137 used. Its presence and size (called M, in bits) is defined by 1138 each SCHC F/R mode and each Profile for each Rule ID. 1140 This field carries information pertaining to the window a SCHC F/R 1141 message relates to. If present, W MUST carry the same value for 1142 all the SCHC F/R messages related to the same window. Depending 1143 on the mode and Profile, W may carry the full window number, or 1144 just the least significant bit or any other partial representation 1145 of the window number. 1147 o Fragment Compressed Number (FCN). The FCN field is present in the 1148 SCHC Fragment Header. Its size (called N, in bits) is defined by 1149 each Profile for each Rule ID. 1151 This field conveys information about the progress in the sequence 1152 of tiles being transmitted by SCHC Fragment messages. For 1153 example, it can contain a partial, efficient representation of a 1154 larger-sized tile index. The description of the exact use of the 1155 FCN field is left to each SCHC F/R mode. However, two values are 1156 reserved for special purposes. They help control the SCHC F/R 1157 process: 1159 * The FCN value with all the bits equal to 1 (called All-1) 1160 signals the very last tile of a SCHC Packet. By extension, if 1161 windows are used, the last window of a packet is called the 1162 All-1 window. 1164 * If windows are used, the FCN value with all the bits equal to 0 1165 (called All-0) signals the last tile of a window that is not 1166 the last one of the SCHC packet. By extension, such a window 1167 is called an All-0 window. 1169 o Message Integrity Check (MIC). This field only appears in the 1170 All-1 SCHC Fragments. Its size (called U, in bits) is defined by 1171 each Profile for each Rule ID. 1173 See Section 8.2.3 for the MIC default size, default polynomial and 1174 details on MIC computation. 1176 o C (integrity Check): C is a 1-bit field. This field is used in 1177 the SCHC ACK message to report on the reassembled SCHC Packet 1178 integrity check (see Section 8.2.3). 1180 A value of 1 tells that the integrity check was performed and is 1181 successful. A value of 0 tells that the integrity check was not 1182 performed, or that is was a failure. 1184 o Compressed Bitmap. The Compressed Bitmap is used together with 1185 windows and Bitmaps (see Section 8.2.2.3). Its presence and size 1186 is defined for each F/R mode for each Rule ID. 1188 This field appears in the SCHC ACK message to report on the 1189 receiver Bitmap (see Section 8.3.2.1). 1191 8.3. SCHC F/R Message Formats 1193 This section defines the SCHC Fragment formats, the SCHC ACK format, 1194 the SCHC ACK REQ format and the SCHC Abort formats. 1196 8.3.1. SCHC Fragment format 1198 A SCHC Fragment conforms to the general format shown in Figure 13. 1199 It comprises a SCHC Fragment Header and a SCHC Fragment Payload. The 1200 SCHC Fragment Payload carries one or several tile(s). 1202 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1203 | Fragment Header | Fragment Payload | padding (as needed) 1204 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1206 Figure 13: SCHC Fragment general format 1208 8.3.1.1. Regular SCHC Fragment 1210 The Regular SCHC Fragment format is shown in Figure 14. Regular SCHC 1211 Fragments are generally used to carry tiles that are not the last one 1212 of a SCHC Packet. The DTag field and the W field are optional. 1214 |--- SCHC Fragment Header ----| 1215 |-- T --|-M-|-- N --| 1216 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1217 | Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed) 1218 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1220 Figure 14: Detailed Header Format for Regular SCHC Fragments 1222 The FCN field MUST NOT contain all bits set to 1. 1224 The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called 1225 an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC 1226 ACK REQ message (see Section 8.3.3) that has the same T, M and N 1227 values, even in the presence of padding. This condition is met if 1228 the Payload is at least the size of an L2 Word. This condition is 1229 also met if the SCHC Fragment Header is a multiple of L2 Words. 1231 8.3.1.2. All-1 SCHC Fragment 1233 The All-1 SCHC Fragment format is shown in Figure 15. The sender 1234 generally uses the All-1 SCHC Fragment format for the message that 1235 completes the emission of a fragmented SCHC Packet. The DTag field, 1236 the W field, the MIC field and the Payload are optional. At least 1237 one of MIC field or Payload MUST be present. The FCN field is all 1238 ones. 1240 |-------- SCHC Fragment Header -------| 1241 |-- T --|-M-|-- N --|-- U --| 1242 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1243 | Rule ID | DTag | W | 11..1 | MIC | Frag Payload | pad. (as needed) 1244 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1245 (FCN) 1247 Figure 15: Detailed Header Format for the All-1 SCHC Fragment 1249 The All-1 SCHC Fragment message MUST be distinguishable by size from 1250 a SCHC Sender-Abort message (see Section 8.3.4) that has the same T, 1251 M and N values, even in the presence of padding. This condition is 1252 met if the MIC is present and is at least the size of an L2 Word, or 1253 if the Payload is present and at least the size an L2 Word. This 1254 condition is also met if the SCHC Sender-Abort Header is a multiple 1255 of L2 Words. 1257 8.3.2. SCHC ACK format 1259 The SCHC ACK message is shown in Figure 16. The DTag field, the W 1260 field and the Compressed Bitmap field are optional. The Compressed 1261 Bitmap field can only be present in SCHC F/R modes that use windows. 1263 |---- SCHC ACK Header ----| 1264 |-- T --|-M-| 1 | 1265 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1266 | Rule ID | DTag | W |C=1| padding as needed (success) 1267 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1269 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1270 | Rule ID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 1271 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1273 Figure 16: Format of the SCHC ACK message 1275 The SCHC ACK Header contains a C bit (see Section 8.2.4). 1277 If the C bit is set to 1 (integrity check successful), no Bitmap is 1278 carried. 1280 If the C bit is set to 0 (integrity check not performed or failed) 1281 and if windows are used, a Compressed Bitmap for the window referred 1282 to by the W field is transmitted as specified in Section 8.3.2.1. 1284 8.3.2.1. Bitmap Compression 1286 For transmission, the Compressed Bitmap in the SCHC ACK message is 1287 defined by the following algorithm (see Figure 17 for a follow-along 1288 example): 1290 o Build a temporary SCHC ACK message that contains the Header 1291 followed by the original Bitmap (see Section 8.2.2.3 for a 1292 description of Bitmaps). 1294 o Position scissors at the end of the Bitmap, after its last bit. 1296 o While the bit on the left of the scissors is 1 and belongs to the 1297 Bitmap, keep moving left, then stop. When this is done, 1299 o While the scissors are not on an L2 Word boundary of the SCHC ACK 1300 message and there is a Bitmap bit on the right of the scissors, 1301 keep moving right, then stop. 1303 o At this point, cut and drop off any bits to the right of the 1304 scissors 1306 When one or more bits have effectively been dropped off as a result 1307 of the above algorithm, the SCHC ACK message is a multiple of L2 1308 Words, no padding bits will be appended. 1310 Because the SCHC Fragment sender knows the size of the original 1311 Bitmap, it can reconstruct the original Bitmap from the Compressed 1312 Bitmap received in the SCH ACK message. 1314 Figure 17 shows an example where L2 Words are actually bytes and 1315 where the original Bitmap contains 17 bits, the last 15 of which are 1316 all set to 1. 1318 |---- SCHC ACK Header ----|-------- Bitmap --------| 1319 |-- T --|-M-| 1 | 1320 +--- ... -+- ... -+---+---+---------------------------------+ 1321 | Rule ID | DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| 1322 +--- ... -+- ... -+---+---+---------------------------------+ 1323 next L2 Word boundary ->| 1325 Figure 17: SCHC ACK Header plus uncompressed Bitmap 1327 Figure 18 shows that the last 14 bits are not sent. 1329 |---- SCHC ACK Header ----|CpBmp| 1330 |-- T --|-M-| 1 | 1331 +--- ... -+- ... -+---+---+-----+ 1332 | Rule ID | DTag | W |C=0|1 0 1| 1333 +--- ... -+- ... -+---+---+-----+ 1334 next L2 Word boundary ->| 1336 Figure 18: Resulting SCHC ACK message with Compressed Bitmap 1338 Figure 19 shows an example of a SCHC ACK with tile indices ranging 1339 from 6 down to 0, where the Bitmap indicates that the second and the 1340 fourth tile of the window have not been correctly received. 1342 |---- SCHC ACK Header ----|--- Bitmap --| 1343 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1344 +---------+-------+---+---+-------------+ 1345 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1| uncompressed Bitmap 1346 +---------+-------+---+---+-------------+ 1347 next L2 Word boundary ->|<-- L2 Word -->| 1349 +---------+-------+---+---+-------------+~~~+ 1350 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK 1351 +---------+-------+---+---+-------------+~~~+ 1352 next L2 Word boundary ->|<-- L2 Word -->| 1354 Figure 19: Example of a SCHC ACK message, missing tiles 1356 Figure 20 shows an example of a SCHC ACK with FCN ranging from 6 down 1357 to 0, where integrity check has not been performed or has failed and 1358 the Bitmap indicates that there is no missing tile in that window. 1360 |---- SCHC ACK Header ----|--- Bitmap --| 1361 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1362 +---------+-------+---+---+-------------+ 1363 | Rule ID | DTag | W |C=0|1 1 1 1 1 1 1| with uncompressed Bitmap 1364 +---------+-------+---+---+-------------+ 1365 next L2 Word boundary ->| 1367 +--- ... -+- ... -+---+---+-+ 1368 | Rule ID | DTag | W |C=0|1| transmitted SCHC ACK 1369 +--- ... -+- ... -+---+---+-+ 1370 next L2 Word boundary ->| 1372 Figure 20: Example of a SCHC ACK message, no missing tile 1374 8.3.3. SCHC ACK REQ format 1376 The SCHC ACK REQ is used by a sender to request a SCHC ACK from the 1377 receiver. Its format is shown in Figure 21. The DTag field and the 1378 W field are optional. The FCN field is all zero. 1380 |---- SCHC ACK REQ Header ----| 1381 |-- T --|-M-|-- N --| 1382 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1383 | Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) 1384 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1386 Figure 21: SCHC ACK REQ format 1388 8.3.4. SCHC Sender-Abort format 1390 When a SCHC Fragment sender needs to abort an on-going fragmented 1391 SCHC Packet transmission, it sends a SCHC Sender-Abort message to the 1392 SCHC Fragment receiver. 1394 The SCHC Sender-Abort format is shown in Figure 22. The DTag field 1395 and the W field are optional. The FCN field is all ones. 1397 |---- Sender-Abort Header ----| 1398 |-- T --|-M-|-- N --| 1399 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1400 | Rule ID | DTag | W | 11..1 | padding (as needed) 1401 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1403 Figure 22: SCHC Sender-Abort format 1405 If the W field is present, 1407 o the fragment sender MUST set it to all ones. Other values are 1408 RESERVED. 1410 o the fragment receiver MUST check its value. If the value is 1411 different from all ones, the message MUST be ignored. 1413 The SCHC Sender-Abort MUST NOT be acknowledged. 1415 8.3.5. SCHC Receiver-Abort format 1417 When a SCHC Fragment receiver needs to abort an on-going fragmented 1418 SCHC Packet transmission, it transmits a SCHC Receiver-Abort message 1419 to the SCHC Fragment sender. 1421 The SCHC Receiver-Abort format is shown in Figure 23. The DTag field 1422 and the W field are optional. 1424 |--- Receiver-Abort Header ---| 1425 |--- T ---|-M-| 1 | 1426 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Rule ID | DTag | W |C=1| 1..1| 1..1 | 1428 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1429 next L2 Word boundary ->|<-- L2 Word -->| 1431 Figure 23: SCHC Receiver-Abort format 1433 If the W field is present, 1435 o the fragment receiver MUST set it to all ones. Other values are 1436 RESERVED. 1438 o if the value is different from all ones, the fragment sender MUST 1439 ignore the message. 1441 The SCHC Receiver-Abort has the same header as a SCHC ACK message. 1442 The bits that follow the SCHC Receiver-Abort Header MUST be as 1443 follows 1445 o if the Header does not end at an L2 Word boundary, append bits set 1446 to 1 as needed to reach the next L2 Word boundary 1448 o append exactly one more L2 Word with bits all set to ones 1450 Such a bit pattern never occurs in a regular SCHC ACK. This is how 1451 the fragment sender recognizes a SCHC Receiver-Abort. 1453 The SCHC Receiver-Abort MUST NOT be acknowledged. 1455 8.4. SCHC F/R modes 1457 This specification includes several SCHC F/R modes, which 1459 o allow for a range of reliability options, such as optional SCHC 1460 Fragment retransmission 1462 o support various LPWAN characteristics, including variable MTU. 1464 More modes may be defined in the future. 1466 8.4.1. No-ACK mode 1468 The No-ACK mode has been designed under the assumption that data unit 1469 out-of-sequence delivery does not occur between the entity performing 1470 fragmentation and the entity performing reassembly. This mode 1471 supports LPWAN technologies that have a variable MTU. 1473 In No-ACK mode, there is no communication from the fragment receiver 1474 to the fragment sender. The sender transmits all the SCHC Fragments 1475 without expecting acknowledgement. 1477 In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. 1478 The other SCHC Fragments are intrinsically aligned to L2 Words. 1480 The tile sizes are not required to be uniform. Windows are not used. 1481 The Retransmission Timer is not used. The Attempts counter is not 1482 used. 1484 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1485 F/R messages operating in this mode. 1487 The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK 1488 MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort 1489 MAY be sent. SCHC Receiver-Abort MUST NOT be sent. 1491 The value of N (size of the FCN field) is RECOMMENDED to be 1. 1493 Each Profile, for each Rule ID value, MUST define 1495 o the size of the DTag field, 1497 o the size and algorithm for the MIC field, 1499 o the expiration time of the Inactivity Timer 1501 Each Profile, for each Rule ID value, MAY define 1503 o a value of N different from the recommended one, 1505 o the meaning of values sent in the FCN field, for values different 1506 from the All-1 value. 1508 For each active pair of Rule ID and DTag values, the receiver MUST 1509 maintain an Inactivity Timer. 1511 8.4.1.1. Sender behavior 1513 At the beginning of the fragmentation of a new SCHC Packet, the 1514 fragment sender MUST select a Rule ID and DTag value pair for this 1515 SCHC Packet. 1517 Each SCHC Fragment MUST contain exactly one tile in its Payload. The 1518 tile MUST be at least the size of an L2 Word. The sender MUST 1519 transmit the SCHC Fragments messages in the order that the tiles 1520 appear in the SCHC Packet. Except for the last tile of a SCHC 1521 Packet, each tile MUST be of a size that complements the SCHC 1522 Fragment Header so that the SCHC Fragment is a multiple of L2 Words 1523 without the need for padding bits. Except for the last one, the SCHC 1524 Fragments MUST use the Regular SCHC Fragment format specified in 1525 Section 8.3.1.1. The last SCHC Fragment MUST use the All-1 format 1526 specified in Section 8.3.1.2. 1528 The sender MAY transmit a SCHC Sender-Abort. 1530 Figure 38 shows an example of a corresponding state machine. 1532 8.4.1.2. Receiver behavior 1534 Upon receiving each Regular SCHC Fragment, 1536 o the receiver MUST reset the Inactivity Timer, 1538 o the receiver assembles the payloads of the SCHC Fragments 1540 On receiving an All-1 SCHC Fragment, 1542 o the receiver MUST append the All-1 SCHC Fragment Payload and the 1543 padding bits to the previously received SCHC Fragment Payloads for 1544 this SCHC Packet 1546 o the receiver MUST perform the integrity check 1548 o if integrity checking fails, the receiver MUST drop the 1549 reassembled SCHC Packet 1551 o the reassembly operation concludes. 1553 On expiration of the Inactivity Timer, the receiver MUST drop the 1554 SCHC Packet being reassembled. 1556 On receiving a SCHC Sender-Abort, the receiver MAY drop the SCHC 1557 Packet being reassembled. 1559 Figure 39 shows an example of a corresponding state machine. 1561 8.4.2. ACK-Always mode 1563 The ACK-Always mode has been designed under the following assumptions 1565 o Data unit out-of-sequence delivery does not occur between the 1566 entity performing fragmentation and the entity performing 1567 reassembly 1569 o The L2 MTU value does not change while the fragments of a SCHC 1570 Packet are being being transmitted. 1572 In ACK-Always mode, windows are used. An acknowledgement, positive 1573 or negative, is transmitted by the fragment receiver to the fragment 1574 sender at the end of the transmission of each window of SCHC 1575 Fragments. 1577 The tiles are not required to be of uniform size. In ACK-Always 1578 mode, only the All-1 SCHC Fragment is padded as needed. The other 1579 SCHC Fragments are intrinsically aligned to L2 Words. 1581 Briefly, the algorithm is as follows: after a first blind 1582 transmission of all the tiles of a window, the fragment sender 1583 iterates retransmitting the tiles that are reported missing until the 1584 fragment receiver reports that all the tiles belonging to the window 1585 have been correctly received, or until too many attempts were made. 1586 The fragment sender only advances to the next window of tiles when it 1587 has ascertained that all the tiles belonging to the current window 1588 have been fully and correctly received. This results in a per-window 1589 lock-step behavior between the sender and the receiver. 1591 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1592 F/R messages operating in this mode. 1594 The W field MUST be present and its size M MUST be 1 bit. 1596 Each Profile, for each Rule ID value, MUST define 1598 o the value of N (size of the FCN field), 1600 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 1602 o the size and algorithm for the MIC field, 1604 o the size of the DTag field, 1606 o the value of MAX_ACK_REQUESTS, 1607 o the expiration time of the Retransmission Timer 1609 o the expiration time of the Inactivity Timer 1611 For each active pair of Rule ID and DTag values, the sender MUST 1612 maintain 1614 o one Attempts counter 1616 o one Retransmission Timer 1618 For each active pair of Rule ID and DTag values, the receiver MUST 1619 maintain an Inactivity Timer. 1621 8.4.2.1. Sender behavior 1623 At the beginning of the fragmentation of a new SCHC Packet, the 1624 fragment sender MUST select a Rule ID and DTag value pair for this 1625 SCHC Packet. 1627 Each SCHC Fragment MUST contain exactly one tile in its Payload. All 1628 tiles with the index 0, as well as the last tile, MUST be at least 1629 the size of an L2 Word. 1631 In all SCHC Fragment messages, the W field MUST be filled with the 1632 least significant bit of the window number that the sender is 1633 currently processing. 1635 For a SCHC Fragment that carries a tile other than the last one of 1636 the SCHC Packet, 1638 o the Fragment MUST be of the Regular type specified in 1639 Section 8.3.1.1 1641 o the FCN field MUST contain the tile index 1643 o each tile MUST be of a size that complements the SCHC Fragment 1644 Header so that the SCHC Fragment is a multiple of L2 Words without 1645 the need for padding bits. 1647 The SCHC Fragment that carries the last tile MUST be an All-1 SCHC 1648 Fragment, described in Section 8.3.1.2. 1650 The fragment sender MUST start by transmitting the window numbered 0. 1652 The sender starts by a "blind transmission" phase, in which it MUST 1653 transmit all the tiles composing the window, in decreasing tile index 1654 order. 1656 Then, it enters a "retransmission phase" in which it MUST initialize 1657 an Attempts counter to 0, it MUST start a Retransmission Timer and it 1658 MUST await a SCHC ACK. Then, 1660 o upon receiving a SCHC ACK, 1662 * if the SCHC ACK indicates that some tiles are missing at the 1663 receiver, then the sender MUST transmit all the tiles that have 1664 been reported missing, it MUST increment Attempts, it MUST 1665 reset the Retransmission Timer and MUST await the next SCHC 1666 ACK. 1668 * if the current window is not the last one and the SCHC ACK 1669 indicates that all tiles were correctly received, the sender 1670 MUST stop the Retransmission Timer, it MUST advance to the next 1671 fragmentation window and it MUST start a blind transmission 1672 phase as described above. 1674 * if the current window is the last one and the SCHC ACK 1675 indicates that more tiles were received than the sender sent, 1676 the fragment sender MUST send a SCHC Sender-Abort, and it MAY 1677 exit with an error condition. 1679 * if the current window is the last one and the SCHC ACK 1680 indicates that all tiles were correctly received yet integrity 1681 check was a failure, the fragment sender MUST send a SCHC 1682 Sender-Abort, and it MAY exit with an error condition. 1684 * if the current window is the last one and the SCHC ACK 1685 indicates that integrity checking was successful, the sender 1686 exits successfully. 1688 o on Retransmission Timer expiration, 1690 * if Attempts is strictly less that MAX_ACK_REQUESTS, the 1691 fragment sender MUST send a SCHC ACK REQ and MUST increment the 1692 Attempts counter. 1694 * otherwise the fragment sender MUST send a SCHC Sender-Abort, 1695 and it MAY exit with an error condition. 1697 At any time, 1699 o on receiving a SCHC Receiver-Abort, the fragment sender MAY exit 1700 with an error condition. 1702 o on receiving a SCHC ACK that bears a W value different from the W 1703 value that it currently uses, the fragment sender MUST silently 1704 discard and ignore that SCHC ACK. 1706 Figure 40 shows an example of a corresponding state machine. 1708 8.4.2.2. Receiver behavior 1710 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 1711 processed at that time 1713 o the receiver SHOULD check if the DTag value has not recently been 1714 used for that Rule ID value, thereby ensuring that the received 1715 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 1716 transmission. If the SCHC Fragment is determined to be such a 1717 remnant, the receiver MAY silently ignore it and discard it. 1719 o the receiver MUST start a process to assemble a new SCHC Packet 1720 with that Rule ID and DTag value pair. 1722 o the receiver MUST start an Inactivity Timer. It MUST initialize 1723 an Attempts counter to 0. It MUST initialize a window counter to 1724 0. 1726 In the rest of this section, "local W bit" means the least 1727 significant bit of the window counter of the receiver. 1729 On reception of any SCHC F/R message, the receiver MUST reset the 1730 Inactivity Timer. 1732 Entering an "acceptance phase", the receiver MUST first initialize an 1733 empty Bitmap for this window, then 1735 o on receiving a SCHC Fragment or SCHC ACK REQ with the W bit 1736 different from the local W bit, the receiver MUST silently ignore 1737 and discard that message. 1739 o on receiving a SCHC Fragment with the W bit equal to the local W 1740 bit, the receiver MUST assemble the received tile based on the 1741 window counter and on the FCN field in the SCHC Fragment and it 1742 MUST update the Bitmap. 1744 * if the SCHC Fragment received is an All-0 SCHC Fragment, the 1745 current window is determined to be a not-last window, and the 1746 receiver MUST send a SCHC ACK for this window. Then, 1748 + If the Bitmap indicates that all the tiles of the current 1749 window have been correctly received, the receiver MUST 1750 increment its window counter and it enters the "acceptance 1751 phase" for that new window. 1753 + If the Bitmap indicates that at least one tile is missing in 1754 the current window, the receiver enters the "retransmission 1755 phase" for this window. 1757 * if the SCHC Fragment received is an All-1 SCHC Fragment, the 1758 padding bits of the All-1 SCHC Fragment MUST be assembled after 1759 the received tile, the current window is determined to be the 1760 last window, the receiver MUST perform the integrity check and 1761 it MUST send a SCHC ACK for this window. Then, 1763 + If the integrity check indicates that the full SCHC Packet 1764 has been correctly reassembled, the receiver MUST enter the 1765 "clean-up phase". 1767 + If the integrity check indicates that the full SCHC Packet 1768 has not been correctly reassembled, the receiver enters the 1769 "retransmission phase" for this window. 1771 o on receiving a SCHC ACK REQ with the W bit equal to the local W 1772 bit, the receiver has not yet determined if the current window is 1773 a not-last one or the last one, the receiver MUST send a SCHC ACK 1774 for this window, and it keeps accepting incoming messages. 1776 In the "retransmission phase": 1778 o if the window is a not-last window 1780 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1781 different from the local W bit the receiver MUST silently 1782 ignore and discard that message. 1784 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1785 bit, the receiver MUST send a SCHC ACK for this window. 1787 * on receiving a SCHC Fragment with a W bit equal to the local W 1788 bit, 1790 + if the SCHC Fragment received is an All-1 SCHC Fragment, the 1791 receiver MUST silently ignore it and discard it. 1793 + otherwise, the receiver MUST update the Bitmap and it MUST 1794 assemble the tile received. 1796 * on the Bitmap becoming fully populated with 1's, the receiver 1797 MUST send a SCHC ACK for this window, it MUST increment its 1798 window counter and it enters the "acceptance phase" for the new 1799 window. 1801 o if the window is the last window 1803 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1804 different from the local W bit the receiver MUST silently 1805 ignore and discard that message. 1807 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1808 bit, the receiver MUST send a SCHC ACK for this window. 1810 * on receiving a SCHC Fragment with a W bit equal to the local W 1811 bit, 1813 + if the SCHC Fragment received is an All-0 SCHC Fragment, the 1814 receiver MUST silently ignore it and discard it. 1816 + otherwise, the receiver MUST update the Bitmap and it MUST 1817 assemble the tile received. If the SCHC Fragment received 1818 is an All-1 SCHC Fragment, the receiver MUST assemble the 1819 padding bits of the All-1 SCHC Fragment after the received 1820 tile. It MUST perform the integrity check. Then 1822 - if the integrity check indicates that the full SCHC 1823 Packet has been correctly reassembled, the receiver MUST 1824 send a SCHC ACK and it enters the "clean-up phase". 1826 - if the integrity check indicates that the full SCHC 1827 Packet has not been correctly reassembled, 1829 o if the SCHC Fragment received was an All-1 SCHC 1830 Fragment, the receiver MUST send a SCHC ACK for this 1831 window 1833 o it keeps accepting incoming messages. 1835 In the "clean-up phase": 1837 o Any received SCHC F/R message with a W bit different from the 1838 local W bit MUST be silently ignored and discarded. 1840 o Any received SCHC F/R message different from an All-1 SCHC 1841 Fragment or a SCHC ACK REQ MUST be silently ignored and discarded. 1843 o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, the 1844 receiver MUST send a SCHC ACK. 1846 At any time, on expiration of the Inactivity Timer, on receiving a 1847 SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the 1848 receiver MUST send a SCHC Receiver-Abort and it MAY exit the receive 1849 process for that SCHC Packet. 1851 Figure 41 shows an example of a corresponding state machine. 1853 8.4.3. ACK-on-Error mode 1855 The ACK-on-Error mode supports LPWAN technologies that have variable 1856 MTU and out-of-order delivery. 1858 In ACK-on-Error mode, windows are used. All tiles MUST be of equal 1859 size, except for the last one, which MUST be of the same size or 1860 smaller than the regular ones. If allowed in a Profile, the 1861 penultimate tile MAY be exactly one L2 Word smaller than the regular 1862 tile size. 1864 A SCHC Fragment message carries one or more tiles, which may span 1865 multiple windows. A SCHC ACK reports on the reception of exactly one 1866 window of tiles. 1868 See Figure 24 for an example. 1870 +---------------------------------------------...-----------+ 1871 | SCHC Packet | 1872 +---------------------------------------------...-----------+ 1874 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| 1875 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| 1877 SCHC Fragment msg |-----------| 1879 Figure 24: a SCHC Packet fragmented in tiles, Ack-on-Error mode 1881 The W field is wide enough that it unambiguously represents an 1882 absolute window number. The fragment receiver sends SCHC ACKs to the 1883 fragment sender about windows for which tiles are missing. No SCHC 1884 ACK is sent by the fragment receiver for windows that it knows have 1885 been fully received. 1887 The fragment sender retransmits SCHC Fragments for tiles that are 1888 reported missing. It can advance to next windows even before it has 1889 ascertained that all tiles belonging to previous windows have been 1890 correctly received, and can still later retransmit SCHC Fragments 1891 with tiles belonging to previous windows. Therefore, the sender and 1892 the receiver may operate in a decoupled fashion. The fragmented SCHC 1893 Packet transmission concludes when 1895 o integrity checking shows that the fragmented SCHC Packet has been 1896 correctly reassembled at the receive end, and this information has 1897 been conveyed back to the sender, 1899 o or too many retransmission attempts were made, 1901 o or the receiver determines that the transmission of this 1902 fragmented SCHC Packet has been inactive for too long. 1904 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1905 F/R messages operating in this mode. 1907 The W field MUST be present in the SCHC F/R messages. 1909 Each Profile, for each Rule ID value, MUST define 1911 o the tile size (a tile does not need to be multiple of an L2 Word, 1912 but it MUST be at least the size of an L2 Word) 1914 o the value of M (size of the W field), 1916 o the value of N (size of the FCN field), 1918 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 1920 o the size and algorithm for the MIC field, 1922 o the size of the DTag field, 1924 o the value of MAX_ACK_REQUESTS, 1926 o the expiration time of the Retransmission Timer 1928 o the expiration time of the Inactivity Timer 1930 o if the last tile is carried in a Regular SCHC Fragment or an All-1 1931 SCHC Fragment (see Section 8.4.3.1) 1933 o if the penultimate tile MAY be one L2 Word smaller than the 1934 regular tile size. In this case, the regular tile size MUST be at 1935 least twice the L2 Word size. 1937 For each active pair of Rule ID and DTag values, the sender MUST 1938 maintain 1939 o one Attempts counter 1941 o one Retransmission Timer 1943 For each active pair of Rule ID and DTag values, the receiver MUST 1944 maintain an Inactivity Timer. 1946 8.4.3.1. Sender behavior 1948 At the beginning of the fragmentation of a new SCHC Packet, 1950 o the fragment sender MUST select a Rule ID and DTag value pair for 1951 this SCHC Packet. A Rule MUST NOT be selected if the values of M 1952 and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot 1953 be fragmented in (2^M) * WINDOW_SIZE tiles or less. 1955 o the fragment sender MUST initialize the Attempts counter to 0 for 1956 that Rule ID and DTag value pair. 1958 A SCHC Fragment message carries in its payload one or more tiles. If 1959 more than one tile is carried in one SCHC Fragment 1961 o the selected tiles MUST be consecutive in the original SCHC Packet 1963 o they MUST be placed in the SCHC Fragment Payload adjacent to one 1964 another, in the order they appear in the SCHC Packet, from the 1965 start of the SCHC Packet toward its end. 1967 Tiles that are not the last one MUST be sent in Regular SCHC 1968 Fragments specified in Section 8.3.1.1. The FCN field MUST contain 1969 the tile index of the first tile sent in that SCHC Fragment. 1971 In a Regular SCHC Fragment message, the sender MUST fill the W field 1972 with the window number of the first tile sent in that SCHC Fragment. 1974 Depending on the Profile, the last tile of a SCHC Packet MUST be sent 1975 either 1977 o in a Regular SCHC Fragment, alone or as part of a multi-tiles 1978 Payload 1980 o alone in an All-1 SCHC Fragment 1982 In an All-1 SCHC Fragment message, the sender MUST fill the W field 1983 with the window number of the last tile of the SCHC Packet. 1985 The fragment sender MUST send SCHC Fragments such that, all together, 1986 they contain all the tiles of the fragmented SCHC Packet. 1988 The fragment sender MUST send at least one All-1 SCHC Fragment. 1990 The fragment sender MUST listen for SCHC ACK messages after having 1991 sent 1993 o an All-1 SCHC Fragment 1995 o or a SCHC ACK REQ with the W field corresponding to the last 1996 window. 1998 A Profile MAY specify other times at which the fragment sender MUST 1999 listen for SCHC ACK messages. For example, this could be after 2000 sending a complete window of tiles. 2002 Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC 2003 ACK REQ, 2005 o it MUST increment the Attempts counter 2007 o it MUST reset the Retransmission Timer 2009 On Retransmission Timer expiration 2011 o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment 2012 sender MUST send a SCHC ACK REQ with the W field corresponding to 2013 the last window and it MUST increment the Attempts counter 2015 o otherwise the fragment sender MUST send a SCHC Sender-Abort and it 2016 MAY exit with an error condition. 2018 On receiving a SCHC ACK, 2020 o if the W field in the SCHC ACK corresponds to the last window of 2021 the SCHC Packet, 2023 * if the C bit is set, the sender MAY exit successfully 2025 * otherwise, 2027 + if the SCHC ACK shows no missing tile at the receiver, the 2028 sender 2030 - MUST send a SCHC Sender-Abort 2032 - MAY exit with an error condition 2034 + otherwise 2035 - the fragment sender MUST send SCHC Fragment messages 2036 containing all the tiles that are reported missing in the 2037 SCHC ACK. 2039 - if the last message in this sequence of SCHC Fragment 2040 messages is not an All-1 SCHC Fragment, then the fragment 2041 sender MUST send a SCHC ACK REQ with the W field 2042 corresponding to the last window after the sequence. 2044 o otherwise, the fragment sender 2046 * MUST send SCHC Fragment messages containing the tiles that are 2047 reported missing in the SCHC ACK 2049 * then it MAY send a SCHC ACK REQ with the W field corresponding 2050 to the last window 2052 See Figure 42 for one among several possible examples of a Finite 2053 State Machine implementing a sender behavior obeying this 2054 specification. 2056 8.4.3.2. Receiver behavior 2058 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 2059 processed at that time 2061 o the receiver SHOULD check if the DTag value has not recently been 2062 used for that Rule ID value, thereby ensuring that the received 2063 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 2064 transmission. If the SCHC Fragment is determined to be such a 2065 remnant, the receiver MAY silently ignore it and discard it. 2067 o the receiver MUST start a process to assemble a new SCHC Packet 2068 with that Rule ID and DTag value pair. 2070 o the receiver MUST start an Inactivity Timer. It MUST initialize 2071 an Attempts counter to 0. 2073 On receiving any SCHC F/R message, the receiver MUST reset the 2074 Inactivity Timer. 2076 On receiving a SCHC Fragment message, the receiver determines what 2077 tiles were received, based on the payload length and on the W and FCN 2078 fields of the SCHC Fragment. 2080 o if the FCN is All-1, if a Payload is present, the full SCHC 2081 Fragment Payload MUST be assembled including the padding bits. 2082 This is because the size of the last tile is not known by the 2083 receiver, therefore padding bits are indistinguishable from the 2084 tile data bits, at this stage. They will be removed by the SCHC 2085 C/D sublayer. If the size of the SCHC Fragment Payload exceeds or 2086 equals the size of one regular tile plus the size of an L2 Word, 2087 this SHOULD raise an error flag. 2089 o otherwise, tiles MUST be assembled based on the a priori known 2090 tile size. 2092 * If allowed by the Profile, the end of the payload MAY contain 2093 the last tile, which may be shorter. Padding bits are 2094 indistinguishable from the tile data bits, at this stage. 2096 * the payload may contain the penultimate tile that, if allowed 2097 by the Profile, MAY be exactly one L2 Word shorter than the 2098 regular tile size. 2100 * Otherwise, padding bits MUST be discarded. The latter is 2101 possible because 2103 + the size of the tiles is known a priori, 2105 + tiles are larger than an L2 Word 2107 + padding bits are always strictly less than an L2 Word 2109 On receiving a SCHC ACK REQ or an All-1 SCHC Fragment, 2111 o if the receiver has at least one window that it knows has tiles 2112 missing, it MUST return a SCHC ACK for the lowest-numbered such 2113 window, 2115 o otherwise, 2117 * if it has received at least one tile, it MUST return a SCHC ACK 2118 for the highest-numbered window it currently has tiles for 2120 * otherwise it MUST return a SCHC ACK for window numbered 0 2122 A Profile MAY specify other times and circumstances at which a 2123 receiver sends a SCHC ACK, and which window the SCHC ACK reports 2124 about in these circumstances. 2126 Upon sending a SCHC ACK, the receiver MUST increase the Attempts 2127 counter. 2129 After receiving an All-1 SCHC Fragment, a receiver MUST check the 2130 integrity of the reassembled SCHC Packet at least every time it 2131 prepares for sending a SCHC ACK for the last window. 2133 Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an 2134 error condition. 2136 Upon expiration of the Inactivity Timer, the receiver MUST send a 2137 SCHC Receiver-Abort and it MAY exit with an error condition. 2139 On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST 2140 send a SCHC Receiver-Abort and it MAY exit with an error condition. 2142 Reassembly of the SCHC Packet concludes when 2144 o a Sender-Abort has been received 2146 o or the Inactivity Timer has expired 2148 o or the Attempts counter has exceeded MAX_ACK_REQUESTS 2150 o or when at least an All-1 SCHC Fragment has been received and 2151 integrity checking of the reassembled SCHC Packet is successful. 2153 See Figure 43 for one among several possible examples of a Finite 2154 State Machine implementing a receiver behavior obeying this 2155 specification, and that is meant to match the sender Finite State 2156 Machine of Figure 42. 2158 9. Padding management 2160 SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does 2161 not have any alignment prerequisite. The size of SCHC Packets can be 2162 any number of bits. 2164 If the layer below SCHC constrains the payload to align to some 2165 boundary, called L2 Words (for example, bytes), the SCHC messages 2166 MUST be padded. When padding occurs, the number of appended bits 2167 MUST be strictly less than the L2 Word size. 2169 If a SCHC Packet is sent unfragmented (see Figure 25), it is padded 2170 as needed for transmission. 2172 If a SCHC Packet needs to be fragmented for transmission, it is not 2173 padded in itself. Only the SCHC F/R messages are padded as needed 2174 for transmission. Some SCHC F/R messages are intrinsically aligned 2175 to L2 Words. 2177 A packet (e.g. an IPv6 packet) 2178 | ^ (padding bits 2179 v | dropped) 2180 +------------------+ +--------------------+ 2181 | SCHC Compression | | SCHC Decompression | 2182 +------------------+ +--------------------+ 2183 | ^ 2184 | If no fragmentation | 2185 +---- SCHC Packet + padding as needed ----->| 2186 | | (integrity 2187 v | checked) 2188 +--------------------+ +-----------------+ 2189 | SCHC Fragmentation | | SCHC Reassembly | 2190 +--------------------+ +-----------------+ 2191 | ^ | ^ 2192 | | | | 2193 | +------------- SCHC ACK ------------+ | 2194 | | 2195 +------- SCHC Fragments + padding as needed---------+ 2197 SENDER RECEIVER 2199 Figure 25: SCHC operations, including padding as needed 2201 Each Profile MUST specify the size of the L2 Word. The L2 Word might 2202 actually be a single bit, in which case no padding will take place at 2203 all. 2205 A Profile MAY define the value of the padding bits. The RECOMMENDED 2206 value is 0. 2208 10. SCHC Compression for IPv6 and UDP headers 2210 This section lists the IPv6 and UDP header fields and describes how 2211 they can be compressed. 2213 10.1. IPv6 version field 2215 This field always holds the same value. In the Rule, TV is set to 6, 2216 MO to "equal" and CDA to "not-sent". 2218 10.2. IPv6 Traffic class field 2220 If the DiffServ field does not vary and is known by both sides, the 2221 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2222 value, an "equal" MO and a "not-sent" CDA. 2224 Otherwise (e.g. ECN bits are to be transmitted), two possibilities 2225 can be considered depending on the variability of the value: 2227 o One possibility is to not compress the field and send the original 2228 value. In the Rule, TV is not set to any particular value, MO is 2229 set to "ignore" and CDA is set to "value-sent". 2231 o If some upper bits in the field are constant and known, a better 2232 option is to only send the LSBs. In the Rule, TV is set to a 2233 value with the stable known upper part, MO is set to MSB(x) and 2234 CDA to LSB. 2236 10.3. Flow label field 2238 If the Flow Label field does not vary and is known by both sides, the 2239 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2240 value, an "equal" MO and a "not-sent" CDA. 2242 Otherwise, two possibilities can be considered: 2244 o One possibility is to not compress the field and send the original 2245 value. In the Rule, TV is not set to any particular value, MO is 2246 set to "ignore" and CDA is set to "value-sent". 2248 o If some upper bits in the field are constant and known, a better 2249 option is to only send the LSBs. In the Rule, TV is set to a 2250 value with the stable known upper part, MO is set to MSB(x) and 2251 CDA to LSB. 2253 10.4. Payload Length field 2255 This field can be elided for the transmission on the LPWAN network. 2256 The SCHC C/D recomputes the original payload length value. In the 2257 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 2258 "compute-IPv6-length". 2260 If the payload length needs to be sent and does not need to be coded 2261 in 16 bits, the TV can be set to 0x0000, the MO set to MSB(16-s) 2262 where 's' is the number of bits to code the maximum length, and CDA 2263 is set to LSB. 2265 10.5. Next Header field 2267 If the Next Header field does not vary and is known by both sides, 2268 the Field Descriptor in the Rule SHOULD contain a TV with this Next 2269 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 2270 sent". 2272 Otherwise, TV is not set in the Field Descriptor, MO is set to 2273 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 2274 list MAY also be used. 2276 10.6. Hop Limit field 2278 The field behavior for this field is different for uplink (Up) and 2279 downlink (Dw). In Up, since there is no IP forwarding between the 2280 Dev and the SCHC C/D, the value is relatively constant. On the other 2281 hand, the Dw value depends on Internet routing and can change more 2282 frequently. The Direction Indicator (DI) can be used to distinguish 2283 both directions: 2285 o in the Up, elide the field: the TV in the Field Descriptor is set 2286 to the known constant value, the MO is set to "equal" and the CDA 2287 is set to "not-sent". 2289 o in the Dw, send the value: TV is not set, MO is set to "ignore" 2290 and CDA is set to "value-sent". 2292 10.7. IPv6 addresses fields 2294 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 2295 long fields; one for the prefix and one for the Interface Identifier 2296 (IID). These fields SHOULD be compressed. To allow for a single 2297 Rule being used for both directions, these values are identified by 2298 their role (Dev or App) and not by their position in the header 2299 (source or destination). 2301 10.7.1. IPv6 source and destination prefixes 2303 Both ends MUST be configured with the appropriate prefixes. For a 2304 specific flow, the source and destination prefixes can be unique and 2305 stored in the Context. It can be either a link-local prefix or a 2306 global prefix. In that case, the TV for the source and destination 2307 prefixes contain the values, the MO is set to "equal" and the CDA is 2308 set to "not-sent". 2310 If the Rule is intended to compress packets with different prefix 2311 values, match-mapping SHOULD be used. The different prefixes are 2312 listed in the TV, the MO is set to "match-mapping" and the CDA is set 2313 to "mapping-sent". See Figure 27 2315 Otherwise, the TV contains the prefix, the MO is set to "equal" and 2316 the CDA is set to "value-sent". 2318 10.7.2. IPv6 source and destination IID 2320 If the Dev or App IID are based on an LPWAN address, then the IID can 2321 be reconstructed with information coming from the LPWAN header. In 2322 that case, the TV is not set, the MO is set to "ignore" and the CDA 2323 is set to "DevIID" or "AppIID". The LPWAN technology generally 2324 carries a single identifier corresponding to the Dev. AppIID cannot 2325 be used. 2327 For privacy reasons or if the Dev address is changing over time, a 2328 static value that is not equal to the Dev address SHOULD be used. In 2329 that case, the TV contains the static value, the MO operator is set 2330 to "equal" and the CDA is set to "not-sent". [RFC7217] provides some 2331 methods that MAY be used to derive this static identifier. 2333 If several IIDs are possible, then the TV contains the list of 2334 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 2335 "mapping-sent". 2337 It MAY also happen that the IID variability only expresses itself on 2338 a few bytes. In that case, the TV is set to the stable part of the 2339 IID, the MO is set to "MSB" and the CDA is set to "LSB". 2341 Finally, the IID can be sent in its entirety on the LPWAN. In that 2342 case, the TV is not set, the MO is set to "ignore" and the CDA is set 2343 to "value-sent". 2345 10.8. IPv6 extensions 2347 No Rule is currently defined that processes IPv6 extensions. 2349 10.9. UDP source and destination port 2351 To allow for a single Rule being used for both directions, the UDP 2352 port values are identified by their role (Dev or App) and not by 2353 their position in the header (source or destination). The SCHC C/D 2354 MUST be aware of the traffic direction (Uplink, Downlink) to select 2355 the appropriate field. The following Rules apply for Dev and App 2356 port numbers. 2358 If both ends know the port number, it can be elided. The TV contains 2359 the port number, the MO is set to "equal" and the CDA is set to "not- 2360 sent". 2362 If the port variation is on few bits, the TV contains the stable part 2363 of the port number, the MO is set to "MSB" and the CDA is set to 2364 "LSB". 2366 If some well-known values are used, the TV can contain the list of 2367 these values, the MO is set to "match-mapping" and the CDA is set to 2368 "mapping-sent". 2370 Otherwise the port numbers are sent over the LPWAN. The TV is not 2371 set, the MO is set to "ignore" and the CDA is set to "value-sent". 2373 10.10. UDP length field 2375 The UDP length can be computed from the received data. In that case, 2376 the TV is not set, the MO is set to "ignore" and the CDA is set to 2377 "compute-length". 2379 If the payload is small, the TV can be set to 0x0000, the MO set to 2380 "MSB" and the CDA to "LSB". 2382 In other cases, the length SHOULD be sent and the CDA is replaced by 2383 "value-sent". 2385 10.11. UDP Checksum field 2387 The UDP checksum operation is mandatory with IPv6 for most packets 2388 but there are exceptions [RFC8200]. 2390 For instance, protocols that use UDP as a tunnel encapsulation may 2391 enable zero-checksum mode for a specific port (or set of ports) for 2392 sending and/or receiving. [RFC8200] requires any node implementing 2393 zero-checksum mode to follow the requirements specified in 2394 "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero 2395 Checksums" [RFC6936]. 2397 6LoWPAN Header Compression [RFC6282] also specifies that a UDP 2398 datagram can be sent without a checksum when an upper layer 2399 guarantees the integrity of the UDP payload and pseudo-header. A 2400 specific example of this is when a Message Integrity Check (MIC) 2401 protects the compressed message between the compressor that elides 2402 the UDP checksum and the decompressor that computes it, with a 2403 strength that is identical or better to the UDP checksum. 2405 Similarly, a SCHC compressor MAY elide the UDP checksum when another 2406 layer guarantees at least equal integrity protection for the UDP 2407 payload and the pseudo-header. In this case, the TV is not set, the 2408 MO is set to "ignore" and the CDA is set to "compute-checksum". 2410 In particular, when SCHC fragmentation is used, a fragmentation MIC 2411 of 2 bytes or more provides equal or better protection than the UDP 2412 checksum; in that case, if the compressor is collocated with the 2413 fragmentation point and the decompressor is collocated with the 2414 packet reassembly point, and if the SCHC Packet is fragmented even 2415 when it would fit unfragmented in the L2 MTU, then the compressor MAY 2416 elide the UDP checksum. Whether and when the UDP Checksum is elided 2417 is to be specified in the Profile. 2419 Since the compression happens before the fragmentation, implementors 2420 should understand the risks when dealing with unprotected data below 2421 the transport layer and take special care when manipulating that 2422 data. 2424 In other cases, the checksum SHOULD be explicitly sent. The TV is 2425 not set, the MO is set to "ignore" and the CDA is set to "value- 2426 sent". 2428 11. IANA Considerations 2430 This document has no request to IANA. 2432 12. Security considerations 2434 12.1. Security considerations for SCHC Compression/Decompression 2436 A malicious header compression could cause the reconstruction of a 2437 wrong packet that does not match with the original one. Such a 2438 corruption MAY be detected with end-to-end authentication and 2439 integrity mechanisms. Header Compression does not add more security 2440 problem than what is already needed in a transmission. For instance, 2441 to avoid an attack, never re-construct a packet bigger than 2442 MAX_PACKET_SIZE (with 1500 bytes as generic default). 2444 12.2. Security considerations for SCHC Fragmentation/Reassembly 2446 This subsection describes potential attacks to LPWAN SCHC F/R and 2447 suggests possible countermeasures. 2449 A node can perform a buffer reservation attack by sending a first 2450 SCHC Fragment to a target. Then, the receiver will reserve buffer 2451 space for the IPv6 packet. Other incoming fragmented SCHC Packets 2452 will be dropped while the reassembly buffer is occupied during the 2453 reassembly timeout. Once that timeout expires, the attacker can 2454 repeat the same procedure, and iterate, thus creating a denial of 2455 service attack. The (low) cost to mount this attack is linear with 2456 the number of buffers at the target node. However, the cost for an 2457 attacker can be increased if individual SCHC Fragments of multiple 2458 packets can be stored in the reassembly buffer. To further increase 2459 the attack cost, the reassembly buffer can be split into SCHC 2460 Fragment-sized buffer slots. Once a packet is complete, it is 2461 processed normally. If buffer overload occurs, a receiver can 2462 discard packets based on the sender behavior, which MAY help identify 2463 which SCHC Fragments have been sent by an attacker. 2465 In another type of attack, the malicious node is required to have 2466 overhearing capabilities. If an attacker can overhear a SCHC 2467 Fragment, it can send a spoofed duplicate (e.g. with random payload) 2468 to the destination. If the LPWAN technology does not support 2469 suitable protection (e.g. source authentication and frame counters to 2470 prevent replay attacks), a receiver cannot distinguish legitimate 2471 from spoofed SCHC Fragments. The original IPv6 packet will be 2472 considered corrupt and will be dropped. To protect resource- 2473 constrained nodes from this attack, it has been proposed to establish 2474 a binding among the SCHC Fragments to be transmitted by a node, by 2475 applying content-chaining to the different SCHC Fragments, based on 2476 cryptographic hash functionality. The aim of this technique is to 2477 allow a receiver to identify illegitimate SCHC Fragments. 2479 Further attacks can involve sending overlapped fragments (i.e. 2480 comprising some overlapping parts of the original IPv6 datagram). 2481 Implementers MUST ensure that the correct operation is not affected 2482 by such event. 2484 In ACK-on-Error, a malicious node MAY force a SCHC Fragment sender to 2485 resend a SCHC Fragment a number of times, with the aim to increase 2486 consumption of the SCHC Fragment sender's resources. To this end, 2487 the malicious node MAY repeatedly send a fake ACK to the SCHC 2488 Fragment sender, with a Bitmap that reports that one or more SCHC 2489 Fragments have been lost. In order to mitigate this possible attack, 2490 MAX_ACK_RETRIES MAY be set to a safe value which allows to limit the 2491 maximum damage of the attack to an acceptable extent. However, note 2492 that a high setting for MAX_ACK_RETRIES benefits SCHC Fragment 2493 reliability modes, therefore the trade-off needs to be carefully 2494 considered. 2496 13. Acknowledgements 2498 Thanks to Carsten Bormann, Philippe Clavier, Diego Dujovne, Eduardo 2499 Ingles Sanchez, Arunprabhu Kandasamy, Rahul Jadhav, Sergio Lopez 2500 Bernal, Antony Markovski, Alexander Pelov, Charles Perkins, Edgar 2501 Ramos, Shoichi Sakane, and Pascal Thubert for useful design 2502 consideration and comments. 2504 Carles Gomez has been funded in part by the Spanish Government 2505 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2506 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2507 Government through project TEC2016-79988-P. Part of his contribution 2508 to this work has been carried out during his stay as a visiting 2509 scholar at the Computer Laboratory of the University of Cambridge. 2511 14. References 2513 14.1. Normative References 2515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2516 Requirement Levels", BCP 14, RFC 2119, 2517 DOI 10.17487/RFC2119, March 1997, 2518 . 2520 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2521 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2522 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2523 . 2525 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2526 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2527 May 2017, . 2529 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2530 (IPv6) Specification", STD 86, RFC 8200, 2531 DOI 10.17487/RFC8200, July 2017, 2532 . 2534 14.2. Informative References 2536 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 2537 "Internet Protocol Small Computer System Interface (iSCSI) 2538 Cyclic Redundancy Check (CRC)/Checksum Considerations", 2539 RFC 3385, DOI 10.17487/RFC3385, September 2002, 2540 . 2542 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2543 "Transmission of IPv6 Packets over IEEE 802.15.4 2544 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2545 . 2547 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2548 Header Compression (ROHC) Framework", RFC 5795, 2549 DOI 10.17487/RFC5795, March 2010, 2550 . 2552 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2553 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2554 DOI 10.17487/RFC6282, September 2011, 2555 . 2557 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2558 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2559 February 2014, . 2561 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2562 Interface Identifiers with IPv6 Stateless Address 2563 Autoconfiguration (SLAAC)", RFC 7217, 2564 DOI 10.17487/RFC7217, April 2014, 2565 . 2567 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2568 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2569 . 2571 Appendix A. Compression Examples 2573 This section gives some scenarios of the compression mechanism for 2574 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2576 The mechanisms defined in this document can be applied to a Dev that 2577 embeds some applications running over CoAP. In this example, three 2578 flows are considered. The first flow is for the device management 2579 based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 2580 124 for Dev and App, respectively. The second flow will be a CoAP 2581 server for measurements done by the Dev (using ports 5683) and Global 2582 IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is 2583 for legacy applications using different ports numbers, the 2584 destination IPv6 address prefix is gamma::1/64. 2586 Figure 26 presents the protocol stack. IPv6 and UDP are represented 2587 with dotted lines since these protocols are compressed on the radio 2588 link. 2590 Management Data 2591 +----------+---------+---------+ 2592 | CoAP | CoAP | legacy | 2593 +----||----+---||----+---||----+ 2594 . UDP . UDP | UDP | 2595 ................................ 2596 . IPv6 . IPv6 . IPv6 . 2597 +------------------------------+ 2598 | SCHC Header compression | 2599 | and fragmentation | 2600 +------------------------------+ 2601 | LPWAN L2 technologies | 2602 +------------------------------+ 2603 Dev or NGW 2605 Figure 26: Simplified Protocol Stack for LP-WAN 2607 In some LPWAN technologies, only the Devs have a device ID. When 2608 such technologies are used, it is necessary to statically define an 2609 IID for the Link Local address for the SCHC C/D. 2611 Rule 0 2612 +----------------+--+--+--+---------+--------+------------++------+ 2613 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 2614 | | | | | | Opera. | Action ||[bits]| 2615 +----------------+--+--+--+---------+---------------------++------+ 2616 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2617 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2618 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2619 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2620 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2621 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2622 |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2623 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2624 |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2625 |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | 2626 +================+==+==+==+=========+========+============++======+ 2627 |UDP DevPort |16|1 |Bi|123 | equal | not-sent || | 2628 |UDP AppPort |16|1 |Bi|124 | equal | not-sent || | 2629 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2630 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2631 +================+==+==+==+=========+========+============++======+ 2633 Rule 1 2634 +----------------+--+--+--+---------+--------+------------++------+ 2635 | Field |FL|FP|DI| Value | Match | Action || Sent | 2636 | | | | | | Opera. | Action ||[bits]| 2637 +----------------+--+--+--+---------+--------+------------++------+ 2638 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2639 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2640 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2641 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2642 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2643 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2644 |IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 | 2645 | | | | |fe80::/64] mapping| || | 2646 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2647 |IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 | 2648 | | | | |alpha/64,| mapping| || | 2649 | | | | |fe80::64]| | || | 2650 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2651 +================+==+==+==+=========+========+============++======+ 2652 |UDP DevPort |16|1 |Bi|5683 | equal | not-sent || | 2653 |UDP AppPort |16|1 |Bi|5683 | equal | not-sent || | 2654 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2655 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2656 +================+==+==+==+=========+========+============++======+ 2658 Rule 2 2659 +----------------+--+--+--+---------+--------+------------++------+ 2660 | Field |FL|FP|DI| Value | Match | Action || Sent | 2661 | | | | | | Opera. | Action ||[bits]| 2662 +----------------+--+--+--+---------+--------+------------++------+ 2663 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2664 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2665 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2666 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2667 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2668 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2669 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 | 2670 |IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2671 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2672 |IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2673 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2674 +================+==+==+==+=========+========+============++======+ 2675 |UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2676 |UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2677 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2678 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2679 +================+==+==+==+=========+========+============++======+ 2681 Figure 27: Context Rules 2683 All the fields described in the three Rules depicted on Figure 27 are 2684 present in the IPv6 and UDP headers. The DevIID-DID value is found 2685 in the L2 header. 2687 The second and third Rules use global addresses. The way the Dev 2688 learns the prefix is not in the scope of the document. 2690 The third Rule compresses each port number to 4 bits. 2692 Appendix B. Fragmentation Examples 2694 This section provides examples for the various fragment reliability 2695 modes specified in this document. In the drawings, Bitmaps are shown 2696 in their uncompressed form. 2698 Figure 28 illustrates the transmission in No-ACK mode of a SCHC 2699 Packet that needs 11 SCHC Fragments. FCN is 1 bit wide. 2701 Sender Receiver 2702 |-------FCN=0-------->| 2703 |-------FCN=0-------->| 2704 |-------FCN=0-------->| 2705 |-------FCN=0-------->| 2706 |-------FCN=0-------->| 2707 |-------FCN=0-------->| 2708 |-------FCN=0-------->| 2709 |-------FCN=0-------->| 2710 |-------FCN=0-------->| 2711 |-------FCN=0-------->| 2712 |-----FCN=1 + MIC --->| Integrity check: success 2713 (End) 2715 Figure 28: No-ACK mode, 11 SCHC Fragments 2717 In the following examples, N (the size of the FCN field) is 3 bits. 2718 The All-1 FCN value is 7. 2720 Figure 29 illustrates the transmission in ACK-on-Error mode of a SCHC 2721 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2722 WINDOW_SIZE=7 and no lost SCHC Fragment. 2724 Sender Receiver 2725 |-----W=0, FCN=6----->| 2726 |-----W=0, FCN=5----->| 2727 |-----W=0, FCN=4----->| 2728 |-----W=0, FCN=3----->| 2729 |-----W=0, FCN=2----->| 2730 |-----W=0, FCN=1----->| 2731 |-----W=0, FCN=0----->| 2732 (no ACK) 2733 |-----W=1, FCN=6----->| 2734 |-----W=1, FCN=5----->| 2735 |-----W=1, FCN=4----->| 2736 |--W=1, FCN=7 + MIC-->| Integrity check: success 2737 |<-- ACK, W=1, C=1 ---| C=1 2738 (End) 2740 Figure 29: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2741 no lost SCHC Fragment. 2743 Figure 30 illustrates the transmission in ACK-on-Error mode of a SCHC 2744 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2745 WINDOW_SIZE=7 and three lost SCHC Fragments. 2747 Sender Receiver 2748 |-----W=0, FCN=6----->| 2749 |-----W=0, FCN=5----->| 2750 |-----W=0, FCN=4--X-->| 2751 |-----W=0, FCN=3----->| 2752 |-----W=0, FCN=2--X-->| 2753 |-----W=0, FCN=1----->| 2754 |-----W=0, FCN=0----->| 6543210 2755 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2756 |-----W=0, FCN=4----->| 2757 |-----W=0, FCN=2----->| 2758 (no ACK) 2759 |-----W=1, FCN=6----->| 2760 |-----W=1, FCN=5----->| 2761 |-----W=1, FCN=4--X-->| 2762 |- W=1, FCN=7 + MIC ->| Integrity check: failure 2763 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 2764 |-----W=1, FCN=4----->| Integrity check: success 2765 |<-- ACK, W=1, C=1 ---| C=1 2766 (End) 2768 Figure 30: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2769 lost SCHC Fragments. 2771 Figure 31 shows an example of a transmission in ACK-on-Error mode of 2772 a SCHC Packet fragmented in 73 tiles, with N=5, WINDOW_SIZE=28, M=2 2773 and 3 lost SCHC Fragments. 2775 Sender Receiver 2776 |-----W=0, FCN=27----->| 4 tiles sent 2777 |-----W=0, FCN=23----->| 4 tiles sent 2778 |-----W=0, FCN=19----->| 4 tiles sent 2779 |-----W=0, FCN=15--X-->| 4 tiles sent (not received) 2780 |-----W=0, FCN=11----->| 4 tiles sent 2781 |-----W=0, FCN=7 ----->| 4 tiles sent 2782 |-----W=0, FCN=3 ----->| 4 tiles sent 2783 |-----W=1, FCN=27----->| 4 tiles sent 2784 |-----W=1, FCN=23----->| 4 tiles sent 2785 |-----W=1, FCN=19----->| 4 tiles sent 2786 |-----W=1, FCN=15----->| 4 tiles sent 2787 |-----W=1, FCN=11----->| 4 tiles sent 2788 |-----W=1, FCN=7 ----->| 4 tiles sent 2789 |-----W=1, FCN=3 --X-->| 4 tiles sent (not received) 2790 |-----W=2, FCN=27----->| 4 tiles sent 2791 |-----W=2, FCN=23----->| 4 tiles sent 2792 ^ |-----W=2, FCN=19----->| 1 tile sent 2793 | |-----W=2, FCN=18----->| 1 tile sent 2794 | |-----W=2, FCN=17----->| 1 tile sent 2795 |-----W=2, FCN=16----->| 1 tile sent 2796 s |-----W=2, FCN=15----->| 1 tile sent 2797 m |-----W=2, FCN=14----->| 1 tile sent 2798 a |-----W=2, FCN=13--X-->| 1 tile sent (not received) 2799 l |-----W=2, FCN=12----->| 1 tile sent 2800 l |---W=2, FCN=31 + MIC->| Integrity check: failure 2801 e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 2802 r |-----W=0, FCN=15----->| 1 tile sent 2803 |-----W=0, FCN=14----->| 1 tile sent 2804 L |-----W=0, FCN=13----->| 1 tile sent 2805 2 |-----W=0, FCN=12----->| 1 tile sent 2806 |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 2807 M |-----W=1, FCN=3 ----->| 1 tile sent 2808 T |-----W=1, FCN=2 ----->| 1 tile sent 2809 U |-----W=1, FCN=1 ----->| 1 tile sent 2810 |-----W=1, FCN=0 ----->| 1 tile sent 2811 | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 2812 | |-----W=2, FCN=13----->| Integrity check: success 2813 V |<--- ACK, W=2, C=1 ---| C=1 2814 (End) 2816 Figure 31: ACK-on-Error mode, variable MTU. 2818 In this example, the L2 MTU becomes reduced just before sending the 2819 "W=2, FCN=19" fragment, leaving space for only 1 tile in each 2820 forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are 2821 carried by a total of 25 SCHC Fragments, the last 9 being of smaller 2822 size. 2824 Note: other sequences of events (e.g. regarding when ACKs are sent by 2825 the Receiver) are also allowed by this specification. Profiles may 2826 restrict this flexibility. 2828 Figure 32 illustrates the transmission in ACK-Always mode of a SCHC 2829 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with 2830 N=3, WINDOW_SIZE=7 and no loss. 2832 Sender Receiver 2833 |-----W=0, FCN=6----->| 2834 |-----W=0, FCN=5----->| 2835 |-----W=0, FCN=4----->| 2836 |-----W=0, FCN=3----->| 2837 |-----W=0, FCN=2----->| 2838 |-----W=0, FCN=1----->| 2839 |-----W=0, FCN=0----->| 2840 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2841 |-----W=1, FCN=6----->| 2842 |-----W=1, FCN=5----->| 2843 |-----W=1, FCN=4----->| 2844 |--W=1, FCN=7 + MIC-->| Integrity check: success 2845 |<-- ACK, W=1, C=1 ---| C=1 2846 (End) 2848 Figure 32: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, no 2849 loss. 2851 Figure 33 illustrates the transmission in ACK-Always mode of a SCHC 2852 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, 2853 WINDOW_SIZE=7 and three lost SCHC Fragments. 2855 Sender Receiver 2856 |-----W=0, FCN=6----->| 2857 |-----W=0, FCN=5----->| 2858 |-----W=0, FCN=4--X-->| 2859 |-----W=0, FCN=3----->| 2860 |-----W=0, FCN=2--X-->| 2861 |-----W=0, FCN=1----->| 2862 |-----W=0, FCN=0----->| 6543210 2863 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2864 |-----W=0, FCN=4----->| 2865 |-----W=0, FCN=2----->| 2866 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2867 |-----W=1, FCN=6----->| 2868 |-----W=1, FCN=5----->| 2869 |-----W=1, FCN=4--X-->| 2870 |--W=1, FCN=7 + MIC-->| Integrity check: failure 2871 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001 2872 |-----W=1, FCN=4----->| Integrity check: success 2873 |<-- ACK, W=1, C=1 ---| C=1 2874 (End) 2876 Figure 33: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, 2877 three lost SCHC Fragments. 2879 Figure 34 illustrates the transmission in ACK-Always mode of a SCHC 2880 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2881 WINDOW_SIZE=7, three lost SCHC Fragments and only one retry needed to 2882 recover each lost SCHC Fragment. 2884 Sender Receiver 2885 |-----W=0, FCN=6----->| 2886 |-----W=0, FCN=5----->| 2887 |-----W=0, FCN=4--X-->| 2888 |-----W=0, FCN=3--X-->| 2889 |-----W=0, FCN=2--X-->| 2890 |--W=0, FCN=7 + MIC-->| Integrity check: failure 2891 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2892 |-----W=0, FCN=4----->| Integrity check: failure 2893 |-----W=0, FCN=3----->| Integrity check: failure 2894 |-----W=0, FCN=2----->| Integrity check: success 2895 |<-- ACK, W=0, C=1 ---| C=1 2896 (End) 2898 Figure 34: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, 2899 three lost SCHC Fragments. 2901 Figure 35 illustrates the transmission in ACK-Always mode of a SCHC 2902 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2903 WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK 2904 lost. 2906 Sender Receiver 2907 |-----W=0, FCN=6----->| 2908 |-----W=0, FCN=5----->| 2909 |-----W=0, FCN=4--X-->| 2910 |-----W=0, FCN=3--X-->| 2911 |-----W=0, FCN=2--X-->| 2912 |--W=0, FCN=7 + MIC-->| Integrity check: failure 2913 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2914 |-----W=0, FCN=4----->| Integrity check: failure 2915 |-----W=0, FCN=3----->| Integrity check: failure 2916 |-----W=0, FCN=2----->| Integrity check: success 2917 |<-X-ACK, W=0, C=1 ---| C=1 2918 timeout | | 2919 |--- W=0, ACK REQ --->| ACK REQ 2920 |<-- ACK, W=0, C=1 ---| C=1 2921 (End) 2923 Figure 35: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, SCHC 2924 ACK loss. 2926 Figure 36 illustrates the transmission in ACK-Always mode of a SCHC 2927 Packet fragmented in 6 tiles, with N=3, WINDOW_SIZE=7, with three 2928 lost SCHC Fragments, and one retransmitted SCHC Fragment lost again. 2930 Sender Receiver 2931 |-----W=0, FCN=6----->| 2932 |-----W=0, FCN=5----->| 2933 |-----W=0, FCN=4--X-->| 2934 |-----W=0, FCN=3--X-->| 2935 |-----W=0, FCN=2--X-->| 2936 |--W=0, FCN=7 + MIC-->| Integrity check: failure 2937 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2938 |-----W=0, FCN=4----->| Integrity check: failure 2939 |-----W=0, FCN=3----->| Integrity check: failure 2940 |-----W=0, FCN=2--X-->| 2941 timeout| | 2942 |--- W=0, ACK REQ --->| ACK REQ 2943 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 2944 |-----W=0, FCN=2----->| Integrity check: success 2945 |<-- ACK, W=0, C=1 ---| C=1 2946 (End) 2948 Figure 36: ACK-Always mode, 6 tiles, retransmitted SCHC Fragment lost 2949 again. 2951 Figure 37 illustrates the transmission in ACK-Always mode of a SCHC 2952 Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, 2953 WINDOW_SIZE=24 and two lost SCHC Fragments. 2955 Sender Receiver 2956 |-----W=0, FCN=23----->| 2957 |-----W=0, FCN=22----->| 2958 |-----W=0, FCN=21--X-->| 2959 |-----W=0, FCN=20----->| 2960 |-----W=0, FCN=19----->| 2961 |-----W=0, FCN=18----->| 2962 |-----W=0, FCN=17----->| 2963 |-----W=0, FCN=16----->| 2964 |-----W=0, FCN=15----->| 2965 |-----W=0, FCN=14----->| 2966 |-----W=0, FCN=13----->| 2967 |-----W=0, FCN=12----->| 2968 |-----W=0, FCN=11----->| 2969 |-----W=0, FCN=10--X-->| 2970 |-----W=0, FCN=9 ----->| 2971 |-----W=0, FCN=8 ----->| 2972 |-----W=0, FCN=7 ----->| 2973 |-----W=0, FCN=6 ----->| 2974 |-----W=0, FCN=5 ----->| 2975 |-----W=0, FCN=4 ----->| 2976 |-----W=0, FCN=3 ----->| 2977 |-----W=0, FCN=2 ----->| 2978 |-----W=0, FCN=1 ----->| 2979 |-----W=0, FCN=0 ----->| 2980 | | 2981 |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 2982 |-----W=0, FCN=21----->| 2983 |-----W=0, FCN=10----->| 2984 |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 2985 |-----W=1, FCN=23----->| 2986 |-----W=1, FCN=22----->| 2987 |-----W=1, FCN=21----->| 2988 |--W=1, FCN=31 + MIC-->| Integrity check: success 2989 |<--- ACK, W=1, C=1 ---| C=1 2990 (End) 2992 Figure 37: ACK-Always mode, 28 tiles, one tile per SCHC Fragment, 2993 lost SCHC Fragments. 2995 Appendix C. Fragmentation State Machines 2997 The fragmentation state machines of the sender and the receiver, one 2998 for each of the different reliability modes, are described in the 2999 following figures: 3001 +===========+ 3002 +------------+ Init | 3003 | FCN=0 +===========+ 3004 | No Window 3005 | No Bitmap 3006 | +-------+ 3007 | +========+==+ | More Fragments 3008 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 3009 +--------> | Send | send Fragment (FCN=0) 3010 +===+=======+ 3011 | last fragment 3012 | ~~~~~~~~~~~~ 3013 | FCN = 1 3014 v send fragment+MIC 3015 +============+ 3016 | END | 3017 +============+ 3019 Figure 38: Sender State Machine for the No-ACK Mode 3021 +------+ Not All-1 3022 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 3023 | + <--+ set Inactivity Timer 3024 | RCV Frag +-------+ 3025 +=+===+======+ |All-1 & 3026 All-1 & | | |MIC correct 3027 MIC wrong | |Inactivity | 3028 | |Timer Exp. | 3029 v | | 3030 +==========++ | v 3031 | Error |<-+ +========+==+ 3032 +===========+ | END | 3033 +===========+ 3035 Figure 39: Receiver State Machine for the No-ACK Mode 3036 +=======+ 3037 | INIT | FCN!=0 & more frags 3038 | | ~~~~~~~~~~~~~~~~~~~~~~ 3039 +======++ +--+ send Window + frag(FCN) 3040 W=0 | | | FCN- 3041 Clear lcl_bm | | v set lcl_bm 3042 FCN=max value | ++==+========+ 3043 +> | | 3044 +---------------------> | SEND | 3045 | +==+===+=====+ 3046 | FCN==0 & more frags | | last frag 3047 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 3048 | set lcl_bm | | set lcl_bm 3049 | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC 3050 | set Retrans_Timer | | set Retrans_Timer 3051 | | | 3052 |Recv_wnd == wnd & | | 3053 |lcl_bm==recv_bm & | | +----------------------+ 3054 |more frag | | | lcl_bm!=rcv-bm | 3055 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 3056 |Stop Retrans_Timer | | | Attempt++ v 3057 |clear lcl_bm v v | +=====+=+ 3058 |window=next_window +====+===+==+===+ |Resend | 3059 +---------------------+ | |Missing| 3060 +----+ Wait | |Frag | 3061 not expected wnd | | Bitmap | +=======+ 3062 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 3063 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 3064 | | | ^ ^ |reSend(empty)All-* | 3065 | | | | | |Set Retrans_Timer | 3066 | | | | +--+Attempt++ | 3067 MIC_bit==1 & | | | +-------------------------+ 3068 Recv_window==window & | | | all missing frags sent 3069 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 3070 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 3071 Stop Retrans_Timer| | | 3072 +=============+ | | | 3073 | END +<--------+ | | 3074 +=============+ | | Attempt > MAX_ACK_REQUESTS 3075 All-1 Window & | | ~~~~~~~~~~~~~~~~~~ 3076 MIC_bit ==0 & | v Send Abort 3077 lcl_bm==recv_bm | +=+===========+ 3078 ~~~~~~~~~~~~ +>| ERROR | 3079 Send Abort +=============+ 3081 Figure 40: Sender State Machine for the ACK-Always Mode 3083 Not All- & w=expected +---+ +---+w = Not expected 3084 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 3085 Set lcl_bm(FCN) | v v |discard 3086 ++===+===+===+=+ 3087 +---------------------+ Rcv +--->* ABORT 3088 | +------------------+ Window | 3089 | | +=====+==+=====+ 3090 | | All-0 & w=expect | ^ w =next & not-All 3091 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 3092 | | set lcl_bm(FCN) | |expected = next window 3093 | | send lcl_bm | |Clear lcl_bm 3094 | | | | 3095 | | w=expected & not-All | | 3096 | | ~~~~~~~~~~~~~~~~~~ | | 3097 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0 3098 | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~ 3099 | | send lcl_bm | | | | | | expected = nxt wnd 3100 | | v | v | | | Clear lcl_bm 3101 | |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN) 3102 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm 3103 | | discard +--| Next | 3104 | | All-0 +---------+ Window +--->* ABORT 3105 | | ~~~~~ +-------->+========+=++ 3106 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 3107 | | & MIC wrong| | & MIC right 3108 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 3109 | | set lcl_bm(FCN)| |set lcl_bm(FCN) 3110 | | send lcl_bm| |send lcl_bm 3111 | | | +----------------------+ 3112 | |All-1 & w=expected | | 3113 | |& MIC wrong v +---+ w=expected & | 3114 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong | 3115 | |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ | 3116 | |send lcl_bm | Wait End | set lcl_bm(FCN)| 3117 | +--------------------->+ +--->* ABORT | 3118 | +===+====+=+-+ All-1&MIC wrong| 3119 | | ^ | ~~~~~~~~~~~~~~~| 3120 | w=expected & MIC right | +---+ send lcl_bm | 3121 | ~~~~~~~~~~~~~~~~~~~~~~ | | 3122 | set lcl_bm(FCN) | +-+ Not All-1 | 3123 | send lcl_bm | | | ~~~~~~~~~ | 3124 | | | | discard | 3125 |All-1&w=expected & MIC right | | | | 3126 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 3127 |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 3128 |send lcl_bm | +<+Send lcl_bm | 3129 +-------------------------->+ END | | 3130 +==========+<---------------+ 3132 --->* ABORT 3133 ~~~~~~~ 3134 Inactivity_Timer = expires 3135 When DWL 3136 IF Inactivity_Timer expires 3137 Send DWL Request 3138 Attempt++ 3140 Figure 41: Receiver State Machine for the ACK-Always Mode 3142 +=======+ 3143 | | 3144 | INIT | 3145 | | FCN!=0 & more frags 3146 +======++ ~~~~~~~~~~~~~~~~~~~~~~ 3147 Frag RuleID trigger | +--+ Send cur_W + frag(FCN); 3148 ~~~~~~~~~~~~~~~~~~~ | | | FCN--; 3149 cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp] 3150 clear [cur_W, Bmp_n];| | v 3151 clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND 3152 +->+ | cur_W==rcv_W & 3153 **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp 3154 +-------------------------->+ | & more frags 3155 | +----------------------->+ | ~~~~~~~~~~~~ 3156 | | ++===+=========+ cur_W++; 3157 | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] 3158 | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~ 3159 | | set cur_Bmp; | |set [cur_W, Bmp_n]; 3160 | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+MIC; 3161 | | set Retrans_Timer| |set Retrans_Timer 3162 | | | | +-----------------------------------+ 3163 | |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| 3164 | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ | 3165 | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W | 3166 | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &| 3167 | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp| 3168 | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| 3169 | +-------------------+ | | Resend | Attempts++;| 3170 +----------------------+ Wait x ACK | | Missing | W=Wn | 3171 +--------------------->+ | | Frags(W) +<-------------+ 3172 | rcv_W==Wn &+-+ | +======+====+ 3173 | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ | 3174 | ~~~~~~~~~~~~~~| ^ | | | ^ | 3175 | send (cur_W,+--+ | | | +-------------+ 3176 | ALL-0-empty) | | | all missing frag sent(W) 3177 | | | | ~~~~~~~~~~~~~~~~~ 3178 | Retrans_Timer expires &| | | set Retrans_Timer 3179 | No more Frags| | | 3180 | ~~~~~~~~~~~~~~| | | 3181 | stop Retrans_Timer;| | | 3182 |(re)send frag(All-1)+MIC | | | 3183 +-------------------------+ | | 3184 cur_W==rcv_W&| | 3185 [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS 3186 No more Frags & MIC flag==OK| | ~~~~~~~~~~ 3187 ~~~~~~~~~~~~~~~~~~| | send Abort 3188 +=========+stop Retrans_Timer| | +===========+ 3189 | END +<-----------------+ +->+ ERROR | 3190 +=========+ +===========+ 3192 Figure 42: Sender State Machine for the ACK-on-Error Mode 3194 This is an example only. It is not normative. The specification in 3195 Section 8.4.3.1 allows for sequences of operations different from the 3196 one shown here. 3198 +=======+ New frag RuleID received 3199 | | ~~~~~~~~~~~~~ 3200 | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); 3201 +=======+ |sync=0 3202 | 3203 Not All* & rcv_W==cur_W+---+ | +---+ 3204 ~~~~~~~~~~~~~~~~~~~~ | | | | (E) 3205 set[cur_W,Bmp_n(FCN)]| v v v | 3206 ++===+=+=+===+=+ 3207 +----------------------+ +--+ All-0&Full[cur_W,Bmp_n] 3208 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~ 3209 | +-------------------+ +<-+ cur_W++;set Inact_timer; 3210 | | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n] 3211 | | All-0 empty(Wn)| | | | ^ ^ 3212 | | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0; 3213 | | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n]) 3214 | | | | | |& All* || last_miss_frag 3215 | | | | | |~~~~~~~~~~~~~~~~~~~~~~ 3216 | | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); 3217 | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) 3218 | |&no_full([cur_W,Bmp_n])| |(E)| 3219 | | ~~~~~~~~~~~~~~~~ | | | | +========+ 3220 | | sendACK([cur_W,Bmp_n])| | | | | Error/ | 3221 | | | | | | +----+ | Abort | 3222 | | v v | | | | +===+====+ 3223 | | +===+=+=+=+===+=+ (D) ^ 3224 | | +--+ Wait x | | | 3225 | | All-0 empty(Wn)+->| Missing Frags |<-+ | 3226 | | ~~~~~~~~~~~~~~ +=============+=+ | 3227 | | sendACK([Wn,Bmp_n]) +--------------+ 3228 | | *ABORT 3229 v v 3230 (A)(B) 3231 (D) All* || last_miss_frag 3232 (C) All* & sync>0 & rcv_W!=cur_W & sync>0 3233 ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) 3234 Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ 3235 sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; 3236 sendACK([Wn,Bmp_n]);sync-- 3238 ABORT-->* Uplink Only & 3239 Inact_Timer expires 3240 (E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS 3241 ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ 3242 sync++; cur_W=rcv_W; send Abort 3243 set[cur_W,Bmp_n(FCN)] 3245 (A)(B) 3246 | | 3247 | | All-1 & rcv_W==cur_W & MIC!=OK All-0 empty(Wn) 3248 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~ 3249 | | sendACK([cur_W,Bmp_n],MIC=0) | v sendACK([Wn,Bmp_n]) 3250 | | +===========+=++ 3251 | +--------------------->+ Wait End +-+ 3252 | +=====+=+====+=+ | All-1 3253 | rcv_W==cur_W & MIC==OK | | ^ | & rcv_W==cur_W 3254 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & MIC!=OK 3255 | sendACK([cur_W,Bmp_n],MIC=1) | | ~~~~~~~~~~~~~~~~~~~ 3256 | | | sendACK([cur_W,Bmp_n],MIC=0); 3257 | | | Attempts++ 3258 |All-1 & Full([cur_W,Bmp_n]) | | 3259 |& MIC==OK & sync==0 | +-->* ABORT 3260 |~~~~~~~~~~~~~~~~~~~ v 3261 |sendACK([cur_W,Bmp_n],MIC=1) +=+=========+ 3262 +---------------------------->+ END | 3263 +===========+ 3265 Figure 43: Receiver State Machine for the ACK-on-Error Mode 3267 Appendix D. SCHC Parameters 3269 This section lists the information that need to be provided in the 3270 LPWAN technology-specific documents. 3272 o Most common uses cases, deployment scenarios 3274 o Mapping of the SCHC architectural elements onto the LPWAN 3275 architecture 3277 o Assessment of LPWAN integrity checking 3279 o Various potential channel conditions for the technology and the 3280 corresponding recommended use of SCHC C/D and F/R 3282 This section lists the parameters that need to be defined in the 3283 Profile. 3285 o Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs, 3286 number of Rules, the way the Rule ID is transmitted 3288 o define the maximum packet size that should ever be reconstructed 3289 by SCHC Decompression (MAX_PACKET_SIZE). See Section 12. 3291 o Padding: size of the L2 Word (for most LPWAN technologies, this 3292 would be a byte; for some technologies, a bit) 3294 o Decision to use SCHC fragmentation mechanism or not. If yes: 3296 * reliability mode(s) used, in which cases (e.g. based on link 3297 channel condition) 3299 * Rule ID values assigned to each mode in use 3301 * presence and number of bits for DTag (T) for each Rule ID value 3303 * support for interleaved packet transmission, to what extent 3305 * WINDOW_SIZE, for modes that use windows 3307 * number of bits for W (M) for each Rule ID value, for modes that 3308 use windows 3310 * number of bits for FCN (N) for each Rule ID value 3312 * size of MIC and algorithm for its computation, for each Rule 3313 ID, if different from the default CRC32. Byte fill-up with 3314 zeroes or other mechanism, to be specified. 3316 * Retransmission Timer duration for each Rule ID value, if 3317 applicable to the SCHC F/R mode 3319 * Inactivity Timer duration for each Rule ID value, if applicable 3320 to the SCHC F/R mode 3322 * MAX_ACK_REQUEST value for each Rule ID value, if applicable to 3323 the SCHC F/R mode 3325 o if L2 Word is wider than a bit and SCHC fragmentation is used, 3326 value of the padding bits (0 or 1). This is needed because the 3327 padding bits of the last fragment are included in the MIC 3328 computation. 3330 A Profile MAY define a delay to be added after each SCHC message 3331 transmission for compliance with local regulations or other 3332 constraints imposed by the applications. 3334 o In some LPWAN technologies, as part of energy-saving techniques, 3335 downlink transmission is only possible immediately after an uplink 3336 transmission. In order to avoid potentially high delay in the 3337 downlink transmission of a fragmented SCHC Packet, the SCHC 3338 Fragment receiver may perform an uplink transmission as soon as 3339 possible after reception of a SCHC Fragment that is not the last 3340 one. Such uplink transmission may be triggered by the L2 (e.g. an 3341 L2 ACK sent in response to a SCHC Fragment encapsulated in a L2 3342 PDU that requires an L2 ACK) or it may be triggered from an upper 3343 layer. 3345 o the following parameters need to be addressed in documents other 3346 than this one but not necessarily in the LPWAN technology-specific 3347 documents: 3349 * The way the Contexts are provisioned 3351 * The way the Rules are generated 3353 Appendix E. Supporting multiple window sizes for fragmentation 3355 For ACK-Always or ACK-on-Error, implementers MAY opt to support a 3356 single window size or multiple window sizes. The latter, when 3357 feasible, may provide performance optimizations. For example, a 3358 large window size SHOULD be used for packets that need to be split 3359 into a large number of tiles. However, when the number of tiles 3360 required to carry a packet is low, a smaller window size, and thus a 3361 shorter Bitmap, MAY be sufficient to provide reception status on all 3362 tiles. If multiple window sizes are supported, the Rule ID MAY 3363 signal the window size in use for a specific packet transmission. 3365 The same window size MUST be used for the transmission of all tiles 3366 that belong to the same SCHC Packet. 3368 Appendix F. Downlink SCHC Fragment transmission 3370 For downlink transmission of a fragmented SCHC Packet in ACK-Always 3371 mode, the SCHC Fragment receiver MAY support timer-based SCHC ACK 3372 retransmission. In this mechanism, the SCHC Fragment receiver 3373 initializes and starts a timer (the Inactivity Timer is used) after 3374 the transmission of a SCHC ACK, except when the SCHC ACK is sent in 3375 response to the last SCHC Fragment of a packet (All-1 fragment). In 3376 the latter case, the SCHC Fragment receiver does not start a timer 3377 after transmission of the SCHC ACK. 3379 If, after transmission of a SCHC ACK that is not an All-1 fragment, 3380 and before expiration of the corresponding Inactivity timer, the SCHC 3381 Fragment receiver receives a SCHC Fragment that belongs to the 3382 current window (e.g. a missing SCHC Fragment from the current window) 3383 or to the next window, the Inactivity timer for the SCHC ACK is 3384 stopped. However, if the Inactivity timer expires, the SCHC ACK is 3385 resent and the Inactivity timer is reinitialized and restarted. 3387 The default initial value for the Inactivity Timer, as well as the 3388 maximum number of retries for a specific SCHC ACK, denoted 3389 MAX_ACK_RETRIES, are not defined in this document, and need to be 3390 defined in a Profile. The initial value of the Inactivity timer is 3391 expected to be greater than that of the Retransmission timer, in 3392 order to make sure that a (buffered) SCHC Fragment to be 3393 retransmitted can find an opportunity for that transmission. One 3394 exception to this recommendation is the special case of the All-1 3395 SCHC Fragment transmission. 3397 When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it 3398 starts its Retransmission Timer with a large timeout value (e.g. 3399 several times that of the initial Inactivity Timer). If a SCHC ACK 3400 is received before expiration of this timer, the SCHC Fragment sender 3401 retransmits any lost SCHC Fragments reported by the SCHC ACK, or if 3402 the SCHC ACK confirms successful reception of all SCHC Fragments of 3403 the last window, the transmission of the fragmented SCHC Packet is 3404 considered complete. If the timer expires, and no SCHC ACK has been 3405 received since the start of the timer, the SCHC Fragment sender 3406 assumes that the All-1 SCHC Fragment has been successfully received 3407 (and possibly, the last SCHC ACK has been lost: this mechanism 3408 assumes that the Retransmission Timer for the All-1 SCHC Fragment is 3409 long enough to allow several SCHC ACK retries if the All-1 SCHC 3410 Fragment has not been received by the SCHC Fragment receiver, and it 3411 also assumes that it is unlikely that several ACKs become all lost). 3413 Authors' Addresses 3415 Ana Minaburo 3416 Acklio 3417 1137A avenue des Champs Blancs 3418 35510 Cesson-Sevigne Cedex 3419 France 3421 Email: ana@ackl.io 3423 Laurent Toutain 3424 IMT-Atlantique 3425 2 rue de la Chataigneraie 3426 CS 17607 3427 35576 Cesson-Sevigne Cedex 3428 France 3430 Email: Laurent.Toutain@imt-atlantique.fr 3431 Carles Gomez 3432 Universitat Politecnica de Catalunya 3433 C/Esteve Terradas, 7 3434 08860 Castelldefels 3435 Spain 3437 Email: carlesgo@entel.upc.edu 3439 Dominique Barthel 3440 Orange Labs 3441 28 chemin du Vieux Chene 3442 38243 Meylan 3443 France 3445 Email: dominique.barthel@orange.com 3447 Juan Carlos Zuniga 3448 SIGFOX 3449 425 rue Jean Rostand 3450 Labege 31670 3451 France 3453 Email: JuanCarlos.Zuniga@sigfox.com