| < draft-pister-roll-indus-routing-reqs-00.txt | draft-pister-roll-indus-routing-reqs-01.txt > | |||
|---|---|---|---|---|
| Networking Working Group K. Pister | Networking Working Group K. Pister | |||
| Internet-Draft R. Enns | Internet-Draft Dust Networks | |||
| Intended status: Informational Dust Networks | Intended status: Informational P. Thubert | |||
| Expires: September 29, 2008 P. Thubert | Expires: October 24, 2008 Cisco Systems, Inc | |||
| Cisco Systems, Inc | April 22, 2008 | |||
| March 28, 2008 | ||||
| Industrial Routing Requirements in Low Power and Lossy Networks | Industrial Routing Requirements in Low Power and Lossy Networks | |||
| draft-pister-roll-indus-routing-reqs-00 | draft-pister-roll-indus-routing-reqs-01 | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 35 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on September 29, 2008. | This Internet-Draft will expire on October 24, 2008. | |||
| Abstract | Abstract | |||
| Wireless, low power field devices enable industrial users to | Wireless, low power field devices enable industrial users to | |||
| significantly increase the amount of information collected and the | significantly increase the amount of information collected and the | |||
| number of control points that can be remotely managed. The | number of control points that can be remotely managed. The | |||
| deployment of these wireless devices will significantly improve the | deployment of these wireless devices will significantly improve the | |||
| productivity and safety of the plants while increasing the efficiency | productivity and safety of the plants while increasing the efficiency | |||
| of the plant workers. For wireless devices to have a significant | of the plant workers. For wireless devices to have a significant | |||
| advantage over wired devices in an industrial environment the | advantage over wired devices in an industrial environment the | |||
| skipping to change at page 2, line 15 ¶ | skipping to change at page 2, line 14 ¶ | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| Table of Contents | Table of Contents | |||
| 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 | 2.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 | |||
| 3. Quality of Service (QoS) Routing requirements . . . . . . . . 7 | 2.2. Network Topology of Industrial Applications . . . . . . . 6 | |||
| 3.1. Configurable Application Requirement . . . . . . . . . . . 9 | 2.2.1. The Physical Topology . . . . . . . . . . . . . . . . 7 | |||
| 4. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 | 3. Service Requirements . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5. Device-Aware Routing Requirements . . . . . . . . . . . . . . 10 | 3.1. Configurable Application Requirement . . . . . . . . . . . 10 | |||
| 6. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 11 | 3.2. Different Routes for Different Flows . . . . . . . . . . . 11 | |||
| 7. Route Establishment Time . . . . . . . . . . . . . . . . . . . 11 | 4. Reliability Requirements . . . . . . . . . . . . . . . . . . . 11 | |||
| 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5. Device-Aware Routing Requirements . . . . . . . . . . . . . . 12 | |||
| 9. Manageability and Ease Of Use . . . . . . . . . . . . . . . . 12 | 6. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. Route Establishment Time . . . . . . . . . . . . . . . . . . . 13 | |||
| 11. Informative Reference . . . . . . . . . . . . . . . . . . . . 13 | 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 9. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 14.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 14.2. Informative References . . . . . . . . . . . . . . . . . . 13 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 15 | 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 | |||
| 13.3. External Informative References . . . . . . . . . . . . . 16 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
| Intellectual Property and Copyright Statements . . . . . . . . . . 17 | ||||
| 1. Terminology | 1. Terminology | |||
| Access Point: The access point is an infrastructure device that | ||||
| connects the low power and lossy network system to a plant's backbone | ||||
| network. | ||||
| Actuator: a field device that moves or controls plant equipment. | Actuator: a field device that moves or controls plant equipment. | |||
| Channel Hopping: An algorithm by which field devices synchronously | Closed Loop Control: A process whereby a device controller controls | |||
| change channels during operation. | an actuator based on information sensed by one or more field devices. | |||
| Channel: RF frequency band used to transmit a modulated signal | ||||
| carrying packets. | ||||
| Closed Loop Control: A process whereby a host application controls an | ||||
| actuator based on information sensed by field devices. | ||||
| Downstream: Data direction traveling from the host application to the | Downstream: Data direction traveling from the plant application to | |||
| field device. | the field device. | |||
| Field Device: physical devices placed in the plant's operating | Field Device: physical devices placed in the plant's operating | |||
| environment (both RF and environmental). Field devices include | environment (both RF and environmental). Field devices include | |||
| sensors and actuators as well as network routing devices and access | sensors and actuators as well as network routing devices and L2N | |||
| points in the plant. Superframe: A collection of timeslots repeating | access points in the plant. | |||
| at a constant rate. | ||||
| HART: "Highway Addressable Remote Transducer", a group of | HART: "Highway Addressable Remote Transducer", a group of | |||
| specifications for industrial process and control devices | specifications for industrial process and control devices | |||
| administered by the HART Foundation (see [HART]). The latest version | administered by the HART Foundation (see [HART]). The latest version | |||
| for the specifications is HART7 which includes the additions for | for the specifications is HART7 which includes the additions for | |||
| WirelessHART. | WirelessHART. | |||
| Host Application: The host application is a process running in the | ||||
| plant that communicates with field devices to perform tasks on that | ||||
| may include control, monitoring and data gathering. | ||||
| ISA: "International Society of Automation". ISA is an ANSI | ISA: "International Society of Automation". ISA is an ANSI | |||
| accredited standards making society. ISA100 is an ISA working group | accredited standards-making society. ISA100 is an ISA working group | |||
| whose charter includes defining a family of standards for industrial | whose charter includes defining a family of standards for industrial | |||
| automation. ISA100.11a is a work group within ISA100 that is working | automation. ISA100.11a is a work group within ISA100 that is working | |||
| on a standard for non-critical process and control applications. | on a standard for non-critical process and control applications. | |||
| L2N: Low Power and Lossy Network Slotted-Link: a data structure that | L2N Access Point: The L2N access point is an infrastructure device | |||
| is associated with a superframe that contains a connection between | that connects the low power and lossy network system to a plant's | |||
| field devices that comprises a timeslot assignment, and channel and | backbone network. | |||
| usage information. | ||||
| Open Loop Control: A process whereby a plant technician controls an | Open Loop Control: A process whereby a plant technician controls an | |||
| actuator over the network where the decision is influenced by | actuator over the network where the decision is influenced by | |||
| information sensed by field devices. | information sensed by field devices. | |||
| Timeslot: A fixed time interval that may be used for the transmission | Plant Application: The plant application is a process running in the | |||
| or reception of a packet between two field devices. A timeslot used | plant that communicates with field devices to perform tasks on that | |||
| for communications is associated with a slotted-link. Upstream: Data | may include control, monitoring and data gathering. | |||
| direction traveling from the field device to the host application. | ||||
| RF: Radio Frequency Sensor: A field device that measures data and/or | Upstream: Data direction traveling from the field device to the plant | |||
| detects an event. | application. | |||
| RL2N: Routing in Low power and Lossy Networks | RL2N: Routing in Low power and Lossy Networks. | |||
| 2. Introduction | 2. Introduction | |||
| Wireless, low power field devices enable industrial users to | Wireless, low-power field devices enable industrial users to | |||
| significantly increase the amount of information collected and the | significantly increase the amount of information collected and the | |||
| number of control points that can be remotely managed. The | number of control points that can be remotely managed. The | |||
| deployment of these wireless devices will significantly improve the | deployment of these wireless devices will significantly improve the | |||
| productivity and safety of the plants while increasing the efficiency | productivity and safety of the plants while increasing the efficiency | |||
| of the plant workers. | of the plant workers. | |||
| Wireless field devices enable expansion of networked points by | Wireless field devices enable expansion of networked points by | |||
| appreciably reducing cost of installing a device. The cost | appreciably reducing cost of installing a device. The cost | |||
| reductions come from eliminating cabling costs and simplified | reductions come from eliminating cabling costs and simplified | |||
| planning. Cabling for a field device can run from $100s/ft to | planning. Cabling for a field device can run from $100s/ft to | |||
| $1,000s/ft. depending on the safety regulations of the plant. | $1,000s/ft depending on the safety regulations of the plant. Cabling | |||
| Cabling also caries an overhead cost associated with planning the | also carries an overhead cost associated with planning the | |||
| installation, where the cable has to run, and the various | installation, determining where the cable has to run, and interfacing | |||
| organizations that have to coordinate its deployment. Doing away | with the various organizations required to coordinate its deployment. | |||
| with the network and power cables reduces the planning and | Doing away with the network and power cables reduces the planning and | |||
| administrative overhead of installing a device. | administrative overhead of installing a device. | |||
| For wireless devices to have a significant advantage over wired | For wireless devices to have a significant advantage over wired | |||
| devices in an industrial environment the wireless network needs to | devices in an industrial environment, the wireless network needs to | |||
| have three qualities: low power, high reliability, and easy | have three qualities: low power, high reliability, and easy | |||
| installation and maintenance. The routing protocol used for low | installation and maintenance. The routing protocol used for low | |||
| power and lossy networks (L2N) is important to fulfilling these | power and lossy networks (L2N) is important to fulfilling these | |||
| goals. | goals. | |||
| Industrial automation is segmented into two distinct application | Industrial automation is segmented into two distinct application | |||
| spaces, known as "process" or "process control" and "discrete | spaces, known as "process" or "process control" and "discrete | |||
| manufacturing" or "factory automation". In industrial process | manufacturing" or "factory automation". In industrial process | |||
| control, the product is typically a fluid (oil, gas, chemicals ...). | control, the product is typically a fluid (oil, gas, chemicals ...). | |||
| In factory automation or discrete manufacturing, the products are | In factory automation or discrete manufacturing, the products are | |||
| individual elements (screws, cars, dolls). While there is some | individual elements (screws, cars, dolls). While there is some | |||
| overlap between products and systems between these two segments, they | overlap of products and systems between these two segments, they are | |||
| are surprisingly separate communities. The specifications targeting | surprisingly separate communities. The specifications targeting | |||
| industrial process control tend to have more tolerance for network | industrial process control tend to have more tolerance for network | |||
| latency than what is needed for factory automation. | latency than what is needed for factory automation. | |||
| Both application spaces desire battery operated networks of hundreds | Both application spaces desire battery operated networks of hundreds | |||
| of sensors and actuators communicating with wired access points. In | of sensors and actuators communicating with L2N access points. In an | |||
| an oil refinery, the total number of devices is likely to exceed one | oil refinery, the total number of devices is likely to exceed one | |||
| million, but the devices will be clustered into smaller networks | million, but the devices will be clustered into smaller networks that | |||
| reporting to existing wired infrastructure. | report to an existing plant network infrastructure. | |||
| Existing wired sensor networks in this space typically use | Existing wired sensor networks in this space typically use | |||
| communication protocols with low data rates - from 1,200 baud (wired | communication protocols with low data rates, from 1,200 baud (e.g. | |||
| HART) into the one to two hundred kbps range for most of the others. | wired HART) to the one to two hundred Kbps range for most of the | |||
| The existing protocols are often master/slave with command/response. | others. The existing protocols are often master/slave with command/ | |||
| response. | ||||
| Note that the total low power and lossy network system capacity for | ||||
| devices using the IEEE802.15.4-2006 2.4 GHz radio is at most 1.6 Mbps | ||||
| when spatial reuse of channels is not utilized. | ||||
| 2.1. Applications and Traffic Patterns | 2.1. Applications and Traffic Patterns | |||
| The industrial market classifies process applications into three | The industrial market classifies process applications into three | |||
| broad categories and six classes. | broad categories and six classes. | |||
| o Safety | o Safety | |||
| * Class 0: Emergency action - Always a critical function Control | * Class 0: Emergency action - Always a critical function | |||
| o Control | ||||
| * Class 1: Closed loop regulatory control - Often a critical | * Class 1: Closed loop regulatory control - Often a critical | |||
| function | function | |||
| * Class 2: Closed loop supervisory control - Usually non-critical | * Class 2: Closed loop supervisory control - Usually non-critical | |||
| function | function | |||
| * Class 3: Open loop control - Operator takes action and controls | * Class 3: Open loop control - Operator takes action and controls | |||
| the actuator (human in the loop) | the actuator (human in the loop) | |||
| o Monitoring | o Monitoring | |||
| * Class 4: Alerting - Short-term operational effect (for example | * Class 4: Alerting - Short-term operational effect (for example | |||
| event-based maintenance) | event-based maintenance) | |||
| * Class 5: Logging and downloading / uploading - No immediate | * Class 5: Logging and downloading / uploading - No immediate | |||
| operational consequence (e.g., history collection, sequence-of- | operational consequence (e.g., history collection, sequence-of- | |||
| events, preventive maintenance) | events, preventive maintenance) | |||
| Critical functions are effect the basic safety or integrity of the | Critical functions effect the basic safety or integrity of the plant. | |||
| plant. Timely deliveries of messages are more important as class | Timely deliveries of messages becomes more important as the class | |||
| numbers decrease. | number decreases. | |||
| Industrial customers are interested in deploying wireless networks | Industrial users are interested in deploying wireless networks for | |||
| for the monitoring classes 4 and 5 and in the non-critical portions | the monitoring classes 4 and 5, and in the non-critical portions of | |||
| of classes 3 through 1. | classes 3 through 1. | |||
| Classes 4 and 5 also include equipment monitoring which is strictly | Classes 4 and 5 also include asset monitoring and tracking which | |||
| speaking separate from process monitoring. An example of equipment | include equipment monitoring and are essentially separate from | |||
| monitoring is the recording of motor vibrations to detect bearing | process monitoring. An example of equipment monitoring is the | |||
| wear. | recording of motor vibrations to detect bearing wear. | |||
| Most low power and lossy network systems in the near future will be | In the near future, most low power and lossy network systems will be | |||
| for low frequency data collection. Packets containing samples will | for low frequency data collection. Packets containing samples will | |||
| be generated continuously, and 90% of the market is covered by packet | be generated continuously, and 90% of the market is covered by packet | |||
| rates of between 1/s and 1/hour, with the average under 1/min. In | rates of between 1/s and 1/hour, with the average under 1/min. In | |||
| industrial process these sensors include temperature, pressure, fluid | industrial process, these sensors include temperature, pressure, | |||
| flow, tank level, and corrosion. There are some sensors which are | fluid flow, tank level, and corrosion. Some sensors are bursty, such | |||
| bursty, such as vibration monitors which may generate and transmit | as vibration monitors that may generate and transmit tens of kilo- | |||
| tens of kilo-bytes (hundreds to thousands of packets) of time-series | bytes (hundreds to thousands of packets) of time-series data at | |||
| data at reporting rates of minutes to days. | reporting rates of minutes to days. | |||
| Almost all of these sensors will have built-in microprocessors which | Almost all of these sensors will have built-in microprocessors that | |||
| may detect alarm conditions. Time crucial alarm packets are expected | may detect alarm conditions. Time-critical alarm packets are | |||
| to have lower latency than sensor data, often requiring substantially | expected to have lower latency than sensor data. | |||
| more bandwidth. | ||||
| Some devices will transmit a log file every day, again with typically | Some devices will transmit a log file every day, again with typically | |||
| tens of Kbytes of data. For these applications there is very little | tens of Kbytes of data. For these applications there is very little | |||
| "downstream" traffic coming from the access point and traveling to | "downstream" traffic coming from the L2N access point and traveling | |||
| particular sensors. During diagnostics, however, a technician may be | to particular sensors. During diagnostics, however, a technician may | |||
| investigating a fault from a control room and expect to have "low" | be investigating a fault from a control room and expect to have "low" | |||
| latency (human tolerable) in a command/response mode. | latency (human tolerable) in a command/response mode. | |||
| Low-rate control, often with a "human in the loop" or "open loop" is | Low-rate control, often with a "human in the loop" (also referred to | |||
| implemented today via communication to a centralized controller, i.e. | as "open loop"), is implemented today via communication to a | |||
| sensor data makes its way through the access point to the centralized | centralized controller. The sensor data makes its way through the | |||
| controller where it is processed, the operator sees the information | L2N access point to the centralized controller where it is processed, | |||
| and takes action, and control information is sent out to the actuator | the operator sees the information and takes action, and the control | |||
| node in the network. | 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 | In the future, it is envisioned that some open loop processes will be | |||
| automated (closed loop) and packets will flow over local loops and | automated (closed loop) and packets will flow over local loops and | |||
| not involve the access point. These closed loop controls for non- | not involve the L2N access point. These closed loop controls for | |||
| critical applications will be implemented on L2Ns. Non-critical | non-critical applications will be implemented on L2Ns. Non-critical | |||
| closed loop applications have a latency requirement that can be as | closed loop applications have a latency requirement that can be as | |||
| low as 100 ms but many control loops are tolerant of latencies above | low as 100 ms but many control loops are tolerant of latencies above | |||
| 1 s. | 1 s. | |||
| In critical control, 10's of milliseconds of latencies are typical. | In critical control, tens of milliseconds of latency is typical. In | |||
| In many of these systems, if a packet does not arrive within the | many of these systems, if a packet does not arrive within the | |||
| specified interval, the system will enter an emergency shutdown | specified interval, the system enters an emergency shutdown state, | |||
| state, often with substantial financial repercussions. For a 1 | often with substantial financial repercussions. For a one-second | |||
| second control loop in a system with a mean-time between shutdowns | control loop in a system with a mean-time between shutdowns target of | |||
| target of 30 years, the latency requirement implies nine 9s of | 30 years, the latency requirement implies nine 9s of reliability. | |||
| reliability. | ||||
| Thus, the routing protocol for L2Ns MUST support multi-topology | 2.2. Network Topology of Industrial Applications | |||
| routing (e.g especially critical for critical control applications). | ||||
| The routing protocol MUST provide the ability to color slotted-links | ||||
| (where the color corresponds to a user defined slotted-link | ||||
| attribute) and can be used to include/exclude slotted-links from a | ||||
| logical topology. | ||||
| For all but the most latency-tolerant applications, route discovery | Although network topology is difficult to generalize, the majority of | |||
| is likely to be too slow a process to initiate when a route failure | existing applications can be met by networks of 10 to 200 field | |||
| is detected. | devices and maximum number of hops from two to 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. | ||||
| The routing protocol MUST support multiple paths (a tree-based | For most industrial applications, a manager, gateway or backbone | |||
| solution is not sufficient). | router acts as a sink for the wireless sensor network. The vast | |||
| majority of the traffic is real time publish/subscribe sensor data | ||||
| from the field devices over a L2N 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. | ||||
| 3. Quality of Service (QoS) Routing requirements | The wireless sensor network is a Low Power and Lossy Network 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 change over | ||||
| time to balance the cost of the forwarding operation amongst the | ||||
| nodes. | ||||
| The industrial applications fall into four large service categories: | The backbone is a high speed network that interconnects 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 always become an important function of the industrial | ||||
| network. The Internet at large is not considered as a viable option | ||||
| to perform the backbone function. | ||||
| 1. Published data. Data that is generated per periodically and has | A plant or corporate network is also present on the factory site. | |||
| a well understood data bandwidth requirement. The end-to-end | This is the typical IT nework for the factory operations beyond | |||
| latency of this data is not as important as regularity with which | process control. That network is out of scope for this document. | |||
| it is presented to the host application. | ||||
| 2.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. | ||||
| 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 | ||||
| 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 | ||||
| | | | ||||
| +-----+ | ||||
| | | ||||
| | 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 | ||||
| L2N | ||||
| Considering that though each field device to field device 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 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. | ||||
| For these reasons, the ROLL routing infrastructure MUST be able to | ||||
| compute and update constrained routes on demand (that is reactively), | ||||
| 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. | ||||
| 3. Service Requirements | ||||
| The industrial applications fall into four large service categories | ||||
| [ISA100.11a]: | ||||
| 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 | 2. Event data. This category includes alarms and aperiodic data | |||
| reports with bursty data bandwidth requirements | 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 | 3. Client/Server. Many industrial applications are based on a | |||
| client/server model and implement a command response protocol. | client/server model and implement a command response protocol. | |||
| The data bandwidth required is often bursty. The round trip | The data bandwidth required is often bursty. The acceptable | |||
| latency for some operations can be 200 ms. | 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 L2N and cost-based fair-share best-effort | ||||
| service is usually expected. | ||||
| 4. Bulk transfer. Bulk transfers involve the transmission of blocks | 4. Bulk transfer. Bulk transfers involve the transmission of blocks | |||
| of data in multiple packets where temporary resources are | of data in multiple packets where temporary resources are | |||
| assigned to meet a transaction time constraint. Bulk transfers | assigned to meet a transaction time constraint. Transient | |||
| assign resources for a limited period of time to meet the QoS | resources are assigned for a limited period of time (related to | |||
| file size and data rate) to meet the bulk transfers service | ||||
| requirements. | requirements. | |||
| For industrial applications QoS parameters include: | For industrial applications Service parameters include but might not | |||
| be limited to: | ||||
| o Data bandwidth - periodic, burst statistics | 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 | 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 | the source to the destination. This may be expressed in terms of | |||
| a deadline for delivery | a deadline for delivery. Most monitoring latencies will be in | |||
| seconds to minutes. | ||||
| o Transmission phase - process applications can be synchronized to | o Transmission phase - process applications can be synchronized to | |||
| wall clock time and require coordinated transmissions. A common | wall clock time and require coordinated transmissions. A common | |||
| coordination frequency is 4 Hz (250 ms). | coordination frequency is 4 Hz (250 ms). | |||
| o Reliability - the end-to-end data delivery statistic. All | o Service contract type - revocation priority. L2Ns have limited | |||
| applications have latency and reliability requirements. In | ||||
| industrial applications, these vary over many orders of magnitude. | ||||
| Some non-critical monitoring applications may tolerate latencies | ||||
| of days and reliability of less than 90%. Most monitoring | ||||
| latencies will be in seconds to minutes, and industrial standard | ||||
| such as HART7 has set user reliability 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 reliability requirements to higher then | ||||
| 99.9%. | ||||
| o QoS contract type - revocation priority. L2Ns have limited | ||||
| network resources that can vary with time. This means the system | network resources that can vary with time. This means the system | |||
| can become fully subscribed or even over subscribed. System | can become fully subscribed or even over subscribed. System | |||
| policies determine how resources are allocated when resources are | policies determine how resources are allocated when resources are | |||
| over subscribed. The choices are blocking and graceful | over subscribed. The choices are blocking and graceful | |||
| degradation. | degradation. | |||
| o Transmission Priority - within field devices there are limited | o Transmission priority - the means by which limited resources | |||
| resources need to be allocated across multiple services. For | within field devices are allocated across multiple services. For | |||
| transmissions, a device has to select which packet in its queue | transmissions, a device has to select which packet in its queue | |||
| will be sent at the next transmission opportunity. Packet | will be sent at the next transmission opportunity. Packet | |||
| priority is used as one criterion for selecting the next packet. | priority is used as one criterion for selecting the next packet. | |||
| For reception a device has to decide how to store a received | For reception, a device has to decide how to store a received | |||
| packet. The field devices are memory constrained and receive | packet. The field devices are memory constrained and receive | |||
| buffers may become full. Packet priority is used to select which | buffers may become full. Packet priority is used to select which | |||
| packets are stored or discarded. | packets are stored or discarded. | |||
| In industrial wireless L2Ns a time slotting technology is used. A | ||||
| time slotted media access protocol synchronizes channel hopping which | ||||
| is one of the means that is used to make the wireless network | ||||
| reliable. Timeslots also are employed to reduce the power by | ||||
| minimizing the active duty cycle for field devices. Communications | ||||
| between devices are assigned a combination of timeslot and channel | ||||
| assignment called a slotted-link. | ||||
| The routing protocol MUST also support different metric types for | The routing protocol MUST also support different metric types for | |||
| each slotted-link used to compute the path according to some | each link used to compute the path according to some objective | |||
| objective function (e.g. minimize latency, maximize reliability, | function (e.g. minimize latency). | |||
| ...). | ||||
| Industrial application data flows between field devices are not | Industrial application data flows between field devices are not | |||
| necessarily symmetric. The routing protocol MUST be able to set up | necessarily symmetric. In particular, asymmetrical cost and | |||
| routes that are directional. | 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 set up unidirectional or asymmetrical cost routes | ||||
| that are composed of one or more non congruent paths. | ||||
| 3.1. Configurable Application Requirement | 3.1. Configurable Application Requirement | |||
| Time-varying user requirements for latency and bandwidth will require | Time-varying user requirements for latency and bandwidth will require | |||
| changes in the provisioning of the underlying L2 protocols. The | changes in the provisioning of the underlying L2 protocols. A | |||
| wireless worker may initiate a bulk transfer to configure or diagnose | technician may initiate a query/response session or bulk transfer to | |||
| a field device. A level sensor device may need to perform a | diagnose or configure a field device. A level sensor device may need | |||
| calibration and send a bulk file to a host. The routing protocol | to perform a calibration and send a bulk file to a plant. The | |||
| MUST route on paths which are changed to appropriately provision the | routing protocol MUST route on paths that are changed to | |||
| application requirements. The routing protocol MUST support the | appropriately provision the application requirements. The routing | |||
| ability to recompute paths based on slotted-link characteristics that | protocol MUST support the ability to recompute paths based on | |||
| may change dynamically. | underlying link characteristics that may change dynamically. | |||
| 4. Network Topology | 3.2. Different Routes for Different Flows | |||
| Network topology is very tough to generalize, but networks of 10 to | Because different services categories have different service | |||
| 200 field devices and maximum number of hops from two to twenty | requirements, it is often desirable to have different routes for | |||
| covers the majority of existing applications. It is assumed that the | different data flows between the same two endpoints. For example, | |||
| field devices themselves will provide routing capability for the | alarm or periodic data from A to Z may require path diversity with | |||
| network, and in most cases additional repeaters/routers will not be | specific latency and reliability. A file transfer between A and Z | |||
| required. | may not need path diversity. The routing algorithm MUST be able to | |||
| generate different routes for different flows. | ||||
| Timeslot size is about 10 ms and timeslot synchronization | 4. Reliability Requirements | |||
| requirements are on the order of +/-1 ms for non-critical process and | ||||
| control data (some L2 protocols provide/require tighter | ||||
| synchronization). Wall clock time *accuracy* requirements vary | ||||
| substantially, but are generally about 100ms. Some applications that | ||||
| time stamp data require 1 ms accuracy to determine the sequence of | ||||
| events reported. (Note that data time stamping does not translate to | ||||
| a latency requirement.) | ||||
| In low power and lossy network systems using the IEEE802.15.4-2006 | Another critical aspect for the routing is the capability to ensure | |||
| 2.4 GHz radio the total raw throughput per radio is 250 kbps. 10 ms | maximum disruption time and route maintainance. The maximum | |||
| timeslots reduces this to 101.6 Kbps for maximum sized packets. This | disruption time is the time it takes at most for a specific path to | |||
| constrains the typical throughput of a single radio access point to | be restored when broken. Route maintainance ensures that a path is | |||
| less 100 kbps. Therefore an access point with one IEEE 802.15.4 | monitored to be restored when broken within the maximum disruption | |||
| radio has a maximum aggregate throughput 100 packets per second and | time. Maintenance should also ensure that a path continues to | |||
| no more then about 100 Kbps. | provide the service for which it was established for instance in | |||
| terms of bandwidth, jitter and latency. | ||||
| A graph that connects a field device to a host application may have | In industrial applications, reliability is usually defined with | |||
| more than one access point. The routing protocol MUST support | respect to end-to-end delivery of packets within a bounded latency. | |||
| multiple access points and load distribution when aggregate network | Reliability requirements vary over many orders of magnitude. Some | |||
| throughputs need to exceed 100 kbps. The routing protocol MUST | non-critical monitoring applications may tolerate a reliability of | |||
| support multiple access points when access point redundancy is | less than 90% with hours of latency. Most industrial standards, such | |||
| required. | as HART7, have set user reliability 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 reliability requirements to higher then 99.9%. | ||||
| Hop-by-hop path diversity is used to improve latency-bounded | ||||
| reliability. Additionally, bicasting or pluricasting may be used | ||||
| over multiple non congruent / non overlapping paths to ensure that at | ||||
| least one instance of a critical packet is actually delivered. | ||||
| Because data from field devices are aggregated and funneled at the | ||||
| L2N access point before they are routed to plant applications, L2N | ||||
| access point redundancy is an important factor in overall | ||||
| reliability. A route that connects a field device to a plant | ||||
| application may have multiple paths that go through more than one L2N | ||||
| access point. The routing protocol MUST support multiple L2N access | ||||
| points and load distribution among L2N access points. The routing | ||||
| protocol MUST support multiple L2N access points when L2N access | ||||
| point redundancy is required. Because L2Ns are lossy in nature, | ||||
| multiple paths in a L2N route MUST be supported. The reliability of | ||||
| each path in a route can change over time. Hence, it is important to | ||||
| measure the reliability on a per-path basis and select a path (or | ||||
| paths) according to the reliability requirements. | ||||
| 5. Device-Aware Routing Requirements | 5. Device-Aware Routing Requirements | |||
| Wireless L2N nodes in industrial environments are powered by a | Wireless L2N nodes in industrial environments are powered by a | |||
| variety of sources. Battery operated devices with lifetime | variety of sources. Battery operated devices with lifetime | |||
| requirements of at least 5 years are the most common. Battery | requirements of at least five years are the most common. Battery | |||
| operated devices have a cap on their total energy, and typically can | operated devices have a cap on their total energy, and typically can | |||
| report some estimate of remaining energy, and typically do not have | report an estimate of remaining energy, and typically do not have | |||
| constraints on the short term average power consumption. Energy | constraints on the short-term average power consumption. Energy | |||
| scavenging devices are more complex. These systems contain both a | scavenging devices are more complex. These systems contain both a | |||
| power scavenging device (such as solar, vibration, or temperature | power scavenging device (such as solar, vibration, or temperature | |||
| difference) and an energy storage device, such as a rechargeable | difference) and an energy storage device, such as a rechargeable | |||
| battery or a capacitor. Therefore these systems have limits on both | battery or a capacitor. These systems, therefore, have limits on | |||
| the long term average power consumption (which cannot exceed the | both long-term average power consumption (which cannot exceed the | |||
| average scavenged power over the same interval) as well as the short- | average scavenged power over the same interval) as well as the short- | |||
| term limits imposed by the energy storage requirements. For solar- | term limits imposed by the energy storage requirements. For solar- | |||
| powered systems, the energy storage system is generally designed to | powered systems, the energy storage system is generally designed to | |||
| provide days of power in the absence of sunlight. Many industrial | provide days of power in the absence of sunlight. Many industrial | |||
| sensors run off of a 4-20mA current loop, and can scavenge on the | sensors run off of a 4-20 mA current loop, and can scavenge on the | |||
| order of mW from that source. Vibration monitoring systems are a | order of milliwatts from that source. Vibration monitoring systems | |||
| natural choice for vibration scavenging, which typically only | are a natural choice for vibration scavenging, which typically only | |||
| provides tens or hundreds of microwatts. Due to industrial | provides tens or hundreds of microwatts. Due to industrial | |||
| temperature ranges and desired lifetimes, the choices of energy | temperature ranges and desired lifetimes, the choices of energy | |||
| storage devices can be limited, and the resulting stored energy is | storage devices can be limited, and the resulting stored energy is | |||
| often comparable to the energy cost of sending or receiving a packet | often comparable to the energy cost of sending or receiving a packet | |||
| rather than the energy of operating the node for several days. And | rather than the energy of operating the node for several days. And | |||
| of course some nodes will be line-powered. | of course, some nodes will be line-powered. | |||
| Example 1: solar panel, lead-acid battery sized for two weeks of | Example 1: solar panel, lead-acid battery sized for two weeks of | |||
| rain. | rain. | |||
| Example 2: vibration scavenger, 1mF tantalum capacitor | Example 2: vibration scavenger, 1mF tantalum capacitor. | |||
| Field devices have limited resources. Low power, low cost devices | Field devices have limited resources. Low-power, low-cost devices | |||
| have limited memory for storing route information. Typical field | have limited memory for storing route information. Typical field | |||
| devices will have a finite number of routes they can support for | devices will have a finite number of routes they can support for | |||
| their embedded sensor/actuator application and for forwarding other | their embedded sensor/actuator application and for forwarding other | |||
| devices packets in a mesh network slotted-link. | devices packets in a mesh network slotted-link. | |||
| Users may have strong preferences on lifetime that is different for | Users may strongly prefer that the same device have different | |||
| the same device in different locations. A sensor monitoring a non- | lifetime requirements in different locations. A sensor monitoring a | |||
| critical parameter in an easily-accessed location may have a lifetime | non-critical parameter in an easily accessed location may have a | |||
| requirement that is shorter and tolerate more statistical variation | lifetime requirement that is shorter and tolerate more statistical | |||
| than a mission-critical sensor in a hard to reach place that requires | variation than a mission-critical sensor in a hard-to-reach place | |||
| shutdown of the plant to replace. | that requires a plant shutdown in order to replace. | |||
| The routing algorithm MUST support node constrained routing (e.g. | The routing algorithm MUST support node-constrained routing (e.g. | |||
| taking into account the existing energy state as a node constraint). | taking into account the existing energy state as a node constraint). | |||
| Node constraints include power and memory as well as constraints | Node constraints include power and memory, as well as constraints | |||
| placed on the device by the user such as battery life. | placed on the device by the user, such as battery life. | |||
| 6. Broadcast/Multicast | 6. Broadcast/Multicast | |||
| Existing industrial host applications do not use broadcast or | Existing industrial plant applications do not use broadcast or | |||
| multicast addressing to communicate to field devices. Unicast | multicast addressing to communicate to field devices. Unicast | |||
| address support is sufficient. However wireless field devices with | address support is sufficient. However wireless field devices with | |||
| communication controllers and protocol stacks will require control | communication controllers and protocol stacks will require control | |||
| and configuration such as firmware downloading that may benefit from | and configuration, such as firmware downloading, that may benefit | |||
| broadcast and multicast addressing. | from broadcast or multicast addressing. | |||
| The routing protocol SHOULD support broadcast and multicast | The routing protocol SHOULD support broadcast or multicast | |||
| addressing. | addressing. | |||
| 7. Route Establishment Time | 7. Route Establishment Time | |||
| Network connectivity in real deployments is always time-varying, with | During network formation, installers with no networking skill must be | |||
| time constants from seconds to months. Optimization is perhaps not | able to determine if their devices are "in the network" with | |||
| the right word to use, in that network optimization will need to run | sufficient connectivity to perform their function. Installers will | |||
| continuously, and single-slotted-link failures that cause loss of | have sufficient skill to provision the devices with a sample rate or | |||
| connectivity are not likely to be tolerated. Once the network is | activity profile. The routing algorithm MUST find the appropriate | |||
| formed, it should never need to "optimized" to a new configuration in | route(s) and report success or failure within several minutes, and | |||
| response to a lost slotted-link. The routing algorithm SHOULD not | SHOULD report success or failure within tens of seconds. | |||
| have to re-optimize in response to the loss of a slotted-link. The | ||||
| routing algorithms SHOULD always be in the process of plesio- | Network connectivity in real deployments is always time varying, with | |||
| optimizing the system for the changing RF environment. The routing | time constants from seconds to months. So long as the underlying | |||
| algorithm MUST re-optimize the path when field devices change due to | connectivity has not been compromised, this link churn should not | |||
| insertion, removal or failure. | 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 | ||||
| optimizing the system in response to changing link statistics. The | ||||
| routing algorithm MUST re-optimize the paths when field devices | ||||
| change due to insertion, removal or failure, and this re-optimization | ||||
| MUST not cause latencies greater than the specified constraints | ||||
| (typically seconds to minutes). | ||||
| 8. Mobility | 8. Mobility | |||
| Various economic factors have contributed to a reduction of trained | Various economic factors have contributed to a reduction of trained | |||
| workers in the plant. The industry as a whole appears to be trying | workers in the plant. The industry as a whole appears to be trying | |||
| to solve this problem with what is called the "wireless worker". | to solve this problem with what is called the "wireless worker". | |||
| Carrying a PDA or something similar, this worker will be able to | Carrying a PDA or something similar, this worker will be able to | |||
| accomplish more work in less time than the older, better-trained | accomplish more work in less time than the older, better-trained | |||
| workers that he or she replaces. Whether the premise is valid, the | workers that he or she replaces. Whether the premise is valid, the | |||
| use case is commonly presented: the worker will be wirelessly | use case is commonly presented: the worker will be wirelessly | |||
| connected to the plant IT system to download documentation, | connected to the plant IT system to download documentation, | |||
| instructions, etc., and will need to be able to connect "directly" to | 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 | the sensors and control points in or near the equipment on which he | |||
| or she is working. It is possible that this "direct" connection | or she is working. It is possible that this "direct" connection | |||
| could come via the normal L2Ns data collection network. This | could come via the normal L2Ns data collection network. This | |||
| connection is likely to require higher bandwidth and lower latency | connection is likely to require higher bandwidth and lower latency | |||
| than the normal data collection operation. | than the normal data collection operation. | |||
| The routing protocol SHOULD support the wireless worker with fast | The routing protocol SHOULD support the wireless worker with fast | |||
| network connection times of a few of seconds, low latency command and | network connection times of a few of seconds, and low command and | |||
| response latencies to host behind the access points and to | response latencies to the plant behind the L2N access points, to | |||
| applications and to field devices. The routing protocol SHOULD also | applications, and to field devices. The routing protocol SHOULD also | |||
| support configuring graphs for bulk transfers. The routing protocol | support the bandwidth allocation for bulk transfers between the field | |||
| MUST support walking speeds for maintaining network connectivity as | device and the handheld device of the wireless worker. The routing | |||
| the handheld device changes position in the wireless network. | 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 | Some field devices will be mobile. These devices may be located on | |||
| moving parts such as rotating components or they 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 | vehicles such as cranes or fork lifts. The routing protocol SHOULD | |||
| support vehicular speeds of up to 35 kmph. | support vehicular speeds of up to 35 kmph. | |||
| 9. Manageability and Ease Of Use | 9. Manageability | |||
| The process and control industry is manpower constrained. The aging | The process and control industry is manpower constrained. The aging | |||
| demographics of plant personnel are causing a looming manpower | demographics of plant personnel are causing a looming manpower | |||
| problem for industry across many markets. The goal for the | problem for industry across many markets. The goal for the | |||
| industrial networks is to make the installation process not require | industrial networks is to have the installation process not require | |||
| any new skills for the plant personnel. The industrial customers do | any new skills for the plant personnel. The person would install the | |||
| not even want to require the current level of networking knowledge | wireless sensor or wireless actuator the same way the wired sensor or | |||
| needed for do-it-yourself home network installations. | wired actuator is installed, except the step to connect wire is | |||
| eliminated. | ||||
| The routing protocol for L2Ns must be easy to deploy and manage. In | The routing protocol for L2Ns is expected to be easy to deploy and | |||
| a further revision of this document, metrics to measure ease of | manage. Because the number of field devices in a network is large, | |||
| deployment for the routing protocol will be detailed. | provisioning the devices manually would not make sense. Therefore, | |||
| the routing protocol MUST support auto-provisioning of field devices. | ||||
| The protocol also MUST support the distribution of configuration from | ||||
| a centralized management controller if operator-initiated | ||||
| configuration change is allowed. | ||||
| 10. Security | 10. Security | |||
| Wireless sensor networks in industrial automation operate in systems | Given that wireless sensor networks in industrial automation operate | |||
| that have substantial financial and human safety implications, | in systems that have substantial financial and human safety | |||
| security is of considerable concern. Levels of security violation | implications, security is of considerable concern. Levels of | |||
| which are tolerated as a "cost of doing business" in the banking | security violation that are tolerated as a "cost of doing business" | |||
| industry are not acceptable when in some cases literally thousands of | in the banking industry are not acceptable when in some cases | |||
| lives may be at risk. | literally thousands of lives may be at risk. | |||
| Industrial wireless device manufactures are specifying security at | Industrial wireless device manufactures are specifying security at | |||
| the MAC layer and the Transport layer. A shared "Network Key" is | the MAC layer and the transport layer. A shared key is used to | |||
| used to authenticate messages at the MAC layer. At the transport | authenticate messages at the MAC layer. At the transport layer, | |||
| layer, commands are encrypted with unique randomly-generated end-to- | commands are encrypted with unique randomly-generated end-to-end | |||
| end Session keys. HART7 and ISA100.11a are examples of security | Session keys. HART7 and ISA100.11a are examples of security systems | |||
| systems for industrial wireless networks. | for industrial wireless networks. | |||
| Industrial plants may not maintain the same level of physical | Industrial plants may not maintain the same level of physical | |||
| security for field devices that is associated with traditional | security for field devices that is associated with traditional | |||
| network sites such as locked IT centers. In industrial plants it | network sites such as locked IT centers. In industrial plants it | |||
| must be assumed that the field devices have marginal physical | must be assumed that the field devices have marginal physical | |||
| security and the security system needs to have limited trust in them. | security and the security system needs to have limited trust in them. | |||
| The routing protocol SHOULD place limited trust in the field devices | The routing protocol SHOULD place limited trust in the field devices | |||
| deployed in the plant network. | deployed in the plant network. | |||
| The routing protocol SHOULD compartmentalize the trust placed in | The routing protocol SHOULD compartmentalize the trust placed in | |||
| field devices so that a compromised field device does not destroy the | field devices so that a compromised field device does not destroy the | |||
| security of the whole network. The routing MUST be configured and | security of the whole network. The routing MUST be configured and | |||
| managed using secure messages and protocols that prevent outsider | managed using secure messages and protocols that prevent outsider | |||
| attacks and limit insider attacks from field devices installed in | attacks and limit insider attacks from field devices installed in | |||
| insecure locations in the plant. | insecure locations in the plant. | |||
| 11. Informative Reference | 11. IANA Considerations | |||
| [HART] "Highway Addressable Remote Transducer", a group of | ||||
| specifications for industrial process and control devices | ||||
| administered by the HART Foundation, www.hartcomm.org. | ||||
| 12. IANA Considerations | ||||
| This document includes no request to IANA. | This document includes no request to IANA. | |||
| 13. Acknowledgements | 12. Acknowledgements | |||
| 14. References | Many thanks to Rick Enns and Chol Su Kang for their contributions. | |||
| 14.1. Normative References | 13. References | |||
| 13.1. Normative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| 14.2. Informative References | 13.2. Informative References | |||
| [I-D.culler-rl2n-routing-reqs] | [I-D.culler-rl2n-routing-reqs] | |||
| Vasseur, J. and D. Cullerot, "Routing Requirements for Low | Vasseur, J. and D. Cullerot, "Routing Requirements for Low | |||
| Power And Lossy Networks", | Power And Lossy Networks", | |||
| draft-culler-rl2n-routing-reqs-01 (work in progress), | draft-culler-rl2n-routing-reqs-01 (work in progress), | |||
| July 2007. | July 2007. | |||
| 13.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, "SP100.11 Working Group Draft Standard, Version 0.1", | ||||
| December 2007. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Kris Pister | Kris Pister | |||
| Dust Networks | Dust Networks | |||
| 30695 Huntwood Ave. | 30695 Huntwood Ave. | |||
| Hayward, 94544 | Hayward, 94544 | |||
| USA | USA | |||
| Email: kpister@dustnetworks.com | Email: kpister@dustnetworks.com | |||
| Rick Enns | ||||
| Dust Networks | ||||
| 30695 Huntwood Ave. | ||||
| Hayward, 94544 | ||||
| USA | ||||
| Email: enns@stanfordalumni.org | ||||
| Pascal Thubert | Pascal Thubert | |||
| Cisco Systems, Inc | Cisco Systems, Inc | |||
| Village d'Entreprises Green Side - 400, Avenue de Roumanille | Village d'Entreprises Green Side - 400, Avenue de Roumanille | |||
| Sophia Antipolis, 06410 | Sophia Antipolis, 06410 | |||
| FRANCE | ||||
| Email: pthubert@cisco.com | Email: pthubert@cisco.com | |||
| Full Copyright Statement | Full Copyright Statement | |||
| Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
| This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
| contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
| retain all their rights. | retain all their rights. | |||
| End of changes. 84 change blocks. | ||||
| 288 lines changed or deleted | 395 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||