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

[Michael Richardson <[e-mail]>]

>>>>> "pthubert" == pthubert  <Pascal> writes:
    pthubert> [Pascal] Thanks for the comments : )

    pthubert> [Pascal] You are correct. The industry makes a difference
    pthubert> between Factory Automation (discrete manufacturing of
    pthubert> individual products) and Process Controls (continuous
    pthubert> production). These are really 2 different activities, and
    pthubert> Factory Automation may require much stricter behaviors for
    pthubert> very rapid operations.  At ISA, WG 11 has standardized

I guess this means that individual products are things which can come
out of a production step, and then accumulate before going into the next
step. (The kind of thing Goldratt warns us against having anywhere other
than at a CCR)

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

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

I think that we need to think about:
1) are the P1/P2/P4/P5 and P6 phases distinct in some way?
   I think that there are significant security differences between them,
   and the number of type of DAGs that need to be constructed may very
   a lot. This has implications that intermediate (storing!) nodes may
   have to have much large capacities for DAGs during non-P3 than they
   do for P3.  Or not...
   My examination of RPL code to date suggests that some of what lets it
   fit into the smallest devices is because they support only a single DAG.
   (no tables, no searches, no code to sort A from B...)

2) how do you bootstrap *securely* into P3 operation?
   Does this require a rekey?  It seems to me that it does.

    pthubert> 1) publish/subscribe, where an association exists between
    pthubert> one source and one or a few recipients, all of which are
    pthubert> identifiable, where publication is periodic within strict

So, layer-6 multicasts carried on layer-3 unicast to known
subscribers... 

    pthubert> 2) source/sink, where any of a number of sources logically
    pthubert> multicasts (however that is implemented) to a predefined

1:N multicast

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

and this is 1:1


    pthubert> page 13, section 2.1.4: says:

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

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

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

So, factory automation and plant control are not present in the same
building.  When someone comes along with factory automation expertise,
they will need to write a draft.

I'm not sure why factory automation is mentioned again.
Let's just say:

Tthe 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.   As a result.. X, Y, Z.

    >> 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.

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

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

Not sure why it is mentioned then.

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

    pthubert> [Pascal] Done in 03 : )

    pthubert> 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.

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

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

But, wait. 6tsch is important for P3 only.
The other phases need to have something written down.
I think it's pretty important to have some concrete numbers for some
actual technologies that actually are being deployed.    Without that,
it's pretty hard for academics to run simulations, or for people
thinking about RPL extensions in field X to think how this might work
(or not) in another field they aren't an expert in.

Also, we need that set of layer 2s to be listed so that the security
requirements of layer 2 can be expressed.  Again, non-P3 vs P3 might
require a rekey.

    pthubert> 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.

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

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

Yes, that's what I'm saying.

The text talks about "dynamically updating the metrics in use"

That says to me that it's not about the values of the metrics, but in
changing which metrics are used.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [