Subject: [Roll] Review of draft-ietf-roll-home-routing-reqs-02

From: JP Vasseur <[email-masked]>
Date: Thu, 21 Aug 2008 23:33:15 +0200

Dear WG,

As discussed in Dublin, the plan is to try to Last Call all the
application-specific routing requirements document before end of September.
Thus, please provide your detailed comments as soon as possible.

Here is my co-chair review on the Home Automation Routing Requirements.

Comments are not by order of importance by in chronological order.

First comments: as discussed in Dublin, could you please try to quickly
address the routing security issues.

Abstract
#######

* S/ ROuting in Low power and Lossy networks (ROLL)/ Routing Over Low power
and Lossy networks (ROLL) // Also in the terminology section //
* ³Examples include lighting control,
   heating control, sensors, leak detectors, healthcare systems and
   advanced remote controls.²
JP> Don¹t you want to classify with sensor (water leak, motion, healthcare
systems...), actuators (lighting, ....)
* Thanks to substitute the term ³multi-hop routing² by ³routing² (explain
that in a typical home all the nodes are not in direct range). It appears in
several sections.
* I think that the terminology section requires some work but I¹ll send a
separate email thread on the ROLL WG mailing list. For the time being, I
would suggest to remove the ROLL Node, ROLL network, ... terminology. You
may just want to a node where a node may be a sensor, actuator, ... Unless
you need to refer to a particular function of the node.

Please re-order sections so that Introduction becomes Section 1.

Introduction Section
#################

* s/ gas/water leak detectors/ gas/water leak sensor => JP> Good to use the
term sensor not to introduce new term (detector)
* ³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. ³
JP> You may want to explain that wall switched are then actuators. We could
also have embedded power sensor in plug-in modules but I guess that you
refer to actuators here.
* ³These requirements may be overlapping requirements
   derived from other application-specific requirements. ³
JP> Good place to reference the other IDs:
http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.txt
, 
http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.tx
t and 
http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-r
eqs-00.txt. + Update the reference section

Section 3
########

* ³Home automation applications represent a special segment of networked
   wireless devices with its unique set of requirements.²
JP> You may want to say that home networks may also comprise wired link
(e.g.PLC)
* ³For instance a lamp may be turned on, not only be a
   wall switch but also from a movement sensor. ³
JP> Don¹t you want to move this to Section 3.1 and try to slightly
generalize the Section 3.1 to ³lighting application².
* ³Geographical areas using central heating may turn off heating when
   not at home and use 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. 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 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. ³
JP> Great example. When you refer to this kind of application you may want
to use the term DR (demand-response) and SDM (Demand Side management) also
listed in the Urban routing requirement ID.
* ³Wireless remote control of the household appliances is well-suited
   for this application. ³ and ³ Moreover, in order to achieve
   effective electricity savings, the energy monitoring application
   running on the Wireless Sensor Network (WSN)²
JP> Well it is not just wireless but also wired (PLC). You may want to say
³Remote control ...².
* Section 3.4: This is an important section. Two comments:
    - This is not just for lighting devices (referring to the title)
    - Distribution of unique address may not always be performed by a
central contoller
* ³A 
   home automation controller sending commands to window shades via ROLL
   devices will have no problems delivering the packet to the router,
   but the router may have to wait for some time before the command can
   be delivered to the window shades if the receiver is sleeping;²
JP> You may want to clarify the paragraph above. I guess that in your
example: the router is the node immediately upstream to the destination, and
the window shades destination=receiver (actuator)? => means buffering on
routers. No need to ellaborate more though, since this is not related to
routing requirements. The 250ms refer to the wake-up time ?
* s/²which can be 
   triggered by the end-user that has received an alarm from a movement
   sensor or smoke detector - or the user simply wants to check the home
   status via video. ³/²which can be
   triggered by the end-user that has received an alarm from sensor
(movement 
   or smoke detector) or the user that simply wants to check the home
   status via video. ³
* PDA: please expand acronym when first used.
* s/³From a ROLL perspective, all the above-mentioned applications may run
   on battery.²/²Because all of the above-mentioned applications may run on
battery, this leads to specific requirements for the routing protocol.²
* ³A home security alarm system is comprised of various devices like
   vibration detectors, fire or carbon monoxide detection system, door
   or window contacts, glass-break detector, presence sensor, panic
   button, home security key.²
JP> Sorry to be ³picky² with the terminology but could you classify as
sensors, actuators, ... ? Thanks.
* ³When a node (or a group of nodes) identifies a risk situation (e.g.
   intrusion, smoke, fire), it sends an alarm message to the control
   centre that could autonomously forward it via Internet or interact
   with the WSN (e.g. trying to obtain more detailed information or
   asking to other nodes close to the alarm event).²
JP> Define the ³control centre² as a local device.
* s/³RAM memory²/RAM and expand the term RAM

Section 4
#########
* s/²Home automation applications have a number of specific requirements
   related to the set of home networking applications and the perceived
   operation of the system.²/²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.²
* ³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. ³
JP> These are not routing requirements. If you require the support of
³groupcast routing² (e.g. Minimization of packet duplication) then it is
indeed a routing requirement, in which case there are other implications on
addressing. Is it what is being required here ? Clearly the second statement
related to acknowledgment delivery is NOT a routing requirement.
* Ah indeed I now read ³The support of unicast, groupcast and broadcast also
has an 
   implication on the addressing scheme and are outside the scope of
   this document that focuses on the routing requirements aspects. ³ So do
you want to clarify the routing specific requirement for Groupcast ?
* Same issue here ³It MUST be to possible to address a group of receivers
known by the 
   sender even if the receivers do not know that they have been grouped
   by the sender.²
* ³The routing protocol should either share the load between
   nodes to preserve battery or only route via mains-powered nodes if
   possible.²
JP> Is it a ³should² or a ³SHOULD². If a ³SHOULD² this translates to the
support of load balancing (symmetrical or asymetrical), thus the computation
of multiple paths to the destination (of equal or unequal cost).
* ³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. ³
JP> And ??
* ³The routing protocol MUST support the recognition of neighbors and
   periodical scanning.²
JP> By periodical scanning you mean ³Keep alive² ? Then you may want to
indicate some frequency since it may contradict with your next statement:
³This process SHOULD preserve energy capacity as much as possible².
* ³Thus, the routing protocol MUST support 250 devices in a subnet.
   The routing protocol SHOULD support 2500 devices in a subnet. ³
JP> Why in a subnet? You mean in the ³network²
* Section 4.7
    - I would suggest not to use the PAN terminology
    - s/²From ROLL perspective,²/²From a routing perspective²
* ³The routing protocol MUST support the ability to isolate a
   misbehaving node thus preserving the correct operation of overall
   network. ³
This is a fairly important requirement, although it may end up being an
implementation issue, which will be determined once we will get to the
routing solution. But this requirement is not about manageability but
network stability. Could you make it a dedicated section ?

Section 5
#########
* Just to avoid ambiguity, please clarify the term ³any-to-one² (which may
interpreted as Multipoint-to-point)

Section 7
#########
I would have similar comments on this section as for the Urban routing
requirement documents. You may want to focus on routing security issues and
work with the security expert that will be appointed.

Other comments: 
- Please capitalize each first letter of each word in titles (3.7.3.
Healthcare routing considerations  => 3.7.3. Healthcare Routing
Considerations )
- Add the other application specific routing requirements documents as
informative references

Thanks.

JP.

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