doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc5826.txt b/doc/rfc/rfc5826.txt
new file mode 100644
index 0000000..10b48b9
--- /dev/null
+++ b/doc/rfc/rfc5826.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Brandt
+Request for Comments: 5826                                      J. Buron
+Category: Informational                              Sigma Designs, Inc.
+ISSN: 2070-1721                                                 G. Porcu
+                                                          Telecom Italia
+                                                              April 2010
+
+
+  Home Automation Routing Requirements in Low-Power and Lossy Networks
+
+Abstract
+
+   This document presents requirements specific to home control and
+   automation applications for Routing Over Low power and Lossy (ROLL)
+   networks.  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 (radio-
+   frequency-based AV remote control, central server for light and heat
+   control).  Because such devices only cover a limited radio range,
+   routing is often required.  The aim of this document is to specify
+   the routing requirements for networks comprising such constrained
+   devices in a home-control and automation environment.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5286.
+
+
+
+
+
+
+
+
+
+
+
+
+Brandt, et al.                Informational                     [Page 1]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brandt, et al.                Informational                     [Page 2]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+      1.2. Requirements Language ......................................6
+   2. Home Automation Applications ....................................6
+      2.1. Lighting Application in Action .............................6
+      2.2. Energy Conservation and Optimizing Energy Consumption ......6
+      2.3. Moving a Remote Control Around .............................7
+      2.4. Adding a New Module to the System ..........................7
+      2.5. Controlling Battery-Operated Window Shades .................8
+      2.6. Remote Video Surveillance ..................................8
+      2.7. Healthcare .................................................9
+           2.7.1. At-Home Health Reporting ...........................10
+           2.7.2. At-Home Health Monitoring ..........................10
+      2.8. Alarm Systems .............................................10
+   3. Unique Routing Requirements of Home Automation Applications ....11
+      3.1. Constraint-Based Routing ..................................12
+      3.2. Support of Mobility .......................................12
+      3.3. Scalability ...............................................13
+      3.4. Convergence Time ..........................................13
+      3.5. Manageability .............................................14
+      3.6. Stability .................................................14
+   4. Traffic Pattern ................................................14
+   5. Security Considerations ........................................15
+   6. Acknowledgments ................................................16
+   7. References .....................................................16
+      7.1. Normative References ......................................16
+      7.2. Informative References ....................................17
+
+1.  Introduction
+
+   This document presents requirements specific to home control and
+   automation applications for Routing Over Low power and Lossy (ROLL)
+   networks.  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.
+
+
+
+Brandt, et al.                Informational                     [Page 3]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   Because ROLL nodes only cover a limited radio range, routing is often
+   required.  These devices are usually highly constrained in terms 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 become reusable
+   again, thus the term "lossy".  All traffic in a ROLL network is
+   carried as IPv6 packets.
+
+   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 battery-operated, 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.
+
+   Although this document focuses its text on radio-based wireless
+   networks, home-automation networks may also operate using a variety
+   of links, such as IEEE 802.15.4, Bluetooth, Low-Power WiFi, wired or
+   other low-power PLC (Power-Line Communication) links.  Many such low-
+   power link technologies share similar characteristics with low-power
+   wireless and this document should be regarded as applying equally to
+   all such links.
+
+   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 [BUILDING-REQS], [RFC5673], and [RFC5548].
+
+   A full list of requirements documents may be found in Section 7.
+
+1.1.  Terminology
+
+   ROLL:          Routing Over Low-power and Lossy networks.  A ROLL
+                  node may be classified as a sensor, actuator, or
+                  controller.
+
+   Actuator:      Network node that performs some physical action.
+                  Dimmers and relays are examples of actuators.  If
+                  sufficiently powered, actuator nodes may participate
+                  in routing network messages.
+
+
+
+
+Brandt, et al.                Informational                     [Page 4]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   Border router: Infrastructure device that connects a ROLL network to
+                  the Internet or some backbone network.
+
+   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 the 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.
+
+   LLNs:          Low-Power and Lossy Networks.
+
+   LAN:           Local Area Network.
+
+   PAN:           Personal Area Network.  A geographically limited
+                  wireless network based on, e.g., 802.15.4 or Z-Wave
+                  radio.
+
+   PDA            Personal Digital Assistant.  A small, handheld
+                  computer.
+
+   PLC            Power-Line Communication.
+
+   RAM            Random Access Memory.
+
+   Sensor:        Network node that measures some physical parameter
+                  and/or detects an 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.
+
+   Upstream:      Data direction traveling from a PAN to a LAN device.
+
+
+
+
+Brandt, et al.                Informational                     [Page 5]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   Refer to the ROLL terminology reference document [ROLL-TERM] for a
+   full list of terms used in the IETF ROLL WG.
+
+1.2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Home Automation Applications
+
+   Home automation applications represent a special segment of networked
+   devices with its unique set of requirements.  Historically, such
+   applications used wired networks or power-line communication (PLC)
+   but wireless solutions have emerged, allowing existing homes to be
+   upgraded more easily.
+
+   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.
+
+2.1.  Lighting Application in Action
+
+   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-button
+   sensor and an actuator at the same time.  This will often be the case
+   when upgrading existing homes as existing wiring is not prepared for
+   automation.
+
+   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.
+
+2.2.  Energy Conservation and Optimizing Energy Consumption
+
+   In order to save energy, air conditioning, central heating, window
+   shades, etc., may be controlled by timers, motion sensors, or
+   remotely via Internet or cell.  Central heating may also be set to a
+   reduced temperature during nighttime.
+
+
+
+
+
+Brandt, et al.                Informational                     [Page 6]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   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 batteries on cheap
+   power.
+
+   In order to achieve effective electricity savings, the energy
+   monitoring application must guarantee that the power consumption of
+   the ROLL devices is much lower than that of the appliance itself.
+
+   Most of these appliances are mains powered and are thus ideal for
+   providing reliable, always-on routing resources.  Battery-powered
+   nodes, by comparison, are constrained routing resources and may only
+   provide reliable routing under some circumstances.
+
+2.3.  Moving a Remote Control Around
+
+   A remote control is a typical example of a mobile device in a home
+   automation network.  An advanced remote control may be used for
+   dimming the light in the dining room while eating and later on,
+   turning up the music while doing the dishes in the kitchen.  Reaction
+   must appear to be instant (within a few hundred milliseconds) even
+   when the remote control has moved to a new location.  The remote
+   control may be communicating to either a central home automation
+   controller or directly to the lamps and the media center.
+
+2.4.  Adding a New Module to the System
+
+   Small-size, low-cost modules may have no user interface except for a
+   single button.  Thus, an automated inclusion process is needed for
+   controllers to find new modules.  Inclusion covers the detection of
+   neighbors and the assignment of a unique node ID.  Inclusion should
+   be completed within a few seconds.
+
+
+
+
+Brandt, et al.                Informational                     [Page 7]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   For ease of use in a consumer application space such as home control,
+   nodes may be included without having to type in special codes before
+   inclusion.  One way to achieve an acceptable balance between security
+   and convenience is to block inclusion during normal operation,
+   explicitly enable inclusion support just before adding a new module,
+   and disable it again just after adding a new module.
+
+   For security considerations, refer to Section 5.
+
+   If assignment of unique addresses is performed by a central
+   controller, it must be possible to route the inclusion request from
+   the joining node to the central controller before the joining node
+   has been included in the network.
+
+2.5.  Controlling Battery-Operated Window Shades
+
+   In consumer premises, window shades are often battery-powered as
+   there is no access to mains power over the windows.  For battery
+   conservation purposes, such an actuator node is sleeping most of the
+   time.  A controller sending commands to a sleeping actuator node via
+   ROLL devices will have no problems delivering the packet to the
+   nearest powered router, but that router may experience a delay until
+   the next wake-up time before the command can be delivered.
+
+2.6.  Remote Video Surveillance
+
+   Remote video surveillance is a fairly classic application for home
+   networking.  It provides the ability for the end-user to get a video
+   stream from a web cam reached via the Internet.  The video stream may
+   be triggered by the end-user after receiving an alarm from a sensor
+   (movement or smoke detector) or the user simply wants to check the
+   home status via video.
+
+   Note that in the former case, more than likely, there will be a form
+   of inter-device communication: upon detecting some movement in the
+   home, the movement sensor may send a request to the light controller
+   to turn on the lights, to the Web Cam to start a video stream that
+   would then be directed to the end-user's cell phone or Personal
+   Digital Assistant (PDA) via the Internet.
+
+   In contrast to other applications, e.g., industrial sensors, where
+   data would mainly be originated by a sensor to a sink and vice versa,
+   this scenario implicates a direct inter-device communication between
+   ROLL devices.
+
+
+
+
+
+
+
+Brandt, et al.                Informational                     [Page 8]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+2.7.  Healthcare
+
+   By adding communication capability to devices, patients and elderly
+   citizens may be able to do simple measurements at home.
+
+   Thanks to online devices, a doctor can keep an eye on the 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
+   the doctor to establish a more precise diagnosis.
+
+   Such applications may be realized as wearable products that
+   frequently do a measurement and automatically deliver the result to a
+   data sink locally or over the Internet.
+
+   Applications falling in this category are referred to as at-home
+   health reporting.  Whether measurements are done in a fixed interval
+   or they are manually activated, they leave all processing to the
+   receiving data sink.
+
+   A more active category of applications may send an alarm if some
+   alarm condition is triggered.  This category of applications is
+   referred to as at-home health monitoring.  Measurements are
+   interpreted in the device and may cause reporting of an event if an
+   alarm is triggered.
+
+   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 five 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.
+
+
+
+
+
+
+
+
+
+
+
+Brandt, et al.                Informational                     [Page 9]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+2.7.1.  At-Home Health Reporting
+
+   Applications might include:
+
+   o Temperature
+   o Weight
+   o Blood pressure
+   o Insulin level
+
+   Measurements may be stored for long-term statistics.  At the same
+   time, a critically high blood pressure may cause the generation of an
+   alarm report.  Refer to Section 2.7.2.
+
+   To avoid a high number of request messages, nodes may be configured
+   to autonomously do a measurement and send a report in intervals.
+
+2.7.2.  At-Home Health Monitoring
+
+   An alarm event may become active, e.g., if the measured blood
+   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:
+
+   o Temperature
+   o Weight
+   o Blood pressure
+   o Insulin level
+   o Electrocardiogram (ECG)
+   o Position tracker
+
+2.8.  Alarm Systems
+
+   A home security alarm system is comprised of various sensors
+   (vibration, fire, carbon monoxide, door/window, glass-break,
+   presence, panic button, etc.).
+
+   Some smoke alarms are battery powered and at the same time mounted in
+   a high place.  Battery-powered safety devices should only be used for
+   routing if no other alternatives exist to avoid draining the battery.
+   A smoke alarm with a drained battery does not provide a lot of
+   safety.  Also, it may be inconvenient to change the batteries in a
+   smoke alarm.
+
+
+
+
+
+
+
+Brandt, et al.                Informational                    [Page 10]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   Alarm system applications may have both a synchronous and an
+   asynchronous behavior; i.e., they may be periodically queried by a
+   central control application (e.g., for a periodical refreshment of
+   the network state) or send a message to the control application on
+   their own initiative.
+
+   When a node (or a group of nodes) identifies a risk situation (e.g.,
+   intrusion, smoke, fire), it sends an alarm message to a central
+   controller that could autonomously forward it via the Internet or
+   interact with other network nodes (e.g., try to obtain more detailed
+   information or ask other nodes close to the alarm event).
+
+   Finally, routing via battery-powered nodes may be very slow if the
+   nodes are sleeping most of the time (they could appear unresponsive
+   to the alarm detection).  To ensure fast message delivery and avoid
+   battery drain, routing should be avoided via sleeping devices.
+
+3.  Unique Routing Requirements of Home Automation Applications
+
+   Home automation applications have a number of specific routing
+   requirements related to the set of home networking applications and
+   the perceived operation of the system.
+
+   The relations of use cases to requirements are outlined in the table
+   below:
+
+   +------------------------------+-----------------------------+
+   | Use case                     | Requirement                 |
+   +------------------------------+-----------------------------+
+   |2.1. Lighting Application in  |3.2. Support of Mobility     |
+   |Action                        |3.3. Scalability             |
+   +------------------------------+-----------------------------+
+   |2.2. Energy Conservation and  |3.1. Constraint-Based Routing|
+   |Optimizing Energy Consumption |                             |
+   +------------------------------+-----------------------------+
+   |2.3. Moving a Remote Control  |3.2. Support of Mobility     |
+   |Around                        |3.4. Convergence Time        |
+   +------------------------------+-----------------------------+
+   |2.4. Adding a New Module to   |3.4. Convergence Time        |
+   |the System                    |3.5. Manageability           |
+   +------------------------------+-----------------------------+
+   |2.7. Healthcare               |3.1. Constraint-Based Routing|
+   |                              |3.2. Support of Mobility     |
+   |                              |3.4. Convergence Time        |
+   +------------------------------+-----------------------------+
+   |2.8. Alarm Systems            |3.3. Scalability             |
+   |                              |3.4. Convergence Time        |
+   +------------------------------+-----------------------------+
+
+
+
+Brandt, et al.                Informational                    [Page 11]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+3.1.  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.
+
+   The use of battery-powered devices reduces installation costs and
+   does enable installation of devices even where main power lines are
+   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 1%.
+
+   Some devices only wake up in response to an event, e.g., a push
+   button.
+
+   Simple battery-powered nodes such as movement sensors on garage 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 with such nodes may at best require a 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
+   into account node properties (CPU, memory, level of energy, sleep
+   intervals, safety/convenience of changing battery).
+
+3.2.  Support of Mobility
+
+   In a home environment, although the majority of devices are fixed
+   devices, there is still a variety of mobile devices, for example, a
+   remote control is likely to move.  Another example of mobile devices
+   is wearable healthcare devices.
+
+   While healthcare devices delivering measurement results can tolerate
+   route discovery times measured in seconds, a remote control appears
+   unresponsive if using more than 0.5 seconds to, e.g., pause the
+   music.
+
+   On more rare occasions, receiving nodes may also have moved.
+   Examples include a safety-off switch in a clothes iron, a vacuum
+   cleaner robot, or the wireless chime of doorbell set.
+
+
+
+
+Brandt, et al.                Informational                    [Page 12]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   Refer to Section 3.4 for routing protocol convergence times.
+
+   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 the first two cases, the node can be expected to reappear at
+   roughly the same location in the network, whereas it can return
+   anywhere in the network in the latter case.
+
+3.3.  Scalability
+
+   Looking at the number of wall switches, power outlets, sensors of
+   various natures, video equipment, and so on in a modern house, it
+   seems quite realistic that hundreds of devices may form a home-
+   automation network in a fully populated "smart" home, and a large
+   proportion of those may be low-power devices.  Moving towards
+   professional-building automation, the number of such devices may be
+   in the order of several thousands.
+
+   The routing protocol needs to be able to support a basic home
+   deployment and so MUST be able to support at least 250 devices in the
+   network.  Furthermore, the protocol SHOULD be extensible to support
+   more sophisticated and future deployments with a larger number of
+   devices.
+
+3.4.  Convergence Time
+
+   A wireless home automation network is subject to various
+   instabilities due to signal strength variation, moving persons, and
+   the like.
+
+   Measured from the transmission of a packet, the following convergence
+   time requirements apply.
+
+   The routing protocol MUST converge within 0.5 seconds if no nodes
+   have moved (see Section 3.2 for motivation).
+
+   The routing protocol MUST converge within four seconds if nodes have
+   moved to re-establish connectivity within a time that a human
+   operator would find tolerable as, for example, when moving a remote
+   control unit.
+
+   In both cases, "converge" means "the originator node has received a
+   response from the destination node".  The above-mentioned convergence
+   time requirements apply to a home control network environment of up
+   to 250 nodes with up to four repeating nodes between source and
+   destination.
+
+
+
+
+
+Brandt, et al.                Informational                    [Page 13]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+3.5.  Manageability
+
+   The ability of the home network to support auto-configuration is of
+   the utmost importance.  Indeed, most end-users will not have the
+   expertise and the skills to perform advanced configuration and
+   troubleshooting.  Thus, the routing protocol designed for home-
+   automation networks MUST provide a set of features including zero-
+   configuration of the routing protocol for a new node to be added to
+   the network.  From a routing perspective, zero-configuration means
+   that a node can obtain an address and join the network on its own,
+   almost without human intervention.
+
+3.6.  Stability
+
+   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
+
+   Depending on the design philosophy of the home network, wall switches
+   may be configured to directly control individual lamps or
+   alternatively, all wall switches send control commands to a central
+   lighting control computer, which again sends out control commands to
+   relevant devices.
+
+   In a distributed system, the traffic tends to be multipoint-to-
+   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
+   happens from one to ten times per hour.
+
+   Remote controls have a similar transmit pattern to wall switches but
+   may be activated more frequently in some deployments.
+
+   Temperature/air and pressure/rain sensors send frames when queried by
+   the user or can be preconfigured to send measurements at fixed
+   intervals (typically minutes).  Motion sensors typically send a frame
+   when motion is first detected and another frame when an idle period
+   with no movement has elapsed.  The highest transmission frequency
+   depends on the idle period used in the sensor.  Sometimes, a timer
+   will trigger a frame transmission when an extended period without
+   status change has elapsed.
+
+   All frames sent in the above examples are quite short, typically less
+   than five bytes of payload.  Lost frames and interference from other
+   transmitters may lead to retransmissions.  In all cases,
+   acknowledgment frames with a size of a few bytes are used.
+
+
+
+Brandt, et al.                Informational                    [Page 14]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+5.  Security Considerations
+
+   As is the case with every network, LLNs are exposed to routing
+   security threats 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 LLN.  These issues require
+   special attention during the design process, so as to facilitate a
+   commercially attractive deployment.
+
+   An attacker can snoop, replay, or originate arbitrary messages to a
+   node in an attempt to manipulate or disable the routing function.
+
+   To mitigate this, the LLN MUST be able to authenticate a new node
+   prior to allowing it to participate in the routing decision process.
+   The routing protocol MUST support message integrity.
+
+   A further example of routing security issues that may arise is 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 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 LLN before the
+   former can take part in self-configuration or self-organization.  A
+   node that has already authenticated and associated with the 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.
+
+
+
+
+
+Brandt, et al.                Informational                    [Page 15]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+   In a home-control environment, it is considered unlikely that a
+   network is constantly being snooped and at the same time, ease of use
+   is important.  As a consequence, the network key MAY be exposed for
+   short periods during inclusion of new nodes.
+
+   Electronic door locks and other critical applications SHOULD apply
+   end-to-end application security on top of the network transport
+   security.
+
+   If connected to a backbone network, the 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 LLN.
+
+   With low-computation power and scarce energy resources, 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 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 LLNs MUST support authentication and integrity
+   measures and SHOULD support confidentiality (routing security)
+   measures.
+
+6.  Acknowledgments
+
+   J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler, and
+   Massimo Maggiorotti are gratefully acknowledged for their
+   contributions to this document.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Brandt, et al.                Informational                    [Page 16]
+
+RFC 5826      Home Automation Routing Requirements in LLNs    April 2010
+
+
+7.2.  Informative References
+
+   [BUILDING-REQS] Martocci, J., Ed., De Mil, P., Vermeylen, W., and N.
+                   Riou, "Building Automation Routing Requirements in
+                   Low Power and Lossy Networks", Work in Progress,
+                   January 2010.
+
+   [RFC5548]       Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed.,
+                   and D. Barthel, Ed., "Routing Requirements for Urban
+                   Low-Power and Lossy Networks", RFC 5548, May 2009.
+
+   [RFC5673]       Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
+                   Phinney, "Industrial Routing Requirements in Low-
+                   Power and Lossy Networks", RFC 5673, October 2009.
+
+   [ROLL-TERM]     Vasseur, JP. "Terminology in Low power And Lossy
+                   Networks", Work in Progress, October 2009.
+
+Authors' Addresses
+
+   Anders Brandt
+   Sigma Designs, Inc.
+   Emdrupvej 26
+   Copenhagen, DK-2100
+   Denmark
+
+   EMail: abr@sdesigns.dk
+
+
+   Jakob Buron
+   Sigma Designs, Inc.
+   Emdrupvej 26
+   Copenhagen, DK-2100
+   Denmark
+
+   EMail: jbu@sdesigns.dk
+
+
+   Giorgio Porcu
+   Telecom Italia
+   Piazza degli Affari, 2
+   20123 Milan
+   Italy
+
+   EMail: gporcu@gmail.com
+
+
+
+
+
+
+Brandt, et al.                Informational                    [Page 17]
+