Re: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Michael:

[Pascal] Thanks for the comments : )

{this email was written in several sittings over 10 days. Probably I missed some stuff}

Section 1.3 says:
 1.3.  Out of scope requirements
   This applicability statement does not address requirements related to
   wireless LLNs employed in factory automation and related
   applications.

So, as I understand things, this document applies to *plants*, but not
automated factories.   Forgive me for my ignorance, but I guess this
means it applies to a oil refinery or chemical plant, but not to a car manufacturer. (Even though, we call them "auto plants")

I'm just trying to understand where the line is and why.

[Pascal] You are correct. The industry makes a difference between Factory Automation (discrete manufacturing of individual products) and Process Controls (continuous production). These are really 2 different activities, and Factory Automation may require much stricter behaviors for very rapid operations.
At ISA, WG 11 has standardized ISA100.11a for Process Control, and the information you find in the draft leverages that experience. WG16 has been working on Factory Automation.

====

>The domain of applicability for the RPL protocol may include all
>   phases but the Normal Operation phase, where the bandwidth allocation
>   and the routes are usually optimized by an external Path Computing
>   Engine (PCE), e.g. an ISA100.11a System Manager.

So, RPL could be used during phases P1, P2, P4, P5 and P6, but not during P3, (Normal Operation), unless a new OF was defined that interacted with the PCE?

[Pascal] Roughly yes, and this is the work we are starting at 6TSCH. In more details, there will be flows that can use distributed routing but critical flows will need the PCE.

(Last time I read the document, I was sure it said that LLNs could be used only during P3)

Given that, I guess the "X" in figure 1 means that RPL *can* be used?


section 2.1.2 then says:
   For factory automation networks, the basic communications cycle for
   control is typically much faster, on the order of 100 Hz or more.

but, I thought factory automation was out of scope?

[Pascal] Yes, still this is good info. 

=====

section 2.1.3:
I think that I'm confused about Source-Sink(SS) vs Peer-to-multipeer(P2MP) given that 2.1.3 says that the sink is usually a multicast address.
Is the distinction that in P2MP multiple packets are unicast?
Or is the distinction that P2MP is primary from outside the LLN, downward into the LLN, while SS is within the LLN?

[Pascal] let me quote Tom here:
"

There are three distinct paradigms used for the bulk of  industrial automation and control communication:

1) publish/subscribe, where an association exists between one source and one or a few recipients, all of which are identifiable, where publication is periodic within strict time limits (though sometimes instances are suppressed due to source compression of the stream). When pub/sub is used for closed-loop control, it is subject to timing attacks where deliberately induced message delivery jitter can destabilize a control loop. Sequentiality and non-loss are insufficient to detect this; it must be based on source time stamping , such as transport time-of-origination time stamping, that is checked at the receiver, or the equivalent, to discard anything that is not received within the proper cycle. In essence there is a fixed-acceptable-delay pipeline between the publisher and the subscriber, generally with a transit delay less than twice the publication period. COAP does not appear to be suitable for this communication paradigm without additional augmentation.

2) source/sink, where any of a number of sources logically multicasts (however that is implemented) to a predefined group address for the sinks, where the membership in that group is time-varying and unknown to the sources. Transport time-of-origination time stamps here are used for message authentication and perhaps in conjunction with source compression of related-interval time stamps in the application messaging. Arrival order and timing is of relatively little interest here, as is message loss detection (except for whatever impact that latter might have on security alerting). 

3) client/server or peer/peer, where all of the traditional properties hold and the specialized ones listed above generally do not.

"
My understanding is that this is more an upper layer paradigm then a routing issue. Pub/sub relates to periodic data that can be buffered to be read asynchronously, like the periodic publication of a measurement. Tom?


======


Or is it that the source is always on the LLN, and the sink is always elsewhere, and the fact that it's a multicast/anycast destination is just a question of how to implement redundancy in the data collection systems? 

[Pascal] Not just redundancy. You might have a copy for a local actuator and a copy for a supervisory system, a log...



page 13, section 2.1.4: says: 

   With rare
   exception, the control algorithms used with PS messaging in the
   process automation industries - those managing continuous material
   flows - rely on fixed-period sampling, computation and transfer of
   outputs, while those in the factory automation industries - those
   managing discrete manufacturing operations - rely on bounded delay
   between sampling of inputs, control computation and transfer of
   outputs to physical actuators that affect the controlled process.

it seems that there are possibly two completely different industrial requirements here which can not, and should not, be satisfied with a single DAG.  Are two documents appropriate here?

[Pascal] It is more than a different DAG, it is a different plant... I read your question as do we want an additional draft for factory automation? 

=====

>   Note: Although there are known patent applications for duocast and
>   N-cast, at the time of this writing the patent assignee, Honeywell
>   International, has offered to permit cost-free RAND use in those
>   industrial wireless standards that have chosen to employee the
>   technology, under a reciprocal licensing requirement relative to that
>   use.  

Can we get an official IPR statement via:
    http://www.ietf.org/ipr/file-disclosure

on this?  I don't think it is particularly relevant to the document, but perhaps I could be wrong.

you need to update [I-D.ietf-roll-rpl] to RFC6550.

[Pascal] Done in 03 : )

4.3.1 says:

> Because the actual link capacity depends on the particular link 
> technology used within an industrial automation network deployment, 
> the Trickle parameters are specified in terms of the link's maximum 
> capacity for conveying link-local multicast messages.  If the link can 
> convey m link-local multicast packets per second on average, the 
> expected time it takes to transmit a link-local multicast packet is 
> 1/m seconds.

I am pleased that a formula is being provided, but I am uncomfortable that this document is not more specific to actual link technology used.
Can this document pick 1-2 actual link technologies and deal with them?

[Pascal] We are working on those concepts at 6TSCH, ccing the ML.


========

5.:
  > The possibility of dynamically updating the metrics in use in the
  > network as well as the frequency of network updates allows deployment
  > characteristics (e.g., network density) to be discovered during
  > network bring-up and to be used to tailor network parameters once the
  > network is operational rather than having to rely on precise pre-
  > configuration.  This also allows the network parameters and the
  > overall routing protocol behavior to evolve during the lifetime of
  > the network.

I don't know how this discovery is going to occur.
Someone trying to build a sensor that is going to satisfy an RFP for devices to work in a network envisioned by this document needs to know
what to include in their code base.   As the code space is very finite,
they need to know exactly what is important here.

[Pascal] Finding the values for parameters is more of a deployment issue, so I read your question as 'which parameters are critical for the device to operate in industrial environment and which range for those parameters'. Again, work at 6TSCH may help.

Cheers,

Pascal