idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-09.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 673: '... datagram SHALL be broken into fragm...' RFC 2119 keyword, line 726: '...ng technology documents. The FCN MUST...' RFC 2119 keyword, line 728: '... first fragment), and MUST wrap from 0...' RFC 2119 keyword, line 744: '...to 0 bits. DTag MUST be set sequentia...' RFC 2119 keyword, line 745: '... 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 1339 has weird spacing: '... 1 byte next ...' -- The document date (December 22, 2017) is 2316 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1860 -- Looks like a reference, but probably isn't: '2' on line 1863 -- Looks like a reference, but probably isn't: '8' on line 1885 -- Looks like a reference, but probably isn't: '4' on line 1892 ** 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 (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Informational L. Toutain 5 Expires: June 25, 2018 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 December 22, 2017 10 LPWAN Static Context Header Compression (SCHC) and fragmentation for 11 IPv6 and UDP 12 draft-ietf-lpwan-ipv6-static-context-hc-09 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 25, 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 Frame Formats . . . . . . . . . . . . . . . 20 99 5.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 20 100 5.4.2. ACK format . . . . . . . . . . . . . . . . . . . . . 21 101 5.4.3. All-1 and All-0 formats . . . . . . . . . . . . . . . 21 102 5.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 23 103 5.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 23 104 5.5.1. No ACK . . . . . . . . . . . . . . . . . . . . . . . 24 105 5.5.2. The Window modes . . . . . . . . . . . . . . . . . . 25 106 5.5.3. Bitmap Optimization . . . . . . . . . . . . . . . . . 29 107 5.6. Supporting multiple window sizes . . . . . . . . . . . . 31 108 5.7. Downlink fragment transmission . . . . . . . . . . . . . 31 109 6. Padding management . . . . . . . . . . . . . . . . . . . . . 32 110 7. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 33 111 7.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 33 112 7.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 33 113 7.3. Flow label field . . . . . . . . . . . . . . . . . . . . 33 114 7.4. Payload Length field . . . . . . . . . . . . . . . . . . 34 115 7.5. Next Header field . . . . . . . . . . . . . . . . . . . . 34 116 7.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 34 117 7.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 35 118 7.7.1. IPv6 source and destination prefixes . . . . . . . . 35 119 7.7.2. IPv6 source and destination IID . . . . . . . . . . . 35 120 7.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 36 121 7.9. UDP source and destination port . . . . . . . . . . . . . 36 122 7.10. UDP length field . . . . . . . . . . . . . . . . . . . . 36 123 7.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 37 124 8. Security considerations . . . . . . . . . . . . . . . . . . . 37 125 8.1. Security considerations for header compression . . . . . 37 126 8.2. Security considerations for fragmentation . . . . . . . . 37 127 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 128 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 129 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 130 10.2. Informative References . . . . . . . . . . . . . . . . . 39 131 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 39 132 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 42 133 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 48 134 Appendix D. Allocation of Rule IDs for fragmentation . . . . . . 55 135 Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 55 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 138 1. Introduction 140 Header compression is mandatory to efficiently bring Internet 141 connectivity to the node within a LPWAN network. Some LPWAN networks 142 properties can be exploited to get an efficient header compression: 144 o Topology is star-oriented; therefore, all the packets follow the 145 same path. For the needs of this draft, the architecture can be 146 summarized to Devices (Dev) exchanging information with LPWAN 147 Application Server (App) through a Network Gateway (NGW). 149 o Traffic flows are mostly known in advance since devices embed 150 built-in applications. Contrary to computers or smartphones, new 151 applications cannot be easily installed. 153 The Static Context Header Compression (SCHC) is defined for this 154 environment. SCHC uses a context where header information is kept in 155 the header format order. This context is static (the values of the 156 header fields do not change over time) avoiding complex 157 resynchronization mechanisms, incompatible with LPWAN 158 characteristics. In most of the cases, IPv6/UDP headers are reduced 159 to a small context identifier. 161 The SCHC header compression mechanism is independent of the specific 162 LPWAN technology over which it will be used. 164 LPWAN technologies are also characterized, among others, by a very 165 reduced data unit and/or payload size [I-D.ietf-lpwan-overview]. 166 However, some of these technologies do not support layer two 167 fragmentation, therefore the only option for them to support the IPv6 168 MTU requirement of 1280 bytes [RFC2460] is the use of a fragmentation 169 protocol at the adaptation layer below IPv6. This draft defines also 170 a fragmentation functionality to support the IPv6 MTU requirement 171 over LPWAN technologies. Such functionality has been designed under 172 the assumption that data unit reordering will not happen between the 173 entity performing fragmentation and the entity performing reassembly. 175 2. LPWAN Architecture 177 LPWAN technologies have similar architectures but different 178 terminology. We can identify different types of entities in a 179 typical LPWAN network, see Figure 1: 181 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 182 actuators, etc.). There can be a high density of devices per radio 183 gateway. 185 o The Radio Gateway (RGW), which is the end point of the constrained 186 link. 188 o The Network Gateway (NGW) is the interconnection node between the 189 Radio Gateway and the Internet. 191 o LPWAN-AAA Server, which controls the user authentication and the 192 applications. 194 o Application Server (App) 196 +------+ 197 () () () | |LPWAN-| 198 () () () () / \ +---------+ | AAA | 199 () () () () () () / \=====| ^ |===|Server| +-----------+ 200 () () () | | <--|--> | +------+ |APPLICATION| 201 () () () () / \==========| v |=============| (App) | 202 () () () / \ +---------+ +-----------+ 203 Dev Radio Gateways NGW 205 Figure 1: LPWAN Architecture 207 3. Terminology 209 This section defines the terminology and acronyms used in this 210 document. 212 o All-0. Fragment format for the last frame of a window. 214 o All-1. Fragment format for the last frame of a packet. 216 o All-0 empty. Fragment format without payload for requesting the 217 Bitmap when the Retransmission Timer expires in a window that is 218 not the last one for a fragmented packet transmission. 220 o All-1 empty. Fragment format without payload for requesting the 221 Bitmap when the Retransmission Timer expires in the last window. 223 o App: LPWAN Application. An application sending/receiving IPv6 224 packets to/from the Device. 226 o APP-IID: Application Interface Identifier. Second part of the 227 IPv6 address to identify the application interface 229 o Bi: Bidirectional, a rule entry that applies in both directions. 231 o C: Checked bit. Used in an acknowledgment (ACK) header to 232 determine when the MIC is correct (1) or not (0). 234 o CDA: Compression/Decompression Action. An action that is 235 performed for both functionalities to compress a header field or 236 to recover its original value in the decompression phase. 238 o Context: A set of rules used to compress/decompress headers 240 o Dev: Device. A Node connected to the LPWAN. A Dev may implement 241 SCHC. 243 o Dev-IID: Device Interface Identifier. Second part of the IPv6 244 address to identify the device interface 246 o DI: Direction Indicator is a differentiator for matching in order 247 to be able to have different values for both sides. 249 o DTag: Datagram Tag is a fragmentation header field that is set to 250 the same value for all fragments carrying the same IPv6 datagram. 252 o Dw: Down Link direction for compression, from SCHC C/D to Dev 254 o FCN: Fragment Compressed Number is a fragmentation header field 255 that carries an efficient representation of a larger-sized 256 fragment number. 258 o FID: Field Identifier is an index to describe the header fields in 259 the Rule 261 o FL: Field Length is a value to identify if the field is fixed or 262 variable length. 264 o FP: Field Position is a value that is used to identify each 265 instance a field appears in the header. 267 o IID: Interface Identifier. See the IPv6 addressing architecture 268 [RFC7136] 270 o Inactivity Timer. A timer to end the fragmentation state machine 271 when there is an error and there is no possibility to continue an 272 on-going fragmented packet transmission. 274 o MIC: Message Integrity Check. A fragmentation header field 275 computed over an IPv6 packet before fragmentation, used for error 276 detection after IPv6 packet reassembly. 278 o MO: Matching Operator. An operator used to match a value 279 contained in a header field with a value contained in a Rule. 281 o Retransmission Timer. A timer used by the fragment sender during 282 an on-going fragmented packet transmission to detect possible link 283 errors when waiting for a possible incoming ACK. 285 o Rule: A set of header field values. 287 o Rule entry: A row in the rule that describes a header field. 289 o Rule ID: An identifier for a rule, SCHC C/D, and Dev share the 290 same Rule ID for a specific flow. A set of Rule IDs are used to 291 support fragmentation functionality. 293 o SCHC C/D: Static Context Header Compression Compressor/ 294 Decompressor. A process in the network to achieve compression/ 295 decompressing headers. SCHC C/D uses SCHC rules to perform 296 compression and decompression. 298 o TV: Target value. A value contained in the Rule that will be 299 matched with the value of a header field. 301 o Up: Up Link direction for compression, from Dev to SCHC C/D. 303 o W: Window bit. A fragment header field used in Window mode (see 304 section 5), which carries the same value for all fragments of a 305 window. 307 o Window: A subset of the fragments needed to carry a packet (see 308 section 5) 310 4. Static Context Header Compression 312 Static Context Header Compression (SCHC) avoids context 313 synchronization, which is the most bandwidth-consuming operation in 314 other header compression mechanisms such as RoHC [RFC5795]. Based on 315 the fact that the nature of data flows is highly predictable in LPWAN 316 networks, some static contexts may be stored on the Device (Dev). 317 The contexts must be stored in both ends, and it can either be 318 learned by a provisioning protocol or by out of band means or it can 319 be pre-provisioned, etc. The way the context is learned on both 320 sides are out of the scope of this document. 322 Dev App 323 +--------------+ +--------------+ 324 |APP1 APP2 APP3| |APP1 APP2 APP3| 325 | | | | 326 | UDP | | UDP | 327 | IPv6 | | IPv6 | 328 | | | | 329 | SCHC C/D | | | 330 | (context) | | | 331 +-------+------+ +-------+------+ 332 | +--+ +----+ +---------+ . 333 +~~ |RG| === |NGW | === |SCHC C/D |... Internet .. 334 +--+ +----+ |(context)| 335 +---------+ 337 Figure 2: Architecture 339 Figure 2 represents the architecture for compression/decompression, 340 it is based on [I-D.ietf-lpwan-overview] terminology. The Device is 341 sending applications flows using IPv6 or IPv6/UDP protocols. These 342 flows are compressed by a Static Context Header Compression 343 Compressor/Decompressor (SCHC C/D) to reduce headers size. The 344 resulting information is sent to a layer two (L2) frame to a LPWAN 345 Radio Network (RG) which forwards the frame to a Network Gateway 346 (NGW). The NGW sends the data to an SCHC C/D for decompression which 347 shares the same rules with the Dev. The SCHC C/D can be located on 348 the Network Gateway (NGW) or in another place as long as a tunnel is 349 established between the NGW and the SCHC C/D. The SCHC C/D in both 350 sides must share the same set of Rules. After decompression, the 351 packet can be sent on the Internet to one or several LPWAN 352 Application Servers (App). 354 The SCHC C/D process is bidirectional, so the same principles can be 355 applied in the other direction. 357 4.1. SCHC Rules 359 The main idea of the SCHC compression scheme is to send the Rule id 360 to the other end instead of sending known field values. This Rule id 361 identifies a rule that matches as much as possible the original 362 packet values. When a value is known by both ends, it is not 363 necessary to send it through the LPWAN network. 365 The context contains a list of rules (cf. Figure 3). Each Rule 366 contains itself a list of fields descriptions composed of a field 367 identifier (FID), a field length (FL), a field position (FP), a 368 direction indicator (DI), a target value (TV), a matching operator 369 (MO) and a Compression/Decompression Action (CDA). 371 /-----------------------------------------------------------------\ 372 | Rule N | 373 /-----------------------------------------------------------------\| 374 | Rule i || 375 /-----------------------------------------------------------------\|| 376 | (FID) Rule 1 ||| 377 |+-------+--+--+--+------------+-----------------+---------------+||| 378 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 379 |+-------+--+--+--+------------+-----------------+---------------+||| 380 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 381 |+-------+--+--+--+------------+-----------------+---------------+||| 382 ||... |..|..|..| ... | ... | ... |||| 383 |+-------+--+--+--+------------+-----------------+---------------+||/ 384 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 385 |+-------+--+--+--+------------+-----------------+---------------+|/ 386 | | 387 \-----------------------------------------------------------------/ 389 Figure 3: Compression/Decompression Context 391 The Rule does not describe the original packet format which must be 392 known from the compressor/decompressor. The rule just describes the 393 compression/decompression behavior for the header fields. In the 394 rule, the description of the header field should be performed in the 395 format packet order. 397 The Rule also describes the compressed header fields which are 398 transmitted regarding their position in the rule which is used for 399 data serialization on the compressor side and data deserialization on 400 the decompressor side. 402 The Context describes the header fields and its values with the 403 following entries: 405 o A Field ID (FID) is a unique value to define the header field. 407 o A Field Length (FL) is the length of the field that can be of 408 fixed length as in IPv6 or UDP headers or variable length as in 409 CoAP options. Fixed length fields shall be represented by its 410 actual value in bits. Variable length fields shall be represented 411 by a function or a variable. 413 o A Field Position (FP) indicating if several instances of the field 414 exist in the headers which one is targeted. The default position 415 is 1 417 o A direction indicator (DI) indicating the packet direction. Three 418 values are possible: 420 * UPLINK (Up) when the field or the value is only present in 421 packets sent by the Dev to the App, 423 * DOWNLINK (Dw) when the field or the value is only present in 424 packet sent from the App to the Dev and 426 * BIDIRECTIONAL (Bi) when the field or the value is present 427 either upstream or downstream. 429 o A Target Value (TV) is the value used to make the comparison with 430 the packet header field. The Target Value can be of any type 431 (integer, strings, etc.). For instance, it can be a single value 432 or a more complex structure (array, list, etc.), such as a JSON or 433 a CBOR structure. 435 o A Matching Operator (MO) is the operator used to make the 436 comparison between the Field Value and the Target Value. The 437 Matching Operator may require some parameters. MO is only used 438 during the compression phase. 440 o A Compression Decompression Action (CDA) is used to describe the 441 compression and the decompression process. The CDA may require 442 some parameters, CDA are used in both compression and 443 decompression phases. 445 4.2. Rule ID 447 Rule IDs are sent between both compression/decompression elements. 448 The size of the Rule ID is not specified in this document, it is 449 implementation-specific and can vary regarding the LPWAN technology, 450 the number of flows, among others. 452 Some values in the Rule ID space are reserved for other 453 functionalities than header compression as fragmentation. (See 454 Section 5). 456 Rule IDs are specific to a Dev. Two Devs may use the same Rule ID for 457 different header compression. To identify the correct Rule ID, the 458 SCHC C/D needs to combine the Rule ID with the Dev L2 identifier to 459 find the appropriate Rule. 461 4.3. Packet processing 463 The compression/decompression process follows several steps: 465 o compression Rule selection: The goal is to identify which Rule(s) 466 will be used to compress the packet's headers. When doing 467 compression in the NGW side the SCHC C/D needs to find the correct 468 Rule to be used by identifying its Dev-ID and the Rule-ID. In the 469 Dev, only the Rule-ID may be used. The next step is to choose the 470 fields by their direction, using the direction indicator (DI), so 471 the fields that do not correspond to the appropriated DI will be 472 excluded. Next, then the fields are identified according to their 473 field identifier (FID) and field position (FP). If the field 474 position does not correspond, then the Rule is not used and the 475 SCHC take next Rule. Once the DI and the FP correspond to the 476 header information, each field's value is then compared to the 477 corresponding target value (TV) stored in the Rule for that 478 specific field using the matching operator (MO). If all the 479 fields in the packet's header satisfy all the matching operators 480 (MOs) of a Rule (i.e. all results are True), the fields of the 481 header are then processed according to the Compression/ 482 Decompression Actions (CDAs) and a compressed header is obtained. 483 Otherwise, the next rule is tested. If no eligible rule is found, 484 then the header must be sent without compression, in which case 485 the fragmentation process must be required. 487 o sending: The Rule ID is sent to the other end followed by the 488 information resulting from the compression of header fields, 489 directly followed by the payload. The product of field 490 compression is sent in the order expressed in the Rule for the 491 matching fields. The way the Rule ID is sent depends on the 492 specific LPWAN layer two technology and will be specified in a 493 specific document and is out of the scope of this document. For 494 example, it can be either included in a Layer 2 header or sent in 495 the first byte of the L2 payload. (Cf. Figure 4). 497 o decompression: In both directions, the receiver identifies the 498 sender through its device-id (e.g. MAC address) and selects the 499 appropriate Rule through the Rule ID. This Rule gives the 500 compressed header format and associates these values to the header 501 fields. It applies the CDA action to reconstruct the original 502 header fields. The CDA application order can be different from 503 the order given by the Rule. For instance, Compute-* may be 504 applied at the end, after all the other CDAs. 506 If after using SCHC compression and adding the payload to the L2 507 frame the datagram is not multiple of 8 bits, padding may be used. 509 +--- ... --+-------------- ... --------------+-----------+--...--+ 510 | Rule ID |Compressed Hdr Fields information| payload |padding| 511 +--- ... --+-------------- ... --------------+-----------+--...--+ 513 Figure 4: LPWAN Compressed Format Packet 515 4.4. Matching operators 517 Matching Operators (MOs) are functions used by both SCHC C/D 518 endpoints involved in the header compression/decompression. They are 519 not typed and can be applied indifferently to integer, string or any 520 other data type. The result of the operation can either be True or 521 False. MOs are defined as follows: 523 o equal: A field value in a packet matches with a TV in a Rule if 524 they are equal. 526 o ignore: No check is done between a field value in a packet and a 527 TV in the Rule. The result of the matching is always true. 529 o MSB(length): A matching is obtained if the most significant bits 530 of the length field value bits of the header are equal to the TV 531 in the rule. The MSB Matching Operator needs a parameter, 532 indicating the number of bits, to proceed to the matching. 534 o match-mapping: The goal of mapping-sent is to reduce the size of a 535 field by allocating a shorter value. The Target Value contains a 536 list of values. Each value is identified by a short ID (or 537 index). This operator matches if a field value is equal to one of 538 those target values. 540 4.5. Compression Decompression Actions (CDA) 542 The Compression Decompression Action (CDA) describes the actions 543 taken during the compression of headers fields, and inversely, the 544 action taken by the decompressor to restore the original value. 546 /--------------------+-------------+----------------------------\ 547 | Action | Compression | Decompression | 548 | | | | 549 +--------------------+-------------+----------------------------+ 550 |not-sent |elided |use value stored in ctxt | 551 |value-sent |send |build from received value | 552 |mapping-sent |send index |value from index on a table | 553 |LSB(length) |send LSB |TV OR received value | 554 |compute-length |elided |compute length | 555 |compute-checksum |elided |compute UDP checksum | 556 |Deviid |elided |build IID from L2 Dev addr | 557 |Appiid |elided |build IID from L2 App addr | 558 \--------------------+-------------+----------------------------/ 560 Figure 5: Compression and Decompression Functions 562 Figure 5 summarizes the basics functions defined to compress and 563 decompress a field. The first column gives the action's name. The 564 second and third columns outline the compression/decompression 565 behavior. 567 Compression is done in the rule order and compressed values are sent 568 in that order in the compressed message. The receiver must be able 569 to find the size of each compressed field which can be given by the 570 rule or may be sent with the compressed header. 572 If the field is identified as being variable, then its size must be 573 sent first using the following coding: 575 o If the size is between 0 and 14 bytes it is sent using 4 bits. 577 o For values between 15 and 255, the first 4 bits sent are set to 1 578 and the size is sent using 8 bits. 580 o For higher value, the first 12 bits are set to 1 and the size is 581 sent on 2 bytes. 583 4.5.1. not-sent CDA 585 The not-sent function is generally used when the field value is 586 specified in the rule and therefore known by the both Compressor and 587 Decompressor. This action is generally used with the "equal" MO. If 588 MO is "ignore", there is a risk to have a decompressed field value 589 different from the compressed field. 591 The compressor does not send any value in the compressed header for 592 the field on which compression is applied. 594 The decompressor restores the field value with the target value 595 stored in the matched rule. 597 4.5.2. value-sent CDA 599 The value-sent action is generally used when the field value is not 600 known by both Compressor and Decompressor. The value is sent in the 601 compressed message header. Both Compressor and Decompressor must 602 know the size of the field, either implicitly (the size is known by 603 both sides) or explicitly in the compressed header field by 604 indicating the length. This function is generally used with the 605 "ignore" MO. 607 4.5.3. mapping-sent 609 The mapping-sent is used to send a smaller index associated with the 610 list of values in the Target Value. This function is used together 611 with the "match-mapping" MO. 613 The compressor looks on the TV to find the field value and send the 614 corresponding index. The decompressor uses this index to restore the 615 field value. 617 The number of bits sent is the minimal size for coding all the 618 possible indexes. 620 4.5.4. LSB CDA 622 LSB action is used to avoid sending the known part of the packet 623 field header to the other end. This action is used together with the 624 "MSB" MO. A length can be specified in the rule to indicate how many 625 bits have to be sent. If the length is not specified, the number of 626 bits sent is the field length minus the bits' length specified in the 627 MSB MO. 629 The compressor sends the "length" Least Significant Bits. The 630 decompressor combines the value received with the Target Value. 632 If this action is made on a variable length field, the remaining size 633 in byte has to be sent before. 635 4.5.5. DEViid, APPiid CDA 637 These functions are used to process respectively the Dev and the App 638 Interface Identifiers (Deviid and Appiid) of the IPv6 addresses. 639 Appiid CDA is less common since current LPWAN technologies frames 640 contain a single address. 642 The IID value may be computed from the Device ID present in the Layer 643 2 header. The computation is specific for each LPWAN technology and 644 may depend on the Device ID size. 646 In the downstream direction, these CDA may be used to determine the 647 L2 addresses used by the LPWAN. 649 4.5.6. Compute-* 651 These classes of functions are used by the decompressor to compute 652 the compressed field value based on received information. Compressed 653 fields are elided during compression and reconstructed during 654 decompression. 656 o compute-length: compute the length assigned to this field. For 657 instance, regarding the field ID, this CDA may be used to compute 658 IPv6 length or UDP length. 660 o compute-checksum: compute a checksum from the information already 661 received by the SCHC C/D. This field may be used to compute UDP 662 checksum. 664 5. Fragmentation 666 5.1. Overview 668 In LPWAN technologies, the L2 data unit size typically varies from 669 tens to hundreds of bytes. If after applying SCHC header compression 670 or when SCHC header compression is not possible the entire IPv6 671 datagram fits within a single L2 data unit, the fragmentation 672 mechanism is not used and the packet is sent. Otherwise, the 673 datagram SHALL be broken into fragments. 675 LPWAN technologies impose some strict limitations on traffic, (e.g.) 676 devices are sleeping most of the time and may receive data during a 677 short period of time after transmission to preserve battery. To 678 adapt the SCHC fragmentation to the capabilities of LPWAN 679 technologies, it is desirable to enable optional fragment 680 retransmission and to allow a gradation of fragment delivery 681 reliability. This document does not make any decision with regard to 682 which fragment delivery reliability option(s) will be used over a 683 specific LPWAN technology. 685 An important consideration is that LPWAN networks typically follow a 686 the star topology, and therefore data unit reordering is not expected 687 in such networks. This specification assumes that reordering will 688 not happen between the entity performing fragmentation and the entity 689 performing reassembly. This assumption allows to reduce complexity 690 and overhead of the fragmentation mechanism. 692 5.2. Functionalities 694 This subsection describes the different fields in the fragmentation 695 header frames (see the related formats in Section 5.4), as well as 696 the tools that are used to enable the fragmentation functionalities 697 defined in this document, and the different reliability options 698 supported. 700 o Rule ID. The Rule ID is present in the fragment header and in the 701 ACK header format. The Rule ID in a fragment header is used to 702 identify that a fragment is being carried, the fragmentation 703 delivery reliability option used and it may indicate the window 704 size in use (if any). The Rule ID in the fragmentation header 705 also allows to interleave non-fragmented IPv6 datagrams with 706 fragments that carry a larger IPv6 datagram. The Rule ID in an 707 ACK allows to identify that the message is an ACK. 709 o Fragment Compressed Number (FCN). The FCN is included in all 710 fragments. This field can be understood as a truncated, efficient 711 representation of a larger-sized fragment number, and does not 712 carry an absolute fragment number. There are two FCN reserved 713 values that are used for controlling the fragmentation process, as 714 described next. The FCN value with all the bits equal to 1 (All- 715 1) denotes the last fragment of a packet. And the FCN value with 716 all the bits equal to 0 (All-0) denotes the last fragment of a 717 window (when such window is not the last one of the packet) in any 718 window mode or the fragments in No ACK mode. The rest of the FCN 719 values are assigned in a sequential and decreasing order, which 720 has the purpose to avoid possible ambiguity for the receiver that 721 might arise under certain conditions. In the fragments, this 722 field is an unsigned integer, with a size of N bits. In the No 723 ACK mode it is set to 1 bit (N=1). For the other reliability 724 options, it is recommended to use a number of bits (N) equal to or 725 greater than 3. Nevertheless, the apropriate value will be 726 defined in the corresponding technology documents. The FCN MUST 727 be set sequentially decreasing from the highest FCN in the window 728 (which will be used for the first fragment), and MUST wrap from 0 729 back to the highest FCN in the window. 730 For windows that are not the last one from a fragmented packet, 731 the FCN for the last fragment in such windows is an All-0. This 732 indicates that the window is finished and communication proceeds 733 according to the reliability option in use. The FCN for the last 734 fragment in the last window is an All-1. It is also important to 735 note that, for No ACK mode or N=1, the last fragment of the packet 736 will carry a FCN equal to 1, while all previous fragments will 737 carry a FCN of 0. 739 o Datagram Tag (DTag). The DTag field, if present, is set to the 740 same value for all fragments carrying the same IPv6 datagram. 741 This field allows to interleave fragments that correspond to 742 different IPv6 datagrams. In the fragment formats the size of the 743 DTag field is T bits, which may be set to a value greater than or 744 equal to 0 bits. DTag MUST be set sequentially increasing from 0 745 to 2^T - 1, and MUST wrap back from 2^T - 1 to 0. In the ACK 746 format, DTag carries the same value as the DTag field in the 747 fragments for which this ACK is intended. 749 o W (window): W is a 1-bit field. This field carries the same value 750 for all fragments of a window, and it is complemented for the next 751 window. The initial value for this field is 0. In the ACK 752 format, this field also has a size of 1 bit. In all ACKs, the W 753 bit carries the same value as the W bit carried by the fragments 754 whose reception is being positively or negatively acknowledged by 755 the ACK. 757 o Message Integrity Check (MIC). This field, which has a size of M 758 bits, is computed by the sender over the complete packet (i.e. a 759 SCHC compressed or an uncompressed IPv6 packet) before 760 fragmentation. The MIC allows the receiver to check errors in the 761 reassembled packet, while it also enables compressing the UDP 762 checksum by use of SCHC compression. The CRC32 as 0xEDB88320 is 763 recommended as the default algorithm for computing the MIC. 764 Nevertheless, other algorithm MAY be mandated in the corresponding 765 technology documents (e.g. technology-specific profiles). 767 o C (MIC checked): C is a 1-bit field. This field is used in the 768 ACK format packets to report the outcome of the MIC check, i.e. 769 whether the reassembled packet was correctly received or not. 771 o Retransmission Timer. It is used by a fragment sender after the 772 transmission of a window to detect a transmission error of the ACK 773 corresponding to this window. Depending on the reliability 774 option, it will lead to a request for an ACK retransmission on 775 ACK-Always or it will trigger the next window on ACK-on-error. 776 The dureation of this timer is not defined in this document and 777 must be defined in the corresponding technology documents (e.g. 778 technology-specific profiles). 780 o Inactivity Timer. This timer is used by a fragment receiver to 781 detect when there is a problem in the transmission of fragments 782 and the receiver does not get any fragment during a period of time 783 or a number of packets in a period of time. When this happens, an 784 Abort message needs to be sent. Initially, and each time a 785 fragment is received the timer is reinitialized. The duration of 786 this timer is not defined in this document and must be defined in 787 the specific technology document (e.g. technology-specific 788 profiles). 790 o Attempts. It is a counter used to request a missing ACK, and in 791 consequence to determine when an Abort is needed, because there 792 are recurrent fragment transmission errors, whose maximum value is 793 MAX_ACK_REQUESTS. The default value of MAX_ACK_REQUESTS is not 794 stated in this document, and it is expected to be defined in other 795 documents (e.g. technology- specific profiles). The Attempts 796 counter is defined per window, it will be initialized each time a 797 new window is used. 799 o Bitmap. The Bitmap is a sequence of bits carried in an ACK for a 800 given window. Each bit in the Bitmap corresponds to a fragment of 801 the current window, and provides feedback on whether the fragment 802 has been received or not. The right-most position on the Bitmap 803 is used to report whether the All-0 or All-1 fragments have been 804 received or not. Feedback for a fragment with the highest FCN 805 value is provided by the left-most position in the Bitmap. In the 806 Bitmap, a bit set to 1 indicates that the corresponding FCN 807 fragment has been correctly sent and received. However, the 808 sending format of the Bitmap will be truncated until a byte 809 boundary where the last error is given. However, when all the 810 Bitmap is transmitted, it may be truncated, see more details in 811 Section 5.5.3 813 o Abort. In case of error or when the Inactivity timer expires or 814 MAX_ACK_REQUESTS is reached the sender or the receiver may use the 815 Abort frames. When the receiver needs to abort the on-going 816 fragmented packet transmission, it uses the ACK Abort format 817 packet with all the bits set to 1. When the sender needs to abort 818 the transmission it will use the All-1 Abort format, this fragment 819 is not acked. 821 o Padding (P). Padding will be used to align the last byte of a 822 fragment with a byte boundary. The number of bits used for 823 padding is not defined and depends on the size of the Rule ID, 824 DTag and FCN fields, and on the layer two payload size. 826 5.3. Delivery Reliability options 828 This specification defines the following three fragment delivery 829 reliability options: 831 o No ACK. No ACK is the simplest fragment delivery reliability 832 option. The receiver does not generate overhead in the form of 833 acknowledgments (ACKs). However, this option does not enhance 834 delivery reliability beyond that offered by the underlying LPWAN 835 technology. In the No ACK option, the receiver MUST NOT issue 836 ACKs. 838 o Window mode - ACK always (ACK-Always). 839 The ACK-always option provides flow control. In addition, this 840 option is able to handle long bursts of lost fragments, since 841 detection of such events can be done before the end of the IPv6 842 packet transmission, as long as the window size is short enough. 843 However, such benefit comes at the expense of ACK use. In ACK- 844 always, an ACK is transmitted by the fragment receiver after a 845 window of fragments has been sent. A window of fragments is a 846 subset of the full set of fragments needed to carry an IPv6 847 packet. In this mode, the ACK informs the sender about received 848 and/or missed fragments from the window of fragments. Upon 849 receipt of an ACK that informs about any lost fragments, the 850 sender retransmits the lost fragments. When an ACK is not 851 received by the fragment sender, the latter sends an ACK request 852 using the All-1 empty fragment. 853 The maximum number of ACK requests is MAX_ACK_REQUESTS. 855 o Window mode - ACK-on-error (ACK-on-error). The ACK-on-error 856 option is suitable for links offering relatively low L2 data unit 857 loss probability. This option reduces the number of ACKs 858 transmitted by the fragment receiver. This may be especially 859 beneficial in asymmetric scenarios, e.g. where fragmented data are 860 sent uplink and the underlying LPWAN technology downlink capacity 861 or message rate is lower than the uplink one. 862 In ACK-on-error, an ACK is transmitted by the fragment receiver 863 after a window of fragments have been sent, only if at least one 864 of the fragments in the window has been lost. In this mode, the 865 ACK informs the sender about received and/or missed fragments from 866 the window of fragments. Upon receipt of an ACK that informs 867 about any lost fragments, the sender retransmits the lost 868 fragments. However, if an ACK is lost, the sender assumes that 869 all fragments covered by the ACK have been successfully delivered, 870 and the receiver will abort the on-going fragmented packet 871 transmission. One exception to this behavior is in the last 872 window, where the receiver MUST transmit an ACK, even if all the 873 fragments in the last window have been correctly received. 875 The same reliability option MUST be used for all fragments of a 876 packet. It is up to implementers and/or representatives of the 877 underlying LPWAN technology to decide which reliability option to use 878 and whether the same reliability option applies to all IPv6 packets 879 or not. Note that the reliability option to be used is not 880 necessarily tied to the particular characteristics of the underlying 881 L2 LPWAN technology (e.g. the No ACK reliability option may be used 882 on top of an L2 LPWAN technology with symmetric characteristics for 883 uplink and downlink). 884 This document does not make any decision as to which fragment 885 delivery reliability option(s) are supported by a specific LPWAN 886 technology. 888 Examples of the different reliability options described are provided 889 in Appendix B. 891 5.4. Fragmentation Frame Formats 893 This section defines the fragment format, the All-0 and All-1 frame 894 formats, the ACK format and the Abort frame formats. 896 5.4.1. Fragment format 898 A fragment comprises a fragment header, a fragment payload, and 899 Padding bits (if any). A fragment conforms to the format shown in 900 Figure 6. The fragment payload carries a subset of either a SCHC 901 header or an IPv6 header or the original IPv6 packet data payload. A 902 fragment is the payload in the L2 protocol data unit (PDU). 904 +-----------------+-----------------------+---------+ 905 | Fragment Header | Fragment payload | padding | 906 +-----------------+-----------------------+---------+ 908 Figure 6: Fragment format. 910 In the No ACK option, fragments except the last one SHALL contain the 911 format as defined in Figure 7. The total size of the fragment header 912 is R bits. 914 <------------ R ----------> 915 <--T--> <--N--> 916 +-- ... --+- ... -+- ... -+---...---+-+ 917 | Rule ID | DTag | FCN | payload |P| 918 +-- ... --+- ... -+- ... -+---...---+-+ 920 Figure 7: Fragment Format for Fragments except the Last One, No ACK 921 option 923 In any of the Window mode options, fragments except the last one 924 SHALL contain the fragmentation format as defined in Figure 8. The 925 total size of the fragment header in this format is R bits. . 927 <------------ R ----------> 928 <--T--> 1 <--N--> 929 +-- ... --+- ... -+-+- ... -+---...---+-+ 930 | Rule ID | DTag |W| FCN | payload |P| 931 +-- ... --+- ... -+-+- ... -+---...---+-+ 933 Figure 8: Fragment Format for Fragments except the Last One, Window 934 mode 936 5.4.2. ACK format 938 The format of an ACK that acknowledges a window that is not the last 939 one (denoted as ALL-0 window) is shown in Figure 9. 941 <-------- R -------> 942 <- T -> 1 943 +---- ... --+-... -+-+----- ... ---+ 944 | Rule ID | DTag |W| Bitmap | (no payload) 945 +---- ... --+-... -+-+----- ... ---+ 947 Figure 9: ACK format for All-0 windows 949 To acknowledge the last window of a packet (denoted as All-1 window), 950 a C bit (i.e. MIC checked) following the W bit is set to 1 to 951 indicate that the MIC check computed by the receiver matches the MIC 952 present in the All-1 fragment. If the MIC check fails, the C bit is 953 set to 0 and the Bitmap for the All-1 window follows. 955 <-------- R -------> <- byte boundary -> 956 <- T -> 1 1 957 +---- ... --+-... -+-+-+ 958 | Rule ID | DTag |W|1| (MIC correct) 959 +---- ... --+-... -+-+-+ 961 +---- ... --+-... -+-+-+------- ... -------+ 962 | Rule ID | DTag |W|0| Bitmap | (MIC Incorrect) 963 +---- ... --+-... -+-+-+------- ... -------+ 964 C 966 Figure 10: Format of an ACK for All-1 windows 968 5.4.3. All-1 and All-0 formats 970 The All-0 format is used for the last fragment of a window that is 971 not the last window of the packet. 973 <------------ R ------------> 974 <- T -> 1 <- N -> 975 +-- ... --+- ... -+-+- ... -+--- ... ---+ 976 | Rule ID | DTag |W| 0..0 | payload | 977 +-- ... --+- ... -+-+- ... -+--- ... ---+ 979 Figure 11: All-0 fragment format 981 The All-0 empty fragment format is used by a sender to request an ACK 982 in ACK-Always mode 984 <------------ R ------------> 985 <- T -> 1 <- N -> 986 +-- ... --+- ... -+-+- ... -+ 987 | Rule ID | DTag |W| 0..0 | (no payload) 988 +-- ... --+- ... -+-+- ... -+ 990 Figure 12: All-0 empty fragment format 992 In the No ACK option, the last fragment of an IPv6 datagram SHALL 993 contain a fragment header that conforms to the format shown in 994 Figure 13. The total size of this fragment header is R+M bits. 996 <------------- R ----------> 997 <- T -> <-N-><----- M -----> 998 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 999 | Rule ID | DTag | 1 | MIC | payload | 1000 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 1002 Figure 13: All-1 Fragment Format for the Last Fragment, No ACK option 1004 In any of the Window modes, the last fragment of an IPv6 datagram 1005 SHALL contain a fragment header that conforms to the format shown in 1006 Figure 14. The total size of the fragment header in this format is 1007 R+M bits. 1009 <------------ R ------------> 1010 <- T -> 1 <- N -> <---- M -----> 1011 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 1012 | Rule ID | DTag |W| 11..1 | MIC | payload | 1013 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 1014 (FCN) 1016 Figure 14: All-1 Fragment Format for the Last Fragment, Window mode 1018 In either ACK-Always or ACK-on-error, in order to request a 1019 retransmission of the ACK for the All-1 window, the fragment sender 1020 uses the format shown in Figure 15. The total size of the fragment 1021 header in this format is R+M bits. 1023 <------------ R ------------> 1024 <- T -> 1 <- N -> <---- M -----> 1025 +-- ... --+- ... -+-+- ... -+---- ... ----+ 1026 | Rule ID | DTag |W| 1..1 | MIC | (no payload) 1027 +-- ... --+- ... -+-+- ... -+---- ... ----+ 1029 Figure 15: All-1 for Retries format, also called All-1 empty 1031 The values for R, N, T and M are not specified in this document, and 1032 have to be determined in other documents (e.g. technology-specific 1033 profile documents). 1035 5.4.4. Abort formats 1037 The All-1 Abort and the ACK abort messages have the following 1038 formats. 1040 <------ byte boundary ------><--- 1 byte ---> 1041 +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+ 1042 | Rule ID | DTag |W| FCN | FF | (no MIC & no payload) 1043 +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+ 1045 Figure 16: All-1 Abort format 1047 <------ byte boundary -----><--- 1 byte ---> 1049 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Rule ID | DTag |W| 1..1| FF | 1051 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Figure 17: ACK Abort format 1055 5.5. Baseline mechanism 1057 The fragment receiver needs to identify all the fragments that belong 1058 to a given IPv6 datagram. To this end, the receiver SHALL use: 1060 o The sender's L2 source address (if present), 1062 o The destination's L2 address (if present), 1064 o Rule ID and 1066 o DTag (the latter, if present). 1068 Then, the fragment receiver may determine the fragment delivery 1069 reliability option that is used for this fragment based on the Rule 1070 ID field in that fragment. 1072 Upon receipt of a link fragment, the receiver starts constructing the 1073 original unfragmented packet. It uses the FCN and the order of 1074 arrival of each fragment to determine the location of the individual 1075 fragments within the original unfragmented packet. A fragment 1076 payload may carry bytes from a SCHC compressed IPv6 header, an 1077 uncompressed IPv6 header or an IPv6 datagram data payload. An 1078 unfragmented packet could be a SCHC compressed or an uncompressed 1079 IPv6 packet (header and data). For example, the receiver may place 1080 the fragment payload within a payload datagram reassembly buffer at 1081 the location determined from: the FCN, the arrival order of the 1082 fragments, and the fragment payload sizes. In Window mode, the 1083 fragment receiver also uses the W bit in the received fragments. 1084 Note that the size of the original, unfragmented packet cannot be 1085 determined from fragmentation headers. 1087 Fragmentation functionality uses the FCN value, which has a length of 1088 N bits. The All-1 and All-0 FCN values are used to control the 1089 fragmentation transmission. The FCN will be assigned sequentially in 1090 a decreasing order starting from 2^N-2, i.e. the highest possible FCN 1091 value depending on the FCN number of bits, but excluding the All-1 1092 value. In all modes, the last fragment of a packet must contains a 1093 MIC which is used to check if there are errors or missing fragments, 1094 and must use the corresponding All-1 fragment format. Also note 1095 that, a fragment with an All-0 format is considered the last fragment 1096 of the current window. 1098 If the recipient receives the last fragment of a datagram (All-1), it 1099 checks for the integrity of the reassembled datagram, based on the 1100 MIC received. In No ACK, if the integrity check indicates that the 1101 reassembled datagram does not match the original datagram (prior to 1102 fragmentation), the reassembled datagram MUST be discarded. In 1103 Window mode, a MIC check is also performed by the fragment receiver 1104 after reception of each subsequent fragment retransmitted after the 1105 first MIC check. 1107 5.5.1. No ACK 1109 In the No ACK mode there is no feedback communication from the 1110 fragment receiver. The sender will send the fragments of a packet 1111 until the last one without any possibility to know if errors or a 1112 losses have occurred. As in this mode there is not a need to 1113 identify specific fragments a one-bit FCN is used, therefore FCN 1114 All-0 will be used in all fragments except the last one. The latter 1115 will carry an All-1 FCN and will also carry the MIC. The receiver 1116 will wait for fragments and will set the Inactivity timer. The No 1117 ACK mode will use the MIC contained in the last fragment to check 1118 error. When the Inactivity Timer expires or when the MIC check 1119 indicates that the reassembled packet does not match the original 1120 one, the receiver will release all resources allocated to reassembly 1121 of the packet. The initial value of the Inactivity Timer will be 1122 determined based on the characteristics of the underlying LPWAN 1123 technology and will be defined in other documents (e.g. technology- 1124 specific profile documents). 1126 5.5.2. The Window modes 1128 In Window modes, a jumping window protocol uses two windows 1129 alternatively, identified as 0 and 1. A fragment with all FCN bits 1130 set to 0 (i.e. an All-0 fragment) indicates that the window is over 1131 (i.e. the fragment is the last one of the window) and allows to 1132 switch from one window to the next one. The All-1 FCN in a fragment 1133 indicates that it is the last fragment of the packet being 1134 transmitted and therefore there will not be another window for the 1135 packet. 1137 The Window mode offers two different reliability option modes: ACK- 1138 on-error and ACK-always. 1140 5.5.2.1. ACK-Always 1142 In ACK-Always, the sender sends fragments by using the two-jumping 1143 window procedure. A delay between each fragment can be added to 1144 respect regulation rules or constraints imposed by the applications. 1145 Each time a fragment is sent, the FCN is decreased by one. When the 1146 FCN reaches value 0 and there are more fragments to be sent, an All-0 1147 fragment is sent and the Retransmission Timer is set. The sender 1148 waits for an ACK to know if transmission errors have occurred. Then, 1149 the receiver sends an ACK reporting whether any fragments have been 1150 lost or not by setting the corresponding bits in the Bitmap, 1151 otherwise, an ACK without Bitmap will be sent, allowing transmission 1152 of a new window. When the last fragment of the packet is sent, an 1153 All-1 fragment (which includes a MIC) is used. In that case, the 1154 sender sets the Retransmission Timer to wait for the ACK 1155 corresponding to the last window. During this period, the sender 1156 starts listening to the radio and starts the Retransmission Timer, 1157 which needs to be dimensioned based on the received window available 1158 for the LPWAN technology in use. If the Retransmission Timer 1159 expires, an empty All-0 (or an empty All-1 if the last fragment has 1160 been sent) fragment is sent to ask the receiver to resend its ACK. 1161 The window number is not changed. 1163 When the sender receives an ACK, it checks the W bit carried by the 1164 ACK. Any ACK carrying an unexpected W bit is discarded. If the W 1165 bit value of the received ACK is correct, the sender analyzes the 1166 received Bitmap. If all the fragments sent during the window have 1167 been well received, and if at least one more fragment needs to be 1168 sent, the sender moves its sending window to the next window value 1169 and sends the next fragments. If no more fragments have to be sent, 1170 then the fragmented packet transmission is finished. 1172 However, if one or more fragments have not been received as per the 1173 ACK (i.e. the corresponding bits are not set in the Bitmap) then the 1174 sender resends the missing fragments. When all missing fragments 1175 have been retransmitted, the sender starts the Retransmission Timer 1176 (even if an All-0 or an All-1 has not been sent during the 1177 retransmission) and waits for an ACK. Upon receipt of the ACK, if 1178 one or more fragments have not yet been received, the counter 1179 Attempts is increased and the sender resends the missing fragments 1180 again. When Attempts reaches MAX_ACK_REQUESTS, the sender aborts the 1181 on-going fragmented packet transmission by sending an Abort message 1182 and releases any resources for transmission of the packet. The 1183 sender also aborts an on-going fragmented packet transmission when a 1184 failed MIC check is reported by the receiver. 1186 On the other hand, at the beginning, the receiver side expects to 1187 receive window 0. Any fragment received but not belonging to the 1188 current window is discarded. All fragments belonging to the correct 1189 window are accepted, and the actual fragment number managed by the 1190 receiver is computed based on the FCN value. The receiver prepares 1191 the Bitmap to report the correctly received and the missing fragments 1192 for the current window. After each fragment is received the receiver 1193 initializes the Inactivity timer, if the Inactivity Timer expires the 1194 transmission is aborted. 1196 When an All-0 fragment is received, it indicates that all the 1197 fragments have been sent in the current window. Since the sender is 1198 not obliged to always send a full window, some fragment number not 1199 set in the receiver memory may not correspond to losses. The 1200 receiver sends the corresponding ACK, the Inactivity Timer is set and 1201 the transmission of the next window by the sender can start. 1203 If an All-0 fragment has been received and all fragments of the 1204 current window have also been received, the receiver then expects a 1205 new Window and waits for the next fragment. Upon receipt of a 1206 fragment, if the window value has not changed, the received fragments 1207 are part of a retransmission. A receiver that has already received a 1208 fragment should discard it, otherwise, it updates the Bitmap. If all 1209 the bits of the Bitmap are set to one, the receiver may send an ACK 1210 without waiting for an All-0 fragment and the Inactivity Timer is 1211 initialized. 1213 On the other hand, if the window value of the next received fragment 1214 is set to the next expected window value, this means that the sender 1215 has received a correct Bitmap reporting that all fragments have been 1216 received. The receiver then updates the value of the next expected 1217 window. 1219 If the receiver receives an All-0 fragment, the sender may send one 1220 or more fragments per window. Otherwise, some fragments in the 1221 window have been lost. 1223 When an All-1 fragment is received, it indicates that the last 1224 fragment of the packet has been sent. Since the last window is not 1225 always full, the MIC will be used to detect if all fragments of the 1226 packet have been received. A correct MIC indicates the end of the 1227 transmission but the receiver must stay alive for an Inactivity Timer 1228 period to answer to any empty All-1 fragments the sender may send if 1229 ACKs sent by the receiver are lost. If the MIC is incorrect, some 1230 fragments have been lost. The receiver sends the ACK regardless of 1231 successful fragmented packet reception or not, the Inactitivity Timer 1232 is set. In case of an incorrect MIC, the receiver waits for 1233 fragments belonging to the same window. After MAX_ACK_REQUESTS, the 1234 receiver will abort the on-going fragmented packet transmission. The 1235 receiver also Aborts upon Inactivity Timer expiration. 1237 5.5.2.2. ACK-on-error 1239 The ACK-on-error sender is similar to ACK-Always, the main difference 1240 being that in ACK-on-error the ACK is not sent at the end of each 1241 window but only when at least one fragment of the current window has 1242 been lost (with the exception of the last window, see next 1243 paragraph). In Ack-on-error, the Retransmission Timer expiration 1244 will be considered as a positive acknowledgment. The Retransmission 1245 Timer is set when sending an All-0 or an All-1 fragment. When the 1246 All-1 fragment has been sent, then the on-going fragmented packet 1247 transmission fragmentation is finished and the sender waits for the 1248 last ACK. At the receiver side, when the All-1 fragment is sent and 1249 the MIC check indicates successful packet reception, an ACK is also 1250 sent to confirm the end of a correct transmission. If the 1251 Retransmission Timer expires, an All-1 empty request for the last ACK 1252 MUST be sent by the sender to complete the fragmented packet 1253 transmission. 1255 If the sender receives an ACK, it checks the window value. ACKs with 1256 an unexpected window number are discarded. If the window number on 1257 the received Bitmap is correct, the sender verifies if the receiver 1258 has received all fragments of the current window. When at least one 1259 fragment has been lost, the counter Attempts is increased by one and 1260 the sender resends the missing fragments again. When Attempts 1261 reaches MAX_ACK_REQUESTS, the sender sends an Abort message and 1262 releases all resources for the on-going fragmented packet 1263 transmission. When the retransmission of missing fragments is 1264 finished, the sender starts listening for an ACK (even if an All-0 or 1265 an All-1 has not been sent during the retransmission) and initializes 1266 and starts the Retransmission Timer. After sending an All-1 1267 fragment, the sender listens for an ACK, initializes Attempts, and 1268 initializes and starts the Retransmission Timer. If the 1269 Retransmission Timer expires, Attempts is increased by one and an 1270 empty All-1 fragment is sent to request the ACK for the last window. 1271 If Attempts reaches MAX_ACK_REQUESTS, the on-going fragmented packet 1272 transmission is aborted. 1274 Unlike the sender, the receiver for ACK-on-error has a larger amount 1275 of differences compared with ACK-Always. First, an ACK is not sent 1276 unless there is a lost fragment or an unexpected behavior (with the 1277 exception of the last window, where an ACK is always sent regardless 1278 of fragment losses or not). The receiver starts by expecting 1279 fragments from window 0 and maintains the information regarding which 1280 fragments it receives. After receiving a fragment, the Inactivity 1281 Timer is set, if no fragment has been received and the Inactivity 1282 Timer expires the transmission is aborted. 1284 Any fragment not belonging to the current window is discarded. The 1285 actual fragment number is computed based on the FCN value. When an 1286 All-0 fragment is received and all fragments have been received, the 1287 receiver updates the expected window value. 1289 If an All-0 fragment is received, even if another fragment is 1290 missing, all fragments from the current window have been sent. Since 1291 the sender is not obligated to send a full window, a fragment number 1292 not used may not necessarily correspond to losses. As the receiver 1293 does not know if the missing fragments are lost or not, it sends an 1294 ACK and reinitialises the Inactivity Timer. 1296 On the other hand, after receiving an All-0 fragment, the receiver 1297 expects a new window and waits for the next fragment. 1298 If the window value of the next fragment has not changed, the 1299 received fragment is a retransmission. A receiver that has already 1300 received a fragment should discard it. If all fragments of a window 1301 (that is not the last one) have been received, the receiver does not 1302 send an ACK. While the receiver waits for the next window and if the 1303 window value is set to the next value, and if an All-1 fragment with 1304 the next value window arrived the receiver aborts the on-going 1305 fragmented packet transmission, and it drops the fragments of the 1306 aborted packet transmission. 1308 If the receiver receives an All-1 fragment, this means that the 1309 transmission should be finished. If the MIC is incorrect some 1310 fragments have been lost. Regardless of fragment losses, the 1311 receiver sends an ACK and initializes the Inactivity Timer. 1313 Reception of an All-1 fragment indicates the last fragment of the 1314 packet has been sent. Since the last window is not always full, the 1315 MIC will be used to detect if all fragments of the window have been 1316 received. A correct MIC check indicates the end of the fragmented 1317 packet transmission. An ACK is sent by the fragment receiver. In 1318 case of an incorrect MIC, the receiver waits for fragments belonging 1319 to the same window or the expiration of the Inactivity Timer. The 1320 latter will lead the receiver to abort the on-going fragmented packet 1321 transmission. 1323 5.5.3. Bitmap Optimization 1325 The Bitmap is transmitted by a receiver as part of the ACK format 1326 when there are some missing fragments in a window. An ACK message 1327 may introduce padding at the end to align transmitted data to a byte 1328 boundary. The first byte boundary includes one or more complete 1329 bytes, depending on the size of Rule ID and DTag. 1331 Note that the ACK sent in response to an All-1 fragment includes the 1332 C bit. Therefore, the window size and thus the Bitmap size need to 1333 be determined taking into account the available space in the layer 1334 two frame payload, where there will be 1 bit less for an ACK sent in 1335 response to an All-1 fragment than in other ACKs. 1337 <---- Bitmap bits ----> 1338 | Rule ID | DTag |W|C|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| 1339 |--- byte boundary ----| 1 byte next | 1 byte next | 1341 Figure 18: Bitmap 1343 The Bitmap, when transmitted, MUST be optimized in size to reduce the 1344 resulting frame size. The right-most bytes with all Bitmap bits set 1345 to 1 MUST NOT be transmitted. As the receiver knows the Bitmap size, 1346 it can reconstruct the original Bitmap without this optimization. In 1347 the example Figure 19, the last 2 bytes of the Bitmap shown in 1348 Figure 18 comprise all bits set to 1, therefore, the last 2 bytes of 1349 the Bitmap are not sent. 1351 In the last window, when checked bit C value is 1, it means that the 1352 received MIC matches the one computed by the receiver, and thus the 1353 Bitmap is not sent. Otherwise, the Bitmap needs to be sent after the 1354 C bit. Note that the introduction of a C bit may force to reduce the 1355 number of fragments in a window to allow the bitmap to fit in a 1356 frame. 1358 <------- R -------> 1359 <- T -> 1 1360 +---- ... --+-... -+-+-+-+ 1361 | Rule ID | DTag |W|1|0| 1362 +---- ... --+-... -+-+-+-+ 1363 |---- byte boundary -----| 1365 Figure 19: Bitmap transmitted fragment format 1367 Figure 20 shows an example of an ACK (for N=3), where the Bitmap 1368 indicates that the second and the fifth fragments have not been 1369 correctly received. 1371 <------ R ------>6 5 4 3 2 1 0 (*) 1372 <- T -> 1 1373 | Rule ID | DTag |W|1|0|1|1|0|1|all-0|padding| Bitmap (before tx) 1374 |--- byte boundary ----| 1 byte next | 1375 (*)=(FCN values indicating the order) 1377 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+ 1378 | Rule ID | DTag |W|1|0|1|1|0|1|1|P| transmitted Bitmap 1379 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+ 1380 |--- byte boundary ----| 1 byte next | 1382 Figure 20: Example of a Bitmap before transmission, and the 1383 transmitted one, in any window except the last one, for N=3 1385 Figure 21 shows an example of an ACK (for N=3), where the Bitmap 1386 indicates that the MIC check has failed but there are no missing 1387 fragments. 1389 <------- R -------> 6 5 4 3 2 1 7 (*) 1390 <- T -> 1 1 1391 | Rule ID | DTag |W|0|1|1|1|1|1|1|1|padding| Bitmap (before tx) 1392 |---- byte boundary ----| 1 byte next | 1 byte next | 1393 C 1394 +---- ... --+-... -+-+-+-+ 1395 | Rule ID | DTag |W|0|1| transmitted Bitmap 1396 +---- ... --+-... -+-+-+-+ 1397 |---- byte boundary -----| 1398 (*) = (FCN values indicating the order) 1400 Figure 21: Example of the Bitmap in Window mode for the last window, 1401 for N=3) 1403 5.6. Supporting multiple window sizes 1405 For ACK-Always or ACK-on-error, implementers may opt to support a 1406 single window size or multiple window sizes. The latter, when 1407 feasible, may provide performance optimizations. For example, a 1408 large window size may be used for packets that need to be carried by 1409 a large number of fragments. However, when the number of fragments 1410 required to carry a packet is low, a smaller window size, and thus a 1411 shorter Bitmap, may be sufficient to provide feedback on all 1412 fragments. If multiple window sizes are supported, the Rule ID may 1413 be used to signal the window size in use for a specific packet 1414 transmission. 1416 Note that the same window size MUST be used for the transmission of 1417 all fragments that belong to a packet. 1419 5.7. Downlink fragment transmission 1421 In some LPWAN technologies, as part of energy-saving techniques, 1422 downlink transmission is only possible immediately after an uplink 1423 transmission. In order to avoid potentially high delay for 1424 fragmented datagram transmission in the downlink, the fragment 1425 receiver MAY perform an uplink transmission as soon as possible after 1426 reception of a fragment that is not the last one. Such uplink 1427 transmission may be triggered by the L2 (e.g. an L2 ACK sent in 1428 response to a fragment encapsulated in a L2 frame that requires an L2 1429 ACK) or it may be triggered from an upper layer. 1431 For fragmented packet transmission in the downlink, and when ACK 1432 Always is used, the fragment receiver MAY support timer-based ACK 1433 retransmission. In this mechanism, the fragment receiver initializes 1434 and starts a timer (the Inactivity Timer is used) after the 1435 transmission of an ACK, except when the ACK is sent in response to 1436 the last fragment of a packet (All-1 fragment). In the latter case, 1437 the fragment receiver does not start a timer after transmission of 1438 the ACK. 1440 If, after transmission of an ACK that is not an All-1 fragment, and 1441 before expiration of the corresponding Inactivity timer, the fragment 1442 receiver receives a fragment that belongs to the current window (e.g. 1443 a missing fragment from the current window) or to the next window, 1444 the Inactivity timer for the ACK is stopped. However, if the 1445 Inactivity timer expires, the ACK is resent and the Inactivity timer 1446 is reinitialized and restarted. 1448 The default initial value for the Inactivity timer, as well as the 1449 maximum number of retries for a specific ACK, denoted 1450 MAX_ACK_RETRIES, are not defined in this document, and need to be 1451 defined in other documents (e.g. technology-specific profiles). The 1452 initial value of the Inactivity timer is expected to be greater than 1453 that of the Retransmission timer, in order to make sure that a 1454 (buffered) fragment to be retransmitted can find an opportunity for 1455 that transmission. 1457 When the fragment sender transmits the All-1 fragment, it initializes 1458 and starts its retransmission timer to a long value (e.g. several 1459 times the initial Inactivity timer). If an ACK is received before 1460 expiration of this timer, the fragment sender retransmits any lost 1461 fragments reported by the ACK, or if the ACK confirms successful 1462 reception of all fragments of the last window, transmission of the 1463 fragmented packet ends. If the timer expires, and no ACK has been 1464 received since the start of the timer, the fragment sender assumes 1465 that the All-1 fragment has been successfully received (and possibly, 1466 the last ACK has been lost: this mechanism assumes that the 1467 retransmission timer for the All-1 fragment is long enough to allow 1468 several ACK retries if the All-1 fragment has not been received by 1469 the fragment receiver, and it also assumes that it is unlikely that 1470 several ACKs become all lost). 1472 6. Padding management 1474 SCHC header, either for compression, fragmentation or acknowledgment 1475 does not preserve byte alignment. Since most of the LPWAN network 1476 technologies payload is expressed in an integer number of bytes; the 1477 sender will introduce at the end some padding bits while the receiver 1478 must be able to eliminate them. 1480 The algorithm for padding bit elimination for compressed or 1481 fragmented frames is simple. Based on the following principle: * The 1482 SCHC header is not aligned on a byte boundary, but its size in bits 1483 is given by the rule. 1485 o The data size is variable, but always a multiple of 8 bits. 1487 o Padding bits MUST never exceed 7 bits. 1489 In that case, a receiver after decoding the SCHC header, must take 1490 the maximum multiple of 8 bits as data. The remaining bits are 1491 padding bits. 1493 7. SCHC Compression for IPv6 and UDP headers 1495 This section lists the different IPv6 and UDP header fields and how 1496 they can be compressed. 1498 7.1. IPv6 version field 1500 This field always holds the same value. Therefore, the TV is 6, the 1501 MO is "equal" and the "CDA "not-sent". 1503 7.2. IPv6 Traffic class field 1505 If the DiffServ field identified by the rest of the rule does not 1506 vary and is known by both sides, the TV should contain this well- 1507 known value, the MO should be "equal" and the CDA must be "not-sent. 1509 If the DiffServ field identified by the rest of the rule varies over 1510 time or is not known by both sides, then there are two possibilities 1511 depending on the variability of the value: The first one is to do not 1512 compressed the field and sends the original value. In the second, 1513 where the values can be computed by sending only the LSB bits: 1515 o TV is not set to any value, MO is set to "ignore" and CDA is set 1516 to "value-sent" 1518 o TV contains a stable value, MO is MSB(X) and CDA is set to LSB 1520 7.3. Flow label field 1522 If the Flow Label field identified by the rest of the rule does not 1523 vary and is known by both sides, the TV should contain this well- 1524 known value, the MO should be "equal" and the CDA should be "not- 1525 sent". 1527 If the Flow Label field identified by the rest of the rule varies 1528 during time or is not known by both sides, there are two 1529 possibilities depending on the variability of the value: The first 1530 one is without compression and then the value is sent. In the 1531 second, only part of the value is sent and the decompressor needs to 1532 compute the original value: 1534 o TV is not set, MO is set to "ignore" and CDA is set to "value- 1535 sent" 1537 o TV contains a stable value, MO is MSB(X) and CDA is set to LSB 1539 7.4. Payload Length field 1541 If the LPWAN technology does not add padding, this field can be 1542 elided for the transmission on the LPWAN network. The SCHC C/D 1543 recomputes the original payload length value. The TV is not set, the 1544 MO is set to "ignore" and the CDA is "compute-IPv6-length". 1546 If the payload length needs to be sent and does not need to be coded 1547 in 16 bits, the TV can be set to 0x0000, the MO set to "MSB (16-s)" 1548 and the CDA to "LSB". The 's' parameter depends on the expected 1549 maximum packet length. 1551 In other cases, the payload length field must be sent and the CDA is 1552 replaced by "value-sent". 1554 7.5. Next Header field 1556 If the Next Header field identified by the rest of the rule does not 1557 vary and is known by both sides, the TV should contain this Next 1558 Header value, the MO should be "equal" and the CDA should be "not- 1559 sent". 1561 If the Next Header field identified by the rest of the rule varies 1562 during time or is not known by both sides, then TV is not set, MO is 1563 set to "ignore" and CDA is set to "value-sent". A matching-list may 1564 also be used. 1566 7.6. Hop Limit field 1568 The End System is generally a device and does not forward packets. 1569 Therefore, the Hop Limit value is constant. So, the TV is set with a 1570 default value, the MO is set to "equal" and the CDA is set to "not- 1571 sent". 1573 Otherwise the value is sent on the LPWAN: TV is not set, MO is set to 1574 ignore and CDA is set to "value-sent". 1576 Note that the field behavior differs in upstream and downstream. In 1577 upstream, since there is no IP forwarding between the Dev and the 1578 SCHC C/D, the value is relatively constant. On the other hand, the 1579 downstream value depends of Internet routing and may change more 1580 frequently. One solution could be to use the Direction Indicator 1581 (DI) to distinguish both directions to elide the field in the 1582 upstream direction and send the value in the downstream direction. 1584 7.7. IPv6 addresses fields 1586 As in 6LoWPAN [RFC4944], IPv6 addresses are splitted into two 64-bit 1587 long fields; one for the prefix and one for the Interface Identifier 1588 (IID). These fields should be compressed. To allow a single rule, 1589 these values are identified by their role (DEV or APP) and not by 1590 their position in the frame (source or destination). The SCHC C/D 1591 must be aware of the traffic direction (upstream, downstream) to 1592 select the appropriate field. 1594 7.7.1. IPv6 source and destination prefixes 1596 Both ends must be synchronized with the appropriate prefixes. For a 1597 specific flow, the source and destination prefixes can be unique and 1598 stored in the context. It can be either a link-local prefix or a 1599 global prefix. In that case, the TV for the source and destination 1600 prefixes contain the values, the MO is set to "equal" and the CDA is 1601 set to "not-sent". 1603 In case the rule allows several prefixes, mapping-list must be used. 1604 The different prefixes are listed in the TV associated with a short 1605 ID. The MO is set to "match-mapping" and the CDA is set to "mapping- 1606 sent". 1608 Otherwise the TV contains the prefix, the MO is set to "equal" and 1609 the CDA is set to "value-sent". 1611 7.7.2. IPv6 source and destination IID 1613 If the DEV or APP IID are based on an LPWAN address, then the IID can 1614 be reconstructed with information coming from the LPWAN header. In 1615 that case, the TV is not set, the MO is set to "ignore" and the CDA 1616 is set to "DEViid" or "APPiid". Note that the LPWAN technology is 1617 generally carrying a single device identifier corresponding to the 1618 DEV. The SCHC C/D may also not be aware of these values. 1620 If the DEV address has a static value that is not derived from an 1621 IEEE EUI-64, then TV contains the actual Dev address value, the MO 1622 operator is set to "equal" and the CDA is set to "not-sent". 1624 If several IIDs are possible, then the TV contains the list of 1625 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 1626 "mapping-sent". 1628 Otherwise the value variation of the IID may be reduced to few bytes. 1629 In that case, the TV is set to the stable part of the IID, the MO is 1630 set to "MSB" and the CDA is set to "LSB". 1632 Finally, the IID can be sent on the LPWAN. In that case, the TV is 1633 not set, the MO is set to "ignore" and the CDA is set to "value- 1634 sent". 1636 7.8. IPv6 extensions 1638 No extension rules are currently defined. They can be based on the 1639 MOs and CDAs described above. 1641 7.9. UDP source and destination port 1643 To allow a single rule, the UDP port values are identified by their 1644 role (DEV or APP) and not by their position in the frame (source or 1645 destination). The SCHC C/D must be aware of the traffic direction 1646 (upstream, downstream) to select the appropriate field. The 1647 following rules apply for DEV and APP port numbers. 1649 If both ends know the port number, it can be elided. The TV contains 1650 the port number, the MO is set to "equal" and the CDA is set to "not- 1651 sent". 1653 If the port variation is on few bits, the TV contains the stable part 1654 of the port number, the MO is set to "MSB" and the CDA is set to 1655 "LSB". 1657 If some well-known values are used, the TV can contain the list of 1658 these values, the MO is set to "match-mapping" and the CDA is set to 1659 "mapping-sent". 1661 Otherwise the port numbers are sent on the LPWAN. The TV is not set, 1662 the MO is set to "ignore" and the CDA is set to "value-sent". 1664 7.10. UDP length field 1666 If the LPWAN technology does not introduce padding, the UDP length 1667 can be computed from the received data. In that case, the TV is not 1668 set, the MO is set to "ignore" and the CDA is set to "compute-UDP- 1669 length". 1671 If the payload is small, the TV can be set to 0x0000, the MO set to 1672 "MSB" and the CDA to "LSB". 1674 On other cases, the length must be sent and the CDA is replaced by 1675 "value-sent". 1677 7.11. UDP Checksum field 1679 IPv6 mandates a checksum in the protocol above IP. Nevertheless, if 1680 a more efficient mechanism such as L2 CRC or MIC is carried by or 1681 over the L2 (such as in the LPWAN fragmentation process (see 1682 Section 5)), the UDP checksum transmission can be avoided. In that 1683 case, the TV is not set, the MO is set to "ignore" and the CDA is set 1684 to "compute-UDP-checksum". 1686 In other cases, the checksum must be explicitly sent. The TV is not 1687 set, the MO is set to "ignore" and the CDF is set to "value-sent". 1689 8. Security considerations 1691 8.1. Security considerations for header compression 1693 A malicious header compression could cause the reconstruction of a 1694 wrong packet that does not match with the original one, such 1695 corruption may be detected with end-to-end authentication and 1696 integrity mechanisms. Denial of Service may be produced but its 1697 arise other security problems that may be solved with or without 1698 header compression. 1700 8.2. Security considerations for fragmentation 1702 This subsection describes potential attacks to LPWAN fragmentation 1703 and suggests possible countermeasures. 1705 A node can perform a buffer reservation attack by sending a first 1706 fragment to a target. Then, the receiver will reserve buffer space 1707 for the IPv6 packet. Other incoming fragmented packets will be 1708 dropped while the reassembly buffer is occupied during the reassembly 1709 timeout. Once that timeout expires, the attacker can repeat the same 1710 procedure, and iterate, thus creating a denial of service attack. 1711 The (low) cost to mount this attack is linear with the number of 1712 buffers at the target node. However, the cost for an attacker can be 1713 increased if individual fragments of multiple packets can be stored 1714 in the reassembly buffer. To further increase the attack cost, the 1715 reassembly buffer can be splitted into fragment-sized buffer slots. 1716 Once a packet is complete, it is processed normally. If buffer 1717 overload occurs, a receiver can discard packets based on the sender 1718 behavior, which may help identify which fragments have been sent by 1719 an attacker. 1721 In another type of attack, the malicious node is required to have 1722 overhearing capabilities. If an attacker can overhear a fragment, it 1723 can send a spoofed duplicate (e.g. with random payload) to the 1724 destination. If the LPWAN technology does not support suitable 1725 protection (e.g. source authentication and frame counters to prevent 1726 replay attacks), a receiver cannot distinguish legitimate from 1727 spoofed fragments. Therefore, the original IPv6 packet will be 1728 considered corrupt and will be dropped. To protect resource- 1729 constrained nodes from this attack, it has been proposed to establish 1730 a binding among the fragments to be transmitted by a node, by 1731 applying content-chaining to the different fragments, based on 1732 cryptographic hash functionality. The aim of this technique is to 1733 allow a receiver to identify illegitimate fragments. 1735 Further attacks may involve sending overlapped fragments (i.e. 1736 comprising some overlapping parts of the original IPv6 datagram). 1737 Implementers should make sure that the correct operation is not 1738 affected by such event. 1740 In Window mode - ACK on error, a malicious node may force a fragment 1741 sender to resend a fragment a number of times, with the aim to 1742 increase consumption of the fragment sender's resources. To this 1743 end, the malicious node may repeatedly send a fake ACK to the 1744 fragment sender, with a Bitmap that reports that one or more 1745 fragments have been lost. In order to mitigate this possible attack, 1746 MAX_FRAG_RETRIES may be set to a safe value which allows to limit the 1747 maximum damage of the attack to an acceptable extent. However, note 1748 that a high setting for MAX_FRAG_RETRIES benefits fragment delivery 1749 reliability, therefore the trade-off needs to be carefully 1750 considered. 1752 9. Acknowledgements 1754 Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier, 1755 Eduardo Ingles Sanchez, Arunprabhu Kandasamy, Sergio Lopez Bernal, 1756 Antony Markovski, Alexander Pelov, Pascal Thubert, Juan Carlos Zuniga 1757 and Diego Dujovne for useful design consideration and comments. 1759 10. References 1761 10.1. Normative References 1763 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1764 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1765 December 1998, . 1767 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1768 "Transmission of IPv6 Packets over IEEE 802.15.4 1769 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1770 . 1772 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1773 Header Compression (ROHC) Framework", RFC 5795, 1774 DOI 10.17487/RFC5795, March 2010, 1775 . 1777 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1778 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 1779 February 2014, . 1781 10.2. Informative References 1783 [I-D.ietf-lpwan-overview] 1784 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 1785 overview-07 (work in progress), October 2017. 1787 Appendix A. SCHC Compression Examples 1789 This section gives some scenarios of the compression mechanism for 1790 IPv6/UDP. The goal is to illustrate the SCHC behavior. 1792 The most common case using the mechanisms defined in this document 1793 will be a LPWAN Dev that embeds some applications running over CoAP. 1794 In this example, three flows are considered. The first flow is for 1795 the device management based on CoAP using Link Local IPv6 addresses 1796 and UDP ports 123 and 124 for Dev and App, respectively. The second 1797 flow will be a CoAP server for measurements done by the Device (using 1798 ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to 1799 beta::1/64. The last flow is for legacy applications using different 1800 ports numbers, the destination IPv6 address prefix is gamma::1/64. 1802 Figure 22 presents the protocol stack for this Device. IPv6 and UDP 1803 are represented with dotted lines since these protocols are 1804 compressed on the radio link. 1806 Management Data 1807 +----------+---------+---------+ 1808 | CoAP | CoAP | legacy | 1809 +----||----+---||----+---||----+ 1810 . UDP . UDP | UDP | 1811 ................................ 1812 . IPv6 . IPv6 . IPv6 . 1813 +------------------------------+ 1814 | SCHC Header compression | 1815 | and fragmentation | 1816 +------------------------------+ 1817 | LPWAN L2 technologies | 1818 +------------------------------+ 1819 DEV or NGW 1821 Figure 22: Simplified Protocol Stack for LP-WAN 1823 Note that in some LPWAN technologies, only the Devs have a device ID. 1824 Therefore, when such technologies are used, it is necessary to define 1825 statically an IID for the Link Local address for the SCHC C/D. 1827 Rule 0 1828 +----------------+--+--+--+---------+--------+------------++------+ 1829 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 1830 | | | | | | Opera. | Action ||[bits]| 1831 +----------------+--+--+--+---------+---------------------++------+ 1832 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1833 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1834 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1835 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1836 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1837 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 1838 |IPv6 DEVprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 1839 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1840 |IPv6 APPprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 1841 |IPv6 APPiid |64|1 |Bi|::1 | equal | not-sent || | 1842 +================+==+==+==+=========+========+============++======+ 1843 |UDP DEVport |16|1 |Bi|123 | equal | not-sent || | 1844 |UDP APPport |16|1 |Bi|124 | equal | not-sent || | 1845 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1846 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1847 +================+==+==+==+=========+========+============++======+ 1849 Rule 1 1850 +----------------+--+--+--+---------+--------+------------++------+ 1851 | Field |FL|FP|DI| Value | Match | Action || Sent | 1852 | | | | | | Opera. | Action ||[bits]| 1853 +----------------+--+--+--+---------+--------+------------++------+ 1854 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1855 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1856 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1857 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1858 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1859 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 1860 |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| [1] | 1861 | | | | |fe80::/64] mapping| || | 1862 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1863 |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| [2] | 1864 | | | | |alpha/64,| mapping| || | 1865 | | | | |fe80::64]| | || | 1866 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 1867 +================+==+==+==+=========+========+============++======+ 1868 |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | 1869 |UDP APPport |16|1 |Bi|5683 | equal | not-sent || | 1870 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1871 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1872 +================+==+==+==+=========+========+============++======+ 1874 Rule 2 1875 +----------------+--+--+--+---------+--------+------------++------+ 1876 | Field |FL|FP|DI| Value | Match | Action || Sent | 1877 | | | | | | Opera. | Action ||[bits]| 1878 +----------------+--+--+--+---------+--------+-------------++------+ 1879 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1880 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1881 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1882 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1883 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1884 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 1885 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] | 1886 |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | 1887 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1888 |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | 1889 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 1890 +================+==+==+==+=========+========+============++======+ 1891 |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | 1892 |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | 1893 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1894 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1895 +================+==+==+==+=========+========+============++======+ 1897 Figure 23: Context rules 1899 All the fields described in the three rules depicted on Figure 23 are 1900 present in the IPv6 and UDP headers. The DEViid-DID value is found 1901 in the L2 header. 1903 The second and third rules use global addresses. The way the Dev 1904 learns the prefix is not in the scope of the document. 1906 The third rule compresses port numbers to 4 bits. 1908 Appendix B. Fragmentation Examples 1910 This section provides examples of different fragment delivery 1911 reliability options possible on the basis of this specification. 1913 Figure 24 illustrates the transmission of an IPv6 packet that needs 1914 11 fragments in the No ACK option. Where FCN is always 1 bit. 1916 Sender Receiver 1917 |-------FCN=0-------->| 1918 |-------FCN=0-------->| 1919 |-------FCN=0-------->| 1920 |-------FCN=0-------->| 1921 |-------FCN=0-------->| 1922 |-------FCN=0-------->| 1923 |-------FCN=0-------->| 1924 |-------FCN=0-------->| 1925 |-------FCN=0-------->| 1926 |-------FCN=0-------->| 1927 |-------FCN=1-------->|MIC checked => 1929 Figure 24: Transmission of an IPv6 packet carried by 11 fragments in 1930 the No ACK option 1932 Figure 25 illustrates the transmission of an IPv6 packet that needs 1933 11 fragments in ACK-on-error, for N=3, without losses. 1935 Sender Receiver 1936 |-----W=0, FCN=6----->| 1937 |-----W=0, FCN=5----->| 1938 |-----W=0, FCN=4----->| 1939 |-----W=0, FCN=3----->| 1940 |-----W=0, FCN=2----->| 1941 |-----W=0, FCN=1----->| 1942 |-----W=0, FCN=0----->| 1943 (no ACK) 1944 |-----W=1, FCN=6----->| 1945 |-----W=1, FCN=5----->| 1946 |-----W=1, FCN=4----->| 1947 |-----W=1, FCN=7----->|MIC checked => 1948 |<---- ACK, W=1 ------| 1950 Figure 25: Transmission of an IPv6 packet carried by 11 fragments in 1951 ACK-on-error, for N=3 and MAX_WIND_FCN=6, without losses. 1953 Figure 26 illustrates the transmission of an IPv6 packet that needs 1954 11 fragments ACK-on-error, for N=3, with three losses. 1956 Sender Receiver 1957 |-----W=0, FCN=6----->| 1958 |-----W=0, FCN=5----->| 1959 |-----W=0, FCN=4--X-->| 1960 |-----W=0, FCN=3----->| 1961 |-----W=0, FCN=2--X-->| 7 1962 |-----W=0, FCN=1----->| / 1963 |-----W=0, FCN=0----->| 6543210 1964 |<-----ACK, W=0-------|Bitmap:1101011 1965 |-----W=0, FCN=4----->| 1966 |-----W=0, FCN=2----->| 1967 (no ACK) 1968 |-----W=1, FCN=6----->| 1969 |-----W=1, FCN=5----->| 1970 |-----W=1, FCN=4--X-->| 1971 |-----W=1, FCN=7----->|MIC checked 1972 |<-----ACK, W=1-------|C=0 Bitmap:1100001 1973 |-----W=1, FCN=4----->|MIC checked => 1974 |<---- ACK, W=1 ------| 1976 Figure 26: Transmission of an IPv6 packet carried by 11 fragments in 1977 ACK-on-error, for N=3 and MAX_WIND_FCN=6, three losses. 1979 Figure 27 illustrates the transmission of an IPv6 packet that needs 1980 11 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, without 1981 losses. Note: in Window mode, an additional bit will be needed to 1982 number windows. 1984 Sender Receiver 1985 |-----W=0, FCN=6----->| 1986 |-----W=0, FCN=5----->| 1987 |-----W=0, FCN=4----->| 1988 |-----W=0, FCN=3----->| 1989 |-----W=0, FCN=2----->| 1990 |-----W=0, FCN=1----->| 1991 |-----W=0, FCN=0----->| 1992 |<-----ACK, W=0-------| Bitmap:1111111 1993 |-----W=1, FCN=6----->| 1994 |-----W=1, FCN=5----->| 1995 |-----W=1, FCN=4----->| 1996 |-----W=1, FCN=7----->|MIC checked => 1997 |<-----ACK, W=1-------| C=1 no Bitmap 1998 (End) 2000 Figure 27: Transmission of an IPv6 packet carried by 11 fragments in 2001 ACK-Always, for N=3 and MAX_WIND_FCN=6, no losses. 2003 Figure 28 illustrates the transmission of an IPv6 packet that needs 2004 11 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 2005 losses. 2007 Sender Receiver 2008 |-----W=1, FCN=6----->| 2009 |-----W=1, FCN=5----->| 2010 |-----W=1, FCN=4--X-->| 2011 |-----W=1, FCN=3----->| 2012 |-----W=1, FCN=2--X-->| 7 2013 |-----W=1, FCN=1----->| / 2014 |-----W=1, FCN=0----->| 6543210 2015 |<-----ACK, W=1-------|Bitmap:1101011 2016 |-----W=1, FCN=4----->| 2017 |-----W=1, FCN=2----->| 2018 |<-----ACK, W=1-------|Bitmap: 2019 |-----W=0, FCN=6----->| 2020 |-----W=0, FCN=5----->| 2021 |-----W=0, FCN=4--X-->| 2022 |-----W=0, FCN=7----->|MIC checked 2023 |<-----ACK, W=0-------| C= 0 Bitmap:11000001 2024 |-----W=0, FCN=4----->|MIC checked => 2025 |<-----ACK, W=0-------| C= 1 no Bitmap 2026 (End) 2028 Figure 28: Transmission of an IPv6 packet carried by 11 fragments in 2029 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses. 2031 Figure 29 illustrates the transmission of an IPv6 packet that needs 6 2032 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 2033 losses, and only one retry is needed for each lost fragment. Note 2034 that, since a single window is needed for transmission of the IPv6 2035 packet in this case, the example illustrates behavior when losses 2036 happen in the last window. 2038 Sender Receiver 2039 |-----W=0, CFN=6----->| 2040 |-----W=0, CFN=5----->| 2041 |-----W=0, CFN=4--X-->| 2042 |-----W=0, CFN=3--X-->| 2043 |-----W=0, CFN=2--X-->| 2044 |-----W=0, CFN=7----->|MIC checked 2045 |<-----ACK, W=0-------|C= 0 Bitmap:1100001 2046 |-----W=0, CFN=4----->|MIC checked: failed 2047 |-----W=0, CFN=3----->|MIC checked: failed 2048 |-----W=0, CFN=2----->|MIC checked: success 2049 |<-----ACK, W=0-------|C=1 no Bitmap 2050 (End) 2052 Figure 29: Transmission of an IPv6 packet carried by 11 fragments in 2053 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and only 2054 one retry is needed for each lost fragment. 2056 Figure 30 illustrates the transmission of an IPv6 packet that needs 6 2057 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 2058 losses, and the second ACK is lost. Note that, since a single window 2059 is needed for transmission of the IPv6 packet in this case, the 2060 example illustrates behavior when losses happen in the last window. 2062 Sender Receiver 2063 |-----W=0, CFN=6----->| 2064 |-----W=0, CFN=5----->| 2065 |-----W=0, CFN=4--X-->| 2066 |-----W=0, CFN=3--X-->| 2067 |-----W=0, CFN=2--X-->| 2068 |-----W=0, CFN=7----->|MIC checked 2069 |<-----ACK, W=0-------|C=0 Bitmap:1100001 2070 |-----W=0, CFN=4----->|MIC checked: wrong 2071 |-----W=0, CFN=3----->|MIC checked: wrong 2072 |-----W=0, CFN=2----->|MIC checked: right 2073 | X---ACK, W=0-------|C= 1 no Bitmap 2074 timeout | | 2075 |-----W=0, CFN=7----->| 2076 |<-----ACK, W=0-------|C= 1 no Bitmap 2078 (End) 2080 Figure 30: Transmission of an IPv6 packet carried by 11 fragments in 2081 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and the 2082 second ACK is lost. 2084 Figure 31 illustrates the transmission of an IPv6 packet that needs 6 2085 fragments in ACK-Always, for N=3 and MAX_WIND_FCN=6, with three 2086 losses, and one retransmitted fragment is lost. Note that, since a 2087 single window is needed for transmission of the IPv6 packet in this 2088 case, the example illustrates behavior when losses happen in the last 2089 window. 2091 Sender Receiver 2092 |-----W=0, CFN=6----->| 2093 |-----W=0, CFN=5----->| 2094 |-----W=0, CFN=4--X-->| 2095 |-----W=0, CFN=3--X-->| 2096 |-----W=0, CFN=2--X-->| 2097 |-----W=0, CFN=7----->|MIC checked 2098 |<-----ACK, W=0-------|C=0 Bitmap:1100001 2099 |-----W=0, CFN=4----->|MIC checked: wrong 2100 |-----W=0, CFN=3----->|MIC checked: wrong 2101 |-----W=0, CFN=2--X-->| 2102 timeout| | 2103 |-----W=0, CFN=7----->|All-0 empty 2104 |<-----ACK, W=0-------|C=0 Bitmap: 1111101 2105 |-----W=0, CFN=2----->|MIC checked: right 2106 |<-----ACK, W=0-------|C=1 no Bitmap 2107 (End) 2109 Figure 31: Transmission of an IPv6 packet carried by 11 fragments in 2110 ACK-Always, for N=3, and MAX_WIND_FCN=6, with three losses, and one 2111 retransmitted fragment is lost. 2113 Appendix C illustrates the transmission of an IPv6 packet that needs 2114 28 fragments in ACK-Always, for N=5 and MAX_WIND_FCN=23, with two 2115 losses. Note that MAX_WIND_FCN=23 may be useful when the maximum 2116 possible Bitmap size, considering the maximum lower layer technology 2117 payload size and the value of R, is 3 bytes. Note also that the FCN 2118 of the last fragment of the packet is the one with FCN=31 (i.e. 2119 FCN=2^N-1 for N=5, or equivalently, all FCN bits set to 1). 2121 Sender Receiver 2122 |-----W=0, CFN=23----->| 2123 |-----W=0, CFN=22----->| 2124 |-----W=0, CFN=21--X-->| 2125 |-----W=0, CFN=20----->| 2126 |-----W=0, CFN=19----->| 2127 |-----W=0, CFN=18----->| 2128 |-----W=0, CFN=17----->| 2129 |-----W=0, CFN=16----->| 2130 |-----W=0, CFN=15----->| 2131 |-----W=0, CFN=14----->| 2132 |-----W=0, CFN=13----->| 2133 |-----W=0, CFN=12----->| 2134 |-----W=0, CFN=11----->| 2135 |-----W=0, CFN=10--X-->| 2136 |-----W=0, CFN=9 ----->| 2137 |-----W=0, CFN=8 ----->| 2138 |-----W=0, CFN=7 ----->| 2139 |-----W=0, CFN=6 ----->| 2140 |-----W=0, CFN=5 ----->| 2141 |-----W=0, CFN=4 ----->| 2142 |-----W=0, CFN=3 ----->| 2143 |-----W=0, CFN=2 ----->| 2144 |-----W=0, CFN=1 ----->| 2145 |-----W=0, CFN=0 ----->| 2146 | |lcl-Bitmap:110111111111101111111111 2147 |<------ACK, W=0-------| Bitmap:1101111111111011 2148 |-----W=0, CFN=21----->| 2149 |-----W=0, CFN=10----->| 2150 |<------ACK, W=0-------|no Bitmap 2151 |-----W=1, CFN=23----->| 2152 |-----W=1, CFN=22----->| 2153 |-----W=1, CFN=21----->| 2154 |-----W=1, CFN=31----->|MIC checked => 2155 |<------ACK, W=1-------|no Bitmap 2156 (End) 2158 Appendix C. Fragmentation State Machines 2160 The fragmentation state machines of the sender and the receiver in 2161 the different reliability options are next in the following figures: 2163 +===========+ 2164 +------------+ Init | 2165 | FCN=0 +===========+ 2166 | No Window 2167 | No Bitmap 2168 | +-------+ 2169 | +========+==+ | More Fragments 2170 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 2171 +--------> | Send | send Fragment (FCN=0) 2172 +===+=======+ 2173 | last fragment 2174 | ~~~~~~~~~~~~ 2175 | FCN = 1 2176 v send fragment+MIC 2177 +============+ 2178 | END | 2179 +============+ 2181 Figure 32: Sender State Machine for the No ACK Mode 2183 +------+ Not All-1 2184 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ 2185 | + <--+ set Inactivity Timer 2186 | RCV Frag +-------+ 2187 +=+===+======+ |All-1 & 2188 All-1 & | | |MIC correct 2189 MIC wrong | |Inactivity | 2190 | |Timer Exp. | 2191 v | | 2192 +==========++ | v 2193 | Error |<-+ +========+==+ 2194 +===========+ | END | 2195 +===========+ 2197 Figure 33: Receiver State Machine for the No ACK Mode 2198 +=======+ 2199 | INIT | FCN!=0 & more frags 2200 | | ~~~~~~~~~~~~~~~~~~~~~~ 2201 +======++ +--+ send Window + frag(FCN) 2202 W=0 | | | FCN- 2203 Clear local Bitmap | | v set local Bitmap 2204 FCN=max value | ++==+========+ 2205 +> | | 2206 +---------------------> | SEND | 2207 | +==+=====+===+ 2208 | FCN==0 & more frags | | last frag 2209 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 2210 | set local-Bitmap | | set local-Bitmap 2211 | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC 2212 | set Retrans_Timer | | set Retrans_Timer 2213 | | | 2214 |Recv_wnd == wnd & | | 2215 |Lcl_Bitmap==recv_Bitmap& | | +------------------------+ 2216 |more frag | | |local-Bitmap!=rcv-Bitmap| 2217 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 2218 |Stop Retrans_Timer | | | Attemp++ v 2219 |clear local_Bitmap v v | +======++ 2220 |window=next_window +====+=====+==+==+ |Resend | 2221 +---------------------+ | |Missing| 2222 +----+ Wait | |Frag | 2223 not expected wnd | | Bitmap | +======++ 2224 ~~~~~~~~~~~~~~~~ +--->+ +-+Retrans_Timer Exp | 2225 discard frag +==+=+===+=+===+=+ |~~~~~~~~~~~~~~~~~ | 2226 | | | ^ ^ |reSend(empty)All-* | 2227 | | | | | |Set Retrans_Timer | 2228 MIC_bit==1 & | | | | +---+Attemp++ | 2229 Recv_window==window & | | | +---------------------------+ 2230 Lcl_Bitmap==recv_Bitmap &| | | all missing frag sent 2231 no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ 2232 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer 2233 Stop Retrans_Timer| | | 2234 +=============+ | | | 2235 | END +<--------+ | | Attemp > MAX_ACK_REQUESTS 2236 +=============+ | | ~~~~~~~~~~~~~~~~~~ 2237 All-1 Window | v Send Abort 2238 ~~~~~~~~~~~~ | +=+===========+ 2239 MIC_bit ==0 & +>| ERROR | 2240 Lcl_Bitmap==recv_Bitmap +=============+ 2242 Figure 34: Sender State Machine for the ACK Always Mode 2244 Not All- & w=expected +---+ +---+w = Not expected 2245 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2246 Set local_Bitmap(FCN) | v v |discard 2247 ++===+===+===+=+ 2248 +---------------------+ Rcv +--->* ABORT 2249 | +------------------+ Window | 2250 | | +=====+==+=====+ 2251 | | All-0 & w=expect | ^ w =next & not-All 2252 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 2253 | | set lcl_Bitmap(FCN)| |expected = next window 2254 | | send local_Bitmap | |Clear local_Bitmap 2255 | | | | 2256 | | w=expct & not-All | | 2257 | | ~~~~~~~~~~~~~~~~~~ | | 2258 | | set lcl_Bitmap(FCN)+-+ | | +--+ w=next & All-0 2259 | | if lcl_Bitmap full | | | | | | ~~~~~~~~~~~~~~~ 2260 | | send lcl_Bitmap | | | | | | expct = nxt wnd 2261 | | v | v v v | 2262 | | w=expct & All-1 +=+=+=+==+=++ | Clear lcl_Bitmap 2263 | | ~~~~~~~~~~~ +->+ Wait +<+ set lcl_Bitmap(FCN) 2264 | | discard +--| Next | send lcl_Bitmap 2265 | | All-0 +---------+ Window +--->* ABORT 2266 | | ~~~~~ +-------->+========+=++ 2267 | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt 2268 | | & MIC wrong| | & MIC right 2269 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 2270 | | set local_Bitmap(FCN)| |set lcl_Bitmap(FCN) 2271 | | send local_Bitmap| |send local_Bitmap 2272 | | | +----------------------+ 2273 | |All-1 & w=expct | | 2274 | |& MIC wrong v +---+ w=expctd & | 2275 | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong | 2276 | |set local_Bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ | 2277 | |send local_Bitmap | Wait End | set lcl_btmp(FCN)| 2278 | +--------------------->+ +--->* ABORT | 2279 | +===+====+=+-+ All-1&MIC wrong| 2280 | | ^ | ~~~~~~~~~~~~~~~| 2281 | | +---+ send lcl_btmp | 2282 | w=expected & MIC right| | | 2283 | ~~~~~~~~~~~~~~~~~~~~~~| +-+ Not All-1 | 2284 | set local_Bitmap(FCN)| | | ~~~~~~~~~ | 2285 | send local_Bitmap| | | discard | 2286 | | | | | 2287 |All-1 & w=expctd & MIC right | | | +-+ All-1 | 2288 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v | v ~~~~~~~~~ | 2289 |set local_Bitmap(FCN) +=+=+=+=+=++Send lcl_btmp | 2290 |send local_Bitmap | | | 2291 +-------------------------->+ END +<---------------+ 2292 ++==+======+ 2293 --->* ABORT 2294 ~~~~~~~ 2295 Inactivity_Timer = expires 2296 When DWN_Link 2297 IF Inactivity_Timer expires 2298 Send DWL Request 2299 Attemp++ 2301 Figure 35: Receiver State Machine for the ACK Always Mode 2302 +=======+ 2303 | | 2304 | INIT | 2305 | | FCN!=0 & more frags 2306 +======++ +--+ ~~~~~~~~~~~~~~~~~~~~~~ 2307 W=0 | | | send Window + frag(FCN) 2308 ~~~~~~~~~~~~~~~~~~ | | | FCN- 2309 Clear local Bitmap | | v set local Bitmap 2310 FCN=max value | ++=============+ 2311 +> | | 2312 | SEND | 2313 +-------------------------> | | 2314 | ++=====+=======+ 2315 | FCN==0 & more frags| |last frag 2316 | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~~~~~~~~ 2317 | set local-Bitmap| |set local-Bitmap 2318 | send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC 2319 | set Retrans_Timer| |set Retrans_Timer 2320 | | | 2321 |Retrans_Timer expires & | | local-Bitmap!=rcv-Bitmap 2322 |more fragments | | +-----------------+ 2323 |~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~~~~~ | 2324 |stop Retrans_Timer | | | Attemp++ | 2325 |clear local-Bitmap v v | v 2326 |window = next window +=====+=====+==+==+ +====+====+ 2327 +----------------------+ + | Resend | 2328 +--------------------->+ Wait Bitmap | | Missing | 2329 | +-- + | | Frag | 2330 | not expected wnd | ++=+===+===+===+==+ +======+==+ 2331 | ~~~~~~~~~~~~~~~~ | ^ | | | ^ | 2332 | discard frag +----+ | | | +-------------------+ 2333 | | | | all missing frag sent 2334 |Retrans_Timer expires & | | | ~~~~~~~~~~~~~~~~~~~~~ 2335 | No more Frag | | | Set Retrans_Timer 2336 | ~~~~~~~~~~~~~~~~~~~~~~~ | | | 2337 | Stop Retrans_Timer | | | 2338 | Send ALL-1-empty | | | 2339 +-------------------------+ | | 2340 | | 2341 Local_Bitmap==Recv_Bitmap| | 2342 ~~~~~~~~~~~~~~~~~~~~~~~~~| |Attemp > MAX_ACK_REQUESTS 2343 +=========+Stop Retrans_Timer | |~~~~~~~~~~~~~~~~~~~~~~~ 2344 | END +<------------------+ v Send Abort 2345 +=========+ +=+=========+ 2346 | ERROR | 2347 +===========+ 2349 Figure 36: Sender State Machine for the ACK on error Mode 2351 Not All- & w=expected +---+ +---+w = Not expected 2352 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 2353 Set local_Bitmap(FCN) | v v |discard 2354 ++===+===+===+=+ 2355 +-----------------------+ +--+ All-0 & full 2356 | ABORT *<---+ Rcv Window | | ~~~~~~~~~~~~ 2357 | +--------------------+ +<-+ w =next 2358 | | +===+===+======+ clear lcl_Bitmap 2359 | | | ^ 2360 | | All-0 & w=expect| |w=expct & not-All & full 2361 | | & no_full Bitmap| |~~~~~~~~~~~~~~~~~~~~~~~~ 2362 | | ~~~~~~~~~~~~~~~~~| |clear lcl_Bitmap; w =nxt 2363 | | send local_Bitmap| | 2364 | | | | +========+ 2365 | | | | +---------->+ | 2366 | | | | |w=next | Error/ | 2367 | | | | |~~~~~~~~ | Abort | 2368 | | | | |Send abort ++=======+ 2369 | | v | | ^ w=expct 2370 | | All-0 +=+===+==+======+ | & all-1 2371 | | ~~~~~~~~~~~~~<---+ Wait +------+ ~~~~~~~ 2372 | | send lcl_btmp | Next Window | Send abort 2373 | | +=======+===+==++ 2374 | | All-1 & w=next & MIC wrong | | +---->* ABORT 2375 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | +----------------+ 2376 | | set local_Bitmap(FCN) | All-1 & w=next| 2377 | | send local_Bitmap | & MIC right| 2378 | | | ~~~~~~~~~~~~~~~~~~| 2379 | | | set lcl_Bitmap(FCN)| 2380 | |All-1 & w=expect & MIC wrong | | 2381 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | +-+ All-1 | 2382 | |set local_Bitmap(FCN) v | v ~~~~~~~~~~ | 2383 | |send local_Bitmap +=======+==+===+ snd lcl_btmp| 2384 | +--------------------->+ Wait End +-+ | 2385 | +=====+=+===+=+ | w=expct & | 2386 | w=expected & MIC right | | ^ | MIC wrong | 2387 | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ ~~~~~~~~~ | 2388 | set local_Bitmap(FCN) | | set lcl_Bitmap(FCN)| 2389 | | | | 2390 |All-1 & w=expected & MIC right | +-->* ABORT | 2391 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | 2392 |set local_Bitmap(FCN) +=+==========+ | 2393 +---------------------------->+ END +<----------+ 2394 +============+ 2395 --->* Only Uplink 2396 ABORT 2397 ~~~~~~~~ 2398 Inactivity_Timer = expires 2400 Figure 37: Receiver State Machine for the ACK on error Mode 2402 Appendix D. Allocation of Rule IDs for fragmentation 2404 A set of Rule IDs are allocated to support different aspects of 2405 fragmentation functionality as per this document. The allocation of 2406 IDs is to be defined in other documents. The set MAY include: 2408 o one ID or a subset of IDs to identify a fragment as well as its 2409 reliability option and its window size, if multiple of these are 2410 supported. 2412 o one ID to identify the ACK message. 2414 o one ID to identify the Abort message as per Section 9.8. 2416 Appendix E. Note 2418 Carles Gomez has been funded in part by the Spanish Government 2419 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2420 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2421 Government through project TEC2016-79988-P. Part of his contribution 2422 to this work has been carried out during his stay as a visiting 2423 scholar at the Computer Laboratory of the University of Cambridge. 2425 Authors' Addresses 2427 Ana Minaburo 2428 Acklio 2429 2bis rue de la Chataigneraie 2430 35510 Cesson-Sevigne Cedex 2431 France 2433 Email: ana@ackl.io 2435 Laurent Toutain 2436 IMT-Atlantique 2437 2 rue de la Chataigneraie 2438 CS 17607 2439 35576 Cesson-Sevigne Cedex 2440 France 2442 Email: Laurent.Toutain@imt-atlantique.fr 2443 Carles Gomez 2444 Universitat Politecnica de Catalunya 2445 C/Esteve Terradas, 7 2446 08860 Castelldefels 2447 Spain 2449 Email: carlesgo@entel.upc.edu