idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-15.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A Receiver-Abort is aligned to L2 Words, by design. Therefore, padding MUST not be appended. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When an All-0 fragment is received, it indicates that all the SCHC Fragments have been sent in the current window. Since the sender is not obliged to always send a full window, some SCHC Fragment number not set in the receiver memory SHOULD not correspond to losses. The receiver sends the corresponding SCHC ACK, the Inactivity Timer is set and the transmission of the next window by the sender can start. -- The document date (June 29, 2018) is 2121 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) -- Looks like a reference, but probably isn't: '1' on line 2371 -- Looks like a reference, but probably isn't: '2' on line 2374 -- Looks like a reference, but probably isn't: '8' on line 2396 -- Looks like a reference, but probably isn't: '4' on line 2403 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). 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: December 31, 2018 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 D. Barthel 9 Orange Labs 10 June 29, 2018 12 LPWAN Static Context Header Compression (SCHC) and fragmentation for 13 IPv6 and UDP 14 draft-ietf-lpwan-ipv6-static-context-hc-15 16 Abstract 18 This document defines the Static Context Header Compression (SCHC) 19 framework, which provides both header compression and fragmentation 20 functionalities. SCHC has been tailored for Low Power Wide Area 21 Networks (LPWAN). 23 SCHC compression is based on a common static context stored in both 24 the LPWAN devices and the network side. This document defines a 25 header compression mechanism and its application to compress IPv6/UDP 26 headers. 28 This document also specifies a fragmentation and reassembly mechanism 29 that is used to support the IPv6 MTU requirement over the LPWAN 30 technologies. Fragmentation is needed for IPv6 datagrams that, after 31 SCHC compression or when such compression was not possible, still 32 exceed the layer two maximum payload size. 34 The SCHC header compression and fragmentation mechanisms are 35 independent of the specific LPWAN technology over which they are 36 used. Note that this document defines generic functionalities and 37 advisedly offers flexibility with regard to parameter settings and 38 mechanism choices. Such settings and choices are expected to be made 39 in other technology-specific documents. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on December 31, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 77 3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5 78 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7. Static Context Header Compression . . . . . . . . . . . . . . 13 82 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 14 83 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 16 84 7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 16 85 7.4. Matching operators . . . . . . . . . . . . . . . . . . . 18 86 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 18 87 7.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 20 88 7.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 20 89 7.5.3. mapping-sent CDA . . . . . . . . . . . . . . . . . . 20 90 7.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 20 91 7.5.5. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 21 92 7.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 21 93 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 21 94 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 95 8.2. Fragmentation Tools . . . . . . . . . . . . . . . . . . . 22 96 8.3. Reliability modes . . . . . . . . . . . . . . . . . . . . 25 97 8.4. Fragmentation Formats . . . . . . . . . . . . . . . . . . 27 98 8.4.1. Fragments that are not the last one . . . . . . . . . 27 99 8.4.2. All-1 fragment . . . . . . . . . . . . . . . . . . . 29 100 8.4.3. SCHC ACK format . . . . . . . . . . . . . . . . . . . 31 101 8.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 33 102 8.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 35 103 8.5.1. No-ACK . . . . . . . . . . . . . . . . . . . . . . . 36 104 8.5.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 36 105 8.5.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 39 106 8.6. Supporting multiple window sizes . . . . . . . . . . . . 41 107 8.7. Downlink SCHC Fragment transmission . . . . . . . . . . . 41 108 9. Padding management . . . . . . . . . . . . . . . . . . . . . 42 109 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 43 110 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 43 111 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 43 112 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 44 113 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 44 114 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 44 115 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 45 116 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 45 117 10.7.1. IPv6 source and destination prefixes . . . . . . . . 45 118 10.7.2. IPv6 source and destination IID . . . . . . . . . . 46 119 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 46 120 10.9. UDP source and destination port . . . . . . . . . . . . 46 121 10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 47 122 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 47 123 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 124 12. Security considerations . . . . . . . . . . . . . . . . . . . 48 125 12.1. Security considerations for SCHC 126 Compression/Decompression . . . . . . . . . . . . . . . 48 127 12.2. Security considerations for SCHC 128 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 48 129 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 130 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 131 14.1. Normative References . . . . . . . . . . . . . . . . . . 50 132 14.2. Informative References . . . . . . . . . . . . . . . . . 50 133 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 51 134 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 54 135 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 60 136 Appendix D. SCHC Parameters - Ticket #15 . . . . . . . . . . . . 67 137 Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 68 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 140 1. Introduction 142 This document defines the Static Context Header Compression (SCHC) 143 framework, which provides both header compression and fragmentation 144 functionalities. SCHC has been tailored for Low Power Wide Area 145 Networks (LPWAN). 147 Header compression is needed to efficiently bring Internet 148 connectivity to the node within an LPWAN network. Some LPWAN 149 networks properties can be exploited to get an efficient header 150 compression: 152 o The network topology is star-oriented, which means that all 153 packets follow the same path. For the needs of this document, the 154 architecture can simply be described as Devices (Dev) exchanging 155 information with LPWAN Application Servers (App) through Network 156 Gateways (NGW). 158 o Because devices embed built-in applications, the traffic flows to 159 be compressed are known in advance. Indeed, new applications 160 cannot be easily installed in LPWAN devices, as they would in 161 computers or smartphones. 163 The Static Context Header Compression (SCHC) is defined for this 164 environment. SCHC uses a context, in which information about header 165 fieds is stored. This context is static: the values of the header 166 fields do not change over time. This avoids complex 167 resynchronization mechanisms, that would be incompatible with LPWAN 168 characteristics. In most cases, a small context identifier is enough 169 to represent the full IPv6/UDP headers. The SCHC header compression 170 mechanism is independent of the specific LPWAN technology over which 171 it is used. 173 LPWAN technologies impose some strict limitations on traffic. For 174 instance, devices are sleeping most of the time and MAY receive data 175 during short periods of time after transmission to preserve battery. 176 LPWAN technologies are also characterized, among others, by a very 177 reduced data unit and/or payload size (see [RFC8376]). However, some 178 of these technologies do not provide fragmentation functionality, 179 therefore the only option for them to support the IPv6 MTU 180 requirement of 1280 bytes [RFC8200] is to use a fragmentation 181 protocol at the adaptation layer, below IPv6. In response to this 182 need, this document also defines a fragmentation/reassembly 183 mechanism, which supports the IPv6 MTU requirement over LPWAN 184 technologies. Such functionality has been designed under the 185 assumption that there is no out-of-sequence delivery of data units 186 between the entity performing fragmentation and the entity performing 187 reassembly. 189 Note that this document defines generic functionality and 190 purposefully offers flexibility with regard to parameter settings and 191 mechanism choices. Such settings and choices are expected to be made 192 in other, technology-specific documents. 194 2. Requirements Notation 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in BCP 199 14 [RFC2119][RFC8174] when, and only when, they appear in all 200 capitals, as shown here. 202 3. LPWAN Architecture 204 LPWAN technologies have similar network architectures but different 205 terminologies. Using the terminology defined in [RFC8376], we can 206 identify different types of entities in a typical LPWAN network, see 207 Figure 1: 209 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 210 actuators, etc.). There can be a very high density of devices per 211 radio gateway. 213 o The Radio Gateway (RGW), which is the end point of the constrained 214 link. 216 o The Network Gateway (NGW) is the interconnection node between the 217 Radio Gateway and the Internet. 219 o LPWAN-AAA Server, which controls the user authentication and the 220 applications. 222 o Application Server (App) 224 +------+ 225 () () () | |LPWAN-| 226 () () () () / \ +---------+ | AAA | 227 () () () () () () / \======| ^ |===|Server| +-----------+ 228 () () () | | <--|--> | +------+ |APPLICATION| 229 () () () () / \==========| v |=============| (App) | 230 () () () / \ +---------+ +-----------+ 231 Dev Radio Gateways NGW 233 Figure 1: LPWAN Architecture 235 4. Terminology 237 This section defines the terminology and acronyms used in this 238 document. 240 Note that the SCHC acronym is pronounced like "sheek" in English (or 241 "chic" in French). Therefore, this document writes "a SCHC Packet" 242 instead of "an SCHC Packet". 244 o Abort. A SCHC Fragment format to signal the other end-point that 245 the on-going fragment transmission is stopped and finished. 247 o All-0. The SCHC Fragment format for the last fragment of a window 248 that is not the last one of a SCHC Packet (see window in this 249 glossary). 251 o All-1. The SCHC Fragment format for the last fragment of the SCHC 252 Packet. 254 o All-0 empty. An All-0 SCHC Fragment without payload. It is used 255 to request the SCHC ACK with the encoded Bitmap when the 256 Retransmission Timer expires, in a window that is not the last one 257 of a packet. 259 o All-1 empty. An All-1 SCHC Fragment without payload. It is used 260 to request the SCHC ACK with the encoded Bitmap when the 261 Retransmission Timer expires in the last window of a packet. 263 o App: LPWAN Application. An application sending/receiving IPv6 264 packets to/from the Device. 266 o AppIID: Application Interface Identifier. The IID that identifies 267 the application server interface. 269 o Bi: Bidirectional. Characterises a Rule Entry that applies to 270 headers of packets travelling in either direction (Up and Dw, see 271 this glossary). 273 o Bitmap: a bit field in the SCHC ACK message that tells the sender 274 which SCHC Fragments in a window of fragments were correctly 275 received. 277 o C: Checked bit. Used in an acknowledgement (SCHC ACK) header to 278 determine if the MIC locally computed by the receiver matches (1) 279 the received MIC or not (0). 281 o CDA: Compression/Decompression Action. Describes the reciprocal 282 pair of actions that are performed at the compressor to compress a 283 header field and at the decompressor to recover the original 284 header field value. 286 o Compression Residue. The bits that need to be sent (beyond the 287 Rule ID itself) after applying the SCHC compression over each 288 header field. 290 o Context: A set of Rules used to compress/decompress headers. 292 o Dev: Device. A node connected to an LPWAN. A Dev SHOULD 293 implement SCHC. 295 o DevIID: Device Interface Identifier. The IID that identifies the 296 Dev interface. 298 o DI: Direction Indicator. This field tells which direction of 299 packet travel (Up, Dw or Bi) a Rule applies to. This allows for 300 assymmetric processing. 302 o DTag: Datagram Tag. This SCHC F/R header field is set to the same 303 value for all SCHC Fragments carrying the same SCHC Packet. 305 o Dw: Downlink direction for compression/decompression in both 306 sides, from SCHC C/D in the network to SCHC C/D in the Dev. 308 o FCN: Fragment Compressed Number. This SCHC F/R header field 309 carries an efficient representation of a larger-sized fragment 310 number. 312 o Field Description. A line in the Rule table. 314 o FID: Field Identifier. This is an index to describe the header 315 fields in a Rule. 317 o FL: Field Length is the length of the packet header field. It is 318 expressed in bits for header fields of fixed lengths or as a type 319 (e.g. variable, token length, ...) for field lengths that are 320 unknown at the time of Rule creation. The length of a header 321 field is defined in the corresponding protocol specification. 323 o FP: Field Position is a value that is used to identify the 324 position where each instance of a field appears in the header. 326 o IID: Interface Identifier. See the IPv6 addressing architecture 327 [RFC7136] 329 o Inactivity Timer. A timer used after receiving a SCHC Fragment to 330 detect when, due to a communication error, there is no possibility 331 to continue an on-going fragmented SCHC Packet transmission. 333 o L2: Layer two. The immediate lower layer SCHC interfaces with. 334 It is provided by an underlying LPWAN technology. 336 o L2 Word: this is the minimum subdivision of payload data that the 337 L2 will carry. In most L2 technologies, the L2 Word is an octet. 338 In bit-oriented radio technologies, the L2 Word might be a single 339 bit. The L2 Word size is assumed to be constant over time for 340 each device. 342 o MIC: Message Integrity Check. A SCHC F/R header field computed 343 over the fragmented SCHC Packet and potential fragment padding, 344 used for error detection after SCHC Packet reassembly. 346 o MO: Matching Operator. An operator used to match a value 347 contained in a header field with a value contained in a Rule. 349 o Padding (P). Extra bits that may be appended by SCHC to a data 350 unit that it passes to the underlying Layer 2 for transmission. 351 SCHC itself operates on bits, not bytes, and does not have any 352 alignment prerequisite. See Section 9. 354 o Retransmission Timer. A timer used by the SCHC Fragment sender 355 during an on-going fragmented SCHC Packet transmission to detect 356 possible link errors when waiting for a possible incoming SCHC 357 ACK. 359 o Rule: A set of header field values. 361 o Rule entry: A column in a Rule that describes a parameter of the 362 header field. 364 o Rule ID: An identifier for a Rule. SCHC C/D on both sides share 365 the same Rule ID for a given packet. A set of Rule IDs are used 366 to support SCHC F/R functionality. 368 o SCHC ACK: A SCHC acknowledgement for fragmentation. This message 369 is used to report on the success of reception of a set of SCHC 370 Fragments. See Section 8 for more details. 372 o SCHC C/D: Static Context Header Compression Compressor/ 373 Decompressor. A mechanism used on both sides, at the Dev and at 374 the network, to achieve Compression/Decompression of headers. 375 SCHC C/D uses Rules to perform compression and decompression. 377 o SCHC F/R: Static Context Header Compression Fragmentation/ 378 Reassembly. A protocol used on both sides, at the Dev and at the 379 network, to achieve Fragmentation/Reassembly of SCHC Packets. 380 SCHC F/R has three reliability modes. 382 o SCHC Fragment: A data unit that carries a subset of a SCHC Packet. 383 SCHC F/R is needed when the size of a SCHC packet exceeds the 384 available payload size of the underlying L2 technology data unit. 385 See Section 8. 387 o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been 388 compressed as per the header compression mechanism defined in this 389 document. If the header compression process is unable to actually 390 compress the packet header, the packet with the uncompressed 391 header is still called a SCHC Packet (in this case, a Rule ID is 392 used to indicate that the packet header has not been compressed). 393 See Section 7 for more details. 395 o TV: Target value. A value contained in a Rule that will be 396 matched with the value of a header field. 398 o Up: Uplink direction for compression/decompression in both sides, 399 from the Dev SCHC C/D to the network SCHC C/D. 401 o W: Window bit. A SCHC Fragment header field used in ACK-on-Error 402 or ACK-Always mode Section 8, which carries the same value for all 403 SCHC Fragments of a window. 405 o Window: A subset of the SCHC Fragments needed to carry a SCHC 406 Packet (see Section 8). 408 5. SCHC overview 410 SCHC can be abstracted as an adaptation layer between IPv6 and the 411 underlying LPWAN technology. SCHC comprises two sublayers (i.e. the 412 Compression sublayer and the Fragmentation sublayer), as shown in 413 Figure 2. 415 +----------------+ 416 | IPv6 | 417 +- +----------------+ 418 | | Compression | 419 SCHC < +----------------+ 420 | | Fragmentation | 421 +- +----------------+ 422 |LPWAN technology| 423 +----------------+ 425 Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN 426 technology 428 As per this document, when a packet (e.g. an IPv6 packet) needs to be 429 transmitted, header compression is first applied to the packet. The 430 resulting packet after header compression (whose header may or may 431 not actually be smaller than that of the original packet) is called a 432 SCHC Packet. If the SCHC Packet size exceeds the layer 2 (L2) MTU, 433 fragmentation is then applied to the SCHC Packet. The SCHC Packet or 434 the SCHC Fragments are then transmitted over the LPWAN. The 435 reciprocal operations take place at the receiver. This process is 436 illustrated in Figure 3. 438 A packet (e.g. an IPv6 packet) 439 | ^ 440 v | 441 +------------------+ +--------------------+ 442 | SCHC Compression | | SCHC Decompression | 443 +------------------+ +--------------------+ 444 | ^ 445 | If no fragmentation (*) | 446 +-------------- SCHC Packet -------------->| 447 | | 448 v | 449 +--------------------+ +-----------------+ 450 | SCHC Fragmentation | | SCHC Reassembly | 451 +--------------------+ +-----------------+ 452 | ^ | ^ 453 | | | | 454 | +-------------- SCHC ACK -------------+ | 455 | | 456 +-------------- SCHC Fragments -------------------+ 458 SENDER RECEIVER 460 *: the decision to use Fragmentation or not is left to each LPWAN technology 461 over which SCHC is applied. See LPWAN technology-specific documents. 463 Figure 3: SCHC operations taking place at the sender and the receiver 465 The SCHC Packet is composed of the Compressed Header followed by the 466 payload from the original packet (see Figure 4). The Compressed 467 Header itself is composed of a Rule ID and a Compression Residue. 468 The Compression Residue may be absent, see Section 7. Both the Rule 469 ID and the Compression Residue potentially have a variable size, and 470 generally are not a mutiple of bytes in size. 472 | Rule ID + Compression Residue | 473 +---------------------------------+--------------------+ 474 | Compressed Header | Payload | 475 +---------------------------------+--------------------+ 477 Figure 4: SCHC Packet 479 The Fragment Header size is variable and depends on the Fragmentation 480 parameters. The Fragment payload contains a part of the SCHC Packet 481 Compressed Header, a part of the SCHC Packet Payload or both. Its 482 size depends on the L2 data unit, see Section 8. The SCHC Fragment 483 has the following format: 485 | Rule ID + DTAG + W + FCN [+ MIC ] | Partial SCHC Packet | 486 +-----------------------------------+-------------------------+ 487 | Fragment Header | Fragment Payload | 488 +-----------------------------------+-------------------------+ 490 Figure 5: SCHC Fragment 492 The SCHC ACK is only used for Fragmentation. It has the following 493 format: 495 |Rule ID + DTag + W| 496 +------------------+-------- ... ---------+ 497 | ACK Header | encoded Bitmap | 498 +------------------+-------- ... ---------+ 500 Figure 6: SCHC ACK 502 The SCHC ACK Header and the encoded Bitmap both have variable size. 504 Figure 7 below maps the functional elements of Figure 3 onto the 505 LPWAN architecture elements of Figure 1. 507 Dev App 508 +----------------+ +--------------+ 509 | APP1 APP2 APP3 | |APP1 APP2 APP3| 510 | | | | 511 | UDP | | UDP | 512 | IPv6 | | IPv6 | 513 | | | | 514 |SCHC C/D and F/R| | | 515 +--------+-------+ +-------+------+ 516 | +--+ +----+ +-----------+ . 517 +~~ |RG| === |NGW | === | SCHC |... Internet .. 518 +--+ +----+ |F/R and C/D| 519 +-----------+ 521 Figure 7: Architecture 523 SCHC C/D and SCHC F/R are located on both sides of the LPWAN 524 transmission, i.e. on the Dev side and on the Network side. 526 Let's describe the operation in the Uplink direction. The Device 527 application packets use IPv6 or IPv6/UDP protocols. Before sending 528 these packets, the Dev compresses their headers using SCHC C/D and, 529 if the SCHC Packet resulting from the compression exceeds the maximum 530 payload size of the underlying LPWAN technology, SCHC F/R is 531 performed (see Section 8). The resulting SCHC Fragments are sent as 532 one or more L2 frames to an LPWAN Radio Gateway (RG) which forwards 533 them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/ 534 R and then to the SCHC C/D for decompression. The SCHC F/R and C/D 535 on the Network side can be located in the NGW or somewhere else as 536 long as a tunnel is established between them and the NGW. Note that, 537 for some LPWAN technologies, it MAY be suitable to locate the SCHC F/ 538 R functionality nearer the NGW, in order to better deal with time 539 constraints of such technologies. The SCHC C/D and F/R on both sides 540 MUST share the same set of Rules. After decompression, the packet 541 can be sent over the Internet to one or several LPWAN Application 542 Servers (App). 544 The SCHC C/D and F/R process is symmetrical, therefore the 545 description of the Downlink direction trivially derives from the one 546 above. 548 6. Rule ID 550 Rule IDs are identifiers used to select the correct context either 551 for Compression/Decompression or for Fragmentation/Reassembly. 553 The size of the Rule IDs is not specified in this document, as it is 554 implementation-specific and can vary according to the LPWAN 555 technology and the number of Rules, among others. 557 The Rule IDs are used: 559 o In the SCHC C/D context, to identify the Rule (i.e., the set of 560 Field Descriptions) that is used to compress a packet header. 562 o At least one Rule ID MAY be allocated to tagging packets for which 563 SCHC compression was not possible (no matching Rule was found). 565 o In SCHC F/R, to identify the specific modes and settings of SCHC 566 Fragments being transmitted, and to identify the SCK ACKs, 567 including their modes and settings. Note that in the case of 568 bidirectional communication, at least two Rule ID values are 569 therefore needed for F/R. 571 7. Static Context Header Compression 573 In order to perform header compression, this document defines a 574 mechanism called Static Context Header Compression (SCHC), which is 575 based on using context, i.e. a set of Rules to compress or decompress 576 headers. SCHC avoids context synchronization, which is the most 577 bandwidth-consuming operation in other header compression mechanisms 578 such as RoHC [RFC5795]. Since the nature of packets is highly 579 predictable in LPWAN networks, static contexts MAY be stored 580 beforehand to omit transmitting some information over the air. The 581 contexts MUST be stored at both ends, and they can be learned by a 582 provisioning protocol or by out of band means, or they can be pre- 583 provisioned. The way the contexts are provisioned on both ends is 584 out of the scope of this document. 586 7.1. SCHC C/D Rules 588 The main idea of the SCHC compression scheme is to transmit the Rule 589 ID to the other end instead of sending known field values. This Rule 590 ID identifies a Rule that provides the closest match to the original 591 packet values. Hence, when a value is known by both ends, it is only 592 necessary to send the corresponding Rule ID over the LPWAN network. 593 How Rules are generated is out of the scope of this document. The 594 Rules MAY be changed at run-time but the way to do this will be 595 specified in another document. 597 The context contains a list of Rules (cf. Figure 8). Each Rule 598 itself contains a list of Field Descriptions composed of a Field 599 Identifier (FID), a Field Length (FL), a Field Position (FP), a 600 Direction Indicator (DI), a Target Value (TV), a Matching Operator 601 (MO) and a Compression/Decompression Action (CDA). 603 /-----------------------------------------------------------------\ 604 | Rule N | 605 /-----------------------------------------------------------------\| 606 | Rule i || 607 /-----------------------------------------------------------------\|| 608 | (FID) Rule 1 ||| 609 |+-------+--+--+--+------------+-----------------+---------------+||| 610 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 611 |+-------+--+--+--+------------+-----------------+---------------+||| 612 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 613 |+-------+--+--+--+------------+-----------------+---------------+||| 614 ||... |..|..|..| ... | ... | ... |||| 615 |+-------+--+--+--+------------+-----------------+---------------+||/ 616 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 617 |+-------+--+--+--+------------+-----------------+---------------+|/ 618 | | 619 \-----------------------------------------------------------------/ 621 Figure 8: Compression/Decompression Context 623 A Rule does not describe how to parse a packet header to find each 624 field. This MUST be known from the compressor/decompressor. Rules 625 only describe the compression/decompression behavior for each header 626 field. In a Rule, the Field Descriptions are listed in the order in 627 which the fields appear in the packet header. 629 A Rule also describes what Compression Residue is sent. The 630 Compression Residue is assembled by concatenating the residues for 631 each field, in the order the Field Descriptions appear in the Rule. 633 The Context describes the header fields and its values with the 634 following entries: 636 o Field ID (FID) is a unique value to define the header field. 638 o Field Length (FL) represents the length of the field. It can be 639 either a fixed value (in bits) if the length is known when the 640 Rule is created or a type if the length is variable. The length 641 of a header field is defined in the corresponding protocol 642 specification. The type defines the process to compute the 643 length, its unit (bits, bytes,...) and the value to be sent before 644 the Compression Residue. 646 o Field Position (FP): most often, a field only occurs once in a 647 packet header. Some fields may occur multiple times in a header. 648 FP indicates which occurrence this Field Description applies to. 649 The default value is 1 (first occurence). 651 o A Direction Indicator (DI) indicates the packet direction(s) this 652 Field Description applies to. Three values are possible: 654 * UPLINK (Up): this Field Description is only applicable to 655 packets sent by the Dev to the App, 657 * DOWNLINK (Dw): this Field Description is only applicable to 658 packets sent from the App to the Dev, 660 * BIDIRECTIONAL (Bi): this Field Description is applicable to 661 packets travelling both Up and Dw. 663 o Target Value (TV) is the value used to make the match with the 664 packet header field. The Target Value can be of any type 665 (integer, strings, etc.). For instance, it can be a single value 666 or a more complex structure (array, list, etc.), such as a JSON or 667 a CBOR structure. 669 o Matching Operator (MO) is the operator used to match the Field 670 Value and the Target Value. The Matching Operator may require 671 some parameters. MO is only used during the compression phase. 672 The set of MOs defined in this document can be found in 673 Section 7.4. 675 o Compression Decompression Action (CDA) describes the compression 676 and decompression processes to be performed after the MO is 677 applied. Some CDAs MAY require parameter values for their 678 operation. CDAs are used in both the compression and the 679 decompression functions. The set of CDAs defined in this document 680 can be found in Section 7.5. 682 7.2. Rule ID for SCHC C/D 684 Rule IDs are sent by the compression function in one side and are 685 received for the decompression function in the other side. In SCHC 686 C/D, the Rule IDs are specific to a Dev. Hence, multiple Dev 687 instances MAY use the same Rule ID to define different header 688 compression contexts. To identify the correct Rule ID, the SCHC C/D 689 needs to correlate the Rule ID with the Dev identifier to find the 690 appropriate Rule to be applied. 692 7.3. Packet processing 694 The compression/decompression process follows several steps: 696 o Compression Rule selection: The goal is to identify which Rule(s) 697 will be used to compress the packet's headers. When doing 698 decompression, on the network side the SCHC C/D needs to find the 699 correct Rule based on the L2 address and in this way, it can use 700 the DevIID and the Rule ID. On the Dev side, only the Rule ID is 701 needed to identify the correct Rule since the Dev only holds Rules 702 that apply to itself. The Rule will be selected by matching the 703 Fields Descriptions to the packet header as described below. When 704 the selection of a Rule is done, this Rule is used to compress the 705 header. The detailed steps for compression Rule selection are the 706 following: 708 * The first step is to choose the Field Descriptions by their 709 direction, using the Direction Indicator (DI). A Field 710 Description that does not correspond to the appropriate DI will 711 be ignored. If all the fields of the packet do not have a 712 Field Description with the correct DI, the Rule is discarded 713 and SCHC C/D proceeds to explore the next Rule. 715 * When the DI has matched, then the next step is to identify the 716 fields according to Field Position (FP). If FP does not 717 correspond, the Rule is not used and the SCHC C/D proceeds to 718 consider the next Rule. 720 * Once the DI and the FP correspond to the header information, 721 each packet field's value is then compared to the corresponding 722 Target Value (TV) stored in the Rule for that specific field 723 using the matching operator (MO). 725 If all the fields in the packet's header satisfy all the 726 matching operators (MO) of a Rule (i.e. all MO results are 727 True), the fields of the header are then compressed according 728 to the Compression/Decompression Actions (CDAs) and a 729 compressed header (with possibly a Compression Residue) SHOULD 730 be obtained. Otherwise, the next Rule is tested. 732 * If no eligible Rule is found, then the header MUST be sent 733 without compression. This MAY require the use of the SCHC F/R 734 process. 736 o Sending: If an eligible Rule is found, the Rule ID is sent to the 737 other end followed by the Compression Residue (which could be 738 empty) and directly followed by the payload. The Compression 739 Residue is the concatenation of the Compression Residues for each 740 field according to the CDAs for that Rule. The way the Rule ID is 741 sent depends on the specific underlying LPWAN technology. For 742 example, it can be either included in an L2 header or sent in the 743 first byte of the L2 payload. (Cf. Figure 9). This process will 744 be specified in the LPWAN technology-specific document and is out 745 of the scope of the present document. On LPWAN technologies that 746 are byte-oriented, the compressed header concatenated with the 747 original packet payload is padded to a multiple of 8 bits, if 748 needed. See Section 9 for details. 750 o Decompression: When doing decompression, on the network side the 751 SCHC C/D needs to find the correct Rule based on the L2 address 752 and in this way, it can use the DevIID and the Rule ID. On the 753 Dev side, only the Rule ID is needed to identify the correct Rule 754 since the Dev only holds Rules that apply to itself. 756 The receiver identifies the sender through its device-id (e.g. 757 MAC address, if exists) and selects the appropriate Rule from the 758 Rule ID. If a source identifier is present in the L2 technology, 759 it is used to select the Rule ID. This Rule describes the 760 compressed header format and associates the values to the header 761 fields. The receiver applies the CDA action to reconstruct the 762 original header fields. The CDA application order can be 763 different from the order given by the Rule. For instance, 764 Compute-* SHOULD be applied at the end, after all the other CDAs. 766 +--- ... --+------- ... -------+------------------+ 767 | Rule ID |Compression Residue| packet payload | 768 +--- ... --+------- ... -------+------------------+ 770 |----- compressed header ------| 772 Figure 9: SCHC C/D Packet Format 774 7.4. Matching operators 776 Matching Operators (MOs) are functions used by both SCHC C/D 777 endpoints involved in the header compression/decompression. They are 778 not typed and can be indifferently applied to integer, string or any 779 other data type. The result of the operation can either be True or 780 False. MOs are defined as follows: 782 o equal: The match result is True if a field value in a packet and 783 the value in the TV are equal. 785 o ignore: No check is done between a field value in a packet and a 786 TV in the Rule. The result of the matching is always true. 788 o MSB(x): A match is obtained if the most significant x bits of the 789 packet header field value are equal to the TV in the Rule. The x 790 parameter of the MSB MO indicates how many bits are involved in 791 the comparison. If the FL is described as variable, the length 792 must be a multiple of the unit. For example, x must be multiple 793 of 8 if the unit of the variable length is in bytes. 795 o match-mapping: With match-mapping, the Target Value is a list of 796 values. Each value of the list is identified by a short ID (or 797 index). Compression is achieved by sending the index instead of 798 the original header field value. This operator matches if the 799 header field value is equal to one of the values in the target 800 list. 802 7.5. Compression Decompression Actions (CDA) 804 The Compression Decompression Action (CDA) describes the actions 805 taken during the compression of headers fields, and inversely, the 806 action taken by the decompressor to restore the original value. 808 /--------------------+-------------+----------------------------\ 809 | Action | Compression | Decompression | 810 | | | | 811 +--------------------+-------------+----------------------------+ 812 |not-sent |elided |use value stored in context | 813 |value-sent |send |build from received value | 814 |mapping-sent |send index |value from index on a table | 815 |LSB |send LSB |TV, received value | 816 |compute-length |elided |compute length | 817 |compute-checksum |elided |compute UDP checksum | 818 |DevIID |elided |build IID from L2 Dev addr | 819 |AppIID |elided |build IID from L2 App addr | 820 \--------------------+-------------+----------------------------/ 822 Figure 10: Compression and Decompression Actions 824 Figure 10 summarizes the basic functions that can be used to compress 825 and decompress a field. The first column lists the actions name. 826 The second and third columns outline the reciprocal compression/ 827 decompression behavior for each action. 829 Compression is done in order that Fields Descriptions appear in a 830 Rule. The result of each Compression/Decompression Action is 831 appended to the working Compression Residue in that same order. The 832 receiver knows the size of each compressed field which can be given 833 by the Rule or MAY be sent with the compressed header. 835 If the field is identified as being variable in the Field 836 Description, then the size of the Compression Residue value (using 837 the unit defined in the FL) MUST be sent first using the following 838 coding: 840 o If the size is between 0 and 14, it is sent as a 4-bits integer. 842 o For values between 15 and 254, the first 4 bits sent are set to 1 843 and the size is sent using 8 bits integer. 845 o For higher values of size, the first 12 bits are set to 1 and the 846 next two bytes contain the size value as a 16 bits integer. 848 If a field is not present in the packet but exists in the Rule and 849 its FL is specified as being variable, size 0 MUST be sent to denote 850 its absence. 852 7.5.1. not-sent CDA 854 The not-sent function is generally used when the field value is 855 specified in a Rule and therefore known by both the Compressor and 856 the Decompressor. This action is generally used with the "equal" MO. 857 If MO is "ignore", there is a risk to have a decompressed field value 858 different from the original field that was compressed. 860 The compressor does not send any Compression Residue for a field on 861 which not-sent compression is applied. 863 The decompressor restores the field value with the Target Value 864 stored in the matched Rule identified by the received Rule ID. 866 7.5.2. value-sent CDA 868 The value-sent action is generally used when the field value is not 869 known by both the Compressor and the Decompressor. The value is sent 870 as a residue in the compressed message header. Both Compressor and 871 Decompressor MUST know the size of the field, either implicitly (the 872 size is known by both sides) or by explicitly indicating the length 873 in the Compression Residue, as defined in Section 7.5. This function 874 is generally used with the "ignore" MO. 876 7.5.3. mapping-sent CDA 878 The mapping-sent is used to send a smaller index (the index into the 879 Target Value list of values) instead of the original value. This 880 function is used together with the "match-mapping" MO. 882 On the compressor side, the match-mapping Matching Operator searches 883 the TV for a match with the header field value and the mapping-sent 884 CDA appends the corresponding index to the Compression Residue to be 885 sent. On the decompressor side, the CDA uses the received index to 886 restore the field value by looking up the list in the TV. 888 The number of bits sent is the minimal size for coding all the 889 possible indices. 891 7.5.4. LSB CDA 893 The LSB action is used together with the "MSB(x)" MO to avoid sending 894 the most significant part of the packet field if that part is already 895 known by the receiving end. The number of bits sent is the original 896 header field length minus the length specified in the MSB(x) MO. 898 The compressor sends the Least Significant Bits (e.g. LSB of the 899 length field). The decompressor concatenates the x most significant 900 bits of Target Value and the received residue. 902 If this action needs to be done on a variable length field, the size 903 of the Compression Residue in bytes MUST be sent as described in 904 Section 7.5. 906 7.5.5. DevIID, AppIID CDA 908 These functions are used to process respectively the Dev and the App 909 Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. 910 AppIID CDA is less common since current LPWAN technologies frames 911 contain a single address, which is the Dev's address. 913 The IID value MAY be computed from the Device ID present in the L2 914 header, or from some other stable identifier. The computation is 915 specific to each LPWAN technology and MAY depend on the Device ID 916 size. 918 In the downlink direction (Dw), at the compressor, this DevIID CDA 919 may be used to generate the L2 addresses on the LPWAN, based on the 920 packet destination address. 922 7.5.6. Compute-* 924 Some fields are elided during compression and reconstructed during 925 decompression. This is the case for length and checksum, so: 927 o compute-length: computes the length assigned to this field. This 928 CDA MAY be used to compute IPv6 length or UDP length. 930 o compute-checksum: computes a checksum from the information already 931 received by the SCHC C/D. This field MAY be used to compute UDP 932 checksum. 934 8. Fragmentation 936 8.1. Overview 938 In LPWAN technologies, the L2 data unit size typically varies from 939 tens to hundreds of bytes. The SCHC F/R (Fragmentation /Reassembly) 940 MAY be used either because after applying SCHC C/D or when SCHC C/D 941 is not possible the entire SCHC Packet still exceeds the L2 data 942 unit. 944 The SCHC F/R functionality defined in this document has been designed 945 under the assumption that data unit out-of-sequence delivery will not 946 happen between the entity performing fragmentation and the entity 947 performing reassembly. This assumption allows reducing the 948 complexity and overhead of the SCHC F/R mechanism. 950 This document also assumes that the L2 data unit size does not vary 951 while a fragmented SCHC Packet is being transmitted. 953 To adapt the SCHC F/R to the capabilities of LPWAN technologies, it 954 is required to enable optional SCHC Fragment retransmission and to 955 allow for a range of reliability options for sending the SCHC 956 Fragments. This document does not make any decision with regard to 957 which SCHC Fragment delivery reliability mode will be used over a 958 specific LPWAN technology. These details will be defined in other 959 technology-specific documents. 961 SCHC F/R uses the knowledge of the L2 Word size (see Section 4) to 962 encode some messages. Therefore, SCHC MUST know the L2 Word size. 963 SCHC F/R generates SCHC Fragments and SCHC ACKs that are, for most of 964 them, multiples of L2 Words. The padding overhead is kept to the 965 absolute minimum. See Section 9. 967 8.2. Fragmentation Tools 969 This subsection describes the different tools that are used to enable 970 the SCHC F/R functionality defined in this document, such as fields 971 in the SCHC F/R header frames (see the related formats in 972 Section 8.4), windows and timers. 974 o Rule ID. The Rule ID is present in the SCHC Fragment header and 975 in the SCHC ACK header formats. The Rule ID in a SCHC Fragment 976 header is used to identify that a SCHC Fragment is being carried, 977 which SCHC F/R reliability mode is used and which window size is 978 used. The Rule ID in the SCHC Fragment header also allows 979 interleaving non-fragmented SCHC Packets and SCHC Fragments that 980 carry other SCHC Packets. The Rule ID in a SCHC ACK identifies 981 the message as a SCHC ACK. 983 o Fragment Compressed Number (FCN). The FCN is included in all SCHC 984 Fragments. This field can be understood as a truncated, efficient 985 representation of a larger-sized fragment number, and does not 986 carry an absolute SCHC Fragment number. There are two FCN 987 reserved values that are used for controlling the SCHC F/R 988 process, as described next: 990 * The FCN value with all the bits equal to 1 (All-1) denotes the 991 last SCHC Fragment of a packet. The last window of a packet is 992 called an All-1 window. 994 * The FCN value with all the bits equal to 0 (All-0) denotes the 995 last SCHC Fragment of a window that is not the last one of the 996 packet. Such a window is called an All-0 window. 998 The rest of the FCN values are assigned in a sequentially 999 decreasing order, which has the purpose to avoid possible 1000 ambiguity for the receiver that might arise under certain 1001 conditions. In the SCHC Fragments, this field is an unsigned 1002 integer, with a size of N bits. In the No-ACK mode, the size is 1003 set to 1 bit (N=1), All-0 is used in all SCHC Fragments and All-1 1004 for the last one. For the other reliability modes, it is 1005 recommended to use a number of bits (N) equal to or greater than 1006 3. Nevertheless, the appropriate value of N MUST be defined in 1007 the corresponding technology-specific profile documents. For 1008 windows that are not the last one of a fragmented SCHC Packet, the 1009 FCN for the last SCHC Fragment in such windows is an All-0. This 1010 indicates that the window is finished and communication proceeds 1011 according to the reliability mode in use. The FCN for the last 1012 SCHC Fragment in the last window is an All-1, indicating the last 1013 SCHC Fragment of the SCHC Packet. It is also important to note 1014 that, in the No-ACK mode or when N=1, the last SCHC Fragment of 1015 the packet will carry a FCN equal to 1, while all previous SCHC 1016 Fragments will carry a FCN to 0. For further details see 1017 Section 8.5. The highest FCN in the window, denoted MAX_WIND_FCN, 1018 MUST be a value equal to or smaller than 2^N-2. (Example for N=5, 1019 MAX_WIND_FCN MAY be set to 23, then subsequent FCNs are set 1020 sequentially and in decreasing order, and the FCN will wrap from 0 1021 back to 23). 1023 o Datagram Tag (DTag). The DTag field, if present, is set to the 1024 same value for all SCHC Fragments carrying the same SCHC 1025 packet, and to different values for different SCHC Packets. Using 1026 this field, the sender can interleave fragments from different 1027 SCHC Packets, while the receiver can still tell them apart. In 1028 the SCHC Fragment formats, the size of the DTag field is T bits, 1029 which MAY be set to a value greater than or equal to 0 bits. For 1030 each new SCHC Packet processed by the sender, DTag MUST be 1031 sequentially increased, from 0 to 2^T - 1 wrapping back from 2^T - 1032 1 to 0. In the SCHC ACK format, DTag carries the same value as 1033 the DTag field in the SCHC Fragments for which this SCHC ACK is 1034 intended. When there is no Dtag, there can be only one SCHC 1035 Packet in transit. Only after all its fragments have been 1036 transmitted can another SCHC Packet be sent. The length of DTag, 1037 denoted T, is not specified in this document because it is 1038 technology dependant. It will be defined in the corresponding 1039 technology-specific documents, based on the number of simultaneous 1040 packets that are to be supported. 1042 o W (window): W is a 1-bit field. This field carries the same value 1043 for all SCHC Fragments of a window, and it is complemented for the 1044 next window. The initial value for this field is 0. In the SCHC 1045 ACK format, this field also has a size of 1 bit. In all SCHC 1046 ACKs, the W bit carries the same value as the W bit carried by the 1047 SCHC Fragments whose reception is being positively or negatively 1048 acknowledged by the SCHC ACK. 1050 o Message Integrity Check (MIC). This field is computed by the 1051 sender over the complete SCHC Packet and before SCHC 1052 fragmentation. The MIC allows the receiver to check errors in the 1053 reassembled packet, while it also enables compressing the UDP 1054 checksum by use of SCHC compression. The CRC32 as 0xEDB88320 1055 (i.e. the reverse representation of the polynomial used e.g. in 1056 the Ethernet standard [RFC3385]) is recommended as the default 1057 algorithm for computing the MIC. Nevertheless, other algorithms 1058 MAY be required and are defined in the technology-specific 1059 documents as well as the length in bits of the MIC used. 1061 o C (MIC checked): C is a 1-bit field. This field is used in the 1062 SCHC ACK packets to report the outcome of the MIC check, i.e. 1063 whether the reassembled packet was correctly received or not. A 1064 value of 1 represents a positive MIC check at the receiver side 1065 (i.e. the MIC computed by the receiver matches the received MIC). 1067 o Retransmission Timer. A SCHC Fragment sender uses it after the 1068 transmission of a window to detect a transmission error of the 1069 SCHC ACK corresponding to this window. Depending on the 1070 reliability mode, it will lead to a request a SCHC ACK 1071 retransmission (in ACK-Always mode) or it will trigger the 1072 transmission of the next window (in ACK-on-Error mode). The 1073 duration of this timer is not defined in this document and MUST be 1074 defined in the corresponding technology-specific documents. 1076 o Inactivity Timer. A SCHC Fragment receiver uses it to take action 1077 when there is a problem in the transmission of SCHC fragments. 1078 Such a problem could be detected by the receiver not getting a 1079 single SCHC Fragment during a given period of time. When this 1080 happens, an Abort message will be sent (see related text later in 1081 this section). Initially, and each time a SCHC Fragment is 1082 received, the timer is reinitialized. The duration of this timer 1083 is not defined in this document and MUST be defined in the 1084 corresponding technology-specific document. 1086 o Attempts. This counter counts the requests for a missing SCHC 1087 ACK. When it reaches the value MAX_ACK_REQUESTS, the sender 1088 assumes there are recurrent SCHC Fragment transmission errors and 1089 determines that an Abort is needed. The default value 1090 MAX_ACK_REQUESTS is not stated in this document, and it is 1091 expected to be defined in the corresponding technology-specific 1092 document. The Attempts counter is defined per window. It is 1093 initialized each time a new window is used. 1095 o Bitmap. The Bitmap is a sequence of bits carried in a SCHC ACK. 1096 Each bit in the Bitmap corresponds to a SCHC fragment of the 1097 current window, and provides feedback on whether the SCHC Fragment 1098 has been received or not. The right-most position on the Bitmap 1099 reports if the All-0 or All-1 fragment has been received or not. 1100 Feedback on the SCHC fragment with the highest FCN value is 1101 provided by the bit in the left-most position of the Bitmap. In 1102 the Bitmap, a bit set to 1 indicates that the SCHC Fragment of FCN 1103 corresponding to that bit position has been correctly sent and 1104 received. The text above describes the internal representation of 1105 the Bitmap. When inserted in the SCHC ACK for transmission from 1106 the receiver to the sender, the Bitmap is shortened for energy/ 1107 bandwidth optimisation, see more details in Section 8.4.3.1. 1109 o Abort. On expiration of the Inactivity timer, or when Attempts 1110 reaches MAX_ACK_REQUESTS or upon occurrence of some other error, 1111 the sender or the receiver may use the Abort. When the receiver 1112 needs to abort the on-going fragmented SCHC Packet transmission, 1113 it sends the Receiver-Abort format. When the sender needs to 1114 abort the transmission, it sends the Sender-Abort format. None of 1115 the Aborts are acknowledged. 1117 8.3. Reliability modes 1119 This specification defines three reliability modes: No-ACK, ACK- 1120 Always, and ACK-on-Error. ACK-Always and ACK-on-Error operate on 1121 windows of SCHC Fragments. A window of SCHC Fragments is a subset of 1122 the full set of SCHC Fragments needed to carry a SCHC Packet. 1124 o No-ACK. No-ACK is the simplest SCHC Fragment reliability mode. 1125 The receiver does not generate overhead in the form of 1126 acknowledgements (ACKs). However, this mode does not enhance 1127 reliability beyond that offered by the underlying LPWAN 1128 technology. In the No-ACK mode, the receiver MUST NOT issue SCHC 1129 ACKs. See further details in Section 8.5.1. 1131 o ACK-Always. The ACK-Always mode provides flow control using a 1132 windowing scheme. This mode is also able to handle long bursts of 1133 lost SCHC Fragments since detection of such events can be done 1134 before the end of the SCHC Packet transmission as long as the 1135 window size is short enough. However, such benefit comes at the 1136 expense of SCHC ACK use. In ACK-Always, the receiver sends a SCHC 1137 ACK after a window of SCHC Fragments has been received. The SCHC 1138 ACK is used to inform the sender which SCHC Fragments in the 1139 current window have been well received. Upon a SCHC ACK 1140 reception, the sender retransmits the lost SCHC Fragments. When a 1141 SCHC ACK is lost and the sender has not received it by the 1142 expiration of the Retransmission Timer, the sender uses a SCHC ACK 1143 request by sending the All-0 empty SCHC Fragment when it is not 1144 the last window and the All-1 empty Fragment when it is the last 1145 window. The maximum number of SCHC ACK requests is 1146 MAX_ACK_REQUESTS. If MAX_ACK_REQUESTS is reached, the 1147 transmission needs to be aborted. See further details in 1148 Section 8.5.2. 1150 o ACK-on-Error. The ACK-on-Error mode is suitable for links 1151 offering relatively low L2 data unit loss probability. In this 1152 mode, the SCHC Fragment receiver reduces the number of SCHC ACKs 1153 transmitted, which MAY be especially beneficial in asymmetric 1154 scenarios. The receiver transmits a SCHC ACK only after the 1155 complete window transmission and if at least one SCHC Fragment of 1156 this window has been lost. An exception to this behavior is in 1157 the last window, where the receiver MUST transmit a SCHC ACK, 1158 including the C bit set based on the MIC checked result, even if 1159 all the SCHC Fragments of the last window have been correctly 1160 received. The SCHC ACK gives the state of all the SCHC Fragments 1161 of the current window (received or lost). Upon a SCHC ACK 1162 reception, the sender retransmits any lost SCHC Fragments based on 1163 the SCHC ACK. If a SCHC ACK is not transmitted back by the 1164 receiver at the end of a window, the sender assumes that all SCHC 1165 Fragments have been correctly received. When a SCHC ACK is lost, 1166 the sender assumes that all SCHC Fragments covered by the lost 1167 SCHC ACK have been successfully delivered, so the sender continues 1168 transmitting the next window of SCHC Fragments. If the next SCHC 1169 Fragments received belong to the next window and it is still 1170 expecting fragments from the previous window, the receiver will 1171 abort the on-going fragmented packet transmission. See further 1172 details in Section 8.5.3. 1174 The same reliability mode MUST be used for all SCHC Fragments of a 1175 SCHC Packet. The decision on which reliability mode will be used and 1176 whether the same reliability mode applies to all SCHC Packets is an 1177 implementation problem and is out of the scope of this document. 1179 Note that the reliability mode choice is not necessarily tied to a 1180 particular characteristic of the underlying L2 LPWAN technology, e.g. 1181 the No-ACK mode MAY be used on top of an L2 LPWAN technology with 1182 symmetric characteristics for uplink and downlink. This document 1183 does not make any decision as to which SCHC Fragment reliability 1184 modes are relevant for a specific LPWAN technology. 1186 Examples of the different reliability modes described are provided in 1187 Appendix B. 1189 8.4. Fragmentation Formats 1191 This section defines the SCHC Fragment format, including the All-0 1192 and All-1 formats and their "empty" variations, the SCHC ACK format 1193 and the Abort formats. 1195 A SCHC Fragment conforms to the general format shown in Figure 11. 1196 It comprises a SCHC Fragment Header and a SCHC Fragment Payload. In 1197 addition, the last SCHC Fragment carries as many padding bits as 1198 needed to fill up an L2 Word. The SCHC Fragment Payload carries a 1199 subset of the SCHC Packet. The SCHC Fragment is the data unit passed 1200 on to the L2 for transmission. 1202 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1203 | Fragment Header | Fragment payload | padding (as needed) 1204 +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ 1206 Figure 11: SCHC Fragment general format. Presence of a padding field 1207 is optional 1209 8.4.1. Fragments that are not the last one 1211 In ACK-Always or ACK-on-Error, SCHC Fragments except the last one 1212 SHALL conform to the detailed format defined in Figure 12. 1214 |----- Fragment Header -----| 1215 |-- T --|1|-- N --| 1216 +-- ... --+- ... -+-+- ... -+--------...-------+ 1217 | Rule ID | DTag |W| FCN | Fragment payload | 1218 +-- ... --+- ... -+-+- ... -+--------...-------+ 1220 Figure 12: Fragment Detailed Format for Fragments except the Last 1221 One, ACK-Always and ACK-on-Error 1223 In the No-ACK mode, SCHC Fragments except the last one SHALL conform 1224 to the detailed format defined in Figure 13. 1226 |---- Fragment Header ----| 1227 |-- T --|-- N --| 1228 +-- ... --+- ... -+- ... -+--------...-------+ 1229 | Rule ID | DTag | FCN | Fragment payload | 1230 +-- ... --+- ... -+- ... -+--------...-------+ 1232 Figure 13: Fragment Detailed Format for Fragments except the Last 1233 One, No-ACK mode 1235 The total size of the fragment header is not necessarily a multiple 1236 of the L2 Word size. To build the fragment payload, SCHC F/R MUST 1237 take from the SCHC Packet a number of bits that makes the SCHC 1238 Fragment an exact multiple of L2 Words. As a consequence, no padding 1239 bit is used for these fragments. 1241 8.4.1.1. All-0 fragment 1243 The All-0 format is used for sending the last SCHC Fragment of a 1244 window that is not the last window of the SCHC Packet. 1246 |----- Fragment Header -----| 1247 |-- T --|1|-- N --| 1248 +-- ... --+- ... -+-+- ... -+--------...-------+ 1249 | Rule ID | DTag |W| 0..0 | Fragment payload | 1250 +-- ... --+- ... -+-+- ... -+--------...-------+ 1252 Figure 14: All-0 fragment detailed format 1254 This is simply an instance of the format described in Figure 12. An 1255 All-0 fragment payload MUST be at least the size of an L2 Word. The 1256 rationale is that the All-0 empty fragment (see Section 8.4.1.2) 1257 needs to be distinguishable from the All-0 regular fragment, even in 1258 the presence of padding. 1260 8.4.1.2. All-0 empty fragment 1262 The All-0 empty fragment is an exception to the All-0 fragment 1263 described above. It is used by a sender to request the 1264 retransmission of a SCHC ACK by the receiver. It is only used in 1265 ACK-Always mode. 1267 |----- Fragment Header -----| 1268 |-- T --|1|-- N --| 1269 +-- ... --+- ... -+-+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1270 | Rule ID | DTag |W| 0..0 | padding (as needed) (no payload) 1271 +-- ... --+- ... -+-+- ... -+~~~~~~~~~~~~~~~~~~~~~ 1273 Figure 15: All-0 empty fragment detailed format 1275 The size of the All-0 fragment header is generally not a multiple of 1276 the L2 Word size. Therefore, an All-0 empty fragment generally needs 1277 padding bits. The padding bits are always less than an L2 Word. 1279 Since an All-0 payload MUST be at least the size of an L2 Word, a 1280 receiver can distinguish an All-0 empty fragment from a regular All-0 1281 fragment, even in the presence of padding. 1283 8.4.2. All-1 fragment 1285 In the No-ACK mode, the last SCHC Fragment of a SCHC Packet SHALL 1286 contain a SCHC Fragment header that conforms to the detailed format 1287 shown in Figure 16. 1289 |---------- Fragment Header ----------| 1290 |-- T --|-N=1-| 1291 +---- ... ---+- ... -+-----+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ 1292 | Rule ID | DTag | 1 | MIC | payload | padding (as needed) 1293 +---- ... ---+- ... -+-----+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ 1295 Figure 16: All-1 Fragment Detailed Format for the Last Fragment, No- 1296 ACK mode 1298 In ACK-Always or ACK-on-Error mode, the last fragment of a SCHC 1299 Packet SHALL contain a SCHC Fragment header that conforms to the 1300 detailed format shown in Figure 17. 1302 |---------- Fragment Header ----------| 1303 |-- T --|1|-- N --| 1304 +-- ... --+- ... -+-+- ... -+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ 1305 | Rule ID | DTag |W| 11..1 | MIC | payload | padding (as needed) 1306 +-- ... --+- ... -+-+- ... -+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ 1307 (FCN) 1309 Figure 17: All-1 Fragment Detailed Format for the Last Fragment, ACK- 1310 Always or ACK-on-Error 1312 The total size of the All-1 SCHC Fragment header is generally not a 1313 multiple of the L2 Word size. The All-1 fragment being the last one 1314 of the SCHC Packet, SCHC F/R cannot freely choose the payload size to 1315 align the fragment to an L2 Word. Therefore, padding bits are 1316 generally appended to the All-1 fragment to make it a multiple of L2 1317 Words in size. 1319 The MIC MUST be computed on the payload and the padding bits. The 1320 rationale is that the SCHC Reassembler needs to check the correctness 1321 of the reassembled SCHC packet but has no way of knowing where the 1322 payload ends. Indeed, the latter requires decompressing the SCHC 1323 Packet. 1325 An All-1 fragment payload MUST be at least the size of an L2 Word. 1326 The rationale is that the All-1 empty fragment (see Section 8.4.2.1) 1327 needs to be distinguishable from the All-1 fragment, even in the 1328 presence of padding. This may entail saving an L2 Word from the 1329 previous fragment payload to make the payload of this All-1 fragment 1330 big enough. 1332 The values for N, T and the length of MIC are not specified in this 1333 document, and SHOULD be determined in other documents (e.g. 1334 technology-specific profile documents). 1336 The length of the MIC MUST be at least an L2 Word size. The 1337 rationale is to be able to distinguish a Sender-Abort (see 1338 Section 8.4.4) from an All-1 Fragment, even in the presence of 1339 padding. 1341 8.4.2.1. All-1 empty fragment 1343 The All-1 empty fragment format is an All-1 fragment format without a 1344 payload (see Figure 18). It is used by a fragment sender, in either 1345 ACK-Always or ACK-on-Error, to request a retransmission of the SCHC 1346 ACK for the All-1 window. 1348 The size of the All-1 empty fragment header is generally not a 1349 multiple of the L2 Word size. Therefore, an All-1 empty fragment 1350 generally needs padding bits. The padding bits are always less than 1351 an L2 Word. 1353 Since an All-1 payload MUST be at least the size of an L2 Word, a 1354 receiver can distinguish an All-1 empty fragment from a regular All-1 1355 fragment, even in the presence of padding. 1357 |---------- Fragment Header --------| 1358 |-- T --|1|-- N --| 1359 +-- ... --+- ... -+-+- ... -+- ... -+~~~~~~~~~~~~~~~~~~~ 1360 | Rule ID | DTag |W| 1..1 | MIC | padding as needed (no payload) 1361 +-- ... --+- ... -+-+- ... -+- ... -+~~~~~~~~~~~~~~~~~~~ 1363 Figure 18: All-1 for Retries format, also called All-1 empty 1365 8.4.3. SCHC ACK format 1367 The format of a SCHC ACK that acknowledges a window that is not the 1368 last one (denoted as All-0 window) is shown in Figure 19. 1370 |-- T --|1| 1371 +---- ... --+- ... -+-+---- ... -----+ 1372 | Rule ID | DTag |W|encoded Bitmap| (no payload) 1373 +---- ... --+- ... -+-+---- ... -----+ 1375 Figure 19: ACK format for All-0 windows 1377 To acknowledge the last window of a packet (denoted as All-1 window), 1378 a C bit (i.e. MIC checked) following the W bit is set to 1 to 1379 indicate that the MIC check computed by the receiver matches the MIC 1380 present in the All-1 fragment. If the MIC check fails, the C bit is 1381 set to 0 and the Bitmap for the All-1 window follows. 1383 |-- T --|1|1| 1384 +---- ... --+- ... -+-+-+ 1385 | Rule ID | DTag |W|1| (MIC correct) 1386 +---- ... --+- ... -+-+-+ 1388 +---- ... --+- ... -+-+-+----- ... -----+ 1389 | Rule ID | DTag |W|0|encoded Bitmap |(MIC Incorrect) 1390 +---- ... --+- ... -+-+-+----- ... -----+ 1391 C 1393 Figure 20: Format of a SCHC ACK for All-1 windows 1395 The Rule ID and Dtag values in the SCHC ACK messages MUST be 1396 identical to the ones used in the SCHC Fragments that are being 1397 acknowledged. This allows matching the SCHC ACK and the 1398 corresponding SCHC Fragments. 1400 The Bitmap carries information on the reception of each fragment of 1401 the window as described in Section 8.2. 1403 See Appendix D for a discussion on the size of the Bitmaps. 1405 In order to reduce the SCK ACK size, the Bitmap that is actually 1406 transmitted is shortened ("encoded") as explained in Section 8.4.3.1. 1408 8.4.3.1. Bitmap Encoding 1410 The SCHC ACK that is transmitted is truncated by applying the 1411 following algorithm: the longest contiguous sequence of bits that 1412 starts at an L2 Word boundary of the SCHC ACK, where the bits of that 1413 sequence are all set to 1, are all part of the Bitmap and finish 1414 exactly at the end of the Bitmap, if one such sequence exists, MUST 1415 NOT be transmitted. Because the SCHC Fragment sender knows the 1416 actual Bitmap size, it can reconstruct the original Bitmap from the 1417 shortened bitmap. 1419 When shortening effectively takes place, the SCHC ACK is a multiple 1420 of L2 Words, and padding MUST NOT be appended. When shortening does 1421 not happen, padding bits MUST be appended as needed to fill up the 1422 last L2 Word. 1424 Figure 21 shows an example where L2 Words are actually bytes and 1425 where the original Bitmap contains 17 bits, the last 15 of which are 1426 all set to 1. 1428 |-- SCHC ACK Header --|-------- Bitmap --------| 1429 | Rule ID | DTag |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| 1430 next L2 Word boundary ->| next L2 Word | next L2 Word | 1432 Figure 21: A non-encoded Bitmap 1434 Figure 22 shows that the last 14 bits are not sent. 1436 |-- T --|1| 1437 +---- ... --+- ... -+-+-+-+-+ 1438 | Rule ID | DTag |W|1|0|1| 1439 +---- ... --+- ... -+-+-+-+-+ 1440 next L2 Word boundary ->| 1442 Figure 22: Optimized Bitmap format 1444 Figure 23 shows an example of a SCHC ACK with FCN ranging from 6 down 1445 to 0, where the Bitmap indicates that the second and the fifth SCHC 1446 Fragments have not been correctly received. 1448 6 5 4 3 2 1 0 (*) 1449 |-- T --|1| 1450 +-----------+-------+-+-+-+-+-+-+-+-+ 1451 | Rule ID | DTag |W|1|0|1|1|0|1|1| Bitmap before tx 1452 +-----------+-------+-+-+-+-+-+-+-+-+ 1453 next L2 Word boundary ->|<-- L2 Word -->| 1454 (*)=(FCN values) 1456 +-----------+-------+-+-+-+-+-+-+-+-+~~~+ 1457 | Rule ID | DTag |W|1|0|1|1|0|1|1|Pad| Encoded Bitmap 1458 +-----------+-------+-+-+-+-+-+-+-+-+~~~+ 1459 next L2 Word boundary ->|<-- L2 Word -->| 1461 Figure 23: Example of a Bitmap before transmission, and the 1462 transmitted one, for a window that is not the last one 1464 Figure 24 shows an example of a SCHC ACK with FCN ranging from 6 down 1465 to 0, where MIC check has failed but the Bitmap indicates that there 1466 is no missing SCHC Fragment. 1468 |- Fragmentation Header-|6 5 4 3 2 1 7 (*) 1469 |-- T --|1| 1470 | Rule ID | DTag |W|0|1|1|1|1|1|1|1| Bitmap before tx 1471 next L2 Word boundary ->|<-- L2 Word -->| 1472 C 1473 +---- ... --+- ... -+-+-+-+ 1474 | Rule ID | DTag |W|0|1| Encoded Bitmap 1475 +---- ... --+- ... -+-+-+-+ 1476 next L2 Word boundary ->| 1477 (*) = (FCN values indicating the order) 1479 Figure 24: Example of the Bitmap in ACK-Always or ACK-on-Error for 1480 the last window 1482 8.4.4. Abort formats 1484 When a SCHC Fragment sender needs to abort the on-going fragmented 1485 SCHC Packet transmission, it sends a Sender-Abort. The Sender-Abort 1486 format (see Figure 25) is a variation of the All-1 fragment, with 1487 neither a MIC nor a payload. All-1 fragments contain at least a MIC. 1488 The absence of the MIC indicates a Sender-Abort. 1490 |--- Sender-Abort Header ---| 1491 +--- ... ---+- ... -+-+-...-+~~~~~~~~~~~~~~~~~~~~~ 1492 | Rule ID | DTag |W| FCN | padding (as needed) 1493 +--- ... ---+- ... -+-+-...-+~~~~~~~~~~~~~~~~~~~~~ 1495 Figure 25: Sender-Abort format. All FCN field bits in this format 1496 are set to 1 1498 The size of the Sender-Abort header is generally not a multiple of 1499 the L2 Word size. Therefore, a Sender-Abort generally needs padding 1500 bits. 1502 Since an All-1 fragment MIC MUST be at least the size of an L2 Word, 1503 a receiver can distinguish a Sender-Abort from an All-1 fragment, 1504 even in the presence of padding. 1506 When a SCHC Fragment receiver needs to abort the on-going fragmented 1507 SCHC Packet transmission, it transmits a Receiver-Abort. The 1508 Receiver-Abort format is a variation on the SCHC ACK format, creating 1509 an exception in the encoded Bitmap algorithm. As shown in Figure 26, 1510 a Receiver-Abort is coded as a SCHC ACK message with a shortened 1511 Bitmap set to 1 up to the first L2 Word boundary, followed by an 1512 extra L2 Word full of 1's. Such a message never occurs in a regular 1513 acknowledgement and is detected as a Receiver-Abort. 1515 The Rule ID and Dtag values in the Receive-Abort message MUST be 1516 identical to the ones used in the fragments of the SCHC Packet the 1517 transmission of which is being aborted. 1519 A Receiver-Abort is aligned to L2 Words, by design. Therefore, 1520 padding MUST not be appended. 1522 |- Receiver-Abort Header -| 1524 +---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Rule ID | DTag |W| 1..1| 1..1 | 1526 +---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 next L2 Word boundary ->|<-- L2 Word -->| 1529 Figure 26: Receiver-Abort format 1531 Neither the Sender-Abort nor the Receiver-Abort messages are ever 1532 acknowledged or retransmitted. 1534 Use cases for the Sender-Abort and Receiver-Abort messages are 1535 explained in Section 8.5 or Appendix C. 1537 8.5. Baseline mechanism 1539 If after applying SCHC header compression (or when SCHC header 1540 compression is not possible) the SCHC Packet does not fit within the 1541 payload of a single L2 data unit, the SCHC Packet SHALL be broken 1542 into SCHC Fragments and the fragments SHALL be sent to the fragment 1543 receiver. The fragment receiver needs to identify all the SCHC 1544 Fragments that belong to a given SCHC Packet. To this end, the 1545 receiver SHALL use: 1547 o The sender's L2 source address (if present), 1549 o The destination's L2 address (if present), 1551 o Rule ID, 1553 o DTag (if present). 1555 Then, the fragment receiver MAY determine the SCHC Fragment 1556 reliability mode that is used for this SCHC Fragment based on the 1557 Rule ID in that fragment. 1559 After a SCHC Fragment reception, the receiver starts constructing the 1560 SCHC Packet. It uses the FCN and the arrival order of each SCHC 1561 Fragment to determine the location of the individual fragments within 1562 the SCHC Packet. For example, the receiver MAY place the fragment 1563 payload within a payload reassembly buffer at the location determined 1564 from the FCN, the arrival order of the SCHC Fragments, and the 1565 fragment payload sizes. In ACK-on-Error or ACK-Always, the fragment 1566 receiver also uses the W bit in the received SCHC Fragments. Note 1567 that the size of the original, unfragmented packet cannot be 1568 determined from fragmentation headers. 1570 Fragmentation functionality uses the FCN value to transmit the SCHC 1571 Fragments. It has a length of N bits where the All-1 and All-0 FCN 1572 values are used to control the fragmentation transmission. The rest 1573 of the FCN numbers MUST be assigned sequentially in a decreasing 1574 order, the first FCN of a window is RECOMMENDED to be MAX_WIND_FCN, 1575 i.e. the highest possible FCN value depending on the FCN number of 1576 bits. 1578 In all modes, the last SCHC Fragment of a packet MUST contain a MIC 1579 which is used to check if there are errors or missing SCHC Fragments 1580 and MUST use the corresponding All-1 fragment format. Note that a 1581 SCHC Fragment with an All-0 format is considered the last SCHC 1582 Fragment of the current window. 1584 If the receiver receives the last fragment of a SCHC Packet (All-1), 1585 it checks for the integrity of the reassembled SCHC Packet, based on 1586 the MIC received. In No-ACK, if the integrity check indicates that 1587 the reassembled SCHC Packet does not match the original SCHC Packet 1588 (prior to fragmentation), the reassembled SCHC Packet MUST be 1589 discarded. In ACK-on-Error or ACK-Always, a MIC check is also 1590 performed by the fragment receiver after reception of each subsequent 1591 SCHC Fragment retransmitted after the first MIC check. 1593 Notice that the SCHC ACK for the All-1 window carries one more bit 1594 (the C bit) compared to the SCHC ACKs for the previous windows. See 1595 Appendix D for a discussion on various options to deal with this 1596 "bump" in the SCHC ACK. 1598 There are three reliability modes: No-ACK, ACK-Always and ACK-on- 1599 Error. In ACK-Always and ACK-on-Error, a jumping window protocol 1600 uses two windows alternatively, identified as 0 and 1. A SCHC 1601 Fragment with all FCN bits set to 0 (i.e. an All-0 fragment) 1602 indicates that the window is over (i.e. the SCHC Fragment is the last 1603 one of the window) and allows to switch from one window to the next 1604 one. The All-1 FCN in a SCHC Fragment indicates that it is the last 1605 fragment of the packet being transmitted and therefore there will not 1606 be another window for this packet. 1608 8.5.1. No-ACK 1610 In the No-ACK mode, there is no feedback communication from the 1611 fragment receiver. The sender will send all the SCHC fragments of a 1612 packet without any possibility of knowing if errors or losses have 1613 occurred. As, in this mode, there is no need to identify specific 1614 SCHC Fragments, a one-bit FCN MAY be used. Consequently, the FCN 1615 All-0 value is used in all SCHC fragments except the last one, which 1616 carries an All-1 FCN and the MIC. The receiver will wait for SCHC 1617 Fragments and will set the Inactivity timer. The receiver will use 1618 the MIC contained in the last SCHC Fragment to check for errors. 1619 When the Inactivity Timer expires or if the MIC check indicates that 1620 the reassembled packet does not match the original one, the receiver 1621 will release all resources allocated to reassembling this packet. 1622 The initial value of the Inactivity Timer will be determined based on 1623 the characteristics of the underlying LPWAN technology and will be 1624 defined in other documents (e.g. technology-specific profile 1625 documents). 1627 8.5.2. ACK-Always 1629 In ACK-Always, the sender transmits SCHC Fragments by using the two- 1630 jumping-windows procedure. A delay between each SCHC fragment can be 1631 added to respect local regulations or other constraints imposed by 1632 the applications. Each time a SCHC fragment is sent, the FCN is 1633 decreased by one. When the FCN reaches value 0, if there are more 1634 SCHC Fragments remaining to be sent, the sender transmits the last 1635 SCHC Fragment of this window using the All-0 fragment format. It 1636 then starts the Retransmission Timer and waits for a SCHC ACK. 1637 Otherwise, if FCN reaches 0 and the sender transmits the last SCHC 1638 Fragment of the SCHC Packet, the sender uses the All-1 fragment 1639 format, which includes a MIC. The sender sets the Retransmission 1640 Timer and waits for the SCHC ACK to know if transmission errors have 1641 occurred. 1643 The Retransmission Timer is dimensioned based on the LPWAN technology 1644 in use. When the Retransmission Timer expires, the sender sends an 1645 All-0 empty (resp. All-1 empty) fragment to request again the SCHC 1646 ACK for the window that ended with the All-0 (resp. All-1) fragment 1647 just sent. The window number is not changed. 1649 After receiving an All-0 or All-1 fragment, the receiver sends a SCHC 1650 ACK with an encoded Bitmap reporting whether any SCHC fragments have 1651 been lost or not. When the sender receives a SCHC ACK, it checks the 1652 W bit carried by the SCHC ACK. Any SCHC ACK carrying an unexpected W 1653 bit value is discarded. If the W bit value of the received SCHC ACK 1654 is correct, the sender analyzes the rest of the SCHC ACK message, 1655 such as the encoded Bitmap and the MIC. If all the SCHC Fragments 1656 sent for this window have been well received, and if at least one 1657 more SCHC Fragment needs to be sent, the sender advances its sending 1658 window to the next window value and sends the next SCHC Fragments. 1659 If no more SCHC Fragments have to be sent, then the fragmented SCHC 1660 Packet transmission is finished. 1662 However, if one or more SCHC Fragments have not been received as per 1663 the SCHC ACK (i.e. the corresponding bits are not set in the encoded 1664 Bitmap) then the sender resends the missing SCHC Fragments. When all 1665 missing SCHC Fragments have been retransmitted, the sender starts the 1666 Retransmission Timer, even if an All-0 or an All-1 has not been sent 1667 as part of this retransmission and waits for a SCHC ACK. Upon 1668 receipt of the SCHC ACK, if one or more SCHC Fragments have not yet 1669 been received, the counter Attempts is increased and the sender 1670 resends the missing SCHC Fragments again. When Attempts reaches 1671 MAX_ACK_REQUESTS, the sender aborts the on-going fragmented SCHC 1672 Packet transmission by sending a Sender-Abort message and releases 1673 any resources for transmission of the packet. The sender also aborts 1674 an on-going fragmented SCHC Packet transmission when a failed MIC 1675 check is reported by the receiver or when a SCHC Fragment that has 1676 not been sent is reported in the encoded Bitmap. 1678 On the other hand, at the beginning, the receiver side expects to 1679 receive window 0. Any SCHC Fragment received but not belonging to 1680 the current window is discarded. All SCHC Fragments belonging to the 1681 correct window are accepted, and the actual SCHC Fragment number 1682 managed by the receiver is computed based on the FCN value. The 1683 receiver prepares the encoded Bitmap to report the correctly received 1684 and the missing SCHC Fragments for the current window. After each 1685 SCHC Fragment is received, the receiver initializes the Inactivity 1686 Timer. When the Inactivity Timer expires, the transmission is 1687 aborted by the receiver sending a Receiver-Abort message. 1689 When an All-0 fragment is received, it indicates that all the SCHC 1690 Fragments have been sent in the current window. Since the sender is 1691 not obliged to always send a full window, some SCHC Fragment number 1692 not set in the receiver memory SHOULD not correspond to losses. The 1693 receiver sends the corresponding SCHC ACK, the Inactivity Timer is 1694 set and the transmission of the next window by the sender can start. 1696 If an All-0 fragment has been received and all SCHC Fragments of the 1697 current window have also been received, the receiver then expects a 1698 new Window and waits for the next SCHC Fragment. Upon receipt of a 1699 SCHC Fragment, if the window value has not changed, the received SCHC 1700 Fragments are part of a retransmission. A receiver that has already 1701 received a SCHC Fragment SHOULD discard it, otherwise, it updates the 1702 encoded Bitmap. If all the bits of the encoded Bitmap are set to 1703 one, the receiver MUST send a SCHC ACK without waiting for an All-0 1704 fragment and the Inactivity Timer is initialized. 1706 On the other hand, if the window value of the next received SCHC 1707 Fragment is set to the next expected window value, this means that 1708 the sender has received a correct encoded Bitmap reporting that all 1709 SCHC Fragments have been received. The receiver then updates the 1710 value of the next expected window. 1712 When an All-1 fragment is received, it indicates that the last SCHC 1713 Fragment of the packet has been sent. Since the last window is not 1714 always full, the MIC will be used by the receiver to detect if all 1715 SCHC Fragments of the packet have been received. A correct MIC 1716 indicates the end of the transmission but the receiver MUST stay 1717 alive for an Inactivity Timer period to answer to any empty All-1 1718 fragments the sender MAY send if SCHC ACKs sent by the receiver are 1719 lost. If the MIC is incorrect, some SCHC Fragments have been lost. 1720 The receiver sends the SCHC ACK regardless of successful fragmented 1721 SCHC Packet reception or not, the Inactitivity Timer is set. In case 1722 of an incorrect MIC, the receiver waits for SCHC Fragments belonging 1723 to the same window. After MAX_ACK_REQUESTS, the receiver will abort 1724 the on-going fragmented SCHC Packet transmission by transmitting a 1725 the Receiver-Abort format. The receiver also aborts upon Inactivity 1726 Timer expiration by sending a Receiver-Abort message. 1728 If the sender receives a SCK ACK with a Bitmap containing a bit set 1729 for a SCHC Fragment that it has not sent during the transmission 1730 phase of this window, it MUST abort the whole fragmentation and 1731 transmission of this SCHC Packet. 1733 8.5.3. ACK-on-Error 1735 The senders behavior for ACK-on-Error and ACK-Always are similar. 1736 The main difference is that in ACK-on-Error the SCHC ACK with the 1737 encoded Bitmap is not sent at the end of each window but only when at 1738 least one SCHC Fragment of the current window has been lost. Except 1739 for the last window where a SCHC ACK MUST be sent to finish the 1740 transmission. 1742 In ACK-on-Error, the Retransmission Timer expiration is considered as 1743 a positive acknowledgement for all windows but the last one. This 1744 timer is set after sending an All-0 or an All-1 fragment. For an 1745 All-0 fragment, on timer expiration, the sender resumes operation and 1746 sends the SCHC Fragments of the next window. 1748 If the sender receives a SCHC ACK, it checks the window value. SCHC 1749 ACKs with an unexpected window number are discarded. If the window 1750 number on the received encoded Bitmap is correct, the sender verifies 1751 if the receiver has received all SCHC fragments of the current 1752 window. When at least one SCHC Fragment has been lost, the counter 1753 Attempts is increased by one and the sender resends the missing SCHC 1754 Fragments again. When Attempts reaches MAX_ACK_REQUESTS, the sender 1755 sends a Sender-Abort message and releases all resources for the on- 1756 going fragmented SCHC Packet transmission. When the retransmission 1757 of the missing SCHC Fragments is finished, the sender starts 1758 listening for a SCHC ACK (even if an All-0 or an All-1 has not been 1759 sent during the retransmission) and initializes the Retransmission 1760 Timer. 1762 After sending an All-1 fragment, the sender listens for a SCHC ACK, 1763 initializes Attempts, and starts the Retransmission Timer. If the 1764 Retransmission Timer expires, Attempts is increased by one and an 1765 empty All-1 fragment is sent to request the SCHC ACK for the last 1766 window. If Attempts reaches MAX_ACK_REQUESTS, the sender aborts the 1767 on-going fragmented SCHC Packet transmission by transmitting the 1768 Sender-Abort fragment. 1770 At the end of any window, if the sender receives a SCK ACK with a 1771 Bitmap containing a bit set for a SCHC Fragment that it has not sent 1772 during the transmission phase of that window, it MUST abort the whole 1773 fragmentation and transmission of this SCHC Packet. 1775 Unlike the sender, the receiver for ACK-on-Error has a larger amount 1776 of differences compared with ACK-Always. First, a SCHC ACK is not 1777 sent unless there is a lost SCHC Fragment or an unexpected behavior. 1778 With the exception of the last window, where a SCHC ACK is always 1779 sent regardless of SCHC Fragment losses or not. The receiver starts 1780 by expecting SCHC Fragments from window 0 and maintains the 1781 information regarding which SCHC Fragments it receives. After 1782 receiving a SCHC Fragment, the Inactivity Timer is set. If no 1783 further SCHC Fragment are received and the Inactivity Timer expires, 1784 the SCHC Fragment receiver aborts the on-going fragmented SCHC Packet 1785 transmission by transmitting the Receiver-Abort data unit. 1787 Any SCHC Fragment not belonging to the current window is discarded. 1788 The actual SCHC Fragment number is computed based on the FCN value. 1789 When an All-0 fragment is received and all SCHC Fragments have been 1790 received, the receiver updates the expected window value and expects 1791 a new window and waits for the next SCHC Fragment. 1792 If the window value of the next SCHC Fragment has not changed, the 1793 received SCHC Fragment is a retransmission. A receiver that has 1794 already received a Fragment discard it. If all SCHC Fragments of a 1795 window (that is not the last one) have been received, the receiver 1796 does not send a SCHC ACK. While the receiver waits for the next 1797 window and if the window value is set to the next value, and if an 1798 All-1 fragment with the next value window arrived the receiver knows 1799 that the last SCHC Fragment of the packet has been sent. Since the 1800 last window is not always full, the MIC will be used to detect if all 1801 SCHC Fragments of the window have been received. A correct MIC check 1802 indicates the end of the fragmented SCHC Packet transmission. An ACK 1803 is sent by the SCHC Fragment receiver. In case of an incorrect MIC, 1804 the receiver waits for SCHC Fragments belonging to the same window or 1805 the expiration of the Inactivity Timer. The latter will lead the 1806 receiver to abort the on-going SCHC fragmented packet transmission by 1807 transmitting the Receiver-Abort message. 1809 If, after receiving an All-0 fragment the receiver missed some SCHC 1810 Fragments, the receiver uses a SCHC ACK with the encoded Bitmap to 1811 ask the retransmission of the missing fragments and expect to receive 1812 SCHC Fragments with the actual window. While waiting the 1813 retransmission an All-0 empty fragment is received, the receiver 1814 sends again the SCHC ACK with the encoded Bitmap, if the SCHC 1815 Fragments received belongs to another window or an All-1 fragment is 1816 received, the transmission is aborted by sending a Receiver-Abort 1817 fragment. Once it has received all the missing fragments it waits 1818 for the next window fragments. 1820 8.6. Supporting multiple window sizes 1822 For ACK-Always or ACK-on-Error, implementers MAY opt to support a 1823 single window size or multiple window sizes. The latter, when 1824 feasible, may provide performance optimizations. For example, a 1825 large window size SHOULD be used for packets that need to be carried 1826 by a large number of SCHC Fragments. However, when the number of 1827 SCHC Fragments required to carry a packet is low, a smaller window 1828 size, and thus a shorter Bitmap, MAY be sufficient to provide 1829 feedback on all SCHC Fragments. If multiple window sizes are 1830 supported, the Rule ID MAY be used to signal the window size in use 1831 for a specific packet transmission. 1833 Note that the same window size MUST be used for the transmission of 1834 all SCHC Fragments that belong to the same SCHC Packet. 1836 8.7. Downlink SCHC Fragment transmission 1838 In some LPWAN technologies, as part of energy-saving techniques, 1839 downlink transmission is only possible immediately after an uplink 1840 transmission. In order to avoid potentially high delay in the 1841 downlink transmission of a fragmented SCHC Packet, the SCHC Fragment 1842 receiver MAY perform an uplink transmission as soon as possible after 1843 reception of a SCHC Fragment that is not the last one. Such uplink 1844 transmission MAY be triggered by the L2 (e.g. an L2 ACK sent in 1845 response to a SCHC Fragment encapsulated in a L2 frame that requires 1846 an L2 ACK) or it MAY be triggered from an upper layer. 1848 For downlink transmission of a fragmented SCHC Packet in ACK-Always 1849 mode, the SCHC Fragment receiver MAY support timer-based SCHC ACK 1850 retransmission. In this mechanism, the SCHC Fragment receiver 1851 initializes and starts a timer (the Inactivity Timer is used) after 1852 the transmission of a SCHC ACK, except when the SCHC ACK is sent in 1853 response to the last SCHC Fragment of a packet (All-1 fragment). In 1854 the latter case, the SCHC Fragment receiver does not start a timer 1855 after transmission of the SCHC ACK. 1857 If, after transmission of a SCHC ACK that is not an All-1 fragment, 1858 and before expiration of the corresponding Inactivity timer, the SCHC 1859 Fragment receiver receives a SCHC Fragment that belongs to the 1860 current window (e.g. a missing SCHC Fragment from the current window) 1861 or to the next window, the Inactivity timer for the SCHC ACK is 1862 stopped. However, if the Inactivity timer expires, the SCHC ACK is 1863 resent and the Inactivity timer is reinitialized and restarted. 1865 The default initial value for the Inactivity timer, as well as the 1866 maximum number of retries for a specific SCHC ACK, denoted 1867 MAX_ACK_RETRIES, are not defined in this document, and need to be 1868 defined in other documents (e.g. technology-specific profiles). The 1869 initial value of the Inactivity timer is expected to be greater than 1870 that of the Retransmission timer, in order to make sure that a 1871 (buffered) SCHC Fragment to be retransmitted can find an opportunity 1872 for that transmission. 1874 When the SCHC Fragment sender transmits the All-1 fragment, it starts 1875 its Retransmission Timer with a large timeout value (e.g. several 1876 times that of the initial Inactivity timer). If a SCHC ACK is 1877 received before expiration of this timer, the SCHC Fragment sender 1878 retransmits any lost SCHC Fragments reported by the SCHC ACK, or if 1879 the SCHC ACK confirms successful reception of all SCHC Fragments of 1880 the last window, the transmission of the fragmented SCHC Packet is 1881 considered complete. If the timer expires, and no SCHC ACK has been 1882 received since the start of the timer, the SCHC Fragment sender 1883 assumes that the All-1 fragment has been successfully received (and 1884 possibly, the last SCHC ACK has been lost: this mechanism assumes 1885 that the retransmission timer for the All-1 fragment is long enough 1886 to allow several SCHC ACK retries if the All-1 fragment has not;been 1887 received by the SCHC Fragment receiver, and it also assumes that it 1888 is unlikely that several ACKs become all lost). 1890 9. Padding management 1892 SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does 1893 not have any alignment prerequisite. If the Layer 2 below SCHC 1894 constrains the L2 Data Unit to align to some boundary, called L2 1895 Words (for example, bytes), SCHC will meet that constraint and 1896 produce messages with the correct alignement. This may entail adding 1897 extra bits (called padding bits). 1899 When padding occurs, the number of appended bits is strictly less 1900 than the L2 Word size. 1902 Padding happens at most once for each Packet going through the full 1903 SCHC chain, i.e. Compression and (optionally) SCHC Fragmentation (see 1904 Figure 2). If a SCHC Packet is sent unfragmented (see Figure 27), it 1905 is padded as needed. If a SCHC Packet is fragmented, only the last 1906 fragment is padded as needed. 1908 A packet (e.g. an IPv6 packet) 1909 | ^ (padding bits 1910 v | dropped) 1911 +------------------+ +--------------------+ 1912 | SCHC Compression | | SCHC Decompression | 1913 +------------------+ +--------------------+ 1914 | ^ 1915 | If no fragmentation | 1916 +---- SCHC Packet + padding as needed ----->| 1917 | | (MIC checked 1918 v | and removed) 1919 +--------------------+ +-----------------+ 1920 | SCHC Fragmentation | | SCHC Reassembly | 1921 +--------------------+ +-----------------+ 1922 | ^ | ^ 1923 | | | | 1924 | +------------- SCHC ACK ------------+ | 1925 | | 1926 +--------------- SCHC Fragments --------------------+ 1927 +--- last SCHC Frag with MIC + padding as needed ---+ 1929 SENDER RECEIVER 1931 Figure 27: SCHC operations, including padding as needed 1933 Each technology-specific document MUST specify the size of the L2 1934 Word. The L2 Word might actually be a single bit, in which case at 1935 most zero bits of padding will be appended to any message, i.e. no 1936 padding will take place at all. 1938 10. SCHC Compression for IPv6 and UDP headers 1940 This section lists the different IPv6 and UDP header fields and how 1941 they can be compressed. 1943 10.1. IPv6 version field 1945 This field always holds the same value. Therefore, in the Rule, TV 1946 is set to 6, MO to "equal" and CDA to "not-sent". 1948 10.2. IPv6 Traffic class field 1950 If the DiffServ field does not vary and is known by both sides, the 1951 Field Descriptor in the Rule SHOULD contain a TV with this well-known 1952 value, an "equal" MO and a "not-sent" CDA. 1954 Otherwise, two possibilities can be considered depending on the 1955 variability of the value: 1957 o One possibility is to not compress the field and send the original 1958 value. In the Rule, TV is not set to any particular value, MO is 1959 set to "ignore" and CDA is set to "value-sent". 1961 o If some upper bits in the field are constant and known, a better 1962 option is to only send the LSBs. In the Rule, TV is set to a 1963 value with the stable known upper part, MO is set to MSB(x) and 1964 CDA to LSB(y). 1966 10.3. Flow label field 1968 If the Flow Label field does not vary and is known by both sides, the 1969 Field Descriptor in the Rule SHOULD contain a TV with this well-known 1970 value, an "equal" MO and a "not-sent" CDA. 1972 Otherwise, two possibilities can be considered: 1974 o One possibility is to not compress the field and send the original 1975 value. In the Rule, TV is not set to any particular value, MO is 1976 set to "ignore" and CDA is set to "value-sent". 1978 o If some upper bits in the field are constant and known, a better 1979 option is to only send the LSBs. In the Rule, TV is set to a 1980 value with the stable known upper part, MO is set to MSB(x) and 1981 CDA to LSB(y). 1983 10.4. Payload Length field 1985 This field can be elided for the transmission on the LPWAN network. 1986 The SCHC C/D recomputes the original payload length value. In the 1987 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 1988 "compute-IPv6-length". 1990 If the payload length needs to be sent and does not need to be coded 1991 in 16 bits, the TV can be set to 0x0000, the MO set to MSB(16-s) 1992 where 's' is the number of bits to code the maximum length, and CDA 1993 is set to LSB(s). 1995 10.5. Next Header field 1997 If the Next Header field does not vary and is known by both sides, 1998 the Field Descriptor in the Rule SHOULD contain a TV with this Next 1999 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 2000 sent". 2002 Otherwise, TV is not set in the Field Descriptor, MO is set to 2003 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 2004 list MAY also be used. 2006 10.6. Hop Limit field 2008 The field behavior for this field is different for Uplink and 2009 Downlink. In Uplink, since there is no IP forwarding between the Dev 2010 and the SCHC C/D, the value is relatively constant. On the other 2011 hand, the Downlink value depends of Internet routing and MAY change 2012 more frequently. One neat way of processing this field is to use the 2013 Direction Indicator (DI) to distinguish both directions: 2015 o in the Uplink, elide the field: the TV in the Field Descriptor is 2016 set to the known constant value, the MO is set to "equal" and the 2017 CDA is set to "not-sent". 2019 o in the Downlink, send the value: TV is not set, MO is set to 2020 "ignore" and CDA is set to "value-sent". 2022 10.7. IPv6 addresses fields 2024 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 2025 long fields; one for the prefix and one for the Interface Identifier 2026 (IID). These fields SHOULD be compressed. To allow for a single 2027 Rule being used for both directions, these values are identified by 2028 their role (DEV or APP) and not by their position in the frame 2029 (source or destination). 2031 10.7.1. IPv6 source and destination prefixes 2033 Both ends MUST be synchronized with the appropriate prefixes. For a 2034 specific flow, the source and destination prefixes can be unique and 2035 stored in the context. It can be either a link-local prefix or a 2036 global prefix. In that case, the TV for the source and destination 2037 prefixes contain the values, the MO is set to "equal" and the CDA is 2038 set to "not-sent". 2040 If the Rule is intended to compress packets with different prefix 2041 values, match-mapping SHOULD be used. The different prefixes are 2042 listed in the TV, the MO is set to "match-mapping" and the CDA is set 2043 to "mapping-sent". See Figure 29 2045 Otherwise, the TV contains the prefix, the MO is set to "equal" and 2046 the CDA is set to "value-sent". 2048 10.7.2. IPv6 source and destination IID 2050 If the DEV or APP IID are based on an LPWAN address, then the IID can 2051 be reconstructed with information coming from the LPWAN header. In 2052 that case, the TV is not set, the MO is set to "ignore" and the CDA 2053 is set to "DevIID" or "AppIID". Note that the LPWAN technology 2054 generally carries a single identifier corresponding to the DEV. 2055 Therefore AppIID cannot be used. 2057 For privacy reasons or if the DEV address is changing over time, a 2058 static value that is not equal to the DEV address SHOULD be used. In 2059 that case, the TV contains the static value, the MO operator is set 2060 to "equal" and the CDF is set to "not-sent". [RFC7217] provides some 2061 methods that MAY be used to derive this static identifier. 2063 If several IIDs are possible, then the TV contains the list of 2064 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 2065 "mapping-sent". 2067 It MAY also happen that the IID variability only expresses itself on 2068 a few bytes. In that case, the TV is set to the stable part of the 2069 IID, the MO is set to "MSB" and the CDA is set to "LSB". 2071 Finally, the IID can be sent in extenso on the LPWAN. In that case, 2072 the TV is not set, the MO is set to "ignore" and the CDA is set to 2073 "value-sent". 2075 10.8. IPv6 extensions 2077 No Rule is currently defined that processes IPv6 extensions. If such 2078 extensions are needed, their compression/decompression Rules can be 2079 based on the MOs and CDAs described above. 2081 10.9. UDP source and destination port 2083 To allow for a single Rule being used for both directions, the UDP 2084 port values are identified by their role (DEV or APP) and not by 2085 their position in the frame (source or destination). The SCHC C/D 2086 MUST be aware of the traffic direction (Uplink, Downlink) to select 2087 the appropriate field. The following Rules apply for DEV and APP 2088 port numbers. 2090 If both ends know the port number, it can be elided. The TV contains 2091 the port number, the MO is set to "equal" and the CDA is set to "not- 2092 sent". 2094 If the port variation is on few bits, the TV contains the stable part 2095 of the port number, the MO is set to "MSB" and the CDA is set to 2096 "LSB". 2098 If some well-known values are used, the TV can contain the list of 2099 these values, the MO is set to "match-mapping" and the CDA is set to 2100 "mapping-sent". 2102 Otherwise the port numbers are sent over the LPWAN. The TV is not 2103 set, the MO is set to "ignore" and the CDA is set to "value-sent". 2105 10.10. UDP length field 2107 The UDP length can be computed from the received data. In that case, 2108 the TV is not set, the MO is set to "ignore" and the CDA is set to 2109 "compute-length". 2111 If the payload is small, the TV can be set to 0x0000, the MO set to 2112 "MSB" and the CDA to "LSB". 2114 In other cases, the length SHOULD be sent and the CDA is replaced by 2115 "value-sent". 2117 10.11. UDP Checksum field 2119 The UDP checksum operation is mandatory with IPv6 [RFC8200] for most 2120 packets but recognizes that there are exceptions to that default 2121 behavior. 2123 For instance, protocols that use UDP as a tunnel encapsulation may 2124 enable zero-checksum mode for a specific port (or set of ports) for 2125 sending and/or receiving. [RFC8200] also stipulates that any node 2126 implementing zero-checksum mode must follow the requirements 2127 specified in "Applicability Statement for the Use of IPv6 UDP 2128 Datagrams with Zero Checksums" [RFC6936]. 2130 6LoWPAN Header Compression [RFC6282] also authorizes to send UDP 2131 datagram that are deprived of the checksum protection when an upper 2132 layer guarantees the integrity of the UDP payload and pseudo-header 2133 all the way between the compressor that elides the UDP checksum and 2134 the decompressor that computes again it. A specific example of this 2135 is when a Message Integrity Check (MIC) protects the compressed 2136 message all along that path with a strength that is identical or 2137 better to the UDP checksum. 2139 In a similar fashion, this specification allows a SCHC compressor to 2140 elide the UDP checks when another layer guarantees an identical or 2141 better integrity protection for the UDP payload and the pseudo- 2142 header. In this case, the TV is not set, the MO is set to "ignore" 2143 and the CDA is set to "compute-checksum". 2145 In particular, when SCHC fragmentation is used, a fragmentation MIC 2146 of 2 bytes or more provides equal or better protection than the UDP 2147 checksum; in that case, if the compressor is collocated with the 2148 fragmentation point and the decompressor is collocated with the 2149 packet reassembly point, then compressor MAY elide the UDP checksum. 2150 Whether and when the UDP Checksum is elided is to be specified in the 2151 technology-specific documents. 2153 Since the compression happens before the fragmentation, implementors 2154 should understand the risks when dealing with unprotected data below 2155 the transport layer and take special care when manipulating that 2156 data. 2158 In other cases, the checksum SHOULD be explicitly sent. The TV is 2159 not set, the MO is set to "ignore" and the CDA is set to "value- 2160 sent". 2162 11. IANA Considerations 2164 This document has no request to IANA. 2166 12. Security considerations 2168 12.1. Security considerations for SCHC Compression/Decompression 2170 A malicious header compression could cause the reconstruction of a 2171 wrong packet that does not match with the original one. Such a 2172 corruption MAY be detected with end-to-end authentication and 2173 integrity mechanisms. Header Compression does not add more security 2174 problem than what is already needed in a transmission. For instance, 2175 to avoid an attack, never re-construct a packet bigger than some 2176 configured size (with 1500 bytes as generic default). 2178 12.2. Security considerations for SCHC Fragmentation/Reassembly 2180 This subsection describes potential attacks to LPWAN SCHC F/R and 2181 suggests possible countermeasures. 2183 A node can perform a buffer reservation attack by sending a first 2184 SCHC Fragment to a target. Then, the receiver will reserve buffer 2185 space for the IPv6 packet. Other incoming fragmented SCHC Packets 2186 will be dropped while the reassembly buffer is occupied during the 2187 reassembly timeout. Once that timeout expires, the attacker can 2188 repeat the same procedure, and iterate, thus creating a denial of 2189 service attack. The (low) cost to mount this attack is linear with 2190 the number of buffers at the target node. However, the cost for an 2191 attacker can be increased if individual SCHC Fragments of multiple 2192 packets can be stored in the reassembly buffer. To further increase 2193 the attack cost, the reassembly buffer can be split into SCHC 2194 Fragment-sized buffer slots. Once a packet is complete, it is 2195 processed normally. If buffer overload occurs, a receiver can 2196 discard packets based on the sender behavior, which MAY help identify 2197 which SCHC Fragments have been sent by an attacker. 2199 In another type of attack, the malicious node is required to have 2200 overhearing capabilities. If an attacker can overhear a SCHC 2201 Fragment, it can send a spoofed duplicate (e.g. with random payload) 2202 to the destination. If the LPWAN technology does not support 2203 suitable protection (e.g. source authentication and frame counters to 2204 prevent replay attacks), a receiver cannot distinguish legitimate 2205 from spoofed SCHC Fragments. Therefore, the original IPv6 packet 2206 will be considered corrupt and will be dropped. To protect resource- 2207 constrained nodes from this attack, it has been proposed to establish 2208 a binding among the SCHC Fragments to be transmitted by a node, by 2209 applying content-chaining to the different SCHC Fragments, based on 2210 cryptographic hash functionality. The aim of this technique is to 2211 allow a receiver to identify illegitimate SCHC Fragments. 2213 Further attacks MAY involve sending overlapped fragments (i.e. 2214 comprising some overlapping parts of the original IPv6 datagram). 2215 Implementers SHOULD make sure that the correct operation is not 2216 affected by such event. 2218 In ACK-on-Error, a malicious node MAY force a SCHC Fragment sender to 2219 resend a SCHC Fragment a number of times, with the aim to increase 2220 consumption of the SCHC Fragment sender's resources. To this end, 2221 the malicious node MAY repeatedly send a fake ACK to the SCHC 2222 Fragment sender, with a Bitmap that reports that one or more SCHC 2223 Fragments have been lost. In order to mitigate this possible attack, 2224 MAX_ACK_RETRIES MAY be set to a safe value which allows to limit the 2225 maximum damage of the attack to an acceptable extent. However, note 2226 that a high setting for MAX_ACK_RETRIES benefits SCHC Fragment 2227 reliability modes, therefore the trade-off needs to be carefully 2228 considered. 2230 13. Acknowledgements 2232 Thanks to Carsten Bormann, Philippe Clavier, Eduardo Ingles Sanchez, 2233 Arunprabhu Kandasamy, Rahul Jadhav, Sergio Lopez Bernal, Antony 2234 Markovski, Alexander Pelov, Pascal Thubert, Juan Carlos Zuniga, Diego 2235 Dujovne, Edgar Ramos, and Shoichi Sakane for useful design 2236 consideration and comments. 2238 14. References 2240 14.1. Normative References 2242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2243 Requirement Levels", BCP 14, RFC 2119, 2244 DOI 10.17487/RFC2119, March 1997, 2245 . 2247 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2248 Interface Identifiers with IPv6 Stateless Address 2249 Autoconfiguration (SLAAC)", RFC 7217, 2250 DOI 10.17487/RFC7217, April 2014, 2251 . 2253 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2254 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2255 May 2017, . 2257 14.2. Informative References 2259 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 2260 "Internet Protocol Small Computer System Interface (iSCSI) 2261 Cyclic Redundancy Check (CRC)/Checksum Considerations", 2262 RFC 3385, DOI 10.17487/RFC3385, September 2002, 2263 . 2265 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2266 "Transmission of IPv6 Packets over IEEE 802.15.4 2267 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2268 . 2270 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2271 Header Compression (ROHC) Framework", RFC 5795, 2272 DOI 10.17487/RFC5795, March 2010, 2273 . 2275 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2276 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2277 DOI 10.17487/RFC6282, September 2011, 2278 . 2280 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2281 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2282 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2283 . 2285 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2286 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2287 February 2014, . 2289 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2290 (IPv6) Specification", STD 86, RFC 8200, 2291 DOI 10.17487/RFC8200, July 2017, 2292 . 2294 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 2295 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 2296 . 2298 Appendix A. SCHC Compression Examples 2300 This section gives some scenarios of the compression mechanism for 2301 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2303 The most common case using the mechanisms defined in this document 2304 will be a LPWAN Dev that embeds some applications running over CoAP. 2305 In this example, three flows are considered. The first flow is for 2306 the device management based on CoAP using Link Local IPv6 addresses 2307 and UDP ports 123 and 124 for Dev and App, respectively. The second 2308 flow will be a CoAP server for measurements done by the Device (using 2309 ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to 2310 beta::1/64. The last flow is for legacy applications using different 2311 ports numbers, the destination IPv6 address prefix is gamma::1/64. 2313 Figure 28 presents the protocol stack for this Device. IPv6 and UDP 2314 are represented with dotted lines since these protocols are 2315 compressed on the radio link. 2317 Management Data 2318 +----------+---------+---------+ 2319 | CoAP | CoAP | legacy | 2320 +----||----+---||----+---||----+ 2321 . UDP . UDP | UDP | 2322 ................................ 2323 . IPv6 . IPv6 . IPv6 . 2324 +------------------------------+ 2325 | SCHC Header compression | 2326 | and fragmentation | 2327 +------------------------------+ 2328 | LPWAN L2 technologies | 2329 +------------------------------+ 2330 DEV or NGW 2332 Figure 28: Simplified Protocol Stack for LP-WAN 2334 Note that in some LPWAN technologies, only the Devs have a device ID. 2335 Therefore, when such technologies are used, it is necessary to 2336 statically define an IID for the Link Local address for the SCHC C/D. 2338 Rule 0 2339 +----------------+--+--+--+---------+--------+------------++------+ 2340 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 2341 | | | | | | Opera. | Action ||[bits]| 2342 +----------------+--+--+--+---------+---------------------++------+ 2343 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2344 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2345 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2346 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2347 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2348 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2349 |IPv6 DEVprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2350 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2351 |IPv6 APPprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2352 |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | 2353 +================+==+==+==+=========+========+============++======+ 2354 |UDP DEVport |16|1 |Bi|123 | equal | not-sent || | 2355 |UDP APPport |16|1 |Bi|124 | equal | not-sent || | 2356 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2357 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2358 +================+==+==+==+=========+========+============++======+ 2360 Rule 1 2361 +----------------+--+--+--+---------+--------+------------++------+ 2362 | Field |FL|FP|DI| Value | Match | Action || Sent | 2363 | | | | | | Opera. | Action ||[bits]| 2364 +----------------+--+--+--+---------+--------+------------++------+ 2365 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2366 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2367 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2368 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2369 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2370 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2371 |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| [1] | 2372 | | | | |fe80::/64] mapping| || | 2373 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2374 |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| [2] | 2375 | | | | |alpha/64,| mapping| || | 2376 | | | | |fe80::64]| | || | 2377 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2378 +================+==+==+==+=========+========+============++======+ 2379 |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | 2380 |UDP APPport |16|1 |Bi|5683 | equal | not-sent || | 2381 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2382 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2383 +================+==+==+==+=========+========+============++======+ 2385 Rule 2 2386 +----------------+--+--+--+---------+--------+------------++------+ 2387 | Field |FL|FP|DI| Value | Match | Action || Sent | 2388 | | | | | | Opera. | Action ||[bits]| 2389 +----------------+--+--+--+---------+--------+------------++------+ 2390 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2391 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2392 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2393 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2394 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2395 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2396 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] | 2397 |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2398 |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | 2399 |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2400 |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | 2401 +================+==+==+==+=========+========+============++======+ 2402 |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB || [4] | 2403 |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB || [4] | 2404 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2405 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2406 +================+==+==+==+=========+========+============++======+ 2408 Figure 29: Context Rules 2410 All the fields described in the three Rules depicted on Figure 29 are 2411 present in the IPv6 and UDP headers. The DevIID-DID value is found 2412 in the L2 header. 2414 The second and third Rules use global addresses. The way the Dev 2415 learns the prefix is not in the scope of the document. 2417 The third Rule compresses port numbers to 4 bits. 2419 Appendix B. Fragmentation Examples 2421 This section provides examples for the different fragment reliability 2422 modes specified in this document. 2424 Figure 30 illustrates the transmission in No-ACK mode of an IPv6 2425 packet that needs 11 fragments. FCN is 1 bit wide. 2427 Sender Receiver 2428 |-------FCN=0-------->| 2429 |-------FCN=0-------->| 2430 |-------FCN=0-------->| 2431 |-------FCN=0-------->| 2432 |-------FCN=0-------->| 2433 |-------FCN=0-------->| 2434 |-------FCN=0-------->| 2435 |-------FCN=0-------->| 2436 |-------FCN=0-------->| 2437 |-------FCN=0-------->| 2438 |-----FCN=1 + MIC --->|MIC checked: success => 2440 Figure 30: Transmission in No-ACK mode of an IPv6 packet carried by 2441 11 fragments 2443 In the following examples, N (i.e. the size if the FCN field) is 3 2444 bits. Therefore, the All-1 FCN value is 7. 2446 Figure 31 illustrates the transmission in ACK-on-Error of an IPv6 2447 packet that needs 11 fragments, with MAX_WIND_FCN=6 and no fragment 2448 loss. 2450 Sender Receiver 2451 |-----W=0, FCN=6----->| 2452 |-----W=0, FCN=5----->| 2453 |-----W=0, FCN=4----->| 2454 |-----W=0, FCN=3----->| 2455 |-----W=0, FCN=2----->| 2456 |-----W=0, FCN=1----->| 2457 |-----W=0, FCN=0----->| 2458 (no ACK) 2459 |-----W=1, FCN=6----->| 2460 |-----W=1, FCN=5----->| 2461 |-----W=1, FCN=4----->| 2462 |--W=1, FCN=7 + MIC-->|MIC checked: success => 2463 |<---- ACK, W=1 ------| 2465 Figure 31: Transmission in ACK-on-Error mode of an IPv6 packet 2466 carried by 11 fragments, with MAX_WIND_FCN=6 and no loss. 2468 Figure 32 illustrates the transmission in ACK-on-Error mode of an 2469 IPv6 packet that needs 11 fragments, with MAX_WIND_FCN=6 and three 2470 lost fragments. 2472 Sender Receiver 2473 |-----W=0, FCN=6----->| 2474 |-----W=0, FCN=5----->| 2475 |-----W=0, FCN=4--X-->| 2476 |-----W=0, FCN=3----->| 2477 |-----W=0, FCN=2--X-->| 7 2478 |-----W=0, FCN=1----->| / 2479 |-----W=0, FCN=0----->| 6543210 2480 |<-----ACK, W=0-------|Bitmap:1101011 2481 |-----W=0, FCN=4----->| 2482 |-----W=0, FCN=2----->| 2483 (no ACK) 2484 |-----W=1, FCN=6----->| 2485 |-----W=1, FCN=5----->| 2486 |-----W=1, FCN=4--X-->| 2487 |- W=1, FCN=7 + MIC ->|MIC checked: failed 2488 |<-----ACK, W=1-------|C=0 Bitmap:1100001 2489 |-----W=1, FCN=4----->|MIC checked: success => 2490 |<---- ACK, W=1 ------|C=1, no Bitmap 2492 Figure 32: Transmission in ACK-on-Error mode of an IPv6 packet 2493 carried by 11 fragments, with MAX_WIND_FCN=6 and three lost 2494 fragments. 2496 Figure 33 illustrates the transmission in ACK-Always mode of an IPv6 2497 packet that needs 11 fragments, with MAX_WIND_FCN=6 and no loss. 2499 Sender Receiver 2500 |-----W=0, FCN=6----->| 2501 |-----W=0, FCN=5----->| 2502 |-----W=0, FCN=4----->| 2503 |-----W=0, FCN=3----->| 2504 |-----W=0, FCN=2----->| 2505 |-----W=0, FCN=1----->| 2506 |-----W=0, FCN=0----->| 2507 |<-----ACK, W=0-------| Bitmap:1111111 2508 |-----W=1, FCN=6----->| 2509 |-----W=1, FCN=5----->| 2510 |-----W=1, FCN=4----->| 2511 |--W=1, FCN=7 + MIC-->|MIC checked: success => 2512 |<-----ACK, W=1-------| C=1 no Bitmap 2513 (End) 2515 Figure 33: Transmission in ACK-Always mode of an IPv6 packet carried 2516 by 11 fragments, with MAX_WIND_FCN=6 and no lost fragment. 2518 Figure 34 illustrates the transmission in ACK-Always mode of an IPv6 2519 packet that needs 11 fragments, with MAX_WIND_FCN=6 and three lost 2520 fragments. 2522 Sender Receiver 2523 |-----W=1, FCN=6----->| 2524 |-----W=1, FCN=5----->| 2525 |-----W=1, FCN=4--X-->| 2526 |-----W=1, FCN=3----->| 2527 |-----W=1, FCN=2--X-->| 7 2528 |-----W=1, FCN=1----->| / 2529 |-----W=1, FCN=0----->| 6543210 2530 |<-----ACK, W=1-------|Bitmap:1101011 2531 |-----W=1, FCN=4----->| 2532 |-----W=1, FCN=2----->| 2533 |<-----ACK, W=1-------|Bitmap: 2534 |-----W=0, FCN=6----->| 2535 |-----W=0, FCN=5----->| 2536 |-----W=0, FCN=4--X-->| 2537 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2538 |<-----ACK, W=0-------| C= 0 Bitmap:11000001 2539 |-----W=0, FCN=4----->|MIC checked: success => 2540 |<-----ACK, W=0-------| C= 1 no Bitmap 2541 (End) 2543 Figure 34: Transmission in ACK-Always mode of an IPv6 packet carried 2544 by 11 fragments, with MAX_WIND_FCN=6 and three lost fragments. 2546 Figure 35 illustrates the transmission in ACK-Always mode of an IPv6 2547 packet that needs 6 fragments, with MAX_WIND_FCN=6, three lost 2548 fragments and only one retry needed to recover each lost fragment. 2550 Sender Receiver 2551 |-----W=0, FCN=6----->| 2552 |-----W=0, FCN=5----->| 2553 |-----W=0, FCN=4--X-->| 2554 |-----W=0, FCN=3--X-->| 2555 |-----W=0, FCN=2--X-->| 2556 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2557 |<-----ACK, W=0-------|C= 0 Bitmap:1100001 2558 |-----W=0, FCN=4----->|MIC checked: failed 2559 |-----W=0, FCN=3----->|MIC checked: failed 2560 |-----W=0, FCN=2----->|MIC checked: success 2561 |<-----ACK, W=0-------|C=1 no Bitmap 2562 (End) 2564 Figure 35: Transmission in ACK-Always mode of an IPv6 packet carried 2565 by 11 fragments, with MAX_WIND_FCN=6, three lost framents and only 2566 one retry needed for each lost fragment. 2568 Figure 36 illustrates the transmission in ACK-Always mode of an IPv6 2569 packet that needs 6 fragments, with MAX_WIND_FCN=6, three lost 2570 fragments, and the second ACK lost. 2572 Sender Receiver 2573 |-----W=0, FCN=6----->| 2574 |-----W=0, FCN=5----->| 2575 |-----W=0, FCN=4--X-->| 2576 |-----W=0, FCN=3--X-->| 2577 |-----W=0, FCN=2--X-->| 2578 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2579 |<-----ACK, W=0-------|C=0 Bitmap:1100001 2580 |-----W=0, FCN=4----->|MIC checked: failed 2581 |-----W=0, FCN=3----->|MIC checked: failed 2582 |-----W=0, FCN=2----->|MIC checked: success 2583 | X---ACK, W=0-------|C= 1 no Bitmap 2584 timeout | | 2585 |--W=0, FCN=7 + MIC-->| 2586 |<-----ACK, W=0-------|C= 1 no Bitmap 2588 (End) 2590 Figure 36: Transmission in ACK-Always mode of an IPv6 packet carried 2591 by 11 fragments, with MAX_WIND_FCN=6, three lost fragments, and the 2592 second ACK lost. 2594 Figure 37 illustrates the transmission in ACK-Always mode of an IPv6 2595 packet that needs 6 fragments, with MAX_WIND_FCN=6, with three lost 2596 fragments, and one retransmitted fragment lost again. 2598 Sender Receiver 2599 |-----W=0, FCN=6----->| 2600 |-----W=0, FCN=5----->| 2601 |-----W=0, FCN=4--X-->| 2602 |-----W=0, FCN=3--X-->| 2603 |-----W=0, FCN=2--X-->| 2604 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2605 |<-----ACK, W=0-------|C=0 Bitmap:1100001 2606 |-----W=0, FCN=4----->|MIC checked: failed 2607 |-----W=0, FCN=3----->|MIC checked: failed 2608 |-----W=0, FCN=2--X-->| 2609 timeout| | 2610 |--W=0, FCN=7 + MIC-->|All-0 empty 2611 |<-----ACK, W=0-------|C=0 Bitmap: 1111101 2612 |-----W=0, FCN=2----->|MIC checked: success 2613 |<-----ACK, W=0-------|C=1 no Bitmap 2614 (End) 2616 Figure 37: Transmission in ACK-Always mode of an IPv6 packet carried 2617 by 11 fragments, with MAX_WIND_FCN=6, with three lost fragments, and 2618 one retransmitted fragment lost again. 2620 Figure 38 illustrates the transmission in ACK-Always mode of an IPv6 2621 packet that needs 28 fragments, with N=5, MAX_WIND_FCN=23 and two 2622 lost fragments. Note that MAX_WIND_FCN=23 may be useful when the 2623 maximum possible Bitmap size, considering the maximum lower layer 2624 technology payload size and the value of R, is 3 bytes. Note also 2625 that the FCN of the last fragment of the packet is the one with 2626 FCN=31 (i.e. FCN=2^N-1 for N=5, or equivalently, all FCN bits set to 2627 1). 2629 Sender Receiver 2630 |-----W=0, FCN=23----->| 2631 |-----W=0, FCN=22----->| 2632 |-----W=0, FCN=21--X-->| 2633 |-----W=0, FCN=20----->| 2634 |-----W=0, FCN=19----->| 2635 |-----W=0, FCN=18----->| 2636 |-----W=0, FCN=17----->| 2637 |-----W=0, FCN=16----->| 2638 |-----W=0, FCN=15----->| 2639 |-----W=0, FCN=14----->| 2640 |-----W=0, FCN=13----->| 2641 |-----W=0, FCN=12----->| 2642 |-----W=0, FCN=11----->| 2643 |-----W=0, FCN=10--X-->| 2644 |-----W=0, FCN=9 ----->| 2645 |-----W=0, FCN=8 ----->| 2646 |-----W=0, FCN=7 ----->| 2647 |-----W=0, FCN=6 ----->| 2648 |-----W=0, FCN=5 ----->| 2649 |-----W=0, FCN=4 ----->| 2650 |-----W=0, FCN=3 ----->| 2651 |-----W=0, FCN=2 ----->| 2652 |-----W=0, FCN=1 ----->| 2653 |-----W=0, FCN=0 ----->| 2654 | |lcl-Bitmap:110111111111101111111111 2655 |<------ACK, W=0-------|encoded Bitmap:1101111111111011 2656 |-----W=0, FCN=21----->| 2657 |-----W=0, FCN=10----->| 2658 |<------ACK, W=0-------|no Bitmap 2659 |-----W=1, FCN=23----->| 2660 |-----W=1, FCN=22----->| 2661 |-----W=1, FCN=21----->| 2662 |--W=1, FCN=31 + MIC-->|MIC checked: sucess => 2663 |<------ACK, W=1-------|no Bitmap 2664 (End) 2666 Figure 38: Transmission in ACK-Always mode of an IPv6 packet carried 2667 by 28 fragments, with N=5, MAX_WIND_FCN=23 and two lost fragments. 2669 Appendix C. Fragmentation State Machines 2671 The fragmentation state machines of the sender and the receiver, one 2672 for each of the different reliability modes, are described in the 2673 following figures: 2675 +===========+ 2676 +------------+ Init | 2677 | FCN=0 +===========+ 2678 | No Window 2679 | No Bitmap 2680 | +-------+ 2681 | +========+==+ | More Fragments 2682 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 2683 +--------> | Send | send Fragment (FCN=0) 2684 +===+=======+ 2685 | last fragment 2686 | ~~~~~~~~~~~~ 2687 | FCN = 1 2688 v send fragment+MIC 2689 +============+ 2690 | END | 2691 +============+ 2693 Figure 39: Sender State Machine for the No-ACK Mode 2695 +------+ Not All-1 2696 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 2697 | + <--+ set Inactivity Timer 2698 | RCV Frag +-------+ 2699 +=+===+======+ |All-1 & 2700 All-1 & | | |MIC correct 2701 MIC wrong | |Inactivity | 2702 | |Timer Exp. | 2703 v | | 2704 +==========++ | v 2705 | Error |<-+ +========+==+ 2706 +===========+ | END | 2707 +===========+ 2709 Figure 40: Receiver State Machine for the No-ACK Mode 2710 +=======+ 2711 | INIT | FCN!=0 & more frags 2712 | | ~~~~~~~~~~~~~~~~~~~~~~ 2713 +======++ +--+ send Window + frag(FCN) 2714 W=0 | | | FCN- 2715 Clear local Bitmap | | v set local Bitmap 2716 FCN=max value | ++==+========+ 2717 +> | | 2718 +---------------------> | SEND | 2719 | +==+===+=====+ 2720 | FCN==0 & more frags | | last frag 2721 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 2722 | set local-Bitmap | | set local-Bitmap 2723 | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC 2724 | set Retrans_Timer | | set Retrans_Timer 2725 | | | 2726 |Recv_wnd == wnd & | | 2727 |Lcl_Bitmap==recv_Bitmap& | | +----------------------+ 2728 |more frag | | |lcl-Bitmap!=rcv-Bitmap| 2729 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 2730 |Stop Retrans_Timer | | | Attemp++ v 2731 |clear local_Bitmap v v | +=====+=+ 2732 |window=next_window +====+===+==+===+ |Resend | 2733 +---------------------+ | |Missing| 2734 +----+ Wait | |Frag | 2735 not expected wnd | | Bitmap | +=======+ 2736 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 2737 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 2738 | | | ^ ^ |reSend(empty)All-* | 2739 | | | | | |Set Retrans_Timer | 2740 | | | | +--+Attemp++ | 2741 MIC_bit==1 & | | | +-------------------------+ 2742 Recv_window==window & | | | all missing frags sent 2743 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 2744 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 2745 Stop Retrans_Timer| | | 2746 +=============+ | | | 2747 | END +<--------+ | | 2748 +=============+ | | Attemp > MAX_ACK_REQUESTS 2749 All-1 Window & | | ~~~~~~~~~~~~~~~~~~ 2750 MIC_bit ==0 & | v Send Abort 2751 Lcl_Bitmap==recv_Bitmap | +=+===========+ 2752 ~~~~~~~~~~~~ +>| ERROR | 2753 Send Abort +=============+ 2755 Figure 41: Sender State Machine for the ACK-Always Mode 2757 Not All- & w=expected +---+ +---+w = Not expected 2758 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2759 Set local_Bitmap(FCN) | v v |discard 2760 ++===+===+===+=+ 2761 +---------------------+ Rcv +--->* ABORT 2762 | +------------------+ Window | 2763 | | +=====+==+=====+ 2764 | | All-0 & w=expect | ^ w =next & not-All 2765 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 2766 | | set lcl_Bitmap(FCN)| |expected = next window 2767 | | send local_Bitmap | |Clear local_Bitmap 2768 | | | | 2769 | | w=expct & not-All | | 2770 | | ~~~~~~~~~~~~~~~~~~ | | 2771 | | set lcl_Bitmap(FCN)+-+ | | +--+ w=next & All-0 2772 | | if lcl_Bitmap full | | | | | | ~~~~~~~~~~~~~~~ 2773 | | send lcl_Bitmap | | | | | | expct = nxt wnd 2774 | | v | v | | | Clear lcl_Bitmap 2775 | | w=expct & All-1 +=+=+=+==+=++ | set lcl_Bitmap(FCN) 2776 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_Bitmap 2777 | | discard +--| Next | 2778 | | All-0 +---------+ Window +--->* ABORT 2779 | | ~~~~~ +-------->+========+=++ 2780 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 2781 | | & MIC wrong| | & MIC right 2782 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 2783 | | set local_Bitmap(FCN)| |set lcl_Bitmap(FCN) 2784 | | send local_Bitmap| |send local_Bitmap 2785 | | | +----------------------+ 2786 | |All-1 & w=expct | | 2787 | |& MIC wrong v +---+ w=expctd & | 2788 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong | 2789 | |set local_Bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ | 2790 | |send local_Bitmap | Wait End | set lcl_btmp(FCN)| 2791 | +--------------------->+ +--->* ABORT | 2792 | +===+====+=+-+ All-1&MIC wrong| 2793 | | ^ | ~~~~~~~~~~~~~~~| 2794 | w=expected & MIC right | +---+ send lcl_btmp | 2795 | ~~~~~~~~~~~~~~~~~~~~~~ | | 2796 | set local_Bitmap(FCN) | +-+ Not All-1 | 2797 | send local_Bitmap | | | ~~~~~~~~~ | 2798 | | | | discard | 2799 |All-1 & w=expctd & MIC right | | | | 2800 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 2801 |set local_Bitmap(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 2802 |send local_Bitmap | +<+Send lcl_btmp | 2803 +-------------------------->+ END | | 2804 +==========+<---------------+ 2806 --->* ABORT 2807 ~~~~~~~ 2808 Inactivity_Timer = expires 2809 When DWN_Link 2810 IF Inactivity_Timer expires 2811 Send DWL Request 2812 Attemp++ 2814 Figure 42: Receiver State Machine for the ACK-Always Mode 2815 +=======+ 2816 | | 2817 | INIT | 2818 | | FCN!=0 & more frags 2819 +======++ +--+ ~~~~~~~~~~~~~~~~~~~~~~ 2820 W=0 | | | send Window + frag(FCN) 2821 ~~~~~~~~~~~~~~~~~~ | | | FCN- 2822 Clear local Bitmap | | v set local Bitmap 2823 FCN=max value | ++=============+ 2824 +> | | 2825 | SEND | 2826 +-------------------------> | | 2827 | ++=====+=======+ 2828 | FCN==0 & more frags| |last frag 2829 | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~ 2830 | set local-Bitmap| |set local-Bitmap 2831 | send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC 2832 | set Retrans_Timer| |set Retrans_Timer 2833 | | | 2834 |Retrans_Timer expires & | | lcl-Bitmap!=rcv-Bitmap 2835 |more fragments | | ~~~~~~~~~~~~~~~~~~~~~~ 2836 |~~~~~~~~~~~~~~~~~~~~ | | Attemp++ 2837 |stop Retrans_Timer | | +-----------------+ 2838 |clear local-Bitmap v v | v 2839 |window = next window +=====+=====+==+==+ +====+====+ 2840 +----------------------+ + | Resend | 2841 +--------------------->+ Wait Bitmap | | Missing | 2842 | +-- + | | Frag | 2843 | not expected wnd | ++=+===+===+===+==+ +======+==+ 2844 | ~~~~~~~~~~~~~~~~ | ^ | | | ^ | 2845 | discard frag +----+ | | | +-------------------+ 2846 | | | | all missing frag sent 2847 |Retrans_Timer expires & | | | ~~~~~~~~~~~~~~~~~~~~~ 2848 | No more Frag | | | Set Retrans_Timer 2849 | ~~~~~~~~~~~~~~~~~~~~~~~ | | | 2850 | Stop Retrans_Timer | | | 2851 | Send ALL-1-empty | | | 2852 +-------------------------+ | | 2853 | | 2854 Local_Bitmap==Recv_Bitmap| | 2855 ~~~~~~~~~~~~~~~~~~~~~~~~~| |Attemp > MAX_ACK_REQUESTS 2856 +=========+Stop Retrans_Timer | |~~~~~~~~~~~~~~~~~~~~~~~ 2857 | END +<------------------+ v Send Abort 2858 +=========+ +=+=========+ 2859 | ERROR | 2860 +===========+ 2862 Figure 43: Sender State Machine for the ACK-on-Error Mode 2864 Not All- & w=expected +---+ +---+w = Not expected 2865 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2866 Set local_Bitmap(FCN) | v v |discard 2867 ++===+===+===+=+ 2868 +-----------------------+ +--+ All-0 & full 2869 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~~~ 2870 | +--------------------+ +<-+ w =next 2871 | | All-0 empty +->+=+=+===+======+ clear lcl_Bitmap 2872 | | ~~~~~~~~~~~ | | | ^ 2873 | | send bitmap +----+ | |w=expct & not-All & full 2874 | | | |~~~~~~~~~~~~~~~~~~~~~~~~ 2875 | | | |set lcl_Bitmap; w =nxt 2876 | | | | 2877 | | All-0 & w=expect | | w=next 2878 | | & no_full Bitmap | | ~~~~~~~~ +========+ 2879 | | ~~~~~~~~~~~~~~~~~ | | Send abort| Error/ | 2880 | | send local_Bitmap | | +---------->+ Abort | 2881 | | | | | +-------->+========+ 2882 | | v | | | all-1 ^ 2883 | | All-0 empty +====+===+==+=+=+ ~~~~~~~ | 2884 | | ~~~~~~~~~~~~~ +--+ Wait | Send abort | 2885 | | send lcl_btmp +->| Missing Fragm.| | 2886 | | +==============++ | 2887 | | +--------------+ 2888 | | Uplink Only & 2889 | | Inactivity_Timer = expires 2890 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 2891 | | Send Abort 2892 | |All-1 & w=expect & MIC wrong 2893 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ All-1 2894 | |set local_Bitmap(FCN) | v ~~~~~~~~~~ 2895 | |send local_Bitmap +===========+==+ snd lcl_btmp 2896 | +--------------------->+ Wait End +-+ 2897 | +=====+=+====+=+ | w=expct & 2898 | w=expected & MIC right | | ^ | MIC wrong 2899 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ ~~~~~~~~~ 2900 | set & send local_Bitmap(FCN) | | set lcl_Bitmap(FCN) 2901 | | | 2902 |All-1 & w=expected & MIC right | +-->* ABORT 2903 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v 2904 |set & send local_Bitmap(FCN) +=+==========+ 2905 +---------------------------->+ END | 2906 +============+ 2907 --->* ABORT 2908 Only Uplink 2909 Inactivity_Timer = expires 2910 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 2911 Send Abort 2913 Figure 44: Receiver State Machine for the ACK-on-Error Mode 2915 Appendix D. SCHC Parameters - Ticket #15 2917 This section gives the list of parameters that need to be defined in 2918 the technology-specific documents. 2920 o Define the most common uses case and how SCHC may be deployed. 2922 o LPWAN Architecture. Explain the SCHC entities (Compression and 2923 Fragmentation), how/where they are represented in the 2924 corresponding technology architecture. If applicable, explain the 2925 various potential channel conditions for the technology and the 2926 corresponding recommended use of C/D and F/R. 2928 o L2 fragmentation decision 2930 o Technology developers must evaluate that L2 has strong enough 2931 integrity checking to match SCHC's assumption. 2933 o Rule ID numbering system, number of Rules 2935 o Size of the Rule IDs 2937 o The way the Rule ID is sent (L2 or L3) and how (describe) 2939 o Fragmentation delivery reliability mode used in which cases (e.g. 2940 based on link channel condition) 2942 o Define the number of bits for FCN (N) and DTag (T) 2944 o in particular, is interleaved packet transmission supported and to 2945 what extent 2947 o The MIC algorithm to be used and the size, if different from the 2948 default CRC32 2950 o Retransmission Timer duration 2952 o Inactivity Timer duration 2954 o Define MAX_ACK_REQUEST (number of attempts) 2956 o Padding: size of the L2 Word (for most technologies, a byte; for 2957 some technologies, a bit). Value of the padding bits (1 or 0). 2958 The value of the padding bits needs to be specified because the 2959 padding bits are included in the MIC calculation. 2961 o Take into account that the length of Rule ID + N + T + W when 2962 possible is good to have a multiple of 8 bits to complete a byte 2963 and avoid padding 2965 o In the ACK format to have a length for Rule ID + T + W bit into a 2966 complete number of byte to do optimization more easily 2968 o The technology documents will describe if Rule ID is constrained 2969 by any alignment 2971 o When fragmenting in ACK-on-Error or ACK-Always mode, it is 2972 expected that the last window (called All-1 window) will not be 2973 fully utilised, i.e. there won't be fragments with all FCN values 2974 from MAX_WIND_FCN downto 1 and finally All-1. It is worth noting 2975 that this document does not mandate that other windows (called 2976 All-0 windows) are fully utilised either. This document purposely 2977 does not specify that All-1 windows use Bitmaps with the same 2978 number of bits as All-0 windows do. By default, Bitmaps for All-0 2979 and All-1 windows are of the same size MAX_WIND_FCN + 1. But a 2980 technology-specific document MAY revert that decision. The 2981 rationale for reverting the decision could be the following: Note 2982 that the SCHC ACK sent as a response to an All-1 fragment includes 2983 a C bit that SCHC ACK for other windows don't have. Therefore, 2984 the SCHC ACK for the All-1 window is one bit bigger. An L2 2985 technology with a severely constrained payload size might decide 2986 that this "bump" in the SCHC ACK for the last fragment is a bad 2987 resource usage. It could thus mandate that the All-1 window is 2988 not allowed to use the FCN value 1 and that the All-1 SCHC ACK 2989 Bitmap size is reduced by 1 bit. This provides room for the C bit 2990 without creating a bump in the SCHC ACK. 2992 And the following parameters need to be addressed in another document 2993 but not forcely in the technology-specific one: 2995 o The way the contexts are provisioning 2997 o The way the Rules as generated 2999 Appendix E. Note 3001 Carles Gomez has been funded in part by the Spanish Government 3002 (Ministerio de Educacion, Cultura y Deporte) through the Jose 3003 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 3004 Government through project TEC2016-79988-P. Part of his contribution 3005 to this work has been carried out during his stay as a visiting 3006 scholar at the Computer Laboratory of the University of Cambridge. 3008 Authors' Addresses 3010 Ana Minaburo 3011 Acklio 3012 1137A avenue des Champs Blancs 3013 35510 Cesson-Sevigne Cedex 3014 France 3016 Email: ana@ackl.io 3018 Laurent Toutain 3019 IMT-Atlantique 3020 2 rue de la Chataigneraie 3021 CS 17607 3022 35576 Cesson-Sevigne Cedex 3023 France 3025 Email: Laurent.Toutain@imt-atlantique.fr 3027 Carles Gomez 3028 Universitat Politecnica de Catalunya 3029 C/Esteve Terradas, 7 3030 08860 Castelldefels 3031 Spain 3033 Email: carlesgo@entel.upc.edu 3035 Dominique Barthel 3036 Orange Labs 3037 28 chemin du Vieux Chene 3038 38243 Meylan 3039 France 3041 Email: dominique.barthel@orange.com