Subject: [Roll] Detailed Review of draft-martocci-roll-building-routing-reqs

From: JP Vasseur <[email-masked]>
Date: Thu, 11 Sep 2008 12:19:51 +0200

Hi Jerry,

Again thanks for the great work and time you spend spelling out the building
automation requirements for ROLL.

The document provide an outstanding level of details, very helpful to
understand the context.

The main comment is that requirements have to be exclusively related to the
routing aspects and there are still quite a few non routing related
requirements (see below, comments on section 4). Some of them also needs to
be more accurately specified for the protocol designer.

Detailed comments below (comments are not by border of importance but in
chronological order)

1) Abstract

* S/²The ROLL Working Group was recently chartered by the IETF to define
   routing characteristics for low power embedded devices.  ROLL would
   like to serve the Industrial, Commercial (Building), Home and Urban
   markets.²/²The Routing Over Low power and Lossy network (ROLL) Working
Group has been chartered to work on routing solution for Low Power and Lossy
networks (LLN) in various markets: Industrial, Commercial (Building), Home
and Urban².

* S/²Pursuant to this effort, this document defines the
   functional requirements for installing integrated facility management
   systems in commercial facilities.  ³/²Pursuant to this effort, this
document defines the
   routing requirement for building automation.  ³

2) Terminology: I¹ll post a terminology ID soon, you may want to refer to it
in this document.

3) Introduction
* Although listed in the terminology section, thanks to expand acronyms when
first used (e.g. HVAC, K-12,
* (NOTE:... => paranthesis missing at the end of the sentence.

4) Section 2.2

* EIA 485: could you please expand and add a informative reference ?
* s/²mbps²/Mbits/s²
* s/²kbps²/Kbits/s²
* I would suggest to remove ³To date, camera systems have been deployed on a
proprietary wired high speed network or on enterprise VLAN. ³ or try to
soften this statement. We see more and more IP video cameras installed in
buildings.

5) Section 3
* This use case is certainly interesting and useful but as written the
introduction looks like a commercial brochure ;-) Could  you make it a bit
more anonymous ? 
* Section 3.3. Are you referring to the need for assets tracking (e.g. RFID)
* Section 3.4, 3.5, 3.6 and 3.7: The text is pretty straightforward. Thus I
would suggest to (at least) shorten the paragraph and spell out a bit more
clearly the network implication in section 3.4

6) Section 4
* s/Œrouting¹ /routing
* Section 4.1: this has been explained in the previous section
* ³It MUST be possible to fully commission devices without requiring any
additional commissioning device (e.g. laptop). The device MAY be
completely configured for network operation by setting a bank of
switches. The number of switches MUST not exceed 16 switches.
³
JP> The first requirement is a 0-configuration routing requirement (you may
want to say it this way) and has been spelled out in other routing
requirements IDs. The two last comments are implementation specific
(hardware requirements in this case), thus outside of the scope of IETF
requirement IDs.
* ³The device network address MUST be settable and henceforth fixed for
   the device without the need for other system devices such as DHCP
   servers. ³
JP> This is a requirement on the address configuration ...
* ³ Network setup MUST support device commissioning times of no more than
   15 minutes per sensor/controller pair.²
JP> Could you slightly reword this sentence referring to the time to
discover a new path ?
* Thanks to move section 4.1.4 to the introduction. No routing requirement.
* I would suggest to remove section 4.1.5
* Section 4.2.1
³A network MUST operationally support at least 1000 routing and 1000
   non-routing devices.
³
JP> Can you rephrase ? For example: ³The routing protocol MUST be able to
support networks with at least 1000 routers and 1000 hosts²
* ³Subnetworks (e.g. rooms, primary equipment) within the network must
   support upwards to 255 sensors and/or actuators.

   Subnetworks MUST seamlessly merge into networks.  Networks MUST
   seamlessly merge into internetworks. ³
JP> Not a routing requirement
* ³A source device may be upwards to 1000 feet from its destination.
   Communication MUST be established between these devices without
   needing to install other intermediate 'communication only' devices
   such as repeaters. ³
JP> You are referring to the PHY/MAC protocols, not a routing function.
* ³For wireless implementations, the routing algorithms SHOULD
   incorporate automatic transmit power regulation to maximize packet
   transfer and minimize network interference regardless of network size
   or density.²
