Networking Working Group A. Brandt
Internet-Draft Zensys, Inc.
Intended status: Informational JP. Vasseur
Expires: May 15, 2008 Cisco Systems, Inc
November 12, 2007
Home Automation Routing Requirement in Low Power and Lossy Networks
draft-brandt-rl2n-home-routing-reqs-02
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 May 15, 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 May 15, 2008 [Page 1]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 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 . . . . . . . . . . . . . . . . . 4
3.1. Turning off the house . . . . . . . . . . . . . . . . . . 4
3.2. Moving a remote control around . . . . . . . . . . . . . . 5
3.3. Adding a new lamp module to the system . . . . . . . . . . 5
3.4. Controlling battery operated window shades . . . . . . . . 5
3.5. Networked smoke alarm . . . . . . . . . . . . . . . . . . 5
3.6. Remote video surveillance . . . . . . . . . . . . . . . . 6
3.7. Healthcare . . . . . . . . . . . . . . . . . . . . . . . . 6
3.8. 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 . . . . . . . . . . . . . . . . . . . . . 8
4.6. Manageability . . . . . . . . . . . . . . . . . . . . . . 8
5. Traffic pattern . . . . . . . . . . . . . . . . . . . . . . . 8
6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
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 May 15, 2008 [Page 2]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
1. Terminology
L2N: Low power and Lossy Network.
RL2N: Routing in Low power and Lossy Networks.
Access Point: The access point is an infrastructure device that
connects the low power and lossy network system to the Internet,
possibly via a customer premises local area network (LAN).
LAN: Local Area Network.
PAN: Personal Area Network. A geographically limited wireless
network based on e.g. 802.15.4 or Z-Wave radio.
Channel: RF frequency band used to transmit a modulated signal
carrying packets.
Downstream: Data direction traveling from the LAN to the PAN device.
Upstream: Data direction traveling from the PAN device to the LAN.
RF: Radio Frequency.
Sensor: A PAN device that measures data and/or detects an event.
HA: Home Automation.
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 responding to events generated by 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 microwave oven affect
Brandt & Vasseur Expires May 15, 2008 [Page 3]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
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".
Unlike other categories of RL2N, the connected home area is very much
consumer-oriented. The implications on network nodes in this aspect,
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 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. Often, the radio uses almost just as much power for listening
as for transmitting.
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. Most home automation applications tend to be running
some kind of command/response protocol. The command may come from
several places. For instance a lamp may be turned on, not only be a
wall switch but also from a movement sensor.
3.1. Turning off the house
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. 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
Brandt & Vasseur Expires May 15, 2008 [Page 4]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
cannot be used for this since some lights should stay on. The light
controller forms the groups and decides which light modules should
receive "turn-off" or "turn-on" requests. Thus, traditional IP
multicast cannot be used for such applications, since multicast
relies on the recivers to subscribe to multicasted streams.
3.2. Moving a remote control around
A remote control is a typical example of a mobile device in a home
automation network. An advanced remote control may be used for
dimming the light in the dining room while eating and later on,
turning up the music while doing the dishes in the kitchen. Reaction
must appear to be instant (within a few hundred milliseconds) even
when the remote control has moved to a new location. The remote
control may be communicating to either a central home automation
controller or directly to the lamps and the media center. The
routing protocol MUST support multiple paths. The routing protocol
MUST be able to locate a working path within 250ms, given that a
working path exists and it has been used before.
3.3. Adding a new lamp 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
light controllers to find new modules. The routing protocol MUST
support re-discovery of neighbors when a new device is added to the
network. The routing protocol MAY scan for neighbors on a frequent
basis. This scanning process MUST NOT use significant network
bandwidth resources.
3.4. 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, the receiver is sleeping most of the time. A
home automation controller sending commands to window shades via RL2N
resources will have no problems delivering the packet to the router,
but the router will have to wait for some time before the command can
be delivered to the window shades; e.g. up to 250ms.
3.5. Networked smoke alarm
Many smoke alarms are battery powered and at the same time mounted in
a high place. Battery-powered safety devices should only be used for
routing if no other alternatives exist. A smoke alarm with a drained
battery does not provide a lot of safety. Also, it may be
inconvenient to exchange battery in a smoke alarm. Finally, routing
via battery-powered nodes may be very slow if they are sleeping most
Brandt & Vasseur Expires May 15, 2008 [Page 5]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
of the time .
3.6. 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
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.7. Healthcare
This section will be documented in further revision of this document.
3.8. 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
Brandt & Vasseur Expires May 15, 2008 [Page 6]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
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).
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 constrained based routing taking
into account node properties (CPU, memory, level of energy, sleep
intervals, safety/convenience of changing battery).
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 hundred milli-seconds.
4.4. Scalability
Looking at the number of wall switches, power outlets, sensor 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.
Brandt & Vasseur Expires May 15, 2008 [Page 7]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
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.
4.6. 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
Brandt & Vasseur Expires May 15, 2008 [Page 8]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
of latency and energy consumption.
6. Open issues
Other items to be addressed in further revisions of this document
include:
* 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 And Lossy Networks",
draft-culler-rl2n-routing-reqs-01 (work in progress),
July 2007.
Brandt & Vasseur Expires May 15, 2008 [Page 9]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 2007
Authors' Addresses
A Brandt
Zensys, Inc.
Emdrupvej 26
Copenhagen, Denmark DK-2100
Email: abr@zen-sys.com
JP Vasseur
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Brandt & Vasseur Expires May 15, 2008 [Page 10]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-02 November 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 May 15, 2008 [Page 11]