idnits 2.17.1 draft-clausen-lln-rpl-experiences-00.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 (January 30, 2012) is 4470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft A. Colin de Verdiere 4 Intended status: Informational J. Yi 5 Expires: August 2, 2012 LIX, Ecole Polytechnique 6 U. Herberg 7 Fujitsu Laboratories of America 8 January 30, 2012 10 Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy 11 Networks 12 draft-clausen-lln-rpl-experiences-00 14 Abstract 16 With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - 17 having been published as a Proposed Standard after a ~2-year 18 development cycle, this document presents an evaluation of the 19 resulting protocol of its applicability and of its limits. The 20 documents presents a selection of observations of the protocol 21 characteristics, exposes experiences acquired when producing various 22 prototype implementations of RPL, and presents results obtained from 23 testing this protocol - by way of network simulations, in network 24 testbeds and in deployments. The document aims at providing a better 25 understanding of possible weaknesses and limits of RPL, notably the 26 possible directions that further protocol developments should 27 explore, in order to address these. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 2, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. RPL Message Emission Timing - Trickle Timers . . . . . . . 6 67 4. Requirement Of DODAG Root . . . . . . . . . . . . . . . . . . 6 68 4.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. RPL Data Traffic Flows . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Fragmentation Of RPL Control Messages And Data Packet . . . . 9 72 6.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. The DAO Mechanism: Downward and Point-to-Point Routes . . . . 10 74 7.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Address Aggregation and Summarization . . . . . . . . . . . . 12 76 8.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 13 77 9. Links Assumed Bi-Directional . . . . . . . . . . . . . . . . . 14 78 9.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 14 79 10. Neighbor Unreachability Detection For Unidirectional Links . . 14 80 10.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 15 81 11. RPL Implementability and Complexity . . . . . . . . . . . . . 16 82 11.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 16 83 12. Underspecification . . . . . . . . . . . . . . . . . . . . . . 17 84 12.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 17 85 13. Protocol Convergence . . . . . . . . . . . . . . . . . . . . . 18 86 13.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 19 87 14. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 14.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 19 89 15. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 92 18. Informative References . . . . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 RPL - the "Routing Protocol for Low Power and Lossy Networks" 98 [I-D.ietf-roll-rpl] - is a proposal for an IPv6 routing protocol for 99 Low-power Lossy Networks (LLNs), by the ROLL Working Group in the 100 Internet Engineering Task Force (IETF). This routing protocol is 101 intended to be the IPv6 routing protocol for LLNs and sensor 102 networks, applicable in all kinds of deployments and applications of 103 LLNs. 105 The objective of RPL and ROLL is to target networks which "comprise 106 up to thousands of nodes" [roll-charter], where the majority of the 107 nodes have very constrained resources, where the network to a large 108 degree is "managed" by a (single or few) central "supernodes" 109 [I-D.ietf-roll-rpl-terminology], and where handling mobility is not 110 an explicit design criteria ([RFC5867], [RFC5826], [RFC5673], 111 [RFC5548]). Supported traffic patterns include multipoint-to-point, 112 point-to-multipoint and point-to-point traffic. The emphasis among 113 these traffic patterns is to optimize for multipoint-to-point 114 traffic, to reasonably support point-to-multipoint traffic and to 115 provide basic features for point-to-point traffic, in that order. 117 As of early 2011, RPL has been approved by the IESG, for publication 118 as a "Proposed Standard" RFC (Request for Comments). The implication 119 of a protocol being labeled "Proposed Standard" is that it is 120 considered generally stable: well-understood and community reviewed, 121 no known design issues pending, and with some community support 122 [RFC2026]. 124 "Proposed Standard" is, however, only the first step on the Standards 125 Track, and it is thus opportune to consider the protocol in order to 126 understand which aspects of it necessitate further investigations, 127 and in order to identify possibly weak points which may restrict the 128 deployment scope of the protocol. This document has as objective to 129 provide observations of RPL, in the spirit of better understanding 130 its characteristics and limits. 132 2. Terminology 134 This document uses the terminology and notation defined in 135 [I-D.ietf-roll-rpl]. 137 Additionally, it uses the following terminology: 139 RPL Router - A device, running the RPL protocol, as specified by 140 [I-D.ietf-roll-rpl]. 142 3. RPL Overview 144 The basic construct in RPL is a "Destination Oriented Directed 145 Acyclic Graph" (DODAG), depicted in Figure 1. In a converged LLN, 146 each RPL Router has identified a stable set of parents, each of which 147 is a potential next-hop on a path towards the "root" of the DODAG, as 148 well as a preferred parent. Each RPL Router, which is part of a 149 DODAG (i.e. has selected parents) will emit DODAG Information Object 150 (DIO) messages, using link-local multicast, indicating its respective 151 rank in the DODAG (i.e. distance to the DODAG Root according to some 152 metric(s), in the simplest form hop-count). Upon having received a 153 (number of such) DIO messages, an RPL Router will calculate its own 154 rank such that it is greater than the rank of each of its parents, 155 select a preferred parent and then itself start emitting DIO 156 messages. 158 (s) 159 ^ ^ ^ 160 / | \ 161 (a) | (b) 162 ^ (c) ^ 163 / ^ (d) 164 (f) | ^ ^ 165 (e)--/ \ 166 (g) 168 Figure 1: RPL DODAG 170 The DODAG formation thus starts at the DODAG Root (initially, the 171 only RPL Router which is part of a DODAG), and spreads gradually to 172 cover the whole LLN as DIOs are received, parents and preferred 173 parents are selected and further RPL Routers participate in the 174 DODAG. The DODAG Root also includes, in DIO messages, a DODAG 175 Configuration Object, describing common configuration attributes for 176 all RPL Routers in that network - including their mode of operation, 177 timer characteristics etc. RPL Routers in a DODAG include a verbatim 178 copy of the last received DODAG Configuration Object in their DIO 179 messages, permitting also such configuration parameters propagating 180 through the network. 182 As a Distance Vector protocol, RPL restricts the ability for an RPL 183 Router to change rank. An RPL Router can freely assume a smaller 184 rank than previously advertised (i.e. logically move closer to the 185 DODAG Root) if it discovers a parent advertising a lower rank, and 186 must then disregard all previous parents of ranks higher than the 187 router's new rank. The ability for an RPL Router to assume a greater 188 rank (i.e. logically move farther from the DODAG Root) than 189 previously advertised is restricted in order to avoid count-to- 190 infinity problems. The DODAG Root can trigger "global recalculation" 191 of the DODAG by increasing a sequence number, DODAG version, in DIO 192 messages. 194 The DODAG so constructed is used for installing routes: the 195 "preferred parent" of an RPL Router can serve as a default route 196 towards the DODAG Root, or the DODAG Root can embed in its DIO 197 messages the destination prefixes, included by DIOs generated by RPL 198 Routers through the LLN, to which connectivity is provided by the 199 DODAG Root. Thus, RPL by way of DIO generation provides "upward 200 routes" or "multipoint-to-point routes" from the sensors inside the 201 LLN and towards the DODAG Root. 203 "Downward routes" are enabled by having sensors issue Destination 204 Advertisement Object (DAO) messages, propagating as unicast via 205 parents towards the DODAG Root. These describe which prefixes belong 206 to, and can be reached via, which RPL Router. In a network, all RPL 207 Routers must operate in either of storing-mode or non-storing-mode, 208 specified by way of a "Mode of Operation" (MOP) flag in the DODAG 209 Configuration Object from the DODAG Root. Depending on the MOP, DAO 210 messages are forwarded differently towards the DODAG Root: 212 o In "non-storing-mode", an RPL Router originates DAO messages, 213 advertising one or more of its parents, and unicast it to the 214 DODAG Root. Once the DODAG Root has received DAOs from an RPL 215 Router, and from all RPL Routers on the path between it and the 216 DODAG Root, it can use source routing for reaching advertised 217 destinations inside the LLN. 219 o In "storing-mode", each RPL Router on the path between the 220 originator of a DAO and the DODAG Root records a route to the 221 prefixes advertised in the DAO, as well as the next-hop towards 222 these (the RPL Router, from which the DAO was received), then 223 forwards the DAO to its preferred parent. 225 "Point-to-point routes", for communication between devices inside the 226 LLN and where neither of the communicating devices are the DODAG 227 Root, are as default supported by having the source sensor transmit 228 via its default route to the DODAG Root (i.e., using the upward 229 routes) which will then, depending on the "Mode of Operation" for the 230 DODAG, either add a source-route to the received data for reaching 231 the destination sensor (downward routes in non-storing-mode) or 232 simply use hop-by-hop routing (downward routes in storing-mode). In 233 the case of storing-mode, if the source and the destination for a 234 point-to-point communication share a common ancestor other than the 235 DODAG Root, a downward route may be available in an RPL Router (and, 236 thus, used) before the data packet reaching the DODAG Root. 238 3.1. RPL Message Emission Timing - Trickle Timers 240 RPL message generation is timer-based, with the DODAG Root being able 241 to configure back-off of message emission intervals using Trickle 242 [RFC6206]. Trickle, as used in RPL, stipulates that an RPL Router 243 transmits a DIO "every so often" - except if receiving a number of 244 DIOs from neighbor RPL routers, enabling the RPL Router to determine 245 if its DIO transmission is redundant. 247 When an RPL Router transmits a DIO, there are two possible outcomes: 248 either every neighbor RPL Router that hears the message finds that 249 the information contained is consistent with its own state (i.e., the 250 received DODAG version number corresponds with that which the RPL 251 Router has recorded and no better rank is advertised than that which 252 is recorded in the parent set) - or, a recipient RPL Router detects 253 that either the sender of the DIO or itself has out-of-date 254 information. If the sender has out-of-date information, then the 255 recipient RPL Router schedules transmission of a DIO to update this 256 information. If the recipient RPL Router has out-of-date 257 information, then it updates based on the information received in the 258 DIO. 260 With Trickle, an RPL Router will schedule emission of a DIO at some 261 time, t, in the future. When receiving a DIO containing information 262 consistent with its own information, the RPL Router will record that 263 "redundant information has been received" by incrementing a 264 redundancy counter, c. At the time t, if c is below some "redundancy 265 threshold", then it transmits its DIO. Otherwise, transmission of a 266 DIO at this time is suppressed, c is reset and a new t is selected to 267 twice as long time in the future - bounded by a pre-configured 268 maximum value for t. If, on the other hand, the RPL Router has 269 received an out-of-date DIO from one of its neighbors, t is reset to 270 a pre-configured minimum value and c is set to zero. In both cases, 271 at the expiration of t, the RPL Router will verify if c is below the 272 "redundancy threshold" and if so transmit - otherwise, increase t and 273 stay quiet. 275 4. Requirement Of DODAG Root 277 As indicated in Section 3, the DODAG Root has both a special 278 responsibility and is subject to special requirements. The DODAG 279 Root is responsible for determining and maintaining the configuration 280 parameters for the DODAG, and for initiating DIO emissions. 282 The DODAG Root is also responsible (in both storing and non-storing 283 mode) for being able to, when downward routes are supported, maintain 284 sufficient topological information to be able to construct routes to 285 all destinations in the network. This entails that the DODAG Root is 286 required to have sufficient memory and sufficient computational 287 resources to be able to record a network graph containing all paths 288 from itself and to all destinations and calculate paths - this, 289 regardless of if the network is operating in storing or non-storing 290 mode. 292 The DODAG Root is also required to have sufficient energy available 293 so as to be able to ensure the relay functions required (this, 294 especially for non-storing mode, where all traffic transits through 295 the DODAG Root). 297 4.1. Observations 299 In a given deployment, select RPL Routers can be provisioned with the 300 required energy, memory and computational resources so as to serve as 301 DODAG Roots, and be administratively configured as such - with the 302 remainder of the RPL routers in the network being of typically lesser 303 capacity. [rpl-eval-UCB] indicates that, in storing mode, a device 304 with 10KB of memory scales up to about 30 RPL Routers - in a larger 305 network (in storing or non-storing mode, both) the DODAG Root would 306 require at least that much, most likely much more, memory. In non- 307 storing mode, only the DODAG Root will require that much, or likely 308 much more, memory with the other RPL Routers being able to make do 309 with considerably less. 311 RPL Routers provisioned with resources to act as DODAG Roots, and 312 administratively configured to act as such, represent a single point 313 of failure in the network. As the memory requirements for DODAG Root 314 and other RPL Routers are substantially different, unless all RPL 315 Routers are provisioned with resources (memory, energy, ...) to act 316 as DODAG Roots, effectively if the designated DODAG Root fails, the 317 network fails and RPL is unable to operate. Even if electing another 318 RPL Router as temporary DODAG root (e.g., for forming a "Floating" 319 DODAG) for providing internal connectivity between RPL Routers, this 320 router may not - likely, will not - have the necessary resources to 321 satisfy the role as DODAG Root. 323 Thus, although in principle RPL provides, by way of "Floating 324 DODAGs", protocol mechanisms for establishing a DODAG for providing 325 internal connectivity even in case of failure of the administratively 326 provisioned DODAG Root - especially in non-storing mode - it is 327 unlikely that any RPL Routers not explicitly provisioned as DODAG 328 Roots will have sufficient resources to undertake this task. 330 Another possible LLN scenario is that only internal point-to-point 331 connectivity is sought, and no RPL Router has a more "central" role 332 than any other - a self-organizing LLN. Requiring special 333 provisioning of a specific "super-node" as DODAG Root is both 334 unnecessary and undesirable. 336 5. RPL Data Traffic Flows 338 RPL makes a-priori assumptions of data traffic patterns: sensor-to- 339 root data traffic (multipoint-to-point) is predominant, root-to- 340 sensor data traffic (point-to-multipoint) is rare and sensor-to- 341 sensor (point-to-point) data traffic is extremely rare. While not 342 specifically called out thus in [I-D.ietf-roll-rpl], the resulting 343 protocol design reflects these assumptions in that the mechanism 344 constructing multipoint-to-point paths is efficient in terms of 345 control traffic generated and state required, point-to-multipoint 346 path construction much less so - and point-to-point paths subject to 347 potentially significant route stretch (routes going through the DODAG 348 Root in non-storing mode) and over-the-wire overhead from using 349 source routing (from the DODAG Root to the destination) (cf 350 Section 7) - or, in case of storing mode, considerable memory 351 requirements in all LLN routers inside the network (cf Section 7). 353 An RPL Router selects from among its parents a "preferred parent", to 354 serve as a default route towards the DODAG Root (and to prefixes 355 advertised by the DODAG Root). Thus, RPL provides "upward routes" or 356 "multipoint-to-point routes" from the RPL Routers below the DODAG 357 Root and towards the DODAG Root. 359 An RPL Router which wishes to act as a destination for data traffic 360 ("downward routes" or "point-to-multipoint") issues DAOs upwards in 361 the DODAG towards the DODAG Root, describing which prefixes belong 362 to, and can be reached via, that RPL Router. 364 Point-to-Point routes between RPL Routers below the DODAG Root are 365 supported by having the source RPL Router transmit, via its default 366 route, data traffic towards the DODAG Root. In non-storing mode, the 367 data traffic will reach the DODAG Root, which will reflect the data 368 traffic downward towards the destination RPL Router, adding a strict 369 source routing header indicating the precise path for the data 370 traffic to reach the intended destination RPL Router. In storing 371 mode, the source and the destination may possibly (although, may also 372 not) have a common ancestor other than the DODAG Root, which may 373 provide a downward route to the destination before data traffic 374 reaching the DODAG Root. 376 5.1. Observations 378 The data traffic characteristics assumed by RPL do not represent a 379 universal distribution of traffic patterns in LLNs: 381 o There are scenarios where sensor-to-sensor traffic is a more 382 common occurrence, documented e.g. in [RFC5867]. 384 o There are scenarios, where all traffic is bi-directional, e.g. in 385 case sensor devices in the LLN are, in majority, "actively read": 386 a request is issued by the root to a specific sensor, and the 387 sensor value is expected returned. 389 For the former, all sensor-to-sensor paths include the root, possibly 390 causing congestion on the communications medium near the root, and 391 draining energy from the intermediate RPL Routers on an unnecessarily 392 long path. If sensor-to-sensor traffic is common, RPL Routers near 393 the root will be particularly solicited as relays, especially in non- 394 storing mode. For the latter, all RPL Routers are required to 395 generate DAOs, which generates a considerable control traffic 396 overhead [bidir]. 398 6. Fragmentation Of RPL Control Messages And Data Packet 400 Fragmentation of IP packets appears when the size of the IP datagram 401 is larger than the Maximum Transmission Unit (MTU) supported by the 402 link layer. When an IP packet is fragmented, all fragments of that 403 IP packet must be successfully received by a router, in order that 404 the IP packet is successfully received - otherwise, the whole IP 405 packet is lost. Moreover, the additional link-layer frame overhead 406 for each of the fragments increases the capacity required from the 407 medium, and may consume more energy for transmitting a higher number 408 of frames on the network interface. 410 RPL is an IPv6 routing protocol, designed to operate on constrained 411 link layers, such as IEEE 802.15.4 [ieee802154], with a maximum MTU 412 of 127 bytes - a deviation from the otherwise specified minimum MTU 413 of 1280 bytes for IPv6 [RFC2460]. Reducing the need of fragmentation 414 of packets on such a link layer, compression adaptation layers exist 415 [RFC4944], [RFC6282], reducing the overhead of the IPv6 header from 416 at least 40 octets to a minimum of 2 octets. With a physical layer 417 packet size of 127 octets, a maximum frame overhead of 25 octets and 418 21 octets for link layer security [RFC4944], 81 octets remain for L2 419 payload. Further subtracting 2 octets for the compressed IPv6 header 420 leaves 79 octets for L3 data payload. 422 The second L in LLN indicating Lossy [roll-charter], higher loss 423 rates than typically seen in IP networks are expected, rendering 424 fragmentation important to avoid. 426 DIO messages consist of a mandatory base object, facilitating DODAG 427 formation, and additional options for e.g. autoconfiguration and 428 network management. The base object contains two unused octets, 429 reserved for future use, resulting in two bytes of unnecessary zeros, 430 sent with each DIO message. The Prefix Information option, used for 431 automatic configuration of address, carries even four unused octets 432 in order to be compatible with IPv6 neighbor discovery. 434 6.1. Observations 436 While 79 octets may seem to be sufficient to carry RPL control 437 messages, consider the following: RPL control messages are carried in 438 ICMPv6, and the mandatory ICMPv6 header consumes 4 octets. The DIO 439 base another 24 octets. If link metrics are used, that consumes at 440 least another 8 octets - and this is using a hop count metric; other 441 metrics may require more. The DODAG Configuration Object consumes up 442 to a further 16 octets, for a total of 52 octets. Adding a Prefix 443 Information Object for address configuration consumes another 32 444 octets, for a total of 84 octets - thus exceeding the 79 octets 445 available for L3 data payload and causing fragmentation of such a 446 DIO. As a point of reference, the ContikiRPL [rpl-contiki] 447 implementation includes both the DODAG Configuration option and the 448 Prefix Information option in all DIO messages. Any other options, 449 e.g. Route Information options indicating prefixes reachable through 450 the DODAG Root, increase the overhead and thus the probability of 451 fragmentation. 453 RPL may further increase the probability of fragmentation of also 454 data traffic: for non-storing-mode, RPL employs source-routing for 455 all downward traffic. [I-D.ietf-6man-header] specifies the RPL 456 Source Routing header, which imposes a fixed overhead of 8 octets per 457 IP packet leaving 71 octets remaining from the MTU - from which must 458 be deducted a variable number of octets, depending on the length of 459 the route. With fewer octets available for data payload, RPL thus 460 increases the probability for fragmentation of also data packets. 461 This, in particular, for longer paths, e.g. in point-to-point data 462 traffic between sensors inside the LLN, where data traffic transit 463 through the DODAG Root and are then source-routed to the destination. 465 7. The DAO Mechanism: Downward and Point-to-Point Routes 467 RPL specifies two distinct and incompatible "modes of operation" for 468 downward traffic: storing mode, where each RPL Router is assumed to 469 maintain routes to all destinations in its sub-DODAG, i.e. RPL 470 Routers that are "deeper down" in the DODAG, and non-storing mode, 471 where only the DODAG Root stores routes to destinations inside the 472 LLN, and where the DODAG Root employs strict source routing in order 473 to route data traffic to the destination RPL Router. 475 7.1. Observations 477 In addition to possible fragmentation, as occurs when using 478 potentially long source routing headers over a medium with a small 479 MTU - similar to what is discussed in Section 6 - the maximum length 480 of the source routing header [I-D.ietf-6man-header] is limited to 136 481 octets, including an 8 octet long header. As each IPv6 address has a 482 length of 16 octets, not more than 8 hops from the source to the 483 destination are possible for "raw IPv6". Using address compression 484 (e.g. as specified in [RFC4944]), the maximum path length may not 485 exceed 64 hops. This excludes deployment of RPL for scenarios with 486 long "chain-like" topologies, such as traffic lights along a street. 488 In storing mode, each RPL Router has to store routes for destinations 489 in its sub-DODAG. This implies that, for RPL Routers near the DODAG 490 Root, the required storage is only bounded by the number of paths to 491 all other destinations in the network. As RPL targets constrained 492 devices with little memory, but also has as ambition to be operating 493 networks consisting of thousands of routers [roll-charter], the 494 storing capacity on these RPL Routers may not be sufficient - or, at 495 least, the storage requirements in RPL Routers "near the DODAG Root" 496 and "far from the DODAG Root" is not homogenous, thus some sort of 497 administrative deployment, and continued administrative maintenance 498 as the network evolves, of devices is needed. Indeed, [rpl-eval-UCB] 499 argues that practical experiences suggest that RPL in storing mode, 500 with RPL routers having 10kB of RAM, should be limited to networks of 501 less than ~30 RPL Routers. Aggregation / summarization of addresses 502 may be advanced as a possible argument that this issue is of little 503 significance - Section 8 discusses why such an argument does not 504 apply. 506 In short, the mechanisms in RPL, when using storing mode, force the 507 choice between requiring all RPL Routers to have sufficient memory to 508 store route entries for all destinations (storing-mode) - or, suffer 509 increased risk of fragmentation, and thus loss of data packets, while 510 consuming network capacity by way of source routing through the DODAG 511 Root. 513 In RPL, the "mode of operation" stipulates that either downward 514 routes are not supported (MOP=0), or that they are supported by way 515 of either storing or non-storing mode. In case downward routes are 516 supported, RPL does not provide any mechanism for discriminating 517 between which routes should or should not be maintained. In 518 particular, in order to calculate paths to a given destination, all 519 intermediaries between the DODAG Root and that destination must 520 themselves be reachable - effectively rendering downward routes in 521 RPL an "all-or-none" situation. In case a destination is 522 unreachable, all the DODAG Root may do is require all destinations to 523 re-issue their DAOs, by way of issuing a DIO with an increased DODAG 524 version number, possibly provoking a broadcast-storm-like situation. 525 This, in particular, as [I-D.ietf-roll-rpl] does not specify DAO 526 message transmission constraints, nor any mechanism for adapting DAO 527 emission to the network capacity. 529 A final point on the DAO mechanism: RPL supports point-to-point 530 traffic only by way of relaying through the DODAG. In networks where 531 point-to-point traffic is no rare occasion, this causes unduly long 532 paths (with possibly increased energy consumption, increased 533 probability of packet losses) as well as possibly congestion around 534 the DODAG Root. 536 8. Address Aggregation and Summarization 538 As indicated in Section 7, in storing mode, an RPL Router is expected 539 to be able to store routing entries for all destinations in its "sub- 540 DODAG", i.e., routing entries for all destinations in the network 541 where the path to the DODAG Root includes that RPL Router. 543 In the Internet, no single router stores explicit routing entries for 544 all destinations. Rather, IP addresses are assigned hierarchically, 545 such that an IP address does not only uniquely identify a network 546 interface, but also its topological location in the network, as 547 illustrated in Figure 2. All addresses with the same prefix are 548 reachable by way of the same router - which can, therefore, advertise 549 only that prefix. Other routers need only record a single routing 550 entry for that prefix, knowing that as the IP packet reaches the 551 router advertising that prefix, more precise routing information is 552 available. 554 .---. 555 | | 556 '---' 557 | 558 | 559 (a) 560 | 561 |1.x.x.x/8 562 | 563 (b) 564 / \ 565 1.1.x.x/16/ \ 1.2.x.x/16 566 / \ 567 .---. .---. 568 | c | | d | 569 '---' '---' 571 Figure 2: Address Hierarchies 573 8.1. Observations 575 In RPL, each RPL Router acquires a number of parents, as described in 576 Section 3, from among which it selects one as its preferred parent 577 and, thus, next-hop on the path to the DODAG Root. RPL Routers 578 maintain a parent set containing possibly more than a single parent 579 so as to be able to rapidly select an alternative preferred parent, 580 should the previously selected such become unavailable. Thus 581 expected behavior is for an RPL Router to be able to change its point 582 of attachment towards the DODAG Root. If IP addresses are assigned 583 in a strictly hierarchical fashion, and if scalability of the routing 584 state maintained in storing mode is based on this hierarchy, then 585 this entails that each time an RPL Router changes its preferred 586 parent, it must also change its own IP address - as well as cause RPL 587 routers in its "sub-DODAG" to do the same. RPL does not specify 588 signaling for reconfiguring addresses in a sub-DODAG. 590 A slightly less strict hierarchy can be envisioned, where an RPL 591 Router can change its preferred parent without necessarily changing 592 addresses of itself and of its sub-DODAG, provided that its former 593 and new preferred parents both have the same preferred parent, and 594 have addresses hierarchically assigned from that - from the 595 "preferred grandparent". With reference to Figure 1, this could be e 596 changing its preferred parent from d to c, provided that both d and c 597 have b as preferred parent. Doing so would impose a restriction on 598 the parent-set selection, admitting only parents which have 599 themselves the same parent - thus, no longer having a DODAG but a 600 simple tree, losing redundancy in the network connectivity. RPL does 601 not specify rules for admitting only parents with identical grand- 602 parents into the parent set - although such is not prohibited either, 603 if the loss of redundancy from constructing a tree is acceptable. 605 The DODAG Root incrementing the DODAG version number is the mechanism 606 by which RPL enables global reconfiguration of the network, 607 reconstructing the DODAG with (intended) more optimal paths. In case 608 of addressing hierarchies being enforced, so as to enable 609 aggregation, this will either restrict the ability for an optimal 610 DODAG construction, or will trigger global address autoconfiguration 611 so as to ensure addressing hierarchies. 613 Finally, with IP addresses serving a dual role of an identifier of 614 both an end-point for communication and a topological location in the 615 network, changing the IP address of a device, so as to reflect a 616 change in network topology, also entails interrupting ongoing 617 communication to or through that device. Additional mechanisms (e.g. 618 a DNS-like system) mapping "communications identifiers" and "IP 619 addresses" are required. 621 9. Links Assumed Bi-Directional 623 Parents (and the preferred parent) are selected based on receipt of 624 DIOs, without verification of the ability for an RPL Router to 625 successfully communicate with the parent - i.e. without any 626 bidirectionality check of links. However, the basic use of links is 627 for "upward" routes, i.e. for the RPL Router to use a parent (the 628 preferred parent) as relay towards the DODAG Root - in the opposite 629 direction of the one in which the DIO was received. 631 9.1. Observations 633 Unidirectional links are no rare occurrence, such as is known from 634 wireless multi-hop networks. If an RPL Router receives a DIO on such 635 a unidirectional link, and selects the originator of the DIO as 636 parent, that would be a bad choice: unicast traffic in the upward 637 direction would be lost. If the RPL Router had verified the 638 bidirectionality of links, it might have selected a better parent, to 639 which it has a bidirectional link. 641 10. Neighbor Unreachability Detection For Unidirectional Links 643 [I-D.ietf-roll-rpl] suggests using Neighbor Unreachability Detection 644 (NUD) [RFC4861] to detect and recover from the situation of 645 unidirectional links between an RPL Router and its (preferred) 646 parent(s). When, e.g., an RPL Router a tries (and fails) to actually 647 use RPL Router b for forwarding traffic, NUD is supposed engaged to 648 detect and prompt corrective action, e.g. by way of selecting an 649 alternative preferred parent. 651 NUD is based upon observing if a data packet is making forward 652 progress towards the destination, either by way of indicators from 653 upper-layer protocols (such as TCP and, though not called out in 654 [RFC4861], also from lower-layer protocols such as Link Layer ACKs ) 655 or - failing that - by unicast probing by way of transmitting a 656 unicast Neighbor Solicitation message and expecting that a solicited 657 Neighbor Advertisement message be returned. 659 10.1. Observations 661 An RPL Router may receive, transiently, a DIO from an RPL Router, 662 closer (in terms of rank) to the DODAG Root than any other RPL Router 663 from which a DIO has been received. Some, especially wireless, link 664 layers may exhibit different transmission characteristics between 665 multicast and unicast transmissions (such is the case for some 666 implementations of IEEE 802.11b, where multicast/broadcast 667 transmissions are sent at much lower bit-rates than are unicast. 668 IEEE 802.11b is, of course, not suggested as a viable interface for 669 LLNs, but serves to illustrate that such asymmetric designs exist), 670 leading to a (multicast) DIO being received from farther away than a 671 unicast transmission can reach. DIOs are sent (downward) using link- 672 local multicast, whereas the traffic flowing in the opposite 673 direction (upward) is unicast. Thus, a received (multicast) DIO may 674 not be indicative of useful unicast connectivity - yet, RPL might 675 cause this RPL Router to select this attractive RPL Router as its 676 preferred parent. This may happen both at initialization or at any 677 time during the LLN lifetime, as RPL allows attachment to a "better 678 parent" at any time. 680 A DODAG so constructed may appear stable and converged until such 681 time that unicast traffic is to be sent and, thus, NUD invoked. 682 Detecting only at that point that unicast connectivity is not 683 maintained, and causing local (and possibly global) repairs exactly 684 at that time, may lead to traffic not being deliverable. As 685 indicated in Section 8, if scalability is dependent on addresses 686 being assigned hierarchically, changing point-of-attachment may 687 entail more than switching preferred parent. 689 Also, absent all RPL Routers consistently advertising their 690 reachability through DAO messages, a protocol requiring bidirectional 691 flows between the communicating devices, such as TCP, will be unable 692 to operate. 694 Finally, upon having been notified by NUD that the "next hop" is 695 unreachable, an RPL Router must discard the preferred parent and 696 select another - hoping that this time, the preferred parent is 697 actually reachable. Also, if NUD indicates "no forward progress" 698 based on an upper-layer protocol, there is no guarantee that the 699 problem stems exclusively from the preferred parent being 700 unreachable. Indeed, it may be a problem farther ahead, possibly 701 outside the LLN, thus changing preferred parent will not alleviate 702 the situation. 704 Incidentally, this stems from a fundamental difference between "fixed 705 links in the Internet" and "wireless links": whereas the former, as a 706 rule, are reliable, predictable and with losses being rare 707 exceptions, the latter are characterized by frequent losses and 708 general unpredictability. 710 11. RPL Implementability and Complexity 712 RPL is designed to operate on "RPL Routers [...] with constraints on 713 processing power, memory, and energy (battery power)" 714 [I-D.ietf-roll-rpl]. However, the 163 pages long specification of 715 RPL, plus additional specifications for routing headers 716 [I-D.ietf-6man-header], Trickle timer [RFC6206], routing metrics 717 [I-D.ietf-roll-routing-metrics] and objective function 718 [I-D.ietf-roll-rpl-of0], describes complex mechanisms (e.g. the 719 upwards and downward data traffic, a security solution, manageability 720 of RPL Routers, auxiliary functions for autoconfiguration of RPL 721 Routers, etc.), and provides no less than 9 message types, and 10 722 different message options. 724 To give one example, the ContikiRPL implementation 725 (http://www.sics.se/contiki), which provides only storing-mode and no 726 security features, consumes about 50 KByte of memory. Sensor 727 hardware, such as MSP430 sensor platforms, does not contain much more 728 memory than that, i.e. there may not be much space left to deploy any 729 application on the RPL Router. 731 11.1. Observations 733 Since RPL is intended as the routing protocol for LLNs, which covers 734 all the diverse applications requirements listed in [RFC5867], 735 [RFC5673], [RFC5826], [RFC5548], it is possible that (i) due to 736 limited memory capacity of the RPL Routers, and (ii) due to expensive 737 development cost of the routing protocol implementation, many RPL 738 implementations will only support a partial set of features from the 739 specification, leading to non-interoperable implementations. 741 In order to accommodate for the verbose exchange format, route 742 stretching and source routing for point-to-point traffic, several 743 additional Internet-Drafts are being discussed for adoption in the 744 ROLL Working Group - adding complexity to an already complex 745 specification which, it is worth recalling, was intended to be of a 746 protocol for low-capacity devices. 748 12. Underspecification 750 While [I-D.ietf-roll-rpl] is verbose in many parts, as described in 751 Section 11, some mechanisms are underspecified. 753 While for DIOs, the Trickle timer specifies a relatively efficient 754 and easy-to-understand timing for message transmission, the timing of 755 DAO transmission is not explicit. As each DAO may have a limited 756 lifetime, one "best guess" for implementers would be to send DAO 757 periodically, just before the life-time of the previous DAO expires. 758 Since DAOs may be lost, another "best guess" would be to send several 759 DAOs shortly one after the other in order to increase probability 760 that at least one DAO is successfully received. 762 The same underspecification applies for DAO-ACK messages: optionally, 763 on reception of a DAO, an RPL Router may acknowledge successful 764 reception by returning a DAO-ACK. Timing of DAO-ACK messages is 765 unspecified by RPL. 767 12.1. Observations 769 By not specifying details about message transmission intervals and 770 required actions when receiving DAO and DAO-ACKs, implementations may 771 exhibit a bad performance if not carefully implemented. Some 772 examples are: 774 1. If DAO messages are not sent in due time before the previous DAO 775 expires (or if the DAO is lost during transmission), the routing 776 entry will expire before it is renewed, leading to a possible 777 data traffic loss. 779 2. RPL does not specify to use jitter [RFC5148] (i.e. small random 780 delay for message transmissions). If DAOs are sent periodically, 781 adjacent RPL Routers may transmit DAO messages at the same time, 782 leading to link layer collisions. 784 3. In non-storing mode, the "piece-wise calculation" of routes to a 785 destination from which a DAO has been received, relies on 786 previous reception of DAOs from intermediate RPL Routers along 787 the path. If not all of these DAOs from intermediate RPL Routers 788 have been received, route calculation is not possible, and DAO- 789 ACKs or data traffic cannot be sent to that destination. 791 Other examples of underspecification include the local repair 792 mechanism, which may lead to loops and thus data traffic loss, if not 793 carefully implemented: an RPL Router discovering that all its parents 794 are unreachable, may - according to the RPL specification - "detach" 795 from the DODAG, i.e. increase its own rank to infinity. It may then 796 "poison" its sub-DODAG by advertising its infinite rank in its DIOs. 797 If, however, the RPL Router receives a DIO before it transmits the 798 "poisoned" DIO, it may attach to its own sub-DODAG, creating a loop. 799 If, instead, it had waited some time before processing DIOs again, 800 chances are it would have succeeded in poisoning its sub-DODAG and 801 thus avoided the loop. 803 13. Protocol Convergence 805 Trickle [RFC6206] is used by RPL to schedule transmission of DIO 806 messages, with the objective to minimize the amount of transmitted 807 DIOs while ensuring a low convergence time of the network. The 808 theoretical behavior of Trickle is well understood, and the 809 convergence properties are well studied. Simulations of the 810 mechanism, such as documented [trickle-multicast], confirm these 811 theoretical studies. 813 In real-world environments, however, varying link qualities may cause 814 the algorithm to converge less well: frequent message losses entail 815 resets of the Trickle timer and more frequent and unpredicted message 816 emissions. 818 This has been observed, e.g., in an experimental testbed: 69 RPL 819 Routers (MSP430-based wireless sensor routers with IEEE 802.15.4, 820 using [rpl-contiki] IPv6 stack and RPL without downward routes; the 821 parameters of the Trickle timer were set to the implementation 822 defaults (minimum DIO interval: 4 s, DIO interval doublings: 8, 823 redundancy constant: 10)) were positioned in a fixed grid topology. 824 This resulted in DODAGs being constructed with an average of 2.45 825 children per RPL Router and an average rank of 3.58. 827 In this small test network, the number of DIO messages emitted - 828 expectedly spiked wihin the first ~10 seconds. Alas, rather than 829 taper off to become zero (as the simulation studies would suggest), 830 the DIO emission rate remained constant at about 70 DIOs per second. 831 Details on this experiment can be found in [rpl-eval]. 833 13.1. Observations 835 The varying link quality in real-world environments results in 836 frequent changes of the best parent, which triggers a reset of the 837 Trickle timer and thus the emission of DIOs. Therefore Trickle does 838 not converge as well for links that are fluctuating in quality as in 839 theory. 841 The resulting higher control overhead due to frequent DIO emission, 842 leads to higher bandwidth and energy consumption as well as possibly 843 to an increased number of collisions of frames, as observed in 844 [trickle-multicast]. 846 14. Loops 848 [I-D.ietf-roll-rpl] states that it "guarantees neither loop free path 849 selection nor tight delay convergence times, but can detect and 850 repair a loop as soon as it is used. RPL uses this loop detection to 851 ensure that packets make forward progress [...] and trigger repairs 852 when necessary". This implies that a loop may only then be detected 853 and fixed when data traffic is sent through the network. 855 In order to trigger a local repair, RPL relies on the "direction" 856 information (with values "up" or "down"), contained in an IPv6 hop- 857 by-hop option header from received a data packet. If an "upward" 858 data packet is received by an RPL Router, but the previous hop of the 859 packet is listed with a lower rank in the neighbor set, the RPL 860 Router concludes that there must be a routing loop and it may 861 therefore trigger a local repair. For downward traffic in non- 862 storing mode, the DODAG Root can detect loops if the same router 863 identifier (i.e. IP address) appears at least twice in the path 864 towards a destination. 866 14.1. Observations 868 The reason for RPL to repair loops only when detected by a data 869 traffic transmission is to reduce control traffic overhead. However, 870 there are two problems in repairing loops only when so triggered: (i) 871 the triggered local repair mechanism delays forward progress of data 872 packets, increasing end-to-end delays, and (ii) the data packet has 873 to be buffered during repair. 875 (i) may seem as the lesser of the two problems, since in a number of 876 applications, such as data acquisition in smart metering 877 applications, an increased delay may be acceptable. However, for 878 applications such as alarm signals or in home automation (e.g. a 879 light switch), increased delay may be undesirable. 881 As for (ii), RPL is supposed to run on LLN routers with "constraints 882 on [...] memory" [I-D.ietf-roll-rpl]; buffering incoming packets 883 during the route repair may not be possible for all incoming data 884 packets, leading to dropped packets. Depending on the transport 885 protocol, these data packets must be retransmitted by the source or 886 are definitely lost. 888 If carefully implemented with respect to avoiding loops before they 889 occur, the impact of the loop detection in RPL may be minimized. 890 However, it can be observed that with current implementations of RPL, 891 such as the ContikiRPL implementation, loops do occur - and that 892 frequently. During the same experiments described in Section 13, a 893 snapshot of the DODAG was made every ten seconds. In 74.14% of the 894 4114 snapshots, at least one loop was observed. Further 895 investigation revealed that in all these cases the DODAG was 896 partitioned, and the loop occurred in the sub-DODAG that no longer 897 had a connection to the DODAG Root. When the link to the only parent 898 of an RPL Router breaks, the RPL Router may increase its rank and - 899 when receiving a DIO from an RPL Router in its sub-DODAG - attach 900 itself to its own sub-DODAG, thereby creating a loop - as detailed in 901 Section 12.1. 903 While it can be argued that the observed loops are harmless since 904 they occur in a DODAG partition that has no connection to the DODAG 905 Root, they show that the state of the network is inconsistent. Even 906 worse, when the broken link re-appears, it is possible that in 907 certain situations, the loop is only repaired when data traffic is 908 sent, possibly leading to data loss (as described above). This can 909 occur if the link to the previous parent is reestablished, but the 910 rank of that previous parent has increased in the meantime. 912 Another problem with the loop repair mechanism arises in non-storing 913 mode when using only downward traffic: while the DODAG Root can 914 easily detect loops (as described above), it has no direct means to 915 trigger a local repair where the loop occurs. Indeed, it can only 916 trigger a global repair by increasing the DODAG version number, 917 leading to a Trickle timer reset and increased control traffic 918 overhead in the network caused by DIO messages, and therefore a 919 possible energy drain of the RPL Routers and congestion of the 920 channel. 922 15. Security Considerations 924 This document does currently not specify any security considerations. 925 This document also does not provide any evaluation of the security 926 mechanisms of RPL. 928 16. IANA Considerations 930 This document has no actions for IANA. 932 17. Acknowledgements 934 The authors would like to thank Matthias Philipp (INRIA) for his 935 contributions to conducting many of the experiments, revealing or 936 confirming the issues described in this document. 938 18. Informative References 940 [I-D.ietf-6man-header] 941 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 942 Routing Header for Source Routes with RPL", work in 943 progress draft-ietf-6man-rpl-routing-header-07.txt, 944 December 2011. 946 [I-D.ietf-roll-routing-metrics] 947 Vasseur, J., Pister, K., Dejan, N., and D. Barthel, 948 "Routing Metrics used for Path Calculation in Low Power 949 and Lossy Networks", work in 950 progress draft-ietf-roll-routing-metrics-19, March 2011. 952 [I-D.ietf-roll-rpl] 953 Winther, T., Thubert, P., Hui, J., Vasseur, J., Brandt, 954 A., Kelsey, R., Levis, P., Piester, K., and R. Struik, 955 "RPL: IPv6 Routing Protocol for Low power and Lossy 956 Networks", work in progress draft-ietf-roll-rpl-19.txt, 957 March 2011. 959 [I-D.ietf-roll-rpl-of0] 960 Thubert, P., "RPL Objective Function Zero", work in 961 progress draft-ietf-roll-of0-20, September 2011. 963 [I-D.ietf-roll-rpl-terminology] 964 Vasseur, JP., "Terminology in Low power And Lossy 965 Networks", work in 966 progress draft-ietf-roll-terminology-06, September 2011. 968 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 969 3", BCP 9, RFC 2026, October 1996. 971 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 972 (IPv6) Specification", RFC 2460, Decemer 1998. 974 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 975 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 976 September 2007. 978 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 979 "Transmission of IPv6 Packets over IEEE 802.15.4 980 Networks", RFC 4944, September 2007. 982 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 983 Considerations in Mobile Ad Hoc Networks (MANETs)", 984 RFC 5148, February 2008. 986 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 987 "Routing Requirements for Urban Low-Power and Lossy 988 Networks", RFC 5548, May 2009. 990 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 991 "Industrial Routing Requirements in Low-Power and Lossy 992 Networks", RFC 5673, October 2009. 994 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 995 Routing Requirements in Low-Power and Lossy Networks", 996 RFC 5826, April 2010. 998 [RFC5867] Martocci, J., Mi, P., Riou, N., and W. Vermeylen, 999 "Building Automation Routing Requirements in Low Power and 1000 Lossy Networks", RFC 5867, June 2010. 1002 [RFC6206] Levis, P., Clausen, T., Gnawali, O., and J. Ko, "The 1003 Trickle Algorithm", RFC 6206, March 2011. 1005 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1006 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1007 September 2011. 1009 [bidir] Clausen, T. and U. Herberg, "A Comparative Performance 1010 Study of the Routing Protocols LOAD and RPL with Bi- 1011 Directional Traffic in Low-power and Lossy Networks 1012 (LLN)", Proceedings of the Eighth ACM International 1013 Symposium on Performance Evaluation of Wireless Ad Hoc, 1014 Sensor, and Ubiquitous Networks (PE-WASUN), 2011. 1016 [ieee802154] 1017 Computer Society, IEEE., "IEEE Std. 802.15.4-2003", 1018 October 2003. 1020 [roll-charter] 1021 "ROLL Charter", 1022 web http://datatracker.ietf.org/wg/roll/charter/. 1024 [rpl-contiki] 1025 Tsiftes, N., Eriksson, J., and A. Dunkels, "Low-Power 1026 Wireless IPv6 Routing with ContikiRPL", 1027 Proceedings Proceedings of the 9th ACM/IEEE International 1028 Conference on Information Processing in Sensor Networks 1029 (ISPN), 2011. 1031 [rpl-eval] 1032 Clausen, T., Herberg, U., and M. Philipp, "A Critical 1033 Evaluation of the IPv6 Routing Protocol for Low Power and 1034 Lossy Networks (RPL)", Proceedings of the 5th IEEE 1035 International Conference on Wireless & Mobile Computing, 1036 Networking & Communication (WiMob), 2011. 1038 [rpl-eval-UCB] 1039 Ko, J., Dawson-Haggerty, S., Culler, D., and A. Terzis, 1040 "Evaluating the Performance of RPL and 6LoWPAN in TinyOS", 1041 Proceedings of the Workshop on Extending the Internet to 1042 Low power and Lossy Networks (IP+SN), 2011. 1044 [trickle-multicast] 1045 Clausen, T. and U. Herberg, "Study of Multipoint-to-Point 1046 and Broadcast Traffic Performance in the 'IPv6 Routing 1047 Protocol for Low Power and Lossy Networks' (RPL)", 1048 Journal of Ambient Intelligence and Humanized Computing, 1049 2011. 1051 Authors' Addresses 1053 Thomas Clausen 1054 LIX, Ecole Polytechnique 1055 91128 Palaiseau Cedex, 1056 France 1058 Phone: +33 6 6058 9349 1059 Email: T.Clausen@computer.org 1060 URI: http://www.thomasclausen.org 1061 Axel Colin de Verdiere 1062 LIX, Ecole Polytechnique 1063 91128 Palaiseau Cedex, 1064 France 1066 Phone: +33 6 1264 7119 1067 Email: axel@axelcdv.com 1068 URI: http://www.axelcdv.com/ 1070 Jiazi Yi 1071 LIX, Ecole Polytechnique 1072 91128 Palaiseau Cedex, 1073 France 1075 Phone: +33 1 6933 4031 1076 Email: jiazi@jiaziyi.com 1077 URI: http://www.jiaziyi.com/ 1079 Ulrich Herberg 1080 Fujitsu Laboratories of America 1081 1240 E Arques Ave 1082 Sunnyvale, CA 94085 1083 USA 1085 Email: ulrich@herberg.name 1086 URI: http://www.herberg.name/