idnits 2.17.1 draft-minaburo-lp-wan-gap-analysis-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 a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2016) is 2985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Minaburo 3 Internet-Draft A. Pelov 4 Intended status: Informational Acklio 5 Expires: August 27, 2016 L. Toutain 6 Institut MINES TELECOM ; TELECOM Bretagne 7 February 24, 2016 9 LP-WAN GAP Analysis 10 draft-minaburo-lp-wan-gap-analysis-01 12 Abstract 14 Low Power Wide Area Networks (LP-WAN) are different technologies 15 covering different applications based on long range, low bandwidth 16 and low power operation. The use of IETF protocols in the LP-WAN 17 technologies should contribute to the deployment of a wide number of 18 applications in an open and standard environment where actual 19 technologies will be able to communicate. This document makes a 20 survey of the principal characteristics of these technologies and 21 covers a cross layer analysis on how to adapt and use the actual IETF 22 protocols, but also the gaps for the integration of the IETF protocol 23 stack in the LP-WAN technologies. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 27, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 LP-WAN (Low-Power Wide Area Network) technologies are a kind of 60 constrained and challenged networks [RFC7228]. They can operate in 61 license-exempt bands to provide connectivity to a vast number of 62 battery-powered devices requiring limited communications. If the 63 existing pilot deployments have shown the huge potential and the 64 industrial interest in their capabilities, the loose coupling with 65 the Internet makes the device management and network operation 66 complex. More importantly, LP-WAN devices are, as of today, with no 67 IP capabilities. The goal is to adapt IETF defined protocols, 68 addressing schemes and naming spaces to this constrained environment. 70 2. Problem Statement 72 The LP-WANs are large-scale constrained networks in the sense of 73 [RFC7228] with the following characteristics: 75 o very small frame payload as low as 12 bytes. Typical traffic 76 patterns are composed of a large majority of frames with payload 77 size around 15 bytes and a small minority of up to 100 byte 78 frames. Some nodes will exchange less than 10 frames per day. 80 o very low bandwidth, most LP-WAN technologies offer a throughput 81 between 50 bit/s to 250 kbit/s, with a duty cycle of 0.1% to 10% 82 on some ISM bands. 84 o high packet loss, which can be the result of bad transmission 85 conditions or collisions between nodes. 87 o variable MTU for a link depending on the used L2 modulation. 89 o highly asymmetric and in some cases unidirectional links. 91 o ultra dense networks with thousands to tens of thousands of nodes. 93 o different modulations and radio channels. 95 o sleepy nodes to preserve energy. 97 In the terminology of [RFC7228], these characteristics put LP-WANs 98 into the "challenged network" category where the IP connectivity has 99 to be redefined or modified. Therefore, LP-WANs need to be 100 considered as a separate class of networks. The intrinsic 101 characteristics, current usages and architectures will allow the 102 group to make and justify the design choices. Some of the desired 103 properties are: 105 o keep compatibility with current Internet: 107 * preserve the end-to-end communication principle. 109 * maintain independence from L2 technology. 111 * use or adapt protocols defined by IETF to this new environment 112 that could be less responsive. 114 * use existing addressing spaces and naming schemes defined by 115 IETF. 117 o ensure the correspondence with the stringent LP-WAN requirements, 118 such as: 120 * limited number of messages per device. 122 * small message size, with potentially no L2 fragmentation. 124 * RTTs potentially orders of magnitude bigger than existing 125 constrained networks. 127 o optimize the protocol stack in order to limit the number of 128 duplicated functionalities; for instance acknowledgements should 129 not be done at several layers. 131 3. Identified gaps in current IETF groups concerning LP-WANs 133 3.1. IPv6 and LP-WAN 135 IPv6 [RFC2460] has been designed to allocate addresses to all the 136 nodes connected to the Internet. Nevertheless the 40 bytes of 137 overhead introduced by the protocol are incompatible with the LP-WAN 138 constraints. If IPv6 were used, several LP-WAN frames will be needed 139 just to carry the header. Another limitation comes from the MTU 140 limit, which is 1280 bytes required from the layer 2 to carry IPv6 141 packet [RFC1981]. This is a side effect of the PMTU discovery 142 mechanism, which allows intermediary routers to send to the source an 143 ICMP message (packet too big) to reduce the size. An attacker will 144 be able to forge this message and reduce drastically the transmission 145 performances. This limit allows to mitigate the impact of this 146 attack. 148 IPv6 needs a configuration protocol (neighbor discovery protocol, NDP 149 [RFC4861]) to learn network parameters, and the node relation with 150 its neighbor. This protocol generates a regular traffic with a large 151 message size that does not fit LP-WAN constraints. 153 3.2. 6LoWPAN, 6lo and LP-WAN 155 6LoWPAN only resolves the IPv6 constraints by drastically reducing 156 IPv6 overhead to about 4 bytes for ND traffic, but the header 157 compression is not better for an end-to-end communications using 158 global addresses (up to 20 bytes). 6LoWPAN has been initially 159 designed for IEEE 802.15.4 networks with a frame size up to 127 bytes 160 and a throughput of up to 250 kb/s with no duty cycle regarding the 161 usage of the network. 163 IEEE 802.15.4 is a CSMA/CA protocol which means that every unicast 164 frame is acknowledged. Because IEEE 802.15.4 has its own reliability 165 mechanism by retransmission, 6LoWPAN does not have reliable delivery. 166 Some LP-WAN technologies do not provide such acknowledgements at L2 167 and would require other reliability mechanisms. 169 6lo extends the usage of 6LoWPAN to other technologies (BLE, DECT, 170 ...), with similar characteristics to IEEE 802.15.4. The main 171 constraint in these networks comes from the nature of the devices 172 (constrained devices), whereas in LP-WANs it is the network itself 173 that imposes the most stringent constraint. 175 Neighbor Discovery has to be optimized by reducing the message size, 176 the periodic exchanges and removing multicast message for point-to- 177 point exchanges with border router. 179 3.3. 6tisch and LP-WAN 181 TODO 183 Describe why 6tisch is complementary to LP-WAN 185 A key element of 6tisch is the use of synchronization to enable 186 determinism. An LP-WAN may or may not support synchronization like 187 the one used in 6tisch. The 6tisch solution is dedicated to mesh 188 networks that operate using 802.15.4e with a deterministic slotted 189 channel. 191 3.4. ROLL and LP-WAN 193 The LP-WANs considered by the WG are based on a star topology, which 194 eliminates the need for routing. Future works may address additional 195 use-cases which may require the adaptation of existing routing 196 protocols or the definition of new ones. For the moment, the work 197 done at the ROLL WG and other routing protocols are out of scope of 198 the LP-WAN WG. 200 3.5. CORE and LP-WAN 202 TODO 204 CoRE provides a resource-oriented application intended to run on 205 constrained IP networks. It may be necessary to adapt the protocols 206 to take into account the duty cycling and the potentially extremely 207 limited throughput. For example, some of the timers in CoAP may need 208 to be redefined. Taking into account CoAP acknowledgements may allow 209 the reduction of L2 acknowledgements. 211 3.6. Security and LP-WAN 213 ToDo 215 3.7. Mobility and LP-WAN 217 TODO 219 LP-WAN nodes can be mobile. However, LP-WAN mobility is different 220 than the one studied in the context of Mobile IP. LP-WAN implies 221 sporadic traffic and will rarely be used for high-frequency, real- 222 time communications. 224 4. Annex A -- survey of LP-WAN technologies 226 Different technologies can be included under the LP-WAN acronym. The 227 following list is the result of a survey among the first participant 228 to the mailing-list. It cannot be exhaustive but is representative 229 of the current trends. 231 +-------------+---------------+--------------+--------+ 232 |Technology |range | Throughput |MAC MTU | 233 +-------------+---------------+--------------+--------+ 234 |LoRa |2-5 km urban |0.3 to 50 kbps|256 B | 235 | |<15 km suburban| | | 236 +-------------+---------------+--------------+--------+ 237 |SIGFOX |10 km urban |100 bps |12 B | 238 | |50 km rural | | | 239 +-------------+---------------+--------------+--------+ 240 |IEEE802.15.4k| < 20 km LoS |1.5 bps to |16/24/ | 241 |LECIM | < 5 km NoLoS | 128 kbps | 32 B | 242 +-------------+---------------+--------------+--------+ 243 |IEEE802.15.4g| 2-3 km LoS | 4.8 kbps to |2047 B | 244 |SUN | |800 kbps | | 245 +-------------+---------------+--------------+--------+ 246 |RPMA | 65 km LoS | up: 624kbps |64 B | 247 | | 20 km NoLoS |down: 156kbps | | 248 | | | mob: 2kbps | | 249 +-------------+---------------+--------------+--------+ 250 |DASH-7 | 2 km | 9 kbps |256 B | 251 | | | 55.55 kbps | | 252 | | | 166.66 kbps | | 253 +-------------+---------------+--------------+--------+ 254 |Weightless-w | 5 km urban | 1 kbps to |min 10 B| 255 | | | 10 Mbps | | 256 +-------------+---------------+--------------+--------+ 257 |Weightless-n |<5 km urban | 30 kbps to |max 20 B| 258 | |<30 km suburban| 100kbps | | 259 +-------------+---------------+--------------+--------+ 260 |Weightless-p |> 2 km urban | up to 100kbps| | 261 +-------------+---------------+--------------+--------+ 262 |NB-LTE |< 15 km | < 150 kbps | < 200 B| 263 +-------------+---------------+--------------+--------+ 265 Figure 1: Survey of LP-WAN technologies 267 The table Figure 1 gives some key performance parameters for some 268 candidate technologies. The maximum MTU size must be taken 269 carefully, for instance in LoRa, it take up to 2 sec to send a 50 270 Byte frame using the most robust modulation. In that case the 271 theoretical limit of 256 B will be impossible to reach. 273 Most of the technologies listed in the Annex A work in the ISM band 274 and may be used for private a public networks. Weightless-W uses 275 white spaces in the TV spectrum and NB-LTE will use licensed 276 channels. Some technologies include encryption at layer 2. 278 5. Acknowledgements 280 Thanks you very much for the discussion and feedback on the LP-WAN 281 mailing list, namely, Pascal Thubert, Carles Gomez, Samita 282 Chakrabarti, Xavier Vilajosana, Misha Dohler, Florian Meier, Timothy 283 J. Salo, Michael Richardson, Robert Cragie, Paul Duffy, Pat Kinney, 284 Joaquin Cabezas and Bill Gage. 286 6. Normative References 288 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 289 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 290 1996, . 292 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 293 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 294 December 1998, . 296 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 297 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 298 DOI 10.17487/RFC4861, September 2007, 299 . 301 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 302 Constrained-Node Networks", RFC 7228, 303 DOI 10.17487/RFC7228, May 2014, 304 . 306 Authors' Addresses 308 Ana Minaburo 309 Acklio 310 2bis rue de la Chataigneraie 311 35510 Cesson-Sevigne Cedex 312 France 314 Email: ana@ackl.io 316 Alexander Pelov 317 Acklio 318 2bis rue de la Chataigneraie 319 35510 Cesson-Sevigne Cedex 320 France 322 Email: a@ackl.io 323 Laurent Toutain 324 Institut MINES TELECOM ; TELECOM Bretagne 325 2 rue de la Chataigneraie 326 CS 17607 327 35576 Cesson-Sevigne Cedex 328 France 330 Email: Laurent.Toutain@telecom-bretagne.eu