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

Tom Phinney <tom.phinney@cox.net> Fri, 01 March 2013 19:42 UTC

Return-Path: <tom.phinney@cox.net>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2590621F8600 for <roll@ietfa.amsl.com>; Fri, 1 Mar 2013 11:42:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.947
X-Spam-Level:
X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PekpSmRLjIw for <roll@ietfa.amsl.com>; Fri, 1 Mar 2013 11:42:22 -0800 (PST)
Received: from fed1rmfepo201.cox.net (fed1rmfepo201.cox.net [68.230.241.146]) by ietfa.amsl.com (Postfix) with ESMTP id C107F21F85DA for <roll@ietf.org>; Fri, 1 Mar 2013 11:42:21 -0800 (PST)
Received: from fed1rmimpo305 ([68.230.241.173]) by fed1rmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130301194221.LOJR19285.fed1rmfepo201.cox.net@fed1rmimpo305> for <roll@ietf.org>; Fri, 1 Mar 2013 14:42:21 -0500
Received: from 192.168.1.250 ([68.106.19.170]) by fed1rmimpo305 with cox id 6KiL1l00c3gAAro01KiLC8; Fri, 01 Mar 2013 14:42:21 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020204.5131049D.0057,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=W9Hmo2qk c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=6t4AJK7m8D8A:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=k8pYvbRhVL0A:10 a=48vgC7mUAAAA:8 a=rbl1wQeSwIs0QDm_BuAA:9 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=1XBuBeO_FlPd5T-q:21 a=3Rh-E_-K3_sQRJYf:21 a=JyzrQi_NOIWKAaGf:21 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <5131049C.9020504@cox.net>
Date: Fri, 01 Mar 2013 12:42:20 -0700
From: Tom Phinney <tom.phinney@cox.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "roll@ietf.org" <roll@ietf.org>, "6tsch@ietf.org" <6tsch@ietf.org>
References: <20381.1362077015@sandelman.ca> <E045AECD98228444A58C61C200AE1BD835CD4B00@xmb-rcd-x01.cisco.com> <17207.1362162863@sandelman.ca>
In-Reply-To: <17207.1362162863@sandelman.ca>
X-Enigmail-Version: 1.1.1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 04 Mar 2013 09:50:38 -0800
Cc: "draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org" <draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org>
Subject: Re: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Tom Phinney <tom.phinney@cox.net>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2013 19:42:23 -0000

Apologies to those who receive this e-mail on more than one list.


First, the traditional industry differentiation between "factory automation" and "process control" is that factory automation is focused on discrete manufacturing steps (and thus is often referred to as "discrete parts manufacturing") while process control involves continuous processing of fluids and quasi-fluids (e.g., sand, cereal and other materials whose flow rate can be measured by a mass flowmeter).

Many real-world plants use hybrids of these two manufacturing styles. For example, a soup canning plant, or drink bottling plant (e.g., a brewery), or a dairy that bottles milk and packages ice cream, or a pharmaceutical plant, or a car tire manufacturing plant, all use continuous-flow manufacturing processes (process control) to make the raw product in batches, and discrete part manufacturing processes (factory automation) to package the product. This hybrid mode of operation is often referred to as "batch processing" and has its own terminology and set of standards that build on those of the other two manufacturing regimes. ISA, the Industrial Society for Automation, has developed standards that address both continuous process control and batch processes that are fed materials from a continuous process. (Most ISA standards then become IEC standards.)


Second, the distinction between peer/peer,
client/server, publish/subscribe and source/sink is as follows:

1a) peer/peer is a 1:1 relationship
of known correspondents, usually connected (i.e., a longer-term association with coordinated residual state information at both ends). This relationship can be symmetric (i.e., federation) or asymmetric (i.e., client/server).

1b) client/server is an asymmetric peer-peer relationship
of "known" correspondents in which the client is always the initiator of the relationship. In cases where the provided service is transactional, the association often is more transient than in a symmetric peer-peer relationship. In this case the server may be a member of a server farm, in which case the correspondent is known by role, not device ID.

2) publish/subscribe is a 1:N relationship of known correspondents, which is best implemented as a multi-peer connection
(i.e., a longer-term association with coordinated residual state information at the endpoints). Some industrial communication technologies, such as IEC 61158 Type 1 (Foundation Fieldbus H1) provide multi-peer connections within the lower four comm layers to directly support such operation. Timeliness is usually important in the publish/subscribe relationship, whether it be the timeliness of daily newspaper delivery or the timeliness of information delivery between devices acting in concert in closed-loop continuous control. As a consequence, untimely retransmission is not of significant value.

3) source/sink is a M:N relationship of unknown correspondents, which is best implemented by connectionless lower layer services. In the automation environment it is used primarily for reporting of alerts, which include a) device-local events and b) alarms about the monitored process. Alerts are reportable by every device that is involved in sensing and controlling the process -- the M of M:N -- and are reported to all devices that are interested in receiving such reports -- the N of M:N. That latter set includes all human operator workstations that are focused on the monitored process, all historians that are tracking information in the monitored process, etc. There is never a need for comm-layer-initiated retransmission of such information; other application-layer mechanisms come into play to retrieve recent reporting history from individual members of the M set when loss of a report is detected an an N endpoint. To make such loss detection and bulk recovery possible, each alert source includes a local monotonically-increasing sequence number in each alert report.

So, in summary,
1a) peer/peer is 1:1 and typically connected;
1b) client/server is 1:1 and often connected, particularly when the association is longer than a single transaction,
2) publish/subscribe is 1:N with known N, and connected in a long-term relationship;
3) source/sink is M:N with unknown M and N, and connectionless.

Typically 1a) and 1b) use unicast in each direction; 2) uses unicast in the subscriber-to-publisher direction and multicast to a publication-specific group address in the publisher-to-subscriber direction; and 3) uses multicast to a group address identifying the reported information scope (e.g., "unit_N_alerts").

-Tom
=====
On 2013.03.01 11:34, Michael Richardson wrote:

      
"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" rel="nofollow">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.