idnits 2.17.1 draft-ietf-roll-home-routing-reqs-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 30, 2009) is 5232 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.Vasseur-Terminology' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'I-D.Pister-Industial-reqs' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'I-D.Levis-Protocols-survey' is defined on line 809, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group A. Brandt 2 Internet Draft Sigma Designs, Inc. 3 Intended status: Informational J. Buron 4 Expires: May 2010 Sigma Designs, Inc. 5 G. Porcu 6 Telecom Italia 7 November 30, 2009 9 Home Automation Routing Requirements in Low Power and Lossy 10 Networks 11 draft-ietf-roll-home-routing-reqs-09 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 30, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license- 45 info). 46 Please review these documents carefully, as they describe your 47 rights and restrictions with respect to this document. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) 55 controlling the copyright in such materials, this document may not 56 be modified outside the IETF Standards Process, and derivative 57 works of it may not be created outside the IETF Standards Process, 58 except to format it for publication as an RFC or to translate it 59 into languages other than English. 61 Abstract 63 This document presents home control and automation application 64 specific requirements for Routing Over Low power and Lossy 65 networks (ROLL). In the near future many homes will contain high 66 numbers of wireless devices for a wide set of purposes. Examples 67 include actuators (relay, light dimmer, heating valve), sensors 68 (wall switch, water leak, blood pressure) and advanced controllers 69 (RF-based AV remote control, Central server for light and heat 70 control). Because such devices only cover a limited radio range, 71 routing is often required. The aim of this document is to specify 72 the routing requirements for networks comprising such constrained 73 devices in a home control and automation environment. 75 Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 78 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 79 in this document are to be interpreted as described in RFC-2119 80 [RFC2119]. 82 Table of Contents 84 1. Introduction................................................4 85 1.1. Terminology............................................5 86 2. Home Automation Applications................................6 87 2.1. Lighting Application In Action.........................6 88 2.2. Energy Conservation and Optimizing Energy Consumption..6 89 2.3. Moving a Remote Control Around.........................7 90 2.4. Adding A New Module To The System......................7 91 2.5. Controlling Battery Operated Window Shades.............8 92 2.6. Remote Video Surveillance..............................8 93 2.7. Healthcare.............................................8 94 2.7.1. At-home Health Reporting..........................9 95 2.7.2. At-home Health Monitoring........................10 96 2.8. Alarm Systems.........................................10 97 3. Unique Routing Requirements of Home Automation Applications11 98 3.1. Constraint-based Routing..............................11 99 3.2. Support of Mobility...................................12 100 3.3. Sleeping Nodes........................................13 101 3.4. Healthcare Routing....................................13 102 3.5. Scalability...........................................13 103 3.6. Convergence Time......................................13 104 3.7. Manageability.........................................14 105 3.8. Stability.............................................14 106 4. Traffic Pattern............................................14 107 5. Security Considerations....................................15 108 6. IANA Considerations........................................16 109 7. Acknowledgments............................................17 110 8. Disclaimer for pre-RFC5378 work............................17 111 9. References.................................................17 112 9.1. Normative References..................................17 113 9.2. Informative References................................17 115 1. Introduction 117 This document presents home control and automation application 118 specific requirements for Routing Over Low power and Lossy 119 networks (ROLL). In the near future many homes will contain high 120 numbers of wireless devices for a wide set of purposes. Examples 121 include actuators (relay, light dimmer, heating valve), sensors 122 (wall switch, water leak, blood pressure) and advanced 123 controllers. Basic home control modules such as wall switches and 124 plug-in modules may be turned into an advanced home automation 125 solution via the use of an IP-enabled application responding to 126 events generated by wall switches, motion sensors, light sensors, 127 rain sensors, and so on. 129 Network nodes may be sensors and actuators at the same time. An 130 example is a wall switch for replacement in existing homes. The 131 push buttons may generate events for a controller node or for 132 activating other actuator nodes. At the same time, a built-in 133 relay may act as actuator for a controller or other remote 134 sensors. 136 Because ROLL nodes only cover a limited radio range, routing is 137 often required. These devices are usually highly constrained in 138 term of resources such as battery and memory and operate in 139 unstable environments. Persons moving around in a house, opening 140 or closing a door or starting a microwave oven affect the 141 reception of weak radio signals. Reflection and absorption may 142 cause a reliable radio link to turn unreliable for a period of 143 time and then being reusable again, thus the term "lossy". All 144 traffic in a ROLL network is carried as IPv6 packets. 146 The connected home area is very much consumer-oriented. The 147 implication on network nodes is that devices are very cost 148 sensitive, which leads to resource-constrained environments having 149 slow CPUs and small memory footprints. At the same time, nodes 150 have to be physically small which puts a limit to the physical 151 size of the battery; and thus, the battery capacity. As a result, 152 it is common for battery operated sensor-style nodes to shut down 153 radio and CPU resources for most of the time. The radio tends to 154 use the same power for listening as for transmitting 156 Section 2 describes a few typical use cases for home automation 157 applications. Section 3 discusses the routing requirements for 158 networks comprising such constrained devices in a home network 159 environment. These requirements may be overlapping requirements 160 derived from other application-specific routing requirements 161 presented in [I-D.Martocci-Building-reqs], [I-D.Pister-Industial- 162 reqs] and [RFC5548]. 164 A full list of requirements documents may be found in section 9. 166 1.1. Terminology 168 ROLL: Routing Over Low-power and Lossy networks 169 A ROLL node may be classified as sensor, actuator 170 or controller. 172 Actuator: Network node which performs some physical action. 173 Dimmers and relays are examples of actuators. 174 If sufficiently powered, actuator nodes may 175 participate in routing network messages. 177 Border router:Infrastructure device that connects a ROLL network 178 to the Internet or some backbone network. 180 Channel: Radio frequency band used to carry network packets. 182 Controller: Network node that controls actuators. Control 183 decisions may be based on sensor readings, sensor 184 events, scheduled actions or incoming commands from 185 the Internet or other backbone networks. 186 If sufficiently powered, controller nodes may 187 participate in routing network messages. 189 Downstream: Data direction traveling from a Local Area Network 190 (LAN) to a Personal Area Network (PAN) device. 192 DR: Demand-Response 193 The mechanism of users adjusting their power 194 consumption in response to actual pricing of power. 196 DSM: Demand Side Management 197 Process allowing power utilities to enable and 198 disable loads in consumer premises. Where DR relies 199 on voluntary action from users, DSM may be based on 200 enrollment in a formal program. 202 HC-LLN: Home Control in Low-Power and Lossy Networks 204 LAN: Local Area Network. 206 PAN: Personal Area Network. 207 A geographically limited wireless network based on 208 e.g. 802.15.4 or Z-Wave radio. 210 PDA Personal Digital Assistant. A small, handheld 211 computer. 213 PLC Power Line Communication 215 RAM Random Access Memory 216 Sensor: Network node that measures some physical parameter 217 and/or detects an event. 218 The sensor may generate a trap message to notify a 219 controller or directly activate an actuator. 220 If sufficiently powered, sensor nodes may 221 participate in routing network messages. 223 Upstream: Data direction traveling from a PAN to a LAN 224 device. 226 Refer to the roll-terminology reference document [I-D.Vasseur- 227 Terminology] for a full list of terms used in the IETF ROLL WG. 229 2. Home Automation Applications 231 Home automation applications represent a special segment of 232 networked devices with its unique set of requirements. 233 Historically, such applications used wired networks or power line 234 communication (PLC), but wireless solutions have emerged; allowing 235 existing homes to be upgraded more easily. 237 To facilitate the requirements discussion in Section 3, this 238 section lists a few typical use cases of home automation 239 applications. New applications are being developed at a high pace 240 and this section does not mean to be exhaustive. Most home 241 automation applications tend to be running some kind of 242 command/response protocol. The command may come from several 243 places. 245 2.1. Lighting Application In Action 247 A lamp may be turned on, not only by a wall switch but also by a 248 movement sensor. The wall switch module may itself be a push- 249 button sensor and an actuator at the same time. This will often be 250 the case when upgrading existing homes as existing wiring is not 251 prepared for automation. 253 One event may cause many actuators to be activated at the same 254 time. 255 Using the direct analogy to an electronic car key, a house owner 256 may activate the "leaving home" function from an electronic house 257 key, mobile phone, etc. For the sake of visual impression, all 258 lights should turn off at the same time. At least, it should 259 appear to happen at the same time. 261 2.2. Energy Conservation and Optimizing Energy Consumption 263 In order to save energy, air conditioning, central heating, window 264 shades etc. may be controlled by timers, motion sensors or 265 remotely via internet or cell. Central heating may also be set to 266 a reduced temperature during night time. 268 The power grid may experience periods where more wind-generated 269 power is produced than is needed. Typically this may happen during 270 night hours. 272 In periods where electricity demands exceed available supply, 273 appliances such as air conditioning, climate control systems, 274 washing machines etc. can be turned off to avoid overloading the 275 power grid. 276 This is known as Demand-Side Management (DSM). 277 Remote control of household appliances is well-suited for this 278 application. 280 The start/stop decision for the appliances can also be regulated 281 by dynamic power pricing information obtained from the electricity 282 utility companies. This method called Demand-Response (DR) works 283 by motivation of users via pricing, bonus points, etc. For 284 example, the washing machine and dish washer may just as well work 285 while power is cheap. The electric car should also charge its 286 batteries on cheap power. 288 In order to achieve effective electricity savings, the energy 289 monitoring application must guarantee that the power consumption 290 of the ROLL devices is much lower than that of the appliance 291 itself. 293 Most of these appliances are mains powered and are thus ideal for 294 providing reliable, always-on routing resources. Battery-powered 295 nodes, by comparison, are constrained routing resources and may 296 only provide reliable routing under some circumstances. 298 2.3. Moving a Remote Control Around 300 A remote control is a typical example of a mobile device in a home 301 automation network. An advanced remote control may be used for 302 dimming the light in the dining room while eating and later on, 303 turning up the music while doing the dishes in the kitchen. 304 Reaction must appear to be instant (within a few hundred 305 milliseconds) even when the remote control has moved to a new 306 location. The remote control may be communicating to either a 307 central home automation controller or directly to the lamps and 308 the media center. 310 2.4. Adding A New Module To The System 312 Small-size, low-cost modules may have no user interface except for 313 a single button. Thus, an automated inclusion process is needed 314 for controllers to find new modules. Inclusion covers the 315 detection of neighbors and assignment of a unique node ID. 316 Inclusion should be completed within a few seconds. 318 For ease of use in a consumer application space such as home 319 control, nodes may be included without having to type in special 320 codes before inclusion. One way to achieve an acceptable balance 321 between security and convenience is to block inclusion during 322 normal operation and explicitly enable inclusion support just 323 before adding a new module and disable it again just after adding 324 a new module. 325 For security considerations, refer to section 5. 327 If assignment of unique addresses is performed by a central 328 controller, it must be possible to route the inclusion request 329 from the joining node to the central controller before the joining 330 node has been included in the network. 332 2.5. Controlling Battery Operated Window Shades 334 In consumer premises, window shades are often battery-powered as 335 there is no access to mains power over the windows. For battery 336 conservation purposes, such an actuator node is sleeping most of 337 the time. A controller sending commands to a sleeping actuator 338 node via ROLL devices will have no problems delivering the packet 339 to the nearest powered router, but that router may experience a 340 delay until the next wake-up time before the command can be 341 delivered. 343 2.6. Remote Video Surveillance 345 Remote video surveillance is a fairly classic application for Home 346 networking providing the ability for the end user to get a video 347 stream from a Web Cam reached via the Internet. The video stream 348 may be triggered by the end-user after receiving an alarm from a 349 sensor (movement or smoke detector) or the user simply wants to 350 check the home status via video. 351 Note that in the former case, more than likely, there will be a 352 form of inter-device communication: Upon detecting some movement 353 in the home, the movement sensor may send a request to the light 354 controller to turn on the lights, to the Web Cam to start a video 355 stream that would then be directed to the end user's cell phone or 356 Personal Digital Assistant (PDA) via the Internet. 357 In contrast to other applications, e.g. industrial sensors, where 358 data would mainly be originated by a sensor to a sink and vice 359 versa, this scenario implicates a direct inter-device 360 communication between ROLL devices. 362 2.7. Healthcare 364 By adding communication capability to devices, patients and 365 elderly citizens may be able to do simple measurements at home. 367 Thanks to online devices, a doctor can keep an eye on the 368 patient's health and receive warnings if a new trend is discovered 369 by automated filters. 371 Fine-grained daily measurements presented in proper ways may allow 372 the doctor to establish a more precise diagnosis. 374 Such applications may be realized as wearable products which 375 frequently do a measurement and automatically deliver the result 376 to a data sink locally or over the Internet. 378 Applications falling in this category are referred to as at-home 379 health reporting. Whether measurements are done in a fixed 380 interval or if they are manually activated, they leave all 381 processing to the receiving data sink. 383 A more active category of applications may send an alarm if some 384 alarm condition is triggered. This category of applications is 385 referred to as at-home health monitoring. Measurements are 386 interpreted in the device and may cause reporting of an event if 387 an alarm is triggered. 389 Many implementations may overlap both categories. 391 Since wireless and battery operated systems may never reach 100% 392 guaranteed operational time, healthcare and security systems will 393 need a management layer implementing alarm mechanisms for low 394 battery, report activity, etc. 395 For instance if a blood pressure sensor did not report a new 396 measurement, say 5 minutes after the scheduled time, some 397 responsible person must be notified. 398 The structure and performance of such a management layer is 399 outside the scope of the routing requirements listed in this 400 document. 402 2.7.1. At-home Health Reporting 404 Applications might include: 406 o Temperature 407 o Weight 408 o Blood pressure 409 o Insulin level 411 Measurements may be stored for long term statistics. At the same 412 time, a critically high blood pressure may cause the generation of 413 an alarm report. Refer to 2.7.2. 415 To avoid a high number of request messages, nodes may be 416 configured to autonomously do a measurement and send a report in 417 intervals. 419 2.7.2. At-home Health Monitoring 421 An alarm event may become active e.g. if the measured blood 422 pressure exceeds a threshold or if a person falls to the ground. 423 Alarm conditions must be reported with the highest priority and 424 timeliness. 426 Applications might include: 428 o Temperature 429 o Weight 430 o Blood pressure 431 o Insulin level 432 o Electrocardiogram (ECG) 433 o Position tracker 435 2.8. Alarm Systems 437 A home security alarm system is comprised of various sensors 438 (vibration, fire or carbon monoxide, door/window, glass-break, 439 presence, panic button, etc.). 441 Some smoke alarms are battery powered and at the same time mounted 442 in a high place. Battery-powered safety devices should only be 443 used for routing if no other alternatives exist to avoid draining 444 the battery. A smoke alarm with a drained battery does not provide 445 a lot of safety. Also, it may be inconvenient to exchange battery 446 in a smoke alarm. 448 Alarm system applications may have both a synchronous and an 449 asynchronous behavior; i.e. they may be periodically queried by a 450 central control application (e.g. for a periodical refreshment of 451 the network state), or send a message to the control application 452 on their own initiative. 454 When a node (or a group of nodes) identifies a risk situation 455 (e.g. intrusion, smoke, fire), it sends an alarm message to a 456 central controller that could autonomously forward it via Internet 457 or interact with other network nodes (e.g. try to obtain more 458 detailed information or ask other nodes close to the alarm event). 460 Finally, routing via battery-powered nodes may be very slow if the 461 nodes are sleeping most of the time (they could appear 462 unresponsive to the alarm detection). To ensure fast message 463 delivery and avoid battery drain, routing should be avoided via 464 sleeping devices. 466 3. Unique Routing Requirements of Home Automation Applications 468 Home automation applications have a number of specific routing 469 requirements related to the set of home networking applications 470 and the perceived operation of the system. 472 The relations of use cases to requirements are outlined in the 473 table below: 475 +-------------------------------+-----------------------------+ 476 | Use case | Requirement | 477 +-------------------------------+-----------------------------+ 478 |2.1. Lighting Application In |3.2. Support of Mobility | 479 |Action |3.5. Scalability | 480 | | | 481 +-------------------------------+-----------------------------+ 482 |2.2. Energy Conservation and |3.1. Constraint-based Routing| 483 |Optimizing Energy Consumption | | 484 +-------------------------------+-----------------------------+ 485 |2.3. Moving a Remote Control |3.2. Support of Mobility | 486 |Around |3.6. Convergence Time | 487 +-------------------------------+-----------------------------+ 488 |2.4. Adding A New Module To The|3.6. Convergence Time | 489 |System |3.7. Manageability | 490 +-------------------------------+-----------------------------+ 491 |2.5. Controlling Battery |3.3. Sleeping Nodes | 492 |Operated Window Shades | | 493 +-------------------------------+-----------------------------+ 494 |2.6. Remote Video Surveillance |3.3. Sleeping Nodes | 495 | |3.6. Convergence Time | 496 +-------------------------------+-----------------------------+ 497 |2.7. Healthcare |3.1. Constraint-based Routing| 498 | |3.2. Support of Mobility | 499 | |3.4. Healthcare Routing | 500 | |3.6. Convergence Time | 501 +-------------------------------+-----------------------------+ 502 |2.8. Alarm Systems |3.5. Scalability | 503 | |3.6. Convergence Time | 504 +-------------------------------+-----------------------------+ 506 3.1. Constraint-based Routing 508 For convenience and low operational costs, power consumption of 509 consumer products must be kept at a very low level to achieve a 510 long battery lifetime. One implication of this fact is that Random 511 Access Memory (RAM) is limited and it may even be powered down; 512 leaving only a few 100 bytes of RAM alive during the sleep phase. 514 The use of battery powered devices reduces installation costs and 515 does enable installation of devices even where main power lines 516 are not available. On the other hand, in order to be cost 517 effective and efficient, the devices have to maximize the sleep 518 phase with a duty cycle lower than 1%. 520 Some devices only wake up in response to an event, e.g. a push 521 button. 523 Simple battery-powered nodes such as movement sensors on garage 524 doors and rain sensors may not be able to assist in routing. 525 Depending on the node type, the node never listens at all, listens 526 rarely or makes contact on demand to a pre-configured target node. 527 Attempting to communicate to such nodes may at best require long 528 time before getting a response. 530 Other battery-powered nodes may have the capability to participate 531 in routing. The routing protocol SHOULD route via mains-powered 532 nodes if possible. 534 The routing protocol MUST support constraint-based routing taking 535 into account node properties (CPU, memory, level of energy, sleep 536 intervals, safety/convenience of changing battery). 538 3.2. Support of Mobility 540 In a home environment, although the majority of devices are fixed 541 devices, there is still a variety of mobile devices: for example a 542 remote control is likely to move. Another example of mobile 543 devices is wearable healthcare devices. 545 While healthcare devices delivering measurement results can 546 tolerate route discovery times measured in seconds, a remote 547 control appears unresponsive if using more than 0.5 seconds to 548 e.g. pause the music. 550 In more rare occasions, receiving nodes may also have moved. 551 Examples include safety-off switch in a clothes iron, a vacuum 552 cleaner robot or the wireless chime of doorbell set. 554 Refer to section 3.6. for routing protocol convergence times. 556 A non-responsive node can either be caused by 1) a failure in the 557 node, 2) a failed link on the path to the node or 3) a moved node. 558 In the first two cases, the node can be expected to reappear at 559 roughly the same location in the network, whereas it can return 560 anywhere in the network in the latter case. 562 3.3. Sleeping Nodes 564 Sleeping nodes may appear to be non-responsive. The routing 565 protocol MUST take into account the delivery time to a sleeping 566 target node. 568 3.4. Healthcare Routing 570 Because most health care applications may run on battery, this 571 leads to specific requirements for the routing protocol. Most 572 health care applications may also be portable and therefore need 573 to locate a new neighbor router on a frequent basis. 574 Not being powered most of the time, the nodes should not be used 575 as routing nodes. However, battery-powered nodes may be involved 576 in routing. Examples include cases where a person falls during a 577 power blackout. In that case it may be that no mains-powered 578 routers are available for forwarding the alarm message to a 579 (battery-backed) internet gateway located out of direct range. 581 Delivery of measurement data has a more relaxed requirement for 582 route discovery time compared to a remote control. On the other 583 hand, it is critical that a "person fell" alarm is actually 584 delivered. 586 If possible at all, the routing protocol MUST deliver a health- 587 care related message. It is NOT a requirement that such message is 588 delivered in less than a second. 590 3.5. Scalability 592 Looking at the number of wall switches, power outlets, sensors of 593 various nature, video equipment and so on in a modern house, it 594 seems quite realistic that hundreds of low power devices may form 595 a home automation network in a fully populated "smart" home. 596 Moving towards professional building automation, the number of 597 such devices may be in the order of several thousands. 599 The routing protocol MUST support 250 devices in the network. 601 3.6. Convergence Time 603 A wireless home automation network is subject to various 604 instabilities due to signal strength variation, moving persons and 605 the like. 606 Measured from the transmission of a packet, the following 607 convergence time requirements apply. 609 The routing protocol MUST converge within 0.5 second if no nodes 610 have moved. 612 The routing protocol MUST converge within 4 seconds if nodes have 613 moved. 615 In both cases, "converge" means "the originator node has received 616 a response from the destination node". The above-mentioned 617 convergence time requirements apply to a home control network 618 environment of up to 250 nodes with up to 4 repeating nodes 619 between source and destination. 621 3.7. Manageability 623 The ability of the home network to support auto-configuration is 624 of the utmost importance. Indeed, most end users will not have the 625 expertise and the skills to perform advanced configuration and 626 troubleshooting. Thus the routing protocol designed for home 627 automation networks MUST provide a set of features including zero- 628 configuration of the routing protocol for a new node to be added 629 to the network. From a routing perspective, zero-configuration 630 means that a node can obtain an address and join the network on 631 its own, almost without human intervention. 633 3.8. Stability 635 If a node is found to fail often compared to the rest of the 636 network, this node SHOULD NOT be the first choice for routing of 637 traffic. 639 4. Traffic Pattern 641 Depending on the design philosophy of the home network, wall 642 switches may be configured to directly control individual lamps or 643 alternatively, all wall switches send control commands to a 644 central lighting control computer which again sends out control 645 commands to relevant devices. 647 In a distributed system, the traffic tends to be multipoint-to- 648 multipoint. In a centralized system, it is a mix of multipoint-to- 649 point and point-to-multipoint. 651 Wall switches only generate traffic when activated, which 652 typically happens from a one to tens of times per hour. 654 Remote controls have a similar transmit pattern to wall switches, 655 but are activated more frequently. 657 Temperature/air pressure/rain sensors send frames when queried by 658 the user or can be preconfigured to send measurements at fixed 659 intervals (typically minutes). Motion sensors typically send a 660 frame when motion is first detected and another frame when an idle 661 period with no movement has elapsed. The highest transmission 662 frequency depends on the idle period used in the sensor. 664 Sometimes, a timer will trigger a frame transmission when an 665 extended period without status change has elapsed. 667 All frames sent in the above examples are quite short, typically 668 less than 5 bytes of payload. Lost frames and interference from 669 other transmitters may lead to retransmissions. In all cases, 670 acknowledgment frames with a size of a few bytes are used. 672 As mentioned in the introduction, all messages are carried in IPv6 673 packets; typically as UDP but ICMP echo and other types may also 674 appear. 675 In order to save bandwidth, the transport layer will typically be 676 using header compression [I-D.Hui-HeaderCompression]. 678 5. Security Considerations 680 As every network, HC-LLNs are exposed to routing security threats 681 that need to be addressed. The wireless and distributed nature of 682 these networks increases the spectrum of potential routing 683 security threats. This is further amplified by the resource 684 constraints of the nodes, thereby preventing resource-intensive 685 routing security approaches from being deployed. A viable routing 686 security approach SHOULD be sufficiently lightweight that it may 687 be implemented across all nodes in a HC-LLN. These issues require 688 special attention during the design process, so as to facilitate a 689 commercially attractive deployment. 691 An attacker can snoop, replay, or originate arbitrary messages to 692 a node in an attempt to manipulate or disable the routing 693 function. 694 To mitigate this, the HC-LLN MUST be able to authenticate a new 695 node prior to allowing it to participate in the routing decision 696 process. The routing protocol MUST support message integrity. 698 Further examples of routing security issues that may arise are the 699 abnormal behavior of nodes that exhibit an egoistic conduct, such 700 as not obeying network rules or forwarding no or false packets. 701 Other important issues may arise in the context of denial-of- 702 service (DoS) attacks, malicious address space allocations, 703 advertisement of variable addresses, a wrong neighborhood, etc. 704 The routing protocol(s) SHOULD support defense against DoS attacks 705 and other attempts to maliciously or inadvertently cause the 706 mechanisms of the routing protocol(s) to over-consume the limited 707 resources of LLN nodes, e.g., by constructing forwarding loops or 708 causing excessive routing protocol overhead traffic, etc. 710 The properties of self-configuration and self-organization that 711 are desirable in a HC-LLN introduce additional routing security 712 considerations. Mechanisms MUST be in place to deny any node that 713 attempts to take malicious advantage of self-configuration and 714 self-organization procedures. Such attacks may attempt, for 715 example, to cause DoS, drain the energy of power-constrained 716 devices, or to hijack the routing mechanism. A node MUST 717 authenticate itself to a trusted node that is already associated 718 with the HC-LLN before the former can take part in self- 719 configuration or self-organization. A node that has already 720 authenticated and associated with the HC-LLN MUST deny, to the 721 maximum extent possible, the allocation of resources to any 722 unauthenticated peer. The routing protocol(s) MUST deny service 723 to any node that has not clearly established trust with the HC- 724 LLN. 725 In a home control environment, it is considered unlikely that a 726 network is constantly being snooped and at the same time, ease of 727 use is important. As a consequence the network key MAY be exposed 728 for short periods during inclusion of new nodes. 729 Electronic door locks and other critical applications SHOULD apply 730 end-to-end application security on top of the network transport 731 security. 733 If connected to a backbone network, the HC-LLN SHOULD be capable 734 of limiting the resources utilized by nodes in said backbone 735 network so as not to be vulnerable to DoS. This should typically 736 be handled by border routers providing access from a backbone 737 network to resources in the HC-LLN. 739 With low computation power and scarce energy resources, HC-LLNs' 740 nodes may not be able to resist any attack from high-power 741 malicious nodes (e.g., laptops and strong radios). However, the 742 amount of damage generated to the whole network SHOULD be 743 commensurate with the number of nodes physically compromised. For 744 example, an intruder taking control over a single node SHOULD NOT 745 be able to completely deny service to the whole network. 747 In general, the routing protocol(s) SHOULD support the 748 implementation of routing security best practices across the HC- 749 LLN. Such an implementation ought to include defense against, for 750 example, eavesdropping, replay, message insertion, modification, 751 and man-in-the-middle attacks. 753 The choice of the routing security solutions will have an impact 754 on the routing protocol(s). To this end, routing protocol(s) 755 proposed in the context of HC-LLNs MUST support authentication and 756 integrity measures and SHOULD support confidentiality (routing 757 security) measures. 759 6. IANA Considerations 761 This document includes no request to IANA. 763 7. Acknowledgments 765 J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler 766 and Massimo Maggiorotti are gratefully acknowledged for their 767 contributions to this document. 769 This document was prepared using 2-Word-v2.0.template.dot. 771 8. Disclaimer for pre-RFC5378 work 773 This document may contain material from IETF Documents or IETF 774 Contributions published or made publicly available before November 775 10, 2008. The person(s) controlling the copyright in some of this 776 material may not have granted the IETF Trust the right to allow 777 modifications of such material outside the IETF Standards Process. 778 Without obtaining an adequate license from the person(s) 779 controlling the copyright in such materials, this document may not 780 be modified outside the IETF Standards Process, and derivative 781 works of it may not be created outside the IETF Standards Process, 782 except to format it for publication as an RFC or to translate it 783 into languages other than English. 785 9. References 787 9.1. Normative References 789 [I-D.Vasseur-Terminology] Vasseur, JP. "Terminology in Low power 790 And Lossy Networks", draft-vasseur-roll-terminology-02 791 (work in progress), October 2008. 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, March 1997. 796 9.2. Informative References 798 [RFC5548] Dohler, M., "Routing Requirements for Urban Low-Power 799 and Lossy Networks", BCP 14, RFC 5548, May 2009. 801 [I-D.Pister-Industial-reqs] Pister, K., "Industrial Routing 802 Requirements in Low Power and Lossy Networks ", draft- 803 ietf-roll-indus-routing-reqs (work in progress) 805 [I-D.Martocci-Building-reqs] Martocci, J., "Building Automation 806 Routing Requirements in Low Power and Lossy Networks ", 807 draft-ietf-roll-building-routing-reqs (work in progress) 809 [I-D.Levis-Protocols-survey] Lewis, P. "Overview of Existing 810 Routing Protocols for Low Power and Lossy Networks", 811 draft-ietf-roll-protocols-survey (work in progress) 813 [I-D.Hui-HeaderCompression] Hui, J., "Compression Format for IPv6 814 Datagrams in 6LoWPAN Networks ", draft-ietf-6lowpan-hc 815 (work in progress), December 2008. 817 Author's Addresses 819 Anders Brandt 821 Sigma Designs, Inc. 822 Emdrupvej 26 823 Copenhagen, DK-2100 824 Denmark 826 Email: abr@sdesigns.dk 828 Jakob Buron 829 Sigma Designs, Inc. 830 Emdrupvej 26 831 Copenhagen, DK-2100 832 Denmark 834 Email: jbu@sdesigns.dk 836 Giorgio Porcu 837 Telecom Italia 838 Piazza degli Affari, 2 839 20123 Milan 840 Italy 842 Acknowledgment 844 Funding for the RFC Editor function is currently provided by the 845 Internet Society.