idnits 2.17.1 draft-brandt-roll-rpl-applicability-home-building-04.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 (May 13, 2013) is 3991 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MPL' is mentioned on line 402, but not defined == Missing Reference: 'IPHC' is mentioned on line 475, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Roll A. Brandt 3 Internet-Draft Sigma Designs 4 Intended status: Informational E. Baccelli 5 Expires: November 14, 2013 INRIA 6 R. Cragie 7 Gridmerge 8 P. van der Stok 9 Consultant 10 May 13, 2013 12 Applicability Statement: The use of the RPL protocol set in Home 13 Automation and Building Control 14 draft-brandt-roll-rpl-applicability-home-building-04 16 Abstract 18 The purpose of this document is to provide guidance in the selection 19 and use of RPL protocols to implement the features required in 20 building and home environments. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 14, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Overview of requirements . . . . . . . . . . . . . . . . 3 59 1.3. Out of scope requirements . . . . . . . . . . . . . . . . 3 60 2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Network Topologies . . . . . . . . . . . . . . . . . . . 4 62 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 5 63 2.2.1. Human user responsiveness . . . . . . . . . . . . . . 5 64 2.2.2. Source-sink (SS) communication paradigm . . . . . . . 6 65 2.2.3. Peer-to-peer (P2P) communication paradigm . . . . . . 6 66 2.2.4. Peer-to-multipeer (P2MP) communication paradigm . . . 6 67 2.2.5. RPL applicability per communication paradigm . . . . 7 68 2.3. Link layer applicability . . . . . . . . . . . . . . . . 7 69 3. Using RPL-P2P to meet requirements . . . . . . . . . . . . . 7 70 4. RPL Profile for RPL-P2P . . . . . . . . . . . . . . . . . . . 7 71 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 8 73 4.1.2. Non-Storing Mode . . . . . . . . . . . . . . . . . . 8 74 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 8 76 4.1.5. Objective Function . . . . . . . . . . . . . . . . . 9 77 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 9 78 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 9 79 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 9 81 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 9 82 4.2.1. Security functions provided by layer-2 . . . . . . . 10 83 4.2.2. 6LowPAN options assumed . . . . . . . . . . . . . . . 10 84 4.2.3. MLE and other things . . . . . . . . . . . . . . . . 10 85 4.3. Recommended Configuration Defaults and Ranges . . . . . . 10 86 5. Manageability Considerations . . . . . . . . . . . . . . . . 10 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 6.1. Security Considerations during initial deployment . . . . 10 89 6.2. Security Considerations during incremental deployment . . 10 90 7. Other related protocols . . . . . . . . . . . . . . . . . . . 11 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 96 11.2. Informative References . . . . . . . . . . . . . . . . . 12 98 Appendix A. RPL shortcomings in home and building deployments . 12 99 A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 13 100 A.1.1. Traffic concentration at the root . . . . . . . . . . 13 101 A.1.2. Excessive battery consumption in source nodes . . . . 13 102 A.2. Risk of delayed route repair . . . . . . . . . . . . . . 13 103 A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 106 1. Introduction 108 TODO: Adapt to new template 110 Home automation and building control application spaces share a 111 substantial number of properties. The purpose of this document is to 112 give guidance in the use of RPL-P2P to provide the features required 113 by the requirements documents "Home Automation Routing Requirements 114 in Low-Power and Lossy Networks" [RFC5826] and "Building Automation 115 Routing Requirements in Low-Power and Lossy Networks" [RFC5867]. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119. 123 1.2. Overview of requirements 125 Applicable requirements are described in [RFC5826] and [RFC5867]. 127 1.3. Out of scope requirements 129 The considered network diameter is limited to a max diameter of 10 130 hops and a typical diameter of 5 hops, which captures the most common 131 cases in home automation and building control networks. 133 This document does not consider the applicability of RPL-related 134 specifications for urban and industrial applications [RFC5548], 135 [RFC5673], which may exhibit significantly larger network diameters. 137 2. Deployment Scenario 139 Networking in buildings is essential to satisfy the energy saving 140 regulations. Comfort of buildings is adapted to the presence of 141 individuals. When no one is present, energy consumption can be 142 reduced. Cost is the main driving factor behind wireless networking 143 in buildings. Especially for retrofit, wireless connectivity saves 144 cabling costs. 146 A typical home automation network is less than 100 nodes. Large 147 building deployments may span 10,000 nodes but to ensure 148 uninterrupted service of light and air conditioning systems in 149 individual zones of the building, nodes are organized in subnetworks. 150 Each subnetwork in a building automation deployment typically 151 contains contains tens to hundreds of nodes. 153 The main purpose of the network is to provide control over light and 154 heating/cooling resources. User intervention may be enabled via wall 155 controllers combined with movement, light and temperature sensors to 156 enable automatic adjustment of window blinds, reduction of room 157 temperature, etc. 159 People expect immediate and reliable responses to their presence or 160 actions. A light not switching on after entry into a room leads to 161 confusion and a profound dissatisfaction with the light product. 163 The surveillance of the correct functioning is at least as important. 164 Devices communicate regularly their status and send alarm messages 165 announcing a dysfunction of equipment or network. 167 In building control the infrastructure of the building management 168 network can be shared with the security/access, the IP telephony, and 169 the fire/alarm networks. This approach has a strong impact on the 170 operation and cost of the network. 172 2.1. Network Topologies 174 The typical home automation network or building control subnetwork 175 can consist of a wired and one or more wireless subnetworks. 176 Especially in large buildings the wireless network is connected to an 177 IP backbone network where all infrastructure services are located, 178 such as DNS, automation servers, etc. The wireless subnetwork is a 179 mesh network with a border router located at a convenient place in 180 the home (building). 182 In a building control network there may be several redundant border 183 routers to each subnetwork. Subnetworks often overlap geographically 184 (and from a wireless perspective). Due to the two purposes of the 185 network, (i) direct control and (ii) surveillance, there may exist 186 two types of routing topologies in a given subnetwork (i) a tree- 187 shaped collection of routes spanning from a central building 188 controller via the border router, on to destination nodes in the 189 subnetwork, and/or (ii) a flat, un-directed collection of intra- 190 network routes between functionally related nodes in the subnetwork. 192 Nodes in Home and Building automation networks are typically 193 inexpensive devices with very low memory capacity, such as individual 194 wall switches. Only a few nodes (such as multi-purpose remote 195 controls) are more expensive devices, which can afford more memory 196 capacity. 198 2.2. Traffic Characteristics 200 Traffic may enter the network from a central controller or it may 201 originate from an intra-network node. The majority of traffic is 202 light-weight point-to-point control style; e.g. Put-Ack or Get- 203 Response. There are however exceptions. Bulk data transfer is used 204 for firmware update and logging. Multicast is used for service 205 discovery or to control groups of nodes, such as light fixtures. 206 Firmware updates enter the network while logs leave the network. 207 Often, there is a direct relation between a controlling sensor and 208 the controlled equipment. The bulk of senders and receivers are 209 separated by a distance that allows one-hop direct path 210 communication. A graph of the communication will show several fully 211 connected subsets of nodes. However, due to interference, multipath 212 fading, reflection and other transmission mechanisms, the one-hop 213 direct path may be temporally disconnected. For reliability 214 purposes, it is therefore essential that alternative n-hop 215 communication routes exist for quick error recovery. Looking over 216 time periods of a day, the networks are very lightly loaded. 217 However, bursts of traffic can be generated by the entry of several 218 persons simultaneously, the occurrence of a defect, and other 219 unforeseen events. Under those conditions, the timeliness must 220 nevertheless be maintained. Therefore, measures are necessary to 221 remove any unnecessary traffic. Short routes are preferred. Long 222 multi-hop routes via the edge router, should be avoided whenever 223 possible. Group communication is essential for lighting control. 224 For example, once the presence of a person is detected in a given 225 room, all involved lights in the room and no other lights should be 226 dimmed, or switched on/off. Several rooms may be covered by the same 227 wireless subnetwork. To reduce network load, it is advisable that 228 messages to the lights in a room are not distributed further in the 229 mesh than necessary on the basis of intended receivers. 231 2.2.1. Human user responsiveness 233 While air conditioning and other environmental-control applications 234 may accept certain response delays, alarm and light control 235 applications may be regarded as soft real-time systems. A slight 236 delay is acceptable, but the perceived quality of service degrades 237 significantly if response times exceed 250 msec. If the light does 238 not turn on at short notice, a user will activate the controls again, 239 causing a sequence of commands such as Light{on,off,on,off,..} or 240 Volume{up,up,up,up,up,...}. 242 The reactive discovery features of RPL-P2P ensures that commands are 243 normally delivered within the 250msec time window and when 244 connectivity needs to be restored, it is typically completed within 245 seconds. In most cases an alternative route will work. Thus, route 246 rediscovery is not even necessary. 248 2.2.2. Source-sink (SS) communication paradigm 250 Source-sink (SS) traffic is a common traffic type in home and 251 building networks. The traffic is generated by environmental sensors 252 which push periodic readings to a central server. The readings may 253 be used for pure logging, or more often, to adjust light, heating and 254 ventilation. Alarm sensors also generate SS style traffic. 256 With regards to message latency, most SS transmissions can tolerate 257 worst-case delays measured in tens of seconds. Alarm sensors, 258 however, represent an exception. 260 2.2.3. Peer-to-peer (P2P) communication paradigm 262 Peer-to-peer (P2P) traffic is a common traffic type in home networks. 263 Some building networks also rely on P2P traffic while others send all 264 control traffic to a local controller box for advanced scene and 265 group control; thus generating more SS and P2MP traffic. 267 P2P traffic is typically generated by remote controls and wall 268 controllers which push control messages directly to light or heat 269 sources. P2P traffic has a strong requirement for low latency since 270 P2P traffic often carries application messages that are invoked by 271 humans. As mentioned in Section 2.2.1 application messages should be 272 delivered within less than a second - even when a route repair is 273 needed before the message can be delivered. . 275 2.2.4. Peer-to-multipeer (P2MP) communication paradigm 277 Peer-to-multipeer (P2MP) traffic is common in home and building 278 networks. Often, a wall switch in a living room responds to user 279 activation by sending commands to a number of light sources 280 simultaneously. 282 Individual wall switches are typically inexpensive devices with 283 extremely low memory capacities. Multi-purpose remote controls for 284 use in a home environment typically have more memory but such devices 285 are asleep when there is no user activity. RPL-P2P reactive 286 discovery allows a node to wake up and find new routes within a few 287 seconds while memory constrained nodes only have to keep routes to 288 relevant targets. 290 2.2.5. RPL applicability per communication paradigm 292 TODO: align with new template 294 Describe here when we use RPL, RPL-P2P and MPL based on sections on 295 SS P2P, PMP, and N-cast. 297 2.3. Link layer applicability 299 This document applies to [IEEE802.15.4] and [G.9959] which are 300 adapted to IPv6 by the adaption layers [RFC4944] and [I-D.lowpanz]. 302 Due to the limited memory of a majority of devices (such as 303 individual light dimmers) RPL-P2P MUST be used with source routing in 304 non-storing mode. The abovementioned adaptation layers leverage on 305 the compression capabilities of [RFC6554] and [RFC6282]. Header 306 compression allows small IP packets to fit into a single layer 2 307 frame even when source routing is used. A network diameter limited 308 to 5 hops helps achieving this. 310 Packet drops are often experienced in the targeted environments. 311 ICMP, UDP and even TCP flows may benefit from link layer unicast 312 acknowledgments and retransmissions. Link layer unicast 313 acknowledgments MUST be enabled when [IEEE802.15.4] or [G.9959] is 314 used with RPL-P2P. 316 3. Using RPL-P2P to meet requirements 318 RPL-P2P SHOULD be used in home and building networks, as point-to- 319 point style traffic is substantial and route repair needs to be 320 completed within seconds. RPL- P2P provides a reactive mechanism for 321 quick, efficient and root- independent route discovery/repair. The 322 use of RPL-P2P furthermore allows data traffic to avoid having to go 323 through a central region around the root of the tree, and drastically 324 reduces path length [SOFT11] [INTEROP12]. These characteristics are 325 desirable in home and building automation networks because they 326 substantially decrease unnecessary network congestion around the 327 tree's root. 329 4. RPL Profile for RPL-P2P 331 RPL-P2P MUST be used in home and building networks. Non-storing mode 332 allows for constrained memory in repeaters when source routing is 333 used. Reactive discovery allows for low application response times 334 even when on-the-fly route repair is needed. 336 4.1. RPL Features 337 TODO: New subsection for prefix and address assignment 339 In one constrained deployment, the link layer master node handing out 340 the logical network identifier and unique node identifiers may be a 341 remote control which returns to sleep once new nodes have been added. 342 There may be no global routable prefixes at all. Likewise, there may 343 be no authoritative always-on root node since there is no border 344 router to host this function. 346 In another constrained deployment, there may be battery powered 347 sensors and wall controllers configured to contact other nodes in 348 response to events and then return to sleep. Such nodes may never 349 detect the announcement of new prefixes via multicast. 351 In each of the abovementioned constrained deployments, the link layer 352 master node SHOULD assume the role as authoritative root node, 353 transmitting singlecast RAs with a ULA prefix information option to 354 nodes during the inclusion process to prepare the nodes for a later 355 operational phase, where a border router is added. 357 A border router SHOULD be designed to be aware of sleeping nodes in 358 order to support the distribution of updated global prefixes to such 359 sleeping nodes. 361 One COULD implement gateway-centric tree-based routing and global 362 prefix distribution as defined by [RFC6550]. This would however only 363 work for always-on nodes. 365 4.1.1. RPL Instances 367 When operating P2P-RPL on a stand-alone basis, there is no 368 authoritative root node maintaining a permanent RPL DODAG. A node 369 MUST be able to join one RPL instance as an instance is created 370 during each P2P-RPL route discovery operation. A node MAY be 371 designed to join multiple RPL instances. 373 4.1.2. Non-Storing Mode 375 Non-storing mode MUST be used to cope with the extremely constrained 376 memory of a majority of nodes in the network (such as individual 377 light switches). 379 4.1.3. DAO Policy 381 TBD. 383 4.1.4. Path Metrics 384 TBD. 386 4.1.5. Objective Function 388 OF0 MUST be supported and is the RECOMMENDED OF to use. Other 389 Objective Functions MAY be used as well. 391 4.1.6. DODAG Repair 393 Since RPL-P2P only creates DODAGs on a temporary basis during route 394 repair, there is no need to repair DODAGs. 396 4.1.7. Multicast 398 Commercial light deployments may have a need for multicast beyond the 399 link-local scope. RPL and P2P-RPL do not provide any means for this 400 transmission mode natively. 402 Several mechanisms exist for achieving such functionality; [MPL] is 403 RECOMMENDED for home and building deployments. 405 [TODO/TBD: text on MPL repeater density] 407 4.1.8. Security 409 In order to support low-cost devices and devices running on battery, 410 the following RPL security parameter values SHOULD be used: 412 o T = '0': Do not use timestamp in the Counter Field. 414 o Algorithm = '0': Use CCM with AES-128 416 o KIM = '10': Use group key, Key Source present, Key Index present 418 o LVL = 0: Use MAC-32 420 4.1.9. P2P communications 422 RPL-P2P [RPL-P2P] MUST be used to accommodate P2P traffic, which is 423 typically substantial in home and building automation networks. 425 4.2. Layer 2 features 427 For deployments based on 429 [IEEE802.15.4] and [G.9959], security MUST be applied at layer 2 430 using the mechanisms provided by the relevant standards. Residential 431 light control can accept a lower security level than other contexts 432 (e.g. a nuclear research lab). Safety critical devices like 433 electronic door locks SHOULD employ additional higher-layer security 434 while light and heating devices may be sufficiently protected by a 435 single network key. The border router MAY enforce access policies to 436 limit access to the trusted LLN domain from the LAN. 438 4.2.1. Security functions provided by layer-2 440 TBD. 442 4.2.2. 6LowPAN options assumed 444 TBD. 446 4.2.3. MLE and other things 448 TBD. 450 4.3. Recommended Configuration Defaults and Ranges 452 TODO 454 5. Manageability Considerations 456 TODO 458 6. Security Considerations 460 TODO 462 6.1. Security Considerations during initial deployment 464 TODO: (This section explains how nodes get their initial trust 465 anchors, initial network keys. It explains if this happens at the 466 factory, in a deployment truck, if it is done in the field, perhaps 467 like http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ 468 papers/CullenJennings.pdf) 470 6.2. Security Considerations during incremental deployment 472 Replacing a failed node means re-assigning the short address of the 473 failed node to the new node added to the network. This again allows 474 a new node replacing a failed node to obtain the same IPv6 addresses 475 as per the lines of [IPHC]. 477 As it is recommended to base security on a shared group key, it is 478 possible to replace failed nodes. For specific details on how to 479 replace failed nodes; refer to the actual link layer documentation. 481 TODO / TBD: Special concerns for adding a new node? 483 7. Other related protocols 485 Application transport protocols may be CoAP over UDP or equivalents. 486 Typically, UDP is used for IP transport to keep down the application 487 response time and bandwidth overhead. 489 Several features required by [RFC5826], [RFC5867] challenge the P2P 490 paths provided by RPL. Appendix A reviews these challenges. In some 491 cases, a node may need to spontaneously initiate the discovery of a 492 path towards a desired destination that is neither the root of a DAG, 493 nor a destination originating DAO signaling. Furthermore, P2P paths 494 provided by RPL are not satisfactory in all cases because they 495 involve too many intermediate nodes before reaching the destination. 497 RPL-P2P [RPL-P2P] provides the features requested by [RFC5826] and 498 [RFC5867]. RPL-P2P uses a subset of the frame formats and features 499 defined for RPL [RFC6550] but may be combined with RPL frame flows in 500 advanced deployments. 502 8. IANA Considerations 504 9. Acknowledgements 506 This document reflects discussions and remarks from several 507 individuals including (in alphabetical order): Michael Richardson, 508 Mukul Goyal, Jerry Martocci, Charles Perkins, and Zach Shelby 510 10. References 512 11. References 514 11.1. Normative References 516 [RFC5826] , "Home Automation Routing Requirements in Low-Power and 517 Lossy Networks", . 519 [RFC5867] , "Building Automation Routing Requirements in Low-Power 520 and Lossy Networks", . 522 [RFC5673] , "Industrial Routing Requirements in Low-Power and Lossy 523 Networks", . 525 [RFC5548] , "Routing Requirements for Urban Low-Power and Lossy 526 Networks", . 528 [IEEE802.15.4] 529 , "IEEE 802.15.4 - Standard for Local and metropolitan 530 area networks -- Part 15.4: Low-Rate Wireless Personal 531 Area Networks", , . 533 [RFC4944] , "Transmission of IPv6 Packets over IEEE 802.15.4 534 Networks", . 536 [G.9959] , "ITU-T G.9959 Short range narrow-band digital 537 radiocommunication transceivers - PHY and MAC layer 538 specifications", , . 540 [I-D.lowpanz] 541 Brandt, A., "Transmission of IPv6 Packets over ITU-T 542 G.9959 Networks", , . 544 [RFC6282] Hui, J., Thubert, P., , , , "Compression Format for IPv6 545 Datagrams over IEEE 802.15.4-Based Networks", RFC6282 , 546 September 2011. 548 [RFC6554] Hui, J., Vasseur, JP., Culler, D., Manral, V., , "An IPv6 549 Routing Header for Source Routes with the Routing Protocol 550 for Low-Power and Lossy Networks (RPL)", RFC6554 , March 551 2012. 553 [RFC6550] , "RPL: IPv6 Routing Protocol for Low-Power and Lossy 554 Networks", . 556 [RPL-P2P] Goyal, M., Baccelli, E., Phillip, M., Brandt, A., and J. 557 Martocci, "Reactive Discovery of Point-to-Point Routes in 558 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl , 559 May 2012. 561 11.2. Informative References 563 [SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL 564 Routing Protocol for IPv6 Sensor Networks: Testbed 565 Experiments", Proceedings of the Conference on Software 566 Telecommunications and Computer Networks, Split, Croatia, 567 September 2011., September 2011. 569 [INTEROP12] 570 Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J. 571 Buron , "Report on P2P-RPL Interoperability Testing", 572 RR-7864 INRIA Research Report RR-7864, Janurary 2012. 574 Appendix A. RPL shortcomings in home and building deployments 575 This document reflects discussions and remarks from several 576 individuals including (in alphabetical order): Charles Perkins, Jerry 577 Martocci, Michael Richardson, Mukul Goyal and Zach Shelby. 579 A.1. Risk of undesired long P2P routes 581 The DAG, being a tree structure is formed from a root. If nodes 582 residing in different branches have a need for communicating 583 internally, DAG mechanisms provided in RPL [RFC6550] will propagate 584 traffic towards the root, potentially all the way to the root, and 585 down along another branch. In a typical example two nodes could 586 reach each other via just two router nodes but in unfortunate cases, 587 RPL may send traffic three hops up and three hops down again. This 588 leads to several undesired phenomena described in the following 589 sections 591 A.1.1. Traffic concentration at the root 593 If many P2P data flows have to move up towards the root to get down 594 again in another branch there is an increased risk of congestion the 595 nearer to the root of the DAG the data flows. Due to the broadcast 596 nature of RF systems any child node of the root is not just directing 597 RF power downwards its sub-tree but just as much upwards towards the 598 root; potentially jamming other MP2P traffic leaving the tree or 599 preventing the root of the DAG from sending P2MP traffic into the DAG 600 because the listen-before-talk link-layer protection kicks in. 602 A.1.2. Excessive battery consumption in source nodes 604 Battery-powered nodes originating P2P traffic depend on the route 605 length. Long routes cause source nodes to stay awake for longer 606 periods before returning to sleep. Thus, a longer route translates 607 proportionally (more or less) into higher battery consumption. 609 A.2. Risk of delayed route repair 611 The RPL DAG mechanism uses DIO and DAO messages to monitor the health 612 of the DAG. In rare occasions, changed radio conditions may render 613 routes unusable just after a destination node has returned a DAO 614 indicating that the destination is reachable. Given enough time, the 615 next Trickle timer-controlled DIODAO update will eventually repair 616 the broken routes. In a worst-case event this is however too late. 617 In an apparently stable DAG, Trickle-timer dynamics may reduce the 618 update rate to a few times every hour. If a user issues an actuator 619 command, e.g. light on in the time interval between the last DAO 620 message was issued the destination module and the time one of the 621 parents sends the next DIO, the destination cannot be reached. 622 Nothing in RPL kicks in to restore connectivity in a reactive 623 fashion. The consequence is a broken service in home and building 624 applications. 626 A.2.1. Broken service 628 Experience from the telecom industry shows that if the voice delay 629 exceeds 250ms users start getting confused, frustrated and/or 630 annoyed. In the same way, if the light does not turn on within the 631 same period of time, a home control user will activate the controls 632 again, causing a sequence of commands such as 633 Light{on,off,off,on,off,..} or Volume{up,up,up,up,up,...} Whether the 634 outcome is nothing or some unintended response this is unacceptable. 635 A controlling system must be able to restore connectivity to recover 636 from the error situation. Waiting for an unknown period of time is 637 not an option. While this issue was identified during the P2P 638 analysis it applies just as well to application scenarios where an IP 639 application outside the LLN controls actuators, lights, etc. 641 Authors' Addresses 643 Anders Brandt 644 Sigma Designs 646 Email: abr@sdesigns.dk 648 Emmanuel Baccelli 649 INRIA 651 Email: Emmanuel.Baccelli@inria.fr 653 Robert Cragie 654 Gridmerge 656 Email: robert.cragie@gridmerge.com 658 Peter van der Stok 659 Consultant 661 Email: consultancy@vanderstok.org