idnits 2.17.1 draft-petrov-lpwan-ipv6-schc-over-lorawan-03.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 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2019) is 1889 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4944' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 582, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-18 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group N. Sornin, Ed. 3 Internet-Draft M. Coracin 4 Intended status: Informational Semtech 5 Expires: August 17, 2019 I. Petrov 6 Acklio 7 A. Yegin 8 Actility 9 J. Catalano 10 Kerlink 11 V. Audebert 12 EDF R&D 13 February 13, 2019 15 Static Context Header Compression (SCHC) over LoRaWAN 16 draft-petrov-lpwan-ipv6-schc-over-lorawan-03 18 Abstract 20 The Static Context Header Compression (SCHC) specification describes 21 generic header compression and fragmentation techniques for LPWAN 22 (Low Power Wide Area Networks) technologies. SCHC is a generic 23 mechanism designed for great flexibility, so that it can be adapted 24 for any of the LPWAN technologies. 26 This document provides the adaptation of SCHC for use in LoRaWAN 27 networks, and provides elements such as efficient parameterization 28 and modes of operation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 17, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Static Context Header Compression Overview . . . . . . . . . 3 67 4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Device classes (A, B, C) and interactions . . . . . . . . 5 69 4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 6 70 4.3. General Message Types . . . . . . . . . . . . . . . . . . 7 71 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 7 72 5. SCHC over LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Rule ID management . . . . . . . . . . . . . . . . . . . 7 74 5.2. IID computation . . . . . . . . . . . . . . . . . . . . . 8 75 5.3. No compression packets are sent using Rule ID 7. . . . . 8 76 5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 77 5.4.1. Uplink fragmentation: From device to gateway . . . . 8 78 5.4.2. Downlinks: From gateway to device . . . . . . . . . . 9 79 6. Security considerations . . . . . . . . . . . . . . . . . . . 13 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 85 Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 The Static Context Header Compression (SCHC) specification 91 [I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header 92 compression and fragmentation techniques that can be used on all 93 LPWAN (Low Power Wide Area Networks) technologies defined in 94 [I-D.ietf-lpwan-overview]. Even though those technologies share a 95 great number of common features like start-oriented topologies, 96 network architecture, devices with mostly quite predictable 97 communications, etc; they do have some slight differences in respect 98 of payload sizes, reactiveness, etc. 100 SCHC gives a generic framework that enables those devices to 101 communicate with other Internet networks. However, for efficient 102 performance, some parameters and modes of operation need to be set 103 appropriately for each of the LPWAN technologies. 105 This document describes the efficient parameters and modes of 106 operation when SCHC is used over LoRaWAN networks. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This section defines the terminology and acronyms used in this 115 document. For all other definitions, please look up the SCHC 116 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 118 o DevEUI: an IEEE EUI-64 identifier used to identify the device 119 during the procedure while joining the network (Join Procedure) 121 o DevAddr: a 32-bit non-unique identifier assigned to a device 122 statically or dynamically after a Join Procedure (depending on the 123 activation mode) 125 o TBD: all significant LoRaWAN-related terms. 127 3. Static Context Header Compression Overview 129 This section contains a short overview of Static Context Header 130 Compression (SCHC). For a detailed description, refer to the full 131 specification [I-D.ietf-lpwan-ipv6-static-context-hc]. 133 Static Context Header Compression (SCHC) avoids context 134 synchronization, which is the most bandwidth-consuming operation in 135 other header compression mechanisms such as RoHC [RFC5795]. Based on 136 the fact that the nature of data flows is highly predictable in LPWAN 137 networks, some static contexts may be stored on the Device (Dev). 138 The contexts must be stored in both ends, and it can either be 139 learned by a provisioning protocol or by out of band means or it can 140 be pre-provisioned, etc. The way the context is learned on both 141 sides is out of the scope of this document. 143 Dev App 144 +--------------+ +--------------+ 145 |APP1 APP2 APP3| |APP1 APP2 APP3| 146 | | | | 147 | UDP | | UDP | 148 | IPv6 | | IPv6 | 149 | | | | 150 | SCHC C/D | | | 151 | (context) | | | 152 +-------+------+ +-------+------+ 153 | +--+ +----+ +---------+ . 154 +~~ |RG| === |NGW | === |SCHC C/D |... Internet .. 155 +--+ +----+ |(context)| 156 +---------+ 158 Figure 1: Architecture 160 Figure 1 represents the architecture for compression/decompression, 161 it is based on [I-D.ietf-lpwan-overview] terminology. The Device is 162 sending applications flows using IPv6 or IPv6/UDP protocols. These 163 flows are compressed by an Static Context Header Compression 164 Compressor/Decompressor (SCHC C/D) to reduce headers size. Resulting 165 information is sent on a layer two (L2) frame to a LPWAN Radio 166 Network (RG) which forwards the frame to a Network Gateway (NGW). 167 The NGW sends the data to a SCHC C/D for decompression which shares 168 the same rules with the Dev. The SCHC C/D can be located on the 169 Network Gateway (NGW) or in another place as long as a tunnel is 170 established between the NGW and the SCHC C/D. The SCHC C/D in both 171 sides must share the same set of Rules. After decompression, the 172 packet can be sent on the Internet to one or several LPWAN 173 Application Servers (App). 175 The SCHC C/D process is bidirectional, so the same principles can be 176 applied in the other direction. 178 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 179 Server, and the SCHC C/D can be embedded in different places, for 180 example in the Network Server and/or the Application Server. 182 Next steps for this section: detailed overview of the LoRaWAN 183 architecture and its mapping to the SCHC architecture. 185 4. LoRaWAN Architecture 187 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 188 is described in [I-D.ietf-lpwan-overview]. Mapping between the LPWAN 189 architecture entities as described in 191 [I-D.ietf-lpwan-ipv6-static-context-hc] and the ones in 192 [lora-alliance-spec] is as follows: 194 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 195 actuators, etc.). There can be a very high density of devices per 196 radio gateway. This entity maps to the LoRaWAN End-device. 198 o The Radio Gateway (RGW), which is the end point of the constrained 199 link. This entity maps to the LoRaWAN Gateway. 201 o The Network Gateway (NGW) is the interconnection node between the 202 Radio Gateway and the Internet. This entity maps to the LoRaWAN 203 Network Server. 205 o LPWAN-AAA Server, which controls the user authentication and the 206 applications. This entity maps to the LoRaWAN Join Server. 208 o Application Server (App). The same terminology is used in LoRaWAN. 210 () () () | +------+ 211 () () () () / \ +---------+ | Join | 212 () () () () () / \======| ^ |===|Server| +-----------+ 213 () () () | | <--|--> | +------+ |Application| 214 () () () () / \==========| v |=============| Server | 215 () () () / \ +---------+ +-----------+ 216 End-Devices Gateways Network Server 218 Figure 2: LPWAN Architecture 220 SCHC C/D (Compressor/Decompressor) and SCHC Fragmentation are 221 performed on the LoRaWAN End-device and the Application Server. 222 While the point-to-point link between the End-device and the 223 Application Server constitutes single IP hop, the ultimate end-point 224 of the IP communication may be an Internet node beyond the 225 Application Server. In other words, the LoRaWAN Application Server 226 acts as the first hop IP router for the End-device. Note that the 227 Application Server and Network Server may be co-located, which 228 effectively turns the Network/Application Server into the first hop 229 IP router. 231 4.1. Device classes (A, B, C) and interactions 233 The LoRaWAN MAC layer supports 3 classes of devices named A,B and C. 234 All devices implement the classA, some devices implement classA+B or 235 class A+C. ClassB and classC are mutually exclusive. 237 o *ClassA*: The classA is the simplest class of devices. The device 238 is allowed to transmit at any time, randomly selecting a 239 communication channel. The network may reply with a downlink in 240 one of the 2 receive windows immediately following the uplinks. 241 Therefore, the network cannot initiate a downlink, it has to wait 242 for the next uplink from the device to get a downlink opportunity. 243 The classA is the lowest power device class. 245 o *ClassB*: classB devices implement all the functionalities of 246 classA devices, but also schedule periodic listen windows. 247 Therefore, as opposed the classA devices, classB devices can 248 receive downlink that are initiated by the network and not 249 following an uplink. There is a trade-off between the periodicity 250 of those scheduled classB listen windows and the power consumption 251 of the device. The lower the downlink latency, the higher the 252 power consumption. 254 o *ClassC*: classC devices implement all the functionalities of 255 classA devices, but keep their receiver open whenever they are not 256 transmitting. ClassC devices can receive downlinks at any time at 257 the expense of a higher power consumption. Battery powered 258 devices can only operate in classC for a limited amount of time 259 (for example for a firmware upgrade over the air). Most of the 260 classC devices are main powered (for example Smart Plugs). 262 4.2. Device addressing 264 LoRaWAN devices use a 32bits network address (devAddr) to communicate 265 with the network over the air. However that address might be reused 266 several time on the same network at the same time for different 267 devices. Devices using the same devAddr are distinguish by the 268 network server based on the cryptographic signature appended to every 269 single LoRaWAN MAC frame, as all devices use different security keys. 270 To communicate with the SCHC gateway the network server MUST identify 271 the devices by a unique 64bits device ID called the devEUI. Unlike 272 devAddr, devEUI is guaranteed to be unique for every single device 273 across all networks. The devEUI is assigned to the device during the 274 manufacturing process by the device's manufacturer. The devEUI is 275 built like an Ethernet MAC address by concatenating the 276 manufacturer's IEEE 24bits OUI field with a 40bits serial number. 277 The network server translates the devAddr into a devEUI in the uplink 278 direction and reciprocally on the downlink direction. 280 +--------+ +---------------+ +--------------------+ 281 | device | <=====> | Network Server| <====> | Application Server | 282 +--------+ devAddr +---------------+ devEUI +--------------------+ 284 Figure 3: LoRaWAN addresses 286 4.3. General Message Types 288 o Confirmed messages: 290 o Unconfirmed messages: 292 4.4. LoRaWAN MAC Frames 294 o JoinRequest 296 o JoinAccept 298 o Data 300 5. SCHC over LoRaWAN 302 5.1. Rule ID management 304 The LoRaWAN MAC layers features a port field in all frames. This 305 port field (FPort) is 8bit long and the values from 1 to 220 can be 306 used. SCHC over LoRaWAN uses 2 contiguous FPort value to separate 307 the uplink SCHC traffic from the downlink and avoid any confusion. 308 Those FPorts are called FPortUp and FPortDwn. Those FPorts can use 309 arbitrary values inside the allowed Fport range but must be shared by 310 the end-device and SCHC gateway. 312 SCHC over LoRAWAN SHOULD support encoding RuleID on 3 bits, there are 313 therefore 8 possible RuleIds on both uplink and downlink direction. 315 The RuleID 0 is reserved for fragmentation in both directions. The 7 316 remaining RuleIDs are available for IPV6 header compression. Uplink 317 (on FPortUp) and downlink (on FportDwn) RuleIDs are independent. The 318 same RuleID may have different meanings on the uplink and downlink 319 paths. 321 The only uplink messages using the FportDwn port are the 322 fragmentation SCHC ACKs messages of a downlink fragmentation session. 323 Similarly, the only downlink messages using the FportUp port are the 324 fragmentation SCHC ACKs messages of an uplink fragmentation session 326 5.2. IID computation 328 TBD (To discuss with the SCHC authors). 330 5.3. No compression packets are sent using Rule ID 7. 332 5.4. Fragmentation 334 The L2 word size used by LoRaWAN is 1 octet (8 bits). The SCHC 335 fragmentation over LoRaWAN exclusively uses the ACK-always mode. A 336 LoRaWAN device cannot support simultaneous interleaved fragmentation 337 sessions in the same direction (uplink or downlink). This means that 338 only a single fragmented IPV6 datagram may be transmitted and/or 339 received by the device at a given moment. The fragmentation 340 parameters are different for uplink and downlink fragmentation 341 sessions and are successively described in the next sections. 343 5.4.1. Uplink fragmentation: From device to gateway 345 In that case the device is the fragmentation transmitter, and the 346 SCHC gateway the fragmentation receiver. 348 o SCHC fragmentation reliability mode : "ACK_ALWAYS" 350 o Window size: 8, the FCN field is encoded on 3 bits 352 o DTag : 1bit. this field is used to clearly separate two 353 consecutive fragmentation sessions. A LoRaWAN device cannot 354 interleave several fragmented SCHC datagrams. 356 o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the 357 reverse representation of the polynomial used e.g. in the Ethernet 358 standard [RFC3385]) 360 o Retransmission Timer and inactivity Timer: LoRaWAN devices do not 361 implement a "retransmission timer". At the end of a window the 362 ACK corresponding to this window is transmitted by the network 363 gateway in the RX1 or RX2 receive slot of the device. If this ACK 364 is not received the device sends an all-0 (or an all-1) fragment 365 with no payload to request an ACK retransmission. The periodicity 366 between retransmission of the all-0/all-1 fragments is device/ 367 application specific and may be different for each device (not 368 specified). The gateway implements an "inactivity timer". The 369 default recommended duration of this timer is 12h. This value is 370 mainly driven by application requirements and may be changed. 372 | RuleID | DTag | W | FCN | Payload | 373 + ------ + ----- + ----- | ------ + ------- + 374 | 3 bits | 1 bit | 1 bit | 3 bits | | 376 Figure 4: All fragment except the last one. Header size is 8 bits. 378 | RuleID | DTag | W | FCN | MIC | Payload | 379 + ------ + ----- + ----- | ------ + ------- + ------- + 380 | 3 bits | 1 bit | 1 bit | 3 bits | 32 bits | | 382 Figure 5: All-1 fragment detailed format for the last fragment. 383 Header size is 8 bits. 385 The format of an all-0 or all-1 acknowledge is: 387 | RuleID | DTag | W | Encoded bitmap | Padding (0s) | 388 + ------ + ----- + ----- | -------------- + ------------ + 389 | 3 bits | 1 bit | 1 bit | 3 or 8 bits | 0 or 3 bits | 391 Figure 6: ACK format for All-0 windows. Header size is 1 or 2 bytes. 393 | RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) | 394 + ------ + ----- + ----- + ----- + ------------------------- + ------------ + 395 | 3 bits | 1 bit | 1 bit | 1 bit | 2 or 8 bits | 0 or 2 bits | 397 Figure 7: ACK format for All-1 windows. Header size is 1 or 2 bytes. 399 5.4.2. Downlinks: From gateway to device 401 In that case the device is the fragmentation receiver, and the SCHC 402 gateway the fragmentation transmitter. The following fields are 403 common to all devices. 405 o SCHC fragmentation reliability mode : ACK_ALWAYS 407 o Window size : 1 , The FCN field is encoded on 1 bits 409 o DTag : 1bit. This field is used to clearly separate two 410 consecutive fragmentation sessions. A LoRaWAN device cannot 411 interleave several fragmented SCHC datagrams. 413 o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the 414 reverse representation of the polynomial used e.g. in the Ethernet 415 standard [RFC3385]) 417 o MAX_ACK_REQUESTS : 8 419 | RuleID | DTag | W | FCN | Payload | 420 + ------ + ----- + ----- | ------ + ------- + ------- + 421 | 3 bits | 1 bit | 1 bit | 1 bits | X bytes + 2 bits | 423 Figure 8: All fragments but the last one. Header size is 6 bits. 425 | RuleID | DTag | W | FCN | MIC | Payload | Padding (0s) | 426 + ------ + ----- + ----- | ------ + ------- + ------- + ------------ + 427 | 3 bits | 1 bit | 1 bit | 1 bits | 32 bits | X bytes | 0 to 7 bits | 429 Figure 9: All-1 Fragment Detailed Format for the Last Fragment. 430 Header size is 6 bits. 432 The format of an all-0 or all-1 acknowledge is: 434 | RuleID | DTag | W | Encoded bitmap | Padding (0s) | 435 + ------ + ----- + ----- | -------------- + ------------ + 436 | 3 bits | 1 bit | 1 bit | 1 bit | 2 bits | 438 Figure 10: ACK format for All-0 windows. Header size is 8 bits. 440 | RuleID | DTag | W | C = 1 | Padding (0s) | 441 + ------ + ----- + ----- + ----- + ------------ + 442 | 3 bits | 1 bit | 1 bit | 1 bit | 2 bits | 444 Figure 11: ACK format for All-1 windows, MIC is correct. Header size 445 is 8 bits. 447 | RuleID | DTag | W | b'111 | 0xFF (all 1's) | 448 + ------ + ----- + ----- + ------ + -------------- + 449 | 3 bits | 1 bit | 1 bit | 3 bits | 8 bits | 451 Figure 12: Receiver ABORT packet (following an all-1 packet with 452 incorrect MIC). Header size is 16 bits. 454 Class A and classB&C devices do not manage retransmissions and timers 455 in the same way. 457 5.4.2.1. Class A devices 459 Class A devices can only receive in an RX slot following the 460 transmission of an uplink. Therefore there cannot be a concept of 461 "retransmission timer" for a gateway talking to classA devices for 462 downlink fragmentation. 464 The device replies with an ACK fragment to every single fragment 465 received from the gateway (because the window size is 1). Following 466 the reception of a FCN=0 fragment (fragment that is not the last 467 fragment of the packet or ACK-request), the device MUST transmit the 468 ACK fragment until it receives the fragment of the next window. The 469 device shall transmit up to MAX_ACK_REQUESTS ACK fragments before 470 aborting. The device should transmit those ACK as soon as possible 471 while taking into consideration eventual local radio regulation on 472 duty-cycle, to progress the fragmentation session as quickly as 473 possible. The ACK bitmap is 1 bit long and is always 1. 475 Following the reception of a FCN=1 fragment (the last fragment of a 476 datagram) and if the MIC is correct, the device shall transmit the 477 ACK with the "MIC is correct" indicator bit set. This message might 478 be lost therefore the gateway may request a retransmission of this 479 ACK in the next downlink. The device SHALL keep this ACK message in 480 memory until it receives a downlink from the gateway different from 481 an ACK-request indicating that the gateway has received the ACK 482 message. 484 Following the reception of a FCN=1 fragment (the last fragment of a 485 datagram) and if the MIC is NOT correct, the device shall transmit a 486 receiver-ABORT fragment. The device SHALL keep this ABORT message in 487 memory until it receives a downlink from the gateway different from 488 an ACK-request indicating that the gateway has received the ABORT 489 message. The fragmentation receiver (device) does not implement 490 retransmission timer and inactivity timer. 492 The fragmentation sender (the gateway) implements an inactivity timer 493 with default duration 12 hours. Once a fragmentation session is 494 started, if the gateway has not received any ACK or receiver-ABORT 495 message 12 hours after the last message from the device was received, 496 the gateway may flush the fragmentation context. For devices with 497 very low transmission rates (example 1 packet a day in normal 498 operation) , that duration may be extended, but this is application 499 specific. 501 5.4.2.2. Class B or C devices 503 Class B&C devices can receive in scheduled RX slots or in RX slots 504 following the transmission of an uplink. The device replies with an 505 ACK fragment to every single fragment received from the gateway 506 (because the window size is 1). Following the reception of a FCN=0 507 fragment (fragment that is not the last fragment of the packet or 508 ACK-request), the device MUST always transmit the corresponding ACK 509 fragment even if that fragment has already been received. The ACK 510 bitmap is 1 bit long and is always 1. If the gateway receives this 511 ACK, it proceeds to send the next window fragment If the 512 retransmission timer elapses and the gateway has not received the ACK 513 of the current window it retransmits the last fragment. The gateway 514 tries retransmitting up to MAX_ACK_REQUESTS times before aborting. 516 Following the reception of a FCN=1 fragment (the last fragment of a 517 datagram) and if the MIC is correct, the device shall transmit the 518 ACK with the "MIC is correct" indicator bit set. If the gateway 519 receives this ACK, the current fragmentation session has succeeded 520 and its context can be cleared. 522 If the retransmission timer elapses and the gateway has not received 523 the all-1 ACK it retransmits the last fragment with the payload (not 524 an ACK-request without payload). The gateway tries retransmitting up 525 to MAX_ACK_REQUESTS times before aborting. 527 The device SHALL keep the all-1 ACK message in memory until it 528 receives a downlink from the gateway different from the last (FCN=1) 529 fragment indicating that the gateway has received the ACK message. 530 Following the reception of a FCN=1 fragment (the last fragment of a 531 datagram) and if the MIC is NOT correct, the device shall transmit a 532 receiver-ABORT fragment. The retransmission timer is used by the 533 gateway (the sender), the optimal value is very much application 534 specific but here are some recommended default values. For classB 535 devices, this timer trigger is a function of the periodicity of the 536 classB ping slots. The recommended value is equal to 3 times the 537 classB ping slot periodicity. For classC devices which are nearly 538 constantly receiving, the recommended value is 30 seconds. This 539 means that the device shall try to transmit the ACK within 30 seconds 540 of the reception of each fragment. The inactivity timer is 541 implemented by the device to flush the context in-case it receives 542 nothing from the gateway over an extended period of time. The 543 recommended value is 12 hours for both classB&C devices. 545 6. Security considerations 547 As this document is only providing parameters that are expected to be 548 better suited for LoRaWAN networks for 549 [I-D.ietf-lpwan-ipv6-static-context-hc]. As such, this parameters 550 does not contribute to any new security issues in addition of those 551 identified in [I-D.ietf-lpwan-ipv6-static-context-hc]. 553 7. Acknowledgements 555 TBD 557 8. References 559 8.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, 563 DOI 10.17487/RFC2119, March 1997, 564 . 566 [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, 567 "Internet Protocol Small Computer System Interface (iSCSI) 568 Cyclic Redundancy Check (CRC)/Checksum Considerations", 569 RFC 3385, DOI 10.17487/RFC3385, September 2002, 570 . 572 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 573 "Transmission of IPv6 Packets over IEEE 802.15.4 574 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 575 . 577 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 578 Header Compression (ROHC) Framework", RFC 5795, 579 DOI 10.17487/RFC5795, March 2010, 580 . 582 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 583 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 584 February 2014, . 586 8.2. Informative References 588 [I-D.ietf-lpwan-ipv6-static-context-hc] 589 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 590 Zuniga, "LPWAN Static Context Header Compression (SCHC) 591 and fragmentation for IPv6 and UDP", draft-ietf-lpwan- 592 ipv6-static-context-hc-18 (work in progress), December 593 2018. 595 [I-D.ietf-lpwan-overview] 596 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 597 overview-10 (work in progress), February 2018. 599 [lora-alliance-spec] 600 Alliance, L., "LoRaWAN Specification Version V1.0.2", 601 . 605 Appendix A. Examples 607 Appendix B. Note 609 Authors' Addresses 611 Nicolas Sornin (editor) 612 Semtech 613 14 Chemin des Clos 614 Meylan 615 France 617 Email: nsornin@semtech.com 619 Michael Coracin 620 Semtech 621 14 Chemin des Clos 622 Meylan 623 France 625 Email: mcoracin@semtech.com 627 Ivaylo Petrov 628 Acklio 629 2bis rue de la Chataigneraie 630 35510 Cesson-Sevigne Cedex 631 France 633 Email: ivaylo@ackl.io 634 Alper Yegin 635 Actility 636 . 637 Paris, Paris 638 France 640 Email: alper.yegin@actility.com 642 Julien Catalano 643 Kerlink 644 1 rue Jacqueline Auriol 645 35235 Thorigne-Fouillard 646 France 648 Email: j.catalano@kerlink.fr 650 Vincent AUDEBERT 651 EDF R&D 652 7 bd Gaspard Monge 653 91120 PALAISEAU 654 FRANCE 656 Email: vincent.audebert@edf.fr