Subject: Re: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs

From: JP Vasseur <[email-masked]>
Date: Thu, 11 Sep 2008 13:05:13 +0200

Hi Christopher,

On 9/10/08 5:35 PM, "Dearlove, Christopher (UK)"
<[email-masked]> wrote:

> 
>>  15) Section 2.2.2: "Since publishing the data is the raison d'etre
> for most of the
>>   sensors, it makes sense to build proactively a set of default routes
>>   between the sensors and one or more backbone router and maintain
>>   those routes at all times.  Also, because of the lossy nature of the
>>   network, the routing in place should attempt to propose multiple
>>   forwarding solutions, building forwarding topologies in the form of
>>   Directed Acyclic Graphs oriented towards the sinks."
> 
> That contradicts the routing protocols comparison draft which demands no
> signalling traffic with no data traffic.

This requirement has been discussed during the WG meeting and should indeed
be reworked, I agree with you.

Any proactive route maintenance
> needs some signalling. (Note however that it doesn't however necessarily
> require a fixed period beacon, various forms of backoff - supported by
> OLSRv2 incidentally - can be used, depending on mobility/dynamism and
> also how it can be recognised. In some cases the overhead can be made
> very small - possibly even comparing favourably with traffic-dependent
> signalling for actual traffic levels, although not meeting the absolute
> specification of zero for zero.)
> 
> I think this is actually a issue for both documents, in particular
> for the routing comparison document which is rather absolutist in its
> limited set of requirements for existing routing protocols to pass.
> I think there is the distinct possibility that you will exclude all
> existing protocols on these strict grounds, then later determine that
> what you actually design ends up violating your strict conditions in
> order to support requirements such as that quoted above. That would
> raise the question as to whether the process had been right.
> 
> I think this argues in favour of looking more closely at the existing
> protocols not just what they do with default settings, but what they
> can do if pushed hard (for example the previously mentioned fisheye
> support in OLSRv2 and the possibilities for backed-off beacon messages
> noted above) and what is fundamental, and what is not, i.e. can we
> extend rather than replace?
> 
> Note that I'm not quoting OLSRv2 because I think it's the protocol
> ROLL definitely wants, but because I'm familiar with it (I'm an author)
> and thus have examples at my fingertips. In particular I know we've
> put stuff in whose usage may not be obvious, and we haven't put stuff
> in because it would be a step too far (for current requirements in the
> MANET WG). I'm sure other protocols have similar possibilities. The
> choice between use as-is and develop new is easy (develop new, no one
> in the IETF has already done exactly what you want, because their
> requirements were different). The choice between develop new and develop
> modification/extension/new mode/whatever of an existing protocol is
> harder.

I *fully* agree with your comment.
The answer to the first choice is pretty straightforward. And we will of
course look at the second choice: if we can find an existing protocol that
can meet ROLL's requirements with reasonable adaptations this would be a
very good outcome. We should avoid developing protocols if existing protocol
can be reused. Now we all known that protocols can always be adapted and
will satisfy requirements to a *certain* extent. That will be the hard part.
Now we also need to bear in mind that the protocol needs to satisfy the
requirements *without* to imposing drastic overloaded of unneeded functions
for constrained devices.

Thanks.

JP.

> 
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
> 

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

---

From: JP Vasseur <[email-masked]>
Date: Mon, 15 Sep 2008 09:09:29 +0200

Hi Tom,

On 9/10/08 5:56 PM, "Tom Phinney" <[email-masked]> wrote:

