draft-ietf-roll-home-routing-reqs-02.txt | draft-ietf-roll-home-routing-reqs-03.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: January 2009 Telecom Italia | Expires: January 2009 Telecom Italia | |||
July 14, 2008 | September 11, 2008 | |||
Home Automation Routing Requirement in Low Power and Lossy Networks | Home Automation Routing Requirement in Low Power and Lossy | |||
draft-ietf-roll-home-routing-reqs-02 | Networks | |||
draft-ietf-roll-home-routing-reqs-03 | ||||
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 | |||
Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that | |||
groups may also distribute working documents as Internet-Drafts. | other groups may also distribute working documents as Internet- | |||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six | |||
and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other | |||
time. It is inappropriate to use Internet-Drafts as reference | documents at any time. It is inappropriate to use Internet-Drafts | |||
material or to cite them other than as "work in progress." | as reference 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 January 14, 2009. | This Internet-Draft will expire on March 11, 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 Over Low power and Lossy | |||
(ROLL). In a modern home, a high number of wireless devices are used | networks (ROLL). In a modern home, a high number of wireless | |||
for a wide set of purposes. Examples include lighting control, | devices are used for a wide set of purposes. Examples include | |||
heating control, sensors, leak detectors, healthcare systems and | actuators (relay, light dimmer, heating valve), sensors (wall | |||
advanced remote controls. Because such devices only cover a limited | switch, water leak, blood pressure) and advanced controllers. | |||
radio range, multi-hop routing is often required. The aim of this | Because such devices only cover a limited radio range, routing is | |||
document is to specify the routing requirements for networks | often required. The aim of this document is to specify the routing | |||
comprising such constrained devices in a home network environment. | 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 NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" | |||
document are to be interpreted as described in RFC-2119 [RFC2119]. | in this document are to be interpreted as described in RFC-2119 | |||
[RFC2119]. | ||||
Table of Contents | Table of Contents | |||
1. Terminology....................................................3 | Terminology......................................................3 | |||
2. Introduction...................................................3 | 1. Introduction..................................................5 | |||
3. Home automation applications...................................4 | 2. Home Automation Applications..................................6 | |||
3.1. Turning off the house when leaving........................4 | 2.1. Lighting Application In Action...........................6 | |||
3.2. Energy conservation and optimizing energy consumption.....5 | 2.2. Energy Conservation and Optimizing Energy Consumption....6 | |||
3.3. Moving a remote control around............................5 | 2.3. Moving a Remote Control Around...........................7 | |||
3.4. Adding a new lamp module to the system....................6 | 2.4. Adding A New Module To The System........................7 | |||
3.5. Controlling battery operated window shades................6 | 2.5. Controlling Battery Operated Window Shades...............8 | |||
3.6. Remote video surveillance.................................6 | 2.6. Remote Video Surveillance................................8 | |||
3.7. Healthcare................................................7 | 2.7. Healthcare...............................................8 | |||
3.7.1. At-home health reporting.............................7 | 2.7.1. At-home Health Reporting............................9 | |||
3.7.2. At-home health monitoring............................8 | 2.7.2. At-home Health Monitoring...........................9 | |||
3.7.3. Healthcare routing considerations....................8 | 2.8. Alarm Systems............................................9 | |||
3.8. Alarm systems.............................................8 | 3. Unique Routing Requirements of Home Automation Applications..10 | |||
3.9. Battery-powered devices...................................9 | 3.1. Support of Groupcast....................................11 | |||
4. Unique requirements of home automation applications............9 | 3.2. Constraint-based Routing................................12 | |||
4.1. Support of groupcast......................................9 | 3.3. Support of Mobility.....................................12 | |||
4.2. Constraint-based Routing.................................10 | 3.4. Sleeping Nodes..........................................13 | |||
4.3. Support of Mobility......................................10 | 3.5. Healthcare Routing......................................13 | |||
4.4. Support of Periodical Scanning...........................11 | 3.6. Scalability.............................................13 | |||
4.5. Scalability..............................................11 | 3.7. Convergence Time........................................14 | |||
4.6. Convergence Time.........................................11 | 3.8. Manageability...........................................14 | |||
4.7. Manageability............................................12 | 3.9. Stability...............................................14 | |||
5. Traffic Pattern...............................................12 | 4. Traffic Pattern..............................................14 | |||
6. Open issues...................................................13 | 5. Open Issues..................................................15 | |||
7. Security Considerations.......................................13 | 6. Security Considerations......................................15 | |||
8. IANA Considerations...........................................13 | 7. IANA Considerations..........................................15 | |||
9. Acknowledgments...............................................13 | 8. Acknowledgments..............................................15 | |||
10. References...................................................14 | 9. References...................................................16 | |||
10.1. Normative References....................................14 | 9.1. Normative References....................................16 | |||
10.2. Informative References..................................14 | 9.2. Informative References..................................17 | |||
Disclaimer of Validity...........................................15 | Disclaimer of Validity..........................................18 | |||
1. Terminology | ||||
ROLL: ROuting in Low-power and Lossy networks | Terminology | |||
ROLL device: A ROLL network node with constrained CPU and memory | ROLL: Routing Over Low-power and Lossy networks | |||
resources; potentially constrained power resources. | A ROLL node may be classified as sensor, actuator | |||
or controller. | ||||
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 a ROLL network to the Internet or some | |||
Internet, possibly via a customer premises local area | backbone network. | |||
network (LAN). | ||||
Actuator: Network node which performs some physical action. | ||||
Dimmers and relays are examples of actuators. | ||||
If sufficiently powered, actuator nodes may | ||||
participate in routing network messages. | ||||
Channel: Radio frequency band used to carry network packets. | ||||
Controller: Network node that controls actuators. Control | ||||
decisions may be based on sensor readings, sensor | ||||
events, scheduled actions or incoming commands from | ||||
the Internet or other backbone networks. | ||||
If sufficiently powered, controller nodes may | ||||
participate in routing network messages. | ||||
Downstream: Data direction traveling from a Local Area Network | ||||
(LAN) to a Personal Area Network (PAN) device. | ||||
DR: Demand-Response | ||||
The mechanism of users adjusting their power | ||||
consumption in response to actual pricing of power. | ||||
DSM: Demand Side Management | ||||
Process allowing power utilities to enable and | ||||
disable loads in consumer premises. Where DR relies | ||||
on voluntary action from users, DSM may be based on | ||||
enrollment in a formal program. | ||||
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: Radio frequency band used to transmit a modulated | PDA Personal Digital Assistant. A small, handheld | |||
signal carrying packets. | computer. | |||
Downstream: Data direction traveling from a Local Area Network | PLC Power Line Communication | |||
(LAN) to a Personal Area Network (PAN) device. | ||||
Upstream: Data direction traveling from a PAN to a LAN device. | RAM Random Access Memory | |||
Sensor: A PAN device that measures data and/or detects an | Sensor: Network node that measures data and/or detects an | |||
event. | event. | |||
The sensor may generate a trap message to notify a | ||||
controller or directly activate an actuator. | ||||
If sufficiently powered, sensor nodes may | ||||
participate in routing network messages. | ||||
2. Introduction | Upstream: Data direction traveling from a PAN to a LAN | |||
device. | ||||
This document presents the home control and automation application | 1. Introduction | |||
specific requirements for Routing in 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 lighting control | ||||
modules, heating control panels, light sensors, temperature sensors, | ||||
gas/water leak detectors, motion detectors, video surveillance, | ||||
healthcare systems and advanced remote controls. Basic home control | ||||
modules such as wall switches and plug-in modules may be turned into | ||||
an advanced home automation solution via the use of an IP-enabled | ||||
application responding to events generated by wall switches, motion | ||||
sensors, light sensors, rain sensors, and so on. | ||||
Because such devices only cover a limited radio range, multi-hop | This document presents home control and automation application | |||
routing is often required. These devices are usually highly | specific requirements for Routing Over Low power and Lossy | |||
constrained in term of resources such as battery and memory and | networks (ROLL). In a modern home, a high number of wireless | |||
operate in unstable environments. Persons moving around in a house, | devices are used for a wide set of purposes. Examples include | |||
opening or closing a door or starting a microwave oven affect the | actuators (relay, light dimmer, heating valve), sensors (wall | |||
reception of weak radio signals. Reflection and absorption may cause | switch, water leak, blood pressure) and advanced controllers. | |||
a reliable radio link to turn unreliable for a period of time and | Basic home control modules such as wall switches and plug-in | |||
then being reusable again, thus the term "lossy". | 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. | ||||
Unlike other categories of PANs, the connected home area is very much | Network nodes may be sensors and actuators at the same time. An | |||
consumer-oriented. The implications on network nodes in this aspect, | example is a wall switch for replacement in existing buildings. | |||
is that devices are very cost sensitive, which leads to resource- | 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 | constrained environments having slow CPUs and small memory | |||
footprints. At the same time, nodes have to be physically small which | footprints. At the same time, nodes have to be physically small | |||
puts a limit to the physical size of the battery; and thus, the | which puts a limit to the physical size of the battery; and thus, | |||
battery capacity. As a result, it is common for low-power sensor- | the battery capacity. As a result, it is common for low-power | |||
style nodes to shut down radio and CPU resources for most of the | sensor-style nodes to shut down radio and CPU resources for most | |||
time. Often, the radio uses the same power for listening as for | of the time. The radio tends to use the same power for listening | |||
transmitting. | as for transmitting | |||
Section 3 describes a few typical use cases for home automation | Section 2 describes a few typical use cases for home automation | |||
applications. Section 4 discusses the routing requirements for | applications. Section 3 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. | derived from other application-specific routing requirements. A | |||
full list of requirements documents may be found in the end of the | ||||
document. | ||||
3. Home automation applications | 2. Home Automation Applications | |||
Home automation applications represent a special segment of networked | Home automation applications represent a special segment of | |||
wireless devices with its unique set of requirements. To facilitate | networked devices with its unique set of requirements. | |||
the requirements discussion in Section 4, this section lists a few | Historically, such applications used wired networks or power line | |||
typical use cases of home automation applications. New applications | communication (PLC), but wireless solutions have emerged; allowing | |||
are being developed at a high pace and this section does not mean to | existing buildings to be upgraded more easily. | |||
be exhaustive. Most home automation applications tend to be running | ||||
some kind of command/response protocol. The command may come from | ||||
several places. For instance a lamp may be turned on, not only be a | ||||
wall switch but also from a movement sensor. | ||||
3.1. Turning off the house when leaving | To facilitate the requirements discussion in Section 3, this | |||
section lists a few typical use cases of home automation | ||||
applications. New applications are being developed at a high pace | ||||
and this section does not mean to be exhaustive. Most home | ||||
automation applications tend to be running some kind of | ||||
command/response protocol. The command may come from several | ||||
places. | ||||
Using the direct analogy to an electronic car key, a house owner may | 2.1. Lighting Application In Action | |||
activate the "leaving home" function from an electronic house key, | ||||
mobile phone, etc. For the sake of visual impression, all lights | ||||
should turn off at the same time. At least, it should appear to | ||||
happen at the same time. A well-known problem in wireless home | ||||
automation is the "popcorn effect": Lamps are turned on one at a | ||||
time, at a rate so slow that it is clearly visible. 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. | ||||
The controller forms the groups and decides which nodes should | A lamp may be turned on, not only by a wall switch but also by a | |||
receive "turn-off" or "turn-on" requests. | movement sensor. The wall switch module may itself be a push- | |||
button sensor and an actuator at the same time. This will often be | ||||
the case when upgrading existing buildings as existing wiring is | ||||
not prepared for automation. | ||||
3.2. Energy conservation and optimizing energy consumption | One event may cause many actuators to be activated at the same | |||
time. | ||||
Using the direct analogy to an electronic car key, a house owner | ||||
may activate the "leaving home" function from an electronic house | ||||
key, mobile phone, etc. For the sake of visual impression, all | ||||
lights should turn off at the same time. At least, it should | ||||
appear to happen at the same time. A well-known problem in | ||||
wireless home automation is the "popcorn effect": Lamps are turned | ||||
on one at a time, at a rate so slow that it is clearly visible. | ||||
Some existing home automation solutions use a clever mix of a | ||||
"subnet groupcast" message in direct range with no acknowledgement | ||||
before sending acknowledged singlecast messages to each device. | ||||
Parts of the world using air conditioning may let shades go down and | The controller forms the group and decides which nodes should | |||
turn off the AC device when leaving home. Air conditioning may start | receive a message. | |||
by timer or via motion sensor when the owner returns home. The owner | ||||
may even activate the air conditioning via cell phone before getting | ||||
home. | ||||
Geographical areas using central heating may turn off heating when | 2.2. Energy Conservation and Optimizing Energy Consumption | |||
not at home and use a reduced temperature during night time. | ||||
The power grid may experience periods where more wind-generated power | In order to save energy, air conditioning, central heating, window | |||
is produced than is needed. Typically this may happen during night | shades etc. may be controlled by timers, motion sensors or | |||
hours. The washing machine and dish washer may just as well work | remotely via internet or cell. Central heating may also be set to | |||
a reduced temperature during night time. | ||||
The power grid may experience periods where more wind-generated | ||||
power is produced than is needed. Typically this may happen during | ||||
night hours. | ||||
In periods where electricity demands exceed available supply, | ||||
appliances such as air conditioning, climate control systems, | ||||
washing machines etc. can be turned off to avoid overloading the | ||||
power grid. | ||||
This is known as Demand-Side Management (DSM). | ||||
Remote control of household appliances is well-suited for this | ||||
application. | ||||
The start/stop decision for the appliances can also be regulated | ||||
by dynamic power pricing information obtained from the electricity | ||||
utility companies. This method called Demand-Response (DR) works | ||||
by motivation of users via pricing, bonus points, etc. For | ||||
example, 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. | |||
In periods where electricity demands exceed available supply, | In order to achieve effective electricity savings, the energy | |||
appliances such as air conditioning, climate control systems, washing | monitoring application must guarantee that the power consumption | |||
machines etc. can be turned off to avoid overloading the power grid. | of the ROLL devices is much lower than that of the appliance | |||
Wireless remote control of the household appliances is well-suited | itself. | |||
for this application. The start/stop decision for the appliances can | ||||
be regulated by dynamic power pricing information obtained from the | ||||
electricity utility companies. Moreover, in order to achieve | ||||
effective electricity savings, the energy monitoring application | ||||
running on the Wireless Sensor Network (WSN) must guarantee that the | ||||
power consumption of the ROLL devices is much lower than that of the | ||||
appliance itself. | ||||
Most of these applications are mains powered and are thus ideal for | Most of these appliances are mains powered and are thus ideal for | |||
providing reliable, always-on routing resources. Battery-powered | providing reliable, always-on routing resources. Battery-powered | |||
nodes, by comparison, are constrained routing resources and may only | nodes, by comparison, are constrained routing resources and may | |||
provide reliable routing under some circumstances. | only provide reliable routing under some circumstances. | |||
3.3. Moving a remote control around | 2.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. | |||
must appear to be instant (within a few hundred milliseconds) even | Reaction must appear to be instant (within a few hundred | |||
when the remote control has moved to a new location. The remote | milliseconds) even when the remote control has moved to a new | |||
control may be communicating to either a central home automation | location. The remote control may be communicating to either a | |||
controller or directly to the lamps and the media center. | central home automation controller or directly to the lamps and | |||
the media center. | ||||
3.4. Adding a new lamp module to the system | 2.4. Adding A New 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 | |||
single button. Thus, an automated inclusion process is needed for | a single button. Thus, an automated inclusion process is needed | |||
controllers to find new modules. Inclusion covers the detection of | for controllers to find new modules. Inclusion covers the | |||
neighbors and assignment of a unique node ID. Inclusion should be | detection of neighbors and assignment of a unique node ID. | |||
completed within a few seconds. | Inclusion should be completed within a few seconds. | |||
Distribution of unique addresses is usually performed by a central | If assignment of unique addresses is performed by a central | |||
controller. In this case, it must be possible to route the inclusion | controller, it must be possible to route the inclusion request | |||
request from the joining node to the central controller even before | from the joining node to the central controller before the joining | |||
the joining node is assigned a unique address. | node has been included in the network. | |||
3.5. Controlling battery operated window shades | 2.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, such an actuator node is sleeping most of | |||
home automation controller sending commands to window shades via ROLL | the time. A controller sending commands to a sleeping actuator | |||
devices will have no problems delivering the packet to the router, | node via ROLL devices will have no problems delivering the packet | |||
but the router may have to wait for some time before the command can | to the nearest powered router, but that router may experience a | |||
be delivered to the window shades if the receiver is sleeping; e.g. | delay until the next wake-up time before the command can be | |||
up to 250ms. | delivered. | |||
3.6. Remote video surveillance | 2.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. The video stream | |||
triggered by the end-user that has received an alarm from a movement | may be triggered by the end-user after receiving an alarm from a | |||
sensor or smoke detector - or the user simply wants to check the home | sensor (movement or smoke detector) or the user simply wants to | |||
status via video. | check the home 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 | |||
of inter-device communication: indeed, 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 (cell phone, PDA) | stream that would then be directed to the end user's cell phone or | |||
via the Internet. | Personal Digital Assistant (PDA) via the Internet. | |||
By contrast with 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 versa, | data would mainly be originated by sensor to a sink and vice | |||
this scenario implicates a direct inter-device communication between | versa, this scenario implicates a direct inter-device | |||
ROLL devices. | communication between ROLL devices. | |||
3.7. Healthcare | 2.7. Healthcare | |||
By adding communication capability to devices, patients and elderly | By adding communication capability to devices, patients and | |||
citizens may be able to do simple measurements at home. Thanks to | elderly citizens may be able to do simple measurements at home. | |||
online devices, a doctor can keep an eye on the patient's health and | Thanks to online devices, a doctor can keep an eye on the | |||
receive warnings if a new trend is discovered by automated filters. | patient's health and receive warnings if a new trend is discovered | |||
by automated filters. | ||||
Fine-grained daily measurements presented in proper ways may allow | Fine-grained daily measurements presented in proper ways may allow | |||
the doctor to establish a more precise diagnosis. | the doctor to establish a more precise diagnosis. | |||
Such applications may be realized as wearable products which | Such applications may be realized as wearable products which | |||
frequently do a measurement and automatically deliver the result to a | frequently do a measurement and automatically deliver the result | |||
data sink locally or over the Internet. | to a data sink locally or over the Internet. | |||
Applications falling in this category are referred to as at-home | Applications falling in this category are referred to as at-home | |||
health reporting. Whether measurements are done in a fixed interval | health reporting. Whether measurements are done in a fixed | |||
or if they are manually activated, they leave all processing to the | interval or if they are manually activated, they leave all | |||
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 an | interpreted in the device and may cause reporting of an event if | |||
alarm is triggered. | an alarm is triggered. | |||
Many implementations may overlap both categories. | Many implementations may overlap both categories. | |||
3.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 | |||
time, a critically high blood pressure may cause the generation of an | time, a critically high blood pressure may cause the generation of | |||
alarm report. Refer to 3.7.2. | an alarm report. Refer to 2.7.2. | |||
To avoid a high number of request messages, nodes may be configured | To avoid a high number of request messages, nodes may be | |||
to autonomously do a measurement and send a report in intervals. | configured to autonomously do a measurement and send a report in | |||
intervals. | ||||
3.7.2. At-home health monitoring | 2.7.2. At-home Health Monitoring | |||
An alarm event may become active e.g. if the measured blood pressure | An alarm event may become active e.g. if the measured blood | |||
exceeds a threshold or if a person falls to the ground. | pressure exceeds a threshold or if a person falls to the ground. | |||
Alarm conditions must be reported with the highest priority and | ||||
timeliness. | ||||
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 Electrocardiogram (ECG) | o Electrocardiogram (ECG) | |||
o Position tracker | o Position tracker | |||
3.7.3. Healthcare routing considerations | 2.8. Alarm Systems | |||
From a ROLL perspective, all the above-mentioned applications may run | ||||
on battery. They may also be portable and therefore need to locate a | ||||
new neighbor router on a frequent basis. | ||||
Not being powered most of the time, the nodes should not be used as | ||||
routing nodes. However, sleeping, battery-powered nodes may be | ||||
involved in routing. Examples include cases where a person falls | ||||
during a power blackout. In that case it may be that no mains-powered | ||||
routers are available for forwarding the alarm message to a (battery- | ||||
backed) internet gateway located out of direct range. | ||||
Delivery of measurement data has a more relaxed requirement for route | ||||
discovery time compared to a remote control. On the other hand, it is | ||||
critical that a "person fell" alarm is actually delivered in the end. | ||||
3.8. Alarm systems | ||||
A home security alarm system is comprised of various devices like | A home security alarm system is comprised of various sensors | |||
vibration detectors, fire or carbon monoxide detection system, door | (vibration, fire or carbon monoxide, door/window, glass-break, | |||
or window contacts, glass-break detector, presence sensor, panic | presence, panic button, etc.). | |||
button, home security key. | ||||
Some smoke alarms are battery powered and at the same time mounted in | Some smoke alarms are battery powered and at the same time mounted | |||
a high place. Battery-powered safety devices should only be used for | in a high place. Battery-powered safety devices should only be | |||
routing if no other alternatives exist to avoid draining the battery. | used for routing if no other alternatives exist to avoid draining | |||
A smoke alarm with a drained battery does not provide a lot of | the battery. A smoke alarm with a drained battery does not provide | |||
safety. Also, it may be inconvenient to exchange battery in a smoke | a lot of safety. Also, it may be inconvenient to exchange battery | |||
alarm. | in a smoke alarm. | |||
Alarm system applications may have both a synchronous and an | Alarm system applications may have both a synchronous and an | |||
asynchronous behavior; i.e. they may be periodically queried by a | asynchronous behavior; i.e. they may be periodically queried by a | |||
central control application (e.g. for a periodical refreshment of the | central control application (e.g. for a periodical refreshment of | |||
network state), or send a message to the control application on their | the network state), or send a message to the control application | |||
own initiative basing upon the status of the environment they | on their own initiative. | |||
monitor. | ||||
When a node (or a group of nodes) identifies a risk situation (e.g. | When a node (or a group of nodes) identifies a risk situation | |||
intrusion, smoke, fire), it sends an alarm message to the control | (e.g. intrusion, smoke, fire), it sends an alarm message to a | |||
centre that could autonomously forward it via Internet or interact | central controller that could autonomously forward it via Internet | |||
with the WSN (e.g. trying to obtain more detailed information or | or interact with other network nodes (e.g. try to obtain more | |||
asking to other nodes close to the alarm event). Alarm messages | detailed information or ask other nodes close to the alarm event). | |||
have, obviously, strict low-latency requirements. | ||||
Finally, routing via battery-powered nodes may be very slowly | Finally, routing via battery-powered nodes may be very slow if the | |||
reacting if the nodes are sleeping most of the time (they could | nodes are sleeping most of the time (they could appear | |||
appear unresponsive to the alarm detection). To ensure fast message | unresponsive to the alarm detection). To ensure fast message | |||
delivery and avoid battery drain, routing should be avoided via this | delivery and avoid battery drain, routing should be avoided via | |||
category of devices. | sleeping devices. | |||
3.9. Battery-powered devices | 3. Unique Routing Requirements of Home Automation Applications | |||
For convenience and low operational costs, power consumption of | Home automation applications have a number of specific routing | |||
consumer products must be kept at a very low level to achieve a long | requirements related to the set of home networking applications | |||
battery lifetime. One implication of this fact is that RAM memory is | and the perceived operation of the system. | |||
limited and it may even be powered down; leaving only a few 100 bytes | ||||
of RAM alive during the sleep phase. | ||||
The use of battery powered devices reduces installation costs and | The relations of use cases to requirements are outlined in the | |||
does enable installation of devices even where main power lines are | table below: | |||
not available. On the other hand, in order to be cost effective and | ||||
efficient, the devices have to maximize the sleep phase with a duty | ||||
cycle lower than 10%. | ||||
4. Unique requirements of home automation applications | +------------------------------- +-----------------------------+ | |||
| Use case | Requirement | | ||||
+------------------------------- +-----------------------------+ | ||||
|2.1. Lighting Application In |3.1. Support of Groupcast | | ||||
|Action |3.3. Support of Mobility | | ||||
| |3.6. Scalability | | ||||
+------------------------------- +-----------------------------+ | ||||
|2.2. Energy Conservation and |3.2. Constraint-based Routing| | ||||
|Optimizing Energy Consumption | | | ||||
+------------------------------- +-----------------------------+ | ||||
|2.3. Moving a Remote Control |3.3. Support of Mobility | | ||||
|Around |3.7. Convergence Time | | ||||
+------------------------------- +-----------------------------+ | ||||
|2.4. Adding A New Module To The |3.7. Convergence Time | | ||||
|System |3.8. Manageability | | ||||
+------------------------------- +-----------------------------+ | ||||
|2.5. Controlling Battery |3.4. Sleeping Nodes | | ||||
|Operated Window Shades | | | ||||
+------------------------------- +-----------------------------+ | ||||
|2.7. Healthcare |3.2. Constraint-based Routing| | ||||
| |3.3. Support of Mobility | | ||||
| |3.5. Healthcare Routing | | ||||
| |3.7. Convergence Time | | ||||
+------------------------------- +-----------------------------+ | ||||
|2.8. Alarm Systems |3.6. Scalability | | ||||
| |3.7. Convergence Time | | ||||
+------------------------------- +-----------------------------+ | ||||
Home automation applications have a number of specific requirements | 3.1. Support of Groupcast | |||
related to the set of home networking applications and the perceived | ||||
operation of the system. | ||||
4.1. Support of groupcast | +----------------------------------------------------------+ | |||
| Author's note: | | ||||
| The support of groupcast only has implication on the | | ||||
| addressing scheme and as such, it is outside the scope | | ||||
| of this document that focuses on routing requirements. | | ||||
| Nevertheless, it is an important parameter for the | | ||||
| definition of the ROLL layer interface towards various | | ||||
| layer two technologies for home control. | | ||||
| | | ||||
| Should a dedicated application-specific document be | | ||||
| created for such details? | | ||||
+----------------------------------------------------------+ | ||||
Groupcast, in the context of home automation, is defined as the | Groupcast, in the context of home automation, is defined as the | |||
ability to simultaneously transmit a message to a group of recipients | ability to simultaneously transmit a message to a group of | |||
without prior interaction with the group members (i.e. group setup). | recipients without prior interaction with the group members (i.e. | |||
A use-case for groupcast is given in Section 3.1. | group setup). A use-case for groupcast is given in Section 2.1. | |||
Broadcast and groupcast in home automation MAY be used to deliver the | Broadcast and groupcast in home automation MAY be used to achieve | |||
illusion that all recipients respond simultaneously. Distant | simultaneous reaction from a group of nodes. | |||
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 | It SHOULD be to possible to address a group of receivers known by | |||
implication on the addressing scheme and are outside the scope of | the sender even if the receivers do not know that they have been | |||
this document that focuses on the routing requirements aspects. | grouped by the sender. | |||
It MUST be to possible to address a group of receivers known by the | 3.2. Constraint-based Routing | |||
sender even if the receivers do not know that they have been grouped | ||||
by the sender. | ||||
4.2. Constraint-based Routing | For convenience and low operational costs, power consumption of | |||
consumer products must be kept at a very low level to achieve a | ||||
long battery lifetime. One implication of this fact is that Random | ||||
Access Memory (RAM) is limited and it may even be powered down; | ||||
leaving only a few 100 bytes of RAM alive during the sleep phase. | ||||
Simple battery-powered nodes such as movement sensors on garage doors | The use of battery powered devices reduces installation costs and | |||
and rain meters may not be able to assist in routing. Depending on | does enable installation of devices even where main power lines | |||
the node type, the node never listens at all, listens rarely or makes | are not available. On the other hand, in order to be cost | |||
contact on demand to a pre-configured target node. Attempting to | effective and efficient, the devices have to maximize the sleep | |||
communicate to such nodes may require long time before getting a | phase with a duty cycle lower than 1%. | |||
response. | ||||
Other battery-powered nodes may have the capability to participate in | Some devices only wake up in response to an event, e.g. a push | |||
routing. The routing protocol should either share the load between | button. | |||
nodes to preserve battery or only route via mains-powered nodes if | ||||
possible. The most reliable routing resource may be a battery-backed, | Simple battery-powered nodes such as movement sensors on garage | |||
mains-powered smoke alarm. | doors and rain sensors 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 at best require long | ||||
time before getting a response. | ||||
Other battery-powered nodes may have the capability to participate | ||||
in routing. The routing protocol SHOULD route via mains-powered | ||||
nodes if possible. | ||||
The routing protocol MUST support constraint-based routing taking | The routing protocol MUST support constraint-based routing taking | |||
into 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 | 3.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 | |||
route discovery times measured in seconds, a remote control appears | tolerate route discovery times measured in seconds, a remote | |||
unresponsive if using more than 0.5 seconds to e.g. pause the music. | control appears 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 | |||
in modules may be moved, the predominant case is that the sending | plug-in modules may be moved, the predominant case is that the | |||
node has moved while the rest of the network has not changed. | sending 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. | |||
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. In | node, 2) a failed link on the path to the node or 3) a moved node. | |||
the first two cases, the node can be expected to reappear at roughly | In the first two cases, the node can be expected to reappear at | |||
the same location in the network, whereas it can return anywhere in | roughly the same location in the network, whereas it can return | |||
the network in the latter case. The search strategy in the routing | anywhere in the network in the latter case. | |||
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 | 3.4. Sleeping Nodes | |||
The routing protocol MUST support the recognition of neighbors and | Sleeping nodes may appear to be non-responsive. The routing | |||
periodical scanning. This process SHOULD preserve energy capacity as | protocol MUST take into account the delivery time to a sleeping | |||
much as possible. | target node. | |||
(Derived from use case 3.8. Alarm Systems) | The wake-up interval of a sleeping node MUST be less than one | |||
second. | ||||
4.5. Scalability | 3.5. Healthcare Routing | |||
Because most health care applications may run on battery, this | ||||
leads to specific requirements for the routing protocol. Most | ||||
health care applications may also be portable and therefore need | ||||
to locate a new neighbor router on a frequent basis. | ||||
Not being powered most of the time, the nodes should not be used | ||||
as routing nodes. However, battery-powered nodes may be involved | ||||
in routing. Examples include cases where a person falls during a | ||||
power blackout. In that case it may be that no mains-powered | ||||
routers are available for forwarding the alarm message to a | ||||
(battery-backed) internet gateway located out of direct range. | ||||
Delivery of measurement data has a more relaxed requirement for | ||||
route discovery time compared to a remote control. On the other | ||||
hand, it is critical that a "person fell" alarm is actually | ||||
delivered. | ||||
3.6. 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 seems | various nature, video equipment and so on in a modern house, it | |||
quite realistic that hundreds of low power devices may form a home | seems quite realistic that hundreds of low power devices may form | |||
automation network in a fully populated "smart" home. Moving towards | a home automation network in a fully populated "smart" home. | |||
professional building automation, the number of such devices may be | Moving towards professional building automation, the number of | |||
in the order of several thousands. | such devices may be in the order of several thousands. | |||
Thus, the routing protocol MUST support 250 devices in a subnet. | The routing protocol MUST support 250 devices in the network. | |||
The routing protocol SHOULD support 2500 devices in a subnet. | ||||
4.6. Convergence Time | 3.7. Convergence Time | |||
A home automation Personal Area Network (PAN) is subject to various | A wireless home automation network is subject to various | |||
instability due to signal strength variation, moving persons and the | instabilities due to signal strength variation, moving persons and | |||
like. Furthermore, as the number of devices increases, the | the like. Furthermore, as the number of devices increases, the | |||
probability of a node failure also 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 | |||
time requirements apply. | convergence 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 | |||
moved. | have 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 | In both cases, "converge" means "the originator node has received | |||
a response from the destination node". | ||||
The ability of the home network to support auto-configuration is of | 3.8. Manageability | |||
the utmost importance. Indeed, most end users will not have the | ||||
The ability of the home network to support auto-configuration is | ||||
of the utmost importance. Indeed, most end users will not have the | ||||
expertise and the skills to perform advanced configuration and | 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 | |||
provide a set of features including zero-configuration of the routing | automation networks MUST provide a set of features including zero- | |||
protocol for a new node to be added to the network. From ROLL | configuration of the routing protocol for a new node to be added | |||
perspective, zero-configuration means that a node can obtain an | to the network. From a routing perspective, zero-configuration | |||
address and join the network on its own, without human intervention. | means that a node can obtain an address and join the network on | |||
its own, without human intervention. | ||||
3.9. 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 overall | misbehaving node thus preserving the correct operation of the | |||
network. | overall network. | |||
5. Traffic Pattern | 4. Traffic Pattern | |||
Depending on the philosophy of the home network, wall switches may be | Depending on the design philosophy of the home network, wall | |||
configured to directly control individual lamps or alternatively, all | switches may be configured to directly control individual lamps or | |||
wall switches send control commands to a central lighting control | alternatively, all wall switches send control commands to a | |||
computer which again sends out control commands to relevant devices. | central lighting control 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 multipoint-to- | |||
centralized system, it is a mix of any-to-one and one-to-many. | multipoint. In a centralized system, it is a mix of multipoint-to- | |||
point and point-to-multipoint. | ||||
Wall switches only generate traffic when activated, which typically | Wall switches only generate traffic when activated, which | |||
happens from a one to tens of times per hour. | typically happens from a one to tens of times per hour. | |||
Remote controls have a similar transmit pattern to wall switches, but | Remote controls have a similar transmit pattern to wall switches, | |||
are activated more frequently. | but are activated more frequently. | |||
Temperature/air pressure/rain sensors send frames when queried by the | Temperature/air pressure/rain sensors send frames when queried by | |||
user or can be preconfigured to send measurements at fixed intervals | the user or can be preconfigured to send measurements at fixed | |||
(typically minutes). Motion sensors typically send a frame when | intervals (typically minutes). Motion sensors typically send a | |||
motion is first detected and another frame when an idle period with | frame when motion is first detected and another frame when an idle | |||
no movement has elapsed. The highest transmission frequency depends | period with no movement has elapsed. The highest transmission | |||
on the idle period used in the sensor. Sometimes, a timer will | frequency depends on the idle period used in the sensor. | |||
trigger a frame transmission when an extended period without status | Sometimes, a timer will trigger a frame transmission when an | |||
change has elapsed. | extended period without status change has elapsed. | |||
All frames sent in the above examples are quite short, typically less | All frames sent in the above examples are quite short, typically | |||
than 5 bytes of payload. Lost frames and interference from other | less than 5 bytes of payload. Lost frames and interference from | |||
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. Open issues | 5. 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 Groupcast definition in a separate document? (TBD) | ||||
o Use case: Home Control Installer Scenario | ||||
o Security | o Security | |||
7. Security Considerations | 6. Security Considerations | |||
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 | Implementing security mechanisms in ROLL network devices may | |||
examples where strong encryption and authentication are needed. The | degrade energy efficiency and increase cost. | |||
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 | The routing protocol chosen for ROLL MUST allow for low-power, | |||
not need encryption. | low-cost network devices with limited security needs. | |||
Protection against unintentional inclusion in neighboring networks | Protection against unintentional inclusion in neighboring networks | |||
must be provided. Providing confidentiality, integrity and | MUST be provided. | |||
authentication against malicious opponents is optional. | ||||
8. IANA Considerations | 7. IANA Considerations | |||
This document includes no request to IANA. | This document includes no request to IANA. | |||
9. Acknowledgments | 8. Acknowledgments | |||
J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler and | J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler | |||
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. | |||
10. References | 9. References | |||
10.1. Normative References | As an exception, this internet draft contains references to other | |||
internet drafts. The reason is that the referenced internet drafts | ||||
are developed in parallel to this document. | ||||
When promoted to an RFC, the references MUST be updated to RFCs as | ||||
well or removed from the references section. | ||||
9.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 | draft-ietf-roll-indus-routing-reqs-01.txt | |||
draft-ietf-roll-urban-routing-reqs-01.txt | ||||
draft-martocci-roll-commercial-routing-reqs-00.txt | ||||
draft-ietf-roll-protocols-survey-00.txt | ||||
9.2. Informative References | ||||
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 | |||
Jakob Buron | ||||
Zensys, Inc. | ||||
Emdrupvej 26 | ||||
Copenhagen, DK-2100 | ||||
Denmark | ||||
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 | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed | |||
pertain to the implementation or use of the technology described in | to pertain to the implementation or use of the technology | |||
this document or the extent to which any license under such rights | described in this document or the extent to which any license | |||
might or might not be available; nor does it represent that it has | under such rights might or might not be available; nor does it | |||
made any independent effort to identify any such rights. Information | represent that it has made any independent effort to identify any | |||
on the procedures with respect to rights in RFC documents can be | such rights. Information on the procedures with respect to rights | |||
found in BCP 78 and BCP 79. | in RFC documents can be found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | 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 | attempt made to obtain a general license or permission for the use | |||
such proprietary rights by implementers or users of this | of such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository | |||
http://www.ietf.org/ipr. | at http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention | |||
copyrights, patents or patent applications, or other proprietary | any copyrights, patents or patent applications, or other | |||
rights that may cover technology that may be required to implement | proprietary rights that may cover technology that may be required | |||
this standard. Please address the information to the IETF at | to implement this standard. Please address the information to the | |||
ietf-ipr@ietf.org. | IETF at ietf-ipr@ietf.org. | |||
Disclaimer of Validity | Disclaimer of Validity | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | |||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | |||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | |||
FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | Copyright Statement | |||
Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
Acknowledgment | Acknowledgment | |||
End of changes. 124 change blocks. | ||||
413 lines changed or deleted | 526 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/ |