[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

ROLL                                                     T. Phinney, Ed.
Internet-Draft                                                consultant
Intended status: Informational                                P. Thubert
Expires: April 3, 2012                                             Cisco
                                                            RA. Assimiti
                                                                   Nivis
                                                         October 1, 2011


                RPL applicability in industrial networks
             draft-phinney-rpl-industrial-applicability-00

Abstract

   The wide deployment of wireless devices, with their low installed
   cost (compared to wired devices), will significantly improve the
   productivity and safety of industrial plants, while simultaneously
   increasing the efficiency and safety of the plant's workers, by
   extending and making more timely the information set available about
   plant operations.  The new Routing Protocol for Low Power and Lossy
   Networks (RPL) defines a Distance Vector protocol that is designed
   for such networks.  The aim of this document is to analyze the
   applicability of that routing protocol in industrial LLNs of field
   devices.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Phinney, et al.           Expires April 3, 2012                 [Page 1]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.











































Phinney, et al.           Expires April 3, 2012                 [Page 2]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Deployment scenarii  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Applications and Traffic classes . . . . . . . . . . . . .  9
     3.3.  RPL applicability matrix . . . . . . . . . . . . . . . . . 10
   4.  Characterization of communication flows in IACS wireless
       networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Source-sink (SS) communication paradigm  . . . . . . . . . 13
     4.3.  Publish-subscribe (PS, or pub/sub) communication
           paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.4.  Peer-to-peer (P2P) communication paradigm  . . . . . . . . 15
     4.5.  Peer-to-multipeer (P2MP) communication paradigm  . . . . . 16
     4.6.  Additional considerations: Duocast and N-cast  . . . . . . 17
     4.7.  RPL applicability per communication paradigm . . . . . . . 18
   5.  RPL profile  . . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.1.  Use for process control  . . . . . . . . . . . . . . . . . 21
     5.2.  RPL features . . . . . . . . . . . . . . . . . . . . . . . 21
       5.2.1.  Storing vs. non-storing mode . . . . . . . . . . . . . 21
       5.2.2.  DAO policy . . . . . . . . . . . . . . . . . . . . . . 21
       5.2.3.  Path metrics . . . . . . . . . . . . . . . . . . . . . 22
       5.2.4.  Objective functions  . . . . . . . . . . . . . . . . . 22
       5.2.5.  DODAG repair . . . . . . . . . . . . . . . . . . . . . 22
       5.2.6.  Security . . . . . . . . . . . . . . . . . . . . . . . 22
     5.3.  RPL options  . . . . . . . . . . . . . . . . . . . . . . . 22
     5.4.  Recommended configuration defaults and ranges  . . . . . . 22
       5.4.1.  Trickle parameters . . . . . . . . . . . . . . . . . . 22
       5.4.2.  Other parameters . . . . . . . . . . . . . . . . . . . 23
       5.4.3.  Additional configuration recommendations . . . . . . . 23
   6.  Other related protocols  . . . . . . . . . . . . . . . . . . . 24
   7.  Manageability  . . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 26
   9.  Security considerations  . . . . . . . . . . . . . . . . . . . 27
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     11.2. Informative References . . . . . . . . . . . . . . . . . . 29
     11.3. External Informative References  . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31









Phinney, et al.           Expires April 3, 2012                 [Page 3]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


1.  Introduction

   Information Technology (IT) is already, and increasingly will be
   applied to industrial Automation and Control System (IACS) technology
   in application areas where those IT technologies can be constrained
   sufficiently by Service Level Agreements (SLA) or other modest change
   that they are able to meet the operational needs of IACS.  When that
   happens, the IACS benefits from the large intellectual, experiential
   and training investment that has already occurred in those IT
   precursors.  One can conclude that future reuse of additional IT
   protocols for IACS will continue to occur due to the significant
   intellectual, experiential and training economies which result from
   that reuse.

   Following that logic, many vendors are already extending or replacing
   their local field-bus technology with Ethernet and IP-based
   solutions.  Examples of this evolution include CIP EtherNet/IP,
   Modbus/TCP, Foundation Fieldbus HSE, PROFInet and Invensys/Foxboro
   FOXnet.  At the same time, wireless, low power field devices are
   being introduced that facilitate a significant increase in the amount
   of information which industrial users can collect and the number of
   control points that can be remotely managed.

   IPv6 appears as a core technology at the conjunction of both trends,
   as illustrated by the current [ISA100.11a] industrial Wireless Sensor
   Networking (WSN) specification, where layers 1-4 technologies
   developed for end uses other than IACS - IEEE 802.15.4 PHY and MAC,
   6LoWPAN and IPv6, and UDP - are adapted to IACS use.  But due to the
   lack of open standards for routing in Low power and Lossy Networks
   (LLN), even ISA100.11a leaves the routing operation to proprietary
   methods.

   The IETF ROLL Working Group has defined application-specific routing
   requirements for a LLN routing protocol, specified in:

      Routing Requirements for Urban LLNs [RFC5548],

      Industrial Routing Requirements in LLNs [RFC5673],

      Home Automation Routing Requirements in LLNs [RFC5826], and

      Building Automation Routing Requirements in LLNs [RFC5867].

   The Routing Protocol for Low Power and Lossy Networks (RPL)
   [I-D.ietf-roll-rpl] specification and its point to point extension/
   optimization [I-D.ietf-roll-p2p-rpl] define a generic Distance Vector
   protocol that is adapted to a variety of Low Power and Lossy Networks
   (LLN) types by the application of specific Objective Functions (OFs).



Phinney, et al.           Expires April 3, 2012                 [Page 4]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
   within instances of the protocol, each instance being associated with
   an Objective Function to form a routing topology.

   A field device that belongs to an instance uses the OF to determine
   which DODAG and which Version of that DODAG the device should join.
   The device also uses the OF to select a number of routers within the
   DODAG current and subsequent Versions to serve as parents or as
   feasible successors.  A new Version of the DODAG is periodically
   reconstructed to enable a global reoptimization of the graph.

   A RPL OF states the outcome of the process used by a RPL node to
   select and optimize routes within a RPL Instance based on the
   information objects available.  The separation of OFs from the core
   protocol specification allows RPL to be adapted to meet the different
   optimization criteria required by the wide range of industrial
   classes of traffic and applications.

   This document provides information on how RPL can accommodate the
   industrial requirements for LLNs, in particular as specified in
   [RFC5673].






























Phinney, et al.           Expires April 3, 2012                 [Page 5]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   Additionally, this document uses terminology from
   [I-D.ietf-roll-terminology], and uses usual terminology from the
   Process Control and Factory Automation industries, some of which is
   recapitulated below:

   FEC:  Forward error correction

   IACS: Industrial automation and control systems

   RAND: reasonable and non-discriminatory (relative to licensing of
         patents)

































Phinney, et al.           Expires April 3, 2012                 [Page 6]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


3.  Overview

3.1.  Deployment scenarii

   [RFC5673] describes in detail the routing requirements for industrial
   LLNs.  This RFC provides information on the varying deployment
   scenarios for such LLNs and how RPL assists in meeting those
   requirements.

   Large industrial plants, or major operating areas within such plants,
   repeatedly go through four major phases, each of which typically
   lasts from months to years:

     P1: Construction or major modification phase

     P2: Planned startup phase

     P3: Normal operation phase

     P4: Planned shutdown phase

   followed eventually by an (at least theoretical)

     P5: Plant decommissioning phase.

   It is also likely, after a major catastrophe at a plant, to have a

     P6: Post-emergency recovery and repair phase.

   The deployment scenarios for wireless LLN devices may be different in
   each of these phases.  In particular, during the Construction or
   major modification phase (P1), LLN devices may be installed months
   before the intended LLN can become usefully operational (because
   needed routers and infrastructure devices are not yet installed or
   active), and there are likely to be many personnel in whom the plant
   owner/operator has only limited trust, such as subcontractors and
   others in the plant area who have undergone only a cursory background
   investigation (if any at all).  In general, during this phase, plant
   instrumentation is not yet operational, so could be removed and
   replaced by a Trojaned device without much likelihood of physical
   detection of the substitution.  Thus physical security of LLN devices
   is generally a more significant risk factor during this phase than
   once the plant is operational, where simple replacement of device
   electronics is detectable.

   Extra LLN devices and even extra LLN subnets may be employed during
   Planned startup (P2) and Planned shutdown (P4) phases, in support of
   the task of transitioning the plant or plant area between operational



Phinney, et al.           Expires April 3, 2012                 [Page 7]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   and shutdown states.  The extra devices typically provide extra
   monitoring as the plant transitions infrequent activity states.  (In
   many continuous process plants, up to 2x extra staff are employed at
   monitoring and control workstations during these two phases,
   precisely because the plant is undergoing extraordinary behavior as
   it transitions to or from its steady-state operational condition.)

   Similar transient devices and subnets may be used during an
   unscheduled Post-emergency recovery and repair phase (P6) of
   operation, but in that case the extra devices usually are routers
   substituting for plant LLN devices that have been damaged by the
   incident (such as a fire, explosion, flood, tornado or hurricane)
   that induced the emergency.

   The Planned startup (P2) and Planned shutdown (P4) phases are similar
   in many respects, but the LLN environment of the two can be quite
   different, since the Planned shutdown phase can assume that the
   stable LLN environment used for Normal operation (P3) is functional
   during shutdown, whereas that stable environment usually is still
   being established during startup.

   The Post-emergency recovery and repair phase (P6) typically operates
   in an LLN environment that is somewhere between that of the Planned
   startup (P2) and Normal operation (P3) phases, but with an
   indeterminate number of temporary routers placed to facilitate
   communication across and around the area affected by the catastrophe.

   Smaller industrial plants and sites may go through similar phases,
   but often commingle the phases because, in those smaller plants, the
   phases require less planning and structuring of personnel
   responsibilities and thus permit less formalization and partitioning
   of the operating scenarios.  For example, it is much simpler, and
   usually requires much less planning, to bring new equipment on a skid
   into a plant, using a forklift, than to lay temporary railroad track
   or employ an extended-axle heavy haul tractor-trailer to deliver a
   multi-ton process vessel, and temporarily deploy and use very large
   heavy-lift cranes to install it.  In the former cases, nearby
   equipment usually can continue normal operation while the
   installation proceeds; in the latter case that is almost always
   impossible, due to safety and other concerns.

   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.

   Additionally, it could be envisioned to include RPL in the normal
   operation provided that a new Objective Function is defined that



Phinney, et al.           Expires April 3, 2012                 [Page 8]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   actually interacts with the PCE is order to establish the reference
   topology, in which case RPL operations would only apply to emergency
   repair actions. when the reference topology becomes unusable for some
   failure, and as long as the problem persists.

3.2.  Applications and Traffic classes

   The industrial market classifies process applications into three
   broad categories and six classes.

   o  Safety

      *  Class 0: Emergency action - Always a critical function

   o  Control

      *  Class 1: Closed loop regulatory control - Often a critical
         function

      *  Class 2: Closed loop supervisory control - Usually non-critical
         function

      *  Class 3: Open loop control - Operator takes action and controls
         the actuator (human in the loop)

   o  Monitoring

      *  Class 4: Alerting - Short-term operational effect (for example
         event-based maintenance)

      *  Class 5: Logging and downloading / uploading - No immediate
         operational consequence (e.g., history collection, sequence-of-
         events, preventive maintenance)

   Safety critical functions effect the basic safety integrity of the
   plant.  These normally dormant functions kick in only when process
   control systems, or their operators, have failed.  By design and by
   regular interval inspection, they have a well-understood probability
   of failure on demand in the range of typically once per 10-1000
   years.

   In-time deliveries of messages becomes more relevant as the class
   number decreases.

   Note that for a control application, the jitter is just as important
   as latency and has a potential of destabilizing control algorithms.

   The domain of applicability for the RPL protocol probably matches the



Phinney, et al.           Expires April 3, 2012                 [Page 9]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   range of classes where industrial users are interested in deploying
   wireless networks.  This domain includes monitoring classes (4 and
   5), and the non-critical portions of control classes (2 and 3).  RPL
   might also be considered as an additional repair mechanism in all
   situations, and independently of the flow classification and the
   medium type.

3.3.  RPL applicability matrix

   It appears from the above sections that whether and the way RPL can
   be applied for a given flow depends both on the deployment scenario
   and on the class of application / traffic.  At a high level, this can
   be summarized by the following matrix:


+---------------------+------------------------------------------------+
|   Phase \  Class    |   0       1       2       3       4       5    |
+=====================+================================================+
|   Construction      |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|   Planned startup   |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|   Normal operation  |                           ?       ?       ?    |
+---------------------+------------------------------------------------+
|   Planned shutdown  |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|Plant decommissioning|                   X       X       X       X    |
+---------------------+------------------------------------------------+
| Recovery and repair |   X       X       X       X       X       X    |
+---------------------+------------------------------------------------+

 ? : typically usable for all but higher-rate classes 0,1 PS traffic

                    Figure 1: RPL applicability matrix

















Phinney, et al.           Expires April 3, 2012                [Page 10]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


4.  Characterization of communication flows in IACS wireless networks

4.1.  General

   In an IACS, high-rate communications flows (e.g., 1 Hz or 4 Hz for a
   traditional process automation network) typically are such that only
   a single wireless LLN hop separates the source device from a LLN
   Border Router (LBR) to a significantly higher data-rate backbone
   network, typically based on IEEE 802.3, IEEE 802.11, or IEEE 802.16,
   as illustrated in Figure 2.


                  ---+------------------------
                     |          Plant Network
                     |
                  +-----+
                  |     | Gateway
                  |     |
                  +-----+
                     |
                     |      Backbone
               +--------------------+------------------+
               |                    |                  |
            +-----+             +-----+             +-----+
            |     | LLN border  |     | LLN border  |     | LLN border
       o    |     | router      |     | router      |     | router
            +-----+             +-----+             +-----+
       o                  o                   o                 o
           o    o   o         o   o  o   o         o  o   o o
                                           LLN

    o : stationary wireless field device, seldom acting as an LLN router

         Figure 2: High-rate low-delay low-variance IACS topology

   For factory automation networks, the basic communications cycle for
   control is typically much faster, on the order of 100 Hz or more.  In
   this case the LLN itself may be based on high-data-rate IEEE 802.11
   or a 100 Mbit/s or faster optical link, and the higher-rate network
   used by the LBRs to connect the LLN to superior automation equipment
   typically might be based on fiber-optic IEEE 802.3, with multiple
   LBRs around the periphery of the factory area, so that most high-rate
   communications again requires only a single wireless LLN hop.

   Multi-hop LLN routing is used within the LLN portion of such networks
   to provide backup communications paths when primary single-hop LLN
   paths fail, or for lower repetition rate communications where longer
   LLN transit times and higher variance are not an issue.  Typically,



Phinney, et al.           Expires April 3, 2012                [Page 11]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   the majority of devices in an IACS can tolerate such higher-delay
   higher-variance paths, so routing choices often are driven by energy
   considerations for the affected devices, rather than simply by IACS
   performance requirements, as illustrated in Figure 3.

                   ---+------------------------
                     |          Plant Network
                     |
                  +-----+
                  |     | Gateway
                  |     |
                  +-----+
                     |
                     |      Backbone
               +--------------------+------------------+
               |                    |                  |
            +-----+             +-----+             +-----+
            |     | Backbone    |     | Backbone    |     | Backbone
            |     | router      |     | router      |     | router
            +-----+             +-----+             +-----+
               o    o   o    o     o   o  o   o   o   o  o   o o
           o o   o  o   o  o  o o   o  o  o   o   o   o  o  o  o o
          o  o o  o o    o   o   o  o  o  o    M    o  o  o o o
          o   o  M o  o  o     o  o    o  o  o    o  o   o  o   o
            o   o o       o        o  o         o        o o
                    o           o          o             o     o
                                           LLN

    o : stationary wireless field device, often acting as an LLN router
    M : mobile wireless device

       Figure 3: Low-rate higher-delay higher-variance IACS topology

   Two decades of experience with digital fieldbuses has shown that four
   communications paradigms dominate in IACS:

   SS:    Source-sink

   PS:    Publish-subscribe

   P2P:   Peer-to-peer

   P2MP:  Peer-to-multipeer








Phinney, et al.           Expires April 3, 2012                [Page 12]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


4.2.  Source-sink (SS) communication paradigm

   In SS, the source-sink communication paradigm, each of many devices
   in one set, S1, sends UDP-like messages, usually infrequently and
   intermittently, to a second set of devices, S2, determined by a
   common multicast address.  A typical example would be that all
   devices within a given process unit N are configured to send process
   alarm messages to the multicast address
   Receivers_of_process_alarms_for_unit_N. Receiving devices, typically
   on non-LLN networks accessed via LBRs, are configured to receive such
   multicast messages if their work assignment covers process unit N,
   and not otherwise.

   Timeliness of message delivery is a significant aspect of some SS
   communication.  When the SS traffic conveys process alarms or device
   alerts, there is often a contractual requirement, and sometimes even
   a regulatory requirement, on the maximum end-to-end transit delay of
   the SS message, including both the LLN and non-LLN components of that
   delay.  However, there is no requirement on relative jitter in the
   delivery of multiple SS messages from the same source, and message
   reordering during transit is irrelevant.

   Within the LLN, the SS paradigm simply requires that messages so
   addressed be forwarded to the responsible LBR (or set of equivalent
   LBRs) for further forwarding outside the LLN.  Within the LLN such
   traffic typically is device-to-LBR or device-to-redundant-set-of-
   equivalent-LBRs.  In general, SS traffic may be aggregated before
   forwarding when both the multicast destination address and other QoS
   attributes are identical.  If information on the target delivery
   times for SS messages is available to the aggregating forwarding
   device, that device may intentionally delay forwarding somewhat to
   facilitate further aggregation, which can significantly reduce LLN
   alarm-reporting traffic during major plant upset events.

4.3.  Publish-subscribe (PS, or pub/sub) communication paradigm

   In PS, the publish-subscribe communication paradigm, a device sends
   UDP-like messages, usually periodically or cyclicly (i.e.,
   repetitively but without fixed periodicity), to a single multicast
   address derived from or correlated with the device's own address.  A
   typical example would be that each sensor and actuator device within
   a given process unit N is configured to send process state messages
   to the multicast address that designates its specific publications.
   In essence the derived multicast address for device D is
   Receivers_of_publications_by_device_D. Typically those receivers are
   in two categories: controllers (C) for control loops in which device
   D participates, and devices accessed via the LLN's LBRs that monitor
   and/or accumulate historical information about device D's status and



Phinney, et al.           Expires April 3, 2012                [Page 13]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   outputs.

   If the controller(s) that receive device D's publication are all
   outside the LLN and accessed by LBRs, then within the LLN such
   traffic typically is device-to-LBR or device-to-redundant-set-of-
   equivalent-LBRs.  But if a controller (Cn) is within the LLN, then a
   number of different LLN-local traffic patterns may be employed,
   depending on the capabilities of the underlying link technology and
   on configured performance requirements for such reporting.  Typically
   in such a case, publication by device D is forwarded up a DODAG to an
   LLN router that is also on a downward DODAG to a destination
   controller Cn, then forwarded down that second DODAG to that
   destination controller Cn.  Of course, if the LLN router (or even the
   LBR) is itself the intended destination controller, which will often
   be the case, then no downward forwarding occurs.

   Timeliness of message delivery is a critical aspect of PS
   communication.  Individual messages can be lost without significant
   impact on the controlled physical process, but typically a sequence
   of four consecutive lost messages will trigger fallback behavior of
   the control algorithms, which is considered a system failure by most
   system owner/operators.  (In general, and unless a local catastrophic
   event such as a major explosion or a tornado occurs in the plant,
   invocation of more than one instance of such fallback handling per
   year, per plant, is considered unacceptable.)

   Message loss, delay and jitter in delivery of PS messaging is a
   relative matter.  PS messaging is used for transfer of process
   measurements and associated status from sensors to control
   computation elements, from control computation elements to actuators,
   and of current commanded position and status from actuators back to
   control computation elements.  The actual time interval of interest
   is that which starts with sensing of the physical process (which
   necessarily occurs before the sensed value can be sent in the first
   message) and which ends when the computed control correction is
   applied to the physical process by the appropriate actuator (which
   cannot occur until after the second message containing the computed
   control output has been received by that actuator).  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.

   Deliberately manipulated message delay and jitter in delivery of PS
   messaging has the potential to destabilize control loops.  It is the



Phinney, et al.           Expires April 3, 2012                [Page 14]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   responsibility of conveyed higher-level protocols to protect against
   such potential security attacks by detecting overly delayed or
   jittered messages at delivery, converting them into instances of
   message loss.  Thus network and data-link protocols such as IPv6 and
   Ethernet need not themselves address such issues, although their
   selection and employment should take the existence (or lack) of such
   higher-layer protection mechanisms, and the resulting consequences
   due to excessive delay and jitter, into consideration in their
   parameterization.

   In general, PS traffic within the LLN is not aggregated before
   forwarding, to minimize message loss and delay in reception by any
   relevant controller(s) that are outside the LLN.  However, if all
   intended destination controllers are within the LLN, and at least one
   of those intended controllers also serves as an LLN router on a DODAG
   to off-LLN destinations that all are not controllers, then the router
   functions in that device may aggregate PS traffic before forwarding
   when the required routing and other QoS attributes are identical.  If
   information on the target delivery times for PS messages to non-
   controller devices is available to the aggregating forwarding device,
   that device may intentionally delay forwarding somewhat to facilitate
   further aggregation.

   In some system architectures, message streams that use PS to convey
   current process measurements and status are compressed at the source
   through a 2-dimensional winnowing process that compares

   1) the process measurement values and status of the about-to-be-sent
      message with that of the last actually-sent message, and

   2) the current time vs. the queueing time for the last actually-sent
      message.

   If the interval since that last-sent message is less than a
   predefined maximum time, and the status is unchanged, and the process
   measurement(s) conveyed in the message is within predefined
   deadband(s) of the last-sent measurement value(s), then transmission
   of the new message is suppressed.  Often this suppression takes the
   form of not queuing the new message for transmission, but in some
   protocols a brief placeholder message indicating "no significant
   change" is queued in its stead.

