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