draft-ietf-roll-home-routing-reqs-06.txt   draft-ietf-roll-home-routing-reqs-07.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: May 2009 Telecom Italia Expires: March 2010 Telecom Italia
November 19, 2008 September 14, 2009
Home Automation Routing Requirements in Low Power and Lossy Home Automation Routing Requirements in Low Power and Lossy
Networks Networks
draft-ietf-roll-home-routing-reqs-06 draft-ietf-roll-home-routing-reqs-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with
any applicable patent or other IPR claims of which he or she is the provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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 May 19, 2009. This Internet-Draft will expire on March 14, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-
info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Abstract Abstract
This document presents home control and automation application This document presents home control and automation application
specific requirements for Routing Over Low power and Lossy specific requirements for Routing Over Low power and Lossy
networks (ROLL). In a modern home, a high number of wireless networks (ROLL). In the near future many homes will contain high
devices are used for a wide set of purposes. Examples include numbers of wireless devices for a wide set of purposes. Examples
actuators (relay, light dimmer, heating valve), sensors (wall include actuators (relay, light dimmer, heating valve), sensors
switch, water leak, blood pressure) and advanced controllers. (wall switch, water leak, blood pressure) and advanced controllers
Because such devices only cover a limited radio range, routing is (RF-based AV remote control, Central server for light and heat
often required. The aim of this document is to specify the routing control). Because such devices only cover a limited radio range,
requirements for networks comprising such constrained devices in a routing is often required. The aim of this document is to specify
home control and automation environment. the routing requirements for networks comprising such constrained
devices in a home control and automation environment.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC-2119 in this document are to be interpreted as described in RFC-2119
[RFC2119]. [RFC2119].
Table of Contents Table of Contents
Terminology......................................................3 1. Introduction..............................................4
1. Introduction..................................................5 1.1. Terminology...........................................5
2. Home Automation Applications..................................6 2. Home Automation Applications...............................6
2.1. Lighting Application In Action...........................6 2.1. Lighting Application In Action.........................6
2.2. Energy Conservation and Optimizing Energy Consumption....6 2.2. Energy Conservation and Optimizing Energy Consumption...7
2.3. Moving a Remote Control Around...........................7 2.3. Moving a Remote Control Around.........................7
2.4. Adding A New Module To The System........................7 2.4. Adding A New Module To The System......................8
2.5. Controlling Battery Operated Window Shades...............8 2.5. Controlling Battery Operated Window Shades..............8
2.6. Remote Video Surveillance................................8 2.6. Remote Video Surveillance..............................8
2.7. Healthcare...............................................8 2.7. Healthcare............................................8
2.7.1. At-home Health Reporting............................9 2.7.1. At-home Health Reporting..........................9
2.7.2. At-home Health Monitoring...........................9 2.7.2. At-home Health Monitoring........................10
2.8. Alarm Systems............................................9 2.8. Alarm Systems........................................10
3. Unique Routing Requirements of Home Automation Applications..10 3. Unique Routing Requirements of Home Automation Applications.11
3.1. Constraint-based Routing................................11 3.1. Constraint-based Routing..............................11
3.2. Support of Mobility.....................................12 3.2. Support of Mobility..................................12
3.3. Sleeping Nodes..........................................12 3.3. Sleeping Nodes.......................................13
3.4. Healthcare Routing......................................12 3.4. Healthcare Routing...................................13
3.5. Scalability.............................................13 3.5. Scalability..........................................13
3.6. Convergence Time........................................13 3.6. Convergence Time.....................................14
3.7. Manageability...........................................13 3.7. Manageability........................................14
3.8. Stability...............................................14 3.8. Stability............................................14
4. Traffic Pattern..............................................14 4. Traffic Pattern...........................................14
5. Open Issues..................................................14 5. Security Considerations...................................15
6. Security Considerations......................................15 6. IANA Considerations.......................................17
7. IANA Considerations..........................................15 7. Acknowledgments...........................................17
8. Acknowledgments..............................................15 8. References...............................................17
9. References...................................................15 8.1. Normative References.................................17
9.1. Normative References....................................15 8.2. Informative References...............................18
9.2. Informative References..................................16 Disclaimer of Validity...............Error! Bookmark not defined.
Disclaimer of Validity..........................................17
Terminology 1. Introduction
This document presents home control and automation application
specific requirements for Routing Over Low power and Lossy
networks (ROLL). In the near future many homes will contain high
numbers of wireless devices for a wide set of purposes. Examples
include actuators (relay, light dimmer, heating valve), sensors
(wall switch, water leak, blood pressure) and advanced
controllers. Basic home control modules such as wall switches and
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.
Network nodes may be sensors and actuators at the same time. An
example is a wall switch for replacement in existing homes. The
push buttons may generate events for a controller node or for
activating other actuator nodes. At the same time, a built-in
relay may act as actuator for a controller or other remote
sensors.
Because ROLL nodes only cover a limited radio range, routing is
often required. These devices are usually highly constrained in
term of resources such as battery and memory and operate in
unstable environments. Persons moving around in a house, opening
or closing a door or starting a microwave oven affect the
reception of weak radio signals. Reflection and absorption may
cause a reliable radio link to turn unreliable for a period of
time and then being reusable again, thus the term "lossy". All
traffic in a ROLL network is carried as IPv6 packets.
Unlike other categories of Personal Area Networks (PANs), the
connected home area is very much consumer-oriented. The
implication on network nodes is that devices are very cost
sensitive, which leads to resource-constrained environments having
slow CPUs and small memory footprints. At the same time, nodes
have to be physically small which puts a limit to the physical
size of the battery; and thus, the battery capacity. As a result,
it is common for low-power sensor-style nodes to shut down radio
and CPU resources for most of the time. The radio tends to use the
same power for listening as for transmitting
Section 2 describes a few typical use cases for home automation
applications. Section 3 discusses the routing requirements for
networks comprising such constrained devices in a home network
environment. These requirements may be overlapping requirements
derived from other application-specific routing requirements
presented in [I-D.Martocci-Building-reqs], [I-D.Pister-Industial-
reqs] and [RFC5548].
A full list of requirements documents may be found in section 9.
1.1. Terminology
ROLL: Routing Over Low-power and Lossy networks ROLL: Routing Over Low-power and Lossy networks
A ROLL node may be classified as sensor, actuator A ROLL node may be classified as sensor, actuator
or controller. or controller.
Actuator: Network node which performs some physical action. Actuator: Network node which performs some physical action.
Dimmers and relays are examples of actuators. Dimmers and relays are examples of actuators.
If sufficiently powered, actuator nodes may If sufficiently powered, actuator nodes may
participate in routing network messages. participate in routing network messages.
skipping to change at page 4, line 27 skipping to change at page 5, line 41
DR: Demand-Response DR: Demand-Response
The mechanism of users adjusting their power The mechanism of users adjusting their power
consumption in response to actual pricing of power. consumption in response to actual pricing of power.
DSM: Demand Side Management DSM: Demand Side Management
Process allowing power utilities to enable and Process allowing power utilities to enable and
disable loads in consumer premises. Where DR relies disable loads in consumer premises. Where DR relies
on voluntary action from users, DSM may be based on on voluntary action from users, DSM may be based on
enrollment in a formal program. enrollment in a formal program.
HC-LLN: Home Control in Low-Power and Lossy Networks
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.
PDA Personal Digital Assistant. A small, handheld PDA Personal Digital Assistant. A small, handheld
computer. computer.
PLC Power Line Communication PLC Power Line Communication
RAM Random Access Memory RAM Random Access Memory
Sensor: Network node that measures some physical parameter
Sensor: Network node that measures data and/or detects an and/or detects an event.
event.
The sensor may generate a trap message to notify a The sensor may generate a trap message to notify a
controller or directly activate an actuator. controller or directly activate an actuator.
If sufficiently powered, sensor nodes may If sufficiently powered, sensor nodes may
participate in routing network messages. participate in routing network messages.
Upstream: Data direction traveling from a PAN to a LAN Upstream: Data direction traveling from a PAN to a LAN
device. device.
Refer to the roll-terminology reference document for a full list Refer to the roll-terminology reference document [I-D.Vasseur-
of terms used in the IETF ROLL WG (I-D.draft-ietf-roll-terminology). Terminology] for a full list of terms used in the IETF ROLL WG.
1. Introduction
This document presents home control and automation application
specific requirements for Routing Over Low power and Lossy
networks (ROLL). In a modern home, a high number of wireless
devices are used for a wide set of purposes. Examples include
actuators (relay, light dimmer, heating valve), sensors (wall
switch, water leak, blood pressure) and advanced controllers.
Basic home control modules such as wall switches and 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.
Network nodes may be sensors and actuators at the same time. An
example is a wall switch for replacement in existing buildings.
The push buttons may generate events for a controller node or for
activating other actuator nodes. At the same time, a built-in
relay may act as actuator for a controller or other remote
sensors.
Because ROLL nodes only cover a limited radio range, routing is
often required. These devices are usually highly constrained in
term of resources such as battery and memory and operate in
unstable environments. Persons moving around in a house, opening
or closing a door or starting a microwave oven affect the
reception of weak radio signals. Reflection and absorption may
cause a reliable radio link to turn unreliable for a period of
time and then being reusable again, thus the term "lossy".
Unlike other categories of PANs, the connected home area is very
much consumer-oriented. The implication on network nodes is that
devices are very cost sensitive, which leads to resource-
constrained environments having slow CPUs and small memory
footprints. At the same time, nodes have to be physically small
which puts a limit to the physical size of the battery; and thus,
the battery capacity. As a result, it is common for low-power
sensor-style nodes to shut down radio and CPU resources for most
of the time. The radio tends to use the same power for listening
as for transmitting
Section 2 describes a few typical use cases for home automation
applications. Section 3 discusses the routing requirements for
networks comprising such constrained devices in a home network
environment. These requirements may be overlapping requirements
derived from other application-specific routing requirements. A
full list of requirements documents may be found in the end of the
document.
2. Home Automation Applications 2. Home Automation Applications
Home automation applications represent a special segment of Home automation applications represent a special segment of
networked devices with its unique set of requirements. networked devices with its unique set of requirements.
Historically, such applications used wired networks or power line Historically, such applications used wired networks or power line
communication (PLC), but wireless solutions have emerged; allowing communication (PLC), but wireless solutions have emerged; allowing
existing buildings to be upgraded more easily. existing homes to be upgraded more easily.
To facilitate the requirements discussion in Section 3, this To facilitate the requirements discussion in Section 3, this
section lists a few typical use cases of home automation section lists a few typical use cases of home automation
applications. New applications are being developed at a high pace applications. New applications are being developed at a high pace
and this section does not mean to be exhaustive. Most home and this section does not mean to be exhaustive. Most home
automation applications tend to be running some kind of automation applications tend to be running some kind of
command/response protocol. The command may come from several command/response protocol. The command may come from several
places. places.
2.1. Lighting Application In Action 2.1. Lighting Application In Action
A lamp may be turned on, not only by a wall switch but also by a A lamp may be turned on, not only by a wall switch but also by a
movement sensor. The wall switch module may itself be a push- movement sensor. The wall switch module may itself be a push-
button sensor and an actuator at the same time. This will often be button sensor and an actuator at the same time. This will often be
the case when upgrading existing buildings as existing wiring is the case when upgrading existing homes as existing wiring is not
not prepared for automation. prepared for automation.
One event may cause many actuators to be activated at the same One event may cause many actuators to be activated at the same
time. time.
Using the direct analogy to an electronic car key, a house owner Using the direct analogy to an electronic car key, a house owner
may activate the "leaving home" function from an electronic house may activate the "leaving home" function from an electronic house
key, mobile phone, etc. For the sake of visual impression, all key, mobile phone, etc. For the sake of visual impression, all
lights should turn off at the same time. At least, it should lights should turn off at the same time. At least, it should
appear to happen at the same time. A well-known problem in appear to happen at the same time. A well-known problem in
wireless home automation is the "popcorn effect": Lamps are turned 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. on one at a time, at a rate so slow that it is clearly visible.
Some existing home automation solutions use a clever mix of a Some existing home automation solutions address this by sending an
"subnet groupcast" message in direct range with no acknowledgement unacknowledged multicast message in direct range before sending
before sending acknowledged singlecast messages to each device. acknowledged singlecast messages to each device.
Subnet groupcast, being an application-level feature, is not
further discussed in this specification.
The controller forms the group and decides which nodes should
receive a message.
2.2. Energy Conservation and Optimizing Energy Consumption 2.2. Energy Conservation and Optimizing Energy Consumption
In order to save energy, air conditioning, central heating, window In order to save energy, air conditioning, central heating, window
shades etc. may be controlled by timers, motion sensors or shades etc. may be controlled by timers, motion sensors or
remotely via internet or cell. Central heating may also be set to remotely via internet or cell. Central heating may also be set to
a reduced temperature during night time. a reduced temperature during night time.
The power grid may experience periods where more wind-generated The power grid may experience periods where more wind-generated
power is produced than is needed. Typically this may happen during power is produced than is needed. Typically this may happen during
skipping to change at page 8, line 36 skipping to change at page 8, line 46
may be triggered by the end-user after receiving an alarm from a may be triggered by the end-user after receiving an alarm from a
sensor (movement or smoke detector) or the user simply wants to sensor (movement or smoke detector) or the user simply wants to
check the home status via video. check the home status via video.
Note that in the former case, more than likely, there will be a Note that in the former case, more than likely, there will be a
form of inter-device communication: Upon detecting some movement form of inter-device communication: Upon detecting some movement
in the home, the movement sensor may send a request to the light 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 controller to turn on the lights, to the Web Cam to start a video
stream that would then be directed to the end user's cell phone or stream that would then be directed to the end user's cell phone or
Personal Digital Assistant (PDA) via the Internet. Personal Digital Assistant (PDA) via the Internet.
In contrast to other applications, e.g. industrial sensors, where In contrast to other applications, e.g. industrial sensors, where
data would mainly be originated by sensor to a sink and vice data would mainly be originated by a sensor to a sink and vice
versa, this scenario implicates a direct inter-device versa, this scenario implicates a direct inter-device
communication between ROLL devices. communication between ROLL devices.
2.7. Healthcare 2.7. Healthcare
By adding communication capability to devices, patients and By adding communication capability to devices, patients and
elderly citizens may be able to do simple measurements at home. elderly citizens may be able to do simple measurements at home.
Thanks to online devices, a doctor can keep an eye on the Thanks to online devices, a doctor can keep an eye on the
patient's health and receive warnings if a new trend is discovered patient's health and receive warnings if a new trend is discovered
by automated filters. by automated filters.
skipping to change at page 9, line 18 skipping to change at page 9, line 27
processing to the receiving data sink. processing to the receiving data sink.
A more active category of applications may send an alarm if some A more active category of applications may send an alarm if some
alarm condition is triggered. This category of applications is alarm condition is triggered. This category of applications is
referred to as at-home health monitoring. Measurements are referred to as at-home health monitoring. Measurements are
interpreted in the device and may cause reporting of an event if interpreted in the device and may cause reporting of an event if
an alarm is triggered. an alarm is triggered.
Many implementations may overlap both categories. Many implementations may overlap both categories.
Since wireless and battery operated systems may never reach 100%
guaranteed operational time, healthcare and security systems will
need a management layer implementing alarm mechanisms for low
battery, report activity, etc.
For instance if a blood pressure sensor did not report a new
measurement, say 5 minutes after the scheduled time, some
responsible person must be notified.
The structure and performance of such a management layer is
outside the scope of the routing requirements listed in this
document.
2.7.1. At-home Health Reporting 2.7.1. At-home Health Reporting
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
Measurements may be stored for long term statistics. At the same Measurements may be stored for long term statistics. At the same
skipping to change at page 11, line 24 skipping to change at page 11, line 33
+-------------------------------+-----------------------------+ +-------------------------------+-----------------------------+
|2.3. Moving a Remote Control |3.2. Support of Mobility | |2.3. Moving a Remote Control |3.2. Support of Mobility |
|Around |3.6. Convergence Time | |Around |3.6. Convergence Time |
+-------------------------------+-----------------------------+ +-------------------------------+-----------------------------+
|2.4. Adding A New Module To The |3.6. Convergence Time | |2.4. Adding A New Module To The |3.6. Convergence Time |
|System |3.7. Manageability | |System |3.7. Manageability |
+-------------------------------+-----------------------------+ +-------------------------------+-----------------------------+
|2.5. Controlling Battery |3.3. Sleeping Nodes | |2.5. Controlling Battery |3.3. Sleeping Nodes |
|Operated Window Shades | | |Operated Window Shades | |
+-------------------------------+-----------------------------+ +-------------------------------+-----------------------------+
|2.6. Remote Video Surveillance |3.3. Sleeping Nodes |
| |3.6. Convergence Time |
+------------------------------- +-----------------------------+
|2.7. Healthcare |3.1. Constraint-based Routing| |2.7. Healthcare |3.1. Constraint-based Routing|
| |3.2. Support of Mobility | | |3.2. Support of Mobility |
| |3.4. Healthcare Routing | | |3.4. Healthcare Routing |
| |3.6. Convergence Time | | |3.6. Convergence Time |
+-------------------------------+-----------------------------+ +-------------------------------+-----------------------------+
|2.8. Alarm Systems |3.5. Scalability | |2.8. Alarm Systems |3.5. Scalability |
| |3.6. Convergence Time | | |3.6. Convergence Time |
+-------------------------------+-----------------------------+ +-------------------------------+-----------------------------+
3.1. Constraint-based Routing 3.1. Constraint-based Routing
skipping to change at page 12, line 36 skipping to change at page 12, line 49
e.g. pause the music. e.g. pause the music.
While, in theory, all battery-powered devices and mains-powered While, in theory, all battery-powered devices and mains-powered
plug-in modules may be moved, the predominant case is that the plug-in modules may be moved, the predominant case is that the
sending node has moved while the rest of the network has not sending node has moved while the rest of the network has not
changed. 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.
In more rare occasions, receiving nodes may also have moved.
Examples include safety-off switch in a clothes iron or the
wireless chime of doorbell set.
The routing protocol MUST provide mobility with convergence time
below 4 seconds if the receiver has moved.
A non-responsive node can either be caused by 1) a failure in the A non-responsive node can either be caused by 1) a failure in the
node, 2) a failed link on the path to the node or 3) a moved node. node, 2) a failed link on the path to the node or 3) a moved node.
In the first two cases, the node can be expected to reappear at In the first two cases, the node can be expected to reappear at
roughly the same location in the network, whereas it can return roughly the same location in the network, whereas it can return
anywhere in the network in the latter case. anywhere in the network in the latter case.
3.3. Sleeping Nodes 3.3. Sleeping Nodes
Sleeping nodes may appear to be non-responsive. The routing Sleeping nodes may appear to be non-responsive. The routing
protocol MUST take into account the delivery time to a sleeping protocol MUST take into account the delivery time to a sleeping
target node. target node.
The wake-up interval of a sleeping node MUST be less than one
second.
3.4. Healthcare Routing 3.4. Healthcare Routing
Because most health care applications may run on battery, this Because most health care applications may run on battery, this
leads to specific requirements for the routing protocol. Most leads to specific requirements for the routing protocol. Most
health care applications may also be portable and therefore need health care applications may also be portable and therefore need
to locate a new neighbor router on a frequent basis. to locate a new neighbor router on a frequent basis.
Not being powered most of the time, the nodes should not be used Not being powered most of the time, the nodes should not be used
as routing nodes. However, battery-powered nodes may be involved as routing nodes. However, battery-powered nodes may be involved
in routing. Examples include cases where a person falls during a in routing. Examples include cases where a person falls during a
power blackout. In that case it may be that no mains-powered power blackout. In that case it may be that no mains-powered
routers are available for forwarding the alarm message to a routers are available for forwarding the alarm message to a
(battery-backed) internet gateway located out of direct range. (battery-backed) internet gateway located out of direct range.
Delivery of measurement data has a more relaxed requirement for Delivery of measurement data has a more relaxed requirement for
route discovery time compared to a remote control. On the other route discovery time compared to a remote control. On the other
hand, it is critical that a "person fell" alarm is actually hand, it is critical that a "person fell" alarm is actually
delivered. delivered.
If possible at all, the routing protocol MUST deliver a health-
care related message. It is NOT a requirement that such message is
delivered in less than a second.
The routing protocol SHOULD support acknowledged transmission. If
the routing protocol does not support acknowledged transmission,
some higher-layer transport protocol or application MUST ensure
delivery of such messages.
3.5. Scalability 3.5. Scalability
Looking at the number of wall switches, power outlets, sensors of Looking at the number of wall switches, power outlets, sensors of
various nature, video equipment and so on in a modern house, it various nature, video equipment and so on in a modern house, it
seems quite realistic that hundreds of low power devices may form seems quite realistic that hundreds of low power devices may form
a home automation network in a fully populated "smart" home. a home automation network in a fully populated "smart" home.
Moving towards professional building automation, the number of Moving towards professional building automation, the number of
such devices may be in the order of several thousands. such devices may be in the order of several thousands.
The routing protocol MUST support 250 devices in the network. The routing protocol MUST support 250 devices in the network.
skipping to change at page 14, line 14 skipping to change at page 14, line 42
to the network. From a routing perspective, zero-configuration to the network. From a routing perspective, zero-configuration
means that a node can obtain an address and join the network on means that a node can obtain an address and join the network on
its own, without human intervention. its own, without human intervention.
3.8. Stability 3.8. Stability
The routing protocol MUST support the ability to isolate a The routing protocol MUST support the ability to isolate a
misbehaving node thus preserving the correct operation of the misbehaving node thus preserving the correct operation of the
overall network. overall network.
In other words, if a node is found to fail often compared to the
rest of the network, this node should not be the first choice for
routing of traffic.
4. Traffic Pattern 4. Traffic Pattern
Depending on the design philosophy of the home network, wall Depending on the design philosophy of the home network, wall
switches may be configured to directly control individual lamps or switches may be configured to directly control individual lamps or
alternatively, all wall switches send control commands to a alternatively, all wall switches send control commands to a
central lighting control computer which again sends out control central lighting control computer which again sends out control
commands to relevant devices. commands to relevant devices.
In a distributed system, the traffic tends to be multipoint-to- In a distributed system, the traffic tends to be multipoint-to-
multipoint. In a centralized system, it is a mix of multipoint-to- multipoint. In a centralized system, it is a mix of multipoint-to-
skipping to change at page 15, line 5 skipping to change at page 15, line 29
period with no movement has elapsed. The highest transmission period with no movement has elapsed. The highest transmission
frequency depends on the idle period used in the sensor. frequency depends on the idle period used in the sensor.
Sometimes, a timer will trigger a frame transmission when an Sometimes, a timer will trigger a frame transmission when an
extended period without status change has elapsed. extended period without status change has elapsed.
All frames sent in the above examples are quite short, typically All frames sent in the above examples are quite short, typically
less than 5 bytes of payload. Lost frames and interference from less than 5 bytes of payload. Lost frames and interference from
other transmitters may lead to retransmissions. In all cases, other transmitters may lead to retransmissions. In all cases,
acknowledgment frames with a size of a few bytes are used. acknowledgment frames with a size of a few bytes are used.
6. Security Considerations As mentioned in the introduction, all messages are carried in IPv6
packets; typically as UDP but ICMP echo and other types may also
appear.
In order to save bandwidth, the transport layer will typically be
using header compression [I-D.Hui-HeaderCompression].
Implementing security mechanisms in ROLL network devices may 5. Security Considerations
degrade energy efficiency and increase cost.
The routing protocol chosen for ROLL MUST allow for low-power, As every network, HC-LLNs are exposed to routing security threats
low-cost network devices with limited security needs. that need to be addressed. The wireless and distributed nature of
these networks increases the spectrum of potential routing
security threats. This is further amplified by the resource
constraints of the nodes, thereby preventing resource-intensive
routing security approaches from being deployed. A viable routing
security approach SHOULD be sufficiently lightweight that it may
be implemented across all nodes in a HC-LLN. These issues require
special attention during the design process, so as to facilitate a
commercially attractive deployment.
Protection against unintentional inclusion in neighboring networks The HC-LLN MUST deny any node that has not been authenticated to
MUST be provided. the HC-LLN and authorized to participate to the routing decision
process.
7. IANA Considerations An attacker SHOULD be prevented from manipulating or disabling the
routing function, for example, by compromising routing control
messages. To this end, the routing protocol(s) MUST support
message integrity.
Further examples of routing security issues that may arise are the
abnormal behavior of nodes that exhibit an egoistic conduct, such
as not obeying network rules or forwarding no or false packets.
Other important issues may arise in the context of denial-of-
service (DoS) attacks, malicious address space allocations,
advertisement of variable addresses, a wrong neighborhood, etc.
The routing protocol(s) SHOULD support defense against DoS attacks
and other attempts to maliciously or inadvertently cause the
mechanisms of the routing protocol(s) to over-consume the limited
resources of LLN nodes, e.g., by constructing forwarding loops or
causing excessive routing protocol overhead traffic, etc.
The properties of self-configuration and self-organization that
are desirable in a HC-LLN introduce additional routing security
considerations. Mechanisms MUST be in place to deny any node that
attempts to take malicious advantage of self-configuration and
self-organization procedures. Such attacks may attempt, for
example, to cause DoS, drain the energy of power-constrained
devices, or to hijack the routing mechanism. A node MUST
authenticate itself to a trusted node that is already associated
with the HC-LLN before the former can take part in self-
configuration or self-organization. A node that has already
authenticated and associated with the HC-LLN MUST deny, to the
maximum extent possible, the allocation of resources to any
unauthenticated peer. The routing protocol(s) MUST deny service
to any node that has not clearly established trust with the HC-
LLN.
If connected to a backbone network, the HC-LLN SHOULD be capable
of limiting the resources utilized by nodes in said backbone
network so as not to be vulnerable to DoS. This should typically
be handled by border routers providing access from a backbone
network to resources in the HC-LLN.
With low computation power and scarce energy resources, HC-LLNs'
nodes may not be able to resist any attack from high-power
malicious nodes (e.g., laptops and strong radios). However, the
amount of damage generated to the whole network SHOULD be
commensurate with the number of nodes physically compromised. For
example, an intruder taking control over a single node SHOULD NOT
be able to completely deny service to the whole network.
In general, the routing protocol(s) SHOULD support the
implementation of routing security best practices across the HC-
LLN. Such an implementation ought to include defense against, for
example, eavesdropping, replay, message insertion, modification,
and man-in-the-middle attacks.
The choice of the routing security solutions will have an impact
on the routing protocol(s). To this end, routing protocol(s)
proposed in the context of HC-LLNs MUST support authentication and
integrity measures and SHOULD support confidentiality (routing
security) measures.
6. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
8. Acknowledgments 7. Acknowledgments
J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler
and Massimo Maggiorotti are gratefully acknowledged for their and Massimo Maggiorotti are gratefully acknowledged for their
contributions to this document. 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.
9. References 8. Disclaimer for pre-RFC5378 work
As an exception, this internet draft contains references to other This document may contain material from IETF Documents or IETF
internet drafts. The reason is that the referenced internet drafts Contributions published or made publicly available before November
are developed in parallel to this document. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
When promoted to an RFC, the references MUST be updated to RFCs as 9. References
well or removed from the references section.
9.1. Normative References 9.1. Normative References
[I-D.Vasseur-Terminology] Vasseur, JP. "Terminology in Low power
And Lossy Networks", draft-vasseur-roll-terminology-02
(work in progress), October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [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.
[I-D.Hui-HeaderCompression] Hui, J., "Compression Format for IPv6
Datagrams in 6LoWPAN Networks ", draft-ietf-6lowpan-hc
(work in progress), December 2008.
9.2. Informative References 9.2. Informative References
[I-D.draft-ietf-roll-terminology] [RFC5548] Dohler, M., "Routing Requirements for Urban Low-Power
"Terminology in Low power And Lossy Networks", and Lossy Networks", BCP 14, RFC 5548, May 2009.
JP Vasseur, draft-ietf-roll-terminology-00
(work in progress), October 2008 [I-D.Pister-Industial-reqs] Pister, K., "Industrial Routing
Requirements in Low Power and Lossy Networks ", draft-
ietf-roll-indus-routing-reqs (work in progress)
[I-D.Martocci-Building-reqs] Martocci, J., "Building Automation
Routing Requirements in Low Power and Lossy Networks ",
draft-ietf-roll-building-routing-reqs (work in progress)
[I-D.Levis-Protocols-survey] Lewis, P. "Overview of Existing
Routing Protocols for Low Power and Lossy Networks",
draft-ietf-roll-protocols-survey (work in progress)
Author's Addresses Author's Addresses
Anders Brandt Anders Brandt
Zensys, Inc.
Sigma Designs, Inc.
Emdrupvej 26 Emdrupvej 26
Copenhagen, DK-2100 Copenhagen, DK-2100
Denmark Denmark
Email: abr@zen-sys.com Email: abr@zen-sys.com
Jakob Buron Jakob Buron
Zensys, Inc. Sigma Designs, Inc.
Emdrupvej 26 Emdrupvej 26
Copenhagen, DK-2100 Copenhagen, DK-2100
Denmark Denmark
Email: jbu@zen-sys.com Email: jbu@zen-sys.com
Giorgio Porcu Giorgio Porcu
Telecom Italia Telecom Italia
Piazza degli Affari, 2 Piazza degli Affari, 2
20123 Milan 20123 Milan
Italy Italy
Email: giorgio.porcu@guest.telecomitalia.it Email: giorgio.porcu@guest.telecomitalia.it
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 38 change blocks. 
185 lines changed or deleted 274 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/