4.4.  Peer-to-peer (P2P) communication paradigm

   In P2P, the peer-to-peer communication paradigm, a device sends UDP-
   like or TCP-like messages from one device (D1) to a second device
   (D2), usually with bidirectional but asymmetric flow of application
   data, where the amount of data is significantly greater in one



Phinney, et al.           Expires April 3, 2012                [Page 15]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   direction than the other.  Typical examples are transfer of
   configuration information to or from a process field device, or
   transfer of captured process diagnostics (e.g., time-stamped noise
   signatures from a coriolis flowmeter) to an off-LLN higher-level
   asset management system.  Unicast addressing is used in both
   directions of data flow.

   In general, specific P2P traffic has only loose timeliness
   requirements, typically just those required so that response times to
   human-operator-initiated actions meet human factors requirements.  As
   a consequence, in general, message aggregation is permitted, although
   few opportunities are likely to present themselves for such
   aggregation due to the sporadic nature of such messaging to a single
   destination, and/or due to the large message payloads that often
   occur in at least one direction of transmission.

4.5.  Peer-to-multipeer (P2MP) communication paradigm

   In P2MP, the peer-to-multipeer communication paradigm, a device sends
   UDP-like messages downward, from one device (D1) to a set of other
   devices (Dn).  Typical examples are bulk downloads to a set of
   devices that use identical code image segments or identically-
   structured database segments; group commands to enable device state
   transitions that are quasi-synchronized across all or part of the
   local network (e.g., switch to the next set of point-to-point
   downloaded session keys, or notifying that the network is switching
   to an emergency repair and recovery mode); etc.  Multicast addressing
   is used in the downward direction of data flow.

   Devices can be assigned to a number of multicast groups, for instance
   by device type.  Then, if it becomes necessary to reflash all devices
   of a given type with a new load image, a multicast distribution
   mechanism can be leveraged to optimize the distribution operation.

   In general, P2MP traffic has only loose timeliness requirements.  As
   a consequence, in general, message aggregation is permitted, although
   few opportunities are likely to present themselves for such
   aggregation due to the sporadic nature of such messaging to a single
   multicast group destination, and/or due to the large message payloads
   that often occur when P2MP is used for group downloads.  However, in
   general, message aggregation negatively impacts the delivery success
   rate for each of the aggregated messages, since the probability of
   error in a received message increases with message length> Together
   these considerations often lead to a policy of non-aggregation for
   P2MP messaging.

   Note: Reliable group download protocols, such as the no-longer-
   published IEEE 802.1E (ISO/IEC 15802-4) system load protocol, and



