[Roll] Document Action: 'Home Automation Routing Requirements in Low Power and Lossy Networks' to Informational RFC

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Home Automation Routing Requirements in Low Power and Lossy Networks '
   <draft-ietf-roll-home-routing-reqs-11.txt> as an Informational RFC


This document is the product of the Routing Over Low power and Lossy networks Working Group. 

The IESG contact persons are Adrian Farrel and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-11.txt

Technical Summary

    This document presents home control and automation application
    specific requirements for Routing Over Low power and Lossy
    networks (ROLL). In a modern home, a high number of wireless
    devices are used for a wide set of purposes. Examples include
    actuators (relay, light dimmer, heating valve), sensors (wall
    switch, water leak, blood pressure) and advanced controllers.
    Basic home control modules such as wall switches and plug-in
    modules may be turned into an advanced home automation solution
    via the use of an IP-enabled application responding to events
    generated by wall switches, motion sensors, light sensors, rain
    sensors, and so on.

    Network nodes may be sensors and actuators at the same time. An
    example is a wall switch for replacement in existing buildings.
    The push buttons may generate events for a controller node or for
    activating other actuator nodes. At the same time, a built-in
    relay may act as actuator for a controller or other remote
    sensors.

    Because ROLL nodes only cover a limited radio range, routing is
    often required. These devices are usually highly constrained in
    term of resources such as battery and memory and operate in
    unstable environments. Persons moving around in a house, opening
    or closing a door or starting a microwave oven affect the
    reception of weak radio signals. Reflection and absorption may
    cause a reliable radio link to turn unreliable for a period of
    time and then being reusable again, thus the term "lossy".

    Unlike other categories of PANs, the connected home area is very
    much consumer-oriented. The implication on network nodes is that
    devices are very cost sensitive, which leads to resource-
    constrained environments having slow CPUs and small memory
    footprints. At the same time, nodes have to be physically small
    which puts a limit to the physical size of the battery; and thus,
    the battery capacity. As a result, it is common for low-power
    sensor-style nodes to shut down radio and CPU resources for most
    of the time. The radio tends to use the same power for listening
    as for transmitting

    Section 2 describes a few typical use cases for home automation
    applications. Section 3 discusses the routing requirements for
    networks comprising such constrained devices in a home network
    environment. These requirements may be overlapping requirements
    derived from other application-specific routing requirements. A
    full list of requirements documents may be found in the end of the
    document.

Working Group Summary

    No controversy.

Document Quality

   The I-D is informational and specifies routing requirements

Personnel

   JP Vasseur ([e-mail]) is the Document Shepherd.
   Adrian Farrel ([e-mail]) is the Responsible AD. 

RFC Editor Note

Section 1

ADD new paragraph before the paragraph beginning "Section 2 describes a 
few..."

   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 (Powerline 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 3.3

OLD
   Looking at the number of wall switches, power outlets, sensors of
   various nature, video equipment and so on in a modern house, it
   seems quite realistic that hundreds of low power devices may form
   a home automation network in a fully populated "smart" home.
   Moving towards professional building automation, the number of
   such devices may be in the order of several thousands.

   The routing protocol MUST support 250 devices in the network.

NEW
   Looking at the number of wall switches, power outlets, sensors of
   various nature, 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.

---

Section 3.4

OLD
   The routing protocol MUST converge within 0.5 second if no nodes
   have moved.

NEW
   The routing protocol MUST converge within 0.5 second if no nodes
   have moved (see Section 3.2 for motivation).

---

Section 3.4

OLD
   The routing protocol MUST converge within 4 seconds if nodes have
   moved.

NEW
   The routing protocol MUST converge within 4 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.

---

Section 4

OLD
   Remote controls have a similar transmit pattern to wall switches,
   but are activated more frequently.

NEW
   Remote controls have a similar transmit pattern to wall switches,
   but may be activated more frequently in some deployments.

---
Section 4

DELETE
   As mentioned in the introduction, all messages are carried in IPv6
   packets; typically as UDP but ICMP echo and other types may also
   appear.
   In order to save bandwidth, the transport layer will typically be
   using header compression [I-D.Hui-HeaderCompression].

---