JP> Please do not use ³algorithm² since we do not specify algorithm at the
IETF ;-) More importantly, this (important) requirement is for the PHY
layer, not the routing protocol unless you intend to derive from this
characteristic a routing requirement (dynamic metric such as the bandwidth
?).
* ³Network devices MUST be able to communicate in a peer-to-peer manner
   with all other devices on the network without being subject to
   intermediate bridge or gating devices. ³
JP> An important requirement. If I may, I would suggest the following
wording: ³Network devices must be able to communicate in a peer-to-peer
manner with all other devices on the network. Thus the routing protocol MUST
provide routes to any other devices without being subject to a constrained
path via a gating device.³
* ³Mobile devices SHOULD be capable of unjoining from an old network
   joining onto a new network within 15 seconds. ³
JP> Could you refer to route discovery time instead (just a question of
terminology)
* ³The total installed infrastructure cost including but not limited to
   the media, required infrastructure devices (amortized across the
   number of devices); labor to install and commission the network MUST
   not exceed $1.00/foot for wired implementations.  ³
JP> Definitely not a protocol issue (pricing). Thanks to delete.
* ³The software stack requirements for sensors and actuators MUST be
   implementable in 8-bit devices with no more than 128kb of flash
   memory (including at least 32Kb for the application code) and no more
   than 8Kb of RAM (including at least 1Kb RAM available for
   application). ³
JP> What if we have a very efficient protocol optimized for small footprint
and I am a really bad coder ? This is a typically difficult requirement to
express. What I would suggest is to use a non normative language here and
replace the MUST and a Œmust¹. The same comment applies to section 4.4.3
* ³The routing algorithms must support in-bound packet caches for sensor
   and actuator devices when these devices are not accessible on the
   network.  The cached packets need to be delivered to its destination
   when the device is accessible on the network.
³
JP> Interesting requirement but needs to be fleshed out. Could you elaborate
a bit more ? Are you referring to store-and-forward techniques since this
has other implications than just routing
* ³ROLL routing MUST support adjustable router table entry sizes on a
   per node basis to maximize limited RAM in the devices. ³
This one falls into the category of ³implementation specific issues² outside
of the scope
* ³Routers MUST support quality of service prioritization to assure
   timely response for critical FMS packets (e.g. Fire and Security
   events). ³
Qos is undoubtedly an important function but as such refers to the
forwarding plane and ability to prioritize packet treatment using various
scheduling techniques (WFQ, MDR, .... W/ or without dynamic priority,
feed-back, etc) and congestion avoidane ((W)RED, ...). Now we also call QoS
routing the ability to compute different paths for different flows. For
example compute the shortest (constrained) path with respect to metric X, Y
and Z where X can be the bandwidth metric, Y the delay metrics and so on.
Are you referring to QoS routing here ?
* ³Sensor/Actuator/Controller addressability MUST be unique site-wide.
   All addressable nodes MUST be accessible to all other nodes in the
   internetwork. 
³
JP> This is given :-) You can remove this paragraph.
* s/ plug-n-play/²plug-and-play²
* ³No bound information
   from other nodes MUST need be reconfigured.  ³
JP> This comes back to the 0-configuration requirement. Thanks to aggregate
all requirements related to 0-config in one place.
* ³ To support high speed code downloads, a mechanism MUST be defined to
   download firmware to devices in parallel yet support guaranteed
   delivery. Devices receiving a high speed download MAY cease normal
   operation, but upon completion of the download MUST automatically
   resume normal operation. ³
JP> If by mechanism you refer to a default routes to reach a management
device then you may want to say it (be routing specific). The last sentence
is implementation specific, this out of the scope of this document.
* Section 4.7.3
³4.7.3. Diagnostics

   To improve diagnostics, the network layer SHOULD be able to be placed
   in and out of 'verbose' mode.  Verbose mode is a temporary debugging
   mode that provides additional communication information including at
   least total number of packets sent, packets received, number of
   failed communication attempts, neighbor table and routing table
   entries.²