Phinney, et al.           Expires April 3, 2012                [Page 16]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   reliable multicast protocols based on the guidance of RFC2887, are
   instructive in how P2MP can be used for initial bulk download,
   followed by either P2MP or P2P selective retransmissions for missed
   download segments.

4.6.  Additional considerations: Duocast and N-cast

   In industrial automation systems, some traffic is from (relatively)
   high-rate monitoring and control loops, of Class 0 and Class 1 as
   described in [RFC5673].  In such systems, the wireless link protocol,
   which typically uses immediate in-band acknowledgement to confirm
   delivery (or, on failure, conclude that a retransmission is
   required), can be adapted to attempt simultaneous delivery to more
   than one receiving device, with separated, sequenced immediate in-
   band acknowledgement by each of those intended receivers.  (This
   mechanism is known colloquially as "duocast" (for two intended
   receivers), or more generically as "N-cast" (for N intended
   receivers).)  Transmission is deemed successful if at least one such
   immediate acknowledgement is received by the sending device;
   otherwise the device queues the message for retransmission, up until
   the maximum configured number of retries has been attempted.

   The logic behind duocast/N-cast is very simple: In wireless systems
   without FEC (forward error correction), the overall rate of success
   for transactions consisting of an initial transmission and an
   immediate acknowledgement is typically 95%.  In other words, 5% of
   such transactions fail, either because the initial message of the
   transaction is not received correctly by the intended receiver, or
   because the immediate acknowledgment by that receiver is not received
   correctly by the transaction initiator.

   In the generalized case of N-cast, where any received acknowledgement
   serves to complete the transaction, and where the N intended
   receivers are spatially diverse, physically separated from each other
   by multiple wavelengths, the probability that all such receivers fail
   to receive the initial message of the transaction, or that all
   generated immediate acknowledgements are not received by the
   transaction initiator, is typically approximately (5%)^N. Thus, for
   duocast, the expected success rate for a single transaction goes from
   95% (1.0 - 0.05) to 99.75% (1.0 - 0.05^2), to 99.9875% (1.0 - 0.05^3)
   when N=3, and even higher when N>3.

   From the above analysis, it is obvious that the primary benefit of
   N-cast occurs when N goes from N=1 (unicast) to N=2 (duocast); the
   reduction in transaction loss rate for increasing N>2 is quite small,
   and for N>3 it is infinitesimal.  In the typical industrial
   automation environment of class 1 process control loops, which
   typically repeat at a 1 Hz or 4 Hz rate, in a very large process



