draft-ietf-roll-home-routing-reqs-00.txt | draft-ietf-roll-home-routing-reqs-01.txt | |||
---|---|---|---|---|
Networking Working Group A. Brandt | Networking Working Group A. Brandt | |||
Internet Draft Zensys, Inc. | Internet Draft Zensys, Inc. | |||
Intended status: Informational G. Porcu | Intended status: Informational G. Porcu | |||
Expires: November 2008 Telecom Italia | Expires: January 2009 Telecom Italia | |||
May 21, 2008 | July 4, 2008 | |||
Home Automation Routing Requirement in Low Power and Lossy Networks | Home Automation Routing Requirement in Low Power and Lossy Networks | |||
draft-ietf-roll-home-routing-reqs-00 | draft-ietf-roll-home-routing-reqs-01 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that | By submitting this Internet-Draft, each author represents that | |||
any applicable patent or other IPR claims of which he or she is | 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 | 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 | becomes aware will be disclosed, in accordance with Section 6 of | |||
BCP 79. | BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire on November 21, 2008. | This Internet-Draft will expire on January 4, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
Abstract | Abstract | |||
This document presents home control and automation application | This document presents home control and automation application | |||
specific requirements for ROuting in Low power and Lossy networks | specific requirements for ROuting in Low power and Lossy networks | |||
(ROLL). In a modern home, a high number of wireless devices are used | (ROLL). In a modern home, a high number of wireless devices are used | |||
skipping to change at page 2, line 22 | skipping to change at page 2, line 22 | |||
document are to be interpreted as described in RFC-2119 [RFC2119]. | document are to be interpreted as described in RFC-2119 [RFC2119]. | |||
Table of Contents | Table of Contents | |||
1. Terminology....................................................3 | 1. Terminology....................................................3 | |||
2. Introduction...................................................3 | 2. Introduction...................................................3 | |||
3. Home automation applications...................................4 | 3. Home automation applications...................................4 | |||
3.1. Turning off the house when leaving........................4 | 3.1. Turning off the house when leaving........................4 | |||
3.2. Energy conservation and optimizing energy consumption.....5 | 3.2. Energy conservation and optimizing energy consumption.....5 | |||
3.3. Moving a remote control around............................5 | 3.3. Moving a remote control around............................5 | |||
3.4. Adding a new lamp module to the system....................5 | 3.4. Adding a new lamp module to the system....................6 | |||
3.5. Controlling battery operated window shades................6 | 3.5. Controlling battery operated window shades................6 | |||
3.6. Remote video surveillance.................................6 | 3.6. Remote video surveillance.................................6 | |||
3.7. Healthcare................................................6 | 3.7. Healthcare................................................6 | |||
3.7.1. At-home health reporting.............................7 | 3.7.1. At-home health reporting.............................7 | |||
3.7.2. At-home health monitoring............................7 | 3.7.2. At-home health monitoring............................7 | |||
3.7.3. Healthcare routing considerations....................8 | 3.7.3. Healthcare routing considerations....................8 | |||
3.8. Alarm systems.............................................8 | 3.8. Alarm systems.............................................8 | |||
3.9. Battery-powered devices...................................8 | 3.9. Battery-powered devices...................................9 | |||
4. Unique requirements of home automation applications............9 | 4. Unique requirements of home automation applications............9 | |||
4.1. Support of groupcast......................................9 | 4.1. Support of groupcast......................................9 | |||
4.2. Metric-based Routing......................................9 | 4.2. Constraint-based Routing..................................9 | |||
4.3. Support of Mobility......................................10 | 4.3. Support of Mobility......................................10 | |||
4.4. Support of periodical scanning...........................10 | 4.4. Support of Periodical Scanning...........................10 | |||
4.5. Scalability..............................................10 | 4.5. Scalability..............................................11 | |||
4.6. Convergence Time.........................................11 | 4.6. Convergence Time.........................................11 | |||
4.7. Manageability............................................11 | 4.7. Manageability............................................11 | |||
5. Traffic pattern...............................................11 | 5. Traffic Pattern...............................................11 | |||
6. Open issues...................................................11 | 6. Open issues...................................................12 | |||
7. Security Considerations.......................................12 | 7. Security Considerations.......................................12 | |||
8. IANA Considerations...........................................12 | 8. IANA Considerations...........................................13 | |||
9. Acknowledgments...............................................12 | 9. Acknowledgments...............................................13 | |||
10. References...................................................12 | 10. References...................................................13 | |||
10.1. Normative References....................................12 | 10.1. Normative References....................................13 | |||
10.2. Informative References..................................12 | 10.2. Informative References..................................14 | |||
Author's Addresses...............................................13 | Disclaimer of Validity...........................................15 | |||
Intellectual Property Statement..................................13 | ||||
Disclaimer of Validity...........................................13 | ||||
1. Terminology | 1. Terminology | |||
ROLL: ROuting in Low-power and Lossy networks | ROLL: ROuting in Low-power and Lossy networks | |||
ROLL device: A ROLL network node with constrained CPU and memory | ||||
resources; potentially constrained power resources. | ||||
Access Point: The access point is an infrastructure device that | Access Point: The access point is an infrastructure device that | |||
connects the low power and lossy network system to the | connects the low power and lossy network system to the | |||
Internet, possibly via a customer premises local area | Internet, possibly via a customer premises local area | |||
network (LAN). | network (LAN). | |||
LAN: Local Area Network. | LAN: Local Area Network. | |||
PAN: Personal Area Network. | PAN: Personal Area Network. | |||
A geographically limited wireless network based on | A geographically limited wireless network based on | |||
e.g. 802.15.4 or Z-Wave radio. | e.g. 802.15.4 or Z-Wave radio. | |||
Channel: RF frequency band used to transmit a modulated signal | Channel: Radio frequency band used to transmit a modulated | |||
carrying packets. | signal carrying packets. | |||
Downstream: Data direction traveling from a LAN to a PAN device. | Downstream: Data direction traveling from a Local Area Network | |||
(LAN) to a Personal Area Network (PAN) device. | ||||
Upstream: Data direction traveling from a PAN to a LAN device. | Upstream: Data direction traveling from a PAN to a LAN device. | |||
RF: Radio Frequency. | ||||
Sensor: A PAN device that measures data and/or detects an | Sensor: A PAN device that measures data and/or detects an | |||
event. | event. | |||
HA: Home Automation. | ||||
2. Introduction | 2. Introduction | |||
This document presents the home control and automation application | This document presents the home control and automation application | |||
specific requirements for Routing in Low power and Lossy Networks | specific requirements for Routing in Low power and Lossy Networks | |||
(ROLL). In a modern home, a high number of wireless devices are used | (ROLL). In a modern home, a high number of wireless devices are used | |||
for a wide set of purposes. Examples include lighting control | for a wide set of purposes. Examples include lighting control | |||
modules, heating control panels, light sensors, temperature sensors, | modules, heating control panels, light sensors, temperature sensors, | |||
gas/water leak detectors, motion detectors, video surveillance, | gas/water leak detectors, motion detectors, video surveillance, | |||
healthcare systems and advanced remote controls. Basic home control | healthcare systems and advanced remote controls. Basic home control | |||
modules such as wall switches and plug-in modules may be turned into | modules such as wall switches and plug-in modules may be turned into | |||
skipping to change at page 4, line 29 | skipping to change at page 4, line 26 | |||
puts a limit to the physical size of the battery; and thus, the | 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- | 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 | style nodes to shut down radio and CPU resources for most of the | |||
time. Often, the radio uses the same power for listening as for | time. Often, the radio uses the same power for listening as for | |||
transmitting. | transmitting. | |||
Section 3. describes a few typical use cases for home automation | Section 3. describes a few typical use cases for home automation | |||
applications. Section 4. discusses the routing requirements for | applications. Section 4. discusses the routing requirements for | |||
networks comprising such constrained devices in a home network | networks comprising such constrained devices in a home network | |||
environment. These requirements may be overlapping requirements | environment. These requirements may be overlapping requirements | |||
derived from other application-specific requirements documents or as | derived from other application-specific requirements. | |||
listed in [I-D.culler-roll-routing-reqs]. | ||||
3. Home automation applications | 3. Home automation applications | |||
Home automation applications represent a special segment of networked | Home automation applications represent a special segment of networked | |||
wireless devices with its unique set of requirements. To facilitate | wireless devices with its unique set of requirements. To facilitate | |||
the requirements discussion in Section 4, this section lists a few | the requirements discussion in Section 4, this section lists a few | |||
typical use cases of home automation applications. New applications | typical use cases of home automation applications. New applications | |||
are being developed at a high pace and this section does not mean to | are being developed at a high pace and this section does not mean to | |||
be exhaustive. Most home automation applications tend to be running | be exhaustive. Most home automation applications tend to be running | |||
some kind of command/response protocol. The command may come from | some kind of command/response protocol. The command may come from | |||
skipping to change at page 5, line 12 | skipping to change at page 5, line 10 | |||
happen at the same time. A well-known problem in wireless home | happen at the same time. A well-known problem in wireless home | |||
automation is the "popcorn effect": Lamps are turned on one at a | 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 | time, at a rate so slow that it is clearly visible. Some existing | |||
home automation solutions use a clever mix of a "subnet groupcast" | home automation solutions use a clever mix of a "subnet groupcast" | |||
message with no acknowledgement and no forwarding before sending | message with no acknowledgement and no forwarding before sending | |||
acknowledged singlecast messages to each lighting device. | acknowledged singlecast messages to each lighting device. | |||
The controller forms the groups and decides which nodes should | The controller forms the groups and decides which nodes should | |||
receive "turn-off" or "turn-on" requests. | receive "turn-off" or "turn-on" requests. | |||
Thus, a solution is needed for addressing groups of nodes without | ||||
prior management of group membership in the receiving nodes. | ||||
3.2. Energy conservation and optimizing energy consumption | 3.2. Energy conservation and optimizing energy consumption | |||
Parts of the world using air conditioning may let shades go down and | Parts of the world using air conditioning may let shades go down and | |||
turn off the AC device when leaving home. Air conditioning may start | turn off the AC device when leaving home. Air conditioning may start | |||
by timer or via motion sensor when the owner returns home. The owner | by timer or via motion sensor when the owner returns home. The owner | |||
may even activate the air conditioning via cell phone before getting | may even activate the air conditioning via cell phone before getting | |||
home. | home. | |||
Geographical areas using central heating may turn off heating when | Geographical areas using central heating may turn off heating when | |||
not at home and use a reduced temperature during night time. | not at home and use a reduced temperature during night time. | |||
The power grid may experience periods where more wind-generated power | The power grid may experience periods where more wind-generated power | |||
is produced than is needed. Typically this may happen during night | is produced than is needed. Typically this may happen during night | |||
hours. The washing machine and dish washer may just as well work | hours. The washing machine and dish washer may just as well work | |||
while power is cheap. The electric car should also charge its | while power is cheap. The electric car should also charge its | |||
batteries on cheap power. | batteries on cheap power. | |||
Most of these applications are mains powered and may thus provide | In periods where electricity demands exceed available supply, | |||
reliable routing resources. | appliances such as air conditioning, climate control systems, washing | |||
machines etc. can be turned off to avoid overloading the power grid. | ||||
Wireless remote control of the household appliances is well-suited | ||||
for this application. The start/stop decision for the appliances can | ||||
be regulated by dynamic power pricing information obtained from the | ||||
electricity utility companies. | ||||
Most of these applications are mains powered and are thus ideal for | ||||
providing reliable, always-on routing resources. Battery-powered | ||||
nodes, by comparison, are constrained routing resources and may only | ||||
provide reliable routing under some circumstances. | ||||
3.3. Moving a remote control around | 3.3. Moving a remote control around | |||
A remote control is a typical example of a mobile device in a home | A remote control is a typical example of a mobile device in a home | |||
automation network. An advanced remote control may be used for | automation network. An advanced remote control may be used for | |||
dimming the light in the dining room while eating and later on, | dimming the light in the dining room while eating and later on, | |||
turning up the music while doing the dishes in the kitchen. Reaction | turning up the music while doing the dishes in the kitchen. Reaction | |||
must appear to be instant (within a few hundred milliseconds) even | must appear to be instant (within a few hundred milliseconds) even | |||
when the remote control has moved to a new location. The remote | when the remote control has moved to a new location. The remote | |||
control may be communicating to either a central home automation | control may be communicating to either a central home automation | |||
controller or directly to the lamps and the media center. | controller or directly to the lamps and the media center. | |||
3.4. Adding a new lamp module to the system | 3.4. Adding a new lamp module to the system | |||
Small-size, low-cost modules may have no user interface except for a | Small-size, low-cost modules may have no user interface except for a | |||
single button. Thus, an automated inclusion process is needed for | single button. Thus, an automated inclusion process is needed for | |||
controllers to find new modules. Inclusion covers the detection of | controllers to find new modules. Inclusion covers the detection of | |||
neighbors and assignment of a unique node ID. Inclusion should be | neighbors and assignment of a unique node ID. Inclusion should be | |||
completed within a few seconds. | completed within a few seconds. | |||
Distribution of unique addresses is usually performed by a central | ||||
controller. In this case, it must be possible to route the inclusion | ||||
request from the joining node to the central controller even before | ||||
the joining node is assigned a unique address. | ||||
3.5. Controlling battery operated window shades | 3.5. Controlling battery operated window shades | |||
In consumer premises, window shades are often battery-powered as | In consumer premises, window shades are often battery-powered as | |||
there is no access to mains power over the windows. For battery | there is no access to mains power over the windows. For battery | |||
conservation purposes, the receiver is sleeping most of the time. A | conservation purposes, the receiver is sleeping most of the time. A | |||
home automation controller sending commands to window shades via ROLL | home automation controller sending commands to window shades via ROLL | |||
resources will have no problems delivering the packet to the router, | devices will have no problems delivering the packet to the router, | |||
but the router will have to wait for some time before the command can | but the router may have to wait for some time before the command can | |||
be delivered to the window shades; e.g. up to 250ms. | be delivered to the window shades if the receiver is sleeping; e.g. | |||
up to 250ms. | ||||
3.6. Remote video surveillance | 3.6. Remote video surveillance | |||
Remote video surveillance is a fairly classic application for Home | Remote video surveillance is a fairly classic application for Home | |||
networking providing the ability for the end user to get a video | networking providing the ability for the end user to get a video | |||
stream from a Web Cam reached via the Internet, which can be | stream from a Web Cam reached via the Internet, which can be | |||
triggered by the end-user that has received an alarm from a movement | triggered by the end-user that has received an alarm from a movement | |||
sensor or smoke detector - or the user simply wants to check the home | sensor or smoke detector - or the user simply wants to check the home | |||
status via video. | status via video. | |||
Note that in the former case, more than likely, there will be a form | Note that in the former case, more than likely, there will be a form | |||
skipping to change at page 8, line 4 | skipping to change at page 8, line 14 | |||
Applications might include: | Applications might include: | |||
o Temperature | o Temperature | |||
o Weight | o Weight | |||
o Blood pressure | o Blood pressure | |||
o Insulin level | o Insulin level | |||
o ECG | ||||
o Electrocardiogram (ECG) | ||||
o Position tracker | o Position tracker | |||
3.7.3. Healthcare routing considerations | 3.7.3. Healthcare routing considerations | |||
From a ROLL perspective, all the above-mentioned applications may run | From a ROLL perspective, all the above-mentioned applications may run | |||
on battery. They may also be portable and therefore need to locate a | on battery. They may also be portable and therefore need to locate a | |||
new neighbor router on a frequent basis. | new neighbor router on a frequent basis. | |||
Not being powered most of the time, the nodes should not be used as | Not being powered most of the time, the nodes should not be used as | |||
routing nodes. However, sleeping, battery-powered nodes may be | routing nodes. However, sleeping, battery-powered nodes may be | |||
skipping to change at page 9, line 5 | skipping to change at page 9, line 16 | |||
most of them, most of the time, have prevention and monitoring | most of them, most of the time, have prevention and monitoring | |||
activity in which routing requirements are deterministic, but all of | activity in which routing requirements are deterministic, but all of | |||
them have an alarm state in which nodes may burst an aperiodic alarm. | them have an alarm state in which nodes may burst an aperiodic alarm. | |||
3.9. Battery-powered devices | 3.9. Battery-powered devices | |||
For convenience and low operational costs, power consumption of | For convenience and low operational costs, power consumption of | |||
consumer products must be kept at a very low level to achieve a long | consumer products must be kept at a very low level to achieve a long | |||
battery lifetime. One implication of this fact is that RAM memory is | battery lifetime. One implication of this fact is that RAM memory is | |||
limited and it may even be powered down; leaving only a few 100 bytes | limited and it may even be powered down; leaving only a few 100 bytes | |||
alive during the sleep phase. | of RAM alive during the sleep phase. | |||
4. Unique requirements of home automation applications | 4. Unique requirements of home automation applications | |||
Home automation applications have a number of specific requirements | Home automation applications have a number of specific requirements | |||
related to the set of home networking applications and the perceived | related to the set of home networking applications and the perceived | |||
operation of the system. | operation of the system. | |||
4.1. Support of groupcast | 4.1. Support of groupcast | |||
The routing protocol must provide the ability to route a packet | Groupcast, in the context of home automation, is defined as the | |||
towards a single device (unicast), a set of devices (also referred to | ability to simultaneously transmit a message to a group of recipients | |||
as "groupcast" in this document) or all devices (broadcast) in the | without prior interaction with the group members (i.e. group setup). | |||
house. | A use-case for groupcast is given in Section 3.1. | |||
Broadcast and groupcast in home automation MAY be used to deliver the | ||||
illusion that all recipients respond simultaneously. Distant | ||||
recipients out of direct range may not react to the (unacknowledged) | ||||
groupcast. Acknowledged unicast delivery MUST be used subsequently. | ||||
The support of unicast, groupcast and broadcast also has an | The support of unicast, groupcast and broadcast also has an | |||
implication on the addressing scheme and are outside the scope of | implication on the addressing scheme and are outside the scope of | |||
this document that focuses on the routing requirements aspects. | this document that focuses on the routing requirements aspects. | |||
It MUST be to possible to address a group of receivers known by the | It MUST be to possible to address a group of receivers known by the | |||
sender even if the receivers do not know that they have been grouped | sender even if the receivers do not know that they have been grouped | |||
by the sender. | by the sender. | |||
Alternatively, a companion specification SHOULD define how to | 4.2. Constraint-based Routing | |||
indirectly address a group of nodes on the application layer via | ||||
classic broadcast in the network layer; e.g. by use of a bitmap in a | ||||
header extension. | ||||
4.2. Metric-based Routing | ||||
[ABR NOTE: IETF-71 WG meeting indicated that the term "constrained" | ||||
has a very specific meaning in the routing community inside IETF. | ||||
What I understood was that the draft should be using the term | ||||
"metric-based routing"] | ||||
Simple battery-powered nodes such as movement sensors on garage doors | Simple battery-powered nodes such as movement sensors on garage doors | |||
and rain meters may not be able to assist in routing. Depending on | 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 | the node type, the node never listens at all, listens rarely or makes | |||
contact on demand to a pre-configured target node. Attempting to | contact on demand to a pre-configured target node. Attempting to | |||
communicate to such nodes may require long time before getting a | communicate to such nodes may require long time before getting a | |||
response. | response. | |||
Other battery-powered nodes may have the capability to participate in | Other battery-powered nodes may have the capability to participate in | |||
routing. The routing protocol should either share the load between | routing. The routing protocol should either share the load between | |||
nodes to preserve battery or only route via mains-powered nodes if | nodes to preserve battery or only route via mains-powered nodes if | |||
possible. The most reliable routing resource may be a battery-backed, | possible. The most reliable routing resource may be a battery-backed, | |||
mains-powered smoke alarm. | mains-powered smoke alarm. | |||
The routing protocol MUST support metric-based routing taking into | The routing protocol MUST support constraint-based routing taking | |||
account node properties (CPU, memory, level of energy, sleep | into account node properties (CPU, memory, level of energy, sleep | |||
intervals, safety/convenience of changing battery). | intervals, safety/convenience of changing battery). | |||
4.3. Support of Mobility | 4.3. Support of Mobility | |||
In a home environment, although the majority of devices are fixed | In a home environment, although the majority of devices are fixed | |||
devices, there is still a variety of mobile devices: for example a | devices, there is still a variety of mobile devices: for example a | |||
multi-purpose remote control is likely to move. Another example of | multi-purpose remote control is likely to move. Another example of | |||
mobile devices is wearable healthcare devices. | mobile devices is wearable healthcare devices. | |||
While healthcare devices delivering measurement results can tolerate | While healthcare devices delivering measurement results can tolerate | |||
route discovery times measured in seconds, a remote control appears | route discovery times measured in seconds, a remote control appears | |||
unresponsive if using more than 0.5 seconds to e.g. pause the music. | 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- | While, in theory, all battery-powered devices and mains-powered plug- | |||
in modules may be moved, the predominant case is that the sending | in modules may be moved, the predominant case is that the sending | |||
node has moved while the rest of the network has not changed. | node has moved while the rest of the network has not changed. | |||
The routing protocol MUST provide mobility with convergence time | The routing protocol MUST provide mobility with convergence time | |||
below 0.5 second if only the sender has moved. | below 0.5 second if only the sender has moved. | |||
The routing protocol SHOULD make use of the fact that if not being | A non-responsive node can either be caused by 1) a failure in the | |||
able to deliver a packet, it is most likely that the sending node | node, 2) a failed link on the path to the node or 3) a moved node. In | |||
moved; rather than the rest of the network. | 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. The search strategy in the routing | ||||
protocol will behave differently depending on this expectation. The | ||||
routing protocol SHOULD make use of the fact that if not being able | ||||
to deliver a packet, it is most likely that the sending node moved; | ||||
rather than a failure occurred in that node or in a link on the path | ||||
towards it. | ||||
4.4. Support of periodical scanning | 4.4. Support of Periodical Scanning | |||
The routing protocol MUST support the recognition of neighbors and | The routing protocol MUST support the recognition of neighbors and | |||
periodical scanning. This process SHOULD preserve energy capacity as | periodical scanning. This process SHOULD preserve energy capacity as | |||
much as possible. | much as possible. | |||
(Derived from use case 3.8. Alarm Systems) | (Derived from use case 3.8. Alarm Systems) | |||
4.5. Scalability | 4.5. Scalability | |||
Looking at the number of wall switches, power outlets, sensors of | Looking at the number of wall switches, power outlets, sensors of | |||
skipping to change at page 11, line 10 | skipping to change at page 11, line 19 | |||
quite realistic that hundreds of low power devices may form a home | quite realistic that hundreds of low power devices may form a home | |||
automation network in a fully populated "smart" home. Moving towards | automation network in a fully populated "smart" home. Moving towards | |||
professional building automation, the number of such devices may be | professional building automation, the number of such devices may be | |||
in the order of several thousands. | in the order of several thousands. | |||
Thus, the routing protocol MUST support 250 devices in a subnet. | Thus, the routing protocol MUST support 250 devices in a subnet. | |||
The routing protocol SHOULD support 2500 devices in a subnet. | The routing protocol SHOULD support 2500 devices in a subnet. | |||
4.6. Convergence Time | 4.6. Convergence Time | |||
A home automation PAN is subject to various instability due to signal | A home automation Personal Area Network (PAN) is subject to various | |||
strength variation, moving persons and the like. Furthermore, as the | instability due to signal strength variation, moving persons and the | |||
number of devices increases, the probability of a node failure also | like. Furthermore, as the number of devices increases, the | |||
increases. | probability of a node failure also increases. | |||
Measured from the transmission of a packet, the following convergence | Measured from the transmission of a packet, the following convergence | |||
time requirements apply. | time requirements apply. | |||
The routing protocol MUST converge within 0.5 second if no nodes have | The routing protocol MUST converge within 0.5 second if no nodes have | |||
moved. | moved. | |||
The routing protocol MUST converge within 2 seconds if the | The routing protocol MUST converge within 2 seconds if the | |||
destination node of the packet has moved. | destination node of the packet has moved. | |||
4.7. Manageability | 4.7. Manageability | |||
The ability of the home network to support auto-configuration is of | The ability of the home network to support auto-configuration is of | |||
the utmost importance. Indeed, most end users will not have the | the utmost importance. Indeed, most end users will not have the | |||
expertise and the skills to perform advanced configuration and | expertise and the skills to perform advanced configuration and | |||
troubleshooting. Thus the routing protocol designed for home PAN MUST | troubleshooting. Thus the routing protocol designed for home PAN MUST | |||
provide a set of features including 0 configuration of the routing | provide a set of features including zero-configuration of the routing | |||
protocol for a new node to be added to the network. | protocol for a new node to be added to the network. From ROLL | |||
perspective, zero-configuration means that a node can obtain an | ||||
address and join the network on its own, without human intervention. | ||||
Furthermore, a failing node MUST NOT have a global impact on the | The routing protocol MUST support the ability to isolate a | |||
routing protocol. The routing protocol SHOULD support the ability to | misbehaving node thus preserving the correct operation of overall | |||
isolate a misbehaving node thus preserving the correct operation of | network. | |||
overall network. | ||||
5. Traffic pattern | 5. Traffic Pattern | |||
Depending on the philosophy of the home network, wall switches may be | Depending on the philosophy of the home network, wall switches may be | |||
configured to directly control individual lamps or alternatively, all | configured to directly control individual lamps or alternatively, all | |||
wall switches send control commands to a central lighting control | wall switches send control commands to a central lighting control | |||
computer which again sends out control commands to relevant devices. | computer which again sends out control commands to relevant devices. | |||
In a distributed system, the traffic tends to be any-to-many. In a | 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. | centralized system, it is a mix of any-to-one and one-to-many. | |||
Wall switches only generate traffic when activated, which typically | ||||
happens from a one to tens of times per hour. | ||||
Remote controls have a similar transmit pattern to wall switches, but | ||||
are activated more frequently. | ||||
Temperature/air pressure/rain sensors send frames when queried by the | ||||
user or can be preconfigured to send measurements at fixed intervals | ||||
(typically minutes). Motion sensors typically send a frame when | ||||
motion is first detected and another frame when an idle period with | ||||
no movement has elapsed. The highest transmission frequency depends | ||||
on the idle period used in the sensor. Sometimes, a timer will | ||||
trigger a frame transmission when an extended period without status | ||||
change has elapsed. | ||||
All frames sent in the above examples are quite short, typically less | ||||
than 5 bytes of payload. Lost frames and interference from other | ||||
transmitters may lead to retransmissions. In all cases, | ||||
acknowledgment frames with a size of a few bytes are used. | ||||
6. Open issues | 6. Open issues | |||
Other items to be addressed in further revisions of this document | Other items to be addressed in further revisions of this document | |||
include: | include: | |||
o Load Balancing (Symmetrical and Asymmetrical) | o Load Balancing (Symmetrical and Asymmetrical) | |||
o Security | o Security | |||
7. Security Considerations | 7. Security Considerations | |||
TBD | Encryption can be employed to provide confidentiality, integrity and | |||
authentication of the messages carried on the wireless links. Adding | ||||
these capabilities to the ROLL devices will degrade energy efficiency | ||||
and increase cost, so a trade-off must be made for each specific | ||||
application. | ||||
Door locks, alarm sensors and medication dosage equipment are | ||||
examples where strong encryption and authentication are needed. The | ||||
command to unlock a door must be authenticated, as must the | ||||
communication between an alarm sensor and the central alarm | ||||
controller. Furthermore, traffic analysis of the alarm system | ||||
communication must not reveal if the alarm is activated. | ||||
Light dimmers, window shades, motion sensors, weight sensors etc. may | ||||
not need encryption. | ||||
Protection against unintentional inclusion in neighboring networks | ||||
must be provided. Providing confidentiality, integrity and | ||||
authentication against malicious opponents is optional. | ||||
8. IANA Considerations | 8. IANA Considerations | |||
This document includes no request to IANA. | This document includes no request to IANA. | |||
9. Acknowledgments | 9. Acknowledgments | |||
J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim and Mischa Dohler | ||||
are gratefully acknowledged for their contributions to this document. | ||||
This document was prepared using 2-Word-v2.0.template.dot. | This document was prepared using 2-Word-v2.0.template.dot. | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
10.2. Informative References | 10.2. Informative References | |||
[I-D.culler-roll-routing-reqs] | ||||
Vasseur, J. and D. Culler, "Routing Requirements for Low | ||||
Power And Lossy Networks", | ||||
draft-culler-roll-routing-reqs-* (work in progress). | ||||
Author's Addresses | Author's Addresses | |||
Anders Brandt | Anders Brandt | |||
Zensys, Inc. | Zensys, Inc. | |||
Emdrupvej 26 | Emdrupvej 26 | |||
Copenhagen, DK-2100 | Copenhagen, DK-2100 | |||
Denmark | Denmark | |||
Email: abr@zen-sys.com | Email: abr@zen-sys.com | |||
End of changes. 34 change blocks. | ||||
76 lines changed or deleted | 126 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |