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
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.
- [Roll] comments on draft-phinney-roll-rpl-industr… Michael Richardson
- Re: [Roll] comments on draft-phinney-roll-rpl-ind… Pascal Thubert (pthubert)
- Re: [Roll] comments on draft-phinney-roll-rpl-ind… Michael Richardson
- Re: [Roll] [6tsch] comments on draft-phinney-roll… Michael Richardson
- Re: [Roll] [6tsch] comments on draft-phinney-roll… Michael Richardson
- Re: [Roll] comments on draft-phinney-roll-rpl-ind… Tom Phinney
- Re: [Roll] [6tsch] comments on draft-phinney-roll… Tom Phinney
- [Roll] [6tsch] comments on draft-phinney-roll-rpl… Tom Phinney