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