idnits 2.17.1 draft-brandt-rl2n-home-routing-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 467. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2007) is 6002 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group A. Brandt 2 Internet-Draft Zensys, Inc. 3 Intended status: Informational JP. Vasseur 4 Expires: May 15, 2008 Cisco Systems, Inc 5 November 12, 2007 7 Home Automation Routing Requirement in Low Power and Lossy Networks 8 draft-brandt-rl2n-home-routing-reqs-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document presents the home control and automation application 42 specific requirements for Routing in Low power and Lossy Networks 43 (RL2N). In a modern home, a high number of wireless devices are used 44 for a wide set of purposes. Examples include lighting control 45 modules, heating control panels, light sensors, temperature sensors, 46 gas/water leak detector, motion detectors, video surveillance, 47 healthcare systems and advanced remote controls. Because such 48 devices only cover a limited radio range, multi-hop routing is often 49 required. Such devices are usually highly constrained in terms of 50 resources such as battery and memory and operate in unstable 51 environments. The aim of this document is to specify the routing 52 requirements for networks comprising such constrained devices in a 53 home network environment. 55 Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Home automation applications . . . . . . . . . . . . . . . . . 4 66 3.1. Turning off the house . . . . . . . . . . . . . . . . . . 4 67 3.2. Moving a remote control around . . . . . . . . . . . . . . 5 68 3.3. Adding a new lamp module to the system . . . . . . . . . . 5 69 3.4. Controlling battery operated window shades . . . . . . . . 5 70 3.5. Networked smoke alarm . . . . . . . . . . . . . . . . . . 5 71 3.6. Remote video surveillance . . . . . . . . . . . . . . . . 6 72 3.7. Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.8. Alarm systems . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Unique requirements of home automation applications . . . . . 6 75 4.1. Support of groupcast . . . . . . . . . . . . . . . . . . . 6 76 4.2. Node constrained Routing . . . . . . . . . . . . . . . . . 7 77 4.3. Support of Mobility . . . . . . . . . . . . . . . . . . . 7 78 4.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.5. Convergence Time . . . . . . . . . . . . . . . . . . . . . 8 80 4.6. Manageability . . . . . . . . . . . . . . . . . . . . . . 8 81 5. Traffic pattern . . . . . . . . . . . . . . . . . . . . . . . 8 82 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 90 Intellectual Property and Copyright Statements . . . . . . . . . . 11 92 1. Terminology 94 L2N: Low power and Lossy Network. 96 RL2N: Routing in Low power and Lossy Networks. 98 Access Point: The access point is an infrastructure device that 99 connects the low power and lossy network system to the Internet, 100 possibly via a customer premises local area network (LAN). 102 LAN: Local Area Network. 104 PAN: Personal Area Network. A geographically limited wireless 105 network based on e.g. 802.15.4 or Z-Wave radio. 107 Channel: RF frequency band used to transmit a modulated signal 108 carrying packets. 110 Downstream: Data direction traveling from the LAN to the PAN device. 112 Upstream: Data direction traveling from the PAN device to the LAN. 114 RF: Radio Frequency. 116 Sensor: A PAN device that measures data and/or detects an event. 118 HA: Home Automation. 120 2. Introduction 122 This document presents the home control and automation application 123 specific requirements for Routing in Low power and Lossy Networks 124 (RL2N). In a modern home, a high number of wireless devices are used 125 for a wide set of purposes. Examples include lighting control 126 modules, heating control panels, light sensors, temperature sensors, 127 gas/water leak detector, motion detectors, video surveillance, 128 healthcare systems and advanced remote controls. Basic home control 129 modules such as wall switches and plug-in modules may be turned into 130 an advanced home automation solution via the use of an IP-enabled 131 application responding to events generated by wall switches, motion 132 sensors, light sensors, rain sensors, and so on. 134 Because such devices only cover a limited radio range, multi-hop 135 routing is often required. These devices are usually highly 136 constrained in term of resources such as battery and memory and 137 operate in unstable environments. Persons moving around in a house, 138 opening or closing a door or starting a microwave oven affect 139 reception of weak radio signals. Reflection and absorption may cause 140 a reliable connection to turn unreliable for a period of time and 141 then being reusable again, thus the term "lossy". 143 Unlike other categories of RL2N, the connected home area is very much 144 consumer-oriented. The implications on network nodes in this aspect, 145 is that devices are very cost sensitive, which leads to resource- 146 constrained environments having slow CPUs and small memory 147 footprints. At the same time, nodes have to physically small which 148 puts a limit to the physical size of the battery; and thus, the 149 battery capacity. As a result, it is common for low-power sensor- 150 style nodes to shut down radio and CPU resources for most of the 151 time. Often, the radio uses almost just as much power for listening 152 as for transmitting. 154 Section 3 describes a few typical use cases for home automation 155 applications. Section 4 discusses the routing requirements for 156 networks comprising such constrained devices in a home network 157 environment. These requirements may be overlapping requirements 158 derived from other application-specific requirements documents or as 159 listed in [I-D.culler-rl2n-routing-reqs]. 161 3. Home automation applications 163 Home automation applications represent a special segment of networked 164 wireless devices with its unique set of requirements. To facilitate 165 the requirements discussion in Section 4, this section lists a few 166 typical use cases of home automation applications. New applications 167 are being developed at a high pace and this section does not mean to 168 be exhaustive. Most home automation applications tend to be running 169 some kind of command/response protocol. The command may come from 170 several places. For instance a lamp may be turned on, not only be a 171 wall switch but also from a movement sensor. 173 3.1. Turning off the house 175 Using the direct analogy to an electronic car key, a house owner may 176 activate the "leaving home" function from an electronic house key, 177 mobile phone, etc. For the sake of visual impression, all lights 178 should turn off at the same time. At least, it should appear to 179 happen at the same time. A well-known problem in wireless home 180 automation is the "popcorn effect": Lamps are turned on one at a 181 time, at a rate so slow that it is clearly visible. Obviously, this 182 mostly apply to very low bandwidth RF systems. Some existing home 183 automation solutions use a clever mix of a "subnet groupcast" message 184 with no acknowledgement and no forwarding before sending acknowledged 185 singlecast messages to each lighting device. Broadcast packets 186 cannot be used for this since some lights should stay on. The light 187 controller forms the groups and decides which light modules should 188 receive "turn-off" or "turn-on" requests. Thus, traditional IP 189 multicast cannot be used for such applications, since multicast 190 relies on the recivers to subscribe to multicasted streams. 192 3.2. Moving a remote control around 194 A remote control is a typical example of a mobile device in a home 195 automation network. An advanced remote control may be used for 196 dimming the light in the dining room while eating and later on, 197 turning up the music while doing the dishes in the kitchen. Reaction 198 must appear to be instant (within a few hundred milliseconds) even 199 when the remote control has moved to a new location. The remote 200 control may be communicating to either a central home automation 201 controller or directly to the lamps and the media center. The 202 routing protocol MUST support multiple paths. The routing protocol 203 MUST be able to locate a working path within 250ms, given that a 204 working path exists and it has been used before. 206 3.3. Adding a new lamp module to the system 208 Small-size, low-cost modules may have no user interface except for a 209 single button. Thus, an automated inclusion process is needed for 210 light controllers to find new modules. The routing protocol MUST 211 support re-discovery of neighbors when a new device is added to the 212 network. The routing protocol MAY scan for neighbors on a frequent 213 basis. This scanning process MUST NOT use significant network 214 bandwidth resources. 216 3.4. Controlling battery operated window shades 218 In consumer premises, window shades are often battery-powered as 219 there is no access to mains power over the windows. For battery 220 conservation purposes, the receiver is sleeping most of the time. A 221 home automation controller sending commands to window shades via RL2N 222 resources will have no problems delivering the packet to the router, 223 but the router will have to wait for some time before the command can 224 be delivered to the window shades; e.g. up to 250ms. 226 3.5. Networked smoke alarm 228 Many smoke alarms are battery powered and at the same time mounted in 229 a high place. Battery-powered safety devices should only be used for 230 routing if no other alternatives exist. A smoke alarm with a drained 231 battery does not provide a lot of safety. Also, it may be 232 inconvenient to exchange battery in a smoke alarm. Finally, routing 233 via battery-powered nodes may be very slow if they are sleeping most 234 of the time . 236 3.6. Remote video surveillance 238 Remote video surveillance is a fairly classic application for Home 239 networking providing the ability for the end user to get a video 240 stream from a Web Cam reached via the Internet, which can either be 241 triggered by the end-user that has received an alarm from a movement 242 sensor, smoke detector or that simply wants to check the home status 243 via video. Note that in the former case, more than likely, there 244 will be a form of inter-device communication: indeed, upon detecting 245 some movement in the home, the movement sensor may send a request to 246 the light controller to turn-on the lights, to the Web Cam to start a 247 video stream that would then be directed to the end user (cell phone, 248 PDA) via the Internet. By contrast with other application where for 249 example a large number of L2N devices such as industrial sensors 250 where the data would mainly be originated by sensor to a sink and 251 vice versa, in such scenario there is a direct inter-device 252 communication between L2N devices. 254 3.7. Healthcare 256 This section will be documented in further revision of this document. 258 3.8. Alarm systems 260 This section will be documented in further revision of this document. 262 4. Unique requirements of home automation applications 264 Home automation applications have a number of specific requirements 265 related to the set of home networking applications and the perceived 266 operation of the system. 268 4.1. Support of groupcast 270 Some home automation systems require low-level addressing of a group 271 of nodes in the same subnet without any prior creation of multicast 272 groups, simply carrying a list of recipients in the subnet. 274 The routing protocol MUST support multicast routing with various 275 scopes: local subnet, all devices. In other words, the routing 276 protocol MUST provide the ability to route a packet toward a single 277 device (unicast), a set of devices (also referred to as "groupcast" 278 in this document) or all devices (multicast) in the house. 280 The support of unicast, groupcast and multicast also has an 281 implication on the addressing scheme and are outside the scope of 282 this document that focusses on the routing requirements aspects. 284 Note: with IP Multicast, signalling mechanisms are used by a 285 receivers to join a group and the sender does not necessarily know 286 the receivers of the group. What is required is the ability to 287 address a group of receivers known by the sender even if the 288 receivers do not need to know that they have been grouped by the 289 sender (requesting each individual node to join a multicast group 290 would be very impractical). 292 4.2. Node constrained Routing 294 Simple battery-powered nodes such as movement sensors on garage doors 295 and rain meters may not be able to assist in routing. Depending on 296 the node type, the node never listens at all, listens rarely or makes 297 contact on demand to a pre-configured target node. Attempting to 298 communicate to such nodes may require long time before getting a 299 response. 301 Other battery-powered node may have the capability to participate to 302 the routing protocol but it may be preferable to choose a 303 (potentially longer) route via non battery powered devices or via 304 battery powered that have more energy. 306 The routing protocol MUST support constrained based routing taking 307 into account node properties (CPU, memory, level of energy, sleep 308 intervals, safety/convenience of changing battery). 310 4.3. Support of Mobility 312 In a home environment, although the majority of devices are fixed 313 devices, there is still a variety of mobile devices: for example a 314 multi-purpose remote control is likely to move. Another example of 315 mobile devices is wearable healthcare devices. 317 The routing protocol MUST provide mobility with convergence time 318 within a few hundred milli-seconds. 320 4.4. Scalability 322 Looking at the number of wall switches, power outlets, sensor of 323 various nature, video equipment and so on in a modern house, it seems 324 quite realistic that hundreds of low power devices may form a home 325 automation network in a fully populated "smart" home. Moving towards 326 professional building automation, the number of such devices may be 327 in the order of several thousands. 329 Thus the routing protocol MUST be highly scalable supporting a large 330 number of devices (at least a few hundreds of devices). 332 4.5. Convergence Time 334 Home automation is clearly an L2N subject to various instability due 335 to signal strength variation. Furthermore, as the number of (battery 336 powered) devices increases, the probability of node failures also 337 increases. In all cases, response time of the order of a few 338 hundreds of milliseconds are required, implying that the routing 339 protocol MUST converge (provide alternate routes upon link or node 340 failure) within a few hundreds of milliseconds. 342 4.6. Manageability 344 The ability of the home network to support auto-configuration is of 345 the utmost importance. Indeed, most end users will not have the 346 expertise and the skills to perform advanced configuration and 347 troubleshooting. Thus the routing protocol designed for home L2N 348 MUST provide a set of features including 0 configuration of the 349 routing protocol for a new node to be added to the network. 351 Furthermore, a misbehaving node MUST NOT have a global impact on the 352 routing protocol. The routing protocol SHOULD support the ability to 353 isolate a misbehaving node thus preserving the correct operation of 354 overall network. 356 5. Traffic pattern 358 Depending on the philosophy of the home network, wall switches may be 359 configured to directly control individual lamps or alternatively, all 360 wall switches send control commands to a central lighting control 361 computer which again sends out control commands to relevant light 362 devices. In a distributed system, the traffic tends to be any-to- 363 many. In a centralized system, it is a mix of any-to-one and one-to- 364 many. 366 A centralized system may benefit from a tree topology routing 367 strategy; having the central light controller close to the root. 369 A tree topology may prove inefficient for nodes in a distributed 370 system. A direct path from sender to receiver may be significantly 371 shorter than a path following the tree. A shorter path means lower 372 latency and less air-time use in a wireless media. Thus, routers 373 MUST provide efficient any-to-many routing and MUST also support any- 374 to-any routing without having to transit via a central point (e.g. 375 tree root) which would unavoidably lead to sub-optimal path in term 376 of latency and energy consumption. 378 6. Open issues 380 Other items to be addressed in further revisions of this document 381 include: 383 * Load Balancing (Symmetrical and Asymmetrical), 385 * Security. 387 7. IANA Considerations 389 This document includes no request to IANA. 391 8. Security Considerations 393 TBD 395 9. Acknowledgements 397 10. References 399 10.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 10.2. Informative References 406 [I-D.culler-rl2n-routing-reqs] 407 Vasseur, J. and D. Cullerot, "Routing Requirements for Low 408 Power And Lossy Networks", 409 draft-culler-rl2n-routing-reqs-01 (work in progress), 410 July 2007. 412 Authors' Addresses 414 A Brandt 415 Zensys, Inc. 416 Emdrupvej 26 417 Copenhagen, Denmark DK-2100 419 Email: abr@zen-sys.com 421 JP Vasseur 422 Cisco Systems, Inc 423 1414 Massachusetts Avenue 424 Boxborough, MA 01719 425 USA 427 Email: jpv@cisco.com 429 Full Copyright Statement 431 Copyright (C) The IETF Trust (2007). 433 This document is subject to the rights, licenses and restrictions 434 contained in BCP 78, and except as set forth therein, the authors 435 retain all their rights. 437 This document and the information contained herein are provided on an 438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 440 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 441 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 442 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Intellectual Property 447 The IETF takes no position regarding the validity or scope of any 448 Intellectual Property Rights or other rights that might be claimed to 449 pertain to the implementation or use of the technology described in 450 this document or the extent to which any license under such rights 451 might or might not be available; nor does it represent that it has 452 made any independent effort to identify any such rights. Information 453 on the procedures with respect to rights in RFC documents can be 454 found in BCP 78 and BCP 79. 456 Copies of IPR disclosures made to the IETF Secretariat and any 457 assurances of licenses to be made available, or the result of an 458 attempt made to obtain a general license or permission for the use of 459 such proprietary rights by implementers or users of this 460 specification can be obtained from the IETF on-line IPR repository at 461 http://www.ietf.org/ipr. 463 The IETF invites any interested party to bring to its attention any 464 copyrights, patents or patent applications, or other proprietary 465 rights that may cover technology that may be required to implement 466 this standard. Please address the information to the IETF at 467 ietf-ipr@ietf.org. 469 Acknowledgment 471 Funding for the RFC Editor function is provided by the IETF 472 Administrative Support Activity (IASA).