Networking Working Group A. Brandt Internet-Draft Zensys Intended status: Informational JP. Vasseur Expires: January 7, 2008 Cisco Systems, Inc July 6, 2007 Home Automation Routing Requirement in Low Power and Lossy Networks draft-brandt-rl2n-home-routing-reqs-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other 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 January 7, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document presents the home control and automation application specific requirements for Routing in Low power and Lossy Networks (RL2N). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include lighting control modules, heating control panels, light sensors, temperature sensors, gas/water leak detector, motion detectors, video surveillance, healthcare systems and advanced remote controls. Because such Brandt & Vasseur Expires January 7, 2008 [Page 1] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 devices only cover a limited radio range, multi-hop routing is often required. Such devices are usually highly constrained in terms of resources such as battery and memory and operate in unstable environments. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home network environment. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Home automation applications . . . . . . . . . . . . . . . . . 3 3.1. Turning off the house . . . . . . . . . . . . . . . . . . 4 3.2. Moving a remote control around . . . . . . . . . . . . . . 4 3.3. Adding a new lamp module to the system . . . . . . . . . . 4 3.3.1. Register lamp with portable remote control . . . . . . 4 3.3.2. Register lamp with central light controller; then place lamp . . . . . . . . . . . . . . . . . . . . . . 5 3.3.3. Register lamp outlet and wall switch with light controller . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Remote video surveillance . . . . . . . . . . . . . . . . 5 3.5. Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Alarm systems . . . . . . . . . . . . . . . . . . . . . . 6 4. Unique requirements of home automation applications . . . . . 6 4.1. Support of groupcast . . . . . . . . . . . . . . . . . . . 6 4.2. Node constrained Routing . . . . . . . . . . . . . . . . . 7 4.3. Support of Mobility . . . . . . . . . . . . . . . . . . . 7 4.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Convergence Time . . . . . . . . . . . . . . . . . . . . . 7 4.6. Delay Tolerant Networks . . . . . . . . . . . . . . . . . 8 4.7. Manageability . . . . . . . . . . . . . . . . . . . . . . 8 5. Traffic pattern . . . . . . . . . . . . . . . . . . . . . . . 8 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Brandt & Vasseur Expires January 7, 2008 [Page 2] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 1. Terminology L2N: Low power and Lossy Network. RL2N: Routing in Low power and Lossy Networks. 2. Introduction This document presents the home control and automation application specific requirements for Routing in Low power and Lossy Networks (RL2N). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include lighting control modules, heating control panels, light sensors, temperature sensors, gas/water leak detector, motion detectors, video surveillance, healthcare systems and advanced remote controls. Basic home control modules such as wall switches and plug-in modules may be turned into an advanced home automation solution via the use of an IP-enabled application reading wall switches, motion sensors, light sensors, rain sensors, and so on. Because such devices only cover a limited radio range, multi-hop 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 vacuum cleaner affect reception of weak radio signals. Reflection and absorption may cause a reliable connection to turn unreliable for a period of time and then being reusable again, thus the term "lossy". Section 3 describes a few typical use cases for home automation applications. Section 4 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 requirements documents or as listed in [I-D.culler-rl2n-routing-reqs]. 3. Home automation applications Home automation applications represent a special segment of networked wireless devices with its unique set of requirements. To facilitate the requirements discussion in Section 4, this section lists a few typical use cases of home automation applications. New applications are being developed at a high pace and this section does not mean to be exhaustive. Brandt & Vasseur Expires January 7, 2008 [Page 3] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 3.1. Turning off the house Using the direct analogy to an electronic car key, a house owner may stand at the gate and activate the "leaving home" function from his/ her 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 home automation is the "popcorn effect": Lamps are turned on one at a time, at a rate so slow that it is clearly visible. Obviously, this mostly apply to very low bandwidth RF systems. Some existing home automation solutions use a clever mix of a "subnet groupcast" message with no acknowledgement and no forwarding before sending acknowledged singlecast messages to each lighting device. Broadcast packets cannot be used for this since some lights should stay on (thus traditional IP multicast cannot be used for such applications). The light controller forms the groups and decides which light modules should receive "turn-off" or "turn-on" requests. 3.2. Moving a remote control around Advanced multi-function remote control may be used for dimming the light in the dining room while eating, turning up the music while doing the dishes in the kitchen and then, later on, turn lights down and start a DVD in the home theater. The music is stopped at the same time. Reaction must appear to be instant (within a few hundreds of milliseconds) even when the remote control has moved to a new location. Devices that needed routing to be reached before may be accessible directly now and vice versa. A remote control is a typical example of mobile device in a home network. 3.3. Adding a new lamp module to the system This apparently simple action may be addressed in a number of ways, depending on philosophy. The main issue is that the small-size, low- cost modules may have no user interface except for a single button. Thus, an automated inclusion process is needed for light controllers to find new modules. 3.3.1. Register lamp with portable remote control A remote control may control all lamps in the house. The new lamp module is powered at its final location. A discovery mechanism (potentially based on a broadcast-based protocol) makes the remote control discover the new module within direct range. The user sets up rules in the remote control for control of the lamp module. The lamp module being powered up at the final location triggers routing update. But because the (portable) remote control goes to sleep just after the last communication, the routers cannot determine the Brandt & Vasseur Expires January 7, 2008 [Page 4] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 location of the remote control by probing for it. 3.3.2. Register lamp with central light controller; then place lamp In this scenario a central light controller controls all lamps in the house. The new lamp module is powered within direct range of the light controller. A discovery (potentially based on a broadcast- based protocol) makes the light controller discover the new module. The user sets up rules in the light controller for control of the lamp module. Then the lamp module is placed at its final location. The lamp module being powered up at the final location causes routers to update routes. 3.3.3. Register lamp outlet and wall switch with light controller In this scenario, a central light controller is still used to controls all lamps in the house. It is practical to mount an outlet and get it registered at the same time. The same applies to wall switches. The wall switch may be out of direct range of the lamp module. At least two scenarios can be envisioned: 3.3.3.1. Installer controller used to set up rules A special portable controller is used to first discover the lamp outlet and the wall switch locally, i.e. within direct reach of their respective locations. Then rules are set up in the light controller for the new lamp outlet and wall switch. The lamp module being powered up at the final location triggers routing updates. 3.3.3.2. Global discovery The lamp outlet and wall switch devices announce themselves to the network. If already armed for an inclusion, routers carry the announcement to the light controller. Then rules are set up in the light controller for the new lamp outlet and wall switch. The lamp module being powered up at the final location triggers routing updates. 3.4. Remote video surveillance Remote video surveillance is a fairly classic application for Home networking providing the ability for the end user to get a video stream from a Web Cam reached via the Internet, which can either be triggered by the end-user that has received an alarm from a movement sensor, smoke detector or that simply wants to check the home status via video. Note that in the former case, more than likely, there will be a form of inter-device communication: indeed, upon detecting some movement in the home, the movement sensor may send a request to Brandt & Vasseur Expires January 7, 2008 [Page 5] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 the light controller to turn-on the lights, to the Web Cam to start a video stream that would then be directed to the end user (cell phone, PDA) via the Internet. By contrast with other application where for example a large number of L2N devices such as industrial sensors where the data would mainly be originated by sensor to a sink and vice versa, in such scenario there is a direct inter-device communication between L2N devices. 3.5. Healthcare This section will be documented in further revision of this document. 3.6. Alarm systems This section will be documented in further revision of this document. 4. Unique requirements of home automation applications Home automation applications have a number of specific requirements related to the set of home networking applications and the perceived operation of the system. 4.1. Support of groupcast Some home automation systems require low-level addressing of a group of nodes in the same subnet without any prior creation of multicast groups, simply carrying a list of recipients in the subnet. The routing protocol MUST support multicast routing with various scopes: local subnet, all devices. In other words, the routing protocol MUST provide the ability to route a packet toward a single device (unicast), a set of devices (also referred to as "groupcast" in this document) or all devices (multicast) in the house. The support of unicast, groupcast and multicast also has an implication on the addressing scheme and are outside the scope of this document that focusses on the routing requirements aspects. Note: with IP Multicast, signalling mechanisms are used by a receivers to join a group and the sender does not necessarily know the receivers of the group. What is required is the ability to address a group of receivers known by the sender even if the receivers do not need to know that they have been grouped by the sender (requesting each individual node to join a multicast group would be very impractical). Brandt & Vasseur Expires January 7, 2008 [Page 6] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 4.2. Node constrained Routing Simple battery-powered nodes such as movement sensors on garage doors and rain meters may not be able to assist in routing. Depending on the node type, the node never listens at all, listens rarely or makes contact on demand to a pre-configured target node. Attempting to communicate to such nodes may require long time before getting a response. Other battery-powered node may have the capability to participate to the routing protocol but it may be preferable to choose a (potentially longer) route via non battery powered devices or via battery powered that have more energy. The routing protocol MUST support constained based routing taking into account node properties (CPU, memory, level of energy). 4.3. 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. The routing protocol MUST provide mobility with convergence time within a few hundreds of milli-seconds. 4.4. Scalability Looking at the number of wall switches, power outlets, sensor of various nature, video equipments and so on in a modern house, it seems quite realistic that hundreds 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 on the order of several thousands. Thus the routing protocol MUST be highly scalable supporting a large number of devices (at least a few hundreds of devices). 4.5. Convergence Time Home automation is clearly an L2N subject to various instability due to signal strength variation. Furthermore, as the number of (battery powered) devices increases, the probability of node failures also increases. In all cases, response time of the order of a few hundreds of milliseconds are required, implying that the routing protocol MUST converge (provide alternate routes upon link or node failure) within a few hundreds of milliseconds. Brandt & Vasseur Expires January 7, 2008 [Page 7] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 4.6. Delay Tolerant Networks TBD. 4.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 L2N MUST provide a set of features including 0 configuration of the routing protocol for a new node to be added to the network. Furthermore, a misbehaving node MUST NOT have a global impact on the routing protocol. The routing protocol SHOULD support the ability to isolate a misbehaving node thus preserving the correct operation of overall network. 5. Traffic pattern Depending on the 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 light devices. In a distributed system, the traffic tends to be any-to- many. In a centralized system, it is a mix of any-to-one and one-to- many. A centralized system may benefit from a tree topology routing strategy; having the central light controller close to the root. A tree topology may prove inefficient for nodes in a distributed system. A direct path from sender to receiver may be significantly shorter than a path following the tree. A shorter path means lower latency and less air-time use in a wireless media. Thus, routers MUST provide efficient any-to-many routing and MUST also support any- to-any routing without having to transit via a central point (e.g. tree root) which would unavoidably lead to sub-optimal path in term of latency and energy consumption. 6. Open issues Other items to be addressed in further revisions of this document include: * Mobility and traffic pattern, Brandt & Vasseur Expires January 7, 2008 [Page 8] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 * Load Balancing (Symmetrical and Asymmetrical), * Security. 7. IANA Considerations This document includes no request to IANA. 8. Security Considerations TBD 9. Acknowledgements 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Cullerot, "Routing Requirements for Low-Power Wireless Networks", draft-culler-rl2n-routing-reqs-00 (work in progress), July 2007. Authors' Addresses A Brandt Zensys Emdrupvej 26 Copenhagen, Denmark DK-2100 Email: abr@zen-sys.com Brandt & Vasseur Expires January 7, 2008 [Page 9] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com Brandt & Vasseur Expires January 7, 2008 [Page 10] Internet-Draft draft-brandt-rl2n-home-routing-reqs-01 July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Brandt & Vasseur Expires January 7, 2008 [Page 11]