idnits 2.17.1 draft-clausen-lln-rpl-experiences-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 631: '... A ZIP node MUST ensure that the ...' RFC 2119 keyword, line 635: '...nnel entry point SHOULD be considered ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2018) is 2285 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 5 Expires: July 27, 2018 J. Yi 6 Ecole Polytechnique 7 U. Herberg 9 Y. Igarashi 10 Hitachi, Ltd., Yokohama Research 11 Laboratory 12 January 23, 2018 14 Observations on RPL: IPv6 Routing Protocol for Low power and Lossy 15 Networks 16 draft-clausen-lln-rpl-experiences-10 18 Abstract 20 With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - 21 published as a Proposed Standard after a ~2-year development cycle, 22 this document presents an observation of the resulting protocol, of 23 its applicability, and of its limits. The documents presents a 24 selection of observations on the protocol characteristics, exposes 25 experiences acquired when producing various prototype implementations 26 of RPL, and presents results obtained from testing this protocol - by 27 way of network simulations, in network testbeds and in deployments. 28 The document aims at providing a better understanding of possible 29 limits of RPL, notably the possible directions that further protocol 30 developments should explore, in order to address these. 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 http://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 July 27, 2018. 49 Copyright Notice 51 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. RPL Message Emission Timing - Trickle Timers . . . . . . . 7 70 4. Requirement Of DODAG Root . . . . . . . . . . . . . . . . . . 8 71 4.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. RPL Data Traffic Flows . . . . . . . . . . . . . . . . . . . . 9 73 5.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 10 74 6. Fragmentation Of RPL Control Messages And Data Packet . . . . 12 75 6.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. The DAO Mechanism: Downward and Point-to-Point Routes . . . . 15 77 7.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 15 78 8. Address Aggregation and Summarization . . . . . . . . . . . . 17 79 8.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 18 80 9. Link Bidirectionality Verification . . . . . . . . . . . . . . 19 81 9.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 19 82 10. Neighbor Unreachability Detection For Unidirectional Links . . 20 83 10.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 21 84 11. RPL Implementability and Complexity . . . . . . . . . . . . . 22 85 11.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 23 86 12. Underspecification . . . . . . . . . . . . . . . . . . . . . . 23 87 12.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 23 88 13. Protocol Convergence . . . . . . . . . . . . . . . . . . . . . 24 89 13.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 24 90 13.2. Caveat . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 14. Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 14.1. Observations . . . . . . . . . . . . . . . . . . . . . . . 26 93 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 96 18. Informative References . . . . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 99 1. Introduction 101 RPL - the "Routing Protocol for Low Power and Lossy Networks" 102 [RFC6550] - is a proposal for an IPv6 routing protocol for Low-power 103 Lossy Networks (LLNs), by the ROLL Working Group in the Internet 104 Engineering Task Force (IETF). This routing protocol is intended to 105 be the IPv6 routing protocol for LLNs and sensor networks, applicable 106 in all kinds of deployments and applications of LLNs. 108 The objective of RPL and ROLL is to provide routing in networks which 109 "comprise up to thousands of nodes" [roll-charter], where the 110 majority of the nodes have very constrained resources [RFC7102], and 111 where handling mobility is not an explicit design criteria [RFC5867], 112 [RFC5826], [RFC5673], [RFC5548]. 114 [roll-charter] states that "Typical traffic patterns are not simply 115 unicast flows (e.g. in some cases most if not all traffic can be 116 point to multipoint)". [RFC7102] further categorizes the supported 117 traffic types into "upward" traffic from sensors to an actuator or 118 LBR (LLN Border Router) (denoted multipoint-to-point), "downward" 119 traffic from the actuator or LBR to the sensors (denoted point-to- 120 multipoint) and traffic from "sensor to sensor" (denoted point-to- 121 point traffic), and establishes this terminology for these traffic 122 types. Thus, while the target for RPL and ROLL is to support all of 123 these traffic types, the emphasis among these, according to 124 [roll-charter], appears to be to optimize for multipoint-to-point 125 traffic, while also supporting point-to-multipoint and point-to-point 126 traffic. 128 With experiences obtained since the publication of RPL as [RFC6550], 129 it is opportune to document observations of the protocol, in order to 130 understand which aspects of it work well and which necessitate 131 further investigations. Understanding possible limitations is 132 important to identify issues which may restrict the deployment scope 133 of the protocol and which may need further protocol work or 134 enhancements. 136 The LLNs have different technologies at the link and physical layer, 137 including IEEE 802.15.4 [ieee802154], IEEE 802.15.4g [ieee802154g], 138 IEEE G3-PLC (Power Line Communication) [g3-plc]. They varies in 139 terms of data rate, MTU (Maximum Transmission Unit), modulation, etc. 140 The observations made in this document, except when explicitly noted 141 otherwise, do not depend on any specific implementation or 142 deployment, but can be understood by analyzing the protocol 143 specification [RFC6550]. That said, all observations made have been 144 confirmed to also be present in, at least, some deployments or test 145 platforms with RPL, i.e., have been experimentally confirmed. 147 This document is explicitly not an implementation guidebook for RPL. 148 It has as objective to document observations of behaviors of 149 [RFC6550], in the spirit of better understanding the characteristics 150 and limits of the protocol. 152 2. Terminology 154 This document uses the terminology and notation defined in [RFC6550]. 156 Additionally, this document uses terminology from [RFC7102], 157 specifically the terms defined for the traffic types "MP2P" 158 (Multipoint-to-Point), "P2P" (Point To Point) and "P2MP" (Point-to- 159 Multipoint). 161 3. RPL Overview 163 The basic construct in RPL is a "Destination Oriented Directed 164 Acyclic Graph" (DODAG), depicted in Figure 1, with a single router 165 acting as DODAG Root. The DODAG Root has responsabilities in 166 addition to those of other routers, including for initiating, 167 configuring, managing the DODAG, and (in some cases) acting as a 168 central relay for traffic through and between routers in the LLN. 170 (s) 171 ^ ^ ^ 172 / | \ 173 (a) | (b) 174 ^ (c) ^ 175 / ^ (d) 176 (f) | ^ ^ 177 (e)--/ \ 178 (g) 180 Figure 1: RPL DODAG 182 In an LLN, in which RPL has converged to a stable state, each router 183 has identified a stable set of parents, each of which is a potential 184 next-hop on a route towards the DODAG Root. One of the parents is 185 selected as preferred parent. Each router that is part of a DODAG 186 (i.e., which has selected parents and a preferred parent) will emit 187 DODAG Information Object (DIO) messages, using link-local multicast, 188 indicating its respective rank in the DODAG (i.e., distance to the 189 DODAG Root according to some metric(s), in the simplest form hop- 190 count). Upon receiving of each DIO message, a router will calculate 191 its own rank such that it is greater than the rank of each of its 192 parents, select a preferred parent and then itself start emitting DIO 193 messages. A router can joint multiple DODAGs, if it receives DIO 194 messages from different DODAG root. 196 DODAG formation thus starts at the DODAG Root (initially, the only 197 router which is part of a DODAG), and spreads gradually to cover the 198 whole LLN as DIOs are received. Parents and preferred parents are 199 thus selected, and further routers participate in the DODAG. The 200 DODAG Root also includes, in DIO messages, a DODAG Configuration 201 Object, describing common configuration attributes for all routers in 202 that network - including their mode of operation, timer 203 characteristics etc. routers in a DODAG include a verbatim copy of 204 the last received DODAG Configuration Object in their DIO messages, 205 permitting also such configuration parameters propagating through the 206 network. 208 As a Distance Vector protocol, RPL restricts the ability of a router 209 to change rank. A router can freely assume a smaller rank than 210 previously advertised (i.e., logically move closer to the DODAG Root) 211 if it discovers a parent advertising a lower rank. RPL must then 212 disregard all previous parents of ranks higher than the router's new 213 rank. The ability of a router to assume a greater rank (i.e., 214 logically move farther from the DODAG Root) than previously 215 advertised is restricted in order to avoid count-to-infinity 216 problems. The DODAG Root can trigger "global recalculation" of the 217 DODAG by increasing a sequence number, DODAG version, in DIO 218 messages. 220 The DODAG so constructed is used for installing routes: the 221 "preferred parent" of a router can serve as a default route towards 222 the DODAG Root, and the DODAG Root can embed in its DIO messages the 223 destination prefixes, included by DIOs generated by routers through 224 the LLN, to which connectivity is provided by the DODAG Root. Thus, 225 RPL by way of DIO generation provides "upward routes" or "multipoint- 226 to-point routes" from the sensors inside the LLN and towards the 227 DODAG Root (and, possibly, to destinations reachable through the 228 DODAG Root). 230 "Downward routes" are enabled by having sensors issue Destination 231 Advertisement Object (DAO) messages, propagating as unicast via 232 preferred parents towards the DODAG Root. These describe which 233 prefixes belong to, and can be reached via, which router. In a 234 network, all routers must operate in either of storing mode or non- 235 storing mode, specified by way of a "Mode of Operation" (MOP) flag in 236 the DODAG Configuration Object from the DODAG Root. Those two modes 237 are non-interoperable, i.e., a mixture of routers running in 238 different modes is impossible in the same routing domain. Depending 239 on the MOP, DAO messages are forwarded differently towards the DODAG 240 Root: 242 o In "non-storing mode", a router originates DAO messages, 243 advertising one or more of its parents, unicasting these to the 244 DODAG Root. Once the DODAG Root has received DAOs from each 245 router along a path to another given router, it can use source 246 routing to reach advertised destinations within the LLN. 248 o In "storing mode", each router on the route between the originator 249 of a DAO and the DODAG Root records a route to the prefixes 250 advertised in the DAO, by indicating the next-hop towards these 251 (the router, from which the DAO was received), then forwards the 252 DAO to its preferred parent. 254 "Point-to-point routes" are used to communicate between non-root 255 nodes in the DODAG. It is by default supported by having the source 256 sensor transmit a data packet, via its default route to the DODAG 257 Root (i.e., using the upward routes). Depending on the "Mode of 258 Operation" for the DODAG, RPL either add a source-route to the 259 received data packet for reaching the destination sensor (downward 260 routes in non-storing mode), or simply use hop-by-hop routing 261 (downward routes in storing mode) for forwarding the data packet. In 262 the case of storing mode, if the source and the destination for a 263 point-to-point data packet share a common ancestor other than the 264 DODAG Root, a downward route may be available in a router (and, thus, 265 used) before the data packet reaches the DODAG Root. 267 3.1. RPL Message Emission Timing - Trickle Timers 269 RPL message generation is timer-based, with the DODAG Root being able 270 to configure back-off of message emission intervals using Trickle 271 [RFC6206]. Trickle, as used in RPL, stipulates that a router 272 transmits a DIO "every so often" - except if receiving a number of 273 DIOs from neighbor routers - enabling the router to determine if its 274 DIO transmission is redundant. 276 When a DIO message is received, there are two possible outcomes: 277 either the router that hears the message finds that the information 278 contained is consistent with its own state (i.e., the received DODAG 279 version number corresponds with that which the router has recorded, 280 and no better rank is advertised than that which is recorded in the 281 parent set) - or, the recipient router detects that either the sender 282 of the DIO or itself has out-of-date information. If the sender has 283 out-of-date information, then the recipient router schedules 284 transmission of a DIO to update this information. If the recipient 285 router has out-of-date information, then it updates based on the 286 information received in the DIO. 288 With Trickle, a router will schedule emission of a DIO at some time, 289 t, in the future. When receiving a DIO containing information 290 consistent with its own information, the router will record that 291 "redundant information has been received" by incrementing a 292 redundancy counter, c. At the time t, if c is below some "redundancy 293 threshold", then it transmits its DIO. Otherwise, transmission of a 294 DIO at this time is suppressed, c is reset and a new t is selected to 295 twice as long time in the future - bounded by a pre-configured 296 maximum value for t. If, on the other hand, the router has received 297 an out-of-date DIO from one of its neighbors, t is reset to a pre- 298 configured minimum value and c is set to zero. In both cases, at the 299 expiration of t, the router will verify if c is below the "redundancy 300 threshold" and if so transmit - otherwise, increase t and stay quiet. 302 4. Requirement Of DODAG Root 304 As indicated in Section 3, the DODAG Root has both a special 305 responsibility and is subject to special requirements. The DODAG 306 Root is responsible for determining and maintaining the configuration 307 parameters for the DODAG, and for initiating DIO emissions. 309 The DODAG Root is also responsible (in both storing and non-storing 310 mode) for being able to, when downward routes are supported, maintain 311 sufficient topological information to be able to construct routes to 312 all destinations in the network. 314 When operating in non-storing mode, this implies that the DODAG Root 315 is required to have sufficient memory and sufficient computational 316 resources to be able to record a network graph containing all routes 317 from itself and to all destinations and to calculate routes. 319 When operating in storing mode, this implies that the DODAG Root 320 needs enough memory to keep a list of all routers in the RPL 321 instance, and a next hop for each of those routers. If aggregation 322 is used, the memory requirements can be reduced in storing mode (see 323 Section 8 for observations about aggregation in RPL). 325 The DODAG Root is also required to have sufficient energy available 326 so as to be able to ensure the relay functions required. This, 327 especially for non-storing mode, where all data packets transit 328 through the DODAG Root. 330 4.1. Observations 332 In a given deployment, selected routers can be provisioned with the 333 required energy, memory and computational resources so as to serve as 334 DODAG Roots, and be administratively configured as such - with the 335 remainder of the routers in the network being of typically lesser 336 capacity. In storing mode, the DODAG root needs to keep a routing 337 entry for each router in the RPL instance. In non-storing mode, the 338 resource requirements on the DODAG Root are likely much higher than 339 in storing mode, as the DODAG Root needs to store a network graph 340 containing complete routes to all destinations in the RPL instance, 341 in order to calculate the routing table (whereas in storing mode, 342 only the next hop for each destination in the RPL instance needs to 343 be stored. Aaggregation may be used to further reduce the resource 344 requirements). 346 A router that acts as a DODAG Root represents a single point of 347 failure for the DODAG it serves. It is possible for a given RPL 348 deployment to contain several DODAGs, each rooted in a border router. 349 RPL also supports that several border routers participate in the same 350 DODAG - with the caveat that in this case, a "virtual" DODAG root, 351 external to the LLN, exists and which coordinates DODAGVersionNumbers 352 and other DODAG parameters. The precise coordination mechanism is 353 not specified in [RFC6550], which instead states that: 355 The method of coordination is out of scope for this specification 356 (to be defined in future companion specifications). 358 As the memory requirements for the DODAG Root and for other routers 359 are substantially different, unless all routers are provisioned with 360 resources (memory, energy, ...) to act as DODAG Roots, effectively if 361 the designated DODAG Root fails, the network fails and RPL is unable 362 to operate. Even if electing another router as temporary DODAG Root 363 (e.g., for forming a "Floating" DODAG) for providing internal 364 connectivity between routers, this router may not have the necessary 365 resources to satisfy this role as (temporary) DODAG Root. 367 Thus, although in principle RPL provides, by way of "Floating 368 DODAGs", protocol mechanisms for establishing a DODAG for providing 369 internal connectivity even in case of failure of the administratively 370 provisioned DODAG Root, all (or at least a large number) of the 371 routers need to have resources to act as roots to support floating 372 DODAG, especially in non-storing mode. 374 Another possible LLN scenario is that only internal point-to-point 375 connectivity is sought, and no router has a more "central" role than 376 any other - a self-organizing LLN. In those cases, it would be hard 377 to specify such "super-device" as DODAG root, and can result in non- 378 optimal routes. 380 5. RPL Data Traffic Flows 382 [RFC7102] defines three data traffic types: multipoint-to-point 383 traffic, point-to-multipoint traffic, and point-to-point traffic. 385 Multipoint-to-point traffic reflects telemetry flowing "from sensors 386 to a sink", with point-to-multipoint traffic reflecting control 387 (commands) "from a central authority to actuators". 389 RPL is designed to support these three data traffic types, but in its 390 doing so implicitly makes two assumptions regarding the targeted 391 deployment scenarios: 393 o Telemetry "from sensors to a sink" is common, control (commands) 394 "from a central authority to actuators" is rare - and while 395 traffic between two sensors is supported, it is extremely rare. 397 o The "sink" and the "central authority" are co-located with, or 398 reachable via, the DODAG root. 400 While not specifically called out thus in [RFC6550], the resulting 401 protocol design, reflects these assumptions in that the mechanism 402 constructing multipoint-to-point routes is efficient in terms of 403 control traffic generated and state required, point-to-multipoint 404 route construction much less so - and point-to-point routes subject 405 to potentially significant route stretch (routes going through the 406 DODAG Root in non-storing mode) and over-the-wire overhead from using 407 source routing (from the DODAG Root to the destination) (see 408 Section 7) - or, in storing mode case, considerable memory 409 requirements in all LLN routers inside the network (see Section 7). 411 A router selects from among its parents a "preferred parent", to 412 serve as a default route towards the DODAG Root (and to prefixes 413 advertised by the DODAG Root). Thus, RPL provides "upward routes" or 414 "multipoint-to-point routes" from the routers below the DODAG Root 415 and towards the DODAG Root. 417 A router that wishes to act as a destination for data traffic 418 ("downward routes" or "point-to-multipoint") issues DAOs upwards in 419 the DODAG towards the DODAG Root, describing which prefixes belong 420 to, and can be reached via, that router. 422 Point-to-point routes are enabled by a combination of "upward routes" 423 and "downward routes": the data traffic is first forwarded based on 424 the "upward route" towards the DODAG root. When there is a route to 425 the destination possible (in a sensor or DODAG root eventually, 426 depending on the operation mode), the data traffic is forwarded along 427 the "downward route". 429 5.1. Observations 431 RPL is well suited for networks in which the sink for data traffic is 432 co-located with, (or is outside the LLN and reachable via), the DODAG 433 root. However, these data traffic characteristics does not represent 434 a universal distribution of traffic types in LLNs. There are 435 scenarios where the sink is not co-located with (or is outside the 436 LLN and reachable via) the DODAG. These include: 438 o Command/control networks in which point-to-point traffic is a more 439 common occurrence, documented, e.g., in [RFC5867] ("Building 440 Automation Routing Requirements in Low Power and Lossy Networks"). 442 o Networks in which all traffic is bi-directional, e.g., in case 443 sensor devices in the LLN are, in majority, "actively read": a 444 request is issued by the DODAG Root to a specific sensor, and the 445 sensor value is expected returned. 447 o In fact, unless all traffic in the LLN is unidirectional, without 448 acknowledgements (e.g., as in UDP), and no control messages (e.g., 449 for service discovery) or other data packets are sent from the 450 DODAG Root to the routers, traffic will be bi-directional. The 451 IETF protocol for use in constrained environments, CoAP [RFC7252], 452 makes use of acknowledgements to control packet loss and ensure 453 that packets are received by the packet destination. In the four 454 message types defined for CoAP: confirmable, acknowledgement, 455 reset and non-confirmable, the first three are dedicated for 456 sending/acknowledgement cycle. Another example is that the ZigBee 457 Alliance SEP 2.0 specification [SEP2.0] (adopted by the IEEE) 458 describes the use of HTTP over TCP over ZigBeeIP, between routers 459 and the DODAG Root - and with the use of TCP inherently causing 460 bidirectional traffic by way of data-packets and their 461 corresponding acknowledgements. In fact, current Internet 462 protocols generally require some form of acknowledgment. 463 Foregoing an acknowledgment probably means a trade-off in the area 464 of reliable transmission or repeated retransmissions or both. 466 o Telemetry scenarios where the DODAG root and the sink are not co- 467 located. This can happen if different kinds of information are 468 sent to different central authorities for processing: for example, 469 temperature goes to Server A and humidity goes to Server B. A 470 possible solution for RPL is to run several DADAGs with different 471 roots, which incurs extra overhead. 473 For scenarios in which point-to-point traffic is a more common 474 occurrence, all point-to-point routes include the DODAG Root, 475 possibly causing congestion events on the communication medium near 476 the DODAG Root, and draining energy from the intermediate routers on 477 an unnecessarily long route. If sensor-to-sensor traffic is common, 478 routers near the DODAG Root will be particularly solicited as relays, 479 especially in non-storing mode. 481 For scenarios with bi-directional traffic, as there is no provision 482 for on-demand generation of routing information from the DODAG Root 483 to a proper subset of all routers, each router (besides the Root) is 484 required to generate DAOs. In particular in non-storing mode, each 485 router will unicast a DAO to the DODAG Root (whereas in storing mode, 486 the DAOs propagate upwards towards the Root). The effects of the 487 requirement to establish downward routes to all routers are: 489 o Increased memory and processing requirements at the DODAG Root (in 490 particular in non-storing mode) and in routers near the DODAG Root 491 (in storing mode). 493 o A considerable control traffic overhead [bidir], in particular at 494 and near the DODAG Root. Given the low data rate of LLNs (between 495 20kbit/s and 250kbit/s for 802.15.4, between 5 kbit/s and 40 496 kbit/s for G3-PLC, depending on the types of modulation), it has 497 potential to congest the channels. 499 o Energy drain from the routers near the DODAG root, because they 500 need to forward more traffic for other parts of the network. 502 6. Fragmentation Of RPL Control Messages And Data Packet 504 The link layers for LLNs generally have limited MTUs compared to 505 ethernet or wireless LANs. For example, for [ieee802154], the MTU is 506 limited to 127 bytes; for [g3-plc], it is up to 252 octets, or 511 507 octets, depending on the bandplan. Those link layers are unable to 508 provide an MTU of at least 1280 octets - as otherwise required for 509 IPv6 [RFC2460]. In such LLNs, link fragmentation and reassembly of 510 IP packets at a layer below IPv6 is used to transport larger IP 511 packets, providing the required minimum 1280 octet MTU [RFC4919]. 513 When such link fragmentation is used, the IP packet has to be 514 reassembled at every hop. Every fragment must be received 515 successfully by the receiving device, or the entire IP packet is 516 lost. Moreover, the additional link-layer frame overhead (and IPv6 517 Fragment header overhead in case of IP fragmentation) for each of the 518 fragments increases the capacity required from the medium. It may 519 consume more energy for transmitting a higher number of frames on the 520 network interface. 522 RPL is an IPv6 routing protocol, designed to operate on constrained 523 link layers, such as [ieee802154], with a maximum frame size of 127 524 bytes - a much smaller value than the specified minimum MTU of 1280 525 bytes for IPv6 [RFC2460]. Reducing the need of fragmentation of IP 526 datagrams on such a link layer, 6LoWPAN provides an adaptation layer 527 [RFC4944], [RFC6282], providing link fragmentation in order to 528 accommodate IPv6 packet transmissions over the maximum IEEE 802.15.4 529 frame size of 127 octets, as well as compressing the IPv6 header, 530 reducing the overhead of the IPv6 header from at least 40 octets to a 531 minimum of 2 octets. Given that the IEEE 802.15.4 frame size of 127 532 octets, a maximum frame overhead of 25 octets and 21 octets for link 533 layer security [RFC4944], 81 octets remain for L2 payload. Further 534 subtracting 2 octets for the compressed IPv6 header leaves 79 octets 535 for L3 data payload if link fragmentation is to be avoided. 537 The second L in LLN indicating Lossy [roll-charter], higher loss 538 rates than typically seen in IP networks are expected, rendering link 539 fragmentation important to avoid. This, in particular because, as 540 mentioned above, the whole IP packet is dropped if only a single 541 fragment is lost [RFC4944]. 543 There are other link layers that can provide efficient MTU (e.g., 544 [ieee802154g] can provide 2047-octet packets) for LLNs. They do not 545 apply to the observations of this section. 547 6.1. Observations 549 [RFC4919] makes the following observation regarding using IP in 550 LoWPAN networks based on IEEE 802.15.4 frames: 552 Applications within LoWPANs are expected to originate small 553 packets. Adding all layers for IP connectivity should still allow 554 transmission in one frame, without incurring excessive 555 fragmentation and reassembly. Furthermore, protocols must be 556 designed or chosen so that the individual "control/protocol 557 packets" fit within a single 802.15.4 frame. Along these lines, 558 IPv6's requirement of sub-IP reassembly [...] may pose challenges 559 for low-end LoWPAN devices that do not have enough RAM or storage 560 for a 1280-octet packet. 562 In order to avoid the link fragmentation and thus to adhere to the 563 recommendation in [RFC4919], each control packet of RPL must fit into 564 the remaining 79 octets of the 802.15.4 frame. While 79 octets may 565 seem to be sufficient to carry RPL control messages, consider the 566 following: RPL control messages are carried in ICMPv6. The mandatory 567 ICMPv6 header consumes 4 octets. The DIO base another 24 octets. If 568 link metrics are used, that consumes at least another 8 octets - and 569 this is when using a simple hop count metric; other metrics may 570 require more. The DODAG Configuration Object consumes up to a 571 further 16 octets, for a total of 52 octets. Adding a Prefix 572 Information Object for address configuration consumes another 32 573 octets, for a total of 84 octets - thus exceeding the 79 octets 574 available for L3 data payload and causing link fragmentation of such 575 a DIO. As a point of reference, the ContikiRPL [rpl-contiki] 576 implementation includes both the DODAG Configuration option and the 577 Prefix Information option in all DIO messages. Any other options, 578 e.g., Route Information options indicating prefixes reachable through 579 the DODAG Root, increase the overhead and thus the probability of 580 fragmentation. 582 RPL may further increase the probability of link fragmentation of 583 data traffic: for non-storing mode, RPL employs source-routing for 584 all downward traffic. [RFC6554] specifies the RPL Source Routing 585 header, which imposes a fixed overhead of 8 octets per IP packet 586 leaving 71 octets remaining from the link-layer MTU in order to 587 contain the whole IP packet into a single frame - from which must be 588 deducted a variable number of octets, depending on the length of the 589 route. With fewer octets available for data payload, RPL thus 590 increases the probability for link fragmentation of also data 591 packets. This, in particular, for longer routes, e.g., for point-to- 592 point data traffic between sensors inside the LLN, where data traffic 593 transit through the DODAG Root and is then source-routed to the 594 destination. The overhead of source routing is further detailed in 595 Section 7. 597 Given the minimal packet size of LLNs, the routing protocol must 598 impose low (or no) overhead on data packets, hopefully independently 599 of the number of hops [RFC4919]. However, source-routing not only 600 causes increased overhead in the IP header, it also leads to a 601 variable available payload for data (depending on how long the source 602 route is). In point-to-point communication and when non-storing mode 603 is used for downward traffic, the source of a data packet will be 604 unaware of how many octets will be available for payload (without 605 incurring link fragmentation) when the DODAG Root relays the data 606 packet and adds the source routing header. Thus, the source may 607 choose an inefficient size for the data payload: if the data payload 608 is large, it may exceed the link-layer MTU at the DODAG Root after 609 adding the source-routing header; on the other hand, if the data 610 payload is low, the network resources are not used efficiently, which 611 introduces more overhead and more frame transmissions. 613 Unless the DODAG Root is the source of an IPv6 packet to be forwarded 614 through an RPL LLN, the IPv6 packet must be encapsulated in IPv6-in- 615 IPv6 tunneling, with the RPL extension added to the outer IPv6 616 header. Similarly, in non-storing mode, the original IPv6 packet 617 must be carried in IPv6-in-IPv6 tunneling, with the RPL routing 618 header added to the outer IPv6 header. Both of these mechanisms add 619 additional overhead, increasing the likelihood that link 620 fragmentation will be required to deliver the IPv6 packet. In 621 addition, even IPv6 packets that are the minimum MTU size of 1280 622 octets will require IPv6 fragmentation to accommodate the RPL tunnel 623 and headers on a deployment using the [RFC4944] specification to 624 carry IPv6 over IEEE 802.15.4, because RFC4944 defines the MTU for 625 such deployments to be 1280 octets. The ZigBee Alliance has relaxed 626 [RFC4944] to use a longer MTU for accommodating 1280 octet IPv6 627 packets with the required tunnel overhead without fragmentation. The 628 "ZigBee IP Specification" (ZIP) [ZigBeeIP] specifies in section 629 5.4.3: 631 A ZIP node MUST ensure that the insertion of a RPL extension 632 header, either directly or via IPv6-in-IPv6 tunneling, does not 633 cause IPv6 fragmentation. This is done by using a different MTU 634 value for packets where the IPv6 header includes a RPL extension 635 header. The RPL tunnel entry point SHOULD be considered as a 636 separate interface whose MTU is set to the 6LoWPAN interface MTU 637 plus RPL_MTU_EXTENSION bytes. 639 Section 7.1 of [ZigBeeIP] defines RPL_MTU_EXTENSION to be 100 bytes. 641 7. The DAO Mechanism: Downward and Point-to-Point Routes 643 RPL specifies two distinct and incompatible "modes of operation" for 644 downward traffic: 1) storing mode: each router is assumed to maintain 645 routes to all destinations in its sub-DODAG, i.e., routers that are 646 "deeper down" in the DODAG, 2) non-storing mode: only the DODAG Root 647 stores routes to destinations inside the LLN. The DODAG Root employs 648 strict source routing in order to route data traffic to the 649 destination router. 651 7.1. Observations 653 In addition to possible fragmentation, as occurs when using 654 potentially long source routing headers over a medium with a small 655 MTU - similar to what is discussed in Section 6 - the maximum length 656 of the source routing header [RFC6554] is limited to 136 octets, 657 including an 8 octet long header. As each IPv6 address has a length 658 of 16 octets, not more than 8 hops from the source to the destination 659 are possible for "raw IPv6". Using address compression (e.g., as 660 specified in [RFC4944]), the maximum route length may not exceed 64 661 hops. This excludes deployment of RPL for scenarios with long 662 "chain-like" topologies, such as traffic lights along a street. 664 In storing mode, each router has to store routes for destinations in 665 its sub-DODAG. This implies that, for routers near the DODAG Root, 666 the required storage is only bounded by the number of destinations in 667 the network. As RPL targets constrained devices with little memory, 668 but also has as ambition to be operating networks consisting of 669 thousands of routers [roll-charter], the storing capacity on these 670 routers may need to be the same as DODAG root. At least, the storage 671 requirements in routers "near the DODAG Root" and "far from the DODAG 672 Root" is not homogenous. Some sort of administrative deployment, and 673 continued administrative maintenance of devices, as the network 674 evolves, is thus needed. 676 In an experimental testbed, [rpl-eval-UCB] argues that practical 677 experiences suggest that RPL in storing mode, with routers having 678 10kB of RAM (TELOSB mote with TinyOS, 16-bit RISC, 48 kB program 679 flash memory, 16 kB configuration EEPROM), should be limited to 680 networks of less than ~30 routers. Note that observation of less 681 than 30 routers only presents the results obtained from specified 682 testbed and implementation in [rpl-eval-UCB]. Aggregation / 683 summarization of addresses may be advanced as a possible argument 684 that this issue is of little significance - Section 8 discusses why 685 such an argument does not apply. Moreover, if the LoWPAN adaption 686 layer [RFC4944] is used in the LLN, route aggregation is not possible 687 since the same /64 is applied across the entire network. 689 In short, the mechanisms in RPL force the choice between requiring 690 all routers to have sufficient memory to store route entries for all 691 destinations (storing mode) - or, suffer increased risk of 692 fragmentation (thus loss of data packets), while consuming network 693 capacity by way of source routing through the DODAG Root (non-storing 694 mode). 696 In RPL, the "mode of operation" stipulates that either downward 697 routes are not supported (MOP=0), or that they are supported by way 698 of either storing or non-storing mode. In case downward routes are 699 supported, RPL does not provide any mechanism for discriminating 700 between which routes should or should not be maintained. In 701 particular, in order to calculate routes to a given destination, all 702 intermediaries between the DODAG Root and that destination must 703 themselves be reachable - effectively rendering downward routes in 704 RPL an "all-or-none" situation. In case a destination is 705 unreachable, all the DODAG Root may do is increase DTSN (Destination 706 Advertisement Trigger Sequence Number) to trigger DAO message 707 transmission, or eventually increase the DODAG version number in case 708 the destination is still unreachable, which possibly provokes a 709 broadcast-storm-like situation. This, in particular, as [RFC6550] 710 does not specify DAO message transmission constraints, nor any 711 mechanism for adapting DAO emission to the network capacity. 713 In storing mode, a DTSN increment by the DODAG Root works only if all 714 routers, on the path from the DODAG Root to the "lost" target router, 715 have kept their routing table up-to-date by triggering DAO updates, 716 and thus have a route to the target router. In non-storing mode, the 717 DODAG Root incrementing its DTSN will trigger global DAO updates. It 718 will result in extra overhead in the network and delay in the 719 recalculation of the missing route. 721 Furthermore, DTSN increments are carried by way of DIO messages. In 722 case the "lost" target router has lost all of its parents, it will 723 not be able to receive DIO messages from them. The router will have 724 to wait until it has poisoned its sub-DODAG and joined the DODAG 725 through another parent. The only way the DODAG Root can speed up 726 this process is by incrementing the DODAG version number, thus 727 triggering global recalculation of the DODAG. 729 Even in case the DTSN increment is carried to the "lost" target 730 router through another parent, the triggered DAO will need to go up 731 the DODAG to the DODAG Root via another route, which might itself be 732 broken. This would necessitate the use of local repair mechanisms, 733 potentially causing loops in the network (see Section 14) and 734 eventually global DODAG recalculation. 736 8. Address Aggregation and Summarization 738 As indicated in Section 7, in storing mode, a router is expected to 739 be able to store routing entries for all destinations in its "sub- 740 DODAG", i.e., routing entries for all destinations in the network 741 where the route to the DODAG Root includes that router. 743 In the Internet, no single router stores explicit routing entries for 744 all destinations. Rather, IP addresses are assigned hierarchically, 745 such that an IP address does not only uniquely identify a network 746 interface, but also its topological location in the network, as 747 illustrated in Figure 2. All addresses with the same prefix are 748 reachable by way of the same router - which can, therefore, advertise 749 only that prefix. Other routers need only record a single routing 750 entry for that prefix, knowing that as the IP packet reaches the 751 router advertising that prefix, more precise routing information is 752 available. 754 .---. 755 | | 756 '---' 757 | 758 | 759 (a) 760 | 761 |1.x.x.x/8 762 | 763 (b) 764 / \ 765 1.1.x.x/16/ \ 1.2.x.x/16 766 / \ 767 .---. .---. 768 | c | | d | 769 '---' '---' 771 Figure 2: Address Hierarchies 773 Any aggregated routes require the use of a prefix shorter than /64, 774 and subsequent hierarchical assignment of prefixes down to a /64 (as 775 any router itself provides a /64 subnet to any hosts connected to the 776 router). 778 Moreover, if the 6lowpan adaption layer [RFC4944] is used in the LLN, 779 route aggregation is not possible since the same /64 is applied 780 across the entire network. 782 8.1. Observations 784 In RPL, each router acquires a number of parents, as described in 785 Section 3, from among which it selects one as its preferred parent 786 and, thus, next-hop on the route to the DODAG Root. routers maintain 787 a parent set containing possibly more than a single parent so as to 788 be able to rapidly select an alternative preferred parent, should the 789 previously selected such become unavailable. Thus expected behavior 790 is for a router to be able to change its point of attachment towards 791 the DODAG Root. If IP addresses are assigned in a strictly 792 hierarchical fashion, and if scalability of the routing state 793 maintained in storing mode is based on this hierarchy, then this 794 entails that each time a router changes its preferred parent, it must 795 also change its own IP address - as well as cause routers in its 796 "sub-DODAG" to do the same. RPL does not specify signaling for 797 reconfiguring addresses in a sub-DODAG, while [RFC6550] specifically 798 allows for aggregation (e.g., in Section 18.2.6.: "[...] it is 799 recommended to delay the sending of DAO message to DAO parents in 800 order to maximize the chances to perform route aggregation"). 802 A slightly less strict hierarchy can be envisioned, where a router 803 can change its preferred parent without necessarily changing 804 addresses of itself and of its sub-DODAG, provided that its former 805 and new preferred parents both have the same preferred parent, and 806 have addresses hierarchically assigned from that - from the 807 "preferred grandparent". With reference to Figure 1, this could be e 808 changing its preferred parent from d to c, provided that both d and c 809 have b as preferred parent. Doing so would impose a restriction on 810 the parent-set selection, admitting only parents which have 811 themselves the same parent, losing redundancy in the network 812 connectivity. RPL does not specify rules for admitting only parents 813 with identical grand-parents into the parent set - although such is 814 not prohibited either, if the loss of redundancy is acceptable. 816 The DODAG Root incrementing the DODAG version number is the mechanism 817 by which RPL enables global reconfiguration of the network, 818 reconstructing the DODAG with (intended) more optimal routes. In 819 case of addressing hierarchies being enforced, so as to enable 820 aggregation, this will either restrict the ability for an optimal 821 DODAG construction, or will also have to trigger global address 822 autoconfiguration so as to ensure addressing hierarchies. 824 Finally, with IP addresses serving a dual role of an identifier of 825 both an end-point for communication and a topological location in the 826 network, changing the IP address of a device, so as to reflect a 827 change in network topology, also entails interrupting ongoing 828 communication to or through that device. Additional mechanisms 829 (e.g., a DNS-like system) mapping "communications identifiers" and 830 "IP addresses" are required. 832 9. Link Bidirectionality Verification 834 Parents (and the preferred parent) are selected based on receipt of 835 DIOs. This, alone, does not guarantee the ability of a router to 836 successfully communicate with the parent. However, the basic use of 837 links is for "upward" routes, i.e., for the router to use a parent 838 (the preferred parent) as relay towards the DODAG Root - in the 839 opposite direction of the one in which the DIO was received. 841 9.1. Observations 843 Unidirectional links are no rare occurrence, such as is known from 844 wireless multi-hop networks. Preliminary results from a test-bed of 845 AMI (Automated Metering Infrastructure) devices using 950MHz radio 846 interfaces, and with a total of 22 links, show that 36% of these 847 links are unidirectional. If a router receives a DIO on such a 848 unidirectional link, and selects the originator of the DIO as parent, 849 which would be a bad choice: unicast traffic in the upward direction 850 would be lost. If the router had verified the bidirectionality of 851 links, it might have selected a better parent, to which it has a 852 bidirectional link. 854 [RFC6550] discusses some mechanisms which can (if deemed needed) be 855 used to verify that a link is bidirectional before choosing a router 856 as a parent. While requiring one mechanism for bidirectional 857 verification to be used, the document does not specify which method 858 to be used, and how to be used. The mechanisms discussed include NUD 859 [RFC4861], BFD [RFC5881] and [RFC5184]. BFD is explicitly called out 860 as "often not desirable" as it uses a proactive approach (exchange of 861 periodic HELLO messages), which would "lead to excessive control 862 traffic". Furthermore, not all L2 protocols provide L2 863 acknowledgements; even less so for multicast packets - and so, not on 864 RPL DIOs, the multicast transmission of which is a requirement for 865 the Trickle timer flooding reduction to be effective (see 866 Section 3.1). This has as consequence that such L2 acknowledgements 867 can only be used to determine if a given link is bidirectional or 868 unidirectional once the router already has selected parents AND 869 actually has data traffic to forward by way of these parents - in 870 contradiction with RPL's stated design principle that require that 871 the reachability of a router be verified before choosing it as a 872 parent ([RFC6550], Section 1.1). Absent any mechanism specified by 873 RPL to verify the bidirectionality of links, routers thus have to 874 rely on NUD to choose their parent correctly (see Section 10). 876 10. Neighbor Unreachability Detection For Unidirectional Links 878 [RFC6550] suggests using Neighbor Unreachability Detection (NUD) 879 [RFC4861] to detect and recover from the situation of unidirectional 880 links between a router and its (preferred) parent(s). When, e.g., a 881 router tries (and fails) to actually use another router for 882 forwarding traffic, NUD is supposed engaged to detect and prompt 883 corrective action, e.g., by way of selecting an alternative preferred 884 parent. 886 NUD is based upon observing whether a data packet is making forward 887 progress towards the destination, either by way of indicators from 888 upper-layer protocols (such as TCP and, though not called out in 889 [RFC4861], also from lower-layer protocols such as Link Layer ACKs ) 890 or - failing that - by unicast probing by way of transmitting a 891 unicast Neighbor Solicitation message and expecting that a solicited 892 Neighbor Advertisement message be returned. 894 10.1. Observations 896 A router may receive, transiently, a DIO from a router, closer (in 897 terms of rank) to the DODAG Root than any other router from which a 898 DIO has been received. Some, especially wireless, link layers may 899 exhibit different transmission characteristics between multicast and 900 unicast transmissions (such is the case for some implementations of 901 IEEE 802.11b, where multicast/broadcast transmissions are sent at 902 much lower bit-rates than are unicast; IEEE 802.11b is, of course, 903 not suggested as a viable L2 for LLNs, but serves to illustrate that 904 such asymmetric designs exist), leading to a (multicast) DIO being 905 received from farther away than a unicast transmission can reach. 906 DIOs are sent (downward) using link-local multicast, whereas the 907 traffic flowing in the opposite direction (upward) is unicast. Thus, 908 a received (multicast) DIO may not be indicative of useful unicast 909 connectivity - yet, RPL might cause this router to select this 910 seemingly attractive router as its preferred parent. This may happen 911 both at initialization, or at any time during the LLN lifetime as RPL 912 allows attachment to a "better parent" over the network lifetime. 914 A DODAG so constructed may appear stable and converged until such 915 time that unicast traffic is to be sent and, thus, NUD invoked. 916 Detecting only at that point that unicast connectivity is not 917 maintained, and causing local (and possibly global) repairs exactly 918 at that time, may lead to traffic not being deliverable. As 919 indicated in Section 8, if scalability is dependent on addresses 920 being assigned hierarchically, changing point-of-attachment may 921 entail more than switching preferred parent. 923 A router may detect that its preferred parent is lost by way of NUD, 924 when trying to communicate to the DODAG Root. If that router has no 925 other parents in its parent set, all it can do is wait: RPL does not 926 provide other mechanisms for a router to react to such an event. In 927 the case where there is no downward traffic (i.e., no data or 928 acknowledgements are sent from the DODAG Root), neither the DODAG 929 Root nor the preferred parent, to which upward connectivity was lost, 930 will be able to detect and react to the event of connectivity loss. 932 In other words, for upward traffic, the routers that by way of NUD 933 detect connectivity loss, will be unable to act in order to restore 934 connectivity (e.g., by way of a signaling mechanism to the DODAG 935 Root, to request DODAG reconstruction by way of version number 936 increase). The routers, which could react (the "preferred parents") 937 will for upward traffic not generate any traffic "downward" allowing 938 NUD to engage and detect connectivity loss. 940 It is worth noting that RPL is optimized for upward traffic 941 (multipoint-to-point traffic). This is exactly the type of traffic 942 where NUD is not applicable as a mechanism for detecting and reacting 943 to connectivity loss. 945 Also, absent all routers consistently advertising their reachability 946 through DAO messages, a protocol requiring bidirectional flows 947 between the communicating devices, such as TCP or CoAP confirmable- 948 acknowledgement exchange, will be unable to operate. 950 Finally, upon having been notified by NUD that the "next hop" is 951 unreachable, a router must discard the preferred parent and select 952 another - hoping that this time, the preferred parent is actually 953 reachable. Also, if NUD indicates "no forward progress" based on an 954 upper-layer protocol, there is no guarantee that the problem stems 955 exclusively from the preferred parent being unreachable. Indeed, it 956 may be a problem further ahead, possibly outside the LLN, thus 957 changing preferred parent will not alleviate the situation. 958 Moreover, using information from an upper-layer protocol, e.g., to 959 return TCP ACKs back to the source, requires established downward 960 routes in the DODAG (i.e., each router needs to send DAO messages to 961 the DODAG Root, as described in Section 7). 963 Incidentally, this stems from a fundamental difference between "fixed 964 links in the Internet" and "wireless links": whereas the former, as a 965 rule, are reliable, predictable and with losses being rare 966 exceptions, the latter are characterized by frequent losses and 967 general unpredictability. 969 11. RPL Implementability and Complexity 971 RPL is designed to operate on "routers [...] with constraints on 972 processing power, memory, and energy (battery power)" [RFC6550]. 973 However, the 163 pages long specification of RPL, plus additional 974 specifications for routing headers [RFC6554], Trickle timer 975 [RFC6206], routing metrics [RFC6551] and objective function 976 [RFC6552], describes complex mechanisms (e.g., the upwards and 977 downward data traffic, a security solution, manageability of routers, 978 auxiliary functions for autoconfiguration of routers, etc.), and 979 provides no less than 9 message types, and 10 different message 980 options. 982 To give one example, the ContikiRPL implementation 983 (http://www.sics.se/contiki), which provides only storing mode and no 984 security features, consumes about 50 KByte of memory. Sensor 985 hardware, such as MSP430 sensor platforms, does not contain much more 986 memory than that, i.e., there may not be much space left to deploy 987 any application on the router. 989 11.1. Observations 991 Since RPL is intended as the routing protocol for LLNs, which covers 992 all the diverse applications requirements listed in [RFC5867], 993 [RFC5673], [RFC5826], [RFC5548], it is likely that (i) due to limited 994 memory capacity of the routers, and (ii) due to expensive development 995 cost of the routing protocol implementation, RPL implementations will 996 only support a partial set of features from the specification, 997 leading to non-interoperable implementations. 999 In order to accommodate the verbose exchange format, route stretching 1000 and source routing for point-to-point traffic, several additional 1001 Internet-Drafts are being discussed for adoption in the ROLL Working 1002 Group - adding complexity to an already complex specification which, 1003 it is worth recalling, was intended to be of a protocol for low- 1004 capacity devices. 1006 12. Underspecification 1008 While [RFC6550] provides various options and extensions in many 1009 parts, which makes a complex protocol, as described in Section 11, 1010 some mechanisms are underspecified. 1012 While for DIOs, the Trickle timer specifies a relatively efficient 1013 and easy-to-understand timing for message transmission, the timing of 1014 DAO transmission is not explicit. As each DAO may have a limited 1015 lifetime, one "best guess" for implementers would be to send DAO 1016 periodically, just before the life-time of the previous DAO expires. 1017 Since DAOs may be lost, another "best guess" would be to send several 1018 DAOs shortly one after the other in order to increase probability 1019 that at least one DAO is successfully received. 1021 The same underspecification applies for DAO-ACK messages: optionally, 1022 on reception of a DAO, a router may acknowledge successful reception 1023 by returning a DAO-ACK. Timing of DAO-ACK messages is unspecified by 1024 RPL. 1026 12.1. Observations 1028 By not specifying details about message transmission intervals and 1029 required actions when receiving DAO and DAO-ACKs, implementations may 1030 exhibit a bad performance if not carefully implemented. Some 1031 examples are: 1033 1. If DAO messages are not sent in due time before the previous DAO 1034 expires (or if the DAO is lost during transmission), the routing 1035 entry will expire before it is renewed, leading to a possible 1036 data traffic loss. 1038 2. RPL does not specify to use jitter [RFC5148] (i.e., small random 1039 delay for message transmissions). If DAOs are sent periodically, 1040 adjacent routers may transmit DAO messages at the same time, 1041 leading to link layer collisions. 1043 3. In non-storing mode, the "piece-wise calculation" of routes to a 1044 destination from which a DAO has been received, relies on 1045 previous reception of DAOs from intermediate routers along the 1046 route. If not all of these DAOs from intermediate routers have 1047 been received, route calculation is not possible, and DAO-ACKs or 1048 data traffic cannot be sent to that destination. 1050 Other examples of underspecification include detection of 1051 connectivity loss, as described in Section 10, as well as the local 1052 repair mechanism, which may lead to loops and thus data traffic loss, 1053 if not carefully implemented: a router discovering that all its 1054 parents are unreachable, may - according to the RPL specification - 1055 "detach" from the DODAG, i.e., increase its own rank to infinity. It 1056 may then "poison" its sub-DODAG by advertising its infinite rank in 1057 its DIOs. If, however, the router receives a DIO before it transmits 1058 the "poisoned" DIO, it may attach to its own sub-DODAG, creating a 1059 loop. If, instead, it had waited some time before processing DIOs 1060 again, chances are it would have succeeded in poisoning its sub-DODAG 1061 and thus avoided the loop. 1063 13. Protocol Convergence 1065 Trickle [RFC6206] is used by RPL to schedule transmission of DIO 1066 messages, with the objective of minimizing the amount of transmitted 1067 DIOs while ensuring a low convergence time of the network. The 1068 theoretical behavior of Trickle is well understood, and the 1069 convergence properties are well studied. Simulations of the 1070 mechanism, such as documented [trickle-multicast], confirm these 1071 theoretical studies. 1073 In real-world environments, however, varying link qualities may cause 1074 the algorithm to converge less well: frequent message losses entail 1075 resets of the Trickle timer and more frequent and unpredicted message 1076 emissions. 1078 13.1. Observations 1080 The varying link quality in real-world environments results in 1081 frequent changes of the best parent, which triggers a reset of the 1082 Trickle timer and thus the emission of DIOs. Therefore Trickle does 1083 not converge as well for links that are fluctuating in quality as in 1084 theory. 1086 This has been observed, e.g., in an experimental testbed: 69 routers 1087 (MSP430-based wireless sensor routers with IEEE 802.15.4, using 1088 [rpl-contiki] IPv6 stack and RPL without downward routes; the 1089 parameters of the Trickle timer were set to the implementation 1090 defaults (minimum DIO interval: 4 s, DIO interval doublings: 8, 1091 redundancy constant: 10) were positioned in a fixed grid topology. 1092 This resulted in DODAGs being constructed with an average of 2.45 1093 children per router and an average rank of 3.58. 1095 In this small test network, the number of DIO messages emitted - 1096 expectedly - spiked within the first ~10 seconds. Alas, rather than 1097 taper off to become zero (as the simulation studies would suggest), 1098 the DIO emission rate remained constant at about 70 DIOs per second. 1099 Details on this experiment can be found in [rpl-eval]. 1101 In another experimental testbed with 17 routers (Tmote Sky, Contiki 1102 platform [powertrace]), the authors also showed that the DIO emission 1103 continues with constant rate. Even with a relatively high data rate 1104 for sensor networks (every router sends 1 packet to the root per 1105 minute), the energy used for routing control packets is higher than 1106 the data traffic transmission. 1108 The resulting higher control overhead due to frequent DIO emission, 1109 leads to higher bandwidth and energy consumption as well as possibly 1110 to an increased number of collisions of frames, as observed in 1111 [trickle-multicast]. 1113 13.2. Caveat 1115 Note that these observations do not claim that it is impossible to 1116 parametrize Trickle timers so that a given deployment exhibits the 1117 theoretical characteristics (or, characetristics sufficiently close 1118 thereto) of the Trickle mechanism. These observations suggest that 1119 the default parameter values, provided for Trickle timers in 1120 [RFC6550], did not apply to the small network tested. These 1121 observations also suggest that special care is required when 1122 selecting the values for the parameters for Trickle timers. These 1123 values likely are to be determined experimentally, and individually 1124 for each deployment. 1126 14. Loops 1128 [RFC6550] states that it "guarantees neither loop free route 1129 selection nor tight delay convergence times, but can detect and 1130 repair a loop as soon as it is used. RPL uses this loop detection to 1131 ensure that packets make forward progress [...] and trigger repairs 1132 when necessary". This implies that a loop may only then be detected 1133 and fixed when data traffic is sent through the network. 1135 In order to trigger a local repair, RPL relies on the "direction" 1136 information (with values "up" or "down"), contained in an IPv6 hop- 1137 by-hop option header from received a data packet. If an "upward" 1138 data packet is received by a router, but the previous hop of the 1139 packet is listed with a lower rank in the neighbor set, the router 1140 concludes that there must be a routing loop and it may therefore 1141 trigger a local repair. For downward traffic in non-storing mode, 1142 the DODAG Root can detect loops if the same router identifier (i.e., 1143 IP address) appears at least twice in the route towards a 1144 destination. 1146 14.1. Observations 1148 The reason for RPL to repair loops only when detected by a data 1149 traffic transmission is to reduce control traffic overhead. However, 1150 there are two problems in repairing loops only when so triggered: (i) 1151 the triggered local repair mechanism delays forward progress of data 1152 packets, increasing end-to-end delays, and (ii) the data packet has 1153 to be buffered during repair. 1155 (i) may seem as the lesser of the two problems, since in a number of 1156 applications, such as data acquisition in smart metering 1157 applications, an increased delay may be acceptable. However, for 1158 applications such as alarm signals or in home automation (e.g., a 1159 light switch), increased delay may be undesirable. 1161 As for (ii), RPL is supposed to run on LLN routers with "constraints 1162 on [...] memory" [RFC6550]; buffering incoming packets during the 1163 route repair may not be possible for all incoming data packets, 1164 leading to dropped packets. Depending on the transport protocol, 1165 these data packets must be retransmitted by the source or are 1166 definitely lost. 1168 If carefully implemented with respect to avoiding loops before they 1169 occur, the impact of the loop detection in RPL may be minimized. 1170 However, it can be observed that with current implementations of RPL, 1171 such as the ContikiRPL implementation, loops do occur - and, 1172 frequently. During the same experiments described in Section 13, a 1173 snapshot of the DODAG was made every ten seconds. In 74.14% of the 1174 4114 snapshots, at least one loop was observed. Further 1175 investigation revealed that in all these cases the DODAG was 1176 partitioned. The loop occurred in the sub-DODAG that no longer had a 1177 connection to the DODAG Root. When the link to the only parent of a 1178 router breaks, the router may increase its rank and - when receiving 1179 a DIO from a router in its sub-DODAG - attach itself to its own sub- 1180 DODAG, thereby creating a loop - as detailed in Section 12.1. 1182 While it can be argued that the observed loops are harmless since 1183 they occur in a DODAG partition that has no connection to the DODAG 1184 Root, they show that the routes are not built correctly. Even worse, 1185 when the broken link re-appears, it is possible that in certain 1186 situations, the loop is only repaired when data traffic is sent, 1187 possibly leading to data loss (as described above). This can occur 1188 if the link to the previous parent is reestablished, but the rank of 1189 that previous parent has increased in the meantime. 1191 Another problem with the loop repair mechanism arises in non-storing 1192 mode when using only downward traffic: while the DODAG Root can 1193 easily detect loops (as described above), it has no direct means to 1194 trigger a local repair where the loop occurs. Indeed, it can only 1195 trigger a global repair by increasing the DODAG version number, 1196 leading to a Trickle timer reset and increased control traffic 1197 overhead in the network caused by DIO messages, and therefore a 1198 possible energy drain of the routers and congestion of the channel. 1200 Finally, loop detection for every data packet increases the 1201 processing overhead. RPL is targeted for deployments on very 1202 constrained devices with little CPU power, therefore a loop detection 1203 for every packet reduces available resources of the LLN router for 1204 other tasks (such as sensing). Moreover, each IPv6 packet needs to 1205 contain the "RPL Option for Carrying RPL Information in Data-Plane 1206 Datagrams" [RFC6553] in order to use loop detection (as well as 1207 determining the RPL instance), which in turn implies an extra IPv6 1208 header (and thus overhead) for IPv6-in-IPv6 tunneling. As this RPL 1209 option is a hop-by-hop option, it needs to be in an encapsulating 1210 IPv6-in-IPv6 tunnel and then regenerated at each hop. 1212 15. Security Considerations 1214 This document does currently not specify any security considerations. 1215 This document also does not provide any evaluation of the security 1216 mechanisms of RPL. 1218 16. IANA Considerations 1220 This document has no actions for IANA. 1222 17. Acknowledgements 1224 The authors would like to thank Matthias Philipp (INRIA) for his 1225 contributions to conducting many of the experiments, revealing or 1226 confirming the issues described in this document. 1228 Moreover, the authors would like to express their gratitude to Ralph 1229 Droms (Cisco) for his careful review of various versions of this 1230 document, for many long discussions, and for his considerable 1231 contributions to both the content and the quality of this document. 1233 18. Informative References 1235 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1236 (IPv6) Specification", RFC 2460, Decemer 1998. 1238 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1239 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1240 September 2007. 1242 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1243 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1244 Overview, Assumptions, Problem Statement, and Goals", 1245 RFC 4919, August 2007. 1247 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1248 "Transmission of IPv6 Packets over IEEE 802.15.4 1249 Networks", RFC 4944, September 2007. 1251 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 1252 Considerations in Mobile Ad Hoc Networks (MANETs)", 1253 RFC 5148, February 2008. 1255 [RFC5184] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1256 "Bidirectional Forwarding Detection (BFD) for IPv4 and 1257 IPv6 (Single Hop)", RFC 5184, June 2010. 1259 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1260 "Routing Requirements for Urban Low-Power and Lossy 1261 Networks", RFC 5548, May 2009. 1263 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1264 "Industrial Routing Requirements in Low-Power and Lossy 1265 Networks", RFC 5673, October 2009. 1267 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1268 Routing Requirements in Low-Power and Lossy Networks", 1269 RFC 5826, April 2010. 1271 [RFC5867] Martocci, J., Mi, P., Riou, N., and W. Vermeylen, 1272 "Building Automation Routing Requirements in Low Power and 1273 Lossy Networks", RFC 5867, June 2010. 1275 [RFC5881] Ward, D. and D. Katz, "Bidirectional Forwarding Detection 1276 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 1277 June 2010. 1279 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1280 "The Trickle Algorithm", RFC 6206, March 2011. 1282 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1283 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1284 September 2011. 1286 [RFC6550] Winther, T., Thubert, P., Hui, J., Vasseur, J., Brandt, 1287 A., Kelsey, R., Levis, P., Piester, K., Struik, R., and R. 1288 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1289 Lossy Networks", RFC 6550, March 2012. 1291 [RFC6551] Vasseur, J., Pister, K., Dejan, N., and D. Barthel, 1292 "Routing Metrics Used for Path Calculation in Low-Power 1293 and Lossy Networks", RFC 6551, March 2012. 1295 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 1296 Protocol for Low-Power and Lossy Networks (RPL)", 1297 RFC 6552, March 2012. 1299 [RFC6553] Hui, J. and J. Vasseur, "The Routing Protocol for Low- 1300 Power and Lossy Networks (RPL) Option for Carrying RPL 1301 Information in Data-Plane Datagrams", RFC 6553, 1302 March 2012. 1304 [RFC6554] Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 1305 Routing Header for Source Routes with the Routing Protocol 1306 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1307 March 2012. 1309 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1310 Lossy Networks", RFC 7102, January 2014. 1312 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1313 Application Protocol (CoAP)", RFC 7252, June 2014. 1315 [SEP2.0] Computer Society, IEEE., "P2030.5 IEEE Draft Standard for 1316 Smart Energy Profile 2.0 Application Protocol", 2014. 1318 [ZigBeeIP] 1319 Alliance, ZigBee., "ZigBee IP Specification", 1320 ZigBee Public Document 13-002r00, February 2013. 1322 [bidir] Clausen, T. and U. Herberg, "A Comparative Performance 1323 Study of the Routing Protocols LOAD and RPL with Bi- 1324 Directional Traffic in Low-power and Lossy Networks 1325 (LLN)", Proceedings of the Eighth ACM International 1326 Symposium on Performance Evaluation of Wireless Ad Hoc, 1327 Sensor, and Ubiquitous Networks (PE-WASUN), 2011. 1329 [g3-plc] TELECOMMUNICATION STANDARDIZATION SECTOR, ITU., "ITU-T 1330 G.9903 Narrowband orthogonal frequency division 1331 multiplexing power line communication transceivers for G3- 1332 PLC networks", Feburary 2014. 1334 [ieee802154] 1335 Computer Society, IEEE., "IEEE Standard for Information 1336 technology - Telecommunications and information exchange 1337 between systems -- Local and metropolitan area networks -- 1338 Specific requirements. Part 15.4: Wireless Medium Access 1339 Control (MAC) and Physical Layer (PHY) Specifications for 1340 Low-Rate Wireless Personal Area Networks (WPANs)", 1341 October 2003. 1343 [ieee802154g] 1344 Computer Society, IEEE., "IEEE Standard for Local and 1345 metropolitan area networks -- Part 15.4: Low-Rate Wireless 1346 Personal Area Networks (LR-WPANs) Amendment 3: Physical 1347 Layer (PHY) Specifications for LowData-Rate, Wireless, 1348 Smart Metering Utility Networks", April 2012. 1350 [powertrace] 1351 Dunkels, A., Eriksson, J., Finne, N., and N. Tsiftes, 1352 "Powertrace: Network-level Power Profiling for Low-power 1353 Wireless Networks", Technical Report SICS T2011:05. 1355 [roll-charter] 1356 "ROLL Charter", 1357 web http://datatracker.ietf.org/wg/roll/charter/, 1358 February 2012. 1360 [rpl-contiki] 1361 Tsiftes, N., Eriksson, J., and A. Dunkels, "Low-Power 1362 Wireless IPv6 Routing with ContikiRPL", 1363 Proceedings Proceedings of the 9th ACM/IEEE International 1364 Conference on Information Processing in Sensor Networks 1365 (ISPN), 2011. 1367 [rpl-eval] 1368 Clausen, T., Herberg, U., and M. Philipp, "A Critical 1369 Evaluation of the IPv6 Routing Protocol for Low Power and 1370 Lossy Networks (RPL)", Proceedings of the 5th IEEE 1371 International Conference on Wireless & Mobile Computing, 1372 Networking & Communication (WiMob), 2011. 1374 [rpl-eval-UCB] 1375 Ko, J., Dawson-Haggerty, S., Culler, D., and A. Terzis, 1376 "Evaluating the Performance of RPL and 6LoWPAN in TinyOS", 1377 Proceedings of the Workshop on Extending the Internet to 1378 Low power and Lossy Networks (IP+SN), 2011. 1380 [trickle-multicast] 1381 Clausen, T. and U. Herberg, "Study of Multipoint-to-Point 1382 and Broadcast Traffic Performance in the 'IPv6 Routing 1383 Protocol for Low Power and Lossy Networks' (RPL)", 1384 Journal of Ambient Intelligence and Humanized Computing, 1385 2011. 1387 Authors' Addresses 1389 Thomas Clausen 1390 Route de Saclay 1391 91128 Palaiseau Cedex, 1392 France 1394 Phone: +33 6 6058 9349 1395 Email: T.Clausen@computer.org 1396 URI: http://www.thomasclausen.org 1398 Axel Colin de Verdiere 1400 Phone: +33 6 1264 7119 1401 Email: axel@axelcdv.com 1402 URI: http://www.axelcdv.com/ 1403 Jiazi Yi 1404 Ecole Polytechnique 1405 Route de Saclay 1406 91128 Palaiseau Cedex, 1407 France 1409 Phone: +33 1 6933 4084 1410 Email: jiazi@jiaziyi.com 1411 URI: http://www.jiaziyi.com/ 1413 Ulrich Herberg 1415 Email: ulrich@herberg.name 1416 URI: http://www.herberg.name/ 1418 Yuichi Igarashi 1419 Hitachi, Ltd., Yokohama Research Laboratory 1421 Phone: +81 45 860 3083 1422 Email: yuichi.igarashi.hb@hitachi.com 1423 URI: http://www.hitachi.com/