> Re item 8) below, closing loops in the field
>   i) does not prevent the same loop from being closed through a remote
> multi-variable controller during some modes of operation, while being closed
> directly in the field during other modes of operation (e.g., fallback, or when
> timing is more critical)
>   ii) does not imply that the loop will be closed with a wired connection, or
> that the wired connection is more energy efficient even when it exists as an
> alternate to the wireless connection.
> 
> A realistic future scenario is for a field device with a battery or
> ultra-capacitor power storage to have both wireless and unpowered wired
> communications capability (e.g., galvanically isolated RS-485), where the
> wireless communication is more flexible and, for local loop operation, more
> energy efficient, and the wired communication capability serves as a backup
> interconnect among the loop elements, but without a wired connection back to
> the operations center blockhouse.  In other words, the loop elements are
> interconnected through wiring to a nearby junction box, but the 2 km home-run
> link from the junction box to the control center does not exist.
> 
> When wireless communication conditions are good, devices use wireless for loop
> interconnect, and either one wireless device reports alarms and other status
> to the control center for all elements of the loop or each element reports
> independently.  When wireless communications are sporadic, the loop
> interconnect uses the self-powered galvanically-isolated RS-485 link and one
> of the devices with good wireless communications to the control center serves
> as a router for those devices which are unable to contact the control center
> directly.
> 
> The above approach is particularly attractive for large storage tanks in tank
> farms, where devices may not all have good wireless visibility of the control
> center, and where a home run cable from the tank to the control center is
> undesirable due to the electro-potential differences between the tank location
> and the distant control center that arise during lightning storms..
> 
> JP> Really interesting scenario. Feel free to add it to the document, it is
> definitely worth it.
> 
> Cheers,
> 
> JP.
> 
> -Tom
> =============
> JP Vasseur wrote:
>>  Detailed Review of draft-ietf-roll-indus-routing-reqs Hi,
>>  
>> After the review of draft-ietf-roll-urban-routing-reqs and
>> draft-ietf-roll-home-routing-reqs (new revision coming soon according to
>> their authors), here is my review of draft-ietf-roll-indus-routing-reqs (lots
>> of excellent content).
>>  
>> 1) Abstract and Section 2
>>       For wireless devices to have a significant
>>    advantage over wired devices in an industrial environment the
>>    wireless network needs to have three qualities: low power, high
>>    reliability, and easy installation and maintenance.
>>  
>> JP> I would propose not to ³oppose² wireless and wired devices. Indeed,
>> sensor networks will more than likely be interconnected by a variety of
>> links. Still those networks will be LLN and will require these three
>> qualities. I would then suggest to keep the list of qualities but generalize
>> it to devices in LLN.
>>  
>>  
>> 2) s/L2N/LLN in the entire document (to match the ROLL charter).
>> I still owe the WG a terminology ID (will be done early next week).
>>  
>> 3) I skip the terminology section since it will addressed in the terminology
>> ID. 
>>  
>> 4) Introduction
>>  
>> Referring to:
>> ³Wireless field devices enable expansion of networked points by
>>    appreciably reducing cost of installing a device.  The cost
>>    reductions come from eliminating cabling costs and simplified
>>    planning.  Cabling also carries an overhead cost associated with
>>    planning the installation, determining where the cable has to run,
>>    and interfacing with the various organizations required to coordinate
>>    its deployment.  Doing away with the network and power cables reduces
>>    the planning and administrative overhead of installing a device.²
>>  
>> JP> This is a bit arguable ... (look at PLC) and not really a technical
>> consideration. I would suggest to simply remove this paragraph.
>>  
>> 5) Section 2
>>  
>> * ³wired HART² please add a informative reference.
>>  
>>  6) s/²In the near future, most low power and lossy network systems will be
>>    for low frequency data collection.²/²In the near future, most low power
>> and lossy network systems in industrial automation environments will be
>>    for low frequency data collection.²
>>  
>> 7) In several places, you make the assumption that the collected data is sent
>> to a Sink/... Residing outside of the LLN. Don¹t you see cases where there
>> will be intra-LLN flows in Industrial automation ?
>> And I just read: ³  In the future, it is envisioned that some open loop
>> processes will be
>>    automated (closed loop) and packets will flow over local loops and
>>    not involve the L2N access point. ³ - Thanks.
>>  
>> 8) you wrote: ³More likely though is that loops will be closed in the field
>>    entirely, which in most cases eliminates the need for having wireless
>>    links within the control loop.²
>> Why does this eliminate the need for wireless links ?
>>  
>> 9) ³L2N-ish² ... You may want to slighlty reword here ;-)
>>  
>> 10) s/²maximum number of hops from two to twenty.²/²maximum number of hops of
>> twenty²
>>  
>> 11) Section 2.2
>>  
>> You wrote: ³ The backbone is a high-speed infrastructure network that may
>>    interconnect multiple WSNs through backbone routers.  Infrastructure
>>    devices can be connected to the backbone.  A gateway / manager that
>>    interconnects the backbone to the plant network of the corporate
>>    network can be viewed as collapsing the backbone and the
>>    infrastructure devices into a single device that operates all the
>>    required logical roles.  The backbone is likely to become an
>>    important function of the industrial network.²
>>  
>> Although I do agree that this is a common architecture, you may want to
>> indicate that this is only one possible architecture.
>>  
>> 12) Could you please use a coherent terminology throughout the document ? L2N
>> sensor, field devices, ... I¹ll try to write the terminology ID this week,
>> then thanks to align the terminology.
>>  
>> 13) I found this section is bit out of the scope:
>>  
>> ³This multiple domain multiple applications connectivity creates a
>>    significant challenge.  Many different applications will all share
>>    the same medium, the ether, within the fence, preferably sharing the
>>    same frequency bands, and preferably sharing the same protocols,
>>    preferably synchronized to optimize co-existence challenges, yet
>>    logically segregated to avoid creation of intolerable short cuts
>>    between existing wired domains.
>>  
>>    Given this challenge, L2N networks are best to be treated as all
>>    sitting on yet another segregated domain, segregated from all other
>>    wired domains where conventional security is organized by perimeter.
>>    Moving away from the traditional perimeter security mindset means
>>    moving towards stronger end-device identity authentication, so that
>>    L2N access points can split the various wireless data streams and
>>    interconnect back to the appropriate domain pending identity and
>>    trust established by the gateways in the authenticity of message
>>    originators.²
>>  
>> 14) Question about Figure 1: it looks like we still do have to compute routes
>> within the LLN ?
>> Furthermore, thanks to mention that this is one of many potential
>> architectures. For example, in section 2.2.2 you wrote ³2.2.2.  Logical
>> Topologies
>>  
>>    Most of the traffic over the LLN is publish/subscribe of sensor data
>>    from the field device towards the backbone router or gateway that
>>    acts as the sink for the WSN.²
>>  
>> You may want to replace the backbone router/gateway by a sink to make the
>> statement more general and applicable to other topologies (without a gateway,
>> ...). The use of gateway is a bit dangerous here unless carefully defined but
>> we¹ll discuss terminology in a separate email.
>>  
>> 15) Section 2.2.2: ³Since publishing the data is the raison d'etre for most
>> of the
>>    Directed Acyclic Graphs oriented towards the sinks.²
>>  
>> Is it a requirement to be able to configure ³default routes?²
>> By ³multiple forwarding solutions² do you actually means ³multiple paths² ?
>>  
>> 16) Comment on ³For these reasons, the ROLL routing infrastructure MUST be
>> able to
>>    compute and update constrained routes on demand (that is reactively),
>>    and it can be expected that this model will become more prevalent for
>>    field device to field device connectivity as well as for some field
>>    device to Infrastructure devices over time.²
>>  
>>   
>> * you may want to move the MUST in the routing requirement sections, to have
>> them all in one place.
>> * Are you requiring a reactive mechanism
>> *  
>>  
>> 17) Section 3.
>> * ³Service Requirement² - You may want to change the title for ³Traffic
>> Characteristics² just to avoid confusion with upper layer requirements.
>> excellent paragraph
>>  * I¹m not sure to see the rationale of the various bullets ³data bandwidth²,
>> ³Latency², ... In this context of routing requirements.
>> * You wrote ³The routing protocol
>>    MUST be able to set up unidirectional or asymmetrical cost routes
>>    that are composed of one or more non congruent paths.²
>> You may want to reword this sentence, which may be misleading (in particular,
>> there is no ³or² routes can be unidirectional and asymmetrical²). Did you
>> mean ³The routing protocol MUST be able to compute a set of unidirectional
>> routes with potentially different costs².
>>  
>> 18) Section 3.1
>>  
>> * S/ Time-varying user requirements for latency and bandwidth will require
>>    changes in the provisioning of the underlying L2 protocols/ Time-varying
>> user requirements for latency and bandwidth may require
>>    changes in the provisioning of the underlying L2 protocols.
>>  
>> *  ³The routing protocol MUST route on paths that are changed to
>>    appropriately provision the application requirements.²  
>>  
>> JP> This should translate into ³The routing protocol MUST dynamically
>> recompute path if the underlying topology changes.
>>  
>>    ³The routing
>>    protocol MUST support the ability to recompute paths based on
>>    underlying link characteristics that may change dynamically.²
>>  
>> JP> Could you be more accurate ? ³What if the BER crosses some threshold?².
>> Should it trigger a path computation ? If so, you would need to list all
>> parameters that can trigger a path computation. Alternatively, (IMO the
>> prefered option) each of the link characteristic should be reflected in a
>> metric or attribute change that will trigger a path computation (use filters
>> of course). 
>>  
>> 19) Section 3.2.
>> S/²The routing algorithm MUST be able to
>>    generate different routes for different flows.²/²The routing algorithm
>> MUST be able to
>>    generate different routes with different characteritics (e.g. Optimized
>> according to different cost, ...).²
>>  
>> 20) Replace globally ³low power lossy network² by ³LLN².
>>  
>> 21) Replace globally ³#² by ³number².
>>  
>> 22) s/² 3)  Probability of failure on demand,²/² 3)  Probability of failure
>> to compute an on demand route²
>>  
>> 23) In the list of ³Reliability Requirements² you may want to add a ³...²
>> since there are many other ones (ability to reroute upon a network failure,
>> ...).
>>  
>> 24) ³Hop-by-hop path diversity is used to improve latency-bounded
>>    reliability.²
>>  
>> JP> Path diversity does not help with latency-bounded reliability ... It does
>> help to increase packet delivery if you use a 1+1 technique, or to find an
>> alternate path or limit the proportion of flows impacted by a single failure
>> but not for latency. What did you mean ?
>>  
>> 25) ³The routing protocol MUST support multiple L2N access
>>    points and load distribution among L2N access points.  
>> JP> In order to make this requirement not ³topology dependent² could you
>> reword it ³The routing protocol MUST be able to compute paths towards
>> different destination so as to perform load balancing across a variety of
>> paths.²
>>  
>> 26) ³The routing
>>    protocol MUST support multiple L2N access points when L2N access
>>    point redundancy is required.²
>>  
>> This is not a routing protocol requirement.
>>  
>> 27) ³Because L2Ns are lossy in nature,
>>    multiple paths in a L2N route MUST be supported. ³ --> already stated.
>>  
>> 28) Section 6:
>>  
>> ³2)  Delivery of common packets to multiple routers over a backbone,
>>        where the packets results in each receiving router initiating
>>        multicast (sometimes as a full broadcast) within the LLN.  This
>>        is byproduct of having potentially physically separated backbone
>>        routers that can inject messages into different portions of the
>>        same larger LLN.²
>>  
>> JP> IMO a too solution-specific statement.
>>  
>> 29) Section 7
>> * ³The routing algorithm SHOULD always be in the process of
>>    optimizing the system in response to changing link statistics.²
>> JP> The term ³optimizing² is worth a few words of explanation. Optimizing
>> with regards to which objective ?
>>  
>> * ³The
>>    routing algorithm MUST re-optimize the paths when field devices
>>    change due to insertion, removal or failure, and this re-optimization
>>    MUST not cause latencies greater than the specified constraints
>>    (typically seconds to minutes).²
>> Few comments here: (1) The first ³MUST² is not different than the basic
>> requirement of being able to compute new path upon topology changes. (2) I
>> would propose to carefully use the term ³re-optimization². Indeed, I guess
>> that you refer to the event where a ³shorter² path is found according to some
>> metrics. Then you are requiring the ability to switch to a shorter path while
>> bounding the latency, which requires to only switch if the delta between the
>> old and new cost is also bounded and also implies other constraints. Indeed,
>> in distributed systems, you cannot guarantee that systems are fully
>> synchronized. Thus a router may start using a route that is not yet ready if
>> some of the next hops have not converged yet, which may lead to micro-loops.
>> Could you elaborate on this requirement ?
>>  
>> 30) 
>> * ³The routing protocol SHOULD support the wireless worker with fast
>>    network connection times of a few of seconds, and low command and
>>    response latencies to the plant behind the L2N access points, to
>>    applications, and to field devices.  ³
>>  
>> Is it a different requirement than the one expressed in Section 7:
>>  
>> ³The routing algorithm MUST find the appropriate
>>    route(s) and report success or failure within several minutes, and
>>    SHOULD report success or failure within tens of seconds.²
>>  
>>  
>> * ³The routing protocol SHOULD also
>>    support the bandwidth allocation for bulk transfers between the field
>>    device and the handheld device of the wireless worker.   ³
>>  
>> JP> of course, I see what you mean but this should either be removed or
>> reworded. This may simply refer to topology changes, for which you already
>> have a routing requirement or some cross-layer function (hope not).
>>  
>> ³The routing
>>    protocol SHOULD support walking speeds for maintaining network
>>    connectivity as the handheld device changes position in the wireless
>>    network.
>>  
>>    Some field devices will be mobile.  These devices may be located on
>>    moving parts such as rotating components or they may be located on
>>    vehicles such as cranes or fork lifts.  The routing protocol SHOULD
>>    support vehicular speeds of up to 35 kmph.
>> ³
>>  
>> JP> You may just want to say that such requirement has also consequences on
>> non-routing functions.
>>  
>> 31) Section 9
>>  
>> * ³Therefore,
>>    the routing protocol MUST support auto-provisioning of field devices.²
>>  
>> JP> To which extent ? Does that mean a true 0-configuration routing protocol
>> ?
>>  
>> *²The protocol also MUST support the distribution of configuration from
>>    a centralized management controller if operator-initiated
>>    configuration change is allowed.²
>>  
>> JP> Not a routing requirement. Or do you refer to the dynamic set up of a
>> ³default DAG/Tree² used to retrieve a more sophisticated ³routing feature²
>> from a centralized tool ?
>>  
>> 32) Section 10
>>  
>> * s/²1) attacks on the actual application served be the wireless
>>    devices and ³/²1) attacks on the actual application served by the wireless
>>    devices and ³
>>  
>> * ³2) attacks that exploit the presence of a wireless access
>>    point that MAY provide connectivity onto legacy wired plant networks,
>>    so attacks that have little to do with the wireless devices in the
>>    L2Ns. ³/²2) attacks that exploit the presence of a wireless access
>>    point that may provide connectivity onto legacy wired plant networks,
>>    so attacks that have little to do with the wireless devices in the
>>    LLNs. ³
>>  
>> * ³The routing protocol SHOULD place limited trust in the field devices
>>    deployed in the plant network.
>> ³
>>  
>> JP> Could you elaborate a little bit ? It sounds a bit too vague for a
>> protocol designer to figure out what action to take according to this
>> requirement. 
>>  
>> ³Standards exist that address those
>>    vulnerabilities.²
>>  
>> JP> ??
>>  
>> 33) replace ³isn¹t by is not², ³doesn¹t by does not² , ...
>>  
>> Thanks.
>>  
>> Cheers,
>>  
>> JP. 
>