Home Automation Routing Requirements in Low-Power and Lossy Networks
draft-ietf-roll-home-routing-reqs-11

[Ballot comment]
The prose frequently assumes radio-based wireless.  The charter for the
group calls out other technologies.  Is it possible that some
requirements motivated by those other technologies have been missed?

You might want to consider devices like robot-vacuum cleaners as nodes
that can be both transmitters and receivers that will be highly
portable.

(Pasi captured this better in his discuss, but this was already written so I'm leaving it here to inform that conversation).
Has the group begun to explore the conflict between the authentication
requirements in the security consideration section and the
zero-configuration for access requirements earlier in the document? If
so, capturing some of that discussion would be helpful. If not, there
may be related requirements that the group hasn't uncovered yet.

---- Old DISCUSS text downgraded to Comments ----

I support Lars' discuss regarding requirements on applications vs requirements on the routing protocol.

There are several constants presented as requirements without
motivation. Where did the .5 second, 2 second, and 4 second
convergence times come from? Why is the receiver-moved-only
requirement in 3.2 separated in the text from the sender-moved-only
requirement in 3.6?

What is section 4 informing? If it is truly necessary, then many of the
claims (frequency of switch/remote use, frequency of sensor reporting)
needs to point to some reference for authority. The end of that section
also makes some claims about mechanism ("typically as UDP" for
example) that are out of place. Can the section be deleted?

The paragraph motivating "MUST support 250 devices" is not persuasive
(plugs and switches are not inherently going to be low-power nodes).
What led to the choice of this particular constant?

[Ballot discuss]
Glad to see this doc - I'm very keen on this work and look forward to being able to use it. Few issues that if we can resolve them now as requirements, I think will help get the protocol work done faster.

[Ballot discuss]
I have two questions with section 3.4 which discusses Healthcare Routing, and an overall issue. 

To me it seems like an error for the routers, or the routing layer, to know that a particular packet is specifically related to Health Care. Are routers also going to know separately about financial data, fire alarms, burgular alarms, and other high-priority classes of packets? It certainly would make good sense for the routers to know that a particular packet is high priority and really must get through (even if delayed), whereas another packet is lower priority. It also would make sense for routers to know that some packets if delayed might as well be discarded, while other packets if delayed should be stored and delivered when possible. This seems like a sensible application of diff serve. I think that this whole section needs to be re-thought. As one example of how this might be reconsidered, the sentence "the routing protocol MUST deliver a health-care related message" might better be written "the routing protocol MUST deliver a packet that is marked with the diff serve class "high priority, don't discard".

Also, the next paragraph "The routing protocol SHOULD support acknowledged transmission". Again this is mixing layers. The routing protocol MUST support bi-directional traffic. The way in which the transport layer or the applications make use of the network SHOULD (or MUST?) allow acknowledgment of data packets in cases where reliable delivery is needed.

My overall issue is that this document seems to imply a major shift in the architecture away from a model where the routers deliver packets, which some knowledge of the QoS requirements of the packets, to an architecture where the routers know about what each application is. On the one hand this would seem to be a serious limitation on the potential future uses of the network, and the home seems like one place where there are potentially huge numbers of possible future uses. Also, if we are going to make this major architectural shift, then there should be some explicit discussion of it.

[Ballot comment]
> Unlike other categories of Personal Area Networks (PANs), the
> connected home area is very much consumer-oriented.

Surely this is not true. I think most sports performance measurement
gear, phone & music player, etc. applications are very consumer
oriented. Perhaps you meant to say that other ROLL areas (like
industrial plant monitoring) are less consumer oriented than home
and PAN areas.

> 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.

I am wondering what value this paragraph adds. This may be a well
known problem, but it is certainly one of poor implementation
and/or choice of L2. I have a very hard time seeing this being
a problem due to routing, or even being a problem in a well
design network. In particular when home networks are naturally
quite limited in physical size, unlike factories or commercial
buildings.

> 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.

While this requirement is logical, I wonder to what extent it assumes
that we somehow have to redo many of the basic building blocks and
concepts that we have in IP networks. Does ROLL require something
AUTOCONF-like? I would certainly hope that we can still have
subnets and the basics of IP addressing stay the same, and that
things like DHCP and DHCP relays work.

> 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.

I'm not convinced that the home network is any more peer-to-peer
driven than other environments. Most equipment that we have today
is still centrally controlled, even if running on top of IP.

[Ballot discuss]
This is an important area and a document in this space is very welcome.
That being said, I'm not sure what to think of this document. If I had
written a document on this topic, it would probably say very different
things. I realize what the charter of the ROLL WG is, but the biggest
problem this document has is its high focus on the routing tools. There
are plenty of issues in building home networks like this, and one has
to find the right architecture and right tools to solve the issues.
This document goes too far in my opinion as positioning routing protocols
as the solution for some of the problems. Application layer mechanisms
for instance may be far more appropriate for some things.

This is not to say that there are no routing related requirements
in wireless ad hoc home networks. But the requirements seems relatively
easy:

- must support self-organized routing setup for a few dozen
  networks and few hundred devices
- must support QoS based routing and forwarding
- must support capability/constraint based routing

So I would suggest that the document be shortened to address my Discuss.
Some specific comments below.

> The routing protocol MUST provide mobility with convergence time
> below 0.5 second if only the sender has moved.
>
> The routing protocol MUST provide mobility with convergence time
> below 4 seconds if the receiver has moved.

This presumes a particular solution to mobility, i.e., doing it at the
routing layer. It is not clear that this would be the right solution.
I would probably personally employ a BAN and a cellular/WLAN uplink
from my phone which would solve the problem at L2, or an application
layer solution that would require nothing from the routing layer
and would work well in any existing network.

> 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.
>
> Sleeping nodes may appear to be non-responsive. The routing
> protocol MUST take into account the delivery time to a sleeping
> target node.

Hmm. I wonder what the real effect to the routing protocol is.
I am absolutely certain that application, transport, layer 2, and even
IP forwarding/queuing techniques change dramatically because of this.
But as far as I can tell, doesn't routing stay unaffected?

> The routing protocol SHOULD support acknowledged transmission. If
> the routing protocol does not support acknowledged transmission,
> some higher-layer transport protocol or application MUST ensure
> delivery of such messages.

Maybe I am misreading the first sentence, but I hope we are not
somehow changing the IP model or forwarding because of ROLL
requirements. IP should deliver packets, unreliably. Routing
should find out what the best and most reliable path is.
Link layers that are inherently very unreliable may increase
their reliability by proper MAC design (and e.g., L2 acknowledgements).
But I'm not sure what all this has to do with routing...

[Ballot comment]
What's the requirement to use V6 on a network with 250 devices? The message with a 5 byte payload will take substantial longer and more power to transmit than if one used v4. I realize the HC is designed to solve that problem but it seems like it is layer complexity on top of complexity.

I suspect you have the wrong "Status of memo boilerplate". You want the one that has "This document may contain material
  from IETF Documents or IETF Contributions published or made publicly
  available before November 10, 2008."

[Ballot discuss]
Glad to see this doc - I'm very keen on this work and look forward to being able to use it. Few issues that if we can resolve them now as requirements, I think will help get the protocol work done faster.


I'm not comfortable with the discussion of Health Care messages and specifically:

  If possible at all, the routing protocol MUST deliver a health-
  care related message.

I would like the requirements to make it clear if the requirement is to support safety critical messages or not. I have no problem with two (or more) levels of QoS where one has a better change of being delivered than the others but if this is going to specify enough to support safety critical messages, it needs to be crisp about the requirements that entails.

I don't think I understand what you mean by the following requirement. 

  The routing protocol SHOULD support acknowledged transmission.

The way I read this, I would say that IP does not provide that, but an application on top could. And SHOULD in requirements are pretty confusing to start with. Can you rephrase this requirement to be more concrete as a requirement and less of a solution?


Could you put more about the requirements around security and zero configuration of adding new elements. It must be secure, but new elements can automatically add themselves and disrupt routing seems contradictory. I also wonder about about how message integrity and zero conf enrollment will work.  I think it is possible to come up with a set of requirements that represent a reasonable balance here. Making it really easy to add or replace devices to the network, while still maintaining security, seems to be the key part of this system but seems both underspecified in the draft while at the same time being over constrained. Surely the alarm system case must impose some security requirements.

[Ballot comment]
The prose frequently assumes radio-based wireless.  The charter for the
group calls out other technologies.  Is it possible that some
requirements motivated by those other technologies have been missed?

You might want to consider devices like robot-vacuum cleaners as nodes
that can be both transmitters and receivers that will be highly
portable.

(Pasi captured this better in his discuss, but this was already written so I'm leaving it here to inform that conversation).
Has the group begun to explore the conflict between the authentication
requirements in the security consideration section and the
zero-configuration for access requirements earlier in the document? If
so, capturing some of that discussion would be helpful. If not, there
may be related requirements that the group hasn't uncovered yet.

[Ballot discuss]
DISCUSS

I support Lars' discuss regarding requirements on applications vs requirements on the routing protocol.

There are several constants presented as requirements without
motivation. Where did the .5 second, 2 second, and 4 second
convergence times come from? Why is the receiver-moved-only
requirement in 3.2 separated in the text from the sender-moved-only
requirement in 3.6?

What is section 4 informing? If it is truly necessary, then many of the
claims (frequency of switch/remote use, frequency of sensor reporting)
needs to point to some reference for authority. The end of that section
also makes some claims about mechanism ("typically as UDP" for
example) that are out of place. Can the section be deleted?

The paragraph motivating "MUST support 250 devices" is not persuasive
(plugs and switches are not inherently going to be low-power nodes).
What led to the choice of this particular constant?

[Ballot comment]
Section 3.2., paragraph 4:
>    The routing protocol MUST provide mobility with convergence time
>    below 0.5 second if only the sender has moved.

  There's an unstated assumption here regarding the size/diameter of the
  network. You might want to point to Section 3.5 here.


Section 3.8., paragraph 1:
>    The routing protocol MUST support the ability to isolate a
>    misbehaving node thus preserving the correct operation of the
>    overall network.
>    In other words, if a node is found to fail often compared to the
>    rest of the network, this node should not be the first choice for
>    routing of traffic.

  At least to me, the second paragraph isn't talking about the same
  thing as the first paragraph. The first one says "never use", the
  second says "not prefer."


Section 2.1., paragraph 3:
>    acknowledged singlecast messages to each device.

  Nit: s/singlecast/unicast/ (?)

[Ballot discuss]
Section 3.4., paragraph 3:
>    If possible at all, the routing protocol MUST deliver a health-
>    care related message. It is NOT a requirement that such message is
>    delivered in less than a second.
>    The routing protocol SHOULD support acknowledged transmission. If
>    the routing protocol does not support acknowledged transmission,
>    some higher-layer transport protocol or application MUST ensure
>    delivery of such messages.

  DISCUSS: I may be misunderstanding something, but why is reliable
  delivery of healthcare *application* data something that the *routing*
  protocol needs to do? If end-to-end reliability is required, the app
  or app protocol needs to be involved anyway. Clearly routing can aid
  this by providing paths to such apps that are more stable, but that's
  about it, no?

[Ballot comment]
I am supporting Pasi's DISCUSS about conflict of zero-configuration with security.

3.5. Scalability

  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.

Should this be "... MUST support at least 250 devices ...".
And to use Chris Newman's trick: why not say 257?

[Ballot discuss]
I have reviewed draft-ietf-roll-home-routing-reqs-08, and have couple
of questions/concerns that I'd like to discuss before recommending
approval of the document:

- The last paragraph of Section 3.4 seems to suggest that the routing
protocol could deliver acknowledgements to applications about whether
an IP packet was delivered or not (but this is more forwarding
than routing thing anyway). I think I'm probably misunderstanding
this text, and the intent was to say something else. But what exactly?

- Sections 3.7 and 5 seem to have conflicting requirements about
security and zero-configuration (adding a new node to the network
without any human intervention is pretty hard to combine with the
requirement to keep unwanted nodes out).

- It looks like [I-D.Hui-HeaderCompression] should be an informative
reference, not normative.

Proto-write-up for  draft-ietf-roll-home-routing-reqs-06

Intended status : Informational Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

JP Vasseur is the document shepherd.
He has personally reviewed the document and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

The I-D has been discussed and reviewed by the Working group.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

Good consensus.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

Checks have been made. No Errors.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

No IANA action.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>          Relevant content can frequently be found in the abstract
>          and/or introduction of the document.  If not, this may be
>          an indication that there are deficiencies in the abstract
>          or introduction.

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

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

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

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

    Section 2 describes a few typical use cases for home automation
    applications. Section 3 discusses the routing requirements for
    networks comprising such constrained devices in a home network
    environment. These requirements may be overlapping requirements
    derived from other application-specific routing requirements. A
    full list of requirements documents may be found in the end of the
    document.
>        Working Group Summary
>          Was there anything in WG process that is worth noting?  For
>          example, was there controversy about particular points or
>          were there decisions where the consensus was particularly
>          rough?

No controversy.

>        Document Quality
>          Are there existing implementations of the protocol?  Have a
>          significant number of vendors indicated their plan to
>          implement the specification?  Are there any reviewers that
>          merit special mention as having done a thorough review,
>          e.g., one that resulted in important changes or a
>          conclusion that the document had no substantive issues?  If
>          there was a MIB Doctor, Media Type or other expert review,
>          what was its course (briefly)?  In the case of a Media Type
>          review, on what date was the request posted?

The I-D is informational and specifies routing requirements.