idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-21.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 23, 2019) is 1738 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 24, 2020 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 D. Barthel 9 Orange Labs 10 JC. Zuniga 11 SIGFOX 12 July 23, 2019 14 Static Context Header Compression (SCHC) and fragmentation for LPWAN, 15 application to UDP/IPv6 16 draft-ietf-lpwan-ipv6-static-context-hc-21 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 24, 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 . . . . . . . . . . . . . . . . . . . 51 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 . . . . . . . . . . . . 68 147 Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 74 148 Appendix E. Supporting multiple window sizes for fragmentation . 76 149 Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 76 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 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 ECN functionality depends on both bits of the ECN field, which are 2295 the 2 LSBs of this field, hence sending only a single LSB of this 2296 field is NOT RECOMMENDED. 2298 10.4. Payload Length field 2300 This field can be elided for the transmission on the LPWAN network. 2301 The SCHC C/D recomputes the original payload length value. In the 2302 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 2303 "compute-*". 2305 10.5. Next Header field 2307 If the Next Header field does not vary and is known by both sides, 2308 the Field Descriptor in the Rule SHOULD contain a TV with this Next 2309 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 2310 sent". 2312 Otherwise, TV is not set in the Field Descriptor, MO is set to 2313 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 2314 list MAY also be used. 2316 10.6. Hop Limit field 2318 The field behavior for this field is different for uplink (Up) and 2319 downlink (Dw). In Up, since there is no IP forwarding between the 2320 Dev and the SCHC C/D, the value is relatively constant. On the other 2321 hand, the Dw value depends on Internet routing and can change more 2322 frequently. The Direction Indicator (DI) can be used to distinguish 2323 both directions: 2325 o in the Up, elide the field: the TV in the Field Descriptor is set 2326 to the known constant value, the MO is set to "equal" and the CDA 2327 is set to "not-sent". 2329 o in the Dw, the Hop Limit is elided for transmission and forced to 2330 1 at the receiver, by setting TV to 1, MO to "ignore" and CDA to 2331 "not-sent". This prevents any further forwarding. 2333 10.7. IPv6 addresses fields 2335 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 2336 long fields; one for the prefix and one for the Interface Identifier 2337 (IID). These fields SHOULD be compressed. To allow for a single 2338 Rule being used for both directions, these values are identified by 2339 their role (Dev or App) and not by their position in the header 2340 (source or destination). 2342 10.7.1. IPv6 source and destination prefixes 2344 Both ends MUST be configured with the appropriate prefixes. For a 2345 specific flow, the source and destination prefixes can be unique and 2346 stored in the Context. In that case, the TV for the source and 2347 destination prefixes contain the values, the MO is set to "equal" and 2348 the CDA is set to "not-sent". 2350 If the Rule is intended to compress packets with different prefix 2351 values, match-mapping SHOULD be used. The different prefixes are 2352 listed in the TV, the MO is set to "match-mapping" and the CDA is set 2353 to "mapping-sent". See Figure 26. 2355 Otherwise, the TV is not set, the MO is set to "ignore" and the CDA 2356 is set to "value-sent". 2358 10.7.2. IPv6 source and destination IID 2360 If the Dev or App IID are based on an LPWAN address, then the IID can 2361 be reconstructed with information coming from the LPWAN header. In 2362 that case, the TV is not set, the MO is set to "ignore" and the CDA 2363 is set to "DevIID" or "AppIID". On LPWAN technologies where the 2364 frames carry a single identifier (corresponding to the Dev.), AppIID 2365 cannot be used. 2367 As described in [RFC8065], it may be undesirable to build the Dev 2368 IPv6 IID out of the Dev address. Another static value is used 2369 instead. In that case, the TV contains the static value, the MO 2370 operator is set to "equal" and the CDA is set to "not-sent". 2371 [RFC7217] provides some methods to derive this static identifier. 2373 If several IIDs are possible, then the TV contains the list of 2374 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 2375 "mapping-sent". 2377 It may also happen that the IID variability only expresses itself on 2378 a few bytes. In that case, the TV is set to the stable part of the 2379 IID, the MO is set to "MSB" and the CDA is set to "LSB". 2381 Finally, the IID can be sent in its entirety on the LPWAN. In that 2382 case, the TV is not set, the MO is set to "ignore" and the CDA is set 2383 to "value-sent". 2385 10.8. IPv6 extensions 2387 This document does not provide recommendations on how to compress 2388 IPv6 extensions. 2390 10.9. UDP source and destination port 2392 To allow for a single Rule being used for both directions, the UDP 2393 port values are identified by their role (Dev or App) and not by 2394 their position in the header (source or destination). The SCHC C/D 2395 MUST be aware of the traffic direction (Uplink, Downlink) to select 2396 the appropriate field. The following Rules apply for Dev and App 2397 port numbers. 2399 If both ends know the port number, it can be elided. The TV contains 2400 the port number, the MO is set to "equal" and the CDA is set to "not- 2401 sent". 2403 If the port variation is on few bits, the TV contains the stable part 2404 of the port number, the MO is set to "MSB" and the CDA is set to 2405 "LSB". 2407 If some well-known values are used, the TV can contain the list of 2408 these values, the MO is set to "match-mapping" and the CDA is set to 2409 "mapping-sent". 2411 Otherwise the port numbers are sent over the LPWAN. The TV is not 2412 set, the MO is set to "ignore" and the CDA is set to "value-sent". 2414 10.10. UDP length field 2416 The UDP length can be computed from the received data. The TV is not 2417 set, the MO is set to "ignore" and the CDA is set to "compute-*". 2419 10.11. UDP Checksum field 2421 The UDP checksum operation is mandatory with IPv6 for most packets 2422 but there are exceptions [RFC8200]. 2424 For instance, protocols that use UDP as a tunnel encapsulation may 2425 enable zero-checksum mode for a specific port (or set of ports) for 2426 sending and/or receiving. [RFC8200] requires any node implementing 2427 zero-checksum mode to follow the requirements specified in 2428 "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero 2429 Checksums" [RFC6936]. 2431 6LoWPAN Header Compression [RFC6282] also specifies that a UDP 2432 checksum can be elided by the compressor and re-computed by the 2433 decompressor when an upper layer guarantees the integrity of the UDP 2434 payload and pseudo-header. A specific example of this is when a 2435 Message Integrity Check protects the compressed message between the 2436 compressor that elides the UDP checksum and the decompressor that 2437 computes it, with a strength that is identical or better to the UDP 2438 checksum. 2440 Similarly, a SCHC compressor MAY elide the UDP checksum when another 2441 layer guarantees at least equal integrity protection for the UDP 2442 payload and the pseudo-header. In this case, the TV is not set, the 2443 MO is set to "ignore" and the CDA is set to "compute-*". 2445 In particular, when SCHC fragmentation is used, a fragmentation RCS 2446 of 2 bytes or more provides equal or better protection than the UDP 2447 checksum; in that case, if the compressor is collocated with the 2448 fragmentation point and the decompressor is collocated with the 2449 packet reassembly point, and if the SCHC Packet is fragmented even 2450 when it would fit unfragmented in the L2 MTU, then the compressor MAY 2451 verify and then elide the UDP checksum. Whether and when the UDP 2452 Checksum is elided is to be specified in the Profile. 2454 Since the compression happens before the fragmentation, implementors 2455 should understand the risks when dealing with unprotected data below 2456 the transport layer and take special care when manipulating that 2457 data. 2459 In other cases, the checksum SHOULD be explicitly sent. The TV is 2460 not set, the MO is set to "ignore" and the CDA is set to "value- 2461 sent". 2463 11. IANA Considerations 2465 This document has no request to IANA. 2467 12. Security considerations 2469 Wireless networks are subjects to various sorts of attacks, which are 2470 not specific to SCHC. In this section, we'll assume that an attacker 2471 was able to break into the network despite the latter's security 2472 measures and that it can now send packets to a target node. What is 2473 specific to SCHC is the amplification of the effects that this break- 2474 in could allow. Our analysis equally applies to legitimate nodes 2475 "going crazy". 2477 12.1. Security considerations for SCHC Compression/Decompression 2479 Let's assume that an attacker is able to send a forged SCHC Packet to 2480 a SCHC Decompressor. 2482 Let's first consider the case where the Rule ID contained in that 2483 forged SCHC Packet does not correspond to a Rule allocated in the 2484 Rule table. An implementation should detect that the Rule ID is 2485 invalid and should silently drop the offending SCHC Packet. 2487 Let's now consider that the Rule ID corresponds to a Rule in the 2488 table. With the CDAs defined in this document, the reconstructed 2489 packet is at most a constant number of bits bigger than the SCHC 2490 Packet that was received. This assumes that the compute-* 2491 decompression actions produce a bounded number of bits, irrespective 2492 of the incoming SCHC Packet. This property is true for IPv6 Length, 2493 UDP Length and UDP Checksum, for which the compute-* CDA is 2494 recommended by this document. 2496 As a consequence, SCHC Decompression does not amplify attacks, beyond 2497 adding a bounded number of bits to the SCHC Packet received. This 2498 bound is determined by the Rule stored in the receiving device. 2500 As a general safety measure, a SCHC Decompressor should never re- 2501 construct a packet larger than MAX_PACKET_SIZE (defined in a Profile, 2502 with 1500 bytes as generic default). 2504 12.2. Security considerations for SCHC Fragmentation/Reassembly 2506 Let's assume that an attacker is able to send to a forged SCHC 2507 Fragment to a SCHC Reassembler. 2509 A node can perform a buffer reservation attack: the receiver will 2510 reserve buffer space for the SCHC Packet. If the implementation has 2511 only one buffer, other incoming fragmented SCHC Packets will be 2512 dropped while the reassembly buffer is occupied during the reassembly 2513 timeout. Once that timeout expires, the attacker can repeat the same 2514 procedure, and iterate, thus creating a denial of service attack. An 2515 implementation may have multiple reassembly buffers. The cost to 2516 mount this attack is linear with the number of buffers at the target 2517 node. Better, the cost for an attacker can be increased if 2518 individual fragments of multiple SCHC Packets can be stored in the 2519 reassembly buffer. The finer grained the reassembly buffer (downto 2520 the smallest tile size), the higher the cost of the attack. If 2521 buffer overload does occur, a smart receiver could selectively 2522 discard SCHC Packets being reassembled based on the sender behavior, 2523 which may help identify which SCHC Fragments have been sent by the 2524 attacker. Another mild counter-measure is for the target to abort 2525 the fragmentation/reassembly session as early as it detects a non- 2526 identical SCHC Fragment duplicate, anticipating for an eventual 2527 corrupt SCHC Packet, so as to save the sender the hassle of sending 2528 the rest of the fragments for this SCHC Packet. 2530 In another type of attack, the malicious node is additionally assumed 2531 to be able to hear an incoming communication destined to the target 2532 node. It can then send a forged SCHC Fragment that looks like it 2533 belongs to a SCHC Packet already being reassembled at the target 2534 node. This can cause the SCHC Packet to be considered corrupt and be 2535 dropped by the receiver. The amplification happens here by a single 2536 spoofed SCHC Fragment rendering a full sequence of legit SCHC 2537 Fragments useless. If the target uses ACK-Always or ACK-on-Error 2538 mode, such a malicious node can also interfere with the 2539 acknowledgement and repetition algorithm of SCHC F/R. A single 2540 spoofed ACK, with all bitmap bits set to 0, will trigger the 2541 repetition of WINDOW_SIZE tiles. This protocol loop amplification 2542 depletes the energy source of the target node and consumes the 2543 channel bandwidth. Similarly, a spoofed ACK REQ will trigger the 2544 sending of a SCHC ACK, which may be much larger than the ACK REQ if 2545 WINDOW_SIZE is large. These consequences should be borne in mind 2546 when defining profiles for SCHC over specific LPWAN technologies. 2548 13. Acknowledgements 2550 Thanks to Sergio Aguilar Romero, Carsten Bormann, David Black, 2551 Philippe Clavier, Daniel Ducuara Beltran Diego Dujovne, Eduardo 2552 Ingles Sanchez, Arunprabhu Kandasamy, Suresh Krishnan, Rahul Jadhav, 2553 Sergio Lopez Bernal, Antony Markovski, Alexander Pelov, Charles 2554 Perkins, Edgar Ramos, Shoichi Sakane, and Pascal Thubert for useful 2555 design consideration and comments. 2557 Carles Gomez has been funded in part by the Spanish Government 2558 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2559 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2560 Government through project TEC2016-79988-P. Part of his contribution 2561 to this work has been carried out during his stay as a visiting 2562 scholar at the Computer Laboratory of the University of Cambridge. 2564 14. References 2566 14.1. Normative References 2568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2569 Requirement Levels", BCP 14, RFC 2119, 2570 DOI 10.17487/RFC2119, March 1997, 2571 . 2573 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2574 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2575 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2576 . 2578 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2579 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2580 May 2017, . 2582 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2583 (IPv6) Specification", STD 86, RFC 8200, 2584 DOI 10.17487/RFC8200, July 2017, 2585 . 2587 14.2. Informative References 2589 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 2590 "Internet Protocol Small Computer System Interface (iSCSI) 2591 Cyclic Redundancy Check (CRC)/Checksum Considerations", 2592 RFC 3385, DOI 10.17487/RFC3385, September 2002, 2593 . 2595 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2596 "Transmission of IPv6 Packets over IEEE 802.15.4 2597 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2598 . 2600 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2601 Header Compression (ROHC) Framework", RFC 5795, 2602 DOI 10.17487/RFC5795, March 2010, 2603 . 2605 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2606 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2607 DOI 10.17487/RFC6282, September 2011, 2608 . 2610 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2611 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2612 February 2014, . 2614 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2615 Interface Identifiers with IPv6 Stateless Address 2616 Autoconfiguration (SLAAC)", RFC 7217, 2617 DOI 10.17487/RFC7217, April 2014, 2618 . 2620 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 2621 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 2622 February 2017, . 2624 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2625 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2626 . 2628 Appendix A. Compression Examples 2630 This section gives some scenarios of the compression mechanism for 2631 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2633 The mechanisms defined in this document can be applied to a Dev that 2634 embeds some applications running over CoAP. In this example, three 2635 flows are considered. The first flow is for the device management 2636 based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 2637 124 for Dev and App, respectively. The second flow will be a CoAP 2638 server for measurements done by the Dev (using ports 5683) and Global 2639 IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is 2640 for legacy applications using different ports numbers, the 2641 destination IPv6 address prefix is gamma::1/64. 2643 Figure 25 presents the protocol stack. IPv6 and UDP are represented 2644 with dotted lines since these protocols are compressed on the radio 2645 link. 2647 Management Data 2648 +----------+---------+---------+ 2649 | CoAP | CoAP | legacy | 2650 +----||----+---||----+---||----+ 2651 . UDP . UDP | UDP | 2652 ................................ 2653 . IPv6 . IPv6 . IPv6 . 2654 +------------------------------+ 2655 | SCHC Header compression | 2656 | and fragmentation | 2657 +------------------------------+ 2658 | LPWAN L2 technologies | 2659 +------------------------------+ 2660 Dev or NGW 2662 Figure 25: Simplified Protocol Stack for LP-WAN 2664 In some LPWAN technologies, only the Devs have a device ID. When 2665 such technologies are used, it is necessary to statically define an 2666 IID for the Link Local address for the SCHC C/D. 2668 Rule 0 2669 +----------------+--+--+--+---------+--------+------------++------+ 2670 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 2671 | | | | | | Opera. | Action ||[bits]| 2672 +----------------+--+--+--+---------+---------------------++------+ 2673 |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | 2674 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2675 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2676 |IPv6 Length |16|1 |Bi| | ignore | compute-* || | 2677 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2678 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2679 |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2680 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2681 |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2682 |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | 2683 +================+==+==+==+=========+========+============++======+ 2684 |UDP DevPort |16|1 |Bi|123 | equal | not-sent || | 2685 |UDP AppPort |16|1 |Bi|124 | equal | not-sent || | 2686 |UDP Length |16|1 |Bi| | ignore | compute-* || | 2687 |UDP checksum |16|1 |Bi| | ignore | compute-* || | 2688 +================+==+==+==+=========+========+============++======+ 2690 Rule 1 2691 +----------------+--+--+--+---------+--------+------------++------+ 2692 | Field |FL|FP|DI| Value | Match | Action || Sent | 2693 | | | | | | Opera. | Action ||[bits]| 2694 +----------------+--+--+--+---------+--------+------------++------+ 2695 |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | 2696 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2697 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2698 |IPv6 Length |16|1 |Bi| | ignore | compute-* || | 2699 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2700 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2701 |IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 | 2702 | | | | |fe80::/64] mapping| || | 2703 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2704 |IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 | 2705 | | | | |alpha/64,| mapping| || | 2706 | | | | |fe80::64]| | || | 2707 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2708 +================+==+==+==+=========+========+============++======+ 2709 |UDP DevPort |16|1 |Bi|5683 | equal | not-sent || | 2710 |UDP AppPort |16|1 |Bi|5683 | equal | not-sent || | 2711 |UDP Length |16|1 |Bi| | ignore | compute-* || | 2712 |UDP checksum |16|1 |Bi| | ignore | compute-* || | 2713 +================+==+==+==+=========+========+============++======+ 2715 Rule 2 2716 +----------------+--+--+--+---------+--------+------------++------+ 2717 | Field |FL|FP|DI| Value | Match | Action || Sent | 2718 | | | | | | Opera. | Action ||[bits]| 2719 +----------------+--+--+--+---------+--------+------------++------+ 2720 |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | 2721 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2722 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2723 |IPv6 Length |16|1 |Bi| | ignore | compute-* || | 2724 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2725 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2726 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 | 2727 |IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2728 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2729 |IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2730 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2731 +================+==+==+==+=========+========+============++======+ 2732 |UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2733 |UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2734 |UDP Length |16|1 |Bi| | ignore | compute-* || | 2735 |UDP checksum |16|1 |Bi| | ignore | compute-* || | 2736 +================+==+==+==+=========+========+============++======+ 2738 Figure 26: Context Rules 2740 All the fields described in the three Rules depicted on Figure 26 are 2741 present in the IPv6 and UDP headers. The DevIID-DID value is found 2742 in the L2 header. 2744 The second and third Rules use global addresses. The way the Dev 2745 learns the prefix is not in the scope of the document. 2747 The third Rule compresses each port number to 4 bits. 2749 Appendix B. Fragmentation Examples 2751 This section provides examples for the various fragment reliability 2752 modes specified in this document. In the drawings, Bitmaps are shown 2753 in their uncompressed form. 2755 Figure 27 illustrates the transmission in No-ACK mode of a SCHC 2756 Packet that needs 11 SCHC Fragments. FCN is 1 bit wide. 2758 Sender Receiver 2759 |-------FCN=0-------->| 2760 |-------FCN=0-------->| 2761 |-------FCN=0-------->| 2762 |-------FCN=0-------->| 2763 |-------FCN=0-------->| 2764 |-------FCN=0-------->| 2765 |-------FCN=0-------->| 2766 |-------FCN=0-------->| 2767 |-------FCN=0-------->| 2768 |-------FCN=0-------->| 2769 |-----FCN=1 + RCS --->| Integrity check: success 2770 (End) 2772 Figure 27: No-ACK mode, 11 SCHC Fragments 2774 In the following examples, N (the size of the FCN field) is 3 bits. 2775 The All-1 FCN value is 7. 2777 Figure 28 illustrates the transmission in ACK-on-Error mode of a SCHC 2778 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2779 WINDOW_SIZE=7 and no lost SCHC Fragment. 2781 Sender Receiver 2782 |-----W=0, FCN=6----->| 2783 |-----W=0, FCN=5----->| 2784 |-----W=0, FCN=4----->| 2785 |-----W=0, FCN=3----->| 2786 |-----W=0, FCN=2----->| 2787 |-----W=0, FCN=1----->| 2788 |-----W=0, FCN=0----->| 2789 (no ACK) 2790 |-----W=1, FCN=6----->| 2791 |-----W=1, FCN=5----->| 2792 |-----W=1, FCN=4----->| 2793 |--W=1, FCN=7 + RCS-->| Integrity check: success 2794 |<-- ACK, W=1, C=1 ---| C=1 2795 (End) 2797 Figure 28: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2798 no lost SCHC Fragment. 2800 Figure 29 illustrates the transmission in ACK-on-Error mode of a SCHC 2801 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 2802 WINDOW_SIZE=7 and three lost SCHC Fragments. 2804 Sender Receiver 2805 |-----W=0, FCN=6----->| 2806 |-----W=0, FCN=5----->| 2807 |-----W=0, FCN=4--X-->| 2808 |-----W=0, FCN=3----->| 2809 |-----W=0, FCN=2--X-->| 2810 |-----W=0, FCN=1----->| 2811 |-----W=0, FCN=0----->| 6543210 2812 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2813 |-----W=0, FCN=4----->| 2814 |-----W=0, FCN=2----->| 2815 (no ACK) 2816 |-----W=1, FCN=6----->| 2817 |-----W=1, FCN=5----->| 2818 |-----W=1, FCN=4--X-->| 2819 |- W=1, FCN=7 + RCS ->| Integrity check: failure 2820 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 2821 |-----W=1, FCN=4----->| Integrity check: success 2822 |<-- ACK, W=1, C=1 ---| C=1 2823 (End) 2825 Figure 29: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 2826 lost SCHC Fragments. 2828 Figure 30 shows an example of a transmission in ACK-on-Error mode of 2829 a SCHC Packet fragmented in 73 tiles, with N=5, WINDOW_SIZE=28, M=2 2830 and 3 lost SCHC Fragments. 2832 Sender Receiver 2833 |-----W=0, FCN=27----->| 4 tiles sent 2834 |-----W=0, FCN=23----->| 4 tiles sent 2835 |-----W=0, FCN=19----->| 4 tiles sent 2836 |-----W=0, FCN=15--X-->| 4 tiles sent (not received) 2837 |-----W=0, FCN=11----->| 4 tiles sent 2838 |-----W=0, FCN=7 ----->| 4 tiles sent 2839 |-----W=0, FCN=3 ----->| 4 tiles sent 2840 |-----W=1, FCN=27----->| 4 tiles sent 2841 |-----W=1, FCN=23----->| 4 tiles sent 2842 |-----W=1, FCN=19----->| 4 tiles sent 2843 |-----W=1, FCN=15----->| 4 tiles sent 2844 |-----W=1, FCN=11----->| 4 tiles sent 2845 |-----W=1, FCN=7 ----->| 4 tiles sent 2846 |-----W=1, FCN=3 --X-->| 4 tiles sent (not received) 2847 |-----W=2, FCN=27----->| 4 tiles sent 2848 |-----W=2, FCN=23----->| 4 tiles sent 2849 ^ |-----W=2, FCN=19----->| 1 tile sent 2850 | |-----W=2, FCN=18----->| 1 tile sent 2851 | |-----W=2, FCN=17----->| 1 tile sent 2852 |-----W=2, FCN=16----->| 1 tile sent 2853 s |-----W=2, FCN=15----->| 1 tile sent 2854 m |-----W=2, FCN=14----->| 1 tile sent 2855 a |-----W=2, FCN=13--X-->| 1 tile sent (not received) 2856 l |-----W=2, FCN=12----->| 1 tile sent 2857 l |---W=2, FCN=31 + RCS->| Integrity check: failure 2858 e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 2859 r |-----W=0, FCN=15----->| 1 tile sent 2860 |-----W=0, FCN=14----->| 1 tile sent 2861 L |-----W=0, FCN=13----->| 1 tile sent 2862 2 |-----W=0, FCN=12----->| 1 tile sent 2863 |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 2864 M |-----W=1, FCN=3 ----->| 1 tile sent 2865 T |-----W=1, FCN=2 ----->| 1 tile sent 2866 U |-----W=1, FCN=1 ----->| 1 tile sent 2867 |-----W=1, FCN=0 ----->| 1 tile sent 2868 | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 2869 | |-----W=2, FCN=13----->| Integrity check: success 2870 V |<--- ACK, W=2, C=1 ---| C=1 2871 (End) 2873 Figure 30: ACK-on-Error mode, variable MTU. 2875 In this example, the L2 MTU becomes reduced just before sending the 2876 "W=2, FCN=19" fragment, leaving space for only 1 tile in each 2877 forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are 2878 carried by a total of 25 SCHC Fragments, the last 9 being of smaller 2879 size. 2881 Note: other sequences of events (e.g. regarding when ACKs are sent by 2882 the Receiver) are also allowed by this specification. Profiles may 2883 restrict this flexibility. 2885 Figure 31 illustrates the transmission in ACK-Always mode of a SCHC 2886 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with 2887 N=3, WINDOW_SIZE=7 and no loss. 2889 Sender Receiver 2890 |-----W=0, FCN=6----->| 2891 |-----W=0, FCN=5----->| 2892 |-----W=0, FCN=4----->| 2893 |-----W=0, FCN=3----->| 2894 |-----W=0, FCN=2----->| 2895 |-----W=0, FCN=1----->| 2896 |-----W=0, FCN=0----->| 2897 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2898 |-----W=1, FCN=6----->| 2899 |-----W=1, FCN=5----->| 2900 |-----W=1, FCN=4----->| 2901 |--W=1, FCN=7 + RCS-->| Integrity check: success 2902 |<-- ACK, W=1, C=1 ---| C=1 2903 (End) 2905 Figure 31: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, no 2906 loss. 2908 Figure 32 illustrates the transmission in ACK-Always mode of a SCHC 2909 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, 2910 WINDOW_SIZE=7 and three lost SCHC Fragments. 2912 Sender Receiver 2913 |-----W=0, FCN=6----->| 2914 |-----W=0, FCN=5----->| 2915 |-----W=0, FCN=4--X-->| 2916 |-----W=0, FCN=3----->| 2917 |-----W=0, FCN=2--X-->| 2918 |-----W=0, FCN=1----->| 2919 |-----W=0, FCN=0----->| 6543210 2920 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 2921 |-----W=0, FCN=4----->| 2922 |-----W=0, FCN=2----->| 2923 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 2924 |-----W=1, FCN=6----->| 2925 |-----W=1, FCN=5----->| 2926 |-----W=1, FCN=4--X-->| 2927 |--W=1, FCN=7 + RCS-->| Integrity check: failure 2928 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001 2929 |-----W=1, FCN=4----->| Integrity check: success 2930 |<-- ACK, W=1, C=1 ---| C=1 2931 (End) 2933 Figure 32: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, 2934 three lost SCHC Fragments. 2936 Figure 33 illustrates the transmission in ACK-Always mode of a SCHC 2937 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2938 WINDOW_SIZE=7, three lost SCHC Fragments and only one retry needed to 2939 recover each lost SCHC Fragment. 2941 Sender Receiver 2942 |-----W=0, FCN=6----->| 2943 |-----W=0, FCN=5----->| 2944 |-----W=0, FCN=4--X-->| 2945 |-----W=0, FCN=3--X-->| 2946 |-----W=0, FCN=2--X-->| 2947 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2948 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2949 |-----W=0, FCN=4----->| Integrity check: failure 2950 |-----W=0, FCN=3----->| Integrity check: failure 2951 |-----W=0, FCN=2----->| Integrity check: success 2952 |<-- ACK, W=0, C=1 ---| C=1 2953 (End) 2955 Figure 33: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, 2956 three lost SCHC Fragments. 2958 Figure 34 illustrates the transmission in ACK-Always mode of a SCHC 2959 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 2960 WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK 2961 lost. 2963 Sender Receiver 2964 |-----W=0, FCN=6----->| 2965 |-----W=0, FCN=5----->| 2966 |-----W=0, FCN=4--X-->| 2967 |-----W=0, FCN=3--X-->| 2968 |-----W=0, FCN=2--X-->| 2969 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2970 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2971 |-----W=0, FCN=4----->| Integrity check: failure 2972 |-----W=0, FCN=3----->| Integrity check: failure 2973 |-----W=0, FCN=2----->| Integrity check: success 2974 |<-X-ACK, W=0, C=1 ---| C=1 2975 timeout | | 2976 |--- W=0, ACK REQ --->| ACK REQ 2977 |<-- ACK, W=0, C=1 ---| C=1 2978 (End) 2980 Figure 34: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, SCHC 2981 ACK loss. 2983 Figure 35 illustrates the transmission in ACK-Always mode of a SCHC 2984 Packet fragmented in 6 tiles, with N=3, WINDOW_SIZE=7, with three 2985 lost SCHC Fragments, and one retransmitted SCHC Fragment lost again. 2987 Sender Receiver 2988 |-----W=0, FCN=6----->| 2989 |-----W=0, FCN=5----->| 2990 |-----W=0, FCN=4--X-->| 2991 |-----W=0, FCN=3--X-->| 2992 |-----W=0, FCN=2--X-->| 2993 |--W=0, FCN=7 + RCS-->| Integrity check: failure 2994 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 2995 |-----W=0, FCN=4----->| Integrity check: failure 2996 |-----W=0, FCN=3----->| Integrity check: failure 2997 |-----W=0, FCN=2--X-->| 2998 timeout| | 2999 |--- W=0, ACK REQ --->| ACK REQ 3000 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 3001 |-----W=0, FCN=2----->| Integrity check: success 3002 |<-- ACK, W=0, C=1 ---| C=1 3003 (End) 3005 Figure 35: ACK-Always mode, 6 tiles, retransmitted SCHC Fragment lost 3006 again. 3008 Figure 36 illustrates the transmission in ACK-Always mode of a SCHC 3009 Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, 3010 WINDOW_SIZE=24 and two lost SCHC Fragments. 3012 Sender Receiver 3013 |-----W=0, FCN=23----->| 3014 |-----W=0, FCN=22----->| 3015 |-----W=0, FCN=21--X-->| 3016 |-----W=0, FCN=20----->| 3017 |-----W=0, FCN=19----->| 3018 |-----W=0, FCN=18----->| 3019 |-----W=0, FCN=17----->| 3020 |-----W=0, FCN=16----->| 3021 |-----W=0, FCN=15----->| 3022 |-----W=0, FCN=14----->| 3023 |-----W=0, FCN=13----->| 3024 |-----W=0, FCN=12----->| 3025 |-----W=0, FCN=11----->| 3026 |-----W=0, FCN=10--X-->| 3027 |-----W=0, FCN=9 ----->| 3028 |-----W=0, FCN=8 ----->| 3029 |-----W=0, FCN=7 ----->| 3030 |-----W=0, FCN=6 ----->| 3031 |-----W=0, FCN=5 ----->| 3032 |-----W=0, FCN=4 ----->| 3033 |-----W=0, FCN=3 ----->| 3034 |-----W=0, FCN=2 ----->| 3035 |-----W=0, FCN=1 ----->| 3036 |-----W=0, FCN=0 ----->| 3037 | | 3038 |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 3039 |-----W=0, FCN=21----->| 3040 |-----W=0, FCN=10----->| 3041 |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 3042 |-----W=1, FCN=23----->| 3043 |-----W=1, FCN=22----->| 3044 |-----W=1, FCN=21----->| 3045 |--W=1, FCN=31 + RCS-->| Integrity check: success 3046 |<--- ACK, W=1, C=1 ---| C=1 3047 (End) 3049 Figure 36: ACK-Always mode, 28 tiles, one tile per SCHC Fragment, 3050 lost SCHC Fragments. 3052 Appendix C. Fragmentation State Machines 3054 The fragmentation state machines of the sender and the receiver, one 3055 for each of the different reliability modes, are described in the 3056 following figures: 3058 +===========+ 3059 +------------+ Init | 3060 | FCN=0 +===========+ 3061 | No Window 3062 | No Bitmap 3063 | +-------+ 3064 | +========+==+ | More Fragments 3065 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 3066 +--------> | Send | send Fragment (FCN=0) 3067 +===+=======+ 3068 | last fragment 3069 | ~~~~~~~~~~~~ 3070 | FCN = 1 3071 v send fragment+RCS 3072 +============+ 3073 | END | 3074 +============+ 3076 Figure 37: Sender State Machine for the No-ACK Mode 3078 +------+ Not All-1 3079 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 3080 | + <--+ set Inactivity Timer 3081 | RCV Frag +-------+ 3082 +=+===+======+ |All-1 & 3083 All-1 & | | |RCS correct 3084 RCS wrong | |Inactivity | 3085 | |Timer Exp. | 3086 v | | 3087 +==========++ | v 3088 | Error |<-+ +========+==+ 3089 +===========+ | END | 3090 +===========+ 3092 Figure 38: Receiver State Machine for the No-ACK Mode 3093 +=======+ 3094 | INIT | FCN!=0 & more frags 3095 | | ~~~~~~~~~~~~~~~~~~~~~~ 3096 +======++ +--+ send Window + frag(FCN) 3097 W=0 | | | FCN- 3098 Clear lcl_bm | | v set lcl_bm 3099 FCN=max value | ++==+========+ 3100 +> | | 3101 +---------------------> | SEND | 3102 | +==+===+=====+ 3103 | FCN==0 & more frags | | last frag 3104 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 3105 | set lcl_bm | | set lcl_bm 3106 | send wnd + frag(all-0) | | send wnd+frag(all-1)+RCS 3107 | set Retrans_Timer | | set Retrans_Timer 3108 | | | 3109 |Recv_wnd == wnd & | | 3110 |lcl_bm==recv_bm & | | +----------------------+ 3111 |more frag | | | lcl_bm!=rcv-bm | 3112 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 3113 |Stop Retrans_Timer | | | Attempt++ v 3114 |clear lcl_bm v v | +=====+=+ 3115 |window=next_window +====+===+==+===+ |Resend | 3116 +---------------------+ | |Missing| 3117 +----+ Wait | |Frag | 3118 not expected wnd | | Bitmap | +=======+ 3119 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 3120 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 3121 | | | ^ ^ |reSend(empty)All-* | 3122 | | | | | |Set Retrans_Timer | 3123 | | | | +--+Attempt++ | 3124 C_bit==1 & | | | +-------------------------+ 3125 Recv_window==window & | | | all missing frags sent 3126 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 3127 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 3128 Stop Retrans_Timer| | | 3129 +=============+ | | | 3130 | END +<--------+ | | 3131 +=============+ | | Attempt > MAX_ACK_REQUESTS 3132 All-1 Window & | | ~~~~~~~~~~~~~~~~~~ 3133 C_bit ==0 & | v Send Abort 3134 lcl_bm==recv_bm | +=+===========+ 3135 ~~~~~~~~~~~~ +>| ERROR | 3136 Send Abort +=============+ 3138 Figure 39: Sender State Machine for the ACK-Always Mode 3140 Not All- & w=expected +---+ +---+w = Not expected 3141 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 3142 Set lcl_bm(FCN) | v v |discard 3143 ++===+===+===+=+ 3144 +---------------------+ Rcv +--->* ABORT 3145 | +------------------+ Window | 3146 | | +=====+==+=====+ 3147 | | All-0 & w=expect | ^ w =next & not-All 3148 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 3149 | | set lcl_bm(FCN) | |expected = next window 3150 | | send lcl_bm | |Clear lcl_bm 3151 | | | | 3152 | | w=expected & not-All | | 3153 | | ~~~~~~~~~~~~~~~~~~ | | 3154 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0 3155 | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~ 3156 | | send lcl_bm | | | | | | expected = nxt wnd 3157 | | v | v | | | Clear lcl_bm 3158 | |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN) 3159 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm 3160 | | discard +--| Next | 3161 | | All-0 +---------+ Window +--->* ABORT 3162 | | ~~~~~ +-------->+========+=++ 3163 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 3164 | | & RCS wrong| | & RCS right 3165 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 3166 | | set lcl_bm(FCN)| |set lcl_bm(FCN) 3167 | | send lcl_bm| |send lcl_bm 3168 | | | +----------------------+ 3169 | |All-1 & w=expected | | 3170 | |& RCS wrong v +---+ w=expected & | 3171 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | RCS wrong | 3172 | |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ | 3173 | |send lcl_bm | Wait End | set lcl_bm(FCN)| 3174 | +--------------------->+ +--->* ABORT | 3175 | +===+====+=+-+ All-1&RCS wrong| 3176 | | ^ | ~~~~~~~~~~~~~~~| 3177 | w=expected & RCS right | +---+ send lcl_bm | 3178 | ~~~~~~~~~~~~~~~~~~~~~~ | | 3179 | set lcl_bm(FCN) | +-+ Not All-1 | 3180 | send lcl_bm | | | ~~~~~~~~~ | 3181 | | | | discard | 3182 |All-1&w=expected & RCS right | | | | 3183 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 3184 |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 3185 |send lcl_bm | +<+Send lcl_bm | 3186 +-------------------------->+ END | | 3187 +==========+<---------------+ 3189 --->* ABORT 3190 ~~~~~~~ 3191 Inactivity_Timer = expires 3192 When DWL 3193 IF Inactivity_Timer expires 3194 Send DWL Request 3195 Attempt++ 3197 Figure 40: Receiver State Machine for the ACK-Always Mode 3199 +=======+ 3200 | | 3201 | INIT | 3202 | | FCN!=0 & more frags 3203 +======++ ~~~~~~~~~~~~~~~~~~~~~~ 3204 Frag RuleID trigger | +--+ Send cur_W + frag(FCN); 3205 ~~~~~~~~~~~~~~~~~~~ | | | FCN--; 3206 cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp] 3207 clear [cur_W, Bmp_n];| | v 3208 clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND 3209 +->+ | cur_W==rcv_W & 3210 **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp 3211 +-------------------------->+ | & more frags 3212 | +----------------------->+ | ~~~~~~~~~~~~ 3213 | | ++===+=========+ cur_W++; 3214 | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] 3215 | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~ 3216 | | set cur_Bmp; | |set [cur_W, Bmp_n]; 3217 | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+RCS; 3218 | | set Retrans_Timer| |set Retrans_Timer 3219 | | | | +-----------------------------------+ 3220 | |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| 3221 | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ | 3222 | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W | 3223 | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &| 3224 | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp| 3225 | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| 3226 | +-------------------+ | | Resend | Attempts++;| 3227 +----------------------+ Wait x ACK | | Missing | W=Wn | 3228 +--------------------->+ | | Frags(W) +<-------------+ 3229 | rcv_W==Wn &+-+ | +======+====+ 3230 | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ | 3231 | ~~~~~~~~~~~~~~| ^ | | | ^ | 3232 | send (cur_W,+--+ | | | +-------------+ 3233 | ALL-0-empty) | | | all missing frag sent(W) 3234 | | | | ~~~~~~~~~~~~~~~~~ 3235 | Retrans_Timer expires &| | | set Retrans_Timer 3236 | No more Frags| | | 3237 | ~~~~~~~~~~~~~~| | | 3238 | stop Retrans_Timer;| | | 3239 |(re)send frag(All-1)+RCS | | | 3240 +-------------------------+ | | 3241 cur_W==rcv_W&| | 3242 [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS 3243 No more Frags & RCS flag==OK| | ~~~~~~~~~~ 3244 ~~~~~~~~~~~~~~~~~~| | send Abort 3245 +=========+stop Retrans_Timer| | +===========+ 3246 | END +<-----------------+ +->+ ERROR | 3247 +=========+ +===========+ 3249 Figure 41: Sender State Machine for the ACK-on-Error Mode 3251 This is an example only. It is not normative. The specification in 3252 Section 8.4.3.1 allows for sequences of operations different from the 3253 one shown here. 3255 +=======+ New frag RuleID received 3256 | | ~~~~~~~~~~~~~ 3257 | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); 3258 +=======+ |sync=0 3259 | 3260 Not All* & rcv_W==cur_W+---+ | +---+ 3261 ~~~~~~~~~~~~~~~~~~~~ | | | | (E) 3262 set[cur_W,Bmp_n(FCN)]| v v v | 3263 ++===+=+=+===+=+ 3264 +----------------------+ +--+ All-0&Full[cur_W,Bmp_n] 3265 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~ 3266 | +-------------------+ +<-+ cur_W++;set Inact_timer; 3267 | | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n] 3268 | | All-0 empty(Wn)| | | | ^ ^ 3269 | | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0; 3270 | | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n]) 3271 | | | | | |& All* || last_miss_frag 3272 | | | | | |~~~~~~~~~~~~~~~~~~~~~~ 3273 | | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); 3274 | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) 3275 | |&no_full([cur_W,Bmp_n])| |(E)| 3276 | | ~~~~~~~~~~~~~~~~ | | | | +========+ 3277 | | sendACK([cur_W,Bmp_n])| | | | | Error/ | 3278 | | | | | | +----+ | Abort | 3279 | | v v | | | | +===+====+ 3280 | | +===+=+=+=+===+=+ (D) ^ 3281 | | +--+ Wait x | | | 3282 | | All-0 empty(Wn)+->| Missing Frags |<-+ | 3283 | | ~~~~~~~~~~~~~~ +=============+=+ | 3284 | | sendACK([Wn,Bmp_n]) +--------------+ 3285 | | *ABORT 3286 v v 3287 (A)(B) 3288 (D) All* || last_miss_frag 3289 (C) All* & sync>0 & rcv_W!=cur_W & sync>0 3290 ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) 3291 Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ 3292 sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; 3293 sendACK([Wn,Bmp_n]);sync-- 3295 ABORT-->* Uplink Only & 3296 Inact_Timer expires 3297 (E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS 3298 ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ 3299 sync++; cur_W=rcv_W; send Abort 3300 set[cur_W,Bmp_n(FCN)] 3302 (A)(B) 3303 | | 3304 | | All-1 & rcv_W==cur_W & RCS!=OK All-0 empty(Wn) 3305 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~ 3306 | | sendACK([cur_W,Bmp_n],C=0) | v sendACK([Wn,Bmp_n]) 3307 | | +===========+=++ 3308 | +--------------------->+ Wait End +-+ 3309 | +=====+=+====+=+ | All-1 3310 | rcv_W==cur_W & RCS==OK | | ^ | & rcv_W==cur_W 3311 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & RCS!=OK 3312 | sendACK([cur_W,Bmp_n],C=1) | | ~~~~~~~~~~~~~~~~~~~ 3313 | | | sendACK([cur_W,Bmp_n],C=0); 3314 | | | Attempts++ 3315 |All-1 & Full([cur_W,Bmp_n]) | | 3316 |& RCS==OK & sync==0 | +-->* ABORT 3317 |~~~~~~~~~~~~~~~~~~~ v 3318 |sendACK([cur_W,Bmp_n],C=1) +=+=========+ 3319 +---------------------------->+ END | 3320 +===========+ 3322 Figure 42: Receiver State Machine for the ACK-on-Error Mode 3324 Appendix D. SCHC Parameters 3326 This section lists the information that needs to be provided in the 3327 LPWAN technology-specific documents. 3329 o Most common uses cases, deployment scenarios 3331 o Mapping of the SCHC architectural elements onto the LPWAN 3332 architecture 3334 o Assessment of LPWAN integrity checking 3336 o Various potential channel conditions for the technology and the 3337 corresponding recommended use of SCHC C/D and F/R 3339 This section lists the parameters that need to be defined in the 3340 Profile. 3342 o Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs, 3343 number of Rules, the way the Rule ID is transmitted 3345 o maximum packet size that should ever be reconstructed by SCHC 3346 Decompression (MAX_PACKET_SIZE). See Section 12. 3348 o Padding: size of the L2 Word (for most LPWAN technologies, this 3349 would be a byte; for some technologies, a bit) 3351 o Decision to use SCHC fragmentation mechanism or not. If yes: 3353 * reliability mode(s) used, in which cases (e.g. based on link 3354 channel condition) 3356 * Rule ID values assigned to each mode in use 3358 * presence and number of bits for DTag (T) for each Rule ID value 3360 * support for interleaved packet transmission, to what extent 3362 * WINDOW_SIZE, for modes that use windows 3364 * number of bits for W (M) for each Rule ID value, for modes that 3365 use windows 3367 * number of bits for FCN (N) for each Rule ID value 3369 * size of RCS and algorithm for its computation, for each Rule 3370 ID, if different from the default CRC32. Byte fill-up with 3371 zeroes or other mechanism, to be specified. 3373 * Retransmission Timer duration for each Rule ID value, if 3374 applicable to the SCHC F/R mode 3376 * Inactivity Timer duration for each Rule ID value, if applicable 3377 to the SCHC F/R mode 3379 * MAX_ACK_REQUEST value for each Rule ID value, if applicable to 3380 the SCHC F/R mode 3382 o if L2 Word is wider than a bit and SCHC fragmentation is used, 3383 value of the padding bits (0 or 1). This is needed because the 3384 padding bits of the last fragment are included in the RCS 3385 computation. 3387 A Profile may define a delay to be added after each SCHC message 3388 transmission for compliance with local regulations or other 3389 constraints imposed by the applications. 3391 o In some LPWAN technologies, as part of energy-saving techniques, 3392 downlink transmission is only possible immediately after an uplink 3393 transmission. In order to avoid potentially high delay in the 3394 downlink transmission of a fragmented SCHC Packet, the SCHC 3395 Fragment receiver may perform an uplink transmission as soon as 3396 possible after reception of a SCHC Fragment that is not the last 3397 one. Such uplink transmission may be triggered by the L2 (e.g. an 3398 L2 ACK sent in response to a SCHC Fragment encapsulated in a L2 3399 PDU that requires an L2 ACK) or it may be triggered from an upper 3400 layer. 3402 o the following parameters need to be addressed in documents other 3403 than this one but not necessarily in the LPWAN technology-specific 3404 documents: 3406 * The way the Contexts are provisioned 3408 * The way the Rules are generated 3410 Appendix E. Supporting multiple window sizes for fragmentation 3412 For ACK-Always or ACK-on-Error, implementers may opt to support a 3413 single window size or multiple window sizes. The latter, when 3414 feasible, may provide performance optimizations. For example, a 3415 large window size should be used for packets that need to be split 3416 into a large number of tiles. However, when the number of tiles 3417 required to carry a packet is low, a smaller window size, and thus a 3418 shorter Bitmap, may be sufficient to provide reception status on all 3419 tiles. If multiple window sizes are supported, the Rule ID may 3420 signal the window size in use for a specific packet transmission. 3422 The same window size MUST be used for the transmission of all tiles 3423 that belong to the same SCHC Packet. 3425 Appendix F. Downlink SCHC Fragment transmission 3427 For downlink transmission of a fragmented SCHC Packet in ACK-Always 3428 mode, the SCHC Fragment receiver may support timer-based SCHC ACK 3429 retransmission. In this mechanism, the SCHC Fragment receiver 3430 initializes and starts a timer (the Inactivity Timer is used) after 3431 the transmission of a SCHC ACK, except when the SCHC ACK is sent in 3432 response to the last SCHC Fragment of a packet (All-1 fragment). In 3433 the latter case, the SCHC Fragment receiver does not start a timer 3434 after transmission of the SCHC ACK. 3436 If, after transmission of a SCHC ACK that is not an All-1 fragment, 3437 and before expiration of the corresponding Inactivity timer, the SCHC 3438 Fragment receiver receives a SCHC Fragment that belongs to the 3439 current window (e.g. a missing SCHC Fragment from the current window) 3440 or to the next window, the Inactivity timer for the SCHC ACK is 3441 stopped. However, if the Inactivity timer expires, the SCHC ACK is 3442 resent and the Inactivity timer is reinitialized and restarted. 3444 The default initial value for the Inactivity Timer, as well as the 3445 maximum number of retries for a specific SCHC ACK, denoted 3446 MAX_ACK_RETRIES, are not defined in this document, and need to be 3447 defined in a Profile. The initial value of the Inactivity timer is 3448 expected to be greater than that of the Retransmission timer, in 3449 order to make sure that a (buffered) SCHC Fragment to be 3450 retransmitted can find an opportunity for that transmission. One 3451 exception to this recommendation is the special case of the All-1 3452 SCHC Fragment transmission. 3454 When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it 3455 starts its Retransmission Timer with a large timeout value (e.g. 3456 several times that of the initial Inactivity Timer). If a SCHC ACK 3457 is received before expiration of this timer, the SCHC Fragment sender 3458 retransmits any lost SCHC Fragments reported by the SCHC ACK, or if 3459 the SCHC ACK confirms successful reception of all SCHC Fragments of 3460 the last window, the transmission of the fragmented SCHC Packet is 3461 considered complete. If the timer expires, and no SCHC ACK has been 3462 received since the start of the timer, the SCHC Fragment sender 3463 assumes that the All-1 SCHC Fragment has been successfully received 3464 (and possibly, the last SCHC ACK has been lost: this mechanism 3465 assumes that the Retransmission Timer for the All-1 SCHC Fragment is 3466 long enough to allow several SCHC ACK retries if the All-1 SCHC 3467 Fragment has not been received by the SCHC Fragment receiver, and it 3468 also assumes that it is unlikely that several ACKs become all lost). 3470 Authors' Addresses 3472 Ana Minaburo 3473 Acklio 3474 1137A avenue des Champs Blancs 3475 35510 Cesson-Sevigne Cedex 3476 France 3478 Email: ana@ackl.io 3480 Laurent Toutain 3481 IMT-Atlantique 3482 2 rue de la Chataigneraie 3483 CS 17607 3484 35576 Cesson-Sevigne Cedex 3485 France 3487 Email: Laurent.Toutain@imt-atlantique.fr 3488 Carles Gomez 3489 Universitat Politecnica de Catalunya 3490 C/Esteve Terradas, 7 3491 08860 Castelldefels 3492 Spain 3494 Email: carlesgo@entel.upc.edu 3496 Dominique Barthel 3497 Orange Labs 3498 28 chemin du Vieux Chene 3499 38243 Meylan 3500 France 3502 Email: dominique.barthel@orange.com 3504 Juan Carlos Zuniga 3505 SIGFOX 3506 425 rue Jean Rostand 3507 Labege 31670 3508 France 3510 Email: JuanCarlos.Zuniga@sigfox.com