idnits 2.17.1 draft-ietf-lpwan-schc-over-sigfox-01.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 186: '... The RuleID MUST be sent at the begi...' RFC 2119 keyword, line 234: '... No-ACK is RECOMMENDED to be used fo...' RFC 2119 keyword, line 258: '...r computing the MIC field MUST be TBD....' RFC 2119 keyword, line 266: '... ACK-on-Error is RECOMMENDED for large...' RFC 2119 keyword, line 276: '... RECOMMENDED to be 8 bits in size an...' (12 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 4, 2019) is 1629 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 7, 2020 Universitat Politecnica de Catalunya 6 L. Toutain 7 IMT-Atlantique 8 November 4, 2019 10 SCHC over Sigfox LPWAN 11 draft-ietf-lpwan-schc-over-sigfox-01 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 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 5 64 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 8 71 6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 9. Informative References . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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, where the Radio Gateway is a Sigfox Base Station and the 134 Network Gateway is the Sigfox Cloud. 136 The Device is sending applications flows that are compressed and/or 137 fragmented by a Static Context Header Compression Compressor/ 138 Decompressor (SCHC C/D) to reduce headers size and/or fragment the 139 packet. The resulting information is sent over a layer two (L2) 140 frame to a LPWAN Radio Gateway (RG) which forwards the frame to a 141 Network Gateway (NGW). 143 4. SCHC over Sigfox 145 In the case of the global Sigfox network, RGs (or base stations) are 146 distributed over the multiple countries where the Sigfox LPWAN 147 service is provided. On the other hand, the NGW (or Cloud-based Core 148 network) is a single entity that connects to all Sigfox base stations 149 in the world. 151 Uplink Sigfox transmissions occur in repetitions over different times 152 and frequencies. Besides these time and frequency diversities, the 153 Sigfox network also provides space diversity, as potentially an 154 uplink message will be received by several base stations. Since all 155 messages are self-contained and base stations forward them all back 156 to the same Core network (NGW), multiple input copies can be combined 157 at the NGW and hence provide for extra reliability based on the 158 triple diversity (i.e. time, space and frequency). 160 Downlink transmissions can only take place after an uplink 161 communication. A device willing to receive downlink messages 162 indicates so to the network in the uplink message and opens a fixed 163 window for reception after the uplink transmission. The delay and 164 duration of this reception window have fixed values. If there is a 165 downlink message to be sent for this given device (e.g. a response to 166 the uplink message or queued information), the network transmits it 167 during the reception window. 169 A detailed description of the Sigfox Radio Protocol can be found in 170 [sigfox-spec]. 172 The NGW communicates with the Network SCHC C/D + F/R for compression/ 173 decompression and/or for fragmentation/reassembly. The Network SCHC 174 C/D + F/R share the same set of rules as the Dev SCHC C/D + F/R. The 175 Network SCHC C/D + F/R can be collocated with the NGW or it could be 176 in another place, as long as a tunnel is established between the NGW 177 and the SCHC C/D + F/R functions. After decompression and/or 178 reassembly, the packet can be forwarded over the Internet to one (or 179 several) LPWAN Application Server(s) (App). 181 The SCHC C/D + F/R processes are bidirectional, so the same 182 principles can be applied on both uplink and downlink. 184 4.1. SCHC Rules 186 The RuleID MUST be sent at the beginning of the SCHC header. The 187 total number of rules to be used affects directly the Rule ID field 188 size, and therefore the total size of the fragmentation header. For 189 this reason, it is recommended to keep the number of rules that are 190 defined for a specific device to the minimum possible. 192 4.2. Packet processing 194 TBD 196 5. Fragmentation 198 The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc] 199 defines a generic fragmentation functionality that allows sending 200 data packets or files larger than the maximum size of a Sigfox data 201 frame. The functionality also defines a mechanism to send reliably 202 multiple messages, by allowing to resend selectively any lost 203 fragments. 205 The SCHC fragmentation supports several modes of operation. These 206 modes have different advantages and disadvantages depending on the 207 specifics of the underlying LPWAN technology and Use Case. This 208 section describes how the SCHC fragmentation functionality should 209 optimally be implemented when used over a Sigfox LPWAN for the most 210 typical use case applications. 212 5.1. Fragmentation headers 214 A list of fragmentation header fields, their sizes as well as 215 suggested modes for SCHC fragmentation over Sigfox are provided in 216 this section. 218 5.2. Uplink fragment transmissions 220 Uplink transmissions are completely asynchronous and can take place 221 in any random frequency of the allowed uplink bandwidth allocation. 222 Hence, devices can go to deep sleep mode, and then wake up and 223 transmit whenever there is a need to send any information to the 224 network. In that way, there is no need to perform any network 225 attachment, synchronization, or other procedure before transmitting a 226 data packet. All data packets are self contained with all the 227 required information for the network to process them accordingly. 229 Since uplink transmissions occur asynchronously, an SCHC fragment can 230 be transmitted at any given time by the Dev. 232 5.2.1. Uplink No-ACK mode 234 No-ACK is RECOMMENDED to be used for transmitting short, non-critical 235 packets that require fragmentation and do not require full 236 reliability. This mode can be used by uplink-only devices that do 237 not support downlink communications, or by bidirectional devices when 238 they send non-critical data. 240 The recommended Fragmentation Header size is 8 bits, and it is 241 composed as follows: 243 The recommended Rule ID size is: 2 bits 245 The recommended DTag size (T) is: 2 bits 247 Fragment Compressed Number (FCN) size (N): 4 bits 249 As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the No-ACK mode 250 the W (window) field is not present. 252 When fragmentation is used to transport IP frames, the Message 253 Integrity Check (MIC) size, M: TBD bits 255 When fragmentation is used to transport non-IP frames, the Message 256 Integrity Check (MIC) size, M: TBD bits 258 The algorithm for computing the MIC field MUST be TBD. 260 5.2.2. Uplink ACK-Always mode 262 TBD 264 5.2.3. Uplink ACK-on-Error mode 266 ACK-on-Error is RECOMMENDED for larger packets that need to be sent 267 reliably. This mode is optimal for Sigfox transmissions, since it 268 leads to a reduced number of ACKs in the lower capacity downlink 269 channel and downlink messages can be sent asynchronously and 270 opportunistically. 272 o Single-byte SCHC UL header 274 In the most generic case, and allowing transmission of packets/files 275 up to 300 bytes long, the SCHC uplink Fragmentation Header size is 276 RECOMMENDED to be 8 bits in size and composed as follows: 278 Rule ID size is: 2 bits. 280 DTag size (T) is: 1 bit. 282 Window (W) size is: 2 bits. 284 Fragment Compressed Number (FCN) size (N): 3 bits. 286 For the ACK-on-Error fragmentation mode(s), a single window size 287 is RECOMMENDED. 289 MAX_ACK_REQUESTS: 3. 291 MAX_WIND_FCN: 6 (or 0b110, which allows a maximum window size of 7 292 fragments). 294 Retransmission Timer: 45 sec. 296 Inactivity Timer: [use case dependent]. 298 When fragmentation is used to transport IP frames, the Message 299 Integrity Check (MIC) size, M: TBD bits 301 The algorithm for computing the MIC field MUST be TBD. 303 The correspondent SCHC ACK in the downlink is 13 bits long, so 304 padding is needed to complete the required 64 bits of Sigfox payload. 306 o Two-byte SCHC UL header 308 In order to allow transmission of very large packets/files up to 2250 309 bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED 310 to be 16 bits in size and composed as follows: 312 Rule ID size is: 4 bits. 314 DTag size (T) is: 4 bit. 316 Window (W) size is: 3 bits. 318 Fragment Compressed Number (FCN) size (N): 5 bits. 320 For the ACK-on-Error fragmentation mode(s), a single window size 321 is RECOMMENDED. 323 MAX_ACK_REQUESTS: 3. 325 Retransmission Timer: 45 sec. 327 Inactivity Timer: [use case dependent]. 329 When fragmentation is used to transport IP frames, the Message 330 Integrity Check (MIC) size, M: TBD bits 332 The algorithm for computing the MIC field MUST be TBD. 334 The correspondent SCHC ACK in the downlink is 43 bits long, so 335 padding is needed to complete the required 64 bits of Sigfox payload. 337 5.3. Downlink fragment transmissions 339 In some LPWAN technologies, as part of energy-saving techniques, 340 downlink transmission is only possible immediately after an uplink 341 transmission. This allows the device to go in a very deep sleep mode 342 and preserve battery, without the need to listen to any information 343 from the network. This is the case for Sigfox-enabled devices, which 344 can only listen to downlink communications after performing an uplink 345 transmission and requesting a downlink. 347 When there are fragments to be transmitted in the downlink, an uplink 348 message is required to trigger the downlink communication. In order 349 to avoid potentially high delay for fragmented datagram transmission 350 in the downlink, the fragment receiver MAY perform an uplink 351 transmission as soon as possible after reception of a downlink 352 fragment that is not the last one. Such uplink transmission MAY be 353 triggered by sending a SCHC message, such as a SCHC ACK. However, 354 other data messages can equally be used to trigger DL communications. 356 For reliable downlink fragment transmission, the ACK-Always mode is 357 RECOMMENDED. 359 The recommended Fragmentation Header size is: 8 bits 361 The recommended Rule ID size is: 2 bits. 363 The recommended DTag size (T) is: 2 bits. 365 Fragment Compressed Number (FCN) size (N): 3 bits. 367 As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the ACK-Always 368 mode a Window (W) 1-bit field must be present. 370 For the ACK-Always fragmentation mode(s), a single window size is 371 RECOMMENDED. 373 The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of 374 MAX_WIND_FCN SHOULD be 6 (or 0b110, which allows a maximum window 375 size of 7 fragments). 377 When fragmentation is used to transport IP frames, the Message 378 Integrity Check (MIC) size, M: TBD bits 380 The algorithm for computing the MIC field MUST be TBD. 382 Sigfox downlink frames have a fixed length of 8 bytes, which means 383 that default SCHC algorithm for padding cannot be used. Therefore, 384 the 3 last bits of the fragmentation header are used to indicate in 385 bytes the size of the padding. A size of 000 means that the full 386 ramaining frame is used to carry payload, a value of 001 indicates 387 that the last byte contains padding, and so on. 389 6. Padding 391 The Sigfox payload fields have different characteristics in uplink 392 and downlink. 394 Uplink frames can contain a payload size from 0 to 96 bits, that is 0 395 to 12 bytes. The radio protocol allows sending zero bits or one 396 single bit of information for binary applications (e.g. status), or 397 an integer number of bytes. Therefore, for 2 or more bits of payload 398 it is required to add padding to the next integer number of bytes. 399 The reason for this flexibility is to optimize transmission time and 400 hence save battery consumption at the device. 402 Downlink frames on the other hand have a fixed length. The payload 403 length must be 64 bits (i.e. 8 bytes). Hence, if less information 404 bits are to be transmitted, padding would be necessary and it should 405 be performed as described in the previous section. 407 7. Security considerations 409 The radio protocol authenticates and ensures the integrity of each 410 message. This is achieved by using a unique device ID and an AES-128 411 based message authentication code, ensuring that the message has been 412 generated and sent by the device with the ID claimed in the message. 414 Application data can be encrypted at the application level or not, 415 depending on the criticality of the use case. This flexibility 416 allows providing a balance between cost and effort vs. risk. AES-128 417 in counter mode is used for encryption. Cryptographic keys are 418 independent for each device. These keys are associated with the 419 device ID and separate integrity and confidentiality keys are pre- 420 provisioned. A confidentiality key is only provisioned if 421 confidentiality is to be used. 423 The radio protocol has protections against reply attacks, and the 424 cloud-based core network provides firewalling protection against 425 undesired incoming communications. 427 8. Acknowledgements 429 Carles Gomez has been funded in part by the ERDF and the Spanish 430 Government through project TEC2016-79988-P. 432 9. Informative References 434 [I-D.ietf-lpwan-ipv6-static-context-hc] 435 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 436 Zuniga, "LPWAN Static Context Header Compression (SCHC) 437 and fragmentation for IPv6 and UDP", draft-ietf-lpwan- 438 ipv6-static-context-hc-17 (work in progress), October 439 2018. 441 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 442 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 443 . 445 [sigfox-spec] 446 Sigfox, "Sigfox Radio Specifications", 447 . 450 Authors' Addresses 452 Juan Carlos Zuniga 453 SIGFOX 454 425 rue Jean Rostand 455 Labege 31670 456 France 458 Email: JuanCarlos.Zuniga@sigfox.com 459 URI: http://www.sigfox.com/ 461 Carles Gomez 462 Universitat Politecnica de Catalunya 463 C/Esteve Terradas, 7 464 08860 Castelldefels 465 Spain 467 Email: carlesgo@entel.upc.edu 469 Laurent Toutain 470 IMT-Atlantique 471 2 rue de la Chataigneraie 472 CS 17607 473 35576 Cesson-Sevigne Cedex 474 France 476 Email: Laurent.Toutain@imt-atlantique.fr