Phinney, et al.           Expires April 3, 2012                [Page 17]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   plant with thousands of field devices reporting at that rate, the
   maximum number of transmission retries that must be planned, and for
   which capacity must be scheduled (within the requisite 250 ms or 1 s
   interval) is seven (7) retries for unicast PS reporting, but only
   three (3) retries with duocast PS reporting.  (This is determined by
   the requirement to not miss four successive reports more than once
   per year, across the entire plant, as such a loss typically triggers
   fallback behavior in the controlled loop, which is considered a
   failure of the wireless system by the plant owner/operator.)  In
   practice, the enormous reduction in both planned and used
   retransmission capacity provided by duocast/N-cast is what enables
   4 Hz loops to be supported in large wireless systems.

   When available, duocast/N-cast typically is used only for one-hop PS
   traffic on Class 1 and Class 0 control loops.  It may also be
   employed for rapid, reliable one-hop delivery of Class 0 and
   sometimes Class 1 process alarms and device alerts, which use the SS
   paradigm.  Because it requires scheduling of multiple receivers that
   are prepared to acknowledge the received message during the
   transaction, in general it is not appropriate for the other types of
   traffic in such systems - P2P and P2MP - and is not needed for other
   classes of control loops or other types of traffic, which do not have
   such stringent reporting requirements.

   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.  Since duocast and N-cast provide performance and energy
   optimizations, they are not essential for use in wireless systems.
   However, in practice, their use makes it possible to support 4 Hz
   wireless loops and meet sub-second safety alarm reporting
   requirements in large plants, where that might otherwise be
   impractical without use of a wired network.  When duocast/N-cast is
   not employed, the wireless retransmission capacity that is needed to
   support such fast loops often is excessive, typically over 100x that
   actually used for retransmission (i.e., providing for seven retries
   per transaction when the mean number used is only 0.06 retries).

