--- 1/draft-ietf-roll-indus-routing-reqs-04.txt 2009-04-21 10:12:05.000000000 +0200 +++ 2/draft-ietf-roll-indus-routing-reqs-05.txt 2009-04-21 10:12:05.000000000 +0200 @@ -1,22 +1,22 @@ Networking Working Group K. Pister, Ed. Internet-Draft Dust Networks Intended status: Informational P. Thubert, Ed. -Expires: July 26, 2009 Cisco Systems +Expires: October 22, 2009 Cisco Systems S. Dwars Shell T. Phinney - January 22, 2009 + April 20, 2009 Industrial Routing Requirements in Low Power and Lossy Networks - draft-ietf-roll-indus-routing-reqs-04 + draft-ietf-roll-indus-routing-reqs-05 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -25,101 +25,133 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 26, 2009. + This Internet-Draft will expire on October 22, 2009. 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. + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract - 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 by extending the information set available from - wired systems. In an industrial environment, low power, high - reliability, and easy installation and maintenance are mandatory - qualities for wireless devices. The aim of this document is to - analyze the requirements for the routing protocol used for Low power - and Lossy Networks (LLN) in industrial environments. + The wide deployment of lower cost wireless devices will significantly + improve the productivity and safety of the plants while increasing + the efficiency of the 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 (LLN) of field devices. 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]. Table of Contents - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 - 2.2. Network Topology of Industrial Applications . . . . . . . 9 - 2.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10 - 2.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 12 - 3. Traffic Characteristics . . . . . . . . . . . . . . . . . . . 13 - 3.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 14 - 3.2. Configurable Application Requirement . . . . . . . . . . . 15 - 3.3. Different Routes for Different Flows . . . . . . . . . . . 15 - 4. Reliability Requirements . . . . . . . . . . . . . . . . . . . 15 - 5. Device-Aware Routing Requirements . . . . . . . . . . . . . . 17 - 6. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 18 - 7. Route Establishment Time . . . . . . . . . . . . . . . . . . . 19 - 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 - 13.3. External Informative References . . . . . . . . . . . . . 23 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 + 3.2. Network Topology of Industrial Applications . . . . . . . 8 + 3.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10 + 3.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 12 + 4. Traffic Characteristics . . . . . . . . . . . . . . . . . . . 13 + 4.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 14 + 4.2. Configurable Application Requirement . . . . . . . . . . . 15 + 4.3. Different Routes for Different Flows . . . . . . . . . . . 15 + 5. Reliability Requirements . . . . . . . . . . . . . . . . . . . 15 + 6. Device-Aware Routing Requirements . . . . . . . . . . . . . . 17 + 7. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 18 + 8. Route Establishment Time . . . . . . . . . . . . . . . . . . . 19 + 9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 14.2. Informative References . . . . . . . . . . . . . . . . . . 24 + 14.3. External Informative References . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 -1. Terminology +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 change 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 which + result from that reuse. + + Following that logic, many vendors are already extending or replacing + their local field-bus technology with Ethernet and IP-based + solutions. Examples of this evolution include CIP EtherNet/IP, + Modbus/TCP, Foundation Fieldbus HSE, PROFInet and Invensys/Foxboro + FOXnet. At the same time, wireless, low power field devices are + being introduced that facilitate a significant increase in the amount + of information which industrial users can collect and the number of + control points that can be remotely managed. + + IPv6 appears as a core technology at the conjunction of both trends, + as illustrated by the current [ISA100.11a] industrial Wireless Sensor + Networking (WSN) specification, where layers 1-4 technologies + developed for purposes other than industrial CT -- IEEE 802.15.4 PHY + and MAC, 6LoWPAN and IPv6, and UDP - are adapted to industrial CT + use. But due to the lack of open standards for routing in Low power + and Lossy Networks (LLN), even ISA100.11a leaves the routing + operation to proprietary methods. + + The aim of this document is to analyze the requirements from the + industrial environment for a routing protocol in Low power and Lossy + Networks (LLN) based on IP version 6 to power the next generation of + Control Technology. + +2. Terminology This document employes terminology defined in the ROLL terminology document [I-D.ietf-roll-terminology]. 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 Foundation (see [HART]). The latest version for the specifications is HART7 which includes the additions for WirelessHART. ISA: "International Society of Automation". ISA is 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. -2. Introduction +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 is being more and more present in standards and products under development and early deployments. @@ -175,21 +207,21 @@ 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 1,200 baud (e.g. wired HART) to the one to two hundred Kbps range for most of the others. The existing protocols are often master/slave with command/ response. -2.1. Applications and Traffic Patterns +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 o Control @@ -326,24 +357,24 @@ 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 mean-time between shutdowns target of 30 years, the latency requirement implies nine 9s of 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 to not aim for fast closed loop + architectures, most users tend not to aim for fast closed loop control with wireless links within that fast loop. -2.2. Network Topology of Industrial Applications +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 maximum number of hops of twenty. 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 @@ -416,70 +447,87 @@ trust established by the gateways in the authenticity of message originators. 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. -2.2.1. The Physical Topology +3.2.1. The Physical Topology There is no specific physical topology for an industrial process - control network. 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 one or two hops. The backbone is - in the refinery proper, many hops away. Even there, powered - infrastructure is also typically several hops away. So hopping to/ - from the powered infrastructure will in general be more costly than - the direct route. + control network. + + 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 one or two 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 router. Most communication between field devices and infrastructure devices as well as field device to field device occurs across the - backbone. Form afar, this model resembles the WIFI ESS (Extended + backbone. From afar, this model resembles the WIFI ESS (Extended Service Set). But from a layer 3 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 - | | + | | 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 -2.2.2. Logical Topologies + 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 end point 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 devices that sits on the backbone and is reachable via one or more backbone router. 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 @@ -521,24 +569,27 @@ of the routes might range from minutes for a mobile workers 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. -3. Traffic Characteristics +4. Traffic Characteristics - The industrial applications fall into four large service categories - [ISA100.11a]: + [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 @@ -555,25 +606,24 @@ 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 period of time (related to - file size and data rate) to meet the bulk transfers service - requirements. + resources are assigned for a limited time (related to file size + and data rate) to meet the bulk transfers service requirements. -3.1. Service Parameters +4.1. Service Parameters 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. @@ -598,61 +648,70 @@ 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 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). + 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 field device to field device connectivity as well as for some field device to Infrastructure devices 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. -3.2. Configurable Application Requirement + 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 an 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 route on paths that are changed to appropriately provision the application requirements. The routing protocol MUST support the ability to recompute paths based on Network Layer abstractions of the underlying link attributes/metric that may change dynamically. -3.3. Different Routes for Different Flows +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 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 characteritics (e.g. Optimized according to different cost, etc...). -4. Reliability Requirements +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 succeses / number of attempts 2) Availability of source to destination connectivity when the application might need it, expressed in number of potential failures / available bandwidth, @@ -653,48 +712,49 @@ application needs it, expressed in number of succeses / 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, + 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) ... + 6) and others depending on the specific case... This makes quantifying reliability the equivalent of plotting it on a three plus dimensional graph. Different applications have different requirements, and expressing reliability as a one dimensional parameter, like 'reliability my wireless network is 99.9%' is often creating 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 shut down 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, 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, so white noise, or - from occasional bursty interference sources like thunderstorms or + 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 maintainance. The maximum disruption time is the time it takes at most for a specific path to be restored when broken. Route maintainance ensures that a path is monitored to be restored when broken within the maximum disruption time. Maintenance should also ensure that a path continues to provide the service for which it was established for instance in @@ -721,21 +781,21 @@ 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. -5. Device-Aware Routing 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 @@ -771,21 +831,21 @@ non-critical parameter in an easily accessed location may have a lifetime requirement that is shorter and 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. -6. Broadcast/Multicast +7. Broadcast/Multicast 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 @@ -815,21 +875,21 @@ 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 broadcast or multicast addressing. -7. Route Establishment Time +8. Route Establishment Time During network formation, installers with no networking skill must be able to determine if their devices are "in the network" with sufficient connectivity to perform their function. Installers will have sufficient skill to provision the devices with a sample rate or activity profile. The routing algorithm MUST find the appropriate route(s) and report success or failure within several minutes, and SHOULD report success or failure within tens of seconds. Network connectivity in real deployments is always time varying, with @@ -838,59 +898,59 @@ substantially affect network operation. The routing algorithm MUST respond to normal link failure rates with routes that meet the Service requirements (especially latency) throughout the routing response. The routing algorithm SHOULD always be in the process of recalculating the route in response to changing link statistics. The routing algorithm MUST recalculate the paths when field devices change due to insertion, removal or failure, and this recalculation MUST NOT cause latencies greater than the specified constraints (typically seconds to minutes). -8. Mobility +9. Mobility Various economic factors have contributed to a reduction of trained workers in the plant. The industry as a whole appears to be trying to solve this problem with what is called 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. - Undecided yet is if these PDAs will use the LLN network directly to - talk to field sensors, or if they will rather use other wireless - connectivity that proxys back into the field, or to anywhere else, - the user interfaces typically used for plant historians, asset - management systems, and the likes. + PDAs are typically used as the user interfaces for plant historians, + asset management systems, and the likes. Undecided yet is if these + PDAs will use the LLN network directly to talk to field sensors, or + if they will rather use other wireless connectivity that proxys 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. -9. Manageability +10. Manageability 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. @@ -923,32 +983,32 @@ MAY require commissioning of information about the node 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 also MUST support the distribution of configuration from a centralized management controller if operator-initiated configuration change is allowed. -10. Security +11. Security 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 temporary losing connectivity, say due to a + 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 attacks that have little to do with the wireless devices in the LLNs. The second type of attack, access points that might be wireless backdoors that may 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 @@ -987,56 +1047,72 @@ proposing 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. - Wireless typically forces abandonance 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 this document. + 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 this document. -11. IANA Considerations + 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 + [I-D.tsao-roll-security-framework]. + +12. IANA Considerations This document includes no request to IANA. -12. Acknowledgements +13. Acknowledgements Many thanks to Rick Enns, Alexander Chernoguzov and Chol Su Kang for their contributions. -13. References +14. References -13.1. Normative References +14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. -13.2. Informative References +14.2. Informative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-00 (work in progress), October 2008. -13.3. External Informative References + [I-D.tsao-roll-security-framework] + Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. + Lozano, "A Security Framework for Routing over Low Power + and Lossy Networks", draft-tsao-roll-security-framework-00 + (work in progress), February 2009. + +14.3. External Informative References [HART] www.hartcomm.org, "Highway Addressable Remote Transducer", a group of specifications for industrial process and control devices administered by the HART Foundation". [ISA100.11a] ISA, "ISA100, Wireless Systems for Automation", May 2008, < http://www.isa.org/Community/ SP100WirelessSystemsforAutomation>.