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