4.7.  RPL applicability per communication paradigm

   To match the requirements above, RPL provides a number of RPL Modes
   of Operation (MOP):







Phinney, et al.           Expires April 3, 2012                [Page 18]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   No downward route:  defined in [I-D.ietf-roll-rpl], section 6.3.1,
      MOP of 0.  This mode allows only upward routing, that is from
      nodes (devices) that reside inside the RPL network toward the
      outside via the DODAG root.

   Non-storing mode:  defined in [I-D.ietf-roll-rpl], section 6.3.1, MOP
      of 1.  This mode improves MOP 0 by adding the capability to use
      source routing from the root towards registered targets within the
      instance DODAG.

   Storing mode without multicast support:  defined in
      [I-D.ietf-roll-rpl], section 6.3.1, MOP of 2.  This mode improves
      MOP 0 by adding the capability to use stateful routing from the
      root towards registered targets within the instance DODAG.

   Storing mode with link-scope multicast DAO:  defined in
      [I-D.ietf-roll-rpl] section 9.10, this mode improves MOP 2 by
      adding the capability to send Destination Advertisements to all
      nodes over a single Layer 2 link (e.g. a wireless hop) and enables
      line-of-sight direct communication.

   Storing mode with multicast support:  defined in [I-D.ietf-roll-rpl],
      Mode-of-operation (MOP) of 3.  This mode improves MOP 2 by adding
      the capability to register multicast groups and perform multicast
      forwarding along the instance DODAG (or a spanning subtree within
      the DODAG).

   Reactive:  defined in [I-D.ietf-roll-p2p-rpl], the reactive mode
      creates on-demand additional DAGs that are used to reach a given
      node acting as DODAG root within a certain number of hops.  This
      mode can typically be used for an ad-hoc closed-loop
      communication.

   The RPL MOP that can be applied for a given flow depends on the
   communication paradigm.  It must be noted that a DODAG that is used
   for PS traffic can also be used for SS traffic since the MOP 2
   extends the MOP 0, and that a DODAG that is used for P2MP
   distribution can also be used for downward PS since the MOP 3 extends
   the MOP 2.

   On the other hand, an Objective Function (OF) that optimizes metrics
   for a pure upwards DODAG might differ from the OF that optimizes a
   mixed upward and downward DODAG.

   As a result, it can be expected that different RPL instances are
   installed with different OFs, different channel allocations, etc...
   that result in different routing and forwarding topologies, sometimes
   with differing delay vs. energy profiles, optimized separately for



