idnits 2.17.1 draft-ietf-roll-home-routing-reqs-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 580. 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 (May 21, 2008) is 5809 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-culler-roll-routing-reqs- - is the name correct? Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 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 G. Porcu 4 Expires: November 2008 Telecom Italia 5 May 21, 2008 7 Home Automation Routing Requirement in Low Power and Lossy Networks 8 draft-ietf-roll-home-routing-reqs-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-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 November 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document presents home control and automation application 42 specific requirements for ROuting in Low power and Lossy networks 43 (ROLL). In a modern home, a high number of wireless devices are used 44 for a wide set of purposes. Examples include lighting control, 45 heating control, sensors, leak detectors, healthcare systems and 46 advanced remote controls. Because such devices only cover a limited 47 radio range, multi-hop routing is often required. The aim of this 48 document is to specify the routing requirements for networks 49 comprising such constrained devices in a home network environment. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [RFC2119]. 57 Table of Contents 59 1. Terminology....................................................3 60 2. Introduction...................................................3 61 3. Home automation applications...................................4 62 3.1. Turning off the house when leaving........................4 63 3.2. Energy conservation and optimizing energy consumption.....5 64 3.3. Moving a remote control around............................5 65 3.4. Adding a new lamp module to the system....................5 66 3.5. Controlling battery operated window shades................6 67 3.6. Remote video surveillance.................................6 68 3.7. Healthcare................................................6 69 3.7.1. At-home health reporting.............................7 70 3.7.2. At-home health monitoring............................7 71 3.7.3. Healthcare routing considerations....................8 72 3.8. Alarm systems.............................................8 73 3.9. Battery-powered devices...................................8 74 4. Unique requirements of home automation applications............9 75 4.1. Support of groupcast......................................9 76 4.2. Metric-based Routing......................................9 77 4.3. Support of Mobility......................................10 78 4.4. Support of periodical scanning...........................10 79 4.5. Scalability..............................................10 80 4.6. Convergence Time.........................................11 81 4.7. Manageability............................................11 82 5. Traffic pattern...............................................11 83 6. Open issues...................................................11 84 7. Security Considerations.......................................12 85 8. IANA Considerations...........................................12 86 9. Acknowledgments...............................................12 87 10. References...................................................12 88 10.1. Normative References....................................12 89 10.2. Informative References..................................12 90 Author's Addresses...............................................13 91 Intellectual Property Statement..................................13 92 Disclaimer of Validity...........................................13 94 1. Terminology 96 ROLL: 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 100 Internet, possibly via a customer premises local area 101 network (LAN). 103 LAN: Local Area Network. 105 PAN: Personal Area Network. 106 A geographically limited wireless network based on 107 e.g. 802.15.4 or Z-Wave radio. 109 Channel: RF frequency band used to transmit a modulated signal 110 carrying packets. 112 Downstream: Data direction traveling from a LAN to a PAN device. 114 Upstream: Data direction traveling from a PAN to a LAN device. 116 RF: Radio Frequency. 118 Sensor: A PAN device that measures data and/or detects an 119 event. 121 HA: Home Automation. 123 2. Introduction 125 This document presents the home control and automation application 126 specific requirements for Routing in Low power and Lossy Networks 127 (ROLL). In a modern home, a high number of wireless devices are used 128 for a wide set of purposes. Examples include lighting control 129 modules, heating control panels, light sensors, temperature sensors, 130 gas/water leak detectors, motion detectors, video surveillance, 131 healthcare systems and advanced remote controls. Basic home control 132 modules such as wall switches and plug-in modules may be turned into 133 an advanced home automation solution via the use of an IP-enabled 134 application responding to events generated by wall switches, motion 135 sensors, light sensors, rain sensors, and so on. 137 Because such devices only cover a limited radio range, multi-hop 138 routing is often required. These devices are usually highly 139 constrained in term of resources such as battery and memory and 140 operate in unstable environments. Persons moving around in a house, 141 opening or closing a door or starting a microwave oven affect the 142 reception of weak radio signals. Reflection and absorption may cause 143 a reliable radio link to turn unreliable for a period of time and 144 then being reusable again, thus the term "lossy". 146 Unlike other categories of PANs, the connected home area is very much 147 consumer-oriented. The implications on network nodes in this aspect, 148 is that devices are very cost sensitive, which leads to resource- 149 constrained environments having slow CPUs and small memory 150 footprints. At the same time, nodes have to be physically small which 151 puts a limit to the physical size of the battery; and thus, the 152 battery capacity. As a result, it is common for low-power sensor- 153 style nodes to shut down radio and CPU resources for most of the 154 time. Often, the radio uses the same power for listening as for 155 transmitting. 157 Section 3. describes a few typical use cases for home automation 158 applications. Section 4. discusses the routing requirements for 159 networks comprising such constrained devices in a home network 160 environment. These requirements may be overlapping requirements 161 derived from other application-specific requirements documents or as 162 listed in [I-D.culler-roll-routing-reqs]. 164 3. Home automation applications 166 Home automation applications represent a special segment of networked 167 wireless devices with its unique set of requirements. To facilitate 168 the requirements discussion in Section 4, this section lists a few 169 typical use cases of home automation applications. New applications 170 are being developed at a high pace and this section does not mean to 171 be exhaustive. Most home automation applications tend to be running 172 some kind of command/response protocol. The command may come from 173 several places. For instance a lamp may be turned on, not only be a 174 wall switch but also from a movement sensor. 176 3.1. Turning off the house when leaving 178 Using the direct analogy to an electronic car key, a house owner may 179 activate the "leaving home" function from an electronic house key, 180 mobile phone, etc. For the sake of visual impression, all lights 181 should turn off at the same time. At least, it should appear to 182 happen at the same time. A well-known problem in wireless home 183 automation is the "popcorn effect": Lamps are turned on one at a 184 time, at a rate so slow that it is clearly visible. Some existing 185 home automation solutions use a clever mix of a "subnet groupcast" 186 message with no acknowledgement and no forwarding before sending 187 acknowledged singlecast messages to each lighting device. 189 The controller forms the groups and decides which nodes should 190 receive "turn-off" or "turn-on" requests. 192 Thus, a solution is needed for addressing groups of nodes without 193 prior management of group membership in the receiving nodes. 195 3.2. Energy conservation and optimizing energy consumption 197 Parts of the world using air conditioning may let shades go down and 198 turn off the AC device when leaving home. Air conditioning may start 199 by timer or via motion sensor when the owner returns home. The owner 200 may even activate the air conditioning via cell phone before getting 201 home. 203 Geographical areas using central heating may turn off heating when 204 not at home and use a reduced temperature during night time. 206 The power grid may experience periods where more wind-generated power 207 is produced than is needed. Typically this may happen during night 208 hours. The washing machine and dish washer may just as well work 209 while power is cheap. The electric car should also charge its 210 batteries on cheap power. 212 Most of these applications are mains powered and may thus provide 213 reliable routing resources. 215 3.3. Moving a remote control around 217 A remote control is a typical example of a mobile device in a home 218 automation network. An advanced remote control may be used for 219 dimming the light in the dining room while eating and later on, 220 turning up the music while doing the dishes in the kitchen. Reaction 221 must appear to be instant (within a few hundred milliseconds) even 222 when the remote control has moved to a new location. The remote 223 control may be communicating to either a central home automation 224 controller or directly to the lamps and the media center. 226 3.4. Adding a new lamp module to the system 228 Small-size, low-cost modules may have no user interface except for a 229 single button. Thus, an automated inclusion process is needed for 230 controllers to find new modules. Inclusion covers the detection of 231 neighbors and assignment of a unique node ID. Inclusion should be 232 completed within a few seconds. 234 3.5. Controlling battery operated window shades 236 In consumer premises, window shades are often battery-powered as 237 there is no access to mains power over the windows. For battery 238 conservation purposes, the receiver is sleeping most of the time. A 239 home automation controller sending commands to window shades via ROLL 240 resources will have no problems delivering the packet to the router, 241 but the router will have to wait for some time before the command can 242 be delivered to the window shades; e.g. up to 250ms. 244 3.6. Remote video surveillance 246 Remote video surveillance is a fairly classic application for Home 247 networking providing the ability for the end user to get a video 248 stream from a Web Cam reached via the Internet, which can be 249 triggered by the end-user that has received an alarm from a movement 250 sensor or smoke detector - or the user simply wants to check the home 251 status via video. 252 Note that in the former case, more than likely, there will be a form 253 of inter-device communication: indeed, upon detecting some movement 254 in the home, the movement sensor may send a request to the light 255 controller to turn-on the lights, to the Web Cam to start a video 256 stream that would then be directed to the end user (cell phone, PDA) 257 via the Internet. 258 By contrast with other applications, e.g. industrial sensors where 259 data would mainly be originated by sensor to a sink and vice versa, 260 this scenario implicates a direct inter-device communication between 261 ROLL devices. 263 3.7. Healthcare 265 By adding communication capability to devices, patients and elderly 266 citizens may be able to do simple measurements at home. Thanks to 267 online devices, a doctor can keep an eye on the patient's health and 268 receive warnings if a new trend is discovered by automated filters. 270 Fine-grained daily measurements presented in proper ways may allow 271 the doctor to establish a more precise diagnosis. 273 Such applications may be realized as wearable products which 274 frequently do a measurement and automatically deliver the result to a 275 data sink locally or over the Internet. 277 Applications falling in this category are referred to as at-home 278 health reporting. Whether measurements are done in a fixed interval 279 or if they are manually activated, they leave all processing to the 280 receiving data sink. 282 A more active category of applications may send an alarm if some 283 alarm condition is triggered. This category of applications is 284 referred to as at-home health monitoring. Measurements are 285 interpreted in the device and may cause reporting of an event if an 286 alarm is triggered. 288 Many implementations may overlap both categories. 290 3.7.1. At-home health reporting 292 Applications might include: 294 o Temperature 296 o Weight 298 o Blood pressure 300 o Insulin level 302 Measurements may be stored for long term statistics. At the same 303 time, a critically high blood pressure may cause the generation of an 304 alarm report. Refer to 3.7.2. 306 To avoid a high number of request messages, nodes may be configured 307 to autonomously do a measurement and send a report in intervals. 309 3.7.2. At-home health monitoring 311 An alarm event may become active e.g. if the measured blood pressure 312 exceeds a threshold or if a person falls to the ground. 314 Applications might include: 316 o Temperature 318 o Weight 320 o Blood pressure 322 o Insulin level 323 o ECG 325 o Position tracker 327 3.7.3. Healthcare routing considerations 329 From a ROLL perspective, all the above-mentioned applications may run 330 on battery. They may also be portable and therefore need to locate a 331 new neighbor router on a frequent basis. 332 Not being powered most of the time, the nodes should not be used as 333 routing nodes. However, sleeping, battery-powered nodes may be 334 involved in routing. Examples include cases where a person falls 335 during a power blackout. In that case it may be that no mains-powered 336 routers are available for forwarding the alarm message to a (battery- 337 backed) internet gateway located out of direct range. 339 Delivery of measurement data has a more relaxed requirement for route 340 discovery time compared to a remote control. On the other hand, it is 341 critical that a "person fell" alarm is actually delivered in the end. 343 3.8. Alarm systems 345 A home security alarm system is comprised of various devices like 346 vibration detectors, fire or carbon monoxide detection system, door 347 or window contacts, glass-break detector, presence sensor, panic 348 button, home security key. 350 Some smoke alarms are battery powered and at the same time mounted in 351 a high place. Battery-powered safety devices should only be used for 352 routing if no other alternatives exist. A smoke alarm with a drained 353 battery does not provide a lot of safety. Also, it may be 354 inconvenient to exchange battery in a smoke alarm. Finally, routing 355 via battery-powered nodes may be very slow if they are sleeping most 356 of the time. 357 All of the above-mentioned reasons suggest that routing should be 358 avoided via this category of devices. 360 A plethora of applications could be developed for home alarm system: 361 most of them, most of the time, have prevention and monitoring 362 activity in which routing requirements are deterministic, but all of 363 them have an alarm state in which nodes may burst an aperiodic alarm. 365 3.9. Battery-powered devices 367 For convenience and low operational costs, power consumption of 368 consumer products must be kept at a very low level to achieve a long 369 battery lifetime. One implication of this fact is that RAM memory is 370 limited and it may even be powered down; leaving only a few 100 bytes 371 alive during the sleep phase. 373 4. Unique requirements of home automation applications 375 Home automation applications have a number of specific requirements 376 related to the set of home networking applications and the perceived 377 operation of the system. 379 4.1. Support of groupcast 381 The routing protocol must provide the ability to route a packet 382 towards a single device (unicast), a set of devices (also referred to 383 as "groupcast" in this document) or all devices (broadcast) in the 384 house. 386 The support of unicast, groupcast and broadcast also has an 387 implication on the addressing scheme and are outside the scope of 388 this document that focuses on the routing requirements aspects. 390 It MUST be to possible to address a group of receivers known by the 391 sender even if the receivers do not know that they have been grouped 392 by the sender. 394 Alternatively, a companion specification SHOULD define how to 395 indirectly address a group of nodes on the application layer via 396 classic broadcast in the network layer; e.g. by use of a bitmap in a 397 header extension. 399 4.2. Metric-based Routing 401 [ABR NOTE: IETF-71 WG meeting indicated that the term "constrained" 402 has a very specific meaning in the routing community inside IETF. 403 What I understood was that the draft should be using the term 404 "metric-based routing"] 406 Simple battery-powered nodes such as movement sensors on garage doors 407 and rain meters may not be able to assist in routing. Depending on 408 the node type, the node never listens at all, listens rarely or makes 409 contact on demand to a pre-configured target node. Attempting to 410 communicate to such nodes may require long time before getting a 411 response. 413 Other battery-powered nodes may have the capability to participate in 414 routing. The routing protocol should either share the load between 415 nodes to preserve battery or only route via mains-powered nodes if 416 possible. The most reliable routing resource may be a battery-backed, 417 mains-powered smoke alarm. 419 The routing protocol MUST support metric-based routing taking into 420 account node properties (CPU, memory, level of energy, sleep 421 intervals, safety/convenience of changing battery). 423 4.3. Support of Mobility 425 In a home environment, although the majority of devices are fixed 426 devices, there is still a variety of mobile devices: for example a 427 multi-purpose remote control is likely to move. Another example of 428 mobile devices is wearable healthcare devices. 430 While healthcare devices delivering measurement results can tolerate 431 route discovery times measured in seconds, a remote control appears 432 unresponsive if using more than 0.5 seconds to e.g. pause the music. 434 While, in theory, all battery-powered devices and mains-powered plug- 435 in modules may be moved, the predominant case is that the sending 436 node has moved while the rest of the network has not changed. 438 The routing protocol MUST provide mobility with convergence time 439 below 0.5 second if only the sender has moved. 441 The routing protocol SHOULD make use of the fact that if not being 442 able to deliver a packet, it is most likely that the sending node 443 moved; rather than the rest of the network. 445 4.4. Support of periodical scanning 447 The routing protocol MUST support the recognition of neighbors and 448 periodical scanning. This process SHOULD preserve energy capacity as 449 much as possible. 451 (Derived from use case 3.8. Alarm Systems) 453 4.5. Scalability 455 Looking at the number of wall switches, power outlets, sensors of 456 various nature, video equipment and so on in a modern house, it seems 457 quite realistic that hundreds of low power devices may form a home 458 automation network in a fully populated "smart" home. Moving towards 459 professional building automation, the number of such devices may be 460 in the order of several thousands. 462 Thus, the routing protocol MUST support 250 devices in a subnet. 463 The routing protocol SHOULD support 2500 devices in a subnet. 465 4.6. Convergence Time 467 A home automation PAN is subject to various instability due to signal 468 strength variation, moving persons and the like. Furthermore, as the 469 number of devices increases, the probability of a node failure also 470 increases. 472 Measured from the transmission of a packet, the following convergence 473 time requirements apply. 475 The routing protocol MUST converge within 0.5 second if no nodes have 476 moved. 478 The routing protocol MUST converge within 2 seconds if the 479 destination node of the packet has moved. 481 4.7. Manageability 483 The ability of the home network to support auto-configuration is of 484 the utmost importance. Indeed, most end users will not have the 485 expertise and the skills to perform advanced configuration and 486 troubleshooting. Thus the routing protocol designed for home PAN MUST 487 provide a set of features including 0 configuration of the routing 488 protocol for a new node to be added to the network. 490 Furthermore, a failing node MUST NOT have a global impact on the 491 routing protocol. The routing protocol SHOULD support the ability to 492 isolate a misbehaving node thus preserving the correct operation of 493 overall network. 495 5. Traffic pattern 497 Depending on the philosophy of the home network, wall switches may be 498 configured to directly control individual lamps or alternatively, all 499 wall switches send control commands to a central lighting control 500 computer which again sends out control commands to relevant devices. 502 In a distributed system, the traffic tends to be any-to-many. In a 503 centralized system, it is a mix of any-to-one and one-to-many. 505 6. Open issues 507 Other items to be addressed in further revisions of this document 508 include: 510 o Load Balancing (Symmetrical and Asymmetrical) 512 o Security 514 7. Security Considerations 516 TBD 518 8. IANA Considerations 520 This document includes no request to IANA. 522 9. Acknowledgments 524 This document was prepared using 2-Word-v2.0.template.dot. 526 10. References 528 10.1. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 10.2. Informative References 535 [I-D.culler-roll-routing-reqs] 536 Vasseur, J. and D. Culler, "Routing Requirements for Low 537 Power And Lossy Networks", 538 draft-culler-roll-routing-reqs-* (work in progress). 540 Author's Addresses 542 Anders Brandt 543 Zensys, Inc. 544 Emdrupvej 26 545 Copenhagen, DK-2100 546 Denmark 548 Email: abr@zen-sys.com 550 Giorgio Porcu 551 Telecom Italia 552 Piazza degli Affari, 2 553 20123 Milan 554 Italy 556 Email: giorgio.porcu@telecomitalia.it 558 Intellectual Property Statement 560 The IETF takes no position regarding the validity or scope of any 561 Intellectual Property Rights or other rights that might be claimed to 562 pertain to the implementation or use of the technology described in 563 this document or the extent to which any license under such rights 564 might or might not be available; nor does it represent that it has 565 made any independent effort to identify any such rights. Information 566 on the procedures with respect to rights in RFC documents can be 567 found in BCP 78 and BCP 79. 569 Copies of IPR disclosures made to the IETF Secretariat and any 570 assurances of licenses to be made available, or the result of an 571 attempt made to obtain a general license or permission for the use of 572 such proprietary rights by implementers or users of this 573 specification can be obtained from the IETF on-line IPR repository at 574 http://www.ietf.org/ipr. 576 The IETF invites any interested party to bring to its attention any 577 copyrights, patents or patent applications, or other proprietary 578 rights that may cover technology that may be required to implement 579 this standard. Please address the information to the IETF at 580 ietf-ipr@ietf.org. 582 Disclaimer of Validity 584 This document and the information contained herein are provided on an 585 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 586 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 587 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 588 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 589 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 590 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 592 Copyright Statement 594 Copyright (C) The IETF Trust (2008). 596 This document is subject to the rights, licenses and restrictions 597 contained in BCP 78, and except as set forth therein, the authors 598 retain all their rights. 600 Acknowledgment 602 Funding for the RFC Editor function is currently provided by the 603 Internet Society.