idnits 2.17.1 draft-ietf-lpwan-ipv6-static-context-hc-07.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 651: '...ise, the datagram SHALL be broken into...' RFC 2119 keyword, line 679: '...ion, the receiver MUST NOT issue ACKs....' RFC 2119 keyword, line 715: '...liability option MUST be used for all ...' RFC 2119 keyword, line 758: '...al to or greater than 3. The FCN MUST...' RFC 2119 keyword, line 761: '...t fragment), and MUST wrap from 0 back...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1310 has weird spacing: '..._bitmap v |...' -- The document date (October 20, 2017) is 2374 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1903 -- Looks like a reference, but probably isn't: '2' on line 1906 -- Looks like a reference, but probably isn't: '8' on line 1927 -- Looks like a reference, but probably isn't: '4' on line 1934 ** 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: April 23, 2018 IMT-Atlantique 6 C. Gomez 7 Universitat Politecnica de Catalunya 8 October 20, 2017 10 LPWAN Static Context Header Compression (SCHC) and fragmentation for 11 IPv6 and UDP 12 draft-ietf-lpwan-ipv6-static-context-hc-07 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 LPWAN (Low Power Wide Area Network) networks. 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 the packet transmission. The context describes the 25 field values and keeps information that will not be transmitted 26 through the 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 in most cases, IPv6/UDP headers 31 are reduced to a small identifier called Rule ID. Eventhough 32 sometimes, a SCHC compressed packet will not fit in one L2 PDU, and 33 the SCHC fragmentation protocol will be used. The SCHC fragmentation 34 and reassembly mechanism is used in two situations: for SCHC- 35 compressed packets that still exceed the L2 PDU size; and for the 36 case where the SCHC compression cannot be performed. 38 This document describes the SCHC compression/decompression framework 39 and applies it to IPv6/UDP headers. This document also specifies a 40 fragmentation and reassembly mechanism that is used to support the 41 IPv6 MTU requirement over LPWAN technologies. Fragmentation is 42 mandatory for IPv6 datagrams that, after SCHC compression or when it 43 has not been possible to apply such compression, still exceed the L2 44 maximum payload size. Similar solutions for other protocols such as 45 CoAP will be described in separate documents. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on April 23, 2018. 64 Copyright Notice 66 Copyright (c) 2017 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4 83 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 4. Static Context Header Compression . . . . . . . . . . . . . . 7 85 4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.2. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 4.3. Packet processing . . . . . . . . . . . . . . . . . . . . 10 88 4.4. Matching operators . . . . . . . . . . . . . . . . . . . 11 89 4.5. Compression Decompression Actions (CDA) . . . . . . . . . 12 90 4.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 13 91 4.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 13 92 4.5.3. mapping-sent . . . . . . . . . . . . . . . . . . . . 13 93 4.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 13 94 4.5.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . 14 95 4.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 14 96 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 14 97 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 98 5.2. Reliability options . . . . . . . . . . . . . . . . . . . 15 99 5.3. Functionalities . . . . . . . . . . . . . . . . . . . . . 16 100 5.4. Formats . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 5.4.1. Fragment format . . . . . . . . . . . . . . . . . . . 18 102 5.4.2. Fragmentation header formats . . . . . . . . . . . . 18 103 5.4.3. ACK format . . . . . . . . . . . . . . . . . . . . . 19 104 5.4.4. All-1 and All-0 formats . . . . . . . . . . . . . . . 20 105 5.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 21 106 5.6. Supporting multiple window sizes . . . . . . . . . . . . 22 107 5.7. Aborting fragmented datagram transmissions . . . . . . . 23 108 5.8. Downlink fragment transmission . . . . . . . . . . . . . 23 109 5.9. Fragmentation Mode of Operation Description . . . . . . . 23 110 5.9.1. No ACK Mode . . . . . . . . . . . . . . . . . . . . . 23 111 5.9.2. The Window modes . . . . . . . . . . . . . . . . . . 25 112 5.9.3. ACK Always . . . . . . . . . . . . . . . . . . . . . 25 113 5.9.4. ACK on error . . . . . . . . . . . . . . . . . . . . 30 114 6. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 35 115 6.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 35 116 6.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 35 117 6.3. Flow label field . . . . . . . . . . . . . . . . . . . . 35 118 6.4. Payload Length field . . . . . . . . . . . . . . . . . . 36 119 6.5. Next Header field . . . . . . . . . . . . . . . . . . . . 36 120 6.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 36 121 6.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 37 122 6.7.1. IPv6 source and destination prefixes . . . . . . . . 37 123 6.7.2. IPv6 source and destination IID . . . . . . . . . . . 37 124 6.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 38 125 6.9. UDP source and destination port . . . . . . . . . . . . . 38 126 6.10. UDP length field . . . . . . . . . . . . . . . . . . . . 38 127 6.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 39 128 7. Security considerations . . . . . . . . . . . . . . . . . . . 39 129 7.1. Security considerations for header compression . . . . . 39 130 7.2. Security considerations for fragmentation . . . . . . . . 39 131 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 132 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 133 9.1. Normative References . . . . . . . . . . . . . . . . . . 40 134 9.2. Informative References . . . . . . . . . . . . . . . . . 41 135 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 41 136 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 44 137 Appendix C. Allocation of Rule IDs for fragmentation . . . . . . 50 138 Appendix D. Note . . . . . . . . . . . . . . . . . . . . . . . . 51 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 141 1. Introduction 143 Header compression is mandatory to efficiently bring Internet 144 connectivity to the node within a LPWAN network. Some LPWAN networks 145 properties can be exploited to get an efficient header compression: 147 o Topology is star-oriented, therefore all the packets follow the 148 same path. For the needs of this draft, the architecture can be 149 summarized to Devices (Dev) exchanging information with LPWAN 150 Application Server (App) through a Network Gateway (NGW). 152 o Traffic flows are mostly known in advance since devices embed 153 built-in applications. Contrary to computers or smartphones, new 154 applications cannot be easily installed. 156 The Static Context Header Compression (SCHC) is defined for this 157 environment. SCHC uses a context where header information is kept in 158 the header format order. This context is static (the values of the 159 header fields do not change over time) avoiding complex 160 resynchronization mechanisms, incompatible with LPWAN 161 characteristics. In most of the cases, IPv6/UDP headers are reduced 162 to a small context identifier. 164 The SCHC header compression mechanism is independent of the specific 165 LPWAN technology over which it will be used. 167 LPWAN technologies are also characterized, among others, by a very 168 reduced data unit and/or payload size [I-D.ietf-lpwan-overview]. 169 However, some of these technologies do not support layer two 170 fragmentation, therefore the only option for them to support the IPv6 171 MTU requirement of 1280 bytes [RFC2460] is the use of a fragmentation 172 protocol at the adaptation layer below IPv6. This draft defines also 173 a fragmentation functionality to support the IPv6 MTU requirement 174 over LPWAN technologies. Such functionality has been designed under 175 the assumption that data unit reordering will not happen between the 176 entity performing fragmentation and the entity performing reassembly. 178 2. LPWAN Architecture 180 LPWAN technologies have similar architectures but different 181 terminology. We can identify different types of entities in a 182 typical LPWAN network, see Figure 1: 184 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 185 actuators, etc.). There can be a high density of devices per radio 186 gateway. 188 o The Radio Gateway (RG), which is the end point of the constrained 189 link. 191 o The Network Gateway (NGW) is the interconnection node between the 192 Radio Gateway and the Internet. 194 o LPWAN-AAA Server, which controls the user authentication and the 195 applications. We use the term LPWAN-AAA server because we are not 196 assuming that this entity speaks RADIUS or Diameter as many/most AAA 197 servers do, but equally we don't want to rule that out, as the 198 functionality will be similar. 200 o Application Server (App) 202 +------+ 203 () () () | |LPWAN-| 204 () () () () / \ +---------+ | AAA | 205 () () () () () () / \=====| ^ |===|Server| +-----------+ 206 () () () | | <--|--> | +------+ |APPLICATION| 207 () () () () / \==========| v |=============| (App) | 208 () () () / \ +---------+ +-----------+ 209 Dev Radio Gateways NGW 211 Figure 1: LPWAN Architecture 213 3. Terminology 215 This section defines the terminology and acronyms used in this 216 document. 218 o App: LPWAN Application. An application sending/receiving IPv6 219 packets to/from the Device. 221 o APP-IID: Application Interface Identifier. Second part of the 222 IPv6 address to identify the application interface 224 o Bi: Bidirectional, it can be used in both senses 226 o CDA: Compression/Decompression Action. An action that is 227 performed for both functionalities to compress a header field or 228 to recover its original value in the decompression phase. 230 o Context: A set of rules used to compress/decompress headers 232 o Dev: Device. A Node connected to the LPWAN. A Dev may implement 233 SCHC. 235 o Dev-IID: Device Interface Identifier. Second part of the IPv6 236 address to identify the device interface 238 o DI: Direction Indicator is a differentiator for matching in order 239 to be able to have different values for both sides. 241 o DTag: Datagram Tag is a fragmentation header field that is set to 242 the same value for all fragments carrying the same IPv6 datagram. 244 o Dw: Down Link direction for compression, from SCHC C/D to Dev 246 o FCN: Fragment Compressed Number is a fragmentation header field 247 that carries an efficient representation of a larger-sized 248 fragment number. 250 o FID: Field Identifier is an index to describe the header fields in 251 the Rule 253 o FL: Field Length is a value to identify if the field is fixed or 254 variable length. 256 o FP: Field Position is a value that is used to identify each 257 instance a field apears in the header. 259 o IID: Interface Identifier. See the IPv6 addressing architecture 260 [RFC7136] 262 o MIC: Message Integrity Check. A fragmentation header field 263 computed over an IPv6 packet before fragmentation, used for error 264 detection after IPv6 packet reassembly. 266 o MO: Matching Operator. An operator used to match a value 267 contained in a header field with a value contained in a Rule. 269 o Rule: A set of header field values. 271 o Rule ID: An identifier for a rule, SCHC C/D, and Dev share the 272 same Rule ID for a specific flow. A set of Rule IDs are used to 273 support fragmentation functionality. 275 o SCHC C/D: Static Context Header Compression Compressor/ 276 Decompressor. A process in the network to achieve compression/ 277 decompressing headers. SCHC C/D uses SCHC rules to perform 278 compression and decompression. 280 o TV: Target value. A value contained in the Rule that will be 281 matched with the value of a header field. 283 o Up: Up Link direction for compression, from Dev to SCHC C/D. 285 o W: Window bit. A fragmentation header field used in Window mode 286 (see section 9), which carries the same value for all fragments of 287 a window. 289 4. Static Context Header Compression 291 Static Context Header Compression (SCHC) avoids context 292 synchronization, which is the most bandwidth-consuming operation in 293 other header compression mechanisms such as RoHC [RFC5795]. Based on 294 the fact that the nature of data flows is highly predictable in LPWAN 295 networks, some static contexts may be stored on the Device (Dev). 296 The contexts must be stored in both ends, and it can either be 297 learned by a provisioning protocol or by out of band means or it can 298 be pre-provisioned, etc. The way the context is learned on both 299 sides is out of the scope of this document. 301 Dev App 302 +--------------+ +--------------+ 303 |APP1 APP2 APP3| |APP1 APP2 APP3| 304 | | | | 305 | UDP | | UDP | 306 | IPv6 | | IPv6 | 307 | | | | 308 | SCHC C/D | | | 309 | (context) | | | 310 +-------+------+ +-------+------+ 311 | +--+ +----+ +---------+ . 312 +~~ |RG| === |NGW | === |SCHC C/D |... Internet .. 313 +--+ +----+ |(context)| 314 +---------+ 316 Figure 2: Architecture 318 Figure 2 represents the architecture for compression/decompression, 319 it is based on [I-D.ietf-lpwan-overview] terminology. The Device is 320 sending applications flows using IPv6 or IPv6/UDP protocols. These 321 flows are compressed by an Static Context Header Compression 322 Compressor/Decompressor (SCHC C/D) to reduce headers size. The 323 resulting information is sent to a layer two (L2) frame to a LPWAN 324 Radio Network (RG) which forwards the frame to a Network Gateway 325 (NGW). The NGW sends the data to an SCHC C/D for decompression which 326 shares the same rules with the Dev. The SCHC C/D can be located on 327 the Network Gateway (NGW) or in another place as long as a tunnel is 328 established between the NGW and the SCHC C/D. The SCHC C/D in both 329 sides must share the same set of Rules. After decompression, the 330 packet can be sent on the Internet to one or several LPWAN 331 Application Servers (App). 333 The SCHC C/D process is bidirectional, so the same principles can be 334 applied in the other direction. 336 4.1. SCHC Rules 338 The main idea of the SCHC compression scheme is to send the Rule id 339 to the other end instead of sending known field values. This Rule id 340 identifies a rule that matches as much as possible the original 341 packet values. When a value is known by both ends, it is not 342 necessary to send it through the LPWAN network. 344 The context contains a list of rules (cf. Figure 3). Each Rule 345 contains itself a list of fields descriptions composed of a field 346 identifier (FID), a field length (FL), a field position (FP), a 347 direction indicator (DI), a target value (TV), a matching operator 348 (MO) and a Compression/Decompression Action (CDA). 350 /-----------------------------------------------------------------\ 351 | Rule N | 352 /-----------------------------------------------------------------\| 353 | Rule i || 354 /-----------------------------------------------------------------\|| 355 | (FID) Rule 1 ||| 356 |+-------+--+--+--+------------+-----------------+---------------+||| 357 ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 358 |+-------+--+--+--+------------+-----------------+---------------+||| 359 ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| 360 |+-------+--+--+--+------------+-----------------+---------------+||| 361 ||... |..|..|..| ... | ... | ... |||| 362 |+-------+--+--+--+------------+-----------------+---------------+||/ 363 ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| 364 |+-------+--+--+--+------------+-----------------+---------------+|/ 365 | | 366 \-----------------------------------------------------------------/ 368 Figure 3: Compression/Decompression Context 370 The Rule does not describe the original packet format which must be 371 known from the compressor/decompressor. The rule just describes the 372 compression/decompression behavior for the header fields. In the 373 rule, the description of the header field must be performed in the 374 format packet order. 376 The Rule also describes the compressed header fields which are 377 transmitted regarding their position in the rule which is used for 378 data serialization on the compressor side and data deserialization on 379 the decompressor side. 381 The Context describes the header fields and its values with the 382 following entries: 384 o A Field ID (FID) is a unique value to define the header field. 386 o A Field Length (FL) is the length of the field that can be of 387 fixed length as in IPv6 or UDP headers or variable length as in 388 CoAP options. Fixed length fields shall be represented by its 389 actual value in bits. Variable length fields shall be represented 390 by a function or a variable. 392 o A Field Position (FP) indicating if several instances of the field 393 exist in the headers which one is targeted. The default position 394 is 1 396 o A direction indicator (DI) indicating the packet direction. Three 397 values are possible: 399 * UPLINK (Up) when the field or the value is only present in 400 packets sent by the Dev to the App, 402 * DOWNLINK (Dw) when the field or the value is only present in 403 packet sent from the App to the Dev and 405 * BIDIRECTIONAL (Bi) when the field or the value is present 406 either upstream or downstream. 408 o A Target Value (TV) is the value used to make the comparison with 409 the packet header field. The Target Value can be of any type 410 (integer, strings,...). For instance, it can be a single value or 411 a more complex structure (array, list,...), such as a JSON or a 412 CBOR structure. 414 o A Matching Operator (MO) is the operator used to make the 415 comparison between the Field Value and the Target Value. The 416 Matching Operator may require some parameters. MO is only used 417 during the compression phase. 419 o A Compression Decompression Action (CDA) is used to describe the 420 compression and the decompression process. The CDA may require 421 some parameters, CDA are used in both compression and 422 decompression phases. 424 4.2. Rule ID 426 Rule IDs are sent between both compression/decompression elements. 427 The size of the Rule ID is not specified in this document, it is 428 implementation-specific and can vary regarding the LPWAN technology, 429 the number of flows, among others. 431 Some values in the Rule ID space are reserved for other 432 functionalities than header compression as fragmentation. (See 433 Section 5). 435 Rule IDs are specific to a Dev. Two Devs may use the same Rule ID for 436 different header compression. To identify the correct Rule ID, the 437 SCHC C/D needs to combine the Rule ID with the Dev L2 identifier to 438 find the appropriate Rule. 440 4.3. Packet processing 442 The compression/decompression process follows several steps: 444 o compression Rule selection: The goal is to identify which Rule(s) 445 will be used to compress the packet's headers. When doing 446 compression from Dw to Up the SCHC C/D needs to find the correct 447 Rule to be used by identifying its Dev-ID and the Rule-ID. In the 448 Up situation, only the Rule-ID is used. The next step is to 449 choose the fields by their direction, using the direction 450 indicator (DI), so the fields that do not correspond to the 451 appropriated DI will be excluded. Next, then the fields are 452 identified according to their field identifier (FID) and field 453 position (FP). If the field position does not correspond, then 454 the Rule is not used and the SCHC take next Rule. Once the DI and 455 the FP correspond to the header information, each field's value is 456 then compared to the corresponding target value (TV) stored in the 457 Rule for that specific field using the matching operator (MO). If 458 all the fields in the packet's header satisfy all the matching 459 operators (MOs) of a Rule (i.e. all results are True), the fields 460 of the header are then processed according to the Compression/ 461 Decompression Actions (CDAs) and a compressed header is obtained. 462 Otherwise, the next rule is tested. If no eligible rule is found, 463 then the header must be sent without compression, in which case 464 the fragmentation process must be required. 466 o sending: The Rule ID is sent to the other end followed by the 467 information resulting from the compression of header fields, 468 directly followed by the payload. The product of field 469 compression is sent in the order expressed in the Rule for the 470 matching fields. The way the Rule ID is sent depends on the 471 specific LPWAN layer two technology and will be specified in a 472 specific document and is out of the scope of this document. For 473 example, it can be either included in a Layer 2 header or sent in 474 the first byte of the L2 payload. (Cf. Figure 4). 476 o decompression: In both directions, The receiver identifies the 477 sender through its device-id (e.g. MAC address) and selects the 478 appropriate Rule through the Rule ID. This Rule gives the 479 compressed header format and associates these values to the header 480 fields. It applies the CDA action to reconstruct the original 481 header fields. The CDA application order can be different from 482 the order given by the Rule. For instance Compute-* may be 483 applied at the end, after all the other CDAs. 485 If after using SCHC compression and adding the payload to the L2 486 frame the datagram is not multiple of 8 bits, padding may be used. 488 +--- ... --+-------------- ... --------------+-----------+--...--+ 489 | Rule ID |Compressed Hdr Fields information| payload |padding| 490 +--- ... --+-------------- ... --------------+-----------+--...--+ 492 Figure 4: LPWAN Compressed Format Packet 494 4.4. Matching operators 496 Matching Operators (MOs) are functions used by both SCHC C/D 497 endpoints involved in the header compression/decompression. They are 498 not typed and can be applied indifferently to integer, string or any 499 other data type. The result of the operation can either be True or 500 False. MOs are defined as follows: 502 o equal: A field value in a packet matches with a TV in a Rule if 503 they are equal. 505 o ignore: No check is done between a field value in a packet and a 506 TV in the Rule. The result of the matching is always true. 508 o MSB(length): A matching is obtained if the most significant bits 509 of the length field value bits of the header are equal to the TV 510 in the rule. The MSB Matching Operator needs a parameter, 511 indicating the number of bits, to proceed to the matching. 513 o match-mapping: The goal of mapping-sent is to reduce the size of a 514 field by allocating a shorter value. The Target Value contains a 515 list of values. Each value is identified by a short ID (or 516 index). This operator matches if a field value is equal to one of 517 those target values. 519 4.5. Compression Decompression Actions (CDA) 521 The Compression Decompression Action (CDA) describes the actions 522 taken during the compression of headers fields, and inversely, the 523 action taken by the decompressor to restore the original value. 525 /--------------------+-------------+----------------------------\ 526 | Action | Compression | Decompression | 527 | | | | 528 +--------------------+-------------+----------------------------+ 529 |not-sent |elided |use value stored in ctxt | 530 |value-sent |send |build from received value | 531 |mapping-sent |send index |value from index on a table | 532 |LSB(length) |send LSB |TV OR received value | 533 |compute-length |elided |compute length | 534 |compute-checksum |elided |compute UDP checksum | 535 |Deviid |elided |build IID from L2 Dev addr | 536 |Appiid |elided |build IID from L2 App addr | 537 \--------------------+-------------+----------------------------/ 539 Figure 5: Compression and Decompression Functions 541 Figure 5 summarizes the basics functions defined to compress and 542 decompress a field. The first column gives the action's name. The 543 second and third columns outline the compression/decompression 544 behavior. 546 Compression is done in the rule order and compressed values are sent 547 in that order in the compressed message. The receiver must be able 548 to find the size of each compressed field which can be given by the 549 rule or may be sent with the compressed header. 551 If the field is identified as being variable, then its size must be 552 sent first using the following coding: 554 o If the size is between 0 and 14 bytes it is sent using 4 bits. 556 o For values between 15 and 255, the first 4 bits sent are set to 1 557 and the size is sent using 8 bits. 559 o For higher value, the first 12 bits are set to 1 and the size is 560 sent on 2 bytes. 562 4.5.1. not-sent CDA 564 The not-sent function is generally used when the field value is 565 specified in the rule and therefore known by the both Compressor and 566 Decompressor. This action is generally used with the "equal" MO. If 567 MO is "ignore", there is a risk to have a decompressed field value 568 different from the compressed field. 570 The compressor does not send any value in the compressed header for 571 the field on which compression is applied. 573 The decompressor restores the field value with the target value 574 stored in the matched rule. 576 4.5.2. value-sent CDA 578 The value-sent action is generally used when the field value is not 579 known by both Compressor and Decompressor. The value is sent in the 580 compressed message header. Both Compressor and Decompressor must 581 know the size of the field, either implicitly (the size is known by 582 both sides) or explicitly in the compressed header field by 583 indicating the length. This function is generally used with the 584 "ignore" MO. 586 4.5.3. mapping-sent 588 mapping-sent is used to send a smaller index associated with the list 589 of values in the Target Value. This function is used together with 590 the "match-mapping" MO. 592 The compressor looks on the TV to find the field value and send the 593 corresponding index. The decompressor uses this index to restore the 594 field value. 596 The number of bits sent is the minimal size for coding all the 597 possible indexes. 599 4.5.4. LSB CDA 601 LSB action is used to avoid sending the known part of the packet 602 field header to the other end. This action is used together with the 603 "MSB" MO. A length can be specified in the rule to indicate how many 604 bits have to be sent. If the length is not specified, the number of 605 bits sent is the field length minus the bits length specified in the 606 MSB MO. 608 The compressor sends the "length" Least Significant Bits. The 609 decompressor combines the value received with the Target Value. 611 If this action is made on a variable length field, the remaining size 612 in byte has to be sent before. 614 4.5.5. DEViid, APPiid CDA 616 These functions are used to process respectively the Dev and the App 617 Interface Identifiers (Deviid and Appiid) of the IPv6 addresses. 618 Appiid CDA is less common since current LPWAN technologies frames 619 contain a single address. 621 The IID value may be computed from the Device ID present in the Layer 622 2 header. The computation is specific for each LPWAN technology and 623 may depend on the Device ID size. 625 In the downstream direction, these CDA may be used to determine the 626 L2 addresses used by the LPWAN. 628 4.5.6. Compute-* 630 These classes of functions are used by the decompressor to compute 631 the compressed field value based on received information. Compressed 632 fields are elided during compression and reconstructed during 633 decompression. 635 o compute-length: compute the length assigned to this field. For 636 instance, regarding the field ID, this CDA may be used to compute 637 IPv6 length or UDP length. 639 o compute-checksum: compute a checksum from the information already 640 received by the SCHC C/D. This field may be used to compute UDP 641 checksum. 643 5. Fragmentation 645 5.1. Overview 647 In LPWAN technologies, the L2 data unit size typically varies from 648 tens to hundreds of bytes. If the entire IPv6 datagram after 649 applying SCHC header compression or when SCHC is not possible, fits 650 within a single L2 data unit, the fragmentation mechanism is not used 651 and the packet is sent. Otherwise, the datagram SHALL be broken into 652 fragments. 654 LPWAN technologies impose some strict limitations on traffic, devices 655 are sleeping most of the time and may receive data during a short 656 period of time after transmission to preserve battery. To adapt the 657 SCHC fragmentation to the capabilities of LPWAN technologies, it is 658 desirable to enable optional fragment retransmission and to allow a 659 gradation of fragment delivery reliability. This document does not 660 make any decision with regard to which fragment delivery reliability 661 option may be used over a specific LPWAN technology. 663 An important consideration is that LPWAN networks typically follow 664 the star topology, and therefore data unit reordering is not expected 665 in such networks. This specification assumes that reordering will 666 not happen between the entity performing fragmentation and the entity 667 performing reassembly. This assumption allows to reduce complexity 668 and overhead of the fragmentation mechanism. 670 5.2. Reliability options 672 This specification defines the following three fragment delivery 673 reliability options: 675 o No ACK. No ACK is the simplest fragment delivery reliability 676 option. The receiver does not generate overhead in the form of 677 acknowledgments (ACKs). However, this option does not enhance 678 delivery reliability beyond that offered by the underlying LPWAN 679 technology. In the No ACK option, the receiver MUST NOT issue ACKs. 681 o Window mode - ACK always (ACK-always). 682 The ACK-always option provides flow control. In addition, it is able 683 to handle long bursts of lost fragments, since detection of such 684 events can be done before the end of the IPv6 packet transmission, as 685 long as the window size is short enough. However, such benefit comes 686 at the expense of ACK use. In ACK-always, an ACK is transmitted by 687 the fragment receiver after a window of fragments have been sent. A 688 window of fragments is a subset of the full set of fragments needed 689 to carry an IPv6 packet. In this mode, the ACK informs the sender 690 about received and/or missed fragments from the window of fragments. 691 Upon receipt of an ACK that informs about any lost fragments, the 692 sender retransmits the lost fragments. When an ACK is not received 693 by the fragment sender, the latter retransmits an all-1 empty 694 fragment, which serves as an ACK request. The maximum number of ACK 695 requests is MAX_ACK_REQUESTS. The default value of MAX_ACK_REQUESTS 696 is not stated in this document, and it is expected to be defined in 697 other documents (e.g. technology- specific profiles). 699 o Window mode - ACK-on-error. The ACK-on-error option is suitable 700 for links offering relatively low L2 data unit loss probability. 701 This option reduces the number of ACKs transmitted by the fragment 702 receiver. This may be especially beneficial in asymmetric scenarios, 703 e.g. where fragmented data are sent uplink and the underlying LPWAN 704 technology downlink capacity or message rate is lower than the uplink 705 one. However, if an ACK is lost, the sender assumes that all 706 fragments covered by the ACK have been successfully delivered. And 707 the receiver will abort the fragmentation. 708 In ACK-on-error, an ACK is transmitted by the fragment receiver after 709 a window of fragments has been sent, only if at least one of the 710 fragments in the window has been lost. In this mode, the ACK informs 711 the sender about received and/or missed fragments from the window of 712 fragments. Upon receipt of an ACK that informs about any lost 713 fragments, the sender retransmits the lost fragments. 715 The same reliability option MUST be used for all fragments of a 716 packet. It is up to implementers and/or representatives of the 717 underlying LPWAN technology to decide which reliability option to use 718 and whether the same reliability option applies to all IPv6 packets 719 or not. Note that the reliability option to be used is not 720 necessarily tied to the particular characteristics of the underlying 721 L2 LPWAN technology (e.g. the No ACK reliability option may be used 722 on top of an L2 LPWAN technology with symmetric characteristics for 723 uplink and downlink). 724 This document does not make any decision as to which fragment 725 delivery reliability option(s) are supported by a specific LPWAN 726 technology. 728 Examples of the different reliability options described are provided 729 in Appendix A. 731 5.3. Functionalities 733 This subsection describes the different fields in the fragmentation 734 header that are used to enable the described fragmentation 735 functionalities and the different reliability options supported. 737 o Rule ID. The Rule ID in the fragmentation part is used to identify 738 the fragmentation mode used, also to idenitfy fragments from ACK and 739 Abort frames. The also allows to interleave non-fragmented IPv6 740 datagrams with fragments that carry a larger IPv6 datagram. In the 741 fragments format this field has a size of R - T - N - 1 bits when 742 Window mode is used. In No ACK mode, the Rule ID field has a size of 743 R - T - N bits see format section. 745 o Fragment Compressed Number (FCN). The FCN is included in all 746 fragments. This field can be understood as a truncated, efficient 747 representation of a larger-sized fragment number, and does not carry 748 an absolute fragment number. There are two reserved values used for 749 the control of the fragmentation. The FCN value when all the bits 750 equals 1 (all-1) denotes the last fragment of a packet. And the FCN 751 value when all the bits equals 0 (all-0) denotes the last fragment of 752 the windonw in any window mode or the fragments in No ACK mode. The 753 rest of the FCN values are used in a sequential and decreasing order, 754 which has the purpose to avoid possible ambiguity for the receiver 755 that might arise under certain conditions. In the fragments, this 756 field is an unsigned integer, with a size of N bits. In the No ACK 757 mode it is set to 1 bit (N=1). For the other modes it is recommended 758 to use a number of bits (N) equal to or greater than 3. The FCN MUST 759 be set sequentially 760 decreasing from the highest FCN in the window (which will be used for 761 the first fragment), and MUST wrap from 0 back to the highest FCN in 762 the window. 763 The FCN for the last fragment in a window is an all-0, which 764 indicates that the window is finished and it proceeds according to 765 the mode in use: either an ack is sent or the next window fragments 766 are expected when there is no error. The FCN for the last fragment 767 is an all-1. It is also important to note that, for No ACK mode or 768 N=1, the last fragment of the packet will carry a FCN equal to 1, 769 while all previous fragments will carry a FCN of 0. 771 o Datagram Tag (DTag). The DTag field, if present, is set to the 772 same value for all fragments carrying the same IPv6 datagram, allows 773 to interleave fragments that correspond to different IPv6 datagrams. 774 In the fragment formats the size of the DTag field is T bits, which 775 may be set to a value greater than or equal to 0 bits. DTag MUST be 776 set sequentially increasing from 0 to 2^T - 1, and MUST wrap back 777 from 2^T - 1 to 0. In the ACK format, DTag carries the same value as 778 the DTag field in the fragments for which this ACK is intended. 780 o W (window): W is a 1-bit field. This field carries the same value 781 for all fragments of a window, and it is complemented for the next 782 window. The initial value for this field is 0. In the ACK format, 783 this field has a size of 1 bit. In all ACKs, the W bit carries the 784 same value as the W bit carried by the fragments whose reception is 785 being positively or negatively acknowledged by the ACK. 787 o Message Integrity Check (MIC). This field, which has a size of M 788 bits. It is computed by the sender over the complete packet (i.e. a 789 SCHC compressed or an uncompressed IPv6 packet) before fragmentation. 790 The algorithm to be used to compute the MIC is not defined in this 791 document, and needs to be defined in other documents (e.g. 792 technology-specific profiles). The MIC allows the receiver to check 793 errors in the reassembled packet, while it also enables compressing 794 the UDP checksum by use of SCHC compression. 796 o Bitmap. The bitmap is a sequence of bits included in the ACK for a 797 given window, each bit in the Bitmap identifies a fragment. It 798 provides feedback on whether each fragment of the current window has 799 been received or not. FCN set to All-0 and All-1 fragments are set 800 to the right-most position on the bitmap in this order. Highest FCN 801 is set to the left-most position. A bit set to 1 indicates that the 802 corresponding FCN fragment has been correctly sent and received. 803 TODO (it is missing to explain the optimization of bitmap in order to 804 have a way to send an abort) 806 5.4. Formats 808 This section defines the fragment format, the fragmentation header 809 formats, and the ACK format. 811 5.4.1. Fragment format 813 A fragment comprises a fragmentation header and a fragment payload, 814 and conforms to the format shown in Figure 6. The fragment payload 815 carries a subset of either a SCHC header or an IPv6 header or the 816 original IPv6 packet payload which could not be compressed. A 817 fragment is the payload in the L2 protocol data unit (PDU). 819 +---------------+-----------------------+ 820 | Fragm. Header | Fragment payload | 821 +---------------+-----------------------+ 823 Figure 6: Fragment format. 825 5.4.2. Fragmentation header formats 827 In the No ACK option, fragments except the last one SHALL contain the 828 fragmentation header as defined in Figure 7. The total size of this 829 fragmentation header is R bits. 831 <------------ R ----------> 832 <--T--> <--N--> 833 +-- ... --+- ... -+- ... -+---...---+ 834 | Rule ID | DTag | FCN | payload | 835 +-- ... --+- ... -+- ... -+---...---+ 837 Figure 7: Fragmentation Header for Fragments except the Last One, No 838 ACK option 840 In any of the Window mode options, fragments except the last one 841 SHALL contain the fragmentation header as defined in Figure 8. The 842 total size of this fragmentation header is R bits. 844 <------------ R ----------> 845 <--T--> 1 <--N--> 846 +-- ... --+- ... -+-+- ... -+---...---+ 847 | Rule ID | DTag |W| FCN | payload | 848 +-- ... --+- ... -+-+- ... -+---...---+ 850 Figure 8: Fragmentation Header for Fragments except the Last One, 851 Window mode 853 5.4.3. ACK format 855 The format of an ACK is shown in Figure 9: 857 <-------- R -------> 858 <- T -> 1 859 +---- ... --+-... -+-+----- ... ---+ 860 | Rule ID | DTag |W| bitmap | 861 +---- ... --+-... -+-+----- ... ---+ 863 Figure 9: Format of an ACK 865 Figure 10 shows an example of an ACK (N=3), where the bitmap 866 indicates that the second and the fifth fragments have not been 867 correctly received. 869 <------- R -------> 870 <- T -> 1 6 5 4 3 2 1 0 871 +---- ... --+-... -+-+-+-+-+-+-+-+-----+ 872 | Rule ID | DTag |W|1|0|1|1|0|1|all-0| TODO 873 +---- ... --+-... -+-+-+-+-+-+-+-+-----+ 875 Figure 10: Example of the bitmap in Window mode, in any window unless 876 the last one, for N=3) 878 <------- R -------> 879 <- T -> 1 6 5 4 3 2 1 7 880 +---- ... --+-... -+-+-+-+-+-+-+-+-----+ 881 | Rule ID | DTag |W|1|0|1|1|0|1|all-1| TODO 882 +---- ... --+-... -+-+-+-+-+-+-+-+-----+ 884 Figure 11: Example of the bitmap in Window mode for the last window, 885 for N=3) 887 5.4.4. All-1 and All-0 formats 889 <------------ R ------------> 890 <- T -> 1 <- N -> 891 +-- ... --+- ... -+-+- ... -+--- ... ---+ 892 | Rule ID | DTag |W| 0..0 | payload | TODO 893 +-- ... --+- ... -+-+- ... -+--- ... ---+ 895 Figure 12: All-0 format fragment 897 In the No ACK option, the last fragment of an IPv6 datagram SHALL 898 contain a fragmentation header that conforms to the format shown in 899 Figure 14. The total size of this fragmentation header is R+M bits. 901 <------------ R ------------> 902 <- T -> 1 <- N -> 903 +-- ... --+- ... -+-+- ... -+ 904 | Rule ID | DTag |W| 0..0 | TODO 905 +-- ... --+- ... -+-+- ... -+ 907 Figure 13: All-0 empty format fragment 909 <------------- R ----------> 910 <- T -> <-N-><----- M -----> 911 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 912 | Rule ID | DTag | 1 | MIC | payload | 913 +---- ... ---+- ... -+-----+---- ... ----+---...---+ 915 Figure 14: All-1 Fragmentation Header for the Last Fragment, No ACK 916 option 918 In any of the Window modes, the last fragment of an IPv6 datagram 919 SHALL contain a fragmentation header that conforms to the format 920 shown in Figure 15. The total size of this fragmentation header is 921 R+M bits. It is used for retransmissions 923 <------------ R ------------> 924 <- T -> 1 <- N -> <---- M -----> 925 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 926 | Rule ID | DTag |W| 11..1 | MIC | payload | 927 +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+ 928 (FCN) 930 Figure 15: All-1 Fragmentation Header for the Last Fragment, Window 931 mode 933 The values for R, N, T and M are not specified in this document, and 934 have to be determined in other documents (e.g. technology-specific 935 profile documents). 937 <------------ R ------------> 938 <- T -> 1 <- N -> <---- M -----> 939 +-- ... --+- ... -+-+- ... -+---- ... ----+ 940 | Rule ID | DTag |W| 1..1 | MIC | (no payload) TODO 941 +-- ... --+- ... -+-+- ... -+---- ... ----+ 943 Figure 16: All-1 for Retries format fragment also called All-1 empty 945 <------------ R ------------> 946 <- T -> 1 <- N -> 947 +-- ... --+- ... -+-+- ... -+ 948 | Rule ID | DTag |W| 11..1 | (no MIC and no payload) TODO 949 +-- ... --+- ... -+-+- ... -+ 951 Figure 17: All-1 for Abort format fragment 953 <----- Complete Byte ------><--- 1 byte ---> 954 <------- R -------> 955 <- T -> 1 956 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Rule ID | DTag |W| 1..1| FF | TODO 958 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+ 960 Figure 18: ACK Abort format fragment 962 5.5. Baseline mechanism 964 The receiver needs to identify all the fragments that belong to a 965 given IPv6 datagram. To this end, the receiver SHALL use: * The 966 sender's L2 source address (if present), * The destination's L2 967 address (if present), * Rule ID and * DTag (the latter, if present). 968 Then, the fragment receiver may determine the fragment delivery 969 reliability option that is used for this fragment based on the Rule 970 ID field in that fragment. 972 Upon receipt of a link fragment, the receiver starts constructing the 973 original unfragmented packet. It uses the FCN and the order of 974 arrival of each fragment to determine the location of the individual 975 fragments within the original unfragmented packet. A fragment 976 payload may carry bytes from a SCHC compressed IPv6 header, an 977 uncompressed IPv6 header or an IPv6 datagram data payload. An 978 unfragmented packet could be a SCHC compressed or an uncompressed 979 IPv6 packet (header and data). For example, the receiver may place 980 the fragment payload within a payload datagram reassembly buffer at 981 the location determined from: the FCN, the arrival order of the 982 fragments, and the fragment payload sizes. In Window mode, the 983 fragment receiver also uses the W bit in the received fragments. 984 Note that the size of the original, unfragmented packet cannot be 985 determined from fragmentation headers. 987 Note that, in Window mode, the first fragment of the window is the 988 one with FCN set to MAX_WIND_FCN. Also note that, in Window mode, 989 the fragment with all-0 is considered the last fragment of its 990 window, except for the last fragment of the whole packet (all-1), 991 which is also the last fragment of the last window. 993 If the recipient receives the last fragment of a datagram (all-1), it 994 checks for the integrity of the reassembled datagram, based on the 995 MIC received. In No ACK, if the integrity check indicates that the 996 reassembled datagram does not match the original datagram (prior to 997 fragmentation), the reassembled datagram MUST be discarded. In 998 Window mode, a MIC check is also performed by the fragment receiver 999 after reception of each subsequent fragment retransmitted after the 1000 first MIC check. In ACK always, if a MIC check indicates that the 1001 datagram has been successfully reassembled, the fragment receiver 1002 sends an ACK without a bitmap to the fragment sender. 1004 If a fragment recipient disassociates from its L2 network, the 1005 recipient MUST discard all link fragments of all partially 1006 reassembled payload datagrams, and fragment senders MUST discard all 1007 not yet transmitted link fragments of all partially transmitted 1008 payload (e.g., IPv6) datagrams. Similarly, when either end of the 1009 LPWAN link first receives a fragment of a packet, it starts a 1010 reassembly timer. When this time expires, if the entire packet has 1011 not been reassembled, the existing fragments MUST be discarded and 1012 the reassembly state MUST be flushed. The value for this timer is 1013 not provided by this specification, and is expected to be defined in 1014 technology-specific profile documents. 1016 TODO (explain the Bitmap optimization) 1018 5.6. Supporting multiple window sizes 1020 For Window mode operation, implementers may opt to support a single 1021 window size or multiple window sizes. The latter, when feasible, may 1022 provide performance optimizations. For example, a large window size 1023 may be used for packets that need to be carried by a large number of 1024 fragments. However, when the number of fragments required to carry 1025 an packet is low, a smaller window size, and thus a shorter bitmap, 1026 may be sufficient to provide feedback on all fragments. If multiple 1027 window sizes are supported, the Rule ID may be used to signal the 1028 window size in use for a specific packet transmission. 1030 TODO (does it works for ACK-on-error?) 1032 5.7. Aborting fragmented datagram transmissions 1034 For several reasons, a fragment sender or a fragment receiver may 1035 want to abort the on-going transmission of one or several fragmented 1036 IPv6 datagrams. 1038 TODO (explain the abort format packets) 1040 Upon transmission or reception of the abortion signal, both entities 1041 MUST release any resources allocated for the fragmented datagram 1042 transmissions being aborted. 1044 5.8. Downlink fragment transmission 1046 In some LPWAN technologies, as part of energy-saving techniques, 1047 downlink transmission is only possible immediately after an uplink 1048 transmission. In order to avoid potentially high delay for 1049 fragmented datagram transmission in the downlink, the fragment 1050 receiver MAY perform an uplink transmission as soon as possible after 1051 reception of a fragment that is not the last one. Such uplink 1052 transmission may be triggered by the L2 (e.g. an L2 ACK sent in 1053 response to a fragment encapsulated in a L2 frame that requires an L2 1054 ACK) or it may be triggered from an upper layer. 1056 5.9. Fragmentation Mode of Operation Description 1058 The fragmentation is based on the FCN value, which has a length of N 1059 bits. The All-1 and All-0 values are reserved, and are used to 1060 control the fragmentation transmission. The FCN will be sent in 1061 downwards position this means from larger to smaller and the number 1062 of bits depends on the implementation. The last fragment in all 1063 modes must contains a MIC which is used to check if there are error 1064 or missing fragments. 1066 5.9.1. No ACK Mode 1068 In the No ACK mode there is no feedback communication. The sender 1069 will send the fragments until the last one whithout any possibility 1070 to know if there were an error or lost. As there is not any control 1071 one bit FCN is used, where FCN all-0 will be sent for all the 1072 fragments except the last one which will use FCN to all-1 and will 1073 send the MIC. Figure 19 shows the state machine for the sender. 1075 +-----------+ 1076 +------------+ Init | 1077 | FCN=0 +-----------+ 1078 | No Window 1079 | No Bitmap 1080 | +-------+ 1081 | +--------+--+ | More Fragments 1082 | | | <--+ ~~~~~~~~~~~~~~~~~~~~ 1083 +--------> | Send | send Fragment (FCN=0) 1084 +---+-------+ 1085 | last fragment 1086 | ~~~~~~~~~~~~ 1087 | FCN = 1 1088 v send fragment+MIC 1089 +------------+ 1090 | END | 1091 +------------+ 1093 Figure 19: Sender State Machine for the No ACK Mode 1095 The receiver waits for fragments and will set a timer in order to see 1096 if there is no missing fragments. The No ACK mode will use the MIC 1097 contained in the last fragment to check error. The FCN is set to 1098 all-1 for the last fragment. Figure 20 shows the state machine for 1099 the receiver. When the Timer expires or when the check of MIC gives 1100 an error it will abort the communication and go to error state, all 1101 the fragments will be dropped. The Inactivity Timer will be based on 1102 the LPWAN technology and will be defined in the specific technology 1103 document. 1105 +------+ Not All-1 1106 +----------+-+ | ~~~~~~~~~~~~~~~~~~~ 1107 | + <--+ set Inactivity Timer 1108 | RCV Frag +-------+ 1109 +-+---+------+ |All-1 & 1110 All-1 & | | |MIC correct 1111 MIC wrong | |Inactivity | 1112 | |Timer Exp. | 1113 v | | 1114 +----------++ | v 1115 | Error |<-+ +--------+--+ 1116 +-----------+ | END | 1117 +-----------+ 1119 Figure 20: Receiver State Machine for the No ACK Mode 1121 5.9.2. The Window modes 1123 The jumping window protocol is using two windows alternatively 0 and 1124 1. The FCN to all-0 fragment means that the window is over and 1125 allows to switch from one window to another. The FCN to all-1 1126 fragment indicates that it is the last fragment and there will not be 1127 another window. 1129 In all the cases, the sender may not have to send all the fragments 1130 contained in the window. To ease FN (fragment number) reconstruction 1131 from FCN, it is recommended to send sequentially all the fragments on 1132 a window and for all non-terminating window to fill entirely the 1133 window. 1135 The receiver generates the bitmap which may have the size of a single 1136 frame based on the size of downlink frame of the LPWAN technology 1137 used. When the bitmap cannot be sent in one frame or for the last 1138 window, 1140 , then first the FCN should be set to the lowest possible value. 1142 The Window mode has two different mode of operation: The ACK on error 1143 and the ACK always. 1145 5.9.3. ACK Always 1147 The Figure 21 finite state machine describes the sender behavior. 1148 Intially, when a fragmented packet need to be sent, the window is set 1149 to 0, a local_bit map is set to 0, and FCN is set the the highest 1150 possible value depending on the number of fragment that will be sent 1151 in the window (INIT STATE). 1153 The sender starts sending fragments (SEND STATE), the sender will 1154 indicate in the fragmentation header: the current window and the FCN 1155 number. A delay between each fragment can be added to respect 1156 regulation rules or constraints imposed by the applications. Each 1157 time a fragment is sent the FCN is decreased of one value and the 1158 bitmap is set. The send state can be leaved for different reasons 1159 (for both reasons it goes to WAIT BITMAP STATE): 1161 o The FCN reaches value 0 and there are more fragments. In that 1162 case an all-0 fragmet is sent and the timer is set. The sender 1163 will wait for the bitmap acknowledged by the receiver. 1165 o The last fragment is sent. In that case an all-1 fragment with 1166 the MIC is sent and the sender will wait for the bitmap 1167 acknowledged by the receiver. The sender set a timer to wait for 1168 the ack. 1170 During the transition between the SEND state of the current window 1171 and the WAIT BITMAP, the sender start listening to the radio and 1172 start a timer. This timer is dimensioned to the receiving window 1173 depending on the LPWAN technology. 1175 In ACK Always, if the timer expire, an empty All-0 (or All-1 if the 1176 last fragment has been sent) fragment is sent to ask the receiver to 1177 resent its bitmap. The window number is not changed. 1179 The sender receives a bitmap, it checks the window value. 1180 Acknowledgment with the non expected window are discarded. 1182 If the window number on the received bitmap is correct, the sender 1183 compares the local bitmap with the received bitmap. If they are 1184 equal all the fragments sent during the window have been well 1185 received. If at least one fragment need to be sent, the sender clear 1186 the bitmap, stop the timer and move its sending window to the next 1187 value. If no more fragments have to be sent, then the fragmented 1188 packet transmission is terminated. 1190 If some fragments are missing (not set in the bit map) then the 1191 sender resend the missing fragments. When the retransmission is 1192 finished, it start listening to the bitmap (even if a All-0 or All-1 1193 has not been sent during the retransmission) and returns to the 1194 waiting bitmap state. 1196 If the local-bitmap is different from the received bitmap the counter 1197 Attemps is increased and the sender resend the missing fragments 1198 again, when a MAX_ATTEMPS is reached the sender sends an Abort and 1199 goes to error. 1201 +-------+ 1202 | INIT | FCN!=0 & more frags 1203 | | ~~~~~~~~~~~~~~~~~~~~~~ 1204 +------++ +--+ send Window + frag(FCN) 1205 W=0 | | | FCN- 1206 Clear local bitmap | | v set local bitmap 1207 FCN=max value | ++--+--------+ 1208 +> | | 1209 +---------------------> | SEND | 1210 | +--+-----+---+ 1211 | FCN==0 & more frags | | last frag 1212 | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ 1213 | set local-bitmap | | set local-bitmap 1214 | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC 1215 | set Timer | | set Timer 1216 | | | 1217 |Recv_wnd == wnd & | | 1218 |Lcl_bitmap==recv_bitmap& | | +-------------------------+ 1219 |more frag | | |local-bitmap!=rcv-bitmap | 1220 |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | 1221 |Stop Timer | | | Attemp++ v 1222 |clear local_bitmap v v | +------++ 1223 |window=next_window +----+-----+--+--+ |Resend | 1224 +---------------------+ | |Missing| 1225 +----+ Wait | |Frag | 1226 not expected wnd | | bitmap | +------++ 1227 ~~~~~~~~~~~~~~~~ +--->+ +---+ Timer Exp | 1228 discard frag +--+---+---+---+-+ |~~~~~~~~~~~~~~~~~ | 1229 | | ^ ^ |Snd(empty)frag(0) | 1230 | | | | |Set Timer | 1231 | | | +-----+ | 1232 Recv_window==window & | | +----------------------------+ 1233 Lcl_bitmap==recv_bitmap &| | all missing frag sent 1234 no more frag| | ~~~~~~~~~~~~~~~~~~~~~~ 1235 ~~~~~~~~~~~~~~~~~~~~~~~~| | Set Timer 1236 Stop Timer| | 1237 +-------------+ | | 1238 | +<----+ | MAX_ATTEMPS > limit 1239 | END | | ~~~~~~~~~~~~~~~~~~ 1240 | | v Send Abort 1241 +-------------+ +-+-----------+ 1242 | ERROR | 1243 +-------------+ 1245 Figure 21: Sender State Machine for the ACK Always Mode 1247 The Figure 22 finite state machine describes the receiver behavior. 1248 The receiver starts with window 0 as the expecting window and 1249 maintain a local_bitmap indicating which fragments it has received 1250 (all-0 and all-1 occupy the same position). 1252 Any fragment not belonging to the current window is discarded. 1253 Fragment belonging to the correct window are accepted, FN is computed 1254 based on the FCN value. The receiver leaves this state when 1255 receiving a: 1257 o All-0 fragment which indicates that all the fragments have been 1258 sent in the current window. Since the sender is not obliged to 1259 send a full window, some fragment number not set in the 1260 local_bitmap may not correspond to losses. 1262 o All-1 fragment which indicated that the transmission is finished. 1263 Since the last window is not full, the MIC will be used to detect 1264 if all the fragments have been received. 1266 A correct MIC indicates the end of the transmission. The receiver 1267 must stay in this state during a period of time to answer to empty 1268 all-1 frag the sender may send if the bitmap is lost. 1270 If All-1 frag has not been received, the receiver expect a new 1271 window. It waits for the next fragment. If the window value has not 1272 changed, the received fragments are part of a retransmission. A 1273 receiver that has already received a frag should discard it (not 1274 represented in the state machine), otherwise it completes its bitmap. 1275 If all the bit of the bitmap are set to one, the receiver may send a 1276 bitmap without waiting for a all-0 frag. 1278 If the window value is set to the next value, this means that the 1279 sender has received a correct bitmap, which means that all the 1280 fragments have been received. The receiver change the value of the 1281 expected window. 1283 If the receiver receives an all-0 fragment, it stays in the same 1284 state. Sender may send more one fragment per window or more. 1285 Otherwise some fragments in the window have been lost. 1287 If the receiver receives an all-1 fragment this means that the 1288 transmission should be finished. If the MIC is incorrect some 1289 fragments have been lost. It sends its bitmap. 1291 In case of an incorrect MIC, the receivers wait for fragment 1292 belonging to the same window. 1294 Not All- & w=expected +---+ +---+w = Not expected 1295 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 1296 Set local_bitmap(FCN) | v v |discard 1297 ++---+---+---+-+ 1298 +---------------------+ Rcv | 1299 | +------------------+ Window | 1300 | | +-----+--+-----+ 1301 | | All-0 & w=expect | ^ w =next & not-All 1302 | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ 1303 | | set lcl_bitmap(FCN)| |expected = next window 1304 | | send local_bitmap | |Clear local_bitmap 1305 | | | | 1306 | | w=expct & not-All | | 1307 | | ~~~~~~~~~~~~~~~~~~ | | 1308 | | set lcl_bitmap(FCN)+-+ | | +--+ w=next & All-0 1309 | | if lcl_bitmap full | | | | | | ~~~~~~~~~~~~~~~ 1310 | | send lcl_bitmap v | v | | | expct = nxt wnd 1311 | | +-+-+-+--+-++ | Clear lcl_bitmap 1312 | | w=expected & +->+ Wait +<+ set lcl_bitmap(FCN) 1313 | | All-1 | | Next | send lcl_bitmap 1314 | | ~~~~~~~~~~~~ +--+ Window | 1315 | | discard +--------+-++ 1316 | | All-1 & w=next| | All-1 & w=nxt 1317 | | & MIC wrong| | & MIC right 1318 | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ 1319 | | set local_bitmap(FCN)| |set lcl_bitmap(FCN) 1320 | | send local_bitmap| |send local_bitmap 1321 | | | +----------------------+ 1322 | |All-1 & w=expct | | 1323 | |& MIC wrong v +---+ w=expctd & | 1324 | |~~~~~~~~~~~~~~~~~~~~ +----+---+-+ | MIC wrong | 1325 | |set local_bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ | 1326 | |send local_bitmap | Wait End | set lcl_btmp(FCN)| 1327 | +--------------------->+ | | 1328 | +---+----+-+ | 1329 | w=expected & MIC right| | 1330 | ~~~~~~~~~~~~~~~~~~~~~~| +-+ Not All-1 | 1331 | set local_bitmap(FCN)| | | ~~~~~~~~~ | 1332 | send local_bitmap| | | discard | 1333 | | | | | 1334 |All-1 & w=expctd & MIC right | | | +-+ All-1 | 1335 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v | v ~~~~~~~~~ | 1336 |set local_bitmap(FCN) +-+-+-+-+-++Send lcl_btmp | 1337 |send local_bitmap | | | 1338 +-------------------------->+ END +<---------------+ 1339 ++--+------+ 1341 Figure 22: Receiver State Machine for the ACK Always Mode 1343 5.9.4. ACK on error 1345 The ACK on error sender is very similar to the ACK always sender, 1346 Intially, when a fragmented packet is sent, the window is set to 0, a 1347 local_bit map is set to 0, and FCN is set the highest possible value 1348 depending on the number of fragment that will be sent in the window. 1349 See Figure 23 1351 The sender starts sending fragments indicating in the fragmentation 1352 header with the current window and the FCN number. A delay between 1353 each fragment can be added to respect regulation rules or constraints 1354 imposed by the applications. This state can be leaved for different 1355 reasons: 1357 o The FCN reaches value 0. In that case a all-0 fragmet is sent and 1358 the sender will wait for the bitmap acknowledged by the receiver. 1360 o The last fragment is sent. In that case a all-1 fragment is sent 1361 and the sender will wait for the bitmap acknowledged by the 1362 receiver. 1364 During the transition between the sending the fragment of the current 1365 window and waiting for bitmap, the sender start listening to the 1366 radio and start a timer. This timer is dimensioned to the receiving 1367 window depending on the LPWAN technology. 1369 In Ack on error mode, the timer expiration will be considered as a 1370 positive acknowledgment. If there are no more fragments then the 1371 fragmentation is finished. 1373 If the sender receives a bitmap, it checks the window value. 1374 Acknowledgment with the non expected window are discarded. 1376 If the window number on the received bitmap is correct, the sender 1377 compare the local bitmap with the received bitmap. If they are equal 1378 all the fragments sent during the window have been well received. If 1379 at least one fragment need to be sent, the sender clear the bitmap, 1380 stop the timer and move its sending window to the next value. If no 1381 more fragments have to be sent, then the fragmented packet 1382 transmission is terminated. 1384 If some fragments are missing (not set in the bit map) then the 1385 sender resend the missing fragments. When the retransmission is 1386 finished, it start listening to the bitmap (even if a All-0 or All-1 1387 has not been sent during the retransmission) and returns to the 1388 waiting bitmap state. 1390 If the local-bitmap is different from the received bitmap the counter 1391 Attemps is increased and the sender resend the missing fragments 1392 again, when a MAX_ATTEMPS is reached the sender sends an Abort and 1393 goes to error. 1395 +-------+ 1396 | | 1397 | INIT | 1398 | | FCN!=0 & more frags 1399 +------++ +--+ ~~~~~~~~~~~~~~~~~~~~~~ 1400 W=0 | | | send Window + frag(FCN) 1401 ~~~~~~~~~~~~~~~~~~ | | | FCN- 1402 Clear local bitmap | | v set local bitmap 1403 FCN=max value | ++-------------+ 1404 +> | | 1405 | SEND | 1406 +--------------------------> | | 1407 | ++-----+-------+ 1408 | FCN==0 & more frags| |last frag 1409 | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~~~~~~~~ 1410 | set local-bitmap| |set local-bitmap 1411 | send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC 1412 | set Timer| |set Timer 1413 | | | 1414 |Timer expires & | | local-bitmap!=rcv-bitmap 1415 |more fragments | | +-----------------+ 1416 |~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~~~~~ | 1417 |stop Timer | | | Attemp++ | 1418 |clear local.bitmap v v | v 1419 |window = next window +-----+-----+--+--+ +----+----+ 1420 +---------------------->+ + | Resend | 1421 | Wait bitmap | | Missing | 1422 +-- + | | Frag | 1423 not expected wnd | ++-+-------+---+--+ +------+--+ 1424 ~~~~~~~~~~~~~~~~ | ^ | | ^ | 1425 discard frag +----+ | | +-------------------+ 1426 | | all missing frag sent 1427 | | ~~~~~~~~~~~~~~~~~~~~~ 1428 Timer expires & | | Set Timer 1429 No more Frag | | 1430 ~~~~~~~~~~~~~~~~ | | 1431 Stop Timer | | MAX_ATTEMPS > limit 1432 +-----------+ | | ~~~~~~~~~~~~~~~~~~ 1433 | +<--------+ | Send Abort 1434 | END | v 1435 +-----------+ +-+----------+ 1436 | ERROR | 1437 +------------+ 1439 Figure 23: Sender State Machine for the ACK on error Mode 1441 Unlike the sender, the receiver for ACK on error has some 1442 differences. First we are not sending the bitmap unless there is an 1443 error or an unexpected behavior. The Figure 24 finite state machine 1444 describes the receiver behavior. The receiver starts with an the 1445 expecting window and maintain a local_bitmap indicating which 1446 fragments it has received (all-0 and all-1 occupy the same position). 1448 Any fragment not belonging to the current window is discarded. 1449 Fragment belonging to the correct window are accepted, FN is computed 1450 based on the FCN value. When an All-0 fragment is received and the 1451 bitmap is full the receiver changes the window value and clear the 1452 bitmap. The receiver leaves this state when receiving a: 1454 o All-0 fragment and not a full bitmap indicate that all the 1455 fragments have been sent in the current window. Since the sender 1456 is not obliged to send a full window, some fragment number not set 1457 in the local_bitmap may not correspond to losses. As the receiver 1458 does not know if the missing fragments are looses or normal 1459 missing fragments it sned s a local bitmap. 1461 o All-1 fragment which indicates that the transmission is finished. 1462 Since the last window is not full, the MIC will be used to detect 1463 if all the fragments have been received. A correct MIC indicates 1464 the end of the transmission. 1466 If All-1 frag has not been received, the receiver expect a new 1467 window. It waits for the next fragment. If the window value has not 1468 changed, the received fragments are part of a retransmission. A 1469 receiver that has already received a frag should discard it (not 1470 represented in the state machine), otherwise it completes its bitmap. 1471 If all the bits of the bitmap are set to one, the receiver clear the 1472 bitmap and wait for the next window without waiting for a all-0 frag. 1473 While the receiver waits for next window and if the window value is 1474 set to the next value, and all-1 fragment with the next value window 1475 arrived the receiver goes to error and abort the transmission, it 1476 drops the fragments. 1478 If the receiver receives an all-0 fragment, it stays in the same 1479 state. Sender may send more one fragment per window or more. 1480 Otherwise some fragments in the window have been lost. 1482 If the receiver receives an all-1 fragment this means that the 1483 transmission should be finished. If the MIC is incorrect some 1484 fragments have been lost. It sends its bitmap. 1486 In case of an incorrect MIC, the receivers wait for fragment 1487 belonging to the same window. 1489 Not All- & w=expected +---+ +---+w = Not expected 1490 ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ 1491 Set local_bitmap(FCN) | v v |discard 1492 ++---+---+---+-+ 1493 +-----------------------+ +--+ All-0 & full 1494 | | Rcv Window | | ~~~~~~~~~~~~ 1495 | +--------------------+ +<-+ w =next 1496 | | +---+---+------+ clear lcl_bitmap 1497 | | | ^ 1498 | | All-0 & w=expect| |w=expct & not-All & full 1499 | | & no_full bitmap| |~~~~~~~~~~~~~~~~~~~~~~~~ 1500 | | ~~~~~~~~~~~~~~~~~| |clear lcl_bitmap; w =nxt 1501 | | send local_bitmap| | 1502 | | | | +--------+ 1503 | | | | +---------->+ | 1504 | | | | |w=next | Error/ | 1505 | | | | |~~~~~~~~ | Abort | 1506 | | | | |Send abort ++-------+ 1507 | | v | | ^ w=expct 1508 | | +-+---+--+------+ | & all-1 1509 | | | Wait +------+ ~~~~~~~ 1510 | | | Next Window | Send abort 1511 | | +-------+---+---+ 1512 | | All-1 & w=next & MIC wrong | | 1513 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | +----------------+ 1514 | | set local_bitmap(FCN) | All-1 & w=next| 1515 | | send local_bitmap | & MIC right| 1516 | | | ~~~~~~~~~~~~~~~~~~| 1517 | | | set lcl_bitmap(FCN)| 1518 | |All-1 & w=expect & MIC wrong | | 1519 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | 1520 | |set local_bitmap(FCN) v | 1521 | |send local_bitmap +-------+------+ | 1522 | +--------------------->+ Wait End +-+ | 1523 | +-----+------+-+ | w=expct & | 1524 | w=expected & MIC right | ^ | MIC wrong | 1525 | ~~~~~~~~~~~~~~~~~~~~~~ | +---+ ~~~~~~~~~ | 1526 | set local_bitmap(FCN) | set lcl_bitmap(FCN)| 1527 | | | 1528 |All-1 & w=expected & MIC right | | 1529 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | 1530 |set local_bitmap(FCN) +-+----------+ | 1531 +---------------------------->+ END +<----------+ 1532 +------------+ 1534 Figure 24: Receiver State Machine for the ACK on error Mode 1536 6. SCHC Compression for IPv6 and UDP headers 1538 This section lists the different IPv6 and UDP header fields and how 1539 they can be compressed. 1541 6.1. IPv6 version field 1543 This field always holds the same value, therefore the TV is 6, the MO 1544 is "equal" and the "CDA "not-sent"". 1546 6.2. IPv6 Traffic class field 1548 If the DiffServ field identified by the rest of the rule do not vary 1549 and is known by both sides, the TV should contain this well-known 1550 value, the MO should be "equal" and the CDA must be "not-sent. 1552 If the DiffServ field identified by the rest of the rule varies over 1553 time or is not known by both sides, then there are two possibilities 1554 depending on the variability of the value, the first one is to do not 1555 compressed the field and sends the original value, or the second 1556 where the values can be computed by sending only the LSB bits: 1558 o TV is not set to any value, MO is set to "ignore" and CDA is set 1559 to "value-sent" 1561 o TV contains a stable value, MO is MSB(X) and CDA is set to LSB 1563 6.3. Flow label field 1565 If the Flow Label field identified by the rest of the rule does not 1566 vary and is known by both sides, the TV should contain this well- 1567 known value, the MO should be "equal" and the CDA should be "not- 1568 sent". 1570 If the Flow Label field identified by the rest of the rule varies 1571 during time or is not known by both sides, there are two 1572 possibilities depending on the variability of the value, the first 1573 one is without compression and then the value is sent and the second 1574 where only part of the value is sent and the decompressor needs to 1575 compute the original value: 1577 o TV is not set, MO is set to "ignore" and CDA is set to "value- 1578 sent" 1580 o TV contains a stable value, MO is MSB(X) and CDA is set to LSB 1582 6.4. Payload Length field 1584 If the LPWAN technology does not add padding, this field can be 1585 elided for the transmission on the LPWAN network. The SCHC C/D 1586 recomputes the original payload length value. The TV is not set, the 1587 MO is set to "ignore" and the CDA is "compute-IPv6-length". 1589 If the payload length needs to be sent and does not need to be coded 1590 in 16 bits, the TV can be set to 0x0000, the MO set to "MSB (16-s)" 1591 and the CDA to "LSB". The 's' parameter depends on the expected 1592 maximum packet length. 1594 On other cases, the payload length field must be sent and the CDA is 1595 replaced by "value-sent". 1597 6.5. Next Header field 1599 If the Next Header field identified by the rest of the rule does not 1600 vary and is known by both sides, the TV should contain this Next 1601 Header value, the MO should be "equal" and the CDA should be "not- 1602 sent". 1604 If the Next header field identified by the rest of the rule varies 1605 during time or is not known by both sides, then TV is not set, MO is 1606 set to "ignore" and CDA is set to "value-sent". A matching-list may 1607 also be used. 1609 6.6. Hop Limit field 1611 The End System is generally a device and does not forward packets, 1612 therefore the Hop Limit value is constant. So the TV is set with a 1613 default value, the MO is set to "equal" and the CDA is set to "not- 1614 sent". 1616 Otherwise the value is sent on the LPWAN: TV is not set, MO is set to 1617 ignore and CDA is set to "value-sent". 1619 Note that the field behavior differs in upstream and downstream. In 1620 upstream, since there is no IP forwarding between the Dev and the 1621 SCHC C/D, the value is relatively constant. On the other hand, the 1622 downstream value depends of Internet routing and may change more 1623 frequently. One solution could be to use the Direction Indicator 1624 (DI) to distinguish both directions to elide the field in the 1625 upstream direction and send the value in the downstream direction. 1627 6.7. IPv6 addresses fields 1629 As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit 1630 long fields; one for the prefix and one for the Interface Identifier 1631 (IID). These fields should be compressed. To allow a single rule, 1632 these values are identified by their role (DEV or APP) and not by 1633 their position in the frame (source or destination). The SCHC C/D 1634 must be aware of the traffic direction (upstream, downstream) to 1635 select the appropriate field. 1637 6.7.1. IPv6 source and destination prefixes 1639 Both ends must be synchronized with the appropriate prefixes. For a 1640 specific flow, the source and destination prefix can be unique and 1641 stored in the context. It can be either a link-local prefix or a 1642 global prefix. In that case, the TV for the source and destination 1643 prefixes contains the values, the MO is set to "equal" and the CDA is 1644 set to "not-sent". 1646 In case the rule allows several prefixes, mapping-list must be used. 1647 The different prefixes are listed in the TV associated with a short 1648 ID. The MO is set to "match-mapping" and the CDA is set to "mapping- 1649 sent". 1651 Otherwise the TV contains the prefix, the MO is set to "equal" and 1652 the CDA is set to value-sent. 1654 6.7.2. IPv6 source and destination IID 1656 If the DEV or APP IID are based on an LPWAN address, then the IID can 1657 be reconstructed with information coming from the LPWAN header. In 1658 that case, the TV is not set, the MO is set to "ignore" and the CDA 1659 is set to "DEViid" or "APPiid". Note that the LPWAN technology is 1660 generally carrying a single device identifier corresponding to the 1661 DEV. The SCHC C/D may also not be aware of these values. 1663 If the DEV address has a static value that is not derived from an 1664 IEEE EUI-64, then TV contains the actual Dev address value, the MO 1665 operator is set to "equal" and the CDA is set to "not-sent". 1667 If several IIDs are possible, then the TV contains the list of 1668 possible IIDs, the MO is set to "match-mapping" and the CDA is set to 1669 "mapping-sent". 1671 Otherwise the value variation of the IID may be reduced to few bytes. 1672 In that case, the TV is set to the stable part of the IID, the MO is 1673 set to MSB and the CDA is set to LSB. 1675 Finally, the IID can be sent on the LPWAN. In that case, the TV is 1676 not set, the MO is set to "ignore" and the CDA is set to "value- 1677 sent". 1679 6.8. IPv6 extensions 1681 No extension rules are currently defined. They can be based on the 1682 MOs and CDAs described above. 1684 6.9. UDP source and destination port 1686 To allow a single rule, the UDP port values are identified by their 1687 role (DEV or APP) and not by their position in the frame (source or 1688 destination). The SCHC C/D must be aware of the traffic direction 1689 (upstream, downstream) to select the appropriate field. The 1690 following rules apply for DEV and APP port numbers. 1692 If both ends know the port number, it can be elided. The TV contains 1693 the port number, the MO is set to "equal" and the CDA is set to "not- 1694 sent". 1696 If the port variation is on few bits, the TV contains the stable part 1697 of the port number, the MO is set to "MSB" and the CDA is set to 1698 "LSB". 1700 If some well-known values are used, the TV can contain the list of 1701 this values, the MO is set to "match-mapping" and the CDA is set to 1702 "mapping-sent". 1704 Otherwise the port numbers are sent on the LPWAN. The TV is not set, 1705 the MO is set to "ignore" and the CDA is set to "value-sent". 1707 6.10. UDP length field 1709 If the LPWAN technology does not introduce padding, the UDP length 1710 can be computed from the received data. In that case the TV is not 1711 set, the MO is set to "ignore" and the CDA is set to "compute-UDP- 1712 length". 1714 If the payload is small, the TV can be set to 0x0000, the MO set to 1715 "MSB" and the CDA to "LSB". 1717 On other cases, the length must be sent and the CDA is replaced by 1718 "value-sent". 1720 6.11. UDP Checksum field 1722 IPv6 mandates a checksum in the protocol above IP. Nevertheless, if 1723 a more efficient mechanism such as L2 CRC or MIC is carried by or 1724 over the L2 (such as in the LPWAN fragmentation process (see section 1725 Section 5)), the UDP checksum transmission can be avoided. In that 1726 case, the TV is not set, the MO is set to "ignore" and the CDA is set 1727 to "compute-UDP-checksum". 1729 In other cases the checksum must be explicitly sent. The TV is not 1730 set, the MO is set to "ignore" and the CDF is set to "value-sent". 1732 7. Security considerations 1734 7.1. Security considerations for header compression 1736 A malicious header compression could cause the reconstruction of a 1737 wrong packet that does not match with the original one, such 1738 corruption may be detected with end-to-end authentication and 1739 integrity mechanisms. Denial of Service may be produced but its 1740 arise other security problems that may be solved with or without 1741 header compression. 1743 7.2. Security considerations for fragmentation 1745 This subsection describes potential attacks to LPWAN fragmentation 1746 and suggests possible countermeasures. 1748 A node can perform a buffer reservation attack by sending a first 1749 fragment to a target. Then, the receiver will reserve buffer space 1750 for the IPv6 packet. Other incoming fragmented packets will be 1751 dropped while the reassembly buffer is occupied during the reassembly 1752 timeout. Once that timeout expires, the attacker can repeat the same 1753 procedure, and iterate, thus creating a denial of service attack. 1754 The (low) cost to mount this attack is linear with the number of 1755 buffers at the target node. However, the cost for an attacker can be 1756 increased if individual fragments of multiple packets can be stored 1757 in the reassembly buffer. To further increase the attack cost, the 1758 reassembly buffer can be split into fragment-sized buffer slots. 1759 Once a packet is complete, it is processed normally. If buffer 1760 overload occurs, a receiver can discard packets based on the sender 1761 behavior, which may help identify which fragments have been sent by 1762 an attacker. 1764 In another type of attack, the malicious node is required to have 1765 overhearing capabilities. If an attacker can overhear a fragment, it 1766 can send a spoofed duplicate (e.g. with random payload) to the 1767 destination. If the LPWAN technology does not support suitable 1768 protection (e.g. source authentication and frame counters to prevent 1769 replay attacks), a receiver cannot distinguish legitimate from 1770 spoofed fragments. Therefore, the original IPv6 packet will be 1771 considered corrupt and will be dropped. To protect resource- 1772 constrained nodes from this attack, it has been proposed to establish 1773 a binding among the fragments to be transmitted by a node, by 1774 applying content-chaining to the different fragments, based on 1775 cryptographic hash functionality. The aim of this technique is to 1776 allow a receiver to identify illegitimate fragments. 1778 Further attacks may involve sending overlapped fragments (i.e. 1779 comprising some overlapping parts of the original IPv6 datagram). 1780 Implementers should make sure that correct operation is not affected 1781 by such event. 1783 In Window mode - ACK on error, a malicious node may force a fragment 1784 sender to resend a fragment a number of times, with the aim to 1785 increase consumption of the fragment sender's resources. To this 1786 end, the malicious node may repeatedly send a fake ACK to the 1787 fragment sender, with a bitmap that reports that one or more 1788 fragments have been lost. In order to mitigate this possible attack, 1789 MAX_FRAG_RETRIES may be set to a safe value which allows to limit the 1790 maximum damage of the attack to an acceptable extent. However, note 1791 that a high setting for MAX_FRAG_RETRIES benefits fragment delivery 1792 reliability, therefore the trade-off needs to be carefully 1793 considered. 1795 8. Acknowledgements 1797 Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier, 1798 Arunprabhu Kandasamy, Antony Markovski, Alexander Pelov, Pascal 1799 Thubert, Juan Carlos Zuniga and Diego Dujovne for useful design 1800 consideration and comments. 1802 9. References 1804 9.1. Normative References 1806 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1807 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1808 December 1998, . 1810 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1811 "Transmission of IPv6 Packets over IEEE 802.15.4 1812 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1813 . 1815 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1816 Header Compression (ROHC) Framework", RFC 5795, 1817 DOI 10.17487/RFC5795, March 2010, 1818 . 1820 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1821 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 1822 February 2014, . 1824 9.2. Informative References 1826 [I-D.ietf-lpwan-overview] 1827 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 1828 overview-07 (work in progress), October 2017. 1830 Appendix A. SCHC Compression Examples 1832 This section gives some scenarios of the compression mechanism for 1833 IPv6/UDP. The goal is to illustrate the SCHC behavior. 1835 The most common case using the mechanisms defined in this document 1836 will be a LPWAN Dev that embeds some applications running over CoAP. 1837 In this example, three flows are considered. The first flow is for 1838 the device management based on CoAP using Link Local IPv6 addresses 1839 and UDP ports 123 and 124 for Dev and App, respectively. The second 1840 flow will be a CoAP server for measurements done by the Device (using 1841 ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to 1842 beta::1/64. The last flow is for legacy applications using different 1843 ports numbers, the destination IPv6 address prefix is gamma::1/64. 1845 Figure 25 presents the protocol stack for this Device. IPv6 and UDP 1846 are represented with dotted lines since these protocols are 1847 compressed on the radio link. 1849 Management Data 1850 +----------+---------+---------+ 1851 | CoAP | CoAP | legacy | 1852 +----||----+---||----+---||----+ 1853 . UDP . UDP | UDP | 1854 ................................ 1855 . IPv6 . IPv6 . IPv6 . 1856 +------------------------------+ 1857 | SCHC Header compression | 1858 | and fragmentation | 1859 +------------------------------+ 1860 | LPWAN L2 technologies | 1861 +------------------------------+ 1862 DEV or NGW 1864 Figure 25: Simplified Protocol Stack for LP-WAN 1866 Note that in some LPWAN technologies, only the Devs have a device ID. 1867 Therefore, when such technologies are used, it is necessary to define 1868 statically an IID for the Link Local address for the SCHC C/D. 1870 Rule 0 1871 +----------------+--+--+--+---------+--------+------------++------+ 1872 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 1873 | | | | | | Opera. | Action ||[bits]| 1874 +----------------+--+--+--+---------+---------------------++------+ 1875 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1876 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1877 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1878 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1879 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1880 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 1881 |IPv6 DEVprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 1882 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1883 |IPv6 APPprefix |64|1 |Bi|FE80::/64| equal | not-sent || | 1884 |IPv6 APPiid |64|1 |Bi|::1 | equal | not-sent || | 1885 +================+==+==+==+=========+========+============++======+ 1886 |UDP DEVport |16|1 |Bi|123 | equal | not-sent || | 1887 |UDP APPport |16|1 |Bi|124 | equal | not-sent || | 1888 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1889 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1890 +================+==+==+==+=========+========+============++======+ 1892 Rule 1 1893 +----------------+--+--+--+---------+--------+------------++------+ 1894 | Field |FL|FP|DI| Value | Match | Action || Sent | 1895 | | | | | | Opera. | Action ||[bits]| 1896 +----------------+--+--+--+---------+--------+------------++------+ 1897 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1898 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1899 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1900 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1901 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1902 |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | 1903 |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| [1] | 1904 | | | | |fe80::/64] mapping| || | 1905 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1906 |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| [2] | 1907 | | | | |alpha/64,| mapping| || | 1908 | | | | |fe80::64]| | || | 1909 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 1910 +================+==+==+==+=========+========+============++======+ 1911 |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | 1912 |UDP APPport |16|1 |Bi|5683 | equal | not-sent || | 1913 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1914 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1915 +================+==+==+==+=========+========+============++======+ 1916 Rule 2 1917 +----------------+--+--+--+---------+--------+------------++------+ 1918 | Field |FL|FP|DI| Value | Match | Action || Sent | 1919 | | | | | | Opera. | Action ||[bits]| 1920 +----------------+--+--+--+---------+--------+-------------++------+ 1921 |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | 1922 |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | 1923 |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | 1924 |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | 1925 |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | 1926 |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | 1927 |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] | 1928 |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | 1929 |IPv6 DEViid |64|1 |Bi| | ignore | DEViid || | 1930 |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | 1931 |IPv6 APPiid |64|1 |Bi|::1000 | equal | not-sent || | 1932 +================+==+==+==+=========+========+============++======+ 1933 |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | 1934 |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB(4) || [4] | 1935 |UDP Length |16|1 |Bi| | ignore | comp-length|| | 1936 |UDP checksum |16|1 |Bi| | ignore | comp-chk || | 1937 +================+==+==+==+=========+========+============++======+ 1939 Figure 26: Context rules 1941 All the fields described in the three rules depicted on Figure 26 are 1942 present in the IPv6 and UDP headers. The DEViid-DID value is found 1943 in the L2 header. 1945 The second and third rules use global addresses. The way the Dev 1946 learns the prefix is not in the scope of the document. 1948 The third rule compresses port numbers to 4 bits. 1950 Appendix B. Fragmentation Examples 1952 This section provides examples of different fragment delivery 1953 reliability options possible on the basis of this specification. 1955 Figure 27 illustrates the transmission of an IPv6 packet that needs 1956 11 fragments in the No ACK option, FCN is always 1 bit. 1958 Sender Receiver 1959 |-------FCN=0-------->| 1960 |-------FCN=0-------->| 1961 |-------FCN=0-------->| 1962 |-------FCN=0-------->| 1963 |-------FCN=0-------->| 1964 |-------FCN=0-------->| 1965 |-------FCN=0-------->| 1966 |-------FCN=0-------->| 1967 |-------FCN=0-------->| 1968 |-------FCN=0-------->| 1969 |-------FCN=1-------->|MIC checked => 1971 Figure 27: Transmission of an IPv6 packet carried by 11 fragments in 1972 the No ACK option 1974 Figure 28 illustrates the transmission of an IPv6 packet that needs 1975 11 fragments in Window mode - ACK on error, for N=3, without losses. 1977 Sender Receiver 1978 |-----W=1, FCN=6----->| 1979 |-----W=1, FCN=5----->| 1980 |-----W=1, FCN=4----->| 1981 |-----W=1, FCN=3----->| 1982 |-----W=1, FCN=2----->| 1983 |-----W=1, FCN=1----->| 1984 |-----W=1, FCN=0----->| 1985 (no ACK) 1986 |-----W=0, FCN=6----->| 1987 |-----W=0, FCN=5----->| 1988 |-----W=0, FCN=4----->| 1989 |-----W=0, FCN=7----->|MIC checked => 1990 (no ACK) 1992 Figure 28: Transmission of an IPv6 packet carried by 11 fragments in 1993 Window mode - ACK on error, for N=3 and MAX_WIND_FCN=6, without 1994 losses. 1996 Figure 29 illustrates the transmission of an IPv6 packet that needs 1997 11 fragments in Window mode - ACK on error, for N=3, with three 1998 losses. 2000 Sender Receiver 2001 |-----W=1, FCN=6----->| 2002 |-----W=1, FCN=5----->| 2003 |-----W=1, FCN=4--X-->| 2004 |-----W=1, FCN=3----->| 2005 |-----W=1, FCN=2--X-->| 2006 |-----W=1, FCN=1----->| 2007 |-----W=1, FCN=0----->| 2008 |<-----ACK, W=1-------|Bitmap:11010111 2009 |-----W=1, FCN=4----->| 2010 |-----W=1, FCN=2----->| 2011 (no ACK) 2012 |-----W=0, FCN=6----->| 2013 |-----W=0, FCN=5----->| 2014 |-----W=0, FCN=4--X-->| 2015 |-----W=0, FCN=7----->|MIC checked 2016 |<-----ACK, W=0-------|Bitmap:11000001 2017 |-----W=0, FCN=4----->|MIC checked => 2018 (no ACK) 2020 Figure 29: Transmission of an IPv6 packet carried by 11 fragments in 2021 Window mode - ACK on error, for N=3 and MAX_WIND_FCN=6, three losses. 2023 Figure 30 illustrates the transmission of an IPv6 packet that needs 2024 11 fragments in Window mode - ACK "always", for N=3 and 2025 MAX_WIND_FCN=6, without losses. Note: in Window mode, an additional 2026 bit will be needed to number windows. 2028 Sender Receiver 2029 |-----W=1, FCN=6----->| 2030 |-----W=1, FCN=5----->| 2031 |-----W=1, FCN=4----->| 2032 |-----W=1, FCN=3----->| 2033 |-----W=1, FCN=2----->| 2034 |-----W=1, FCN=1----->| 2035 |-----W=1, FCN=0----->| 2036 |<-----ACK, W=1-------|no bitmap 2037 |-----W=0, FCN=6----->| 2038 |-----W=0, FCN=5----->| 2039 |-----W=0, FCN=4----->| 2040 |-----W=0, FCN=7----->|MIC checked => 2041 |<-----ACK, W=0-------|no bitmap 2042 (End) 2044 Figure 30: Transmission of an IPv6 packet carried by 11 fragments in 2045 Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, no losses. 2047 Figure 31 illustrates the transmission of an IPv6 packet that needs 2048 11 fragments in Window mode - ACK "always", for N=3 and 2049 MAX_WIND_FCN=6, with three losses. 2051 Sender Receiver 2052 |-----W=1, FCN=6----->| 2053 |-----W=1, FCN=5----->| 2054 |-----W=1, FCN=4--X-->| 2055 |-----W=1, FCN=3----->| 2056 |-----W=1, FCN=2--X-->| 2057 |-----W=1, FCN=1----->| 2058 |-----W=1, FCN=0----->| 2059 |<-----ACK, W=1-------|bitmap:11010111 2060 |-----W=1, FCN=4----->| 2061 |-----W=1, FCN=2----->| 2062 |<-----ACK, W=1-------|no bitmap 2063 |-----W=0, FCN=6----->| 2064 |-----W=0, FCN=5----->| 2065 |-----W=0, FCN=4--X-->| 2066 |-----W=0, FCN=7----->|MIC checked 2067 |<-----ACK, W=0-------|bitmap:11000001 2068 |-----W=0, FCN=4----->|MIC checked => 2069 |<-----ACK, W=0-------|no bitmap 2070 (End) 2072 Figure 31: Transmission of an IPv6 packet carried by 11 fragments in 2073 Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three 2074 losses. 2076 Figure 32 illustrates the transmission of an IPv6 packet that needs 6 2077 fragments in Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, 2078 with three losses, and only one retry is needed for each lost 2079 fragment. Note that, since a single window is needed for 2080 transmission of the IPv6 packet in this case, the example illustrates 2081 behavior when losses happen in the last window. 2083 Sender Receiver 2084 |-----W=0, CFN=6----->| 2085 |-----W=0, CFN=5----->| 2086 |-----W=0, CFN=4--X-->| 2087 |-----W=0, CFN=3--X-->| 2088 |-----W=0, CFN=2--X-->| 2089 |-----W=0, CFN=7----->|MIC checked 2090 |<-----ACK, W=0-------|bitmap:11000001 2091 |-----W=0, CFN=4----->|MIC checked: failed 2092 |-----W=0, CFN=3----->|MIC checked: failed 2093 |-----W=0, CFN=2----->|MIC checked: success 2094 |<-----ACK, W=0-------|no bitmap 2095 (End) 2097 Figure 32: Transmission of an IPv6 packet carried by 11 fragments in 2098 Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three 2099 losses, and only one retry is needed for each lost fragment. 2101 Figure 33 illustrates the transmission of an IPv6 packet that needs 6 2102 fragments in Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, 2103 with three losses, and the second ACK is lost. Note that, since a 2104 single window is needed for transmission of the IPv6 packet in this 2105 case, the example illustrates behavior when losses happen in the last 2106 window. 2108 Sender Receiver 2109 |-----W=0, CFN=6----->| 2110 |-----W=0, CFN=5----->| 2111 |-----W=0, CFN=4--X-->| 2112 |-----W=0, CFN=3--X-->| 2113 |-----W=0, CFN=2--X-->| 2114 |-----W=0, CFN=7----->|MIC checked 2115 |<-----ACK, W=0-------|bitmap:11000001 2116 |-----W=0, CFN=4----->|MIC checked: wrong 2117 |-----W=0, CFN=3----->|MIC checked: wrong 2118 |-----W=0, CFN=2----->|MIC checked: right 2119 | X---ACK, W=0-------|no bitmap 2120 timeout | | 2121 |-----W=0, CFN=7----->| 2122 |<-----ACK, W=0-------|no bitmap 2124 (End) 2126 Figure 33: Transmission of an IPv6 packet carried by 11 fragments in 2127 Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three 2128 losses, and the second ACK is lost. 2130 Figure 34 illustrates the transmission of an IPv6 packet that needs 6 2131 fragments in Window mode - ACK "always", for N=3 and MAX_WIND_FCN=6, 2132 with three losses, and one retransmitted fragment is lost. Note 2133 that, since a single window is needed for transmission of the IPv6 2134 packet in this case, the example illustrates behavior when losses 2135 happen in the last window. 2137 Sender Receiver 2138 |-----W=0, CFN=6----->| 2139 |-----W=0, CFN=5----->| 2140 |-----W=0, CFN=4--X-->| 2141 |-----W=0, CFN=3--X-->| 2142 |-----W=0, CFN=2--X-->| 2143 |-----W=0, CFN=7----->|MIC checked 2144 |<-----ACK, W=0-------|bitmap:11000001 2145 |-----W=0, CFN=4----->|MIC checked: wrong 2146 |-----W=0, CFN=3----->|MIC checked: wrong 2147 |-----W=0, CFN=2--X-->| 2148 timeout| | 2149 |-----W=0, CFN=7----->| 2150 |<-----ACK, W=0-------|bitmap:11110001 2151 |-----W=0, CFN=2----->|MIC checked: right 2152 |<-----ACK, W=0-------|no bitmap 2153 (End) 2155 Figure 34: Transmission of an IPv6 packet carried by 11 fragments in 2156 Window mode - ACK "Always", for N=3, and MAX_WIND_FCN=6, with three 2157 losses, and one retransmitted fragment is lost. 2159 Appendix C illustrates the transmission of an IPv6 packet that needs 2160 28 fragments in Window mode - ACK "always", for N=5 and 2161 MAX_WIND_FCN=23, with two losses. Note that MAX_WIND_FCN=23 may be 2162 useful when the maximum possible bitmap size, considering the maximum 2163 lower layer technology payload size and the value of R, is 3 bytes. 2164 Note also that the FCN of the last fragment of the packet is the one 2165 with FCN=31 (i.e. FCN=2^N-1 for N=5, or equivalently, all FCN bits 2166 set to 1). 2168 Sender Receiver 2169 |-----W=1, CFN=23----->| 2170 |-----W=1, CFN=22----->| 2171 |-----W=1, CFN=21--X-->| 2172 |-----W=1, CFN=20----->| 2173 |-----W=1, CFN=19----->| 2174 |-----W=1, CFN=18----->| 2175 |-----W=1, CFN=17----->| 2176 |-----W=1, CFN=16----->| 2177 |-----W=1, CFN=15----->| 2178 |-----W=1, CFN=14----->| 2179 |-----W=1, CFN=13----->| 2180 |-----W=1, CFN=12----->| 2181 |-----W=1, CFN=11----->| 2182 |-----W=1, CFN=10--X-->| 2183 |-----W=1, CFN=9 ----->| 2184 |-----W=1, CFN=8 ----->| 2185 |-----W=1, CFN=7 ----->| 2186 |-----W=1, CFN=6 ----->| 2187 |-----W=1, CFN=5 ----->| 2188 |-----W=1, CFN=4 ----->| 2189 |-----W=1, CFN=3 ----->| 2190 |-----W=1, CFN=2 ----->| 2191 |-----W=1, CFN=1 ----->| 2192 |-----W=1, CFN=0 ----->| 2193 |<------ACK, W=1-------|bitmap:110111111111101111111111 2194 |-----W=1, CFN=21----->| 2195 |-----W=1, CFN=10----->| 2196 |<------ACK, W=1-------|no bitmap 2197 |-----W=0, CFN=23----->| 2198 |-----W=0, CFN=22----->| 2199 |-----W=0, CFN=21----->| 2200 |-----W=0, CFN=31----->|MIC checked => 2201 |<------ACK, W=0-------|no bitmap 2202 (End) 2204 Appendix C. Allocation of Rule IDs for fragmentation 2206 A set of Rule IDs are allocated to support different aspects of 2207 fragmentation functionality as per this document. The allocation of 2208 IDs is to be defined in other documents. The set MAY include: 2210 o one ID or a subset of IDs to identify a fragment as well as its 2211 reliability option and its window size, if multiple of these are 2212 supported. 2214 o one ID to identify the ACK message. 2216 o one ID to identify the Abort message as per Section 9.8. 2218 Appendix D. Note 2220 Carles Gomez has been funded in part by the Spanish Government 2221 (Ministerio de Educacion, Cultura y Deporte) through the Jose 2222 Castillejo grant CAS15/00336, and by the ERDF and the Spanish 2223 Government through project TEC2016-79988-P. Part of his contribution 2224 to this work has been carried out during his stay as a visiting 2225 scholar at the Computer Laboratory of the University of Cambridge. 2227 Authors' Addresses 2229 Ana Minaburo 2230 Acklio 2231 2bis rue de la Chataigneraie 2232 35510 Cesson-Sevigne Cedex 2233 France 2235 Email: ana@ackl.io 2237 Laurent Toutain 2238 IMT-Atlantique 2239 2 rue de la Chataigneraie 2240 CS 17607 2241 35576 Cesson-Sevigne Cedex 2242 France 2244 Email: Laurent.Toutain@imt-atlantique.fr 2246 Carles Gomez 2247 Universitat Politecnica de Catalunya 2248 C/Esteve Terradas, 7 2249 08860 Castelldefels 2250 Spain 2252 Email: carlesgo@entel.upc.edu