Subject: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs

From: JP Vasseur <[email-masked]>
Date: Wed, 04 Jun 2008 17:13:45 +0200

Dear WG,

I made a detailed review of draft-ietf-roll-home-routing-reqs

Here are my comments (not of equil importance):

1) idnits
  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  
----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
     being 1 character in excess of 72.

2) Each acronym must be expanded the first time it is used (e.g. PANs in
section 2)
3) Remove reference to I-D.culler-roll-routing-reqs (ID has expired)
4) Section 3.1
³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.²
This might be a good place to define the term ³groupcast² more carefully.
5) Section 3.1
³ Thus, a solution is needed for addressing groups of nodes without prior
management of group membership in the receiving nodes. ³
Is it a ³must² or a MUST?
6) Section 3.2
³ The power grid may experience periods where more wind-generated power
   is produced than is needed. Typically this may happen during night
   hours. 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. ³
-> Add the example of power dynamic pricing that can be used to regulate the
operation of a set of devices in the home.
7) Section 3.2
" Most of these applications are mains powered and may thus provide
reliable routing resources."
I would suggest to reword the sentence. Indeed, a battery node may still
provide reliable routing but this is a constrained resource (battery
operated) that the routing decision may want to avoid if an alternate path
exist.
8) As written section 3.4 is about auto-conf rather than routing (requires
for auto-conf)? Would you want to slightly elaborate there?
9) section 3.5: " ROLL resources" ? Why would the router have to wait for
some time ? Because you make the assumption of devices in deep sleep mode?
10) Section 3.6
S/ROLL devices/constrained devices or please define a "ROLL" device in the
terminology section
11) Could you elaborate on the routing requirements here: " A plethora of
applications could be developed for home alarm system: most of them, most of
the time, have prevention and monitoring activity in which routing
requirements are deterministic, but all of them have an alarm state in which
nodes may burst an aperiodic alarm. "
12) Section 3.9: I guess that you meant " leaving only a few 100 bytes of
RAM powered during the deep sleep phase."
13) Section 4.1:
" The routing protocol must provide the ability to route a packet towards a
single device (unicast), a set of devices (also referred to as "groupcast"
in this document) or all devices (broadcast) in the house.
- Don't you mean to use a MUST here ?
- Please insert a section prior to this requirements on the definition of
Groupcast.
14) You wrote: " Alternatively, a companion specification SHOULD define how
to indirectly address a group of nodes on the application layer via
classic broadcast in the network layer; e.g. by use of a bitmap in a
header extension. "
But you cannot have a SHOULD in this document on a document defined
somewhere else.
15) You wrote:
"[ABR NOTE: IETF-71 WG meeting indicated that the term "constrained"
has a very specific meaning in the routing community inside IETF.
What I understood was that the draft should be using the term
"metric-based routing"]"
I do not think so. The term "constrained based routing" used in this
document is appropriate if what you require is to have the ability the
compute the shortest path based on some metrics (there could be more than
one metrics) taking into account some link or node constraints. If this is
what you need, then you indeed refer to constrained based routing.
Based on what you wrote
" Simple battery-powered nodes such as movement sensors on garage doors
and rain meters 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 require long time before getting a
response."
You do refer to constrained based routing.
16) 
"The routing protocol MUST support metric-based routing taking into
account node properties (CPU, memory, level of energy, sleep intervals,
safety/convenience of changing battery). "
S/metric-based routing/constrained based routing.
The metric-based routing refers to the ability to use different metrics to
compute the shortest path, which is a different requirement ?
Is that needed for Home Automation ?
In your case you may either need:
1) Constrained based routing: e.g. Avoid a node whose battery level < X
2) Multi-metric based routing: assign different metrics for a specific link
(for example, one metric to reflect the bandwidth, one metric to reflect the
propagation delay, ...).
17) 
" 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 the rest of the network."
You may want to be more explicit on what this actually translate to for the
routing protocol.
18) Section 4.7. Please expand PAN when first used.
19) " home PAN MUST provide a set of features including 0 configuration of
the routing protocol for a new node to be added to the network. "
Do you really mean "0 configuration" ?? What about optional configuration of
timers ?
20) " Furthermore, a failing node MUST NOT have a global impact on the
routing protocol. "
This is a very strong requirement ... Are you sure that this is what you
mean? I feel more comfortable about your second
21) It would be nice if you could elaborate a little bit on the traffic
pattern for the various use cases since health monitoring and alarm
significantly differs on that aspect. Please provide some number of packet
sizes, frequency at which packets are sent out, ...
22) Could you flesh out the security requirements ?
23) Acknolegment: list of people (if any) that you want to thank for their
contribution/feed-backs/...
24) Remove [I-D.culler-roll-routing-reqs] as informative reference.

