idnits 2.17.1 draft-zuniga-lpwan-schc-over-sigfox-05.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 173: '... The RuleID MUST be sent at the begi...' RFC 2119 keyword, line 220: '... No-ACK is RECOMMENDED to be used fo...' RFC 2119 keyword, line 238: '...r computing the MIC field MUST be TBD....' RFC 2119 keyword, line 246: '... ACK-on-Error is RECOMMENDED for large...' RFC 2119 keyword, line 262: '... RECOMMENDED....' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 05, 2018) is 1998 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-17 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Informational C. Gomez 5 Expires: May 9, 2019 Universitat Politecnica de Catalunya 6 L. Toutain 7 IMT-Atlantique 8 November 05, 2018 10 SCHC over Sigfox LPWAN 11 draft-zuniga-lpwan-schc-over-sigfox-05 13 Abstract 15 The Static Context Header Compression (SCHC) specification describes 16 a header compression scheme and a fragmentation functionality for Low 17 Power Wide Area Network (LPWAN) technologies. SCHC offers a great 18 level of flexibility that can be tailored for different LPWAN 19 technologies. 21 The present document provides the optimal parameters and modes of 22 operation when SCHC is implemented over a Sigfox LPWAN. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 9, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Static Context Header Compression . . . . . . . . . . . . . . 3 61 4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Packet processing . . . . . . . . . . . . . . . . . . . . 4 64 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5.1. Fragmentation headers . . . . . . . . . . . . . . . . . . 5 66 5.2. Uplink fragment transmissions . . . . . . . . . . . . . . 5 67 5.2.1. Uplink No-ACK mode . . . . . . . . . . . . . . . . . 5 68 5.2.2. Uplink ACK-Always mode . . . . . . . . . . . . . . . 6 69 5.2.3. Uplink ACK-on-Error mode . . . . . . . . . . . . . . 6 70 5.3. Downlink fragment transmissions . . . . . . . . . . . . . 6 71 6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Informative References . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The Static Context Header Compression (SCHC) specification 80 [I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression 81 scheme and a fragmentation functionality. Both can be used on top of 82 all the LWPAN systems defined in [RFC8376] . These LPWAN systems have 83 similar characteristics such as star-oriented topologies, network 84 architecture, connected devices with built-in applications, etc. 86 SCHC offers a great level of flexibility to accommodate all these 87 LPWAN systems. Even though there are a great number of similarities 88 between LPWAN technologies, some differences exist with respect to 89 the transmission characteristics, payload sizes, etc. Hence, there 90 are optimal parameters and modes of operation that can be used when 91 SCHC is used on top of a specific LPWAN. 93 This document describes the recommended parameters and modes of 94 operation to be used when SCHC is implemented over a Sigfox LPWAN. 96 2. Terminology 98 It is assumed that the reader is familiar with the terms and 99 mechanisms defined in [RFC8376] and in 100 [I-D.ietf-lpwan-ipv6-static-context-hc]. 102 3. Static Context Header Compression 104 The Static Context Header Compression (SCHC) described in 105 [I-D.ietf-lpwan-ipv6-static-context-hc] takes advantage of the 106 predictability of data flows existing in LPWAN networks to avoid 107 context synchronization. Nonetheless, these contexts must be stored 108 and configured on both ends. This can be done either by using a 109 provisioning protocol, by out of band means, or by pre-provisioning 110 them (for instance at manufacturing time). The way the contexts are 111 configured and stored on both ends is out of the scope of this 112 document. 114 Dev App 115 +----------------+ +--------------+ 116 | APP1 APP2 APP3 | |APP1 APP2 APP3| 117 +----------------+ +--------------+ 118 | UDP | | | UDP | 119 | IPv6 | | | IPv6 | 120 +--------+ | | | 121 |SCHC C/D and F/R| | | 122 | | | | 123 +--------+-------+ +-------+------+ 124 $ +--+ +----+ +-----------+ . 125 +~~ |RG| === |NGW | === | SCHC |... Internet .. 126 +--+ +----+ |F/R and C/D| 127 +-----------+ 129 Figure 1: Architecture 131 Figure 1 represents the architecture for compression/decompression 132 and fragmentation/reassembly, which is based on [RFC8376] 133 terminology. 135 The Device is sending applications flows that are compressed and/or 136 fragmented by a Static Context Header Compression Compressor/ 137 Decompressor (SCHC C/D) to reduce headers size and/or fragment the 138 packet. The resulting information is sent over a layer two (L2) 139 frame to a LPWAN Radio Gateway (RG) which forwards the frame to a 140 Network Gateway (NGW). 142 4. SCHC over Sigfox 144 In the case of the global Sigfox network, RGs (or base stations) are 145 distributed over the multiple countries where the Sigfox LPWAN 146 service is provided. On the other hand, the NGW (or Cloud-based Core 147 network) is a single entity that connects to all Sigfox base stations 148 in the world. 150 Uplink transmissions occur in repetitions over different times and 151 frequencies. Besides these time and frequency diversities, the 152 Sigfox network also provides space diversity, as potentially an 153 uplink message will be received by several base stations. Since all 154 messages are self-contained and base stations forward them all back 155 to the same Core network (NGW), multiple input copies can be combined 156 at the NGW and hence provide for extra reliability based on the 157 triple diversity (i.e. time, space and frequency). 159 The NGW communicates with the Network SCHC C/D for compression/ 160 decompression and/or for fragmentation/reassembly. The Network SCHC 161 C/D shares the same set of rules as the Dev SCHC C/D. The Network 162 SCHC C/D can be collocated with the NGW or it could be in another 163 place, as long as a tunnel is established between the NGW and the 164 SCHC C/D. After decompression and/or reassembly, the packet can be 165 forwarded over the Internet to one (or several) LPWAN Application 166 Server(s) (App). 168 The SCHC C/D process is bidirectional, so the same principles can be 169 applied on both uplink and downlink. 171 4.1. SCHC Rules 173 The RuleID MUST be sent at the beginning of the SCHC header. The 174 total number of rules to be used affects directly the Rule ID field 175 size, and therefore the total size of the fragmentation header. For 176 this reason, it is recommended to keep the number of rules that are 177 defined for a specific device to the minimum possible. 179 4.2. Packet processing 181 TBD 183 5. Fragmentation 185 The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc] 186 defines a generic fragmentation functionality that allows sending 187 data packets larger than the maximum size of a Sigfox data frame. 188 The functionality also defines a mechanism to send reliably multiple 189 frames, by allowing to resend selectively any lost frames. 191 The SCHC fragmentation supports several modes of operation. These 192 modes have different advantages and disadvantages depending on the 193 specifics of the underlying LPWAN technology and Use Case. This 194 section describes how the SCHC fragmentation functionality should 195 optimally be implemented when used over a Sigfox LPWAN for the most 196 typical use case applications. 198 5.1. Fragmentation headers 200 A list of fragmentation header fields, their sizes as well as 201 suggested modes for SCHC fragmentation over Sigfox are provided in 202 this section. 204 5.2. Uplink fragment transmissions 206 Uplink transmissions are completely asynchronous and can take place 207 in any random frequency of the allowed uplink bandwidth allocation. 208 Hence, devices can go to deep sleep mode, and then wake up and 209 transmit whenever there is a need to send any information to the 210 network. In that way, there is no need to perform any network 211 attachment, synchronization, or other procedure before transmitting a 212 data packet. All data packets are self contained with all the 213 required information for the network to process them accordingly. 215 Since uplink transmissions occur asynchronously, an SCHC fragment can 216 be transmitted at any given time by the Dev. 218 5.2.1. Uplink No-ACK mode 220 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 221 packets that require fragmentation. 223 The recommended Fragmentation Header size is 8 bits, and it is 224 composed as follows: 226 The recommended Rule ID size is: 2 bits 228 The recommended DTag size (T) is: 2 bits 230 Fragment Compressed Number (FCN) size (N): 4 bits 232 As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the No-ACK mode 233 the W (window) field is not present. 235 When fragmentation is used to transport IP frames, the Message 236 Integrity Check (MIC) size, M: TBD bits 238 The algorithm for computing the MIC field MUST be TBD. 240 5.2.2. Uplink ACK-Always mode 242 TBD 244 5.2.3. Uplink ACK-on-Error mode 246 ACK-on-Error is RECOMMENDED for larger packets that need to be sent 247 reliably, since it leads to a reduced number of ACKs in the lower 248 capacity downlink channel. 250 In the most generic case, the Fragmentation Header size is 8 bits and 251 it is composed as follows: 253 The recommended Rule ID size is: 2 bits. 255 The recommended DTag size (T) is: 1 bit. 257 The recommended Window (W) size is: 2 bits. 259 Fragment Compressed Number (FCN) size (N): 3 bits. 261 For the ACK-on-Error fragmentation mode(s), a single window size is 262 RECOMMENDED. 264 The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of 265 MAX_WIND_FCN SHOULD be 6 (or 0b110, which allows a maximum window 266 size of 7 fragments). 268 When fragmentation is used to transport IP frames, the Message 269 Integrity Check (MIC) size, M: TBD bits 271 The algorithm for computing the MIC field MUST be TBD. 273 5.3. Downlink fragment transmissions 275 In some LPWAN technologies, as part of energy-saving techniques, 276 downlink transmission is only possible immediately after an uplink 277 transmission. This allows the device to go in a very deep sleep mode 278 and preserve battery, without the need to listen to any information 279 from the network. This is the case for Sigfox-enabled devices, which 280 can only listen to downlink communications after performing an uplink 281 transmission and requesting a downlink. 283 When there are fragments to be transmitted in the downlink, an uplink 284 message is required to trigger the downlink communication. In order 285 to avoid potentially high delay for fragmented datagram transmission 286 in the downlink, the fragment receiver MAY perform an uplink 287 transmission as soon as possible after reception of a downlink 288 fragment that is not the last one. Such uplink transmission MAY be 289 triggered by sending a SCHC message, such as a SCHC ACK. 291 For reliable downlink fragment transmission, the ACK-Always mode is 292 RECOMMENDED. 294 The recommended Fragmentation Header size is: 8 bits 296 The recommended Rule ID size is: 2 bits. 298 The recommended DTag size (T) is: 2 bits. 300 Fragment Compressed Number (FCN) size (N): 3 bits. 302 As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the ACK-Always 303 mode a Window (W) 1-bit field must be present. 305 For the ACK-Always fragmentation mode(s), a single window size is 306 RECOMMENDED. 308 The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of 309 MAX_WIND_FCN SHOULD be 6 (or 0b110, which allows a maximum window 310 size of 7 fragments). 312 When fragmentation is used to transport IP frames, the Message 313 Integrity Check (MIC) size, M: TBD bits 315 The algorithm for computing the MIC field MUST be TBD. 317 Sigfox downlink frames have a fixed length of 8 bytes, which means 318 that default SCHC algorithm for padding cannot be used. Therefore, 319 the 3 last bits of the fragmentation header are used to indicate in 320 bytes the size of the padding. A size of 000 means that the full 321 ramaining frame is used to carry payload, a value of 001 indicates 322 that the last byte contains padding, and so on. 324 6. Padding 326 The Sigfox payload fields have different characteristics in uplink 327 and downlink. 329 Uplink frames can contain a payload from 0 to 96 bits (i.e. 12 330 bytes). The radio protocol allows sending zero bits or one single 331 bit of information for binary applications (e.g. status). However, 332 for 2 or more bits of payload it is required to add padding to the 333 next integer number of bytes. The reason for this flexibility is to 334 optimize transmission time and hence save battery consumption at the 335 device. 337 Downlink frames on the other hand have a fixed length. The payload 338 length must be 64 bits (i.e. 8 bytes). Hence, if less information 339 bits are to be transmitted padding would be necessary and it should 340 be performed as described in the previous section. 342 7. Security considerations 344 The radio protocol authenticates and ensures the integrity of each 345 message. This is achieved by using a unique device ID and an AES-128 346 based message authentication code, ensuring that the message has been 347 generated and sent by the device with the ID claimed in the message. 349 Application data can be encrypted at the application level or not, 350 depending on the criticality of the use case, to provide a balance 351 between cost and effort vs. risk. AES-128 in counter mode is used 352 for encryption. Cryptographic keys are independent for each device. 353 These keys are associated with the device ID and separate integrity 354 and confidentiality keys are pre-provisioned. A confidentiality key 355 is only provisioned if confidentiality is to be used. 357 The radio protocol has protections against reply attacks, and the 358 cloud-based core network provides firewalling protection against 359 undesired incoming communications. 361 8. Acknowledgements 363 Carles Gomez has been funded in part by the ERDF and the Spanish 364 Government through project TEC2016-79988-P. 366 9. Informative References 368 [I-D.ietf-lpwan-ipv6-static-context-hc] 369 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 370 Zuniga, "LPWAN Static Context Header Compression (SCHC) 371 and fragmentation for IPv6 and UDP", draft-ietf-lpwan- 372 ipv6-static-context-hc-17 (work in progress), October 373 2018. 375 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 376 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 377 . 379 Authors' Addresses 380 Juan Carlos Zuniga 381 SIGFOX 382 425 rue Jean Rostand 383 Labege 31670 384 France 386 Email: JuanCarlos.Zuniga@sigfox.com 387 URI: http://www.sigfox.com/ 389 Carles Gomez 390 Universitat Politecnica de Catalunya 391 C/Esteve Terradas, 7 392 08860 Castelldefels 393 Spain 395 Email: carlesgo@entel.upc.edu 397 Laurent Toutain 398 IMT-Atlantique 399 2 rue de la Chataigneraie 400 CS 17607 401 35576 Cesson-Sevigne Cedex 402 France 404 Email: Laurent.Toutain@imt-atlantique.fr