idnits 2.17.1 draft-ietf-roll-home-routing-reqs-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 752. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 765. 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 (September 11, 2008) is 5699 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 G. Porcu 4 Expires: January 2009 Telecom Italia 5 September 11, 2008 7 Home Automation Routing Requirement in Low Power and Lossy 8 Networks 9 draft-ietf-roll-home-routing-reqs-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on March 11, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document presents home control and automation application 45 specific requirements for Routing Over Low power and Lossy 46 networks (ROLL). In a modern home, a high number of wireless 47 devices are used for a wide set of purposes. Examples include 48 actuators (relay, light dimmer, heating valve), sensors (wall 49 switch, water leak, blood pressure) and advanced controllers. 50 Because such devices only cover a limited radio range, routing is 51 often required. The aim of this document is to specify the routing 52 requirements for networks comprising such constrained devices in a 53 home control and automation environment. 55 Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 58 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 59 in this document are to be interpreted as described in RFC-2119 60 [RFC2119]. 62 Table of Contents 64 Terminology......................................................3 65 1. Introduction..................................................5 66 2. Home Automation Applications..................................6 67 2.1. Lighting Application In Action...........................6 68 2.2. Energy Conservation and Optimizing Energy Consumption....6 69 2.3. Moving a Remote Control Around...........................7 70 2.4. Adding A New Module To The System........................7 71 2.5. Controlling Battery Operated Window Shades...............8 72 2.6. Remote Video Surveillance................................8 73 2.7. Healthcare...............................................8 74 2.7.1. At-home Health Reporting............................9 75 2.7.2. At-home Health Monitoring...........................9 76 2.8. Alarm Systems............................................9 77 3. Unique Routing Requirements of Home Automation Applications..10 78 3.1. Support of Groupcast....................................11 79 3.2. Constraint-based Routing................................12 80 3.3. Support of Mobility.....................................12 81 3.4. Sleeping Nodes..........................................13 82 3.5. Healthcare Routing......................................13 83 3.6. Scalability.............................................13 84 3.7. Convergence Time........................................14 85 3.8. Manageability...........................................14 86 3.9. Stability...............................................14 87 4. Traffic Pattern..............................................14 88 5. Open Issues..................................................15 89 6. Security Considerations......................................15 90 7. IANA Considerations..........................................15 91 8. Acknowledgments..............................................15 92 9. References...................................................16 93 9.1. Normative References....................................16 94 9.2. Informative References..................................17 95 Disclaimer of Validity..........................................18 97 Terminology 99 ROLL: Routing Over Low-power and Lossy networks 100 A ROLL node may be classified as sensor, actuator 101 or controller. 103 Access Point: The access point is an infrastructure device that 104 connects a ROLL network to the Internet or some 105 backbone network. 107 Actuator: Network node which performs some physical action. 108 Dimmers and relays are examples of actuators. 110 If sufficiently powered, actuator nodes may 111 participate in routing network messages. 113 Channel: Radio frequency band used to carry network packets. 115 Controller: Network node that controls actuators. Control 116 decisions may be based on sensor readings, sensor 117 events, scheduled actions or incoming commands from 118 the Internet or other backbone networks. 119 If sufficiently powered, controller nodes may 120 participate in routing network messages. 122 Downstream: Data direction traveling from a Local Area Network 123 (LAN) to a Personal Area Network (PAN) device. 125 DR: Demand-Response 126 The mechanism of users adjusting their power 127 consumption in response to actual pricing of power. 129 DSM: Demand Side Management 130 Process allowing power utilities to enable and 131 disable loads in consumer premises. Where DR relies 132 on voluntary action from users, DSM may be based on 133 enrollment in a formal program. 135 LAN: Local Area Network. 137 PAN: Personal Area Network. 138 A geographically limited wireless network based on 139 e.g. 802.15.4 or Z-Wave radio. 141 PDA Personal Digital Assistant. A small, handheld 142 computer. 144 PLC Power Line Communication 146 RAM Random Access Memory 148 Sensor: Network node that measures data and/or detects an 149 event. 150 The sensor may generate a trap message to notify a 151 controller or directly activate an actuator. 152 If sufficiently powered, sensor nodes may 153 participate in routing network messages. 155 Upstream: Data direction traveling from a PAN to a LAN 156 device. 158 1. Introduction 160 This document presents home control and automation application 161 specific requirements for Routing Over Low power and Lossy 162 networks (ROLL). In a modern home, a high number of wireless 163 devices are used for a wide set of purposes. Examples include 164 actuators (relay, light dimmer, heating valve), sensors (wall 165 switch, water leak, blood pressure) and advanced controllers. 166 Basic home control modules such as wall switches and plug-in 167 modules may be turned into an advanced home automation solution 168 via the use of an IP-enabled application responding to events 169 generated by wall switches, motion sensors, light sensors, rain 170 sensors, and so on. 172 Network nodes may be sensors and actuators at the same time. An 173 example is a wall switch for replacement in existing buildings. 174 The push buttons may generate events for a controller node or for 175 activating other actuator nodes. At the same time, a built-in 176 relay may act as actuator for a controller or other remote 177 sensors. 179 Because ROLL nodes only cover a limited radio range, routing is 180 often required. These devices are usually highly constrained in 181 term of resources such as battery and memory and operate in 182 unstable environments. Persons moving around in a house, opening 183 or closing a door or starting a microwave oven affect the 184 reception of weak radio signals. Reflection and absorption may 185 cause a reliable radio link to turn unreliable for a period of 186 time and then being reusable again, thus the term "lossy". 188 Unlike other categories of PANs, the connected home area is very 189 much consumer-oriented. The implication on network nodes is that 190 devices are very cost sensitive, which leads to resource- 191 constrained environments having slow CPUs and small memory 192 footprints. At the same time, nodes have to be physically small 193 which puts a limit to the physical size of the battery; and thus, 194 the battery capacity. As a result, it is common for low-power 195 sensor-style nodes to shut down radio and CPU resources for most 196 of the time. The radio tends to use the same power for listening 197 as for transmitting 199 Section 2 describes a few typical use cases for home automation 200 applications. Section 3 discusses the routing requirements for 201 networks comprising such constrained devices in a home network 202 environment. These requirements may be overlapping requirements 203 derived from other application-specific routing requirements. A 204 full list of requirements documents may be found in the end of the 205 document. 207 2. Home Automation Applications 209 Home automation applications represent a special segment of 210 networked devices with its unique set of requirements. 211 Historically, such applications used wired networks or power line 212 communication (PLC), but wireless solutions have emerged; allowing 213 existing buildings to be upgraded more easily. 215 To facilitate the requirements discussion in Section 3, this 216 section lists a few typical use cases of home automation 217 applications. New applications are being developed at a high pace 218 and this section does not mean to be exhaustive. Most home 219 automation applications tend to be running some kind of 220 command/response protocol. The command may come from several 221 places. 223 2.1. Lighting Application In Action 225 A lamp may be turned on, not only by a wall switch but also by a 226 movement sensor. The wall switch module may itself be a push- 227 button sensor and an actuator at the same time. This will often be 228 the case when upgrading existing buildings as existing wiring is 229 not prepared for automation. 231 One event may cause many actuators to be activated at the same 232 time. 233 Using the direct analogy to an electronic car key, a house owner 234 may activate the "leaving home" function from an electronic house 235 key, mobile phone, etc. For the sake of visual impression, all 236 lights should turn off at the same time. At least, it should 237 appear to happen at the same time. A well-known problem in 238 wireless home automation is the "popcorn effect": Lamps are turned 239 on one at a time, at a rate so slow that it is clearly visible. 240 Some existing home automation solutions use a clever mix of a 241 "subnet groupcast" message in direct range with no acknowledgement 242 before sending acknowledged singlecast messages to each device. 244 The controller forms the group and decides which nodes should 245 receive a message. 247 2.2. Energy Conservation and Optimizing Energy Consumption 249 In order to save energy, air conditioning, central heating, window 250 shades etc. may be controlled by timers, motion sensors or 251 remotely via internet or cell. Central heating may also be set to 252 a reduced temperature during night time. 254 The power grid may experience periods where more wind-generated 255 power is produced than is needed. Typically this may happen during 256 night hours. 258 In periods where electricity demands exceed available supply, 259 appliances such as air conditioning, climate control systems, 260 washing machines etc. can be turned off to avoid overloading the 261 power grid. 262 This is known as Demand-Side Management (DSM). 263 Remote control of household appliances is well-suited for this 264 application. 266 The start/stop decision for the appliances can also be regulated 267 by dynamic power pricing information obtained from the electricity 268 utility companies. This method called Demand-Response (DR) works 269 by motivation of users via pricing, bonus points, etc. For 270 example, the washing machine and dish washer may just as well work 271 while power is cheap. The electric car should also charge its 272 batteries on cheap power. 274 In order to achieve effective electricity savings, the energy 275 monitoring application must guarantee that the power consumption 276 of the ROLL devices is much lower than that of the appliance 277 itself. 279 Most of these appliances are mains powered and are thus ideal for 280 providing reliable, always-on routing resources. Battery-powered 281 nodes, by comparison, are constrained routing resources and may 282 only provide reliable routing under some circumstances. 284 2.3. Moving a Remote Control Around 286 A remote control is a typical example of a mobile device in a home 287 automation network. An advanced remote control may be used for 288 dimming the light in the dining room while eating and later on, 289 turning up the music while doing the dishes in the kitchen. 290 Reaction must appear to be instant (within a few hundred 291 milliseconds) even when the remote control has moved to a new 292 location. The remote control may be communicating to either a 293 central home automation controller or directly to the lamps and 294 the media center. 296 2.4. Adding A New Module To The System 298 Small-size, low-cost modules may have no user interface except for 299 a single button. Thus, an automated inclusion process is needed 300 for controllers to find new modules. Inclusion covers the 301 detection of neighbors and assignment of a unique node ID. 302 Inclusion should be completed within a few seconds. 304 If assignment of unique addresses is performed by a central 305 controller, it must be possible to route the inclusion request 306 from the joining node to the central controller before the joining 307 node has been included in the network. 309 2.5. Controlling Battery Operated Window Shades 311 In consumer premises, window shades are often battery-powered as 312 there is no access to mains power over the windows. For battery 313 conservation purposes, such an actuator node is sleeping most of 314 the time. A controller sending commands to a sleeping actuator 315 node via ROLL devices will have no problems delivering the packet 316 to the nearest powered router, but that router may experience a 317 delay until the next wake-up time before the command can be 318 delivered. 320 2.6. Remote Video Surveillance 322 Remote video surveillance is a fairly classic application for Home 323 networking providing the ability for the end user to get a video 324 stream from a Web Cam reached via the Internet. The video stream 325 may be triggered by the end-user after receiving an alarm from a 326 sensor (movement or smoke detector) or the user simply wants to 327 check the home status via video. 328 Note that in the former case, more than likely, there will be a 329 form of inter-device communication: Upon detecting some movement 330 in the home, the movement sensor may send a request to the light 331 controller to turn on the lights, to the Web Cam to start a video 332 stream that would then be directed to the end user's cell phone or 333 Personal Digital Assistant (PDA) via the Internet. 334 In contrast to other applications, e.g. industrial sensors, where 335 data would mainly be originated by sensor to a sink and vice 336 versa, this scenario implicates a direct inter-device 337 communication between ROLL devices. 339 2.7. Healthcare 341 By adding communication capability to devices, patients and 342 elderly citizens may be able to do simple measurements at home. 343 Thanks to online devices, a doctor can keep an eye on the 344 patient's health and receive warnings if a new trend is discovered 345 by automated filters. 347 Fine-grained daily measurements presented in proper ways may allow 348 the doctor to establish a more precise diagnosis. 350 Such applications may be realized as wearable products which 351 frequently do a measurement and automatically deliver the result 352 to a data sink locally or over the Internet. 354 Applications falling in this category are referred to as at-home 355 health reporting. Whether measurements are done in a fixed 356 interval or if they are manually activated, they leave all 357 processing to the receiving data sink. 359 A more active category of applications may send an alarm if some 360 alarm condition is triggered. This category of applications is 361 referred to as at-home health monitoring. Measurements are 362 interpreted in the device and may cause reporting of an event if 363 an alarm is triggered. 365 Many implementations may overlap both categories. 367 2.7.1. At-home Health Reporting 369 Applications might include: 371 o Temperature 372 o Weight 373 o Blood pressure 374 o Insulin level 376 Measurements may be stored for long term statistics. At the same 377 time, a critically high blood pressure may cause the generation of 378 an alarm report. Refer to 2.7.2. 380 To avoid a high number of request messages, nodes may be 381 configured to autonomously do a measurement and send a report in 382 intervals. 384 2.7.2. At-home Health Monitoring 386 An alarm event may become active e.g. if the measured blood 387 pressure exceeds a threshold or if a person falls to the ground. 388 Alarm conditions must be reported with the highest priority and 389 timeliness. 391 Applications might include: 393 o Temperature 394 o Weight 395 o Blood pressure 396 o Insulin level 397 o Electrocardiogram (ECG) 398 o Position tracker 400 2.8. Alarm Systems 402 A home security alarm system is comprised of various sensors 403 (vibration, fire or carbon monoxide, door/window, glass-break, 404 presence, panic button, etc.). 406 Some smoke alarms are battery powered and at the same time mounted 407 in a high place. Battery-powered safety devices should only be 408 used for routing if no other alternatives exist to avoid draining 409 the battery. A smoke alarm with a drained battery does not provide 410 a lot of safety. Also, it may be inconvenient to exchange battery 411 in a smoke alarm. 413 Alarm system applications may have both a synchronous and an 414 asynchronous behavior; i.e. they may be periodically queried by a 415 central control application (e.g. for a periodical refreshment of 416 the network state), or send a message to the control application 417 on their own initiative. 419 When a node (or a group of nodes) identifies a risk situation 420 (e.g. intrusion, smoke, fire), it sends an alarm message to a 421 central controller that could autonomously forward it via Internet 422 or interact with other network nodes (e.g. try to obtain more 423 detailed information or ask other nodes close to the alarm event). 425 Finally, routing via battery-powered nodes may be very slow if the 426 nodes are sleeping most of the time (they could appear 427 unresponsive to the alarm detection). To ensure fast message 428 delivery and avoid battery drain, routing should be avoided via 429 sleeping devices. 431 3. Unique Routing Requirements of Home Automation Applications 433 Home automation applications have a number of specific routing 434 requirements related to the set of home networking applications 435 and the perceived operation of the system. 437 The relations of use cases to requirements are outlined in the 438 table below: 440 +------------------------------- +-----------------------------+ 441 | Use case | Requirement | 442 +------------------------------- +-----------------------------+ 443 |2.1. Lighting Application In |3.1. Support of Groupcast | 444 |Action |3.3. Support of Mobility | 445 | |3.6. Scalability | 446 +------------------------------- +-----------------------------+ 447 |2.2. Energy Conservation and |3.2. Constraint-based Routing| 448 |Optimizing Energy Consumption | | 449 +------------------------------- +-----------------------------+ 450 |2.3. Moving a Remote Control |3.3. Support of Mobility | 451 |Around |3.7. Convergence Time | 452 +------------------------------- +-----------------------------+ 453 |2.4. Adding A New Module To The |3.7. Convergence Time | 454 |System |3.8. Manageability | 455 +------------------------------- +-----------------------------+ 456 |2.5. Controlling Battery |3.4. Sleeping Nodes | 457 |Operated Window Shades | | 458 +------------------------------- +-----------------------------+ 459 |2.7. Healthcare |3.2. Constraint-based Routing| 460 | |3.3. Support of Mobility | 461 | |3.5. Healthcare Routing | 462 | |3.7. Convergence Time | 463 +------------------------------- +-----------------------------+ 464 |2.8. Alarm Systems |3.6. Scalability | 465 | |3.7. Convergence Time | 466 +------------------------------- +-----------------------------+ 468 3.1. Support of Groupcast 470 +----------------------------------------------------------+ 471 | Author's note: | 472 | The support of groupcast only has implication on the | 473 | addressing scheme and as such, it is outside the scope | 474 | of this document that focuses on routing requirements. | 475 | Nevertheless, it is an important parameter for the | 476 | definition of the ROLL layer interface towards various | 477 | layer two technologies for home control. | 478 | | 479 | Should a dedicated application-specific document be | 480 | created for such details? | 481 +----------------------------------------------------------+ 483 Groupcast, in the context of home automation, is defined as the 484 ability to simultaneously transmit a message to a group of 485 recipients without prior interaction with the group members (i.e. 486 group setup). A use-case for groupcast is given in Section 2.1. 488 Broadcast and groupcast in home automation MAY be used to achieve 489 simultaneous reaction from a group of nodes. 491 It SHOULD be to possible to address a group of receivers known by 492 the sender even if the receivers do not know that they have been 493 grouped by the sender. 495 3.2. Constraint-based Routing 497 For convenience and low operational costs, power consumption of 498 consumer products must be kept at a very low level to achieve a 499 long battery lifetime. One implication of this fact is that Random 500 Access Memory (RAM) is limited and it may even be powered down; 501 leaving only a few 100 bytes of RAM alive during the sleep phase. 503 The use of battery powered devices reduces installation costs and 504 does enable installation of devices even where main power lines 505 are not available. On the other hand, in order to be cost 506 effective and efficient, the devices have to maximize the sleep 507 phase with a duty cycle lower than 1%. 509 Some devices only wake up in response to an event, e.g. a push 510 button. 512 Simple battery-powered nodes such as movement sensors on garage 513 doors and rain sensors may not be able to assist in routing. 514 Depending on the node type, the node never listens at all, listens 515 rarely or makes contact on demand to a pre-configured target node. 516 Attempting to communicate to such nodes may at best require long 517 time before getting a response. 519 Other battery-powered nodes may have the capability to participate 520 in routing. The routing protocol SHOULD route via mains-powered 521 nodes if possible. 523 The routing protocol MUST support constraint-based routing taking 524 into account node properties (CPU, memory, level of energy, sleep 525 intervals, safety/convenience of changing battery). 527 3.3. Support of Mobility 529 In a home environment, although the majority of devices are fixed 530 devices, there is still a variety of mobile devices: for example a 531 multi-purpose remote control is likely to move. Another example of 532 mobile devices is wearable healthcare devices. 534 While healthcare devices delivering measurement results can 535 tolerate route discovery times measured in seconds, a remote 536 control appears unresponsive if using more than 0.5 seconds to 537 e.g. pause the music. 539 While, in theory, all battery-powered devices and mains-powered 540 plug-in modules may be moved, the predominant case is that the 541 sending node has moved while the rest of the network has not 542 changed. 544 The routing protocol MUST provide mobility with convergence time 545 below 0.5 second if only the sender has moved. 547 A non-responsive node can either be caused by 1) a failure in the 548 node, 2) a failed link on the path to the node or 3) a moved node. 549 In the first two cases, the node can be expected to reappear at 550 roughly the same location in the network, whereas it can return 551 anywhere in the network in the latter case. 553 3.4. Sleeping Nodes 555 Sleeping nodes may appear to be non-responsive. The routing 556 protocol MUST take into account the delivery time to a sleeping 557 target node. 559 The wake-up interval of a sleeping node MUST be less than one 560 second. 562 3.5. Healthcare Routing 564 Because most health care applications may run on battery, this 565 leads to specific requirements for the routing protocol. Most 566 health care applications may also be portable and therefore need 567 to locate a new neighbor router on a frequent basis. 568 Not being powered most of the time, the nodes should not be used 569 as routing nodes. However, battery-powered nodes may be involved 570 in routing. Examples include cases where a person falls during a 571 power blackout. In that case it may be that no mains-powered 572 routers are available for forwarding the alarm message to a 573 (battery-backed) internet gateway located out of direct range. 575 Delivery of measurement data has a more relaxed requirement for 576 route discovery time compared to a remote control. On the other 577 hand, it is critical that a "person fell" alarm is actually 578 delivered. 580 3.6. Scalability 582 Looking at the number of wall switches, power outlets, sensors of 583 various nature, video equipment and so on in a modern house, it 584 seems quite realistic that hundreds of low power devices may form 585 a home automation network in a fully populated "smart" home. 586 Moving towards professional building automation, the number of 587 such devices may be in the order of several thousands. 589 The routing protocol MUST support 250 devices in the network. 591 3.7. Convergence Time 593 A wireless home automation network is subject to various 594 instabilities due to signal strength variation, moving persons and 595 the like. Furthermore, as the number of devices increases, the 596 probability of a node failure also increases. 598 Measured from the transmission of a packet, the following 599 convergence time requirements apply. 601 The routing protocol MUST converge within 0.5 second if no nodes 602 have moved. 604 The routing protocol MUST converge within 2 seconds if the 605 destination node of the packet has moved. 607 In both cases, "converge" means "the originator node has received 608 a response from the destination node". 610 3.8. Manageability 612 The ability of the home network to support auto-configuration is 613 of the utmost importance. Indeed, most end users will not have the 614 expertise and the skills to perform advanced configuration and 615 troubleshooting. Thus the routing protocol designed for home 616 automation networks MUST provide a set of features including zero- 617 configuration of the routing protocol for a new node to be added 618 to the network. From a routing perspective, zero-configuration 619 means that a node can obtain an address and join the network on 620 its own, without human intervention. 622 3.9. Stability 624 The routing protocol MUST support the ability to isolate a 625 misbehaving node thus preserving the correct operation of the 626 overall network. 628 4. Traffic Pattern 630 Depending on the design philosophy of the home network, wall 631 switches may be configured to directly control individual lamps or 632 alternatively, all wall switches send control commands to a 633 central lighting control computer which again sends out control 634 commands to relevant devices. 636 In a distributed system, the traffic tends to be multipoint-to- 637 multipoint. In a centralized system, it is a mix of multipoint-to- 638 point and point-to-multipoint. 640 Wall switches only generate traffic when activated, which 641 typically happens from a one to tens of times per hour. 643 Remote controls have a similar transmit pattern to wall switches, 644 but are activated more frequently. 646 Temperature/air pressure/rain sensors send frames when queried by 647 the user or can be preconfigured to send measurements at fixed 648 intervals (typically minutes). Motion sensors typically send a 649 frame when motion is first detected and another frame when an idle 650 period with no movement has elapsed. The highest transmission 651 frequency depends on the idle period used in the sensor. 652 Sometimes, a timer will trigger a frame transmission when an 653 extended period without status change has elapsed. 655 All frames sent in the above examples are quite short, typically 656 less than 5 bytes of payload. Lost frames and interference from 657 other transmitters may lead to retransmissions. In all cases, 658 acknowledgment frames with a size of a few bytes are used. 660 5. Open Issues 662 Other items to be addressed in further revisions of this document 663 include: 665 o Load Balancing (Symmetrical and Asymmetrical) 666 o Groupcast definition in a separate document? (TBD) 667 o Use case: Home Control Installer Scenario 668 o Security 670 6. Security Considerations 672 Implementing security mechanisms in ROLL network devices may 673 degrade energy efficiency and increase cost. 675 The routing protocol chosen for ROLL MUST allow for low-power, 676 low-cost network devices with limited security needs. 678 Protection against unintentional inclusion in neighboring networks 679 MUST be provided. 681 7. IANA Considerations 683 This document includes no request to IANA. 685 8. Acknowledgments 687 J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler 688 and Massimo Maggiorotti are gratefully acknowledged for their 689 contributions to this document. 691 This document was prepared using 2-Word-v2.0.template.dot. 693 9. References 695 As an exception, this internet draft contains references to other 696 internet drafts. The reason is that the referenced internet drafts 697 are developed in parallel to this document. 699 When promoted to an RFC, the references MUST be updated to RFCs as 700 well or removed from the references section. 702 9.1. Normative References 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, March 1997. 707 draft-ietf-roll-indus-routing-reqs-01.txt 709 draft-ietf-roll-urban-routing-reqs-01.txt 711 draft-martocci-roll-commercial-routing-reqs-00.txt 713 draft-ietf-roll-protocols-survey-00.txt 715 9.2. Informative References 717 Author's Addresses 719 Anders Brandt 720 Zensys, Inc. 721 Emdrupvej 26 722 Copenhagen, DK-2100 723 Denmark 725 Email: abr@zen-sys.com 727 Jakob Buron 728 Zensys, Inc. 729 Emdrupvej 26 730 Copenhagen, DK-2100 731 Denmark 733 Email: jbu@zen-sys.com 735 Giorgio Porcu 736 Telecom Italia 737 Piazza degli Affari, 2 738 20123 Milan 739 Italy 741 Email: giorgio.porcu@guest.telecomitalia.it 743 Intellectual Property Statement 745 The IETF takes no position regarding the validity or scope of any 746 Intellectual Property Rights or other rights that might be claimed 747 to pertain to the implementation or use of the technology 748 described in this document or the extent to which any license 749 under such rights might or might not be available; nor does it 750 represent that it has made any independent effort to identify any 751 such rights. Information on the procedures with respect to rights 752 in RFC documents can be found in BCP 78 and BCP 79. 754 Copies of IPR disclosures made to the IETF Secretariat and any 755 assurances of licenses to be made available, or the result of an 756 attempt made to obtain a general license or permission for the use 757 of such proprietary rights by implementers or users of this 758 specification can be obtained from the IETF on-line IPR repository 759 at http://www.ietf.org/ipr. 761 The IETF invites any interested party to bring to its attention 762 any copyrights, patents or patent applications, or other 763 proprietary rights that may cover technology that may be required 764 to implement this standard. Please address the information to the 765 IETF at ietf-ipr@ietf.org. 767 Disclaimer of Validity 769 This document and the information contained herein are provided on 770 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 771 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 772 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 773 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 774 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 775 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 776 FOR A PARTICULAR PURPOSE. 778 Copyright Statement 780 Copyright (C) The IETF Trust (2008). 782 This document is subject to the rights, licenses and restrictions 783 contained in BCP 78, and except as set forth therein, the authors 784 retain all their rights. 786 Acknowledgment 788 Funding for the RFC Editor function is currently provided by the 789 Internet Society.