Networking Working Group JP. Vasseur
Internet-Draft Zensys
Intended status: Informational JP. Vasseur
Expires: January 1, 2008 Cisco Systems, Inc
June 30, 2007
Routing Requirement in Low Power and Lossy Networks in Home automation
requirements for RL2N-routing
draft-brandt-rl2n-home-routing-reqs-00
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 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document presents application specific requirements for Routing
in Low power and Loosy Networks (RL2N). The scope of this document
is home control and home automation. 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
Vasseur & Vasseur Expires January 1, 2008 [Page 1]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
detectors, video surveillance, healthcare systems and advanced remote
controls. Because such 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Home automation applications . . . . . . . . . . . . . . . . . 4
3.1. Turning off the house . . . . . . . . . . . . . . . . . . 5
3.2. Moving a remote control around . . . . . . . . . . . . . . 5
3.3. Adding a new lamp module to the system . . . . . . . . . . 5
3.3.1. Register lamp with portable remote control . . . . . . 5
3.3.2. Register lamp with central light controller; then
place lamp . . . . . . . . . . . . . . . . . . . . . . 6
3.3.3. Register lamp outlet and wall switch with light
controller . . . . . . . . . . . . . . . . . . . . . . 6
3.3.4. Alarm systems . . . . . . . . . . . . . . . . . . . . 6
3.3.5. Remote video surveillance . . . . . . . . . . . . . . 6
3.3.6. Healthcare . . . . . . . . . . . . . . . . . . . . . . 6
4. Unique requirements of home automation applications . . . . . 7
4.1. Support of groupcast . . . . . . . . . . . . . . . . . . . 7
4.2. Node constrained Routing . . . . . . . . . . . . . . . . . 7
4.3. Support of Mobility . . . . . . . . . . . . . . . . . . . 7
4.4. Quality of Service (QoS) Routing . . . . . . . . . . . . . 8
4.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Convergence Time . . . . . . . . . . . . . . . . . . . . . 8
4.7. Delay Tolerant Networks . . . . . . . . . . . . . . . . . 8
4.8. Manageability . . . . . . . . . . . . . . . . . . . . . . 8
5. Traffic pattern . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 10
Vasseur & Vasseur Expires January 1, 2008 [Page 2]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Vasseur & Vasseur Expires January 1, 2008 [Page 3]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
1. Terminology
L2N: Low power and Lossy Network.
RL2N: Routing in Low power and Lossy Networks.
2. Introduction
This document presents application specific requirements for routing
in low power and lossy networks (RL2N). The scope of this document
is home control and home automation. 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 restored again, thus the term "lossy".
Section 3 describes common 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-rsn-routing-reqs].
3. Home automation applications
Home automation applications represent a special segment of networked
wireless devices. 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.
Vasseur & Vasseur Expires January 1, 2008 [Page 4]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 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.
Consequently, 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.
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
location of the remote control by probing for it.
Vasseur & Vasseur Expires January 1, 2008 [Page 5]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
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.3.4. Alarm systems
This section will be documented in further revision of this document.
3.3.5. Remote video surveillance
This section will be documented in further revision of this document.
3.3.6. Healthcare
This section will be documented in further revision of this document.
Vasseur & Vasseur Expires January 1, 2008 [Page 6]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
4. Unique requirements of home automation applications
Home automation applications have a number of specific requirements
related to the perceived operation of the system.
4.1. Support of groupcast
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, a set of devices or all devices in the house.
It may be discussed how to achieve group addressing with IP
addressing schemes. 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. Thus the routing protocol MUST support the ability to
route a packet destined to a single device, a set of devices or all
devices.
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 will be very impractical):
this is referred to as "groupcast" mechanism in this document.
4.2. Node constrained Routing
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.
The routing engine MUST be aware of special node properties caused
for example by battery conservation. Thus the routing process MUST
support node constrained routing.
4.3. Support of Mobility
In a residential home environment, although the majority of devices
are fixed devices, there is still a variety of mobile devices: for
example a remote control used for multiple purposes is likely to
move. Another example of mobile devices is wearable healthcare
devices.
Vasseur & Vasseur Expires January 1, 2008 [Page 7]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
The routing protocol MUST provide mobility with convergence time
within a few hundreds of milli-seconds.
4.4. Quality of Service (QoS) Routing
Home networks typically hosts a variety of applications such as FTP,
HTTP, and so on as well as home automation traffic. It is expected
to see in such networks several classes of services. Although is
most cases a single topology supporting several classes of services
may be sufficient, the support of traffic substantially differing in
nature (e.g. Low priority high volume traffic such as email with
high priority low volume traffic for alarm detection) may require for
the routing protocol to support more than one topologies.
RL2N MAY provide the ability to support multi-topology routing.
4.5. Scalability
Looking at the number of wall switches and power outlets 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.
4.6. 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 failure may also
increase. 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.7. Delay Tolerant Networks
TBD.
4.8. Manageability
TBD
Vasseur & Vasseur Expires January 1, 2008 [Page 8]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
5. Traffic pattern
Depending on the philosophy of the home automation system, 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 one-to-
one and one-to-many.
6. Open issues
Other items to be addressed in further revisions of this document
include:
* Mobility and traffic pattern,
* 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
[I-D.ietf-pce-pcep]
Roux, J. and J. Vasseur, "Path Computation Element (PCE)
communication Protocol (PCEP)", draft-ietf-pce-pcep-07
(work in progress), March 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Vasseur & Vasseur Expires January 1, 2008 [Page 9]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 2007
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
10.2. Informative References
[I-D.culler-rsn-routing-reqs]
Cullerot, D. and J. Vasseur, "Routing Requirements for
Sensor Networks", draft-culler-rsn-routing-reqs-00 (work
in progress), April 2007.
Authors' Addresses
A Brandt
Zensys
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
Vasseur & Vasseur Expires January 1, 2008 [Page 10]
Internet-Draft draft-brandt-rl2n-home-routing-reqs-00 June 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).
Vasseur & Vasseur Expires January 1, 2008 [Page 11]