idnits 2.17.1 draft-zuniga-lpwan-schc-over-sigfox-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.) ** 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 171: '... The RuleID MUST be sent at the begi...' RFC 2119 keyword, line 218: '... No-ACK is RECOMMENDED to be used fo...' RFC 2119 keyword, line 236: '...r computing the MIC field MUST be TBD....' RFC 2119 keyword, line 244: '... ACK-on-Error is RECOMMENDED for large...' RFC 2119 keyword, line 261: '... 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 (July 02, 2018) is 2119 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF SCHC' is mentioned on line 303, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-07 == Outdated reference: A later version (-10) exists of draft-ietf-lpwan-overview-07 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 JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Informational C. Gomez 5 Expires: January 3, 2019 Universitat Politecnica de Catalunya 6 L. Toutain 7 IMT-Atlantique 8 July 02, 2018 10 SCHC over Sigfox LPWAN 11 draft-zuniga-lpwan-schc-over-sigfox-03 13 Abstract 15 The Static Context Header Compression (SCHC) specification describes 16 a header compression scheme and 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 January 3, 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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 fragmentation functionality that can be used on top of all 82 the LWPAN systems defined in [I-D.ietf-lpwan-overview]. These LPWAN 83 systems have similar characteristics such as star-oriented 84 topologies, network architecture, connected devices with built-in 85 applications, etc. 87 SCHC offers a great level of flexibility to accommodate all these 88 LPWAN systems. Even though there are a great number of similarities 89 between LPWAN technologies, some differences exist with respect to 90 the transmission characteristics, payload sizes, etc. Hence, there 91 are optimal parameters and modes of operation that can be used when 92 SCHC is used on top of a specific LPWAN. 94 This document describes the optimal parameters and modes of operation 95 when SCHC is implemented over a Sigfox LPWAN. 97 2. Terminology 99 The reader is assumed to be familiar with the terms and mechanisms 100 defined in [I-D.ietf-lpwan-overview] and in 101 [I-D.ietf-lpwan-ipv6-static-context-hc]. 103 3. Static Context Header Compression 105 Static Context Header Compression (SCHC) avoids context 106 synchronization because data flows are highly predictable in LPWAN 107 networks. Contexts must be stored and configured on both ends. This 108 can be done either by using a provisioning protocol, by out of band 109 means, or by pre-provisioning them e.g. at manufacturing time. The 110 way the contexts are configured and stored on both ends is out of the 111 scope of this document. 113 Dev App 114 +--------------+ +--------------+ 115 |APP1 APP2 APP3| |APP1 APP2 APP3| 116 | | | | 117 | UDP | | UDP | 118 | IPv6 | | IPv6 | 119 | | | | 120 | SCHC C/D | | | 121 | (context) | | | 122 +-------+------+ +-------+------+ 123 | +--+ +----+ +---------+ . 124 +~~ |RG| === |NGW | === |SCHC C/D |... Internet .. 125 +--+ +----+ |(context)| 126 +---------+ 128 Figure 1: Architecture 130 Figure 1 represents the architecture for compression/decompression 131 and fragmentation, which is based on [I-D.ietf-lpwan-overview] 132 terminology. 134 The Device is sending applications flows that are compressed (and/or 135 fragmented) by a Static Context Header Compression Compressor/ 136 Decompressor (SCHC C/D) to reduce headers size and/or fragment the 137 packet. The resulting information is sent over a layer two (L2) 138 frame to a LPWAN Radio Gateway (RG) which forwards the frame to a 139 Network Gateway (NGW). 141 4. SCHC over Sigfox 143 In the case of the global Sigfox network, RGs (or base stations) are 144 distributed over the multiple countries where the Sigfox LPWAN 145 service is provided. On the other hand, the NGW (or Cloud-based Core 146 network) is a single entity that connects to all Sigfox base stations 147 in the world. 149 Uplink transmissions occur in repetitions over different times and 150 frequencies. Besides these time and frequency diversities, the 151 Sigfox network also provides space diversity, as potentially an 152 uplink message will be received by several base stations. Since all 153 messages are self-contained and base stations forward them all back 154 to the same Core network (NGW), multiple input copies can be combined 155 at the NGW and hence provide for extra reliability based on the 156 triple diversity. 158 The NGW communicates with the Network SCHC C/D for compression/ 159 decompression (and/or fragmentation/reassembly). The Network SCHC C/ 160 D shares the same set of rules as the Dev SCHC C/D. The Network SCHC 161 C/D can be collocated with the NGW or in another place, as long as a 162 tunnel is established between the NGW and the SCHC C/D. After 163 decompression (and/or reassembly), the packet can be forwarded over 164 the Internet to one (or several) LPWAN Application Server(s) (App). 166 The SCHC C/D process is bidirectional, so the same principles can be 167 applied on both uplink and downlink. 169 4.1. SCHC Rules 171 The RuleID MUST be sent at the beginning of the SCHC header. The 172 total number of rules to be used affects directly the Rule ID field 173 size, and therefore the total size of the fragmentation header. For 174 this reason, it is recommended to keep the number of rules that are 175 defined for a specific device to the minimum possible. 177 4.2. Packet processing 179 TBD 181 5. Fragmentation 183 The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc] 184 defines a generic fragmentation functionality that allows sending 185 data packets larger than the maximum size of a Sigfox data frame. 186 The functionality also defines a mechanism to send reliably multiple 187 frames, by allowing to resend selectively any lost frames. 189 The SCHC fragmentation supports several modes of operation. These 190 modes have different advantages and disadvantages depending on the 191 specifics of the underlying LPWAN technology and Use Case. This 192 section describes how the SCHC fragmentation functionality should 193 optimally be implemented when used over a Sigfox LPWAN for the most 194 typical use case applications. 196 5.1. Fragmentation headers 198 A list of fragmentation header fields, their sizes as well as 199 recommended modes for SCHC fragmentation over Sigfox are provided in 200 this section. 202 5.2. Uplink fragment transmissions 204 Uplink transmissions are completely asynchronous and can take place 205 in any random frequency of the allowed uplink bandwidth allocation. 206 Hence, devices can go to deep sleep mode, and then wake up and 207 transmit whenever there is a need to send any information to the 208 network. In that way, there is no need to perform any network 209 attachment, synchronization, or other procedure before transmitting a 210 data packet. All data packets are self contained with all the 211 required information for the network to process them accordingly. 213 Since uplink transmissions occur asynchronously, an SCHC fragment can 214 be transmitted at any given time by the Dev. 216 5.2.1. Uplink No-ACK mode 218 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 219 packets that require fragmentation. 221 Fragmentation Header size: 8 bits 223 The recommended Rule ID size is: 3 bits 225 The recommended DTag size (T) is: 0 bits, as the number of available 226 Rule IDs are sufficient to interleave fragmented packets. 228 Fragment Compressed Number (FCN) size (N): 4 bits 230 As per [REF SCHC], in the No-ACK mode the W (window) 1-bit field is 231 not present. 233 When fragmentation is used to transport IP frames, the Message 234 Integrity Check (MIC) size, M: TBD bits 236 The algorithm for computing the MIC field MUST be TBD. 238 5.2.2. Uplink ACK-Always mode 240 TBD 242 5.2.3. Uplink ACK-on-Error mode 244 ACK-on-Error is RECOMMENDED for larger packets, since it leads to a 245 reduced number of ACKs to be sent in the lower capacity downlink 246 channel. 248 The recommended Fragmentation Header size is: 8 bits 250 The recommended Rule ID size is: 3 bits. 252 The recommended DTag size (T) is: 0 bits, as the number of available 253 Rule IDs are sufficient to interleave fragmented packets. 255 Fragment Compressed Number (FCN) size (N): 4 bits. 257 As per [REF SCHC], in the ACK-on-Error mode the Window (W) 1-bit 258 field must be present. 260 For the ACK-on-Error fragmentation mode(s), a single window size is 261 RECOMMENDED. 263 The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of 264 MAX_WIND_FCN SHOULD be 14 (which allows a maximum window size with 15 265 fragments). 267 When fragmentation is used to transport IP frames, the Message 268 Integrity Check (MIC) size, M: TBD bits 270 The algorithm for computing the MIC field MUST be TBD. 272 5.3. Downlink fragment transmissions 274 In some LPWAN technologies, as part of energy-saving techniques, 275 downlink transmission is only possible immediately after an uplink 276 transmission. This allows the device to go in a very deep sleep mode 277 and preserve battery, without the need to listen to any information 278 from the network. This is the case for Sigfox-enabled devices, which 279 can only listen to downlink communications after performing an uplink 280 transmission. 282 When there are multiple fragments to be transmitted in the downlink, 283 an uplink message is required to trigger the downlink communication. 284 In order to avoid potentially high delay for fragmented datagram 285 transmission in the downlink, the fragment receiver MAY perform an 286 uplink transmission as soon as possible after reception of a fragment 287 that is not the last one. Such uplink transmission MAY be triggered 288 by sending a SCHC message, such as an ACK. In this sense, ACK-Always 289 is the preferred fragmentation mode for downlink communications. 291 For downlink fragment transmission, the ACK-Always mode MUST be 292 supported. 294 The recommended Fragmentation Header size is: 8 bits 296 The recommended Rule ID size is: 3 bits. 298 The recommended DTag size (T) is: 0 bits, as the number of available 299 Rule IDs are sufficient to interleave fragmented packets. 301 Fragment Compressed Number (FCN) size (N): 4 bits. 303 As per [REF SCHC], in the ACK-on-Error mode the Window (W) 1-bit 304 field must be present. 306 For the ACK-Always fragmentation mode(s), a single window size is 307 RECOMMENDED. 309 The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of 310 MAX_WIND_FCN SHOULD be 14 (which allows a maximum window size with 15 311 fragments). 313 When fragmentation is used to transport IP frames, the Message 314 Integrity Check (MIC) size, M: TBD bits 316 The algorithm for computing the MIC field MUST be TBD. 318 Sigfox downlink frames have a fixed length of 8 bytes, which means 319 that default SCHC algorithm for padding cannot be used. Therefore, 320 the 3 last bits of the fragmentation header are used to indicate in 321 bytes the size of the padding. A size of 000 means that the full 322 ramaining frame is used to carry payload, a value of 001 indicates 323 that the last byte contains padding, and so on. 325 6. Padding 327 The Sigfox payload fields have different characteristics in uplink 328 and downlink. 330 Uplink frames can contain a payload from 0 to 96 bits (i.e. 12 331 bytes). The radio protocol allows sending zero bits or one single 332 bit of information for binary applications (e.g. status). However, 333 for 2 or more bits of payload it is required to add padding to the 334 next integer number of bytes. The reason for this flexibility is to 335 optimize transmission time and hence save battery consumption at the 336 device. 338 Downlink frames on the other hand have a fixed length. The payload 339 length must be 64 bits (i.e. 8 bytes). Hence, if less information 340 bits are to be transmitted padding would be necessary and it should 341 be performed as described in the previous section. 343 7. Security considerations 345 The radio protocol authenticates and ensures the integrity of each 346 message. This is achieved by using a unique device ID and an AES-128 347 based message authentication code, ensuring that the message has been 348 generated and sent by the device with the ID claimed in the message. 350 Application data can be encrypted at the application level or not, 351 depending on the criticality of the use case, to provide a balance 352 between cost and effort vs. risk. AES-128 in counter mode is used 353 for encryption. Cryptographic keys are independent for each device. 354 These keys are associated with the device ID and separate integrity 355 and confidentiality keys are pre-provisioned. A confidentiality key 356 is only provisioned if confidentiality is to be used. 358 The radio protocol has protections against reply attacks, and the 359 cloud-based core network provides firewalling protection against 360 undesired incoming communications. 362 8. Acknowledgements 364 Carles Gomez has been funded in part by the ERDF and the Spanish 365 Government through project TEC2016-79988-P. 367 9. Informative References 369 [I-D.ietf-lpwan-ipv6-static-context-hc] 370 Minaburo, A., Toutain, L., and C. Gomez, "LPWAN Static 371 Context Header Compression (SCHC) and fragmentation for 372 IPv6 and UDP", draft-ietf-lpwan-ipv6-static-context-hc-07 373 (work in progress), October 2017. 375 [I-D.ietf-lpwan-overview] 376 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 377 overview-07 (work in progress), October 2017. 379 Authors' Addresses 381 Juan Carlos Zuniga 382 SIGFOX 383 425 rue Jean Rostand 384 Labege 31670 385 France 387 Email: JuanCarlos.Zuniga@sigfox.com 388 URI: http://www.sigfox.com/ 390 Carles Gomez 391 Universitat Politecnica de Catalunya 392 C/Esteve Terradas, 7 393 08860 Castelldefels 394 Spain 396 Email: carlesgo@entel.upc.edu 398 Laurent Toutain 399 IMT-Atlantique 400 2 rue de la Chataigneraie 401 CS 17607 402 35576 Cesson-Sevigne Cedex 403 France 405 Email: Laurent.Toutain@imt-atlantique.fr