--- 1/draft-ietf-roll-home-routing-reqs-08.txt 2009-11-30 12:12:38.000000000 +0100 +++ 2/draft-ietf-roll-home-routing-reqs-09.txt 2009-11-30 12:12:38.000000000 +0100 @@ -1,19 +1,21 @@ Networking Working Group A. Brandt -Internet Draft Zensys, Inc. -Intended status: Informational G. Porcu -Expires: March 2010 Telecom Italia - September 16, 2009 +Internet Draft Sigma Designs, Inc. +Intended status: Informational J. Buron +Expires: May 2010 Sigma Designs, Inc. + G. Porcu + Telecom Italia + November 30, 2009 Home Automation Routing Requirements in Low Power and Lossy Networks - draft-ietf-roll-home-routing-reqs-08 + draft-ietf-roll-home-routing-reqs-09 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,34 +25,46 @@ documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 16, 2010. + This Internet-Draft will expire on April 30, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) + controlling the copyright in such materials, this document may not + be modified outside the IETF Standards Process, and derivative + works of it may not be created outside the IETF Standards Process, + except to format it for publication as an RFC or to translate it + into languages other than English. + Abstract This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In the near future many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers (RF-based AV remote control, Central server for light and heat control). Because such devices only cover a limited radio range, @@ -60,50 +74,50 @@ Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents - 1. Introduction..................................................4 - 1.1. Terminology..............................................5 - 2. Home Automation Applications..................................6 - 2.1. Lighting Application In Action...........................6 - 2.2. Energy Conservation and Optimizing Energy Consumption....7 - 2.3. Moving a Remote Control Around...........................7 - 2.4. Adding A New Module To The System........................8 - 2.5. Controlling Battery Operated Window Shades...............8 - 2.6. Remote Video Surveillance................................8 - 2.7. Healthcare...............................................8 - 2.7.1. At-home Health Reporting............................9 - 2.7.2. At-home Health Monitoring..........................10 - 2.8. Alarm Systems...........................................10 - 3. Unique Routing Requirements of Home Automation Applications..11 - 3.1. Constraint-based Routing................................11 - 3.2. Support of Mobility.....................................12 - 3.3. Sleeping Nodes..........................................13 - 3.4. Healthcare Routing......................................13 - 3.5. Scalability.............................................13 - 3.6. Convergence Time........................................14 - 3.7. Manageability...........................................14 - 3.8. Stability...............................................14 - 4. Traffic Pattern..............................................14 - 5. Security Considerations......................................15 - 6. IANA Considerations..........................................17 - 7. Acknowledgments..............................................17 - 8. Disclaimer for pre-RFC5378 work..............................17 - 9. References...................................................17 - 9.1. Normative References....................................17 - 9.2. Informative References..................................18 + 1. Introduction................................................4 + 1.1. Terminology............................................5 + 2. Home Automation Applications................................6 + 2.1. Lighting Application In Action.........................6 + 2.2. Energy Conservation and Optimizing Energy Consumption..6 + 2.3. Moving a Remote Control Around.........................7 + 2.4. Adding A New Module To The System......................7 + 2.5. Controlling Battery Operated Window Shades.............8 + 2.6. Remote Video Surveillance..............................8 + 2.7. Healthcare.............................................8 + 2.7.1. At-home Health Reporting..........................9 + 2.7.2. At-home Health Monitoring........................10 + 2.8. Alarm Systems.........................................10 + 3. Unique Routing Requirements of Home Automation Applications11 + 3.1. Constraint-based Routing..............................11 + 3.2. Support of Mobility...................................12 + 3.3. Sleeping Nodes........................................13 + 3.4. Healthcare Routing....................................13 + 3.5. Scalability...........................................13 + 3.6. Convergence Time......................................13 + 3.7. Manageability.........................................14 + 3.8. Stability.............................................14 + 4. Traffic Pattern............................................14 + 5. Security Considerations....................................15 + 6. IANA Considerations........................................16 + 7. Acknowledgments............................................17 + 8. Disclaimer for pre-RFC5378 work............................17 + 9. References.................................................17 + 9.1. Normative References..................................17 + 9.2. Informative References................................17 1. Introduction This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In the near future many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Basic home control modules such as wall switches and @@ -122,30 +136,29 @@ Because ROLL nodes only cover a limited radio range, routing is often required. These devices are usually highly constrained in term of resources such as battery and memory and operate in unstable environments. Persons moving around in a house, opening or closing a door or starting a microwave oven affect the reception of weak radio signals. Reflection and absorption may cause a reliable radio link to turn unreliable for a period of time and then being reusable again, thus the term "lossy". All traffic in a ROLL network is carried as IPv6 packets. - Unlike other categories of Personal Area Networks (PANs), the - connected home area is very much consumer-oriented. The + The connected home area is very much consumer-oriented. The implication on network nodes is that devices are very cost sensitive, which leads to resource-constrained environments having slow CPUs and small memory footprints. At the same time, nodes have to be physically small which puts a limit to the physical size of the battery; and thus, the battery capacity. As a result, - it is common for low-power sensor-style nodes to shut down radio - and CPU resources for most of the time. The radio tends to use the - same power for listening as for transmitting + it is common for battery operated sensor-style nodes to shut down + radio and CPU resources for most of the time. The radio tends to + use the same power for listening as for transmitting Section 2 describes a few typical use cases for home automation applications. Section 3 discusses the routing requirements for networks comprising such constrained devices in a home network environment. These requirements may be overlapping requirements derived from other application-specific routing requirements presented in [I-D.Martocci-Building-reqs], [I-D.Pister-Industial- reqs] and [RFC5548]. A full list of requirements documents may be found in section 9. @@ -236,27 +249,21 @@ button sensor and an actuator at the same time. This will often be the case when upgrading existing homes as existing wiring is not prepared for automation. One event may cause many actuators to be activated at the same time. Using the direct analogy to an electronic car key, a house owner may activate the "leaving home" function from an electronic house key, mobile phone, etc. For the sake of visual impression, all lights should turn off at the same time. At least, it should - appear to happen at the same time. A well-known problem in - wireless home automation is the "popcorn effect": Lamps are turned - on one at a time, at a rate so slow that it is clearly visible. - - Some existing home automation solutions address this by sending an - unacknowledged multicast message in direct range before sending - acknowledged singlecast messages to each device. + appear to happen at the same time. 2.2. Energy Conservation and Optimizing Energy Consumption In order to save energy, air conditioning, central heating, window shades etc. may be controlled by timers, motion sensors or remotely via internet or cell. Central heating may also be set to a reduced temperature during night time. The power grid may experience periods where more wind-generated power is produced than is needed. Typically this may happen during @@ -301,20 +308,29 @@ the media center. 2.4. Adding A New Module To The System Small-size, low-cost modules may have no user interface except for a single button. Thus, an automated inclusion process is needed for controllers to find new modules. Inclusion covers the detection of neighbors and assignment of a unique node ID. Inclusion should be completed within a few seconds. + For ease of use in a consumer application space such as home + control, nodes may be included without having to type in special + codes before inclusion. One way to achieve an acceptable balance + between security and convenience is to block inclusion during + normal operation and explicitly enable inclusion support just + before adding a new module and disable it again just after adding + a new module. + For security considerations, refer to section 5. + If assignment of unique addresses is performed by a central controller, it must be possible to route the inclusion request from the joining node to the central controller before the joining node has been included in the network. 2.5. Controlling Battery Operated Window Shades In consumer premises, window shades are often battery-powered as there is no access to mains power over the windows. For battery conservation purposes, such an actuator node is sleeping most of @@ -515,42 +532,33 @@ nodes if possible. The routing protocol MUST support constraint-based routing taking into account node properties (CPU, memory, level of energy, sleep intervals, safety/convenience of changing battery). 3.2. Support of Mobility In a home environment, although the majority of devices are fixed devices, there is still a variety of mobile devices: for example a - multi-purpose remote control is likely to move. Another example of - mobile devices is wearable healthcare devices. + remote control is likely to move. Another example of mobile + devices is wearable healthcare devices. While healthcare devices delivering measurement results can tolerate route discovery times measured in seconds, a remote control appears unresponsive if using more than 0.5 seconds to e.g. pause the music. - While, in theory, all battery-powered devices and mains-powered - plug-in modules may be moved, the predominant case is that the - sending node has moved while the rest of the network has not - changed. - - The routing protocol MUST provide mobility with convergence time - below 0.5 second if only the sender has moved. - In more rare occasions, receiving nodes may also have moved. - Examples include safety-off switch in a clothes iron or the - wireless chime of doorbell set. + Examples include safety-off switch in a clothes iron, a vacuum + cleaner robot or the wireless chime of doorbell set. - The routing protocol MUST provide mobility with convergence time - below 4 seconds if the receiver has moved. + Refer to section 3.6. for routing protocol convergence times. A non-responsive node can either be caused by 1) a failure in the node, 2) a failed link on the path to the node or 3) a moved node. In the first two cases, the node can be expected to reappear at roughly the same location in the network, whereas it can return anywhere in the network in the latter case. 3.3. Sleeping Nodes Sleeping nodes may appear to be non-responsive. The routing @@ -572,76 +580,68 @@ Delivery of measurement data has a more relaxed requirement for route discovery time compared to a remote control. On the other hand, it is critical that a "person fell" alarm is actually delivered. If possible at all, the routing protocol MUST deliver a health- care related message. It is NOT a requirement that such message is delivered in less than a second. - The routing protocol SHOULD support acknowledged transmission. If - the routing protocol does not support acknowledged transmission, - some higher-layer transport protocol or application MUST ensure - delivery of such messages. - 3.5. Scalability Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of low power devices may form a home automation network in a fully populated "smart" home. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol MUST support 250 devices in the network. 3.6. Convergence Time A wireless home automation network is subject to various instabilities due to signal strength variation, moving persons and - the like. Furthermore, as the number of devices increases, the - probability of a node failure also increases. - + the like. Measured from the transmission of a packet, the following convergence time requirements apply. The routing protocol MUST converge within 0.5 second if no nodes have moved. - The routing protocol MUST converge within 2 seconds if the - destination node of the packet has moved. + The routing protocol MUST converge within 4 seconds if nodes have + moved. In both cases, "converge" means "the originator node has received - a response from the destination node". + a response from the destination node". The above-mentioned + convergence time requirements apply to a home control network + environment of up to 250 nodes with up to 4 repeating nodes + between source and destination. 3.7. Manageability The ability of the home network to support auto-configuration is of the utmost importance. Indeed, most end users will not have the expertise and the skills to perform advanced configuration and troubleshooting. Thus the routing protocol designed for home automation networks MUST provide a set of features including zero- configuration of the routing protocol for a new node to be added to the network. From a routing perspective, zero-configuration means that a node can obtain an address and join the network on - its own, without human intervention. + its own, almost without human intervention. 3.8. Stability - The routing protocol MUST support the ability to isolate a - misbehaving node thus preserving the correct operation of the - overall network. - - In other words, if a node is found to fail often compared to the - rest of the network, this node should not be the first choice for - routing of traffic. + If a node is found to fail often compared to the rest of the + network, this node SHOULD NOT be the first choice for routing of + traffic. 4. Traffic Pattern Depending on the design philosophy of the home network, wall switches may be configured to directly control individual lamps or alternatively, all wall switches send control commands to a central lighting control computer which again sends out control commands to relevant devices. In a distributed system, the traffic tends to be multipoint-to- @@ -680,28 +681,26 @@ that need to be addressed. The wireless and distributed nature of these networks increases the spectrum of potential routing security threats. This is further amplified by the resource constraints of the nodes, thereby preventing resource-intensive routing security approaches from being deployed. A viable routing security approach SHOULD be sufficiently lightweight that it may be implemented across all nodes in a HC-LLN. These issues require special attention during the design process, so as to facilitate a commercially attractive deployment. - The HC-LLN MUST deny any node that has not been authenticated to - the HC-LLN and authorized to participate to the routing decision - process. - - An attacker SHOULD be prevented from manipulating or disabling the - routing function, for example, by compromising routing control - messages. To this end, the routing protocol(s) MUST support - message integrity. + An attacker can snoop, replay, or originate arbitrary messages to + a node in an attempt to manipulate or disable the routing + function. + To mitigate this, the HC-LLN MUST be able to authenticate a new + node prior to allowing it to participate in the routing decision + process. The routing protocol MUST support message integrity. Further examples of routing security issues that may arise are the abnormal behavior of nodes that exhibit an egoistic conduct, such as not obeying network rules or forwarding no or false packets. Other important issues may arise in the context of denial-of- service (DoS) attacks, malicious address space allocations, advertisement of variable addresses, a wrong neighborhood, etc. The routing protocol(s) SHOULD support defense against DoS attacks and other attempts to maliciously or inadvertently cause the mechanisms of the routing protocol(s) to over-consume the limited @@ -716,20 +715,27 @@ example, to cause DoS, drain the energy of power-constrained devices, or to hijack the routing mechanism. A node MUST authenticate itself to a trusted node that is already associated with the HC-LLN before the former can take part in self- configuration or self-organization. A node that has already authenticated and associated with the HC-LLN MUST deny, to the maximum extent possible, the allocation of resources to any unauthenticated peer. The routing protocol(s) MUST deny service to any node that has not clearly established trust with the HC- LLN. + In a home control environment, it is considered unlikely that a + network is constantly being snooped and at the same time, ease of + use is important. As a consequence the network key MAY be exposed + for short periods during inclusion of new nodes. + Electronic door locks and other critical applications SHOULD apply + end-to-end application security on top of the network transport + security. If connected to a backbone network, the HC-LLN SHOULD be capable of limiting the resources utilized by nodes in said backbone network so as not to be vulnerable to DoS. This should typically be handled by border routers providing access from a backbone network to resources in the HC-LLN. With low computation power and scarce energy resources, HC-LLNs' nodes may not be able to resist any attack from high-power malicious nodes (e.g., laptops and strong radios). However, the @@ -780,62 +786,60 @@ 9.1. Normative References [I-D.Vasseur-Terminology] Vasseur, JP. "Terminology in Low power And Lossy Networks", draft-vasseur-roll-terminology-02 (work in progress), October 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [I-D.Hui-HeaderCompression] Hui, J., "Compression Format for IPv6 - Datagrams in 6LoWPAN Networks ", draft-ietf-6lowpan-hc - (work in progress), December 2008. - 9.2. Informative References [RFC5548] Dohler, M., "Routing Requirements for Urban Low-Power and Lossy Networks", BCP 14, RFC 5548, May 2009. [I-D.Pister-Industial-reqs] Pister, K., "Industrial Routing Requirements in Low Power and Lossy Networks ", draft- ietf-roll-indus-routing-reqs (work in progress) [I-D.Martocci-Building-reqs] Martocci, J., "Building Automation Routing Requirements in Low Power and Lossy Networks ", draft-ietf-roll-building-routing-reqs (work in progress) [I-D.Levis-Protocols-survey] Lewis, P. "Overview of Existing Routing Protocols for Low Power and Lossy Networks", draft-ietf-roll-protocols-survey (work in progress) + [I-D.Hui-HeaderCompression] Hui, J., "Compression Format for IPv6 + Datagrams in 6LoWPAN Networks ", draft-ietf-6lowpan-hc + (work in progress), December 2008. + Author's Addresses Anders Brandt Sigma Designs, Inc. Emdrupvej 26 Copenhagen, DK-2100 Denmark - Email: abr@zen-sys.com + Email: abr@sdesigns.dk Jakob Buron Sigma Designs, Inc. Emdrupvej 26 Copenhagen, DK-2100 Denmark - Email: jbu@zen-sys.com + Email: jbu@sdesigns.dk Giorgio Porcu Telecom Italia Piazza degli Affari, 2 20123 Milan Italy - Email: giorgio.porcu@guest.telecomitalia.it - Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.