idnits 2.17.1 draft-petrov-lpwan-ipv6-schc-over-lorawan-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.) ** There are 2 instances of too long lines in the document, the longest one being 63 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 (March 05, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4944' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC7136' is defined on line 298, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-10 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: September 6, 2018 I. Petrov 6 Acklio 7 A. Yegin 8 Actility 9 J. Catalano 10 Kerlink 11 V. Audebert 12 EDF R&D 13 March 05, 2018 15 Static Context Header Compression (SCHC) over LoRaWAN 16 draft-petrov-lpwan-ipv6-schc-over-lorawan-01 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 September 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . 5 70 4.3. General Message Types . . . . . . . . . . . . . . . . . . 6 71 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 6 72 5. SCHC over LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Rule ID management . . . . . . . . . . . . . . . . . . . 6 74 5.2. IID computation . . . . . . . . . . . . . . . . . . . . . 6 75 5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 6 76 5.3.1. Reliability options . . . . . . . . . . . . . . . . . 6 77 5.3.2. Supporting multiple window sizes . . . . . . . . . . 6 78 5.3.3. Downlink fragment transmission . . . . . . . . . . . 6 79 5.3.4. SCHC behavior for devices in class A, B and C . . . . 6 80 6. Security considerations . . . . . . . . . . . . . . . . . . . 6 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 84 8.2. Informative References . . . . . . . . . . . . . . . . . 7 85 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 86 Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 7 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 89 1. Introduction 91 The Static Context Header Compression (SCHC) specification 92 [I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header 93 compression and fragmentation techniques that can be used on all 94 LPWAN (Low Power Wide Area Networks) technologies defined in 96 [I-D.ietf-lpwan-overview]. Even though those technologies share a 97 great number of common features like start-oriented topologies, 98 network architecture, devices with mostly quite predictable 99 communications, etc; they do have some slight differences in respect 100 of payload sizes, reactiveness, etc. 102 SCHC gives a generic framework that enables those devices to 103 communicate with other Internet networks. However, for efficient 104 performance, some parameters and modes of operation need to be set 105 appropriately for each of the LPWAN technologies. 107 This document describes the efficient parameters and modes of 108 operation when SCHC is used over LoRaWAN networks. 110 2. Terminology 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 device 117 during the procedure while joining the network (Join Procedure) 119 o DevAddr: a 32-bit non-unique identifier assigned to a 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, which is the most bandwidth-consuming operation in 133 other header compression mechanisms such as RoHC [RFC5795]. Based on 134 the fact that the nature of data flows is highly predictable in LPWAN 135 networks, some static contexts may be stored on the Device (Dev). 136 The contexts must be stored in both ends, and it can either be 137 learned by a provisioning protocol or by out of band means or it can 138 be pre-provisioned, etc. The way the context is learned on both 139 sides is out of the scope of this document. 141 Dev App 142 +--------------+ +--------------+ 143 |APP1 APP2 APP3| |APP1 APP2 APP3| 144 | | | | 145 | UDP | | UDP | 146 | IPv6 | | IPv6 | 147 | | | | 148 | SCHC C/D | | | 149 | (context) | | | 150 +-------+------+ +-------+------+ 151 | +--+ +----+ +---------+ . 152 +~~ |RG| === |NGW | === |SCHC C/D |... Internet .. 153 +--+ +----+ |(context)| 154 +---------+ 156 Figure 1: Architecture 158 Figure 1 represents the architecture for compression/decompression, 159 it is based on [I-D.ietf-lpwan-overview] terminology. The Device is 160 sending applications flows using IPv6 or IPv6/UDP protocols. These 161 flows are compressed by an Static Context Header Compression 162 Compressor/Decompressor (SCHC C/D) to reduce headers size. Resulting 163 information is sent on a layer two (L2) frame to a LPWAN Radio 164 Network (RG) which forwards the frame to a Network Gateway (NGW). 165 The NGW sends the data to a SCHC C/D for decompression which shares 166 the same rules with the Dev. The SCHC C/D can be located on the 167 Network Gateway (NGW) or in another place as long as a tunnel is 168 established between the NGW and the SCHC C/D. The SCHC C/D in both 169 sides must share the same set of Rules. After decompression, the 170 packet can be sent on the Internet to one or several LPWAN 171 Application Servers (App). 173 The SCHC C/D process is bidirectional, so the same principles can be 174 applied in the other direction. 176 In a LoRaWAN network, the RG is called a Gateway, the NGW is Network 177 Server, and the SCHC C/D can be embedded in different places, for 178 example in the Network Server and/or the Application Server. 180 Next steps for this section: detailed overview of the LoRaWAN 181 architecture and its mapping to the SCHC architecture. 183 4. LoRaWAN Architecture 185 An overview of LoRaWAN [lora-alliance-spec] protocol and architecture 186 is described in [I-D.ietf-lpwan-overview]. Mapping between the LPWAN 187 architecture entities as described in 189 [I-D.ietf-lpwan-ipv6-static-context-hc] and the ones in 190 [lora-alliance-spec] is as follows: 192 o Devices (Dev) are the end-devices or hosts (e.g. sensors, 193 actuators, etc.). There can be a very high density of devices per 194 radio gateway. This entity maps to the LoRaWAN End-device. 196 o The Radio Gateway (RGW), which is the end point of the constrained 197 link. This entity maps to the LoRaWAN Gateway. 199 o The Network Gateway (NGW) is the interconnection node between the 200 Radio Gateway and the Internet. This entity maps to the LoRaWAN 201 Network Server. 203 o LPWAN-AAA Server, which controls the user authentication and the 204 applications. This entity maps to the LoRaWAN Join Server. 206 o Application Server (App). The same terminology is used in LoRaWAN. 208 () () () | +------+ 209 () () () () / \ +---------+ | Join | () () () () () () / \======| ^ |===|Server| +-----------+ 210 () () () | | <--|--> | +------+ |Application| () () () () / \==========| v |=============| Server | 211 () () () / \ +---------+ +-----------+ 212 End-Devices Gateways Network Server 214 Figure 1: LPWAN/LoRaWAN Architecture 216 SCHC C/D (Compressor/Decompressor) and SCHC Fragmentation are 217 performed on the LoRaWAN End-device and the Application Server. 218 While the point-to-point link between the End-device and the 219 Application Server constitutes single IP hop, the ultimate end-point 220 of the IP communication may be an Internet node beyond the 221 Application Server. In other words, the LoRaWAN Application Server 222 acts as the first hop IP router for the End-device. Note that the 223 Application Server and Network Server may be co-located, which 224 effectively turns the Network/Application Server into the first hop 225 IP router. 227 4.1. Device classes (A, B, C) and interactions 229 TBD 231 4.2. Device addressing 233 TBD 235 4.3. General Message Types 237 TBD 239 4.4. LoRaWAN MAC Frames 241 TBD 243 5. SCHC over LoRaWAN 245 5.1. Rule ID management 247 Rule ID can be stored and transported in the FPort field of the 248 LoRaWAN MAC frame. 250 TBD 252 5.2. IID computation 254 TBD 256 5.3. Fragmentation 258 TBD 260 5.3.1. Reliability options 262 TBD 264 5.3.2. Supporting multiple window sizes 266 TBD 268 5.3.3. Downlink fragment transmission 270 TBD 272 5.3.4. SCHC behavior for devices in class A, B and C 274 TBD 276 6. Security considerations 278 TBD 280 7. Acknowledgements 282 TBD 284 8. References 286 8.1. Normative References 288 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 289 "Transmission of IPv6 Packets over IEEE 802.15.4 290 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 291 . 293 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 294 Header Compression (ROHC) Framework", RFC 5795, 295 DOI 10.17487/RFC5795, March 2010, 296 . 298 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 299 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 300 February 2014, . 302 8.2. Informative References 304 [I-D.ietf-lpwan-ipv6-static-context-hc] 305 Minaburo, A., Toutain, L., and C. Gomez, "LPWAN Static 306 Context Header Compression (SCHC) and fragmentation for 307 IPv6 and UDP", draft-ietf-lpwan-ipv6-static-context-hc-10 308 (work in progress), February 2018. 310 [I-D.ietf-lpwan-overview] 311 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 312 overview-10 (work in progress), February 2018. 314 [lora-alliance-spec] 315 Alliance, L., "LoRaWAN Specification Version V1.0.2", 316 . 320 Appendix A. Examples 322 Appendix B. Note 323 Authors' Addresses 325 Nicolas Sornin (editor) 326 Semtech 327 14 Chemin des Clos 328 Meylan 329 France 331 Email: nsornin@semtech.com 333 Michael Coracin 334 Semtech 335 14 Chemin des Clos 336 Meylan 337 France 339 Email: mcoracin@semtech.com 341 Ivaylo Petrov 342 Acklio 343 2bis rue de la Chataigneraie 344 35510 Cesson-Sevigne Cedex 345 France 347 Email: ivaylo@ackl.io 349 Alper Yegin 350 Actility 351 . 352 Paris, Paris 353 France 355 Email: alper.yegin@actility.com 357 Julien Catalano 358 Kerlink 359 1 rue Jacqueline Auriol 360 35235 Thorigne-Fouillard 361 France 363 Email: j.catalano@kerlink.fr 364 Vincent AUDEBERT 365 EDF R&D 366 7 bd Gaspard Monge 367 91120 PALAISEAU 368 FRANCE 370 Email: vincent.audebert@edf.fr