idnits 2.17.00 (12 Aug 2021) /tmp/idnits21452/draft-ietf-lpwan-ipv6-static-context-hc-13.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '... most of the time and MAY receive data...' RFC 2119 keyword, line 268: '... connected to the LPWAN. A Dev SHOULD...' RFC 2119 keyword, line 483: '...east one Rule ID MAY be reserved to th...' RFC 2119 keyword, line 494: '...etworks, static contexts MAY be stored...' RFC 2119 keyword, line 496: '... contexts MUST be stored at both end...' (92 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1097 has weird spacing: '...long as the...' == Line 1320 has weird spacing: '... 1 byte next ...' == 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 (May 22, 2018) is 1460 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2164 -- Looks like a reference, but probably isn't: '2' on line 2167 -- Looks like a reference, but probably isn't: '8' on line 2189 -- Looks like a reference, but probably isn't: '4' on line 2196 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: draft-ietf-lpwan-overview has been published as RFC 8376 Summary: 3 errors (**), 0 flaws (~~), 5 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: Informational L. Toutain 5 Expires: November 23, 2018 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 May 22, 2018 10 LPWAN Static Context Header Compression (SCHC) and fragmentation for 11 IPv6 and UDP 12 draft-ietf-lpwan-ipv6-static-context-hc-13 14 Abstract 16 This document defines the Static Context Header Compression (SCHC) 17 framework, which provides header compression and fragmentation 18 functionality. SCHC has been tailored for Low Power Wide Area 19 Networks (LPWAN). 21 SCHC compression is based on a common static context stored in both 22 LPWAN devices and in the network sides. This document defines SCHC 23 header compression mechanism and its deployment for IPv6/UDP headers. 24 This document also specifies a fragmentation and reassembly mechanism 25 that is used to support the IPv6 MTU requirement over the LPWAN 26 technologies. The Fragmentation is needed for IPv6 datagrams that, 27 after SCHC compression or when it has not been possible to apply such 28 compression, still exceed the layer two maximum payload size. 30 The SCHC header compression mechanism is independent of the specific 31 LPWAN technology over which it will be used. Note that this document 32 defines generic functionalities and advisedly offers flexibility with 33 regard to parameters settings and mechanism choices, that are 34 expected to be made in other technology-specific documents. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 23, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Static Context Header Compression . . . . . . . . . . . . . . 11 76 6.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12 77 6.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14 78 6.3. Packet processing . . . . . . . . . . . . . . . . . . . . 14 79 6.4. Matching operators . . . . . . . . . . . . . . . . . . . 16 80 6.5. Compression Decompression Actions (CDA) . . . . . . . . . 17 81 6.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 18 82 6.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 18 83 6.5.3. mapping-sent CDA . . . . . . . . . . . . . . . . . . 18 84 6.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 19 85 6.5.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . 19 86 6.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 19 87 7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 20 88 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 89 7.2. Fragmentation Tools . . . . . . . . . . . . . . . . . . . 20 90 7.3. Reliability modes . . . . . . . . . . . . . . . . . . . . 23 91 7.4. Fragmentation Formats . . . . . . . . . . . . . . . . . . 25 92 7.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 25 93 7.4.2. All-1 and All-0 formats . . . . . . . . . . . . . . . 26 94 7.4.3. SCHC ACK format . . . . . . . . . . . . . . . . . . . 28 95 7.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 30 97 7.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 31 98 7.5.1. No-ACK . . . . . . . . . . . . . . . . . . . . . . . 33 99 7.5.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 33 100 7.5.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 35 101 7.6. Supporting multiple window sizes . . . . . . . . . . . . 37 102 7.7. Downlink SCHC Fragment transmission . . . . . . . . . . . 37 103 8. Padding management . . . . . . . . . . . . . . . . . . . . . 38 104 9. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 39 105 9.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 39 106 9.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 39 107 9.3. Flow label field . . . . . . . . . . . . . . . . . . . . 40 108 9.4. Payload Length field . . . . . . . . . . . . . . . . . . 40 109 9.5. Next Header field . . . . . . . . . . . . . . . . . . . . 40 110 9.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 40 111 9.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 41 112 9.7.1. IPv6 source and destination prefixes . . . . . . . . 41 113 9.7.2. IPv6 source and destination IID . . . . . . . . . . . 41 114 9.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 42 115 9.9. UDP source and destination port . . . . . . . . . . . . . 42 116 9.10. UDP length field . . . . . . . . . . . . . . . . . . . . 42 117 9.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 43 118 10. Security considerations . . . . . . . . . . . . . . . . . . . 43 119 10.1. Security considerations for header compression . . . . . 43 120 10.2. Security considerations for SCHC 121 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43 122 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 123 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 124 12.1. Normative References . . . . . . . . . . . . . . . . . . 45 125 12.2. Informative References . . . . . . . . . . . . . . . . . 45 126 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 45 127 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 48 128 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 54 129 Appendix D. SCHC Parameters - Ticket #15 . . . . . . . . . . . . 61 130 Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 62 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 133 1. Introduction 135 This document defines a header compression scheme and fragmentation 136 functionality, both specially tailored for Low Power Wide Area 137 Networks (LPWAN). 139 Header compression is needed to efficiently bring Internet 140 connectivity to the node within an LPWAN network. Some LPWAN 141 networks properties can be exploited to get an efficient header 142 compression: 144 o The topology is star-oriented which means that all packets follow 145 the same path. For the necessity of this draft, the architecture 146 is simple and is described as Devices (Dev) exchanging information 147 with LPWAN Application Servers (App) through Network Gateways 148 (NGW). 150 o The traffic flows can be known in advance since devices embed 151 built-in applications. New applications cannot be easily 152 installed in LPWAN devices, as they would in computers or 153 smartphones. 155 The Static Context Header Compression (SCHC) is defined for this 156 environment. SCHC uses a context, where header information is kept 157 in the header format order. This context is static: the values of 158 the header fields do not change over time. This avoids complex 159 resynchronization mechanisms, that would be incompatible with LPWAN 160 characteristics. In most cases, a small context identifier is enough 161 to represent the full IPv6/UDP headers. The SCHC header compression 162 mechanism is independent of the specific LPWAN technology over which 163 it is used. 165 LPWAN technologies impose some strict limitations on traffic. For 166 instance, devices are sleeping most of the time and MAY receive data 167 during short periods of time after transmission to preserve battery. 168 LPWAN technologies are also characterized, among others, by a very 169 reduced data unit and/or payload size [I-D.ietf-lpwan-overview]. 170 However, some of these technologies do not provide fragmentation 171 functionality, therefore the only option for them to support the IPv6 172 MTU requirement of 1280 bytes [RFC2460] is to use a fragmentation 173 protocol at the adaptation layer, below IPv6. In response to this 174 need, this document also defines a fragmentation/reassembly 175 mechanism, which supports the IPv6 MTU requirement over LPWAN 176 technologies. Such functionality has been designed under the 177 assumption that data unit out-of-sequence delivery will not happen 178 between the entity performing fragmentation and the entity performing 179 reassembly. 181 Note that this document defines generic functionality and 182 purposefully offers flexibility with regard to parameter settings and 183 mechanism choices, that are expected to be made in other, technology- 184 specific documents. 186 2. LPWAN Architecture 188 LPWAN technologies have similar network architectures but different 189 terminology. We can identify different types of entities in a 190 typical LPWAN network, see Figure 1: 192 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 193 actuators, etc.). There can be a very high density of devices per 194 radio gateway. 196 o The Radio Gateway (RGW), which is the end point of the constrained 197 link. 199 o The Network Gateway (NGW) is the interconnection node between the 200 Radio Gateway and the Internet. 202 o LPWAN-AAA Server, which controls the user authentication and the 203 applications. 205 o Application Server (App) 207 +------+ 208 () () () | |LPWAN-| 209 () () () () / \ +---------+ | AAA | 210 () () () () () () / \======| ^ |===|Server| +-----------+ 211 () () () | | <--|--> | +------+ |APPLICATION| 212 () () () () / \==========| v |=============| (App) | 213 () () () / \ +---------+ +-----------+ 214 Dev Radio Gateways NGW 216 Figure 1: LPWAN Architecture 218 3. Terminology 220 This section defines the terminology and acronyms used in this 221 document. 223 o Abort. A SCHC Fragment format to signal the other end-point that 224 the on-going fragment transmission is stopped and finished. 226 o All-0. The SCHC Fragment format for the last frame of a window 227 that is not the last one of a packet (see Window in this 228 glossary). 230 o All-1. The SCHC Fragment format for the last frame of the packet. 232 o All-0 empty. An All-0 SCHC Fragment without payload. It is used 233 to request the SCHC ACK with the encoded Bitmap when the 234 Retransmission Timer expires, in a window that is not the last one 235 of a packet. 237 o All-1 empty. An All-1 SCHC Fragment without payload. It is used 238 to request the SCHC ACK with the encoded Bitmap when the 239 Retransmission Timer expires in the last window of a packet. 241 o App: LPWAN Application. An application sending/receiving IPv6 242 packets to/from the Device. 244 o APP-IID: Application Interface Identifier. Second part of the 245 IPv6 address that identifies the application server interface. 247 o Bi: Bidirectional, a rule entry that applies to headers of packets 248 travelling in both directions (Up and Dw). 250 o Bitmap: a field of bits in an acknowledgment message that tells 251 the sender which SCHC Fragments of a window were correctly 252 received. 254 o C: Checked bit. Used in an acknowledgment (SCHC ACK) header to 255 determine if the MIC locally computed by the receiver matches (1) 256 the received MIC or not (0). 258 o CDA: Compression/Decompression Action. Describes the reciprocal 259 pair of actions that are performed at the compressor to compress a 260 header field and at the decompressor to recover the original 261 header field value. 263 o Compression Residue. The bits that need to be sent after applying 264 the SCHC compression over each header field 266 o Context: A set of rules used to compress/decompress headers. 268 o Dev: Device. A node connected to the LPWAN. A Dev SHOULD 269 implement SCHC. 271 o Dev-IID: Device Interface Identifier. Second part of the IPv6 272 address that identifies the device interface. 274 o DI: Direction Indicator. This field tells which direction of 275 packet travel (Up, Dw or Bi) a rule applies to. This allows for 276 assymmetric processing. 278 o DTag: Datagram Tag. This SCHC F/R header field is set to the same 279 value for all SCHC Fragments carrying the same IPv6 datagram. 281 o Dw: Downlink direction for compression/decompression in both 282 sides, from SCHC C/D in the network to SCHC C/D in the Dev. 284 o FCN: Fragment Compressed Number. This SCHC F/R header field 285 carries an efficient representation of a larger-sized fragment 286 number. 288 o Field Description. A line in the Rule Table. 290 o FID: Field Identifier. This is an index to describe the header 291 fields in a Rule. 293 o FL: Field Length is the length of the field in bits for fixed 294 values or a type (variable, token length, ...) for length unknown 295 at the rule creation. The length of a header field is defined in 296 the specific protocol standard. 298 o FP: Field Position is a value that is used to identify the 299 position where each instance of a field appears in the header. 301 o IID: Interface Identifier. See the IPv6 addressing architecture 302 [RFC7136] 304 o Inactivity Timer. A timer used after receiving a SCHC Fragment to 305 detect when there is an error and there is no possibility to 306 continue an on-going SCHC Fragmented packet transmission. 308 o L2: Layer two. The immediate lower layer SCHC interfaces with. 309 It is provided by an underlying LPWAN technology. 311 o MIC: Message Integrity Check. A SCHC F/R header field computed 312 over an IPv6 packet before fragmentation, used for error detection 313 after IPv6 packet reassembly. 315 o MO: Matching Operator. An operator used to match a value 316 contained in a header field with a value contained in a Rule. 318 o Retransmission Timer. A timer used by the SCHC Fragment sender 319 during an on-going SCHC Fragmented packet transmission to detect 320 possible link errors when waiting for a possible incoming SCHC 321 ACK. 323 o Rule: A set of header field values. 325 o Rule entry: A column in the rule that describes a parameter of the 326 header field. 328 o Rule ID: An identifier for a rule, SCHC C/D in both sides share 329 the same Rule ID for a specific packet. A set of Rule IDs are 330 used to support SCHC F/R functionality. 332 o SCHC ACK: A SCHC acknowledgement for fragmentation, this format 333 used to report the success or unsuccess reception of a set of SCHC 334 Fragments. See Section 7 for more details. 336 o SCHC C/D: Static Context Header Compression Compressor/ 337 Decompressor. A mechanism used in both sides, at the Dev and at 338 the network to achieve Compression/Decompression of headers. SCHC 339 C/D uses SCHC rules to perform compression and decompression. 341 o SCHC F/R: Static Context Header Compression Fragmentation/ 342 Reassembly. A protocol used in both sides, at the Dev and at the 343 network to achieve Fragmentation/Reassembly of fragments. SCHC F/ 344 R has three reliability modes. 346 o SCHC Fragment: A data unit that carries a subset of a SCHC Packet. 347 SCHC F/R is needed when the size of a SCHC packet exceeds the 348 available payload size of the underlying L2 technology data unit. 349 See Section 7. 351 o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been 352 compressed as per the header compression mechanism defined in this 353 document. If the header compression process is unable to actually 354 compress the packet header, the packet with the uncompressed 355 header is still called a SCHC Packet (in this case, a Rule ID is 356 used to indicate that the packet header has not been compressed). 357 See Section 6 for more details. 359 o TV: Target value. A value contained in the Rule that will be 360 matched with the value of a header field. 362 o Up: Uplink direction for compression/decompression in both sides, 363 from the Dev SCHC C/D to the network SCHC C/D. 365 o W: Window bit. A SCHC Fragment header field used in Window mode 366 Section 7, which carries the same value for all SCHC Fragments of 367 a window. 369 o Window: A subset of the SCHC Fragments needed to carry a packet 370 Section 7. 372 4. SCHC overview 374 SCHC can be abstracted as an adaptation layer between IPv6 and the 375 underlying LPWAN technology. SCHC comprises two sublayers (i.e. the 376 Compression sublayer and the Fragmentation sublayer), as shown in 377 Figure 2. 379 +----------------+ 380 | IPv6 | 381 +- +----------------+ 382 | | Compression | 383 SCHC < +----------------+ 384 | | Fragmentation | 385 +- +----------------+ 386 |LPWAN technology| 387 +----------------+ 389 Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN 390 technology 392 As per this document, when a packet (e.g. an IPv6 packet) needs to be 393 transmitted, header compression is first applied to the packet. The 394 resulting packet after header compression (whose header may or may 395 not actually be smaller than that of the original packet) is called a 396 SCHC Packet. If the SCHC Packet size exceeds the layer 2 (L2) MTU, 397 fragmentation is then applied to the SCHC Packet. The SCHC Packet or 398 the SCHC Fragments are then transmitted over the LPWAN. The 399 reciprocal operations take place at the receiver. This process is 400 illustrated in Figure 3. 402 A packet (e.g. an IPv6 packet) 403 | ^ 404 v | 405 +-------------------+ +--------------------+ 406 | SCHC Compression | | SCHC Decompression | 407 +------------------+ +--------------------+ 408 | | 409 | If no fragmentation (*) | 410 +----------------- SCHC Packet ------------>| 411 | | 412 +--------------------+ +-----------------+ 413 | SCHC Fragmentation | | SCHC Reassembly | 414 +--------------------+ +-----------------+ 415 ^ | ^ | 416 | | | | 417 | +---------- SCHC Fragments ----------+ | 418 +-------------- SCHC ACK ------------------------+ 419 SENDER RECEIVER 421 *: see Section 7 to define the use of Fragmentation and the 422 technology-specific documents for the L2 decision. 424 Figure 3: SCHC operations taking place at the sender and the receiver 425 The SCHC Packet is composed of the Compressed Header followed by the 426 payload from the original packet (see Figure 4). The Compressed 427 Header itself is composed of a Rule ID and a Compression Residue. 428 The Compression Residue may be absent, see Section 6. Both the Rule 429 ID and the Compression Residue potentially have a variable size, and 430 generally are not a mutiple of bytes in size. 432 | Rule ID + Compression Residue | 433 +---------------------------------+--------------------+ 434 | Compressed Header | Payload | 435 +---------------------------------+--------------------+ 437 Figure 4: SCHC Packet 439 The Fragment Header size is variable and depends on the Fragmentation 440 parameters. The Fragment payload may contain: part of the SCHC 441 Packet or Payload or both and its size depends on the L2 data unit, 442 see Section 7. The SCHC Fragment has the following format: 444 | Rule ID + DTAG + W + FCN [+ MIC ] | Partial SCHC Packet | 445 +-----------------------------------+-------------------------+ 446 | Fragment Header | Fragment Payload | 447 +-----------------------------------+-------------------------+ 449 Figure 5: SCHC Fragment 451 The SCHC ACK is byte aligned and the ACK Header and the encoded 452 Bitmap both have variable size. The SCHC ACK is used only in 453 Fragmentation and has the following format: 455 |Rule ID + DTag + W| 456 +------------------+-------- ... ---------+ 457 | ACK Header | encoded Bitmap | 458 +------------------+-------- ... ---------+ 460 Figure 6: SCHC ACK 462 5. Rule ID 464 Rule ID are identifiers used to select either the correct context to 465 be used for Compression/Decompression functionalities or for 466 Fragmentation/Reassembly or after trying to do SCHC C/D and SCHC F/R 467 the packet is sent as is. The size of the Rule ID is not specified 468 in this document, as it is implementation-specific and can vary 469 according to the LPWAN technology and the number of Rules, among 470 others. 472 The Rule IDs identifiers are used: 474 o In the SCHC C/D context to keep the Field Description of the 475 header packet. 477 o In SCHC F/R to identify the specific modes and settings. In 478 bidirectional SCHC F/R at least two Rules 479 ID are needed. 481 o To identify the SCHC ACK in SCHC F/R 483 o And at least one Rule ID MAY be reserved to the case where no SCHC 484 C/D nor SCHC F/R were possible. 486 6. Static Context Header Compression 488 In order to perform header compression, this document defines a 489 mechanism called Static Context Header Compression (SCHC), which is 490 based on using context, i.e. a set of rules to compress or decompress 491 headers. SCHC avoids context synchronization, which is the most 492 bandwidth-consuming operation in other header compression mechanisms 493 such as RoHC [RFC5795]. Since the nature of packets are highly 494 predictable in LPWAN networks, static contexts MAY be stored 495 beforehand to omit transmitting some information over the air. The 496 contexts MUST be stored at both ends, and they can either be learned 497 by a provisioning protocol, by out of band means, or they can be pre- 498 provisioned. The way the contexts are provisioned on both ends is 499 out of the scope of this document. 501 Dev App 502 +----------------+ +--------------+ 503 | APP1 APP2 APP3 | |APP1 APP2 APP3| 504 | | | | 505 | UDP | | UDP | 506 | IPv6 | | IPv6 | 507 | | | | 508 |SCHC Comp / Frag| | | 509 +--------+-------+ +-------+------+ 510 | +--+ +----+ +-----------+ . 511 +~~ |RG| === |NGW | === | SCHC |... Internet .. 512 +--+ +----+ |Comp / Frag| 513 +-----------+ 515 Figure 7: Architecture 517 Figure 7 The figure represents the architecture for SCHC (Static 518 Context Header Compression) Compression/Fragmentation where SCHC C/D 519 (Compressor/Decompressor) and SCHC F/R (Fragmentation/Reassembly) are 520 performed. It is based on {{I-D.ietf- lpwan-overview}} terminology. 521 SCHC Compression/Fragmentation is located on both sides of the 522 transmission in the Dev and in the Network side. In the Uplink 523 direction, the Device application packets use IPv6 or IPv6/UDP 524 protocols. Before sending these packets, the Dev compresses their 525 headers using SCHC C/D and if the SCHC Packet resulting from the 526 compression exceeds the maximum payload size of the underlying LPWAN 527 technology, SCHC F/R is performed, see Section 7. The resulting SCHC 528 Fragments are sent as one or more L2 frames to an LPWAN Radio Gateway 529 (RG) which forwards the frame(s) to a Network Gateway (NGW). 531 The NGW sends the data to a SCHC F/R and then to the SCHC C/D for 532 decompression. The SCHC C/D in the Network side can be located in 533 the Network Gateway (NGW) or somewhere else as long as a tunnel is 534 established between the NGW and the SCHC Compression/Fragmentation. 535 Note that, for some LPWAN technologies, it MAY be suitable to locate 536 SCHC Fragmentation/Reassembly functionality nearer the NGW, in order 537 to better deal with time constraints of such technologies. The SCHC 538 C/Ds on both sides MUST share the same set of Rules. After 539 decompression, the packet can be sent over the Internet to one or 540 several LPWAN Application Servers (App). 542 The SCHC Compression/Fragmentation process is symmetrical, therefore 543 the same description applies to the reverse direction. 545 6.1. SCHC C/D Rules 547 The main idea of the SCHC compression scheme is to transmit the Rule 548 ID to the other end instead of sending known field values. This Rule 549 ID identifies a rule that provides the closest match to the original 550 packet values. Hence, when a value is known by both ends, it is only 551 necessary to send the corresponding Rule ID over the LPWAN network. 552 How Rules are generated is out of the scope of this document. The 553 rule MAY be changed but it will be specified in another document. 555 The context contains a list of rules (cf. Figure 8). Each Rule 556 contains itself a list of Fields Descriptions composed of a field 557 identifier (FID), a field length (FL), a field position (FP), a 558 direction indicator (DI), a target value (TV), a matching operator 559 (MO) and a Compression/Decompression Action (CDA). 561 /-----------------------------------------------------------------\ 562 | Rule N | 563 /-----------------------------------------------------------------\| 564 | Rule i || 565 /-----------------------------------------------------------------\|| 566 | (FID) Rule 1 ||| 567 |+-------+--+--+--+------------+-----------------+---------------+||| 568 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 569 |+-------+--+--+--+------------+-----------------+---------------+||| 570 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 571 |+-------+--+--+--+------------+-----------------+---------------+||| 572 ||... |..|..|..| ... | ... | ... |||| 573 |+-------+--+--+--+------------+-----------------+---------------+||/ 574 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 575 |+-------+--+--+--+------------+-----------------+---------------+|/ 576 | | 577 \-----------------------------------------------------------------/ 579 Figure 8: Compression/Decompression Context 581 The Rule does not describe how to delineate each field in the 582 original packet header. This MUST be known from the compressor/ 583 decompressor. The rule only describes the compression/decompression 584 behavior for each header field. In the rule, the Fields Descriptions 585 are listed in the order in which the fields appear in the packet 586 header. 588 The Rule also describes the Compression Residue sent regarding the 589 order of the Fields Descriptions in the Rule. 591 The Context describes the header fields and its values with the 592 following entries: 594 o Field ID (FID) is a unique value to define the header field. 596 o Field Length (FL) represents the length of the field. It can be 597 either a fixed value (in bits) if the length is known when the 598 rule is created or a type if the length is variable. The length 599 of a header field is defined in the specific protocol standard. 600 The type defines the process to compute length, its unit (bits, 601 bytes,...) and the value to be sent before the compression 602 residue. 604 o Field Position (FP): indicating if several instances of a field 605 exist in the headers which one is targeted. The default position 606 is 1. 608 o A direction indicator (DI) indicates the packet direction(s) this 609 Field Description applies to. Three values are possible: 611 * UPLINK (Up): this Field Description is only applicable to 612 packets sent by the Dev to the App, 614 * DOWNLINK (Dw): this Field Description is only applicable to 615 packets sent from the App to the Dev, 617 * BIDIRECTIONAL (Bi): this Field Description is applicable to 618 packets travelling both Up and Dw. 620 o Target Value (TV) is the value used to make the match with the 621 packet header field. The Target Value can be of any type 622 (integer, strings, etc.). For instance, it can be a single value 623 or a more complex structure (array, list, etc.), such as a JSON or 624 a CBOR structure. 626 o Matching Operator (MO) is the operator used to match the Field 627 Value and the Target Value. The Matching Operator may require 628 some parameters. MO is only used during the compression phase. 629 The set of MOs defined in this document can be found in 630 Section 6.4. 632 o Compression Decompression Action (CDA) describes the compression 633 and decompression processes to be performed after the MO 634 is applied. The CDA MAY require some parameters to be processed. 635 CDAs are used in both the compression and the decompression 636 functions. The set of CDAs defined in this document can be found 637 in Section 6.5. 639 6.2. Rule ID for SCHC C/D 641 Rule IDs are sent by the compression function in one side and are 642 received for the decompression function in the other side. In SCHC 643 C/D, the Rule IDs are specific to a Dev. Hence, multiple Dev 644 instances MAY use the same Rule ID to define different header 645 compression contexts. To identify the correct Rule ID, the SCHC C/D 646 needs to correlate the Rule ID with the Dev identifier to find the 647 appropriate Rule to be applied. 649 6.3. Packet processing 651 The compression/decompression process follows several steps: 653 o Compression Rule selection: The goal is to identify which Rule(s) 654 will be used to compress the packet's headers. When 655 doing decompression, in the network side the SCHC C/D needs to 656 find the correct Rule based on the L2 address and in this way, it 657 can use the Dev-ID and the Rule-ID. In the Dev side, only the 658 Rule ID is needed to identify the correct Rule since the Dev only 659 holds Rules that apply to itself. The Rule will be selected by 660 matching the Fields Descriptions to the packet header as described 661 below. When the selection of a Rule is done, this Rule is used to 662 compress the header. The detailed steps for compression Rule 663 selection are the following: 665 * The first step is to choose the Fields Descriptions by their 666 direction, using the direction indicator (DI). A Field 667 Description that does not correspond to the appropriate DI will 668 be ignored, if all the fields of the packet do not have a Field 669 Description with the correct DI the Rule is discarded and SCHC 670 C/D proceeds to explore the next Rule. 672 * When the DI has matched, then the next step is to identify the 673 fields according to Field Position (FP). If the Field Position 674 does not correspond, the Rule is not used and the SCHC C/D 675 proceeds to consider the next Rule. 677 * Once the DI and the FP correspond to the header information, 678 each field's value of the packet is then compared to the 679 corresponding Target Value (TV) stored in the Rule for that 680 specific field using the matching operator (MO). 682 If all the fields in the packet's header satisfy all the 683 matching operators (MO) of a Rule (i.e. all MO results are 684 True), the fields of the header are then compressed according 685 to the Compression/Decompression Actions (CDAs) and a 686 compressed header (with possibly a Compression Residue) SHOULD 687 be obtained. Otherwise, the next Rule is tested. 689 * If no eligible Rule is found, then the header MUST be sent 690 without compression, depending on the L2 PDU size, this is one 691 of the case that MAY require the use of the SCHC F/R process. 693 o Sending: If an eligible Rule is found, the Rule ID is sent to the 694 other end followed by the Compression Residue (which could be 695 empty) and directly followed by the payload. The Compression 696 Residue is the concatenation of the Compression 697 Residues for each field according to the CDAs for that rule. The 698 way the Rule ID is sent depends on the specific LPWAN layer two 699 technology. For example, it can be either included in a Layer 2 700 header or sent in the first byte of the L2 payload. (Cf. 701 Figure 9). This process will be specified in the LPWAN 702 technology-specific document and is out of the scope of the 703 present document. On LPWAN technologies that are byte- oriented, 704 the compressed header concatenated with the original packet 705 payload is padded to a multiple of 8 bits, if needed. See 706 Section 8 for details. 708 o Decompression: When doing decompression, in the network side the 709 SCHC C/D needs to find the correct Rule based on the L2 address 710 and in this way, it can use the Dev-ID and the Rule-ID. In the 711 Dev side, only the Rule ID is needed to identify the correct Rule 712 since the Dev only holds Rules that apply to itself. 714 The receiver identifies the sender through its device-id (e.g. 715 MAC address, if exists) and selects the appropriate Rule 716 from the Rule ID. If a source identifier is present in the L2 717 technology, it is used to select the Rule ID. This Rule describes 718 the compressed header format and associates the values to the 719 header fields. The receiver applies the CDA action to reconstruct 720 the original header fields. The CDA application order can be 721 different from the order given by the Rule. For instance, 722 Compute-* SHOULD be applied at the end, after all the other CDAs. 724 +--- ... --+------- ... -------+------------------+~~~~~~~ 725 | Rule ID |Compression Residue| packet payload |padding 726 +--- ... --+------- ... -------+------------------+~~~~~~~ 727 (optional) 728 |----- compressed header ------| 730 Figure 9: SCHC C/D Packet Format 732 6.4. Matching operators 734 Matching Operators (MOs) are functions used by both SCHC C/D 735 endpoints involved in the header compression/decompression. They are 736 not typed and can be indifferently applied to integer, string or any 737 other data type. The result of the operation can either be True or 738 False. MOs are defined as follows: 740 o equal: The match result is True if a field value in a packet and 741 the value in the TV are equal. 743 o ignore: No check is done between a field value in a packet and a 744 TV in the Rule. The result of the matching is always true. 746 o MSB(x): A match is obtained if the most significant x bits of the 747 field value in the header packet are equal to the TV in the Rule. 748 The x parameter of the MSB Matching Operator indicates how many 749 bits are involved in the comparison. If the FL is described as 750 variable, the length must be a multiple of the unit. For example, 751 x must be multiple of 8 if the unit of the variable length is in 752 bytes. 754 o match-mapping: With match-mapping, the Target Value is a list of 755 values. Each value of the list is identified by a short ID (or 756 index). Compression is achieved by sending the index instead of 757 the original header field value. This operator matches if the 758 header field value is equal to one of the values in the target 759 list. 761 6.5. Compression Decompression Actions (CDA) 763 The Compression Decompression Action (CDA) describes the actions 764 taken during the compression of headers fields, and inversely, the 765 action taken by the decompressor to restore the original value. 767 /--------------------+-------------+----------------------------\ 768 | Action | Compression | Decompression | 769 | | | | 770 +--------------------+-------------+----------------------------+ 771 |not-sent |elided |use value stored in ctxt | 772 |value-sent |send |build from received value | 773 |mapping-sent |send index |value from index on a table | 774 |LSB |send LSB |TV, received value | 775 |compute-length |elided |compute length | 776 |compute-checksum |elided |compute UDP checksum | 777 |Deviid |elided |build IID from L2 Dev addr | 778 |Appiid |elided |build IID from L2 App addr | 779 \--------------------+-------------+----------------------------/ 780 y=size of the transmitted bits 782 Figure 10: Compression and Decompression Functions 784 Figure 10 summarizes the basic functions that can be used to compress 785 and decompress a field. The first column lists the actions name. 786 The second and third columns outline the reciprocal compression/ 787 decompression behavior for each action. 789 Compression is done in order that Fields Descriptions appear in the 790 Rule. The result of each Compression/Decompression Action is 791 appended to the working Compression Residue in that same order. The 792 receiver knows the size of each compressed field which can be given 793 by the rule or MAY be sent with the compressed header. 795 If the field is identified as being variable in the Field 796 Description, then the size of the Compression Residue value (using 797 the unit defined in the FL) MUST be sent first using the following 798 coding: 800 o If the size is between 0 and 14 bytes, it is sent as a 4-bits 801 integer. 803 o For values between 15 and 254, the first 4 bits sent are set to 1 804 and the size is sent using 8 bits integer. 806 o For higher values of size, the first 12 bits are set to 1 and the 807 next two bytes contain the size value as a 16 bits integer. 809 o If a field does not exist in the packet but in the Rule and its FL 810 is variable, the size zero MUST be used. 812 6.5.1. not-sent CDA 814 The not-sent function is generally used when the field value is 815 specified in the Rule and therefore known by both the Compressor and 816 the Decompressor. This action is generally used with the "equal" MO. 817 If MO is "ignore", there is a risk to have a decompressed field value 818 different from the compressed field. 820 The compressor does not send any Compression Residue for a field on 821 which not-sent compression is applied. 823 The decompressor restores the field value with the Target Value 824 stored in the matched Rule identified by the received Rule ID. 826 6.5.2. value-sent CDA 828 The value-sent action is generally used when the field value is not 829 known by both Compressor and Decompressor. The value is sent in the 830 compressed message header. Both Compressor and Decompressor MUST 831 know the size of the field, either implicitly (the size is known by 832 both sides) or by explicitly indicating the length in the Compression 833 Residue, as defined in Section 6.5. This function is generally used 834 with the "ignore" MO. 836 6.5.3. mapping-sent CDA 838 The mapping-sent is used to send a smaller index (the index into the 839 Target Value list of values) instead of the original value. This 840 function is used together with the "match-mapping" MO. 842 On the compressor side, the match-mapping Matching Operator searches 843 the TV for a match with the header field value and the mapping-sent 844 CDA appends the corresponding index to the Compression Residue to be 845 sent. On the decompressor side, the CDA uses the received index to 846 restore the field value by looking up the list in the TV. 848 The number of bits sent is the minimal size for coding all the 849 possible indices. 851 6.5.4. LSB CDA 853 The LSB action is used together with the "MSB(x)" MO to avoid sending 854 the higher part of the packet field if that part is already known by 855 the receiving end. A length can be specified in the rule to indicate 856 how many bits have to be sent. If the length is not specified, the 857 number of bits sent is the original header field length minus the 858 length specified in the MSB(x) MO. 860 The compressor sends the Least Significant Bits (e.g. LSB of the 861 length field). The decompressor combines the value received with the 862 Target Value depending on the field type. 864 If this action needs to be done on a variable length field, the size 865 of the Compression Residue in bytes MUST be sent as described in 866 Section 6.5. 868 6.5.5. DEViid, APPiid CDA 870 These functions are used to process respectively the Dev and the App 871 Interface Identifiers (Deviid and Appiid) of the IPv6 addresses. 872 Appiid CDA is less common since current LPWAN technologies frames 873 contain a single address, which is the Dev's address. 875 The IID value MAY be computed from the Device ID present in the Layer 876 2 header, or from some other stable identifier. The computation is 877 specific for each LPWAN technology and MAY depend on the Device ID 878 size. 880 In the Downlink direction, these Deviid CDA is used to determine the 881 L2 addresses used by the LPWAN. 883 6.5.6. Compute-* 885 Some fields are elided during compression and reconstructed during 886 decompression. This is the case for length and Checksum, so: 888 o compute-length: computes the length assigned to this field. This 889 CDA MAY be used to compute IPv6 length or UDP length. 891 o compute-checksum: computes a checksum from the information already 892 received by the SCHC C/D. This field MAY be used to compute UDP 893 checksum. 895 7. Fragmentation 897 7.1. Overview 899 In LPWAN technologies, the L2 data unit size typically varies from 900 tens to hundreds of bytes. The SCHC F/R (Fragmentation /Reassembly) 901 MAY be used either because after applying SCHC C/D or when SCHC C/D 902 is not possible the entire SCHC Packet still exceeds the L2 data 903 unit. 905 The SCHC F/R functionality defined in this document has been designed 906 under the assumption that data unit out-of- sequence delivery will 907 not happen between the entity performing fragmentation and the entity 908 performing reassembly. This assumption allows reducing the 909 complexity and overhead of the SCHC F/R mechanism. 911 To adapt the SCHC F/R to the capabilities of LPWAN technologies is 912 required to enable optional SCHC Fragment retransmission and to allow 913 a stepper delivery for the reliability of SCHC Fragments. This 914 document does not make any decision with regard to which SCHC 915 Fragment delivery reliability mode will be used over a specific LPWAN 916 technology. These details will be defined in other technology- 917 specific documents. 919 7.2. Fragmentation Tools 921 This subsection describes the different tools that are used to enable 922 the SCHC F/R functionality defined in this document, such as fields 923 in the SCHC F/R header frames (see the related formats in 924 Section 7.4), and the different parameters supported in the 925 reliability modes such as timers and parameters. 927 o Rule ID. The Rule ID is present in the SCHC Fragment header and 928 in the SCHC ACK header format. The Rule ID in a SCHC fragment 929 header is used to identify that a SCHC Fragment is being carried, 930 which SCHC F/R reliability mode is used and which window size is 931 used. The Rule ID in the SCHC F/R header also allows interleaving 932 non-fragmented 933 packets and SCHC Fragments that carry other SCHC Packets. The 934 Rule ID in an SCHC ACK identifies the message as an SCHC ACK. 936 o Fragment Compressed Number (FCN). The FCN is included in all SCHC 937 Fragments. This field can be understood as a truncated, 938 efficient representation of a larger-sized fragment number, and 940 does not carry an absolute SCHC Fragment number. There are two 941 FCN reserved values that are used for controlling the SCHC F/R 942 process, as described next: 944 * The FCN value with all the bits equal to 1 (All-1) denotes the 945 last SCHC Fragment of a packet. The last window of a packet is 946 called an All-1 window. 948 * The FCN value with all the bits equal to 0 (All-0) denotes the 949 last SCHC Fragment of a window that is not the last one of the 950 packet. Such a window is called an All-0 window. 952 The rest of the FCN values are assigned in a sequentially 953 decreasing order, which has the purpose to avoid possible 954 ambiguity for the receiver that might arise under certain 955 conditions. In the SCHC Fragments, this field is an unsigned 956 integer, with a size of N bits. In the No-ACK mode, it is set to 957 1 bit (N=1), All-0 is used in all SCHC Fragments and All-1 for the 958 last one. For the other reliability modes, it is recommended to 959 use a number of bits (N) equal to or greater than 3. 960 Nevertheless, the appropriate value of N MUST be defined in the 961 corresponding technology-specific profile documents. For windows 962 that are not the last one from a SCHC Fragmented packet, the FCN 963 for the last SCHC Fragment in such windows is an All-0. This 964 indicates that the window is finished and communication proceeds 965 according to the reliability mode in use. The FCN for the last 966 SCHC Fragment in the last window is an All-1, indicating the last 967 SCHC Fragment of the SCHC Packet. It is also important to note 968 that, in the No-ACK mode or when N=1, the last SCHC Fragment of 969 the packet will carry a FCN equal to 1, while all previous SCHC 970 Fragments will carry a FCN to 0. For further details see 971 Section 7.5. The highest FCN in the window, denoted MAX_WIND_FCN, 972 MUST be a value equal to or smaller than 2^N-2. (Example for N=5, 973 MAX_WIND_FCN MAY be set to 23, then subsequent FCNs are set 974 sequentially and in decreasing order, and the FCN will wrap from 0 975 back to 23). 977 o Datagram Tag (DTag). The DTag field, if present, is set to the 978 same value for all SCHC Fragments carrying the same SCHC 979 packet, and to different values for different SCHC Packets. Using 980 this field, the sender can interleave fragments from different 981 SCHC Packets, while the receiver can still tell them apart. In 982 the SCHC Fragment formats, the size of the DTag field is T bits, 983 which MAY be set to a value greater than or equal to 0 bits. For 984 each new SCHC Packet processed by the sender, DTag MUST be 985 sequentially increased, from 0 to 2^T - 1 wrapping back from 2^T - 986 1 to 0. In the SCHC ACK format, DTag carries the same value as 987 the DTag field in the SCHC Fragments for which this SCHC ACK is 988 intended. When there is no Dtag, there can be only 1 SCHC Packet 989 in transist. And only after all its fragments have been 990 transmitted another SCHC Packet could be sent. The length of 991 DTag, denoted T is not given in this document because is technolgy 992 dependant, and will be defined in the corresponding technology- 993 documents. DTag is based on the number of simultaneous packets 994 supported. 996 o W (window): W is a 1-bit field. This field carries the same value 997 for all SCHC Fragments of a window, and it is complemented for the 998 next window. The initial value for this field is 0. In the SCHC 999 ACK format, this field also has a size of 1 bit. In all SCHC 1000 ACKs, the W bit carries the same value as the W bit carried by the 1001 SCHC Fragments whose reception is being positively or negatively 1002 acknowledged by the SCHC ACK. 1004 o Message Integrity Check (MIC). This field is computed by the 1005 sender over the complete SCHC Packet and before SCHC 1006 fragmentation. The MIC allows the receiver to check errors in the 1007 reassembled packet, while it also enables compressing the UDP 1008 checksum by use of SCHC compression. The CRC32 as 0xEDB88320 1009 (i.e. the reverse representation of the polynomial used e.g. in 1010 the Ethernet standard [RFC3385]) is recommended as the default 1011 algorithm for computing the MIC. Nevertheless, other algorithms 1012 MAY be required and are defined in the technology-specific 1013 documents as well as the length in bits of the MIC used. 1015 o C (MIC checked): C is a 1-bit field. This field is used in the 1016 SCHC ACK packets to report the outcome of the MIC check, i.e. 1017 whether the reassembled packet was correctly received or not. A 1018 value of 1 represents a positive MIC check at the receiver side 1019 (i.e. the MIC computed by the receiver matches the received MIC). 1021 o Retransmission Timer. A SCHC Fragment sender uses it after the 1022 transmission of a window to detect a transmission error of the 1023 SCHC ACK corresponding to this window. Depending on the 1024 reliability mode, it will lead to a request an SCHC ACK 1025 retransmission (in ACK-Always mode) or it will trigger the 1026 transmission of the next window (in ACK-on-Error mode). The 1027 duration of this timer is not defined in this document and MUST be 1028 defined in the corresponding technology documents. 1030 o Inactivity Timer. A SCHC Fragment receiver uses it to take action 1031 when there is a problem in the transmission of SCHC fragments. 1032 Such a problem could be detected by the receiver not getting a 1033 single SCHC Fragment during a given period of time or not getting 1034 a given number of packets in a given period of time. When this 1035 happens, an Abort message will be sent (see related text later in 1036 this section). Initially, and each time a SCHC Fragment is 1037 received, the timer is reinitialized. The duration of this timer 1038 is not defined in this document and MUST be defined in the 1039 specific technology document. 1041 o Attempts. This counter counts the requests for a missing SCHC 1042 ACK. When it reaches the value MAX_ACK_REQUESTS, the sender 1043 assume there are recurrent SCHC Fragment transmission errors and 1044 determines that an Abort is needed. The default value offered 1045 MAX_ACK_REQUESTS is not stated in this document, and it is 1046 expected to be defined in the specific technology document. The 1047 Attempts counter is defined per window. It is initialized each 1048 time a new window is used. 1050 o Bitmap. The Bitmap is a sequence of bits carried in an SCHC ACK. 1051 Each bit in the Bitmap corresponds to a SCHC fragment of the 1052 current window, and provides feedback on whether the SCHC Fragment 1053 has been received or not. The right-most position on the Bitmap 1054 reports if the All-0 or All-1 fragment has been received or not. 1055 Feedback on the SCHC fragment with the highest FCN value is 1056 provided by the bit in the left-most position of the Bitmap. In 1057 the Bitmap, a bit set to 1 indicates that the SCHC Fragment of FCN 1058 corresponding to that bit position has been correctly sent and 1059 received. The text above describes the internal representation of 1060 the Bitmap. When inserted in the SCHC ACK for transmission from 1061 the receiver to the sender, the Bitmap MAY be truncated for 1062 energy/bandwidth optimisation, see more details in 1063 Section 7.4.3.1. 1065 o Abort. On expiration of the Inactivity timer, or when Attempts 1066 reached MAX_ACK_REQUESTS or upon an occurrence of some other 1067 error, the sender or the receiver MUST use the Abort. When the 1068 receiver needs to abort the on-going SCHC Fragmented packet 1069 transmission, it sends the Receiver-Abort format. When the sender 1070 needs to abort the transmission, it sends the Sender-Abort format. 1071 None of the Abort are acknowledged. 1073 o Padding (P). If it is needed, the number of bits used for padding 1074 is not defined and depends on the size of the Rule ID, DTag and 1075 FCN fields, and on the L2 payload size (see Section 8). Some SCHC 1076 ACKs are byte-aligned and do not need padding (see 1077 Section 7.4.3.1). 1079 7.3. Reliability modes 1081 This specification defines three reliability modes: No-ACK, ACK- 1082 Always, and ACK-on-Error. ACK-Always and ACK-on-Error operate on 1083 windows of SCHC Fragments. A window of SCHC Fragments is a subset of 1084 the full set of SCHC Fragments needed to carry a packet or an SCHC 1085 Packet. 1087 o No-ACK. No-ACK is the simplest SCHC Fragment reliability mode. 1088 The receiver does not generate overhead in the form of 1089 acknowledgments (ACKs). However, this mode does not enhance 1090 reliability beyond that offered by the underlying LPWAN 1091 technology. In the No-ACK mode, the receiver MUST NOT issue SCHC 1092 ACKs. See further details in Section 7.5.1. 1094 o ACK-Always. The ACK-Always mode provides flow control using a 1095 window scheme. This mode is also able to handle long bursts of 1096 lost SCHC Fragments since detection of such events can be done 1097 before the end of the SCHC Packet transmission as long as the 1098 window size is short enough. However, such benefit comes at the 1099 expense of SCHC ACK use. In ACK-Always the receiver sends an SCHC 1100 ACK after a window of SCHC Fragments has been received, where a 1101 window of SCHC Fragments is a subset of the whole number of SCHC 1102 Fragments needed to carry a complete SCHC Packet. The SCHC ACK is 1103 used to inform the sender if a SCHC fragment in the actual window 1104 has been lost or well received. Upon an SCHC ACK reception, the 1105 sender retransmits the lost SCHC Fragments. When an SCHC ACK is 1106 lost and the sender has not received it before the expiration of 1107 the Retransmission Timer, the sender uses an SCHC ACK request by 1108 sending the All-0 empty SCHC Fragment when it is not the last 1109 window and the ALL-1 empty Fragment when it is the last window. 1110 The maximum number of SCHC ACK requests is MAX_ACK_REQUESTS. If 1111 the MAX_ACK_REQUEST is reached the transmission needs to be 1112 Aborted. See further details in Section 7.5.2. 1114 o ACK-on-Error. The ACK-on-Error mode is suitable for links 1115 offering relatively low L2 data unit loss probability. In this 1116 mode, the SCHC Fragment receiver reduces the number of SCHC ACKs 1117 transmitted, which MAY be especially beneficial in asymmetric 1118 scenarios. Because the SCHC Fragments use the uplink of the 1119 underlying LPWAN technology, which has higher capacity than 1120 downlink. The receiver transmits an SCHC ACK only after the 1121 complete window transmission and if at least one SCHC Fragment of 1122 this window has been lost. An exception to this behavior is in 1123 the last window, where the receiver MUST transmit an SCHC ACK, 1124 including the C bit set based on the MIC checked result, even if 1125 all the SCHC Fragments of the last window have been correctly 1126 received. The SCHC ACK gives the state of all the SCHC Fragments 1127 (received or lost). Upon an SCHC ACK reception, the sender 1128 retransmits the lost SCHC Fragments. If an SCHC ACK is not 1129 transmitted back by the receiver at the end of a window, the 1130 sender assumes that all SCHC Fragments have been correctly 1131 received. When the SCHC ACK is lost, the sender assumes that all 1132 SCHC Fragments covered by the lost SCHC ACK have been successfully 1133 delivered, so the sender continues transmitting the next window of 1134 SCHC Fragments. If the next SCHC Fragments received belong to the 1135 next window, the receiver will abort the on-going fragmented 1136 packet transmission. See further details in Section 7.5.3. 1138 The same reliability mode MUST be used for all SCHC Fragments of an 1139 SCHC Packet. The decision on which reliability mode will be used and 1140 whether the same reliability mode applies to all SCHC Packets is an 1141 implementation problem and is out of the scope of this document. 1143 Note that the reliability mode choice is not necessarily tied to a 1144 particular characteristic of the underlying L2 LPWAN technology, e.g. 1145 the No-ACK mode MAY be used on top of an L2 LPWAN technology with 1146 symmetric characteristics for uplink and downlink. This document 1147 does not make any decision as to which SCHC Fragment reliability 1148 mode(s) are supported by a specific LPWAN technology. 1150 Examples of the different reliability modes described are provided in 1151 Appendix B. 1153 7.4. Fragmentation Formats 1155 This section defines the SCHC Fragment format, the All-0 and All-1 1156 formats, the SCHC ACK format and the Abort formats. 1158 7.4.1. Fragment format 1160 A SCHC Fragment comprises a SCHC Fragment header, a SCHC Fragment 1161 payload and padding bits (if needed). A SCHC Fragment conforms to 1162 the general format shown in Figure 11. The SCHC Fragment payload 1163 carries a subset of SCHC Packet. A SCHC Fragment is the payload of 1164 the L2 protocol data unit (PDU). Padding MAY be added in SCHC 1165 Fragments and in SCHC ACKs if necessary, therefore a padding field is 1166 optional (this is explicitly indicated in Figure 11 for the sake of 1167 illustration clarity. 1169 +-----------------+-----------------------+~~~~~~~~~~~~~~~ 1170 | Fragment Header | Fragment payload | padding (opt.) 1171 +-----------------+-----------------------+~~~~~~~~~~~~~~~ 1173 Figure 11: Fragment general format. Presence of a padding field is 1174 optional 1176 In ACK-Always or ACK-on-Error, SCHC Fragments except the last one 1177 SHALL conform the detailed format defined in Figure 12. The total 1178 size of the fragment header is not byte aligned. 1180 |---Fragmentation Header----| 1181 |-- T --|1|-- N --| 1182 +-- ... --+- ... -+-+- ... -+--------...-------+ 1183 | Rule ID | DTag |W| FCN | Fragment payload | 1184 +-- ... --+- ... -+-+- ... -+--------...-------+ 1186 Figure 12: Fragment Detailed Format for Fragments except the Last 1187 One, ACK-Always and ACK-on-Error 1189 In the No-ACK mode, SCHC Fragments except the last one SHALL conform 1190 to the detailed format defined in Figure 13. The total size of the 1191 fragment header is not byte aligned. 1193 |---Fragmentation Header---| 1194 |-- T --|-- N --| 1195 +-- ... --+- ... -+- ... -+--------...-------+ 1196 | Rule ID | DTag | FCN | Fragment payload | 1197 +-- ... --+- ... -+- ... -+--------...-------+ 1199 Figure 13: Fragment Detailed Format for Fragments except the Last 1200 One, No-ACK mode 1202 In all these cases, the total size of the fragment header is not byte 1203 aligned. 1205 7.4.2. All-1 and All-0 formats 1207 The All-0 format is used for sending the last SCHC Fragment of a 1208 window that is not the last window of the packet. 1210 |-- T --|1|-- N --| 1211 +-- ... --+- ... -+-+- ... -+--- ... ---+ 1212 | Rule ID | DTag |W| 0..0 | payload | 1213 +-- ... --+- ... -+-+- ... -+--- ... ---+ 1215 Figure 14: All-0 fragment detailed format 1217 The All-0 empty fragment format is used by a sender to request the 1218 retransmission of an SCHC ACK by the receiver. It is only used in 1219 ACK-Always mode. 1221 |-- T --|1|-- N --| 1222 +-- ... --+- ... -+-+- ... -+ 1223 | Rule ID | DTag |W| 0..0 | (no payload) 1224 +-- ... --+- ... -+-+- ... -+ 1226 Figure 15: All-0 empty fragment detailed format 1228 In the No-ACK mode, the last SCHC Fragment of an IPv6 datagram SHALL 1229 contain a SCHC Fragment header that conforms to the detaield format 1230 shown in Figure 16. 1232 |-- T --|-N=1-| 1233 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 1234 | Rule ID | DTag | 1 | MIC | payload | 1235 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 1237 Figure 16: All-1 Fragment Detailed Format for the Last Fragment, No- 1238 ACK mode 1240 In any of the Window modes, the last fragment of an IPv6 datagram 1241 SHALL contain a SCHC Fragment header that conforms to the detailed 1242 format shown in Figure 17. The total size of the SCHC Fragment 1243 header in this format is not byte aligned. 1245 |-- T --|1|-- N --| 1246 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 1247 | Rule ID | DTag |W| 11..1 | MIC | payload | 1248 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 1249 (FCN) 1251 Figure 17: All-1 Fragment Detailed Format for the Last Fragment, ACK- 1252 Always or ACK-on-Error 1254 In either ACK-Always or ACK-on-Error, in order to request a 1255 retransmission of the SCHC ACK for the All-1 window, the fragment 1256 sender uses the format shown in Figure 18. The total size of the 1257 SCHC Fragment header in not byte aligned. 1259 |-- T --|1|-- N --| 1260 +-- ... --+- ... -+-+- ... -+---- ... ----+ 1261 | Rule ID | DTag |W| 1..1 | MIC | (no payload) 1262 +-- ... --+- ... -+-+- ... -+---- ... ----+ 1264 Figure 18: All-1 for Retries format, also called All-1 empty 1266 The values for Fragmentation Header, N, T and the length of MIC are 1267 not specified in this document, and SHOULD be determined in other 1268 documents (e.g. technology-specific profile documents). 1270 7.4.3. SCHC ACK format 1272 The format of an SCHC ACK that acknowledges a window that is not the 1273 last one (denoted as All-0 window) is shown in Figure 19. 1275 |-- T --|1| 1276 +---- ... --+- ... -+-+---- ... -----+ 1277 | Rule ID | DTag |W|encoded Bitmap| (no payload) 1278 +---- ... --+- ... -+-+---- ... -----+ 1280 Figure 19: ACK format for All-0 windows 1282 To acknowledge the last window of a packet (denoted as All-1 window), 1283 a C bit (i.e. MIC checked) following the W bit is set to 1 to 1284 indicate that the MIC check computed by the receiver matches the MIC 1285 present in the All-1 fragment. If the MIC check fails, the C bit is 1286 set to 0 and the Bitmap for the All-1 window follows. 1288 |-- T --|1|1| 1289 +---- ... --+- ... -+-+-+ 1290 | Rule ID | DTag |W|1| (MIC correct) 1291 +---- ... --+- ... -+-+-+ 1293 +---- ... --+- ... -+-+-+----- ... -----+ 1294 | Rule ID | DTag |W|0|encoded Bitmap |(MIC Incorrect) 1295 +---- ... --+- ... -+-+-+----- ... -----+ 1296 C 1298 Figure 20: Format of an SCHC ACK for All-1 windows 1300 7.4.3.1. Bitmap Encoding 1302 The Bitmap is transmitted by a receiver as part of the SCHC ACK 1303 format. An SCHC ACK message MAY include padding at the end to align 1304 its number of transmitted bits to a multiple of 8 bits. 1306 Note that the SCHC ACK sent a response to an All-1 fragment including 1307 the C bit. Therefore, the window size and thus the encoded Bitmap 1308 size need to be determined to take into account the available space 1309 in the layer two frame payload, where there will be 1 bit less for an 1310 SCHC ACK sent in response to an All-1 fragment than in other SCHC 1311 ACKs. Note that the maximum number of SCHC Fragments of the last 1312 window is one unit smaller than that of the previous windows. 1314 When the receiver transmits an encoded Bitmap with a SCHC Fragment 1315 that has not been sent during the transmission, the sender will Abort 1316 the transmission. 1318 |---- Bitmap bits ----| 1319 | Rule ID | DTag |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| 1320 |--- byte boundary ----| 1 byte next | 1 byte next | 1322 Figure 21: A non-encoded Bitmap 1324 In order to reduce the resulting frame size, the encoded Bitmap is 1325 shortened by applying the following algorithm: all the right-most 1326 contiguous bytes in the encoded Bitmap that have all their bits set 1327 to 1 MUST NOT be transmitted. Because the SCHC Fragment sender knows 1328 the actual Bitmap size, it can reconstruct the original Bitmap with 1329 the trailing 1 bit optimized away. In the example shown in 1330 Figure 22, the last 2 bytes of the Bitmap shown in Figure 21 1331 comprises bits that are all set to 1, therefore they are not sent. 1333 |-- T --|1| 1334 +---- ... --+- ... -+-+-+-+ 1335 | Rule ID | DTag |W|1|0| 1336 +---- ... --+- ... -+-+-+-+ 1337 |---- byte boundary -----| 1339 Figure 22: Optimized Bitmap format 1341 Figure 23 shows an example of an SCHC ACK with FCN ranging from 6 1342 down to 0, where the Bitmap indicates that the second and the fifth 1343 SCHC Fragments have not been correctly received. 1345 6 5 4 3 2 1 0 (*) 1346 |-- T --|1| 1347 +---------+-------+-+-+-+-+-+-+-+-----+ 1348 | Rule ID | DTag |W|1|0|1|1|0|1|all-0| Bitmap(before tx) 1349 +---------+-------+-+-+-+-+-+-+-+-----+ 1350 |<-- byte boundary ->|<---- 1 byte---->| 1351 (*)=(FCN values) 1353 +---------+------+-+-+-+-+-+-+-+-----+~~ 1354 | Rule ID | DTag |W|1|0|1|1|0|1|all-0|Padding(opt.) encoded Bitmap 1355 +---------+------+-+-+-+-+-+-+-+-----+~~ 1356 |<-- byte boundary ->|<---- 1 byte---->| 1358 Figure 23: Example of a Bitmap before transmission, and the 1359 transmitted one, in any window except the last one 1361 Figure 24 shows an example of an SCHC ACK with FCN ranging from 6 1362 down to 0, where the Bitmap indicates that the MIC check has failed 1363 but there are no missing SCHC Fragments. 1365 |-Fragmentation Header-|6 5 4 3 2 1 7 (*) 1366 |-- T --|1| 1367 | Rule ID | DTag |W|0|1|1|1|1|1|1|1|padding| Bitmap (before tx) 1368 |---- byte boundary -----| 1 byte next | 1369 C 1370 +---- ... --+-... -+-+-+-+ 1371 | Rule ID | DTag |W|0|1| encoded Bitmap 1372 +---- ... --+-... -+-+-+-+ 1373 |---- byte boundary -----| 1374 (*) = (FCN values indicating the order) 1376 Figure 24: Example of the Bitmap in ACK-Always or ACK-on-Error for 1377 the last window, for N=3) 1379 7.4.4. Abort formats 1381 Abort are coded as exceptions to the previous coding, a specific 1382 format is defined for each direction. When a SCHC Fragment sender 1383 needs to abort the transmission, it sends the Sender-Abort format 1384 Figure 25, that is an All-1 fragment with no MIC or payload. In 1385 regular cases All-1 fragment contains at least a MIC value. This 1386 absence of the MIC value indicates an Abort. 1388 When a SCHC Fragment receiver needs to abort the on-going SCHC 1389 Fragmented packet transmission, it transmits the Receiver- Abort 1390 format Figure 26, creating an exception in the encoded Bitmap coding. 1392 Encoded Bitmap avoid sending the rigth most bits of the Bitmap set to 1393 1. Abort is coded as an SCHC ACK message with a Bitmap set to 1 1394 until the byte boundary, followed by an extra 0xFF byte. Such 1395 message never occurs in a regular acknowledgement and is view as an 1396 abort. 1398 None of these messages are not acknowledged nor retransmitted. 1400 The sender uses the Sender-Abort when the MAX_ACK_REQUEST is reached. 1401 The receiver uses the Receiver-Abort when the Inactivity timer 1402 expires, or in the ACK-on-Error mode, SCHC ACK is lost and the sender 1403 transmits SCHC Fragments of a new window. Some other cases for Abort 1404 are explained in the Section 7.5 or Appendix C. 1406 |-- Fragmentation Header ---|--- 1 byte ----| 1407 +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+ 1408 | Rule ID | DTag |W| FCN | FF | (no MIC & no payload) 1409 +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+ 1411 Figure 25: Sender-Abort format. All FCN fields in this format are 1412 set to 1 1414 |----- byte boundary ------|---- 1 byte ---| 1416 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Rule ID | DTag |W| 1..1| FF | 1418 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 Figure 26: Receiver-Abort format 1422 7.5. Baseline mechanism 1424 If after applying SCHC header compression (or when SCHC header 1425 compression is not possible) the SCHC Packet does not fit within the 1426 payload of a single L2 data unit, the SCHC Packet SHALL be broken 1427 into SCHC Fragments and the fragments SHALL be sent to the fragment 1428 receiver. The fragment receiver needs to identify all the SCHC 1429 Fragments that belong to a given SCHC Packet. To this end, the 1430 receiver SHALL use: 1432 o The sender's L2 source address (if present), 1434 o The destination's L2 address (if present), 1436 o Rule ID, 1437 o DTag (if present). 1439 Then, the fragment receiver MAY determine the SCHC Fragment 1440 reliability mode that is used for this SCHC Fragment based on the 1441 Rule ID in that fragment. 1443 After a SCHC Fragment reception, the receiver starts constructing the 1444 SCHC Packet. It uses the FCN and the arrival order of each SCHC 1445 Fragment to determine the location of the individual fragments within 1446 the SCHC Packet. For example, the receiver MAY place the fragment 1447 payload within a payload datagram reassembly buffer at the location 1448 determined from the FCN, the arrival order of the SCHC Fragments, and 1449 the fragment payload sizes. In Window mode, the fragment receiver 1450 also uses the W bit in the received SCHC Fragments. Note that the 1451 size of the original, unfragmented packet cannot be determined from 1452 fragmentation headers. 1454 Fragmentation functionality uses the FCN value to transmit the SCHC 1455 Fragments. It has a length of N bits where the All-1 and All-0 FCN 1456 values are used to control the fragmentation transmission. The rest 1457 of the FCN numbers MUST be assigned sequentially in a decreasing 1458 order, the first FCN of a window is RECOMMENDED to be MAX_WIND_FCN, 1459 i.e. the highest possible FCN value depending on the FCN number of 1460 bits. 1462 In all modes, the last SCHC Fragment of a packet MUST contain a MIC 1463 which is used to check if there are errors or missing SCHC Fragments 1464 and MUST use the corresponding All-1 fragment format. Note that a 1465 SCHC Fragment with an All-0 format is considered the last SCHC 1466 Fragment of the current window. 1468 If the receiver receives the last fragment of a datagram (All-1), it 1469 checks for the integrity of the reassembled datagram, based on the 1470 MIC received. In No-ACK, if the integrity check indicates that the 1471 reassembled datagram does not match the original datagram (prior to 1472 fragmentation), the reassembled datagram MUST be discarded. In 1473 Window mode, a MIC check is also performed by the fragment receiver 1474 after reception of each subsequent SCHC Fragment retransmitted after 1475 the first MIC check. 1477 There are three reliability modes: No-ACK, ACK-Always and ACK-on- 1478 Error. In ACK-Always and ACK-on-Error, a jumping window protocol 1479 uses two windows alternatively, identified as 0 and 1. A SCHC 1480 Fragment with all FCN bits set to 0 (i.e. an All-0 fragment) 1481 indicates that the window is over (i.e. the SCHC Fragment is the last 1482 one of the window) and allows to switch from one window to the next 1483 one. The All-1 FCN in a SCHC Fragment indicates that it is the last 1484 fragment of the packet being transmitted and therefore there will not 1485 be another window for this packet. 1487 7.5.1. No-ACK 1489 In the No-ACK mode, there is no feedback communication from the 1490 fragment receiver. The sender will send all the SCHC fragments of a 1491 packet without any possibility of knowing if errors or losses have 1492 occurred. As, in this mode, there is no need to identify specific 1493 SCHC Fragments, a one-bit FCN MAY be used. Consequently, the FCN 1494 All-0 value is used in all SCHC fragments except the last one, which 1495 carries an All-1 FCN and the MIC. The receiver will wait for SCHC 1496 Fragments and will set the Inactivity timer. The receiver will use 1497 the MIC contained in the last SCHC Fragment to check for errors. 1498 When the Inactivity Timer expires or if the MIC check indicates that 1499 the reassembled packet does not match the original one, the receiver 1500 will release all resources allocated to reassembling this packet. 1501 The initial value of the Inactivity Timer will be determined based on 1502 the characteristics of the underlying LPWAN technology and will be 1503 defined in other documents (e.g. technology-specific profile 1504 documents). 1506 7.5.2. ACK-Always 1508 In ACK-Always, the sender transmits SCHC Fragments by using the two- 1509 jumping-windows procedure. A delay between each SCHC fragment can be 1510 added to respect local regulations or other constraints imposed by 1511 the applications. Each time a SCHC fragment is sent, the FCN is 1512 decreased by one. When the FCN reaches value 0 and there are more 1513 SCHC Fragments to be sent after, the sender transmits the last SCHC 1514 Fragment of this window using the All-0 fragment format, it starts 1515 the transmitted is the last SCHC Fragment of the SCHC Packet, the 1516 sender uses the All-1 fragment format, which includes a MIC. The 1517 sender sets the Retransmission Timer and waits for the SCHC ACK to 1518 know if transmission errors have occured. 1520 The Retransmission Timer is dimensioned based on the LPWAN technology 1521 in use. When the Retransmission Timer expires, the sender sends an 1522 All-0 empty (resp. All-1 empty) fragment to request again the SCHC 1523 ACK for the window that ended with the All-0 (resp. All-1) fragment 1524 just sent. The window number is not changed. 1526 After receiving an All-0 or All-1 fragment, the receiver sends an 1527 SCHC ACK with an encoded Bitmap reporting whether any SCHC fragments 1528 have been lost or not. When the sender receives an SCHC ACK, it 1529 checks the W bit carried by the SCHC ACK. Any SCHC ACK carrying an 1530 unexpected W bit value is discarded. If the W bit value of the 1531 received SCHC ACK is correct, the sender analyzes the rest of the 1532 SCHC ACK message, such as the encoded Bitmap and the MIC. If all the 1533 SCHC Fragments sent for this window have been well received, and if 1534 at least one more SCHC Fragment needs to be sent, the sender advances 1535 its sending window to the next window value and sends the next SCHC 1536 Fragments. If no more SCHC Fragments have to be sent, then the SCHC 1537 fragmented packet transmission is finished. 1539 However, if one or more SCHC Fragments have not been received as per 1540 the SCHC ACK (i.e. the corresponding bits are not set in the encoded 1541 Bitmap) then the sender resends the missing SCHC Fragments. When all 1542 missing SCHC Fragments have been retransmitted, the sender starts the 1543 Retransmission Timer, even if an All-0 or an All-1 has not been sent 1544 as part of this retransmission and waits for an SCHC ACK. Upon 1545 receipt of the SCHC ACK, if one or more SCHC Fragments have not yet 1546 been received, the counter Attempts is increased and the sender 1547 resends the missing SCHC Fragments again. When Attempts reaches 1548 MAX_ACK_REQUESTS, the sender aborts the on-going SCHC Fragmented 1549 packet transmission by sending an Abort message and releases any 1550 resources for transmission of the packet. The sender also aborts an 1551 on-going SCHC Fragmented packet transmission when a failed MIC check 1552 is reported by the receiver or when a SCHC Fragment that has not been 1553 sent is reported in the encoded Bitmap. 1555 On the other hand, at the beginning, the receiver side expects to 1556 receive window 0. Any SCHC Fragment received but not belonging to 1557 the current window is discarded. All SCHC Fragments belonging to the 1558 correct window are accepted, and the actual SCHC Fragment number 1559 managed by the receiver is computed based on the FCN value. The 1560 receiver prepares the encoded Bitmap to report the correctly received 1561 and the missing SCHC Fragments for the current window. After each 1562 SCHC Fragment is received the receiver initializes the Inactivity 1563 timer, if the Inactivity Timer expires the transmission is aborted. 1565 When an All-0 fragment is received, it indicates that all the SCHC 1566 Fragments have been sent in the current window. Since the sender is 1567 not obliged to always send a full window, some SCHC Fragment number 1568 not set in the receiver memory SHOULD not correspond to losses. The 1569 receiver sends the corresponding SCHC ACK, the Inactivity Timer is 1570 set and the transmission of the next window by the sender can start. 1572 If an All-0 fragment has been received and all SCHC Fragments of the 1573 current window have also been received, the receiver then expects a 1574 new Window and waits for the next SCHC Fragment. Upon receipt of a 1575 SCHC Fragment, if the window value has not changed, the received SCHC 1576 Fragments are part of a retransmission. A receiver that has already 1577 received a SCHC Fragment SHOULD discard it, otherwise, it updates the 1578 encoded Bitmap. If all the bits of the encoded Bitmap are set to 1579 one, the receiver MUST send an SCHC ACK without waiting for an All-0 1580 fragment and the Inactivity Timer is initialized. 1582 On the other hand, if the window value of the next received SCHC 1583 Fragment is set to the next expected window value, this means that 1584 the sender has received a correct encoded Bitmap reporting that all 1585 SCHC Fragments have been received. The receiver then updates the 1586 value of the next expected window. 1588 When an All-1 fragment is received, it indicates that the last SCHC 1589 Fragment of the packet has been sent. Since the last window is not 1590 always full, the MIC will be used to detect if all SCHC Fragments of 1591 the packet have been received. A correct MIC indicates the end of 1592 the transmission but the receiver MUST stay alive for an Inactivity 1593 Timer period to answer to any empty All-1 fragments the sender MAY 1594 send if SCHC ACKs sent by the receiver are lost. If the MIC is 1595 incorrect, some SCHC Fragments have been lost. The receiver sends 1596 the SCHC ACK regardless of successful SCHC Fragmented packet 1597 reception or not, the Inactitivity Timer is set. In case of an 1598 incorrect MIC, the receiver waits for SCHC Fragments belonging to the 1599 same window. After MAX_ACK_REQUESTS, the receiver will abort the on- 1600 going SCHC Fragmented packet transmission by transmitting a the 1601 Receiver-Abort format. The receiver also aborts upon Inactivity 1602 Timer expiration. 1604 7.5.3. ACK-on-Error 1606 The senders behavior for ACK-on-Error and ACK-Always are similar. 1607 The main difference is that in ACK-on-Error the SCHC ACK with the 1608 encoded Bitmap is not sent at the end of each window but only when at 1609 least one SCHC Fragment of the current window has been lost. Excepts 1610 for the last window where an SCHC ACK MUST be sent to finish the 1611 transmission. 1613 In ACK-on-Error, the Retransmission Timer expiration will be 1614 considered as a positive acknowledgment. This timer is set after 1615 sending an All-0 or an All-1 fragment. When the All-1 fragment has 1616 been sent, then the on-going SCHC F/R process is finished and the 1617 sender waits for the last SCHC ACK. If the Retransmission Timer 1618 expires while waiting for the SCHC ACK for the last window, an All-1 1619 empty MUST be sent to request the last SCHC ACK by the sender to 1620 complete the SCHC Fragmented packet transmission. When it expires 1621 the sender continue sending SCHC Fragments of the next window. 1623 If the sender receives an SCHC ACK, it checks the window value. SCHC 1624 ACKs with an unexpected window number are discarded. If the window 1625 number on the received encoded Bitmap is correct, the sender verifies 1626 if the receiver has received all SCHC fragments of the current 1627 window. When at least one SCHC Fragment has been lost, the counter 1628 Attempts is increased by one and the sender resends the missing SCHC 1629 Fragments again. When Attempts reaches MAX_ACK_REQUESTS, the sender 1630 sends an Abort message and releases all resources for the on-going 1631 SCHC Fragmented packet transmission. When the retransmission of the 1632 missing SCHC Fragments is finished, the sender starts listening for 1633 an SCHC ACK (even if an All-0 or an All-1 has not been sent during 1634 the retransmission) and initializes the Retransmission Timer. After 1635 sending an All-1 fragment, the sender listens for an SCHC ACK, 1636 initializes Attempts, and starts the Retransmission Timer. If the 1637 Retransmission Timer expires, Attempts is increased by one and an 1638 empty All-1 fragment is sent to request the SCHC ACK for the last 1639 window. If Attempts reaches MAX_ACK_REQUESTS, the sender aborts the 1640 on-going SCHC Fragmented packet transmission by transmitting the 1641 Sender-Abort fragment. 1643 Unlike the sender, the receiver for ACK-on-Error has a larger amount 1644 of differences compared with ACK-Always. First, an SCHC ACK is not 1645 sent unless there is a lost SCHC Fragment or an unexpected behavior. 1646 With the exception of the last window, where an SCHC ACK is always 1647 sent regardless of SCHC Fragment losses or not. The receiver starts 1648 by expecting SCHC Fragments from window 0 and maintains the 1649 information regarding which SCHC Fragments it receives. After 1650 receiving an SCHC Fragment, the Inactivity Timer is set. If no 1651 further SCHC Fragment are received and the Inactivity Timer expires, 1652 the SCHC Fragment receiver aborts the on-going SCHC Fragmented packet 1653 transmission by transmitting the Receiver-Abort data unit. 1655 Any SCHC Fragment not belonging to the current window is discarded. 1656 The actual SCHC Fragment number is computed based on the FCN value. 1657 When an All-0 fragment is received and all SCHC Fragments have been 1658 received, the receiver updates the expected window value and expects 1659 a new window and waits for the next SCHC Fragment. 1660 If the window value of the next SCHC Fragment has not changed, the 1661 received SCHC Fragment is a retransmission. A receiver that has 1662 already received an SCHC Fragment discard it. If all SCHC Fragments 1663 of a window (that is not the last one) have been received, the 1664 receiver does not send an SCHC ACK. While the receiver waits for the 1665 next window and if the window value is set to the next value, and if 1666 an All-1 fragment with the next value window arrived the receiver 1667 knows that the last SCHC Fragment of the packet has been sent. Since 1668 the last window is not always full, the MIC will be used to detect if 1669 all SCHC Fragments of the window have been received. A correct MIC 1670 check indicates the end of the SCHC Fragmented packet transmission. 1671 An ACK is sent by the SCHC Fragment receiver. In case of an 1672 incorrect MIC, the receiver waits for SCHC Fragments belonging to the 1673 same window or the expiration of the Inactivity Timer. The latter 1674 will lead the receiver to abort the on-going SCHC fragmented packet 1675 transmission. 1677 If after receiving an All-0 fragment the receiver missed some SCHC 1678 Fragments, the receiver uses an SCHC ACK with the encoded Bitmap to 1679 ask the retransmission of the missing fragments and expect to receive 1680 SCHC Fragments with the actual window. While waiting the 1681 retransmission an All-0 empty fragment is received, the receiver 1682 sends again the SCHC ACK with the encoded Bitmap, if the SCHC 1683 Fragments received belongs to another window or an All-1 fragment is 1684 received, the transmission is aborted by sending a Receiver-Abort 1685 fragment. Once it has received all the missing fragments it waits 1686 for the next window fragments. 1688 7.6. Supporting multiple window sizes 1690 For ACK-Always or ACK-on-Error, implementers MAY opt to support a 1691 single window size or multiple window sizes. The latter, when 1692 feasible, may provide performance optimizations. For example, a 1693 large window size SHOULD be used for packets that need to be carried 1694 by a large number of SCHC Fragments. However, when the number of 1695 SCHC Fragments required to carry a packet is low, a smaller window 1696 size, and thus a shorter Bitmap, MAY be sufficient to provide 1697 feedback on all SCHC Fragments. If multiple window sizes are 1698 supported, the Rule ID MAY be used to signal the window size in use 1699 for a specific packet transmission. 1701 Note that the same window size MUST be used for the transmission of 1702 all SCHC Fragments that belong to the same SCHC Packet. 1704 7.7. Downlink SCHC Fragment transmission 1706 In some LPWAN technologies, as part of energy-saving techniques, 1707 downlink transmission is only possible immediately after an uplink 1708 transmission. In order to avoid potentially high delay in the 1709 downlink transmission of a SCHC Fragmented datagram, the SCHC 1710 Fragment receiver MAY perform an uplink transmission as soon as 1711 possible after reception of a SCHC Fragment that is not the last one. 1712 Such uplink transmission MAY be triggered by the L2 (e.g. an L2 ACK 1713 sent in response to a SCHC Fragment encapsulated in a L2 frame that 1714 requires an L2 ACK) or it MAY be triggered from an upper layer. 1716 For downlink transmission of a SCHC Fragmented packet in ACK-Always 1717 mode, the SCHC Fragment receiver MAY support timer-based SCHC ACK 1718 retransmission. In this mechanism, the SCHC Fragment receiver 1719 initializes and starts a timer (the Inactivity Timer is used) after 1720 the transmission of an SCHC ACK, except when the SCHC ACK is sent in 1721 response to the last SCHC Fragment of a packet (All-1 fragment). In 1722 the latter case, the SCHC Fragment receiver does not start a timer 1723 after transmission of the SCHC ACK. 1725 If, after transmission of an SCHC ACK that is not an All-1 fragment, 1726 and before expiration of the corresponding Inactivity timer, the SCHC 1727 Fragment receiver receives a SCHC Fragment that belongs to the 1728 current window (e.g. a missing SCHC Fragment from the current window) 1729 or to the next window, the Inactivity timer for the SCHC ACK is 1730 stopped. However, if the Inactivity timer expires, the SCHC ACK is 1731 resent and the Inactivity timer is reinitialized and restarted. 1733 The default initial value for the Inactivity timer, as well as the 1734 maximum number of retries for a specific SCHC ACK, denoted 1735 MAX_ACK_RETRIES, are not defined in this document, and need to be 1736 defined in other documents (e.g. technology-specific profiles). The 1737 initial value of the Inactivity timer is expected to be greater than 1738 that of the Retransmission timer, in order to make sure that a 1739 (buffered) SCHC Fragment to be retransmitted can find an opportunity 1740 for that transmission. 1742 When the SCHC Fragment sender transmits the All-1 fragment, it starts 1743 its Retransmission Timer with a large timeout value (e.g. several 1744 times that of the initial Inactivity timer). If an SCHC ACK is 1745 received before expiration of this timer, the SCHC Fragment sender 1746 retransmits any lost SCHC Fragments reported by the SCHC ACK, or if 1747 the SCHC ACK confirms successful reception of all SCHC Fragments of 1748 the last window, the transmission of the SCHC Fragmented packet is 1749 considered complete. If the timer expires, and no SCHC ACK has been 1750 received since the start of the timer, the SCHC Fragment sender 1751 assumes that the All-1 fragment has been successfully received (and 1752 possibly, the last SCHC ACK has been lost: this mechanism assumes 1753 that the retransmission timer for the All-1 fragment is long enough 1754 to allow several SCHC ACK retries if the All-1 fragment has not been 1755 received by the SCHC Fragment receiver, and it also assumes that it 1756 is unlikely that several ACKs become all lost). 1758 8. Padding management 1760 Default padding is defined for L2 frame with a variable length of 1761 bytes. Padding is done twice, after compression and in the all-1 1762 fragmentation. 1764 In compression, the Compressed Header is generally not a multiple of 1765 bytes in size, but the payload following the Compressed Header is 1766 always a multiple of 8 bits (see Figure 4). If needed, padding bits 1767 can be added after the payload to reach the next byte boundary. 1768 Since the Compressed Header (through the Rule ID and the Compression 1769 Residue) tells its length and the payload is always a multiple of 8 1770 bits, the receiver can without ambiguity remove the padding bits, 1771 which never exceed 7 bits. 1773 SCHC F/R works on a byte aligned (i.e. padded SCHC Packet). 1774 Fragmentation header may not be aligned on byte boundary, but each 1775 fragment except the last one (All-1 fragment) must sent the maximum 1776 bits as possible. Only the last fragment need to introduce padding 1777 to reach the next boundary limit. Since the SCHC is known to be a 1778 multiple of 8 bits, the receiver can remove the extra bit to reach 1779 this limit. 1781 Default padding mechanism do not need to send the padding length and 1782 can lead to a maximum of 14 bits of padding. 1784 The padding is not mandatory and is optional to the technology- 1785 specific document to give a different solution. In this docuement 1786 there are some inputs on how to manage the padding. 1788 9. SCHC Compression for IPv6 and UDP headers 1790 This section lists the different IPv6 and UDP header fields and how 1791 they can be compressed. 1793 9.1. IPv6 version field 1795 This field always holds the same value. Therefore, in the rule, TV 1796 is set to 6, MO to "equal" and CDA to "not-sent". 1798 9.2. IPv6 Traffic class field 1800 If the DiffServ field does not vary and is known by both sides, the 1801 Field Descriptor in the rule SHOULD contain a TV with this well-known 1802 value, an "equal" MO and a "not-sent" CDA. 1804 Otherwise, two possibilities can be considered depending on the 1805 variability of the value: 1807 o One possibility is to not compress the field and send the original 1808 value. In the rule, TV is not set to any particular value, MO is 1809 set to "ignore" and CDA is set to "value-sent". 1811 o If some upper bits in the field are constant and known, a better 1812 option is to only send the LSBs. In the rule, TV is set to a 1813 value with the stable known upper part, MO is set to MSB(x) and 1814 CDA to LSB(y). 1816 9.3. Flow label field 1818 If the Flow Label field does not vary and is known by both sides, the 1819 Field Descriptor in the rule SHOULD contain a TV with this well-known 1820 value, an "equal" MO and a "not-sent" CDA. 1822 Otherwise, two possibilities can be considered: 1824 o One possibility is to not compress the field and send the original 1825 value. In the rule, TV is not set to any particular value, MO is 1826 set to "ignore" and CDA is set to "value-sent". 1828 o If some upper bits in the field are constant and known, a better 1829 option is to only send the LSBs. In the rule, TV is set to a 1830 value with the stable known upper part, MO is set to MSB(x) and 1831 CDA to LSB(y). 1833 9.4. Payload Length field 1835 This field can be elided for the transmission on the LPWAN network. 1836 The SCHC C/D recomputes the original payload length value. In the 1837 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is 1838 "compute-IPv6-length". 1840 If the payload length needs to be sent and does not need to be coded 1841 in 16 bits, the TV can be set to 0x0000, the MO set to MSB(16-s) 1842 where 's' is the number of bits to code the maximum length, and CDA 1843 is set to LSB(s). 1845 9.5. Next Header field 1847 If the Next Header field does not vary and is known by both sides, 1848 the Field Descriptor in the rule SHOULD contain a TV with this Next 1849 Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- 1850 sent". 1852 Otherwise, TV is not set in the Field Descriptor, MO is set to 1853 "ignore" and CDA is set to "value-sent". Alternatively, a matching- 1854 list MAY also be used. 1856 9.6. Hop Limit field 1858 The field behavior for this field is different for Uplink and 1859 Downlink. In Uplink, since there is no IP forwarding between the Dev 1860 and the SCHC C/D, the value is relatively constant. On the other 1861 hand, the Downlink value depends of Internet routing and MAY change 1862 more frequently. One neat way of processing this field is to use the 1863 Direction Indicator (DI) to distinguish both directions: 1865 o in the Uplink, elide the field: the TV in the Field Descriptor is 1866 set to the known constant value, the MO is set to "equal" and the 1867 CDA is set to "not-sent". 1869 o in the Downlink, send the value: TV is not set, MO is set to 1870 "ignore" and CDA is set to "value-sent". 1872 9.7. IPv6 addresses fields 1874 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 1875 long fields; one for the prefix and one for the Interface Identifier 1876 (IID). These fields SHOULD be compressed. To allow for a single 1877 rule being used for both directions, these values are identified by 1878 their role (DEV or APP) and not by their position in the frame 1879 (source or destination). 1881 9.7.1. IPv6 source and destination prefixes 1883 Both ends MUST be synchronized with the appropriate prefixes. For a 1884 specific flow, the source and destination prefixes can be unique and 1885 stored in the context. It can be either a link-local prefix or a 1886 global prefix. In that case, the TV for the source and destination 1887 prefixes contain the values, the MO is set to "equal" and the CDA is 1888 set to "not-sent". 1890 If the rule is intended to compress packets with different prefix 1891 values, match-mapping SHOULD be used. The different prefixes are 1892 listed in the TV, the MO is set to "match-mapping" and the CDA is set 1893 to "mapping-sent". See Figure 28 1895 Otherwise, the TV contains the prefix, the MO is set to "equal" and 1896 the CDA is set to "value-sent". 1898 9.7.2. IPv6 source and destination IID 1900 If the DEV or APP IID are based on an LPWAN address, then the IID can 1901 be reconstructed with information coming from the LPWAN header. In 1902 that case, the TV is not set, the MO is set to "ignore" and the CDA 1903 is set to "DEViid" or "APPiid". Note that the LPWAN technology 1904 generally carries a single identifier corresponding to the DEV. 1905 Therefore Appiid cannot be used. 1907 For privacy reasons or if the DEV address is changing over time, a 1908 static value that is not equal to the DEV address SHOULD be used. In 1909 that case, the TV contains the static value, the MO operator is set 1910 to "equal" and the CDF is set to "not-sent". [RFC7217] provides some 1911 methods that MAY be used to derive this static identifier. 1913 If several IIDs are possible, then the TV contains the list of 1914 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 1915 "mapping-sent". 1917 It MAY also happen that the IID variability only expresses itself on 1918 a few bytes. In that case, the TV is set to the stable part of the 1919 IID, the MO is set to "MSB" and the CDA is set to "LSB". 1921 Finally, the IID can be sent in extenso on the LPWAN. In that case, 1922 the TV is not set, the MO is set to "ignore" and the CDA is set to 1923 "value-sent". 1925 9.8. IPv6 extensions 1927 No rule is currently defined that processes IPv6 extensions. If such 1928 extensions are needed, their compression/decompression rules can be 1929 based on the MOs and CDAs described above. 1931 9.9. UDP source and destination port 1933 To allow for a single rule being used for both directions, the UDP 1934 port values are identified by their role (DEV or APP) and not by 1935 their position in the frame (source or destination). The SCHC C/D 1936 MUST be aware of the traffic direction (Uplink, Downlink) to select 1937 the appropriate field. The following rules apply for DEV and APP 1938 port numbers. 1940 If both ends know the port number, it can be elided. The TV contains 1941 the port number, the MO is set to "equal" and the CDA is set to "not- 1942 sent". 1944 If the port variation is on few bits, the TV contains the stable part 1945 of the port number, the MO is set to "MSB" and the CDA is set to 1946 "LSB". 1948 If some well-known values are used, the TV can contain the list of 1949 these values, the MO is set to "match-mapping" and the CDA is set to 1950 "mapping-sent". 1952 Otherwise the port numbers are sent over the LPWAN. The TV is not 1953 set, the MO is set to "ignore" and the CDA is set to "value-sent". 1955 9.10. UDP length field 1957 The UDP length can be computed from the received data. In that case, 1958 the TV is not set, the MO is set to "ignore" and the CDA is set to 1959 "compute-length". 1961 If the payload is small, the TV can be set to 0x0000, the MO set to 1962 "MSB" and the CDA to "LSB". 1964 In other cases, the length SHOULD be sent and the CDA is replaced by 1965 "value-sent". 1967 9.11. UDP Checksum field 1969 IPv6 mandates a checksum in the protocol above IP. Nevertheless, if 1970 a more efficient mechanism such as L2 CRC or MIC is carried by or 1971 over the L2 (such as in the LPWAN SCHC F/R process (see Section 7)), 1972 the UDP checksum transmission can be avoided. In that case, the TV 1973 is not set, the MO is set to "ignore" and the CDA is set to "compute- 1974 checksum". 1976 In other cases, the checksum SHOULD be explicitly sent. The TV is 1977 not set, the MO is set to "ignore" and the CDF is set to "value- 1978 sent". 1980 10. Security considerations 1982 10.1. Security considerations for header compression 1984 A malicious header compression could cause the reconstruction of a 1985 wrong packet that does not match with the original one. Such a 1986 corruption MAY be detected with end-to-end authentication and 1987 integrity mechanisms. Header Compression does not add more security 1988 problem than what is already needed in a transmission. For instance, 1989 to avoid an attack, never re-construct a packet bigger than some 1990 configured size (with 1500 bytes as generic default). 1992 10.2. Security considerations for SCHC Fragmentation/Reassembly 1994 This subsection describes potential attacks to LPWAN SCHC F/R and 1995 suggests possible countermeasures. 1997 A node can perform a buffer reservation attack by sending a first 1998 SCHC Fragment to a target. Then, the receiver will reserve buffer 1999 space for the IPv6 packet. Other incoming SCHC Fragmented packets 2000 will be dropped while the reassembly buffer is occupied during the 2001 reassembly timeout. Once that timeout expires, the attacker can 2002 repeat the same procedure, and iterate, thus creating a denial of 2003 service attack. The (low) cost to mount this attack is linear with 2004 the number of buffers at the target node. However, the cost for an 2005 attacker can be increased if individual SCHC Fragments of multiple 2006 packets can be stored in the reassembly buffer. To further increase 2007 the attack cost, the reassembly buffer can be split into SCHC 2008 Fragment-sized buffer slots. Once a packet is complete, it is 2009 processed normally. If buffer overload occurs, a receiver can 2010 discard packets based on the sender behavior, which MAY help identify 2011 which SCHC Fragments have been sent by an attacker. 2013 In another type of attack, the malicious node is required to have 2014 overhearing capabilities. If an attacker can overhear a SCHC 2015 Fragment, it can send a spoofed duplicate (e.g. with random payload) 2016 to the destination. If the LPWAN technology does not support 2017 suitable protection (e.g. source authentication and frame counters to 2018 prevent replay attacks), a receiver cannot distinguish legitimate 2019 from spoofed SCHC Fragments. Therefore, the original IPv6 packet 2020 will be considered corrupt and will be dropped. To protect resource- 2021 constrained nodes from this attack, it has been proposed to establish 2022 a binding among the SCHC Fragments to be transmitted by a node, by 2023 applying content-chaining to the different SCHC Fragments, based on 2024 cryptographic hash functionality. The aim of this technique is to 2025 allow a receiver to identify illegitimate SCHC Fragments. 2027 Further attacks MAY involve sending overlapped fragments (i.e. 2028 comprising some overlapping parts of the original IPv6 datagram). 2029 Implementers SHOULD make sure that the correct operation is not 2030 affected by such event. 2032 In Window mode - ACK on error, a malicious node MAY force a SCHC 2033 Fragment sender to resend a SCHC Fragment a number of times, with the 2034 aim to increase consumption of the SCHC Fragment sender's resources. 2035 To this end, the malicious node MAY repeatedly send a fake ACK to the 2036 SCHC Fragment sender, with a Bitmap that reports that one or more 2037 SCHC Fragments have been lost. In order to mitigate this possible 2038 attack, MAX_ACK_RETRIES MAY be set to a safe value which allows to 2039 limit the maximum damage of the attack to an acceptable extent. 2040 However, note that a high setting for MAX_ACK_RETRIES benefits SCHC 2041 Fragment reliability modes, therefore the trade-off needs to be 2042 carefully considered. 2044 11. Acknowledgements 2046 Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier, 2047 Eduardo Ingles Sanchez, Arunprabhu Kandasamy, Rahul Jadhav, Sergio 2048 Lopez Bernal, Antony Markovski, Alexander Pelov, Pascal Thubert, Juan 2049 Carlos Zuniga, Diego Dujovne, Edgar Ramos, and Shoichi Sakane for 2050 useful design consideration and comments. 2052 12. References 2053 12.1. Normative References 2055 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2056 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2057 December 1998, . 2059 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 2060 "Internet Protocol Small Computer System Interface (iSCSI) 2061 Cyclic Redundancy Check (CRC)/Checksum Considerations", 2062 RFC 3385, DOI 10.17487/RFC3385, September 2002, 2063 . 2065 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2066 "Transmission of IPv6 Packets over IEEE 802.15.4 2067 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2068 . 2070 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 2071 Header Compression (ROHC) Framework", RFC 5795, 2072 DOI 10.17487/RFC5795, March 2010, 2073 . 2075 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 2076 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 2077 February 2014, . 2079 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2080 Interface Identifiers with IPv6 Stateless Address 2081 Autoconfiguration (SLAAC)", RFC 7217, 2082 DOI 10.17487/RFC7217, April 2014, 2083 . 2085 12.2. Informative References 2087 [I-D.ietf-lpwan-overview] 2088 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 2089 overview-10 (work in progress), February 2018. 2091 Appendix A. SCHC Compression Examples 2093 This section gives some scenarios of the compression mechanism for 2094 IPv6/UDP. The goal is to illustrate the behavior of SCHC. 2096 The most common case using the mechanisms defined in this document 2097 will be a LPWAN Dev that embeds some applications running over CoAP. 2098 In this example, three flows are considered. The first flow is for 2099 the device management based on CoAP using Link Local IPv6 addresses 2100 and UDP ports 123 and 124 for Dev and App, respectively. The second 2101 flow will be a CoAP server for measurements done by the Device (using 2102 ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to 2103 beta::1/64. The last flow is for legacy applications using different 2104 ports numbers, the destination IPv6 address prefix is gamma::1/64. 2106 Figure 27 presents the protocol stack for this Device. IPv6 and UDP 2107 are represented with dotted lines since these protocols are 2108 compressed on the radio link. 2110 Management Data 2111 +----------+---------+---------+ 2112 | CoAP | CoAP | legacy | 2113 +----||----+---||----+---||----+ 2114 . UDP . UDP | UDP | 2115 ................................ 2116 . IPv6 . IPv6 . IPv6 . 2117 +------------------------------+ 2118 | SCHC Header compression | 2119 | and fragmentation | 2120 +------------------------------+ 2121 | LPWAN L2 technologies | 2122 +------------------------------+ 2123 DEV or NGW 2125 Figure 27: Simplified Protocol Stack for LP-WAN 2127 Note that in some LPWAN technologies, only the Devs have a device ID. 2128 Therefore, when such technologies are used, it is necessary to 2129 statically define an IID for the Link Local address for the SCHC C/D. 2131 Rule 0 2132 +----------------+--+--+--+---------+--------+------------++------+ 2133 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 2134 | | | | | | Opera. | Action ||[bits]| 2135 +----------------+--+--+--+---------+---------------------++------+ 2136 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2137 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2138 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2139 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2140 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2141 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2142 |IPv6 DEVprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2143 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 2144 |IPv6 APPprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 2145 |IPv6 APPiid |64|1 |Bi|::1 | equal | not-sent || | 2146 +================+==+==+==+=========+========+============++======+ 2147 |UDP DEVport |16|1 |Bi|123 | equal | not-sent || | 2148 |UDP APPport |16|1 |Bi|124 | equal | not-sent || | 2149 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2150 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2151 +================+==+==+==+=========+========+============++======+ 2153 Rule 1 2154 +----------------+--+--+--+---------+--------+------------++------+ 2155 | Field |FL|FP|DI| Value | Match | Action || Sent | 2156 | | | | | | Opera. | Action ||[bits]| 2157 +----------------+--+--+--+---------+--------+------------++------+ 2158 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2159 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2160 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2161 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2162 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2163 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 2164 |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| [1] | 2165 | | | | |fe80::/64] mapping| || | 2166 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 2167 |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| [2] | 2168 | | | | |alpha/64,| mapping| || | 2169 | | | | |fe80::64]| | || | 2170 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 2171 +================+==+==+==+=========+========+============++======+ 2172 |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | 2173 |UDP APPport |16|1 |Bi|5683 | equal | not-sent || | 2174 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2175 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2176 +================+==+==+==+=========+========+============++======+ 2178 Rule 2 2179 +----------------+--+--+--+---------+--------+------------++------+ 2180 | Field |FL|FP|DI| Value | Match | Action || Sent | 2181 | | | | | | Opera. | Action ||[bits]| 2182 +----------------+--+--+--+---------+--------+------------++------+ 2183 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 2184 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 2185 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 2186 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 2187 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 2188 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 2189 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] | 2190 |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | 2191 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 2192 |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | 2193 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 2194 +================+==+==+==+=========+========+============++======+ 2195 |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB || [4] | 2196 |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB || [4] | 2197 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 2198 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 2199 +================+==+==+==+=========+========+============++======+ 2201 Figure 28: Context rules 2203 All the fields described in the three rules depicted on Figure 28 are 2204 present in the IPv6 and UDP headers. The DEViid-DID value is found 2205 in the L2 header. 2207 The second and third rules use global addresses. The way the Dev 2208 learns the prefix is not in the scope of the document. 2210 The third rule compresses port numbers to 4 bits. 2212 Appendix B. Fragmentation Examples 2214 This section provides examples for the different fragment reliability 2215 modes specified in this document. 2217 Figure 29 illustrates the transmission in No-ACK mode of an IPv6 2218 packet that needs 11 fragments. FCN is 1 bit wide. 2220 Sender Receiver 2221 |-------FCN=0-------->| 2222 |-------FCN=0-------->| 2223 |-------FCN=0-------->| 2224 |-------FCN=0-------->| 2225 |-------FCN=0-------->| 2226 |-------FCN=0-------->| 2227 |-------FCN=0-------->| 2228 |-------FCN=0-------->| 2229 |-------FCN=0-------->| 2230 |-------FCN=0-------->| 2231 |-----FCN=1 + MIC --->|MIC checked: success => 2233 Figure 29: Transmission in No-ACK mode of an IPv6 packet carried by 2234 11 fragments 2236 In the following examples, N (i.e. the size if the FCN field) is 3 2237 bits. Therefore, the All-1 FCN value is 7. 2239 Figure 30 illustrates the transmission in ACK-on-Error of an IPv6 2240 packet that needs 11 fragments, with MAX_WIND_FCN=6 and no fragment 2241 loss. 2243 Sender Receiver 2244 |-----W=0, FCN=6----->| 2245 |-----W=0, FCN=5----->| 2246 |-----W=0, FCN=4----->| 2247 |-----W=0, FCN=3----->| 2248 |-----W=0, FCN=2----->| 2249 |-----W=0, FCN=1----->| 2250 |-----W=0, FCN=0----->| 2251 (no ACK) 2252 |-----W=1, FCN=6----->| 2253 |-----W=1, FCN=5----->| 2254 |-----W=1, FCN=4----->| 2255 |--W=1, FCN=7 + MIC-->|MIC checked: success => 2256 |<---- ACK, W=1 ------| 2258 Figure 30: Transmission in ACK-on-Error mode of an IPv6 packet 2259 carried by 11 fragments, with MAX_WIND_FCN=6 and no loss. 2261 Figure 31 illustrates the transmission in ACK-on-Error mode of an 2262 IPv6 packet that needs 11 fragments, with MAX_WIND_FCN=6 and three 2263 lost fragments. 2265 Sender Receiver 2266 |-----W=0, FCN=6----->| 2267 |-----W=0, FCN=5----->| 2268 |-----W=0, FCN=4--X-->| 2269 |-----W=0, FCN=3----->| 2270 |-----W=0, FCN=2--X-->| 7 2271 |-----W=0, FCN=1----->| / 2272 |-----W=0, FCN=0----->| 6543210 2273 |<-----ACK, W=0-------|Bitmap:1101011 2274 |-----W=0, FCN=4----->| 2275 |-----W=0, FCN=2----->| 2276 (no ACK) 2277 |-----W=1, FCN=6----->| 2278 |-----W=1, FCN=5----->| 2279 |-----W=1, FCN=4--X-->| 2280 |- W=1, FCN=7 + MIC ->|MIC checked: failed 2281 |<-----ACK, W=1-------|C=0 Bitmap:1100001 2282 |-----W=1, FCN=4----->|MIC checked: success => 2283 |<---- ACK, W=1 ------|C=1, no Bitmap 2285 Figure 31: Transmission in ACK-on-Error mode of an IPv6 packet 2286 carried by 11 fragments, with MAX_WIND_FCN=6 and three lost 2287 fragments. 2289 Figure 32 illustrates the transmission in ACK-Always mode of an IPv6 2290 packet that needs 11 fragments, with MAX_WIND_FCN=6 and no loss. 2292 Sender Receiver 2293 |-----W=0, FCN=6----->| 2294 |-----W=0, FCN=5----->| 2295 |-----W=0, FCN=4----->| 2296 |-----W=0, FCN=3----->| 2297 |-----W=0, FCN=2----->| 2298 |-----W=0, FCN=1----->| 2299 |-----W=0, FCN=0----->| 2300 |<-----ACK, W=0-------| Bitmap:1111111 2301 |-----W=1, FCN=6----->| 2302 |-----W=1, FCN=5----->| 2303 |-----W=1, FCN=4----->| 2304 |--W=1, FCN=7 + MIC-->|MIC checked: success => 2305 |<-----ACK, W=1-------| C=1 no Bitmap 2306 (End) 2308 Figure 32: Transmission in ACK-Always mode of an IPv6 packet carried 2309 by 11 fragments, with MAX_WIND_FCN=6 and no lost fragment. 2311 Figure 33 illustrates the transmission in ACK-Always mode of an IPv6 2312 packet that needs 11 fragments, with MAX_WIND_FCN=6 and three lost 2313 fragments. 2315 Sender Receiver 2316 |-----W=1, FCN=6----->| 2317 |-----W=1, FCN=5----->| 2318 |-----W=1, FCN=4--X-->| 2319 |-----W=1, FCN=3----->| 2320 |-----W=1, FCN=2--X-->| 7 2321 |-----W=1, FCN=1----->| / 2322 |-----W=1, FCN=0----->| 6543210 2323 |<-----ACK, W=1-------|Bitmap:1101011 2324 |-----W=1, FCN=4----->| 2325 |-----W=1, FCN=2----->| 2326 |<-----ACK, W=1-------|Bitmap: 2327 |-----W=0, FCN=6----->| 2328 |-----W=0, FCN=5----->| 2329 |-----W=0, FCN=4--X-->| 2330 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2331 |<-----ACK, W=0-------| C= 0 Bitmap:11000001 2332 |-----W=0, FCN=4----->|MIC checked: success => 2333 |<-----ACK, W=0-------| C= 1 no Bitmap 2334 (End) 2336 Figure 33: Transmission in ACK-Always mode of an IPv6 packet carried 2337 by 11 fragments, with MAX_WIND_FCN=6 and three lost fragments. 2339 Figure 34 illustrates the transmission in ACK-Always mode of an IPv6 2340 packet that needs 6 fragments, with MAX_WIND_FCN=6, three lost 2341 fragments and only one retry needed to recover each lost fragment. 2343 Sender Receiver 2344 |-----W=0, FCN=6----->| 2345 |-----W=0, FCN=5----->| 2346 |-----W=0, FCN=4--X-->| 2347 |-----W=0, FCN=3--X-->| 2348 |-----W=0, FCN=2--X-->| 2349 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2350 |<-----ACK, W=0-------|C= 0 Bitmap:1100001 2351 |-----W=0, FCN=4----->|MIC checked: failed 2352 |-----W=0, FCN=3----->|MIC checked: failed 2353 |-----W=0, FCN=2----->|MIC checked: success 2354 |<-----ACK, W=0-------|C=1 no Bitmap 2355 (End) 2357 Figure 34: Transmission in ACK-Always mode of an IPv6 packet carried 2358 by 11 fragments, with MAX_WIND_FCN=6, three lost framents and only 2359 one retry needed for each lost fragment. 2361 Figure 35 illustrates the transmission in ACK-Always mode of an IPv6 2362 packet that needs 6 fragments, with MAX_WIND_FCN=6, three lost 2363 fragments, and the second ACK lost. 2365 Sender Receiver 2366 |-----W=0, FCN=6----->| 2367 |-----W=0, FCN=5----->| 2368 |-----W=0, FCN=4--X-->| 2369 |-----W=0, FCN=3--X-->| 2370 |-----W=0, FCN=2--X-->| 2371 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2372 |<-----ACK, W=0-------|C=0 Bitmap:1100001 2373 |-----W=0, FCN=4----->|MIC checked: failed 2374 |-----W=0, FCN=3----->|MIC checked: failed 2375 |-----W=0, FCN=2----->|MIC checked: success 2376 | X---ACK, W=0-------|C= 1 no Bitmap 2377 timeout | | 2378 |--W=0, FCN=7 + MIC-->| 2379 |<-----ACK, W=0-------|C= 1 no Bitmap 2381 (End) 2383 Figure 35: Transmission in ACK-Always mode of an IPv6 packet carried 2384 by 11 fragments, with MAX_WIND_FCN=6, three lost fragments, and the 2385 second ACK lost. 2387 Figure 36 illustrates the transmission in ACK-Always mode of an IPv6 2388 packet that needs 6 fragments, with MAX_WIND_FCN=6, with three lost 2389 fragments, and one retransmitted fragment lost again. 2391 Sender Receiver 2392 |-----W=0, FCN=6----->| 2393 |-----W=0, FCN=5----->| 2394 |-----W=0, FCN=4--X-->| 2395 |-----W=0, FCN=3--X-->| 2396 |-----W=0, FCN=2--X-->| 2397 |--W=0, FCN=7 + MIC-->|MIC checked: failed 2398 |<-----ACK, W=0-------|C=0 Bitmap:1100001 2399 |-----W=0, FCN=4----->|MIC checked: failed 2400 |-----W=0, FCN=3----->|MIC checked: failed 2401 |-----W=0, FCN=2--X-->| 2402 timeout| | 2403 |--W=0, FCN=7 + MIC-->|All-0 empty 2404 |<-----ACK, W=0-------|C=0 Bitmap: 1111101 2405 |-----W=0, FCN=2----->|MIC checked: success 2406 |<-----ACK, W=0-------|C=1 no Bitmap 2407 (End) 2409 Figure 36: Transmission in ACK-Always mode of an IPv6 packet carried 2410 by 11 fragments, with MAX_WIND_FCN=6, with three lost fragments, and 2411 one retransmitted fragment lost again. 2413 Figure 37 illustrates the transmission in ACK-Always mode of an IPv6 2414 packet that needs 28 fragments, with N=5, MAX_WIND_FCN=23 and two 2415 lost fragments. Note that MAX_WIND_FCN=23 may be useful when the 2416 maximum possible Bitmap size, considering the maximum lower layer 2417 technology payload size and the value of R, is 3 bytes. Note also 2418 that the FCN of the last fragment of the packet is the one with 2419 FCN=31 (i.e. FCN=2^N-1 for N=5, or equivalently, all FCN bits set to 2420 1). 2422 Sender Receiver 2423 |-----W=0, FCN=23----->| 2424 |-----W=0, FCN=22----->| 2425 |-----W=0, FCN=21--X-->| 2426 |-----W=0, FCN=20----->| 2427 |-----W=0, FCN=19----->| 2428 |-----W=0, FCN=18----->| 2429 |-----W=0, FCN=17----->| 2430 |-----W=0, FCN=16----->| 2431 |-----W=0, FCN=15----->| 2432 |-----W=0, FCN=14----->| 2433 |-----W=0, FCN=13----->| 2434 |-----W=0, FCN=12----->| 2435 |-----W=0, FCN=11----->| 2436 |-----W=0, FCN=10--X-->| 2437 |-----W=0, FCN=9 ----->| 2438 |-----W=0, FCN=8 ----->| 2439 |-----W=0, FCN=7 ----->| 2440 |-----W=0, FCN=6 ----->| 2441 |-----W=0, FCN=5 ----->| 2442 |-----W=0, FCN=4 ----->| 2443 |-----W=0, FCN=3 ----->| 2444 |-----W=0, FCN=2 ----->| 2445 |-----W=0, FCN=1 ----->| 2446 |-----W=0, FCN=0 ----->| 2447 | |lcl-Bitmap:110111111111101111111111 2448 |<------ACK, W=0-------|encoded Bitmap:1101111111111011 2449 |-----W=0, FCN=21----->| 2450 |-----W=0, FCN=10----->| 2451 |<------ACK, W=0-------|no Bitmap 2452 |-----W=1, FCN=23----->| 2453 |-----W=1, FCN=22----->| 2454 |-----W=1, FCN=21----->| 2455 |--W=1, FCN=31 + MIC-->|MIC checked: sucess => 2456 |<------ACK, W=1-------|no Bitmap 2457 (End) 2459 Figure 37: Transmission in ACK-Always mode of an IPv6 packet carried 2460 by 28 fragments, with N=5, MAX_WIND_FCN=23 and two lost fragments. 2462 Appendix C. Fragmentation State Machines 2464 The fragmentation state machines of the sender and the receiver, one 2465 for each of the different reliability modes, are described in the 2466 following figures: 2468 +===========+ 2469 +------------+ Init | 2470 | FCN=0 +===========+ 2471 | No Window 2472 | No Bitmap 2473 | +-------+ 2474 | +========+==+ | More Fragments 2475 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 2476 +--------> | Send | send Fragment (FCN=0) 2477 +===+=======+ 2478 | last fragment 2479 | ~~~~~~~~~~~~ 2480 | FCN = 1 2481 v send fragment+MIC 2482 +============+ 2483 | END | 2484 +============+ 2486 Figure 38: Sender State Machine for the No-ACK Mode 2488 +------+ Not All-1 2489 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 2490 | + <--+ set Inactivity Timer 2491 | RCV Frag +-------+ 2492 +=+===+======+ |All-1 & 2493 All-1 & | | |MIC correct 2494 MIC wrong | |Inactivity | 2495 | |Timer Exp. | 2496 v | | 2497 +==========++ | v 2498 | Error |<-+ +========+==+ 2499 +===========+ | END | 2500 +===========+ 2502 Figure 39: Receiver State Machine for the No-ACK Mode 2503 +=======+ 2504 | INIT | FCN!=0 & more frags 2505 | | ~~~~~~~~~~~~~~~~~~~~~~ 2506 +======++ +--+ send Window + frag(FCN) 2507 W=0 | | | FCN- 2508 Clear local Bitmap | | v set local Bitmap 2509 FCN=max value | ++==+========+ 2510 +> | | 2511 +---------------------> | SEND | 2512 | +==+===+=====+ 2513 | FCN==0 & more frags | | last frag 2514 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 2515 | set local-Bitmap | | set local-Bitmap 2516 | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC 2517 | set Retrans_Timer | | set Retrans_Timer 2518 | | | 2519 |Recv_wnd == wnd & | | 2520 |Lcl_Bitmap==recv_Bitmap& | | +----------------------+ 2521 |more frag | | |lcl-Bitmap!=rcv-Bitmap| 2522 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 2523 |Stop Retrans_Timer | | | Attemp++ v 2524 |clear local_Bitmap v v | +=====+=+ 2525 |window=next_window +====+===+==+===+ |Resend | 2526 +---------------------+ | |Missing| 2527 +----+ Wait | |Frag | 2528 not expected wnd | | Bitmap | +=======+ 2529 ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | 2530 discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | 2531 | | | ^ ^ |reSend(empty)All-* | 2532 | | | | | |Set Retrans_Timer | 2533 MIC_bit==1 & | | | | +--+Attemp++ | 2534 Recv_window==window & | | | +-------------------------+ 2535 Lcl_Bitmap==recv_Bitmap &| | | all missing frag sent 2536 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 2537 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 2538 Stop Retrans_Timer| | | 2539 +=============+ | | | 2540 | END +<--------+ | | Attemp > MAX_ACK_REQUESTS 2541 +=============+ | | ~~~~~~~~~~~~~~~~~~ 2542 All-1 Window | v Send Abort 2543 ~~~~~~~~~~~~ | +=+===========+ 2544 MIC_bit ==0 & +>| ERROR | 2545 Lcl_Bitmap==recv_Bitmap +=============+ 2547 Figure 40: Sender State Machine for the ACK-Always Mode 2549 Not All- & w=expected +---+ +---+w = Not expected 2550 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2551 Set local_Bitmap(FCN) | v v |discard 2552 ++===+===+===+=+ 2553 +---------------------+ Rcv +--->* ABORT 2554 | +------------------+ Window | 2555 | | +=====+==+=====+ 2556 | | All-0 & w=expect | ^ w =next & not-All 2557 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 2558 | | set lcl_Bitmap(FCN)| |expected = next window 2559 | | send local_Bitmap | |Clear local_Bitmap 2560 | | | | 2561 | | w=expct & not-All | | 2562 | | ~~~~~~~~~~~~~~~~~~ | | 2563 | | set lcl_Bitmap(FCN)+-+ | | +--+ w=next & All-0 2564 | | if lcl_Bitmap full | | | | | | ~~~~~~~~~~~~~~~ 2565 | | send lcl_Bitmap | | | | | | expct = nxt wnd 2566 | | v | v | | | Clear lcl_Bitmap 2567 | | w=expct & All-1 +=+=+=+==+=++ | set lcl_Bitmap(FCN) 2568 | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_Bitmap 2569 | | discard +--| Next | 2570 | | All-0 +---------+ Window +--->* ABORT 2571 | | ~~~~~ +-------->+========+=++ 2572 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 2573 | | & MIC wrong| | & MIC right 2574 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 2575 | | set local_Bitmap(FCN)| |set lcl_Bitmap(FCN) 2576 | | send local_Bitmap| |send local_Bitmap 2577 | | | +----------------------+ 2578 | |All-1 & w=expct | | 2579 | |& MIC wrong v +---+ w=expctd & | 2580 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong | 2581 | |set local_Bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ | 2582 | |send local_Bitmap | Wait End | set lcl_btmp(FCN)| 2583 | +--------------------->+ +--->* ABORT | 2584 | +===+====+=+-+ All-1&MIC wrong| 2585 | | ^ | ~~~~~~~~~~~~~~~| 2586 | w=expected & MIC right | +---+ send lcl_btmp | 2587 | ~~~~~~~~~~~~~~~~~~~~~~ | | 2588 | set local_Bitmap(FCN) | +-+ Not All-1 | 2589 | send local_Bitmap | | | ~~~~~~~~~ | 2590 | | | | discard | 2591 |All-1 & w=expctd & MIC right | | | | 2592 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | 2593 |set local_Bitmap(FCN) +=+=+=+=+==+ |~~~~~~~~~ | 2594 |send local_Bitmap | +<+Send lcl_btmp | 2595 +-------------------------->+ END | | 2596 +==========+<---------------+ 2598 --->* ABORT 2599 ~~~~~~~ 2600 Inactivity_Timer = expires 2601 When DWN_Link 2602 IF Inactivity_Timer expires 2603 Send DWL Request 2604 Attemp++ 2606 Figure 41: Receiver State Machine for the ACK-Always Mode 2607 +=======+ 2608 | | 2609 | INIT | 2610 | | FCN!=0 & more frags 2611 +======++ +--+ ~~~~~~~~~~~~~~~~~~~~~~ 2612 W=0 | | | send Window + frag(FCN) 2613 ~~~~~~~~~~~~~~~~~~ | | | FCN- 2614 Clear local Bitmap | | v set local Bitmap 2615 FCN=max value | ++=============+ 2616 +> | | 2617 | SEND | 2618 +-------------------------> | | 2619 | ++=====+=======+ 2620 | FCN==0 & more frags| |last frag 2621 | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~ 2622 | set local-Bitmap| |set local-Bitmap 2623 | send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC 2624 | set Retrans_Timer| |set Retrans_Timer 2625 | | | 2626 |Retrans_Timer expires & | | lcl-Bitmap!=rcv-Bitmap 2627 |more fragments | | ~~~~~~~~~~~~~~~~~~~~~~ 2628 |~~~~~~~~~~~~~~~~~~~~ | | Attemp++ 2629 |stop Retrans_Timer | | +-----------------+ 2630 |clear local-Bitmap v v | v 2631 |window = next window +=====+=====+==+==+ +====+====+ 2632 +----------------------+ + | Resend | 2633 +--------------------->+ Wait Bitmap | | Missing | 2634 | +-- + | | Frag | 2635 | not expected wnd | ++=+===+===+===+==+ +======+==+ 2636 | ~~~~~~~~~~~~~~~~ | ^ | | | ^ | 2637 | discard frag +----+ | | | +-------------------+ 2638 | | | | all missing frag sent 2639 |Retrans_Timer expires & | | | ~~~~~~~~~~~~~~~~~~~~~ 2640 | No more Frag | | | Set Retrans_Timer 2641 | ~~~~~~~~~~~~~~~~~~~~~~~ | | | 2642 | Stop Retrans_Timer | | | 2643 | Send ALL-1-empty | | | 2644 +-------------------------+ | | 2645 | | 2646 Local_Bitmap==Recv_Bitmap| | 2647 ~~~~~~~~~~~~~~~~~~~~~~~~~| |Attemp > MAX_ACK_REQUESTS 2648 +=========+Stop Retrans_Timer | |~~~~~~~~~~~~~~~~~~~~~~~ 2649 | END +<------------------+ v Send Abort 2650 +=========+ +=+=========+ 2651 | ERROR | 2652 +===========+ 2654 Figure 42: Sender State Machine for the ACK-on-Error Mode 2656 Not All- & w=expected +---+ +---+w = Not expected 2657 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2658 Set local_Bitmap(FCN) | v v |discard 2659 ++===+===+===+=+ 2660 +-----------------------+ +--+ All-0 & full 2661 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~~~ 2662 | +--------------------+ +<-+ w =next 2663 | | All-0 empty +->+=+=+===+======+ clear lcl_Bitmap 2664 | | ~~~~~~~~~~~ | | | ^ 2665 | | send bitmap +----+ | |w=expct & not-All & full 2666 | | | |~~~~~~~~~~~~~~~~~~~~~~~~ 2667 | | | |set lcl_Bitmap; w =nxt 2668 | | | | 2669 | | All-0 & w=expect | | w=next 2670 | | & no_full Bitmap | | ~~~~~~~~ +========+ 2671 | | ~~~~~~~~~~~~~~~~~ | | Send abort| Error/ | 2672 | | send local_Bitmap | | +---------->+ Abort | 2673 | | | | | +-------->+========+ 2674 | | v | | | all-1 ^ 2675 | | All-0 empty +====+===+==+=+=+ ~~~~~~~ | 2676 | | ~~~~~~~~~~~~~ +--+ Wait | Send abort | 2677 | | send lcl_btmp +->| Missing Fragm.| | 2678 | | +==============++ | 2679 | | +--------------+ 2680 | | Uplink Only & 2681 | | Inactivity_Timer = expires 2682 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 2683 | | Send Abort 2684 | |All-1 & w=expect & MIC wrong 2685 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ All-1 2686 | |set local_Bitmap(FCN) | v ~~~~~~~~~~ 2687 | |send local_Bitmap +===========+==+ snd lcl_btmp 2688 | +--------------------->+ Wait End +-+ 2689 | +=====+=+====+=+ | w=expct & 2690 | w=expected & MIC right | | ^ | MIC wrong 2691 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ ~~~~~~~~~ 2692 | set & send local_Bitmap(FCN) | | set lcl_Bitmap(FCN) 2693 | | | 2694 |All-1 & w=expected & MIC right | +-->* ABORT 2695 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v 2696 |set & send local_Bitmap(FCN) +=+==========+ 2697 +---------------------------->+ END | 2698 +============+ 2699 --->* ABORT 2700 Only Uplink 2701 Inactivity_Timer = expires 2702 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 2703 Send Abort 2705 Figure 43: Receiver State Machine for the ACK-on-Error Mode 2707 Appendix D. SCHC Parameters - Ticket #15 2709 This section gives the list of parameters that need to be defined in 2710 the technology-specific documents, technology developers must 2711 evaluate that L2 has strong enough integrity checking to match SCHC's 2712 assumption: 2714 o LPWAN Architecture. Explain the SCHC entities (Compression and 2715 Fragmentation), how/where are they be represented in the 2716 corresponding technology architecture. 2718 o L2 fragmentation decision 2720 o Rule ID number of rules 2722 o Size of the Rule ID 2724 o The way the Rule ID is sent (L2 or L3) and how (describe) 2726 o Fragmentation delivery reliability mode used in which cases 2728 o Define the number of bits FCN (N) and DTag (T) 2730 o The MIC algorithm to be used and the size if different from the 2731 default CRC32 2733 o Retransmission Timer duration 2735 o Inactivity Timer duration 2737 o Define the MAX_ACK_REQUEST (number of attempts) 2739 o Use of padding or not and how and when to use it 2741 o Take into account that the length of rule-id + N + T + W when 2742 possible is good to have a multiple of 8 bits to complete a byte 2743 and avoid padding 2745 o In the ACK format to have a length for Rule-ID + T + W bit into a 2746 complete number of byte to do optimization more easily 2748 o The technology documents will describe if Rule ID is constrained 2749 by any alignment 2751 And the following parameters need to be addressed in another document 2752 but not forcely in the technology-specific one: 2754 o The way the contexts are provisioning 2756 o The way the Rules as generated 2758 Appendix E. Note 2760 Carles Gomez has been funded in part by the Spanish Government 2761 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2762 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2763 Government through project TEC2016-79988-P. Part of his contribution 2764 to this work has been carried out during his stay as a visiting 2765 scholar at the Computer Laboratory of the University of Cambridge. 2767 Authors' Addresses 2769 Ana Minaburo 2770 Acklio 2771 2bis rue de la Chataigneraie 2772 35510 Cesson-Sevigne Cedex 2773 France 2775 Email: ana@ackl.io 2777 Laurent Toutain 2778 IMT-Atlantique 2779 2 rue de la Chataigneraie 2780 CS 17607 2781 35576 Cesson-Sevigne Cedex 2782 France 2784 Email: Laurent.Toutain@imt-atlantique.fr 2786 Carles Gomez 2787 Universitat Politecnica de Catalunya 2788 C/Esteve Terradas, 7 2789 08860 Castelldefels 2790 Spain 2792 Email: carlesgo@entel.upc.edu