idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-20.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 22, 2019) is 1733 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 23, 2020 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 D. Barthel 9 Orange Labs 10 JC. Zuniga 11 SIGFOX 12 July 22, 2019 14 Static Context Header Compression (SCHC) and fragmentation for LPWAN, 15 application to UDP/IPv6 16 draft-ietf-lpwan-ipv6-static-context-hc-20 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 23, 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 . . . . . . . . . . . . . . . . . . . 17 93 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 17 94 7.5.1. processing fixed-length fields . . . . . . . . . . . 18 95 7.5.2. processing variable-length fields . . . . . . . . . . 18 96 7.5.3. not-sent CDA . . . . . . . . . . . . . . . . . . . . 19 97 7.5.4. value-sent CDA . . . . . . . . . . . . . . . . . . . 19 98 7.5.5. mapping-sent CDA . . . . . . . . . . . . . . . . . . 19 99 7.5.6. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 20 100 7.5.7. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 20 101 7.5.8. Compute-* . . . . . . . . . . . . . . . . . . . . . . 20 102 8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 21 103 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . 32 115 8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . 50 123 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 50 124 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 50 125 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 50 126 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 51 127 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 51 128 10.7.1. IPv6 source and destination prefixes . . . . . . . . 51 129 10.7.2. IPv6 source and destination IID . . . . . . . . . . 52 130 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 52 131 10.9. UDP source and destination port . . . . . . . . . . . . 52 132 10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 53 133 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 53 134 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 135 12. Security considerations . . . . . . . . . . . . . . . . . . . 54 136 12.1. Security considerations for SCHC 137 Compression/Decompression . . . . . . . . . . . . . . . 54 138 12.2. Security considerations for SCHC 139 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 55 140 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 141 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 142 14.1. Normative References . . . . . . . . . . . . . . . . . . 56 143 14.2. Informative References . . . . . . . . . . . . . . . . . 56 144 Appendix A. Compression Examples . . . . . . . . . . . . . . . . 57 145 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 60 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). 301 o IID: Interface Identifier. See the IPv6 addressing architecture 302 [RFC7136] 304 o L2: Layer two. The immediate lower layer SCHC interfaces with. 305 It is provided by an underlying LPWAN technology. It does not 306 necessarily correspond to the OSI model definition of Layer 2. 308 o L2 Word: this is the minimum subdivision of payload data that the 309 L2 will carry. In most L2 technologies, the L2 Word is an octet. 310 In bit-oriented radio technologies, the L2 Word might be a single 311 bit. The L2 Word size is assumed to be constant over time for 312 each device. 314 o MO: Matching Operator. An operator used to match a value 315 contained in a header field with a value contained in a Rule. 317 o Padding (P). Extra bits that may be appended by SCHC to a data 318 unit that it passes to the underlying Layer 2 for transmission. 319 SCHC itself operates on bits, not bytes, and does not have any 320 alignment prerequisite. See Section 9. 322 o Profile: SCHC offers variations in the way it is operated, with a 323 number of parameters listed in Appendix D. A Profile indicates a 324 particular setting of all these parameters. Both ends of a SCHC 325 communication must be provisioned with the same Profile 326 information and with the same set of Rules before the 327 communication starts, so that there is no ambiguity in how they 328 expect to communicate. 330 o Rule: A set of Field Descriptions. 332 o Rule ID (Rule Identifier): An identifier for a Rule. SCHC C/D on 333 both sides share the same Rule ID for a given packet. A set of 334 Rule IDs are used to support SCHC F/R functionality. 336 o SCHC C/D: SCHC Compressor/Decompressor. A mechanism used on both 337 sides, at the Dev and at the network, to achieve Compression/ 338 Decompression of headers. 340 o SCHC F/R: SCHC Fragmentation / Reassembly. A mechanism used on 341 both sides, at the Dev and at the network, to achieve 342 Fragmentation / Reassembly of SCHC Packets. 344 o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been 345 compressed as per the header compression mechanism defined in this 346 document. If the header compression process is unable to actually 347 compress the packet header, the packet with the uncompressed 348 header is still called a SCHC Packet (in this case, a Rule ID is 349 used to indicate that the packet header has not been compressed). 350 See Section 7 for more details. 352 o TV: Target value. A value contained in a Rule that will be 353 matched with the value of a header field. 355 o Up: Uplink direction for compression/decompression, from the Dev 356 SCHC C/D to the network SCHC C/D. 358 Additional terminology for the optional SCHC Fragmentation / 359 Reassembly mechanism (SCHC F/R) is found in Section 8.2. 361 5. SCHC overview 363 SCHC can be characterized as an adaptation layer between IPv6 and the 364 underlying LPWAN technology. SCHC comprises two sublayers (i.e. the 365 Compression sublayer and the Fragmentation sublayer), as shown in 366 Figure 2. 368 +----------------+ 369 | IPv6 | 370 +- +----------------+ 371 | | Compression | 372 SCHC < +----------------+ 373 | | Fragmentation | 374 +- +----------------+ 375 |LPWAN technology| 376 +----------------+ 378 Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN 379 technology 381 Before a packet (e.g. an IPv6 packet) is transmitted, header 382 compression is first applied. The resulting packet is called a SCHC 383 Packet, whether or not any compression is performed. If the SCHC 384 Packet is to be fragmented, the optional SCHC Fragmentation MAY be 385 applied to the SCHC Packet. The inverse operations take place at the 386 receiver. This process is illustrated in Figure 3. 388 A packet (e.g. an IPv6 packet) 389 | ^ 390 v | 391 +------------------+ +--------------------+ 392 | SCHC Compression | | SCHC Decompression | 393 +------------------+ +--------------------+ 394 | ^ 395 | If no fragmentation (*) | 396 +-------------- SCHC Packet -------------->| 397 | | 398 v | 399 +--------------------+ +-----------------+ 400 | SCHC Fragmentation | | SCHC Reassembly | 401 +--------------------+ +-----------------+ 402 | ^ | ^ 403 | | | | 404 | +-------------- SCHC ACK -------------+ | 405 | | 406 +-------------- SCHC Fragments -------------------+ 408 Sender Receiver 410 *: the decision to use Fragmentation or not is left to each Profile. 412 Figure 3: SCHC operations at the SENDER and the RECEIVER 414 5.1. SCHC Packet format 416 The SCHC Packet is composed of the Compressed Header followed by the 417 payload from the original packet (see Figure 4). The Compressed 418 Header itself is composed of the Rule ID and a Compression Residue, 419 which is the output of compressing the packet header with that Rule 420 (see Section 7). The Compression Residue may be empty. Both the 421 Rule ID and the Compression Residue potentially have a variable size, 422 and are not necessarily a multiple of bytes in size. 424 |------- Compressed Header -------| 425 +---------------------------------+--------------------+ 426 | Rule ID | Compression Residue | Payload | 427 +---------------------------------+--------------------+ 429 Figure 4: SCHC Packet 431 5.2. Functional mapping 433 Figure 5 below maps the functional elements of Figure 3 onto the 434 LPWAN architecture elements of Figure 1. 436 Dev App 437 +----------------+ +----+ +----+ +----+ 438 | App1 App2 App3 | |App1| |App2| |App3| 439 | | | | | | | | 440 | UDP | |UDP | |UDP | |UDP | 441 | IPv6 | |IPv6| |IPv6| |IPv6| 442 | | | | | | | | 443 |SCHC C/D and F/R| | | | | | | 444 +--------+-------+ +----+ +----+ +----+ 445 | +---+ +---+ +----+ +----+ . . . 446 +~ |RGW| === |NGW| == |SCHC| == |SCHC|...... Internet .... 447 +---+ +---+ |F/R | |C/D | 448 +----+ +----+ 450 Figure 5: Architecture 452 SCHC C/D and SCHC F/R are located on both sides of the LPWAN 453 transmission, i.e. on the Dev side and on the Network side. 455 The operation in the Uplink direction is as follows. The Device 456 application uses IPv6 or IPv6/UDP protocols. Before sending the 457 packets, the Dev compresses their headers using SCHC C/D and, if the 458 SCHC Packet resulting from the compression needs to be fragmented by 459 SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC 460 Fragments are sent to an LPWAN Radio Gateway (RGW) which forwards 461 them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/ 462 R for re-assembly (if needed) and then to the SCHC C/D for 463 decompression. After decompression, the packet can be sent over the 464 Internet to one or several LPWAN Application Servers (App). 466 The SCHC F/R and C/D on the Network side can be located in the NGW, 467 or somewhere else as long as a tunnel is established between them and 468 the NGW. For some LPWAN technologies, it may be suitable to locate 469 the SCHC F/R functionality nearer the NGW, in order to better deal 470 with time constraints of such technologies. 472 The SCHC C/Ds on both sides MUST share the same set of Rules. So 473 MUST the SCHC F/Rs on both sides. 475 The operation in the Downlink direction is similar to that in the 476 Uplink direction, only reverting the order in which the architecture 477 elements are traversed. 479 6. Rule ID 481 Rule IDs identify the Rules used for Compression/Decompression or for 482 Fragmentation/Reassembly. 484 The scope of a Rule ID is the link between the SCHC Compressor and 485 the SCHC Decompressor, or between the SCHC Fragmenter and the SCHC 486 Reassembler. 488 The size of the Rule IDs is not specified in this document, as it is 489 implementation-specific and can vary according to the LPWAN 490 technology and the number of Rules, among others. It is defined in 491 Profiles. 493 The Rule IDs are used: 495 o For SCHC C/D, to identify the Rule (i.e., the set of Field 496 Descriptions) that is used to compress a packet header. 498 * At least one Rule ID MUST be allocated to tagging packets for 499 which SCHC compression was not possible (no matching Rule was 500 found). 502 o In SCHC F/R, to identify the specific mode and settings of F/R for 503 one direction of traffic (Up or Dw). 505 * When F/R is used for both communication directions, at least 506 two Rule ID values are needed for F/R, one per direction of 507 traffic. 509 7. Compression/Decompression 511 Compression with SCHC is based on using a set of Rules, called the 512 Context, to compress or decompress headers. SCHC avoids Context 513 synchronization traffic, which consumes considerable bandwidth in 514 other header compression mechanisms such as RoHC [RFC5795]. Since 515 the content of packets is highly predictable in LPWAN networks, 516 static Contexts may be stored beforehand. The Contexts MUST be 517 stored at both ends, and they can be learned by a provisioning 518 protocol or by out of band means, or they can be pre-provisioned. 519 The way the Contexts are provisioned is out of the scope of this 520 document. 522 7.1. SCHC C/D Rules 524 The main idea of the SCHC compression scheme is to transmit the Rule 525 ID to the other end instead of sending known field values. This Rule 526 ID identifies a Rule that matches the original packet values. Hence, 527 when a value is known by both ends, it is only necessary to send the 528 corresponding Rule ID over the LPWAN network. The manner by which 529 Rules are generated is out of the scope of this document. The Rules 530 MAY be changed at run-time but the mechanism is out of scope of this 531 document. 533 The Context is a set of Rules. See Figure 6 for a high level, 534 abstract representation of the Context. The formal specification of 535 the representation of the Rules is outside the scope of this 536 document. 538 Each Rule itself contains a list of Field Descriptions composed of a 539 Field Identifier (FID), a Field Length (FL), a Field Position (FP), a 540 Direction Indicator (DI), a Target Value (TV), a Matching Operator 541 (MO) and a Compression/Decompression Action (CDA). 543 /-----------------------------------------------------------------\ 544 | Rule N | 545 /-----------------------------------------------------------------\| 546 | Rule i || 547 /-----------------------------------------------------------------\|| 548 | (FID) Rule 1 ||| 549 |+-------+--+--+--+------------+-----------------+---------------+||| 550 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 551 |+-------+--+--+--+------------+-----------------+---------------+||| 552 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 553 |+-------+--+--+--+------------+-----------------+---------------+||| 554 ||... |..|..|..| ... | ... | ... |||| 555 |+-------+--+--+--+------------+-----------------+---------------+||/ 556 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 557 |+-------+--+--+--+------------+-----------------+---------------+|/ 558 | | 559 \-----------------------------------------------------------------/ 561 Figure 6: A Compression/Decompression Context 563 A Rule does not describe how the compressor parses a packet header to 564 find and identify each field (e.g. the IPv6 Source Address, the UDP 565 Destination Port or a CoAP URI path option). It is assumed that 566 there is a protocol parser alongside SCHC that is able to identify 567 all the fields encountered in the headers to be compressed, and to 568 label them with a Field ID. Rules only describe the compression/ 569 decompression behavior for each header field, after it has been 570 identified. 572 In a Rule, the Field Descriptions are listed in the order in which 573 the fields appear in the packet header. The Field Descriptions 574 describe the header fields with the following entries: 576 o Field ID (FID) designates a protocol and field (e.g. UDP 577 Destination Port), unambiguously among all protocols that a SCHC 578 compressor processes. In the presence of protocol nesting, the 579 Field ID also identifies the nesting. 581 o Field Length (FL) represents the length of the field. It can be 582 either a fixed value (in bits) if the length is known when the 583 Rule is created or a type if the length is variable. The length 584 of a header field is defined by its own protocol specification 585 (e.g. IPv6 or UDP). If the length is variable, the type defines 586 the process to compute the length and its unit (bits, bytes...). 588 o Field Position (FP): most often, a field only occurs once in a 589 packet header. However, some fields may occur multiple times. An 590 example is the uri-path of CoAP. FP indicates which occurrence 591 this Field Description applies to. If FP is not specified in the 592 Field Description, it takes the default value of 1. The value 1 593 designates the first occurence. The value 0 is special. It means 594 "don't care", see Section 7.3. 596 o A Direction Indicator (DI) indicates the packet direction(s) this 597 Field Description applies to. Three values are possible: 599 * UPLINK (Up): this Field Description is only applicable to 600 packets sent by the Dev to the App, 602 * DOWNLINK (Dw): this Field Description is only applicable to 603 packets sent from the App to the Dev, 605 * BIDIRECTIONAL (Bi): this Field Description is applicable to 606 packets traveling both Up and Dw. 608 o Target Value (TV) is the value used to match against the packet 609 header field. The Target Value can be a scalar value of any type 610 (integer, strings, etc.) or a more complex structure (array, list, 611 etc.). The types and representations are out of scope for this 612 document. 614 o Matching Operator (MO) is the operator used to match the Field 615 Value and the Target Value. The Matching Operator may require 616 some parameters. MO is only used during the compression phase. 617 The set of MOs defined in this document can be found in 618 Section 7.4. 620 o Compression Decompression Action (CDA) describes the compression 621 and decompression processes to be performed after the MO is 622 applied. Some CDAs might use parameter values for their 623 operation. CDAs are used in both the compression and the 624 decompression functions. The set of CDAs defined in this document 625 can be found in Section 7.5. 627 7.2. Rule ID for SCHC C/D 629 Rule IDs are sent by the compression function in one side and are 630 received for the decompression function in the other side. In SCHC 631 C/D, the Rule IDs are specific to the Context related to one Dev. 632 Hence, multiple Dev instances, which refer to different header 633 compression Contexts, MAY reuse the same Rule ID for different Rules. 634 On the network side, in order to identify the correct Rule to be 635 applied, the SCHC Decompressor needs to associate the Rule ID with 636 the Dev identifier. Similarly, the SCHC Compressor on the network 637 side first identifies the destination Dev before looking for the 638 appropriate compression Rule (and associated Rule ID) in the Context 639 of that Dev. 641 7.3. Packet processing 643 The compression/decompression process follows several steps: 645 o Compression Rule selection: the set of Rules is browsed to 646 identify which Rule will be used to compress the packet header. 647 The Rule is selected by matching the Fields Descriptions to the 648 packet header. The detailed steps are the following: 650 * The first step is to check the Field Identifiers (FID). If any 651 header field of the packet being examined cannot be matched 652 with a Field Description with the correct FID, the Rule MUST be 653 disregarded. If any Field Description in the Rule has a FID 654 that cannot be matched to one of the header fields of the 655 packet being examined, the Rule MUST be disregarded. 657 * The next step is to match the Field Descriptions by their 658 direction, using the Direction Indicator (DI). If any field of 659 the packet header cannot be matched with a Field Description 660 with the correct FID and DI, the Rule MUST be disregarded. 662 * Then the Field Descriptions are further selected according to 663 Field Position (FP). If any field of the packet header cannot 664 be matched with a Field Description with the correct FID, DI 665 and FP, the Rule MUST be disregarded. 667 The value 0 for FP means "don't care", i.e. the comparison of 668 this Field Description's FP with the position of the field of 669 the packet header being compressed returns True, whatever that 670 position. FP=0 can be useful to build compression Rules for 671 protocols headers in which some fields order is irrelevant. An 672 example could be uri-queries in CoAP. Care needs to be 673 exercised when writing Rules containing FP=0 values. Inded, it 674 may result in decompressed packets having fields ordered 675 differently compared to the original packet. 677 * Once each header field has been associated with a Field 678 Description with matching FID, DI and FP, each packet field's 679 value is then compared to the corresponding Target Value (TV) 680 stored in the Rule for that specific field, using the matching 681 operator (MO). If every field in the packet header satisfies 682 the corresponding matching operators (MO) of a Rule (i.e. all 683 MO results are True), that Rule is used for compressing the 684 header. Otherwise, the Rule MUST be disregarded. 686 * If no eligible compression Rule is found, then the header MUST 687 be sent in its entirety using the Rule ID of the "default" Rule 688 dedicated to this purpose. Sending an uncompressed header may 689 require SCHC F/R. 691 o Compression: each field of the header is compressed according to 692 the Compression/Decompression Actions (CDAs). The fields are 693 compressed in the order that the Field Descriptions appear in the 694 Rule. The compression of each field results in a residue, which 695 may be empty. The Compression Residue for the packet header is 696 the concatenation of the non-empty residues for each field of the 697 header, in the order the Field Descriptions appear in the Rule. 699 |------------------- Compression Residue -------------------| 700 +-----------------+-----------------+-----+-----------------+ 701 | field 1 residue | field 2 residue | ... | field N residue | 702 +-----------------+-----------------+-----+-----------------+ 704 Figure 7: Compression Residue structure 706 o Sending: The Rule ID is sent to the other end followed by the 707 Compression Residue (which could be empty) or the uncompressed 708 header, and directly followed by the payload (see Figure 4). The 709 way the Rule ID is sent will be specified in the Profile and is 710 out of the scope of the present document. For example, it could 711 be included in an L2 header or sent as part of the L2 payload. 713 o Decompression: when decompressing, on the network side the SCHC C/ 714 D needs to find the correct Rule based on the L2 address; in this 715 way, it can use the DevIID and the Rule ID. On the Dev side, only 716 the Rule ID is needed to identify the correct Rule since the Dev 717 typically only holds Rules that apply to itself. 719 The receiver identifies the sender through its device-id or source 720 identifier (e.g. MAC address, if it exists) and selects the Rule 721 using the Rule ID. This Rule describes the compressed header 722 format and associates the received residues to each of the header 723 fields. For each field in the header, the receiver applies the 724 CDA action associated to that field in order to reconstruct the 725 original header field value. The CDA application order can be 726 different from the order in which the fields are listed in the 727 Rule. In particular, Compute-* MUST be applied after the 728 application of the CDAs of all the fields it computes on. 730 7.4. Matching operators 732 Matching Operators (MOs) are functions used by both SCHC C/D 733 endpoints. They are not typed and can be applied to integer, string 734 or any other data type. The result of the operation can either be 735 True or False. MOs are defined as follows: 737 o equal: The match result is True if the field value in the packet 738 matches the TV. 740 o ignore: No matching is attempted between the field value in the 741 packet and the TV in the Rule. The result is always true. 743 o MSB(x): A match is obtained if the most significant x bits of the 744 packet header field value are equal to the TV in the Rule. The x 745 parameter of the MSB MO indicates how many bits are involved in 746 the comparison. If the FL is described as variable, the length 747 must be a multiple of the unit. For example, x must be multiple 748 of 8 if the unit of the variable length is in bytes. 750 o match-mapping: With match-mapping, the Target Value is a list of 751 values. Each value of the list is identified by an index. 752 Compression is achieved by sending the index instead of the 753 original header field value. This operator matches if the header 754 field value is equal to one of the values in the target list. 756 7.5. Compression Decompression Actions (CDA) 758 The Compression Decompression Action (CDA) describes the actions 759 taken during the compression of header fields and the inverse action 760 taken by the decompressor to restore the original value. 762 +--------------+-------------+-------------------------------+ 763 | Action | Compression | Decompression | 764 +--------------+-------------+-------------------------------+ 765 | | | | 766 | not-sent | elided | use TV stored in Rule | 767 | value-sent | send | use received value | 768 | mapping-sent | send index | retrieve value from TV list | 769 | LSB | send LSB | concat. TV and received value | 770 | compute-* | elided | recompute at decompressor | 771 | DevIID | elided | build IID from L2 Dev addr | 772 | AppIID | elided | build IID from L2 App addr | 773 +--------------+-------------+-------------------------------+ 775 Table 1: Compression and Decompression Actions 777 Table 1 summarizes the basic actions that can be used to compress and 778 decompress a field. The first column shows the action's name. The 779 second and third columns show the compression and decompression 780 behaviors for each action. 782 7.5.1. processing fixed-length fields 784 If the field is identified in the Field Description as being of fixed 785 length, then aplying the CDA to compress this field results in a 786 fixed amount of bits. The residue for that field is simply the bits 787 resulting from applying the CDA to the field. This value may be 788 empty (e.g. not-sent CDA), in which case the field residue is absent 789 from the Compression Residue. 791 |- field residue -| 792 +-----------------+ 793 | value | 794 +-----------------+ 796 Figure 8: fixed sized field residue structure 798 7.5.2. processing variable-length fields 800 If the field is identified in the Field Description as being of 801 variable length, then aplying the CDA to compress this field may 802 result in a value of fixed size (e.g. not-sent or mapping-sent) or of 803 variable size (e.g. value-sent or LSB). In the latter case, the 804 residue for that field is the bits that result from applying the CDA 805 to the field, preceded with the size of the value. The most 806 significant bit of the size is stored first (left of the residue bit 807 field). 809 |--- field residue ---| 810 +-------+-------------+ 811 | size | value | 812 +-------+-------------+ 814 Figure 9: variable sized field residue structure 816 The size (using the unit defined in the FL) is encoded on 4, 12 or 28 817 bits as follows: 819 o If the size is between 0 and 14, it is encoded as a 4 bits 820 unsigned integer. 822 o Sizes between 15 and 254 are encoded as 0b1111 followed by the 8 823 bits unsigned integer. 825 o Larger sizes are encoded as 0xfff followed by the 16 bits unsigned 826 integer. 828 If the field is identified in the Field Description as being of 829 variable length and this field is not present in the packet header 830 being compressed, size 0 MUST be sent to denote its absence. 832 7.5.3. not-sent CDA 834 The not-sent action can be used when the field value is specified in 835 a Rule and therefore known by both the Compressor and the 836 Decompressor. This action SHOULD be used with the "equal" MO. If MO 837 is "ignore", there is a risk to have a decompressed field value 838 different from the original field that was compressed. 840 The compressor does not send any residue for a field on which not- 841 sent compression is applied. 843 The decompressor restores the field value with the Target Value 844 stored in the matched Rule identified by the received Rule ID. 846 7.5.4. value-sent CDA 848 The value-sent action can be used when the field value is not known 849 by both the Compressor and the Decompressor. The value is sent in 850 its entirety. 852 If this action is performed on a variable length field, the size of 853 the residue value (using the units defined in FL) MUST be sent as 854 described in Section 7.5.2. 856 This action is generally used with the "ignore" MO. 858 7.5.5. mapping-sent CDA 860 The mapping-sent action is used to send an index (the index into the 861 Target Value list of values) instead of the original value. This 862 action is used together with the "match-mapping" MO. 864 On the compressor side, the match-mapping Matching Operator searches 865 the TV for a match with the header field value. The mapping-sent CDA 866 then sends the corresponding index as the field residue. The most 867 significant bit of the index is stored first (left of the residue bit 868 field). 870 On the decompressor side, the CDA uses the received index to restore 871 the field value by looking up the list in the TV. 873 The number of bits sent is the minimal size for coding all the 874 possible indices. 876 7.5.6. LSB CDA 878 The LSB action is used together with the "MSB(x)" MO to avoid sending 879 the most significant part of the packet field if that part is already 880 known by the receiving end. 882 The compressor sends the Least Significant Bits as the field residue 883 value. The number of bits sent is the original header field length 884 minus the length specified in the MSB(x) MO. 886 The decompressor concatenates the x most significant bits of Target 887 Value and the received residue value. 889 If this action is performed on a variable length field, the size of 890 the residue value (using the units defined in FL) MUST be sent as 891 described in Section 7.5.2. 893 7.5.7. DevIID, AppIID CDA 895 These actions are used to process respectively the Dev and the App 896 Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. 897 AppIID CDA is less common since most current LPWAN technologies 898 frames contain a single L2 address, which is the Dev's address. 900 The IID value MAY be computed from the Device ID present in the L2 901 header, or from some other stable identifier. The computation is 902 specific to each Profile and MAY depend on the Device ID size. 904 In the downlink direction (Dw), at the compressor, the DevIID CDA may 905 be used to generate the L2 addresses on the LPWAN, based on the 906 packet's Destination Address. 908 7.5.8. Compute-* 910 Some fields can be elided at the compressor and recomputed locally at 911 the decompressor. 913 Because the field is uniquely identified by its Field ID (e.g. UDP 914 length), the relevant protocol specification unambiguously defines 915 the algorithm for such computation. 917 Examples of fields that know how to recompute themselves are UDP 918 length, IPv6 length and UDP checksum. 920 8. Fragmentation/Reassembly 922 8.1. Overview 924 In LPWAN technologies, the L2 MTU typically ranges from tens to 925 hundreds of bytes. Some of these technologies do not have an 926 internal fragmentation/reassembly mechanism. 928 The optional SCHC Fragmentation/Reassembly (SCHC F/R) functionality 929 enables such LPWAN technologies to comply with the IPv6 MTU 930 requirement of 1280 bytes [RFC8200]. It is optional to implement. 931 If it is not needed, its description can be safely ignored. 933 This specification includes several SCHC F/R modes, which allow for a 934 range of reliability options such as optional SCHC Fragment 935 retransmission. More modes may be defined in the future. 937 The same SCHC F/R mode MUST be used for all SCHC Fragments of a SCHC 938 Packet. This document does not specify which mode(s) are to be used 939 over a specific LPWAN technology. That information will be given in 940 Profiles. 942 The L2 Word size (see Section 4) determines the encoding of some 943 messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs 944 that are multiples of L2 Words. 946 8.2. SCHC F/R Protocol Elements 948 This subsection describes the different elements that are used to 949 enable the SCHC F/R functionality defined in this document. These 950 elements include the SCHC F/R messages, tiles, windows, bitmaps, 951 counters, timers and header fields. 953 The elements are described here in a generic manner. Their 954 application to each SCHC F/R mode is found in Section 8.4. 956 8.2.1. Messages 958 SCHC F/R defines the following messages: 960 o SCHC Fragment: A message that carries part of a SCHC Packet from 961 the sender to the receiver. 963 o SCHC ACK: An acknowledgement for fragmentation, by the receiver to 964 the sender. This message is used to indicate whether or not the 965 reception of pieces of, or the whole of the fragmented SCHC 966 Packet, was successful. 968 o SCHC ACK REQ: A request by the sender for a SCHC ACK from the 969 receiver. 971 o SCHC Sender-Abort: A message by the sender telling the receiver 972 that it has aborted the transmission of a fragmented SCHC Packet. 974 o SCHC Receiver-Abort: A message by the receiver to tell the sender 975 to abort the transmission of a fragmented SCHC Packet. 977 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 979 8.2.2.1. Tiles 981 The SCHC Packet is fragmented into pieces, hereafter called tiles. 982 The tiles MUST be non-empty and pairwise disjoint. Their union MUST 983 be equal to the SCHC Packet. 985 See Figure 10 for an example. 987 SCHC Packet 988 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 989 Tiles | | | | | | | | | | | | | | 990 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 992 Figure 10: a SCHC Packet fragmented in tiles 994 Each SCHC Fragment message carries at least one tile in its Payload, 995 if the Payload field is present. 997 8.2.2.2. Windows 999 Some SCHC F/R modes may handle successive tiles in groups, called 1000 windows. 1002 If windows are used 1004 o all the windows of a SCHC Packet, except the last one, MUST 1005 contain the same number of tiles. This number is WINDOW_SIZE. 1007 o WINDOW_SIZE MUST be specified in a Profile. 1009 o the windows are numbered. 1011 o their numbers MUST increase from 0 upward, from the start of the 1012 SCHC Packet to its end. 1014 o the last window MUST contain WINDOW_SIZE tiles or less. 1016 o tiles are numbered within each window. 1018 o the tile indices MUST decrement from WINDOW_SIZE - 1 downward, 1019 looking from the start of the SCHC Packet toward its end. 1021 o each tile of a SCHC Packet is therefore uniquely identified by a 1022 window number and a tile index within this window. 1024 See Figure 11 for an example. 1026 +---------------------------------------------...-------------+ 1027 | SCHC Packet | 1028 +---------------------------------------------...-------------+ 1030 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 | 1031 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -| 1033 Figure 11: a SCHC Packet fragmented in tiles grouped in 28 windows, 1034 with WINDOW_SIZE = 5 1036 When windows are used 1038 o Bitmaps (see Section 8.2.2.3) MAY be sent back by the receiver to 1039 the sender in a SCHC ACK message. 1041 o A Bitmap corresponds to exactly one Window. 1043 8.2.2.3. Bitmaps 1045 Each bit in the Bitmap for a window corresponds to a tile in the 1046 window. Each Bitmap has therefore WINDOW_SIZE bits. The bit at the 1047 left-most position corresponds to the tile numbered WINDOW_SIZE - 1. 1048 Consecutive bits, going right, correspond to sequentially decreasing 1049 tile indices. In Bitmaps for windows that are not the last one of a 1050 SCHC Packet, the bit at the right-most position corresponds to the 1051 tile numbered 0. In the Bitmap for the last window, the bit at the 1052 right-most position corresponds either to the tile numbered 0 or to a 1053 tile that is sent/received as "the last one of the SCHC Packet" 1054 without explicitly stating its number (see Section 8.3.1.2). 1056 At the receiver 1057 o a bit set to 1 in the Bitmap indicates that a tile associated with 1058 that bit position has been correctly received for that window. 1060 o a bit set to 0 in the Bitmap indicates that no tile associated 1061 with that bit position has been correctly received for that 1062 window. 1064 8.2.2.4. Timers and counters 1066 Some SCHC F/R modes can use the following timers and counters 1068 o Inactivity Timer: a SCHC Fragment receiver uses this timer to 1069 abort waiting for a SCHC F/R message. 1071 o Retransmission Timer: a SCHC Fragment sender uses this timer to 1072 abort waiting for an expected SCHC ACK. 1074 o Attempts: this counter counts the requests for SCHC ACKs, up to 1075 MAX_ACK_REQUESTS. 1077 8.2.3. Integrity Checking 1079 The integrity of the fragmentation-reassembly process of a SCHC 1080 Packet MUST be checked at the receive end. By default, integrity 1081 checking is performed by computing a Reassembly Check Sequence (RCS) 1082 of the SCHC Packet at the sender side before fragmentation and 1083 transmitting it to the receiver for comparison with the RCS locally 1084 computed after reassembly. 1086 The RCS supports UDP checksum elision by SCHC C/D (see 1087 Section 10.11). 1089 The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of 1090 the polynomial used e.g. in the Ethernet standard [RFC3385]) is 1091 RECOMMENDED as the default algorithm for computing the RCS. 1092 Nevertheless, other RCS lengths or other algorithms MAY be required 1093 by the Profile. 1095 The RCS MUST be computed on the full SCHC Packet concatenated with 1096 the padding bits, if any, of the SCHC Fragment carrying the last 1097 tile. The rationale is that the SCHC reassembler has no way of 1098 knowing the boundary between the last tile and the padding bits. 1099 Indeed, this requires decompressing the SCHC Packet, which is out of 1100 the scope of the SCHC reassembler. 1102 Note that the concatenation of the complete SCHC Packet and the 1103 potential padding bits of the last SCHC Fragment does not generally 1104 constitute an integer number of bytes. For implementers to be able 1105 to use byte-oriented CRC libraries, it is RECOMMENDED that the 1106 concatenation of the complete SCHC Packet and the last fragment 1107 potential padding bits be zero-extended to the next byte boundary and 1108 that the RCS be computed on that byte array. A Profile MAY specify 1109 another behavior. 1111 8.2.4. Header Fields 1113 The SCHC F/R messages contain the following fields (see the formats 1114 in Section 8.3): 1116 o Rule ID: this field is present in all the SCHC F/R messages. It 1117 is used to identify 1119 * that a SCHC F/R message is being carried, as opposed to an 1120 unfragmented SCHC Packet, 1122 * which SCHC F/R mode is used 1124 * and for this mode 1126 + if windows are used and what the value of WINDOW_SIZE is, 1128 + what other optional fields are present and what the field 1129 sizes are. 1131 The Rule ID allows SCHC F/R interleaving non-fragmented SCHC 1132 Packets and SCHC Fragments that carry other SCHC Packets, or 1133 interleaving SCHC Fragments that use different SCHC F/R modes or 1134 different parameters. 1136 o Datagram Tag (DTag). Its size (called T, in bits) is defined by 1137 each Profile for each Rule ID. When T is 0, the DTag field does 1138 not appear in the SCHC F/R messages and the DTag value is defined 1139 as 0. 1141 When T is 0, there can be only one fragmented SCHC Packet in 1142 transit for a given Rule ID. 1144 If T is not 0, DTag 1146 * MUST be set to the same value for all the SCHC F/R messages 1147 related to the same fragmented SCHC Packet, 1149 * MUST be set to different values for SCHC F/R messages related 1150 to different SCHC Packets that are being fragmented under the 1151 same Rule ID and the transmission of which may overlap. 1153 A sequence counter that is incremented for each new fragmented 1154 SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to 1155 0 is RECOMMENDED for maximum traceability and avoidance of 1156 ambiguity. 1158 A flow of SCHC F/R messages with a given Rule ID and DTag value 1159 pair MUST NOT interfere with the operation of a SCHC F/R instance 1160 that uses another Rule ID and DTag value pair. 1162 o W: The W field is optional. It is only present if windows are 1163 used. Its presence and size (called M, in bits) is defined by 1164 each SCHC F/R mode and each Profile for each Rule ID. 1166 This field carries information pertaining to the window a SCHC F/R 1167 message relates to. If present, W MUST carry the same value for 1168 all the SCHC F/R messages related to the same window. Depending 1169 on the mode and Profile, W may carry the full window number, or 1170 just the least significant bit or any other partial representation 1171 of the window number. 1173 o Fragment Compressed Number (FCN). The FCN field is present in the 1174 SCHC Fragment Header. Its size (called N, in bits) is defined by 1175 each Profile for each Rule ID. 1177 This field conveys information about the progress in the sequence 1178 of tiles being transmitted by SCHC Fragment messages. For 1179 example, it can contain a partial, efficient representation of a 1180 larger-sized tile index. The description of the exact use of the 1181 FCN field is left to each SCHC F/R mode. However, two values are 1182 reserved for special purposes. They help control the SCHC F/R 1183 process: 1185 * The FCN value with all the bits equal to 1 (called All-1) 1186 signals the very last tile of a SCHC Packet. By extension, if 1187 windows are used, the last window of a packet is called the 1188 All-1 window. 1190 * If windows are used, the FCN value with all the bits equal to 0 1191 (called All-0) signals the last tile of a window that is not 1192 the last one of the SCHC packet. By extension, such a window 1193 is called an All-0 window. 1195 o Reassembly Check Sequence (RCS). This field only appears in the 1196 All-1 SCHC Fragments. Its size (called U, in bits) is defined by 1197 each Profile for each Rule ID. 1199 See Section 8.2.3 for the RCS default size, default polynomial and 1200 details on RCS computation. 1202 o C (integrity Check): C is a 1-bit field. This field is used in 1203 the SCHC ACK message to report on the reassembled SCHC Packet 1204 integrity check (see Section 8.2.3). 1206 A value of 1 tells that the integrity check was performed and is 1207 successful. A value of 0 tells that the integrity check was not 1208 performed, or that is was a failure. 1210 o Compressed Bitmap. The Compressed Bitmap is used together with 1211 windows and Bitmaps (see Section 8.2.2.3). Its presence and size 1212 is defined for each F/R mode for each Rule ID. 1214 This field appears in the SCHC ACK message to report on the 1215 receiver Bitmap (see Section 8.3.2.1). 1217 8.3. SCHC F/R Message Formats 1219 This section defines the SCHC Fragment formats, the SCHC ACK format, 1220 the SCHC ACK REQ format and the SCHC Abort formats. 1222 8.3.1. SCHC Fragment format 1224 A SCHC Fragment conforms to the general format shown in Figure 12. 1225 It comprises a SCHC Fragment Header and a SCHC Fragment Payload. The 1226 SCHC Fragment Payload carries one or several tile(s). 1228 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1229 | Fragment Header | Fragment Payload | padding (as needed) 1230 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1232 Figure 12: SCHC Fragment general format 1234 8.3.1.1. Regular SCHC Fragment 1236 The Regular SCHC Fragment format is shown in Figure 13. Regular SCHC 1237 Fragments are generally used to carry tiles that are not the last one 1238 of a SCHC Packet. The DTag field and the W field are optional. 1240 |--- SCHC Fragment Header ----| 1241 |-- T --|-M-|-- N --| 1242 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1243 | Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed) 1244 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1246 Figure 13: Detailed Header Format for Regular SCHC Fragments 1248 The FCN field MUST NOT contain all bits set to 1. 1250 The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called 1251 an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC 1252 ACK REQ message (see Section 8.3.3) that has the same T, M and N 1253 values, even in the presence of padding. This condition is met if 1254 the Payload is at least the size of an L2 Word. This condition is 1255 also met if the SCHC Fragment Header is a multiple of L2 Words. 1257 8.3.1.2. All-1 SCHC Fragment 1259 The All-1 SCHC Fragment format is shown in Figure 14. The sender 1260 generally uses the All-1 SCHC Fragment format for the message that 1261 completes the emission of a fragmented SCHC Packet. The DTag field, 1262 the W field, the RCS field and the Payload are optional. At least 1263 one of RCS field or Payload MUST be present. The FCN field is all 1264 ones. 1266 |-------- SCHC Fragment Header -------| 1267 |-- T --|-M-|-- N --|-- U --| 1268 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1269 | Rule ID | DTag | W | 11..1 | RCS | Frag Payload | pad. (as needed) 1270 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1271 (FCN) 1273 Figure 14: Detailed Header Format for the All-1 SCHC Fragment 1275 The All-1 SCHC Fragment message MUST be distinguishable by size from 1276 a SCHC Sender-Abort message (see Section 8.3.4) that has the same T, 1277 M and N values, even in the presence of padding. This condition is 1278 met if the RCS is present and is at least the size of an L2 Word, or 1279 if the Payload is present and at least the size an L2 Word. This 1280 condition is also met if the SCHC Sender-Abort Header is a multiple 1281 of L2 Words. 1283 8.3.2. SCHC ACK format 1285 The SCHC ACK message is shown in Figure 15. The DTag field, the W 1286 field and the Compressed Bitmap field are optional. The Compressed 1287 Bitmap field can only be present in SCHC F/R modes that use windows. 1289 |---- SCHC ACK Header ----| 1290 |-- T --|-M-| 1 | 1291 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1292 | Rule ID | DTag | W |C=1| padding as needed (success) 1293 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1295 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1296 | Rule ID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 1297 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1299 Figure 15: Format of the SCHC ACK message 1301 The SCHC ACK Header contains a C bit (see Section 8.2.4). 1303 If the C bit is set to 1 (integrity check successful), no Bitmap is 1304 carried. 1306 If the C bit is set to 0 (integrity check not performed or failed) 1307 and if windows are used, a Compressed Bitmap for the window referred 1308 to by the W field is transmitted as specified in Section 8.3.2.1. 1310 8.3.2.1. Bitmap Compression 1312 For transmission, the Compressed Bitmap in the SCHC ACK message is 1313 defined by the following algorithm (see Figure 16 for a follow-along 1314 example): 1316 o Build a temporary SCHC ACK message that contains the Header 1317 followed by the original Bitmap (see Section 8.2.2.3 for a 1318 description of Bitmaps). 1320 o Position scissors at the end of the Bitmap, after its last bit. 1322 o While the bit on the left of the scissors is 1 and belongs to the 1323 Bitmap, keep moving left, then stop. When this is done, 1325 o While the scissors are not on an L2 Word boundary of the SCHC ACK 1326 message and there is a Bitmap bit on the right of the scissors, 1327 keep moving right, then stop. 1329 o At this point, cut and drop off any bits to the right of the 1330 scissors 1332 When one or more bits have effectively been dropped off as a result 1333 of the above algorithm, the SCHC ACK message is a multiple of L2 1334 Words, no padding bits will be appended. 1336 Because the SCHC Fragment sender knows the size of the original 1337 Bitmap, it can reconstruct the original Bitmap from the Compressed 1338 Bitmap received in the SCH ACK message. 1340 Figure 16 shows an example where L2 Words are actually bytes and 1341 where the original Bitmap contains 17 bits, the last 15 of which are 1342 all set to 1. 1344 |---- SCHC ACK Header ----|-------- Bitmap --------| 1345 |-- T --|-M-| 1 | 1346 +--- ... -+- ... -+---+---+---------------------------------+ 1347 | Rule ID | DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| 1348 +--- ... -+- ... -+---+---+---------------------------------+ 1349 next L2 Word boundary ->| 1351 Figure 16: SCHC ACK Header plus uncompressed Bitmap 1353 Figure 17 shows that the last 14 bits are not sent. 1355 |---- SCHC ACK Header ----|CpBmp| 1356 |-- T --|-M-| 1 | 1357 +--- ... -+- ... -+---+---+-----+ 1358 | Rule ID | DTag | W |C=0|1 0 1| 1359 +--- ... -+- ... -+---+---+-----+ 1360 next L2 Word boundary ->| 1362 Figure 17: Resulting SCHC ACK message with Compressed Bitmap 1364 Figure 18 shows an example of a SCHC ACK with tile indices ranging 1365 from 6 down to 0, where the Bitmap indicates that the second and the 1366 fourth tile of the window have not been correctly received. 1368 |---- SCHC ACK Header ----|--- Bitmap --| 1369 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1370 +---------+-------+---+---+-------------+ 1371 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1| uncompressed Bitmap 1372 +---------+-------+---+---+-------------+ 1373 next L2 Word boundary ->|<-- L2 Word -->| 1375 +---------+-------+---+---+-------------+~~~+ 1376 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK 1377 +---------+-------+---+---+-------------+~~~+ 1378 next L2 Word boundary ->|<-- L2 Word -->| 1380 Figure 18: Example of a SCHC ACK message, missing tiles 1382 Figure 19 shows an example of a SCHC ACK with FCN ranging from 6 down 1383 to 0, where integrity check has not been performed or has failed and 1384 the Bitmap indicates that there is no missing tile in that window. 1386 |---- SCHC ACK Header ----|--- Bitmap --| 1387 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1388 +---------+-------+---+---+-------------+ 1389 | Rule ID | DTag | W |C=0|1 1 1 1 1 1 1| with uncompressed Bitmap 1390 +---------+-------+---+---+-------------+ 1391 next L2 Word boundary ->| 1393 +--- ... -+- ... -+---+---+-+ 1394 | Rule ID | DTag | W |C=0|1| transmitted SCHC ACK 1395 +--- ... -+- ... -+---+---+-+ 1396 next L2 Word boundary ->| 1398 Figure 19: Example of a SCHC ACK message, no missing tile 1400 8.3.3. SCHC ACK REQ format 1402 The SCHC ACK REQ is used by a sender to request a SCHC ACK from the 1403 receiver. Its format is shown in Figure 20. The DTag field and the 1404 W field are optional. The FCN field is all zero. 1406 |---- SCHC ACK REQ Header ----| 1407 |-- T --|-M-|-- N --| 1408 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1409 | Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) 1410 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1412 Figure 20: SCHC ACK REQ format 1414 8.3.4. SCHC Sender-Abort format 1416 When a SCHC Fragment sender needs to abort an on-going fragmented 1417 SCHC Packet transmission, it sends a SCHC Sender-Abort message to the 1418 SCHC Fragment receiver. 1420 The SCHC Sender-Abort format is shown in Figure 21. The DTag field 1421 and the W field are optional. The FCN field is all ones. 1423 |---- Sender-Abort Header ----| 1424 |-- T --|-M-|-- N --| 1425 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1426 | Rule ID | DTag | W | 11..1 | padding (as needed) 1427 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1429 Figure 21: SCHC Sender-Abort format 1431 If the W field is present, 1433 o the fragment sender MUST set it to all ones. Other values are 1434 RESERVED. 1436 o the fragment receiver MUST check its value. If the value is 1437 different from all ones, the message MUST be ignored. 1439 The SCHC Sender-Abort MUST NOT be acknowledged. 1441 8.3.5. SCHC Receiver-Abort format 1443 When a SCHC Fragment receiver needs to abort an on-going fragmented 1444 SCHC Packet transmission, it transmits a SCHC Receiver-Abort message 1445 to the SCHC Fragment sender. 1447 The SCHC Receiver-Abort format is shown in Figure 22. The DTag field 1448 and the W field are optional. 1450 |--- Receiver-Abort Header ---| 1451 |--- T ---|-M-| 1 | 1452 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Rule ID | DTag | W |C=1| 1..1| 1..1 | 1454 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1455 next L2 Word boundary ->|<-- L2 Word -->| 1457 Figure 22: SCHC Receiver-Abort format 1459 If the W field is present, 1461 o the fragment receiver MUST set it to all ones. Other values are 1462 RESERVED. 1464 o if the value is different from all ones, the fragment sender MUST 1465 ignore the message. 1467 The SCHC Receiver-Abort has the same header as a SCHC ACK message. 1468 The bits that follow the SCHC Receiver-Abort Header MUST be as 1469 follows 1471 o if the Header does not end at an L2 Word boundary, append bits set 1472 to 1 as needed to reach the next L2 Word boundary 1474 o append exactly one more L2 Word with bits all set to ones 1476 Such a bit pattern never occurs in a regular SCHC ACK. This is how 1477 the fragment sender recognizes a SCHC Receiver-Abort. 1479 The SCHC Receiver-Abort MUST NOT be acknowledged. 1481 8.4. SCHC F/R modes 1483 This specification includes several SCHC F/R modes, which 1485 o allow for a range of reliability options, such as optional SCHC 1486 Fragment retransmission 1488 o support various LPWAN characteristics, including variable MTU. 1490 More modes may be defined in the future. 1492 8.4.1. No-ACK mode 1494 The No-ACK mode has been designed under the assumption that data unit 1495 out-of-sequence delivery does not occur between the entity performing 1496 fragmentation and the entity performing reassembly. This mode 1497 supports LPWAN technologies that have a variable MTU. 1499 In No-ACK mode, there is no communication from the fragment receiver 1500 to the fragment sender. The sender transmits all the SCHC Fragments 1501 without expecting acknowledgement. 1503 In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. 1504 The other SCHC Fragments are intrinsically aligned to L2 Words. 1506 The tile sizes are not required to be uniform. Windows are not used. 1507 The Retransmission Timer is not used. The Attempts counter is not 1508 used. 1510 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1511 F/R messages operating in this mode. 1513 The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK 1514 MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort 1515 MAY be sent. SCHC Receiver-Abort MUST NOT be sent. 1517 The value of N (size of the FCN field) is RECOMMENDED to be 1. 1519 Each Profile, for each Rule ID value, MUST define 1521 o the size of the DTag field, 1523 o the size and algorithm for the RCS field, 1525 o the expiration time of the Inactivity Timer 1526 Each Profile, for each Rule ID value, MAY define 1528 o a value of N different from the recommended one, 1530 o the meaning of values sent in the FCN field, for values different 1531 from the All-1 value. 1533 For each active pair of Rule ID and DTag values, the receiver MUST 1534 maintain an Inactivity Timer. 1536 8.4.1.1. Sender behavior 1538 At the beginning of the fragmentation of a new SCHC Packet, the 1539 fragment sender MUST select a Rule ID and DTag value pair for this 1540 SCHC Packet. 1542 Each SCHC Fragment MUST contain exactly one tile in its Payload. The 1543 tile MUST be at least the size of an L2 Word. The sender MUST 1544 transmit the SCHC Fragments messages in the order that the tiles 1545 appear in the SCHC Packet. Except for the last tile of a SCHC 1546 Packet, each tile MUST be of a size that complements the SCHC 1547 Fragment Header so that the SCHC Fragment is a multiple of L2 Words 1548 without the need for padding bits. Except for the last one, the SCHC 1549 Fragments MUST use the Regular SCHC Fragment format specified in 1550 Section 8.3.1.1. The last SCHC Fragment MUST use the All-1 format 1551 specified in Section 8.3.1.2. 1553 The sender MAY transmit a SCHC Sender-Abort. 1555 Figure 37 shows an example of a corresponding state machine. 1557 8.4.1.2. Receiver behavior 1559 Upon receiving each Regular SCHC Fragment, 1561 o the receiver MUST reset the Inactivity Timer, 1563 o the receiver assembles the payloads of the SCHC Fragments 1565 On receiving an All-1 SCHC Fragment, 1567 o the receiver MUST append the All-1 SCHC Fragment Payload and the 1568 padding bits to the previously received SCHC Fragment Payloads for 1569 this SCHC Packet 1571 o the receiver MUST perform the integrity check 1572 o if integrity checking fails, the receiver MUST drop the 1573 reassembled SCHC Packet 1575 o the reassembly operation concludes. 1577 On expiration of the Inactivity Timer, the receiver MUST drop the 1578 SCHC Packet being reassembled. 1580 On receiving a SCHC Sender-Abort, the receiver MAY drop the SCHC 1581 Packet being reassembled. 1583 Figure 38 shows an example of a corresponding state machine. 1585 8.4.2. ACK-Always mode 1587 The ACK-Always mode has been designed under the following assumptions 1589 o Data unit out-of-sequence delivery does not occur between the 1590 entity performing fragmentation and the entity performing 1591 reassembly 1593 o The L2 MTU value does not change while the fragments of a SCHC 1594 Packet are being transmitted. 1596 In ACK-Always mode, windows are used. An acknowledgement, positive 1597 or negative, is transmitted by the fragment receiver to the fragment 1598 sender at the end of the transmission of each window of SCHC 1599 Fragments. 1601 The tiles are not required to be of uniform size. In ACK-Always 1602 mode, only the All-1 SCHC Fragment is padded as needed. The other 1603 SCHC Fragments are intrinsically aligned to L2 Words. 1605 Briefly, the algorithm is as follows: after a first blind 1606 transmission of all the tiles of a window, the fragment sender 1607 iterates retransmitting the tiles that are reported missing until the 1608 fragment receiver reports that all the tiles belonging to the window 1609 have been correctly received, or until too many attempts were made. 1610 The fragment sender only advances to the next window of tiles when it 1611 has ascertained that all the tiles belonging to the current window 1612 have been fully and correctly received. This results in a per-window 1613 lock-step behavior between the sender and the receiver. 1615 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1616 F/R messages operating in this mode. 1618 The W field MUST be present and its size M MUST be 1 bit. 1620 Each Profile, for each Rule ID value, MUST define 1622 o the value of N (size of the FCN field), 1624 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 1626 o the size and algorithm for the RCS field, 1628 o the size of the DTag field, 1630 o the value of MAX_ACK_REQUESTS, 1632 o the expiration time of the Retransmission Timer 1634 o the expiration time of the Inactivity Timer 1636 For each active pair of Rule ID and DTag values, the sender MUST 1637 maintain 1639 o one Attempts counter 1641 o one Retransmission Timer 1643 For each active pair of Rule ID and DTag values, the receiver MUST 1644 maintain an Inactivity Timer. 1646 8.4.2.1. Sender behavior 1648 At the beginning of the fragmentation of a new SCHC Packet, the 1649 fragment sender MUST select a Rule ID and DTag value pair for this 1650 SCHC Packet. 1652 Each SCHC Fragment MUST contain exactly one tile in its Payload. All 1653 tiles with the index 0, as well as the last tile, MUST be at least 1654 the size of an L2 Word. 1656 In all SCHC Fragment messages, the W field MUST be filled with the 1657 least significant bit of the window number that the sender is 1658 currently processing. 1660 For a SCHC Fragment that carries a tile other than the last one of 1661 the SCHC Packet, 1663 o the Fragment MUST be of the Regular type specified in 1664 Section 8.3.1.1 1666 o the FCN field MUST contain the tile index 1667 o each tile MUST be of a size that complements the SCHC Fragment 1668 Header so that the SCHC Fragment is a multiple of L2 Words without 1669 the need for padding bits. 1671 The SCHC Fragment that carries the last tile MUST be an All-1 SCHC 1672 Fragment, described in Section 8.3.1.2. 1674 The fragment sender MUST start by transmitting the window numbered 0. 1676 The sender starts by a "blind transmission" phase, in which it MUST 1677 transmit all the tiles composing the window, in decreasing tile index 1678 order. 1680 Then, it enters a "retransmission phase" in which it MUST initialize 1681 an Attempts counter to 0, it MUST start a Retransmission Timer and it 1682 MUST await a SCHC ACK. Then, 1684 o upon receiving a SCHC ACK, 1686 * if the SCHC ACK indicates that some tiles are missing at the 1687 receiver, then the sender MUST transmit all the tiles that have 1688 been reported missing, it MUST increment Attempts, it MUST 1689 reset the Retransmission Timer and MUST await the next SCHC 1690 ACK. 1692 * if the current window is not the last one and the SCHC ACK 1693 indicates that all tiles were correctly received, the sender 1694 MUST stop the Retransmission Timer, it MUST advance to the next 1695 fragmentation window and it MUST start a blind transmission 1696 phase as described above. 1698 * if the current window is the last one and the SCHC ACK 1699 indicates that more tiles were received than the sender sent, 1700 the fragment sender MUST send a SCHC Sender-Abort, and it MAY 1701 exit with an error condition. 1703 * if the current window is the last one and the SCHC ACK 1704 indicates that all tiles were correctly received yet integrity 1705 check was a failure, the fragment sender MUST send a SCHC 1706 Sender-Abort, and it MAY exit with an error condition. 1708 * if the current window is the last one and the SCHC ACK 1709 indicates that integrity checking was successful, the sender 1710 exits successfully. 1712 o on Retransmission Timer expiration, 1713 * if Attempts is strictly less that MAX_ACK_REQUESTS, the 1714 fragment sender MUST send a SCHC ACK REQ and MUST increment the 1715 Attempts counter. 1717 * otherwise the fragment sender MUST send a SCHC Sender-Abort, 1718 and it MAY exit with an error condition. 1720 At any time, 1722 o on receiving a SCHC Receiver-Abort, the fragment sender MAY exit 1723 with an error condition. 1725 o on receiving a SCHC ACK that bears a W value different from the W 1726 value that it currently uses, the fragment sender MUST silently 1727 discard and ignore that SCHC ACK. 1729 Figure 39 shows an example of a corresponding state machine. 1731 8.4.2.2. Receiver behavior 1733 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 1734 processed at that time 1736 o the receiver SHOULD check if the DTag value has not recently been 1737 used for that Rule ID value, thereby ensuring that the received 1738 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 1739 transmission. If the SCHC Fragment is determined to be such a 1740 remnant, the receiver MAY silently ignore it and discard it. 1742 o the receiver MUST start a process to assemble a new SCHC Packet 1743 with that Rule ID and DTag value pair. 1745 o the receiver MUST start an Inactivity Timer. It MUST initialize 1746 an Attempts counter to 0. It MUST initialize a window counter to 1747 0. 1749 In the rest of this section, "local W bit" means the least 1750 significant bit of the window counter of the receiver. 1752 On reception of any SCHC F/R message, the receiver MUST reset the 1753 Inactivity Timer. 1755 Entering an "acceptance phase", the receiver MUST first initialize an 1756 empty Bitmap for this window, then 1758 o on receiving a SCHC Fragment or SCHC ACK REQ with the W bit 1759 different from the local W bit, the receiver MUST silently ignore 1760 and discard that message. 1762 o on receiving a SCHC Fragment with the W bit equal to the local W 1763 bit, the receiver MUST assemble the received tile based on the 1764 window counter and on the FCN field in the SCHC Fragment and it 1765 MUST update the Bitmap. 1767 * if the SCHC Fragment received is an All-0 SCHC Fragment, the 1768 current window is determined to be a not-last window, and the 1769 receiver MUST send a SCHC ACK for this window. Then, 1771 + If the Bitmap indicates that all the tiles of the current 1772 window have been correctly received, the receiver MUST 1773 increment its window counter and it enters the "acceptance 1774 phase" for that new window. 1776 + If the Bitmap indicates that at least one tile is missing in 1777 the current window, the receiver enters the "retransmission 1778 phase" for this window. 1780 * if the SCHC Fragment received is an All-1 SCHC Fragment, the 1781 padding bits of the All-1 SCHC Fragment MUST be assembled after 1782 the received tile, the current window is determined to be the 1783 last window, the receiver MUST perform the integrity check and 1784 it MUST send a SCHC ACK for this window. Then, 1786 + If the integrity check indicates that the full SCHC Packet 1787 has been correctly reassembled, the receiver MUST enter the 1788 "clean-up phase". 1790 + If the integrity check indicates that the full SCHC Packet 1791 has not been correctly reassembled, the receiver enters the 1792 "retransmission phase" for this window. 1794 o on receiving a SCHC ACK REQ with the W bit equal to the local W 1795 bit, the receiver has not yet determined if the current window is 1796 a not-last one or the last one, the receiver MUST send a SCHC ACK 1797 for this window, and it keeps accepting incoming messages. 1799 In the "retransmission phase": 1801 o if the window is a not-last window 1803 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1804 different from the local W bit the receiver MUST silently 1805 ignore and discard that message. 1807 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1808 bit, the receiver MUST send a SCHC ACK for this window. 1810 * on receiving a SCHC Fragment with a W bit equal to the local W 1811 bit, 1813 + if the SCHC Fragment received is an All-1 SCHC Fragment, the 1814 receiver MUST silently ignore it and discard it. 1816 + otherwise, the receiver MUST update the Bitmap and it MUST 1817 assemble the tile received. 1819 * on the Bitmap becoming fully populated with 1's, the receiver 1820 MUST send a SCHC ACK for this window, it MUST increment its 1821 window counter and it enters the "acceptance phase" for the new 1822 window. 1824 o if the window is the last window 1826 * on receiving a SCHC Fragment or SCHC ACK REQ with a W bit 1827 different from the local W bit the receiver MUST silently 1828 ignore and discard that message. 1830 * on receiving a SCHC ACK REQ with a W bit equal to the local W 1831 bit, the receiver MUST send a SCHC ACK for this window. 1833 * on receiving a SCHC Fragment with a W bit equal to the local W 1834 bit, 1836 + if the SCHC Fragment received is an All-0 SCHC Fragment, the 1837 receiver MUST silently ignore it and discard it. 1839 + otherwise, the receiver MUST update the Bitmap and it MUST 1840 assemble the tile received. If the SCHC Fragment received 1841 is an All-1 SCHC Fragment, the receiver MUST assemble the 1842 padding bits of the All-1 SCHC Fragment after the received 1843 tile. It MUST perform the integrity check. Then 1845 - if the integrity check indicates that the full SCHC 1846 Packet has been correctly reassembled, the receiver MUST 1847 send a SCHC ACK and it enters the "clean-up phase". 1849 - if the integrity check indicates that the full SCHC 1850 Packet has not been correctly reassembled, 1852 o if the SCHC Fragment received was an All-1 SCHC 1853 Fragment, the receiver MUST send a SCHC ACK for this 1854 window 1856 o it keeps accepting incoming messages. 1858 In the "clean-up phase": 1860 o Any received SCHC F/R message with a W bit different from the 1861 local W bit MUST be silently ignored and discarded. 1863 o Any received SCHC F/R message different from an All-1 SCHC 1864 Fragment or a SCHC ACK REQ MUST be silently ignored and discarded. 1866 o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, the 1867 receiver MUST send a SCHC ACK. 1869 At any time, on expiration of the Inactivity Timer, on receiving a 1870 SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the 1871 receiver MUST send a SCHC Receiver-Abort and it MAY exit the receive 1872 process for that SCHC Packet. 1874 Figure 40 shows an example of a corresponding state machine. 1876 8.4.3. ACK-on-Error mode 1878 The ACK-on-Error mode supports LPWAN technologies that have variable 1879 MTU and out-of-order delivery. 1881 In ACK-on-Error mode, windows are used. All tiles MUST be of equal 1882 size, except for the last one, which MUST be of the same size or 1883 smaller than the regular ones. If allowed in a Profile, the 1884 penultimate tile MAY be exactly one L2 Word smaller than the regular 1885 tile size. 1887 A SCHC Fragment message carries one or more tiles, which may span 1888 multiple windows. A SCHC ACK reports on the reception of exactly one 1889 window of tiles. 1891 See Figure 23 for an example. 1893 +---------------------------------------------...-----------+ 1894 | SCHC Packet | 1895 +---------------------------------------------...-----------+ 1897 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| 1898 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| 1900 SCHC Fragment msg |-----------| 1902 Figure 23: a SCHC Packet fragmented in tiles, Ack-on-Error mode 1904 The W field is wide enough that it unambiguously represents an 1905 absolute window number. The fragment receiver sends SCHC ACKs to the 1906 fragment sender about windows for which tiles are missing. No SCHC 1907 ACK is sent by the fragment receiver for windows that it knows have 1908 been fully received. 1910 The fragment sender retransmits SCHC Fragments for tiles that are 1911 reported missing. It can advance to next windows even before it has 1912 ascertained that all tiles belonging to previous windows have been 1913 correctly received, and can still later retransmit SCHC Fragments 1914 with tiles belonging to previous windows. Therefore, the sender and 1915 the receiver may operate in a decoupled fashion. The fragmented SCHC 1916 Packet transmission concludes when 1918 o integrity checking shows that the fragmented SCHC Packet has been 1919 correctly reassembled at the receive end, and this information has 1920 been conveyed back to the sender, 1922 o or too many retransmission attempts were made, 1924 o or the receiver determines that the transmission of this 1925 fragmented SCHC Packet has been inactive for too long. 1927 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1928 F/R messages operating in this mode. 1930 The W field MUST be present in the SCHC F/R messages. 1932 Each Profile, for each Rule ID value, MUST define 1934 o the tile size (a tile does not need to be multiple of an L2 Word, 1935 but it MUST be at least the size of an L2 Word) 1937 o the value of M (size of the W field), 1939 o the value of N (size of the FCN field), 1941 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 1943 o the size and algorithm for the RCS field, 1945 o the size of the DTag field, 1947 o the value of MAX_ACK_REQUESTS, 1949 o the expiration time of the Retransmission Timer 1951 o the expiration time of the Inactivity Timer 1952 o if the last tile is carried in a Regular SCHC Fragment or an All-1 1953 SCHC Fragment (see Section 8.4.3.1) 1955 o if the penultimate tile MAY be one L2 Word smaller than the 1956 regular tile size. In this case, the regular tile size MUST be at 1957 least twice the L2 Word size. 1959 For each active pair of Rule ID and DTag values, the sender MUST 1960 maintain 1962 o one Attempts counter 1964 o one Retransmission Timer 1966 For each active pair of Rule ID and DTag values, the receiver MUST 1967 maintain an Inactivity Timer. 1969 8.4.3.1. Sender behavior 1971 At the beginning of the fragmentation of a new SCHC Packet, 1973 o the fragment sender MUST select a Rule ID and DTag value pair for 1974 this SCHC Packet. A Rule MUST NOT be selected if the values of M 1975 and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot 1976 be fragmented in (2^M) * WINDOW_SIZE tiles or less. 1978 o the fragment sender MUST initialize the Attempts counter to 0 for 1979 that Rule ID and DTag value pair. 1981 A Regular SCHC Fragment message carries in its payload one or more 1982 tiles. If more than one tile is carried in one Regular SCHC Fragment 1984 o the selected tiles MUST be consecutive in the original SCHC Packet 1986 o they MUST be placed in the SCHC Fragment Payload adjacent to one 1987 another, in the order they appear in the SCHC Packet, from the 1988 start of the SCHC Packet toward its end. 1990 Tiles that are not the last one MUST be sent in Regular SCHC 1991 Fragments specified in Section 8.3.1.1. The FCN field MUST contain 1992 the tile index of the first tile sent in that SCHC Fragment. 1994 In a Regular SCHC Fragment message, the sender MUST fill the W field 1995 with the window number of the first tile sent in that SCHC Fragment. 1997 Depending on the Profile, the last tile of a SCHC Packet MUST be sent 1998 either 1999 o in a Regular SCHC Fragment, alone or as part of a multi-tiles 2000 Payload 2002 o alone in an All-1 SCHC Fragment 2004 In an All-1 SCHC Fragment message, the sender MUST fill the W field 2005 with the window number of the last tile of the SCHC Packet. 2007 The fragment sender MUST send SCHC Fragments such that, all together, 2008 they contain all the tiles of the fragmented SCHC Packet. 2010 The fragment sender MUST send at least one All-1 SCHC Fragment. 2012 The fragment sender MUST listen for SCHC ACK messages after having 2013 sent 2015 o an All-1 SCHC Fragment 2017 o or a SCHC ACK REQ. 2019 A Profile MAY specify other times at which the fragment sender MUST 2020 listen for SCHC ACK messages. For example, this could be after 2021 sending a complete window of tiles. 2023 Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC 2024 ACK REQ, 2026 o it MUST increment the Attempts counter 2028 o it MUST reset the Retransmission Timer 2030 On Retransmission Timer expiration 2032 o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment 2033 sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ 2034 with the W field corresponding to the last window, 2036 o otherwise the fragment sender MUST send a SCHC Sender-Abort and it 2037 MAY exit with an error condition. 2039 On receiving a SCHC ACK, 2041 o if the W field in the SCHC ACK corresponds to the last window of 2042 the SCHC Packet, 2044 * if the C bit is set, the sender MAY exit successfully 2046 * otherwise, 2047 + if the Profile mandates that the last tile be sent in an 2048 All-1 SCHC Fragment, 2050 - if the SCHC ACK shows no missing tile at the receiver, 2051 the sender 2053 o MUST send a SCHC Sender-Abort 2055 o MAY exit with an error condition 2057 - otherwise 2059 o the fragment sender MUST send SCHC Fragment messages 2060 containing all the tiles that are reported missing in 2061 the SCHC ACK. 2063 o if the last message in this sequence of SCHC Fragment 2064 messages is not an All-1 SCHC Fragment, then the 2065 fragment sender MUST in addition send a SCHC ACK REQ 2066 with the W field corresponding to the last window, 2067 after the sequence. 2069 + otherwise, 2071 - if the SCHC ACK shows no missing tile at the receiver, 2072 the sender MUST send the All-1 SCHC Fragment 2074 - otherwise 2076 o the fragment sender MUST send SCHC Fragment messages 2077 containing all the tiles that are reported missing in 2078 the SCHC ACK. 2080 o the fragment sender MUST then send either the All-1 2081 SCHC Fragment or a SCHC ACK REQ with the W field 2082 corresponding to the last window. 2084 o otherwise, the fragment sender 2086 * MUST send SCHC Fragment messages containing the tiles that are 2087 reported missing in the SCHC ACK 2089 * then it MAY send a SCHC ACK REQ with the W field corresponding 2090 to the last window 2092 See Figure 41 for one among several possible examples of a Finite 2093 State Machine implementing a sender behavior obeying this 2094 specification. 2096 8.4.3.2. Receiver behavior 2098 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 2099 processed at that time 2101 o the receiver SHOULD check if the DTag value has not recently been 2102 used for that Rule ID value, thereby ensuring that the received 2103 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 2104 transmission. If the SCHC Fragment is determined to be such a 2105 remnant, the receiver MAY silently ignore it and discard it. 2107 o the receiver MUST start a process to assemble a new SCHC Packet 2108 with that Rule ID and DTag value pair. 2110 o the receiver MUST start an Inactivity Timer. It MUST initialize 2111 an Attempts counter to 0. 2113 On receiving any SCHC F/R message, the receiver MUST reset the 2114 Inactivity Timer. 2116 On receiving a SCHC Fragment message, the receiver determines what 2117 tiles were received, based on the payload length and on the W and FCN 2118 fields of the SCHC Fragment. 2120 o if the FCN is All-1, if a Payload is present, the full SCHC 2121 Fragment Payload MUST be assembled including the padding bits. 2122 This is because the size of the last tile is not known by the 2123 receiver, therefore padding bits are indistinguishable from the 2124 tile data bits, at this stage. They will be removed by the SCHC 2125 C/D sublayer. If the size of the SCHC Fragment Payload exceeds or 2126 equals the size of one regular tile plus the size of an L2 Word, 2127 this SHOULD raise an error flag. 2129 o otherwise, tiles MUST be assembled based on the a priori known 2130 tile size. 2132 * If allowed by the Profile, the end of the payload MAY contain 2133 the last tile, which may be shorter. Padding bits are 2134 indistinguishable from the tile data bits, at this stage. 2136 * the payload may contain the penultimate tile that, if allowed 2137 by the Profile, MAY be exactly one L2 Word shorter than the 2138 regular tile size. 2140 * Otherwise, padding bits MUST be discarded. The latter is 2141 possible because 2143 + the size of the tiles is known a priori, 2144 + tiles are larger than an L2 Word 2146 + padding bits are always strictly less than an L2 Word 2148 On receiving a SCHC ACK REQ or an All-1 SCHC Fragment, 2150 o if the receiver has at least one window that it knows has tiles 2151 missing, it MUST return a SCHC ACK for the lowest-numbered such 2152 window, 2154 o otherwise, 2156 * if it has received at least one tile, it MUST return a SCHC ACK 2157 for the highest-numbered window it currently has tiles for 2159 * otherwise it MUST return a SCHC ACK for window numbered 0 2161 A Profile MAY specify other times and circumstances at which a 2162 receiver sends a SCHC ACK, and which window the SCHC ACK reports 2163 about in these circumstances. 2165 Upon sending a SCHC ACK, the receiver MUST increase the Attempts 2166 counter. 2168 After receiving an All-1 SCHC Fragment, a receiver MUST check the 2169 integrity of the reassembled SCHC Packet at least every time it 2170 prepares for sending a SCHC ACK for the last window. 2172 Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an 2173 error condition. 2175 Upon expiration of the Inactivity Timer, the receiver MUST send a 2176 SCHC Receiver-Abort and it MAY exit with an error condition. 2178 On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST 2179 send a SCHC Receiver-Abort and it MAY exit with an error condition. 2181 Reassembly of the SCHC Packet concludes when 2183 o a Sender-Abort has been received 2185 o or the Inactivity Timer has expired 2187 o or the Attempts counter has exceeded MAX_ACK_REQUESTS 2189 o or when at least an All-1 SCHC Fragment has been received and 2190 integrity checking of the reassembled SCHC Packet is successful. 2192 See Figure 42 for one among several possible examples of a Finite 2193 State Machine implementing a receiver behavior obeying this 2194 specification, and that is meant to match the sender Finite State 2195 Machine of Figure 41. 2197 9. Padding management 2199 SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does 2200 not have any alignment prerequisite. The size of SCHC Packets can be 2201 any number of bits. 2203 If the layer below SCHC constrains the payload to align to some 2204 boundary, called L2 Words (for example, bytes), the SCHC messages 2205 MUST be padded. When padding occurs, the number of appended bits 2206 MUST be strictly less than the L2 Word size. 2208 If a SCHC Packet is sent unfragmented (see Figure 24), it is padded 2209 as needed for transmission. 2211 If a SCHC Packet needs to be fragmented for transmission, it is not 2212 padded in itself. Only the SCHC F/R messages are padded as needed 2213 for transmission. Some SCHC F/R messages are intrinsically aligned 2214 to L2 Words. 2216 A packet (e.g. an IPv6 packet) 2217 | ^ (padding bits 2218 v | dropped) 2219 +------------------+ +--------------------+ 2220 | SCHC Compression | | SCHC Decompression | 2221 +------------------+ +--------------------+ 2222 | ^ 2223 | If no fragmentation | 2224 +---- SCHC Packet + padding as needed ----->| 2225 | | (integrity 2226 v | checked) 2227 +--------------------+ +-----------------+ 2228 | SCHC Fragmentation | | SCHC Reassembly | 2229 +--------------------+ +-----------------+ 2230 | ^ | ^ 2231 | | | | 2232 | +------------- SCHC ACK ------------+ | 2233 | | 2234 +------- SCHC Fragments + padding as needed---------+ 2236 Sender Receiver 2238 Figure 24: SCHC operations, including padding as needed 2240 Each Profile MUST specify the size of the L2 Word. The L2 Word might 2241 actually be a single bit, in which case no padding will take place at 2242 all. 2244 A Profile MAY define the value of the padding bits. The RECOMMENDED 2245 value is 0. 2247 10. SCHC Compression for IPv6 and UDP headers 2249 This section lists the IPv6 and UDP header fields and describes how 2250 they can be compressed. 2252 10.1. IPv6 version field 2254 The IPv6 version field is labeled by the protocol parser as being the 2255 "version" field of the IPv6 protocol. Therefore, it only exists for 2256 IPv6 packets. In the Rule, TV is set to 6, MO to "ignore" and CDA to 2257 "not-sent". 2259 10.2. IPv6 Traffic class field 2261 If the DiffServ field does not vary and is known by both sides, the 2262 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2263 value, an "equal" MO and a "not-sent" CDA. 2265 Otherwise (e.g. ECN bits are to be transmitted), two possibilities 2266 can be considered depending on the variability of the value: 2268 o One possibility is to not compress the field and send the original 2269 value. In the Rule, TV is not set to any particular value, MO is 2270 set to "ignore" and CDA is set to "value-sent". 2272 o If some upper bits in the field are constant and known, a better 2273 option is to only send the LSBs. In the Rule, TV is set to a 2274 value with the stable known upper part, MO is set to MSB(x) and 2275 CDA to LSB. 2277 10.3. Flow label field 2279 If the Flow Label field does not vary and is known by both sides, the 2280 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2281 value, an "equal" MO and a "not-sent" CDA. 2283 Otherwise, two possibilities can be considered: 2285 o One possibility is to not compress the field and send the original 2286 value. In the Rule, TV is not set to any particular value, MO is 2287 set to "ignore" and CDA is set to "value-sent". 2289 o If some upper bits in the field are constant and known, a better 2290 option is to only send the LSBs. In the Rule, TV is set to a 2291 value with the stable known upper part, MO is set to MSB(x) and 2292 CDA to LSB. 2294 10.4. Payload Length field 2296 This field can be elided for the transmission on the LPWAN network. 2297 The SCHC C/D recomputes the original payload length value. In the 2298 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 2299 "compute-*". 2301 10.5. Next Header field 2303 If the Next Header field does not vary and is known by both sides, 2304 the Field Descriptor in the Rule SHOULD contain a TV with this Next 2305 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 2306 sent". 2308 Otherwise, TV is not set in the Field Descriptor, MO is set to 2309 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 2310 list MAY also be used. 2312 10.6. Hop Limit field 2314 The field behavior for this field is different for uplink (Up) and 2315 downlink (Dw). In Up, since there is no IP forwarding between the 2316 Dev and the SCHC C/D, the value is relatively constant. On the other 2317 hand, the Dw value depends on Internet routing and can change more 2318 frequently. The Direction Indicator (DI) can be used to distinguish 2319 both directions: 2321 o in the Up, elide the field: the TV in the Field Descriptor is set 2322 to the known constant value, the MO is set to "equal" and the CDA 2323 is set to "not-sent". 2325 o in the Dw, the Hop Limit is elided for transmission and forced to 2326 1 at the receiver, by setting TV to 1, MO to "ignore" and CDA to 2327 "not-sent". This prevents any further forwarding. 2329 10.7. IPv6 addresses fields 2331 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 2332 long fields; one for the prefix and one for the Interface Identifier 2333 (IID). These fields SHOULD be compressed. To allow for a single 2334 Rule being used for both directions, these values are identified by 2335 their role (Dev or App) and not by their position in the header 2336 (source or destination). 2338 10.7.1. IPv6 source and destination prefixes 2340 Both ends MUST be configured with the appropriate prefixes. For a 2341 specific flow, the source and destination prefixes can be unique and 2342 stored in the Context. In that case, the TV for the source and 2343 destination prefixes contain the values, the MO is set to "equal" and 2344 the CDA is set to "not-sent". 2346 If the Rule is intended to compress packets with different prefix 2347 values, match-mapping SHOULD be used. The different prefixes are 2348 listed in the TV, the MO is set to "match-mapping" and the CDA is set 2349 to "mapping-sent". See Figure 26. 2351 Otherwise, the TV is not set, the MO is set to "ignore" and the CDA 2352 is set to "value-sent". 2354 10.7.2. IPv6 source and destination IID 2356 If the Dev or App IID are based on an LPWAN address, then the IID can 2357 be reconstructed with information coming from the LPWAN header. In 2358 that case, the TV is not set, the MO is set to "ignore" and the CDA 2359 is set to "DevIID" or "AppIID". On LPWAN technologies where the 2360 frames carry a single identifier (corresponding to the Dev.), AppIID 2361 cannot be used. 2363 As described in [RFC8065], it may be undesirable to build the Dev 2364 IPv6 IID out of the Dev address. Another static value is used 2365 instead. In that case, the TV contains the static value, the MO 2366 operator is set to "equal" and the CDA is set to "not-sent". 2367 [RFC7217] provides some methods to derive this static identifier. 2369 If several IIDs are possible, then the TV contains the list of 2370 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 2371 "mapping-sent". 2373 It may also happen that the IID variability only expresses itself on 2374 a few bytes. In that case, the TV is set to the stable part of the 2375 IID, the MO is set to "MSB" and the CDA is set to "LSB". 2377 Finally, the IID can be sent in its entirety on the LPWAN. In that 2378 case, the TV is not set, the MO is set to "ignore" and the CDA is set 2379 to "value-sent". 2381 10.8. IPv6 extensions 2383 This document does not provide recommendations on how to compress 2384 IPv6 extensions. 2386 10.9. UDP source and destination port 2388 To allow for a single Rule being used for both directions, the UDP 2389 port values are identified by their role (Dev or App) and not by 2390 their position in the header (source or destination). The SCHC C/D 2391 MUST be aware of the traffic direction (Uplink, Downlink) to select 2392 the appropriate field. The following Rules apply for Dev and App 2393 port numbers. 2395 If both ends know the port number, it can be elided. The TV contains 2396 the port number, the MO is set to "equal" and the CDA is set to "not- 2397 sent". 2399 If the port variation is on few bits, the TV contains the stable part 2400 of the port number, the MO is set to "MSB" and the CDA is set to 2401 "LSB". 2403 If some well-known values are used, the TV can contain the list of 2404 these values, the MO is set to "match-mapping" and the CDA is set to 2405 "mapping-sent". 2407 Otherwise the port numbers are sent over the LPWAN. The TV is not 2408 set, the MO is set to "ignore" and the CDA is set to "value-sent". 2410 10.10. UDP length field 2412 The UDP length can be computed from the received data. The TV is not 2413 set, the MO is set to "ignore" and the CDA is set to "compute-*". 2415 10.11. UDP Checksum field 2417 The UDP checksum operation is mandatory with IPv6 for most packets 2418 but there are exceptions [RFC8200]. 2420 For instance, protocols that use UDP as a tunnel encapsulation may 2421 enable zero-checksum mode for a specific port (or set of ports) for 2422 sending and/or receiving. [RFC8200] requires any node implementing 2423 zero-checksum mode to follow the requirements specified in 2424 "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero 2425 Checksums" [RFC6936]. 2427 6LoWPAN Header Compression [RFC6282] also specifies that a UDP 2428 checksum can be elided by the compressor and re-computed by the 2429 decompressor when an upper layer guarantees the integrity of the UDP 2430 payload and pseudo-header. A specific example of this is when a 2431 Message Integrity Check protects the compressed message between the 2432 compressor that elides the UDP checksum and the decompressor that 2433 computes it, with a strength that is identical or better to the UDP 2434 checksum. 2436 Similarly, a SCHC compressor MAY elide the UDP checksum when another 2437 layer guarantees at least equal integrity protection for the UDP 2438 payload and the pseudo-header. In this case, the TV is not set, the 2439 MO is set to "ignore" and the CDA is set to "compute-*". 2441 In particular, when SCHC fragmentation is used, a fragmentation RCS 2442 of 2 bytes or more provides equal or better protection than the UDP 2443 checksum; in that case, if the compressor is collocated with the 2444 fragmentation point and the decompressor is collocated with the 2445 packet reassembly point, and if the SCHC Packet is fragmented even 2446 when it would fit unfragmented in the L2 MTU, then the compressor MAY 2447 verify and then elide the UDP checksum. Whether and when the UDP 2448 Checksum is elided is to be specified in the Profile. 2450 Since the compression happens before the fragmentation, implementors 2451 should understand the risks when dealing with unprotected data below 2452 the transport layer and take special care when manipulating that 2453 data. 2455 In other cases, the checksum SHOULD be explicitly sent. The TV is 2456 not set, the MO is set to "ignore" and the CDA is set to "value- 2457 sent". 2459 11. IANA Considerations 2461 This document has no request to IANA. 2463 12. Security considerations 2465 Wireless networks are subjects to various sorts of attacks, which are 2466 not specific to SCHC. In this section, we'll assume that an attacker 2467 was able to break into the network despite the latter's security 2468 measures and that it can now send packets to a target node. What is 2469 specific to SCHC is the amplification of the effects that this break- 2470 in could allow. Our analysis equally applies to legitimate nodes 2471 "going crazy". 2473 12.1. Security considerations for SCHC Compression/Decompression 2475 Let's assume that an attacker is able to send a forged SCHC Packet to 2476 a SCHC Decompressor. 2478 Let's first consider the case where the Rule ID contained in that 2479 forged SCHC Packet does not correspond to a Rule allocated in the 2480 Rule table. An implementation should detect that the Rule ID is 2481 invalid and should silently drop the offending SCHC Packet. 2483 Let's now consider that the Rule ID corresponds to a Rule in the 2484 table. With the CDAs defined in this document, the reconstructed 2485 packet is at most a constant number of bits bigger than the SCHC 2486 Packet that was received. This assumes that the compute-* 2487 decompression actions produce a bounded number of bits, irrespective 2488 of the incoming SCHC Packet. This property is true for IPv6 Length, 2489 UDP Length and UDP Checksum, for which the compute-* CDA is 2490 recommended by this document. 2492 As a consequence, SCHC Decompression does not amplify attacks, beyond 2493 adding a bounded number of bits to the SCHC Packet received. This 2494 bound is determined by the Rule stored in the receiving device. 2496 As a general safety measure, a SCHC Decompressor should never re- 2497 construct a packet larger than MAX_PACKET_SIZE (defined in a Profile, 2498 with 1500 bytes as generic default). 2500 12.2. Security considerations for SCHC Fragmentation/Reassembly 2502 Let's assume that an attacker is able to send to a forged SCHC 2503 Fragment to a SCHC Reassembler. 2505 A node can perform a buffer reservation attack: the receiver will 2506 reserve buffer space for the SCHC Packet. If the implementation has 2507 only one buffer, other incoming fragmented SCHC Packets will be 2508 dropped while the reassembly buffer is occupied during the reassembly 2509 timeout. Once that timeout expires, the attacker can repeat the same 2510 procedure, and iterate, thus creating a denial of service attack. An 2511 implementation may have multiple reassembly buffers. The cost to 2512 mount this attack is linear with the number of buffers at the target 2513 node. Better, the cost for an attacker can be increased if 2514 individual fragments of multiple SCHC Packets can be stored in the 2515 reassembly buffer. The finer grained the reassembly buffer (downto 2516 the smallest tile size), the higher the cost of the attack. If 2517 buffer overload does occur, a smart receiver could selectively 2518 discard SCHC Packets being reassembled based on the sender behavior, 2519 which may help identify which SCHC Fragments have been sent by the 2520 attacker. Another mild counter-measure is for the target to abort 2521 the fragmentation/reassembly session as early as it detects a non- 2522 identical SCHC Fragment duplicate, anticipating for an eventual 2523 corrupt SCHC Packet, so as to save the sender the hassle of sending 2524 the rest of the fragments for this SCHC Packet. 2526 In another type of attack, the malicious node is additionally assumed 2527 to be able to hear an incoming communication destined to the target 2528 node. It can then send a forged SCHC Fragment that looks like it 2529 belongs to a SCHC Packet already being reassembled at the target 2530 node. This can cause the SCHC Packet to be considered corrupt and be 2531 dropped by the receiver. The amplification happens here by a single 2532 spoofed SCHC Fragment rendering a full sequence of legit SCHC 2533 Fragments useless. If the target uses ACK-Always or ACK-on-Error 2534 mode, such a malicious node can also interfere with the 2535 acknowledgement and repetition algorithm of SCHC F/R. A single 2536 spoofed ACK, with all bitmap bits set to 0, will trigger the 2537 repetition of WINDOW_SIZE tiles. This protocol loop amplification 2538 depletes the energy source of the target node and consumes the 2539 channel bandwidth. Similarly, a spoofed ACK REQ will trigger the 2540 sending of a SCHC ACK, which may be much larger than the ACK REQ if 2541 WINDOW_SIZE is large. These consequences should be borne in mind 2542 when defining profiles for SCHC over specific LPWAN technologies. 2544 13. Acknowledgements 2546 Thanks to Sergio Aguilar Romero, Carsten Bormann, Philippe Clavier, 2547 Daniel Ducuara Beltran Diego Dujovne, Eduardo Ingles Sanchez, 2548 Arunprabhu Kandasamy, Suresh Krishnan, Rahul Jadhav, Sergio Lopez 2549 Bernal, Antony Markovski, Alexander Pelov, Charles Perkins, Edgar 2550 Ramos, Shoichi Sakane, and Pascal Thubert for useful design 2551 consideration and comments. 2553 Carles Gomez has been funded in part by the Spanish Government 2554 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2555 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2556 Government through project TEC2016-79988-P. Part of his contribution 2557 to this work has been carried out during his stay as a visiting 2558 scholar at the Computer Laboratory of the University of Cambridge. 2560 14. References 2562 14.1. Normative References 2564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2565 Requirement Levels", BCP 14, RFC 2119, 2566 DOI 10.17487/RFC2119, March 1997, 2567 . 2569 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2570 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2571 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2572 . 2574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2575 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2576 May 2017, . 2578 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2579 (IPv6) Specification", STD 86, RFC 8200, 2580 DOI 10.17487/RFC8200, July 2017, 2581 . 2583 14.2. Informative References 2585 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 2586 "Internet Protocol Small Computer System Interface (iSCSI) 2587 Cyclic Redundancy Check (CRC)/Checksum Considerations", 2588 RFC 3385, DOI 10.17487/RFC3385, September 2002, 2589 . 2591 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2592 "Transmission of IPv6 Packets over IEEE 802.15.4 2593 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2594 . 2596 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2597 Header Compression (ROHC) Framework", RFC 5795, 2598 DOI 10.17487/RFC5795, March 2010, 2599 . 2601 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2602 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2603 DOI 10.17487/RFC6282, September 2011, 2604 . 2606 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2607 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2608 February 2014, . 2610 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2611 Interface Identifiers with IPv6 Stateless Address 2612 Autoconfiguration (SLAAC)", RFC 7217, 2613 DOI 10.17487/RFC7217, April 2014, 2614 . 2616 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 2617 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 2618 February 2017, . 2620 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2621 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2622 . 2624 Appendix A. Compression Examples 2626 This section gives some scenarios of the compression mechanism for 2627 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2629 The mechanisms defined in this document can be applied to a Dev that 2630 embeds some applications running over CoAP. In this example, three 2631 flows are considered. The first flow is for the device management 2632 based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 2633 124 for Dev and App, respectively. The second flow will be a CoAP 2634 server for measurements done by the Dev (using ports 5683) and Global 2635 IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is 2636 for legacy applications using different ports numbers, the 2637 destination IPv6 address prefix is gamma::1/64. 2639 Figure 25 presents the protocol stack. IPv6 and UDP are represented 2640 with dotted lines since these protocols are compressed on the radio 2641 link. 2643 Management Data 2644 +----------+---------+---------+ 2645 | CoAP | CoAP | legacy | 2646 +----||----+---||----+---||----+ 2647 . UDP . UDP | UDP | 2648 ................................ 2649 . IPv6 . IPv6 . IPv6 . 2650 +------------------------------+ 2651 | SCHC Header compression | 2652 | and fragmentation | 2653 +------------------------------+ 2654 | LPWAN L2 technologies | 2655 +------------------------------+ 2656 Dev or NGW 2658 Figure 25: Simplified Protocol Stack for LP-WAN 2660 In some LPWAN technologies, only the Devs have a device ID. When 2661 such technologies are used, it is necessary to statically define an 2662 IID for the Link Local address for the SCHC C/D. 2664 Rule 0 2665 +----------------+--+--+--+---------+--------+------------++------+ 2666 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 2667 | | | | | | Opera. | Action ||[bits]| 2668 +----------------+--+--+--+---------+---------------------++------+ 2669 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2670 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2671 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2672 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2673 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2674 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2675 |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2676 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2677 |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2678 |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | 2679 +================+==+==+==+=========+========+============++======+ 2680 |UDP DevPort |16|1 |Bi|123 | equal | not-sent || | 2681 |UDP AppPort |16|1 |Bi|124 | equal | not-sent || | 2682 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2683 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2684 +================+==+==+==+=========+========+============++======+ 2685 Rule 1 2686 +----------------+--+--+--+---------+--------+------------++------+ 2687 | Field |FL|FP|DI| Value | Match | Action || Sent | 2688 | | | | | | Opera. | Action ||[bits]| 2689 +----------------+--+--+--+---------+--------+------------++------+ 2690 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2691 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2692 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2693 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2694 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2695 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2696 |IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 | 2697 | | | | |fe80::/64] mapping| || | 2698 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2699 |IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 | 2700 | | | | |alpha/64,| mapping| || | 2701 | | | | |fe80::64]| | || | 2702 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2703 +================+==+==+==+=========+========+============++======+ 2704 |UDP DevPort |16|1 |Bi|5683 | equal | not-sent || | 2705 |UDP AppPort |16|1 |Bi|5683 | equal | not-sent || | 2706 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2707 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2708 +================+==+==+==+=========+========+============++======+ 2710 Rule 2 2711 +----------------+--+--+--+---------+--------+------------++------+ 2712 | Field |FL|FP|DI| Value | Match | Action || Sent | 2713 | | | | | | Opera. | Action ||[bits]| 2714 +----------------+--+--+--+---------+--------+------------++------+ 2715 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2716 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2717 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2718 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2719 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2720 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2721 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 | 2722 |IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2723 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2724 |IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2725 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2726 +================+==+==+==+=========+========+============++======+ 2727 |UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2728 |UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2729 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2730 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2731 +================+==+==+==+=========+========+============++======+ 2732 Figure 26: Context Rules 2734 All the fields described in the three Rules depicted on Figure 26 are 2735 present in the IPv6 and UDP headers. The DevIID-DID value is found 2736 in the L2 header. 2738 The second and third Rules use global addresses. The way the Dev 2739 learns the prefix is not in the scope of the document. 2741 The third Rule compresses each port number to 4 bits. 2743 Appendix B. Fragmentation Examples 2745 This section provides examples for the various fragment reliability 2746 modes specified in this document. In the drawings, Bitmaps are shown 2747 in their uncompressed form. 2749 Figure 27 illustrates the transmission in No-ACK mode of a SCHC 2750 Packet that needs 11 SCHC Fragments. FCN is 1 bit wide. 2752 Sender Receiver 2753 |-------FCN=0-------->| 2754 |-------FCN=0-------->| 2755 |-------FCN=0-------->| 2756 |-------FCN=0-------->| 2757 |-------FCN=0-------->| 2758 |-------FCN=0-------->| 2759 |-------FCN=0-------->| 2760 |-------FCN=0-------->| 2761 |-------FCN=0-------->| 2762 |-------FCN=0-------->| 2763 |-----FCN=1 + RCS --->| Integrity check: success 2764 (End) 2766 Figure 27: No-ACK mode, 11 SCHC Fragments 2768 In the following examples, N (the size of the FCN field) is 3 bits. 2769 The All-1 FCN value is 7. 2771 Figure 28 illustrates the transmission in ACK-on-Error mode of a SCHC 2772 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2773 WINDOW_SIZE=7 and no lost SCHC Fragment. 2775 Sender Receiver 2776 |-----W=0, FCN=6----->| 2777 |-----W=0, FCN=5----->| 2778 |-----W=0, FCN=4----->| 2779 |-----W=0, FCN=3----->| 2780 |-----W=0, FCN=2----->| 2781 |-----W=0, FCN=1----->| 2782 |-----W=0, FCN=0----->| 2783 (no ACK) 2784 |-----W=1, FCN=6----->| 2785 |-----W=1, FCN=5----->| 2786 |-----W=1, FCN=4----->| 2787 |--W=1, FCN=7 + RCS-->| Integrity check: success 2788 |<-- ACK, W=1, C=1 ---| C=1 2789 (End) 2791 Figure 28: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2792 no lost SCHC Fragment. 2794 Figure 29 illustrates the transmission in ACK-on-Error mode of a SCHC 2795 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2796 WINDOW_SIZE=7 and three lost SCHC Fragments. 2798 Sender Receiver 2799 |-----W=0, FCN=6----->| 2800 |-----W=0, FCN=5----->| 2801 |-----W=0, FCN=4--X-->| 2802 |-----W=0, FCN=3----->| 2803 |-----W=0, FCN=2--X-->| 2804 |-----W=0, FCN=1----->| 2805 |-----W=0, FCN=0----->| 6543210 2806 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2807 |-----W=0, FCN=4----->| 2808 |-----W=0, FCN=2----->| 2809 (no ACK) 2810 |-----W=1, FCN=6----->| 2811 |-----W=1, FCN=5----->| 2812 |-----W=1, FCN=4--X-->| 2813 |- W=1, FCN=7 + RCS ->| Integrity check: failure 2814 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 2815 |-----W=1, FCN=4----->| Integrity check: success 2816 |<-- ACK, W=1, C=1 ---| C=1 2817 (End) 2819 Figure 29: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2820 lost SCHC Fragments. 2822 Figure 30 shows an example of a transmission in ACK-on-Error mode of 2823 a SCHC Packet fragmented in 73 tiles, with N=5, WINDOW_SIZE=28, M=2 2824 and 3 lost SCHC Fragments. 2826 Sender Receiver 2827 |-----W=0, FCN=27----->| 4 tiles sent 2828 |-----W=0, FCN=23----->| 4 tiles sent 2829 |-----W=0, FCN=19----->| 4 tiles sent 2830 |-----W=0, FCN=15--X-->| 4 tiles sent (not received) 2831 |-----W=0, FCN=11----->| 4 tiles sent 2832 |-----W=0, FCN=7 ----->| 4 tiles sent 2833 |-----W=0, FCN=3 ----->| 4 tiles sent 2834 |-----W=1, FCN=27----->| 4 tiles sent 2835 |-----W=1, FCN=23----->| 4 tiles sent 2836 |-----W=1, FCN=19----->| 4 tiles sent 2837 |-----W=1, FCN=15----->| 4 tiles sent 2838 |-----W=1, FCN=11----->| 4 tiles sent 2839 |-----W=1, FCN=7 ----->| 4 tiles sent 2840 |-----W=1, FCN=3 --X-->| 4 tiles sent (not received) 2841 |-----W=2, FCN=27----->| 4 tiles sent 2842 |-----W=2, FCN=23----->| 4 tiles sent 2843 ^ |-----W=2, FCN=19----->| 1 tile sent 2844 | |-----W=2, FCN=18----->| 1 tile sent 2845 | |-----W=2, FCN=17----->| 1 tile sent 2846 |-----W=2, FCN=16----->| 1 tile sent 2847 s |-----W=2, FCN=15----->| 1 tile sent 2848 m |-----W=2, FCN=14----->| 1 tile sent 2849 a |-----W=2, FCN=13--X-->| 1 tile sent (not received) 2850 l |-----W=2, FCN=12----->| 1 tile sent 2851 l |---W=2, FCN=31 + RCS->| Integrity check: failure 2852 e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 2853 r |-----W=0, FCN=15----->| 1 tile sent 2854 |-----W=0, FCN=14----->| 1 tile sent 2855 L |-----W=0, FCN=13----->| 1 tile sent 2856 2 |-----W=0, FCN=12----->| 1 tile sent 2857 |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 2858 M |-----W=1, FCN=3 ----->| 1 tile sent 2859 T |-----W=1, FCN=2 ----->| 1 tile sent 2860 U |-----W=1, FCN=1 ----->| 1 tile sent 2861 |-----W=1, FCN=0 ----->| 1 tile sent 2862 | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 2863 | |-----W=2, FCN=13----->| Integrity check: success 2864 V |<--- ACK, W=2, C=1 ---| C=1 2865 (End) 2867 Figure 30: ACK-on-Error mode, variable MTU. 2869 In this example, the L2 MTU becomes reduced just before sending the 2870 "W=2, FCN=19" fragment, leaving space for only 1 tile in each 2871 forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are 2872 carried by a total of 25 SCHC Fragments, the last 9 being of smaller 2873 size. 2875 Note: other sequences of events (e.g. regarding when ACKs are sent by 2876 the Receiver) are also allowed by this specification. Profiles may 2877 restrict this flexibility. 2879 Figure 31 illustrates the transmission in ACK-Always mode of a SCHC 2880 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with 2881 N=3, WINDOW_SIZE=7 and no loss. 2883 Sender Receiver 2884 |-----W=0, FCN=6----->| 2885 |-----W=0, FCN=5----->| 2886 |-----W=0, FCN=4----->| 2887 |-----W=0, FCN=3----->| 2888 |-----W=0, FCN=2----->| 2889 |-----W=0, FCN=1----->| 2890 |-----W=0, FCN=0----->| 2891 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2892 |-----W=1, FCN=6----->| 2893 |-----W=1, FCN=5----->| 2894 |-----W=1, FCN=4----->| 2895 |--W=1, FCN=7 + RCS-->| Integrity check: success 2896 |<-- ACK, W=1, C=1 ---| C=1 2897 (End) 2899 Figure 31: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, no 2900 loss. 2902 Figure 32 illustrates the transmission in ACK-Always mode of a SCHC 2903 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, 2904 WINDOW_SIZE=7 and three lost SCHC Fragments. 2906 Sender Receiver 2907 |-----W=0, FCN=6----->| 2908 |-----W=0, FCN=5----->| 2909 |-----W=0, FCN=4--X-->| 2910 |-----W=0, FCN=3----->| 2911 |-----W=0, FCN=2--X-->| 2912 |-----W=0, FCN=1----->| 2913 |-----W=0, FCN=0----->| 6543210 2914 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2915 |-----W=0, FCN=4----->| 2916 |-----W=0, FCN=2----->| 2917 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2918 |-----W=1, FCN=6----->| 2919 |-----W=1, FCN=5----->| 2920 |-----W=1, FCN=4--X-->| 2921 |--W=1, FCN=7 + RCS-->| Integrity check: failure 2922 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001 2923 |-----W=1, FCN=4----->| Integrity check: success 2924 |<-- ACK, W=1, C=1 ---| C=1 2925 (End) 2927 Figure 32: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, 2928 three lost SCHC Fragments. 2930 Figure 33 illustrates the transmission in ACK-Always mode of a SCHC 2931 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2932 WINDOW_SIZE=7, three lost SCHC Fragments and only one retry needed to 2933 recover each lost SCHC Fragment. 2935 Sender Receiver 2936 |-----W=0, FCN=6----->| 2937 |-----W=0, FCN=5----->| 2938 |-----W=0, FCN=4--X-->| 2939 |-----W=0, FCN=3--X-->| 2940 |-----W=0, FCN=2--X-->| 2941 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2942 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2943 |-----W=0, FCN=4----->| Integrity check: failure 2944 |-----W=0, FCN=3----->| Integrity check: failure 2945 |-----W=0, FCN=2----->| Integrity check: success 2946 |<-- ACK, W=0, C=1 ---| C=1 2947 (End) 2949 Figure 33: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, 2950 three lost SCHC Fragments. 2952 Figure 34 illustrates the transmission in ACK-Always mode of a SCHC 2953 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2954 WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK 2955 lost. 2957 Sender Receiver 2958 |-----W=0, FCN=6----->| 2959 |-----W=0, FCN=5----->| 2960 |-----W=0, FCN=4--X-->| 2961 |-----W=0, FCN=3--X-->| 2962 |-----W=0, FCN=2--X-->| 2963 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2964 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2965 |-----W=0, FCN=4----->| Integrity check: failure 2966 |-----W=0, FCN=3----->| Integrity check: failure 2967 |-----W=0, FCN=2----->| Integrity check: success 2968 |<-X-ACK, W=0, C=1 ---| C=1 2969 timeout | | 2970 |--- W=0, ACK REQ --->| ACK REQ 2971 |<-- ACK, W=0, C=1 ---| C=1 2972 (End) 2974 Figure 34: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, SCHC 2975 ACK loss. 2977 Figure 35 illustrates the transmission in ACK-Always mode of a SCHC 2978 Packet fragmented in 6 tiles, with N=3, WINDOW_SIZE=7, with three 2979 lost SCHC Fragments, and one retransmitted SCHC Fragment lost again. 2981 Sender Receiver 2982 |-----W=0, FCN=6----->| 2983 |-----W=0, FCN=5----->| 2984 |-----W=0, FCN=4--X-->| 2985 |-----W=0, FCN=3--X-->| 2986 |-----W=0, FCN=2--X-->| 2987 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2988 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2989 |-----W=0, FCN=4----->| Integrity check: failure 2990 |-----W=0, FCN=3----->| Integrity check: failure 2991 |-----W=0, FCN=2--X-->| 2992 timeout| | 2993 |--- W=0, ACK REQ --->| ACK REQ 2994 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 2995 |-----W=0, FCN=2----->| Integrity check: success 2996 |<-- ACK, W=0, C=1 ---| C=1 2997 (End) 2999 Figure 35: ACK-Always mode, 6 tiles, retransmitted SCHC Fragment lost 3000 again. 3002 Figure 36 illustrates the transmission in ACK-Always mode of a SCHC 3003 Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, 3004 WINDOW_SIZE=24 and two lost SCHC Fragments. 3006 Sender Receiver 3007 |-----W=0, FCN=23----->| 3008 |-----W=0, FCN=22----->| 3009 |-----W=0, FCN=21--X-->| 3010 |-----W=0, FCN=20----->| 3011 |-----W=0, FCN=19----->| 3012 |-----W=0, FCN=18----->| 3013 |-----W=0, FCN=17----->| 3014 |-----W=0, FCN=16----->| 3015 |-----W=0, FCN=15----->| 3016 |-----W=0, FCN=14----->| 3017 |-----W=0, FCN=13----->| 3018 |-----W=0, FCN=12----->| 3019 |-----W=0, FCN=11----->| 3020 |-----W=0, FCN=10--X-->| 3021 |-----W=0, FCN=9 ----->| 3022 |-----W=0, FCN=8 ----->| 3023 |-----W=0, FCN=7 ----->| 3024 |-----W=0, FCN=6 ----->| 3025 |-----W=0, FCN=5 ----->| 3026 |-----W=0, FCN=4 ----->| 3027 |-----W=0, FCN=3 ----->| 3028 |-----W=0, FCN=2 ----->| 3029 |-----W=0, FCN=1 ----->| 3030 |-----W=0, FCN=0 ----->| 3031 | | 3032 |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 3033 |-----W=0, FCN=21----->| 3034 |-----W=0, FCN=10----->| 3035 |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 3036 |-----W=1, FCN=23----->| 3037 |-----W=1, FCN=22----->| 3038 |-----W=1, FCN=21----->| 3039 |--W=1, FCN=31 + RCS-->| Integrity check: success 3040 |<--- ACK, W=1, C=1 ---| C=1 3041 (End) 3043 Figure 36: ACK-Always mode, 28 tiles, one tile per SCHC Fragment, 3044 lost SCHC Fragments. 3046 Appendix C. Fragmentation State Machines 3048 The fragmentation state machines of the sender and the receiver, one 3049 for each of the different reliability modes, are described in the 3050 following figures: 3052 +===========+ 3053 +------------+ Init | 3054 | FCN=0 +===========+ 3055 | No Window 3056 | No Bitmap 3057 | +-------+ 3058 | +========+==+ | More Fragments 3059 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 3060 +--------> | Send | send Fragment (FCN=0) 3061 +===+=======+ 3062 | last fragment 3063 | ~~~~~~~~~~~~ 3064 | FCN = 1 3065 v send fragment+RCS 3066 +============+ 3067 | END | 3068 +============+ 3070 Figure 37: Sender State Machine for the No-ACK Mode 3072 +------+ Not All-1 3073 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 3074 | + <--+ set Inactivity Timer 3075 | RCV Frag +-------+ 3076 +=+===+======+ |All-1 & 3077 All-1 & | | |RCS correct 3078 RCS wrong | |Inactivity | 3079 | |Timer Exp. | 3080 v | | 3081 +==========++ | v 3082 | Error |<-+ +========+==+ 3083 +===========+ | END | 3084 +===========+ 3086 Figure 38: Receiver State Machine for the No-ACK Mode 3087 +=======+ 3088 | INIT | FCN!=0 & more frags 3089 | | ~~~~~~~~~~~~~~~~~~~~~~ 3090 +======++ +--+ send Window + frag(FCN) 3091 W=0 | | | FCN- 3092 Clear lcl_bm | | v set lcl_bm 3093 FCN=max value | ++==+========+ 3094 +> | | 3095 +---------------------> | SEND | 3096 | +==+===+=====+ 3097 | FCN==0 & more frags | | last frag 3098 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 3099 | set lcl_bm | | set lcl_bm 3100 | send wnd + frag(all-0) | | send wnd+frag(all-1)+RCS 3101 | set Retrans_Timer | | set Retrans_Timer 3102 | | | 3103 |Recv_wnd == wnd & | | 3104 |lcl_bm==recv_bm & | | +----------------------+ 3105 |more frag | | | lcl_bm!=rcv-bm | 3106 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 3107 |Stop Retrans_Timer | | | Attempt++ v 3108 |clear lcl_bm v v | +=====+=+ 3109 |window=next_window +====+===+==+===+ |Resend | 3110 +---------------------+ | |Missing| 3111 +----+ Wait | |Frag | 3112 not expected wnd | | Bitmap | +=======+ 3113 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 3114 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 3115 | | | ^ ^ |reSend(empty)All-* | 3116 | | | | | |Set Retrans_Timer | 3117 | | | | +--+Attempt++ | 3118 C_bit==1 & | | | +-------------------------+ 3119 Recv_window==window & | | | all missing frags sent 3120 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 3121 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 3122 Stop Retrans_Timer| | | 3123 +=============+ | | | 3124 | END +<--------+ | | 3125 +=============+ | | Attempt > MAX_ACK_REQUESTS 3126 All-1 Window & | | ~~~~~~~~~~~~~~~~~~ 3127 C_bit ==0 & | v Send Abort 3128 lcl_bm==recv_bm | +=+===========+ 3129 ~~~~~~~~~~~~ +>| ERROR | 3130 Send Abort +=============+ 3132 Figure 39: Sender State Machine for the ACK-Always Mode 3134 Not All- & w=expected +---+ +---+w = Not expected 3135 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 3136 Set lcl_bm(FCN) | v v |discard 3137 ++===+===+===+=+ 3138 +---------------------+ Rcv +--->* ABORT 3139 | +------------------+ Window | 3140 | | +=====+==+=====+ 3141 | | All-0 & w=expect | ^ w =next & not-All 3142 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 3143 | | set lcl_bm(FCN) | |expected = next window 3144 | | send lcl_bm | |Clear lcl_bm 3145 | | | | 3146 | | w=expected & not-All | | 3147 | | ~~~~~~~~~~~~~~~~~~ | | 3148 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0 3149 | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~ 3150 | | send lcl_bm | | | | | | expected = nxt wnd 3151 | | v | v | | | Clear lcl_bm 3152 | |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN) 3153 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm 3154 | | discard +--| Next | 3155 | | All-0 +---------+ Window +--->* ABORT 3156 | | ~~~~~ +-------->+========+=++ 3157 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 3158 | | & RCS wrong| | & RCS right 3159 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 3160 | | set lcl_bm(FCN)| |set lcl_bm(FCN) 3161 | | send lcl_bm| |send lcl_bm 3162 | | | +----------------------+ 3163 | |All-1 & w=expected | | 3164 | |& RCS wrong v +---+ w=expected & | 3165 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | RCS wrong | 3166 | |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ | 3167 | |send lcl_bm | Wait End | set lcl_bm(FCN)| 3168 | +--------------------->+ +--->* ABORT | 3169 | +===+====+=+-+ All-1&RCS wrong| 3170 | | ^ | ~~~~~~~~~~~~~~~| 3171 | w=expected & RCS right | +---+ send lcl_bm | 3172 | ~~~~~~~~~~~~~~~~~~~~~~ | | 3173 | set lcl_bm(FCN) | +-+ Not All-1 | 3174 | send lcl_bm | | | ~~~~~~~~~ | 3175 | | | | discard | 3176 |All-1&w=expected & RCS right | | | | 3177 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 3178 |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 3179 |send lcl_bm | +<+Send lcl_bm | 3180 +-------------------------->+ END | | 3181 +==========+<---------------+ 3183 --->* ABORT 3184 ~~~~~~~ 3185 Inactivity_Timer = expires 3186 When DWL 3187 IF Inactivity_Timer expires 3188 Send DWL Request 3189 Attempt++ 3191 Figure 40: Receiver State Machine for the ACK-Always Mode 3193 +=======+ 3194 | | 3195 | INIT | 3196 | | FCN!=0 & more frags 3197 +======++ ~~~~~~~~~~~~~~~~~~~~~~ 3198 Frag RuleID trigger | +--+ Send cur_W + frag(FCN); 3199 ~~~~~~~~~~~~~~~~~~~ | | | FCN--; 3200 cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp] 3201 clear [cur_W, Bmp_n];| | v 3202 clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND 3203 +->+ | cur_W==rcv_W & 3204 **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp 3205 +-------------------------->+ | & more frags 3206 | +----------------------->+ | ~~~~~~~~~~~~ 3207 | | ++===+=========+ cur_W++; 3208 | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] 3209 | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~ 3210 | | set cur_Bmp; | |set [cur_W, Bmp_n]; 3211 | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+RCS; 3212 | | set Retrans_Timer| |set Retrans_Timer 3213 | | | | +-----------------------------------+ 3214 | |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| 3215 | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ | 3216 | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W | 3217 | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &| 3218 | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp| 3219 | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| 3220 | +-------------------+ | | Resend | Attempts++;| 3221 +----------------------+ Wait x ACK | | Missing | W=Wn | 3222 +--------------------->+ | | Frags(W) +<-------------+ 3223 | rcv_W==Wn &+-+ | +======+====+ 3224 | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ | 3225 | ~~~~~~~~~~~~~~| ^ | | | ^ | 3226 | send (cur_W,+--+ | | | +-------------+ 3227 | ALL-0-empty) | | | all missing frag sent(W) 3228 | | | | ~~~~~~~~~~~~~~~~~ 3229 | Retrans_Timer expires &| | | set Retrans_Timer 3230 | No more Frags| | | 3231 | ~~~~~~~~~~~~~~| | | 3232 | stop Retrans_Timer;| | | 3233 |(re)send frag(All-1)+RCS | | | 3234 +-------------------------+ | | 3235 cur_W==rcv_W&| | 3236 [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS 3237 No more Frags & RCS flag==OK| | ~~~~~~~~~~ 3238 ~~~~~~~~~~~~~~~~~~| | send Abort 3239 +=========+stop Retrans_Timer| | +===========+ 3240 | END +<-----------------+ +->+ ERROR | 3241 +=========+ +===========+ 3243 Figure 41: Sender State Machine for the ACK-on-Error Mode 3245 This is an example only. It is not normative. The specification in 3246 Section 8.4.3.1 allows for sequences of operations different from the 3247 one shown here. 3249 +=======+ New frag RuleID received 3250 | | ~~~~~~~~~~~~~ 3251 | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); 3252 +=======+ |sync=0 3253 | 3254 Not All* & rcv_W==cur_W+---+ | +---+ 3255 ~~~~~~~~~~~~~~~~~~~~ | | | | (E) 3256 set[cur_W,Bmp_n(FCN)]| v v v | 3257 ++===+=+=+===+=+ 3258 +----------------------+ +--+ All-0&Full[cur_W,Bmp_n] 3259 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~ 3260 | +-------------------+ +<-+ cur_W++;set Inact_timer; 3261 | | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n] 3262 | | All-0 empty(Wn)| | | | ^ ^ 3263 | | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0; 3264 | | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n]) 3265 | | | | | |& All* || last_miss_frag 3266 | | | | | |~~~~~~~~~~~~~~~~~~~~~~ 3267 | | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); 3268 | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) 3269 | |&no_full([cur_W,Bmp_n])| |(E)| 3270 | | ~~~~~~~~~~~~~~~~ | | | | +========+ 3271 | | sendACK([cur_W,Bmp_n])| | | | | Error/ | 3272 | | | | | | +----+ | Abort | 3273 | | v v | | | | +===+====+ 3274 | | +===+=+=+=+===+=+ (D) ^ 3275 | | +--+ Wait x | | | 3276 | | All-0 empty(Wn)+->| Missing Frags |<-+ | 3277 | | ~~~~~~~~~~~~~~ +=============+=+ | 3278 | | sendACK([Wn,Bmp_n]) +--------------+ 3279 | | *ABORT 3280 v v 3281 (A)(B) 3282 (D) All* || last_miss_frag 3283 (C) All* & sync>0 & rcv_W!=cur_W & sync>0 3284 ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) 3285 Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ 3286 sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; 3287 sendACK([Wn,Bmp_n]);sync-- 3289 ABORT-->* Uplink Only & 3290 Inact_Timer expires 3291 (E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS 3292 ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ 3293 sync++; cur_W=rcv_W; send Abort 3294 set[cur_W,Bmp_n(FCN)] 3296 (A)(B) 3297 | | 3298 | | All-1 & rcv_W==cur_W & RCS!=OK All-0 empty(Wn) 3299 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~ 3300 | | sendACK([cur_W,Bmp_n],C=0) | v sendACK([Wn,Bmp_n]) 3301 | | +===========+=++ 3302 | +--------------------->+ Wait End +-+ 3303 | +=====+=+====+=+ | All-1 3304 | rcv_W==cur_W & RCS==OK | | ^ | & rcv_W==cur_W 3305 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & RCS!=OK 3306 | sendACK([cur_W,Bmp_n],C=1) | | ~~~~~~~~~~~~~~~~~~~ 3307 | | | sendACK([cur_W,Bmp_n],C=0); 3308 | | | Attempts++ 3309 |All-1 & Full([cur_W,Bmp_n]) | | 3310 |& RCS==OK & sync==0 | +-->* ABORT 3311 |~~~~~~~~~~~~~~~~~~~ v 3312 |sendACK([cur_W,Bmp_n],C=1) +=+=========+ 3313 +---------------------------->+ END | 3314 +===========+ 3316 Figure 42: Receiver State Machine for the ACK-on-Error Mode 3318 Appendix D. SCHC Parameters 3320 This section lists the information that needs to be provided in the 3321 LPWAN technology-specific documents. 3323 o Most common uses cases, deployment scenarios 3325 o Mapping of the SCHC architectural elements onto the LPWAN 3326 architecture 3328 o Assessment of LPWAN integrity checking 3330 o Various potential channel conditions for the technology and the 3331 corresponding recommended use of SCHC C/D and F/R 3333 This section lists the parameters that need to be defined in the 3334 Profile. 3336 o Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs, 3337 number of Rules, the way the Rule ID is transmitted 3339 o maximum packet size that should ever be reconstructed by SCHC 3340 Decompression (MAX_PACKET_SIZE). See Section 12. 3342 o Padding: size of the L2 Word (for most LPWAN technologies, this 3343 would be a byte; for some technologies, a bit) 3345 o Decision to use SCHC fragmentation mechanism or not. If yes: 3347 * reliability mode(s) used, in which cases (e.g. based on link 3348 channel condition) 3350 * Rule ID values assigned to each mode in use 3352 * presence and number of bits for DTag (T) for each Rule ID value 3354 * support for interleaved packet transmission, to what extent 3356 * WINDOW_SIZE, for modes that use windows 3358 * number of bits for W (M) for each Rule ID value, for modes that 3359 use windows 3361 * number of bits for FCN (N) for each Rule ID value 3363 * size of RCS and algorithm for its computation, for each Rule 3364 ID, if different from the default CRC32. Byte fill-up with 3365 zeroes or other mechanism, to be specified. 3367 * Retransmission Timer duration for each Rule ID value, if 3368 applicable to the SCHC F/R mode 3370 * Inactivity Timer duration for each Rule ID value, if applicable 3371 to the SCHC F/R mode 3373 * MAX_ACK_REQUEST value for each Rule ID value, if applicable to 3374 the SCHC F/R mode 3376 o if L2 Word is wider than a bit and SCHC fragmentation is used, 3377 value of the padding bits (0 or 1). This is needed because the 3378 padding bits of the last fragment are included in the RCS 3379 computation. 3381 A Profile may define a delay to be added after each SCHC message 3382 transmission for compliance with local regulations or other 3383 constraints imposed by the applications. 3385 o In some LPWAN technologies, as part of energy-saving techniques, 3386 downlink transmission is only possible immediately after an uplink 3387 transmission. In order to avoid potentially high delay in the 3388 downlink transmission of a fragmented SCHC Packet, the SCHC 3389 Fragment receiver may perform an uplink transmission as soon as 3390 possible after reception of a SCHC Fragment that is not the last 3391 one. Such uplink transmission may be triggered by the L2 (e.g. an 3392 L2 ACK sent in response to a SCHC Fragment encapsulated in a L2 3393 PDU that requires an L2 ACK) or it may be triggered from an upper 3394 layer. 3396 o the following parameters need to be addressed in documents other 3397 than this one but not necessarily in the LPWAN technology-specific 3398 documents: 3400 * The way the Contexts are provisioned 3402 * The way the Rules are generated 3404 Appendix E. Supporting multiple window sizes for fragmentation 3406 For ACK-Always or ACK-on-Error, implementers may opt to support a 3407 single window size or multiple window sizes. The latter, when 3408 feasible, may provide performance optimizations. For example, a 3409 large window size should be used for packets that need to be split 3410 into a large number of tiles. However, when the number of tiles 3411 required to carry a packet is low, a smaller window size, and thus a 3412 shorter Bitmap, may be sufficient to provide reception status on all 3413 tiles. If multiple window sizes are supported, the Rule ID may 3414 signal the window size in use for a specific packet transmission. 3416 The same window size MUST be used for the transmission of all tiles 3417 that belong to the same SCHC Packet. 3419 Appendix F. Downlink SCHC Fragment transmission 3421 For downlink transmission of a fragmented SCHC Packet in ACK-Always 3422 mode, the SCHC Fragment receiver may support timer-based SCHC ACK 3423 retransmission. In this mechanism, the SCHC Fragment receiver 3424 initializes and starts a timer (the Inactivity Timer is used) after 3425 the transmission of a SCHC ACK, except when the SCHC ACK is sent in 3426 response to the last SCHC Fragment of a packet (All-1 fragment). In 3427 the latter case, the SCHC Fragment receiver does not start a timer 3428 after transmission of the SCHC ACK. 3430 If, after transmission of a SCHC ACK that is not an All-1 fragment, 3431 and before expiration of the corresponding Inactivity timer, the SCHC 3432 Fragment receiver receives a SCHC Fragment that belongs to the 3433 current window (e.g. a missing SCHC Fragment from the current window) 3434 or to the next window, the Inactivity timer for the SCHC ACK is 3435 stopped. However, if the Inactivity timer expires, the SCHC ACK is 3436 resent and the Inactivity timer is reinitialized and restarted. 3438 The default initial value for the Inactivity Timer, as well as the 3439 maximum number of retries for a specific SCHC ACK, denoted 3440 MAX_ACK_RETRIES, are not defined in this document, and need to be 3441 defined in a Profile. The initial value of the Inactivity timer is 3442 expected to be greater than that of the Retransmission timer, in 3443 order to make sure that a (buffered) SCHC Fragment to be 3444 retransmitted can find an opportunity for that transmission. One 3445 exception to this recommendation is the special case of the All-1 3446 SCHC Fragment transmission. 3448 When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it 3449 starts its Retransmission Timer with a large timeout value (e.g. 3450 several times that of the initial Inactivity Timer). If a SCHC ACK 3451 is received before expiration of this timer, the SCHC Fragment sender 3452 retransmits any lost SCHC Fragments reported by the SCHC ACK, or if 3453 the SCHC ACK confirms successful reception of all SCHC Fragments of 3454 the last window, the transmission of the fragmented SCHC Packet is 3455 considered complete. If the timer expires, and no SCHC ACK has been 3456 received since the start of the timer, the SCHC Fragment sender 3457 assumes that the All-1 SCHC Fragment has been successfully received 3458 (and possibly, the last SCHC ACK has been lost: this mechanism 3459 assumes that the Retransmission Timer for the All-1 SCHC Fragment is 3460 long enough to allow several SCHC ACK retries if the All-1 SCHC 3461 Fragment has not been received by the SCHC Fragment receiver, and it 3462 also assumes that it is unlikely that several ACKs become all lost). 3464 Authors' Addresses 3466 Ana Minaburo 3467 Acklio 3468 1137A avenue des Champs Blancs 3469 35510 Cesson-Sevigne Cedex 3470 France 3472 Email: ana@ackl.io 3474 Laurent Toutain 3475 IMT-Atlantique 3476 2 rue de la Chataigneraie 3477 CS 17607 3478 35576 Cesson-Sevigne Cedex 3479 France 3481 Email: Laurent.Toutain@imt-atlantique.fr 3482 Carles Gomez 3483 Universitat Politecnica de Catalunya 3484 C/Esteve Terradas, 7 3485 08860 Castelldefels 3486 Spain 3488 Email: carlesgo@entel.upc.edu 3490 Dominique Barthel 3491 Orange Labs 3492 28 chemin du Vieux Chene 3493 38243 Meylan 3494 France 3496 Email: dominique.barthel@orange.com 3498 Juan Carlos Zuniga 3499 SIGFOX 3500 425 rue Jean Rostand 3501 Labege 31670 3502 France 3504 Email: JuanCarlos.Zuniga@sigfox.com