idnits 2.17.00 (12 Aug 2021) /tmp/idnits62819/draft-brandt-roll-rpl-applicability-home-building-03.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 (February 5, 2013) is 3391 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-roll-p2p-rpl has been published as RFC 6997 Summary: 0 errors (**), 0 flaws (~~), 2 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: August 9, 2013 INRIA 6 R. Cragie 7 Gridmerge 8 February 5, 2013 10 Applicability Statement: The use of RPL-P2P in Home and Building Control 11 draft-brandt-roll-rpl-applicability-home-building-03 13 Abstract 15 The purpose of this document is to provide guidance in the use of 16 RPL-P2P to implement the features required in building and home 17 environments. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 9, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 1.2. Overview of requirements . . . . . . . . . . . . . . . . . 4 56 1.3. Out of scope requirements . . . . . . . . . . . . . . . . 4 57 2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Network Topologies . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 5 60 2.2.1. Human user responsiveness . . . . . . . . . . . . . . 5 61 2.2.2. Source-sink (SS) communication paradigm . . . . . . . 6 62 2.2.3. Peer-to-peer (P2P) communication paradigm . . . . . . 6 63 2.2.4. Peer-to-multipeer (P2MP) communication paradigm . . . 6 64 2.3. Link layer applicability . . . . . . . . . . . . . . . . . 6 65 3. Using RPL-P2P to meet requirements . . . . . . . . . . . . . . 7 66 4. RPL Profile for RPL-P2P . . . . . . . . . . . . . . . . . . . 7 67 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 7 69 4.1.2. Non-Storing Mode . . . . . . . . . . . . . . . . . . . 7 70 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 8 72 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 8 73 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 8 77 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . . 8 78 4.2.1. Security functions provided by layer-2 . . . . . . . . 8 79 4.2.2. 6LowPAN options assumed . . . . . . . . . . . . . . . 9 80 4.2.3. MLE and other things . . . . . . . . . . . . . . . . . 9 81 4.3. Recommended Configuration Defaults and Ranges . . . . . . 9 82 5. Manageability Considerations . . . . . . . . . . . . . . . . . 9 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 6.1. Security Considerations during initial deployment . . . . 9 85 6.2. Security Considerations during incremental deployment . . 9 86 7. Other related protocols . . . . . . . . . . . . . . . . . . . 9 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 93 Appendix A. RPL shortcomings in home and building deployments . . 11 94 A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 11 95 A.1.1. Traffic concentration at the root . . . . . . . . . . 12 96 A.1.2. Excessive battery consumption in source nodes . . . . 12 97 A.2. Risk of delayed route repair . . . . . . . . . . . . . . . 12 98 A.2.1. Broken service . . . . . . . . . . . . . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 101 1. Introduction 103 Home automation and building control application spaces share a 104 substantial number of properties. The purpose of this document is to 105 give guidance in the use of RPL-P2P to provide the features required 106 by the requirements documents "Home Automation Routing Requirements 107 in Low-Power and Lossy Networks" [RFC5826] and "Building Automation 108 Routing Requirements in Low-Power and Lossy Networks" [RFC5867]. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119. 116 1.2. Overview of requirements 118 Applicable requirements are described in [RFC5826] and [RFC5867]. 120 1.3. Out of scope requirements 122 The considered network diameter is limited to a max diameter of 10 123 hops and a typical diameter of 5 hops, which captures the most common 124 cases in home automation and building control networks. 126 This document does not consider the applicability of RPL-related 127 specifications for urban and industrial applications [RFC5548], 128 [RFC5673], which may exhibit significantly larger network diameters. 130 2. Deployment Scenario 132 A typical home automation network is less than 100 nodes. Large 133 building deployments may span 10,000 nodes but to ensure 134 uninterrupted service of light and air conditioning systems in 135 individual zones of the building, nodes are organized in subnetworks. 136 Each subnetwork in a building automation deployment is typically less 137 than 200 nodes and rarely more than 500 nodes. 139 The main purpose of the network is to provide control over light and 140 heating/cooling resources. User intervention may be enabled via wall 141 controllers combined with movement, light and temperature sensors to 142 enable automatic adjustment of window blinds, reduction of room 143 temperature, etc. 145 Alarm systems are also important applications in home and building 146 networks. 148 2.1. Network Topologies 150 The typical home automation network or building control subnetwork is 151 a mesh network with a border router located at a convenient place in 152 the home. In a building control network there may be several 153 redundant border routers. The network often consists in a number of 154 overlapping wireless subnetworks. Two types of routing topologies 155 may exist in each subnetwork (i) a tree-shaped collection of routes 156 spanning from a central building controller via the border router, on 157 to destination nodes in the subnetwork, and/or (ii) a flat, un- 158 directed collection of intra-network routes between arbitrary nodes 159 in the subnetwork. 161 Nodes in Home and Building automation networks are typically 162 inexpensive devices with extremely low memory capacities, such as 163 individual wall switches. Only a few nodes (such as multi-purpose 164 remote controls for instance) are more expensive devices, which can 165 afford more memory capacity. 167 2.2. Traffic Characteristics 169 Traffic may enter the network from a central controller or it may 170 originate from an intra-network node, such as a wall switch. The 171 majority of traffic is light-weight point-to-point control style; 172 e.g. Put-Ack or Get-Response. There are however exceptions. Bulk 173 data transfer is used for firmware update and logging. Multicast is 174 used for service discovery or to control groups of nodes, such as 175 light fixtures. Firmware updates enter the network while logs leave 176 the network. 178 2.2.1. Human user responsiveness 180 While airconditioning and other environmental-control applications 181 may accept certain response delays, alarm and light control 182 applications may be regarded as soft real-time systems. A slight 183 delay is acceptable, but the perceived quality of service degrades 184 significantly if response times exceed 250 msec. If the light does 185 not turn on at short notice, a user will activate the controls again, 186 causing a sequence of commands such as Light{on,off,on,off,..} or 187 Volume{up,up,up,up,up,...}. 189 The reactive discovery features of RPL-P2P ensures that commands are 190 normally delivered within the 250msec time window and when 191 connectivity needs to be restored, it is typically completed within 192 seconds. 194 2.2.2. Source-sink (SS) communication paradigm 196 Source-sink (SS) traffic is a common traffic type in home and 197 building networks. The traffic is generated by environmental sensors 198 which push periodic readings to a central server. The readings may 199 be used for pure logging, or more often, to adjust light, heating and 200 ventilation. Alarm sensors also generate SS style traffic. 202 With regards to message latency, most SS transmissions can tolerate 203 worst-case delays measured in tens of seconds. Alarm sensors, 204 however, represent one exception. 206 2.2.3. Peer-to-peer (P2P) communication paradigm 208 Peer-to-peer (P2P) traffic is a common traffic type in home networks. 209 Some building networks also rely on P2P traffic while others send all 210 control traffic to a local controller box for advanced scene and 211 group control; thus generating more SS and P2MP traffic. 213 P2P traffic is typically generated by remote controls and wall 214 controllers which push control messages directly to light or heat 215 sources. P2P traffic has a strong requirement for low latency since 216 P2P traffic often carries application messages that are invoked by 217 humans. As mentioned in Section 2.2.1 application messages need to 218 be delivered within less than a second - even when a route repair is 219 needed before the message can be delivered. 221 2.2.4. Peer-to-multipeer (P2MP) communication paradigm 223 Peer-to-multipeer (P2MP) traffic is common in home and building 224 networks. Often, a wall switch in a living room responds to user 225 activation by sending commands to a number of light sources 226 simultaneously. 228 Individual wall switches are typically inexpensive devices with 229 extremely low memory capacities. Multi-purpose remote controls for 230 use in a home environment typically have more memory but such devices 231 are asleep when there is no user activity. RPL-P2P reactive 232 discovery allows a node to wake up and find new routes within a few 233 seconds while memory constrained nodes only have to keep routes to 234 relevant targets. 236 2.3. Link layer applicability 238 This document applies to [IEEE802.15.4] and [G.9959] which are 239 adapted to IPv6 by the adaption layers [RFC4944] and [I-D.lowpanz]. 241 Due to the limited memory of a majority of devices (such as 242 individual light-switches) RPL-P2P MUST be used with source routing 243 in non-storing mode. The abovementioned adaptation layers leverage 244 on the compression capabilities of [RFC6554] and [RFC6282]. Header 245 compression allows small IP packets to fit into a single layer 2 246 frame even when source routing is used. A network diameter limited 247 to 5 hops helps achieving this. 249 Packet drops are often experienced in the targeted environments. 250 ICMP, UDP and even TCP flows may benefit from link layer unicast 251 acknowledgments and retransmissions. Link layer unicast 252 acknowledgments MUST be enabled when [IEEE802.15.4] or [G.9959] is 253 used with RPL-P2P. 255 3. Using RPL-P2P to meet requirements 257 RPL-P2P MUST be used in home and building networks, as P2P traffic is 258 substantial and route repair must be completed within seconds. RPL- 259 P2P provides a reactive mechanism for quick, efficient and root- 260 independent route discovery/repair. The use of RPL-P2P furthermore 261 allows data traffic to avoid having to go through a central region 262 around the root of the tree, and drastically reduces path length 263 [SOFT11] [INTEROP12]. These characteristics are desirable in home 264 and building automation networks because they substantially decrease 265 unnecessary network congestion around the tree's root. 267 4. RPL Profile for RPL-P2P 269 RPL-P2P MUST be used in home and building networks. Non-storing mode 270 allows for constrained memory in repeaters when source routing is 271 used. Reactive discovery allows for low application response times 272 even when on-the-fly route repair is needed. 274 4.1. RPL Features 276 4.1.1. RPL Instances 278 TBD. 280 4.1.2. Non-Storing Mode 282 Non-storing mode MUST be used to cope with the extremely constrained 283 memory of a majority of nodes in the network (such as individual 284 light switches). 286 4.1.3. DAO Policy 288 TBD. 290 4.1.4. Path Metrics 292 TBD. 294 4.1.5. Objective Function 296 OF0 MUST be supported and is the RECOMMENDED OF to use. Other 297 Objective Functions MAY be used as well. 299 4.1.6. DODAG Repair 301 Since RPL-P2P only creates DODAGs on a temporary basis during route 302 repair, there is no need to repair DODAGs. 304 4.1.7. Multicast 306 TBD. 308 4.1.8. Security 310 TBD. 312 4.1.9. P2P communications 314 RPL-P2P [RPL-P2P] MUST be used to accomodate P2P traffic, which is 315 typically substantial in home and building automation networks. 317 4.2. Layer 2 features 319 Security MUST be applied at layer 2 for [IEEE802.15.4] and [G.9959]. 320 Residential light control can accept a lower security level than 321 other contexts (e.g. a nuclear research lab). Safety critical 322 devices like electronic door locks SHOULD employ additional higher- 323 layer security while light and heating devices may be sufficiently 324 protected by a single network key. The border router MAY enforce 325 access policies to limit access to the trusted LLN domain from the 326 LAN. 328 4.2.1. Security functions provided by layer-2 330 TBD. 332 4.2.2. 6LowPAN options assumed 334 TBD. 336 4.2.3. MLE and other things 338 TBD. 340 4.3. Recommended Configuration Defaults and Ranges 342 TODO 344 5. Manageability Considerations 346 TODO 348 6. Security Considerations 350 TODO 352 6.1. Security Considerations during initial deployment 354 TODO: (This section explains how nodes get their initial trust 355 anchors, initial network keys. It explains if this happens at the 356 factory, in a deployment truck, if it is done in the field, perhaps 357 like http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ 358 papers/CullenJennings.pdf) 360 6.2. Security Considerations during incremental deployment 362 TODO: (This section explains how that replaces a failed node takes on 363 the dead nodes' identity, or not. How are nodes retired. How are 364 nodes removed if they are compromised) 366 7. Other related protocols 368 Application transport protocols may be CoAP over UDP or equivalents. 369 Typically, UDP is used for IP transport to keep down the application 370 response time and bandwidth overhead. 372 Several features required by [RFC5826], [RFC5867] challenge the P2P 373 paths provided by RPL. Appendix A reviews these challenges. In some 374 cases, a node may need to spontaneously initiate the discovery of a 375 path towards a desired destination that is neither the root of a DAG, 376 nor a destination originating DAO signaling. Furthermore, P2P paths 377 provided by RPL are not satisfactory in all cases because they 378 involve too many intermediate nodes before reaching the destination. 380 RPL-P2P [RPL-P2P] provides the features requested by [RFC5826] and 381 [RFC5867]. RPL-P2P uses a subset of the frame formats and features 382 defined for RPL [RFC6550] but may be combined with RPL frame flows in 383 advanced deployments. 385 8. IANA Considerations 387 9. Acknowledgements 389 This document reflects discussions and remarks from several 390 individuals including (in alphabetical order): Michael Richardson, 391 Mukul Goyal, Jerry Martocci, Charles Perkins, and Zach Shelby 393 10. References 395 11. References 397 11.1. Normative References 399 [RFC5826] "Home Automation Routing Requirements in Low-Power and 400 Lossy Networks". 402 [RFC5867] "Building Automation Routing Requirements in Low-Power and 403 Lossy Networks". 405 [RFC5673] "Industrial Routing Requirements in Low-Power and Lossy 406 Networks". 408 [RFC5548] "Routing Requirements for Urban Low-Power and Lossy 409 Networks". 411 [IEEE802.15.4] 412 "IEEE 802.15.4 - Standard for Local and metropolitan area 413 networks -- Part 15.4: Low-Rate Wireless Personal Area 414 Networks", . 416 [RFC4944] "Transmission of IPv6 Packets over IEEE 802.15.4 417 Networks". 419 [G.9959] "ITU-T G.9959 Short range narrow-band digital 420 radiocommunication transceivers - PHY and MAC layer 421 specifications", . 423 [I-D.lowpanz] 424 Brandt, A., "Transmission of IPv6 Packets over ITU-T 425 G.9959 Networks", . 427 [RFC6282] Hui, J. and Thubert, P., "Compression Format for IPv6 428 Datagrams over IEEE 802.15.4-Based Networks", RFC6282 , 429 September 2011. 431 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and Manral, V., "An 432 IPv6 Routing Header for Source Routes with the Routing 433 Protocol for Low-Power and Lossy Networks (RPL)", 434 RFC6554 , March 2012. 436 [RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy 437 Networks". 439 [RPL-P2P] Goyal, M., Baccelli, E., Phillip, M., Brandt, A., and J. 440 Martocci, "Reactive Discovery of Point-to-Point Routes in 441 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl , 442 May 2012. 444 11.2. Informative References 446 [SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL 447 Routing Protocol for IPv6 Sensor Networks: Testbed 448 Experiments", Proceedings of the Conference on Software 449 Telecommunications and Computer Networks, Split, Croatia, 450 September 2011., September 2011. 452 [INTEROP12] 453 Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J. 454 Buron , "Report on P2P-RPL Interoperability Testing", RR- 455 7864 INRIA Research Report RR-7864, Janurary 2012. 457 Appendix A. RPL shortcomings in home and building deployments 459 This document reflects discussions and remarks from several 460 individuals including (in alphabetical order): Charles Perkins, Jerry 461 Martocci, Michael Richardson, Mukul Goyal and Zach Shelby. 463 A.1. Risk of undesired long P2P routes 465 The DAG, being a tree structure is formed from a root. If nodes 466 residing in different branches have a need for communicating 467 internally, DAG mechanisms provided in RPL [RFC6550] will propagate 468 traffic towards the root, potentially all the way to the root, and 469 down along another branch. In a typical example two nodes could 470 reach each other via just two router nodes but in unfortunate cases, 471 RPL may send traffic three hops up and three hops down again. This 472 leads to several undesired phenomena described in the following 473 sections 475 A.1.1. Traffic concentration at the root 477 If many P2P data flows have to move up towards the root to get down 478 again in another branch there is an increased risk of congestion the 479 nearer to the root of the DAG the data flows. Due to the broadcast 480 nature of RF systems any child node of the root is not just directing 481 RF power downwards its subtree but just as much upwards towards the 482 root; potentially jamming other MP2P traffic leaving the tree or 483 preventing the root of the DAG from sending P2MP traffic into the DAG 484 because the listen-before-talk link-layer protection kicks in. 486 A.1.2. Excessive battery consumption in source nodes 488 Battery-powered nodes originating P2P traffic depend on the route 489 length. Long routes cause source nodes to stay awake for longer 490 periods before returning to sleep. Thus, a longer route translates 491 proportionally (more or less) into higher battery consumption. 493 A.2. Risk of delayed route repair 495 The RPL DAG mechanism uses DIO and DAO messages to monitor the health 496 of the DAG. In rare occasions, changed radio conditions may render 497 routes unusable just after a destination node has returned a DAO 498 indicating that the destination is reachable. Given enough time, the 499 next Trickle timer-controlled DIODAO update will eventually repair 500 the broken routes. In a worst-case event this is however too late. 501 In an apparently stable DAG, Trickle-timer dynamics may reduce the 502 update rate to a few times every hour. If a user issues an actuator 503 command, e.g. light on in the time interval between the last DAO 504 message was issued the destination module and the time one of the 505 parents sends the next DIO, the destination cannot be reached. 506 Nothing in RPL kicks in to restore connectivity in a reactive 507 fashion. The consequence is a broken service in home and building 508 applications. 510 A.2.1. Broken service 512 Experience from the telecom industry shows that if the voice delay 513 exceeds 250ms users start getting confused, frustrated andor annoyed. 514 In the same way, if the light does not turn on within the same period 515 of time, a home control user will activate the controls again, 516 causing a sequence of commands such as Light{on,off,off,on,off,..} or 517 Volume{up,up,up,up,up,...} Whether the outcome is nothing or some 518 unintended response this is unacceptable. A controlling system must 519 be able to restore connectivity to recover from the error situation. 520 Waiting for an unknown period of time is not an option. While this 521 issue was identified during the P2P analysis it applies just as well 522 to application scenarios where an IP application outside the LLN 523 controls actuators, lights, etc. 525 Authors' Addresses 527 Anders Brandt 528 Sigma Designs 530 Email: abr@sdesigns.dk 532 Emmanuel Baccelli 533 INRIA 535 Email: Emmanuel.Baccelli@inria.fr 537 Robert Cragie 538 Gridmerge 540 Email: robert.cragie@gridmerge.com