Thanks.

JP.

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Jakob Buron" <[email-masked]>
Date: Mon, 23 Jun 2008 10:30:54 +0200

Dear WG,

a new revision of the home automation I-D based on JPs comments will be posted soon. Please see my inline comments for an overview of the proposed changes by Anders and myself. Do let me know if you have any feedback at this point.

Kind regards,
Jakob

> -----Original Message-----
> From: JP Vasseur <[email-masked]>
> Date: Wed, 04 Jun 2008 17:13:45 +0200
> To: <[email-masked]>
> Subject: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs
> 
> Dear WG,
> 
Will fix.

> 2) Each acronym must be expanded the first time it is used (e.g. PANs 
> in section 2)
OK.

> 3) Remove reference to I-D.culler-roll-routing-reqs (ID has expired)
OK

>    acknowledged singlecast messages to each lighting device.² This 
> might be a good place to define the term ³groupcast² more carefully.
I'll add a definition of groupcast in Section 4.1.

> 5) Section 3.1
> ³ Thus, a solution is needed for addressing groups of nodes without 
> prior management of group membership in the receiving nodes. ³ Is it a 
> ³must² or a MUST?
I'll remove this sentence since requirements should not appear in use cases. 

>    while power is cheap. The electric car should also charge its 
> batteries on cheap power. ³
> -> Add the example of power dynamic pricing that can be used
> to regulate
> -> the
We already have the "start-device-when-power-is-cheap" case. I'll add "stop-device-when-power-is-expensive" case. This should be useful for air conditioning/climate control systems.

> I would suggest to reword the sentence. Indeed, a battery node may 
> still provide reliable routing but this is a constrained resource 
> (battery
> operated) that the routing decision may want to avoid if an alternate 
> path exist.
I will change to "Most of these applications 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."
Giorgio - do you agree on this wording? Can we link this to a health care example of reliable routing via battery-powered devices?

8) As written section 3.4 is about auto-conf rather than routing 
> (requires for auto-conf)? Would you want to slightly elaborate there?
Inserted at the end of sec. 3.4:
"Distribution of unique addresses is usually performed by a central controller. In this case, it must be possible  to route the inclusion request from the joining node to the central controller even before the joining node is  assigned a unique address."

> 9) section 3.5: " ROLL resources" ? Why would the router have to wait 
> for some time ? Because you make the assumption of devices in deep 
> sleep mode?
"ROLL resources" changed to "ROLL devices".
The router only has to wait if the receiver is sleeping. An acknowledgment-mechanism is needed to manage this, but that is beyond the scope if this I-D.
I'll clarify that the router has to wait _if_ the receiver is sleeping.

> 10) Section 3.6
> S/ROLL devices/constrained devices or please define a "ROLL" 
> device in the terminology section
I'll define a ROLL device as "A ROLL network node with constrained CPU and memory resources; potentially  constrained power resources."

> 11) Could you elaborate on the routing requirements here: " A plethora 
> of applications could be developed for home alarm
> system: most of them, most of the time, have prevention and monitoring 
> activity in which routing requirements are deterministic, but all of 
> them have an alarm state in which nodes may burst an aperiodic alarm. 
> "
I will highly appreciate contributions here, Giorgio, you probably have some thought on this. Do you want to add something?

