idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 05, 2019) is 1575 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) ** Downref: Normative reference to an Informational RFC: RFC 8376 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Standards Track L. Toutain 5 Expires: June 7, 2020 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 D. Barthel 9 Orange Labs 10 JC. Zuniga 11 SIGFOX 12 December 05, 2019 14 Static Context Header Compression (SCHC) and fragmentation for LPWAN, 15 application to UDP/IPv6 16 draft-ietf-lpwan-ipv6-static-context-hc-24 18 Abstract 20 This document defines the Static Context Header Compression (SCHC) 21 framework, which provides both a header compression mechanism and an 22 optional fragmentation mechanism. SCHC has been designed for Low 23 Power Wide Area Networks (LPWAN). 25 SCHC compression is based on a common static context stored both in 26 the LPWAN device and in the network infrastructure side. This 27 document defines a generic header compression mechanism and its 28 application to compress IPv6/UDP headers. 30 This document also specifies an optional fragmentation and reassembly 31 mechanism. It can be used to support the IPv6 MTU requirement over 32 the LPWAN technologies. Fragmentation is needed for IPv6 datagrams 33 that, after SCHC compression or when such compression was not 34 possible, still exceed the layer-2 maximum payload size. 36 The SCHC header compression and fragmentation mechanisms are 37 independent of the specific LPWAN technology over which they are 38 used. This document defines generic functionalities and offers 39 flexibility with regard to parameter settings and mechanism choices. 40 This document standardizes the exchange over the LPWAN between two 41 SCHC entities. Settings and choices specific to a technology or a 42 product are expected to be grouped into profiles, which are specified 43 in other documents. Data models for the context and profiles are out 44 of scope. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on June 7, 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 . . . . . . . . . . . . . . . . . . . 11 87 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12 89 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 13 90 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 15 91 7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15 92 7.4. Matching operators . . . . . . . . . . . . . . . . . . . 17 93 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 18 94 7.5.1. processing fixed-length fields . . . . . . . . . . . 19 95 7.5.2. processing variable-length fields . . . . . . . . . . 19 96 7.5.3. not-sent CDA . . . . . . . . . . . . . . . . . . . . 20 97 7.5.4. value-sent CDA . . . . . . . . . . . . . . . . . . . 20 98 7.5.5. mapping-sent CDA . . . . . . . . . . . . . . . . . . 20 99 7.5.6. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 21 100 7.5.7. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 21 101 7.5.8. Compute-* . . . . . . . . . . . . . . . . . . . . . . 21 102 8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 22 103 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 104 8.2. SCHC F/R Protocol Elements . . . . . . . . . . . . . . . 22 105 8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 22 106 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 23 107 8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 25 108 8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 26 109 8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 28 110 8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 28 111 8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 30 112 8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 32 113 8.3.4. SCHC Sender-Abort format . . . . . . . . . . . . . . 33 114 8.3.5. SCHC Receiver-Abort format . . . . . . . . . . . . . 33 115 8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 34 116 8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 34 117 8.4.2. ACK-Always mode . . . . . . . . . . . . . . . . . . . 36 118 8.4.3. ACK-on-Error mode . . . . . . . . . . . . . . . . . . 43 119 9. Padding management . . . . . . . . . . . . . . . . . . . . . 51 120 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 52 121 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 52 122 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 52 123 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 52 124 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 53 125 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 53 126 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 53 127 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 53 128 10.7.1. IPv6 source and destination prefixes . . . . . . . . 54 129 10.7.2. IPv6 source and destination IID . . . . . . . . . . 54 130 10.8. IPv6 extension headers . . . . . . . . . . . . . . . . . 54 131 10.9. UDP source and destination ports . . . . . . . . . . . . 55 132 10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 55 133 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 55 134 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 135 12. Security considerations . . . . . . . . . . . . . . . . . . . 56 136 12.1. Security considerations for SCHC 137 Compression/Decompression . . . . . . . . . . . . . . . 56 138 12.1.1. Forged SCHC Packet . . . . . . . . . . . . . . . . . 56 139 12.1.2. Compressed packet size as a side channel to guess a 140 secret token . . . . . . . . . . . . . . . . . . . . 57 141 12.1.3. Decompressed packet different from the original 142 packet . . . . . . . . . . . . . . . . . . . . . . . 58 143 12.2. Security considerations for SCHC 144 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 58 145 12.2.1. Buffer reservation attack . . . . . . . . . . . . . 58 146 12.2.2. Corrupt Fragment attack . . . . . . . . . . . . . . 59 147 12.2.3. Fragmentation as a way to bypass Network Inspection 59 148 12.2.4. Privacy issues associated with SCHC header fields . 59 149 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 150 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 151 14.1. Normative References . . . . . . . . . . . . . . . . . . 60 152 14.2. Informative References . . . . . . . . . . . . . . . . . 61 153 Appendix A. Compression Examples . . . . . . . . . . . . . . . . 61 154 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 64 155 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 72 156 Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 78 157 Appendix E. Supporting multiple window sizes for fragmentation . 80 158 Appendix F. ACK-Always and ACK-on-Error on quasi-bidirectional 159 links . . . . . . . . . . . . . . . . . . . . . . . 80 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 162 1. Introduction 164 This document defines the Static Context Header Compression (SCHC) 165 framework, which provides both a header compression mechanism and an 166 optional fragmentation mechanism. SCHC has been designed for Low 167 Power Wide Area Networks (LPWAN). 169 LPWAN technologies impose some strict limitations on traffic. For 170 instance, devices sleep most of the time and may only receive data 171 during short periods of time after transmission, in order to preserve 172 battery. LPWAN technologies are also characterized by a greatly 173 reduced data unit and/or payload size (see [RFC8376]). 175 Header compression is needed for efficient Internet connectivity to a 176 node within an LPWAN network. The following properties of LPWAN 177 networks can be exploited to get an efficient header compression: 179 o The network topology is star-oriented, which means that all 180 packets between the same source-destination pair follow the same 181 path. For the needs of this document, the architecture can simply 182 be described as Devices (Dev) exchanging information with LPWAN 183 Application Servers (App) through a Network Gateway (NGW). 185 o Because devices embed built-in applications, the traffic flows to 186 be compressed are known in advance. Indeed, new applications are 187 less frequently installed in an LPWAN device, than they are in a 188 general-purpose computer or smartphone. 190 SCHC compression uses a Context (a set of Rules) in which information 191 about header fields is stored. This Context is static: the values of 192 the header fields and the actions to do compression/decompression do 193 not change over time. This avoids the need for complex 194 resynchronization mechanisms. Indeed, a return path may be more 195 restricted/expensive, sometimes completely unavailable [RFC8376]. A 196 compression protocol that relies on feedback is not compatible with 197 the characteristics of such LPWANs. 199 In most cases, a small Rule identifier is enough to represent the 200 full IPv6/UDP headers. The SCHC header compression mechanism is 201 independent of the specific LPWAN technology over which it is used. 203 Furthermore, some LPWAN technologies do not provide a fragmentation 204 functionality; to support the IPv6 MTU requirement of 1280 bytes 205 [RFC8200], they require a fragmentation protocol at the adaptation 206 layer below IPv6. Accordingly, this document defines an optional 207 fragmentation/reassembly mechanism for LPWAN technologies to support 208 the IPv6 MTU requirement. 210 This document defines generic functionality and offers flexibility 211 with regard to parameters settings and mechanism choices. 212 Technology-specific settings are expected to be grouped into Profiles 213 specified in other documents. 215 2. Requirements Notation 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 219 "OPTIONAL" in this document are to be interpreted as described in BCP 220 14 [RFC2119] [RFC8174] when, and only when, they appear in all 221 capitals, as shown here. 223 3. LPWAN Architecture 225 LPWAN network architectures are similar among them, but each LPWAN 226 technology names architecture elements differently. In this 227 document, we use terminology from [RFC8376], which identifies the 228 following entities in a typical LPWAN network (see Figure 1): 230 o Devices (Dev) are the end-devices or hosts (e.g., sensors, 231 actuators, etc.). There can be a very high density of devices per 232 radio gateway. 234 o The Radio Gateway (RGW) is the end point of the constrained link. 236 o The Network Gateway (NGW) is the interconnection node between the 237 Radio Gateway and the Internet. 239 o Application Server (App) is the end point of the application level 240 protocol on the Internet side. 242 () () () | 243 () () () () / \ +---------+ 244 () () () () () () / \======| ^ | +-----------+ 245 () () () | | <--|--> | |Application| 246 () () () () / \==========| v |=============| (App) | 247 () () () / \ +---------+ +-----------+ 248 Dev RGWs NGW 250 Figure 1: LPWAN Architecture, simplified from that shown in RFC8376 252 4. Terminology 254 This section defines the terminology and acronyms used in this 255 document. It extends the terminology of [RFC8376]. 257 The SCHC acronym is pronounced like "sheek" in English (or "chic" in 258 French). Therefore, this document writes "a SCHC Packet" instead of 259 "an SCHC Packet". 261 o App: LPWAN Application, as defined by [RFC8376]. An application 262 sending/receiving packets to/from the Dev. 264 o AppIID: Application Interface Identifier. The IID that identifies 265 the application server interface. 267 o Bi: Bidirectional. Characterizes a Field Descriptor that applies 268 to headers of packets traveling in either direction (Up and Dw, 269 see this glossary). 271 o CDA: Compression/Decompression Action. Describes the pair of 272 actions that are performed at the compressor to compress a header 273 field and at the decompressor to recover the original value of the 274 header field. 276 o Compression Residue. The bits that remain to be sent (beyond the 277 Rule ID itself) after applying the SCHC compression. 279 o Context: A set of Rules used to compress/decompress headers. 281 o Dev: Device, as defined by [RFC8376]. 283 o DevIID: Device Interface Identifier. The IID that identifies the 284 Dev interface. 286 o DI: Direction Indicator. This field tells which direction of 287 packet travel (Up, Dw or Bi) a Field Description applies to. This 288 allows for asymmetric processing, using the same Rule. 290 o Dw: Downlink direction for compression/decompression, from SCHC C/ 291 D in the network to SCHC C/D in the Dev. 293 o Field Description. A tuple containing identifier, value, matching 294 operator and actions to be applied to a field. 296 o FID: Field Identifier. This identifies the protocol and field a 297 Field Description applies to. 299 o FL: Field Length is the length of the original packet header 300 field. It is expressed as a number of bits for header fields of 301 fixed lengths or as a type (e.g., variable, token length, ...) for 302 field lengths that are unknown at the time of Rule creation. The 303 length of a header field is defined in the corresponding protocol 304 specification (such as IPv6 or UDP). 306 o FP: when a Field is expected to appear multiple times in a header, 307 Field Position specifies the occurrence this Field Description 308 applies to (for example, first uri-path option, second uri-path, 309 etc. in a CoAP header), counting from 1. The value 0 is special 310 and means "don't care", see Section 7.3. 312 o IID: Interface Identifier. See the IPv6 addressing architecture 313 [RFC7136]. 315 o L2: Layer two. The immediate lower layer SCHC interfaces with. 316 It is provided by an underlying LPWAN technology. It does not 317 necessarily correspond to the OSI model definition of Layer 2. 319 o L2 Word: this is the minimum subdivision of payload data that the 320 L2 will carry. In most L2 technologies, the L2 Word is an octet. 321 In bit-oriented radio technologies, the L2 Word might be a single 322 bit. The L2 Word size is assumed to be constant over time for 323 each device. 325 o MO: Matching Operator. An operator used to match a value 326 contained in a header field with a value contained in a Rule. 328 o Padding (P). Extra bits that may be appended by SCHC to a data 329 unit that it passes to the underlying Layer 2 for transmission. 330 SCHC itself operates on bits, not bytes, and does not have any 331 alignment prerequisite. See Section 9. 333 o Profile: SCHC offers variations in the way it is operated, with a 334 number of parameters listed in Appendix D. A Profile indicates a 335 particular setting of all these parameters. Both ends of a SCHC 336 communication must be provisioned with the same Profile 337 information and with the same set of Rules before the 338 communication starts, so that there is no ambiguity in how they 339 expect to communicate. 341 o Rule: A set of Field Descriptions. 343 o Rule ID (Rule Identifier): An identifier for a Rule. SCHC C/D on 344 both sides share the same Rule ID for a given packet. A set of 345 Rule IDs are used to support SCHC F/R functionality. 347 o SCHC C/D: SCHC Compressor/Decompressor. A mechanism used on both 348 sides, at the Dev and at the network, to achieve Compression/ 349 Decompression of headers. 351 o SCHC F/R: SCHC Fragmentation / Reassembly. A mechanism used on 352 both sides, at the Dev and at the network, to achieve 353 Fragmentation / Reassembly of SCHC Packets. 355 o SCHC Packet: A packet (e.g., an IPv6 packet) whose header has been 356 compressed as per the header compression mechanism defined in this 357 document. If the header compression process is unable to actually 358 compress the packet header, the packet with the uncompressed 359 header is still called a SCHC Packet (in this case, a Rule ID is 360 used to indicate that the packet header has not been compressed). 361 See Section 7 for more details. 363 o TV: Target value. A value contained in a Rule that will be 364 matched with the value of a header field. 366 o Up: Uplink direction for compression/decompression, from the Dev 367 SCHC C/D to the network SCHC C/D. 369 Additional terminology for the optional SCHC Fragmentation / 370 Reassembly mechanism (SCHC F/R) is found in Section 8.2. 372 5. SCHC overview 374 SCHC can be characterized as an adaptation layer between an upper 375 layer (typically, IPv6) and an underlying layer (typically, an LPWAN 376 technology). SCHC comprises two sublayers (i.e. the Compression 377 sublayer and the Fragmentation sublayer), as shown in Figure 2. 379 +----------------+ 380 | IPv6 | 381 +- +----------------+ 382 | | Compression | 383 SCHC < +----------------+ 384 | | Fragmentation | 385 +- +----------------+ 386 |LPWAN technology| 387 +----------------+ 389 Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN 390 technology 392 Before an upper layer packet (e.g., an IPv6 packet) is transmitted to 393 the underlying layer, header compression is first attempted. The 394 resulting packet is called a SCHC Packet, whether or not any 395 compression is performed. If needed by the underlying layer, the 396 optional SCHC Fragmentation MAY be applied to the SCHC Packet. The 397 inverse operations take place at the receiver. This process is 398 illustrated in Figure 3. 400 A packet (e.g., an IPv6 packet) 401 | ^ 402 v | 403 +------------------+ +--------------------+ 404 | SCHC Compression | | SCHC Decompression | 405 +------------------+ +--------------------+ 406 | ^ 407 | If no fragmentation (*) | 408 +-------------- SCHC Packet -------------->| 409 | | 410 v | 411 +--------------------+ +-----------------+ 412 | SCHC Fragmentation | | SCHC Reassembly | 413 +--------------------+ +-----------------+ 414 | ^ | ^ 415 | | | | 416 | +---------- SCHC ACK (+) -------------+ | 417 | | 418 +-------------- SCHC Fragments -------------------+ 420 Sender Receiver 422 *: the decision to not use SCHC Fragmentation is left to each Profile. 423 +: optional, depends on Fragmentation mode. 425 Figure 3: SCHC operations at the Sender and the Receiver 427 5.1. SCHC Packet format 429 The SCHC Packet is composed of the Compressed Header followed by the 430 payload from the original packet (see Figure 4). The Compressed 431 Header itself is composed of the Rule ID and a Compression Residue, 432 which is the output of compressing the packet header with that Rule 433 (see Section 7). The Compression Residue may be empty. Both the 434 Rule ID and the Compression Residue potentially have a variable size, 435 and are not necessarily a multiple of bytes in size. 437 |------- Compressed Header -------| 438 +---------------------------------+--------------------+ 439 | Rule ID | Compression Residue | Payload | 440 +---------------------------------+--------------------+ 442 Figure 4: SCHC Packet 444 5.2. Functional mapping 446 Figure 5 maps the functional elements of Figure 3 onto the LPWAN 447 architecture elements of Figure 1. 449 Dev App 450 +----------------+ +----+ +----+ +----+ 451 | App1 App2 App3 | |App1| |App2| |App3| 452 | | | | | | | | 453 | UDP | |UDP | |UDP | |UDP | 454 | IPv6 | |IPv6| |IPv6| |IPv6| 455 | | | | | | | | 456 |SCHC C/D and F/R| | | | | | | 457 +--------+-------+ +----+ +----+ +----+ 458 | +---+ +---+ +----+ +----+ . . . 459 +~ |RGW| === |NGW| == |SCHC| == |SCHC|...... Internet .... 460 +---+ +---+ |F/R | |C/D | 461 +----+ +----+ 463 Figure 5: Architecture 465 SCHC C/D and SCHC F/R are located on both sides of the LPWAN 466 transmission, hereafter called "the Dev side" and "the Network 467 infrastructure side". 469 The operation in the Uplink direction is as follows. The Device 470 application uses IPv6 or IPv6/UDP protocols. Before sending the 471 packets, the Dev compresses their headers using SCHC C/D and, if the 472 SCHC Packet resulting from the compression needs to be fragmented by 473 SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC 474 Fragments are sent to an LPWAN Radio Gateway (RGW) which forwards 475 them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/ 476 R for re-assembly (if needed) and then to the SCHC C/D for 477 decompression. After decompression, the packet can be sent over the 478 Internet to one or several LPWAN Application Servers (App). 480 The SCHC F/R and C/D on the Network infrastructure side can be part 481 of the NGW, or located in the Internet as long as a tunnel is 482 established between them and the NGW. For some LPWAN technologies, 483 it may be suitable to locate the SCHC F/R functionality nearer the 484 NGW, in order to better deal with time constraints of such 485 technologies. 487 The SCHC C/Ds on both sides MUST share the same set of Rules. So 488 MUST the SCHC F/Rs on both sides. 490 The operation in the Downlink direction is similar to that in the 491 Uplink direction, only reversing the order in which the architecture 492 elements are traversed. 494 6. Rule ID 496 Rule IDs identify the Rules used for Compression/Decompression or for 497 Fragmentation/Reassembly. 499 The scope of the Rule ID of a Compression/Decompression Rule is the 500 link between the SCHC C/D in a given Dev and the corresponding SCHC 501 C/D in the Network infrastructure side. The scope of the Rule ID of 502 a Fragmentation/Reassembly Rule is the link between the SCHC F/R in a 503 given Dev and the corresponding SCHC F/R in the Network 504 infrastructure side. If such a link is bidirectional, the scope 505 includes both directions. 507 Inside their scopes, Rules for Compression/Decompression and Rules 508 for Fragmentation/Reassembly share the same Rule ID space. 510 The size of the Rule IDs is not specified in this document, as it is 511 implementation-specific and can vary according to the LPWAN 512 technology and the number of Rules, among others. It is defined in 513 Profiles. 515 The Rule IDs are used: 517 o For SCHC C/D, to identify the Rule (i.e., the set of Field 518 Descriptions) that is used to compress a packet header. 520 * At least one Rule ID MUST be allocated to tagging packets for 521 which SCHC compression was not possible (i.e., no matching 522 compression Rule was found). 524 o In SCHC F/R, to identify the specific mode and settings of F/R for 525 one direction of traffic (Up or Dw). 527 * When F/R is used for both communication directions, at least 528 two Rule ID values are needed for F/R, one per direction of 529 traffic. This is because F/R may entail control messages 530 flowing in the reverse direction compared to data traffic. 532 7. Compression/Decompression 534 Compression with SCHC is based on using a set of Rules, called the 535 Context, to compress or decompress headers. SCHC avoids Context 536 synchronization traffic, which consumes considerable bandwidth in 537 other header compression mechanisms such as RoHC [RFC5795]. Since 538 the content of packets is highly predictable in LPWAN networks, 539 static Contexts can be stored beforehand. The Contexts MUST be 540 stored at both ends, and they can be learned by a provisioning 541 protocol or by out of band means, or they can be pre-provisioned. 542 The way the Contexts are provisioned is out of the scope of this 543 document. 545 7.1. SCHC C/D Rules 547 The main idea of the SCHC compression scheme is to transmit the Rule 548 ID to the other end instead of sending known field values. This Rule 549 ID identifies a Rule that matches the original packet values. Hence, 550 when a value is known by both ends, it is only necessary to send the 551 corresponding Rule ID over the LPWAN network. The manner by which 552 Rules are generated is out of the scope of this document. The Rules 553 MAY be changed at run-time but the mechanism is out of scope of this 554 document. 556 The Context is a set of Rules. See Figure 6 for a high level, 557 abstract representation of the Context. The formal specification of 558 the representation of the Rules is outside the scope of this 559 document. 561 Each Rule itself contains a list of Field Descriptions composed of a 562 Field Identifier (FID), a Field Length (FL), a Field Position (FP), a 563 Direction Indicator (DI), a Target Value (TV), a Matching Operator 564 (MO) and a Compression/Decompression Action (CDA). 566 /-----------------------------------------------------------------\ 567 | Rule N | 568 /-----------------------------------------------------------------\| 569 | Rule i || 570 /-----------------------------------------------------------------\|| 571 | (FID) Rule 1 ||| 572 |+-------+--+--+--+------------+-----------------+---------------+||| 573 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 574 |+-------+--+--+--+------------+-----------------+---------------+||| 575 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 576 |+-------+--+--+--+------------+-----------------+---------------+||| 577 ||... |..|..|..| ... | ... | ... |||| 578 |+-------+--+--+--+------------+-----------------+---------------+||/ 579 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 580 |+-------+--+--+--+------------+-----------------+---------------+|/ 581 | | 582 \-----------------------------------------------------------------/ 584 Figure 6: A Compression/Decompression Context 586 A Rule does not describe how the compressor parses a packet header to 587 find and identify each field (e.g., the IPv6 Source Address, the UDP 588 Destination Port or a CoAP URI path option). It is assumed that 589 there is a protocol parser alongside SCHC that is able to identify 590 all the fields encountered in the headers to be compressed, and to 591 label them with a Field ID. Rules only describe the compression/ 592 decompression behavior for each header field, after it has been 593 identified. 595 In a Rule, the Field Descriptions are listed in the order in which 596 the fields appear in the packet header. The Field Descriptions 597 describe the header fields with the following entries: 599 o Field ID (FID) designates a protocol and field (e.g., UDP 600 Destination Port), unambiguously among all protocols that a SCHC 601 compressor processes. In the presence of protocol nesting, the 602 Field ID also identifies the nesting. 604 o Field Length (FL) represents the length of the original field. It 605 can be either a fixed value (in bits) if the length is known when 606 the Rule is created or a type if the length is variable. The 607 length of a header field is defined by its own protocol 608 specification (e.g., IPv6 or UDP). If the length is variable, the 609 type defines the process to compute the length and its unit (bits, 610 bytes...). 612 o Field Position (FP): most often, a field only occurs once in a 613 packet header. However, some fields may occur multiple times. An 614 example is the uri-path of CoAP. FP indicates which occurrence 615 this Field Description applies to. If FP is not specified in the 616 Field Description, it takes the default value of 1. The value 1 617 designates the first occurrence. The value 0 is special. It 618 means "don't care", see Section 7.3. 620 o A Direction Indicator (DI) indicates the packet direction(s) this 621 Field Description applies to. Three values are possible: 623 * UPLINK (Up): this Field Description is only applicable to 624 packets sent by the Dev to the App, 626 * DOWNLINK (Dw): this Field Description is only applicable to 627 packets sent from the App to the Dev, 629 * BIDIRECTIONAL (Bi): this Field Description is applicable to 630 packets traveling both Up and Dw. 632 o Target Value (TV) is the value used to match against the packet 633 header field. The Target Value can be a scalar value of any type 634 (integer, strings, etc.) or a more complex structure (array, list, 635 etc.). The types and representations are out of scope for this 636 document. 638 o Matching Operator (MO) is the operator used to match the Field 639 Value and the Target Value. The Matching Operator may require 640 some parameters. MO is only used during the compression phase. 641 The set of MOs defined in this document can be found in 642 Section 7.4. 644 o Compression Decompression Action (CDA) describes the compression 645 and decompression processes to be performed after the MO is 646 applied. Some CDAs might use parameter values for their 647 operation. CDAs are used in both the compression and the 648 decompression functions. The set of CDAs defined in this document 649 can be found in Section 7.5. 651 7.2. Rule ID for SCHC C/D 653 Rule IDs are sent by the compression function in one side and are 654 received for the decompression function in the other side. In SCHC 655 C/D, the Rule IDs are specific to the Context related to one Dev. 656 Hence, multiple Dev instances, which refer to different header 657 compression Contexts, MAY reuse the same Rule ID for different Rules. 658 On the Network infrastructure side, in order to identify the correct 659 Rule to be applied, the SCHC Decompressor needs to associate the Rule 660 ID with the Dev identifier. Similarly, the SCHC Compressor on the 661 Network infrastructure side first identifies the destination Dev 662 before looking for the appropriate compression Rule (and associated 663 Rule ID) in the Context of that Dev. 665 7.3. Packet processing 667 The compression/decompression process follows several phases: 669 o Compression Rule selection: the general idea is to browse the Rule 670 set to find a Rule that has a matching Field Descriptor (given the 671 DI and FP) for all and only those header fields that appear in the 672 packet being compressed. The detailed algorithm is the following: 674 * The first step is to check the Field Identifiers (FID). If any 675 header field of the packet being examined cannot be matched 676 with a Field Description with the correct FID, the Rule MUST be 677 disregarded. If any Field Description in the Rule has a FID 678 that cannot be matched to one of the header fields of the 679 packet being examined, the Rule MUST be disregarded. 681 * The next step is to match the Field Descriptions by their 682 direction, using the Direction Indicator (DI). If any field of 683 the packet header cannot be matched with a Field Description 684 with the correct FID and DI, the Rule MUST be disregarded. 686 * Then the Field Descriptions are further selected according to 687 Field Position (FP). If any field of the packet header cannot 688 be matched with a Field Description with the correct FID, DI 689 and FP, the Rule MUST be disregarded. 691 The value 0 for FP means "don't care", i.e. the comparison of 692 this Field Description's FP with the position of the field of 693 the packet header being compressed returns True, whatever that 694 position. FP=0 can be useful to build compression Rules for 695 protocols headers in which some fields order is irrelevant. An 696 example could be uri-queries in CoAP. Care needs to be 697 exercised when writing Rules containing FP=0 values. Indeed, 698 it may result in decompressed packets having fields ordered 699 differently compared to the original packet. 701 * Once each header field has been associated with a Field 702 Description with matching FID, DI and FP, each packet field's 703 value is then compared to the corresponding Target Value (TV) 704 stored in the Rule for that specific field, using the matching 705 operator (MO). If every field in the packet header satisfies 706 the corresponding matching operators (MO) of a Rule (i.e. all 707 MO results are True), that Rule is valid for use to compress 708 the header. Otherwise, the Rule MUST be disregarded. 710 This specification does not prevent multiple Rules from 711 matching the above steps and therefore being valid for use. 712 Which Rule to use among multiple valid Rules is left to the 713 implementation. As long as the same Rule set is installed at 714 both ends, this degree of freedom does not constitute an 715 interoperability issue. 717 * If no valid compression Rule is found, then the packet MUST be 718 sent uncompressed using the Rule ID dedicated to this purpose 719 (see Section 6). The entire packet header is the Compression 720 Residue (see Figure 4). Sending an uncompressed header is 721 likely to require SCHC F/R. 723 o Compression: if a valid Rule was found, each field of the header 724 is compressed according to the Compression/Decompression Actions 725 (CDAs) of the Rule. The fields are compressed in the order that 726 the Field Descriptions appear in the Rule. The compression of 727 each field results in a residue, which may be empty. The 728 Compression Residue for the packet header is the concatenation of 729 the non-empty residues for each field of the header, in the order 730 the Field Descriptions appear in the Rule. The order in which the 731 Field Descriptions appear in the Rule is therefore semantically 732 important. 734 |------------------- Compression Residue -------------------| 735 +-----------------+-----------------+-----+-----------------+ 736 | field 1 residue | field 2 residue | ... | field N residue | 737 +-----------------+-----------------+-----+-----------------+ 739 Figure 7: Compression Residue structure 741 o Sending: The Rule ID is sent to the other end followed by the 742 Compression Residue (which could be empty) or the uncompressed 743 header, and directly followed by the payload (see Figure 4). The 744 way the Rule ID is sent will be specified in the Profile and is 745 out of the scope of the present document. For example, it could 746 be included in an L2 header or sent as part of the L2 payload. 748 o Decompression: when decompressing, on the Network infrastructure 749 side the SCHC C/D needs to find the correct Rule based on the L2 750 address of the Dev; in this way, it can use the DevIID and the 751 Rule ID. On the Dev side, only the Rule ID is needed to identify 752 the correct Rule since the Dev typically only holds Rules that 753 apply to itself. 755 This Rule describes the compressed header format. From this, the 756 decompressor determines the order of the residues, the fixed-sized 757 or variable-sized nature of each residue (see Section 7.5.2), and 758 the size of the fixed-sized residues. 760 From the received compressed header, it can therefore retrieve all 761 the residue values and associate them to the corresponding header 762 fields. 764 For each field in the header, the receiver applies the CDA action 765 associated to that field in order to reconstruct the original 766 header field value. The CDA application order can be different 767 from the order in which the fields are listed in the Rule. In 768 particular, Compute-* MUST be applied after the application of the 769 CDAs of all the fields it computes on. 771 7.4. Matching operators 773 Matching Operators (MOs) are functions used by both SCHC C/D 774 endpoints. They are not typed and can be applied to integer, string 775 or any other data type. The result of the operation can either be 776 True or False. MOs are defined as follows: 778 o equal: The match result is True if the field value in the packet 779 matches the TV. 781 o ignore: No matching is attempted between the field value in the 782 packet and the TV in the Rule. The result is always true. 784 o MSB(x): A match is obtained if the most significant (leftmost) x 785 bits of the packet header field value are equal to the TV in the 786 Rule. The x parameter of the MSB MO indicates how many bits are 787 involved in the comparison. If the FL is described as variable, 788 the x parameter must be a multiple of the FL unit. For example, x 789 must be multiple of 8 if the unit of the variable length is bytes. 791 o match-mapping: With match-mapping, the Target Value is a list of 792 values. Each value of the list is identified by an index. 793 Compression is achieved by sending the index instead of the 794 original header field value. This operator matches if the header 795 field value is equal to one of the values in the target list. 797 7.5. Compression Decompression Actions (CDA) 799 The Compression Decompression Action (CDA) describes the actions 800 taken during the compression of header fields and the inverse action 801 taken by the decompressor to restore the original value. 803 +--------------+-------------+-------------------------------+ 804 | Action | Compression | Decompression | 805 +--------------+-------------+-------------------------------+ 806 | | | | 807 | not-sent | elided | use TV stored in Rule | 808 | value-sent | send | use received value | 809 | mapping-sent | send index | retrieve value from TV list | 810 | LSB | send LSB | concat. TV and received value | 811 | compute-* | elided | recompute at decompressor | 812 | DevIID | elided | build IID from L2 Dev addr | 813 | AppIID | elided | build IID from L2 App addr | 814 +--------------+-------------+-------------------------------+ 816 Table 1: Compression and Decompression Actions 818 Table 1 summarizes the basic actions that can be used to compress and 819 decompress a field. The first column shows the action's name. The 820 second and third columns show the compression and decompression 821 behaviors for each action. 823 7.5.1. processing fixed-length fields 825 If the field is identified in the Field Description as being of fixed 826 length, then applying the CDA to compress this field results in a 827 fixed amount of bits. The residue for that field is simply the bits 828 resulting from applying the CDA to the field. This value may be 829 empty (e.g., not-sent CDA), in which case the field residue is absent 830 from the Compression Residue. 832 |- field residue -| 833 +-----------------+ 834 | value | 835 +-----------------+ 837 Figure 8: fixed sized field residue structure 839 7.5.2. processing variable-length fields 841 If the field is identified in the Field Description as being of 842 variable length, then applying the CDA to compress this field may 843 result in a value of fixed size (e.g., not-sent or mapping-sent) or 844 of variable size (e.g., value-sent or LSB). In the latter case, the 845 residue for that field is the bits that result from applying the CDA 846 to the field, preceded with the size of the value. The most 847 significant bit of the size is stored to the left (leftmost bit of 848 the residue field). 850 |--- field residue ---| 851 +-------+-------------+ 852 | size | value | 853 +-------+-------------+ 855 Figure 9: variable sized field residue structure 857 The size (using the unit defined in the FL) is encoded on 4, 12 or 28 858 bits as follows: 860 o If the size is between 0 and 14, it is encoded as a 4 bits 861 unsigned integer. 863 o Sizes between 15 and 254 are encoded as 0b1111 followed by the 8 864 bits unsigned integer. 866 o Larger sizes are encoded as 0xfff followed by the 16 bits unsigned 867 integer. 869 If the field is identified in the Field Description as being of 870 variable length and this field is not present in the packet header 871 being compressed, size 0 MUST be sent to denote its absence. 873 7.5.3. not-sent CDA 875 The not-sent action can be used when the field value is specified in 876 a Rule and therefore known by both the Compressor and the 877 Decompressor. This action SHOULD be used with the "equal" MO. If MO 878 is "ignore", there is a risk to have a decompressed field value 879 different from the original field that was compressed. 881 The compressor does not send any residue for a field on which not- 882 sent compression is applied. 884 The decompressor restores the field value with the Target Value 885 stored in the matched Rule identified by the received Rule ID. 887 7.5.4. value-sent CDA 889 The value-sent action can be used when the field value is not known 890 by both the Compressor and the Decompressor. The field is sent in 891 its entirety, using the same bit order as in the original packet 892 header. 894 If this action is performed on a variable length field, the size of 895 the residue value (using the units defined in FL) MUST be sent as 896 described in Section 7.5.2. 898 This action is generally used with the "ignore" MO. 900 7.5.5. mapping-sent CDA 902 The mapping-sent action is used to send an index (the index into the 903 Target Value list of values) instead of the original value. This 904 action is used together with the "match-mapping" MO. 906 On the compressor side, the match-mapping Matching Operator searches 907 the TV for a match with the header field value. The mapping-sent CDA 908 then sends the corresponding index as the field residue. The most 909 significant bit of the index is stored to the left (leftmost bit of 910 the residue field). 912 On the decompressor side, the CDA uses the received index to restore 913 the field value by looking up the list in the TV. 915 The number of bits sent is the minimal size for coding all the 916 possible indices. 918 The first element in the list MUST be represented by index value 0, 919 and successive elements in the list MUST have indices incremented by 920 1. 922 7.5.6. LSB CDA 924 The LSB action is used together with the "MSB(x)" MO to avoid sending 925 the most significant part of the packet field if that part is already 926 known by the receiving end. 928 The compressor sends the Least Significant Bits as the field residue 929 value. The number of bits sent is the original header field length 930 minus the length specified in the MSB(x) MO. The bits appear in the 931 residue in the same bit order as in the original packet header. 933 The decompressor concatenates the x most significant bits of Target 934 Value and the received residue value. 936 If this action is performed on a variable length field, the size of 937 the residue value (using the units defined in FL) MUST be sent as 938 described in Section 7.5.2. 940 7.5.7. DevIID, AppIID CDA 942 These actions are used to process respectively the Dev and the App 943 Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. 944 AppIID CDA is less common since most current LPWAN technologies 945 frames contain a single L2 address, which is the Dev's address. 947 The IID value MAY be computed from the Device ID present in the L2 948 header, or from some other stable identifier. The computation is 949 specific to each Profile and MAY depend on the Device ID size. 951 In the downlink direction (Dw), at the compressor, the DevIID CDA may 952 be used to generate the L2 addresses on the LPWAN, based on the 953 packet's Destination Address. 955 7.5.8. Compute-* 957 Some fields can be elided at the compressor and recomputed locally at 958 the decompressor. 960 Because the field is uniquely identified by its Field ID (e.g., UDP 961 length), the relevant protocol specification unambiguously defines 962 the algorithm for such computation. 964 Examples of fields that know how to recompute themselves are UDP 965 length, IPv6 length and UDP checksum. 967 8. Fragmentation/Reassembly 969 8.1. Overview 971 In LPWAN technologies, the L2 MTU typically ranges from tens to 972 hundreds of bytes. Some of these technologies do not have an 973 internal fragmentation/reassembly mechanism. 975 The optional SCHC Fragmentation/Reassembly (SCHC F/R) functionality 976 enables such LPWAN technologies to comply with the IPv6 MTU 977 requirement of 1280 bytes [RFC8200]. It is OPTIONAL to implement per 978 this specification, but Profiles may specify that it is REQUIRED. 980 This specification includes several SCHC F/R modes, which allow for a 981 range of reliability options such as optional SCHC Fragment 982 retransmission. More modes may be defined in the future. 984 The same SCHC F/R mode MUST be used for all SCHC Fragments of a given 985 SCHC Packet. This document does not specify which mode(s) must be 986 implemented and used over a specific LPWAN technology. That 987 information will be given in Profiles. 989 SCHC allows transmitting non-fragmented SCHC Packet concurrently with 990 fragmented SCHC Packets. In addition, SCHC F/R provides protocol 991 elements that allow transmitting several fragmented SCHC Packets 992 concurrently, i.e. interleaving the transmission of fragments from 993 different fragmented SCHC Packets. A Profile MAY restrict the latter 994 behavior. 996 The L2 Word size (see Section 4) determines the encoding of some 997 messages. SCHC F/R usually generates SCHC Fragments and SCHC ACKs 998 that are multiples of L2 Words. 1000 8.2. SCHC F/R Protocol Elements 1002 This subsection describes the different elements that are used to 1003 enable the SCHC F/R functionality defined in this document. These 1004 elements include the SCHC F/R messages, tiles, windows, bitmaps, 1005 counters, timers and header fields. 1007 The elements are described here in a generic manner. Their 1008 application to each SCHC F/R mode is found in Section 8.4. 1010 8.2.1. Messages 1012 SCHC F/R defines the following messages: 1014 o SCHC Fragment: A message that carries part of a SCHC Packet from 1015 the sender to the receiver. 1017 o SCHC ACK: An acknowledgement for fragmentation, by the receiver to 1018 the sender. This message is used to indicate whether or not the 1019 reception of pieces of, or the whole of the fragmented SCHC 1020 Packet, was successful. 1022 o SCHC ACK REQ: A request by the sender for a SCHC ACK from the 1023 receiver. 1025 o SCHC Sender-Abort: A message by the sender telling the receiver 1026 that it has aborted the transmission of a fragmented SCHC Packet. 1028 o SCHC Receiver-Abort: A message by the receiver to tell the sender 1029 to abort the transmission of a fragmented SCHC Packet. 1031 The format of these messages is provided in Section 8.3. 1033 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 1035 8.2.2.1. Tiles 1037 The SCHC Packet is fragmented into pieces, hereafter called tiles. 1038 The tiles MUST be non-empty and pairwise disjoint. Their union MUST 1039 be equal to the SCHC Packet. 1041 See Figure 10 for an example. 1043 SCHC Packet 1044 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 1045 Tiles | | | | | | | | | | | | | | 1046 +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ 1048 Figure 10: a SCHC Packet fragmented in tiles 1050 Modes (see Section 8.4) MAY place additional constraints on tile 1051 sizes. 1053 Each SCHC Fragment message carries at least one tile in its Payload, 1054 if the Payload field is present. 1056 8.2.2.2. Windows 1058 Some SCHC F/R modes may handle successive tiles in groups, called 1059 windows. 1061 If windows are used 1063 o all the windows of a SCHC Packet, except the last one, MUST 1064 contain the same number of tiles. This number is WINDOW_SIZE. 1066 o WINDOW_SIZE MUST be specified in a Profile. 1068 o the windows are numbered. 1070 o their numbers MUST increment by 1 from 0 upward, from the start of 1071 the SCHC Packet to its end. 1073 o the last window MUST contain WINDOW_SIZE tiles or less. 1075 o tiles are numbered within each window. 1077 o the tile indices MUST decrement by 1 from WINDOW_SIZE - 1 1078 downward, looking from the start of the SCHC Packet toward its 1079 end. 1081 o each tile of a SCHC Packet is therefore uniquely identified by a 1082 window number and a tile index within this window. 1084 See Figure 11 for an example. 1086 +---------------------------------------------...-------------+ 1087 | SCHC Packet | 1088 +---------------------------------------------...-------------+ 1090 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 | 1091 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -| 1093 Figure 11: a SCHC Packet fragmented in tiles grouped in 29 windows, 1094 with WINDOW_SIZE = 5 1096 Appendix E discusses the benefits of selecting one among multiple 1097 window sizes depending on the size of the SCHC Packet to be 1098 fragmented. 1100 When windows are used 1102 o Bitmaps (see Section 8.2.2.3) MAY be sent back by the receiver to 1103 the sender in a SCHC ACK message. 1105 o A Bitmap corresponds to exactly one Window. 1107 8.2.2.3. Bitmaps 1109 Each bit in the Bitmap for a window corresponds to a tile in the 1110 window. Each Bitmap has therefore WINDOW_SIZE bits. The bit at the 1111 left-most position corresponds to the tile numbered WINDOW_SIZE - 1. 1112 Consecutive bits, going right, correspond to sequentially decreasing 1113 tile indices. In Bitmaps for windows that are not the last one of a 1114 SCHC Packet, the bit at the right-most position corresponds to the 1115 tile numbered 0. In the Bitmap for the last window, the bit at the 1116 right-most position corresponds either to the tile numbered 0 or to a 1117 tile that is sent/received as "the last one of the SCHC Packet" 1118 without explicitly stating its number (see Section 8.3.1.2). 1120 At the receiver 1122 o a bit set to 1 in the Bitmap indicates that a tile associated with 1123 that bit position has been correctly received for that window. 1125 o a bit set to 0 in the Bitmap indicates that there has been no tile 1126 correctly received, associated with that bit position, for that 1127 window. Possible reasons include that the tile was not sent at 1128 all, not received, or received with errors. 1130 8.2.2.4. Timers and counters 1132 Some SCHC F/R modes can use the following timers and counters 1134 o Inactivity Timer: a SCHC Fragment receiver uses this timer to 1135 abort waiting for a SCHC F/R message. 1137 o Retransmission Timer: a SCHC Fragment sender uses this timer to 1138 abort waiting for an expected SCHC ACK. 1140 o Attempts: this counter counts the requests for SCHC ACKs, up to 1141 MAX_ACK_REQUESTS. 1143 8.2.3. Integrity Checking 1145 The integrity of the fragmentation-reassembly process of a SCHC 1146 Packet MUST be checked at the receive end. A Profile MUST specify 1147 how integrity checking is performed. 1149 It is RECOMMENDED that integrity checking be performed by computing a 1150 Reassembly Check Sequence (RCS) based on the SCHC Packet at the 1151 sender side and transmitting it to the receiver for comparison with 1152 the RCS locally computed after reassembly. 1154 The RCS supports UDP checksum elision by SCHC C/D (see 1155 Section 10.11). 1157 The CRC32 polynomial 0xEDB88320 (i.e., the reversed polynomial 1158 representation, which is used in the Ethernet standard [ETHERNET]) is 1159 RECOMMENDED as the default algorithm for computing the RCS. 1161 The RCS MUST be computed on the full SCHC Packet concatenated with 1162 the padding bits, if any, of the SCHC Fragment carrying the last 1163 tile. The rationale is that the SCHC reassembler has no way of 1164 knowing the boundary between the last tile and the padding bits. 1165 Indeed, this requires decompressing the SCHC Packet, which is out of 1166 the scope of the SCHC reassembler. 1168 The concatenation of the complete SCHC Packet and any padding bits, 1169 if present, of the last SCHC Fragment does not generally constitute 1170 an integer number of bytes. CRC libraries are usually byte-oriented. 1171 It is RECOMMENDED that the concatenation of the complete SCHC Packet 1172 and any last fragment padding bits be zero-extended to the next byte 1173 boundary and that the RCS be computed on that byte array. 1175 8.2.4. Header Fields 1177 The SCHC F/R messages contain the following fields (see the formats 1178 in Section 8.3): 1180 o Rule ID: this field is present in all the SCHC F/R messages. The 1181 Rule identifies 1183 * that a SCHC F/R message is being carried, as opposed to an 1184 unfragmented SCHC Packet, 1186 * which SCHC F/R mode is used 1188 * in case this mode uses windows, what the value of WINDOW_SIZE 1189 is, 1191 * what other optional fields are present and what the field sizes 1192 are. 1194 The Rule tells apart a non-fragmented SCHC Packet from SCHC 1195 Fragments. It will also tell apart SCHC Fragments of fragmented 1196 SCHC Packets that use different SCHC F/R modes or different 1197 parameters. Interleaved transmission of these is therefore 1198 possible. 1200 All SCHC F/R messages pertaining to the same SCHC Packet MUST bear 1201 the same Rule ID. 1203 o Datagram Tag (DTag). This field allows differentiating SCHC F/R 1204 messages belonging to different SCHC Packets that may be using the 1205 same Rule ID simultaneously. Hence, it allows interleaving 1206 fragments of a new SCHC Packet with fragments of a previous SCHC 1207 Packet under the same Rule ID. 1209 The size of the DTag field (called T, in bits) is defined by each 1210 Profile for each Rule ID. When T is 0, the DTag field does not 1211 appear in the SCHC F/R messages and the DTag value is defined as 1212 0. 1214 When T is 0, there can be no more than one fragmented SCHC Packet 1215 in transit for each fragmentation Rule ID. 1217 If T is not 0, DTag 1219 * MUST be set to the same value for all the SCHC F/R messages 1220 related to the same fragmented SCHC Packet, 1222 * MUST be set to different values for SCHC F/R messages related 1223 to different SCHC Packets that are being fragmented under the 1224 same Rule ID, and whose transmission may overlap. 1226 o W: The W field is optional. It is only present if windows are 1227 used. Its presence and size (called M, in bits) is defined by 1228 each SCHC F/R mode and each Profile for each Rule ID. 1230 This field carries information pertaining to the window a SCHC F/R 1231 message relates to. If present, W MUST carry the same value for 1232 all the SCHC F/R messages related to the same window. Depending 1233 on the mode and Profile, W may carry the full window number, or 1234 just the least significant bit or any other partial representation 1235 of the window number. 1237 o Fragment Compressed Number (FCN). The FCN field is present in the 1238 SCHC Fragment Header. Its size (called N, in bits) is defined by 1239 each Profile for each Rule ID. 1241 This field conveys information about the progress in the sequence 1242 of tiles being transmitted by SCHC Fragment messages. For 1243 example, it can contain a partial, efficient representation of a 1244 larger-sized tile index. The description of the exact use of the 1245 FCN field is left to each SCHC F/R mode. However, two values are 1246 reserved for special purposes. They help control the SCHC F/R 1247 process: 1249 * The FCN value with all the bits equal to 1 (called All-1) 1250 signals that the very last tile of a SCHC Packet has been 1251 transmitted. By extension, if windows are used, the last 1252 window of a packet is called the All-1 window. 1254 * If windows are used, the FCN value with all the bits equal to 0 1255 (called All-0) signals the last tile of a window that is not 1256 the last one of the SCHC packet. By extension, such a window 1257 is called an All-0 window. 1259 o Reassembly Check Sequence (RCS). This field only appears in the 1260 All-1 SCHC Fragments. Its size (called U, in bits) is defined by 1261 each Profile for each Rule ID. 1263 See Section 8.2.3 for the RCS default size, default polynomial and 1264 details on RCS computation. 1266 o C (integrity Check): C is a 1-bit field. This field is used in 1267 the SCHC ACK message to report on the reassembled SCHC Packet 1268 integrity check (see Section 8.2.3). 1270 A value of 1 tells that the integrity check was performed and is 1271 successful. A value of 0 tells that the integrity check was not 1272 performed, or that is was a failure. 1274 o Compressed Bitmap. The Compressed Bitmap is used together with 1275 windows and Bitmaps (see Section 8.2.2.3). Its presence and size 1276 is defined for each F/R mode for each Rule ID. 1278 This field appears in the SCHC ACK message to report on the 1279 receiver Bitmap (see Section 8.3.2.1). 1281 8.3. SCHC F/R Message Formats 1283 This section defines the SCHC Fragment formats, the SCHC ACK format, 1284 the SCHC ACK REQ format and the SCHC Abort formats. 1286 8.3.1. SCHC Fragment format 1288 A SCHC Fragment conforms to the general format shown in Figure 12. 1289 It comprises a SCHC Fragment Header and a SCHC Fragment Payload. The 1290 SCHC Fragment Payload carries one or several tile(s). 1292 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1293 | Fragment Header | Fragment Payload | padding (as needed) 1294 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1296 Figure 12: SCHC Fragment general format 1298 8.3.1.1. Regular SCHC Fragment 1300 The Regular SCHC Fragment format is shown in Figure 13. Regular SCHC 1301 Fragments are generally used to carry tiles that are not the last one 1302 of a SCHC Packet. The DTag field and the W field are OPTIONAL, their 1303 presence is specified by each mode and Profile. 1305 |--- SCHC Fragment Header ----| 1306 |-- T --|-M-|-- N --| 1307 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1308 | Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed) 1309 +-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ 1311 Figure 13: Detailed Header Format for Regular SCHC Fragments 1313 The FCN field MUST NOT contain all bits set to 1. 1315 Profiles MUST ensure that a SCHC Fragment with FCN equal to 0 (called 1316 an All-0 SCHC Fragment) is distinguishable by size, even in the 1317 presence of padding, from a SCHC ACK REQ message (see Section 8.3.3) 1318 with the same Rule ID value and with the same T, M and N values. 1319 This condition is met if the Payload is at least the size of an L2 1320 Word. This condition is also met if the SCHC Fragment Header is a 1321 multiple of L2 Words. 1323 8.3.1.2. All-1 SCHC Fragment 1325 The All-1 SCHC Fragment format is shown in Figure 14. The sender 1326 uses the All-1 SCHC Fragment format for the message that completes 1327 the emission of a fragmented SCHC Packet. The DTag field, the W 1328 field, the RCS field and the Payload are OPTIONAL, their presence is 1329 specified by each mode and Profile. At least one of RCS field or 1330 Payload MUST be present. The FCN field is all ones. 1332 |-------- SCHC Fragment Header -------| 1333 |-- T --|-M-|-- N --|-- U --| 1334 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1335 | Rule ID | DTag | W | 11..1 | RCS | Frag Payload | pad. (as needed) 1336 +-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ 1337 (FCN) 1339 Figure 14: Detailed Header Format for the All-1 SCHC Fragment 1341 Profiles MUST ensure that an All-1 SCHC Fragment message is 1342 distinguishable by size, even in the presence of padding, from a SCHC 1343 Sender-Abort message (see Section 8.3.4) with the same Rule ID value 1344 and with the same T, M and N values. This condition is met if the 1345 RCS is present and is at least the size of an L2 Word, or if the 1346 Payload is present and at least the size an L2 Word. This condition 1347 is also met if the SCHC Sender-Abort Header is a multiple of L2 1348 Words. 1350 8.3.2. SCHC ACK format 1352 The SCHC ACK message is shown in Figure 15. The DTag field and the W 1353 field are OPTIONAL, their presence is specified by each mode and 1354 Profile. The Compressed Bitmap field MUST be present in SCHC F/R 1355 modes that use windows, and MUST NOT be present in other modes. 1357 |---- SCHC ACK Header ----| 1358 |-- T --|-M-| 1 | 1359 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1360 | Rule ID | DTag | W |C=1| padding as needed (success) 1361 +--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ 1363 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1364 | Rule ID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) 1365 +--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ 1367 Figure 15: Format of the SCHC ACK message 1369 The SCHC ACK Header contains a C bit (see Section 8.2.4). 1371 If the C bit is set to 1 (integrity check successful), no Bitmap is 1372 carried. 1374 If the C bit is set to 0 (integrity check not performed or failed) 1375 and if windows are used, a Compressed Bitmap for the window referred 1376 to by the W field is transmitted as specified in Section 8.3.2.1. 1378 8.3.2.1. Bitmap Compression 1380 For transmission, the Compressed Bitmap in the SCHC ACK message is 1381 defined by the following algorithm (see Figure 16 for a follow-along 1382 example): 1384 o Build a temporary SCHC ACK message that contains the Header 1385 followed by the original Bitmap (see Section 8.2.2.3 for a 1386 description of Bitmaps). 1388 o Position scissors at the end of the Bitmap, after its last bit. 1390 o While the bit on the left of the scissors is 1 and belongs to the 1391 Bitmap, keep moving left, then stop. When this is done, 1393 o While the scissors are not on an L2 Word boundary of the SCHC ACK 1394 message and there is a Bitmap bit on the right of the scissors, 1395 keep moving right, then stop. 1397 o At this point, cut and drop off any bits to the right of the 1398 scissors 1400 When one or more bits have effectively been dropped off as a result 1401 of the above algorithm, the SCHC ACK message is a multiple of L2 1402 Words, no padding bits will be appended. 1404 Because the SCHC Fragment sender knows the size of the original 1405 Bitmap, it can reconstruct the original Bitmap from the Compressed 1406 Bitmap received in the SCH ACK message. 1408 Figure 16 shows an example where L2 Words are actually bytes and 1409 where the original Bitmap contains 17 bits, the last 15 of which are 1410 all set to 1. 1412 |---- SCHC ACK Header ----|-------- Bitmap --------| 1413 |-- T --|-M-| 1 | 1414 +--- ... -+- ... -+---+---+---------------------------------+ 1415 | Rule ID | DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| 1416 +--- ... -+- ... -+---+---+---------------------------------+ 1417 next L2 Word boundary ->| 1419 Figure 16: SCHC ACK Header plus uncompressed Bitmap 1421 Figure 17 shows that the last 14 bits are not sent. 1423 |---- SCHC ACK Header ----|CpBmp| 1424 |-- T --|-M-| 1 | 1425 +--- ... -+- ... -+---+---+-----+ 1426 | Rule ID | DTag | W |C=0|1 0 1| 1427 +--- ... -+- ... -+---+---+-----+ 1428 next L2 Word boundary ->| 1430 Figure 17: Resulting SCHC ACK message with Compressed Bitmap 1432 Figure 18 shows an example of a SCHC ACK with tile indices ranging 1433 from 6 down to 0, where the Bitmap indicates that the second and the 1434 fourth tile of the window have not been correctly received. 1436 |---- SCHC ACK Header ----|--- Bitmap --| 1437 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1438 +---------+-------+---+---+-------------+ 1439 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1| uncompressed Bitmap 1440 +---------+-------+---+---+-------------+ 1441 next L2 Word boundary ->|<-- L2 Word -->| 1443 +---------+-------+---+---+-------------+~~~+ 1444 | Rule ID | DTag | W |C=0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK 1445 +---------+-------+---+---+-------------+~~~+ 1446 next L2 Word boundary ->|<-- L2 Word -->| 1448 Figure 18: Example of a SCHC ACK message, missing tiles 1450 Figure 19 shows an example of a SCHC ACK with FCN ranging from 6 down 1451 to 0, where integrity check has not been performed or has failed and 1452 the Bitmap indicates that there is no missing tile in that window. 1454 |---- SCHC ACK Header ----|--- Bitmap --| 1455 |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #) 1456 +---------+-------+---+---+-------------+ 1457 | Rule ID | DTag | W |C=0|1 1 1 1 1 1 1| with uncompressed Bitmap 1458 +---------+-------+---+---+-------------+ 1459 next L2 Word boundary ->| 1461 +--- ... -+- ... -+---+---+-+ 1462 | Rule ID | DTag | W |C=0|1| transmitted SCHC ACK 1463 +--- ... -+- ... -+---+---+-+ 1464 next L2 Word boundary ->| 1466 Figure 19: Example of a SCHC ACK message, no missing tile 1468 8.3.3. SCHC ACK REQ format 1470 The SCHC ACK REQ is used by a sender to request a SCHC ACK from the 1471 receiver. Its format is shown in Figure 20. The DTag field and the 1472 W field are OPTIONAL, their presence is specified by each mode and 1473 Profile. The FCN field is all zero. 1475 |---- SCHC ACK REQ Header ----| 1476 |-- T --|-M-|-- N --| 1477 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1478 | Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) 1479 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1481 Figure 20: SCHC ACK REQ format 1483 8.3.4. SCHC Sender-Abort format 1485 When a SCHC Fragment sender needs to abort an on-going fragmented 1486 SCHC Packet transmission, it sends a SCHC Sender-Abort message to the 1487 SCHC Fragment receiver. 1489 The SCHC Sender-Abort format is shown in Figure 21. The DTag field 1490 and the W field are OPTIONAL, their presence is specified by each 1491 mode and Profile. The FCN field is all ones. 1493 |---- Sender-Abort Header ----| 1494 |-- T --|-M-|-- N --| 1495 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1496 | Rule ID | DTag | W | 11..1 | padding (as needed) 1497 +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1499 Figure 21: SCHC Sender-Abort format 1501 If the W field is present, 1503 o the fragment sender MUST set it to all ones. Other values are 1504 RESERVED. 1506 o the fragment receiver MUST check its value. If the value is 1507 different from all ones, the message MUST be ignored. 1509 The SCHC Sender-Abort MUST NOT be acknowledged. 1511 8.3.5. SCHC Receiver-Abort format 1513 When a SCHC Fragment receiver needs to abort an on-going fragmented 1514 SCHC Packet transmission, it transmits a SCHC Receiver-Abort message 1515 to the SCHC Fragment sender. 1517 The SCHC Receiver-Abort format is shown in Figure 22. The DTag field 1518 and the W field are OPTIONAL, their presence is specified by each 1519 mode and Profile. 1521 |--- Receiver-Abort Header ---| 1522 |--- T ---|-M-| 1 | 1523 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1524 | Rule ID | DTag | W |C=1| 1..1| 1..1 | 1525 +--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ 1526 next L2 Word boundary ->|<-- L2 Word -->| 1528 Figure 22: SCHC Receiver-Abort format 1530 If the W field is present, 1531 o the fragment receiver MUST set it to all ones. Other values are 1532 RESERVED. 1534 o if the value is different from all ones, the fragment sender MUST 1535 ignore the message. 1537 The SCHC Receiver-Abort has the same header as a SCHC ACK message. 1538 The bits that follow the SCHC Receiver-Abort Header MUST be as 1539 follows 1541 o if the Header does not end at an L2 Word boundary, append bits set 1542 to 1 as needed to reach the next L2 Word boundary 1544 o append exactly one more L2 Word with bits all set to ones 1546 Such a bit pattern never occurs in a legitimate SCHC ACK. This is 1547 how the fragment sender recognizes a SCHC Receiver-Abort. 1549 The SCHC Receiver-Abort MUST NOT be acknowledged. 1551 8.4. SCHC F/R modes 1553 This specification includes several SCHC F/R modes, which 1555 o allow for a range of reliability options, such as optional SCHC 1556 Fragment retransmission 1558 o support various LPWAN characteristics, such as links with variable 1559 MTU or unidirectional links. 1561 More modes may be defined in the future. 1563 Appendix B provides examples of fragmentation sessions based on the 1564 modes described hereafter. 1566 Appendix C provides examples of Finite State Machines implementing 1567 the SCHC F/R modes described hereafter. 1569 8.4.1. No-ACK mode 1571 The No-ACK mode has been designed under the assumption that data unit 1572 out-of-sequence delivery does not occur between the entity performing 1573 fragmentation and the entity performing reassembly. This mode 1574 supports LPWAN technologies that have a variable MTU. 1576 In No-ACK mode, there is no communication from the fragment receiver 1577 to the fragment sender. The sender transmits all the SCHC Fragments 1578 without expecting any acknowledgement. Therefore, No-ACK does not 1579 require bidirectional links: unidirectional links are just fine. 1581 In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. 1582 The other SCHC Fragments are intrinsically aligned to L2 Words. 1584 The tile sizes are not required to be uniform. Windows are not used. 1585 The Retransmission Timer is not used. The Attempts counter is not 1586 used. 1588 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1589 F/R messages operating in this mode. 1591 The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK 1592 MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort 1593 MAY be sent. SCHC Receiver-Abort MUST NOT be sent. 1595 The value of N (size of the FCN field) is RECOMMENDED to be 1. 1597 Each Profile, for each Rule ID value, MUST define 1599 o the size of the DTag field, 1601 o the size and algorithm for the RCS field, 1603 o the expiration time of the Inactivity Timer 1605 Each Profile, for each Rule ID value, MAY define 1607 o a value of N different from the recommended one, 1609 o the meaning of values sent in the FCN field, for values different 1610 from the All-1 value. 1612 For each active pair of Rule ID and DTag values, the receiver MUST 1613 maintain an Inactivity Timer. If the receiver is under-resourced to 1614 do this, it MUST silently drop the related messages. 1616 8.4.1.1. Sender behavior 1618 At the beginning of the fragmentation of a new SCHC Packet, the 1619 fragment sender MUST select a Rule ID and DTag value pair for this 1620 SCHC Packet. 1622 Each SCHC Fragment MUST contain exactly one tile in its Payload. The 1623 tile MUST be at least the size of an L2 Word. The sender MUST 1624 transmit the SCHC Fragments messages in the order that the tiles 1625 appear in the SCHC Packet. Except for the last tile of a SCHC 1626 Packet, each tile MUST be of a size that complements the SCHC 1627 Fragment Header so that the SCHC Fragment is a multiple of L2 Words 1628 without the need for padding bits. Except for the last one, the SCHC 1629 Fragments MUST use the Regular SCHC Fragment format specified in 1630 Section 8.3.1.1. The SCHC Fragment that carries the last tile MUST 1631 be an All-1 SCHC Fragment, described in Section 8.3.1.2. 1633 The sender MAY transmit a SCHC Sender-Abort. 1635 Figure 37 shows an example of a corresponding state machine. 1637 8.4.1.2. Receiver behavior 1639 Upon receiving each Regular SCHC Fragment, 1641 o the receiver MUST reset the Inactivity Timer, 1643 o the receiver assembles the payloads of the SCHC Fragments 1645 On receiving an All-1 SCHC Fragment, 1647 o the receiver MUST append the All-1 SCHC Fragment Payload and the 1648 padding bits to the previously received SCHC Fragment Payloads for 1649 this SCHC Packet 1651 o the receiver MUST perform the integrity check 1653 o if integrity checking fails, the receiver MUST drop the 1654 reassembled SCHC Packet 1656 o the reassembly operation concludes. 1658 On expiration of the Inactivity Timer, the receiver MUST drop the 1659 SCHC Packet being reassembled. 1661 On receiving a SCHC Sender-Abort, the receiver MAY drop the SCHC 1662 Packet being reassembled. 1664 Figure 38 shows an example of a corresponding state machine. 1666 8.4.2. ACK-Always mode 1668 The ACK-Always mode has been designed under the following assumptions 1670 o Data unit out-of-sequence delivery does not occur between the 1671 entity performing fragmentation and the entity performing 1672 reassembly 1674 o The L2 MTU value does not change while the fragments of a SCHC 1675 Packet are being transmitted. 1677 o There is a feedback path from the reassembler to the fragmenter. 1678 See Appendix F for a discussion on using ACK-Always mode on quasi- 1679 bidirectional links. 1681 In ACK-Always mode, windows are used. An acknowledgement, positive 1682 or negative, is transmitted by the fragment receiver to the fragment 1683 sender at the end of the transmission of each window of SCHC 1684 Fragments. 1686 The tiles are not required to be of uniform size. In ACK-Always 1687 mode, only the All-1 SCHC Fragment is padded as needed. The other 1688 SCHC Fragments are intrinsically aligned to L2 Words. 1690 Briefly, the algorithm is as follows: after a first blind 1691 transmission of all the tiles of a window, the fragment sender 1692 iterates retransmitting the tiles that are reported missing until the 1693 fragment receiver reports that all the tiles belonging to the window 1694 have been correctly received, or until too many attempts were made. 1695 The fragment sender only advances to the next window of tiles when it 1696 has ascertained that all the tiles belonging to the current window 1697 have been fully and correctly received. This results in a per-window 1698 lock-step behavior between the sender and the receiver. 1700 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 1701 F/R messages operating in this mode. 1703 The W field MUST be present and its size M MUST be 1 bit. 1705 Each Profile, for each Rule ID value, MUST define 1707 o the value of N (size of the FCN field), 1709 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 1711 o the size and algorithm for the RCS field, 1713 o the size of the DTag field, 1715 o the value of MAX_ACK_REQUESTS, 1717 o the expiration time of the Retransmission Timer 1719 o the expiration time of the Inactivity Timer 1720 For each active pair of Rule ID and DTag values, the sender MUST 1721 maintain 1723 o one Attempts counter 1725 o one Retransmission Timer 1727 For each active pair of Rule ID and DTag values, the receiver MUST 1728 maintain 1730 o one Inactivity Timer 1732 o one Attempts counter 1734 8.4.2.1. Sender behavior 1736 At the beginning of the fragmentation of a new SCHC Packet, the 1737 fragment sender MUST select a Rule ID and DTag value pair for this 1738 SCHC Packet. 1740 Each SCHC Fragment MUST contain exactly one tile in its Payload. All 1741 tiles with the index 0, as well as the last tile, MUST be at least 1742 the size of an L2 Word. 1744 In all SCHC Fragment messages, the W field MUST be filled with the 1745 least significant bit of the window number that the sender is 1746 currently processing. 1748 For a SCHC Fragment that carries a tile other than the last one of 1749 the SCHC Packet, 1751 o the Fragment MUST be of the Regular type specified in 1752 Section 8.3.1.1 1754 o the FCN field MUST contain the tile index 1756 o each tile MUST be of a size that complements the SCHC Fragment 1757 Header so that the SCHC Fragment is a multiple of L2 Words without 1758 the need for padding bits. 1760 The SCHC Fragment that carries the last tile MUST be an All-1 SCHC 1761 Fragment, described in Section 8.3.1.2. 1763 The fragment sender MUST start by transmitting the window numbered 0. 1765 All message receptions being discussed in the rest of this section 1766 are to be understood as "matching the RuleID and DTag pair being 1767 processed", even if not spelled out, for brevity. 1769 The sender starts by a "blind transmission" phase, in which it MUST 1770 transmit all the tiles composing the window, in decreasing tile index 1771 order. 1773 Then, it enters a "retransmission phase" in which it MUST initialize 1774 an Attempts counter to 0, it MUST start a Retransmission Timer and it 1775 MUST await a SCHC ACK. Then, 1777 o upon receiving a SCHC ACK, 1779 * if the SCHC ACK indicates that some tiles are missing at the 1780 receiver, then the sender MUST transmit all the tiles that have 1781 been reported missing, it MUST increment Attempts, it MUST 1782 reset the Retransmission Timer and MUST await the next SCHC 1783 ACK. 1785 * if the current window is not the last one and the SCHC ACK 1786 indicates that all tiles were correctly received, the sender 1787 MUST stop the Retransmission Timer, it MUST advance to the next 1788 fragmentation window and it MUST start a blind transmission 1789 phase as described above. 1791 * if the current window is the last one and the SCHC ACK 1792 indicates that more tiles were received than the sender sent, 1793 the fragment sender MUST send a SCHC Sender-Abort, and it MAY 1794 exit with an error condition. 1796 * if the current window is the last one and the SCHC ACK 1797 indicates that all tiles were correctly received yet integrity 1798 check was a failure, the fragment sender MUST send a SCHC 1799 Sender-Abort, and it MAY exit with an error condition. 1801 * if the current window is the last one and the SCHC ACK 1802 indicates that integrity checking was successful, the sender 1803 exits successfully. 1805 o on Retransmission Timer expiration, 1807 * if Attempts is strictly less that MAX_ACK_REQUESTS, the 1808 fragment sender MUST send a SCHC ACK REQ and MUST increment the 1809 Attempts counter. 1811 * otherwise the fragment sender MUST send a SCHC Sender-Abort, 1812 and it MAY exit with an error condition. 1814 At any time, 1815 o on receiving a SCHC Receiver-Abort, the fragment sender MAY exit 1816 with an error condition. 1818 o on receiving a SCHC ACK that bears a W value different from the W 1819 value that it currently uses, the fragment sender MUST silently 1820 discard and ignore that SCHC ACK. 1822 Figure 39 shows an example of a corresponding state machine. 1824 8.4.2.2. Receiver behavior 1826 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 1827 processed at that time 1829 o the receiver SHOULD check if the DTag value has not recently been 1830 used for that Rule ID value, thereby ensuring that the received 1831 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 1832 transmission. The initial value of the Inactivity Timer is the 1833 RECOMMENDED lifetime for the DTag value at the receiver. If the 1834 SCHC Fragment is determined to be such a remnant, the receiver MAY 1835 silently ignore it and discard it. 1837 o the receiver MUST start a process to assemble a new SCHC Packet 1838 with that Rule ID and DTag value pair. 1840 o the receiver MUST start an Inactivity Timer for that RuleID and 1841 DTag pair. It MUST initialize an Attempts counter to 0 for that 1842 RuleID and DTag pair. It MUST initialize a window counter to 0. 1843 If the receiver is under-resourced to do this, it MUST respond to 1844 the sender with a SCHC Receiver Abort. 1846 In the rest of this section, "local W bit" means the least 1847 significant bit of the window counter of the receiver. 1849 On reception of any SCHC F/R message for the RuleID and DTag pair 1850 being processed, the receiver MUST reset the Inactivity Timer 1851 pertaining to that RuleID and DTag pair. 1853 All message receptions being discussed in the rest of this section 1854 are to be understood as "matching the RuleID and DTag pair being 1855 processed", even if not spelled out, for brevity. 1857 The receiver MUST first initialize an empty Bitmap for the first 1858 window, then enter an "acceptance phase", in which 1860 o on receiving a SCHC Fragment or a SCHC ACK REQ, either one having 1861 the W bit different from the local W bit, the receiver MUST 1862 silently ignore and discard that message. 1864 o on receiving a SCHC ACK REQ with the W bit equal to the local W 1865 bit, the receiver MUST send a SCHC ACK for this window. 1867 o on receiving a SCHC Fragment with the W bit equal to the local W 1868 bit, the receiver MUST assemble the received tile based on the 1869 window counter and on the FCN field in the SCHC Fragment and it 1870 MUST update the Bitmap. 1872 * if the SCHC Fragment received is an All-0 SCHC Fragment, the 1873 current window is determined to be a not-last window, the 1874 receiver MUST send a SCHC ACK for this window and it MUST enter 1875 the "retransmission phase" for this window. 1877 * if the SCHC Fragment received is an All-1 SCHC Fragment, the 1878 padding bits of the All-1 SCHC Fragment MUST be assembled after 1879 the received tile, the current window is determined to be the 1880 last window, the receiver MUST perform the integrity check and 1881 it MUST send a SCHC ACK for this window. Then, 1883 + If the integrity check indicates that the full SCHC Packet 1884 has been correctly reassembled, the receiver MUST enter the 1885 "clean-up phase" for this window. 1887 + If the integrity check indicates that the full SCHC Packet 1888 has not been correctly reassembled, the receiver enters the 1889 "retransmission phase" for this window. 1891 In the "retransmission phase": 1893 o if the window is a not-last window 1895 * on receiving a SCHC Fragment that is not All-0 or All-1 and 1896 that has a W bit different from the local W bit, the receiver 1897 MUST increment its window counter and allocate a fresh Bitmap, 1898 it MUST assemble the tile received and update the Bitmap and it 1899 MUST enter the "acceptance phase" for that new window. 1901 * on receiving a SCHC ACK REQ with a W bit different from the 1902 local W bit, the receiver MUST increment its window counter and 1903 allocate a fresh Bitmap, it MUST send a SCHC ACK for that new 1904 window and it MUST enter the "acceptance phase" for that new 1905 window. 1907 * on receiving a SCHC All-0 Fragment with a W bit different from 1908 the local W bit, the receiver MUST increment its window counter 1909 and allocate a fresh Bitmap, it MUST assemble the tile received 1910 and update the Bitmap, it MUST send a SCHC ACK for that new 1911 window and it MUST stay in the "retransmission phase" for that 1912 new window. 1914 * on receiving a SCHC All-1 Fragment with a W bit different from 1915 the local W bit, the receiver MUST increment its window counter 1916 and allocate a fresh Bitmap, it MUST assemble the tile 1917 received, including the padding bits, it MUST update the Bitmap 1918 and perform the integrity check, it MUST send a SCHC ACK for 1919 the new window, which is determined to be the last window. 1920 Then, 1922 + If the integrity check indicates that the full SCHC Packet 1923 has been correctly reassembled, the receiver MUST enter the 1924 "clean-up phase" for that new window. 1926 + If the integrity check indicates that the full SCHC Packet 1927 has not been correctly reassembled, the receiver enters the 1928 "retransmission phase" for that new window. 1930 * on receiving a SCHC Fragment with a W bit equal to the local W 1931 bit, 1933 + if the SCHC Fragment received is an All-1 SCHC Fragment, the 1934 receiver MUST silently ignore it and discard it. 1936 + otherwise, the receiver MUST assemble the tile received and 1937 update the Bitmap. If the Bitmap becomes fully populated 1938 with 1's or if the SCHC Fragment is an All-0, the receiver 1939 MUST send a SCHC ACK for this window. 1941 * on receiving a SCHC ACK REQ with the W bit equal to the local W 1942 bit, the receiver MUST send a SCHC ACK for this window. 1944 o if the window is the last window 1946 * on receiving a SCHC Fragment or a SCHC ACK REQ, either one 1947 having a W bit different from the local W bit, the receiver 1948 MUST silently ignore and discard that message. 1950 * on receiving a SCHC ACK REQ with the W bit equal to the local W 1951 bit, the receiver MUST send a SCHC ACK for this window. 1953 * on receiving a SCHC Fragment with a W bit equal to the local W 1954 bit, 1956 + if the SCHC Fragment received is an All-0 SCHC Fragment, the 1957 receiver MUST silently ignore it and discard it. 1959 + otherwise, the receiver MUST update the Bitmap and it MUST 1960 assemble the tile received. If the SCHC Fragment received 1961 is an All-1 SCHC Fragment, the receiver MUST assemble the 1962 padding bits of the All-1 SCHC Fragment after the received 1963 tile, it MUST perform the integrity check and 1965 - if the integrity check indicates that the full SCHC 1966 Packet has been correctly reassembled, the receiver MUST 1967 send a SCHC ACK and it enters the "clean-up phase". 1969 - if the integrity check indicates that the full SCHC 1970 Packet has not been correctly reassembled, 1972 o if the SCHC Fragment received was an All-1 SCHC 1973 Fragment, the receiver MUST send a SCHC ACK for this 1974 window. 1976 In the "clean-up phase": 1978 o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, either one 1979 having the W bit equal to the local W bit, the receiver MUST send 1980 a SCHC ACK. 1982 o Any other SCHC Fragment received MUST be silently ignored and 1983 discarded. 1985 At any time, on sending a SCHC ACK, the receiver MUST increment the 1986 Attempts counter. 1988 At any time, on incrementing its window counter, the receiver MUST 1989 reset the Attempts counter. 1991 At any time, on expiration of the Inactivity Timer, on receiving a 1992 SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the 1993 receiver MUST send a SCHC Receiver-Abort and it MAY exit the receive 1994 process for that SCHC Packet. 1996 Figure 40 shows an example of a corresponding state machine. 1998 8.4.3. ACK-on-Error mode 2000 The ACK-on-Error mode supports LPWAN technologies that have variable 2001 MTU and out-of-order delivery. It operates with links that provide a 2002 feedback path from the reassembler to the fragmenter. See Appendix F 2003 for a discussion on using ACK-on-Error mode on quasi-bidirectional 2004 links. 2006 In ACK-on-Error mode, windows are used. 2008 All tiles, but the last one and the penultimate one, MUST be of equal 2009 size, hereafter called "regular". The size of the last tile MUST be 2010 smaller than or equal to the regular tile size. Regarding the 2011 penultimate tile, a Profile MUST pick one of the following two 2012 options: 2014 o The penultimate tile size MUST be the regular tile size 2016 o or the penultimate tile size MUST be either the regular tile size 2017 or the regular tile size minus one L2 Word. 2019 A SCHC Fragment message carries one or several contiguous tiles, 2020 which may span multiple windows. A SCHC ACK reports on the reception 2021 of exactly one window of tiles. 2023 See Figure 23 for an example. 2025 +---------------------------------------------...-----------+ 2026 | SCHC Packet | 2027 +---------------------------------------------...-----------+ 2029 Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| 2030 Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| 2032 SCHC Fragment msg |-----------| 2034 Figure 23: a SCHC Packet fragmented in tiles, ACK-on-Error mode 2036 The W field is wide enough that it unambiguously represents an 2037 absolute window number. The fragment receiver sends SCHC ACKs to the 2038 fragment sender about windows for which tiles are missing. No SCHC 2039 ACK is sent by the fragment receiver for windows that it knows have 2040 been fully received. 2042 The fragment sender retransmits SCHC Fragments for tiles that are 2043 reported missing. It can advance to next windows even before it has 2044 ascertained that all tiles belonging to previous windows have been 2045 correctly received, and can still later retransmit SCHC Fragments 2046 with tiles belonging to previous windows. Therefore, the sender and 2047 the receiver may operate in a decoupled fashion. The fragmented SCHC 2048 Packet transmission concludes when 2050 o integrity checking shows that the fragmented SCHC Packet has been 2051 correctly reassembled at the receive end, and this information has 2052 been conveyed back to the sender, 2054 o or too many retransmission attempts were made, 2055 o or the receiver determines that the transmission of this 2056 fragmented SCHC Packet has been inactive for too long. 2058 Each Profile MUST specify which Rule ID value(s) correspond to SCHC 2059 F/R messages operating in this mode. 2061 The W field MUST be present in the SCHC F/R messages. 2063 Each Profile, for each Rule ID value, MUST define 2065 o the tile size (a tile does not need to be multiple of an L2 Word, 2066 but it MUST be at least the size of an L2 Word) 2068 o the value of M (size of the W field), 2070 o the value of N (size of the FCN field), 2072 o the value of WINDOW_SIZE, which MUST be strictly less than 2^N, 2074 o the size and algorithm for the RCS field, 2076 o the size of the DTag field, 2078 o the value of MAX_ACK_REQUESTS, 2080 o the expiration time of the Retransmission Timer 2082 o the expiration time of the Inactivity Timer 2084 o whether the last tile is carried in a Regular SCHC Fragment or an 2085 All-1 SCHC Fragment (see Section 8.4.3.1) 2087 o if the penultimate tile MAY be one L2 Word smaller than the 2088 regular tile size. In this case, the regular tile size MUST be at 2089 least twice the L2 Word size. 2091 For each active pair of Rule ID and DTag values, the sender MUST 2092 maintain 2094 o one Attempts counter 2096 o one Retransmission Timer 2098 For each active pair of Rule ID and DTag values, the receiver MUST 2099 maintain 2101 o one Inactivity Timer 2102 o one Attempts counter 2104 8.4.3.1. Sender behavior 2106 At the beginning of the fragmentation of a new SCHC Packet, 2108 o the fragment sender MUST select a Rule ID and DTag value pair for 2109 this SCHC Packet. A Rule MUST NOT be selected if the values of M 2110 and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot 2111 be fragmented in (2^M) * WINDOW_SIZE tiles or less. 2113 o the fragment sender MUST initialize the Attempts counter to 0 for 2114 that Rule ID and DTag value pair. 2116 A Regular SCHC Fragment message carries in its payload one or more 2117 tiles. If more than one tile is carried in one Regular SCHC Fragment 2119 o the selected tiles MUST be contiguous in the original SCHC Packet 2121 o they MUST be placed in the SCHC Fragment Payload adjacent to one 2122 another, in the order they appear in the SCHC Packet, from the 2123 start of the SCHC Packet toward its end. 2125 Tiles that are not the last one MUST be sent in Regular SCHC 2126 Fragments specified in Section 8.3.1.1. The FCN field MUST contain 2127 the tile index of the first tile sent in that SCHC Fragment. 2129 In a Regular SCHC Fragment message, the sender MUST fill the W field 2130 with the window number of the first tile sent in that SCHC Fragment. 2132 Depending on the Profile, the last tile of a SCHC Packet MUST be sent 2133 either 2135 o in a Regular SCHC Fragment, alone or as part of a multi-tiles 2136 Payload 2138 o alone in an All-1 SCHC Fragment 2140 In an All-1 SCHC Fragment message, the sender MUST fill the W field 2141 with the window number of the last tile of the SCHC Packet. 2143 The fragment sender MUST send SCHC Fragments such that, all together, 2144 they contain all the tiles of the fragmented SCHC Packet. 2146 The fragment sender MUST send at least one All-1 SCHC Fragment. 2148 The fragment sender MUST listen for SCHC ACK messages after having 2149 sent 2150 o an All-1 SCHC Fragment 2152 o or a SCHC ACK REQ. 2154 A Profile MAY specify other times at which the fragment sender MUST 2155 listen for SCHC ACK messages. For example, this could be after 2156 sending a complete window of tiles. 2158 Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC 2159 ACK REQ, 2161 o it MUST increment the Attempts counter 2163 o it MUST reset the Retransmission Timer 2165 On Retransmission Timer expiration 2167 o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment 2168 sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ 2169 with the W field corresponding to the last window, 2171 o otherwise the fragment sender MUST send a SCHC Sender-Abort and it 2172 MAY exit with an error condition. 2174 All message receptions being discussed in the rest of this section 2175 are to be understood as "matching the RuleID and DTag pair being 2176 processed", even if not spelled out, for brevity. 2178 On receiving a SCHC ACK, 2180 o if the W field in the SCHC ACK corresponds to the last window of 2181 the SCHC Packet, 2183 * if the C bit is set, the sender MAY exit successfully 2185 * otherwise, 2187 + if the Profile mandates that the last tile be sent in an 2188 All-1 SCHC Fragment, 2190 - if the SCHC ACK shows no missing tile at the receiver, 2191 the sender 2193 o MUST send a SCHC Sender-Abort 2195 o MAY exit with an error condition 2197 - otherwise 2198 o the fragment sender MUST send SCHC Fragment messages 2199 containing all the tiles that are reported missing in 2200 the SCHC ACK. 2202 o if the last of these SCHC Fragment messages is not an 2203 All-1 SCHC Fragment, then the fragment sender MUST in 2204 addition send after it a SCHC ACK REQ with the W field 2205 corresponding to the last window. 2207 + otherwise, 2209 - if the SCHC ACK shows no missing tile at the receiver, 2210 the sender MUST send the All-1 SCHC Fragment 2212 - otherwise 2214 o the fragment sender MUST send SCHC Fragment messages 2215 containing all the tiles that are reported missing in 2216 the SCHC ACK. 2218 o the fragment sender MUST then send either the All-1 2219 SCHC Fragment or a SCHC ACK REQ with the W field 2220 corresponding to the last window. 2222 o otherwise, the fragment sender 2224 * MUST send SCHC Fragment messages containing the tiles that are 2225 reported missing in the SCHC ACK 2227 * then it MAY send a SCHC ACK REQ with the W field corresponding 2228 to the last window 2230 See Figure 41 for one among several possible examples of a Finite 2231 State Machine implementing a sender behavior obeying this 2232 specification. 2234 8.4.3.2. Receiver behavior 2236 On receiving a SCHC Fragment with a Rule ID and DTag pair not being 2237 processed at that time 2239 o the receiver SHOULD check if the DTag value has not recently been 2240 used for that Rule ID value, thereby ensuring that the received 2241 SCHC Fragment is not a remnant of a prior fragmented SCHC Packet 2242 transmission. The initial value of the Inactivity Timer is the 2243 RECOMMENDED lifetime for the DTag value at the receiver. If the 2244 SCHC Fragment is determined to be such a remnant, the receiver MAY 2245 silently ignore it and discard it. 2247 o the receiver MUST start a process to assemble a new SCHC Packet 2248 with that Rule ID and DTag value pair. The receiver MUST start an 2249 Inactivity Timer for that Rule ID and DTag value pair. It MUST 2250 initialize an Attempts counter to 0 for that Rule ID and DTag 2251 value pair. If the receiver is under-resourced to do this, it 2252 MUST respond to the sender with a SCHC Receiver Abort. 2254 On reception of any SCHC F/R message for the RuleID and DTag pair 2255 being processed, the receiver MUST reset the Inactivity Timer 2256 pertaining to that RuleID and DTag pair. 2258 All message receptions being discussed in the rest of this section 2259 are to be understood as "matching the RuleID and DTag pair being 2260 processed", even if not spelled out, for brevity. 2262 On receiving a SCHC Fragment message, the receiver determines what 2263 tiles were received, based on the payload length and on the W and FCN 2264 fields of the SCHC Fragment. 2266 o if the FCN is All-1, if a Payload is present, the full SCHC 2267 Fragment Payload MUST be assembled including the padding bits. 2268 This is because the size of the last tile is not known by the 2269 receiver, therefore padding bits are indistinguishable from the 2270 tile data bits, at this stage. They will be removed by the SCHC 2271 C/D sublayer. If the size of the SCHC Fragment Payload exceeds or 2272 equals the size of one regular tile plus the size of an L2 Word, 2273 this SHOULD raise an error flag. 2275 o otherwise, tiles MUST be assembled based on the a priori known 2276 tile size. 2278 * If allowed by the Profile, the end of the payload MAY contain 2279 the last tile, which may be shorter. Padding bits are 2280 indistinguishable from the tile data bits, at this stage. 2282 * the payload may contain the penultimate tile that, if allowed 2283 by the Profile, MAY be exactly one L2 Word shorter than the 2284 regular tile size. 2286 * Otherwise, padding bits MUST be discarded. The latter is 2287 possible because 2289 + the size of the tiles is known a priori, 2291 + tiles are larger than an L2 Word 2293 + padding bits are always strictly less than an L2 Word 2295 On receiving a SCHC ACK REQ or an All-1 SCHC Fragment, 2297 o if the receiver knows of any windows with missing tiles for the 2298 packet being reassembled, it MUST return a SCHC ACK for the 2299 lowest-numbered such window, 2301 o otherwise, 2303 * if it has received at least one tile, it MUST return a SCHC ACK 2304 for the highest-numbered window it currently has tiles for 2306 * otherwise it MUST return a SCHC ACK for window numbered 0 2308 A Profile MAY specify other times and circumstances at which a 2309 receiver sends a SCHC ACK, and which window the SCHC ACK reports 2310 about in these circumstances. 2312 Upon sending a SCHC ACK, the receiver MUST increase the Attempts 2313 counter. 2315 After receiving an All-1 SCHC Fragment, a receiver MUST check the 2316 integrity of the reassembled SCHC Packet at least every time it 2317 prepares for sending a SCHC ACK for the last window. 2319 Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an 2320 error condition. 2322 Upon expiration of the Inactivity Timer, the receiver MUST send a 2323 SCHC Receiver-Abort and it MAY exit with an error condition. 2325 On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST 2326 send a SCHC Receiver-Abort and it MAY exit with an error condition. 2328 Reassembly of the SCHC Packet concludes when 2330 o a Sender-Abort has been received 2332 o or the Inactivity Timer has expired 2334 o or the Attempts counter has exceeded MAX_ACK_REQUESTS 2336 o or when at least an All-1 SCHC Fragment has been received and 2337 integrity checking of the reassembled SCHC Packet is successful. 2339 See Figure 42 for one among several possible examples of a Finite 2340 State Machine implementing a receiver behavior obeying this 2341 specification, and that is meant to match the sender Finite State 2342 Machine of Figure 41. 2344 9. Padding management 2346 SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does 2347 not have any alignment prerequisite. The size of SCHC Packets can be 2348 any number of bits. 2350 If the layer below SCHC constrains the payload to align to some 2351 boundary, called L2 Words (for example, bytes), the SCHC messages 2352 MUST be padded. When padding occurs, the number of appended bits 2353 MUST be strictly less than the L2 Word size. 2355 If a SCHC Packet is sent unfragmented (see Figure 24), it is padded 2356 as needed for transmission. 2358 If a SCHC Packet needs to be fragmented for transmission, it is not 2359 padded in itself. Only the SCHC F/R messages are padded as needed 2360 for transmission. Some SCHC F/R messages are intrinsically aligned 2361 to L2 Words. 2363 A packet (e.g., an IPv6 packet) 2364 | ^ (padding bits 2365 v | dropped) 2366 +------------------+ +--------------------+ 2367 | SCHC Compression | | SCHC Decompression | 2368 +------------------+ +--------------------+ 2369 | ^ 2370 | If no fragmentation | 2371 +---- SCHC Packet + padding as needed ----->| 2372 | | (integrity 2373 v | checked) 2374 +--------------------+ +-----------------+ 2375 | SCHC Fragmentation | | SCHC Reassembly | 2376 +--------------------+ +-----------------+ 2377 | ^ | ^ 2378 | | | | 2379 | +--- SCHC ACK + padding as needed --+ | 2380 | | 2381 +------- SCHC Fragments + padding as needed---------+ 2383 Sender Receiver 2385 Figure 24: SCHC operations, including padding as needed 2387 Each Profile MUST specify the size of the L2 Word. The L2 Word might 2388 actually be a single bit, in which case no padding will take place at 2389 all. 2391 A Profile MAY define the value of the padding bits. The RECOMMENDED 2392 value is 0. 2394 10. SCHC Compression for IPv6 and UDP headers 2396 This section lists the IPv6 and UDP header fields and describes how 2397 they can be compressed. An example of a set of Rules for UDP/IPv6 2398 header compression is provided in Appendix A. 2400 10.1. IPv6 version field 2402 The IPv6 version field is labeled by the protocol parser as being the 2403 "version" field of the IPv6 protocol. Therefore, it only exists for 2404 IPv6 packets. In the Rule, TV is set to 6, MO to "ignore" and CDA to 2405 "not-sent". 2407 10.2. IPv6 Traffic class field 2409 If the DiffServ field does not vary and is known by both sides, the 2410 Field Descriptor in the Rule SHOULD contain a TV with this well-known 2411 value, an "equal" MO and a "not-sent" CDA. 2413 Otherwise (e.g., ECN bits are to be transmitted), two possibilities 2414 can be considered depending on the variability of the value: 2416 o One possibility is to not compress the field and send the original 2417 value. In the Rule, TV is not set to any particular value, MO is 2418 set to "ignore" and CDA is set to "value-sent". 2420 o If some upper bits in the field are constant and known, a better 2421 option is to only send the LSBs. In the Rule, TV is set to a 2422 value with the stable known upper part, MO is set to MSB(x) and 2423 CDA to LSB. 2425 ECN functionality depends on both bits of the ECN field, which are 2426 the 2 LSBs of this field, hence sending only a single LSB of this 2427 field is NOT RECOMMENDED. 2429 10.3. Flow label field 2431 If the flow label is not set, i.e. its value is zero, the Field 2432 Descriptor in the Rule SHOULD contain a TV set to zero, an "equal" MO 2433 and a "not-sent" CDA. 2435 If the flow label is set to a pseudo-random value according to 2436 [RFC6437], in the Rule, TV is not set to any particular value, MO is 2437 set to "ignore" and CDA is set to "value-sent". 2439 If the flow label is set according to some prior agreement, i.e. by a 2440 flow state establishment method as allowed by [RFC6437], the Field 2441 Descriptor in the Rule SHOULD contain a TV with this agreed-upon 2442 value, an "equal" MO and a "not-sent" CDA. 2444 10.4. Payload Length field 2446 This field can be elided for the transmission on the LPWAN network. 2447 The SCHC C/D recomputes the original payload length value. In the 2448 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 2449 "compute-*". 2451 10.5. Next Header field 2453 If the Next Header field does not vary and is known by both sides, 2454 the Field Descriptor in the Rule SHOULD contain a TV with this Next 2455 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 2456 sent". 2458 Otherwise, TV is not set in the Field Descriptor, MO is set to 2459 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 2460 list MAY also be used. 2462 10.6. Hop Limit field 2464 The field behavior for this field is different for uplink (Up) and 2465 downlink (Dw). In Up, since there is no IP forwarding between the 2466 Dev and the SCHC C/D, the value is relatively constant. On the other 2467 hand, the Dw value depends on Internet routing and can change more 2468 frequently. The Direction Indicator (DI) can be used to distinguish 2469 both directions: 2471 o in the Up, elide the field: the TV in the Field Descriptor is set 2472 to the known constant value, the MO is set to "equal" and the CDA 2473 is set to "not-sent". 2475 o in the Dw, the Hop Limit is elided for transmission and forced to 2476 1 at the receiver, by setting TV to 1, MO to "ignore" and CDA to 2477 "not-sent". This prevents any further forwarding. 2479 10.7. IPv6 addresses fields 2481 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 2482 long fields; one for the prefix and one for the Interface Identifier 2483 (IID). These fields SHOULD be compressed. To allow for a single 2484 Rule being used for both directions, these values are identified by 2485 their role (Dev or App) and not by their position in the header 2486 (source or destination). 2488 10.7.1. IPv6 source and destination prefixes 2490 Both ends MUST be configured with the appropriate prefixes. For a 2491 specific flow, the source and destination prefixes can be unique and 2492 stored in the Context. In that case, the TV for the source and 2493 destination prefixes contain the values, the MO is set to "equal" and 2494 the CDA is set to "not-sent". 2496 If the Rule is intended to compress packets with different prefix 2497 values, match-mapping SHOULD be used. The different prefixes are 2498 listed in the TV, the MO is set to "match-mapping" and the CDA is set 2499 to "mapping-sent". See Figure 26. 2501 Otherwise, the TV is not set, the MO is set to "ignore" and the CDA 2502 is set to "value-sent". 2504 10.7.2. IPv6 source and destination IID 2506 If the Dev or App IID are based on an LPWAN address, then the IID can 2507 be reconstructed with information coming from the LPWAN header. In 2508 that case, the TV is not set, the MO is set to "ignore" and the CDA 2509 is set to "DevIID" or "AppIID". On LPWAN technologies where the 2510 frames carry a single identifier (corresponding to the Dev.), AppIID 2511 cannot be used. 2513 As described in [RFC8065], it may be undesirable to build the Dev 2514 IPv6 IID out of the Dev address. Another static value is used 2515 instead. In that case, the TV contains the static value, the MO 2516 operator is set to "equal" and the CDA is set to "not-sent". 2518 If several IIDs are possible, then the TV contains the list of 2519 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 2520 "mapping-sent". 2522 It may also happen that the IID variability only expresses itself on 2523 a few bytes. In that case, the TV is set to the stable part of the 2524 IID, the MO is set to "MSB" and the CDA is set to "LSB". 2526 Finally, the IID can be sent in its entirety on the LPWAN. In that 2527 case, the TV is not set, the MO is set to "ignore" and the CDA is set 2528 to "value-sent". 2530 10.8. IPv6 extension headers 2532 This document does not provide recommendations on how to compress 2533 IPv6 extension headers. 2535 10.9. UDP source and destination ports 2537 To allow for a single Rule being used for both directions, the UDP 2538 port values are identified by their role (Dev or App) and not by 2539 their position in the header (source or destination). The SCHC C/D 2540 MUST be aware of the traffic direction (Uplink, Downlink) to select 2541 the appropriate field. The following Rules apply for Dev and App 2542 port numbers. 2544 If both ends know the port number, it can be elided. The TV contains 2545 the port number, the MO is set to "equal" and the CDA is set to "not- 2546 sent". 2548 If the port variation is on few bits, the TV contains the stable part 2549 of the port number, the MO is set to "MSB" and the CDA is set to 2550 "LSB". 2552 If some well-known values are used, the TV can contain the list of 2553 these values, the MO is set to "match-mapping" and the CDA is set to 2554 "mapping-sent". 2556 Otherwise the port numbers are sent over the LPWAN. The TV is not 2557 set, the MO is set to "ignore" and the CDA is set to "value-sent". 2559 10.10. UDP length field 2561 The UDP length can be computed from the received data. The TV is not 2562 set, the MO is set to "ignore" and the CDA is set to "compute-*". 2564 10.11. UDP Checksum field 2566 The UDP checksum operation is mandatory with IPv6 for most packets 2567 but there are exceptions [RFC8200]. 2569 For instance, protocols that use UDP as a tunnel encapsulation may 2570 enable zero-checksum mode for a specific port (or set of ports) for 2571 sending and/or receiving. [RFC8200] requires any node implementing 2572 zero-checksum mode to follow the requirements specified in 2573 "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero 2574 Checksums" [RFC6936]. 2576 6LoWPAN Header Compression [RFC6282] also specifies that a UDP 2577 checksum can be elided by the compressor and re-computed by the 2578 decompressor when an upper layer guarantees the integrity of the UDP 2579 payload and pseudo-header. A specific example of this is when a 2580 message integrity check protects the compressed message between the 2581 compressor that elides the UDP checksum and the decompressor that 2582 computes it, with a strength that is identical or better to the UDP 2583 checksum. 2585 Similarly, a SCHC compressor MAY elide the UDP checksum when another 2586 layer guarantees at least equal integrity protection for the UDP 2587 payload and the pseudo-header. In this case, the TV is not set, the 2588 MO is set to "ignore" and the CDA is set to "compute-*". 2590 In particular, when SCHC fragmentation is used, a fragmentation RCS 2591 of 2 bytes or more provides equal or better protection than the UDP 2592 checksum; in that case, if the compressor is collocated with the 2593 fragmentation point and the decompressor is collocated with the 2594 packet reassembly point, and if the SCHC Packet is fragmented even 2595 when it would fit unfragmented in the L2 MTU, then the compressor MAY 2596 verify and then elide the UDP checksum. Whether and when the UDP 2597 Checksum is elided is to be specified in the Profile. 2599 Since the compression happens before the fragmentation, implementers 2600 should understand the risks when dealing with unprotected data below 2601 the transport layer and take special care when manipulating that 2602 data. 2604 In other cases, the checksum SHOULD be explicitly sent. The TV is 2605 not set, the MO is set to "ignore" and the CDA is set to "value- 2606 sent". 2608 11. IANA Considerations 2610 This document has no request to IANA. 2612 12. Security considerations 2614 As explained in Section 5, SCHC is expected to be implemented on top 2615 of LPWAN technologies, which are expected to implement security 2616 measures. 2618 In this section, we analyze the potential security threats that could 2619 be introduced into an LPWAN by adding the SCHC functionalities. 2621 12.1. Security considerations for SCHC Compression/Decompression 2623 12.1.1. Forged SCHC Packet 2625 Let's assume that an attacker is able to send a forged SCHC Packet to 2626 a SCHC Decompressor. 2628 Let's first consider the case where the Rule ID contained in that 2629 forged SCHC Packet does not correspond to a Rule allocated in the 2630 Rule table. An implementation should detect that the Rule ID is 2631 invalid and should silently drop the offending SCHC Packet. 2633 Let's now consider that the Rule ID corresponds to a Rule in the 2634 table. With the CDAs defined in this document, the reconstructed 2635 packet is at most a constant number of bits bigger than the SCHC 2636 Packet that was received. This assumes that the compute-* 2637 decompression actions produce a bounded number of bits, irrespective 2638 of the incoming SCHC Packet. This property is true for IPv6 Length, 2639 UDP Length and UDP Checksum, for which the compute-* CDA is 2640 recommended by this document. 2642 As a consequence, SCHC Decompression does not amplify attacks, beyond 2643 adding a bounded number of bits to the SCHC Packet received. This 2644 bound is determined by the Rule stored in the receiving device. 2646 As a general safety measure, a SCHC Decompressor should never re- 2647 construct a packet larger than MAX_PACKET_SIZE (defined in a Profile, 2648 with 1500 bytes as generic default). 2650 12.1.2. Compressed packet size as a side channel to guess a secret 2651 token 2653 Some packet compression methods are known to be susceptible to 2654 attacks, such as BREACH and CRIME. The attack involves injecting 2655 arbitrary data into the packet and observing the resulting compressed 2656 packet size. The observed size potentially reflects correlation 2657 between the arbitrary data and some content that was meant to remain 2658 secret, such as a security token, thereby allowing the attacker to 2659 get at the secret. 2661 By contrast, SCHC Compression takes place header field by header 2662 field, with the SCHC Packet being a mere concatenation of the 2663 compression residues of each of the individual field. Any 2664 correlation between header fields does not result in a change in the 2665 SCHC Packet size compressed under the same Rule. 2667 If SCHC C/D is used to compress packets that include a secret 2668 information field, such as a token, the Rule set should be designed 2669 so that the size of the compression residue for the field to remain 2670 secret is the same irrespective of the value of the secret 2671 information. This is achieved by e.g., sending this field in extenso 2672 with the "ignore" MO and the "value-sent" CDA. This recommendation 2673 is disputable if it is ascertained that the Rule set itself will 2674 remain secret. 2676 12.1.3. Decompressed packet different from the original packet 2678 As explained in Section 7.3, using FPs with value 0 in Field 2679 Descriptors in a Rule may result in header fields appearing in the 2680 decompressed packet in an order different from that in the original 2681 packet. Likewise, as stated in Section 7.5.3, using an "ignore" MO 2682 together with a "not-sent" CDA will result in the header field taking 2683 the TV value, which is likely to be different from the original 2684 value. 2686 Depending on the protocol, the order of header fields in the packet 2687 may be functionally significant or not. 2689 Furthermore, if the packet is protected by a checksum or a similar 2690 integrity protection mechanism, and if the checksum is transmitted 2691 instead of being recomputed as part of the decompression, these 2692 situations may result in the packet being considered corrupt and 2693 dropped. 2695 12.2. Security considerations for SCHC Fragmentation/Reassembly 2697 12.2.1. Buffer reservation attack 2699 Let's assume that an attacker is able to send a forged SCHC Fragment 2700 to a SCHC Reassembler. 2702 A node can perform a buffer reservation attack: the receiver will 2703 reserve buffer space for the SCHC Packet. If the implementation has 2704 only one buffer, other incoming fragmented SCHC Packets will be 2705 dropped while the reassembly buffer is occupied during the reassembly 2706 timeout. Once that timeout expires, the attacker can repeat the same 2707 procedure, and iterate, thus creating a denial of service attack. An 2708 implementation may have multiple reassembly buffers. The cost to 2709 mount this attack is linear with the number of buffers at the target 2710 node. Better, the cost for an attacker can be increased if 2711 individual fragments of multiple SCHC Packets can be stored in the 2712 reassembly buffer. The finer grained the reassembly buffer (downto 2713 the smallest tile size), the higher the cost of the attack. If 2714 buffer overload does occur, a smart receiver could selectively 2715 discard SCHC Packets being reassembled based on the sender behavior, 2716 which may help identify which SCHC Fragments have been sent by the 2717 attacker. Another mild counter-measure is for the target to abort 2718 the fragmentation/reassembly session as early as it detects a non- 2719 identical SCHC Fragment duplicate, anticipating for an eventual 2720 corrupt SCHC Packet, so as to save the sender the hassle of sending 2721 the rest of the fragments for this SCHC Packet. 2723 12.2.2. Corrupt Fragment attack 2725 Let's assume that an attacker is able to send a forged SCHC Fragment 2726 to a SCHC Reassembler. The malicious node is additionally assumed to 2727 be able to hear an incoming communication destined to the target 2728 node. 2730 It can then send a forged SCHC Fragment that looks like it belongs to 2731 a SCHC Packet already being reassembled at the target node. This can 2732 cause the SCHC Packet to be considered corrupt and be dropped by the 2733 receiver. The amplification happens here by a single spoofed SCHC 2734 Fragment rendering a full sequence of legit SCHC Fragments useless. 2735 If the target uses ACK-Always or ACK-on-Error mode, such a malicious 2736 node can also interfere with the acknowledgement and repetition 2737 algorithm of SCHC F/R. A single spoofed ACK, with all bitmap bits 2738 set to 0, will trigger the repetition of WINDOW_SIZE tiles. This 2739 protocol loop amplification depletes the energy source of the target 2740 node and consumes the channel bandwidth. Similarly, a spoofed ACK 2741 REQ will trigger the sending of a SCHC ACK, which may be much larger 2742 than the ACK REQ if WINDOW_SIZE is large. These consequences should 2743 be borne in mind when defining profiles for SCHC over specific LPWAN 2744 technologies. 2746 12.2.3. Fragmentation as a way to bypass Network Inspection 2748 Fragmentation is known for potentially allowing to force through a 2749 Network Inspection device (e.g., firewall) packets that would be 2750 rejected if unfragmented. This involves sending overlapping 2751 fragments to rewrite fields whose initial value led the Network 2752 Inspection device to allow the flow go through. 2754 SCHC F/R is expected to be used over one LPWAN link, where no Network 2755 Inspection device is expected to sit. As described in Section 5.2, 2756 even if the SCHC F/R on the Network infrastructure side is located in 2757 the Internet, a tunnel is to be established between it and the NGW. 2759 12.2.4. Privacy issues associated with SCHC header fields 2761 SCHC F/R allocates a DTag value to fragments belonging to the same 2762 SCHC Packet. Concerns were raised that, if DTag is a wide counter 2763 that is incremented in a predictable fashion for each new fragmented 2764 SCHC Packet, it might lead to a privacy issue, such as enabling 2765 tracking of a device across LPWANs. 2767 However, SCHC F/R is expected to be used over exactly one LPWAN link. 2768 As described in Section 5.2, even if the SCHC F/R on the Network 2769 infrastructure side is located in the Internet, a tunnel is to be 2770 established between it and the NGW. Therefore, assuming the tunnel 2771 provides confidentiality, neither the DTag field nor any other SCHC- 2772 introduced field is visible over the Internet. 2774 13. Acknowledgements 2776 Thanks to (in alphabetical order) Sergio Aguilar Romero, David Black, 2777 Carsten Bormann, Deborah Brungard, Brian Carpenter, Philippe Clavier, 2778 Alissa Cooper, Roman Danyliw, Daniel Ducuara Beltran, Diego Dujovne, 2779 Eduardo Ingles Sanchez, Rahul Jadhav, Benjamin Kaduk, 2780 Arunprabhu Kandasamy, Suresh Krishnan, Mirja Kuehlewind, Barry Leiba, 2781 Sergio Lopez Bernal, Antoni Markovski, Alexey Melnikov, 2782 Georgios Papadopoulos, Alexander Pelov, Charles Perkins, Edgar Ramos, 2783 Alvaro Retana, Adam Roach, Shoichi Sakane, Joseph Salowey, 2784 Pascal Thubert, and Eric Vyncke for useful design considerations, 2785 reviews and comments. 2787 Carles Gomez has been funded in part by the Spanish Government 2788 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2789 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2790 Government through project TEC2016-79988-P. Part of his contribution 2791 to this work has been carried out during his stay as a visiting 2792 scholar at the Computer Laboratory of the University of Cambridge. 2794 14. References 2796 14.1. Normative References 2798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2799 Requirement Levels", BCP 14, RFC 2119, 2800 DOI 10.17487/RFC2119, March 1997, 2801 . 2803 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2804 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2805 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2806 . 2808 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2809 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2810 May 2017, . 2812 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2813 (IPv6) Specification", STD 86, RFC 8200, 2814 DOI 10.17487/RFC8200, July 2017, 2815 . 2817 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2818 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2819 . 2821 14.2. Informative References 2823 [ETHERNET] 2824 "IEEE Standard for Ethernet", IEEE standard, 2825 DOI 10.1109/ieeestd.2018.8457469, n.d.. 2827 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2828 "Transmission of IPv6 Packets over IEEE 802.15.4 2829 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2830 . 2832 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2833 Header Compression (ROHC) Framework", RFC 5795, 2834 DOI 10.17487/RFC5795, March 2010, 2835 . 2837 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2838 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2839 DOI 10.17487/RFC6282, September 2011, 2840 . 2842 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2843 "IPv6 Flow Label Specification", RFC 6437, 2844 DOI 10.17487/RFC6437, November 2011, 2845 . 2847 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2848 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2849 February 2014, . 2851 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 2852 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 2853 February 2017, . 2855 Appendix A. Compression Examples 2857 This section gives some scenarios of the compression mechanism for 2858 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2860 The mechanisms defined in this document can be applied to a Dev that 2861 embeds some applications running over CoAP. In this example, three 2862 flows are considered. The first flow is for the device management 2863 based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 2864 124 for Dev and App, respectively. The second flow will be a CoAP 2865 server for measurements done by the Dev (using ports 5683) and Global 2866 IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is 2867 for legacy applications using different ports numbers, the 2868 destination IPv6 address prefix is gamma::1/64. 2870 Figure 25 presents the protocol stack. IPv6 and UDP are represented 2871 with dotted lines since these protocols are compressed on the radio 2872 link. 2874 Management Data 2875 +----------+---------+---------+ 2876 | CoAP | CoAP | legacy | 2877 +----||----+---||----+---||----+ 2878 . UDP . UDP | UDP | 2879 ................................ 2880 . IPv6 . IPv6 . IPv6 . 2881 +------------------------------+ 2882 | SCHC Header compression | 2883 | and fragmentation | 2884 +------------------------------+ 2885 | LPWAN L2 technologies | 2886 +------------------------------+ 2887 Dev or NGW 2889 Figure 25: Simplified Protocol Stack for LP-WAN 2891 In some LPWAN technologies, only the Devs have a device ID. When 2892 such technologies are used, it is necessary to statically define an 2893 IID for the Link Local address for the SCHC C/D. 2895 Rule 0 2896 Special Rule ID used to tag an uncompressed UDP/IPV6 packet. 2898 Rule 1 2899 +----------------+--+--+--+---------+--------+------------++------+ 2900 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 2901 | | | | | | Opera. | Action ||[bits]| 2902 +----------------+--+--+--+---------+---------------------++------+ 2903 |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | 2904 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2905 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2906 |IPv6 Length |16|1 |Bi| | ignore | compute-* || | 2907 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2908 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2909 |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2910 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2911 |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2912 |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | 2913 +================+==+==+==+=========+========+============++======+ 2914 |UDP DevPort |16|1 |Bi|123 | equal | not-sent || | 2915 |UDP AppPort |16|1 |Bi|124 | equal | not-sent || | 2916 |UDP Length |16|1 |Bi| | ignore | compute-* || | 2917 |UDP checksum |16|1 |Bi| | ignore | compute-* || | 2918 +================+==+==+==+=========+========+============++======+ 2920 Rule 2 2921 +----------------+--+--+--+---------+--------+------------++------+ 2922 | Field |FL|FP|DI| Value | Match | Action || Sent | 2923 | | | | | | Opera. | Action ||[bits]| 2924 +----------------+--+--+--+---------+--------+------------++------+ 2925 |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | 2926 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2927 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2928 |IPv6 Length |16|1 |Bi| | ignore | compute-* || | 2929 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2930 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2931 |IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 | 2932 | | | | |fe80::/64] mapping| || | 2933 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2934 |IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 | 2935 | | | | |alpha/64,| mapping| || | 2936 | | | | |fe80::64]| | || | 2937 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2938 +================+==+==+==+=========+========+============++======+ 2939 |UDP DevPort |16|1 |Bi|5683 | equal | not-sent || | 2940 |UDP AppPort |16|1 |Bi|5683 | equal | not-sent || | 2941 |UDP Length |16|1 |Bi| | ignore | compute-* || | 2942 |UDP checksum |16|1 |Bi| | ignore | compute-* || | 2943 +================+==+==+==+=========+========+============++======+ 2945 Rule 3 2946 +----------------+--+--+--+---------+--------+------------++------+ 2947 | Field |FL|FP|DI| Value | Match | Action || Sent | 2948 | | | | | | Opera. | Action ||[bits]| 2949 +----------------+--+--+--+---------+--------+------------++------+ 2950 |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | 2951 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2952 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2953 |IPv6 Length |16|1 |Bi| | ignore | compute-* || | 2954 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2955 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2956 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 | 2957 |IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2958 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2959 |IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2960 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2961 +================+==+==+==+=========+========+============++======+ 2962 |UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2963 |UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | 2964 |UDP Length |16|1 |Bi| | ignore | compute-* || | 2965 |UDP checksum |16|1 |Bi| | ignore | compute-* || | 2966 +================+==+==+==+=========+========+============++======+ 2968 Figure 26: Context Rules 2970 Figure 26 describes a example of a Rule set. 2972 In this example, 0 was chosen as the special Rule ID that tags 2973 packets that cannot be compressed with any compression Rule. 2975 All the fields described in Rules 1-3 are present in the IPv6 and UDP 2976 headers. The DevIID-DID value is found in the L2 header. 2978 Rules 2-3 use global addresses. The way the Dev learns the prefix is 2979 not in the scope of the document. 2981 Rule 3 compresses each port number to 4 bits. 2983 Appendix B. Fragmentation Examples 2985 This section provides examples for the various fragment reliability 2986 modes specified in this document. In the drawings, Bitmaps are shown 2987 in their uncompressed form. 2989 Figure 27 illustrates the transmission in No-ACK mode of a SCHC 2990 Packet that needs 11 SCHC Fragments. FCN is 1 bit wide. 2992 Sender Receiver 2993 |-------FCN=0-------->| 2994 |-------FCN=0-------->| 2995 |-------FCN=0-------->| 2996 |-------FCN=0-------->| 2997 |-------FCN=0-------->| 2998 |-------FCN=0-------->| 2999 |-------FCN=0-------->| 3000 |-------FCN=0-------->| 3001 |-------FCN=0-------->| 3002 |-------FCN=0-------->| 3003 |-----FCN=1 + RCS --->| Integrity check: success 3004 (End) 3006 Figure 27: No-ACK mode, 11 SCHC Fragments 3008 In the following examples, N (the size of the FCN field) is 3 bits. 3009 The All-1 FCN value is 7. 3011 Figure 28 illustrates the transmission in ACK-on-Error mode of a SCHC 3012 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 3013 WINDOW_SIZE=7 and no lost SCHC Fragment. 3015 Sender Receiver 3016 |-----W=0, FCN=6----->| 3017 |-----W=0, FCN=5----->| 3018 |-----W=0, FCN=4----->| 3019 |-----W=0, FCN=3----->| 3020 |-----W=0, FCN=2----->| 3021 |-----W=0, FCN=1----->| 3022 |-----W=0, FCN=0----->| 3023 (no ACK) 3024 |-----W=1, FCN=6----->| 3025 |-----W=1, FCN=5----->| 3026 |-----W=1, FCN=4----->| 3027 |--W=1, FCN=7 + RCS-->| Integrity check: success 3028 |<-- ACK, W=1, C=1 ---| C=1 3029 (End) 3031 Figure 28: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 3032 no lost SCHC Fragment. 3034 Figure 29 illustrates the transmission in ACK-on-Error mode of a SCHC 3035 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, 3036 WINDOW_SIZE=7 and three lost SCHC Fragments. 3038 Sender Receiver 3039 |-----W=0, FCN=6----->| 3040 |-----W=0, FCN=5----->| 3041 |-----W=0, FCN=4--X-->| 3042 |-----W=0, FCN=3----->| 3043 |-----W=0, FCN=2--X-->| 3044 |-----W=0, FCN=1----->| 3045 |-----W=0, FCN=0----->| 6543210 3046 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 3047 |-----W=0, FCN=4----->| 3048 |-----W=0, FCN=2----->| 3049 (no ACK) 3050 |-----W=1, FCN=6----->| 3051 |-----W=1, FCN=5----->| 3052 |-----W=1, FCN=4--X-->| 3053 |- W=1, FCN=7 + RCS ->| Integrity check: failure 3054 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 3055 |-----W=1, FCN=4----->| Integrity check: success 3056 |<-- ACK, W=1, C=1 ---| C=1 3057 (End) 3059 Figure 29: ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, 3060 lost SCHC Fragments. 3062 Figure 30 shows an example of a transmission in ACK-on-Error mode of 3063 a SCHC Packet fragmented in 73 tiles, with N=5, WINDOW_SIZE=28, M=2 3064 and 3 lost SCHC Fragments. 3066 Sender Receiver 3067 |-----W=0, FCN=27----->| 4 tiles sent 3068 |-----W=0, FCN=23----->| 4 tiles sent 3069 |-----W=0, FCN=19----->| 4 tiles sent 3070 |-----W=0, FCN=15--X-->| 4 tiles sent (not received) 3071 |-----W=0, FCN=11----->| 4 tiles sent 3072 |-----W=0, FCN=7 ----->| 4 tiles sent 3073 |-----W=0, FCN=3 ----->| 4 tiles sent 3074 |-----W=1, FCN=27----->| 4 tiles sent 3075 |-----W=1, FCN=23----->| 4 tiles sent 3076 |-----W=1, FCN=19----->| 4 tiles sent 3077 |-----W=1, FCN=15----->| 4 tiles sent 3078 |-----W=1, FCN=11----->| 4 tiles sent 3079 |-----W=1, FCN=7 ----->| 4 tiles sent 3080 |-----W=1, FCN=3 --X-->| 4 tiles sent (not received) 3081 |-----W=2, FCN=27----->| 4 tiles sent 3082 |-----W=2, FCN=23----->| 4 tiles sent 3083 ^ |-----W=2, FCN=19----->| 1 tile sent 3084 | |-----W=2, FCN=18----->| 1 tile sent 3085 | |-----W=2, FCN=17----->| 1 tile sent 3086 |-----W=2, FCN=16----->| 1 tile sent 3087 s |-----W=2, FCN=15----->| 1 tile sent 3088 m |-----W=2, FCN=14----->| 1 tile sent 3089 a |-----W=2, FCN=13--X-->| 1 tile sent (not received) 3090 l |-----W=2, FCN=12----->| 1 tile sent 3091 l |---W=2, FCN=31 + RCS->| Integrity check: failure 3092 e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 3093 r |-----W=0, FCN=15----->| 1 tile sent 3094 |-----W=0, FCN=14----->| 1 tile sent 3095 L |-----W=0, FCN=13----->| 1 tile sent 3096 2 |-----W=0, FCN=12----->| 1 tile sent 3097 |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 3098 M |-----W=1, FCN=3 ----->| 1 tile sent 3099 T |-----W=1, FCN=2 ----->| 1 tile sent 3100 U |-----W=1, FCN=1 ----->| 1 tile sent 3101 |-----W=1, FCN=0 ----->| 1 tile sent 3102 | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 3103 | |-----W=2, FCN=13----->| Integrity check: success 3104 V |<--- ACK, W=2, C=1 ---| C=1 3105 (End) 3107 Figure 30: ACK-on-Error mode, variable MTU. 3109 In this example, the L2 MTU becomes reduced just before sending the 3110 "W=2, FCN=19" fragment, leaving space for only 1 tile in each 3111 forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are 3112 carried by a total of 25 SCHC Fragments, the last 9 being of smaller 3113 size. 3115 Note: other sequences of events (e.g., regarding when ACKs are sent 3116 by the Receiver) are also allowed by this specification. Profiles 3117 may restrict this flexibility. 3119 Figure 31 illustrates the transmission in ACK-Always mode of a SCHC 3120 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with 3121 N=3, WINDOW_SIZE=7 and no loss. 3123 Sender Receiver 3124 |-----W=0, FCN=6----->| 3125 |-----W=0, FCN=5----->| 3126 |-----W=0, FCN=4----->| 3127 |-----W=0, FCN=3----->| 3128 |-----W=0, FCN=2----->| 3129 |-----W=0, FCN=1----->| 3130 |-----W=0, FCN=0----->| 3131 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 3132 |-----W=1, FCN=6----->| 3133 |-----W=1, FCN=5----->| 3134 |-----W=1, FCN=4----->| 3135 |--W=1, FCN=7 + RCS-->| Integrity check: success 3136 |<-- ACK, W=1, C=1 ---| C=1 3137 (End) 3139 Figure 31: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, no 3140 loss. 3142 Figure 32 illustrates the transmission in ACK-Always mode of a SCHC 3143 Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, 3144 WINDOW_SIZE=7 and three lost SCHC Fragments. 3146 Sender Receiver 3147 |-----W=0, FCN=6----->| 3148 |-----W=0, FCN=5----->| 3149 |-----W=0, FCN=4--X-->| 3150 |-----W=0, FCN=3----->| 3151 |-----W=0, FCN=2--X-->| 3152 |-----W=0, FCN=1----->| 3153 |-----W=0, FCN=0----->| 6543210 3154 |<-- ACK, W=0, C=0 ---| Bitmap:1101011 3155 |-----W=0, FCN=4----->| 3156 |-----W=0, FCN=2----->| 3157 |<-- ACK, W=0, C=0 ---| Bitmap:1111111 3158 |-----W=1, FCN=6----->| 3159 |-----W=1, FCN=5----->| 3160 |-----W=1, FCN=4--X-->| 3161 |--W=1, FCN=7 + RCS-->| Integrity check: failure 3162 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001 3163 |-----W=1, FCN=4----->| Integrity check: success 3164 |<-- ACK, W=1, C=1 ---| C=1 3165 (End) 3167 Figure 32: ACK-Always mode, 11 tiles, one tile per SCHC Fragment, 3168 three lost SCHC Fragments. 3170 Figure 33 illustrates the transmission in ACK-Always mode of a SCHC 3171 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 3172 WINDOW_SIZE=7, three lost SCHC Fragments and only one retry needed to 3173 recover each lost SCHC Fragment. 3175 Sender Receiver 3176 |-----W=0, FCN=6----->| 3177 |-----W=0, FCN=5----->| 3178 |-----W=0, FCN=4--X-->| 3179 |-----W=0, FCN=3--X-->| 3180 |-----W=0, FCN=2--X-->| 3181 |--W=0, FCN=7 + RCS-->| Integrity check: failure 3182 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 3183 |-----W=0, FCN=4----->| Integrity check: failure 3184 |-----W=0, FCN=3----->| Integrity check: failure 3185 |-----W=0, FCN=2----->| Integrity check: success 3186 |<-- ACK, W=0, C=1 ---| C=1 3187 (End) 3189 Figure 33: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, 3190 three lost SCHC Fragments. 3192 Figure 34 illustrates the transmission in ACK-Always mode of a SCHC 3193 Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, 3194 WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK 3195 lost. 3197 Sender Receiver 3198 |-----W=0, FCN=6----->| 3199 |-----W=0, FCN=5----->| 3200 |-----W=0, FCN=4--X-->| 3201 |-----W=0, FCN=3--X-->| 3202 |-----W=0, FCN=2--X-->| 3203 |--W=0, FCN=7 + RCS-->| Integrity check: failure 3204 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 3205 |-----W=0, FCN=4----->| Integrity check: failure 3206 |-----W=0, FCN=3----->| Integrity check: failure 3207 |-----W=0, FCN=2----->| Integrity check: success 3208 |<-X-ACK, W=0, C=1 ---| C=1 3209 timeout | | 3210 |--- W=0, ACK REQ --->| ACK REQ 3211 |<-- ACK, W=0, C=1 ---| C=1 3212 (End) 3214 Figure 34: ACK-Always mode, 6 tiles, one tile per SCHC Fragment, SCHC 3215 ACK loss. 3217 Figure 35 illustrates the transmission in ACK-Always mode of a SCHC 3218 Packet fragmented in 6 tiles, with N=3, WINDOW_SIZE=7, with three 3219 lost SCHC Fragments, and one retransmitted SCHC Fragment lost again. 3221 Sender Receiver 3222 |-----W=0, FCN=6----->| 3223 |-----W=0, FCN=5----->| 3224 |-----W=0, FCN=4--X-->| 3225 |-----W=0, FCN=3--X-->| 3226 |-----W=0, FCN=2--X-->| 3227 |--W=0, FCN=7 + RCS-->| Integrity check: failure 3228 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 3229 |-----W=0, FCN=4----->| Integrity check: failure 3230 |-----W=0, FCN=3----->| Integrity check: failure 3231 |-----W=0, FCN=2--X-->| 3232 timeout| | 3233 |--- W=0, ACK REQ --->| ACK REQ 3234 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 3235 |-----W=0, FCN=2----->| Integrity check: success 3236 |<-- ACK, W=0, C=1 ---| C=1 3237 (End) 3239 Figure 35: ACK-Always mode, 6 tiles, retransmitted SCHC Fragment lost 3240 again. 3242 Figure 36 illustrates the transmission in ACK-Always mode of a SCHC 3243 Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, 3244 WINDOW_SIZE=24 and two lost SCHC Fragments. 3246 Sender Receiver 3247 |-----W=0, FCN=23----->| 3248 |-----W=0, FCN=22----->| 3249 |-----W=0, FCN=21--X-->| 3250 |-----W=0, FCN=20----->| 3251 |-----W=0, FCN=19----->| 3252 |-----W=0, FCN=18----->| 3253 |-----W=0, FCN=17----->| 3254 |-----W=0, FCN=16----->| 3255 |-----W=0, FCN=15----->| 3256 |-----W=0, FCN=14----->| 3257 |-----W=0, FCN=13----->| 3258 |-----W=0, FCN=12----->| 3259 |-----W=0, FCN=11----->| 3260 |-----W=0, FCN=10--X-->| 3261 |-----W=0, FCN=9 ----->| 3262 |-----W=0, FCN=8 ----->| 3263 |-----W=0, FCN=7 ----->| 3264 |-----W=0, FCN=6 ----->| 3265 |-----W=0, FCN=5 ----->| 3266 |-----W=0, FCN=4 ----->| 3267 |-----W=0, FCN=3 ----->| 3268 |-----W=0, FCN=2 ----->| 3269 |-----W=0, FCN=1 ----->| 3270 |-----W=0, FCN=0 ----->| 3271 | | 3272 |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 3273 |-----W=0, FCN=21----->| 3274 |-----W=0, FCN=10----->| 3275 |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 3276 |-----W=1, FCN=23----->| 3277 |-----W=1, FCN=22----->| 3278 |-----W=1, FCN=21----->| 3279 |--W=1, FCN=31 + RCS-->| Integrity check: success 3280 |<--- ACK, W=1, C=1 ---| C=1 3281 (End) 3283 Figure 36: ACK-Always mode, 28 tiles, one tile per SCHC Fragment, 3284 lost SCHC Fragments. 3286 Appendix C. Fragmentation State Machines 3288 The fragmentation state machines of the sender and the receiver, one 3289 for each of the different reliability modes, are described in the 3290 following figures: 3292 +===========+ 3293 +------------+ Init | 3294 | FCN=0 +===========+ 3295 | No Window 3296 | No Bitmap 3297 | +-------+ 3298 | +========+==+ | More Fragments 3299 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 3300 +--------> | Send | send Fragment (FCN=0) 3301 +===+=======+ 3302 | last fragment 3303 | ~~~~~~~~~~~~ 3304 | FCN = 1 3305 v send fragment+RCS 3306 +============+ 3307 | END | 3308 +============+ 3310 Figure 37: Sender State Machine for the No-ACK Mode 3312 +------+ Not All-1 3313 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 3314 | + <--+ set Inactivity Timer 3315 | RCV Frag +-------+ 3316 +=+===+======+ |All-1 & 3317 All-1 & | | |RCS correct 3318 RCS wrong | |Inactivity | 3319 | |Timer Exp. | 3320 v | | 3321 +==========++ | v 3322 | Error |<-+ +========+==+ 3323 +===========+ | END | 3324 +===========+ 3326 Figure 38: Receiver State Machine for the No-ACK Mode 3327 +=======+ 3328 | INIT | FCN!=0 & more frags 3329 | | ~~~~~~~~~~~~~~~~~~~~~~ 3330 +======++ +--+ send Window + frag(FCN) 3331 W=0 | | | FCN- 3332 Clear lcl_bm | | v set lcl_bm 3333 FCN=max value | ++==+========+ 3334 +> | | 3335 +---------------------> | SEND | 3336 | +==+===+=====+ 3337 | FCN==0 & more frags | | last frag 3338 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 3339 | set lcl_bm | | set lcl_bm 3340 | send wnd + frag(all-0) | | send wnd+frag(all-1)+RCS 3341 | set Retrans_Timer | | set Retrans_Timer 3342 | | | 3343 |Recv_wnd == wnd & | | 3344 |lcl_bm==recv_bm & | | +----------------------+ 3345 |more frag | | | lcl_bm!=rcv-bm | 3346 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 3347 |Stop Retrans_Timer | | | Attempt++ v 3348 |clear lcl_bm v v | +=====+=+ 3349 |window=next_window +====+===+==+===+ |Resend | 3350 +---------------------+ | |Missing| 3351 +----+ Wait | |Frag | 3352 not expected wnd | | Bitmap | +=======+ 3353 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 3354 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 3355 | | | ^ ^ |reSend(empty)All-* | 3356 | | | | | |Set Retrans_Timer | 3357 | | | | +--+Attempt++ | 3358 C_bit==1 & | | | +-------------------------+ 3359 Recv_window==window & | | | all missing frags sent 3360 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 3361 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 3362 Stop Retrans_Timer| | | 3363 +=============+ | | | 3364 | END +<--------+ | | 3365 +=============+ | | Attempt > MAX_ACK_REQUESTS 3366 All-1 Window & | | ~~~~~~~~~~~~~~~~~~ 3367 C_bit ==0 & | v Send Abort 3368 lcl_bm==recv_bm | +=+===========+ 3369 ~~~~~~~~~~~~ +>| ERROR | 3370 Send Abort +=============+ 3372 Figure 39: Sender State Machine for the ACK-Always Mode 3374 Not All- & w=expected +---+ +---+w = Not expected 3375 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 3376 Set lcl_bm(FCN) | v v |discard 3377 ++===+===+===+=+ 3378 +---------------------+ Rcv +--->* ABORT 3379 | +------------------+ Window | 3380 | | +=====+==+=====+ 3381 | | All-0 & w=expect | ^ w =next & not-All 3382 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 3383 | | set lcl_bm(FCN) | |expected = next window 3384 | | send lcl_bm | |Clear lcl_bm 3385 | | | | 3386 | | w=expected & not-All | | 3387 | | ~~~~~~~~~~~~~~~~~~ | | 3388 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0 3389 | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~ 3390 | | send lcl_bm | | | | | | expected = nxt wnd 3391 | | v | v | | | Clear lcl_bm 3392 | |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN) 3393 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm 3394 | | discard +--| Next | 3395 | | All-0 +---------+ Window +--->* ABORT 3396 | | ~~~~~ +-------->+========+=++ 3397 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 3398 | | & RCS wrong| | & RCS right 3399 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 3400 | | set lcl_bm(FCN)| |set lcl_bm(FCN) 3401 | | send lcl_bm| |send lcl_bm 3402 | | | +----------------------+ 3403 | |All-1 & w=expected | | 3404 | |& RCS wrong v +---+ w=expected & | 3405 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | RCS wrong | 3406 | |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ | 3407 | |send lcl_bm | Wait End | set lcl_bm(FCN)| 3408 | +--------------------->+ +--->* ABORT | 3409 | +===+====+=+-+ All-1&RCS wrong| 3410 | | ^ | ~~~~~~~~~~~~~~~| 3411 | w=expected & RCS right | +---+ send lcl_bm | 3412 | ~~~~~~~~~~~~~~~~~~~~~~ | | 3413 | set lcl_bm(FCN) | +-+ Not All-1 | 3414 | send lcl_bm | | | ~~~~~~~~~ | 3415 | | | | discard | 3416 |All-1&w=expected & RCS right | | | | 3417 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 3418 |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 3419 |send lcl_bm | +<+Send lcl_bm | 3420 +-------------------------->+ END | | 3421 +==========+<---------------+ 3423 --->* ABORT 3425 In any state 3426 on receiving a SCHC ACK REQ 3427 Send a SCHC ACK for the current window 3429 Figure 40: Receiver State Machine for the ACK-Always Mode 3431 +=======+ 3432 | | 3433 | INIT | 3434 | | FCN!=0 & more frags 3435 +======++ ~~~~~~~~~~~~~~~~~~~~~~ 3436 Frag RuleID trigger | +--+ Send cur_W + frag(FCN); 3437 ~~~~~~~~~~~~~~~~~~~ | | | FCN--; 3438 cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp] 3439 clear [cur_W, Bmp_n];| | v 3440 clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND 3441 +->+ | cur_W==rcv_W & 3442 **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp 3443 +-------------------------->+ | & more frags 3444 | +----------------------->+ | ~~~~~~~~~~~~ 3445 | | ++===+=========+ cur_W++; 3446 | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] 3447 | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~ 3448 | | set cur_Bmp; | |set [cur_W, Bmp_n]; 3449 | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+RCS; 3450 | | set Retrans_Timer| |set Retrans_Timer 3451 | | | | +-----------------------------------+ 3452 | |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| 3453 | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ | 3454 | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W | 3455 | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &| 3456 | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp| 3457 | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| 3458 | +-------------------+ | | Resend | Attempts++;| 3459 +----------------------+ Wait x ACK | | Missing | W=Wn | 3460 +--------------------->+ | | Frags(W) +<-------------+ 3461 | rcv_W==Wn &+-+ | +======+====+ 3462 | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ | 3463 | ~~~~~~~~~~~~~~| ^ | | | ^ | 3464 | send (cur_W,+--+ | | | +-------------+ 3465 | ALL-0-empty) | | | all missing frag sent(W) 3466 | | | | ~~~~~~~~~~~~~~~~~ 3467 | Retrans_Timer expires &| | | set Retrans_Timer 3468 | No more Frags| | | 3469 | ~~~~~~~~~~~~~~| | | 3470 | stop Retrans_Timer;| | | 3471 |(re)send frag(All-1)+RCS | | | 3472 +-------------------------+ | | 3473 cur_W==rcv_W&| | 3474 [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS 3475 No more Frags & RCS flag==OK| | ~~~~~~~~~~ 3476 ~~~~~~~~~~~~~~~~~~| | send Abort 3477 +=========+stop Retrans_Timer| | +===========+ 3478 | END +<-----------------+ +->+ ERROR | 3479 +=========+ +===========+ 3481 Figure 41: Sender State Machine for the ACK-on-Error Mode 3483 This is an example only. It is not normative. The specification in 3484 Section 8.4.3.1 allows for sequences of operations different from the 3485 one shown here. 3487 +=======+ New frag RuleID received 3488 | | ~~~~~~~~~~~~~ 3489 | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); 3490 +=======+ |sync=0 3491 | 3492 Not All* & rcv_W==cur_W+---+ | +---+ 3493 ~~~~~~~~~~~~~~~~~~~~ | | | | (E) 3494 set[cur_W,Bmp_n(FCN)]| v v v | 3495 ++===+=+=+===+=+ 3496 +----------------------+ +--+ All-0&Full[cur_W,Bmp_n] 3497 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~ 3498 | +-------------------+ +<-+ cur_W++;set Inact_timer; 3499 | | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n] 3500 | | All-0 empty(Wn)| | | | ^ ^ 3501 | | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0; 3502 | | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n]) 3503 | | | | | |& All* || last_miss_frag 3504 | | | | | |~~~~~~~~~~~~~~~~~~~~~~ 3505 | | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); 3506 | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) 3507 | |&no_full([cur_W,Bmp_n])| |(E)| 3508 | | ~~~~~~~~~~~~~~~~ | | | | +========+ 3509 | | sendACK([cur_W,Bmp_n])| | | | | Error/ | 3510 | | | | | | +----+ | Abort | 3511 | | v v | | | | +===+====+ 3512 | | +===+=+=+=+===+=+ (D) ^ 3513 | | +--+ Wait x | | | 3514 | | All-0 empty(Wn)+->| Missing Frags |<-+ | 3515 | | ~~~~~~~~~~~~~~ +=============+=+ | 3516 | | sendACK([Wn,Bmp_n]) +--------------+ 3517 | | *ABORT 3518 v v 3519 (A)(B) 3520 (D) All* || last_miss_frag 3521 (C) All* & sync>0 & rcv_W!=cur_W & sync>0 3522 ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) 3523 Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ 3524 sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; 3525 sendACK([Wn,Bmp_n]);sync-- 3527 ABORT-->* Uplink Only & 3528 Inact_Timer expires 3529 (E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS 3530 ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ 3531 sync++; cur_W=rcv_W; send Abort 3532 set[cur_W,Bmp_n(FCN)] 3534 (A)(B) 3535 | | 3536 | | All-1 & rcv_W==cur_W & RCS!=OK All-0 empty(Wn) 3537 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~ 3538 | | sendACK([cur_W,Bmp_n],C=0) | v sendACK([Wn,Bmp_n]) 3539 | | +===========+=++ 3540 | +--------------------->+ Wait End +-+ 3541 | +=====+=+====+=+ | All-1 3542 | rcv_W==cur_W & RCS==OK | | ^ | & rcv_W==cur_W 3543 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & RCS!=OK 3544 | sendACK([cur_W,Bmp_n],C=1) | | ~~~~~~~~~~~~~~~~~~~ 3545 | | | sendACK([cur_W,Bmp_n],C=0); 3546 | | | Attempts++ 3547 |All-1 & Full([cur_W,Bmp_n]) | | 3548 |& RCS==OK & sync==0 | +-->* ABORT 3549 |~~~~~~~~~~~~~~~~~~~ v 3550 |sendACK([cur_W,Bmp_n],C=1) +=+=========+ 3551 +---------------------------->+ END | 3552 +===========+ 3554 Figure 42: Receiver State Machine for the ACK-on-Error Mode 3556 Appendix D. SCHC Parameters 3558 This section lists the information that needs to be provided in the 3559 LPWAN technology-specific documents. 3561 o Most common uses cases, deployment scenarios 3563 o Mapping of the SCHC architectural elements onto the LPWAN 3564 architecture 3566 o Assessment of LPWAN integrity checking 3568 o Various potential channel conditions for the technology and the 3569 corresponding recommended use of SCHC C/D and F/R 3571 This section lists the parameters that need to be defined in the 3572 Profile. 3574 o Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs, 3575 number of Rules, the way the Rule ID is transmitted 3577 o maximum packet size that should ever be reconstructed by SCHC 3578 Decompression (MAX_PACKET_SIZE). See Section 12. 3580 o Padding: size of the L2 Word (for most LPWAN technologies, this 3581 would be a byte; for some technologies, a bit) 3583 o Decision to use SCHC fragmentation mechanism or not. If yes, the 3584 document must describe: 3586 * reliability mode(s) used, in which cases (e.g., based on link 3587 channel condition) 3589 * Rule ID values assigned to each mode in use 3591 * presence and number of bits for DTag (T) for each Rule ID 3592 value, lifetime of DTag at the receiver 3594 * support for interleaved packet transmission, to what extent 3596 * WINDOW_SIZE, for modes that use windows 3598 * number of bits for W (M) for each Rule ID value, for modes that 3599 use windows 3601 * number of bits for FCN (N) for each Rule ID value 3603 * what makes an All-0 SCHC Fragment and a SCHC ACK REQ 3604 distinguishable (see Section 8.3.1.1). 3606 * what makes an All-1 SCHC Fragment and a SCHC Sender-Abort 3607 distinguishable (see Section 8.3.1.2). 3609 * size of RCS and algorithm for its computation, for each Rule 3610 ID, if different from the default CRC32. Byte fill-up with 3611 zeroes or other mechanism, to be specified. 3613 * Retransmission Timer duration for each Rule ID value, if 3614 applicable to the SCHC F/R mode 3616 * Inactivity Timer duration for each Rule ID value, if applicable 3617 to the SCHC F/R mode 3619 * MAX_ACK_REQUESTS value for each Rule ID value, if applicable to 3620 the SCHC F/R mode 3622 o if L2 Word is wider than a bit and SCHC fragmentation is used, 3623 value of the padding bits (0 or 1). This is needed because the 3624 padding bits of the last fragment are included in the RCS 3625 computation. 3627 A Profile may define a delay to be added after each SCHC message 3628 transmission for compliance with local regulations or other 3629 constraints imposed by the applications. 3631 o In some LPWAN technologies, as part of energy-saving techniques, 3632 downlink transmission is only possible immediately after an uplink 3633 transmission. In order to avoid potentially high delay in the 3634 downlink transmission of a fragmented SCHC Packet, the SCHC 3635 Fragment receiver may perform an uplink transmission as soon as 3636 possible after reception of a SCHC Fragment that is not the last 3637 one. Such uplink transmission may be triggered by the L2 (e.g., 3638 an L2 ACK sent in response to a SCHC Fragment encapsulated in a L2 3639 PDU that requires an L2 ACK) or it may be triggered from an upper 3640 layer. See Appendix F. 3642 o the following parameters need to be addressed in documents other 3643 than this one but not necessarily in the LPWAN technology-specific 3644 documents: 3646 * The way the Contexts are provisioned 3648 * The way the Rules are generated 3650 Appendix E. Supporting multiple window sizes for fragmentation 3652 For ACK-Always or ACK-on-Error, implementers may opt to support a 3653 single window size or multiple window sizes. The latter, when 3654 feasible, may provide performance optimizations. For example, a 3655 large window size should be used for packets that need to be split 3656 into a large number of tiles. However, when the number of tiles 3657 required to carry a packet is low, a smaller window size, and thus a 3658 shorter Bitmap, may be sufficient to provide reception status on all 3659 tiles. If multiple window sizes are supported, the Rule ID signals 3660 the window size in use for a specific packet transmission. 3662 Appendix F. ACK-Always and ACK-on-Error on quasi-bidirectional links 3664 The ACK-Always and ACK-on-Error modes of SCHC F/R are bidirectional 3665 protocols: they require a feedback path from the reassembler to the 3666 fragmenter. 3668 Some LPWAN technologies provide quasi-bidirectional connectivity, 3669 whereby a downlink transmission from the Network Infrastructure can 3670 only take place right after an uplink transmission by the Dev. 3672 When using SCHC F/R to send fragmented SCHC Packets downlink over 3673 these quasi-bidirectional links, the following situation may arise: 3674 if an uplink SCHC ACK is lost, the SCHC ACK REQ message by the sender 3675 could be stuck indefinitely in the downlink queue at the Network 3676 Infrastructure, waiting for a transmission opportunity. 3678 There are many ways by which this deadlock can be avoided. The Dev 3679 application might be sending recurring uplink messages such as keep- 3680 alive, or the Dev application stack might be sending other recurring 3681 uplink messages as part of its operation. However, these are out of 3682 the control of this generic SCHC specification. 3684 In order to cope with quasi-bidirectional links, a SCHC-over-foo 3685 specification may want to amend the SCHC F/R specification to add a 3686 timer-based retransmission of the SCHC ACK. Below is an example of 3687 the suggested behavior for ACK-Always mode. Because it is an 3688 example, [RFC2119] language is deliberately not used here. 3690 For downlink transmission of a fragmented SCHC Packet in ACK-Always 3691 mode, the SCHC Fragment receiver may support timer-based SCHC ACK 3692 retransmission. In this mechanism, the SCHC Fragment receiver 3693 initializes and starts a timer (the UplinkACK Timer) after the 3694 transmission of a SCHC ACK, except when the SCHC ACK is sent in 3695 response to the last SCHC Fragment of a packet (All-1 fragment). In 3696 the latter case, the SCHC Fragment receiver does not start a timer 3697 after transmission of the SCHC ACK. 3699 If, after transmission of a SCHC ACK that is not an All-1 fragment, 3700 and before expiration of the corresponding UplinkACK timer, the SCHC 3701 Fragment receiver receives a SCHC Fragment that belongs to the 3702 current window (e.g., a missing SCHC Fragment from the current 3703 window) or to the next window, the UplinkACK timer for the SCHC ACK 3704 is stopped. However, if the UplinkACK timer expires, the SCHC ACK is 3705 resent and the UplinkACK timer is reinitialized and restarted. 3707 The default initial value for the UplinkACK Timer, as well as the 3708 maximum number of retries for a specific SCHC ACK, denoted 3709 MAX_ACK_REQUESTS, is to be defined in a Profile. The initial value 3710 of the UplinkACK timer is expected to be greater than that of the 3711 Retransmission timer, in order to make sure that a (buffered) SCHC 3712 Fragment to be retransmitted finds an opportunity for that 3713 transmission. One exception to this recommendation is the special 3714 case of the All-1 SCHC Fragment transmission. 3716 When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it 3717 starts its Retransmission Timer with a large timeout value (e.g., 3718 several times that of the initial UplinkACK Timer). If a SCHC ACK is 3719 received before expiration of this timer, the SCHC Fragment sender 3720 retransmits any lost SCHC Fragments as reported by the SCHC ACK, or 3721 if the SCHC ACK confirms successful reception of all SCHC Fragments 3722 of the last window, the transmission of the fragmented SCHC Packet is 3723 considered complete. If the timer expires, and no SCHC ACK has been 3724 received since the start of the timer, the SCHC Fragment sender 3725 assumes that the All-1 SCHC Fragment has been successfully received 3726 (and possibly, the last SCHC ACK has been lost: this mechanism 3727 assumes that the Retransmission Timer for the All-1 SCHC Fragment is 3728 long enough to allow several SCHC ACK retries if the All-1 SCHC 3729 Fragment has not been received by the SCHC Fragment receiver, and it 3730 also assumes that it is unlikely that several ACKs become all lost). 3732 Authors' Addresses 3734 Ana Minaburo 3735 Acklio 3736 1137A avenue des Champs Blancs 3737 35510 Cesson-Sevigne Cedex 3738 France 3740 Email: ana@ackl.io 3742 Laurent Toutain 3743 IMT-Atlantique 3744 2 rue de la Chataigneraie 3745 CS 17607 3746 35576 Cesson-Sevigne Cedex 3747 France 3749 Email: Laurent.Toutain@imt-atlantique.fr 3751 Carles Gomez 3752 Universitat Politecnica de Catalunya 3753 C/Esteve Terradas, 7 3754 08860 Castelldefels 3755 Spain 3757 Email: carlesgo@entel.upc.edu 3759 Dominique Barthel 3760 Orange Labs 3761 28 chemin du Vieux Chene 3762 38243 Meylan 3763 France 3765 Email: dominique.barthel@orange.com 3766 Juan Carlos Zuniga 3767 SIGFOX 3768 425 rue Jean Rostand 3769 Labege 31670 3770 France 3772 Email: JuanCarlos.Zuniga@sigfox.com