Phinney, et al.           Expires April 3, 2012                [Page 19]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   the different flows at hand.

   This can be broadly summarized in the following table:


+---------------------+------------+-----------------------------------+
|   Paradigm\RPL MOP  |  RPL spec  |         Mode of operation         |
+=====================+============+===================================+
|   Peer-to-peer      |  RPL P2P   |     reactive (on-demand)          |
+---------------------+------------+-----------------------------------+
|   P2P line-of-sight |  RPL base  |  2 (storing) with multicast DAO   |
+---------------------+------------+-----------------------------------+
|   P2MP distribution |  RPL base  |     3 (storing with multicast)    |
+---------------------+------------+-----------------------------------+
|   Publish-subscribe |  RPL base  |  1 or 2 (storing or not-storing)  |
+---------------------+------------+-----------------------------------+
|   Source-sink       |  RPL base  |     0 (no downward route)         |
+---------------------+------------+-----------------------------------+
|   N-cast publish    |  RPL base  |     0 (no downward route)         |
+---------------------+------------+-----------------------------------+


          Figure 4: RPL applicability per communication paradigm




























Phinney, et al.           Expires April 3, 2012                [Page 20]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


5.  RPL profile

5.1.  Use for process control

   This section outlines a RPL profile for a representative deployment
   in a process control application.  Process monitoring without control
   is typically less demanding, so a subset of this profile generally
   will suffice.