> 12) Section 3.9: I guess that you meant " leaving only a few 100 bytes 
> of RAM powered during the deep sleep phase."
I'll add "of RAM".

> 13) Section 4.1:
> " The routing protocol must provide the ability to route a packet 
> towards a single device (unicast), a set of devices (also referred to 
> as "groupcast"
Will be changed to:
"Broadcast and groupcast in home automation MAY be used to deliver the illusion that all recipients respond  simultaneously. Distant recipients out of direct range may not react to the (unacknowledged) groupcast.  Acknowledged unicast delivery MUST be used subsequently."

> - Please insert a section prior to this requirements on the definition 
> of Groupcast.
I propose to add this section:
"Groupcast, in the context of home automation, is defined as the ability to simultaneously transmit a message to a group of recipients without prior interaction with the group members (i.e. group setup). A use-case for groupcast is given in Section 3.1. "

> 14) You wrote: " Alternatively, a companion specification SHOULD 
> define how to indirectly address a group of nodes on the application 
> layer via classic broadcast in the network layer; e.g. by use of a 
> bitmap in a header extension. "
OK - that sentence will be removed.

> compute the shortest path based on some metrics (there could be more 
> than one metrics) taking into account some link or node constraints. 
> If this is what you need, then you indeed refer to constrained based 
> routing.
> Based on what you wrote
> " Simple battery-powered nodes such as movement sensors on garage 
> doors and rain meters 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 
> account node properties (CPU, memory, level of energy, sleep 
> intervals, safety/convenience of changing battery). "
> The metric-based routing refers to the ability to use different 
> metrics to compute the shortest path, which is a different requirement 
> ?
> 2) Multi-metric based routing: assign different metrics for a specific 
> link (for example, one metric to reflect the bandwidth, one metric to 
> reflect the propagation delay, ...).
I agree with JPs taxonomy of routing types, and I believe that we need constraint-based routing. Multi-metric routing would be too complicated for a simple network.
If there are no objections on the ML, we'll revert back to the term "constraint-based routing" instead of "metric-based routing".

> able to deliver a packet, it is most likely that the sending node 
> moved; rather than the rest of the network."
> You may want to be more explicit on what this actually translate to 
> for the routing protocol.
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. The search strategy in the routing protocol will behave differently depending on this expectation.

> 18) Section 4.7. Please expand PAN when first used.
OK

> 19) " home PAN MUST provide a set of features including 0 
> configuration of the routing protocol for a new node to be added to 
> the network. "
> Do you really mean "0 configuration" ?? What about optional 
> configuration of timers ?
We mean zero configuration, as defined by Giorgio:
" From ROLL perspective, zero-configuration means only and above all, that a node can obtain an address and join the network on its own, without human intervention."
I propose to add this definition and keep the 0 configuration requirement.

> This is a very strong requirement ... Are you sure that this is what 
> you mean? I feel more comfortable about your second
Agreed. I propose to delete the first requirement and make the second a MUST:
"The routing protocol MUST support the ability to isolate a misbehaving node thus preserving the correct operation the overall network."
Giorgio has a very good comment on the unspecified impact of a central controller failing. This case is important for sure, but not all ROLL networks need to have a central controller, so I would propose to avoid discussing it here.

> 21) It would be nice if you could elaborate a little bit on the 
> traffic pattern for the various use cases since health monitoring and 
> alarm significantly differs on that aspect.
> Please provide some number of packet sizes, frequency at which packets 
> are sent out, ...
I'll add some numbers for the home appliance remote control and motion sensor cases. Perhaps Giorgio could add some data on a healthcare scenario?

> 22) Could you flesh out the security requirements ?
This is still not clear from our side either. I'll add some general guidelines, though.

> 23) Acknolegment: list of people (if any) that you want to 
> thank for their contribution/feed-backs/...
Good idea.

> 24) Remove [I-D.culler-roll-routing-reqs] as informative reference.
OK.

--
Jakob Buron
Software Engineer
Zensys A/S
Emdrupvej 26
DK-2100 Copenhagen O
Phone : +45 39130043
www.zen-sys.com