idnits 2.17.1 draft-pister-roll-indus-routing-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 769. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Network connectivity in real deployments is always time varying, with time constants from seconds to months. So long as the underlying connectivity has not been compromised, this link churn should not 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). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 22, 2008) is 5845 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'HART' is mentioned on line 705, but not defined == Unused Reference: 'I-D.culler-rl2n-routing-reqs' is defined on line 697, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group K. Pister 3 Internet-Draft Dust Networks 4 Intended status: Informational P. Thubert 5 Expires: October 24, 2008 Cisco Systems, Inc 6 April 22, 2008 8 Industrial Routing Requirements in Low Power and Lossy Networks 9 draft-pister-roll-indus-routing-reqs-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 24, 2008. 36 Abstract 38 Wireless, low power field devices enable industrial users to 39 significantly increase the amount of information collected and the 40 number of control points that can be remotely managed. The 41 deployment of these wireless devices will significantly improve the 42 productivity and safety of the plants while increasing the efficiency 43 of the plant workers. For wireless devices to have a significant 44 advantage over wired devices in an industrial environment the 45 wireless network needs to have three qualities: low power, high 46 reliability, and easy installation and maintenance. The aim of this 47 document is to analyze the requirements for the routing protocol used 48 for low power and lossy networks (L2N) in industrial environments. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 61 2.2. Network Topology of Industrial Applications . . . . . . . 6 62 2.2.1. The Physical Topology . . . . . . . . . . . . . . . . 7 63 3. Service Requirements . . . . . . . . . . . . . . . . . . . . . 9 64 3.1. Configurable Application Requirement . . . . . . . . . . . 10 65 3.2. Different Routes for Different Flows . . . . . . . . . . . 11 66 4. Reliability Requirements . . . . . . . . . . . . . . . . . . . 11 67 5. Device-Aware Routing Requirements . . . . . . . . . . . . . . 12 68 6. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 13 69 7. Route Establishment Time . . . . . . . . . . . . . . . . . . . 13 70 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 9. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 14 72 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 13.3. External Informative References . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 Intellectual Property and Copyright Statements . . . . . . . . . . 17 82 1. Terminology 84 Actuator: a field device that moves or controls plant equipment. 86 Closed Loop Control: A process whereby a device controller controls 87 an actuator based on information sensed by one or more field devices. 89 Downstream: Data direction traveling from the plant application to 90 the field device. 92 Field Device: physical devices placed in the plant's operating 93 environment (both RF and environmental). Field devices include 94 sensors and actuators as well as network routing devices and L2N 95 access points in the plant. 97 HART: "Highway Addressable Remote Transducer", a group of 98 specifications for industrial process and control devices 99 administered by the HART Foundation (see [HART]). The latest version 100 for the specifications is HART7 which includes the additions for 101 WirelessHART. 103 ISA: "International Society of Automation". ISA is an ANSI 104 accredited standards-making society. ISA100 is an ISA working group 105 whose charter includes defining a family of standards for industrial 106 automation. ISA100.11a is a work group within ISA100 that is working 107 on a standard for non-critical process and control applications. 109 L2N Access Point: The L2N access point is an infrastructure device 110 that connects the low power and lossy network system to a plant's 111 backbone network. 113 Open Loop Control: A process whereby a plant technician controls an 114 actuator over the network where the decision is influenced by 115 information sensed by field devices. 117 Plant Application: The plant application is a process running in the 118 plant that communicates with field devices to perform tasks on that 119 may include control, monitoring and data gathering. 121 Upstream: Data direction traveling from the field device to the plant 122 application. 124 RL2N: Routing in Low power and Lossy Networks. 126 2. Introduction 128 Wireless, low-power field devices enable industrial users to 129 significantly increase the amount of information collected and the 130 number of control points that can be remotely managed. The 131 deployment of these wireless devices will significantly improve the 132 productivity and safety of the plants while increasing the efficiency 133 of the plant workers. 135 Wireless field devices enable expansion of networked points by 136 appreciably reducing cost of installing a device. The cost 137 reductions come from eliminating cabling costs and simplified 138 planning. Cabling for a field device can run from $100s/ft to 139 $1,000s/ft depending on the safety regulations of the plant. Cabling 140 also carries an overhead cost associated with planning the 141 installation, determining where the cable has to run, and interfacing 142 with the various organizations required to coordinate its deployment. 143 Doing away with the network and power cables reduces the planning and 144 administrative overhead of installing a device. 146 For wireless devices to have a significant advantage over wired 147 devices in an industrial environment, the wireless network needs to 148 have three qualities: low power, high reliability, and easy 149 installation and maintenance. The routing protocol used for low 150 power and lossy networks (L2N) is important to fulfilling these 151 goals. 153 Industrial automation is segmented into two distinct application 154 spaces, known as "process" or "process control" and "discrete 155 manufacturing" or "factory automation". In industrial process 156 control, the product is typically a fluid (oil, gas, chemicals ...). 157 In factory automation or discrete manufacturing, the products are 158 individual elements (screws, cars, dolls). While there is some 159 overlap of products and systems between these two segments, they are 160 surprisingly separate communities. The specifications targeting 161 industrial process control tend to have more tolerance for network 162 latency than what is needed for factory automation. 164 Both application spaces desire battery operated networks of hundreds 165 of sensors and actuators communicating with L2N access points. In an 166 oil refinery, the total number of devices is likely to exceed one 167 million, but the devices will be clustered into smaller networks that 168 report to an existing plant network infrastructure. 170 Existing wired sensor networks in this space typically use 171 communication protocols with low data rates, from 1,200 baud (e.g. 172 wired HART) to the one to two hundred Kbps range for most of the 173 others. The existing protocols are often master/slave with command/ 174 response. 176 2.1. Applications and Traffic Patterns 178 The industrial market classifies process applications into three 179 broad categories and six classes. 181 o Safety 183 * Class 0: Emergency action - Always a critical function 185 o Control 187 * Class 1: Closed loop regulatory control - Often a critical 188 function 190 * Class 2: Closed loop supervisory control - Usually non-critical 191 function 193 * Class 3: Open loop control - Operator takes action and controls 194 the actuator (human in the loop) 196 o Monitoring 198 * Class 4: Alerting - Short-term operational effect (for example 199 event-based maintenance) 201 * Class 5: Logging and downloading / uploading - No immediate 202 operational consequence (e.g., history collection, sequence-of- 203 events, preventive maintenance) 205 Critical functions effect the basic safety or integrity of the plant. 206 Timely deliveries of messages becomes more important as the class 207 number decreases. 209 Industrial users are interested in deploying wireless networks for 210 the monitoring classes 4 and 5, and in the non-critical portions of 211 classes 3 through 1. 213 Classes 4 and 5 also include asset monitoring and tracking which 214 include equipment monitoring and are essentially separate from 215 process monitoring. An example of equipment monitoring is the 216 recording of motor vibrations to detect bearing wear. 218 In the near future, most low power and lossy network systems will be 219 for low frequency data collection. Packets containing samples will 220 be generated continuously, and 90% of the market is covered by packet 221 rates of between 1/s and 1/hour, with the average under 1/min. In 222 industrial process, these sensors include temperature, pressure, 223 fluid flow, tank level, and corrosion. Some sensors are bursty, such 224 as vibration monitors that may generate and transmit tens of kilo- 225 bytes (hundreds to thousands of packets) of time-series data at 226 reporting rates of minutes to days. 228 Almost all of these sensors will have built-in microprocessors that 229 may detect alarm conditions. Time-critical alarm packets are 230 expected to have lower latency than sensor data. 232 Some devices will transmit a log file every day, again with typically 233 tens of Kbytes of data. For these applications there is very little 234 "downstream" traffic coming from the L2N access point and traveling 235 to particular sensors. During diagnostics, however, a technician may 236 be investigating a fault from a control room and expect to have "low" 237 latency (human tolerable) in a command/response mode. 239 Low-rate control, often with a "human in the loop" (also referred to 240 as "open loop"), is implemented today via communication to a 241 centralized controller. The sensor data makes its way through the 242 L2N access point to the centralized controller where it is processed, 243 the operator sees the information and takes action, and the control 244 information is then sent out to the actuator node in the network. 246 In the future, it is envisioned that some open loop processes will be 247 automated (closed loop) and packets will flow over local loops and 248 not involve the L2N access point. These closed loop controls for 249 non-critical applications will be implemented on L2Ns. Non-critical 250 closed loop applications have a latency requirement that can be as 251 low as 100 ms but many control loops are tolerant of latencies above 252 1 s. 254 In critical control, tens of milliseconds of latency is typical. In 255 many of these systems, if a packet does not arrive within the 256 specified interval, the system enters an emergency shutdown state, 257 often with substantial financial repercussions. For a one-second 258 control loop in a system with a mean-time between shutdowns target of 259 30 years, the latency requirement implies nine 9s of reliability. 261 2.2. Network Topology of Industrial Applications 263 Although network topology is difficult to generalize, the majority of 264 existing applications can be met by networks of 10 to 200 field 265 devices and maximum number of hops from two to twenty. It is assumed 266 that the field devices themselves will provide routing capability for 267 the network, and additional repeaters/routers will not be required in 268 most cases. 270 For most industrial applications, a manager, gateway or backbone 271 router acts as a sink for the wireless sensor network. The vast 272 majority of the traffic is real time publish/subscribe sensor data 273 from the field devices over a L2N towards one or more sinks. 274 Increasingly over time, these sinks will be a part of a backbone but 275 today they are often fragmented and isolated. 277 The wireless sensor network is a Low Power and Lossy Network of field 278 devices for which two logical roles are defined, the field routers 279 and the non routing devices. It is acceptable and even probable that 280 the repartition of the roles across the field devices change over 281 time to balance the cost of the forwarding operation amongst the 282 nodes. 284 The backbone is a high speed network that interconnects multiple WSNs 285 through backbone routers. Infrastructure devices can be connected to 286 the backbone. A gateway / manager that interconnects the backbone to 287 the plant network of the corporate network can be viewed as 288 collapsing the backbone and the infrastructure devices into a single 289 device that operates all the required logical roles. The backbone is 290 likely to always become an important function of the industrial 291 network. The Internet at large is not considered as a viable option 292 to perform the backbone function. 294 A plant or corporate network is also present on the factory site. 295 This is the typical IT nework for the factory operations beyond 296 process control. That network is out of scope for this document. 298 2.2.1. The Physical Topology 300 There is no specific physical topology for an industrial process 301 control network. One extreme example is a multi-square-kilometer 302 refinery where isolated tanks, some of them with power but most with 303 no backbone connectivity, compose a farm that spans over of the 304 surface of the plant. A few hundred field devices are deployed to 305 ensure the global coverage using a wireless self-forming self-healing 306 mesh network that might be 5 to 10 hops across. Local feedback loops 307 and mobile workers tend to be only one or two hops. The backbone is 308 in the refinery proper, many hops away. Even there, powered 309 infrastructure is also typically several hops away. So hopping to/ 310 from the powered infrastructure will in general be more costly than 311 the direct route. 313 In the opposite extreme case, the backbone network spans all the 314 nodes and most nodes are in direct sight of one or more backbone 315 router. Most communication between field devices and infrastructure 316 devices as well as field device to field device occurs across the 317 backbone. Form afar, this model resembles the WIFI ESS (Extended 318 Service Set). But from a layer 3 perspective, the issues are the 319 default (backbone) router selection and the routing inside the 320 backbone whereas the radio hop towards the field device is in fact a 321 simple local delivery. 322 ---+------------------------ 323 | Plant Network 324 | 325 +-----+ 326 | | Gateway 327 | | 328 +-----+ 329 | 330 | Backbone 331 +--------------------+------------------+ 332 | | | 333 +-----+ +-----+ +-----+ 334 | | Backbone | | Backbone | | Backbone 335 | | router | | router | | router 336 +-----+ +-----+ +-----+ 337 o o o o o o o o o o o o o 338 o o o o o o o o o o o o o o o o o o 339 o o o o o o o o o o o M o o o o o 340 o o M o o o o o o o o o o o o o 341 o o o o o o o o o 342 o o o o o 343 L2N 345 Considering that though each field device to field device route 346 computation has specific constraints in terms of latency and 347 availability it can be expected that the shortest path possible will 348 often be selected and that this path will be routed inside the LLN as 349 opposed to via the backbone. It can also be noted that the lifetimes 350 of the routes might range from minutes for a mobile workers to tens 351 of years for a command and control closed loop. Finally, time- 352 varying user requirements for latency and bandwidth will change the 353 constraints on the routes, which might either trigger a constrained 354 route recomputation, a reprovisioning of the underlying L2 protocols, 355 or both in that order. For instance, a wireless worker may initiate 356 a bulk transfer to configure or diagnose a field device. A level 357 sensor device may need to perform a calibration and send a bulk file 358 to a plant. 360 For these reasons, the ROLL routing infrastructure MUST be able to 361 compute and update constrained routes on demand (that is reactively), 362 and it can be expected that this model will become more prevalent for 363 field device to field device connectivity as well as for some field 364 device to Infrastructure devices over time. 366 3. Service Requirements 368 The industrial applications fall into four large service categories 369 [ISA100.11a]: 371 1. Periodic data (aka buffered). Data that is generated 372 periodically and has a well understood data bandwidth 373 requirement, both deterministic and predictable. Timely delivery 374 of such data is often the core function of a wireless sensor 375 network and permanent resources are assigned to ensure that the 376 required bandwidth stays available. Buffered data usually 377 exhibits a short time to live, and the newer reading obsoletes 378 the previous. In some cases, alarms are low priority information 379 that gets repeated over and over. The end-to-end latency of this 380 data is not as important as the regularity with which the data is 381 presented to the plant application. 383 2. Event data. This category includes alarms and aperiodic data 384 reports with bursty data bandwidth requirements. In certain 385 cases, alarms are critical and require a priority service from 386 the network. 388 3. Client/Server. Many industrial applications are based on a 389 client/server model and implement a command response protocol. 390 The data bandwidth required is often bursty. The acceptable 391 round-trip latency for some legacy systems was based on the time 392 to send tens of bytes over a 1200 baud link. Hundreds of 393 milliseconds is typical. This type of request is statistically 394 multiplexed over the L2N and cost-based fair-share best-effort 395 service is usually expected. 397 4. Bulk transfer. Bulk transfers involve the transmission of blocks 398 of data in multiple packets where temporary resources are 399 assigned to meet a transaction time constraint. Transient 400 resources are assigned for a limited period of time (related to 401 file size and data rate) to meet the bulk transfers service 402 requirements. 404 For industrial applications Service parameters include but might not 405 be limited to: 407 o Data bandwidth - the bandwidth might be allocated permanently or 408 for a period of time to a specific flow that usually exhibits well 409 defined properties of burstiness and throughput. Some bandwidth 410 will also be statistically shared between flows in a best effort 411 fashion. 413 o Latency - the time taken for the data to transit the network from 414 the source to the destination. This may be expressed in terms of 415 a deadline for delivery. Most monitoring latencies will be in 416 seconds to minutes. 418 o Transmission phase - process applications can be synchronized to 419 wall clock time and require coordinated transmissions. A common 420 coordination frequency is 4 Hz (250 ms). 422 o Service contract type - revocation priority. L2Ns have limited 423 network resources that can vary with time. This means the system 424 can become fully subscribed or even over subscribed. System 425 policies determine how resources are allocated when resources are 426 over subscribed. The choices are blocking and graceful 427 degradation. 429 o Transmission priority - the means by which limited resources 430 within field devices are allocated across multiple services. For 431 transmissions, a device has to select which packet in its queue 432 will be sent at the next transmission opportunity. Packet 433 priority is used as one criterion for selecting the next packet. 434 For reception, a device has to decide how to store a received 435 packet. The field devices are memory constrained and receive 436 buffers may become full. Packet priority is used to select which 437 packets are stored or discarded. 439 The routing protocol MUST also support different metric types for 440 each link used to compute the path according to some objective 441 function (e.g. minimize latency). 443 Industrial application data flows between field devices are not 444 necessarily symmetric. In particular, asymmetrical cost and 445 unidirectional routes are common for published data and alerts, which 446 represent the most part of the sensor traffic. The routing protocol 447 MUST be able to set up unidirectional or asymmetrical cost routes 448 that are composed of one or more non congruent paths. 450 3.1. Configurable Application Requirement 452 Time-varying user requirements for latency and bandwidth will require 453 changes in the provisioning of the underlying L2 protocols. A 454 technician may initiate a query/response session or bulk transfer to 455 diagnose or configure a field device. A level sensor device may need 456 to perform a calibration and send a bulk file to a plant. The 457 routing protocol MUST route on paths that are changed to 458 appropriately provision the application requirements. The routing 459 protocol MUST support the ability to recompute paths based on 460 underlying link characteristics that may change dynamically. 462 3.2. Different Routes for Different Flows 464 Because different services categories have different service 465 requirements, it is often desirable to have different routes for 466 different data flows between the same two endpoints. For example, 467 alarm or periodic data from A to Z may require path diversity with 468 specific latency and reliability. A file transfer between A and Z 469 may not need path diversity. The routing algorithm MUST be able to 470 generate different routes for different flows. 472 4. Reliability Requirements 474 Another critical aspect for the routing is the capability to ensure 475 maximum disruption time and route maintainance. The maximum 476 disruption time is the time it takes at most for a specific path to 477 be restored when broken. Route maintainance ensures that a path is 478 monitored to be restored when broken within the maximum disruption 479 time. Maintenance should also ensure that a path continues to 480 provide the service for which it was established for instance in 481 terms of bandwidth, jitter and latency. 483 In industrial applications, reliability is usually defined with 484 respect to end-to-end delivery of packets within a bounded latency. 485 Reliability requirements vary over many orders of magnitude. Some 486 non-critical monitoring applications may tolerate a reliability of 487 less than 90% with hours of latency. Most industrial standards, such 488 as HART7, have set user reliability expectations at 99.9%. 489 Regulatory requirements are a driver for some industrial 490 applications. Regulatory monitoring requires high data integrity 491 because lost data is assumed to be out of compliance and subject to 492 fines. This can drive reliability requirements to higher then 99.9%. 494 Hop-by-hop path diversity is used to improve latency-bounded 495 reliability. Additionally, bicasting or pluricasting may be used 496 over multiple non congruent / non overlapping paths to ensure that at 497 least one instance of a critical packet is actually delivered. 499 Because data from field devices are aggregated and funneled at the 500 L2N access point before they are routed to plant applications, L2N 501 access point redundancy is an important factor in overall 502 reliability. A route that connects a field device to a plant 503 application may have multiple paths that go through more than one L2N 504 access point. The routing protocol MUST support multiple L2N access 505 points and load distribution among L2N access points. The routing 506 protocol MUST support multiple L2N access points when L2N access 507 point redundancy is required. Because L2Ns are lossy in nature, 508 multiple paths in a L2N route MUST be supported. The reliability of 509 each path in a route can change over time. Hence, it is important to 510 measure the reliability on a per-path basis and select a path (or 511 paths) according to the reliability requirements. 513 5. Device-Aware Routing Requirements 515 Wireless L2N nodes in industrial environments are powered by a 516 variety of sources. Battery operated devices with lifetime 517 requirements of at least five years are the most common. Battery 518 operated devices have a cap on their total energy, and typically can 519 report an estimate of remaining energy, and typically do not have 520 constraints on the short-term average power consumption. Energy 521 scavenging devices are more complex. These systems contain both a 522 power scavenging device (such as solar, vibration, or temperature 523 difference) and an energy storage device, such as a rechargeable 524 battery or a capacitor. These systems, therefore, have limits on 525 both long-term average power consumption (which cannot exceed the 526 average scavenged power over the same interval) as well as the short- 527 term limits imposed by the energy storage requirements. For solar- 528 powered systems, the energy storage system is generally designed to 529 provide days of power in the absence of sunlight. Many industrial 530 sensors run off of a 4-20 mA current loop, and can scavenge on the 531 order of milliwatts from that source. Vibration monitoring systems 532 are a natural choice for vibration scavenging, which typically only 533 provides tens or hundreds of microwatts. Due to industrial 534 temperature ranges and desired lifetimes, the choices of energy 535 storage devices can be limited, and the resulting stored energy is 536 often comparable to the energy cost of sending or receiving a packet 537 rather than the energy of operating the node for several days. And 538 of course, some nodes will be line-powered. 540 Example 1: solar panel, lead-acid battery sized for two weeks of 541 rain. 543 Example 2: vibration scavenger, 1mF tantalum capacitor. 545 Field devices have limited resources. Low-power, low-cost devices 546 have limited memory for storing route information. Typical field 547 devices will have a finite number of routes they can support for 548 their embedded sensor/actuator application and for forwarding other 549 devices packets in a mesh network slotted-link. 551 Users may strongly prefer that the same device have different 552 lifetime requirements in different locations. A sensor monitoring a 553 non-critical parameter in an easily accessed location may have a 554 lifetime requirement that is shorter and tolerate more statistical 555 variation than a mission-critical sensor in a hard-to-reach place 556 that requires a plant shutdown in order to replace. 558 The routing algorithm MUST support node-constrained routing (e.g. 559 taking into account the existing energy state as a node constraint). 560 Node constraints include power and memory, as well as constraints 561 placed on the device by the user, such as battery life. 563 6. Broadcast/Multicast 565 Existing industrial plant applications do not use broadcast or 566 multicast addressing to communicate to field devices. Unicast 567 address support is sufficient. However wireless field devices with 568 communication controllers and protocol stacks will require control 569 and configuration, such as firmware downloading, that may benefit 570 from broadcast or multicast addressing. 572 The routing protocol SHOULD support broadcast or multicast 573 addressing. 575 7. Route Establishment Time 577 During network formation, installers with no networking skill must be 578 able to determine if their devices are "in the network" with 579 sufficient connectivity to perform their function. Installers will 580 have sufficient skill to provision the devices with a sample rate or 581 activity profile. The routing algorithm MUST find the appropriate 582 route(s) and report success or failure within several minutes, and 583 SHOULD report success or failure within tens of seconds. 585 Network connectivity in real deployments is always time varying, with 586 time constants from seconds to months. So long as the underlying 587 connectivity has not been compromised, this link churn should not 588 substantially affect network operation. The routing algorithm MUST 589 respond to normal link failure rates with routes that meet the 590 Service requirements (especially latency) throughout the routing 591 response. The routing algorithm SHOULD always be in the process of 592 optimizing the system in response to changing link statistics. The 593 routing algorithm MUST re-optimize the paths when field devices 594 change due to insertion, removal or failure, and this re-optimization 595 MUST not cause latencies greater than the specified constraints 596 (typically seconds to minutes). 598 8. Mobility 600 Various economic factors have contributed to a reduction of trained 601 workers in the plant. The industry as a whole appears to be trying 602 to solve this problem with what is called the "wireless worker". 603 Carrying a PDA or something similar, this worker will be able to 604 accomplish more work in less time than the older, better-trained 605 workers that he or she replaces. Whether the premise is valid, the 606 use case is commonly presented: the worker will be wirelessly 607 connected to the plant IT system to download documentation, 608 instructions, etc., and will need to be able to connect "directly" to 609 the sensors and control points in or near the equipment on which he 610 or she is working. It is possible that this "direct" connection 611 could come via the normal L2Ns data collection network. This 612 connection is likely to require higher bandwidth and lower latency 613 than the normal data collection operation. 615 The routing protocol SHOULD support the wireless worker with fast 616 network connection times of a few of seconds, and low command and 617 response latencies to the plant behind the L2N access points, to 618 applications, and to field devices. The routing protocol SHOULD also 619 support the bandwidth allocation for bulk transfers between the field 620 device and the handheld device of the wireless worker. The routing 621 protocol SHOULD support walking speeds for maintaining network 622 connectivity as the handheld device changes position in the wireless 623 network. 625 Some field devices will be mobile. These devices may be located on 626 moving parts such as rotating components or they may be located on 627 vehicles such as cranes or fork lifts. The routing protocol SHOULD 628 support vehicular speeds of up to 35 kmph. 630 9. Manageability 632 The process and control industry is manpower constrained. The aging 633 demographics of plant personnel are causing a looming manpower 634 problem for industry across many markets. The goal for the 635 industrial networks is to have the installation process not require 636 any new skills for the plant personnel. The person would install the 637 wireless sensor or wireless actuator the same way the wired sensor or 638 wired actuator is installed, except the step to connect wire is 639 eliminated. 641 The routing protocol for L2Ns is expected to be easy to deploy and 642 manage. Because the number of field devices in a network is large, 643 provisioning the devices manually would not make sense. Therefore, 644 the routing protocol MUST support auto-provisioning of field devices. 645 The protocol also MUST support the distribution of configuration from 646 a centralized management controller if operator-initiated 647 configuration change is allowed. 649 10. Security 651 Given that wireless sensor networks in industrial automation operate 652 in systems that have substantial financial and human safety 653 implications, security is of considerable concern. Levels of 654 security violation that are tolerated as a "cost of doing business" 655 in the banking industry are not acceptable when in some cases 656 literally thousands of lives may be at risk. 658 Industrial wireless device manufactures are specifying security at 659 the MAC layer and the transport layer. A shared key is used to 660 authenticate messages at the MAC layer. At the transport layer, 661 commands are encrypted with unique randomly-generated end-to-end 662 Session keys. HART7 and ISA100.11a are examples of security systems 663 for industrial wireless networks. 665 Industrial plants may not maintain the same level of physical 666 security for field devices that is associated with traditional 667 network sites such as locked IT centers. In industrial plants it 668 must be assumed that the field devices have marginal physical 669 security and the security system needs to have limited trust in them. 670 The routing protocol SHOULD place limited trust in the field devices 671 deployed in the plant network. 673 The routing protocol SHOULD compartmentalize the trust placed in 674 field devices so that a compromised field device does not destroy the 675 security of the whole network. The routing MUST be configured and 676 managed using secure messages and protocols that prevent outsider 677 attacks and limit insider attacks from field devices installed in 678 insecure locations in the plant. 680 11. IANA Considerations 682 This document includes no request to IANA. 684 12. Acknowledgements 686 Many thanks to Rick Enns and Chol Su Kang for their contributions. 688 13. References 690 13.1. Normative References 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 13.2. Informative References 697 [I-D.culler-rl2n-routing-reqs] 698 Vasseur, J. and D. Cullerot, "Routing Requirements for Low 699 Power And Lossy Networks", 700 draft-culler-rl2n-routing-reqs-01 (work in progress), 701 July 2007. 703 13.3. External Informative References 705 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer", 706 a group of specifications for industrial process and 707 control devices administered by the HART Foundation". 709 [ISA100.11a] 710 ISA, "SP100.11 Working Group Draft Standard, Version 0.1", 711 December 2007. 713 Authors' Addresses 715 Kris Pister 716 Dust Networks 717 30695 Huntwood Ave. 718 Hayward, 94544 719 USA 721 Email: kpister@dustnetworks.com 723 Pascal Thubert 724 Cisco Systems, Inc 725 Village d'Entreprises Green Side - 400, Avenue de Roumanille 726 Sophia Antipolis, 06410 727 FRANCE 729 Email: pthubert@cisco.com 731 Full Copyright Statement 733 Copyright (C) The IETF Trust (2008). 735 This document is subject to the rights, licenses and restrictions 736 contained in BCP 78, and except as set forth therein, the authors 737 retain all their rights. 739 This document and the information contained herein are provided on an 740 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 741 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 742 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 743 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 744 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 745 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 747 Intellectual Property 749 The IETF takes no position regarding the validity or scope of any 750 Intellectual Property Rights or other rights that might be claimed to 751 pertain to the implementation or use of the technology described in 752 this document or the extent to which any license under such rights 753 might or might not be available; nor does it represent that it has 754 made any independent effort to identify any such rights. Information 755 on the procedures with respect to rights in RFC documents can be 756 found in BCP 78 and BCP 79. 758 Copies of IPR disclosures made to the IETF Secretariat and any 759 assurances of licenses to be made available, or the result of an 760 attempt made to obtain a general license or permission for the use of 761 such proprietary rights by implementers or users of this 762 specification can be obtained from the IETF on-line IPR repository at 763 http://www.ietf.org/ipr. 765 The IETF invites any interested party to bring to its attention any 766 copyrights, patents or patent applications, or other proprietary 767 rights that may cover technology that may be required to implement 768 this standard. Please address the information to the IETF at 769 ietf-ipr@ietf.org.