idnits 2.17.00 (12 Aug 2021) /tmp/idnits61629/draft-brandt-roll-rpl-applicability-home-building-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 16, 2010) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-roll-rpl has been published as RFC 6550 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: May 16, 2011 INRIA 6 R. Cragie 7 Gridmerge 8 November 16, 2010 10 Applicability Statement: The use of RPL in Building and Home 11 Environments 12 draft-brandt-roll-rpl-applicability-home-building-01 14 Abstract 16 The purpose of this document is to to provide guidance in the use of 17 RPL to provide the features required in building or home 18 environments, two application spaces which share a substantial number 19 of requirements. Note that this document refers to a specific 20 revision of the RPL draft, and thus, a new revision of the RPL draft 21 will likely necessitate a new revision of this document. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 8, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Risk of undesired long P2P routes . . . . . . . . . . . . . 3 60 2.1.1. Traffic concentration at the root . . . . . . . . . . . 4 61 2.1.2. Excessive battery consumption in source nodes . . . . . 4 62 2.2. Risk of delayed route repair . . . . . . . . . . . . . . . 4 63 2.2.1. Broken service . . . . . . . . . . . . . . . . . . . . 4 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 5. Informative References . . . . . . . . . . . . . . . . . . . . 5 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 The purpose of this document is to to provide guidance in the use of 73 RPL [RPL-15] to provide the features required both by [HOME-REQ] and 74 by [BUILDING-REQ] , as these two application spaces share a 75 substantial number of requirements. Note that this document refers 76 to a specific revision of the RPL draft, and thus, a new revision of 77 the RPL draft will likely necessitate a new revision of this 78 document. RPL provides multipoint-to-point (MP2P) paths from sensors 79 to a sink, along a DAG; an advanced tree structure for organising 80 network nodes in a loop-free topology with backup routes and 81 potential support for policy-based routing. The root of the DAG is 82 the sink, and sensors discover and maintain the DAG via the 83 dissemination of DIO signaling, initiated by the root. Conversely, 84 RPL provides point-to-multippoint (P2MP) paths from the root to nodes 85 along the same DAG. RPL also provide point-to-point (P2P) paths from 86 node to node, through the first ancestor along the DAG, that is 87 common to both source and destination nodes. Such paths are 88 discovered and maintained via DAO signaling, initiated by the 89 destination node. 91 2. Problem Statement 93 Several features required by [HOME-REQ] and by [BUILDING-REQ] 94 challenge the P2P paths provided by RPL [RPL-15]. This section 95 reviews these challenges. In some cases, a sensor may need to 96 spontaneously initiate the discovery and mainten of a path towards a 97 desired destination that is neither the root of a DAG, nor a 98 destination originating DAO signaling. This feature is absent from 99 the RPL for now. Furthermore, provided P2P paths are not 100 satisfactory in some cases because they involve too many intermediate 101 sensors before reaching destination, which may be an issue in terms 102 of energy or delay constraints. RPL does not provide a mechanism for 103 discovering and maintaining more efficient alternative P2P paths when 104 they are available. These deficiencies call for the specification, 105 within RPL, of complementary mechanisms which will help alleviate the 106 challenges described below. 108 2.1. Risk of undesired long P2P routes 110 The DAG, being a tree structure is formed from a root. If nodes 111 residing in different branches have a need for communicating 112 internally, DAG mechanisms provided in RPL [RPL-15] will propagate 113 traffic towards the root, potentially all the way to the root, and 114 down along another branch. In a typical example two nodes could 115 reach each other via just two router nodes but in unfortunate cases, 116 RPL [RPL-15] may send traffic three hops up and three hops down 117 again. This leads to several undesired phenomena described in the 118 following sections 120 2.1.1. Traffic concentration at the root 122 If many P2P data flows have to move up towards the root to get down 123 again in another branch there is an increased risk of congestion the 124 nearer to the root of the DAG the data flows. Due to the broadcast 125 nature of RF systems any child node of the root is not just directing 126 RF power downwards its subtree but just as much upwards towards the 127 root; potentially jamming other MP2P traffic leaving the tree or 128 preventing the root of the DAG from sending P2MP traffic into the DAG 129 because the listen-before-talk link-layer protection kicks in. 131 2.1.2. Excessive battery consumption in source nodes 133 Battery-powered nodes originating P2P traffic depend on the route 134 length. Long routes cause source nodes to stay awake for longer 135 periods before returning to sleep. Thus, a longer route translates 136 proportionally (more or less) into higher battery consumption. 138 2.2. Risk of delayed route repair 140 The RPL DAG mechanism uses DIO and DAO messages to monitor the health 141 of the DAG. In rare occasions, changed radio conditions may render 142 routes unusable just after a destination node has returned a DAO 143 indicating that the destination is reachable. Given enough time, the 144 next Trickle timer-controlled DIODAO update will eventually repair 145 the broken routes. In a worst-case event this is however too late. 146 In an apparently stable DAG, Trickle-timer dynamics may reduce the 147 update rate to a few times every hour. If a user issues an actuator 148 command, e.g. light on in the time interval between the last DAO 149 message was issued the destination module and the time one of the 150 parents sends the next DIO, the destination cannot be reached. 151 Nothing in RPL [RPL-15] kicks in to restore connectivity in a 152 reactive fashion. The consequence is a broken service in home and 153 building applications. 155 2.2.1. Broken service 157 Experience from the telecom industry shows that if the voice delay 158 exceeds 250ms users start getting confused, frustrated andor annoyed. 159 In the same way, if the light does not turn on within the same period 160 of time, a home control user will activate the controls again, 161 causing a sequence of commands such as Light{on,off,off,on,off,..} or 162 Volume{up,up,up,up,up,...} Whether the outcome is nothing or some 163 unintended response this is unacceptable. A controlling system must 164 be able to restore connectivity to recover from the error situation. 166 Waiting for an unknown period of time is not an option. While this 167 issue was identified during the P2P analysis it applies just as well 168 to application scenarios where an IP application outside the LLN 169 controls actuators, lights, etc. 171 3. IANA Considerations 173 This document has no actions for IANA. 175 4. Security Considerations 177 This document does not have to any security considerations. 179 5. Informative References 181 [HOME-REQ] 182 Brandt, A., Buron, J., and G. Porcu, "Home Automation 183 Routing Requirements in Low Power and Lossy Networks", 184 RFC5826. 186 [BUILDING-REQ] 187 Martocci, J., De Mil, P., Vermeylen, W., and N. Riou, 188 "Building Automation Routing Requirements in Low Power and 189 Lossy Networks", RFC5867. 191 [RPL-15] Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for 192 Low power and Lossy Networks", draft-ietf-roll-rpl-15 , 193 2010. 195 Appendix A. Acknowledgements 197 This document reflects discussions and remarks from several 198 individuals including (in alphabetical order): Mukul Goyal, Jerry 199 Martocci, Charles Perkins, and Zach Shelby. 201 Authors' Addresses 203 Anders Brandt 204 Sigma Designs 206 Email: abr@sdesigns.dk 207 Emmanuel Baccelli 208 INRIA 210 Email: Emmanuel.Baccelli@inria.fr 212 Robert Cragie 213 Gridmerge 215 Email: robert.cragie@gridmerge.com