idnits 2.17.1 draft-ayers-low-power-interop-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 13, 2020) is 1375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission H. Ayers 3 Internet-Draft P. Levis 4 Intended status: Informational Stanford University 5 Expires: January 14, 2021 July 13, 2020 7 Design Considerations for Low Power Internet Protocols 8 draft-ayers-low-power-interop-01 10 Abstract 12 Low-power wireless networks provide IPv6 connectivity through 13 6LoWPAN, a set of standards to aggressively compress IPv6 packets 14 over small maximum transfer unit (MTU) links such as 802.15.4. 16 The entire purpose of IP was to interconnect different networks, but 17 we find that different 6LoWPAN implementations fail to reliably 18 communicate with one another. These failures are due to stacks 19 implementing different subsets of the standard out of concern for 20 code size. We argue that this failure stems from 6LoWPAN's design, 21 not implementation, and is due to applying traditional Internet 22 protocol design principles to low-power networks. 24 We propose three design principles for Internet protocols on low- 25 power networks, designed to prevent similar failures in the future. 26 These principles are based around the importance of providing 27 flexible tradeoffs between code size and energy efficiency. We apply 28 these principles to 6LoWPAN and show that the modified protocol 29 provides a wide range of implementation strategies while allowing 30 implementations with different strategies to reliably communicate. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 14, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. 6LoWPAN Today . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Traditional Principles: Not Low-Power . . . . . . . . . . . . 10 70 5. Three Principles . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. Principle 1: Capability Spectrum . . . . . . . . . . . . 10 72 5.2. Principle 2: Capability Discovery . . . . . . . . . . . . 11 73 5.3. Principle 3: Explicit and Finite Bounds . . . . . . . . . 12 74 6. A Principled 6LoWPAN . . . . . . . . . . . . . . . . . . . . 12 75 6.1. Principle 1: Capability Spectrum . . . . . . . . . . . . 13 76 6.2. Principle 2: Capability Discovery . . . . . . . . . . . . 16 77 6.3. Principle 3: Provide Reasonable Bounds . . . . . . . . . 16 78 7. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 7.1. Implementations . . . . . . . . . . . . . . . . . . . . . 17 80 7.2. Compile-Time Costs . . . . . . . . . . . . . . . . . . . 18 81 7.3. Run-time Performance . . . . . . . . . . . . . . . . . . 20 82 8. Discussion and Conclusions . . . . . . . . . . . . . . . . . 21 83 9. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 9.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 22 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 89 12.2. Informative References . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 92 1. Introduction 94 Interoperability has been fundamental to the Internet's success. The 95 Internet Protocol (IP) allows devices with different software and 96 link layers to communicate. IP provides a basic communication 97 substrate for many higher layer protocols and applications. In the 98 decades of the Internet's evolution, we have accumulated and 99 benefited from a great deal of wisdom and guidance in how to design, 100 specify, and implement robust, interoperable protocols. 102 Over the past decade, the Internet has extended to tens of billions 103 of low-power, embedded systems such as sensor networks and the 104 Internet of Things. Hundreds of proprietary protocols have been 105 replaced by 6LoWPAN, a standardized format for IP networking on low- 106 power wireless link layers such as 802.15.4 [RFC6282] and Bluetooth 107 Low Energy [RFC7668]. 6LoWPAN was created with the express purpose of 108 bringing interoperable IP networking to low power devices, as stated 109 in the 6LoWPAN WG charter. Many embedded operating systems have 110 adopted 6LoWPAN, [tinyos] [riot] [mbedos] [contiki-ng] [contiki] 111 [lite-os] and [zephyr], and every major protocol suite uses it 112 (zigbee, openthread). In fact, devices today can communicate with 113 the broader Internet. 115 However, in many cases 6LoWPAN implementations cannot communicate 116 _with each other_. We find that no pairing of the major 117 implementations fully interoperates. Despite 6LoWPAN's focus on 118 interoperability, two key features of the protocol -- range extension 119 via mesh networking of devices, and the convenience of different 120 vendors being able to share a gateway -- are largely impossible 10 121 years later. 123 Each of the openly available 6LoWPAN stacks, most of which are used 124 in production, implements a subset of the protocol _and_ includes 125 compile-time flags to cut out additional compression/decompression 126 options. As a result, two devices might both use 6LoWPAN, yet be 127 unable to exchange certain IP packets because they use required 128 features the other does not implement. This is especially 129 problematic for gateways, which _need_ to be able to talk to multiple 130 implementations to enable significant scaling in real world 131 applications. 133 This draft argues that the failure of 6LoWPAN interoperability stems 134 from applying traditional protocol design principles to low-power 135 networks. Low-power protocols minimize energy consumption via 136 compression. Squeezing every bit out of packet headers, however, 137 requires many different options/operating modes. Principles such as 138 Postel's Law - "Be liberal in what you accept, and conservative in 139 what you send" [RFC1122] - state that an implementation must be able 140 to receive every feature, even thought it only sends some of them. 141 However, code space is tight on many systems. As a result, when an 142 application does not fit, developers cut out portions of the 143 networking stack and stop working with other devices. Put another 144 way, 3kB of unused compression code seems tiny, but when removing it 145 allows an additional 3kB of useful features, developers cut out parts 146 of 6LoWPAN and devices become part of a custom networked system 147 rather than the Internet. 149 This draft presents three design principles which resolve this 150 tension between interoperability and efficiency. Protocols following 151 these principles get the best of both worlds: resource-limited 152 devices can implement subsets of a protocol to save code space while 153 remaining able to communicate with every other implementation. 155 *Capability spectrum:* a low-power protocol specifies a linear 156 spectrum of capabilities. Simpler implementations have fewer 157 capabilities and save less energy, while fuller implementations have 158 strictly more capabilities and are able to save more energy. When 159 two devices differ in capability levels, communication can always 160 fall back to the lower one. 162 *Capability discovery:* a low-power protocol provides mechanisms to 163 discover the capability of communicating devices. This discovery can 164 be proactive (advertisements) or reactive (in response to errors). 166 *Explicit, finite bounds:* a low-power protocol specifies explicit, 167 finite bounds on growth during decompression. Without explicit 168 bounds, buffers must be sized too conservatively. In practice, 169 implementations allocate smaller buffers and silently drop packets 170 they cannot decompress. 172 This draft is not the first to observe poor 6LoWPAN interoperability 173 [probe-it-plugtest], but it is the first to identify this root cause. 174 It is the first to define design principles for protocols that allow 175 implementations to reduce code size and still interoperate. This 176 draft examines how these principles could be applied to a low power 177 protocol and evaluates the overhead of doing so. It finds that 178 applying these principles to 6LoWPAN promises interoperability across 179 a wide range of device capabilities, while imposing a code size cost 180 of less than 10%. In particular, capability discovery requires an 181 order of magnitude less code than the code size difference at the 182 extremes of our capability spectrum, with minimal runtime overhead. 184 2. Background 186 6LoWPAN is a set of standards on communicating IPv6 over low-power 187 wireless link layers such as IEEE 802.15.4 and Bluetooth[RFC4944] 188 [RFC6282] [RFC7668]. 6LoWPAN primarily specifies two things: 189 aggressive compression of IPv6 headers and how to fragment/re- 190 assemble packets on link layers whose MTU is smaller than the minimum 191 1280 bytes required by IPv6. 6LoWPAN also specifies optimized IPv6 192 Neighbor Discovery. 6LoWPAN is critical to ensuring that IPv6 193 communication does not exceed the energy budget of low power systems. 195 The interoperability IP provides is a goal in and of itself, and so 196 many different network stacks, including ZigBee and Thread, have 197 transitioned to supporting IP connectivity with 6LoWPAN. IP 198 connectivity allows systems to easily incorporate new services and 199 applications, and allows applications to build on all of the existing 200 Internet systems, such as network management and monitoring. 202 *Low Power Hardware and Operating Systems* 204 **IoT Platform** **Code (kB)** **Year** 205 -------------------- --------------- ---------- 206 EMB-WMB 64 2012 207 Zolertia Z1 92 2013 208 TI CC2650 128 2015 209 NXP MKW40Z 160 2015 210 SAMR21 XPro 256 2014 211 Nordic NRF52840 DK 512 2018 213 Figure 1: Flash Size across IoT Platforms 215 Figure 1 shows a variety of older and more recent low-power 216 platforms. Modern microcontrollers typically have 128-512 kB of code 217 flash. Applications often struggle with these limits on code flash, 218 and rarely leave code space unused. Embedded systems are application 219 specific, and use their limited available resources toward different 220 ends. Despite this, they still rely on a small number of reusable 221 OSes for basic abstractions. 223 To support the highly constrained applications and devices for which 224 embedded OSes are used, embedded OSes must be minimal. However, the 225 manner in which they must be minimal varies - some applications 226 require minimal use of radio energy, which can require code size 227 consuming techniques like compression, while others require tiny/low 228 cost MCUs without space for those mechanisms. To support this 229 variety, OSes have compile-time flags to include or exclude parts of 230 the system or networking stack (contiki,mbedos,contiki-ng). Some 231 systems take a more extreme approach, dynamically generating the 232 minimum code to compile from the application itself (tinyos). Part 233 of this minimalist focus is that until application developers demand 234 certain features, OSes are likely to leave them out entirely (a 235 requirement often specified in contribution guides - contiki-ng). 236 These techniques are critical to ensuring a given OS can support a 237 wide range of embedded platforms, and influence the implementation of 238 network protocols. 240 3. 6LoWPAN Today 242 The original 6LoWPAN working group charter stated "The Working Group 243 will generate the necessary documents to ensure interoperable 244 implementations of 6LoWPAN networks". However looking at 245 implementations today, we find that each includes a different subset 246 of the protocol. Source code shows this is due to concerns with code 247 size. Experiences with a new implementation verify these concerns. 249 *Feature Fail* A 6LoWPAN receiver has much less flexibility than a 250 sender: it must be able to process any valid compression it receives. 251 Figure 2 shows the receiver features supported by 6 major open-source 252 6LoWPAN stacks. Some, such as TinyOS, are mostly developed and used 253 in academia. Others, such as ARM Mbed and Nest's OpenThread, are 254 developed and supported commercially. Contiki and Contiki-NG sit 255 somewhere in the middle, having both significant academic and 256 commercial use. Riot is an open-source OS with hundreds of 257 contributors for industrial, academic, and hobbyist use. Two widely 258 used open source stacks excluded from this analysis are LiteOS 259 [lite-os] and Zephyr [zephyr] -- they are excluded because LiteOS 260 uses the same 6LoWPAN library (LWIP) used in MBED-OS, and Zephyr 261 simply imports OpenThread. 263 In almost all cases, each stack's support for features is symmetric 264 for sending and receiving. There are significant mismatches in 265 feature support between stacks. These mismatches lead to 266 deterministic cases when IP communication fails. We verified these 267 failures by modifying existing network applications and testing them 268 on hardware, using Wireshark to verify packets were compressed and 269 formatted as we expected when receivers failed to decode packets. 270 Every implementation pair fails for some type of packet which can be 271 organically generated by one of the stacks. This result may be 272 surprising when compared to prior work which demonstrated successful 273 interoperability, such as [RPL-interop]. However, this early success 274 preceded the release of RFC 6282, which increased the complexity (and 275 overhead) of 6LoWPAN. 277 Feature Stack 278 ------------------------------------- ------- -- -- ---- --- ------ 279 Contiki NG OT Riot Arm TinyOS 280 ------------------------------------- ------- -- -- ---- --- ------ 281 Uncompressed IPv6 o o o o o 282 6LoWPAN Fragmentation o o o o o o 283 1280 byte packets o o o o o o 284 Dispatch_IPHC header prefix o o o o o o 285 IPv6 Stateless Address Compression o o o o o o 286 Stateless multicast addr compression o o o o o o 287 802.15.4 16 bit short address support o o o o o 288 IPv6 Address Autoconfiguration o o o o o o 289 Stateful Address Compression o o o o o o 290 Stateful multicast addr compression o o o 291 TC and Flow label compression o o o o o o 292 NH Compression: Ipv6 (tunneled) o o o 293 IPv6 NH Compression: UDP o o o o o o 294 UDP port compression o o o o o o 295 UDP checksum elision o 296 Compression + headers past first frag o o 297 Compression of IPv6 Extension Headers ~ ~ o o 298 Mesh Header o o ~ 299 Broadcast Header o 300 Regular IPv6 ND o o o o ~ 301 RFC 6775 6LoWPAN ND o o 302 RFC 7400 Generic Header Compression 303 ------------------------------------- ------- -- -- ---- --- ------ 304 ~ = Partial Support 306 Figure 2: 6LoWPAN Interoperability Matrix 308 +-----------+---------+-------------+------+----------------+ 309 | Stack Code Size Measurements (kB) | 310 +-----------+---------+-------------+------+----------------+ 311 | | 6Lo-All | Compression | Frag | Mesh/Bcast Hdr | 312 +-----------+---------+-------------+------+----------------+ 313 | Contiki-NG| 6.2 | 3.4 | 1.9 | N/A | 314 | Contiki | 11.3 | 6.0 | 3.3 | N/A | 315 | OT | 26.6 | 20.0 | 1.3 | 4.5 | 316 | Riot | 7.5 | >4.7 | 1.5 | N/A | 317 | Arm Mbed | 22.1 | 18.0 | 3.1 | 1331 | 318 | TinyOS | 16.2 | ---- | ---- | 0.6 | 319 +-----------+---------+-------------+------+----------------+ 321 Figure 3: 6LoWPAN stack code size for 6 open source stacks. The code 322 size varies by over a factor of 4, in part due to different feature 323 sets. Compression dominated the code requirements of each stack. 324 Individual components do not add up to total as some size cannot be 325 clearly attributed to any subcomponent. TinyOS's whole-program 326 optimization model precluded separating out subcomponents, and only 327 includes incomplete mesh header support. 329 *Why?* 331 IP communication can consistently fail in low-power networks, despite 332 the presence of succinct standards (RFC 6282 + RFC 4944 is 52 pages) 333 designed for low-power devices. Worse, this failure is silent: the 334 receiver will simply drop the packet. Examining the documentation 335 and implementation of each stack, code size concerns motivated 336 feature elision. Mbed, Riot, and Contiki even provide compile-time 337 flags to remove additional features for particularly constrained use 338 cases. 340 Figure 3 shows a break down of the code size of each stack. 341 Compression dominates the code size of 6LoWPAN implementations, and 342 in several cases 6LoWPAN's size is comparable to the whole rest of 343 the IPv6 stack. The Contiki and Contiki-NG implementations are 344 significantly smaller than the others in part because they elide 345 significant and complex features. The ARM Mbed IPv6 stack uses 45kB 346 of flash. This is nearly 1/3 of the available space on a CC2650, 347 just for IPv6: it does not include storage, sensors, the OS kernel, 348 cryptography, higher layer protocols, signal processing, or 349 applications. 351 Can a careful developer implement a leaner, fully-featured stack? To 352 answer this question, we implemented our own 6LoWPAN stack. Our 353 open-source implementation is written in Rust, for Tock, a secure 354 embedded OS [tock]. 356 Our experiences support the comments and documentation of the other 357 stacks. We surpassed the size of the Contiki-NG and Riot 6LoWPAN 358 code before adding support for recursive compression of IPv6 or the 359 mesh and broadcast headers. We noted several aspects of the protocol 360 required surprisingly complex code to properly handle. For example, 361 6LoWPAN requires IPv6 tunneled inside a compressed packet to compress 362 interior headers as well. This requires the decompression library to 363 support recursive invocation, which increases minimum execution stack 364 sizes and makes tracking buffer offsets during decompression more 365 difficult. Refusing to support tunneled IPv6 packets (e.g., Contiki) 366 greatly simplified the code. Another example: headers in the first 367 6LoWPAN sub-IP fragment must be compressed, while headers in 368 subsequent fragments must not be compressed. Given that low-power 369 link layers have variable length headers, correctly determining 370 exactly where to fragment and what should be compressed requires 371 complex interactions between layers of the stack. Finally, 6LoWPAN 372 requires support for out-of-order reception of fragments, potentially 373 from different packets. This forced our receiver to store and track 374 state for a collection of received packets, preventing reliance on a 375 single global receive buffer. The exercise of implementing a 6LoWPAN 376 stack from the ground up affirmed that code size concerns encourage 377 feature elision. 379 *Why does it matter?* 381 For any 6LoWPAN implementation, there exists a border router 382 implementation that can connect it to the broader Internet. But this 383 status-quo model of connectivity forces vertical integration and 384 fails to meet the original design goals of 6LoWPAN, for two reasons. 386 First, a 6LoWPAN gateway can not know how to safely compress packets 387 for different nodes, unless it communicates only with devices 388 produced by the same vendor. As a result, for a coverage area 389 containing devices produced by 5 different vendors, 5 gateways are 390 required. If not for feature mismatches, a single gateway would 391 suffice. Second, the current situation significantly limits the 392 potential for range extension via mesh topologies. Most existing 393 6LoWPAN meshes rely on "route-over" mesh routing at the network 394 layer, which requires that each node can at least partially 395 decompress and recompress IP headers when forwarding. Mesh-under 396 routing is no better, as implementation of the mesh header is not 397 universal (see Figure 2). Poor interoperability worsens the 398 usability, range, cost, and efficiency of these networks. 400 4. Traditional Principles: Not Low-Power 402 Over the past 45 years, the Internet community has coalesced on a 403 small number of design principles. Connectivity through 404 interoperability is a key premise of the Internet. Principles such 405 as layering and encapsulation support composing protocols in new ways 406 (e.g., tunneling), while the end-to-end principle [end-to-end] allows 407 building a robust network out of an enormous and complex collection 408 of unreliable parts. The robustness principle asserts that 409 implementations should make no assumptions on packets they receive: 410 bugs, transmission errors, and even memory corruption can cause a 411 device to receive arbitrarily formatted packets. It also asserts 412 that an implementation must be ready to receive any and all properly 413 formatted packets. This aspect of the principle is often attributed 414 to John Postel as Postel's Law, first written down in the initial 415 specification of IPv4: "In general, an implementation should be 416 conservative in its sending behavior, and liberal in its receiving 417 behavior." 419 Protocols often have optional features ("MAY, SHOULD, and OPTIONAL" 420 in RFC language). Implicitly, due to Postel's Law, a receiver needs 421 to handle either case. This scenario creates an asymmetry, where 422 sender code can have reduced complexity but receiver code must be 423 large and complex. 425 We need to think about low-power protocols differently. They need 426 new principles to help guide their design. These principles need to 427 embrace that there is no "one size fits all" design, while defining 428 how devices choosing different design points interoperate. 429 Flexibility needs to exist not only for senders, but also receivers, 430 without harming interoperability. 432 5. Three Principles 434 This section describes three protocol design principles which prevent 435 failures in low-power protocols. These principles are absolutely 436 necessary to ensure interoperable implementations in this space, and 437 should be closely observed. 439 5.1. Principle 1: Capability Spectrum 441 A low power protocol should be deployable/installable on devices 442 which are at the low end of code and RAM resources. Rather than 443 require every device pay the potential energy costs of fewer 444 optimizations, a protocol should support a linear spectrum of device 445 capabilities. 447 This may seem familiar -- the IP [RFC0791] and TCP [RFC0793] 448 specifications provide optional fields which can be used by endpoints 449 at their leisure; many non-standard HTTP headers will be ignored 450 unless both client and server support them; TLS ciphersuite support 451 is often asymmetrical. But this principle is different. For those 452 examples, no linear spectrum exists -- support for any particular 453 capability is generally unrelated to support for any other. Checking 454 for support of any feature requires explicit enumeration of each, 455 making it impossible to effectively compress such options. A non- 456 linear spectrum requires storing feature support for every neighbor 457 in RAM, or re-discovering capabilities on every exchange. 459 Low power protocols require simpler capability management. A low 460 power protocol should define a capability spectrum with a clear 461 ordering in which especially resource constrained devices can reduce 462 code size or RAM use by eliding features. Such a spectrum makes a 463 protocol usable by extremely low resource devices without forcing 464 more resourceful devices to communicate inefficiently. 466 This capability spectrum should be a linear scale. For a device to 467 support capability level $N$, it must also support all lower 468 capability levels. More complex configuration approaches (e.g., a 469 set of independent options) might allow for a particular 470 implementation to be more efficient, picking the features that give 471 the most benefit for the least added complexity. However, this sort 472 of optimization makes interoperability more difficult, as two devices 473 must negotiate each specific feature to use. 475 5.2. Principle 2: Capability Discovery 477 The second principle follows from the first: if different capability 478 levels exist, there should be a mechanism for two devices to 479 determine what level to communicate with. 481 The capability negotiation we propose here differs from capability 482 discovery mechanisms built for traditional systems, such as IP Path 483 MTU discovery or the Link Layer Discovery Protocol (LLDP). IP Path 484 MTU discovery relies on continual probing until an acceptable value 485 is discovered. LLDP requires regular, detailed capability 486 advertisements at a fixed interval. The energy overhead of network 487 probing or advertising is unacceptable in most low power 488 environments. Capability discovery in low power networks should 489 require no more than one failure between any two neighbors, even if 490 this slightly increases the overhead per error. Proactive capability 491 discovery should be built into baseline communication required for 492 tasks like neighbor discovery or route maintenance. Further, 493 assumptions for traditional systems that prohibit storing per- 494 endpoint state do not apply, as nodes store information about link- 495 layer neighbors, _not IP endpoints_. This is needed because low-power 496 networks with route over topologies frequently involve decompression 497 and re-compression at each hop to enable forwarding. Low power nodes 498 have few neighbors, so storing a few bits of state for each is 499 feasible and can significantly reduce the amount of radio energy 500 needed for communication. The code size cost of storing state is 501 small compared to the cost of complex compression mechanisms. 503 In a low power network with capability discovery, if two devices wish 504 to communicate, they default to the lower of their supported 505 capability levels. E.g. a level 2 and a level 4 device should 506 communicate at level 2. One offshoot of this principle is that it 507 requires implementations have symmetric capabilities for send and 508 receive - no benefits can be realized from an asymmetric 509 implementation. 511 5.3. Principle 3: Explicit and Finite Bounds 513 Protocols must specify explicit and reasonable bounds on recursive or 514 variable features so implementations can bound RAM use. This allow 515 implementations to safely limit their RAM use without silent 516 interoperability failures. This also ensures that capability 517 discovery is sufficient for interoperability. 519 The idea of imposing bounds is, on its own, not unique to this space. 520 TCP enforces a finite limit of 40 bytes for TCP options which may be 521 appended to the TCP header, as does IPv4. DHCP allows for the 522 communication of maximum DHCP message sizes. In the space of low 523 power Internet protocols, however, this idea _must be pervasive._ 524 Notably, the original designers of a specification may not know 525 exactly what these values should be. This is not a new problem: TCP 526 congestion control, for example, had to specify initial congestion 527 window values. In this space, bounds should initially be very 528 conservative. Over time, if increasing resources or knowledge 529 suggests they should grow, then future devices will have the onus of 530 using fewer resources to interoperate with earlier ones. The 531 capability spectrum defined in the previous two principles can be 532 helpful in this regard. 534 6. A Principled 6LoWPAN 536 This section proposes how to apply the three principles in the 537 previous section to 6LoWPAN through specific modifications to the 538 protocol. These modifications ensure that two 6LoWPAN devices can 539 communicate even if they choose different code size/energy efficiency 540 tradeoffs. We refer to this modified protocol as Principled 6LoWPAN 541 (P6LoWPAN). 543 This application of our principles is not intended as a suggestion 544 that these changes be made immediately to 6LoWPAN, as modifying an 545 established protocol is a complex task very different from 546 constructing new protocols. Instead, this application is a tool for 547 evaluating these principles, and an example for how they should be 548 applied. 550 6.1. Principle 1: Capability Spectrum 552 We propose replacing the large collection of "MUST" requirements -- 553 the features in Figure 2 --into 6 levels of functionality. These 554 "Capability Levels" are depicted in Figure 4. 556 +----------------+-----------------------------------+ 557 | **Capability** | **Basic Description / Added | 558 | | Features** | 559 +================+===================================+ 560 | Level 0 | Uncompressed IPv6 + ability to | 561 | | send ICMP errors | 562 +----------------+-----------------------------------+ 563 | | - Uncompressed IPv6 | 564 | | | 565 | | - 6LoWPAN Fragmentation | 566 | | (Fragment Header) | 567 | | | 568 | | - 1280 Byte Packets | 569 | | | 570 | | - Stateless decompression of | 571 | | source addresses | 572 +----------------+-----------------------------------+ 573 | Level 1 | IPv6 Compression Basics + | 574 | | Stateless Addr Compression | 575 +----------------+-----------------------------------+ 576 | | - Support for the | 577 | | Dispatch\_IPHC Header Prefix | 578 | | | 579 | | - Correctly handle elision of | 580 | | IPv6 length and version | 581 | | | 582 | | - Stateless compression of all | 583 | | unicast addresses | 584 | | | 585 | | - Stateless compression of | 586 | | multicast addresses | 587 | | | 588 | | - Compression + 16 bit | 589 | | link-layer addresses | 590 | | | 591 | | - IPv6 address | 592 | | autoconfiguration | 593 +----------------+-----------------------------------+ 594 | Level 2 | Stateful IPv6 Address Compression | 595 +----------------+-----------------------------------+ 596 | | - Stateful compression of | 597 | | unicast addresses | 598 | | | 599 | | - Stateful compression of | 600 | | multicast addresses | 601 +----------------+-----------------------------------+ 602 | Level 3 | IPv6 Traffic Class and Flow Label | 603 | | Compression | 604 +----------------+-----------------------------------+ 605 | | - Traffic Class compression | 606 | | | 607 | | - Flow Label Compression | 608 | | | 609 | | - Hop Limit Compression | 610 +----------------+-----------------------------------+ 611 | Level 4 | Next Header Compression + UDP | 612 | | Port Compression | 613 +----------------+-----------------------------------+ 614 | | - Handle Tunneled IPv6 | 615 | | correctly | 616 | | | 617 | | - Handle the compression of the | 618 | | UDP Next Header | 619 | | | 620 | | - Correctly handle elision of | 621 | | the UDP length field | 622 | | | 623 | | - Correctly handle the | 624 | | compression of UDP ports | 625 | | | 626 | | - Handle headers past the first | 627 | | fragment, when first fragment | 628 | | compressed. | 629 +----------------+-----------------------------------+ 630 | Level 5 | Entire Specification | 631 | (all routers) | | 632 +----------------+-----------------------------------+ 633 | | - Support the broadcast header | 634 | | and the mesh header | 635 | | | 636 | | - Support compression of all | 637 | | IPv6 Extension headers | 638 +----------------+-----------------------------------+ 639 Figure 4: Capability Spectrum 641 These levels prioritize features which provide the greatest energy 642 savings per byte of added code size, based off our code size 643 measurements and the number of bits saved by each additional 644 compression mechanism. They allow for a wide range of code size/ 645 efficiency tradeoffs. 647 For example, addresses dominate an uncompressed IPv6 header. Level 0 648 devices only support compressed source addresses, while level 1 649 devices support all stateless address compression. In one early 650 design of this spectrum, Level 0 supported only uncompressed packets. 651 However, this raises a problem with ICMP error generation. If a node 652 cannot decompress the source address of a received packet, it cannot 653 send ICMP errors. ICMP errors are required for capability discovery. 654 Stateful compression depends on an out-of-band signal to set up 655 state, such that nodes only send statefully compressed packets to 656 nodes who also support it. Therefore decompressing stateless source 657 addresses is a minimum requirement. 659 The classes in this scale do not precisely reflect the current 660 feature support of the implementations described in Section 3. For 661 example, Contiki supports UDP port compression (level 4) but does not 662 support 802.15.4 short addresses (level 2) or stateful multicast 663 compression (level 3): following this formulation, Contiki only 664 provides level 1 support. If Contiki supported 16-bit addresses, it 665 would provide level 2 support. A concrete spectrum such as the one 666 above gives stack designers a structure and set of guidelines on the 667 order in which to implement features. Based on our experiences 668 developing a 6LoWPAN stack, we believe that if this scale existed as 669 part of the initial specification, implementations would have made an 670 effort to adhere to it. 672 One additional advantage of this spectrum is that it allows for some 673 future additions to the P6LoWPAN specification without breaking 674 interoperability between new and old implementations. For example, 675 our scale does not include support for Generic Header Compression 676 [RFC7400] because none of the open-source stacks we analyzed 677 implement it. Despite this, support for this RFC could easily be 678 added as a new class on this linear scale (as Class 6), and devices 679 supporting it would know to not use it when communicating with lower 680 class implementations. 682 This spectrum requires that a node store 3 bits of state for each 683 neighbor. Given that low-power nodes often store ten or more bytes 684 for each entry in their link table (link quality estimates, 685 addresses, etc.), this cost is small. 6LoWPAN already assumes that 686 routers are more resourceful devices, P6LoWPAN routers are required 687 to be level 5. 689 6.2. Principle 2: Capability Discovery 691 We propose two mechanisms by which P6LoWPAN performs capability 692 discovery: neighbor discovery (ND) and ICMP\@. Neighbor discovery 693 [RFC4861] is analogous to ARP in IPv4: it allows IPv6 devices to 694 discover the link layer addresses of neighboring addresses as well as 695 local gateways. Devices use neighbor discovery to proactively 696 discover capability levels and ICMP to detect when incompatible 697 features are used. Of the two, only ICMP is required. Neighbor 698 discovery simply allows a pair of differing nodes to avoid an initial 699 ICMP error, and allows for optimization of host-router communication 700 during neighbor discovery. 702 *ICMP:* We propose adding a new ICMPv6 message type--P6LoWPAN Class 703 Unsupported--which a device sends in response to receiving 6LoWPAN 704 features it does not understand. This error encodes the device's 705 capability level. A node receiving such an error updates its link 706 table entry with the capability level. In the future, any packets 707 sent to that address use at most the supported level. 709 *Neighbor discovery:* We propose adding an IPv6 ND option that allows 710 a device to communicate its capability class during network 711 association. This option would be included in Router Solicitations 712 and Neighbor Advertisements, and would allow all devices that obtain 713 link-layer addresses via ND to also know how to send packets which 714 that neighbor can receive. When a node uses ND to resolve an IP 715 address to a link layer address, it learns the supported capability 716 level as well as the link layer address. This option minimizes the 717 energy cost of communicating capabilities. It is worth noting that 718 RFC 7400 already employs a similar method for communicating whether 719 devices implement General Header Compression: adding such an option 720 is clearly viable [RFC7400]. 722 6.3. Principle 3: Provide Reasonable Bounds 724 Section 3 discussed two missing bounds which affect 6LoWPAN 725 interoperability: limits on header decompression and bounds on 726 recursion when decompressing tunneled IPv6. 728 For P6LoWPAN, we propose that header decompression be bounded to 51 729 bytes. This bound allows for significant RAM savings in 730 implementations that decompress first fragments into the same buffer 731 in which the fragment was originally held. 51 bytes is a good 732 tradeoff between RAM savings and how frequently we expect such a 733 bound would force packets to be sent uncompressed. A 51 byte limit 734 allows for transmission of a packet containing a maximally compressed 735 IP header (+38 bytes), a maximally compressed UDP header (+6 bytes), 736 and one maximally compressed IPv6 extension header (+7 bytes). This 737 allows saving hundreds of bytes of RAM, without jeopardizing 738 interoperability. Packets requiring more decompression than this are 739 extremely rare, and could be sent uncompressed. How rare? It is 740 only possible to surpass this limit if tunneled IPv6 is used or 741 multiple IPv6 extension headers are present. As of 2014, a real- 742 world study of IPv6 extension header use found that 99% of packets 743 with _multiple_ extension headers were dropped in the real Internet, 744 as published at IETF 90. 746 Second, we propose that headers for tunneled IPv6 should not be 747 compressed. The primary motivation for this feature was from the RPL 748 protocol [RFC6550], as discussed in Section 3. However, the fact 749 that RPL must tunnel IPv6 in this way is generally agreed to be a 750 problem and a wart in its design that should be avoided when 751 possible. This change allows implementations to avoid recursive 752 functions to decompress these headers, and instead use simple if/else 753 statements. 755 7. Evaluation 757 This section evaluates the costs of applying our principles to 758 6LoWPAN. The principles are written such that interoperability comes 759 by construction, and thus interoperability of the modified protocol 760 cannot be directly evaluated without observing implementations 761 written by different stakeholders. But indirect evaluation is 762 possible. Can a reasonable set of capability levels provide a good 763 range of implementation complexity from which a developer can choose? 764 Is the overhead of the proposed mechanisms low enough to make them 765 viable? Are the savings afforded by a linear capability spectrum 766 worth the associated limitations? We find the incremental costs of 767 capability discovery mechanisms is small, adding 172-388 bytes of 768 code in the worst case. We find that the capability spectrum allows 769 meaningful savings in code size and memory usage. Finally, we find 770 capability discovery has a low run-time performance cost when a 771 linear spectrum is used. 773 7.1. Implementations 775 First, we implemented the proposed P6LoWPAN on the Contiki-NG 6LoWPAN 776 stack, modifying it such that a compile-time option determines which 777 features of 6LoWPAN are compiled. We selected Contiki-NG because it 778 has the smallest 6LoWPAN stack of those tested, so any overheads the 779 mechanisms introduce would be most pronounced. Our changes required 780 modifying 500 lines of code relative to the head of the 4.2 release 781 of Contiki-NG. We did not add additional 6LoWPAN features which were 782 absent from the original Contiki-NG 6LoWPAN stack. Our code size 783 numbers therefore represent a conservative lower bound of the total 784 possible savings. All code sizes provided in this section are 785 compiled with the Texas Instruments CC2650 as the target. 787 We also added ICMP and ND support for capability discovery. The 788 updated stack responds to incompatible 6LoWPAN messages with an ICMP 789 error, and communicates its capability level in Router Solicitation 790 messages using the 6CIO prefix originally defined in [RFC7400]. It 791 stores the capability class of each node in its link table, and 792 compresses IPv6 packets by the maximum amount supported by the 793 destination. 795 Finally, we implemented a second modified 6LoWPAN stack in Contiki- 796 NG, which does not follow the recommendation of using a linear 797 capability spectrum. In this modified implementation, each node can 798 select any of the 6LoWPAN features it chooses. We refer to this 799 implementation as FLEX-6LoWPAN. For this alternative policy, we 800 isolated 26 features of 6LoWPAN as single bit flags in a 32 bit 801 bitfield. Thus, FLEX-6LoWPAN stores and communicates capabilities 802 using 4 byte objects. FLEX-6LOWPAN also supports the added 803 granularity required to maximally compress outgoing messages intended 804 for a device supporting any specific combination of features. We did 805 not add back in any 6LoWPAN features which the Contiki-NG stack did 806 not originally support. This second implementation required 807 modifying about 300 additional lines of code from the P6LoWPAN 808 implementation. 810 7.2. Compile-Time Costs 812 Figure 5 shows the size of the original Contiki-NG 6LoWPAN stack 813 compiled at each possible capability level. Each capability level 814 adds between 0.25 and 1.05 kB of code, and the spectrum enables 815 implementations to cut the size of the 6LoWPAN stack by up to 45%. 816 The code size cost of adding capability discovery, using the P6LoWPAN 817 implementation with the linear capability spectrum, is shown in 818 Figure 6. Capability discovery adds 178-388 bytes, a fraction of the 819 size which implementations can save by supporting lower capability 820 levels. The code added for communication varies across capability 821 levels because the number of code paths for ICMP error generation and 822 compression changes. 824 Capability Code Size (kB) Increase (kB) 825 ---------------- -------------------- ------------------- 826 Level 0 3.2 \- 827 Level 1 4.2 1.0 828 Level 2 4.8 0.6 829 Level 3 5.1 0.3 830 Level 4 5.6 0.5 831 Level 5 6.2 0.6 832 ---------------- -------------------- ------------------- 834 Figure 5: 6LoWPAN code size of different capabilities levels in 835 Contiki-NG. The spectrum spans a nearly 100% increase in code size. 837 Capability Base w/Discovery Increase 838 ---------------- ---------- ----------------- -------------- 839 Level 0 3.2 3.4 188 bytes 840 Level 1 4.2 4.4 260 bytes 841 Level 2 4.8 5.2 388 bytes 842 Level 3 5.1 5.4 340 bytes 843 Level 4 5.6 5.9 296 bytes 844 Level 5 6.2 6.3 172 bytes 845 ---------------- ---------- ----------------- -------------- 847 Figure 6: The cost of implementing capability discovery in Contiki-NG 848 is on average less than 5% of the total 6LoWPAN size; the maximum 849 size reduction from choosing a lower capability level is 10x the 850 discovery cost. 852 Figure 7 presents the compile-time costs of using an arbitrary 853 bitfield instead of a linear capability spectrum by comparing our 854 P6LoWPAN implementation with our FLEX-6LoPWAN implementation. The 855 bitfield approach requires 32 bits per neighbor to store 856 capabilities, instead of 3 bits. More importantly, it complicates 857 determining the allowable compression between two nodes, as 858 demonstrated by the code size increase. The important takeaway here 859 is that opting for a less restrictive set of feature combinations 860 mitigates much of the savings provided by implementing capabilities. 861 For example, a FLEX-6LoWPAN device with the equivalent of level 4 862 capabilities requires more code space than a level 5 P6LoWPAN device 863 - the linear capability spectrum makes a difference. The code size 864 addition for FLEX-6LoWPAN is a conservative lower bound, as we did 865 not need to add checks for handling 6LoWPAN compression features that 866 Contiki-NG does not support. 868 7.3. Run-time Performance 870 *ND Cost* 6LoWPAN ND communication [RFC6775] is host-initiated and 871 flows through routers (which must be level 5), and nodes store 872 neighbor capability levels alongside link layer addresses: thus there 873 is no possibility of communication failures due to capability 874 mismatches. Therefore the cost of capability discovery in networks 875 that use IPv6 ND is exclusively that certain ND messages become 876 longer (router solicitations and neighbor advertisements are sent 877 with an added capability option). To put this added cost in 878 perspective, The equation below shows the total link-layer payload 879 bytes sent/received for ND by a node in its initial wake-up period. 880 This equation assumes the configuration described in RFC 6775 as the 881 "Basic Router Solicitation Exchange" - route over topology, 1 6LoWPAN 882 context, 1 on-link prefix, and the host requires address 883 registration. All variables not affected by the use of capability 884 discovery are assigned the minimum possible value for the scenario 885 discussed, so that the overhead of capability discovery represents a 886 worst case. 888 If C = total link layer payload sent/recieved for ND, and N = 889 endpoints requiring address resolution: 891 C = Router Soliciation {RS} + Min. IP Hdr {2} + Router Advertisement 892 {104} + Min. IP Hdr {2} + (Neighbour Solicitation {24} + Min. IP Hdr 893 {2})*N + (Neighbour Advertisement {24} + Min. IP Hdr {2})*N + Address 894 Registration Options in first NS {24} + Address Registration Options 895 in first NA {16}. 897 Figure 8 shows the values of RS and NA for each 6LoWPAN 898 implementation, and the resulting total ND cost. Notably, use of an 899 arbitrary bitfield increases the size of the capability option by 4 900 bytes, making use of existing ND options like the 6CIO option 901 impossible. In both cases the additional bytes added for capability 902 discovery are small compared to the total cost of ND( <= 8% linear 903 spectrum / <= 16% arbitrary bitfield). 905 *ICMP Cost* In networks that do not use IPv6 ND the cost of 906 capability discovery is the energy/latency required for one ICMP 907 packet per failure between any two nodes. For P6LoWPAN capability 908 based failures can only happen in one direction, so the size of this 909 link-layer payload is: 911 C_icmp = Compressed IP Header Size + 4 913 For FLEX-6LoWPAN C_icmp = 48, because the recipient does not know the 914 capabilities of the sender, and thus must send an uncompressed packet 915 to ensure successful reception of its own capabilities. This example 916 reveals why use of an arbitrary bitfield is so undesirable - the 917 ability to compress headers in ICMP errors can reduce overhead by a 918 factor of 4 or more (in the common case of 8 byte compressed 919 headers). 921 -- Linear Spectrum Arbitrary Bitfield 922 ------------------- --------------------- ------------------------ 923 6LoWPAN Code Size 5.9 kB 6.5 kB 924 RAM per neighbor 19 Bytes 22 Bytes 925 ------------------- --------------------- ------------------------ 927 Figure 7: Resource requirements for a 6LoWPAN stack in Contiki-NG 928 using a linear capability spectrum vs. using an arbitrary capability 929 bitfield. 931 -- RS NA C (Total ND Cost) 932 -------------- --------------- --------------- --------------------- 933 6LoWPAN 20 24 168 + 52\*N 934 P6LoWPAN 24 28 172+56\*N 935 FLEX-6LoWPAN 28 32 176+60\*N 936 -------------- --------------- --------------- --------------------- 938 Figure 8: Total ND cost for each implementation 940 8. Discussion and Conclusions 942 A new generation of low-power devices face a connectivity dilemma: 943 Internet protocols are not designed for energy efficiency, but 944 compression and other energy saving adaptations takes up precious 945 code space. Device deployments specialized for single-vendor local 946 networks make trade-offs specific to their application requirements. 947 As a result, IP communication between IP enabled devices fails. This 948 problem is not specific to 6LoWPAN -- Iova et. al. recently noted 949 similar issues in the RPL protocol: "RPL has too large of a footprint 950 for resource-constrained devices, and requires all devices in a 951 network to run the same mode of operation, limiting heterogeneity" 952 [iova]. 954 Part of the challenge is that some traditional protocol design 955 principles do not apply well to the low-power setting. We present 956 three design principles for low-power protocols that attempt to 957 remedy this. These principles explicitly acknowledge the unique code 958 space/energy tradeoffs of low-power devices. 960 Looking forward, considering this tension is critical for protocol 961 designers in this ecosystem of diverse hardware capabilities and 962 application tradeoffs. 6LoWPAN is not the only low power Internet 963 protocol -- the low power space uses its own routing protocols, 964 address discovery protocols, and application layer protocols 965 [RFC6550] [RFC7252]. Additional protocols will follow as the space 966 matures. Many of these protocols will be initially developed outside 967 the IETF -- Jonathan Hui was a graduate student when he presented the 968 first complete IPv6-based network architecture for sensor nets [hui], 969 as was Adam Dunkels when he created Contiki. We present a roadmap 970 for how these principles can reframe the discussion of how to connect 971 the next hundred billion devices to the Internet. 973 9. Definitions 975 9.1. Terminology 977 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 978 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 979 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 980 [RFC2119]. 982 10. Security Considerations 984 This informational document does have some implications for security 985 if followed. 987 First, capability advertisements of the type recommended in this 988 document are liable to leak some information regarding the type of 989 device sending those advertisements. In any situation for which this 990 information is privileged, such advertisements must be suppressed. 992 Second, implementations should be careful not to take for granted 993 that the suggestions in this document will be implemented by all 994 other transmitting devices. Accordingly, though this document 995 recommends reasonable bounds, receivers still must be careful to 996 prevent buffer overflows in the event these bounds are not followed. 998 11. IANA Considerations 1000 This document has no actions for IANA. 1002 12. References 1004 12.1. Normative References 1006 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1007 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1008 DOI 10.17487/RFC4861, September 2007, 1009 . 1011 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1012 "Transmission of IPv6 Packets over IEEE 802.15.4 1013 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1014 . 1016 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1017 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1018 DOI 10.17487/RFC6282, September 2011, 1019 . 1021 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1022 Bormann, "Neighbor Discovery Optimization for IPv6 over 1023 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1024 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1025 . 1027 12.2. Informative References 1029 [contiki] Dunkels, A., "Contiki OS", n.d., 1030 . 1032 [contiki-ng] 1033 Duquennoy, S., "Contiki-NG", n.d., 1034 . 1036 [end-to-end] 1037 Clark, D., "End-to-end Arguments in System Design", n.d.. 1039 [hui] Culler, D., "IP is Dead, Long Live IP for Wireless Sensor 1040 Networks", n.d.. 1042 [iova] Kiraly, C., "RPL The Routing Standard for the Internet of 1043 Things...Or Is It?", n.d.. 1045 [lite-os] Huawei, ., "LiteOS", n.d., . 1047 [mbedos] ARM, ., "ARM MbedOS", n.d., . 1049 [probe-it-plugtest] 1050 Huang, X., "Tehcnical Interoperability 6LoWPAN-CoAP Report 1051 from Interop Event", n.d.. 1053 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1054 DOI 10.17487/RFC0791, September 1981, 1055 . 1057 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1058 RFC 793, DOI 10.17487/RFC0793, September 1981, 1059 . 1061 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1062 Communication Layers", STD 3, RFC 1122, 1063 DOI 10.17487/RFC1122, October 1989, 1064 . 1066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1067 Requirement Levels", BCP 14, RFC 2119, 1068 DOI 10.17487/RFC2119, March 1997, 1069 . 1071 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1072 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1073 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1074 Low-Power and Lossy Networks", RFC 6550, 1075 DOI 10.17487/RFC6550, March 2012, 1076 . 1078 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1079 Application Protocol (CoAP)", RFC 7252, 1080 DOI 10.17487/RFC7252, June 2014, 1081 . 1083 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1084 IPv6 over Low-Power Wireless Personal Area Networks 1085 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1086 2014, . 1088 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1089 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1090 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1091 . 1093 [riot] Berlin, F., "riot OS", n.d., . 1095 [RPL-interop] 1096 Ko, J., "Contikierpl and tinyrpl - Happy Together", n.d.. 1098 [tinyos] Levis, P., "TinyOS An Operating System for Sensor 1099 Networks", n.d., . 1102 [tock] Levy, A., "Multiprogramming a 64kB Computer Safely and 1103 Efficiently", n.d.. 1105 [zephyr] Foundation, T., "zephyrOS", n.d., 1106 . 1108 Authors' Addresses 1110 Hudson Ayers 1111 Stanford University 1112 350 Serra Mall 1113 Stanford, CA 1114 United States 1116 Email: hayers@stanford.edu 1118 Philip Levis 1119 Stanford University 1120 350 Serra Mall 1121 Stanford, CA 1122 United States 1124 Email: pal@cs.stanford.edu