summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5673.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5673.txt')
-rw-r--r--doc/rfc/rfc5673.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc5673.txt b/doc/rfc/rfc5673.txt
new file mode 100644
index 0000000..69e7f56
--- /dev/null
+++ b/doc/rfc/rfc5673.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group K. Pister, Ed.
+Request for Comments: 5673 Dust Networks
+Category: Informational P. Thubert, Ed.
+ Cisco Systems
+ S. Dwars
+ Shell
+ T. Phinney
+ Consultant
+ October 2009
+
+
+ Industrial Routing Requirements in Low-Power and Lossy Networks
+
+Abstract
+
+ The wide deployment of lower-cost wireless devices will significantly
+ improve the productivity and safety of industrial plants while
+ increasing the efficiency of plant workers by extending the
+ information set available about the plant operations. The aim of
+ this document is to analyze the functional requirements for a routing
+ protocol used in industrial Low-power and Lossy Networks (LLNs) of
+ field devices.
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 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
+ 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 BSD License.
+
+
+
+
+
+
+
+
+Pister, et al. Informational [Page 1]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Applications and Traffic Patterns . . . . . . . . . . . . 5
+ 3.2. Network Topology of Industrial Applications . . . . . . . 9
+ 3.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10
+ 3.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 12
+ 4. Requirements Related to Traffic Characteristics . . . . . . . 13
+ 4.1. Service Requirements . . . . . . . . . . . . . . . . . . . 14
+ 4.2. Configurable Application Requirement . . . . . . . . . . . 15
+ 4.3. Different Routes for Different Flows . . . . . . . . . . . 15
+ 5. Reliability Requirements . . . . . . . . . . . . . . . . . . . 16
+ 6. Device-Aware Routing Requirements . . . . . . . . . . . . . . 18
+ 7. Broadcast/Multicast Requirements . . . . . . . . . . . . . . . 19
+ 8. Protocol Performance Requirements . . . . . . . . . . . . . . 20
+ 9. Mobility Requirements . . . . . . . . . . . . . . . . . . . . 21
+ 10. Manageability Requirements . . . . . . . . . . . . . . . . . . 21
+ 11. Antagonistic Requirements . . . . . . . . . . . . . . . . . . 22
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
+ 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
+ 14.2. Informative References . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pister, et al. Informational [Page 2]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+1. Introduction
+
+ Information Technology (IT) is already, and increasingly will be
+ applied to industrial Control Technology (CT) in application areas
+ where those IT technologies can be constrained sufficiently by
+ Service Level Agreements (SLA) or other modest changes that they are
+ able to meet the operational needs of industrial CT. When that
+ happens, the CT 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 industrial CT will continue to occur due to the
+ significant intellectual, experiential, and training economies that
+ result from that reuse.
+
+ Following that logic, many vendors are already extending or replacing
+ their local fieldbus [IEC61158] technology with Ethernet and IP-based
+ solutions. Examples of this evolution include Common Industrial
+ Protocol (CIP) EtherNet/IP, Modbus/TCP, Fieldbus Foundation High
+ Speed Ethernet (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
+ that 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 specification, where technologies for layers 1-4 that were
+ developed for purposes other than industrial CT -- [IEEE802.15.4] PHY
+ and MAC, IPv6 over Low-Power Wireless Personal Area Networks
+ (6LoWPANs) [RFC4919], and UDP -- are adapted to industrial CT use.
+ But due to the lack of open standards for routing in Low-power and
+ Lossy Networks (LLNs), even ISA100.11a leaves the routing operation
+ to proprietary methods.
+
+ The aim of this document is to analyze the requirements from the
+ industrial environment for a routing protocol in Low power and Lossy
+ Networks (LLNs) based on IPv6 to power the next generation of Control
+ Technology.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+Pister, et al. Informational [Page 3]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+2. Terminology
+
+ This document employs terminology defined in the ROLL (Routing Over
+ Low-power and Lossy networks) terminology document [ROLL-TERM]. This
+ document also refers to industrial standards:
+
+ HART: Highway Addressable Remote Transducer, a group of
+ specifications for industrial process and control devices
+ administered by the HART Communication Foundation (see [HART]). The
+ latest version for the specifications is HART7, which includes the
+ additions for WirelessHART [IEC62591].
+
+ ISA: International Society of Automation, an ANSI-accredited
+ standards-making society. ISA100 is an ISA committee whose charter
+ includes defining a family of standards for industrial automation.
+ [ISA100.11a] is a working group within ISA100 that is working on a
+ standard for monitoring and non-critical process control
+ applications.
+
+3. Overview
+
+ Wireless, low-power field devices enable industrial users to
+ significantly increase the amount of information collected and the
+ number of control points that can be remotely managed. The
+ deployment of these wireless devices will significantly improve the
+ productivity and safety of the plants while increasing the efficiency
+ of the plant workers. IPv6 is perceived as a key technology to
+ provide the scalability and interoperability that are required in
+ that space, and it is more and more present in standards and products
+ under development and early deployments.
+
+ Cable is perceived as a more proven, safer technology, and existing,
+ operational deployments are very stable in time. For these reasons,
+ it is not expected that wireless will replace wire in any foreseeable
+ future; the consensus in the industrial space is rather that wireless
+ will tremendously augment the scope and benefits of automation by
+ enabling the control of devices that were not connected in the past
+ for reasons of cost and/or deployment complexities. But for LLNs to
+ be adopted in the industrial environment, the wireless network needs
+ to have three qualities: low power, high reliability, and easy
+ installation and maintenance. The routing protocol used for LLNs is
+ important to fulfilling these goals.
+
+ Industrial automation is segmented into two distinct application
+ spaces, known as "process" or "process control" and "discrete
+ manufacturing" or "factory automation". In industrial process
+ control, the product is typically a fluid (oil, gas, chemicals,
+ etc.). In factory automation or discrete manufacturing, the products
+
+
+
+Pister, et al. Informational [Page 4]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ are individual elements (screws, cars, dolls). While there is some
+ overlap of products and systems between these two segments, they are
+ surprisingly separate communities. The specifications targeting
+ industrial process control tend to have more tolerance for network
+ latency than what is needed for factory automation.
+
+ Irrespective of this different 'process' and 'discrete' plant nature,
+ both plant types will have similar needs for automating the
+ collection of data that used to be collected manually, or was not
+ collected before. Examples are wireless sensors that report the
+ state of a fuse, report the state of a luminary, HVAC status, report
+ vibration levels on pumps, report man-down, and so on.
+
+ Other novel application arenas that equally apply to both 'process'
+ and 'discrete' involve mobile sensors that roam in and out of plants,
+ such as active sensor tags on containers or vehicles.
+
+ Some if not all of these applications will need to be served by the
+ same low-power and lossy wireless network technology. This may mean
+ several disconnected, autonomous LLNs connecting to multiple hosts,
+ but sharing the same ether. Interconnecting such networks, if only
+ to supervise channel and priority allocations, or to fully
+ synchronize, or to share path capacity within a set of physical
+ network components may be desired, or may not be desired for
+ practical reasons, such as e.g., cyber security concerns in relation
+ to plant safety and integrity.
+
+ All application spaces desire battery-operated networks of hundreds
+ of sensors and actuators communicating with LLN access points. In an
+ oil refinery, the total number of devices might exceed one million,
+ but the devices will be clustered into smaller networks that in most
+ cases interconnect and report to an existing plant network
+ infrastructure.
+
+ Existing wired sensor networks in this space typically use
+ communication protocols with low data rates, from 1200 baud (e.g.,
+ wired HART) to the 100-200 kbps range for most of the others. The
+ existing protocols are often master/slave with command/response.
+
+3.1. Applications and Traffic Patterns
+
+ The industrial market classifies process applications into three
+ broad categories and six classes.
+
+ o Safety
+
+ * Class 0: Emergency action - Always a critical function
+
+
+
+
+Pister, et al. Informational [Page 5]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ o Control
+
+ * Class 1: Closed-loop regulatory control - Often a critical
+ function
+
+ * Class 2: Closed-loop supervisory control - Usually a 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 become 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.
+
+ Industrial users are interested in deploying wireless networks for
+ the monitoring classes 4 and 5, and in the non-critical portions of
+ classes 2 through 3.
+
+ Classes 4 and 5 also include asset monitoring and tracking, which
+ include equipment monitoring and are essentially separate from
+ process monitoring. An example of equipment monitoring is the
+ recording of motor vibrations to detect bearing wear. However,
+ similar sensors detecting excessive vibration levels could be used as
+ safeguarding loops that immediately initiate a trip, and thus end up
+ being class 0.
+
+ In the near future, most LLN systems in industrial automation
+ environments will be for low-frequency data collection. Packets
+ containing samples will be generated continuously, and 90% of the
+
+
+
+Pister, et al. Informational [Page 6]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ market is covered by packet rates of between 1/second and 1/hour,
+ with the average under 1/minute. In industrial process, these
+ sensors include temperature, pressure, fluid flow, tank level, and
+ corrosion. Some sensors are bursty, such as vibration monitors that
+ may generate and transmit tens of kilobytes (hundreds to thousands of
+ packets) of time-series data at reporting rates of minutes to days.
+
+ Almost all of these sensors will have built-in microprocessors that
+ may detect alarm conditions. Time-critical alarm packets are
+ expected to be granted a lower latency than periodic sensor data
+ streams.
+
+ Some devices will transmit a log file every day, again with typically
+ tens of kilobytes of data. For these applications, there is very
+ little "downstream" traffic coming from the LLN access point and
+ traveling to particular sensors. During diagnostics, however, a
+ technician may be investigating a fault from a control room and
+ expect to have "low" latency (human tolerable) in a command/response
+ mode.
+
+ Low-rate control, often with a "human in the loop" (also referred to
+ as "open loop"), is implemented via communication to a control room
+ because that's where the human in the loop will be. The sensor data
+ makes its way through the LLN access point to the centralized
+ controller where it is processed, the operator sees the information
+ and takes action, and the control information is then sent out to the
+ actuator node in the network.
+
+ In the future, it is envisioned that some open-loop processes will be
+ automated (closed loop) and packets will flow over local loops and
+ not involve the LLN access point. These closed-loop controls for
+ non-critical applications will be implemented on LLNs. Non-critical
+ closed-loop applications have a latency requirement that can be as
+ low as 100 milliseconds but many control loops are tolerant of
+ latencies above 1 second.
+
+ More likely though is that loops will be closed in the field
+ entirely, and in such a case, having wireless links within the
+ control loop does not usually present actual value. Most control
+ loops have sensors and actuators within such proximity that a wire
+ between them remains the most sensible option from an economic point
+ of view. This 'control in the field' architecture is already common
+ practice with wired fieldbusses. An 'upstream' wireless link would
+ only be used to influence the in-field controller settings and to
+ occasionally capture diagnostics. Even though the link back to a
+ control room might be wireless, this architecture reduces the tight
+ latency and availability requirements for the wireless links.
+
+
+
+
+Pister, et al. Informational [Page 7]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ Closing loops in the field:
+
+ o does not prevent the same loop from being closed through a remote
+ multivariable controller during some modes of operation, while
+ being closed directly in the field during other modes of operation
+ (e.g., fallback, or when timing is more critical)
+
+ o does not imply that the loop will be closed with a wired
+ connection, or that the wired connection is more energy efficient
+ even when it exists as an alternate to the wireless connection.
+
+ A realistic future scenario is for a field device with a battery or
+ ultra-capacitor power storage to have both wireless and unpowered
+ wired communications capability (e.g., galvanically isolated RS-485),
+ where the wireless communication is more flexible and, for local loop
+ operation, more energy efficient. The wired communication capability
+ serves as a backup interconnect among the loop elements, but without
+ a wired connection back to the operations center blockhouse. In
+ other words, the loop elements are interconnected through wiring to a
+ nearby junction box, but the 2 km home-run link from the junction box
+ to the control center does not exist.
+
+ When wireless communication conditions are good, devices use wireless
+ for loop interconnect, and either one wireless device reports alarms
+ and other status to the control center for all elements of the loop,
+ or each element reports independently. When wireless communications
+ are sporadic, the loop interconnect uses the self-powered
+ galvanically isolated RS-485 link and one of the devices with good
+ wireless communications to the control center serves as a router for
+ those devices that are unable to contact the control center directly.
+
+ The above approach is particularly attractive for large storage tanks
+ in tank farms, where devices may not all have good wireless
+ visibility of the control center, and where a home-run cable from the
+ tank to the control center is undesirable due to the electro-
+ potential differences between the tank location and the distant
+ control center that arise during lightning storms.
+
+ In fast control, tens of milliseconds of latency is typical. In many
+ of these systems, if a packet does not arrive within the specified
+ interval, the system enters an emergency shutdown state, often with
+ substantial financial repercussions. For a one-second control loop
+ in a system with a target of 30 years for the mean time between
+ shutdowns, the latency requirement implies nine 9s of reliability
+ (aka 99.9999999% reliability). Given such exposure, given the
+ intrinsic vulnerability of wireless link availability, and given the
+
+
+
+
+
+Pister, et al. Informational [Page 8]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ emergence of control in the field architectures, most users tend not
+ to aim for fast closed-loop control with wireless links within that
+ fast loop.
+
+3.2. Network Topology of Industrial Applications
+
+ Although network topology is difficult to generalize, the majority of
+ existing applications can be met by networks of 10 to 200 field
+ devices and a maximum number of hops of 20. It is assumed that the
+ field devices themselves will provide routing capability for the
+ network, and additional repeaters/routers will not be required in
+ most cases.
+
+ For the vast majority of industrial applications, the traffic is
+ mostly composed of real-time publish/subscribe sensor data also
+ referred to as buffered, from the field devices over an LLN towards
+ one or more sinks. Increasingly over time, these sinks will be a
+ part of a backbone, but today they are often fragmented and isolated.
+
+ The wireless sensor network (WSN) is an LLN of field devices for
+ which two logical roles are defined, the field routers and the non-
+ routing devices. It is acceptable and even probable that the
+ repartition of the roles across the field devices changes over time
+ to balance the cost of the forwarding operation amongst the nodes.
+
+ In order to scale a control network in terms of density, one possible
+ architecture is to deploy a backbone as a canopy that aggregates
+ multiple smaller LLNs. The backbone is a high-speed infrastructure
+ network that may interconnect multiple WSNs through backbone routers.
+ Infrastructure devices can be connected to the backbone. A gateway/
+ manager that interconnects the backbone to the plant network of the
+ corporate network can be viewed as collapsing the backbone and the
+ infrastructure devices into a single device that operates all the
+ required logical roles. The backbone is likely to become an option
+ in the industrial network.
+
+ Typically, such backbones interconnect to the 'legacy' wired plant
+ infrastructure, which is known as the plant network or Process
+ Control Domain (PCD). These plant automation networks are segregated
+ domain-wise from the office network or office domain (OD), which in
+ itself is typically segregated from the Internet.
+
+ Sinks for LLN sensor data reside on the plant network (the PCD), the
+ business network (the OD), and on the Internet. Applications close
+ to existing plant automation, such as wired process control and
+ monitoring systems running on fieldbusses, that require high
+ availability and low latencies, and that are managed by 'Control and
+ Automation' departments typically reside on the PCD. Other
+
+
+
+Pister, et al. Informational [Page 9]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ applications such as automated corrosion monitoring, cathodic
+ protection voltage verification, or machine condition (vibration)
+ monitoring where one sample per week is considered over-sampling,
+ would more likely deliver their sensor readings in the OD. Such
+ applications are 'owned' by, e.g., maintenance departments.
+
+ Yet other applications like third-party-maintained luminaries, or
+ vendor-managed inventory systems, where a supplier of chemicals needs
+ access to tank level readings at his customer's site, will be best
+ served with direct Internet connectivity all the way to its sensor at
+ his customer's site. Temporary 'babysitting sensors' deployed for
+ just a few days, say during startup or troubleshooting or for ad hoc
+ measurement campaigns for research and development purposes, are
+ other examples where Internet would be the domain where wireless
+ sensor data would land, and other domains such as the OD and PCD
+ should preferably be circumvented if quick deployment without
+ potentially impacting plant safety integrity is required.
+
+ This multiple-domain multiple-application connectivity creates a
+ significant challenge. Many different applications will all share
+ the same medium, the ether, within the fence, preferably sharing the
+ same frequency bands, and preferably sharing the same protocols,
+ preferably synchronized to optimize coexistence challenges, yet
+ logically segregated to avoid creation of intolerable shortcuts
+ between existing wired domains.
+
+ Given this challenge, LLNs are best to be treated as all sitting on
+ yet another segregated domain, segregated from all other wired
+ domains where conventional security is organized by perimeter.
+ Moving away from the traditional perimeter-security mindset means
+ moving towards stronger end-device identity authentication, so that
+ LLN access points can split the various wireless data streams and
+ interconnect back to the appropriate domain (pending the gateways'
+ establishment of the message originators' identity and trust).
+
+ Similar considerations are to be given to how multiple applications
+ may or may not be allowed to share routing devices and their
+ potentially redundant bandwidth within the network. Challenges here
+ are to balance available capacity, required latencies, expected
+ priorities, and (last but not least) available (battery) energy
+ within the routing devices.
+
+3.2.1. The Physical Topology
+
+ There is no specific physical topology for an industrial process
+ control network.
+
+
+
+
+
+Pister, et al. Informational [Page 10]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ One extreme example is a multi-square-kilometer refinery where
+ isolated tanks, some of them with power but most with no backbone
+ connectivity, compose a farm that spans over of the surface of the
+ plant. A few hundred field devices are deployed to ensure the global
+ coverage using a wireless self-forming self-healing mesh network that
+ might be 5 to 10 hops across. Local feedback loops and mobile
+ workers tend to be only 1 or 2 hops. The backbone is in the refinery
+ proper, many hops away. Even there, powered infrastructure is also
+ typically several hops away. In that case, hopping to/from the
+ powered infrastructure may often be more costly than the direct
+ route.
+
+ In the opposite extreme case, the backbone network spans all the
+ nodes and most nodes are in direct sight of one or more backbone
+ routers. Most communication between field devices and infrastructure
+ devices, as well as field device to field device, occurs across the
+ backbone. From afar, this model resembles the WiFi ESS (Extended
+ Service Set). But from a layer-3 (L3) perspective, the issues are
+ the default (backbone) router selection and the routing inside the
+ backbone, whereas the radio hop towards the field device is in fact a
+ simple local delivery.
+
+ ---------+----------------------------
+ | Plant Network
+ |
+ +-----+
+ | | Gateway M : Mobile device
+ | | o : Field device
+ +-----+
+ |
+ | 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
+
+ Figure 1: Backbone-Based Physical Topology
+
+
+
+
+
+Pister, et al. Informational [Page 11]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ An intermediate case is illustrated in Figure 1 with a backbone that
+ spans the Wireless Sensor Network in such a fashion that any WSN node
+ is only a few wireless hops away from the nearest backbone router.
+ WSN nodes are expected to organize into self-forming, self-healing,
+ self-optimizing logical topologies that enable leveraging the
+ backbone when it is most efficient to do so.
+
+ It must be noted that the routing function is expected to be so
+ simple that any field device could assume the role of a router,
+ depending on the self-discovery of the topology and the power status
+ of the neighbors. On the other hand, only devices equipped with the
+ appropriate hardware and software combination could assume the role
+ of an endpoint for a given purpose, such as sensor or actuator.
+
+3.2.2. Logical Topologies
+
+ Most of the traffic over the LLN is publish/subscribe of sensor data
+ from the field device towards a sink that can be a backbone router, a
+ gateway, or a controller/manager. The destination of the sensor data
+ is an infrastructure device that sits on the backbone and is
+ reachable via one or more backbone routers.
+
+ For security, reliability, availability, or serviceability reasons,
+ it is often required that the logical topologies are not physically
+ congruent over the radio network; that is, they form logical
+ partitions of the LLN. For instance, a routing topology that is set
+ up for control should be isolated from a topology that reports the
+ temperature and the status of the vents, if that second topology has
+ lesser constraints for the security policy. This isolation might be
+ implemented as Virtual LANs and Virtual Routing Tables in shared
+ nodes in the backbone, but correspond effectively to physical nodes
+ in the wireless network.
+
+ Since publishing the data is the raison d'etre for most of the
+ sensors, in some cases it makes sense to build proactively a set of
+ routes between the sensors and one or more backbone routers and
+ maintain those routes at all time. Also, because of the lossy nature
+ of the network, the routing in place should attempt to propose
+ multiple paths in the form of Directed Acyclic Graphs oriented
+ towards the destination.
+
+ In contrast with the general requirement of maintaining default
+ routes towards the sinks, the need for field device to field device
+ (FD-to-FD) connectivity is very specific and rare, though the traffic
+ associated might be of foremost importance. FD-to-FD routes are
+ often the most critical, optimized, and well-maintained routes. A
+ class 0 safeguarding loop requires guaranteed delivery and extremely
+ tight response times. Both the respect of criteria in the route
+
+
+
+Pister, et al. Informational [Page 12]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ computation and the quality of the maintenance of the route are
+ critical for the field devices' operation. Typically, a control loop
+ will be using a dedicated direct wire that has very different
+ capabilities, cost, and constraints than the wireless medium, with
+ the need to use a wireless path as a backup route only in case of
+ loss of the wired path.
+
+ Considering that each FD-to-FD route computation has specific
+ constraints in terms of latency and availability, it can be expected
+ that the shortest path possible will often be selected and that this
+ path will be routed inside the LLN as opposed to via the backbone.
+ It can also be noted that the lifetimes of the routes might range
+ from minutes for a mobile worker to tens of years for a command and
+ control closed loop. Finally, time-varying user requirements for
+ latency and bandwidth will change the constraints on the routes,
+ which might either trigger a constrained route recomputation, a
+ reprovisioning of the underlying L2 protocols, or both in that order.
+ For instance, a wireless worker may initiate a bulk transfer to
+ configure or diagnose a field device. A level sensor device may need
+ to perform a calibration and send a bulk file to a plant.
+
+4. Requirements Related to Traffic Characteristics
+
+ [ISA100.11a] selected IPv6 as its network layer for a number of
+ reasons, including the huge address space and the large potential
+ size of a subnet, which can range up to 10K nodes in a plant
+ deployment. In the ISA100 model, industrial applications fall into
+ four large service categories:
+
+ 1. Periodic data (aka buffered). Data that is generated
+ periodically and has a well understood data bandwidth
+ requirement, both deterministic and predictable. Timely delivery
+ of such data is often the core function of a wireless sensor
+ network and permanent resources are assigned to ensure that the
+ required bandwidth stays available. Buffered data usually
+ exhibits a short time to live, and the newer reading obsoletes
+ the previous. In some cases, alarms are low-priority information
+ that gets repeated over and over. The end-to-end latency of this
+ data is not as important as the regularity with which the data is
+ presented to the plant application.
+
+ 2. Event data. This category includes alarms and aperiodic data
+ reports with bursty data bandwidth requirements. In certain
+ cases, alarms are critical and require a priority service from
+ the network.
+
+
+
+
+
+
+Pister, et al. Informational [Page 13]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ 3. Client/Server. Many industrial applications are based on a
+ client/server model and implement a command response protocol.
+ The data bandwidth required is often bursty. The acceptable
+ round-trip latency for some legacy systems was based on the time
+ to send tens of bytes over a 1200 baud link. Hundreds of
+ milliseconds is typical. This type of request is statistically
+ multiplexed over the LLN and cost-based, fair-share, best-effort
+ service is usually expected.
+
+ 4. Bulk transfer. Bulk transfers involve the transmission of blocks
+ of data in multiple packets where temporary resources are
+ assigned to meet a transaction time constraint. Transient
+ resources are assigned for a limited time (related to file size
+ and data rate) to meet the bulk transfers service requirements.
+
+4.1. Service Requirements
+
+ The following service parameters can affect routing decisions in a
+ resource-constrained network:
+
+ o Data bandwidth - the bandwidth might be allocated permanently or
+ for a period of time to a specific flow that usually exhibits
+ well-defined properties of burstiness and throughput. Some
+ bandwidth will also be statistically shared between flows in a
+ best-effort fashion.
+
+ o Latency - the time taken for the data to transit the network from
+ the source to the destination. This may be expressed in terms of
+ a deadline for delivery. Most monitoring latencies will be in
+ seconds to minutes.
+
+ o Transmission phase - process applications can be synchronized to
+ wall clock time and require coordinated transmissions. A common
+ coordination frequency is 4 Hz (250 ms).
+
+ o Service contract type - revocation priority. LLNs have limited
+ network resources that can vary with time. This means the system
+ can become fully subscribed or even over-subscribed. System
+ policies determine how resources are allocated when resources are
+ over-subscribed. The choices are blocking and graceful
+ degradation.
+
+ o Transmission priority - the means by which limited resources
+ within field devices are allocated across multiple services. For
+ transmissions, a device has to select which packet in its queue
+ will be sent at the next transmission opportunity. Packet
+ priority is used as one criterion for selecting the next packet.
+ For reception, a device has to decide how to store a received
+
+
+
+Pister, et al. Informational [Page 14]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ packet. The field devices are memory-constrained and receive
+ buffers may become full. Packet priority is used to select which
+ packets are stored or discarded.
+
+ The routing protocol MUST also support different metric types for
+ each link used to compute the path according to some objective
+ function (e.g., minimize latency) depending on the nature of the
+ traffic.
+
+ For these reasons, the ROLL routing infrastructure is REQUIRED to
+ compute and update constrained routes on demand, and it can be
+ expected that this model will become more prevalent for FD-to-FD
+ connectivity as well as for some FD-to-infrastructure-device
+ connectivity over time.
+
+ Industrial application data flows between field devices are not
+ necessarily symmetric. In particular, asymmetrical cost and
+ unidirectional routes are common for published data and alerts, which
+ represent the most part of the sensor traffic. The routing protocol
+ MUST be able to compute a set of unidirectional routes with
+ potentially different costs that are composed of one or more non-
+ congruent paths.
+
+ As multiple paths are set up and a variety of flows traverse the
+ network towards a same destination (for instance, a node acting as a
+ sink for the LLN), the use of an additional marking/tagging mechanism
+ based on upper-layer information will be REQUIRED for intermediate
+ routers to discriminate the flows and perform the appropriate routing
+ decision using only the content of the IPv6 packet (e.g., use of
+ DSCP, Flow Label).
+
+4.2. Configurable Application Requirement
+
+ Time-varying user requirements for latency and bandwidth may require
+ changes in the provisioning of the underlying L2 protocols. A
+ technician may initiate a query/response session or bulk transfer to
+ diagnose or configure a field device. A level sensor device may need
+ to perform a calibration and send a bulk file to a plant. The
+ routing protocol MUST support the ability to recompute paths based on
+ network-layer abstractions of the underlying link attributes/metrics
+ that may change dynamically.
+
+4.3. Different Routes for Different Flows
+
+ Because different services categories have different service
+ requirements, it is often desirable to have different routes for
+ different data flows between the same two endpoints. For example,
+ alarm or periodic data from A to Z may require path diversity with
+
+
+
+Pister, et al. Informational [Page 15]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ specific latency and reliability. A file transfer between A and Z
+ may not need path diversity. The routing algorithm MUST be able to
+ generate different routes with different characteristics (e.g.,
+ optimized according to different costs, etc.).
+
+ Dynamic or configured states of links and nodes influence the
+ capability of a given path to fulfill operational requirements such
+ as stability, battery cost, or latency. Constraints such as battery
+ lifetime derive from the application itself, and because industrial
+ applications data flows are typically well-defined and well-
+ controlled, it is usually possible to estimate the battery
+ consumption of a router for a given topology.
+
+ The routing protocol MUST support the ability to (re)compute paths
+ based on network-layer abstractions of upper-layer constraints to
+ maintain the level of operation within required parameters. Such
+ information MAY be advertised by the routing protocol as metrics that
+ enable routing algorithms to establish appropriate paths that fit the
+ upper-layer constraints.
+
+ The handling of an IPv6 packet by the network layer operates on the
+ standard properties and the settings of the IPv6 packet header
+ fields. These fields include the 3-tuple of the Flow Label and the
+ Source and Destination Address that can be used to identify a flow
+ and the Traffic Class octet that can be used to influence the Per Hop
+ Behavior in intermediate routers.
+
+ An application MAY choose how to set those fields for each packet or
+ for streams of packets, and the routing protocol specification SHOULD
+ state how different field settings will be handled to perform
+ different routing decisions.
+
+5. Reliability Requirements
+
+ LLN reliability constitutes several unrelated aspects:
+
+ 1) Availability of source-to-destination connectivity when the
+ application needs it, expressed in number of successes divided by
+ number of attempts.
+
+ 2) Availability of source-to-destination connectivity when the
+ application might need it, expressed in number of potential
+ failures / available bandwidth,
+
+ 3) Ability, expressed in number of successes divided by number of
+ attempts to get data delivered from source to destination within
+ a capped time,
+
+
+
+
+Pister, et al. Informational [Page 16]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ 4) How well a network (serving many applications) achieves end-to-
+ end delivery of packets within a bounded latency,
+
+ 5) Trustworthiness of data that is delivered to the sinks,
+
+ 6) and others depending on the specific case.
+
+ This makes quantifying reliability the equivalent of plotting it on a
+ three (or more) dimensional graph. Different applications have
+ different requirements, and expressing reliability as a one
+ dimensional parameter, like 'reliability on my wireless network is
+ 99.9%' often creates more confusion than clarity.
+
+ The impact of not receiving sensor data due to sporadic network
+ outages can be devastating if this happens unnoticed. However, if
+ destinations that expect periodic sensor data or alarm status updates
+ fail to get them, then automatically these systems can take
+ appropriate actions that prevent dangerous situations. Pending the
+ wireless application, appropriate action ranges from initiating a
+ shutdown within 100 ms, to using a last known good value for as much
+ as N successive samples, to sending out an operator into the plant to
+ collect monthly data in the conventional way, i.e., some portable
+ sensor, or paper and a clipboard.
+
+ The impact of receiving corrupted data, and not being able to detect
+ that received data is corrupt, is often more dangerous. Data
+ corruption can either come from random bit errors due to white noise,
+ or from occasional bursty interference sources like thunderstorms or
+ leaky microwave ovens, but also from conscious attacks by
+ adversaries.
+
+ Another critical aspect for the routing is the capability to ensure
+ maximum disruption time and route maintenance. The maximum
+ disruption time is the time it takes at most for a specific path to
+ be restored when broken. Route maintenance ensures that a path is
+ monitored cannot stay disrupted for more than the maximum disruption
+ time. Maintenance should also ensure that a path continues to
+ provide the service for which it was established, for instance, in
+ terms of bandwidth, jitter, and latency.
+
+ In industrial applications, availability is usually defined with
+ respect to end-to-end delivery of packets within a bounded latency.
+ Availability requirements vary over many orders of magnitude. Some
+ non-critical monitoring applications may tolerate an availability of
+ less than 90% with hours of latency. Most industrial standards, such
+ as HART7 [IEC62591], have set user availability expectations at
+ 99.9%. Regulatory requirements are a driver for some industrial
+ applications. Regulatory monitoring requires high data integrity
+
+
+
+Pister, et al. Informational [Page 17]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ because lost data is assumed to be out of compliance and subject to
+ fines. This can drive up either availability or trustworthiness
+ requirements.
+
+ Because LLN link stability is often low, path diversity is critical.
+ Hop-by-hop link diversity is used to improve latency-bounded
+ reliability by sending data over diverse paths.
+
+ Because data from field devices are aggregated and funneled at the
+ LLN access point before they are routed to plant applications, LLN
+ access point redundancy is an important factor in overall
+ availability. A route that connects a field device to a plant
+ application may have multiple paths that go through more than one LLN
+ access point. The routing protocol MUST be able to compute paths of
+ not-necessarily-equal cost toward a given destination so as to enable
+ load-balancing across a variety of paths. The availability of each
+ path in a multipath route can change over time. Hence, it is
+ important to measure the availability on a per-path basis and select
+ a path (or paths) according to the availability requirements.
+
+6. Device-Aware Routing Requirements
+
+ Wireless LLN nodes in industrial environments are powered by a
+ variety of sources. Battery-operated devices with lifetime
+ requirements of at least five years are the most common. Battery
+ operated devices have a cap on their total energy, and typically can
+ report an estimate of remaining energy, and typically do not have
+ constraints on the short-term average power consumption. Energy-
+ scavenging devices are more complex. These systems contain both a
+ power-scavenging device (such as solar, vibration, or temperature
+ difference) and an energy storage device, such as a rechargeable
+ battery or a capacitor. These systems, therefore, have limits on
+ both long-term average power consumption (which cannot exceed the
+ average scavenged power over the same interval) as well as the short-
+ term limits imposed by the energy storage requirements. For solar-
+ powered systems, the energy storage system is generally designed to
+ provide days of power in the absence of sunlight. Many industrial
+ sensors run off of a 4-20 mA current loop, and can scavenge on the
+ order of milliwatts from that source. Vibration monitoring systems
+ are a natural choice for vibration scavenging, which typically only
+ provides tens or hundreds of microwatts. Due to industrial
+ temperature ranges and desired lifetimes, the choices of energy
+ storage devices can be limited, and the resulting stored energy is
+ often comparable to the energy cost of sending or receiving a packet
+ rather than the energy of operating the node for several days. And
+ of course, some nodes will be line-powered.
+
+
+
+
+
+Pister, et al. Informational [Page 18]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ Example 1: solar panel, lead-acid battery sized for two weeks of
+ rain.
+
+ Example 2: vibration scavenger, 1 mF tantalum capacitor.
+
+ Field devices have limited resources. Low-power, low-cost devices
+ have limited memory for storing route information. Typical field
+ devices will have a finite number of routes they can support for
+ their embedded sensor/actuator application and for forwarding other
+ devices packets in a mesh network slotted-link.
+
+ Users may strongly prefer that the same device have different
+ lifetime requirements in different locations. A sensor monitoring a
+ non-critical parameter in an easily accessed location may have a
+ lifetime requirement that is shorter and may tolerate more
+ statistical variation than a mission-critical sensor in a hard-to-
+ reach place that requires a plant shutdown in order to replace.
+
+ The routing algorithm MUST support node-constrained routing (e.g.,
+ taking into account the existing energy state as a node constraint).
+ Node constraints include power and memory, as well as constraints
+ placed on the device by the user, such as battery life.
+
+7. Broadcast/Multicast Requirements
+
+ Some existing industrial plant applications do not use broadcast or
+ multicast addressing to communicate to field devices. Unicast
+ address support is sufficient for them.
+
+ In some other industrial process automation environments, multicast
+ over IP is used to deliver to multiple nodes that may be functionally
+ similar or not. Example usages are:
+
+ 1) Delivery of alerts to multiple similar servers in an automation
+ control room. Alerts are multicast to a group address based on
+ the part of the automation process where the alerts arose (e.g.,
+ the multicast address "all-nodes-interested-in-alerts-for-
+ process-unit-X"). This is always a restricted-scope multicast,
+ not a broadcast.
+
+ 2) Delivery of common packets to multiple routers over a backbone,
+ where the packets result in each receiving router initiating
+ multicast (sometimes as a full broadcast) within the LLN. For
+ instance, this can be a byproduct of having potentially
+ physically separated backbone routers that can inject messages
+ into different portions of the same larger LLN.
+
+
+
+
+
+Pister, et al. Informational [Page 19]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ 3) Publication of measurement data to more than one subscriber.
+ This feature is useful in some peer-to-peer control applications.
+ For example, level position may be useful to a controller that
+ operates the flow valve and also to the overfill alarm indicator.
+ Both controller and alarm indicator would receive the same
+ publication sent as a multicast by the level gauge.
+
+ All of these uses require an 1:N security mechanism as well; they
+ aren't of any use if the end-to-end security is only point-to-point.
+
+ It is quite possible that first-generation wireless automation field
+ networks can be adequately useful without either of these
+ capabilities, but in the near future, wireless field devices with
+ communication controllers and protocol stacks will require control
+ and configuration, such as firmware downloading, that may benefit
+ from broadcast or multicast addressing.
+
+ The routing protocol SHOULD support multicast addressing.
+
+8. Protocol Performance Requirements
+
+ The routing protocol MUST converge after the addition of a new device
+ within several minutes, and SHOULD converge within tens of seconds
+ such that a device is able to establish connectivity to any other
+ point in the network or determine that there is a connectivity issue.
+ Any routing algorithm used to determine how to route packets in the
+ network, MUST be capable of routing packets to and from a newly added
+ device within several minutes of its addition, and SHOULD be able to
+ perform this function within tens of seconds.
+
+ The routing protocol MUST distribute sufficient information about
+ link failures to enable traffic to be routed such that all service
+ requirements (especially latency) continue to be met. This places a
+ requirement on the speed of distribution and convergence of this
+ information as well as the responsiveness of any routing algorithms
+ used to determine how to route packets. This requirement only
+ applies at normal link failure rates (see Section 5) and MAY degrade
+ during failure storms.
+
+ Any algorithm that computes routes for packets in the network MUST be
+ able to perform route computations in advance of needing to use the
+ route. Since such algorithms are required to react to link failures,
+ link usage information, and other dynamic link properties as the
+ information is distributed by the routing protocol, the algorithms
+ SHOULD recompute route based on the receipt of new information.
+
+
+
+
+
+
+Pister, et al. Informational [Page 20]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+9. Mobility Requirements
+
+ Various economic factors have contributed to a reduction of trained
+ workers in the industrial plant. A very common problem is that of
+ the "wireless worker". Carrying a PDA or something similar, this
+ worker will be able to accomplish more work in less time than the
+ older, better-trained workers that he or she replaces. Whether the
+ premise is valid, the use case is commonly presented: the worker will
+ be wirelessly connected to the plant IT system to download
+ documentation, instructions, etc., and will need to be able to
+ connect "directly" to the sensors and control points in or near the
+ equipment on which he or she is working. It is possible that this
+ "direct" connection could come via the normal LLNs data collection
+ network. This connection is likely to require higher bandwidth and
+ lower latency than the normal data collection operation.
+
+ PDAs are typically used as the user interfaces for plant historians,
+ asset management systems, and the like. It is undecided if these
+ PDAs will use the LLN directly to talk to field sensors, or if they
+ will rather use other wireless connectivity that proxies back into
+ the field or to anywhere else.
+
+ The routing protocol SHOULD support the wireless worker with fast
+ network connection times of a few of seconds, and low command and
+ response latencies to the plant behind the LLN access points, to
+ applications, and to field devices. The routing protocol SHOULD also
+ support the bandwidth allocation for bulk transfers between the field
+ device and the handheld device of the wireless worker. The routing
+ protocol SHOULD support walking speeds for maintaining network
+ connectivity as the handheld device changes position in the wireless
+ network.
+
+ Some field devices will be mobile. These devices may be located on
+ moving parts such as rotating components, or they may be located on
+ vehicles such as cranes or fork lifts. The routing protocol SHOULD
+ support vehicular speeds of up to 35 kmph.
+
+10. Manageability Requirements
+
+ The process and control industry is manpower constrained. The aging
+ demographics of plant personnel are causing a looming manpower
+ problem for industry across many markets. The goal for the
+ industrial networks is to have the installation process not require
+ any new skills for the plant personnel. The person would install the
+ wireless sensor or wireless actuator the same way the wired sensor or
+ wired actuator is installed, except the step to connect wire is
+ eliminated.
+
+
+
+
+Pister, et al. Informational [Page 21]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ Most users in fact demand even much further simplified provisioning
+ methods, a plug and play operation that would be fully transparent to
+ the user. This requires availability of open and untrusted side
+ channels for new joiners, and it requires strong and automated
+ authentication so that networks can automatically accept or reject
+ new joiners. Ideally, for a user, adding new routing devices should
+ be as easy as dragging and dropping an icon from a pool of
+ authenticated new joiners into a pool for the wired domain that this
+ new sensor should connect to. Under the hood, invisible to the user,
+ auditable security mechanisms should take care of new device
+ authentication, and secret join key distribution. These more
+ sophisticated 'over the air' secure provisioning methods should
+ eliminate the use of traditional configuration tools for setting up
+ devices prior to being ready to securely join an LLN access point.
+
+ The routing protocol SHOULD be fully configurable over the air as
+ part of the joining process of a new routing device.
+
+ There will be many new applications where even without any human
+ intervention at the plant, devices that have never been on site
+ before, should be allowed, based on their credentials and
+ cryptographic capabilities, to connect anyway. Examples are third-
+ party road tankers, rail cargo containers with overfill protection
+ sensors, or consumer cars that need to be refueled with hydrogen by
+ robots at future fueling stations.
+
+ The routing protocol for LLNs is expected to be easy to deploy and
+ manage. Because the number of field devices in a network is large,
+ provisioning the devices manually may not make sense. The proper
+ operation of the routing protocol MAY require that the node be
+ commissioned with information about itself, like identity, security
+ tokens, radio standards and frequencies, etc.
+
+ The routing protocol SHOULD NOT require to preprovision information
+ about the environment where the node will be deployed. The routing
+ protocol MUST enable the full discovery and setup of the environment
+ (available links, selected peers, reachable network). The protocol
+ MUST enable the distribution of its own configuration to be performed
+ by some external mechanism from a centralized management controller.
+
+11. Antagonistic Requirements
+
+ This document contains a number of strongly required constraints on
+ the ROLL routing protocol. Some of those strong requirements might
+ appear antagonistic and, as such, impossible to fulfill at the same
+ time.
+
+
+
+
+
+Pister, et al. Informational [Page 22]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ For instance, the strong requirement of power economy applies on
+ general routing but is variant since it is reasonable to spend more
+ energy on ensuring the availability of a short emergency closed-loop
+ path than it is to maintain an alert path that is used for regular
+ updates on the operating status of the device. In the same fashion,
+ the strong requirement on easy provisioning does not match easily the
+ strong security requirements that can be needed to implement a
+ factory policy. Then again, a non-default non-trivial setup can be
+ acceptable as long as the default configuration enables a device to
+ join with some degree of security.
+
+ Convergence time and network size are also antagonistic. The values
+ expressed in Section 8 ("Protocol Performance Requirements") apply to
+ an average network with tens of devices. The use of a backbone can
+ maintain that level of performance and still enable to grow the
+ network to thousands of node. In any case, it is acceptable to grow
+ reasonably the convergence time with the network size.
+
+12. Security Considerations
+
+ Given that wireless sensor networks in industrial automation operate
+ in systems that have substantial financial and human safety
+ implications, security is of considerable concern. Levels of
+ security violation that are tolerated as a "cost of doing business"
+ in the banking industry are not acceptable when in some cases
+ literally thousands of lives may be at risk.
+
+ Security is easily confused with guarantee for availability. When
+ discussing wireless security, it's important to distinguish clearly
+ between the risks of temporarily losing connectivity, say due to a
+ thunderstorm, and the risks associated with knowledgeable adversaries
+ attacking a wireless system. The conscious attacks need to be split
+ between 1) attacks on the actual application served by the wireless
+ devices and 2) attacks that exploit the presence of a wireless access
+ point that may provide connectivity onto legacy wired plant networks,
+ so these are attacks that have little to do with the wireless devices
+ in the LLNs. In the second type of attack, access points that might
+ be wireless backdoors that allow an attacker outside the fence to
+ access typically non-secured process control and/or office networks
+ are typically the ones that do create exposures where lives are at
+ risk. This implies that the LLN access point on its own must possess
+ functionality that guarantees domain segregation, and thus prohibits
+ many types of traffic further upstream.
+
+ The current generation of industrial wireless device manufacturers is
+ specifying security at the MAC (Media Access Control) layer and the
+ transport layer. A shared key is used to authenticate messages at
+ the MAC layer. At the transport layer, commands are encrypted with
+
+
+
+Pister, et al. Informational [Page 23]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ statistically unique randomly generated end-to-end session keys.
+ HART7 [IEC62591] and ISA100.11a are examples of security systems for
+ industrial wireless networks.
+
+ Although such symmetric key encryption and authentication mechanisms
+ at MAC and transport layers may protect reasonably well during the
+ lifecycle, the initial network boot (provisioning) step in many cases
+ requires more sophisticated steps to securely land the initial secret
+ keys in field devices. Also, it is vital that during these steps,
+ the ease of deployment and the freedom of mixing and matching
+ products from different suppliers does not complicate life for those
+ that deploy and commission. Given the average skill levels in the
+ field and the serious resource constraints in the market, investing a
+ little bit more in sensor-node hardware and software so that new
+ devices automatically can be deemed trustworthy, and thus
+ automatically join the domains that they should join, with just one
+ drag-and-drop action for those in charge of deploying, will yield
+ faster adoption and proliferation of the LLN technology.
+
+ Industrial plants may not maintain the same level of physical
+ security for field devices that is associated with traditional
+ network sites such as locked IT centers. In industrial plants, it
+ must be assumed that the field devices have marginal physical
+ security and might be compromised. The routing protocol SHOULD limit
+ the risk incurred by one node being compromised, for instance by
+ proposing a non-congruent path for a given route and balancing the
+ traffic across the network.
+
+ The routing protocol SHOULD compartmentalize the trust placed in
+ field devices so that a compromised field device does not destroy the
+ security of the whole network. The routing MUST be configured and
+ managed using secure messages and protocols that prevent outsider
+ attacks and limit insider attacks from field devices installed in
+ insecure locations in the plant.
+
+ The wireless environment typically forces the abandonment of
+ classical 'by perimeter' thinking when trying to secure network
+ domains. Wireless nodes in LLN networks should thus be regarded as
+ little islands with trusted kernels, situated in an ocean of
+ untrusted connectivity, an ocean that might be full of pirate ships.
+ Consequently, confidence in node identity and ability to challenge
+ authenticity of source node credentials gets more relevant.
+ Cryptographic boundaries inside devices that clearly demark the
+ border between trusted and untrusted areas need to be drawn.
+ Protection against compromise of the cryptographic boundaries inside
+ the hardware of devices is outside of the scope of this document.
+
+
+
+
+
+Pister, et al. Informational [Page 24]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ Note that because nodes are usually expected to be capable of
+ routing, the end-node security requirements are usually a superset of
+ the router requirements, in order to prevent a end node from being
+ used to inject forged information into the network that could alter
+ the plant operations.
+
+ Additional details of security across all application scenarios are
+ provided in the ROLL security framework [ROLL-SEC-FMWK].
+ Implications of these security requirements for the routing protocol
+ itself are a topic for future work.
+
+13. Acknowledgements
+
+ Many thanks to Rick Enns, Alexander Chernoguzov, and Chol Su Kang for
+ their contributions.
+
+14. References
+
+14.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+14.2. Informative References
+
+ [HART] HART (Highway Addressable Remote Transducer)
+ Communication Foundation, "HART Communication
+ Protocol and Foundation - Home Page",
+ <http://www.hartcomm.org>.
+
+ [IEC61158] IEC, "Industrial communication networks - Fieldbus
+ specifications", IEC 61158 series.
+
+ [IEC62591] IEC, "Industrial communication networks - Wireless
+ communication network and communication profiles -
+ WirelessHART", IEC 62591.
+
+ [IEEE802.15.4] IEEE, "Telecommunications and information exchange
+ between systems -- Local and metropolitan area
+ networks -- Specific requirements Part 15.4:
+ Wireless Medium Access Control (MAC) and Physical
+ Layer (PHY) Specifications for Low-Rate Wireless
+ Personal Area Networks (WPANs)", IEEE 802.15.4,
+ 2006.
+
+
+
+
+
+
+
+Pister, et al. Informational [Page 25]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+ [ISA100.11a] ISA, "Wireless systems for industrial automation:
+ Process control and related applications",
+ ISA 100.11a, May 2008, <http://www.isa.org/
+ Community/SP100WirelessSystemsforAutomation>.
+
+ [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher,
+ "IPv6 over Low-Power Wireless Personal Area Networks
+ (6LoWPANs): Overview, Assumptions, Problem
+ Statement, and Goals", RFC 4919, August 2007.
+
+ [ROLL-SEC-FMWK] Tsao, T., Alexander, R., Dohler, M., Daza, V., and
+ A. Lozano, "A Security Framework for Routing over
+ Low Power and Lossy Networks", Work in Progress,
+ September 2009.
+
+ [ROLL-TERM] Vasseur, JP., "Terminology in Low power And Lossy
+ Networks", Work in Progress, October 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pister, et al. Informational [Page 26]
+
+RFC 5673 Industrial Routing Reqs in LLNs October 2009
+
+
+Authors' Addresses
+
+ Kris Pister (editor)
+ Dust Networks
+ 30695 Huntwood Ave.
+ Hayward, CA 94544
+ USA
+
+ EMail: kpister@dustnetworks.com
+
+
+ Pascal Thubert (editor)
+ 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
+
+
+ Sicco Dwars
+ Shell Global Solutions International B.V.
+ Sir Winston Churchilllaan 299
+ Rijswijk 2288 DC
+ Netherlands
+
+ Phone: +31 70 447 2660
+ EMail: sicco.dwars@shell.com
+
+
+ Tom Phinney
+ Consultant
+ 5012 W. Torrey Pines Circle
+ Glendale, AZ 85308-3221
+ USA
+
+ Phone: +1 602 938 3163
+ EMail: tom.phinney@cox.net
+
+
+
+
+
+
+
+
+
+
+Pister, et al. Informational [Page 27]
+