5.2.  RPL features

5.2.1.  Storing vs. non-storing mode

   RPL operation is defined for a single RPL instance.  However,
   multiple RPL instances can be supported in multi-service networks
   where different applications may require the use of different routing
   metrics and constraints, e.g., a network carrying both safety and
   non-safety control and monitoring traffic.

   In general, storing mode is required for high-reporting-rate devices
   (where "high rate" is with respect to the underlying link data
   conveyance capability).  Such devices, in the absence of path
   failure, are typically only one hop from the LBR(s) that convey their
   messaging to other parts of the system.  Fortunately, in such cases,
   the routing tables required by such nodes are small, even when they
   include information on DODAGs that are used as backup alternate
   routes.

   In general, devices which communicate with LBRs through a chain of
   intermediary devices will use storing mode for their upward DODAGs,
   but will use non-storing mode for downward DODAGs for messaging that
   they route further into the LLN.  However, routers that provide
   downward forwarding for PS messaging addressed to controllers within
   the LLN (which is expected to be a rare occurrence) will use storing
   mode for those forwarding paths, so that timely, destination-
   constrained forwarding of such recurring messaging does not overload
   the routing node(s) and their downstream subnets.

5.2.2.  DAO policy

   Two-way communication is a requirement in industrial automation
   systems.  As a result, nodes SHOULD send DAO messages to establish
   downward paths from the root to themselves.

   <to be added>






Phinney, et al.           Expires April 3, 2012                [Page 21]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


5.2.3.  Path metrics

   RPL relies on an Objective Function for selecting parents and
   computing path costs and rank.  This objective function is decoupled
   from the core RPL mechanisms and also from the metrics in use in the
   network.  Two objective functions for RPL have been defined at the
   time of this writing, OF0 and MRHOF, both of which define the
   selection of a preferred parent and backup parents, and are suitable
   for industrial automation network deployments.

   Neither of the currently defined objective functions supports
   multiple metrics that might be required in heterogeneous industrial
   automation networks (e.g., networks composed of devices with
   different energy and timeliness-of-communication constraints).
   Additional objective functions specifically designed for such
   networks may be defined in companion RFCs.

5.2.4.  Objective functions

   <to be added>

5.2.5.  DODAG repair

5.2.6.  Security

   Industrial automation network deployments typically operate in areas
   that provide limited physical security (relative to the risk of
   attack).  For this reason, the link layer, transport layer and
   application layer technologies utilized within such networks
   typically provide security mechanisms to ensure authentication,
   confidentiality, integrity, timeliness and freshness.  As a result,
   such deployments may not need to implement RPL's security mechanisms
   and could rely on link layer and higher layer security features.

