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
AbstractThe 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.
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
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. RFC2119].
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.
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.
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
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.
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
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.
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.
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
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.
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. 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.
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.
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).
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.
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
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.
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.
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. 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.
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.
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.
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.
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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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.
[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.