[Roll] [6tsch] comments on draft-phinney-roll-rpl-industrial-applicability

Tom Phinney <tom.phinney@cox.net> Sat, 02 March 2013 17:58 UTC

Return-Path: <tom.phinney@cox.net>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4488321F8576 for <roll@ietfa.amsl.com>; Sat, 2 Mar 2013 09:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kXz-rkWvyWR5 for <roll@ietfa.amsl.com>; Sat, 2 Mar 2013 09:58:52 -0800 (PST)
Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net []) by ietfa.amsl.com (Postfix) with ESMTP id 699D021F84BE for <roll@ietf.org>; Sat, 2 Mar 2013 09:58:52 -0800 (PST)
Received: from fed1rmimpo209 ([]) by fed1rmfepo101.cox.net (InterMail vM. 201-2260-137-20101110) with ESMTP id <20130302175851.VPHK25001.fed1rmfepo101.cox.net@fed1rmimpo209> for <roll@ietf.org>; Sat, 2 Mar 2013 12:58:51 -0500
Received: from ([]) by fed1rmimpo209 with cox id 6hyr1l0093gAAro01hyrgr; Sat, 02 Mar 2013 12:58:51 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020201.51323DDB.0094,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=SfMpgItu c=1 sm=1 a=mbYREmtDDBfCLQwKCHNpxg==:17 a=YkMd_PYDa9IA:10 a=mu-2PAB6mIwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=zKXdt2971PUA:10 a=OyP9-m7eLojCRTrj5WcA:9 a=QEXdDO2ut3YA:10 a=4vB-4DCPJfMA:10 a=mbYREmtDDBfCLQwKCHNpxg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Message-ID: <51323DDA.6050301@cox.net>
Date: Sat, 02 Mar 2013 10:58:50 -0700
From: Tom Phinney <tom.phinney@cox.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "roll@ietf.org" <roll@ietf.org>, "6tsch@ietf.org" <6tsch@ietf.org>
References: <29193.1362243215@sandelman.ca>
In-Reply-To: <29193.1362243215@sandelman.ca>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 04 Mar 2013 09:50:39 -0800
Subject: [Roll] [6tsch] 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: Sat, 02 Mar 2013 17:58:53 -0000

On 2013.03.02 09:53, Michael Richardson wrote:
>>>>>> "Tom" == Tom Phinney <tom.phinney@cox.net>; writes:
>     Tom> variance in cycle-to-cycle.execution time. The messaging
>     Tom> involved in such automation typically require higher data rates
>     Tom> than those offered by IEEE 802.15.4, and any wireless messaging
> ...
>     Tom>    The communication between the continuous process controllers
>     Tom> of a plant and the discrete automation controllers typically
>     Tom> occurs on a 100 Mbit/s or faster backbone comm link. Wireless
>     Tom> is not involved, and there is no reason to anticipate that it
> mcr> So, given that many plants are hybrids, are you saying that
> mcr> this document applies only to the process control parts of the
> mcr> plant?
> So, I take it that you are agreeing with this statement.
Essentially yes. While the higher-layer parts of industrial wireless
protocols such as WirelessHART and ISA-100.11a are more-or-less suitable
for use in the factory automation environment, in general the time
scales of required reporting and action are such that IEEE 802.15.4 will
not be appropriate. Of course there may be some parts of the plant, such
as mechanical interlocks against human intrusion, that are workable with
a 100 ms or 250 ms or even 1 s reporting delay, but that will not be
true for limit switches and other such devices in factory automation
lines that typically must report every few ms.
> And disagreeing that "hybrid plants are also out of scope", because
> all process plants have a factory automation component, but that the
> factory automation component is out of scope.
Essentially yes, because the ROLL/RPL mechanism is focused on
self-organizing multi-hop networks where significant variance in
reporting delays is generally tolerable. The portions of process
automation networks where tight time constraints apply are typically one
hop off the backbone, so ROLL/RPL would be used only for self-organizing
system startup or recover after a plant disaster (e.g., explosion, fire,
tornado tearing up the plant, etc.). Likewise for most factory
automation systems, due to the information timeliness demands of the
PLCs that typically automate such processes.
> Further, you have made it clear that there is no direct interconnection
> between the two networks.
If you don't consider a wired Ethernet connection between routers to be
a direct connection, then that must be the case. I personally would not
phrase it that way; rather, the two networks do not interact directly in
their network organization, although their members communicate as
directly as their differing communications technologies permit.

Note that this is also true for IEEE 802.15.4 systems that communicate
with 802.11 systems; their networks do not interact directly in their
network organization, even though they use the same spectral RF band in
the same 3D spatial region. This is particularly the case where ETSI 300
328 v1.8.1 applies, since the process system may have to use at least
fifteen IEEE 802.15.4 channels when the distances involved require
operation at greater than 10 dBm EIRP and timeliness considerations do
not permit indefinitely-repeated deferral to ongoing IEEE 802.11