5.3.  RPL options

5.4.  Recommended configuration defaults and ranges

5.4.1.  Trickle parameters

   Trickle was designed to be density-aware and perform well in networks
   characterized by a wide range of node densities.  The combination of
   DIO packet suppression and adaptive timers for sending updates allows
   Trickle to perform well in both sparse and dense environments.

   <to be added>





Phinney, et al.           Expires April 3, 2012                [Page 22]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


5.4.2.  Other parameters

   <to be added>

5.4.3.  Additional configuration recommendations

   <to be added>












































Phinney, et al.           Expires April 3, 2012                [Page 23]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


6.  Other related protocols

   <to be added>
















































Phinney, et al.           Expires April 3, 2012                [Page 24]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


7.  Manageability

   Network manageability is a critical aspect of smart grid network
   deployment and operation.  With millions of devices participating in
   the smart grid network, many requiring real-time reachability,
   automatic configuration, and lightweight network health monitoring
   and management are crucial for achieving network availability and
   efficient operation.

   RPL enables automatic and consistent configuration of RPL routers
   through parameters specified by the DODAG root and disseminated
   through DIO packets.  The use of Trickle for scheduling DIO
   transmissions ensures lightweight yet timely propagation of important
   network and parameter updates and allows network operators to choose
   the trade-off point they are comfortable with respect to overhead vs.
   reliability and timeliness of network updates.

   The metrics in use in the network along with the Trickle Timer
   parameters used to control the frequency and redundancy of network
   updates can be dynamically varied by the root during the lifetime of
   the network.  To that end, all DIO messages SHOULD contain a Metric
   Container option for disseminating the metrics and metric values used
   for DODAG setup.  In addition, DIO messages SHOULD contain a DODAG
   Configuration option for disseminating the Trickle Timer parameters
   throughout the network.

   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.

   RPL specifies a number of variables and events that can be tracked
   for purposes of network fault and performance monitoring of RPL
   routers.  Depending on the memory and processing capabilities of each
   smart grid device, various subsets of these can be employed in the
   field.

   <to be added>









Phinney, et al.           Expires April 3, 2012                [Page 25]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


8.  IANA considerations

   This specification has no requirement on IANA.
















































Phinney, et al.           Expires April 3, 2012                [Page 26]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


9.  Security considerations

   This document does not specify operations that could introduce new
   threats.  Security considerations for RPL deployments are to be
   developed in accordance with recommendations laid out in, for
   example, [I-D.tsao-roll-security-framework].

   Industrial automation networks are subject to stringent security
   requirements as they are considered a critical infrastructure
   component.  At the same time, since they are composed of large
   numbers of resource- constrained devices inter-connected with
   limited-throughput links, many available security mechanisms are not
   practical for use in such networks.  As a result, the choice of
   security mechanisms is highly dependent on the device and network
   capabilities characterizing a particular deployment.

   In contrast to other types of LLNs, in industrial automation networks
   centralized administrative control and access to a permanent secure
   infrastructure is available.  As a result link-layer, transport-layer
   and/or application-layer security mechanisms are typically in place
   and may make use of RPL's secure mode unnecessary.






























Phinney, et al.           Expires April 3, 2012                [Page 27]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


10.  Acknowledgements

   <to be added>
















































Phinney, et al.           Expires April 3, 2012                [Page 28]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [I-D.ietf-roll-of0]
              Thubert, P., "RPL Objective Function Zero",
              draft-ietf-roll-of0-20 (work in progress), September 2011.

   [I-D.ietf-roll-p2p-rpl]
              Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie,
              R., and J. Martocci, "Reactive Discovery of Point-to-Point
              Routes in Low Power and Lossy Networks",
              draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011.

   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-06 (work in
              progress), September 2011.

   [I-D.tsao-roll-security-framework]
              Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
              Security Framework for Routing over Low Power and Lossy
              Networks", draft-tsao-roll-security-framework-02 (work in
              progress), March 2010.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.



Phinney, et al.           Expires April 3, 2012                [Page 29]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.

11.3.  External Informative References

   [HART]     www.hartcomm.org, "Highway Addressable Remote Transducer,
              a group of specifications for industrial process and
              control devices administered by the HART Foundation".

   [ISA100.11a]
              ISA, "ISA100, Wireless Systems for Automation", May 2008,
              <     http://www.isa.org/Community/
              SP100WirelessSystemsforAutomation>.





































Phinney, et al.           Expires April 3, 2012                [Page 30]


Internet-Draft   RPL-industrial-applicability-statement     October 2011


Authors' Addresses

   Tom Phinney (editor)
   consultant
   5012 W. Torrey Pines Circle
   Glendale, AZ  85308-3221
   USA

   Phone: +1 602 938 3163
   Email: tom.phinney@cox.net


   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com


   Robert Assimiti
   Nivis
   1000 Circle 75 Parkway SE, Ste 300
   Atlanta, GA  30339
   USA

   Phone: +1 678 202 6859
   Email: robert.assimiti@nivis.com



















Phinney, et al.           Expires April 3, 2012                [Page 31]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/