idnits 2.17.00 (12 Aug 2021) /tmp/idnits38960/draft-ietf-lpwan-ipv6-static-context-hc-19.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 (July 04, 2019) is 1052 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: January 5, 2020 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 D. Barthel 9 Orange Labs 10 JC. Zuniga 11 SIGFOX 12 July 04, 2019 14 Static Context Header Compression (SCHC) and fragmentation for LPWAN, 15 application to UDP/IPv6 16 draft-ietf-lpwan-ipv6-static-context-hc-19 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 January 5, 2020. 63 Copyright Notice 65 Copyright (c) 2019 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 . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . 48 120 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 49 121 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 49 122 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 49 123 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 49 124 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 50 125 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 50 126 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 50 127 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 50 128 10.7.1. IPv6 source and destination prefixes . . . . . . . . 51 129 10.7.2. IPv6 source and destination IID . . . . . . . . . . 51 130 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 51 131 10.9. UDP source and destination port . . . . . . . . . . . . 52 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 . . . . . . . . . . . . . . . . 54 140 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 141 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 142 14.1. Normative References . . . . . . . . . . . . . . . . . . 55 143 14.2. Informative References . . . . . . . . . . . . . . . . . 56 144 Appendix A. Compression Examples . . . . . . . . . . . . . . . . 57 145 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 59 146 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 67 147 Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 73 148 Appendix E. Supporting multiple window sizes for fragmentation . 75 149 Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 75 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 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 LPWAN technologies impose some strict limitations on traffic. For 160 instance, devices sleep most of the time and may only receive data 161 during short periods of time after transmission, in order to preserve 162 battery. LPWAN technologies are also characterized by a greatly 163 reduced data unit and/or payload size (see [RFC8376]). 165 Header compression is needed for efficient Internet connectivity to 166 the node within an LPWAN network. The following properties of LPWAN 167 networks can be exploited to get an efficient header compression: 169 o The network topology is star-oriented, which means that all 170 packets between the same source-destination pair follow the same 171 path. For the needs of this document, the architecture can simply 172 be described as Devices (Dev) exchanging information with LPWAN 173 Application Servers (App) through a Network Gateway (NGW). 175 o Because devices embed built-in applications, the traffic flows to 176 be compressed are known in advance. Indeed, new applications are 177 less frequently installed in an LPWAN device, than they are in a 178 computer or smartphone. 180 SCHC compression uses a Context (a set of Rules) in which information 181 about header fields is stored. This Context is static: the values of 182 the header fields and the actions to do compression/decompression do 183 not change over time. This avoids the need for complex 184 resynchronization mechanisms. Indeed, a return path may be more 185 restricted/expensive, sometimes completely unavailable [RFC8376]. A 186 compression protocol that relies on feedback is not compatible with 187 the characteristics of such LPWANs. 189 In most cases, a small Rule identifier is enough to represent the 190 full IPv6/UDP headers. The SCHC header compression mechanism is 191 independent of the specific LPWAN technology over which it is used. 193 Furthermore, some LPWAN technologies do not provide a fragmentation 194 functionality; to support the IPv6 MTU requirement of 1280 bytes 195 [RFC8200], they require a fragmentation protocol at the adaptation 196 layer below IPv6. Accordingly, this document defines an optional 197 fragmentation/reassembly mechanism for LPWAN technologies to support 198 the IPv6 MTU 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 value 264 of the header field. 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: when a Field is expected to appear multiple times in a header, 297 Field Position specifies the occurence this Field Description 298 applies to (for example, first uri-path option, second uri-path, 299 etc. in a CoAP header). The value 1 designates the first 300 occurence. The default value is 1. 302 o IID: Interface Identifier. See the IPv6 addressing architecture 303 [RFC7136] 305 o L2: Layer two. The immediate lower layer SCHC interfaces with. 306 It is provided by an underlying LPWAN technology. It does not 307 necessarily correspond to the OSI model definition of Layer 2. 309 o L2 Word: this is the minimum subdivision of payload data that the 310 L2 will carry. In most L2 technologies, the L2 Word is an octet. 311 In bit-oriented radio technologies, the L2 Word might be a single 312 bit. The L2 Word size is assumed to be constant over time for 313 each device. 315 o MO: Matching Operator. An operator used to match a value 316 contained in a header field with a value contained in a Rule. 318 o Padding (P). Extra bits that may be appended by SCHC to a data 319 unit that it passes to the underlying Layer 2 for transmission. 320 SCHC itself operates on bits, not bytes, and does not have any 321 alignment prerequisite. See Section 9. 323 o Profile: SCHC offers variations in the way it is operated, with a 324 number of parameters listed in Appendix D. A Profile indicates a 325 particular setting of all these parameters. Both ends of a SCHC 326 communication must be provisioned with the same Profile 327 information and with the same set of Rules before the 328 communication starts, so that there is no ambiguity in how they 329 expect to communicate. 331 o Rule: A set of Field Descriptions. 333 o Rule ID (Rule Identifier): An identifier for a Rule. SCHC C/D on 334 both sides share the same Rule ID for a given packet. A set of 335 Rule IDs are used to support SCHC F/R functionality. 337 o SCHC C/D: SCHC Compressor/Decompressor. A mechanism used on both 338 sides, at the Dev and at the network, to achieve Compression/ 339 Decompression of headers. 341 o SCHC F/R: SCHC Fragmentation / Reassembly. A mechanism used on 342 both sides, at the Dev and at the network, to achieve 343 Fragmentation / Reassembly of SCHC Packets. 345 o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been 346 compressed as per the header compression mechanism defined in this 347 document. If the header compression process is unable to actually 348 compress the packet header, the packet with the uncompressed 349 header is still called a SCHC Packet (in this case, a Rule ID is 350 used to indicate that the packet header has not been compressed). 351 See Section 7 for more details. 353 o TV: Target value. A value contained in a Rule that will be 354 matched with the value of a header field. 356 o Up: Uplink direction for compression/decompression, from the Dev 357 SCHC C/D to the network SCHC C/D. 359 Additional terminology for the optional SCHC Fragmentation / 360 Reassembly mechanism (SCHC F/R) is found in Section 8.2. 362 5. SCHC overview 364 SCHC can be characterized as an adaptation layer between IPv6 and the 365 underlying LPWAN technology. SCHC comprises two sublayers (i.e. the 366 Compression sublayer and the Fragmentation sublayer), as shown in 367 Figure 2. 369 +----------------+ 370 | IPv6 | 371 +- +----------------+ 372 | | Compression | 373 SCHC < +----------------+ 374 | | Fragmentation | 375 +- +----------------+ 376 |LPWAN technology| 377 +----------------+ 379 Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN 380 technology 382 Before a packet (e.g. an IPv6 packet) is transmitted, header 383 compression is first applied. The resulting packet is called a SCHC 384 Packet, whether or not any compression is performed. If the SCHC 385 Packet is to be fragmented, the optional SCHC Fragmentation MAY be 386 applied to the SCHC Packet. The inverse operations take place at the 387 receiver. This process is illustrated in Figure 3. 389 A packet (e.g. an IPv6 packet) 390 | ^ 391 v | 392 +------------------+ +--------------------+ 393 | SCHC Compression | | SCHC Decompression | 394 +------------------+ +--------------------+ 395 | ^ 396 | If no fragmentation (*) | 397 +-------------- SCHC Packet -------------->| 398 | | 399 v | 400 +--------------------+ +-----------------+ 401 | SCHC Fragmentation | | SCHC Reassembly | 402 +--------------------+ +-----------------+ 403 | ^ | ^ 404 | | | | 405 | +-------------- SCHC ACK -------------+ | 406 | | 407 +-------------- SCHC Fragments -------------------+ 409 Sender Receiver 411 *: the decision to use Fragmentation or not is left to each Profile. 413 Figure 3: SCHC operations at the SENDER and the RECEIVER 415 5.1. SCHC Packet format 417 The SCHC Packet is composed of the Compressed Header followed by the 418 payload from the original packet (see Figure 4). The Compressed 419 Header itself is composed of the Rule ID and a Compression Residue, 420 which is the output of compressing the packet header with that Rule 421 (see Section 7). The Compression Residue may be empty. Both the 422 Rule ID and the Compression Residue potentially have a variable size, 423 and are not necessarily a multiple of bytes in size. 425 |------- Compressed Header -------| 426 +---------------------------------+--------------------+ 427 | Rule ID | Compression Residue | Payload | 428 +---------------------------------+--------------------+ 430 Figure 4: SCHC Packet 432 5.2. Functional mapping 434 Figure 5 below maps the functional elements of Figure 3 onto the 435 LPWAN architecture elements of Figure 1. 437 Dev App 438 +----------------+ +----+ +----+ +----+ 439 | App1 App2 App3 | |App1| |App2| |App3| 440 | | | | | | | | 441 | UDP | |UDP | |UDP | |UDP | 442 | IPv6 | |IPv6| |IPv6| |IPv6| 443 | | | | | | | | 444 |SCHC C/D and F/R| | | | | | | 445 +--------+-------+ +----+ +----+ +----+ 446 | +---+ +---+ +----+ +----+ . . . 447 +~ |RGW| === |NGW| == |SCHC| == |SCHC|...... Internet .... 448 +---+ +---+ |F/R | |C/D | 449 +----+ +----+ 451 Figure 5: Architecture 453 SCHC C/D and SCHC F/R are located on both sides of the LPWAN 454 transmission, i.e. on the Dev side and on the Network side. 456 The operation in the Uplink direction is as follows. The Device 457 application uses IPv6 or IPv6/UDP protocols. Before sending the 458 packets, the Dev compresses their headers using SCHC C/D and, if the 459 SCHC Packet resulting from the compression needs to be fragmented by 460 SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC 461 Fragments are sent to an LPWAN Radio Gateway (RGW) which forwards 462 them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/ 463 R for re-assembly (if needed) and then to the SCHC C/D for 464 decompression. After decompression, the packet can be sent over the 465 Internet to one or several LPWAN Application Servers (App). 467 The SCHC F/R and C/D on the Network side can be located in the NGW, 468 or somewhere else as long as a tunnel is established between them and 469 the NGW. For some LPWAN technologies, it may be suitable to locate 470 the SCHC F/R functionality nearer the NGW, in order to better deal 471 with time constraints of such technologies. 473 The SCHC C/Ds on both sides MUST share the same set of Rules. So 474 MUST the SCHC F/Rs on both sides. 476 The operation in the Downlink direction is similar to that in the 477 Uplink direction, only reverting the order in which the architecture 478 elements are traversed. 480 6. Rule ID 482 Rule IDs identify the Rules used for Compression/Decompression or for 483 Fragmentation/Reassembly. 485 The scope of a Rule ID is the link between the SCHC Compressor and 486 the SCHC Decompressor, or between the SCHC Fragmenter and the SCHC 487 Reassembler. 489 The size of the Rule IDs is not specified in this document, as it is 490 implementation-specific and can vary according to the LPWAN 491 technology and the number of Rules, among others. It is defined in 492 Profiles. 494 The Rule IDs are used: 496 o For SCHC C/D, to identify the Rule (i.e., the set of Field 497 Descriptions) that is used to compress a packet header. 499 * At least one Rule ID MUST be allocated to tagging packets for 500 which SCHC compression was not possible (no matching Rule was 501 found). 503 o In SCHC F/R, to identify the specific mode and settings of F/R for 504 one direction of traffic (Up or Dw). 506 * When F/R is used for both communication directions, at least 507 two Rule ID values are needed for F/R, one per direction of 508 traffic. 510 7. Compression/Decompression 512 Compression with SCHC is based on using a set of Rules, called the 513 Context, to compress or decompress headers. SCHC avoids Context 514 synchronization traffic, which consumes considerable bandwidth in 515 other header compression mechanisms such as RoHC [RFC5795]. Since 516 the content of packets is highly predictable in LPWAN networks, 517 static Contexts may be stored beforehand. The Contexts MUST be 518 stored at both ends, and they can be learned by a provisioning 519 protocol or by out of band means, or they can be pre-provisioned. 520 The way the Contexts are provisioned is out of the scope of this 521 document. 523 7.1. SCHC C/D Rules 525 The main idea of the SCHC compression scheme is to transmit the Rule 526 ID to the other end instead of sending known field values. This Rule 527 ID identifies a Rule that matches the original packet values. Hence, 528 when a value is known by both ends, it is only necessary to send the 529 corresponding Rule ID over the LPWAN network. The manner by which 530 Rules are generated is out of the scope of this document. The Rules 531 MAY be changed at run-time but the mechanism is out of scope of this 532 document. 534 The Context is a set of Rules. See Figure 6 for a high level, 535 abstract representation of the Context. The formal specification of 536 the representation of the Rules is outside the scope of this 537 document. 539 Each Rule itself contains a list of Field Descriptions composed of a 540 Field Identifier (FID), a Field Length (FL), a Field Position (FP), a 541 Direction Indicator (DI), a Target Value (TV), a Matching Operator 542 (MO) and a Compression/Decompression Action (CDA). 544 /-----------------------------------------------------------------\ 545 | Rule N | 546 /-----------------------------------------------------------------\| 547 | Rule i || 548 /-----------------------------------------------------------------\|| 549 | (FID) Rule 1 ||| 550 |+-------+--+--+--+------------+-----------------+---------------+||| 551 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 552 |+-------+--+--+--+------------+-----------------+---------------+||| 553 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 554 |+-------+--+--+--+------------+-----------------+---------------+||| 555 ||... |..|..|..| ... | ... | ... |||| 556 |+-------+--+--+--+------------+-----------------+---------------+||/ 557 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 558 |+-------+--+--+--+------------+-----------------+---------------+|/ 559 | | 560 \-----------------------------------------------------------------/ 562 Figure 6: A Compression/Decompression Context 564 A Rule does not describe how the compressor parses a packet header to 565 find and identify each field (e.g. the IPv6 Source Address, the UDP 566 Destination Port or a CoAP URI path option). It is assumed that 567 there is a protocol parser alongside SCHC that is able to identify 568 all the fields encountered in the headers to be compressed, and to 569 label them with a Field ID. Rules only describe the compression/ 570 decompression behavior for each header field, after it has been 571 identified. 573 In a Rule, the Field Descriptions are listed in the order in which 574 the fields appear in the packet header. The Field Descriptions 575 describe the header fields with the following entries: 577 o Field ID (FID) designates a protocol and field (e.g. UDP 578 Destination Port), unambiguously among all protocols that a SCHC 579 compressor processes. In the presence of protocol nesting, the 580 Field ID also identifies the nesting. 582 o Field Length (FL) represents the length of the field. It can be 583 either a fixed value (in bits) if the length is known when the 584 Rule is created or a type if the length is variable. The length 585 of a header field is defined by its own protocol specification 586 (e.g. IPv6 or UDP). If the length is variable, the type defines 587 the process to compute the length and its unit (bits, bytes...). 589 o Field Position (FP): most often, a field only occurs once in a 590 packet header. Some fields may occur multiple times in a header. 592 FP indicates which occurrence this Field Description applies to. 593 The default value is 1 (first occurrence). 595 o A Direction Indicator (DI) indicates the packet direction(s) this 596 Field Description applies to. Three values are possible: 598 * UPLINK (Up): this Field Description is only applicable to 599 packets sent by the Dev to the App, 601 * DOWNLINK (Dw): this Field Description is only applicable to 602 packets sent from the App to the Dev, 604 * BIDIRECTIONAL (Bi): this Field Description is applicable to 605 packets traveling both Up and Dw. 607 o Target Value (TV) is the value used to match against the packet 608 header field. The Target Value can be a scalar value of any type 609 (integer, strings, etc.) or a more complex structure (array, list, 610 etc.). The types and representations are out of scope for this 611 document. 613 o Matching Operator (MO) is the operator used to match the Field 614 Value and the Target Value. The Matching Operator may require 615 some parameters. MO is only used during the compression phase. 616 The set of MOs defined in this document can be found in 617 Section 7.4. 619 o Compression Decompression Action (CDA) describes the compression 620 and decompression processes to be performed after the MO is 621 applied. Some CDAs might use parameter values for their 622 operation. CDAs are used in both the compression and the 623 decompression functions. The set of CDAs defined in this document 624 can be found in Section 7.5. 626 7.2. Rule ID for SCHC C/D 628 Rule IDs are sent by the compression function in one side and are 629 received for the decompression function in the other side. In SCHC 630 C/D, the Rule IDs are specific to the Context related to one Dev. 631 Hence, multiple Dev instances, which refer to different header 632 compression Contexts, MAY reuse the same Rule ID for different Rules. 633 On the network side, in order to identify the correct Rule to be 634 applied, the SCHC Decompressor needs to associate the Rule ID with 635 the Dev identifier. Similarly, the SCHC Compressor on the network 636 side first identifies the destination Dev before looking for the 637 appropriate compression Rule (and associated Rule ID) in the Context 638 of that Dev. 640 7.3. Packet processing 642 The compression/decompression process follows several steps: 644 o Compression Rule selection: the set of Rules is browsed to 645 identify which Rule will be used to compress the packet header. 646 The Rule is selected by matching the Fields Descriptions to the 647 packet header. The detailed steps are the following: 649 * The first step is to check the Field Identifiers (FID). If any 650 header field of the packet being examined cannot be matched 651 with a Field Description with the correct FID, the Rule MUST be 652 disregarded. If any Field Description in the Rule has a FID 653 that cannot be matched to one of the header fields of the 654 packet being examined, the Rule MUST be disregarded. 656 * The next step is to match the Field Descriptions by their 657 direction, using the Direction Indicator (DI). If any field of 658 the packet header cannot be matched with a Field Description 659 with the correct FID and DI, the Rule MUST be disregarded. 661 * Then the Field Descriptions are further selected according to 662 Field Position (FP). If any field of the packet header cannot 663 be matched with a Field Description with the correct FID, DI 664 and FP, the Rule MUST be disregarded. 666 * Once each header field has been associated with a Field 667 Description with matching FID, DI and FP, each packet field's 668 value is then compared to the corresponding Target Value (TV) 669 stored in the Rule for that specific field, using the matching 670 operator (MO). If every field in the packet header satisfies 671 the corresponding matching operators (MO) of a Rule (i.e. all 672 MO results are True), that Rule is used for compressing the 673 header. Otherwise, the Rule MUST be disregarded. 675 * If no eligible compression Rule is found, then the header MUST 676 be sent in its entirety using the Rule ID of the "default" Rule 677 dedicated to this purpose. Sending an uncompressed header may 678 require SCHC F/R. 680 o Compression: each field of the header is compressed according to 681 the Compression/Decompression Actions (CDAs). The fields are 682 compressed in the order that the Field Descriptions appear in the 683 Rule. The compression of each field results in a residue, which 684 may be empty. The Compression Residue for the packet header is 685 the concatenation of the non-empty residues for each field of the 686 header, in the order the Field Descriptions appear in the Rule. 688 |------------------- Compression Residue -------------------| 689 +-----------------+-----------------+-----+-----------------+ 690 | field 1 residue | field 2 residue | ... | field N residue | 691 +-----------------+-----------------+-----+-----------------+ 693 Figure 7: Compression Residue structure 695 o Sending: The Rule ID is sent to the other end followed by the 696 Compression Residue (which could be empty) or the uncompressed 697 header, and directly followed by the payload (see Figure 4). The 698 way the Rule ID is sent will be specified in the Profile and is 699 out of the scope of the present document. For example, it could 700 be included in an L2 header or sent as part of the L2 payload. 702 o Decompression: when decompressing, on the network side the SCHC C/ 703 D needs to find the correct Rule based on the L2 address; in this 704 way, it can use the DevIID and the Rule ID. On the Dev side, only 705 the Rule ID is needed to identify the correct Rule since the Dev 706 typically only holds Rules that apply to itself. 708 The receiver identifies the sender through its device-id or source 709 identifier (e.g. MAC address, if it exists) and selects the Rule 710 using the Rule ID. This Rule describes the compressed header 711 format and associates the received residues to each of the header 712 fields. For each field in the header, the receiver applies the 713 CDA action associated to that field in order to reconstruct the 714 original header field value. The CDA application order can be 715 different from the order in which the fields are listed in the 716 Rule. In particular, Compute-* MUST be applied after the 717 application of the CDAs of all the fields it computes on. 719 7.4. Matching operators 721 Matching Operators (MOs) are functions used by both SCHC C/D 722 endpoints. They are not typed and can be applied to integer, string 723 or any other data type. The result of the operation can either be 724 True or False. MOs are defined as follows: 726 o equal: The match result is True if the field value in the packet 727 matches the TV. 729 o ignore: No matching is attempted between the field value in the 730 packet and the TV in the Rule. The result is always true. 732 o MSB(x): A match is obtained if the most significant x bits of the 733 packet header field value are equal to the TV in the Rule. The x 734 parameter of the MSB MO indicates how many bits are involved in 735 the comparison. If the FL is described as variable, the length 736 must be a multiple of the unit. For example, x must be multiple 737 of 8 if the unit of the variable length is in bytes. 739 o match-mapping: With match-mapping, the Target Value is a list of 740 values. Each value of the list is identified by an index. 741 Compression is achieved by sending the index instead of the 742 original header field value. This operator matches if the header 743 field value is equal to one of the values in the target list. 745 7.5. Compression Decompression Actions (CDA) 747 The Compression Decompression Action (CDA) describes the actions 748 taken during the compression of header fields and the inverse action 749 taken by the decompressor to restore the original value. 751 +--------------+-------------+-------------------------------+ 752 | Action | Compression | Decompression | 753 +--------------+-------------+-------------------------------+ 754 | | | | 755 | not-sent | elided | use TV stored in Rule | 756 | value-sent | send | use received value | 757 | mapping-sent | send index | retrieve value from TV list | 758 | LSB | send LSB | concat. TV and received value | 759 | compute-* | elided | recompute at decompressor | 760 | DevIID | elided | build IID from L2 Dev addr | 761 | AppIID | elided | build IID from L2 App addr | 762 +--------------+-------------+-------------------------------+ 764 Table 1: Compression and Decompression Actions 766 Table 1 summarizes the basic actions that can be used to compress and 767 decompress a field. The first column shows the action's name. The 768 second and third columns show the compression and decompression 769 behaviors for each action. 771 7.5.1. processing fixed-length fields 773 If the field is identified in the Field Description as being of fixed 774 length, then aplying the CDA to compress this field results in a 775 fixed amount of bits. The residue for that field is simply the bits 776 resulting from applying the CDA to the field. This value may be 777 empty (e.g. not-sent CDA), in which case the field residue is absent 778 from the Compression Residue. 780 |- field residue -| 781 +-----------------+ 782 | value | 783 +-----------------+ 785 Figure 8: fixed sized field residue structure 787 7.5.2. processing variable-length fields 789 If the field is identified in the Field Description as being of 790 variable length, then aplying the CDA to compress this field may 791 result in a value of fixed size (e.g. not-sent or mapping-sent) or of 792 variable size (e.g. value-sent or LSB). In the latter case, the 793 residue for that field is the bits that result from applying the CDA 794 to the field, preceded with the size of the value. The most 795 significant bit of the size is stored first (left of the residue bit 796 field). 798 |--- field residue ---| 799 +-------+-------------+ 800 | size | value | 801 +-------+-------------+ 803 Figure 9: variable sized field residue structure 805 The size (using the unit defined in the FL) is encoded on 4, 12 or 28 806 bits as follows: 808 o If the size is between 0 and 14, it is encoded as a 4 bits 809 unsigned integer. 811 o Sizes between 15 and 254 are encoded as 0b1111 followed by the 8 812 bits unsigned integer. 814 o Larger sizes are encoded as 0xfff followed by the 16 bits unsigned 815 integer. 817 If the field is identified in the Field Description as being of 818 variable length and this field is not present in the packet header 819 being compressed, size 0 MUST be sent to denote its absence. 821 7.5.3. not-sent CDA 823 The not-sent action can be used when the field value is specified in 824 a Rule and therefore known by both the Compressor and the 825 Decompressor. This action SHOULD be used with the "equal" MO. If MO 826 is "ignore", there is a risk to have a decompressed field value 827 different from the original field that was compressed. 829 The compressor does not send any residue for a field on which not- 830 sent compression is applied. 832 The decompressor restores the field value with the Target Value 833 stored in the matched Rule identified by the received Rule ID. 835 7.5.4. value-sent CDA 837 The value-sent action can be used when the field value is not known 838 by both the Compressor and the Decompressor. The value is sent in 839 its entirety. 841 If this action is performed on a variable length field, the size of 842 the residue value (using the units defined in FL) MUST be sent as 843 described in Section 7.5.2. 845 This action is generally used with the "ignore" MO. 847 7.5.5. mapping-sent CDA 849 The mapping-sent action is used to send an index (the index into the 850 Target Value list of values) instead of the original value. This 851 action is used together with the "match-mapping" MO. 853 On the compressor side, the match-mapping Matching Operator searches 854 the TV for a match with the header field value. The mapping-sent CDA 855 then sends the corresponding index as the field residue. The most 856 significant bit of the index is stored first (left of the residue bit 857 field). 859 On the decompressor side, the CDA uses the received index to restore 860 the field value by looking up the list in the TV. 862 The number of bits sent is the minimal size for coding all the 863 possible indices. 865 7.5.6. LSB CDA 867 The LSB action is used together with the "MSB(x)" MO to avoid sending 868 the most significant part of the packet field if that part is already 869 known by the receiving end. 871 The compressor sends the Least Significant Bits as the field residue 872 value. The number of bits sent is the original header field length 873 minus the length specified in the MSB(x) MO. 875 The decompressor concatenates the x most significant bits of Target 876 Value and the received residue value. 878 If this action is performed on a variable length field, the size of 879 the residue value (using the units defined in FL) MUST be sent as 880 described in Section 7.5.2. 882 7.5.7. DevIID, AppIID CDA 884 These actions are used to process respectively the Dev and the App 885 Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. 886 AppIID CDA is less common since most current LPWAN technologies 887 frames contain a single L2 address, which is the Dev's address. 889 The IID value MAY be computed from the Device ID present in the L2 890 header, or from some other stable identifier. The computation is 891 specific to each Profile and MAY depend on the Device ID size. 893 In the downlink direction (Dw), at the compressor, the DevIID CDA may 894 be used to generate the L2 addresses on the LPWAN, based on the 895 packet's Destination Address. 897 7.5.8. Compute-* 899 Some fields can be elided at the compressor and recomputed locally at 900 the decompressor. 902 Because the field is uniquely identified by its Field ID (e.g. UDP 903 length), the relevant protocol specification unambiguously defines 904 the algorithm for such computation. 906 Examples of fields that know how to recompute themselves are UDP 907 length, IPv6 length and UDP checksum. 909 8. Fragmentation/Reassembly 911 8.1. Overview 913 In LPWAN technologies, the L2 MTU typically ranges from tens to 914 hundreds of bytes. Some of these technologies do not have an 915 internal fragmentation/reassembly mechanism. 917 The optional SCHC Fragmentation/Reassembly (SCHC F/R) functionality 918 enables such LPWAN technologies to comply with the IPv6 MTU 919 requirement of 1280 bytes [RFC8200]. It is optional to implement. 920 If it is not needed, its description can be safely ignored. 922 This specification includes several SCHC F/R modes, which allow for a 923 range of reliability options such as optional SCHC Fragment 924 retransmission. More modes may be defined in the future. 926 The same SCHC F/R mode MUST be used for all SCHC Fragments of a SCHC 927 Packet. This document does not specify which mode(s) are to be used 928 over a specific LPWAN technology. That information will be given in 929 Profiles. 931 The L2 Word size (see Section 4) determines the encoding of some 932 messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs 933 that are multiples of L2 Words. 935 8.2. SCHC F/R Protocol Elements 937 This subsection describes the different elements that are used to 938 enable the SCHC F/R functionality defined in this document. These 939 elements include the SCHC F/R messages, tiles, windows, bitmaps, 940 counters, timers and header fields. 942 The elements are described here in a generic manner. Their 943 application to each SCHC F/R mode is found in Section 8.4. 945 8.2.1. Messages 947 SCHC F/R defines the following messages: 949 o SCHC Fragment: A message that carries part of a SCHC Packet from 950 the sender to the receiver. 952 o SCHC ACK: An acknowledgement for fragmentation, by the receiver to 953 the sender. This message is used to indicate whether or not the 954 reception of pieces of, or the whole of the fragmented SCHC 955 Packet, was successful. 957 o SCHC ACK REQ: A request by the sender for a SCHC ACK from the 958 receiver. 960 o SCHC Sender-Abort: A message by the sender telling the receiver 961 that it has aborted the transmission of a fragmented SCHC Packet. 963 o SCHC Receiver-Abort: A message by the receiver to tell the sender 964 to abort the transmission of a fragmented SCHC Packet. 966 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 968 8.2.2.1. Tiles 970 The SCHC Packet is fragmented into pieces, hereafter called tiles. 971 The tiles MUST be non-empty and pairwise disjoint. Their union MUST 972 be equal to the SCHC Packet. 974 See Figure 10 for an example. 976 SCHC Packet 977 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 978 Tiles | | | | | | | | | | | | | | 979 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 981 Figure 10: a SCHC Packet fragmented in tiles 983 Each SCHC Fragment message carries at least one tile in its Payload, 984 if the Payload field is present. 986 8.2.2.2. Windows 988 Some SCHC F/R modes may handle successive tiles in groups, called 989 windows. 991 If windows are used 993 o all the windows of a SCHC Packet, except the last one, MUST 994 contain the same number of tiles. This number is WINDOW_SIZE. 996 o WINDOW_SIZE MUST be specified in a Profile. 998 o the windows are numbered. 1000 o their numbers MUST increase from 0 upward, from the start of the 1001 SCHC Packet to its end. 1003 o the last window MUST contain WINDOW_SIZE tiles or less. 1005 o tiles are numbered within each window. 1007 o the tile indices MUST decrement from WINDOW_SIZE - 1 downward, 1008 looking from the start of the SCHC Packet toward its end. 1010 o each tile of a SCHC Packet is therefore uniquely identified by a 1011 window number and a tile index within this window. 1013 See Figure 11 for an example. 1015 +---------------------------------------------...-------------+ 1016 | SCHC Packet | 1017 +---------------------------------------------...-------------+ 1019 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 | 1020 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -| 1022 Figure 11: a SCHC Packet fragmented in tiles grouped in 28 windows, 1023 with WINDOW_SIZE = 5 1025 When windows are used 1027 o Bitmaps (see Section 8.2.2.3) MAY be sent back by the receiver to 1028 the sender in a SCHC ACK message. 1030 o A Bitmap corresponds to exactly one Window. 1032 8.2.2.3. Bitmaps 1034 Each bit in the Bitmap for a window corresponds to a tile in the 1035 window. Each Bitmap has therefore WINDOW_SIZE bits. The bit at the 1036 left-most position corresponds to the tile numbered WINDOW_SIZE - 1. 1037 Consecutive bits, going right, correspond to sequentially decreasing 1038 tile indices. In Bitmaps for windows that are not the last one of a 1039 SCHC Packet, the bit at the right-most position corresponds to the 1040 tile numbered 0. In the Bitmap for the last window, the bit at the 1041 right-most position corresponds either to the tile numbered 0 or to a 1042 tile that is sent/received as "the last one of the SCHC Packet" 1043 without explicitly stating its number (see Section 8.3.1.2). 1045 At the receiver 1047 o a bit set to 1 in the Bitmap indicates that a tile associated with 1048 that bit position has been correctly received for that window. 1050 o a bit set to 0 in the Bitmap indicates that no tile associated 1051 with that bit position has been correctly received for that 1052 window. 1054 8.2.2.4. Timers and counters 1056 Some SCHC F/R modes can use the following timers and counters 1058 o Inactivity Timer: a SCHC Fragment receiver uses this timer to 1059 abort waiting for a SCHC F/R message. 1061 o Retransmission Timer: a SCHC Fragment sender uses this timer to 1062 abort waiting for an expected SCHC ACK. 1064 o Attempts: this counter counts the requests for SCHC ACKs, up to 1065 MAX_ACK_REQUESTS. 1067 8.2.3. Integrity Checking 1069 The integrity of the fragmentation-reassembly process of a SCHC 1070 Packet MUST be checked at the receive end. By default, integrity 1071 checking is performed by computing a Reassembly Check Sequence (RCS) 1072 of the SCHC Packet at the sender side before fragmentation and 1073 transmitting it to the receiver for comparison with the RCS locally 1074 computed after reassembly. 1076 The RCS supports UDP checksum elision by SCHC C/D (see 1077 Section 10.11). 1079 The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of 1080 the polynomial used e.g. in the Ethernet standard [RFC3385]) is 1081 RECOMMENDED as the default algorithm for computing the RCS. 1082 Nevertheless, other RCS lengths or other algorithms MAY be required 1083 by the Profile. 1085 The RCS MUST be computed on the full SCHC Packet concatenated with 1086 the padding bits, if any, of the SCHC Fragment carrying the last 1087 tile. The rationale is that the SCHC reassembler has no way of 1088 knowing the boundary between the last tile and the padding bits. 1089 Indeed, this requires decompressing the SCHC Packet, which is out of 1090 the scope of the SCHC reassembler. 1092 Note that the concatenation of the complete SCHC Packet and the 1093 potential padding bits of the last SCHC Fragment does not generally 1094 constitute an integer number of bytes. For implementers to be able 1095 to use byte-oriented CRC libraries, it is RECOMMENDED that the 1096 concatenation of the complete SCHC Packet and the last fragment 1097 potential padding bits be zero-extended to the next byte boundary and 1098 that the RCS be computed on that byte array. A Profile MAY specify 1099 another behavior. 1101 8.2.4. Header Fields 1103 The SCHC F/R messages contain the following fields (see the formats 1104 in Section 8.3): 1106 o Rule ID: this field is present in all the SCHC F/R messages. It 1107 is used to identify 1108 * that a SCHC F/R message is being carried, as opposed to an 1109 unfragmented SCHC Packet, 1111 * which SCHC F/R mode is used 1113 * and for this mode 1115 + if windows are used and what the value of WINDOW_SIZE is, 1117 + what other optional fields are present and what the field 1118 sizes are. 1120 The Rule ID allows SCHC F/R interleaving non-fragmented SCHC 1121 Packets and SCHC Fragments that carry other SCHC Packets, or 1122 interleaving SCHC Fragments that use different SCHC F/R modes or 1123 different parameters. 1125 o Datagram Tag (DTag). Its size (called T, in bits) is defined by 1126 each Profile for each Rule ID. When T is 0, the DTag field does 1127 not appear in the SCHC F/R messages and the DTag value is defined 1128 as 0. 1130 When T is 0, there can be only one fragmented SCHC Packet in 1131 transit for a given Rule ID. 1133 If T is not 0, DTag 1135 * MUST be set to the same value for all the SCHC F/R messages 1136 related to the same fragmented SCHC Packet, 1138 * MUST be set to different values for SCHC F/R messages related 1139 to different SCHC Packets that are being fragmented under the 1140 same Rule ID and the transmission of which may overlap. 1142 A sequence counter that is incremented for each new fragmented 1143 SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to 1144 0 is RECOMMENDED for maximum traceability and avoidance of 1145 ambiguity. 1147 A flow of SCHC F/R messages with a given Rule ID and DTag value 1148 pair MUST NOT interfere with the operation of a SCHC F/R instance 1149 that uses another Rule ID and DTag value pair. 1151 o W: The W field is optional. It is only present if windows are 1152 used. Its presence and size (called M, in bits) is defined by 1153 each SCHC F/R mode and each Profile for each Rule ID. 1155 This field carries information pertaining to the window a SCHC F/R 1156 message relates to. If present, W MUST carry the same value for 1157 all the SCHC F/R messages related to the same window. Depending 1158 on the mode and Profile, W may carry the full window number, or 1159 just the least significant bit or any other partial representation 1160 of the window number. 1162 o Fragment Compressed Number (FCN). The FCN field is present in the 1163 SCHC Fragment Header. Its size (called N, in bits) is defined by 1164 each Profile for each Rule ID. 1166 This field conveys information about the progress in the sequence 1167 of tiles being transmitted by SCHC Fragment messages. For 1168 example, it can contain a partial, efficient representation of a 1169 larger-sized tile index. The description of the exact use of the 1170 FCN field is left to each SCHC F/R mode. However, two values are 1171 reserved for special purposes. They help control the SCHC F/R 1172 process: 1174 * The FCN value with all the bits equal to 1 (called All-1) 1175 signals the very last tile of a SCHC Packet. By extension, if 1176 windows are used, the last window of a packet is called the 1177 All-1 window. 1179 * If windows are used, the FCN value with all the bits equal to 0 1180 (called All-0) signals the last tile of a window that is not 1181 the last one of the SCHC packet. By extension, such a window 1182 is called an All-0 window. 1184 o Reassembly Check Sequence (RCS). This field only appears in the 1185 All-1 SCHC Fragments. Its size (called U, in bits) is defined by 1186 each Profile for each Rule ID. 1188 See Section 8.2.3 for the RCS default size, default polynomial and 1189 details on RCS computation. 1191 o C (integrity Check): C is a 1-bit field. This field is used in 1192 the SCHC ACK message to report on the reassembled SCHC Packet 1193 integrity check (see Section 8.2.3). 1195 A value of 1 tells that the integrity check was performed and is 1196 successful. A value of 0 tells that the integrity check was not 1197 performed, or that is was a failure. 1199 o Compressed Bitmap. The Compressed Bitmap is used together with 1200 windows and Bitmaps (see Section 8.2.2.3). Its presence and size 1201 is defined for each F/R mode for each Rule ID. 1203 This field appears in the SCHC ACK message to report on the 1204 receiver Bitmap (see Section 8.3.2.1). 1206 8.3. SCHC F/R Message Formats 1208 This section defines the SCHC Fragment formats, the SCHC ACK format, 1209 the SCHC ACK REQ format and the SCHC Abort formats. 1211 8.3.1. SCHC Fragment format 1213 A SCHC Fragment conforms to the general format shown in Figure 12. 1214 It comprises a SCHC Fragment Header and a SCHC Fragment Payload. The 1215 SCHC Fragment Payload carries one or several tile(s). 1217 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1218 | Fragment Header | Fragment Payload | padding (as needed) 1219 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1221 Figure 12: SCHC Fragment general format 1223 8.3.1.1. Regular SCHC Fragment 1225 The Regular SCHC Fragment format is shown in Figure 13. Regular SCHC 1226 Fragments are generally used to carry tiles that are not the last one 1227 of a SCHC Packet. The DTag field and the W field are optional. 1229 |--- SCHC Fragment Header ----| 1230 |-- T --|-M-|-- N --| 1231 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1232 | Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed) 1233 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1235 Figure 13: Detailed Header Format for Regular SCHC Fragments 1237 The FCN field MUST NOT contain all bits set to 1. 1239 The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called 1240 an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC 1241 ACK REQ message (see Section 8.3.3) that has the same T, M and N 1242 values, even in the presence of padding. This condition is met if 1243 the Payload is at least the size of an L2 Word. This condition is 1244 also met if the SCHC Fragment Header is a multiple of L2 Words. 1246 8.3.1.2. All-1 SCHC Fragment 1248 The All-1 SCHC Fragment format is shown in Figure 14. The sender 1249 generally uses the All-1 SCHC Fragment format for the message that 1250 completes the emission of a fragmented SCHC Packet. The DTag field, 1251 the W field, the RCS field and the Payload are optional. At least 1252 one of RCS field or Payload MUST be present. The FCN field is all 1253 ones. 1255 |-------- SCHC Fragment Header -------| 1256 |-- T --|-M-|-- N --|-- U --| 1257 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1258 | Rule ID | DTag | W | 11..1 | RCS | Frag Payload | pad. (as needed) 1259 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1260 (FCN) 1262 Figure 14: Detailed Header Format for the All-1 SCHC Fragment 1264 The All-1 SCHC Fragment message MUST be distinguishable by size from 1265 a SCHC Sender-Abort message (see Section 8.3.4) that has the same T, 1266 M and N values, even in the presence of padding. This condition is 1267 met if the RCS is present and is at least the size of an L2 Word, or 1268 if the Payload is present and at least the size an L2 Word. This 1269 condition is also met if the SCHC Sender-Abort Header is a multiple 1270 of L2 Words. 1272 8.3.2. SCHC ACK format 1274 The SCHC ACK message is shown in Figure 15. The DTag field, the W 1275 field and the Compressed Bitmap field are optional. The Compressed 1276 Bitmap field can only be present in SCHC F/R modes that use windows. 1278 |---- SCHC ACK Header ----| 1279 |-- T --|-M-| 1 | 1280 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1281 | Rule ID | DTag | W |C=1| padding as needed (success) 1282 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1284 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1285 | Rule ID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 1286 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1288 Figure 15: Format of the SCHC ACK message 1290 The SCHC ACK Header contains a C bit (see Section 8.2.4). 1292 If the C bit is set to 1 (integrity check successful), no Bitmap is 1293 carried. 1295 If the C bit is set to 0 (integrity check not performed or failed) 1296 and if windows are used, a Compressed Bitmap for the window referred 1297 to by the W field is transmitted as specified in Section 8.3.2.1. 1299 8.3.2.1. Bitmap Compression 1301 For transmission, the Compressed Bitmap in the SCHC ACK message is 1302 defined by the following algorithm (see Figure 16 for a follow-along 1303 example): 1305 o Build a temporary SCHC ACK message that contains the Header 1306 followed by the original Bitmap (see Section 8.2.2.3 for a 1307 description of Bitmaps). 1309 o Position scissors at the end of the Bitmap, after its last bit. 1311 o While the bit on the left of the scissors is 1 and belongs to the 1312 Bitmap, keep moving left, then stop. When this is done, 1314 o While the scissors are not on an L2 Word boundary of the SCHC ACK 1315 message and there is a Bitmap bit on the right of the scissors, 1316 keep moving right, then stop. 1318 o At this point, cut and drop off any bits to the right of the 1319 scissors 1321 When one or more bits have effectively been dropped off as a result 1322 of the above algorithm, the SCHC ACK message is a multiple of L2 1323 Words, no padding bits will be appended. 1325 Because the SCHC Fragment sender knows the size of the original 1326 Bitmap, it can reconstruct the original Bitmap from the Compressed 1327 Bitmap received in the SCH ACK message. 1329 Figure 16 shows an example where L2 Words are actually bytes and 1330 where the original Bitmap contains 17 bits, the last 15 of which are 1331 all set to 1. 1333 |---- SCHC ACK Header ----|-------- Bitmap --------| 1334 |-- T --|-M-| 1 | 1335 +--- ... -+- ... -+---+---+---------------------------------+ 1336 | Rule ID | DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| 1337 +--- ... -+- ... -+---+---+---------------------------------+ 1338 next L2 Word boundary ->| 1340 Figure 16: SCHC ACK Header plus uncompressed Bitmap 1342 Figure 17 shows that the last 14 bits are not sent. 1344 |---- SCHC ACK Header ----|CpBmp| 1345 |-- T --|-M-| 1 | 1346 +--- ... -+- ... -+---+---+-----+ 1347 | Rule ID | DTag | W |C=0|1 0 1| 1348 +--- ... -+- ... -+---+---+-----+ 1349 next L2 Word boundary ->| 1351 Figure 17: Resulting SCHC ACK message with Compressed Bitmap 1353 Figure 18 shows an example of a SCHC ACK with tile indices ranging 1354 from 6 down to 0, where the Bitmap indicates that the second and the 1355 fourth tile of the window have not been correctly received. 1357 |---- SCHC ACK Header ----|--- Bitmap --| 1358 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1359 +---------+-------+---+---+-------------+ 1360 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1| uncompressed Bitmap 1361 +---------+-------+---+---+-------------+ 1362 next L2 Word boundary ->|<-- L2 Word -->| 1364 +---------+-------+---+---+-------------+~~~+ 1365 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK 1366 +---------+-------+---+---+-------------+~~~+ 1367 next L2 Word boundary ->|<-- L2 Word -->| 1369 Figure 18: Example of a SCHC ACK message, missing tiles 1371 Figure 19 shows an example of a SCHC ACK with FCN ranging from 6 down 1372 to 0, where integrity check has not been performed or has failed and 1373 the Bitmap indicates that there is no missing tile in that window. 1375 |---- SCHC ACK Header ----|--- Bitmap --| 1376 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1377 +---------+-------+---+---+-------------+ 1378 | Rule ID | DTag | W |C=0|1 1 1 1 1 1 1| with uncompressed Bitmap 1379 +---------+-------+---+---+-------------+ 1380 next L2 Word boundary ->| 1382 +--- ... -+- ... -+---+---+-+ 1383 | Rule ID | DTag | W |C=0|1| transmitted SCHC ACK 1384 +--- ... -+- ... -+---+---+-+ 1385 next L2 Word boundary ->| 1387 Figure 19: Example of a SCHC ACK message, no missing tile 1389 8.3.3. SCHC ACK REQ format 1391 The SCHC ACK REQ is used by a sender to request a SCHC ACK from the 1392 receiver. Its format is shown in Figure 20. The DTag field and the 1393 W field are optional. The FCN field is all zero. 1395 |---- SCHC ACK REQ Header ----| 1396 |-- T --|-M-|-- N --| 1397 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1398 | Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) 1399 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1401 Figure 20: SCHC ACK REQ format 1403 8.3.4. SCHC Sender-Abort format 1405 When a SCHC Fragment sender needs to abort an on-going fragmented 1406 SCHC Packet transmission, it sends a SCHC Sender-Abort message to the 1407 SCHC Fragment receiver. 1409 The SCHC Sender-Abort format is shown in Figure 21. The DTag field 1410 and the W field are optional. The FCN field is all ones. 1412 |---- Sender-Abort Header ----| 1413 |-- T --|-M-|-- N --| 1414 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1415 | Rule ID | DTag | W | 11..1 | padding (as needed) 1416 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1418 Figure 21: SCHC Sender-Abort format 1420 If the W field is present, 1422 o the fragment sender MUST set it to all ones. Other values are 1423 RESERVED. 1425 o the fragment receiver MUST check its value. If the value is 1426 different from all ones, the message MUST be ignored. 1428 The SCHC Sender-Abort MUST NOT be acknowledged. 1430 8.3.5. SCHC Receiver-Abort format 1432 When a SCHC Fragment receiver needs to abort an on-going fragmented 1433 SCHC Packet transmission, it transmits a SCHC Receiver-Abort message 1434 to the SCHC Fragment sender. 1436 The SCHC Receiver-Abort format is shown in Figure 22. The DTag field 1437 and the W field are optional. 1439 |--- Receiver-Abort Header ---| 1440 |--- T ---|-M-| 1 | 1441 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Rule ID | DTag | W |C=1| 1..1| 1..1 | 1443 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1444 next L2 Word boundary ->|<-- L2 Word -->| 1446 Figure 22: SCHC Receiver-Abort format 1448 If the W field is present, 1450 o the fragment receiver MUST set it to all ones. Other values are 1451 RESERVED. 1453 o if the value is different from all ones, the fragment sender MUST 1454 ignore the message. 1456 The SCHC Receiver-Abort has the same header as a SCHC ACK message. 1457 The bits that follow the SCHC Receiver-Abort Header MUST be as 1458 follows 1460 o if the Header does not end at an L2 Word boundary, append bits set 1461 to 1 as needed to reach the next L2 Word boundary 1463 o append exactly one more L2 Word with bits all set to ones 1465 Such a bit pattern never occurs in a regular SCHC ACK. This is how 1466 the fragment sender recognizes a SCHC Receiver-Abort. 1468 The SCHC Receiver-Abort MUST NOT be acknowledged. 1470 8.4. SCHC F/R modes 1472 This specification includes several SCHC F/R modes, which 1474 o allow for a range of reliability options, such as optional SCHC 1475 Fragment retransmission 1477 o support various LPWAN characteristics, including variable MTU. 1479 More modes may be defined in the future. 1481 8.4.1. No-ACK mode 1483 The No-ACK mode has been designed under the assumption that data unit 1484 out-of-sequence delivery does not occur between the entity performing 1485 fragmentation and the entity performing reassembly. This mode 1486 supports LPWAN technologies that have a variable MTU. 1488 In No-ACK mode, there is no communication from the fragment receiver 1489 to the fragment sender. The sender transmits all the SCHC Fragments 1490 without expecting acknowledgement. 1492 In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. 1493 The other SCHC Fragments are intrinsically aligned to L2 Words. 1495 The tile sizes are not required to be uniform. Windows are not used. 1496 The Retransmission Timer is not used. The Attempts counter is not 1497 used. 1499 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1500 F/R messages operating in this mode. 1502 The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK 1503 MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort 1504 MAY be sent. SCHC Receiver-Abort MUST NOT be sent. 1506 The value of N (size of the FCN field) is RECOMMENDED to be 1. 1508 Each Profile, for each Rule ID value, MUST define 1510 o the size of the DTag field, 1512 o the size and algorithm for the RCS field, 1514 o the expiration time of the Inactivity Timer 1516 Each Profile, for each Rule ID value, MAY define 1518 o a value of N different from the recommended one, 1520 o the meaning of values sent in the FCN field, for values different 1521 from the All-1 value. 1523 For each active pair of Rule ID and DTag values, the receiver MUST 1524 maintain an Inactivity Timer. 1526 8.4.1.1. Sender behavior 1528 At the beginning of the fragmentation of a new SCHC Packet, the 1529 fragment sender MUST select a Rule ID and DTag value pair for this 1530 SCHC Packet. 1532 Each SCHC Fragment MUST contain exactly one tile in its Payload. The 1533 tile MUST be at least the size of an L2 Word. The sender MUST 1534 transmit the SCHC Fragments messages in the order that the tiles 1535 appear in the SCHC Packet. Except for the last tile of a SCHC 1536 Packet, each tile MUST be of a size that complements the SCHC 1537 Fragment Header so that the SCHC Fragment is a multiple of L2 Words 1538 without the need for padding bits. Except for the last one, the SCHC 1539 Fragments MUST use the Regular SCHC Fragment format specified in 1540 Section 8.3.1.1. The last SCHC Fragment MUST use the All-1 format 1541 specified in Section 8.3.1.2. 1543 The sender MAY transmit a SCHC Sender-Abort. 1545 Figure 37 shows an example of a corresponding state machine. 1547 8.4.1.2. Receiver behavior 1549 Upon receiving each Regular SCHC Fragment, 1551 o the receiver MUST reset the Inactivity Timer, 1553 o the receiver assembles the payloads of the SCHC Fragments 1555 On receiving an All-1 SCHC Fragment, 1557 o the receiver MUST append the All-1 SCHC Fragment Payload and the 1558 padding bits to the previously received SCHC Fragment Payloads for 1559 this SCHC Packet 1561 o the receiver MUST perform the integrity check 1563 o if integrity checking fails, the receiver MUST drop the 1564 reassembled SCHC Packet 1566 o the reassembly operation concludes. 1568 On expiration of the Inactivity Timer, the receiver MUST drop the 1569 SCHC Packet being reassembled. 1571 On receiving a SCHC Sender-Abort, the receiver MAY drop the SCHC 1572 Packet being reassembled. 1574 Figure 38 shows an example of a corresponding state machine. 1576 8.4.2. ACK-Always mode 1578 The ACK-Always mode has been designed under the following assumptions 1580 o Data unit out-of-sequence delivery does not occur between the 1581 entity performing fragmentation and the entity performing 1582 reassembly 1584 o The L2 MTU value does not change while the fragments of a SCHC 1585 Packet are being transmitted. 1587 In ACK-Always mode, windows are used. An acknowledgement, positive 1588 or negative, is transmitted by the fragment receiver to the fragment 1589 sender at the end of the transmission of each window of SCHC 1590 Fragments. 1592 The tiles are not required to be of uniform size. In ACK-Always 1593 mode, only the All-1 SCHC Fragment is padded as needed. The other 1594 SCHC Fragments are intrinsically aligned to L2 Words. 1596 Briefly, the algorithm is as follows: after a first blind 1597 transmission of all the tiles of a window, the fragment sender 1598 iterates retransmitting the tiles that are reported missing until the 1599 fragment receiver reports that all the tiles belonging to the window 1600 have been correctly received, or until too many attempts were made. 1601 The fragment sender only advances to the next window of tiles when it 1602 has ascertained that all the tiles belonging to the current window 1603 have been fully and correctly received. This results in a per-window 1604 lock-step behavior between the sender and the receiver. 1606 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1607 F/R messages operating in this mode. 1609 The W field MUST be present and its size M MUST be 1 bit. 1611 Each Profile, for each Rule ID value, MUST define 1613 o the value of N (size of the FCN field), 1615 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 1617 o the size and algorithm for the RCS field, 1619 o the size of the DTag field, 1621 o the value of MAX_ACK_REQUESTS, 1622 o the expiration time of the Retransmission Timer 1624 o the expiration time of the Inactivity Timer 1626 For each active pair of Rule ID and DTag values, the sender MUST 1627 maintain 1629 o one Attempts counter 1631 o one Retransmission Timer 1633 For each active pair of Rule ID and DTag values, the receiver MUST 1634 maintain an Inactivity Timer. 1636 8.4.2.1. Sender behavior 1638 At the beginning of the fragmentation of a new SCHC Packet, the 1639 fragment sender MUST select a Rule ID and DTag value pair for this 1640 SCHC Packet. 1642 Each SCHC Fragment MUST contain exactly one tile in its Payload. All 1643 tiles with the index 0, as well as the last tile, MUST be at least 1644 the size of an L2 Word. 1646 In all SCHC Fragment messages, the W field MUST be filled with the 1647 least significant bit of the window number that the sender is 1648 currently processing. 1650 For a SCHC Fragment that carries a tile other than the last one of 1651 the SCHC Packet, 1653 o the Fragment MUST be of the Regular type specified in 1654 Section 8.3.1.1 1656 o the FCN field MUST contain the tile index 1658 o each tile MUST be of a size that complements the SCHC Fragment 1659 Header so that the SCHC Fragment is a multiple of L2 Words without 1660 the need for padding bits. 1662 The SCHC Fragment that carries the last tile MUST be an All-1 SCHC 1663 Fragment, described in Section 8.3.1.2. 1665 The fragment sender MUST start by transmitting the window numbered 0. 1667 The sender starts by a "blind transmission" phase, in which it MUST 1668 transmit all the tiles composing the window, in decreasing tile index 1669 order. 1671 Then, it enters a "retransmission phase" in which it MUST initialize 1672 an Attempts counter to 0, it MUST start a Retransmission Timer and it 1673 MUST await a SCHC ACK. Then, 1675 o upon receiving a SCHC ACK, 1677 * if the SCHC ACK indicates that some tiles are missing at the 1678 receiver, then the sender MUST transmit all the tiles that have 1679 been reported missing, it MUST increment Attempts, it MUST 1680 reset the Retransmission Timer and MUST await the next SCHC 1681 ACK. 1683 * if the current window is not the last one and the SCHC ACK 1684 indicates that all tiles were correctly received, the sender 1685 MUST stop the Retransmission Timer, it MUST advance to the next 1686 fragmentation window and it MUST start a blind transmission 1687 phase as described above. 1689 * if the current window is the last one and the SCHC ACK 1690 indicates that more tiles were received than the sender sent, 1691 the fragment sender MUST send a SCHC Sender-Abort, and it MAY 1692 exit with an error condition. 1694 * if the current window is the last one and the SCHC ACK 1695 indicates that all tiles were correctly received yet integrity 1696 check was a failure, the fragment sender MUST send a SCHC 1697 Sender-Abort, and it MAY exit with an error condition. 1699 * if the current window is the last one and the SCHC ACK 1700 indicates that integrity checking was successful, the sender 1701 exits successfully. 1703 o on Retransmission Timer expiration, 1705 * if Attempts is strictly less that MAX_ACK_REQUESTS, the 1706 fragment sender MUST send a SCHC ACK REQ and MUST increment the 1707 Attempts counter. 1709 * otherwise the fragment sender MUST send a SCHC Sender-Abort, 1710 and it MAY exit with an error condition. 1712 At any time, 1714 o on receiving a SCHC Receiver-Abort, the fragment sender MAY exit 1715 with an error condition. 1717 o on receiving a SCHC ACK that bears a W value different from the W 1718 value that it currently uses, the fragment sender MUST silently 1719 discard and ignore that SCHC ACK. 1721 Figure 39 shows an example of a corresponding state machine. 1723 8.4.2.2. Receiver behavior 1725 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 1726 processed at that time 1728 o the receiver SHOULD check if the DTag value has not recently been 1729 used for that Rule ID value, thereby ensuring that the received 1730 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 1731 transmission. If the SCHC Fragment is determined to be such a 1732 remnant, the receiver MAY silently ignore it and discard it. 1734 o the receiver MUST start a process to assemble a new SCHC Packet 1735 with that Rule ID and DTag value pair. 1737 o the receiver MUST start an Inactivity Timer. It MUST initialize 1738 an Attempts counter to 0. It MUST initialize a window counter to 1739 0. 1741 In the rest of this section, "local W bit" means the least 1742 significant bit of the window counter of the receiver. 1744 On reception of any SCHC F/R message, the receiver MUST reset the 1745 Inactivity Timer. 1747 Entering an "acceptance phase", the receiver MUST first initialize an 1748 empty Bitmap for this window, then 1750 o on receiving a SCHC Fragment or SCHC ACK REQ with the W bit 1751 different from the local W bit, the receiver MUST silently ignore 1752 and discard that message. 1754 o on receiving a SCHC Fragment with the W bit equal to the local W 1755 bit, the receiver MUST assemble the received tile based on the 1756 window counter and on the FCN field in the SCHC Fragment and it 1757 MUST update the Bitmap. 1759 * if the SCHC Fragment received is an All-0 SCHC Fragment, the 1760 current window is determined to be a not-last window, and the 1761 receiver MUST send a SCHC ACK for this window. Then, 1763 + If the Bitmap indicates that all the tiles of the current 1764 window have been correctly received, the receiver MUST 1765 increment its window counter and it enters the "acceptance 1766 phase" for that new window. 1768 + If the Bitmap indicates that at least one tile is missing in 1769 the current window, the receiver enters the "retransmission 1770 phase" for this window. 1772 * if the SCHC Fragment received is an All-1 SCHC Fragment, the 1773 padding bits of the All-1 SCHC Fragment MUST be assembled after 1774 the received tile, the current window is determined to be the 1775 last window, the receiver MUST perform the integrity check and 1776 it MUST send a SCHC ACK for this window. Then, 1778 + If the integrity check indicates that the full SCHC Packet 1779 has been correctly reassembled, the receiver MUST enter the 1780 "clean-up phase". 1782 + If the integrity check indicates that the full SCHC Packet 1783 has not been correctly reassembled, the receiver enters the 1784 "retransmission phase" for this window. 1786 o on receiving a SCHC ACK REQ with the W bit equal to the local W 1787 bit, the receiver has not yet determined if the current window is 1788 a not-last one or the last one, the receiver MUST send a SCHC ACK 1789 for this window, and it keeps accepting incoming messages. 1791 In the "retransmission phase": 1793 o if the window is a not-last window 1795 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1796 different from the local W bit the receiver MUST silently 1797 ignore and discard that message. 1799 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1800 bit, the receiver MUST send a SCHC ACK for this window. 1802 * on receiving a SCHC Fragment with a W bit equal to the local W 1803 bit, 1805 + if the SCHC Fragment received is an All-1 SCHC Fragment, the 1806 receiver MUST silently ignore it and discard it. 1808 + otherwise, the receiver MUST update the Bitmap and it MUST 1809 assemble the tile received. 1811 * on the Bitmap becoming fully populated with 1's, the receiver 1812 MUST send a SCHC ACK for this window, it MUST increment its 1813 window counter and it enters the "acceptance phase" for the new 1814 window. 1816 o if the window is the last window 1818 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1819 different from the local W bit the receiver MUST silently 1820 ignore and discard that message. 1822 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1823 bit, the receiver MUST send a SCHC ACK for this window. 1825 * on receiving a SCHC Fragment with a W bit equal to the local W 1826 bit, 1828 + if the SCHC Fragment received is an All-0 SCHC Fragment, the 1829 receiver MUST silently ignore it and discard it. 1831 + otherwise, the receiver MUST update the Bitmap and it MUST 1832 assemble the tile received. If the SCHC Fragment received 1833 is an All-1 SCHC Fragment, the receiver MUST assemble the 1834 padding bits of the All-1 SCHC Fragment after the received 1835 tile. It MUST perform the integrity check. Then 1837 - if the integrity check indicates that the full SCHC 1838 Packet has been correctly reassembled, the receiver MUST 1839 send a SCHC ACK and it enters the "clean-up phase". 1841 - if the integrity check indicates that the full SCHC 1842 Packet has not been correctly reassembled, 1844 o if the SCHC Fragment received was an All-1 SCHC 1845 Fragment, the receiver MUST send a SCHC ACK for this 1846 window 1848 o it keeps accepting incoming messages. 1850 In the "clean-up phase": 1852 o Any received SCHC F/R message with a W bit different from the 1853 local W bit MUST be silently ignored and discarded. 1855 o Any received SCHC F/R message different from an All-1 SCHC 1856 Fragment or a SCHC ACK REQ MUST be silently ignored and discarded. 1858 o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, the 1859 receiver MUST send a SCHC ACK. 1861 At any time, on expiration of the Inactivity Timer, on receiving a 1862 SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the 1863 receiver MUST send a SCHC Receiver-Abort and it MAY exit the receive 1864 process for that SCHC Packet. 1866 Figure 40 shows an example of a corresponding state machine. 1868 8.4.3. ACK-on-Error mode 1870 The ACK-on-Error mode supports LPWAN technologies that have variable 1871 MTU and out-of-order delivery. 1873 In ACK-on-Error mode, windows are used. All tiles MUST be of equal 1874 size, except for the last one, which MUST be of the same size or 1875 smaller than the regular ones. If allowed in a Profile, the 1876 penultimate tile MAY be exactly one L2 Word smaller than the regular 1877 tile size. 1879 A SCHC Fragment message carries one or more tiles, which may span 1880 multiple windows. A SCHC ACK reports on the reception of exactly one 1881 window of tiles. 1883 See Figure 23 for an example. 1885 +---------------------------------------------...-----------+ 1886 | SCHC Packet | 1887 +---------------------------------------------...-----------+ 1889 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| 1890 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| 1892 SCHC Fragment msg |-----------| 1894 Figure 23: a SCHC Packet fragmented in tiles, Ack-on-Error mode 1896 The W field is wide enough that it unambiguously represents an 1897 absolute window number. The fragment receiver sends SCHC ACKs to the 1898 fragment sender about windows for which tiles are missing. No SCHC 1899 ACK is sent by the fragment receiver for windows that it knows have 1900 been fully received. 1902 The fragment sender retransmits SCHC Fragments for tiles that are 1903 reported missing. It can advance to next windows even before it has 1904 ascertained that all tiles belonging to previous windows have been 1905 correctly received, and can still later retransmit SCHC Fragments 1906 with tiles belonging to previous windows. Therefore, the sender and 1907 the receiver may operate in a decoupled fashion. The fragmented SCHC 1908 Packet transmission concludes when 1910 o integrity checking shows that the fragmented SCHC Packet has been 1911 correctly reassembled at the receive end, and this information has 1912 been conveyed back to the sender, 1914 o or too many retransmission attempts were made, 1916 o or the receiver determines that the transmission of this 1917 fragmented SCHC Packet has been inactive for too long. 1919 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1920 F/R messages operating in this mode. 1922 The W field MUST be present in the SCHC F/R messages. 1924 Each Profile, for each Rule ID value, MUST define 1926 o the tile size (a tile does not need to be multiple of an L2 Word, 1927 but it MUST be at least the size of an L2 Word) 1929 o the value of M (size of the W field), 1931 o the value of N (size of the FCN field), 1933 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 1935 o the size and algorithm for the RCS field, 1937 o the size of the DTag field, 1939 o the value of MAX_ACK_REQUESTS, 1941 o the expiration time of the Retransmission Timer 1943 o the expiration time of the Inactivity Timer 1945 o if the last tile is carried in a Regular SCHC Fragment or an All-1 1946 SCHC Fragment (see Section 8.4.3.1) 1948 o if the penultimate tile MAY be one L2 Word smaller than the 1949 regular tile size. In this case, the regular tile size MUST be at 1950 least twice the L2 Word size. 1952 For each active pair of Rule ID and DTag values, the sender MUST 1953 maintain 1954 o one Attempts counter 1956 o one Retransmission Timer 1958 For each active pair of Rule ID and DTag values, the receiver MUST 1959 maintain an Inactivity Timer. 1961 8.4.3.1. Sender behavior 1963 At the beginning of the fragmentation of a new SCHC Packet, 1965 o the fragment sender MUST select a Rule ID and DTag value pair for 1966 this SCHC Packet. A Rule MUST NOT be selected if the values of M 1967 and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot 1968 be fragmented in (2^M) * WINDOW_SIZE tiles or less. 1970 o the fragment sender MUST initialize the Attempts counter to 0 for 1971 that Rule ID and DTag value pair. 1973 A Regular SCHC Fragment message carries in its payload one or more 1974 tiles. If more than one tile is carried in one Regular SCHC Fragment 1976 o the selected tiles MUST be consecutive in the original SCHC Packet 1978 o they MUST be placed in the SCHC Fragment Payload adjacent to one 1979 another, in the order they appear in the SCHC Packet, from the 1980 start of the SCHC Packet toward its end. 1982 Tiles that are not the last one MUST be sent in Regular SCHC 1983 Fragments specified in Section 8.3.1.1. The FCN field MUST contain 1984 the tile index of the first tile sent in that SCHC Fragment. 1986 In a Regular SCHC Fragment message, the sender MUST fill the W field 1987 with the window number of the first tile sent in that SCHC Fragment. 1989 Depending on the Profile, the last tile of a SCHC Packet MUST be sent 1990 either 1992 o in a Regular SCHC Fragment, alone or as part of a multi-tiles 1993 Payload 1995 o alone in an All-1 SCHC Fragment 1997 In an All-1 SCHC Fragment message, the sender MUST fill the W field 1998 with the window number of the last tile of the SCHC Packet. 2000 The fragment sender MUST send SCHC Fragments such that, all together, 2001 they contain all the tiles of the fragmented SCHC Packet. 2003 The fragment sender MUST send at least one All-1 SCHC Fragment. 2005 The fragment sender MUST listen for SCHC ACK messages after having 2006 sent 2008 o an All-1 SCHC Fragment 2010 o or a SCHC ACK REQ. 2012 A Profile MAY specify other times at which the fragment sender MUST 2013 listen for SCHC ACK messages. For example, this could be after 2014 sending a complete window of tiles. 2016 Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC 2017 ACK REQ, 2019 o it MUST increment the Attempts counter 2021 o it MUST reset the Retransmission Timer 2023 On Retransmission Timer expiration 2025 o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment 2026 sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ 2027 with the W field corresponding to the last window, 2029 o otherwise the fragment sender MUST send a SCHC Sender-Abort and it 2030 MAY exit with an error condition. 2032 On receiving a SCHC ACK, 2034 o if the W field in the SCHC ACK corresponds to the last window of 2035 the SCHC Packet, 2037 * if the C bit is set, the sender MAY exit successfully 2039 * otherwise, 2041 + if the Profile mandates that the last tile be sent in an 2042 All-1 SCHC Fragment, 2044 - if the SCHC ACK shows no missing tile at the receiver, 2045 the sender 2047 o MUST send a SCHC Sender-Abort 2049 o MAY exit with an error condition 2051 - otherwise 2053 o the fragment sender MUST send SCHC Fragment messages 2054 containing all the tiles that are reported missing in 2055 the SCHC ACK. 2057 o if the last message in this sequence of SCHC Fragment 2058 messages is not an All-1 SCHC Fragment, then the 2059 fragment sender MUST in addition send a SCHC ACK REQ 2060 with the W field corresponding to the last window, 2061 after the sequence. 2063 + otherwise, 2065 - if the SCHC ACK shows no missing tile at the receiver, 2066 the sender MUST send the All-1 SCHC Fragment 2068 - otherwise 2070 o the fragment sender MUST send SCHC Fragment messages 2071 containing all the tiles that are reported missing in 2072 the SCHC ACK. 2074 o the fragment sender MUST then send either the All-1 2075 SCHC Fragment or a SCHC ACK REQ with the W field 2076 corresponding to the last window. 2078 o otherwise, the fragment sender 2080 * MUST send SCHC Fragment messages containing the tiles that are 2081 reported missing in the SCHC ACK 2083 * then it MAY send a SCHC ACK REQ with the W field corresponding 2084 to the last window 2086 See Figure 41 for one among several possible examples of a Finite 2087 State Machine implementing a sender behavior obeying this 2088 specification. 2090 8.4.3.2. Receiver behavior 2092 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 2093 processed at that time 2095 o the receiver SHOULD check if the DTag value has not recently been 2096 used for that Rule ID value, thereby ensuring that the received 2097 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 2098 transmission. If the SCHC Fragment is determined to be such a 2099 remnant, the receiver MAY silently ignore it and discard it. 2101 o the receiver MUST start a process to assemble a new SCHC Packet 2102 with that Rule ID and DTag value pair. 2104 o the receiver MUST start an Inactivity Timer. It MUST initialize 2105 an Attempts counter to 0. 2107 On receiving any SCHC F/R message, the receiver MUST reset the 2108 Inactivity Timer. 2110 On receiving a SCHC Fragment message, the receiver determines what 2111 tiles were received, based on the payload length and on the W and FCN 2112 fields of the SCHC Fragment. 2114 o if the FCN is All-1, if a Payload is present, the full SCHC 2115 Fragment Payload MUST be assembled including the padding bits. 2116 This is because the size of the last tile is not known by the 2117 receiver, therefore padding bits are indistinguishable from the 2118 tile data bits, at this stage. They will be removed by the SCHC 2119 C/D sublayer. If the size of the SCHC Fragment Payload exceeds or 2120 equals the size of one regular tile plus the size of an L2 Word, 2121 this SHOULD raise an error flag. 2123 o otherwise, tiles MUST be assembled based on the a priori known 2124 tile size. 2126 * If allowed by the Profile, the end of the payload MAY contain 2127 the last tile, which may be shorter. Padding bits are 2128 indistinguishable from the tile data bits, at this stage. 2130 * the payload may contain the penultimate tile that, if allowed 2131 by the Profile, MAY be exactly one L2 Word shorter than the 2132 regular tile size. 2134 * Otherwise, padding bits MUST be discarded. The latter is 2135 possible because 2137 + the size of the tiles is known a priori, 2139 + tiles are larger than an L2 Word 2141 + padding bits are always strictly less than an L2 Word 2143 On receiving a SCHC ACK REQ or an All-1 SCHC Fragment, 2144 o if the receiver has at least one window that it knows has tiles 2145 missing, it MUST return a SCHC ACK for the lowest-numbered such 2146 window, 2148 o otherwise, 2150 * if it has received at least one tile, it MUST return a SCHC ACK 2151 for the highest-numbered window it currently has tiles for 2153 * otherwise it MUST return a SCHC ACK for window numbered 0 2155 A Profile MAY specify other times and circumstances at which a 2156 receiver sends a SCHC ACK, and which window the SCHC ACK reports 2157 about in these circumstances. 2159 Upon sending a SCHC ACK, the receiver MUST increase the Attempts 2160 counter. 2162 After receiving an All-1 SCHC Fragment, a receiver MUST check the 2163 integrity of the reassembled SCHC Packet at least every time it 2164 prepares for sending a SCHC ACK for the last window. 2166 Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an 2167 error condition. 2169 Upon expiration of the Inactivity Timer, the receiver MUST send a 2170 SCHC Receiver-Abort and it MAY exit with an error condition. 2172 On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST 2173 send a SCHC Receiver-Abort and it MAY exit with an error condition. 2175 Reassembly of the SCHC Packet concludes when 2177 o a Sender-Abort has been received 2179 o or the Inactivity Timer has expired 2181 o or the Attempts counter has exceeded MAX_ACK_REQUESTS 2183 o or when at least an All-1 SCHC Fragment has been received and 2184 integrity checking of the reassembled SCHC Packet is successful. 2186 See Figure 42 for one among several possible examples of a Finite 2187 State Machine implementing a receiver behavior obeying this 2188 specification, and that is meant to match the sender Finite State 2189 Machine of Figure 41. 2191 9. Padding management 2193 SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does 2194 not have any alignment prerequisite. The size of SCHC Packets can be 2195 any number of bits. 2197 If the layer below SCHC constrains the payload to align to some 2198 boundary, called L2 Words (for example, bytes), the SCHC messages 2199 MUST be padded. When padding occurs, the number of appended bits 2200 MUST be strictly less than the L2 Word size. 2202 If a SCHC Packet is sent unfragmented (see Figure 24), it is padded 2203 as needed for transmission. 2205 If a SCHC Packet needs to be fragmented for transmission, it is not 2206 padded in itself. Only the SCHC F/R messages are padded as needed 2207 for transmission. Some SCHC F/R messages are intrinsically aligned 2208 to L2 Words. 2210 A packet (e.g. an IPv6 packet) 2211 | ^ (padding bits 2212 v | dropped) 2213 +------------------+ +--------------------+ 2214 | SCHC Compression | | SCHC Decompression | 2215 +------------------+ +--------------------+ 2216 | ^ 2217 | If no fragmentation | 2218 +---- SCHC Packet + padding as needed ----->| 2219 | | (integrity 2220 v | checked) 2221 +--------------------+ +-----------------+ 2222 | SCHC Fragmentation | | SCHC Reassembly | 2223 +--------------------+ +-----------------+ 2224 | ^ | ^ 2225 | | | | 2226 | +------------- SCHC ACK ------------+ | 2227 | | 2228 +------- SCHC Fragments + padding as needed---------+ 2230 Sender Receiver 2232 Figure 24: SCHC operations, including padding as needed 2234 Each Profile MUST specify the size of the L2 Word. The L2 Word might 2235 actually be a single bit, in which case no padding will take place at 2236 all. 2238 A Profile MAY define the value of the padding bits. The RECOMMENDED 2239 value is 0. 2241 10. SCHC Compression for IPv6 and UDP headers 2243 This section lists the IPv6 and UDP header fields and describes how 2244 they can be compressed. 2246 10.1. IPv6 version field 2248 The IPv6 version field is labeled by the protocol parser as being the 2249 "version" field of the IPv6 protocol. Therefore, it only exists for 2250 IPv6 packets. In the Rule, TV is set to 6, MO to "ignore" and CDA to 2251 "not-sent". 2253 10.2. IPv6 Traffic class field 2255 If the DiffServ field does not vary and is known by both sides, the 2256 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2257 value, an "equal" MO and a "not-sent" CDA. 2259 Otherwise (e.g. ECN bits are to be transmitted), two possibilities 2260 can be considered depending on the variability of the value: 2262 o One possibility is to not compress the field and send the original 2263 value. In the Rule, TV is not set to any particular value, MO is 2264 set to "ignore" and CDA is set to "value-sent". 2266 o If some upper bits in the field are constant and known, a better 2267 option is to only send the LSBs. In the Rule, TV is set to a 2268 value with the stable known upper part, MO is set to MSB(x) and 2269 CDA to LSB. 2271 10.3. Flow label field 2273 If the Flow Label field does not vary and is known by both sides, the 2274 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2275 value, an "equal" MO and a "not-sent" CDA. 2277 Otherwise, two possibilities can be considered: 2279 o One possibility is to not compress the field and send the original 2280 value. In the Rule, TV is not set to any particular value, MO is 2281 set to "ignore" and CDA is set to "value-sent". 2283 o If some upper bits in the field are constant and known, a better 2284 option is to only send the LSBs. In the Rule, TV is set to a 2285 value with the stable known upper part, MO is set to MSB(x) and 2286 CDA to LSB. 2288 10.4. Payload Length field 2290 This field can be elided for the transmission on the LPWAN network. 2291 The SCHC C/D recomputes the original payload length value. In the 2292 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 2293 "compute-*". 2295 10.5. Next Header field 2297 If the Next Header field does not vary and is known by both sides, 2298 the Field Descriptor in the Rule SHOULD contain a TV with this Next 2299 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 2300 sent". 2302 Otherwise, TV is not set in the Field Descriptor, MO is set to 2303 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 2304 list MAY also be used. 2306 10.6. Hop Limit field 2308 The field behavior for this field is different for uplink (Up) and 2309 downlink (Dw). In Up, since there is no IP forwarding between the 2310 Dev and the SCHC C/D, the value is relatively constant. On the other 2311 hand, the Dw value depends on Internet routing and can change more 2312 frequently. The Direction Indicator (DI) can be used to distinguish 2313 both directions: 2315 o in the Up, elide the field: the TV in the Field Descriptor is set 2316 to the known constant value, the MO is set to "equal" and the CDA 2317 is set to "not-sent". 2319 o in the Dw, the Hop Limit is elided for transmission and forced to 2320 1 at the receiver, by setting TV to 1, MO to "ignore" and CDA to 2321 "not-sent". This prevents any further forwarding. 2323 10.7. IPv6 addresses fields 2325 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 2326 long fields; one for the prefix and one for the Interface Identifier 2327 (IID). These fields SHOULD be compressed. To allow for a single 2328 Rule being used for both directions, these values are identified by 2329 their role (Dev or App) and not by their position in the header 2330 (source or destination). 2332 10.7.1. IPv6 source and destination prefixes 2334 Both ends MUST be configured with the appropriate prefixes. For a 2335 specific flow, the source and destination prefixes can be unique and 2336 stored in the Context. In that case, the TV for the source and 2337 destination prefixes contain the values, the MO is set to "equal" and 2338 the CDA is set to "not-sent". 2340 If the Rule is intended to compress packets with different prefix 2341 values, match-mapping SHOULD be used. The different prefixes are 2342 listed in the TV, the MO is set to "match-mapping" and the CDA is set 2343 to "mapping-sent". See Figure 26. 2345 Otherwise, the TV is not set, the MO is set to "ignore" and the CDA 2346 is set to "value-sent". 2348 10.7.2. IPv6 source and destination IID 2350 If the Dev or App IID are based on an LPWAN address, then the IID can 2351 be reconstructed with information coming from the LPWAN header. In 2352 that case, the TV is not set, the MO is set to "ignore" and the CDA 2353 is set to "DevIID" or "AppIID". On LPWAN technologies where the 2354 frames carry a single identifier (corresponding to the Dev.), AppIID 2355 cannot be used. 2357 As described in [RFC8065], it may be undesirable to build the Dev 2358 IPv6 IID out of the Dev address. Another static value is used 2359 instead. In that case, the TV contains the static value, the MO 2360 operator is set to "equal" and the CDA is set to "not-sent". 2361 [RFC7217] provides some methods to derive this static identifier. 2363 If several IIDs are possible, then the TV contains the list of 2364 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 2365 "mapping-sent". 2367 It may also happen that the IID variability only expresses itself on 2368 a few bytes. In that case, the TV is set to the stable part of the 2369 IID, the MO is set to "MSB" and the CDA is set to "LSB". 2371 Finally, the IID can be sent in its entirety on the LPWAN. In that 2372 case, the TV is not set, the MO is set to "ignore" and the CDA is set 2373 to "value-sent". 2375 10.8. IPv6 extensions 2377 This document does not provide recommendations on how to compress 2378 IPv6 extensions. 2380 10.9. UDP source and destination port 2382 To allow for a single Rule being used for both directions, the UDP 2383 port values are identified by their role (Dev or App) and not by 2384 their position in the header (source or destination). The SCHC C/D 2385 MUST be aware of the traffic direction (Uplink, Downlink) to select 2386 the appropriate field. The following Rules apply for Dev and App 2387 port numbers. 2389 If both ends know the port number, it can be elided. The TV contains 2390 the port number, the MO is set to "equal" and the CDA is set to "not- 2391 sent". 2393 If the port variation is on few bits, the TV contains the stable part 2394 of the port number, the MO is set to "MSB" and the CDA is set to 2395 "LSB". 2397 If some well-known values are used, the TV can contain the list of 2398 these values, the MO is set to "match-mapping" and the CDA is set to 2399 "mapping-sent". 2401 Otherwise the port numbers are sent over the LPWAN. The TV is not 2402 set, the MO is set to "ignore" and the CDA is set to "value-sent". 2404 10.10. UDP length field 2406 The UDP length can be computed from the received data. The TV is not 2407 set, the MO is set to "ignore" and the CDA is set to "compute-*". 2409 10.11. UDP Checksum field 2411 The UDP checksum operation is mandatory with IPv6 for most packets 2412 but there are exceptions [RFC8200]. 2414 For instance, protocols that use UDP as a tunnel encapsulation may 2415 enable zero-checksum mode for a specific port (or set of ports) for 2416 sending and/or receiving. [RFC8200] requires any node implementing 2417 zero-checksum mode to follow the requirements specified in 2418 "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero 2419 Checksums" [RFC6936]. 2421 6LoWPAN Header Compression [RFC6282] also specifies that a UDP 2422 checksum can be elided by the compressor and re-computed by the 2423 decompressor when an upper layer guarantees the integrity of the UDP 2424 payload and pseudo-header. A specific example of this is when a 2425 Message Integrity Check protects the compressed message between the 2426 compressor that elides the UDP checksum and the decompressor that 2427 computes it, with a strength that is identical or better to the UDP 2428 checksum. 2430 Similarly, a SCHC compressor MAY elide the UDP checksum when another 2431 layer guarantees at least equal integrity protection for the UDP 2432 payload and the pseudo-header. In this case, the TV is not set, the 2433 MO is set to "ignore" and the CDA is set to "compute-*". 2435 In particular, when SCHC fragmentation is used, a fragmentation RCS 2436 of 2 bytes or more provides equal or better protection than the UDP 2437 checksum; in that case, if the compressor is collocated with the 2438 fragmentation point and the decompressor is collocated with the 2439 packet reassembly point, and if the SCHC Packet is fragmented even 2440 when it would fit unfragmented in the L2 MTU, then the compressor MAY 2441 verify and then elide the UDP checksum. Whether and when the UDP 2442 Checksum is elided is to be specified in the Profile. 2444 Since the compression happens before the fragmentation, implementors 2445 should understand the risks when dealing with unprotected data below 2446 the transport layer and take special care when manipulating that 2447 data. 2449 In other cases, the checksum SHOULD be explicitly sent. The TV is 2450 not set, the MO is set to "ignore" and the CDA is set to "value- 2451 sent". 2453 11. IANA Considerations 2455 This document has no request to IANA. 2457 12. Security considerations 2459 Wireless networks are subjects to various sorts of attacks, which are 2460 not specific to SCHC. In this section, we'll assume that an attacker 2461 was able to break into the network despite the latter's security 2462 measures and that it can now send packets to a target node. What is 2463 specific to SCHC is the amplification of the effects that this break- 2464 in could allow. Our analysis equally applies to legitimate nodes 2465 "going crazy". 2467 12.1. Security considerations for SCHC Compression/Decompression 2469 Let's assume that an attacker is able to send a forged SCHC Packet to 2470 a SCHC Decompressor. 2472 Let's first consider the case where the Rule ID contained in that 2473 forged SCHC Packet does not correspond to a Rule allocated in the 2474 Rule table. An implementation should detect that the Rule ID is 2475 invalid and should silently drop the offending SCHC Packet. 2477 Let's now consider that the Rule ID corresponds to a Rule in the 2478 table. With the CDAs defined in this document, the reconstructed 2479 packet is at most a constant number of bits bigger than the SCHC 2480 Packet that was received. This assumes that the compute-* 2481 decompression actions produce a bounded number of bits, irrespective 2482 of the incoming SCHC Packet. This property is true for IPv6 Length, 2483 UDP Length and UDP Checksum, for which the compute-* CDA is 2484 recommended by this document. 2486 As a consequence, SCHC Decompression does not amplify attacks, beyond 2487 adding a bounded number of bits to the SCHC Packet received. This 2488 bound is determined by the Rule stored in the receiving device. 2490 As a general safety measure, a SCHC Decompressor should never re- 2491 construct a packet larger than MAX_PACKET_SIZE (defined in a Profile, 2492 with 1500 bytes as generic default). 2494 12.2. Security considerations for SCHC Fragmentation/Reassembly 2496 Let's assume that an attacker is able to send to a forged SCHC 2497 Fragment to a SCHC Reassembler. 2499 A node can perform a buffer reservation attack: the receiver will 2500 reserve buffer space for the SCHC Packet. If the implementation has 2501 only one buffer, other incoming fragmented SCHC Packets will be 2502 dropped while the reassembly buffer is occupied during the reassembly 2503 timeout. Once that timeout expires, the attacker can repeat the same 2504 procedure, and iterate, thus creating a denial of service attack. An 2505 implementation may have multiple reassembly buffers. The cost to 2506 mount this attack is linear with the number of buffers at the target 2507 node. Better, the cost for an attacker can be increased if 2508 individual fragments of multiple SCHC Packets can be stored in the 2509 reassembly buffer. The finer grained the reassembly buffer (downto 2510 the smallest tile size), the higher the cost of the attack. If 2511 buffer overload does occur, a smart receiver could selectively 2512 discard SCHC Packets being reassembled based on the sender behavior, 2513 which may help identify which SCHC Fragments have been sent by the 2514 attacker. Another mild counter-measure is for the target to abort 2515 the fragmentation/reassembly session as early as it detects a non- 2516 identical SCHC Fragment duplicate, anticipating for an eventual 2517 corrupt SCHC Packet, so as to save the sender the hassle of sending 2518 the rest of the fragments for this SCHC Packet. 2520 In another type of attack, the malicious node is additionally assumed 2521 to be able to hear an incoming communication destined to the target 2522 node. It can then send a forged SCHC Fragment that looks like it 2523 belongs to a SCHC Packet already being reassembled at the target 2524 node. This can cause the SCHC Packet to be considered corrupt and be 2525 dropped by the receiver. The amplification happens here by a single 2526 spoofed SCHC Fragment rendering a full sequence of legit SCHC 2527 Fragments useless. If the target uses ACK-Always or ACK-on-Error 2528 mode, such a malicious node can also interfere with the 2529 acknowledgement and repetition algorithm of SCHC F/R. A single 2530 spoofed ACK, with all bitmap bits set to 0, will trigger the 2531 repetition of WINDOW_SIZE tiles. This protocol loop amplification 2532 depletes the energy source of the target node and consumes the 2533 channel bandwidth. Similarly, a spoofed ACK REQ will trigger the 2534 sending of a SCHC ACK, which may be much larger than the ACK REQ if 2535 WINDOW_SIZE is large. These consequences should be borne in mind 2536 when defining profiles for SCHC over specific LPWAN technologies. 2538 13. Acknowledgements 2540 Thanks to Sergio Aguilar Romero, Carsten Bormann, Philippe Clavier, 2541 Daniel Ducuara Beltran Diego Dujovne, Eduardo Ingles Sanchez, 2542 Arunprabhu Kandasamy, Suresh Krishnan, Rahul Jadhav, Sergio Lopez 2543 Bernal, Antony Markovski, Alexander Pelov, Charles Perkins, Edgar 2544 Ramos, Shoichi Sakane, and Pascal Thubert for useful design 2545 consideration and comments. 2547 Carles Gomez has been funded in part by the Spanish Government 2548 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2549 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2550 Government through project TEC2016-79988-P. Part of his contribution 2551 to this work has been carried out during his stay as a visiting 2552 scholar at the Computer Laboratory of the University of Cambridge. 2554 14. References 2556 14.1. Normative References 2558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2559 Requirement Levels", BCP 14, RFC 2119, 2560 DOI 10.17487/RFC2119, March 1997, 2561 . 2563 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2564 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2565 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2566 . 2568 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2569 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2570 May 2017, . 2572 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2573 (IPv6) Specification", STD 86, RFC 8200, 2574 DOI 10.17487/RFC8200, July 2017, 2575 . 2577 14.2. Informative References 2579 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 2580 "Internet Protocol Small Computer System Interface (iSCSI) 2581 Cyclic Redundancy Check (CRC)/Checksum Considerations", 2582 RFC 3385, DOI 10.17487/RFC3385, September 2002, 2583 . 2585 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2586 "Transmission of IPv6 Packets over IEEE 802.15.4 2587 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2588 . 2590 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2591 Header Compression (ROHC) Framework", RFC 5795, 2592 DOI 10.17487/RFC5795, March 2010, 2593 . 2595 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2596 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2597 DOI 10.17487/RFC6282, September 2011, 2598 . 2600 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2601 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2602 February 2014, . 2604 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2605 Interface Identifiers with IPv6 Stateless Address 2606 Autoconfiguration (SLAAC)", RFC 7217, 2607 DOI 10.17487/RFC7217, April 2014, 2608 . 2610 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 2611 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 2612 February 2017, . 2614 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2615 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2616 . 2618 Appendix A. Compression Examples 2620 This section gives some scenarios of the compression mechanism for 2621 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2623 The mechanisms defined in this document can be applied to a Dev that 2624 embeds some applications running over CoAP. In this example, three 2625 flows are considered. The first flow is for the device management 2626 based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 2627 124 for Dev and App, respectively. The second flow will be a CoAP 2628 server for measurements done by the Dev (using ports 5683) and Global 2629 IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is 2630 for legacy applications using different ports numbers, the 2631 destination IPv6 address prefix is gamma::1/64. 2633 Figure 25 presents the protocol stack. IPv6 and UDP are represented 2634 with dotted lines since these protocols are compressed on the radio 2635 link. 2637 Management Data 2638 +----------+---------+---------+ 2639 | CoAP | CoAP | legacy | 2640 +----||----+---||----+---||----+ 2641 . UDP . UDP | UDP | 2642 ................................ 2643 . IPv6 . IPv6 . IPv6 . 2644 +------------------------------+ 2645 | SCHC Header compression | 2646 | and fragmentation | 2647 +------------------------------+ 2648 | LPWAN L2 technologies | 2649 +------------------------------+ 2650 Dev or NGW 2652 Figure 25: Simplified Protocol Stack for LP-WAN 2654 In some LPWAN technologies, only the Devs have a device ID. When 2655 such technologies are used, it is necessary to statically define an 2656 IID for the Link Local address for the SCHC C/D. 2658 Rule 0 2659 +----------------+--+--+--+---------+--------+------------++------+ 2660 | Field |FL|FP|DI| Value | Match | Comp Decomp|| 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 |Bi|255 | ignore | not-sent || | 2669 |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2670 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2671 |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2672 |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | 2673 +================+==+==+==+=========+========+============++======+ 2674 |UDP DevPort |16|1 |Bi|123 | equal | not-sent || | 2675 |UDP AppPort |16|1 |Bi|124 | equal | not-sent || | 2676 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2677 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2678 +================+==+==+==+=========+========+============++======+ 2680 Rule 1 2681 +----------------+--+--+--+---------+--------+------------++------+ 2682 | Field |FL|FP|DI| Value | Match | Action || Sent | 2683 | | | | | | Opera. | Action ||[bits]| 2684 +----------------+--+--+--+---------+--------+------------++------+ 2685 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2686 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2687 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2688 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2689 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2690 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2691 |IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 | 2692 | | | | |fe80::/64] mapping| || | 2693 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2694 |IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 | 2695 | | | | |alpha/64,| mapping| || | 2696 | | | | |fe80::64]| | || | 2697 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2698 +================+==+==+==+=========+========+============++======+ 2699 |UDP DevPort |16|1 |Bi|5683 | equal | not-sent || | 2700 |UDP AppPort |16|1 |Bi|5683 | equal | not-sent || | 2701 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2702 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2703 +================+==+==+==+=========+========+============++======+ 2705 Rule 2 2706 +----------------+--+--+--+---------+--------+------------++------+ 2707 | Field |FL|FP|DI| Value | Match | Action || Sent | 2708 | | | | | | Opera. | Action ||[bits]| 2709 +----------------+--+--+--+---------+--------+------------++------+ 2710 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2711 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2712 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2713 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2714 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2715 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2716 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 | 2717 |IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2718 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2719 |IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2720 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2721 +================+==+==+==+=========+========+============++======+ 2722 |UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2723 |UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2724 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2725 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2726 +================+==+==+==+=========+========+============++======+ 2728 Figure 26: Context Rules 2730 All the fields described in the three Rules depicted on Figure 26 are 2731 present in the IPv6 and UDP headers. The DevIID-DID value is found 2732 in the L2 header. 2734 The second and third Rules use global addresses. The way the Dev 2735 learns the prefix is not in the scope of the document. 2737 The third Rule compresses each port number to 4 bits. 2739 Appendix B. Fragmentation Examples 2741 This section provides examples for the various fragment reliability 2742 modes specified in this document. In the drawings, Bitmaps are shown 2743 in their uncompressed form. 2745 Figure 27 illustrates the transmission in No-ACK mode of a SCHC 2746 Packet that needs 11 SCHC Fragments. FCN is 1 bit wide. 2748 Sender Receiver 2749 |-------FCN=0-------->| 2750 |-------FCN=0-------->| 2751 |-------FCN=0-------->| 2752 |-------FCN=0-------->| 2753 |-------FCN=0-------->| 2754 |-------FCN=0-------->| 2755 |-------FCN=0-------->| 2756 |-------FCN=0-------->| 2757 |-------FCN=0-------->| 2758 |-------FCN=0-------->| 2759 |-----FCN=1 + RCS --->| Integrity check: success 2760 (End) 2762 Figure 27: No-ACK mode, 11 SCHC Fragments 2764 In the following examples, N (the size of the FCN field) is 3 bits. 2765 The All-1 FCN value is 7. 2767 Figure 28 illustrates the transmission in ACK-on-Error mode of a SCHC 2768 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2769 WINDOW_SIZE=7 and no lost SCHC Fragment. 2771 Sender Receiver 2772 |-----W=0, FCN=6----->| 2773 |-----W=0, FCN=5----->| 2774 |-----W=0, FCN=4----->| 2775 |-----W=0, FCN=3----->| 2776 |-----W=0, FCN=2----->| 2777 |-----W=0, FCN=1----->| 2778 |-----W=0, FCN=0----->| 2779 (no ACK) 2780 |-----W=1, FCN=6----->| 2781 |-----W=1, FCN=5----->| 2782 |-----W=1, FCN=4----->| 2783 |--W=1, FCN=7 + RCS-->| Integrity check: success 2784 |<-- ACK, W=1, C=1 ---| C=1 2785 (End) 2787 Figure 28: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2788 no lost SCHC Fragment. 2790 Figure 29 illustrates the transmission in ACK-on-Error mode of a SCHC 2791 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2792 WINDOW_SIZE=7 and three lost SCHC Fragments. 2794 Sender Receiver 2795 |-----W=0, FCN=6----->| 2796 |-----W=0, FCN=5----->| 2797 |-----W=0, FCN=4--X-->| 2798 |-----W=0, FCN=3----->| 2799 |-----W=0, FCN=2--X-->| 2800 |-----W=0, FCN=1----->| 2801 |-----W=0, FCN=0----->| 6543210 2802 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2803 |-----W=0, FCN=4----->| 2804 |-----W=0, FCN=2----->| 2805 (no ACK) 2806 |-----W=1, FCN=6----->| 2807 |-----W=1, FCN=5----->| 2808 |-----W=1, FCN=4--X-->| 2809 |- W=1, FCN=7 + RCS ->| Integrity check: failure 2810 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 2811 |-----W=1, FCN=4----->| Integrity check: success 2812 |<-- ACK, W=1, C=1 ---| C=1 2813 (End) 2815 Figure 29: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2816 lost SCHC Fragments. 2818 Figure 30 shows an example of a transmission in ACK-on-Error mode of 2819 a SCHC Packet fragmented in 73 tiles, with N=5, WINDOW_SIZE=28, M=2 2820 and 3 lost SCHC Fragments. 2822 Sender Receiver 2823 |-----W=0, FCN=27----->| 4 tiles sent 2824 |-----W=0, FCN=23----->| 4 tiles sent 2825 |-----W=0, FCN=19----->| 4 tiles sent 2826 |-----W=0, FCN=15--X-->| 4 tiles sent (not received) 2827 |-----W=0, FCN=11----->| 4 tiles sent 2828 |-----W=0, FCN=7 ----->| 4 tiles sent 2829 |-----W=0, FCN=3 ----->| 4 tiles sent 2830 |-----W=1, FCN=27----->| 4 tiles sent 2831 |-----W=1, FCN=23----->| 4 tiles sent 2832 |-----W=1, FCN=19----->| 4 tiles sent 2833 |-----W=1, FCN=15----->| 4 tiles sent 2834 |-----W=1, FCN=11----->| 4 tiles sent 2835 |-----W=1, FCN=7 ----->| 4 tiles sent 2836 |-----W=1, FCN=3 --X-->| 4 tiles sent (not received) 2837 |-----W=2, FCN=27----->| 4 tiles sent 2838 |-----W=2, FCN=23----->| 4 tiles sent 2839 ^ |-----W=2, FCN=19----->| 1 tile sent 2840 | |-----W=2, FCN=18----->| 1 tile sent 2841 | |-----W=2, FCN=17----->| 1 tile sent 2842 |-----W=2, FCN=16----->| 1 tile sent 2843 s |-----W=2, FCN=15----->| 1 tile sent 2844 m |-----W=2, FCN=14----->| 1 tile sent 2845 a |-----W=2, FCN=13--X-->| 1 tile sent (not received) 2846 l |-----W=2, FCN=12----->| 1 tile sent 2847 l |---W=2, FCN=31 + RCS->| Integrity check: failure 2848 e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 2849 r |-----W=0, FCN=15----->| 1 tile sent 2850 |-----W=0, FCN=14----->| 1 tile sent 2851 L |-----W=0, FCN=13----->| 1 tile sent 2852 2 |-----W=0, FCN=12----->| 1 tile sent 2853 |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 2854 M |-----W=1, FCN=3 ----->| 1 tile sent 2855 T |-----W=1, FCN=2 ----->| 1 tile sent 2856 U |-----W=1, FCN=1 ----->| 1 tile sent 2857 |-----W=1, FCN=0 ----->| 1 tile sent 2858 | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 2859 | |-----W=2, FCN=13----->| Integrity check: success 2860 V |<--- ACK, W=2, C=1 ---| C=1 2861 (End) 2863 Figure 30: ACK-on-Error mode, variable MTU. 2865 In this example, the L2 MTU becomes reduced just before sending the 2866 "W=2, FCN=19" fragment, leaving space for only 1 tile in each 2867 forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are 2868 carried by a total of 25 SCHC Fragments, the last 9 being of smaller 2869 size. 2871 Note: other sequences of events (e.g. regarding when ACKs are sent by 2872 the Receiver) are also allowed by this specification. Profiles may 2873 restrict this flexibility. 2875 Figure 31 illustrates the transmission in ACK-Always mode of a SCHC 2876 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with 2877 N=3, WINDOW_SIZE=7 and no loss. 2879 Sender Receiver 2880 |-----W=0, FCN=6----->| 2881 |-----W=0, FCN=5----->| 2882 |-----W=0, FCN=4----->| 2883 |-----W=0, FCN=3----->| 2884 |-----W=0, FCN=2----->| 2885 |-----W=0, FCN=1----->| 2886 |-----W=0, FCN=0----->| 2887 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2888 |-----W=1, FCN=6----->| 2889 |-----W=1, FCN=5----->| 2890 |-----W=1, FCN=4----->| 2891 |--W=1, FCN=7 + RCS-->| Integrity check: success 2892 |<-- ACK, W=1, C=1 ---| C=1 2893 (End) 2895 Figure 31: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, no 2896 loss. 2898 Figure 32 illustrates the transmission in ACK-Always mode of a SCHC 2899 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, 2900 WINDOW_SIZE=7 and three lost SCHC Fragments. 2902 Sender Receiver 2903 |-----W=0, FCN=6----->| 2904 |-----W=0, FCN=5----->| 2905 |-----W=0, FCN=4--X-->| 2906 |-----W=0, FCN=3----->| 2907 |-----W=0, FCN=2--X-->| 2908 |-----W=0, FCN=1----->| 2909 |-----W=0, FCN=0----->| 6543210 2910 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2911 |-----W=0, FCN=4----->| 2912 |-----W=0, FCN=2----->| 2913 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2914 |-----W=1, FCN=6----->| 2915 |-----W=1, FCN=5----->| 2916 |-----W=1, FCN=4--X-->| 2917 |--W=1, FCN=7 + RCS-->| Integrity check: failure 2918 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001 2919 |-----W=1, FCN=4----->| Integrity check: success 2920 |<-- ACK, W=1, C=1 ---| C=1 2921 (End) 2923 Figure 32: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, 2924 three lost SCHC Fragments. 2926 Figure 33 illustrates the transmission in ACK-Always mode of a SCHC 2927 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2928 WINDOW_SIZE=7, three lost SCHC Fragments and only one retry needed to 2929 recover each lost SCHC Fragment. 2931 Sender Receiver 2932 |-----W=0, FCN=6----->| 2933 |-----W=0, FCN=5----->| 2934 |-----W=0, FCN=4--X-->| 2935 |-----W=0, FCN=3--X-->| 2936 |-----W=0, FCN=2--X-->| 2937 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2938 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2939 |-----W=0, FCN=4----->| Integrity check: failure 2940 |-----W=0, FCN=3----->| Integrity check: failure 2941 |-----W=0, FCN=2----->| Integrity check: success 2942 |<-- ACK, W=0, C=1 ---| C=1 2943 (End) 2945 Figure 33: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, 2946 three lost SCHC Fragments. 2948 Figure 34 illustrates the transmission in ACK-Always mode of a SCHC 2949 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2950 WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK 2951 lost. 2953 Sender Receiver 2954 |-----W=0, FCN=6----->| 2955 |-----W=0, FCN=5----->| 2956 |-----W=0, FCN=4--X-->| 2957 |-----W=0, FCN=3--X-->| 2958 |-----W=0, FCN=2--X-->| 2959 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2960 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2961 |-----W=0, FCN=4----->| Integrity check: failure 2962 |-----W=0, FCN=3----->| Integrity check: failure 2963 |-----W=0, FCN=2----->| Integrity check: success 2964 |<-X-ACK, W=0, C=1 ---| C=1 2965 timeout | | 2966 |--- W=0, ACK REQ --->| ACK REQ 2967 |<-- ACK, W=0, C=1 ---| C=1 2968 (End) 2970 Figure 34: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, SCHC 2971 ACK loss. 2973 Figure 35 illustrates the transmission in ACK-Always mode of a SCHC 2974 Packet fragmented in 6 tiles, with N=3, WINDOW_SIZE=7, with three 2975 lost SCHC Fragments, and one retransmitted SCHC Fragment lost again. 2977 Sender Receiver 2978 |-----W=0, FCN=6----->| 2979 |-----W=0, FCN=5----->| 2980 |-----W=0, FCN=4--X-->| 2981 |-----W=0, FCN=3--X-->| 2982 |-----W=0, FCN=2--X-->| 2983 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2984 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2985 |-----W=0, FCN=4----->| Integrity check: failure 2986 |-----W=0, FCN=3----->| Integrity check: failure 2987 |-----W=0, FCN=2--X-->| 2988 timeout| | 2989 |--- W=0, ACK REQ --->| ACK REQ 2990 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 2991 |-----W=0, FCN=2----->| Integrity check: success 2992 |<-- ACK, W=0, C=1 ---| C=1 2993 (End) 2995 Figure 35: ACK-Always mode, 6 tiles, retransmitted SCHC Fragment lost 2996 again. 2998 Figure 36 illustrates the transmission in ACK-Always mode of a SCHC 2999 Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, 3000 WINDOW_SIZE=24 and two lost SCHC Fragments. 3002 Sender Receiver 3003 |-----W=0, FCN=23----->| 3004 |-----W=0, FCN=22----->| 3005 |-----W=0, FCN=21--X-->| 3006 |-----W=0, FCN=20----->| 3007 |-----W=0, FCN=19----->| 3008 |-----W=0, FCN=18----->| 3009 |-----W=0, FCN=17----->| 3010 |-----W=0, FCN=16----->| 3011 |-----W=0, FCN=15----->| 3012 |-----W=0, FCN=14----->| 3013 |-----W=0, FCN=13----->| 3014 |-----W=0, FCN=12----->| 3015 |-----W=0, FCN=11----->| 3016 |-----W=0, FCN=10--X-->| 3017 |-----W=0, FCN=9 ----->| 3018 |-----W=0, FCN=8 ----->| 3019 |-----W=0, FCN=7 ----->| 3020 |-----W=0, FCN=6 ----->| 3021 |-----W=0, FCN=5 ----->| 3022 |-----W=0, FCN=4 ----->| 3023 |-----W=0, FCN=3 ----->| 3024 |-----W=0, FCN=2 ----->| 3025 |-----W=0, FCN=1 ----->| 3026 |-----W=0, FCN=0 ----->| 3027 | | 3028 |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 3029 |-----W=0, FCN=21----->| 3030 |-----W=0, FCN=10----->| 3031 |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 3032 |-----W=1, FCN=23----->| 3033 |-----W=1, FCN=22----->| 3034 |-----W=1, FCN=21----->| 3035 |--W=1, FCN=31 + RCS-->| Integrity check: success 3036 |<--- ACK, W=1, C=1 ---| C=1 3037 (End) 3039 Figure 36: ACK-Always mode, 28 tiles, one tile per SCHC Fragment, 3040 lost SCHC Fragments. 3042 Appendix C. Fragmentation State Machines 3044 The fragmentation state machines of the sender and the receiver, one 3045 for each of the different reliability modes, are described in the 3046 following figures: 3048 +===========+ 3049 +------------+ Init | 3050 | FCN=0 +===========+ 3051 | No Window 3052 | No Bitmap 3053 | +-------+ 3054 | +========+==+ | More Fragments 3055 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 3056 +--------> | Send | send Fragment (FCN=0) 3057 +===+=======+ 3058 | last fragment 3059 | ~~~~~~~~~~~~ 3060 | FCN = 1 3061 v send fragment+RCS 3062 +============+ 3063 | END | 3064 +============+ 3066 Figure 37: Sender State Machine for the No-ACK Mode 3068 +------+ Not All-1 3069 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 3070 | + <--+ set Inactivity Timer 3071 | RCV Frag +-------+ 3072 +=+===+======+ |All-1 & 3073 All-1 & | | |RCS correct 3074 RCS wrong | |Inactivity | 3075 | |Timer Exp. | 3076 v | | 3077 +==========++ | v 3078 | Error |<-+ +========+==+ 3079 +===========+ | END | 3080 +===========+ 3082 Figure 38: Receiver State Machine for the No-ACK Mode 3083 +=======+ 3084 | INIT | FCN!=0 & more frags 3085 | | ~~~~~~~~~~~~~~~~~~~~~~ 3086 +======++ +--+ send Window + frag(FCN) 3087 W=0 | | | FCN- 3088 Clear lcl_bm | | v set lcl_bm 3089 FCN=max value | ++==+========+ 3090 +> | | 3091 +---------------------> | SEND | 3092 | +==+===+=====+ 3093 | FCN==0 & more frags | | last frag 3094 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 3095 | set lcl_bm | | set lcl_bm 3096 | send wnd + frag(all-0) | | send wnd+frag(all-1)+RCS 3097 | set Retrans_Timer | | set Retrans_Timer 3098 | | | 3099 |Recv_wnd == wnd & | | 3100 |lcl_bm==recv_bm & | | +----------------------+ 3101 |more frag | | | lcl_bm!=rcv-bm | 3102 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 3103 |Stop Retrans_Timer | | | Attempt++ v 3104 |clear lcl_bm v v | +=====+=+ 3105 |window=next_window +====+===+==+===+ |Resend | 3106 +---------------------+ | |Missing| 3107 +----+ Wait | |Frag | 3108 not expected wnd | | Bitmap | +=======+ 3109 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 3110 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 3111 | | | ^ ^ |reSend(empty)All-* | 3112 | | | | | |Set Retrans_Timer | 3113 | | | | +--+Attempt++ | 3114 C_bit==1 & | | | +-------------------------+ 3115 Recv_window==window & | | | all missing frags sent 3116 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 3117 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 3118 Stop Retrans_Timer| | | 3119 +=============+ | | | 3120 | END +<--------+ | | 3121 +=============+ | | Attempt > MAX_ACK_REQUESTS 3122 All-1 Window & | | ~~~~~~~~~~~~~~~~~~ 3123 C_bit ==0 & | v Send Abort 3124 lcl_bm==recv_bm | +=+===========+ 3125 ~~~~~~~~~~~~ +>| ERROR | 3126 Send Abort +=============+ 3128 Figure 39: Sender State Machine for the ACK-Always Mode 3130 Not All- & w=expected +---+ +---+w = Not expected 3131 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 3132 Set lcl_bm(FCN) | v v |discard 3133 ++===+===+===+=+ 3134 +---------------------+ Rcv +--->* ABORT 3135 | +------------------+ Window | 3136 | | +=====+==+=====+ 3137 | | All-0 & w=expect | ^ w =next & not-All 3138 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 3139 | | set lcl_bm(FCN) | |expected = next window 3140 | | send lcl_bm | |Clear lcl_bm 3141 | | | | 3142 | | w=expected & not-All | | 3143 | | ~~~~~~~~~~~~~~~~~~ | | 3144 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0 3145 | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~ 3146 | | send lcl_bm | | | | | | expected = nxt wnd 3147 | | v | v | | | Clear lcl_bm 3148 | |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN) 3149 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm 3150 | | discard +--| Next | 3151 | | All-0 +---------+ Window +--->* ABORT 3152 | | ~~~~~ +-------->+========+=++ 3153 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 3154 | | & RCS wrong| | & RCS right 3155 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 3156 | | set lcl_bm(FCN)| |set lcl_bm(FCN) 3157 | | send lcl_bm| |send lcl_bm 3158 | | | +----------------------+ 3159 | |All-1 & w=expected | | 3160 | |& RCS wrong v +---+ w=expected & | 3161 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | RCS wrong | 3162 | |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ | 3163 | |send lcl_bm | Wait End | set lcl_bm(FCN)| 3164 | +--------------------->+ +--->* ABORT | 3165 | +===+====+=+-+ All-1&RCS wrong| 3166 | | ^ | ~~~~~~~~~~~~~~~| 3167 | w=expected & RCS right | +---+ send lcl_bm | 3168 | ~~~~~~~~~~~~~~~~~~~~~~ | | 3169 | set lcl_bm(FCN) | +-+ Not All-1 | 3170 | send lcl_bm | | | ~~~~~~~~~ | 3171 | | | | discard | 3172 |All-1&w=expected & RCS right | | | | 3173 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 3174 |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 3175 |send lcl_bm | +<+Send lcl_bm | 3176 +-------------------------->+ END | | 3177 +==========+<---------------+ 3179 --->* ABORT 3180 ~~~~~~~ 3181 Inactivity_Timer = expires 3182 When DWL 3183 IF Inactivity_Timer expires 3184 Send DWL Request 3185 Attempt++ 3187 Figure 40: Receiver State Machine for the ACK-Always Mode 3189 +=======+ 3190 | | 3191 | INIT | 3192 | | FCN!=0 & more frags 3193 +======++ ~~~~~~~~~~~~~~~~~~~~~~ 3194 Frag RuleID trigger | +--+ Send cur_W + frag(FCN); 3195 ~~~~~~~~~~~~~~~~~~~ | | | FCN--; 3196 cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp] 3197 clear [cur_W, Bmp_n];| | v 3198 clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND 3199 +->+ | cur_W==rcv_W & 3200 **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp 3201 +-------------------------->+ | & more frags 3202 | +----------------------->+ | ~~~~~~~~~~~~ 3203 | | ++===+=========+ cur_W++; 3204 | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] 3205 | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~ 3206 | | set cur_Bmp; | |set [cur_W, Bmp_n]; 3207 | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+RCS; 3208 | | set Retrans_Timer| |set Retrans_Timer 3209 | | | | +-----------------------------------+ 3210 | |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| 3211 | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ | 3212 | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W | 3213 | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &| 3214 | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp| 3215 | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| 3216 | +-------------------+ | | Resend | Attempts++;| 3217 +----------------------+ Wait x ACK | | Missing | W=Wn | 3218 +--------------------->+ | | Frags(W) +<-------------+ 3219 | rcv_W==Wn &+-+ | +======+====+ 3220 | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ | 3221 | ~~~~~~~~~~~~~~| ^ | | | ^ | 3222 | send (cur_W,+--+ | | | +-------------+ 3223 | ALL-0-empty) | | | all missing frag sent(W) 3224 | | | | ~~~~~~~~~~~~~~~~~ 3225 | Retrans_Timer expires &| | | set Retrans_Timer 3226 | No more Frags| | | 3227 | ~~~~~~~~~~~~~~| | | 3228 | stop Retrans_Timer;| | | 3229 |(re)send frag(All-1)+RCS | | | 3230 +-------------------------+ | | 3231 cur_W==rcv_W&| | 3232 [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS 3233 No more Frags & RCS flag==OK| | ~~~~~~~~~~ 3234 ~~~~~~~~~~~~~~~~~~| | send Abort 3235 +=========+stop Retrans_Timer| | +===========+ 3236 | END +<-----------------+ +->+ ERROR | 3237 +=========+ +===========+ 3239 Figure 41: Sender State Machine for the ACK-on-Error Mode 3241 This is an example only. It is not normative. The specification in 3242 Section 8.4.3.1 allows for sequences of operations different from the 3243 one shown here. 3245 +=======+ New frag RuleID received 3246 | | ~~~~~~~~~~~~~ 3247 | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); 3248 +=======+ |sync=0 3249 | 3250 Not All* & rcv_W==cur_W+---+ | +---+ 3251 ~~~~~~~~~~~~~~~~~~~~ | | | | (E) 3252 set[cur_W,Bmp_n(FCN)]| v v v | 3253 ++===+=+=+===+=+ 3254 +----------------------+ +--+ All-0&Full[cur_W,Bmp_n] 3255 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~ 3256 | +-------------------+ +<-+ cur_W++;set Inact_timer; 3257 | | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n] 3258 | | All-0 empty(Wn)| | | | ^ ^ 3259 | | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0; 3260 | | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n]) 3261 | | | | | |& All* || last_miss_frag 3262 | | | | | |~~~~~~~~~~~~~~~~~~~~~~ 3263 | | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); 3264 | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) 3265 | |&no_full([cur_W,Bmp_n])| |(E)| 3266 | | ~~~~~~~~~~~~~~~~ | | | | +========+ 3267 | | sendACK([cur_W,Bmp_n])| | | | | Error/ | 3268 | | | | | | +----+ | Abort | 3269 | | v v | | | | +===+====+ 3270 | | +===+=+=+=+===+=+ (D) ^ 3271 | | +--+ Wait x | | | 3272 | | All-0 empty(Wn)+->| Missing Frags |<-+ | 3273 | | ~~~~~~~~~~~~~~ +=============+=+ | 3274 | | sendACK([Wn,Bmp_n]) +--------------+ 3275 | | *ABORT 3276 v v 3277 (A)(B) 3278 (D) All* || last_miss_frag 3279 (C) All* & sync>0 & rcv_W!=cur_W & sync>0 3280 ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) 3281 Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ 3282 sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; 3283 sendACK([Wn,Bmp_n]);sync-- 3285 ABORT-->* Uplink Only & 3286 Inact_Timer expires 3287 (E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS 3288 ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ 3289 sync++; cur_W=rcv_W; send Abort 3290 set[cur_W,Bmp_n(FCN)] 3292 (A)(B) 3293 | | 3294 | | All-1 & rcv_W==cur_W & RCS!=OK All-0 empty(Wn) 3295 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~ 3296 | | sendACK([cur_W,Bmp_n],C=0) | v sendACK([Wn,Bmp_n]) 3297 | | +===========+=++ 3298 | +--------------------->+ Wait End +-+ 3299 | +=====+=+====+=+ | All-1 3300 | rcv_W==cur_W & RCS==OK | | ^ | & rcv_W==cur_W 3301 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & RCS!=OK 3302 | sendACK([cur_W,Bmp_n],C=1) | | ~~~~~~~~~~~~~~~~~~~ 3303 | | | sendACK([cur_W,Bmp_n],C=0); 3304 | | | Attempts++ 3305 |All-1 & Full([cur_W,Bmp_n]) | | 3306 |& RCS==OK & sync==0 | +-->* ABORT 3307 |~~~~~~~~~~~~~~~~~~~ v 3308 |sendACK([cur_W,Bmp_n],C=1) +=+=========+ 3309 +---------------------------->+ END | 3310 +===========+ 3312 Figure 42: Receiver State Machine for the ACK-on-Error Mode 3314 Appendix D. SCHC Parameters 3316 This section lists the information that needs to be provided in the 3317 LPWAN technology-specific documents. 3319 o Most common uses cases, deployment scenarios 3321 o Mapping of the SCHC architectural elements onto the LPWAN 3322 architecture 3324 o Assessment of LPWAN integrity checking 3326 o Various potential channel conditions for the technology and the 3327 corresponding recommended use of SCHC C/D and F/R 3329 This section lists the parameters that need to be defined in the 3330 Profile. 3332 o Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs, 3333 number of Rules, the way the Rule ID is transmitted 3335 o maximum packet size that should ever be reconstructed by SCHC 3336 Decompression (MAX_PACKET_SIZE). See Section 12. 3338 o Padding: size of the L2 Word (for most LPWAN technologies, this 3339 would be a byte; for some technologies, a bit) 3341 o Decision to use SCHC fragmentation mechanism or not. If yes: 3343 * reliability mode(s) used, in which cases (e.g. based on link 3344 channel condition) 3346 * Rule ID values assigned to each mode in use 3348 * presence and number of bits for DTag (T) for each Rule ID value 3350 * support for interleaved packet transmission, to what extent 3352 * WINDOW_SIZE, for modes that use windows 3354 * number of bits for W (M) for each Rule ID value, for modes that 3355 use windows 3357 * number of bits for FCN (N) for each Rule ID value 3359 * size of RCS and algorithm for its computation, for each Rule 3360 ID, if different from the default CRC32. Byte fill-up with 3361 zeroes or other mechanism, to be specified. 3363 * Retransmission Timer duration for each Rule ID value, if 3364 applicable to the SCHC F/R mode 3366 * Inactivity Timer duration for each Rule ID value, if applicable 3367 to the SCHC F/R mode 3369 * MAX_ACK_REQUEST value for each Rule ID value, if applicable to 3370 the SCHC F/R mode 3372 o if L2 Word is wider than a bit and SCHC fragmentation is used, 3373 value of the padding bits (0 or 1). This is needed because the 3374 padding bits of the last fragment are included in the RCS 3375 computation. 3377 A Profile may define a delay to be added after each SCHC message 3378 transmission for compliance with local regulations or other 3379 constraints imposed by the applications. 3381 o In some LPWAN technologies, as part of energy-saving techniques, 3382 downlink transmission is only possible immediately after an uplink 3383 transmission. In order to avoid potentially high delay in the 3384 downlink transmission of a fragmented SCHC Packet, the SCHC 3385 Fragment receiver may perform an uplink transmission as soon as 3386 possible after reception of a SCHC Fragment that is not the last 3387 one. Such uplink transmission may be triggered by the L2 (e.g. an 3388 L2 ACK sent in response to a SCHC Fragment encapsulated in a L2 3389 PDU that requires an L2 ACK) or it may be triggered from an upper 3390 layer. 3392 o the following parameters need to be addressed in documents other 3393 than this one but not necessarily in the LPWAN technology-specific 3394 documents: 3396 * The way the Contexts are provisioned 3398 * The way the Rules are generated 3400 Appendix E. Supporting multiple window sizes for fragmentation 3402 For ACK-Always or ACK-on-Error, implementers may opt to support a 3403 single window size or multiple window sizes. The latter, when 3404 feasible, may provide performance optimizations. For example, a 3405 large window size should be used for packets that need to be split 3406 into a large number of tiles. However, when the number of tiles 3407 required to carry a packet is low, a smaller window size, and thus a 3408 shorter Bitmap, may be sufficient to provide reception status on all 3409 tiles. If multiple window sizes are supported, the Rule ID may 3410 signal the window size in use for a specific packet transmission. 3412 The same window size MUST be used for the transmission of all tiles 3413 that belong to the same SCHC Packet. 3415 Appendix F. Downlink SCHC Fragment transmission 3417 For downlink transmission of a fragmented SCHC Packet in ACK-Always 3418 mode, the SCHC Fragment receiver may support timer-based SCHC ACK 3419 retransmission. In this mechanism, the SCHC Fragment receiver 3420 initializes and starts a timer (the Inactivity Timer is used) after 3421 the transmission of a SCHC ACK, except when the SCHC ACK is sent in 3422 response to the last SCHC Fragment of a packet (All-1 fragment). In 3423 the latter case, the SCHC Fragment receiver does not start a timer 3424 after transmission of the SCHC ACK. 3426 If, after transmission of a SCHC ACK that is not an All-1 fragment, 3427 and before expiration of the corresponding Inactivity timer, the SCHC 3428 Fragment receiver receives a SCHC Fragment that belongs to the 3429 current window (e.g. a missing SCHC Fragment from the current window) 3430 or to the next window, the Inactivity timer for the SCHC ACK is 3431 stopped. However, if the Inactivity timer expires, the SCHC ACK is 3432 resent and the Inactivity timer is reinitialized and restarted. 3434 The default initial value for the Inactivity Timer, as well as the 3435 maximum number of retries for a specific SCHC ACK, denoted 3436 MAX_ACK_RETRIES, are not defined in this document, and need to be 3437 defined in a Profile. The initial value of the Inactivity timer is 3438 expected to be greater than that of the Retransmission timer, in 3439 order to make sure that a (buffered) SCHC Fragment to be 3440 retransmitted can find an opportunity for that transmission. One 3441 exception to this recommendation is the special case of the All-1 3442 SCHC Fragment transmission. 3444 When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it 3445 starts its Retransmission Timer with a large timeout value (e.g. 3446 several times that of the initial Inactivity Timer). If a SCHC ACK 3447 is received before expiration of this timer, the SCHC Fragment sender 3448 retransmits any lost SCHC Fragments reported by the SCHC ACK, or if 3449 the SCHC ACK confirms successful reception of all SCHC Fragments of 3450 the last window, the transmission of the fragmented SCHC Packet is 3451 considered complete. If the timer expires, and no SCHC ACK has been 3452 received since the start of the timer, the SCHC Fragment sender 3453 assumes that the All-1 SCHC Fragment has been successfully received 3454 (and possibly, the last SCHC ACK has been lost: this mechanism 3455 assumes that the Retransmission Timer for the All-1 SCHC Fragment is 3456 long enough to allow several SCHC ACK retries if the All-1 SCHC 3457 Fragment has not been received by the SCHC Fragment receiver, and it 3458 also assumes that it is unlikely that several ACKs become all lost). 3460 Authors' Addresses 3462 Ana Minaburo 3463 Acklio 3464 1137A avenue des Champs Blancs 3465 35510 Cesson-Sevigne Cedex 3466 France 3468 Email: ana@ackl.io 3470 Laurent Toutain 3471 IMT-Atlantique 3472 2 rue de la Chataigneraie 3473 CS 17607 3474 35576 Cesson-Sevigne Cedex 3475 France 3477 Email: Laurent.Toutain@imt-atlantique.fr 3478 Carles Gomez 3479 Universitat Politecnica de Catalunya 3480 C/Esteve Terradas, 7 3481 08860 Castelldefels 3482 Spain 3484 Email: carlesgo@entel.upc.edu 3486 Dominique Barthel 3487 Orange Labs 3488 28 chemin du Vieux Chene 3489 38243 Meylan 3490 France 3492 Email: dominique.barthel@orange.com 3494 Juan Carlos Zuniga 3495 SIGFOX 3496 425 rue Jean Rostand 3497 Labege 31670 3498 France 3500 Email: JuanCarlos.Zuniga@sigfox.com