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