idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-08.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 672: '... datagram SHALL be broken into fragm...' RFC 2119 keyword, line 723: '...ng technology documents. The FCN MUST...' RFC 2119 keyword, line 725: '... first fragment), and MUST wrap from 0...' RFC 2119 keyword, line 741: '...to 0 bits. DTag MUST be set sequentia...' RFC 2119 keyword, line 742: '... to 2^T - 1, and MUST wrap back from 2...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1312 has weird spacing: '... 1 byte next ...' == Line 2230 has weird spacing: '..._bitmap v |...' -- The document date (December 17, 2017) is 2322 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1830 -- Looks like a reference, but probably isn't: '2' on line 1833 -- Looks like a reference, but probably isn't: '8' on line 1855 -- Looks like a reference, but probably isn't: '4' on line 1862 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-ietf-lpwan-overview-07 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Informational L. Toutain 5 Expires: June 20, 2018 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 December 17, 2017 10 LPWAN Static Context Header Compression (SCHC) and fragmentation for 11 IPv6 and UDP 12 draft-ietf-lpwan-ipv6-static-context-hc-08 14 Abstract 16 This document describes a header compression scheme and fragmentation 17 functionality for very low bandwidth networks. These techniques are 18 specially tailored for Low Power Wide Area Network (LPWAN). 20 The Static Context Header Compression (SCHC) offers a great level of 21 flexibility when processing the header fields. SCHC compression is 22 based on a common static context stored in a LPWAN device and in the 23 network. Static context means that the stored information does not 24 change during packet transmission. The context describes the field 25 values and keeps information that will not be transmitted through the 26 constrained network. 28 SCHC must be used for LPWAN networks because it avoids complex 29 resynchronization mechanisms, which are incompatible with LPWAN 30 characteristics. And also, because with SCHC, in most cases IPv6/UDP 31 headers can be reduced to a small identifier called Rule ID. Even 32 though, sometimes, a SCHC compressed packet will not fit in one L2 33 PDU, and the SCHC fragmentation protocol defined in this document may 34 be used. 36 This document describes the SCHC compression/decompression framework 37 and applies it to IPv6/UDP headers. This document also specifies a 38 fragmentation and reassembly mechanism that is used to support the 39 IPv6 MTU requirement over LPWAN technologies. Fragmentation is 40 mandatory for IPv6 datagrams that, after SCHC compression or when it 41 has not been possible to apply such compression, still exceed the L2 42 maximum payload size. Similar solutions for other protocols such as 43 CoAP will be described in separate documents. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on June 20, 2018. 62 Copyright Notice 64 Copyright (c) 2017 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4 81 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 4. Static Context Header Compression . . . . . . . . . . . . . . 7 83 4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.2. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 4.3. Packet processing . . . . . . . . . . . . . . . . . . . . 10 86 4.4. Matching operators . . . . . . . . . . . . . . . . . . . 12 87 4.5. Compression Decompression Actions (CDA) . . . . . . . . . 12 88 4.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 13 89 4.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 13 90 4.5.3. mapping-sent . . . . . . . . . . . . . . . . . . . . 14 91 4.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 14 92 4.5.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . 14 93 4.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 14 94 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 15 95 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 96 5.2. Functionalities . . . . . . . . . . . . . . . . . . . . . 15 97 5.3. Delivery Reliability options . . . . . . . . . . . . . . 18 98 5.4. Fragmentation Frames Formats . . . . . . . . . . . . . . 19 99 5.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 19 100 5.4.2. Fragmentation formats . . . . . . . . . . . . . . . . 20 101 5.4.3. ACK format . . . . . . . . . . . . . . . . . . . . . 20 102 5.4.4. All-1 and All-0 formats . . . . . . . . . . . . . . . 21 103 5.4.5. Abort formats . . . . . . . . . . . . . . . . . . . . 23 104 5.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 23 105 5.5.1. No ACK . . . . . . . . . . . . . . . . . . . . . . . 24 106 5.5.2. The Window modes . . . . . . . . . . . . . . . . . . 25 107 5.5.3. Bitmap Optimization . . . . . . . . . . . . . . . . . 28 108 5.6. Supporting multiple window sizes . . . . . . . . . . . . 30 109 5.7. Downlink fragment transmission . . . . . . . . . . . . . 31 110 6. Padding management . . . . . . . . . . . . . . . . . . . . . 32 111 7. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 32 112 7.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 32 113 7.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 32 114 7.3. Flow label field . . . . . . . . . . . . . . . . . . . . 33 115 7.4. Payload Length field . . . . . . . . . . . . . . . . . . 33 116 7.5. Next Header field . . . . . . . . . . . . . . . . . . . . 33 117 7.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 34 118 7.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 34 119 7.7.1. IPv6 source and destination prefixes . . . . . . . . 34 120 7.7.2. IPv6 source and destination IID . . . . . . . . . . . 35 121 7.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 35 122 7.9. UDP source and destination port . . . . . . . . . . . . . 35 123 7.10. UDP length field . . . . . . . . . . . . . . . . . . . . 36 124 7.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 36 125 8. Security considerations . . . . . . . . . . . . . . . . . . . 36 126 8.1. Security considerations for header compression . . . . . 36 127 8.2. Security considerations for fragmentation . . . . . . . . 36 128 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 129 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 130 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 131 10.2. Informative References . . . . . . . . . . . . . . . . . 38 132 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 38 133 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 41 134 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 47 135 Appendix D. Allocation of Rule IDs for fragmentation . . . . . . 54 136 Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 54 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 139 1. Introduction 141 Header compression is mandatory to efficiently bring Internet 142 connectivity to the node within a LPWAN network. Some LPWAN networks 143 properties can be exploited to get an efficient header compression: 145 o Topology is star-oriented; therefore, all the packets follow the 146 same path. For the needs of this draft, the architecture can be 147 summarized to Devices (Dev) exchanging information with LPWAN 148 Application Server (App) through a Network Gateway (NGW). 150 o Traffic flows are mostly known in advance since devices embed 151 built-in applications. Contrary to computers or smartphones, new 152 applications cannot be easily installed. 154 The Static Context Header Compression (SCHC) is defined for this 155 environment. SCHC uses a context where header information is kept in 156 the header format order. This context is static (the values of the 157 header fields do not change over time) avoiding complex 158 resynchronization mechanisms, incompatible with LPWAN 159 characteristics. In most of the cases, IPv6/UDP headers are reduced 160 to a small context identifier. 162 The SCHC header compression mechanism is independent of the specific 163 LPWAN technology over which it will be used. 165 LPWAN technologies are also characterized, among others, by a very 166 reduced data unit and/or payload size [I-D.ietf-lpwan-overview]. 167 However, some of these technologies do not support layer two 168 fragmentation, therefore the only option for them to support the IPv6 169 MTU requirement of 1280 bytes [RFC2460] is the use of a fragmentation 170 protocol at the adaptation layer below IPv6. This draft defines also 171 a fragmentation functionality to support the IPv6 MTU requirement 172 over LPWAN technologies. Such functionality has been designed under 173 the assumption that data unit reordering will not happen between the 174 entity performing fragmentation and the entity performing reassembly. 176 2. LPWAN Architecture 178 LPWAN technologies have similar architectures but different 179 terminology. We can identify different types of entities in a 180 typical LPWAN network, see Figure 1: 182 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 183 actuators, etc.). There can be a high density of devices per radio 184 gateway. 186 o The Radio Gateway (RGW), which is the end point of the constrained 187 link. 189 o The Network Gateway (NGW) is the interconnection node between the 190 Radio Gateway and the Internet. 192 o LPWAN-AAA Server, which controls the user authentication and the 193 applications. 195 o Application Server (App) 197 +------+ 198 () () () | |LPWAN-| 199 () () () () / \ +---------+ | AAA | 200 () () () () () () / \=====| ^ |===|Server| +-----------+ 201 () () () | | <--|--> | +------+ |APPLICATION| 202 () () () () / \==========| v |=============| (App) | 203 () () () / \ +---------+ +-----------+ 204 Dev Radio Gateways NGW 206 Figure 1: LPWAN Architecture 208 3. Terminology 210 This section defines the terminology and acronyms used in this 211 document. 213 o All-0. Fragmentation Packet format to send the last frame of a 214 window. 216 o All-1. Fragmentation Packet format to send the last frame of a 217 packet. 219 o All-0 empty. Fragmentation Packet format without payload to 220 request the bitmap when the Retransmission Timer expires in a 221 window. 223 o All-1 empty. Fragmentation Packet format without payload to 224 request the bitmap when the Retransmission Timer expires in the 225 last window. 227 o App: LPWAN Application. An application sending/receiving IPv6 228 packets to/from the Device. 230 o APP-IID: Application Interface Identifier. Second part of the 231 IPv6 address to identify the application interface 233 o Bi: Bidirectional, a rule entry that applies in both directions. 235 o C: Checked bit. Used in fragmentation header to determine when 236 the MIC is correct (1) or not (0). 238 o CDA: Compression/Decompression Action. An action that is 239 performed for both functionalities to compress a header field or 240 to recover its original value in the decompression phase. 242 o Context: A set of rules used to compress/decompress headers 244 o Dev: Device. A Node connected to the LPWAN. A Dev may implement 245 SCHC. 247 o Dev-IID: Device Interface Identifier. Second part of the IPv6 248 address to identify the device interface 250 o DI: Direction Indicator is a differentiator for matching in order 251 to be able to have different values for both sides. 253 o DTag: Datagram Tag is a fragmentation header field that is set to 254 the same value for all fragments carrying the same IPv6 datagram. 256 o Dw: Down Link direction for compression, from SCHC C/D to Dev 258 o FCN: Fragment Compressed Number is a fragmentation header field 259 that carries an efficient representation of a larger-sized 260 fragment number. 262 o FID: Field Identifier is an index to describe the header fields in 263 the Rule 265 o FL: Field Length is a value to identify if the field is fixed or 266 variable length. 268 o FP: Field Position is a value that is used to identify each 269 instance a field appears in the header. 271 o IID: Interface Identifier. See the IPv6 addressing architecture 272 [RFC7136] 274 o Inactivity Timer. Timer to End the state machine when there is an 275 error and there is no possibility to continue the transmission. 277 o MIC: Message Integrity Check. A fragmentation header field 278 computed over an IPv6 packet before fragmentation, used for error 279 detection after IPv6 packet reassembly. 281 o MO: Matching Operator. An operator used to match a value 282 contained in a header field with a value contained in a Rule. 284 o Retransmission Timer. Timer used in the sender transmission to 285 detect error in the link when waiting for an ACK. 287 o Rule: A set of header field values. 289 o Rule entry: A row in the rule that describes a header field. 291 o Rule ID: An identifier for a rule, SCHC C/D, and Dev share the 292 same Rule ID for a specific flow. A set of Rule IDs are used to 293 support fragmentation functionality. 295 o SCHC C/D: Static Context Header Compression Compressor/ 296 Decompressor. A process in the network to achieve compression/ 297 decompressing headers. SCHC C/D uses SCHC rules to perform 298 compression and decompression. 300 o TV: Target value. A value contained in the Rule that will be 301 matched with the value of a header field. 303 o Up: Up Link direction for compression, from Dev to SCHC C/D. 305 o W: Window bit. A fragmentation header field used in Window mode 306 (see section 9), which carries the same value for all fragments of 307 a window. 309 4. Static Context Header Compression 311 Static Context Header Compression (SCHC) avoids context 312 synchronization, which is the most bandwidth-consuming operation in 313 other header compression mechanisms such as RoHC [RFC5795]. Based on 314 the fact that the nature of data flows is highly predictable in LPWAN 315 networks, some static contexts may be stored on the Device (Dev). 316 The contexts must be stored in both ends, and it can either be 317 learned by a provisioning protocol or by out of band means or it can 318 be pre-provisioned, etc. The way the context is learned on both 319 sides are out of the scope of this document. 321 Dev App 322 +--------------+ +--------------+ 323 |APP1 APP2 APP3| |APP1 APP2 APP3| 324 | | | | 325 | UDP | | UDP | 326 | IPv6 | | IPv6 | 327 | | | | 328 | SCHC C/D | | | 329 | (context) | | | 330 +-------+------+ +-------+------+ 331 | +--+ +----+ +---------+ . 332 +~~ |RG| === |NGW | === |SCHC C/D |... Internet .. 333 +--+ +----+ |(context)| 334 +---------+ 336 Figure 2: Architecture 338 Figure 2 represents the architecture for compression/decompression, 339 it is based on [I-D.ietf-lpwan-overview] terminology. The Device is 340 sending applications flows using IPv6 or IPv6/UDP protocols. These 341 flows are compressed by a Static Context Header Compression 342 Compressor/Decompressor (SCHC C/D) to reduce headers size. The 343 resulting information is sent to a layer two (L2) frame to a LPWAN 344 Radio Network (RG) which forwards the frame to a Network Gateway 345 (NGW). The NGW sends the data to an SCHC C/D for decompression which 346 shares the same rules with the Dev. The SCHC C/D can be located on 347 the Network Gateway (NGW) or in another place as long as a tunnel is 348 established between the NGW and the SCHC C/D. The SCHC C/D in both 349 sides must share the same set of Rules. After decompression, the 350 packet can be sent on the Internet to one or several LPWAN 351 Application Servers (App). 353 The SCHC C/D process is bidirectional, so the same principles can be 354 applied in the other direction. 356 4.1. SCHC Rules 358 The main idea of the SCHC compression scheme is to send the Rule id 359 to the other end instead of sending known field values. This Rule id 360 identifies a rule that matches as much as possible the original 361 packet values. When a value is known by both ends, it is not 362 necessary to send it through the LPWAN network. 364 The context contains a list of rules (cf. Figure 3). Each Rule 365 contains itself a list of fields descriptions composed of a field 366 identifier (FID), a field length (FL), a field position (FP), a 367 direction indicator (DI), a target value (TV), a matching operator 368 (MO) and a Compression/Decompression Action (CDA). 370 /-----------------------------------------------------------------\ 371 | Rule N | 372 /-----------------------------------------------------------------\| 373 | Rule i || 374 /-----------------------------------------------------------------\|| 375 | (FID) Rule 1 ||| 376 |+-------+--+--+--+------------+-----------------+---------------+||| 377 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 378 |+-------+--+--+--+------------+-----------------+---------------+||| 379 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 380 |+-------+--+--+--+------------+-----------------+---------------+||| 381 ||... |..|..|..| ... | ... | ... |||| 382 |+-------+--+--+--+------------+-----------------+---------------+||/ 383 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 384 |+-------+--+--+--+------------+-----------------+---------------+|/ 385 | | 386 \-----------------------------------------------------------------/ 388 Figure 3: Compression/Decompression Context 390 The Rule does not describe the original packet format which must be 391 known from the compressor/decompressor. The rule just describes the 392 compression/decompression behavior for the header fields. In the 393 rule, the description of the header field should be performed in the 394 format packet order. 396 The Rule also describes the compressed header fields which are 397 transmitted regarding their position in the rule which is used for 398 data serialization on the compressor side and data deserialization on 399 the decompressor side. 401 The Context describes the header fields and its values with the 402 following entries: 404 o A Field ID (FID) is a unique value to define the header field. 406 o A Field Length (FL) is the length of the field that can be of 407 fixed length as in IPv6 or UDP headers or variable length as in 408 CoAP options. Fixed length fields shall be represented by its 409 actual value in bits. Variable length fields shall be represented 410 by a function or a variable. 412 o A Field Position (FP) indicating if several instances of the field 413 exist in the headers which one is targeted. The default position 414 is 1 416 o A direction indicator (DI) indicating the packet direction. Three 417 values are possible: 419 * UPLINK (Up) when the field or the value is only present in 420 packets sent by the Dev to the App, 422 * DOWNLINK (Dw) when the field or the value is only present in 423 packet sent from the App to the Dev and 425 * BIDIRECTIONAL (Bi) when the field or the value is present 426 either upstream or downstream. 428 o A Target Value (TV) is the value used to make the comparison with 429 the packet header field. The Target Value can be of any type 430 (integer, strings, etc.). For instance, it can be a single value 431 or a more complex structure (array, list, etc.), such as a JSON or 432 a CBOR structure. 434 o A Matching Operator (MO) is the operator used to make the 435 comparison between the Field Value and the Target Value. The 436 Matching Operator may require some parameters. MO is only used 437 during the compression phase. 439 o A Compression Decompression Action (CDA) is used to describe the 440 compression and the decompression process. The CDA may require 441 some parameters, CDA are used in both compression and 442 decompression phases. 444 4.2. Rule ID 446 Rule IDs are sent between both compression/decompression elements. 447 The size of the Rule ID is not specified in this document, it is 448 implementation-specific and can vary regarding the LPWAN technology, 449 the number of flows, among others. 451 Some values in the Rule ID space are reserved for other 452 functionalities than header compression as fragmentation. (See 453 Section 5). 455 Rule IDs are specific to a Dev. Two Devs may use the same Rule ID for 456 different header compression. To identify the correct Rule ID, the 457 SCHC C/D needs to combine the Rule ID with the Dev L2 identifier to 458 find the appropriate Rule. 460 4.3. Packet processing 462 The compression/decompression process follows several steps: 464 o compression Rule selection: The goal is to identify which Rule(s) 465 will be used to compress the packet's headers. When doing 466 compression in the NGW side the SCHC C/D needs to find the correct 467 Rule to be used by identifying its Dev-ID and the Rule-ID. In the 468 Dev, only the Rule-ID may be used. The next step is to choose the 469 fields by their direction, using the direction indicator (DI), so 470 the fields that do not correspond to the appropriated DI will be 471 excluded. Next, then the fields are identified according to their 472 field identifier (FID) and field position (FP). If the field 473 position does not correspond, then the Rule is not used and the 474 SCHC take next Rule. Once the DI and the FP correspond to the 475 header information, each field's value is then compared to the 476 corresponding target value (TV) stored in the Rule for that 477 specific field using the matching operator (MO). If all the 478 fields in the packet's header satisfy all the matching operators 479 (MOs) of a Rule (i.e. all results are True), the fields of the 480 header are then processed according to the Compression/ 481 Decompression Actions (CDAs) and a compressed header is obtained. 482 Otherwise, the next rule is tested. If no eligible rule is found, 483 then the header must be sent without compression, in which case 484 the fragmentation process must be required. 486 o sending: The Rule ID is sent to the other end followed by the 487 information resulting from the compression of header fields, 488 directly followed by the payload. The product of field 489 compression is sent in the order expressed in the Rule for the 490 matching fields. The way the Rule ID is sent depends on the 491 specific LPWAN layer two technology and will be specified in a 492 specific document and is out of the scope of this document. For 493 example, it can be either included in a Layer 2 header or sent in 494 the first byte of the L2 payload. (Cf. Figure 4). 496 o decompression: In both directions, the receiver identifies the 497 sender through its device-id (e.g. MAC address) and selects the 498 appropriate Rule through the Rule ID. This Rule gives the 499 compressed header format and associates these values to the header 500 fields. It applies the CDA action to reconstruct the original 501 header fields. The CDA application order can be different from 502 the order given by the Rule. For instance, Compute-* may be 503 applied at the end, after all the other CDAs. 505 If after using SCHC compression and adding the payload to the L2 506 frame the datagram is not multiple of 8 bits, padding may be used. 508 +--- ... --+-------------- ... --------------+-----------+--...--+ 509 | Rule ID |Compressed Hdr Fields information| payload |padding| 510 +--- ... --+-------------- ... --------------+-----------+--...--+ 512 Figure 4: LPWAN Compressed Format Packet 514 4.4. Matching operators 516 Matching Operators (MOs) are functions used by both SCHC C/D 517 endpoints involved in the header compression/decompression. They are 518 not typed and can be applied indifferently to integer, string or any 519 other data type. The result of the operation can either be True or 520 False. MOs are defined as follows: 522 o equal: A field value in a packet matches with a TV in a Rule if 523 they are equal. 525 o ignore: No check is done between a field value in a packet and a 526 TV in the Rule. The result of the matching is always true. 528 o MSB(length): A matching is obtained if the most significant bits 529 of the length field value bits of the header are equal to the TV 530 in the rule. The MSB Matching Operator needs a parameter, 531 indicating the number of bits, to proceed to the matching. 533 o match-mapping: The goal of mapping-sent is to reduce the size of a 534 field by allocating a shorter value. The Target Value contains a 535 list of values. Each value is identified by a short ID (or 536 index). This operator matches if a field value is equal to one of 537 those target values. 539 4.5. Compression Decompression Actions (CDA) 541 The Compression Decompression Action (CDA) describes the actions 542 taken during the compression of headers fields, and inversely, the 543 action taken by the decompressor to restore the original value. 545 /--------------------+-------------+----------------------------\ 546 | Action | Compression | Decompression | 547 | | | | 548 +--------------------+-------------+----------------------------+ 549 |not-sent |elided |use value stored in ctxt | 550 |value-sent |send |build from received value | 551 |mapping-sent |send index |value from index on a table | 552 |LSB(length) |send LSB |TV OR received value | 553 |compute-length |elided |compute length | 554 |compute-checksum |elided |compute UDP checksum | 555 |Deviid |elided |build IID from L2 Dev addr | 556 |Appiid |elided |build IID from L2 App addr | 557 \--------------------+-------------+----------------------------/ 559 Figure 5: Compression and Decompression Functions 561 Figure 5 summarizes the basics functions defined to compress and 562 decompress a field. The first column gives the action's name. The 563 second and third columns outline the compression/decompression 564 behavior. 566 Compression is done in the rule order and compressed values are sent 567 in that order in the compressed message. The receiver must be able 568 to find the size of each compressed field which can be given by the 569 rule or may be sent with the compressed header. 571 If the field is identified as being variable, then its size must be 572 sent first using the following coding: 574 o If the size is between 0 and 14 bytes it is sent using 4 bits. 576 o For values between 15 and 255, the first 4 bits sent are set to 1 577 and the size is sent using 8 bits. 579 o For higher value, the first 12 bits are set to 1 and the size is 580 sent on 2 bytes. 582 4.5.1. not-sent CDA 584 The not-sent function is generally used when the field value is 585 specified in the rule and therefore known by the both Compressor and 586 Decompressor. This action is generally used with the "equal" MO. If 587 MO is "ignore", there is a risk to have a decompressed field value 588 different from the compressed field. 590 The compressor does not send any value in the compressed header for 591 the field on which compression is applied. 593 The decompressor restores the field value with the target value 594 stored in the matched rule. 596 4.5.2. value-sent CDA 598 The value-sent action is generally used when the field value is not 599 known by both Compressor and Decompressor. The value is sent in the 600 compressed message header. Both Compressor and Decompressor must 601 know the size of the field, either implicitly (the size is known by 602 both sides) or explicitly in the compressed header field by 603 indicating the length. This function is generally used with the 604 "ignore" MO. 606 4.5.3. mapping-sent 608 The mapping-sent is used to send a smaller index associated with the 609 list of values in the Target Value. This function is used together 610 with the "match-mapping" MO. 612 The compressor looks on the TV to find the field value and send the 613 corresponding index. The decompressor uses this index to restore the 614 field value. 616 The number of bits sent is the minimal size for coding all the 617 possible indexes. 619 4.5.4. LSB CDA 621 LSB action is used to avoid sending the known part of the packet 622 field header to the other end. This action is used together with the 623 "MSB" MO. A length can be specified in the rule to indicate how many 624 bits have to be sent. If the length is not specified, the number of 625 bits sent is the field length minus the bits' length specified in the 626 MSB MO. 628 The compressor sends the "length" Least Significant Bits. The 629 decompressor combines the value received with the Target Value. 631 If this action is made on a variable length field, the remaining size 632 in byte has to be sent before. 634 4.5.5. DEViid, APPiid CDA 636 These functions are used to process respectively the Dev and the App 637 Interface Identifiers (Deviid and Appiid) of the IPv6 addresses. 638 Appiid CDA is less common since current LPWAN technologies frames 639 contain a single address. 641 The IID value may be computed from the Device ID present in the Layer 642 2 header. The computation is specific for each LPWAN technology and 643 may depend on the Device ID size. 645 In the downstream direction, these CDA may be used to determine the 646 L2 addresses used by the LPWAN. 648 4.5.6. Compute-* 650 These classes of functions are used by the decompressor to compute 651 the compressed field value based on received information. Compressed 652 fields are elided during compression and reconstructed during 653 decompression. 655 o compute-length: compute the length assigned to this field. For 656 instance, regarding the field ID, this CDA may be used to compute 657 IPv6 length or UDP length. 659 o compute-checksum: compute a checksum from the information already 660 received by the SCHC C/D. This field may be used to compute UDP 661 checksum. 663 5. Fragmentation 665 5.1. Overview 667 In LPWAN technologies, the L2 data unit size typically varies from 668 tens to hundreds of bytes. If the entire IPv6 datagram after 669 applying SCHC header compression or when SCHC header compression is 670 not possible, fits within a single L2 data unit, the fragmentation 671 mechanism is not used and the packet is sent. Otherwise, the 672 datagram SHALL be broken into fragments. 674 LPWAN technologies impose some strict limitations on traffic, devices 675 are sleeping most of the time and may receive data during a short 676 period of time after transmission to preserve battery. To adapt the 677 SCHC fragmentation to the capabilities of LPWAN technologies, it is 678 desirable to enable optional fragment retransmission and to allow a 679 gradation of fragment delivery reliability. This document does not 680 make any decision with regard to which fragment delivery reliability 681 option(s) will be used over a specific LPWAN technology. 683 An important consideration is that LPWAN networks typically follow 684 the star topology, and therefore data unit reordering is not expected 685 in such networks. This specification assumes that reordering will 686 not happen between the entity performing fragmentation and the entity 687 performing reassembly. This assumption allows to reduce complexity 688 and overhead of the fragmentation mechanism. 690 5.2. Functionalities 692 This subsection describes the different fields in the fragmentation 693 header frames (see the fragmentation frames format in Section 5.4) 694 that are used to enable the fragmentation functionalities defined in 695 this document, and the different reliability options supported. 697 o Rule ID. The Rule ID is present in the fragmentation header and 698 in the ACK header format. The Rule ID is a fragmentation header 699 is used to identify that a fragment is being carried, the 700 fragmentation delivery reliability option used and it may indicate 701 the window size in use (if any). The Rule ID in the fragmentation 702 header also allows to interleave non-fragmented IPv6 datagrams 703 with fragments that carry a larger IPv6 datagram. The Rule ID in 704 an ACK allows to identify that the message is an ACK. 706 o Fragment Compressed Number (FCN). The FCN is included in all 707 fragments. This field can be understood as a truncated, efficient 708 representation of a larger-sized fragment number, and does not 709 carry an absolute fragment number. There are two FCN reserved 710 values that are used for controlling the fragmentation process, as 711 described next. The FCN value with all the bits equal to 1 (All- 712 1) denotes the last fragment of a packet. And the FCN value with 713 all the bits equal to 0 (All-0) denotes the last fragment of a 714 window (when such window is not the last one of the packet) in any 715 window mode or the fragments in No ACK mode. The rest of the FCN 716 values are assigned in a sequential and decreasing order, which 717 has the purpose to avoid possible ambiguity for the receiver that 718 might arise under certain conditions. In the fragments, this 719 field is an unsigned integer, with a size of N bits. In the No 720 ACK mode it is set to 1 bit (N=1). For the other reliability 721 options, it is recommended to use a number of bits (N) equal to or 722 greater than 3. Nevertheless, the apropriate value will be 723 defined in the corresponding technology documents. The FCN MUST 724 be set sequentially decreasing from the highest FCN in the window 725 (which will be used for the first fragment), and MUST wrap from 0 726 back to the highest FCN in the window. 727 For windows that are not the last one from a fragmented packet, 728 the FCN for the last fragment in such windows is an All-0. This 729 indicates that the window is finished and communication proceeds 730 according to the reliability option in use. The FCN for the last 731 fragment in the last window is an All-1. It is also important to 732 note that, for No ACK mode or N=1, the last fragment of the packet 733 will carry a FCN equal to 1, while all previous fragments will 734 carry a FCN of 0. 736 o Datagram Tag (DTag). The DTag field, if present, is set to the 737 same value for all fragments carrying the same IPv6 datagram. 738 This field allows to interleave fragments that correspond to 739 different IPv6 datagrams. In the fragment formats the size of the 740 DTag field is T bits, which may be set to a value greater than or 741 equal to 0 bits. DTag MUST be set sequentially increasing from 0 742 to 2^T - 1, and MUST wrap back from 2^T - 1 to 0. In the ACK 743 format, DTag carries the same value as the DTag field in the 744 fragments for which this ACK is intended. 746 o W (window): W is a 1-bit field. This field carries the same value 747 for all fragments of a window, and it is complemented for the next 748 window. The initial value for this field is 0. In the ACK 749 format, this field also has a size of 1 bit. In all ACKs, the W 750 bit carries the same value as the W bit carried by the fragments 751 whose reception is being positively or negatively acknowledged by 752 the ACK. 754 o Message Integrity Check (MIC). This field, which has a size of M 755 bits, is computed by the sender over the complete packet (i.e. a 756 SCHC compressed or an uncompressed IPv6 packet) before 757 fragmentation. The MIC allows the receiver to check errors in the 758 reassembled packet, while it also enables compressing the UDP 759 checksum by use of SCHC compression. The CRC32 as 0xEDB88320 is 760 recommended as the default algorithm for computing the MIC. 761 Nevertheless, other algorithm MAY be mandated in the corresponding 762 technology documents (e.g. technology-specific profiles). 764 o C (MIC checked): C is a 1-bit field. This field is used in the 765 ACK format packets to report the outcome of the MIC check, i.e. 766 whether the reassembled packet was correctly received or not. 768 o Retransmission Timer. It is used by a fragment sender after the 769 transmission of a window to detect a transmission error of the ACK 770 corresponding to this window. Depending on the reliability 771 option, it will lead to a request for an ACK retransmission on 772 ACK-Always or it will trigger the next window on ACK-on-error. 773 The dureation of this timer is not defined in this document and 774 must be defined in the corresponding technology documents (e.g. 775 technology-specific profiles). 777 o Inactivity Timer. This timer is used by a fragment receiver to 778 detect when there is a problem in the transmission of fragments 779 and the receiver does not get any fragment during a period of time 780 or a number of packets in a period of time. When this happens, an 781 Abort message needs to be sent. Initially, and each time a 782 fragment is received the timer is reinitialized. The duration of 783 this timer timer is not defined in this document and must be 784 defined in the specific technology document (e.g. technology- 785 specific profiles). 787 o Attempts. It is a counter used to request a missing ACK, and in 788 consequence to determine when an Abort is needed, because there 789 are recurrent fragment transmission errors, whose maximum value is 790 MAX_ACK_REQUESTS. The default value of MAX_ACK_REQUESTS is not 791 stated in this document, and it is expected to be defined in other 792 documents (e.g. technology-specific profiles). 794 o Bitmap. The Bitmap is a sequence of bits carried in an ACK for a 795 given window. Each bit in the Bitmap corresponds to a fragment of 796 the current window, and provides feedback on whether the fragment 797 has been received or not. The right-most position on the Bitmap 798 is used to report whether the All-0 or All-1 fragments have been 799 received or not. Feedback for a fragment with the highest FCN 800 value is provided by the left-most position in the Bitmap. In the 801 Bitmap, a bit set to 1 indicates that the corresponding FCN 802 fragment has been correctly sent and received. However, the 803 sending format of the bitmap will be truncated until a byte 804 boundary where the last error is given. However, when all the 805 Bitmap is transmitted, it may be truncated, see more details in 806 Section 5.5.3 808 o Abort. In case of error or when the Inactivity timer expires or 809 the MAX_ACK_REQUESTS is reached the sender or the receiver may use 810 the Abort frames. When the receiver needs to abort the on-going 811 fragmented packet transmission, it uses the ACK Abort format 812 packet with all the bits set to 1. The sender will use the All-1 813 Abort format to trigger the end of the transmission. 815 o Padding (P). Padding will be used to align the last byte of a 816 fragment with a byte boundary. The number of bits used for 817 padding is not defined and depends on the size of the Rule ID, 818 DTag and FCN fields, and on the layer two payload size. 820 5.3. Delivery Reliability options 822 This specification defines the following three fragment delivery 823 reliability options: 825 o No ACK. No ACK is the simplest fragment delivery reliability 826 option. The receiver does not generate overhead in the form of 827 acknowledgments (ACKs). However, this option does not enhance 828 delivery reliability beyond that offered by the underlying LPWAN 829 technology. In the No ACK option, the receiver MUST NOT issue 830 ACKs. 832 o Window mode - ACK always (ACK-always). 833 The ACK-always option provides flow control. In addition, this 834 option is able to handle long bursts of lost fragments, since 835 detection of such events can be done before the end of the IPv6 836 packet transmission, as long as the window size is short enough. 837 However, such benefit comes at the expense of ACK use. In ACK- 838 always, an ACK is transmitted by the fragment receiver after a 839 window of fragments has been sent. A window of fragments is a 840 subset of the full set of fragments needed to carry an IPv6 841 packet. In this mode, the ACK informs the sender about received 842 and/or missed fragments from the window of fragments. Upon 843 receipt of an ACK that informs about any lost fragments, the 844 sender retransmits the lost fragments. When an ACK is not 845 received by the fragment sender, the latter sends an ACK request 846 using the All-1 empty fragment. 848 The maximum number of ACK requests is MAX_ACK_REQUESTS. 850 o Window mode - ACK-on-error (ACK-on-error). The ACK-on-error 851 option is suitable for links offering relatively low L2 data unit 852 loss probability. This option reduces the number of ACKs 853 transmitted by the fragment receiver. This may be especially 854 beneficial in asymmetric scenarios, e.g. where fragmented data are 855 sent uplink and the underlying LPWAN technology downlink capacity 856 or message rate is lower than the uplink one. 857 In ACK-on-error, an ACK is transmitted by the fragment receiver 858 after a window of fragments have been sent, only if at least one 859 of the fragments in the window has been lost. In this mode, the 860 ACK informs the sender about received and/or missed fragments from 861 the window of fragments. Upon receipt of an ACK that informs 862 about any lost fragments, the sender retransmits the lost 863 fragments. However, if an ACK is lost, the sender assumes that 864 all fragments covered by the ACK have been successfully delivered. 865 And the receiver will abort the on-going fragmented packet 866 transmission. One exception to this behavior is in the last 867 window, whete the receiver MUST transmit an ACK, even if all the 868 fragments in the last window have been correctly received. 870 The same reliability option MUST be used for all fragments of a 871 packet. It is up to implementers and/or representatives of the 872 underlying LPWAN technology to decide which reliability option to use 873 and whether the same reliability option applies to all IPv6 packets 874 or not. Note that the reliability option to be used is not 875 necessarily tied to the particular characteristics of the underlying 876 L2 LPWAN technology (e.g. the No ACK reliability option may be used 877 on top of an L2 LPWAN technology with symmetric characteristics for 878 uplink and downlink). 879 This document does not make any decision as to which fragment 880 delivery reliability option(s) are supported by a specific LPWAN 881 technology. 883 Examples of the different reliability options described are provided 884 in Appendix B. 886 5.4. Fragmentation Frames Formats 888 This section defines the fragment format, the All-0 and All-1 frames 889 format, the ACK format and the Abort frames format. 891 5.4.1. Fragment format 893 A fragment comprises a fragmentation header, a fragment payload, and 894 Padding bits (if any). A fragment conforms to the format shown in 895 Figure 6. The fragment payload carries a subset of either a SCHC 896 header or an IPv6 header or the original IPv6 packet data payload. A 897 fragment is the payload in the L2 protocol data unit (PDU). 899 +-----------------+-----------------------+---------+ 900 | Fragment Header | Fragment payload | padding | 901 +-----------------+-----------------------+---------+ 903 Figure 6: Fragment format. 905 5.4.2. Fragmentation formats 907 In the No ACK option, fragments except the last one SHALL contain the 908 format as defined in Figure 7. The total size of the fragmentation 909 header is R bits. 911 <------------ R ----------> 912 <--T--> <--N--> 913 +-- ... --+- ... -+- ... -+---...---+-+ 914 | Rule ID | DTag | FCN | payload |P| 915 +-- ... --+- ... -+- ... -+---...---+-+ 917 Figure 7: Fragmentation Format for Fragments except the Last One, No 918 ACK option 920 In any of the Window mode options, fragments except the last one 921 SHALL contain the fragmentation format as defined in Figure 8. The 922 total size of this fragmentation header is R bits. 924 <------------ R ----------> 925 <--T--> 1 <--N--> 926 +-- ... --+- ... -+-+- ... -+---...---+-+ 927 | Rule ID | DTag |W| FCN | payload |P| 928 +-- ... --+- ... -+-+- ... -+---...---+-+ 930 Figure 8: Fragmentation Format for Fragments except the Last One, 931 Window mode 933 5.4.3. ACK format 935 The format of an ACK that acknowledges a window that is not the last 936 one (denoted as ALL-0 window) is shown in Figure 9. 938 <-------- R -------> 939 <- T -> 1 940 +---- ... --+-... -+-+----- ... ---+ 941 | Rule ID | DTag |W| bitmap | (no payload) 942 +---- ... --+-... -+-+----- ... ---+ 944 Figure 9: ACK format for All-0 windows 946 To acknowledge the last window of a packet (denoted as All-1 window), 947 a C bit (i.e. MIC checked) following the W bit is set to 1 to 948 indicate that the MIC check computed by the receiver matches the MIC 949 present in the ALL-1 fragment. If the MIC check fails, the C bit is 950 set to 0 and the Bitmap for the All-1 window follows. 952 <-------- R -------> <- byte boundary -> 953 <- T -> 1 1 954 +---- ... --+-... -+-+-+ 955 | Rule ID | DTag |W|1| (MIC correct) 956 +---- ... --+-... -+-+-+ 958 +---- ... --+-... -+-+-+------- ... -------+ 959 | Rule ID | DTag |W|0| bitmap | (MIC Incorrect) 960 +---- ... --+-... -+-+-+------- ... -------+ 961 C 963 Figure 10: Format of an ACK for All-1 windows 965 5.4.4. All-1 and All-0 formats 967 The All-0 format is used for the last fragment of a window that is 968 not the last window of the packet. 970 <------------ R ------------> 971 <- T -> 1 <- N -> 972 +-- ... --+- ... -+-+- ... -+--- ... ---+ 973 | Rule ID | DTag |W| 0..0 | payload | 974 +-- ... --+- ... -+-+- ... -+--- ... ---+ 976 Figure 11: All-0 fragment format 978 The All-0 empty fragment format is used by a sender to request an ACK 979 in ACK-Always mode 980 <------------ R ------------> 981 <- T -> 1 <- N -> 982 +-- ... --+- ... -+-+- ... -+ 983 | Rule ID | DTag |W| 0..0 | (no payload) 984 +-- ... --+- ... -+-+- ... -+ 986 Figure 12: All-0 empty fragment format 988 In the No ACK option, the last fragment of an IPv6 datagram SHALL 989 contain a fragmentation header that conforms to the format shown in 990 Figure 13. The total size of this fragmentation header is R+M bits. 992 <------------- R ----------> 993 <- T -> <-N-><----- M -----> 994 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 995 | Rule ID | DTag | 1 | MIC | payload | 996 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 998 Figure 13: All-1 Fragmentation Format for the Last Fragment, No ACK 999 option 1001 In any of the Window modes, the last fragment of an IPv6 datagram 1002 SHALL contain a fragmentation header that conforms to the format 1003 shown in Figure 14. The total size of the fragmentation header in 1004 this format is R+M bits. It is used for request a retransmission 1006 <------------ R ------------> 1007 <- T -> 1 <- N -> <---- M -----> 1008 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 1009 | Rule ID | DTag |W| 11..1 | MIC | payload | 1010 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 1011 (FCN) 1013 Figure 14: All-1 Fragmentation Format for the Last Fragment, Window 1014 mode 1016 In either ACK-Always or ACK-on-error, in order to request a 1017 retransmission of the ACK for the All-1 window, the fragment sender 1018 uses the format shown in Figure 15. The total size of the 1019 fragmentation header in this format is R+M bits. 1021 <------------ R ------------> 1022 <- T -> 1 <- N -> <---- M -----> 1023 +-- ... --+- ... -+-+- ... -+---- ... ----+ 1024 | Rule ID | DTag |W| 1..1 | MIC | (no payload) 1025 +-- ... --+- ... -+-+- ... -+---- ... ----+ 1027 Figure 15: All-1 for Retries format fragment also called All-1 empty 1029 The values for R, N, T and M are not specified in this document, and 1030 have to be determined in other documents (e.g. technology-specific 1031 profile documents). 1033 5.4.5. Abort formats 1035 The All-1 Abort format and the ACK abort have the following formats. 1037 <------ byte boundary ------><--- 1 byte ---> 1038 +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+ 1039 | Rule ID | DTag |W| FCN | FF | (no MIC & no payload) 1040 +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+ 1042 Figure 16: All-1 Abort format 1044 <------ byte boundary -----><--- 1 byte ---> 1046 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Rule ID | DTag |W| 1..1| FF | 1048 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Figure 17: ACK Abort format 1052 5.5. Baseline mechanism 1054 The fragment receiver needs to identify all the fragments that belong 1055 to a given IPv6 datagram. To this end, the receiver SHALL use: 1057 o The sender's L2 source address (if present), 1059 o The destination's L2 address (if present), 1061 o Rule ID and 1063 o DTag (the latter, if present). 1065 Then, the fragment receiver may determine the fragment delivery 1066 reliability option that is used for this fragment based on the Rule 1067 ID field in that fragment. 1069 Upon receipt of a link fragment, the receiver starts constructing the 1070 original unfragmented packet. It uses the FCN and the order of 1071 arrival of each fragment to determine the location of the individual 1072 fragments within the original unfragmented packet. A fragment 1073 payload may carry bytes from a SCHC compressed IPv6 header, an 1074 uncompressed IPv6 header or an IPv6 datagram data payload. An 1075 unfragmented packet could be a SCHC compressed or an uncompressed 1076 IPv6 packet (header and data). For example, the receiver may place 1077 the fragment payload within a payload datagram reassembly buffer at 1078 the location determined from: the FCN, the arrival order of the 1079 fragments, and the fragment payload sizes. In Window mode, the 1080 fragment receiver also uses the W bit in the received fragments. 1081 Note that the size of the original, unfragmented packet cannot be 1082 determined from fragmentation headers. 1084 Fragmentation functionality uses the FCN value, which has a length of 1085 N bits. The All-1 and All-0 FCN values are used to control the 1086 fragmentation transmission. The FCN will be assigned sequentially in 1087 a decreasing order starting from 2^N-2, i.e. the highest possible FCN 1088 value depending on the FCN number of bits, but excluding the All-1 1089 value. In all modes, the last fragment of a packet must contains a 1090 MIC which is used to check if there are errors or missing fragments, 1091 and must use the corresponding All-1 fragment format. Also note 1092 that, a fragment with an All-0 format is considered the last fragment 1093 of the current window. 1095 If the recipient receives the last fragment of a datagram (All-1), it 1096 checks for the integrity of the reassembled datagram, based on the 1097 MIC received. In No ACK, if the integrity check indicates that the 1098 reassembled datagram does not match the original datagram (prior to 1099 fragmentation), the reassembled datagram MUST be discarded. In 1100 Window mode, a MIC check is also performed by the fragment receiver 1101 after reception of each subsequent fragment retransmitted after the 1102 first MIC check. 1104 5.5.1. No ACK 1106 In the No ACK mode there is no feedback communication from the 1107 fragment receiver. The sender will send the fragments of a packet 1108 until the last one without any possibility to know if errors or a 1109 losses have occurred. As in this mode there is not a need to 1110 identify specific fragments a one-bit FCN is used, therefore FCN 1111 All-0 will be used in all fragments except the last one. The latter 1112 will carry an All-1 FCN and will also carry the MIC. The receiver 1113 will wait for fragments and will set the Inactivity timer. The No 1114 ACK mode will use the MIC contained in the last fragment to check 1115 error. When the Inactivity Timer expires or when the MIC check 1116 indicates that the reassembled packet does not match the originall 1117 one, the receiver will release all resources allocated to reassembly 1118 of the packet. The initial value of the Inactivity Timer will be 1119 determined based on the characteristics of the underlying LPWAN 1120 technology and will be defined in other documents (e.g. technology- 1121 specific profile documents). 1123 5.5.2. The Window modes 1125 In Window modes, a jumping window protocol is using two windows 1126 alternatively, 0 and 1. An FCN set to All-0 indicates that the 1127 window is over (i.e. the fragment is the last one of the window) and 1128 allows to switch from one window to another. The All-1 FCN in a 1129 fragment indicates that it is the last fragment of the packet and 1130 therefore there will not be another window for the packet. 1132 The Window mode offers two different reliability options modes: ACK- 1133 on-error and ACK-always. 1135 5.5.2.1. ACK-Always 1137 The sender starts sending fragments using the two windows procedure. 1138 A delay between each fragment can be added to respect regulation 1139 rules or constraints imposed by the applications. Each time a 1140 fragment is sent the FCN is decreased by one and the sending 1141 information is set locally. When the FCN reaches value 0 and there 1142 are more fragments to be sent, an All-0 fragment is sent and the 1143 retransmission timer is set. The sender waits for an ACK to know if 1144 there were some transmission errors. If there are some errors the 1145 receiver sends an ACK with the corresponding errors in the Bitmap, 1146 otherwise, an ACK without Bitmap will be sent and a new window should 1147 be sent. When the last fragment is sent, and All-1 fragment with MIC 1148 is sent. The sender sets the retransmission timer to wait for the 1149 ACK corresponding to the last window. During this period, the sender 1150 starts listening to the radio and starts an Inactivity timer, which 1151 is dimensioned based on the received window available for the LPWAN 1152 technology in use. If the Inactivity timer expires an empty All-0 1153 (or All-1 if the last fragment has been sent) fragment is sent to ask 1154 the receiver to resend its ACK. The window number is not changed. 1156 When the sender receives an ACK, it checks the window value. The ACK 1157 fragments carrying an unexpected W bit are discarded. If the window 1158 number of the received ACK is correct, the sender compares the 1159 sending information with the received Bitmap. If the sending 1160 information is equal to the received Bitmap all the fragments sent 1161 during the window have been well received. If at least one fragment 1162 needs to be sent, the sender moves its sending window to the next 1163 value and sends the last fragment. If no more fragments have to be 1164 sent, then the fragmented packet transmission is finished. 1166 If some fragments are missing (not set in the Bitmap) then the sender 1167 resends the missing fragments. When the retransmission is finished, 1168 it starts the retransmission timer (even if an All-0 or an All-1 has 1169 not been sent during the retransmission) and waits for ACK. 1171 If the sending information is different from the received Bitmap the 1172 counter Attempts is increased and the sender resends the missing 1173 fragments again when a MAX_ACK_REQUESTS is reached, the sender sends 1174 an Abort and drops the fragments. The sender Aborts the transmission 1175 when a corrupt MIC has been received or when MAX_ACK_REQUESTS has 1176 reached. 1178 At the beginning, the receiver side expects to receive window 0. Any 1179 fragment not belonging to the current window is discarded. All 1180 Fragments belonging to the correct window are accepted, the fragment 1181 number is computed based on the FCN value. The receiver updates the 1182 Bitmap with the correct received fragments. 1184 When All-0 fragment is received, it indicates that all the fragments 1185 have been sent in the current window. Since the sender is not 1186 obliged to send a full window, some fragment number not set in the 1187 memory may not correspond to losses. It sends the corresponding ACK 1188 and the next window can start. 1190 When All-1 fragment is received, it indicates that the transmission 1191 is finished. Since the last window is not full, the MIC will be used 1192 to detect if all the fragments have been received. A correct MIC 1193 indicates the end of the transmission but the receiver must stay 1194 alive an Inactivity timer period to answer to empty All-1 fragment 1195 the sender may send if the ACK is lost. 1197 If All-1 fragment has not been received, the receiver expects a new 1198 window. It waits for the next fragment. If the window value has not 1199 changed, the received fragments are part of a retransmission. A 1200 receiver that has already received a fragment should discard it, 1201 otherwise, it updates the Bitmap. If all the bits of the Bitmap are 1202 set to one, the receiver may send an ACK without waiting for an All-0 1203 fragment. 1205 If the window value is set to the next value, this means that the 1206 sender has received a correct bitmap, which means that all the 1207 fragments have been received. The receiver changes the value of the 1208 expected window. 1210 If the receiver receives an All-0 fragment, the sender may send one 1211 or more fragments per window. Otherwise, some fragments in the 1212 window have been lost. 1214 If the receiver receives an All-1 fragment this means that the 1215 transmission should be finished. If the MIC is incorrect some 1216 fragments have been lost. It sends the ACK. In case of an incorrect 1217 MIC, the receivers wait for fragments belonging to the same window. 1218 After MAX_ACK_REQUESTS the receiver will Abort the transmission. It 1219 can also Abort when the Inactivity timer has expired. 1221 5.5.2.2. ACK-on-error 1223 The ACK-on-error is similar to the ACK-Always procedure, the 1224 difference is that in ACK-on-error the ACK is not sent at the end of 1225 each window but only when there is an error. In Ack-on-error mode, 1226 the retransmission timer expiration will be considered as a positive 1227 acknowledgment, it is set when receiving an All-0 or an All-1 1228 fragment. If there are no more fragments then the fragmentation is 1229 finished. 1231 When the All-1 last fragment is sent and the correct MIC have been 1232 received an ACK is sent to confirms the end of the correct 1233 transmission. If the retransmission timer expires an All-1 empty 1234 request the last ACK that MUST be sent to complete the fragmentation 1235 transmission. 1237 If the sender receives an ACK, it checks the window value. ACKs with 1238 the non-expected window number are discarded. If the window number 1239 on the received Bitmap is correct, the sender verifies if the 1240 receiver has all the fragments. When all the fragments have been 1241 received the transmission of a new window should continue. 1242 Otherwise, when there is an error the counter Attempts is increased 1243 and the sender resends the missing fragments again. When a 1244 MAX_ACK_REQUESTS is reached, the sender sends an Abort. When the 1245 retransmission is finished, it starts listening to the ACK (even if 1246 an All-0 or an All-1 has not been sent during the retransmission) and 1247 set the retransmission timer. If the retransmission timer expires 1248 the transmission is aborted. 1250 Unlike the sender, the receiver for ACK-on-error has some 1251 differences. First, we are not sending ACK unless there is an error 1252 or an unexpected behavior. The receiver starts with the expected 1253 window and maintains the information indicating which fragments it 1254 has received (All-0 and All-1 occupy the same position). After 1255 receiving a fragment an Inactivity timer is set, if nothing has been 1256 received and the Inactivity timer expires the transmission is 1257 aborted. 1259 Any fragment not belonging to the current window is discarded. The 1260 Fragment Number is computed based on the FCN value. When an All-0 1261 fragment is received and the Bitmap is full, the receiver changes the 1262 window value. 1264 An All-0 fragment and not a full bitmap indicate that all the 1265 fragments have been sent in the current window. Since the sender is 1266 not obligated to send a full window, some fragment number not used 1267 may not correspond to losses. As the receiver does not know if the 1268 missing fragments are lost or normal missing fragments, it sends an 1269 ACK. 1271 An All-1 fragment indicates that the transmission is finished. Since 1272 the last window is not full, the MIC will be used to detect if all 1273 the fragments have been received. A correct MIC indicates the end of 1274 the transmission. 1276 If All-1 fragment has not been received, the receiver expects a new 1277 window. It waits for the next fragment. If the window value has not 1278 changed, the received fragments are part of a retransmission. A 1279 receiver that has already received a fragment should discard it. If 1280 all the bits of the Bitmap are set to one, the receiver waits for the 1281 next window without waiting for an All-0 fragment and it does not 1282 send an ACK either. While the receiver waits for next window and if 1283 the window value is set to the next value, and if an All-1 fragment 1284 with the next value window arrived the receiver goes to error and 1285 abort the transmission, it drops the fragments. 1287 If the receiver receives an All-1 fragment this means that the 1288 transmission should be finished. If the MIC is incorrect some 1289 fragments have been lost. It sends an ACK. 1291 In case of an incorrect MIC, the receivers wait for fragment 1292 belonging to the same window or the expiration of the Inactivity 1293 timer which will Abort the transmission. 1295 5.5.3. Bitmap Optimization 1297 The Fragmentation Bitmap is the optmization of what has been 1298 received. It is transmitted in the ACK format fragment when there 1299 are some missing fragments. An ACK message may introduce padding at 1300 the end to align transmitted data to a byte boundary. The first byte 1301 boundary includes one or more complete bytes, depending on the size 1302 of Rule ID and DTag. 1304 The receiver generates the Bitmap which may have the size of a single 1305 downlink frame of the LPWAN technology used. To avoid this problem 1306 the FCN size should be set to the corresponding downlink size minus 1 1307 bit for C bit. The C bit will be sent only in the ACK for the last 1308 frame of the packet (All-1). 1310 <---- bitmap fragments ----> 1311 | Rule ID | DTag |W|C|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|0| 1312 |--- byte boundary ----| 1 byte next | 1 byte next | 1314 Figure 18: Bitmap 1316 Bitmap transmitted MUST be optimized in size to reduce frame size. 1317 The right-most bytes with all Bitmap bit set to 1 MUST be removed 1318 from the transmission. As the receiver knows the Bitmap size, it can 1319 reconstruct the value. In the example Figure 19 the last 2 bytes of 1320 the bitmap are set to 1, therefore, they are not sent. 1322 In the last window, when checked bit C value is one, means that the 1323 MIC is corrected and the Bitmap is not sent. Otherwise, the Bitmap 1324 needs to be sent after the C bit. Note that the introduction of a C 1325 bit may force to reduce the number of fragments to allow the bitmap 1326 to fit in a frame. 1328 <------- R -------> 1329 <- T -> 1 1330 +---- ... --+-... -+-+-+-+ 1331 | Rule ID | DTag |W|1|0| 1332 +---- ... --+-... -+-+-+-+ 1333 |---- byte boundary -----| 1335 Figure 19: Bitmap transmitted fragment format 1337 Figure 20 shows an example of an ACK (N=3), where the Bitmap 1338 indicates that the second and the fifth fragments have not been 1339 correctly received. 1341 <------ R ------>6 5 4 3 2 1 0 (*) 1342 <- T -> 1 1343 | Rule ID | DTag |W|1|0|1|1|0|1|all-0|padding| Bitmap 1344 |--- byte boundary ----| 1 byte next | 1345 (*)=(FCN values indicating the order) 1347 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+ 1348 | Rule ID | DTag |W|1|0|1|1|0|1|1|P| transmitted Bitmap 1349 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+ 1350 |--- byte boundary ----| 1 byte next | 1352 Figure 20: Example of the bitmap in Window mode, in any window except 1353 the last one, for N=3) 1355 Figure 21 shows an example of an ACK (N=3), where the bitmap 1356 indicates that the MIC check has failed but there is no missing 1357 fragments. 1359 <------- R -------> 6 5 4 3 2 1 7 (*) 1360 <- T -> 1 1 1361 | Rule ID | DTag |W|0|1|1|1|1|1|1|1|padding| Bitmap 1362 |---- byte boundary ----| 1 byte next | 1 byte next | 1363 C 1364 +---- ... --+-... -+-+-+-+ 1365 | Rule ID | DTag |W|0|1| transmitted Bitmap 1366 +---- ... --+-... -+-+-+-+ 1367 |---- byte boundary -----| 1368 (*) = (FCN values indicating the order) 1370 Figure 21: Example of the Bitmap in Window mode for the last window, 1371 for N=3) 1373 5.6. Supporting multiple window sizes 1375 For ACK-Always or ACK-on-error, implementers may opt to support a 1376 single window size or multiple window sizes. The latter, when 1377 feasible, may provide performance optimizations. For example, a 1378 large window size may be used for packets that need to be carried by 1379 a large number of fragments. However, when the number of fragments 1380 required to carry a packet is low, a smaller window size, and thus a 1381 shorter bitmap, may be sufficient to provide feedback on all 1382 fragments. If multiple window sizes are supported, the Rule ID may 1383 be used to signal the window size in use for a specific packet 1384 transmission. 1386 Note that the same window size MUST be used for the transmission of 1387 all fragments that belong to a packet. 1389 5.7. Downlink fragment transmission 1391 In some LPWAN technologies, as part of energy-saving techniques, 1392 downlink transmission is only possible immediately after an uplink 1393 transmission. In order to avoid potentially high delay for 1394 fragmented datagram transmission in the downlink, the fragment 1395 receiver MAY perform an uplink transmission as soon as possible after 1396 reception of a fragment that is not the last one. Such uplink 1397 transmission may be triggered by the L2 (e.g. an L2 ACK sent in 1398 response to a fragment encapsulated in a L2 frame that requires an L2 1399 ACK) or it may be triggered from an upper layer. 1401 For fragmented packet transmission in the downlink, and when ACK 1402 Always is used, the fragment receiver MAY support timer-based ACK 1403 retransmission. In this mechanism, the fragment receiver initializes 1404 and starts a timer (the Inactivity Timer is used) after the 1405 transmission of an ACK, except when the ACK is sent in response to 1406 the last fragment of a packet (All-1 fragment). In the latter case, 1407 the fragment receiver does not start a timer after transmission of 1408 the ACK. 1410 If, after transmission of an ACK that is not an All-1 fragment, and 1411 before expiration of the corresponding Inactivity timer, the fragment 1412 receiver receives a fragment that belongs to the current window (e.g. 1413 a missing fragment from the current window) or to the next window, 1414 the Inactivity timer for the ACK is stopped. However, if the 1415 Inactivity timer expires, the ACK is resent and the Inactivity timer 1416 is reinitialized and restarted. 1418 The default initial value for the Inactivity timer, as well as the 1419 maximum number of retries for a specific ACK, denoted 1420 MAX_ACK_RETRIES, are not defined in this document, and need to be 1421 defined in other documents (e.g. technology-specific profiles). The 1422 initial value of the Inactivity timer is expected to be greater than 1423 that of the Retransmission timer, in order to make sure that a 1424 (buffered) fragment to be retransmitted can find an opportunity for 1425 that transmission. 1427 When the fragment sender transmits the All-1 fragment, it initializes 1428 and starts its retransmission timer to a long value (e.g. several 1429 times the initial Inactivity timer). If an ACK is received before 1430 expiration of this timer, the fragment sender retransmits any lost 1431 fragments reported by the ACK, or if the ACK confirms successful 1432 reception of all fragments of the last window, transmission of the 1433 fragmented packet ends. If the timer expires, and no ACK has been 1434 received since the start of the timer, the fragment sender assumes 1435 that the all-1 fragment has been successfully received (and possibly, 1436 the last ACK has been lost: this mechanism assumes that the 1437 retransmission timer for the all-1 fragment is long enough to allow 1438 several ACK retries if the all-1 fragment has not been received by 1439 the fragment receiver, and it also assumes that it is unlikely that 1440 several ACKs become all lost). 1442 6. Padding management 1444 SCHC header, either for compression, fragmentation or acknowledgment 1445 does not preserve byte alignment. Since most of the LPWAN network 1446 technologies payload is expressed in an integer number of bytes; the 1447 sender will introduce at the end some padding bits while the receiver 1448 must be able to eliminate them. 1450 The algorithm for padding bit elimination for compressed or 1451 fragmented frames is simple. Based on the following principle: * The 1452 SCHC header is not aligned on a byte boundary, but its size in bits 1453 is given by the rule. 1455 o The data size is variable, but always a multiple of 8 bits. 1457 o Padding bits MUST never exceed 7 bits. 1459 In that case, a receiver after decoding the SCHC header, must take 1460 the maximum multiple of 8 bits as data. The remaining bits are 1461 padding bits. 1463 7. SCHC Compression for IPv6 and UDP headers 1465 This section lists the different IPv6 and UDP header fields and how 1466 they can be compressed. 1468 7.1. IPv6 version field 1470 This field always holds the same value. Therefore, the TV is 6, the 1471 MO is "equal" and the "CDA "not-sent"". 1473 7.2. IPv6 Traffic class field 1475 If the DiffServ field identified by the rest of the rule do not vary 1476 and is known by both sides, the TV should contain this well-known 1477 value, the MO should be "equal" and the CDA must be "not-sent. 1479 If the DiffServ field identified by the rest of the rule varies over 1480 time or is not known by both sides, then there are two possibilities 1481 depending on the variability of the value, the first one is to do not 1482 compressed the field and sends the original value, or the second 1483 where the values can be computed by sending only the LSB bits: 1485 o TV is not set to any value, MO is set to "ignore" and CDA is set 1486 to "value-sent" 1488 o TV contains a stable value, MO is MSB(X) and CDA is set to LSB 1490 7.3. Flow label field 1492 If the Flow Label field identified by the rest of the rule does not 1493 vary and is known by both sides, the TV should contain this well- 1494 known value, the MO should be "equal" and the CDA should be "not- 1495 sent". 1497 If the Flow Label field identified by the rest of the rule varies 1498 during time or is not known by both sides, there are two 1499 possibilities depending on the variability of the value, the first 1500 one is without compression and then the value is sent and the second 1501 where only part of the value is sent and the decompressor needs to 1502 compute the original value: 1504 o TV is not set, MO is set to "ignore" and CDA is set to "value- 1505 sent" 1507 o TV contains a stable value, MO is MSB(X) and CDA is set to LSB 1509 7.4. Payload Length field 1511 If the LPWAN technology does not add padding, this field can be 1512 elided for the transmission on the LPWAN network. The SCHC C/D 1513 recomputes the original payload length value. The TV is not set, the 1514 MO is set to "ignore" and the CDA is "compute-IPv6-length". 1516 If the payload length needs to be sent and does not need to be coded 1517 in 16 bits, the TV can be set to 0x0000, the MO set to "MSB (16-s)" 1518 and the CDA to "LSB". The 's' parameter depends on the expected 1519 maximum packet length. 1521 On other cases, the payload length field must be sent and the CDA is 1522 replaced by "value-sent". 1524 7.5. Next Header field 1526 If the Next Header field identified by the rest of the rule does not 1527 vary and is known by both sides, the TV should contain this Next 1528 Header value, the MO should be "equal" and the CDA should be "not- 1529 sent". 1531 If the Next header field identified by the rest of the rule varies 1532 during time or is not known by both sides, then TV is not set, MO is 1533 set to "ignore" and CDA is set to "value-sent". A matching-list may 1534 also be used. 1536 7.6. Hop Limit field 1538 The End System is generally a device and does not forward packets. 1539 Therefore, the Hop Limit value is constant. So, the TV is set with a 1540 default value, the MO is set to "equal" and the CDA is set to "not- 1541 sent". 1543 Otherwise the value is sent on the LPWAN: TV is not set, MO is set to 1544 ignore and CDA is set to "value-sent". 1546 Note that the field behavior differs in upstream and downstream. In 1547 upstream, since there is no IP forwarding between the Dev and the 1548 SCHC C/D, the value is relatively constant. On the other hand, the 1549 downstream value depends of Internet routing and may change more 1550 frequently. One solution could be to use the Direction Indicator 1551 (DI) to distinguish both directions to elide the field in the 1552 upstream direction and send the value in the downstream direction. 1554 7.7. IPv6 addresses fields 1556 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 1557 long fields; one for the prefix and one for the Interface Identifier 1558 (IID). These fields should be compressed. To allow a single rule, 1559 these values are identified by their role (DEV or APP) and not by 1560 their position in the frame (source or destination). The SCHC C/D 1561 must be aware of the traffic direction (upstream, downstream) to 1562 select the appropriate field. 1564 7.7.1. IPv6 source and destination prefixes 1566 Both ends must be synchronized with the appropriate prefixes. For a 1567 specific flow, the source and destination prefix can be unique and 1568 stored in the context. It can be either a link-local prefix or a 1569 global prefix. In that case, the TV for the source and destination 1570 prefixes contain the values, the MO is set to "equal" and the CDA is 1571 set to "not-sent". 1573 In case the rule allows several prefixes, mapping-list must be used. 1574 The different prefixes are listed in the TV associated with a short 1575 ID. The MO is set to "match-mapping" and the CDA is set to "mapping- 1576 sent". 1578 Otherwise the TV contains the prefix, the MO is set to "equal" and 1579 the CDA is set to value-sent. 1581 7.7.2. IPv6 source and destination IID 1583 If the DEV or APP IID are based on an LPWAN address, then the IID can 1584 be reconstructed with information coming from the LPWAN header. In 1585 that case, the TV is not set, the MO is set to "ignore" and the CDA 1586 is set to "DEViid" or "APPiid". Note that the LPWAN technology is 1587 generally carrying a single device identifier corresponding to the 1588 DEV. The SCHC C/D may also not be aware of these values. 1590 If the DEV address has a static value that is not derived from an 1591 IEEE EUI-64, then TV contains the actual Dev address value, the MO 1592 operator is set to "equal" and the CDA is set to "not-sent". 1594 If several IIDs are possible, then the TV contains the list of 1595 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 1596 "mapping-sent". 1598 Otherwise the value variation of the IID may be reduced to few bytes. 1599 In that case, the TV is set to the stable part of the IID, the MO is 1600 set to MSB and the CDA is set to LSB. 1602 Finally, the IID can be sent on the LPWAN. In that case, the TV is 1603 not set, the MO is set to "ignore" and the CDA is set to "value- 1604 sent". 1606 7.8. IPv6 extensions 1608 No extension rules are currently defined. They can be based on the 1609 MOs and CDAs described above. 1611 7.9. UDP source and destination port 1613 To allow a single rule, the UDP port values are identified by their 1614 role (DEV or APP) and not by their position in the frame (source or 1615 destination). The SCHC C/D must be aware of the traffic direction 1616 (upstream, downstream) to select the appropriate field. The 1617 following rules apply for DEV and APP port numbers. 1619 If both ends know the port number, it can be elided. The TV contains 1620 the port number, the MO is set to "equal" and the CDA is set to "not- 1621 sent". 1623 If the port variation is on few bits, the TV contains the stable part 1624 of the port number, the MO is set to "MSB" and the CDA is set to 1625 "LSB". 1627 If some well-known values are used, the TV can contain the list of 1628 these values, the MO is set to "match-mapping" and the CDA is set to 1629 "mapping-sent". 1631 Otherwise the port numbers are sent on the LPWAN. The TV is not set, 1632 the MO is set to "ignore" and the CDA is set to "value-sent". 1634 7.10. UDP length field 1636 If the LPWAN technology does not introduce padding, the UDP length 1637 can be computed from the received data. In that case, the TV is not 1638 set, the MO is set to "ignore" and the CDA is set to "compute-UDP- 1639 length". 1641 If the payload is small, the TV can be set to 0x0000, the MO set to 1642 "MSB" and the CDA to "LSB". 1644 On other cases, the length must be sent and the CDA is replaced by 1645 "value-sent". 1647 7.11. UDP Checksum field 1649 IPv6 mandates a checksum in the protocol above IP. Nevertheless, if 1650 a more efficient mechanism such as L2 CRC or MIC is carried by or 1651 over the L2 (such as in the LPWAN fragmentation process (see 1652 Section 5)), the UDP checksum transmission can be avoided. In that 1653 case, the TV is not set, the MO is set to "ignore" and the CDA is set 1654 to "compute-UDP-checksum". 1656 In other cases, the checksum must be explicitly sent. The TV is not 1657 set, the MO is set to "ignore" and the CDF is set to "value-sent". 1659 8. Security considerations 1661 8.1. Security considerations for header compression 1663 A malicious header compression could cause the reconstruction of a 1664 wrong packet that does not match with the original one, such 1665 corruption may be detected with end-to-end authentication and 1666 integrity mechanisms. Denial of Service may be produced but its 1667 arise other security problems that may be solved with or without 1668 header compression. 1670 8.2. Security considerations for fragmentation 1672 This subsection describes potential attacks to LPWAN fragmentation 1673 and suggests possible countermeasures. 1675 A node can perform a buffer reservation attack by sending a first 1676 fragment to a target. Then, the receiver will reserve buffer space 1677 for the IPv6 packet. Other incoming fragmented packets will be 1678 dropped while the reassembly buffer is occupied during the reassembly 1679 timeout. Once that timeout expires, the attacker can repeat the same 1680 procedure, and iterate, thus creating a denial of service attack. 1681 The (low) cost to mount this attack is linear with the number of 1682 buffers at the target node. However, the cost for an attacker can be 1683 increased if individual fragments of multiple packets can be stored 1684 in the reassembly buffer. To further increase the attack cost, the 1685 reassembly buffer can be split into fragment-sized buffer slots. 1686 Once a packet is complete, it is processed normally. If buffer 1687 overload occurs, a receiver can discard packets based on the sender 1688 behavior, which may help identify which fragments have been sent by 1689 an attacker. 1691 In another type of attack, the malicious node is required to have 1692 overhearing capabilities. If an attacker can overhear a fragment, it 1693 can send a spoofed duplicate (e.g. with random payload) to the 1694 destination. If the LPWAN technology does not support suitable 1695 protection (e.g. source authentication and frame counters to prevent 1696 replay attacks), a receiver cannot distinguish legitimate from 1697 spoofed fragments. Therefore, the original IPv6 packet will be 1698 considered corrupt and will be dropped. To protect resource- 1699 constrained nodes from this attack, it has been proposed to establish 1700 a binding among the fragments to be transmitted by a node, by 1701 applying content-chaining to the different fragments, based on 1702 cryptographic hash functionality. The aim of this technique is to 1703 allow a receiver to identify illegitimate fragments. 1705 Further attacks may involve sending overlapped fragments (i.e. 1706 comprising some overlapping parts of the original IPv6 datagram). 1707 Implementers should make sure that correct operation is not affected 1708 by such event. 1710 In Window mode - ACK on error, a malicious node may force a fragment 1711 sender to resend a fragment a number of times, with the aim to 1712 increase consumption of the fragment sender's resources. To this 1713 end, the malicious node may repeatedly send a fake ACK to the 1714 fragment sender, with a bitmap that reports that one or more 1715 fragments have been lost. In order to mitigate this possible attack, 1716 MAX_FRAG_RETRIES may be set to a safe value which allows to limit the 1717 maximum damage of the attack to an acceptable extent. However, note 1718 that a high setting for MAX_FRAG_RETRIES benefits fragment delivery 1719 reliability, therefore the trade-off needs to be carefully 1720 considered. 1722 9. Acknowledgements 1724 Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier, 1725 Arunprabhu Kandasamy, Antony Markovski, Alexander Pelov, Pascal 1726 Thubert, Juan Carlos Zuniga and Diego Dujovne for useful design 1727 consideration and comments. 1729 10. References 1731 10.1. Normative References 1733 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1734 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1735 December 1998, . 1737 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1738 "Transmission of IPv6 Packets over IEEE 802.15.4 1739 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1740 . 1742 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1743 Header Compression (ROHC) Framework", RFC 5795, 1744 DOI 10.17487/RFC5795, March 2010, 1745 . 1747 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1748 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 1749 February 2014, . 1751 10.2. Informative References 1753 [I-D.ietf-lpwan-overview] 1754 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 1755 overview-07 (work in progress), October 2017. 1757 Appendix A. SCHC Compression Examples 1759 This section gives some scenarios of the compression mechanism for 1760 IPv6/UDP. The goal is to illustrate the SCHC behavior. 1762 The most common case using the mechanisms defined in this document 1763 will be a LPWAN Dev that embeds some applications running over CoAP. 1764 In this example, three flows are considered. The first flow is for 1765 the device management based on CoAP using Link Local IPv6 addresses 1766 and UDP ports 123 and 124 for Dev and App, respectively. The second 1767 flow will be a CoAP server for measurements done by the Device (using 1768 ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to 1769 beta::1/64. The last flow is for legacy applications using different 1770 ports numbers, the destination IPv6 address prefix is gamma::1/64. 1772 Figure 22 presents the protocol stack for this Device. IPv6 and UDP 1773 are represented with dotted lines since these protocols are 1774 compressed on the radio link. 1776 Management Data 1777 +----------+---------+---------+ 1778 | CoAP | CoAP | legacy | 1779 +----||----+---||----+---||----+ 1780 . UDP . UDP | UDP | 1781 ................................ 1782 . IPv6 . IPv6 . IPv6 . 1783 +------------------------------+ 1784 | SCHC Header compression | 1785 | and fragmentation | 1786 +------------------------------+ 1787 | LPWAN L2 technologies | 1788 +------------------------------+ 1789 DEV or NGW 1791 Figure 22: Simplified Protocol Stack for LP-WAN 1793 Note that in some LPWAN technologies, only the Devs have a device ID. 1794 Therefore, when such technologies are used, it is necessary to define 1795 statically an IID for the Link Local address for the SCHC C/D. 1797 Rule 0 1798 +----------------+--+--+--+---------+--------+------------++------+ 1799 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 1800 | | | | | | Opera. | Action ||[bits]| 1801 +----------------+--+--+--+---------+---------------------++------+ 1802 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1803 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1804 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1805 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1806 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1807 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 1808 |IPv6 DEVprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 1809 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1810 |IPv6 APPprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 1811 |IPv6 APPiid |64|1 |Bi|::1 | equal | not-sent || | 1812 +================+==+==+==+=========+========+============++======+ 1813 |UDP DEVport |16|1 |Bi|123 | equal | not-sent || | 1814 |UDP APPport |16|1 |Bi|124 | equal | not-sent || | 1815 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1816 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1817 +================+==+==+==+=========+========+============++======+ 1819 Rule 1 1820 +----------------+--+--+--+---------+--------+------------++------+ 1821 | Field |FL|FP|DI| Value | Match | Action || Sent | 1822 | | | | | | Opera. | Action ||[bits]| 1823 +----------------+--+--+--+---------+--------+------------++------+ 1824 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1825 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1826 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1827 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1828 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1829 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 1830 |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| [1] | 1831 | | | | |fe80::/64] mapping| || | 1832 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1833 |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| [2] | 1834 | | | | |alpha/64,| mapping| || | 1835 | | | | |fe80::64]| | || | 1836 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 1837 +================+==+==+==+=========+========+============++======+ 1838 |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | 1839 |UDP APPport |16|1 |Bi|5683 | equal | not-sent || | 1840 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1841 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1842 +================+==+==+==+=========+========+============++======+ 1844 Rule 2 1845 +----------------+--+--+--+---------+--------+------------++------+ 1846 | Field |FL|FP|DI| Value | Match | Action || Sent | 1847 | | | | | | Opera. | Action ||[bits]| 1848 +----------------+--+--+--+---------+--------+-------------++------+ 1849 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1850 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1851 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1852 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1853 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1854 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 1855 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] | 1856 |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | 1857 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1858 |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | 1859 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 1860 +================+==+==+==+=========+========+============++======+ 1861 |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | 1862 |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | 1863 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1864 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1865 +================+==+==+==+=========+========+============++======+ 1867 Figure 23: Context rules 1869 All the fields described in the three rules depicted on Figure 23 are 1870 present in the IPv6 and UDP headers. The DEViid-DID value is found 1871 in the L2 header. 1873 The second and third rules use global addresses. The way the Dev 1874 learns the prefix is not in the scope of the document. 1876 The third rule compresses port numbers to 4 bits. 1878 Appendix B. Fragmentation Examples 1880 This section provides examples of different fragment delivery 1881 reliability options possible on the basis of this specification. 1883 Figure 24 illustrates the transmission of an IPv6 packet that needs 1884 11 fragments in the No ACK option, FCN is always 1 bit. 1886 Sender Receiver 1887 |-------FCN=0-------->| 1888 |-------FCN=0-------->| 1889 |-------FCN=0-------->| 1890 |-------FCN=0-------->| 1891 |-------FCN=0-------->| 1892 |-------FCN=0-------->| 1893 |-------FCN=0-------->| 1894 |-------FCN=0-------->| 1895 |-------FCN=0-------->| 1896 |-------FCN=0-------->| 1897 |-------FCN=1-------->|MIC checked => 1899 Figure 24: Transmission of an IPv6 packet carried by 11 fragments in 1900 the No ACK option 1902 Figure 25 illustrates the transmission of an IPv6 packet that needs 1903 11 fragments in ACK-on-error, for N=3, without losses. 1905 Sender Receiver 1906 |-----W=0, FCN=6----->| 1907 |-----W=0, FCN=5----->| 1908 |-----W=0, FCN=4----->| 1909 |-----W=0, FCN=3----->| 1910 |-----W=0, FCN=2----->| 1911 |-----W=0, FCN=1----->| 1912 |-----W=0, FCN=0----->| 1913 (no ACK) 1914 |-----W=1, FCN=6----->| 1915 |-----W=1, FCN=5----->| 1916 |-----W=1, FCN=4----->| 1917 |-----W=1, FCN=7----->|MIC checked => 1918 |<---- ACK, W=1 ------| 1920 Figure 25: Transmission of an IPv6 packet carried by 11 fragments in 1921 ACK-on-error, for N=3 and MAX_WIND_FCN=6, without losses. 1923 Figure 26 illustrates the transmission of an IPv6 packet that needs 1924 11 fragments ACK-on-error, for N=3, with three losses. 1926 Sender Receiver 1927 |-----W=0, FCN=6----->| 1928 |-----W=0, FCN=5----->| 1929 |-----W=0, FCN=4--X-->| 1930 |-----W=0, FCN=3----->| 1931 |-----W=0, FCN=2--X-->| 1932 |-----W=0, FCN=1----->| 1933 |-----W=0, FCN=0----->| 1934 |<-----ACK, W=0-------|Bitmap:11010111 1935 |-----W=0, FCN=4----->| 1936 |-----W=0, FCN=2----->| 1937 (no ACK) 1938 |-----W=1, FCN=6----->| 1939 |-----W=1, FCN=5----->| 1940 |-----W=1, FCN=4--X-->| 1941 |-----W=1, FCN=7----->|MIC checked 1942 |<-----ACK, W=1-------|Bitmap:11000001 1943 |-----W=1, FCN=4----->|MIC checked => 1944 |<---- ACK, W=1 ------| 1946 Figure 26: Transmission of an IPv6 packet carried by 11 fragments in 1947 ACK-on-error, for N=3 and MAX_WIND_FCN=6, three losses. 1949 Figure 27 illustrates the transmission of an IPv6 packet that needs 1950 11 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, without 1951 losses. Note: in Window mode, an additional bit will be needed to 1952 number windows. 1954 Sender Receiver 1955 |-----W=0, FCN=6----->| 1956 |-----W=0, FCN=5----->| 1957 |-----W=0, FCN=4----->| 1958 |-----W=0, FCN=3----->| 1959 |-----W=0, FCN=2----->| 1960 |-----W=0, FCN=1----->| 1961 |-----W=0, FCN=0----->| 1962 |<-----ACK, W=0-------|no Bitmap 1963 |-----W=1, FCN=6----->| 1964 |-----W=1, FCN=5----->| 1965 |-----W=1, FCN=4----->| 1966 |-----W=1, FCN=7----->|MIC checked => 1967 |<-----ACK, W=1-------|no Bitmap 1968 (End) 1970 Figure 27: Transmission of an IPv6 packet carried by 11 fragments in 1971 ACK-Always, for N=3 and MAX_WIND_FCN=6, no losses. 1973 Figure 28 illustrates the transmission of an IPv6 packet that needs 1974 11 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 1975 losses. 1977 Sender Receiver 1978 |-----W=1, FCN=6----->| 1979 |-----W=1, FCN=5----->| 1980 |-----W=1, FCN=4--X-->| 1981 |-----W=1, FCN=3----->| 1982 |-----W=1, FCN=2--X-->| 1983 |-----W=1, FCN=1----->| 1984 |-----W=1, FCN=0----->| 1985 |<-----ACK, W=1-------|Bitmap:11010111 1986 |-----W=1, FCN=4----->| 1987 |-----W=1, FCN=2----->| 1988 |<-----ACK, W=1-------|no Bitmap 1989 |-----W=0, FCN=6----->| 1990 |-----W=0, FCN=5----->| 1991 |-----W=0, FCN=4--X-->| 1992 |-----W=0, FCN=7----->|MIC checked 1993 |<-----ACK, W=0-------|Bitmap:11000001 1994 |-----W=0, FCN=4----->|MIC checked => 1995 |<-----ACK, W=0-------|no Bitmap 1996 (End) 1998 Figure 28: Transmission of an IPv6 packet carried by 11 fragments in 1999 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses. 2001 Figure 29 illustrates the transmission of an IPv6 packet that needs 6 2002 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 2003 losses, and only one retry is needed for each lost fragment. Note 2004 that, since a single window is needed for transmission of the IPv6 2005 packet in this case, the example illustrates behavior when losses 2006 happen in the last window. 2008 Sender Receiver 2009 |-----W=0, CFN=6----->| 2010 |-----W=0, CFN=5----->| 2011 |-----W=0, CFN=4--X-->| 2012 |-----W=0, CFN=3--X-->| 2013 |-----W=0, CFN=2--X-->| 2014 |-----W=0, CFN=7----->|MIC checked 2015 |<-----ACK, W=0-------|Bitmap:11000001 2016 |-----W=0, CFN=4----->|MIC checked: failed 2017 |-----W=0, CFN=3----->|MIC checked: failed 2018 |-----W=0, CFN=2----->|MIC checked: success 2019 |<-----ACK, W=0-------|no Bitmap 2020 (End) 2022 Figure 29: Transmission of an IPv6 packet carried by 11 fragments in 2023 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and only 2024 one retry is needed for each lost fragment. 2026 Figure 30 illustrates the transmission of an IPv6 packet that needs 6 2027 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 2028 losses, and the second ACK is lost. Note that, since a single window 2029 is needed for transmission of the IPv6 packet in this case, the 2030 example illustrates behavior when losses happen in the last window. 2032 Sender Receiver 2033 |-----W=0, CFN=6----->| 2034 |-----W=0, CFN=5----->| 2035 |-----W=0, CFN=4--X-->| 2036 |-----W=0, CFN=3--X-->| 2037 |-----W=0, CFN=2--X-->| 2038 |-----W=0, CFN=7----->|MIC checked 2039 |<-----ACK, W=0-------|Bitmap:11000001 2040 |-----W=0, CFN=4----->|MIC checked: wrong 2041 |-----W=0, CFN=3----->|MIC checked: wrong 2042 |-----W=0, CFN=2----->|MIC checked: right 2043 | X---ACK, W=0-------|no Bitmap 2044 timeout | | 2045 |-----W=0, CFN=7----->| 2046 |<-----ACK, W=0-------|no Bitmap 2048 (End) 2050 Figure 30: Transmission of an IPv6 packet carried by 11 fragments in 2051 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and the 2052 second ACK is lost. 2054 Figure 31 illustrates the transmission of an IPv6 packet that needs 6 2055 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 2056 losses, and one retransmitted fragment is lost. Note that, since a 2057 single window is needed for transmission of the IPv6 packet in this 2058 case, the example illustrates behavior when losses happen in the last 2059 window. 2061 Sender Receiver 2062 |-----W=0, CFN=6----->| 2063 |-----W=0, CFN=5----->| 2064 |-----W=0, CFN=4--X-->| 2065 |-----W=0, CFN=3--X-->| 2066 |-----W=0, CFN=2--X-->| 2067 |-----W=0, CFN=7----->|MIC checked 2068 |<-----ACK, W=0-------|Bitmap:11000001 2069 |-----W=0, CFN=4----->|MIC checked: wrong 2070 |-----W=0, CFN=3----->|MIC checked: wrong 2071 |-----W=0, CFN=2--X-->| 2072 timeout| | 2073 |-----W=0, CFN=7----->|All-0 empty 2074 |<-----ACK, W=0-------|Bitmap:11110001 2075 |-----W=0, CFN=2----->|MIC checked: right 2076 |<-----ACK, W=0-------|no Bitmap 2077 (End) 2079 Figure 31: Transmission of an IPv6 packet carried by 11 fragments in 2080 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and one 2081 retransmitted fragment is lost. 2083 Appendix C illustrates the transmission of an IPv6 packet that needs 2084 28 fragments in ACK-Always, for N=5 and MAX_WIND_FCN=23, with two 2085 losses. Note that MAX_WIND_FCN=23 may be useful when the maximum 2086 possible bitmap size, considering the maximum lower layer technology 2087 payload size and the value of R, is 3 bytes. Note also that the FCN 2088 of the last fragment of the packet is the one with FCN=31 (i.e. 2089 FCN=2^N-1 for N=5, or equivalently, all FCN bits set to 1). 2091 Sender Receiver 2092 |-----W=0, CFN=23----->| 2093 |-----W=0, CFN=22----->| 2094 |-----W=0, CFN=21--X-->| 2095 |-----W=0, CFN=20----->| 2096 |-----W=0, CFN=19----->| 2097 |-----W=0, CFN=18----->| 2098 |-----W=0, CFN=17----->| 2099 |-----W=0, CFN=16----->| 2100 |-----W=0, CFN=15----->| 2101 |-----W=0, CFN=14----->| 2102 |-----W=0, CFN=13----->| 2103 |-----W=0, CFN=12----->| 2104 |-----W=0, CFN=11----->| 2105 |-----W=0, CFN=10--X-->| 2106 |-----W=0, CFN=9 ----->| 2107 |-----W=0, CFN=8 ----->| 2108 |-----W=0, CFN=7 ----->| 2109 |-----W=0, CFN=6 ----->| 2110 |-----W=0, CFN=5 ----->| 2111 |-----W=0, CFN=4 ----->| 2112 |-----W=0, CFN=3 ----->| 2113 |-----W=0, CFN=2 ----->| 2114 |-----W=0, CFN=1 ----->| 2115 |-----W=0, CFN=0 ----->| 2116 | |lcl-Bitmap:110111111111101111111111 2117 |<------ACK, W=0-------| Bitmap:1101111111111011 2118 |-----W=0, CFN=21----->| 2119 |-----W=0, CFN=10----->| 2120 |<------ACK, W=0-------|no Bitmap 2121 |-----W=1, CFN=23----->| 2122 |-----W=1, CFN=22----->| 2123 |-----W=1, CFN=21----->| 2124 |-----W=1, CFN=31----->|MIC checked => 2125 |<------ACK, W=1-------|no Bitmap 2126 (End) 2128 Appendix C. Fragmentation State Machines 2130 The fragmentation state machines of the sender and the receiver in 2131 the different reliability options are next in the following figures: 2133 +-----------+ 2134 +------------+ Init | 2135 | FCN=0 +-----------+ 2136 | No Window 2137 | No Bitmap 2138 | +-------+ 2139 | +--------+--+ | More Fragments 2140 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 2141 +--------> | Send | send Fragment (FCN=0) 2142 +---+-------+ 2143 | last fragment 2144 | ~~~~~~~~~~~~ 2145 | FCN = 1 2146 v send fragment+MIC 2147 +------------+ 2148 | END | 2149 +------------+ 2151 Figure 32: Sender State Machine for the No ACK Mode 2153 +------+ Not All-1 2154 +----------+-+ | ~~~~~~~~~~~~~~~~~~~ 2155 | + <--+ set Inactivity Timer 2156 | RCV Frag +-------+ 2157 +-+---+------+ |All-1 & 2158 All-1 & | | |MIC correct 2159 MIC wrong | |Inactivity | 2160 | |Timer Exp. | 2161 v | | 2162 +----------++ | v 2163 | Error |<-+ +--------+--+ 2164 +-----------+ | END | 2165 +-----------+ 2167 Figure 33: Receiver State Machine for the No ACK Mode 2168 +-------+ 2169 | INIT | FCN!=0 & more frags 2170 | | ~~~~~~~~~~~~~~~~~~~~~~ 2171 +------++ +--+ send Window + frag(FCN) 2172 W=0 | | | FCN- 2173 Clear local bitmap | | v set local bitmap 2174 FCN=max value | ++--+--------+ 2175 +> | | 2176 +---------------------> | SEND | 2177 | +--+-----+---+ 2178 | FCN==0 & more frags | | last frag 2179 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 2180 | set local-bitmap | | set local-bitmap 2181 | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC 2182 | set Retrans_Timer | | set Retrans_Timer 2183 | | | 2184 |Recv_wnd == wnd & | | 2185 |Lcl_bitmap==recv_bitmap& | | +------------------------+ 2186 |more frag | | |local-bitmap!=rcv-bitmap| 2187 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 2188 |Stop Retrans_Timer | | | Attemp++ v 2189 |clear local_bitmap v v | +------++ 2190 |window=next_window +----+-----+--+--+ |Resend | 2191 +---------------------+ | |Missing| 2192 +----+ Wait | |Frag | 2193 not expected wnd | | bitmap | +------++ 2194 ~~~~~~~~~~~~~~~~ +--->+ +-+Retrans_Timer Exp | 2195 discard frag +--+-+---+-+---+-+ |~~~~~~~~~~~~~~~~~ | 2196 | | | ^ ^ |reSend(empty)All-* | 2197 | | | | | |Set Retrans_Timer | 2198 MIC_bit==1 & | | | | +---+Attemp++ | 2199 Recv_window==window & | | | +---------------------------+ 2200 Lcl_bitmap==recv_bitmap &| | | all missing frag sent 2201 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 2202 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 2203 Stop Retrans_Timer| | | 2204 +-------------+ | | | 2205 | END +<--------+ | | Attemp > MAX_ACK_REQUESTS 2206 +-------------+ | | ~~~~~~~~~~~~~~~~~~ 2207 All-1 Window | v Send Abort 2208 ~~~~~~~~~~~~ | +-+-----------+ 2209 MIC_bit ==0 & +>| ERROR | 2210 Lcl_bitmap==recv_bitmap +-------------+ 2212 Figure 34: Sender State Machine for the ACK Always Mode 2214 Not All- & w=expected +---+ +---+w = Not expected 2215 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2216 Set local_bitmap(FCN) | v v |discard 2217 ++---+---+---+-+ 2218 +---------------------+ Rcv +--->* ABORT 2219 | +------------------+ Window | 2220 | | +-----+--+-----+ 2221 | | All-0 & w=expect | ^ w =next & not-All 2222 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 2223 | | set lcl_bitmap(FCN)| |expected = next window 2224 | | send local_bitmap | |Clear local_bitmap 2225 | | | | 2226 | | w=expct & not-All | | 2227 | | ~~~~~~~~~~~~~~~~~~ | | 2228 | | set lcl_bitmap(FCN)+-+ | | +--+ w=next & All-0 2229 | | if lcl_bitmap full | | | | | | ~~~~~~~~~~~~~~~ 2230 | | send lcl_bitmap v | v | | | expct = nxt wnd 2231 | | +-+-+-+--+-++ | Clear lcl_bitmap 2232 | | w=expected & +->+ Wait +<+ set lcl_bitmap(FCN) 2233 | | All-1 | | Next | send lcl_bitmap 2234 | | ~~~~~~~~~~~~ +--+ Window +--->* ABORT 2235 | | discard +--------+-++ 2236 | | All-1 & w=next| | All-1 & w=nxt 2237 | | & MIC wrong| | & MIC right 2238 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 2239 | | set local_bitmap(FCN)| |set lcl_bitmap(FCN) 2240 | | send local_bitmap| |send local_bitmap 2241 | | | +----------------------+ 2242 | |All-1 & w=expct | | 2243 | |& MIC wrong v +---+ w=expctd & | 2244 | |~~~~~~~~~~~~~~~~~~~~ +----+---+-+ | MIC wrong | 2245 | |set local_bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ | 2246 | |send local_bitmap | Wait End | set lcl_btmp(FCN)| 2247 | +--------------------->+ +--->* ABORT | 2248 | +---+----+-+ | 2249 | w=expected & MIC right| | 2250 | ~~~~~~~~~~~~~~~~~~~~~~| +-+ Not All-1 | 2251 | set local_bitmap(FCN)| | | ~~~~~~~~~ | 2252 | send local_bitmap| | | discard | 2253 | | | | | 2254 |All-1 & w=expctd & MIC right | | | +-+ All-1 | 2255 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v | v ~~~~~~~~~ | 2256 |set local_bitmap(FCN) +-+-+-+-+-++Send lcl_btmp | 2257 |send local_bitmap | | | 2258 +-------------------------->+ END +<---------------+ 2259 ++--+------+ 2260 --->* ABORT 2261 ~~~~~~~ 2262 Inactivity_Timer = expires 2263 When DWN_Link 2264 IF Inactivity_Timer expires 2265 Send DWL Request 2266 Attemp++ 2268 Figure 35: Receiver State Machine for the ACK Always Mode 2269 +-------+ 2270 | | 2271 | INIT | 2272 | | FCN!=0 & more frags 2273 +------++ +--+ ~~~~~~~~~~~~~~~~~~~~~~ 2274 W=0 | | | send Window + frag(FCN) 2275 ~~~~~~~~~~~~~~~~~~ | | | FCN- 2276 Clear local bitmap | | v set local bitmap 2277 FCN=max value | ++-------------+ 2278 +> | | 2279 | SEND | 2280 +-------------------------> | | 2281 | ++-----+-------+ 2282 | FCN==0 & more frags| |last frag 2283 | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~~~~~~~~ 2284 | set local-bitmap| |set local-bitmap 2285 | send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC 2286 | set Retrans_Timer| |set Retrans_Timer 2287 | | | 2288 |Retrans_Timer expires & | | local-bitmap!=rcv-bitmap 2289 |more fragments | | +-----------------+ 2290 |~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~~~~~ | 2291 |stop Retrans_Timer | | | Attemp++ | 2292 |clear local.bitmap v v | v 2293 |window = next window +-----+-----+--+--+ +----+----+ 2294 +----------------------+ + | Resend | 2295 +--------------------->+ Wait bitmap | | Missing | 2296 | +-- + | | Frag | 2297 | not expected wnd | ++-+---+---+---+--+ +------+--+ 2298 | ~~~~~~~~~~~~~~~~ | ^ | | | ^ | 2299 | discard frag +----+ | | | +-------------------+ 2300 | | | | all missing frag sent 2301 |Retrans_Timer expires & | | | ~~~~~~~~~~~~~~~~~~~~~ 2302 | No more Frag | | | Set Retrans_Timer 2303 | ~~~~~~~~~~~~~~~~~~~~~~~ | | | 2304 | Stop Retrans_Timer | | | 2305 | Send ALL-1-empty | | | 2306 +-------------------------+ | | 2307 | | 2308 Local_bitmap==Recv_bitmap| | 2309 ~~~~~~~~~~~~~~~~~~~~~~~~~| |Attemp > MAX_ACK_REQUESTS 2310 +---------+Stop Retrans_Timer | |~~~~~~~~~~~~~~~~~~~~~~~ 2311 | END +<------------------+ v Send Abort 2312 +---------+ +-+---------+ 2313 | ERROR | 2314 +-----------+ 2316 Figure 36: Sender State Machine for the ACK on error Mode 2318 Not All- & w=expected +---+ +---+w = Not expected 2319 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2320 Set local_bitmap(FCN) | v v |discard 2321 ++---+---+---+-+ 2322 +-----------------------+ +--+ All-0 & full 2323 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~~~ 2324 | +--------------------+ +<-+ w =next 2325 | | +---+---+------+ clear lcl_bitmap 2326 | | | ^ 2327 | | All-0 & w=expect| |w=expct & not-All & full 2328 | | & no_full bitmap| |~~~~~~~~~~~~~~~~~~~~~~~~ 2329 | | ~~~~~~~~~~~~~~~~~| |clear lcl_bitmap; w =nxt 2330 | | send local_bitmap| | 2331 | | | | +--------+ 2332 | | | | +---------->+ | 2333 | | | | |w=next | Error/ | 2334 | | | | |~~~~~~~~ | Abort | 2335 | | | | |Send abort ++-------+ 2336 | | v | | ^ w=expct 2337 | | +-+---+--+------+ | & all-1 2338 | | ABORT *<---+ Wait +------+ ~~~~~~~ 2339 | | | Next Window | Send abort 2340 | | +-------+---+---+ 2341 | | All-1 & w=next & MIC wrong | | 2342 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | +----------------+ 2343 | | set local_bitmap(FCN) | All-1 & w=next| 2344 | | send local_bitmap | & MIC right| 2345 | | | ~~~~~~~~~~~~~~~~~~| 2346 | | | set lcl_bitmap(FCN)| 2347 | |All-1 & w=expect & MIC wrong | | 2348 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | 2349 | |set local_bitmap(FCN) v +--->* ABORT | 2350 | |send local_bitmap +-------+---+--+ | 2351 | +--------------------->+ Wait End +-+ | 2352 | +-----+------+-+ | w=expct & | 2353 | w=expected & MIC right | ^ | MIC wrong | 2354 | ~~~~~~~~~~~~~~~~~~~~~~ | +---+ ~~~~~~~~~ | 2355 | set local_bitmap(FCN) | set lcl_bitmap(FCN)| 2356 | | | 2357 |All-1 & w=expected & MIC right | | 2358 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | 2359 |set local_bitmap(FCN) +-+----------+ | 2360 +---------------------------->+ END +<----------+ 2361 +------------+ 2362 --->* Only Uplink 2363 ABORT 2364 ~~~~~~~~ 2365 Inactivity_Timer = expires 2367 Figure 37: Receiver State Machine for the ACK on error Mode 2369 Appendix D. Allocation of Rule IDs for fragmentation 2371 A set of Rule IDs are allocated to support different aspects of 2372 fragmentation functionality as per this document. The allocation of 2373 IDs is to be defined in other documents. The set MAY include: 2375 o one ID or a subset of IDs to identify a fragment as well as its 2376 reliability option and its window size, if multiple of these are 2377 supported. 2379 o one ID to identify the ACK message. 2381 o one ID to identify the Abort message as per Section 9.8. 2383 Appendix E. Note 2385 Carles Gomez has been funded in part by the Spanish Government 2386 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2387 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2388 Government through project TEC2016-79988-P. Part of his contribution 2389 to this work has been carried out during his stay as a visiting 2390 scholar at the Computer Laboratory of the University of Cambridge. 2392 Authors' Addresses 2394 Ana Minaburo 2395 Acklio 2396 2bis rue de la Chataigneraie 2397 35510 Cesson-Sevigne Cedex 2398 France 2400 Email: ana@ackl.io 2402 Laurent Toutain 2403 IMT-Atlantique 2404 2 rue de la Chataigneraie 2405 CS 17607 2406 35576 Cesson-Sevigne Cedex 2407 France 2409 Email: Laurent.Toutain@imt-atlantique.fr 2410 Carles Gomez 2411 Universitat Politecnica de Catalunya 2412 C/Esteve Terradas, 7 2413 08860 Castelldefels 2414 Spain 2416 Email: carlesgo@entel.upc.edu