JP> Very interesting, I¹ll send a separate email to the list about this
topic.
* ³4.7.4. Trace Route

   Network diagnostics such as PING and Trace Route SHOULD be supported
   with extensions in Trace Route describing wireless parameter
   information when applicable. ³
JP> Traceroute uses ICMP, not routing ...
* ³4.8. Compatibility

   The building automation industry adheres to application layer
   protocol standards to achieve vendor interoperability.  These
   standards are BACnet and LON.  It is estimated that fully 80% of the
   customer bid requests received world-wide will require compliance to
   one or both of these standards.  The ROLL routing algorithms will
   therefore need to dovetail to these application protocols to assure
   acceptance in the building automation industry.  These protocols have
   been in place for over 10 years.  Many sites will require backwards
   compatibility with the existing legacy devices. ³
JP> Well ... I do agree that both Bacnet and Lonwork are important legacy
protocols. That being said, we cannot design a solution that will be
compatible with these protocols, the IETF is responsible for IP
specification. As you know, we can expect Bacnet to take advantage of the
protocols defined here thanks to its Bacnet over IP version although IP is
used by Bacnet as a layer 2 with Bacnet routing on top of it but this is
another debate. 
* ³4.8.1. IPv4 Compatibility

   The routing protocol MUST define a communication scheme to assure
   compatibility of IPv4 and IPv6 devices. ³
JP> Do you see other requirements than 6to4 ?
* ³4.8.2. Maximum Packet Size

   Routing algorithms must support packet sizes to 1526 octets. ³
JP> Two questions here:
Q1: Why ?
Q2: is it a ³must² or ³MUST²?
* ³Route adaptation also reduces latency if the new route costs consider hop
count as a 
   cost attribute. ³
JP> Not sure that I completely agree with that statement, could you
elaborate ?
* ³4.9.1. Path Cost

   Path selection MUST be based on path quality, rather than signal
   strength only.  Path quality includes signal strength, available
   bandwidth, hop count and communication error rates. ³
JP> This is an important requirement. I would suggest to phrase it a bit
differently by saying that the routing protocol MUST support a range of
metrics and optimize (constrained) path according to these metrics. If I
may, could you have a look at the following document
http://www.ietf.org/internet-drafts/draft-mjkim-roll-routing-metrics-00.txt
and provide comments/suggestions ? Thanks.
* ³4.9.2. Path Adaptation

   Communication paths MUST adapt toward signal quality optimality in
   time. ³
This actually translate to the ability to support dynamic metrics. Look at
the ID referred above.
* ³4.9.3. Route Redundancy

   To reduce real-time latency, the network layer SHOULD be configurable
   to allow secondary and tertiary paths to be established and used upon
   failure of the primary path ³
JP> Let me make sure that I get this requirement right: are you referring to
the ability for the routing protocol to dynamically recompute path upon
failure or the support of that is usually refers to as path protection
whereby diverse paths are pre-calculated. It is an important aspect to
clarify since diverse path computation is certainly not a trivial issue.
* ³4.9.4. Route Preference

   The route discovery mechanism SHOULD allow a source node (sensor) to
   dictate a configured destination node (controller) as a preferred
   routing path. 
³
JP> Not sure to understand what you mean by ³dictate a configured
destination node as a preferred path ?²
* ³The default MUST be asymmetric routes. ³
JP> Do you mean that the routing engine must compute asymmetrical paths
(paths to the destination with different cost) and these routes must
systematically be used ?
* ³4.9.6. Path Persistence

   Devices SHOULD optionally persist communication paths across boots
³
JP> This is an local node issue.
* ³4.10.1. Device Integrity

   Commercial Building devices MUST all be periodically scanned to
   assure that the device is viable and can communicate data and alarm
   information as needed. ³
JP> Isn¹t it a system architecture issue as opposed to a routing issue ?

7) Traffic Pattern
* Interesting. Does that mean that by contrast with many other sensoring
systems, the traffic is very much localized and aggregated whereby traffic
between controller tends to generate heavy loads ?
* Would you have any information about typical packet size distribution ?

8) Security 
JP> You may want to say a few words on the security routing issues ?

9) References
IETF: just add 
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

and draft-vasseur-roll-terminology
External: please add reference to Bacnet, Lonwork, ...

Thanks.

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