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