idnits 2.17.1 draft-barthel-lpwan-oam-schc-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2020) is 1505 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 409 -- Looks like a reference, but probably isn't: '2' on line 409 -- Looks like a reference, but probably isn't: '3' on line 409 -- Looks like a reference, but probably isn't: '4' on line 409 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group D. Barthel 3 Internet-Draft Orange SA 4 Intended status: Informational L. Toutain 5 Expires: September 11, 2020 IMT Atlantique 6 A. Kandasamy 7 Acklio 8 D. Dujovne 9 Universidad Diego Portales 10 JC. Zuniga 11 SIGFOX 12 March 10, 2020 14 OAM for LPWAN using Static Context Header Compression (SCHC) 15 draft-barthel-lpwan-oam-schc-01 17 Abstract 19 With IP protocols now generalizing to constrained networks, users 20 expect to be able to Operate, Administer and Maintain them with the 21 familiar tools and protocols they already use on less constrained 22 networks. 24 OAM uses specific messages sent into the data plane to measure some 25 parameters of a network. Most of the time, no explicit values are 26 sent is these messages. Network parameters are obtained from the 27 analysis of these specific messages. 29 This can be used: 31 o To detect if a host is up or down. 33 o To measure the RTT and its variation over time. 35 o To learn the path used by packets to reach a destination. 37 OAM in LPWAN is a little bit trickier since the bandwidth is limited 38 and extra traffic added by OAM can introduce perturbation on regular 39 transmission. 41 Two scenarios can be investigated: 43 o OAM coming from internet. In that case, the NGW should act as a 44 proxy and handle specifically the OAM traffic. 46 o OAM coming from LPWAN devices: This can be included into regular 47 devices but some specific devices may be installed in the LPWAN 48 network to measure its quality. 50 The primitive functionalities of OAM are achieved with the ICMPv6 51 protocol. 53 ICMPv6 defines messages that inform the source of IPv6 packets of 54 errors during packet delivery. It also defines the Echo Request/ 55 Reply messages that are used for basic network troubleshooting (ping 56 command). ICMPv6 messages are transported on IPv6. 58 This document describes how basic OAM is performed on Low Power Wide 59 Area Networks (LPWANs) by compressing ICMPv6/IPv6 headers and by 60 protecting the LPWAN network and the Device from undesirable ICMPv6 61 traffic. 63 Status of This Memo 65 This Internet-Draft is submitted in full conformance with the 66 provisions of BCP 78 and BCP 79. 68 Internet-Drafts are working documents of the Internet Engineering 69 Task Force (IETF). Note that other groups may also distribute 70 working documents as Internet-Drafts. The list of current Internet- 71 Drafts is at https://datatracker.ietf.org/drafts/current/. 73 Internet-Drafts are draft documents valid for a maximum of six months 74 and may be updated, replaced, or obsoleted by other documents at any 75 time. It is inappropriate to use Internet-Drafts as reference 76 material or to cite them other than as "work in progress." 78 This Internet-Draft will expire on September 11, 2020. 80 Copyright Notice 82 Copyright (c) 2020 IETF Trust and the persons identified as the 83 document authors. All rights reserved. 85 This document is subject to BCP 78 and the IETF Trust's Legal 86 Provisions Relating to IETF Documents 87 (https://trustee.ietf.org/license-info) in effect on the date of 88 publication of this document. Please review these documents 89 carefully, as they describe your rights and restrictions with respect 90 to this document. Code Components extracted from this document must 91 include Simplified BSD License text as described in Section 4.e of 92 the Trust Legal Provisions and are provided without warranty as 93 described in the Simplified BSD License. 95 Table of Contents 97 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 98 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 99 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 100 4. Detailed behavior . . . . . . . . . . . . . . . . . . . . . . 4 101 4.1. Device does a ping . . . . . . . . . . . . . . . . . . . 4 102 4.1.1. Rule example . . . . . . . . . . . . . . . . . . . . 6 103 4.2. Device is ping'ed . . . . . . . . . . . . . . . . . . . . 6 104 4.2.1. Rule example . . . . . . . . . . . . . . . . . . . . 7 105 4.3. Device is the source of an ICMPv6 error message . . . . . 7 106 4.4. Device is the destination of an ICMPv6 error message . . 8 107 4.4.1. ICMPv6 error message compression. . . . . . . . . . . 9 108 5. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 10 109 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 110 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 112 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 113 8.2. Informative References . . . . . . . . . . . . . . . . . 13 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 116 1. Introduction 118 The primitive functionalities of OAM [RFC6291] are achieved with the 119 ICMPv6 protocol. 121 ICMPv6 [RFC4443] is a companion protocol to IPv6 [RFC8200]. 123 [RFC4443] defines a generic message format. This format is used for 124 messages to be sent back to the source of an IPv6 packet to inform it 125 about errors during packet delivery. 127 More specifically, [RFC4443] defines 4 error messages: Destination 128 Unreachable, Packet Too Big, Time Exceeded and Parameter Problem. 130 [RFC4443] also defines the Echo Request and Echo Reply messages, 131 which provide support for the ping application. 133 Other ICMPv6 messages are defined in other RFCs, such as an extended 134 format of the same messages [RFC4884] and other messages used by the 135 Neighbor Discovery Protocol [RFC4861]. 137 This document focuses on using Static Context Header Compression 138 (SCHC) to compress [RFC4443] messages that need to be transmitted 139 over the LPWAN network, and on having the LPWAN gateway proxying the 140 Device to save it the unwanted traffic. 142 LPWANs' salient characteristics are described in [RFC8376]. 144 2. Terminology 146 This draft re-uses the Terminology defined in 147 [I-D.ietf-lpwan-ipv6-static-context-hc]. 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 3. Use cases 157 In the LPWAN architecture, we can distinguish the following cases: 159 o the Device is the originator of an Echo Request message, and 160 therefore the destination of the Echo Reply message. 162 o the Device is the destination of an Echo Request message, and 163 therefore the purported source of an Echo Reply message. 165 o the Device is the (purported) source of an ICMP error message, 166 mainly in response to an incorrect incoming IPv6 message, or in 167 response to a ping request. In this case, as much as possible, 168 the core SCHC C/D should act as a proxy and originate the ICMP 169 message, so that the Device and the LPWAN network are protected 170 from this unwanted traffic. 172 o the Device is the destination of the ICMP message, mainly in 173 response to a packet sent by the Device to the network that 174 generates an error. In this case, we want the ICMP message to 175 reach the Device, and this document describes in section 176 Section 4.4.1 what SCHC compression should be applied. 178 These cases are further described in Section 4. 180 4. Detailed behavior 182 4.1. Device does a ping 184 If a ping request is generated by a Device, then SCHC compression 185 applies. 187 The format of an ICMPv6 Echo Request message is described in 188 Figure 1, with Type=128 and Code=0. 190 0 1 2 3 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Code | Checksum | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Identifier | Sequence Number | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Data ... 198 +-+-+-+-+- 200 Figure 1: ICMPv6 Echo Request message format 202 If we assume that one rule will be devoted to compressing Echo 203 Request messages, then Type and Code are known in the rule to be 128 204 and 0 and can therefore be elided with the not-sent CDA. 206 Checksum can be reconstructed with the compute-checksum CDA and 207 therefore is not transmitted. 209 [RFC4443] states that Identifier and Sequence Number are meant to 210 "aid in matching Echo Replies to this Echo Request" and that they 211 "may be zero". Data is "zero or more bytes of arbitrary data". 213 We recommend that Identifier be zero, Sequence Number be a counter on 214 3 bits, and Data be zero bytes (absent). Therefore, Identifier is 215 elided with the not-sent CDA, Sequence Number is transmitted on 3 216 bits with the LSB CDA and no Data is transmitted. 218 The transmission cost of the Echo Request message is therefore the 219 size of the Rule Id + 3 bits. 221 When the destination receives the Echo Request message, it will 222 respond back with a Echo Reply message. This message bears the same 223 format as the Echo Request message but with Type = 129 (see 224 Figure 1). 226 [RFC4443] states that the Identifier, Sequence Number and Data fields 227 of the Echo Reply message shall contain the same values as the 228 invoking Echo Request message. Therefore, a rule shall be used 229 similar to that used for compressing the Echo Request message. 231 TODO: how about a shared rule for Echo Request and Echo Reply with an 232 LSB(1) CDA on the Type field? Or exploiting the Up/Down direction 233 field in the rule? 235 4.1.1. Rule example 237 The following rule gives an example of a SCHC compression. The type 238 can be elided if the direction is taken into account. Identifier is 239 ignored and generated as 0 at decompression. This implies that only 240 one single ping can be launched at any given time on a device. 241 Finally, only the least significant 8 bits of the sequence number are 242 sent on the LPWAN, allowing a serie of 255 consecutive pings. 244 +----------------+--+--+--+---------+--------+------------++------+ 245 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 246 | | | | | | Opera. | Action ||(bits)| 247 +----------------+--+--+--+---------+---------------------++------+ 248 |ICMPv6 Type |8 |1 |Up|128 | equal | not-sent || | 249 |ICMPv6 Type |8 |1 |Dw|129 | equal | not-sent || | 250 |ICMPv6 Code |8 |1 |Bi|0 | equal | not-sent || | 251 |ICMPv6 Identif. |16|1 |Bi|0 | ignore | not-sent || | 252 |ICMPv6 Sequence |16|1 |Bi|0 | MSB(24)| LSB || 8 | 253 +================+==+==+==+=========+========+============++======+ 255 Figure 2: Example of compression rule for a ping from the device 257 4.2. Device is ping'ed 259 If the Device is ping'ed (i.e., is the destination of an Echo Request 260 message), the default behavior is to avoid propagating the Echo 261 Request message over the LPWAN. 263 This is done by proxying the ping request on the core SCHC C/D. This 264 requires to add an action when the rule is selected. Instead of been 265 processed by the compressor, the packet description is processed by a 266 ping proxy. The rule is used for the selection, so CDAs are not 267 necessary. 269 The resulting behavior is shown on Figure 3 and described below: 271 Device NGW core SCHC C/D Internet Host 273 | | | Echo Request, Code=0 | 274 | | |<---------------------------| 275 | | | | 276 | | |--------------------------->| 277 | | | Echo Reply, Code=0 | 279 Figure 3: Examples of ICMPv6 Echo Request/Reply 281 4.2.1. Rule example 283 The following rule shows an example of a compression rule for pinging 284 a device. 286 +----------------+--+--+--+---------+--------+------------++------+ 287 | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | 288 | | | | | | Opera. | Action ||(bits)| 289 +----------------+--+--+--+---------+---------------------++------+ 290 |ICMPv6 Type |8 |1 |Dw|128 | equal | not-sent || | 291 |ICMPv6 Type |8 |1 |Uo|129 | equal | not-sent || | 292 |ICMPv6 Code |8 |1 |Bi|0 | equal | not-sent || | 293 |ICMPv6 Identif. |16|1 |Bi|0 | ignore | value-sent || | 294 |ICMPv6 Sequence |16|1 |Bi|0 | MSB(24)| LSB || 8 | 295 +================+==+==+==+=========+========+============++======+ 297 Figure 4: Example of compression rule for a ping to a device 299 In this example, type and code are elided, the identifer has to be 300 sent, and the sequence number is limited to one byte. 302 4.3. Device is the source of an ICMPv6 error message 304 As stated in [RFC4443], a node should generate an ICMPv6 message in 305 response to an IPv6 packet that is malformed or which cannot be 306 processed due to some incorrect field value. 308 The general intent of this document is to spare both the Device and 309 the LPWAN network this un-necessary traffic. The incorrect packets 310 should be caught at the core SCHC C/D and the ICMPv6 notification 311 should be sent back from there. 313 Device NGW core SCHC C/D Internet Host 315 | | | Destination Port=XXX | 316 | | |<---------------------------| 317 | | | | 318 | | |--------------------------->| 319 | | | ICMPv6 Port Unreachable | 320 | | | | 321 | | | | 323 Figure 5: Example of ICMPv6 error message sent back to the Internet 325 Figure 5 shows an example of an IPv6 packet trying to reach a Device. 326 Let's assume that the port number used as destination port is not 327 "known" (needs better definition) from the core SCHC C/D. Instead of 328 sending the packet over the LPWAN and having this packet rejected by 329 the Device, the core SCHC C/D issues an ICMPv6 error message 330 "Destination Unreachable" (Type 1) with Code 1 ("Port Unreachable") 331 on behalf of the Device. 333 In that case the SCHC C/D acts as a router and MUST have a routable 334 IPv6 address to generate an ICMPv6 message. when compressing a packet 335 containing an IPv6 header, no compression rules are found and: * if a 336 rule contains some extension headers, a parameter problem may be 337 generated (type 4), * no rules contains the IPv6 prefix, a no route 338 to destination ICMPv6 message (type 0, code 0) may be generated, * a 339 prefix is found, but no devIID matches, a address unreachable ICMPv6 340 message (type 0, code 3) may be generated, * a device IPv6 address is 341 found, but no port matches, a port unreachable ICMPv6 message (type 342 0, code 4) may be generated, 344 TODO: This assumes that all ports that the Device listens to will be 345 matched by a SCHC rule. Is this the basic assumption of SCHC that 346 all packets that do not match a rule are rejected? If yes, why do 347 have fragmentation also for uncompressed packets? 349 TODO: discuss the various Type/Code that are expected to be generated 350 in response to various errors. 352 4.4. Device is the destination of an ICMPv6 error message 354 In this situation, we assume that a Device has been configured to 355 send information to a server on the Internet. If this server becomes 356 no longer accessible, an ICMPv6 message will be generated back 357 towards the Device by an intermediate router. This information can 358 be useful to the Device, for example for reducing the reporting rate 359 in case of periodic reporting of data. Therefore, we compress the 360 ICMPv6 message using SCHC and forward it to the Device over the 361 LPWAN. 363 Device NGW core SCHC C/D Internet Server 365 | | | | 366 | SCHC compressed IPv6 | | 367 |~~~~~~~~~~~|----------->|----------------------X | 368 | | | <--------------------- | 369 |<~~~~~~~~~~|------------| ICMPv6 Host unreachable | 370 |SCHC compressed ICMPv6 | | 371 | | | | 372 | | | | 374 Figure 6: Example of ICMPv6 error message sent back to the Device 376 Figure 6 illustrates this behavior. The ICMPv6 error message is 377 compressed as described in Section 4.4.1 and forwarded over the LPWAN 378 to the Device. 380 4.4.1. ICMPv6 error message compression. 382 The ICMPv6 error messages defined in [RFC4443] contain the fields 383 shown in Figure 7. 385 0 1 2 3 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Code | Checksum | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Value | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | As much of invoking packet | 393 + as possible without the ICMPv6 packet + 394 | exceeding the minimum IPv6 MTU | 396 Figure 7: ICMPv6 Error Message format 398 [RFC4443] states that Type can take the values 1 to 4, and Code can 399 be set to values between 0 and 6. Value is unused for the 400 Destination Unreachable and Time Exceeded messages. It contains the 401 MTU for the Packet Too Big message and a pointer to the byte causing 402 the error for the Parameter Error message. Therefore, Value is never 403 expected to be greater than 1280 in LPWAN networks. 405 The following generic rule can therefore be used to compress all 406 ICMPv6 error messages as defined today. More specific rules can also 407 be defined to achieve better compression of some error messages. 409 The Type field can be associated to a matching list [1, 2, 3, 4] and 410 is therefore compressed down to 2 bits. Code can be reduced to 3 411 bits using the LSB CDA. Value can be sent on 11 bits using the LSB 412 CDA, but if the Device is known to send smaller packets, then the 413 size of this field can be further reduced. 415 By [RFC4443], the rest of the ICMPv6 message must contain as much as 416 possible of the IPv6 offending (invoking) packet that triggered this 417 ICMPv6 error message. This information is used to try and identify 418 the SCHC rule that was used to decompress the offending IPv6 packet. 419 If the rule can be found then the Rule Id is added at the end of the 420 compressed ICMPv6 message. Otherwise the compressed packet ends with 421 the compressed Value field. 423 [RFC4443] states that the "ICMPv6 error message MUST include as much 424 of the IPv6 offending (invoking) packet ... as possible". In order 425 to comply with this requirement, if there is enough information in 426 the incoming ICMPv6 message for the core SCHC C/D to identify the 427 rule that has been used to decompress the erroneous IPv6 packet, this 428 Rule Id must be sent in the compressed ICMPv6 message to the Device. 429 TODO: the erroneous IPv6 packet header (not just the Rule Id) should 430 be sent back. This includes the Rule Id and the compression residue. 431 This means the SCHC C/D uses the context backwards (in the reverse 432 direction). How does the Device know it must also use the context 433 backwards? 435 TODO: how does one know that the "payload" of a compressed-header 436 packet is in fact another compressed header? 438 5. Traceroute 440 The traceroute6 program sends successive probe packets destined to a 441 chosen target but with the Hop Limit value successively incremented 442 from the initial value 1. 444 It expects to receive a "Time Exceeded" (Type = 3) "Hop Limit" (Code 445 = 0) ICMPv6 error message back from the successive routers along the 446 path to the destination. 448 The probe packet is usually a UDP datagram, but can also be a TCP 449 datagram or even an ICMPv6 message. The destination port is chosen 450 in the unassigned range in hope that the destination, when eventually 451 reached, will respond with a "Destination Unreachable" (Type = 1) 452 "Port Unreachable" (Code = 4) ICMPv6 error message. 454 It is not anticipated that a Device will want to traceroute a 455 destination on the Internet. 457 By contrast, a host on the Internet may attempt to traceroute an IPv6 458 address that is assigned to an LPWAN device. This is described in 459 Figure 8. 461 Device NGW core SCHC C/D Internet 463 | | | Hop Limit=1, Dest Port=XXX | 464 | | |<---------------------------| 465 | | | | 466 | | |--------------------------->| 467 | | | ICMPv6 Hop Limit error | 468 | | | | 469 | | | | 470 | | | Hop Limit=2, Dest Port=XXX | 471 | | |<---------------------------| 472 | | | | 473 | | |--------------------------->| 474 | | | ICMPv6 Port Unreachable | 476 Figure 8: Example of traceroute to the LPWAN Device 478 When the probe packet first reaches the core SCHC C/D, its remaining 479 Hop Limit is 1. The core SCHC C/D will respond back with a "Time 480 Exceeded" (Type = 3) "Hop Limit" (Code = 0) ICMPv6 error message. 481 Later on, when the probe packet reaches the code SCHC C/D with a Hop 482 Limit value of 2, the core SCHC C/D will, as explained in 483 Section 4.3, answer back with a "Destination Unreachable" (Type = 1) 484 "Port Unreachable" (Code = 4) ICMPv6 error message. This is what the 485 traceroute6 command expects. Therefore, the traceroute6 command will 486 work with LPWAN IPv6 destinations, except for the time displayed for 487 the destination, which is actually the time to its proxy. 489 However, if the probe packet happens to hit a port that matches a 490 SCHC rule for that Device, the packet will be compressed with this 491 rule and sent over the LPWAN, which is unfortunate. Forwarding of 492 packets to the Device over the LPWAN should only be done from 493 authenticated/trusted sources anyway. Rate-limitation on top of 494 authentication will mitigate this nuisance. 496 6. Security considerations 498 TODO 500 7. IANA Considerations 502 TODO 504 8. References 506 8.1. Normative References 508 [I-D.ietf-lpwan-ipv6-static-context-hc] 509 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 510 Zuniga, "Static Context Header Compression (SCHC) and 511 fragmentation for LPWAN, application to UDP/IPv6", draft- 512 ietf-lpwan-ipv6-static-context-hc-24 (work in progress), 513 December 2019. 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 521 Control Message Protocol (ICMPv6) for the Internet 522 Protocol Version 6 (IPv6) Specification", STD 89, 523 RFC 4443, DOI 10.17487/RFC4443, March 2006, 524 . 526 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 527 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 528 DOI 10.17487/RFC4861, September 2007, 529 . 531 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 532 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 533 DOI 10.17487/RFC4884, April 2007, 534 . 536 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 537 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 538 Acronym in the IETF", BCP 161, RFC 6291, 539 DOI 10.17487/RFC6291, June 2011, 540 . 542 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 543 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 544 May 2017, . 546 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 547 (IPv6) Specification", STD 86, RFC 8200, 548 DOI 10.17487/RFC8200, July 2017, 549 . 551 8.2. Informative References 553 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 554 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 555 . 557 Authors' Addresses 559 Dominique Barthel 560 Orange SA 561 28 chemin du Vieux Chene 562 BP 98 563 38243 Meylan Cedex 564 France 566 Email: dominique.barthel@orange.com 568 Laurent Toutain 569 IMT Atlantique 570 2 rue de la Chataigneraie 571 CS 17607 572 35576 Cesson-Sevigne Cedex 573 France 575 Email: laurent.toutain@imt-atlantique.fr 577 Arunprabhu Kandasamy 578 Acklio 579 1137A avenue des Champs Blancs 580 35510 Cesson-Sevigne Cedex 581 France 583 Email: arun@ackl.io 584 Diego Dujovne 585 Universidad Diego Portales 586 Vergara 432 587 Santiago 588 Chile 590 Email: diego.dujovne@mail.udp.cl 592 Juan Carlos Zuniga 593 SIGFOX 594 425 rue Jean Rostand 595 Labege 31670 596 France 598 Email: JuanCarlos.Zuniga@sigfox.com