idnits 2.17.1 draft-ietf-lpwan-schc-over-lorawan-02.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.) ** There are 32 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: _Note_: While it is used to recover faster from transmission errors, it SHALL not be considered as the only way to distinguish two fragmentation sessions. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: _Note_: The Fpending bit included in LoRaWAN protocol SHOULD not be used for SCHC-over-LoRaWAN protocol. It might be set by the Network Server for other purposes in but not SCHC needs. -- The document date (July 08, 2019) is 1746 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4944' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC5795' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 780, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-19 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group O. Gimenez, Ed. 3 Internet-Draft Semtech 4 Intended status: Informational I. Petrov, Ed. 5 Expires: January 9, 2020 Acklio 6 July 08, 2019 8 Static Context Header Compression (SCHC) over LoRaWAN 9 draft-ietf-lpwan-schc-over-lorawan-02 11 Abstract 13 The Static Context Header Compression (SCHC) specification describes 14 generic header compression and fragmentation techniques for LPWAN 15 (Low Power Wide Area Networks) technologies. SCHC is a generic 16 mechanism designed for great flexibility, so that it can be adapted 17 for any of the LPWAN technologies. 19 This document provides the adaptation of SCHC for use in LoRaWAN 20 networks, and provides elements such as efficient parameterization 21 and modes of operation. This is called a profile. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Static Context Header Compression Overview . . . . . . . . . 3 60 4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5 61 4.1. End-Device classes (A, B, C) and interactions . . . . . . 6 62 4.2. End-Device addressing . . . . . . . . . . . . . . . . . . 7 63 4.3. General Message Types . . . . . . . . . . . . . . . . . . 7 64 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8 65 5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8 67 5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9 68 5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 9 69 5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9 70 5.5. DTag . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.5.1. Uplink fragmentation: From device to SCHC gateway . . 10 72 5.5.2. Downlink fragmentation: From SCHC gateway to device . 13 73 6. Security considerations . . . . . . . . . . . . . . . . . . . 16 74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 78 9.2. Informative References . . . . . . . . . . . . . . . . . 18 79 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 80 A.1. Uplink - Compression example - No fragmentation . . . . . 18 81 A.2. Uplink - Compression and fragmentation example . . . . . 19 82 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 20 83 Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 The Static Context Header Compression (SCHC) specification 89 [I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header 90 compression and fragmentation techniques that can be used on all 91 LPWAN (Low Power Wide Area Networks) technologies defined in 92 [RFC8376]. Even though those technologies share a great number of 93 common features like star-oriented topologies, network architecture, 94 devices with mostly quite predictable communications, etc; they do 95 have some slight differences in respect of payload sizes, 96 reactiveness, etc. 98 SCHC gives a generic framework that enables those devices to 99 communicate with other Internet networks. However, for efficient 100 performance, some parameters and modes of operation need to be set 101 appropriately for each of the LPWAN technologies. 103 This document describes the efficient parameters and modes of 104 operation when SCHC is used over LoRaWAN networks. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 This section defines the terminology and acronyms used in this 113 document. For all other definitions, please look up the SCHC 114 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 116 o DevEUI: an IEEE EUI-64 identifier used to identify the end-device 117 during the procedure while joining the network (Join Procedure) 119 o DevAddr: a 32-bit non-unique identifier assigned to a end-device 120 statically or dynamically after a Join Procedure (depending on the 121 activation mode) 123 o TBD: all significant LoRaWAN-related terms. 125 3. Static Context Header Compression Overview 127 This section contains a short overview of Static Context Header 128 Compression (SCHC). For a detailed description, refer to the full 129 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 131 Static Context Header Compression (SCHC) avoids context 132 synchronization, based on the fact that the nature of data flows is 133 highly predictable in LPWAN networks, some static contexts may be 134 stored on the Device (Dev). The contexts must be stored in both 135 ends, and it can either be learned by a provisioning protocol or by 136 out-of-band means or it can be pre-provisioned, etc. The way the 137 context is learned on both sides is out of the scope of this 138 document. 140 Dev App 141 +----------------+ +----+ +----+ +----+ 142 | App1 App2 App3 | |App1| |App2| |App3| 143 | | | | | | | | 144 | UDP | |UDP | |UDP | |UDP | 145 | IPv6 | |IPv6| |IPv6| |IPv6| 146 | | | | | | | | 147 |SCHC C/D and F/R| | | | | | | 148 +--------+-------+ +----+ +----+ +----+ 149 | +--+ +----+ +----+ +----+ . . . 150 +~ |RG| === |NGW | == |SCHC| == |SCHC|...... Internet .... 151 +--+ +----+ |F/R | |C/D | 152 +----+ +----+ 154 Figure 1: Architecture 156 Figure 1 represents the architecture for compression/decompression, 157 it is based on [RFC8376] terminology. The Device is sending 158 applications flows using IPv6 or IPv6/UDP protocols. These flow 159 might be fragemented (SCHC F/R), and compressed by an Static Context 160 Header Compression Compressor/Decompressor (SCHC C/D) to reduce 161 headers size. Resulting information is sent on a layer two (L2) 162 frame to a LPWAN Radio Network (RG) which forwards the frame to a 163 Network Gateway (NGW). The NGW sends the data to a SCHC F/R for 164 defragmentation, if required, then C/D for decompression which shares 165 the same rules with the device. The SCHC F/R and C/D can be located 166 on the Network Gateway (NGW) or in another place as long as a tunnel 167 is established between the NGW and the SCHC F/R, then SCHC F/R and 168 SCHC C/D. The SCHC C/D in both sides must share the same set of 169 Rules. After decompression, the packet can be sent on the Internet 170 to one or several LPWAN Application Servers (App). 172 The SCHC F/R and SCHC C/D process is bidirectional, so the same 173 principles can be applied in the other direction. 175 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 176 Server, and the SCHC C/D is an Application Server. It can be 177 provided by the Network Server or any third party software. Figure 1 178 can be map in LoRaWAN terminology to: 180 Dev App 181 +----------------+ +----+ +----+ +----+ 182 | App1 App2 App3 | |App1| |App2| |App3| 183 | | | | | | | | 184 | UDP | |UDP | |UDP | |UDP | 185 | IPv6 | |IPv6| |IPv6| |IPv6| 186 | | | | | | | | 187 |SCHC C/D and F/R| | | | | | | 188 +--------+-------+ +----+ +----+ +----+ 189 | +-------+ +-------+ +----------------+ . . . 190 +~ |Gateway| === |Network| == |Application |...... Internet .... 191 +-------+ |server | |server F/R - C/D| 192 +-------+ +----------------+ 194 Figure 2: Architecture 196 4. LoRaWAN Architecture 198 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 199 is described in [RFC8376]. Mapping between the LPWAN architecture 200 entities as described in [I-D.ietf-lpwan-ipv6-static-context-hc] and 201 the ones in [lora-alliance-spec] is as follows: 203 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 204 actuators, etc.). There can be a very high density of devices per 205 radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN 206 End-Device. 208 o The Radio Gateway (RGW), which is the end point of the constrained 209 link. This entity maps to the LoRaWAN Gateway. 211 o The Network Gateway (NGW) is the interconnection node between the 212 Radio Gateway and the Internet. This entity maps to the LoRaWAN 213 Network Server. 215 o LPWAN-AAA Server, which controls the user authentication and the 216 applications. This entity maps to the LoRaWAN Join Server. 218 o Application Server (App). The same terminology is used in LoRaWAN. 219 In that case, the application server will be the SCHC gateway, doing 220 C/D and F/R. 222 () () () | +------+ 223 () () () () / \ +---------+ | Join | 224 () () () () () / \======| ^ |===|Server| +-----------+ 225 () () () | | <--|--> | +------+ |Application| 226 () () () () / \==========| v |=============| Server | 227 () () () / \ +---------+ +-----------+ 228 End-Devices Gateways Network Server 230 Figure 3: LPWAN Architecture 232 SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/ 233 Reassembly) are performed on the LoRaWAN End-Device and the 234 Application Server (called SCHC gateway). While the point-to-point 235 link between the End-Device and the Application Server constitutes 236 single IP hop, the ultimate end-point of the IP communication may be 237 an Internet node beyond the Application Server. In other words, the 238 LoRaWAN Application Server (SCHC gateway) acts as the first hop IP 239 router for the End-Device. The Application Server and Network Server 240 may be co-located, which effectively turns the Network/Application 241 Server into the first hop IP router. 243 4.1. End-Device classes (A, B, C) and interactions 245 The LoRaWAN MAC layer supports 3 classes of end-devices named A, B 246 and C. All end-devices implement the classA, some end-devices 247 implement classA+B or class A+C. ClassB and classC are mutually 248 exclusive. 250 o *ClassA*: The classA is the simplest class of end-devices. The 251 end-device is allowed to transmit at any time, randomly selecting 252 a communication channel. The network may reply with a downlink in 253 one of the 2 receive windows immediately following the uplinks. 254 Therefore, the network cannot initiate a downlink, it has to wait 255 for the next uplink from the end-device to get a downlink 256 opportunity. The classA is the lowest power end-device class. 258 o *ClassB*: classB end-devices implement all the functionalities of 259 classA end-devices, but also schedule periodic listen windows. 260 Therefore, as opposed the classA end-devices, classB end-devices 261 can receive downlink that are initiated by the network and not 262 following an uplink. There is a trade-off between the periodicity 263 of those scheduled classB listen windows and the power consumption 264 of the end-device. The lower the downlink latency, the higher the 265 power consumption. 267 o *ClassC*: classC end-devices implement all the functionalities of 268 classA end-devices, but keep their receiver open whenever they are 269 not transmitting. ClassC end-devices can receive downlinks at any 270 time at the expense of a higher power consumption. Battery 271 powered end-devices can only operate in classC for a limited 272 amount of time (for example for a firmware upgrade over-the-air). 273 Most of the classC end-devices are main powered (for example Smart 274 Plugs). 276 4.2. End-Device addressing 278 LoRaWAN end-devices use a 32 bits network address (devAddr) to 279 communicate with the network over-the-air. However, that address 280 might be reused several time on the same network at the same time for 281 different end-devices. End-devices using the same devAddr are 282 distinguish by the Network Server based on the cryptographic 283 signature appended to every single LoRaWAN MAC frame, as all end- 284 devices use different security keys. To communicate with the SCHC 285 gateway the Network Server MUST identify the end-devices by a unique 286 64bits device ID called the devEUI. Unlike devAddr, devEUI is 287 guaranteed to be unique for every single end-device across all 288 networks. The devEUI is assigned to the end-device during the 289 manufacturing process by the end-device's manufacturer. It is built 290 like an Ethernet MAC address by concatenating the manufacturer's IEEE 291 OUI field with a vendor unique number. ex: 24bits OUI is 292 concatenated with a 40 bits serial number. The Network Server 293 translates the devAddr into a devEUI in the uplink direction and 294 reciprocally on the downlink direction. 296 +--------+ +----------+ +---------+ +----------+ 297 | End- | <=====> | Network | <====> | SCHC | <========> | Internet | 298 | Device | devAddr | Server | devEUI | Gateway | IPv6/UDP | | 299 +--------+ +----------+ +---------+ +----------+ 301 Figure 4: LoRaWAN addresses 303 4.3. General Message Types 305 o *Confirmed messages*: The sender asks the receiver to acknowledge 306 the message. 308 o *Unconfirmed messages*: The sender does not ask the receiver to 309 acknowledge the message. 311 As SCHC defines its own acknowledgment mechanisms, SCHC does not 312 require to use confirmed messages. 314 4.4. LoRaWAN MAC Frames 316 o *JoinRequest*: This message is used by a end-device to join a 317 network. It contains the end-device's unique identifier devEUI 318 and a random nonce that will be used for session key derivation. 320 o *JoinAccept*: To on-board a end-device, the Network Server 321 responds to the JoinRequest end-device's message with a JoinAccept 322 message. That message is encrypted with the end-device's AppKey 323 and contains (amongst other fields) the major network's settings 324 and a network random nonce used to derive the session keys. 326 o *Data* 328 5. SCHC-over-LoRaWAN 330 5.1. LoRaWAN FPort 332 The LoRaWAN MAC layers features a frame port field in all frames. 333 This field (FPort) is 8-bit long and the values from 1 to 223 can be 334 used. It allows LoRaWAN network and application to identify data. 336 A fragmentation session with application payload transferred from 337 device to server, is called uplink fragmentation session. It uses 338 FPortUpShort or FPortUpDefault for data uplink and its associated 339 SCHC control downlinks. The other way, a fragmentation session with 340 application payload transferred from server to device, is called 341 downlink fragmentation session. It uses FPortDown for data downlink 342 and its associated SCHC control uplinks. 344 FPorts can use arbitrary values inside the allowed FPort range and 345 must be shared by the end-device, the Network Server and SCHC 346 gateway. The uplink and downlink SCHC ports must be different. In 347 order to improve interoperability, it is recommended to use: 349 o FPortUpShort = 20 351 o FPortUpDefault = 21 353 o FPortDown = 22 355 Those are recommended values and are application defined. Also 356 application can have multiple fragmentation session between a device 357 and one or several SCHC gateways. A set of three FPort values is 358 required for each gateway instance the device is required to 359 communicate with. 361 The only uplink messages using the FPortDown port are the 362 fragmentation SCHC control messages of a downlink fragmentation 363 session (ex ACKs). Similarly, the only downlink messages using the 364 FPortUpShort or FPortUpDefault ports are the fragmentation SCHC 365 control messages of an uplink fragmentation session. 367 5.2. Rule ID management 369 SCHC-over-LoRaWAN SHOULD support encoding RuleID on 6 bits (64 370 possible rules). 372 The RuleID 0 is reserved for fragmentation. The RuleID 63 is used to 373 tag packets for which SCHC compression was not possible (no matching 374 Rule was found). 376 The remaining RuleIDs are available for compression. RuleIDs are 377 shared between uplink and downlink sessions. A RuleID different from 378 0 means that the fragmentation is not used, thus the packet should be 379 send to C/D layer. 381 5.3. IID computation 383 As LoRaWAN network uses unique EUI-64 per end-device, the Interface 384 IDentifier is the LoRaWAN DevEUI. It is compliant with [RFC4291] and 385 IID starting with binary 000 must enforce the 64-bits rule. TODO: 386 Derive IID from DevEUI with privacy constraints ? Ask working group ? 388 5.4. Fragmentation 390 The L2 word size used by LoRaWAN is 1 byte (8 bits). The SCHC 391 fragmentation over LoRaWAN uses the ACK-on-Error for uplink 392 fragmentation and Ack-Always for downlink fragmentation. A LoRaWAN 393 end-device cannot support simultaneous interleaved fragmentation 394 sessions in the same direction (uplink or downlink). This means that 395 only a single fragmented IPv6 datagram may be transmitted and/or 396 received by the end-device at a given moment. 398 The fragmentation parameters are different for uplink and downlink 399 fragmentation sessions and are successively described in the next 400 sections. 402 5.5. DTag 404 A LoRaWAN device cannot interleave several fragmented SCHC datagrams. 405 This one bit field is used to distinguish two consecutive 406 fragmentation sessions. 408 _Note_: While it is used to recover faster from transmission errors, 409 it SHALL not be considered as the only way to distinguish two 410 fragmentation sessions. 412 5.5.1. Uplink fragmentation: From device to SCHC gateway 414 In that case the device is the fragmentation transmitter, and the 415 SCHC gateway the fragmentation receiver. Two fragmentation rules are 416 defined regarding the *FPort*: 418 o *FPortUpShort*: SCHC header is only one byte. Used when 419 fragmentation is required and payload size is less than 381 bytes. 421 o *FPortUpDefault*: SCHC header is two bytes. Used for all other 422 cases: no fragmentation required or payload size is between 382 423 and 1524 byte. 425 *Both rules share common parameters:* 427 o *SCHC fragmentation reliability mode*: "ACK-on-Error" 429 o *DTag*: size is 1 bit. 431 o *FCN*: The FCN field is encoded on N = 7 bits, so WINDOW_SIZE = 432 127 tiles are allowed in a window (FCN=All-1 is reserved for 433 SCHC). 435 o *MIC calculation algorithm*: CRC32 using 0xEDB88320 (i.e. the 436 reverse representation of the polynomial used e.g. in the Ethernet 437 standard [RFC3385]) as suggested in 438 [I-D.ietf-lpwan-ipv6-static-context-hc]. 440 o *MAX_ACK_REQUESTS*: 8 442 o *Tile*: size is 3 bytes (24 bits) 444 o *Retransmission and inactivity timers*: LoRaWAN end-devices do not 445 implement a "retransmission timer". At the end of a window or a 446 fragmentation session, corresponding ACK(s) is (are) transmitted 447 by the network gateway (LoRaWAN application server) in the RX1 or 448 RX2 receive slot of end-device. If this ACK is not received the 449 end-device sends an all-0 (or an all-1) fragment with no payload 450 to request an SCHC ACK retransmission. The periodicity between 451 retransmission of the all-0/all-1 fragments is device/application 452 specific and may be different for each device (not specified). 453 The SCHC gateway implements an "inactivity timer". The default 454 recommended duration of this timer is 12 hours. This value is 455 mainly driven by application requirements and may be changed by 456 the application. 458 *The following fields are different:* 460 o RuleID size 462 o Window index size W 464 5.5.1.1. FPortUpShort - 1 byte header 466 In that case RuleID size is 0, the rule is the FPort=FPortUpShort and 467 only fragmented payload can be transported. 469 o *RuleID*: size is 0 bit in SCHC header, not used. 471 o *Window index*: encoded on W = 0 bit, not used 473 With this set of parameters, the SCHC fragment header overhead is 1 474 byte (8 bits). MTU is: _127 tiles * 3 bytes per tile = 381 bytes_ 476 *Regular fragments* 478 | DTag | FCN | Payload | 479 + ----- + ------ + ------- + 480 | 1 bit | 7 bits | | 482 Figure 5: All fragment except the last one. Header size is 8 bits (1 483 byte). 485 *SCHC ACK* 487 | DTag | C | Encoded bitmap (if C = 0) | Padding (0s) | 488 + ----- + ----- + ------------------------- + ------------ + 489 | 1 bit | 1 bit | 0 to 127 bits | 7 or 0 bits | 491 Figure 6: SCHC ACK format, failed mic check. 493 5.5.1.2. FPortUpDefault - 2 bytes header 495 o *RuleID*: size is 6 bits (64 possible rules, 62 available for 496 compression) 498 o *Window index*: encoded on W = 2 bits. So 4 windows are 499 available. 501 With this set of parameters, the SCHC fragment header overhead is 2 502 bytes (16 bits). MTU is: _4 windows * 127 tiles * 3 bytes per tile = 503 1524 bytes_ 505 _Note_: Even if it is less efficient, this rule can also be used for 506 fragmented payload size less than 382 bytes. 508 *Regular fragments* 510 | RuleID | DTag | W | FCN | Payload | 511 + ------ + ----- + ------ + ------ + ------- + 512 | 6 bits | 1 bit | 2 bits | 7 bits | | 514 Figure 7: All fragment except the last one. Header size is 16 bits 515 (2 bytes). 517 *Last fragment (All-1)* 519 | RuleID | DTag | W | FCN=All-1 | MIC | Payload | 520 + ------ + ----- + ------ + --------- + ------- + ----------------- + 521 | 6 bits | 1 bit | 2 bits | 7 bits | 32 bits | Last tile, if any | 523 Figure 8: All-1 fragment detailed format for the last fragment. 525 *SCHC ACK* 527 | RuleID | DTag | W | C | Encoded bitmap (if C = 0) | 528 + ------ + ----- + ----- + ----- + ------------------------- + 529 | 6 bits | 1 bit | 2 bit | 1 bit | 0 to 127 bits | 531 Figure 9: SCHC formats, failed MIC check. 533 *Receiver-Abort* 535 | RuleID | DTag | W = b'11 | C = 1 | b'111111 | 0xFF (all 1's) | 536 + ------ + ----- + -------- + ------+--------- + ---------------+ 537 | 6 bits | 1 bit | 2 bits | 1 bit | 6 bits | 8 bits | 539 Figure 10: Receiver-Abort format. 541 *SCHC acknowledge request* 542 | RuleID | DTag | W | FCN = b'0000000 | 543 + ------ + ----- + ------ + --------------- + 544 | 6 bits | 1 bit | 2 bits | 7 bits | 546 Figure 11: SCHC ACK REQ format. 548 5.5.2. Downlink fragmentation: From SCHC gateway to device 550 In that case the device is the fragmentation receiver, and the SCHC 551 gateway the fragmentation transmitter. The following fields are 552 common to all devices. 554 o *SCHC fragmentation reliability mode*: ACK-Always. 556 o *RuleID*: size is 6 bits (64 possible rules, 62 for compression). 558 o *Window index*: encoded on W=1 bit, as per 559 [I-D.ietf-lpwan-ipv6-static-context-hc]. 561 o *DTag*: Not used, so its size is 0 bit. 563 o *FCN*: The FCN field is encoded on N=1 bits, so WINDOW_SIZE = 1 564 tile (FCN=All-1 is reserved for SCHC). 566 o *MIC calculation algorithm*: CRC32 using 0xEDB88320 (i.e. the 567 reverse representation of the polynomial used e.g. in the Ethernet 568 standard [RFC3385]), as per 569 [I-D.ietf-lpwan-ipv6-static-context-hc]. 571 o *MAX_ACK_REQUESTS*: 8 573 As only 1 tile is used, its size can change for each downlink, and 574 will be maximum available MTU minus header (1 byte) 576 _Note_: The Fpending bit included in LoRaWAN protocol SHOULD not be 577 used for SCHC-over-LoRaWAN protocol. It might be set by the Network 578 Server for other purposes in but not SCHC needs. 580 *Regular fragments* 581 | RuleID | W | FCN = b'0 | Payload | 582 + ------ + ----- + --------- + ------- + 583 | 6 bits | 1 bit | 1 bits | X bytes | 585 Figure 12: All fragments but the last one. Header size 1 byte (8 586 bits). 588 *Last fragment (All-1)* 590 | RuleID | W | FCN = b'1 | MIC | Payload | 591 + ------ + ----- + --------- + ------- + ----------------- + 592 | 6 bits | 1 bit | 1 bit | 32 bits | Last tile, if any | 594 Figure 13: All-1 SCHC ACK detailed format for the last fragment. 596 *SCHC acknowledge* 598 | RuleID | W | C = b'1 | 599 + ------ + ----- + ------- + 600 | 6 bits | 1 bit | 1 bit | 602 Figure 14: SCHC ACK format, MIC is correct. 604 *Receiver-Abort* 606 | RuleID | W | C = b'0 | b'11111111 | 607 + ------ + ----- + ------- + ---------- + 608 | 6 bits | 1 bit | 1 bits | 8 bits | 610 Figure 15: Receiver-Abort packet (following an all-1 packet with 611 incorrect MIC). 613 Class A and classB&C end-devices do not manage retransmissions and 614 timers in the same way. 616 5.5.2.1. ClassA end-devices 618 Class A end-devices can only receive in an RX slot following the 619 transmission of an uplink. Therefore there cannot be a concept of 620 "retransmission timer" for an SCHC gateway. The SCHC gateway cannot 621 initiate communication to a classA end-device. 623 The device replies with an ACK message to every single fragment 624 received from the SCHC gateway (because the window size is 1). 626 Following the reception of a FCN=0 fragment (fragment that is not the 627 last fragment of the packet or ACK-request, but the end of a window), 628 the device MUST transmit the SCHC ACK fragment until it receives the 629 fragment of the next window. The device shall transmit up to 630 MAX_ACK_REQUESTS ACK messages before aborting. The device should 631 transmit those ACK as soon as possible while taking into 632 consideration potential local radio regulation on duty-cycle, to 633 progress the fragmentation session as quickly as possible. The ACK 634 bitmap is 1 bit long and is always 1. 636 Following the reception of a FCN=All-1 fragment (the last fragment of 637 a datagram) and if the MIC is correct, the device shall transmit the 638 ACK with the "MIC is correct" indicator bit set (C=1). This message 639 might be lost therefore the SCHC gateway may request a retransmission 640 of this ACK in the next downlink. The device SHALL keep this ACK 641 message in memory until it receives a downlink, on SCHC FPortDown 642 from the SCHC gateway different from an ACK-request: it indicates 643 that the SCHC gateway has received the ACK message. 645 Following the reception of a FCN=All-1 fragment (the last fragment of 646 a datagram), if all fragments have been received and the MIC is NOT 647 correct, the device shall transmit a Receiver-Abort fragment. The 648 device SHALL keep this Abort message in memory until it receives a 649 downlink, on SCHC FPortDown, from the SCHC gateway different from an 650 ACK-request indicating that the SCHC gateway has received the Abort 651 message. The fragmentation receiver (device) does not implement 652 retransmission timer and inactivity timer. 654 The fragmentation sender (the SCHC gateway) implements an inactivity 655 timer with default duration of 12 hours. Once a fragmentation 656 session is started, if the SCHC gateway has not received any ACK or 657 Receiver-Abort message 12 hours after the last message from the 658 device was received, the SCHC gateway may flush the fragmentation 659 context. For devices with very low transmission rates (example 1 660 packet a day in normal operation) , that duration may be extended, 661 but this is application specific. 663 5.5.2.2. Class B or C end-devices 665 Class B&C end-devices can receive in scheduled RX slots or in RX 666 slots following the transmission of an uplink. The device replies 667 with an ACK message to every single fragment received from the SCHC 668 gateway (because the window size is 1). Following the reception of a 669 FCN=0 fragment (fragment that is not the last fragment of the packet 670 or ACK-request), the device MUST always transmit the corresponding 671 SCHC ACK message even if that fragment has already been received. 672 The ACK bitmap is 1 bit long and is always 1. If the SCHC gateway 673 receives this ACK, it proceeds to send the next window fragment. If 674 the retransmission timer elapses and the SCHC gateway has not 675 received the ACK of the current window it retransmits the last 676 fragment. The SCHC gateway tries retransmitting up to 677 MAX_ACK_REQUESTS times before aborting. 679 Following the reception of a FCN=All-1 fragment (the last fragment of 680 a datagram) and if the MIC is correct, the device shall transmit the 681 ACK with the "MIC is correct" indicator bit set. If the SCHC gateway 682 receives this ACK, the current fragmentation session has succeeded 683 and its context can be cleared. 685 If the retransmission timer elapses and the SCHC gateway has not 686 received the SCHC ACK it retransmits the last fragment with the 687 payload (not an ACK-request without payload). The SCHC gateway tries 688 retransmitting up to MAX_ACK_REQUESTS times before aborting. 690 The device SHALL keep the SCHC ACK message in memory until it 691 receives a downlink from the SCHC gateway different from the last 692 (FCN>0 and different DTag) fragment indicating that the SCHC gateway 693 has received the ACK message. 695 Following the reception of a FCN=All-1 fragment (the last fragment of 696 a datagram), if all fragments have been received and if the MIC is 697 NOT correct, the device shall transmit a Receiver-Abort fragment. 698 The retransmission timer is used by the SCHC gateway (the sender), 699 the optimal value is very much application specific but here are some 700 recommended default values. For classB end-devices, this timer 701 trigger is a function of the periodicity of the classB ping slots. 702 The recommended value is equal to 3 times the classB ping slot 703 periodicity. For classC end-devices which are nearly constantly 704 receiving, the recommended value is 30 seconds. This means that the 705 end-device shall try to transmit the ACK within 30 seconds of the 706 reception of each fragment. The inactivity timer is implemented by 707 the end-device to flush the context in-case it receives nothing from 708 the SCHC gateway over an extended period of time. The recommended 709 value is 12 hours for both classB&C end-devices. 711 6. Security considerations 713 This document is only providing parameters that are expected to be 714 better suited for LoRaWAN networks for 715 [I-D.ietf-lpwan-ipv6-static-context-hc]. As such, this parameters 716 does not contribute to any new security issues in addition of those 717 identified in [I-D.ietf-lpwan-ipv6-static-context-hc]. 719 Acknowledgements 721 Thanks to all those listed in the Contributors section for the 722 excellent text, insightful discussions, reviews and suggestions. 724 Contributors 726 Contributors ordered by family name. 728 o ins: V. Audebert name: Vincent AUDEBERT org: EDF R&D street: 7 bd 729 Gaspard Monge city: 91120 PALAISEAU country: FRANCE email: 730 vincent.audebert@edf.fr 732 o ins: J. Catalano name: Julien Catalano org: Kerlink street: 1 rue 733 Jacqueline Auriol city: 35235 Thorigne-Fouillard country: France 734 email: j.catalano@kerlink.fr 736 o ins: M. Coracin name: Michael Coracin org: Semtech street: 14 737 Chemin des Clos city: Meylan country: France email: 738 mcoracin@semtech.com 740 o ins: M. Le Gourrierec name: Marc Le Gourrierec org: SagemCom 741 street: 250 Route de l'Empereur city: 92500 Rueil Malmaison 742 country: FRANCE email: marc.legourrierec@sagemcom.com 744 o ins: N. Sornin name: Nicolas Sornin org: Semtech street: 14 745 Chemin des Clos city: Meylan country: France email: 746 nsornin@semtech.com 748 o ins: A. Yegin name: Alper Yegin org: Actility street: . city: 749 Paris, Paris country: France email: alper.yegin@actility.com 751 9. References 753 9.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, 757 DOI 10.17487/RFC2119, March 1997, 758 . 760 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 761 "Internet Protocol Small Computer System Interface (iSCSI) 762 Cyclic Redundancy Check (CRC)/Checksum Considerations", 763 RFC 3385, DOI 10.17487/RFC3385, September 2002, 764 . 766 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 767 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 768 2006, . 770 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 771 "Transmission of IPv6 Packets over IEEE 802.15.4 772 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 773 . 775 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 776 Header Compression (ROHC) Framework", RFC 5795, 777 DOI 10.17487/RFC5795, March 2010, 778 . 780 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 781 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 782 February 2014, . 784 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 785 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 786 . 788 9.2. Informative References 790 [I-D.ietf-lpwan-ipv6-static-context-hc] 791 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 792 Zuniga, "Static Context Header Compression (SCHC) and 793 fragmentation for LPWAN, application to UDP/IPv6", draft- 794 ietf-lpwan-ipv6-static-context-hc-19 (work in progress), 795 July 2019. 797 [lora-alliance-spec] 798 Alliance, L., "LoRaWAN Specification Version V1.0.3", 799 . 802 Appendix A. Examples 804 A.1. Uplink - Compression example - No fragmentation 806 Figure 16 is representing an applicative payload going through SCHC, 807 no fragmentation required 809 An applicative payload of 78 bytes is passed to SCHC compression layer using 810 rule 1, allowing to compress it to 40 bytes and 5 bits: 21 bits residue + 38 bytes 811 payload. 813 | RuleID | Compression residue | Payload | Padding=0b000 | 814 + ------ + ------------------- + --------- + ------------- + 815 | 1 | 21 bits | 38 bytes | 3 bits | 817 The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by 818 LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for 819 fragmentation. The payload will be transmitted through FPortUpDefault 821 | LoRaWAN Header | RuleID | Compression residue | Payload | Padding=b'000 | 822 + -------------- + ------ + ------------------- + --------- + ------------- + 823 | XXXX | 1 | 21 bits | 38 bytes | 3 bits | 825 Figure 16: Uplink example: compression without fragmentation 827 A.2. Uplink - Compression and fragmentation example 829 Figure 17 is representing an applicative payload going through SCHC, 830 with fragmentation. 832 An applicative payload of 478 bytes is passed to SCHC compression layer using 833 rule 1, allowing to compress it to 440 bytes: 21 bits residue + 138 bytes 834 payload. 836 | RuleID | Compression residue | Payload | 837 + ------ + ------------------- + --------- + 838 | 1 | 21 bits | 138 bytes | 840 Given the size of the payload, FPortUpDefault will be used. 841 The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by 842 LoRaWAN protocol: 9 bytes are available for SCHC payload. 843 SCHC header is 2 bytes so 2 tiles are send in first fragment. 845 | LoRaWAN Header | FOpts | RuleID | DTag | W | FCN | 2 tiles | 846 + -------------- + ------- + ------ + ----- + ------ + ------ + ------- + 847 | XXXX | 2 bytes | 0 | 0 | 0 | 126 | 6 bytes | 849 Content of the two tiles is: 850 | RuleID | Compression residue | Payload | 851 + ------ + ------------------- + ------------------ + 852 | 1 | 21 bits | 2 bytes + 5 bits | 854 Next transmission MTU is 242 bytes, no FOpts. 80 tiles are transmitted: 856 | LoRaWAN Header | RuleID | DTag | W | FCN | 80 tiles | 857 + -------------- + ------ + ----- + ------ + ------ + --------- + 858 | XXXX | 0 | 0 | 0 | 124 | 240 bytes | 860 Next transmission MTU is 242 bytes, no FOpts. All 65 remaining tiles are 861 transmitted, last tile is only 2 bytes. Padding is added for the remaining 6 bits. 863 | LoRaWAN Header | RuleID | DTag | W | FCN | MIC | 65 tiles | Padding=b'000 | 864 + -------------- + ------ + ----- + ------ + ------ + ----- + --------- + ---------------- + 865 | XXXX | 0 | 0 | 0 | 127 | CRC32 | 194 bytes | 3 bits | 867 All packets have been received by the SCHC gateway, computed MIC is correct so 868 the following ACK is send to the device: 870 | LoRaWAN Header | RuleID | DTag | W | C | 871 + -------------- + ------ + ----- + ------ + --- + 872 | XXXX | 0 | 0 | 0 | 1 | 874 Figure 17: Uplink example: compression and fragmentation 876 A.3. Downlink 878 An applicative payload of 43 bytes is passed to SCHC compression layer using 879 rule 1, allowing to compress it to 24 bytes and 5 bits: 21 bits residue + 22 bytes 880 payload. 882 | RuleID | Compression residue | Payload | 883 + ------ + ------------------- + --------- + 884 | 1 | 21 bits | 18 bytes | 886 The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by 887 LoRaWAN protocol: 9 bytes are available for SCHC payload => it has to be fragmented. 889 | LoRaWAN Header | FOpts | RuleID | W | FCN | 1 tile | 890 + -------------- + ------- + ------ + ------ + ------ + ------- + 891 | XXXX | 2 bytes | 0 | 0 | 0 | 8 bytes | 892 Content of the two tiles is: 893 | RuleID | Compression residue | Payload | 894 + ------ + ------------------- + ------------------ + 895 | 1 | 21 bits | 2 bytes + 5 bits | 897 The receiver answers with an SCHC ACK 899 | RuleID | W = 0 | C = b'1 | 900 + ------ + ----- + ------- + 901 | 6 bits | 1 bit | 1 bit | 903 The second downlink is send, no FOpts: 905 | LoRaWAN Header | RuleID | W | FCN | 1 tile | 906 + -------------- + ------ + ------ + ------ + -------- + 907 | XXXX | 0 | 1 | 0 | 10 bytes | 909 The receiver answers with an SCHC ACK 911 | RuleID | W = 1 | C = b'1 | 912 + ------ + ----- + ------- + 913 | 6 bits | 1 bit | 1 bit | 915 The third downlink is send, no FOpts: 917 | LoRaWAN Header | RuleID | W | FCN | 1 tile | 918 + -------------- + ------ + ------ + ------ + -------- + 919 | XXXX | 0 | 0 | 0 | 10 bytes | 921 The receiver answers with an SCHC ACK 923 | RuleID | W = 0 | C = 1 | 924 + ------ + ----- + ------- + 925 | 6 bits | 1 bit | 1 bit | 927 The last downlink is send, no FOpts: 929 | LoRaWAN Header | RuleID | W | FCN | 1 tile | 930 + -------------- + ------ + ------ + ------ + -------- + 931 | XXXX | 0 | 1 | 1 | 2 bytes | 933 The receiver answers with an SCHC ACK 935 | RuleID | W = 1 | C = 1 | 936 + ------ + ----- + ------- + 937 | 6 bits | 1 bit | 1 bit | 939 Figure 18: Downlink example: compression and fragmentation 941 Appendix B. Note 943 Authors' Addresses 945 Olivier Gimenez (editor) 946 Semtech 947 14 Chemin des Clos 948 Meylan 949 France 951 Email: ogimenez@semtech.com 953 Ivaylo Petrov (editor) 954 Acklio 955 2bis rue de la Chataigneraie 956 35510 Cesson-Sevigne Cedex 957 France 959 Email: ivaylo@ackl.io