--- 1/draft-ietf-roll-indus-routing-reqs-05.txt 2009-06-05 17:12:13.000000000 +0200 +++ 2/draft-ietf-roll-indus-routing-reqs-06.txt 2009-06-05 17:12:13.000000000 +0200 @@ -1,22 +1,22 @@ Networking Working Group K. Pister, Ed. Internet-Draft Dust Networks Intended status: Informational P. Thubert, Ed. -Expires: October 22, 2009 Cisco Systems +Expires: December 7, 2009 Cisco Systems S. Dwars Shell T. Phinney - April 20, 2009 + June 5, 2009 Industrial Routing Requirements in Low Power and Lossy Networks - draft-ietf-roll-indus-routing-reqs-05 + draft-ietf-roll-indus-routing-reqs-06 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -25,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 22, 2009. + This Internet-Draft will expire on December 7, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -62,38 +62,39 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 3.2. Network Topology of Industrial Applications . . . . . . . 8 3.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10 3.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 12 - 4. Traffic Characteristics . . . . . . . . . . . . . . . . . . . 13 - 4.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 14 + 4. Requirements related to Traffic Characteristics . . . . . . . 13 + 4.1. Service Requirements . . . . . . . . . . . . . . . . . . . 14 4.2. Configurable Application Requirement . . . . . . . . . . . 15 4.3. Different Routes for Different Flows . . . . . . . . . . . 15 - 5. Reliability Requirements . . . . . . . . . . . . . . . . . . . 15 - 6. Device-Aware Routing Requirements . . . . . . . . . . . . . . 17 - 7. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 18 - 8. Route Establishment Time . . . . . . . . . . . . . . . . . . . 19 - 9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 21 - 11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 - 14.2. Informative References . . . . . . . . . . . . . . . . . . 24 - 14.3. External Informative References . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + 5. Reliability Requirements . . . . . . . . . . . . . . . . . . . 16 + 6. Device-Aware Routing Requirements . . . . . . . . . . . . . . 18 + 7. Broadcast/Multicast requirements . . . . . . . . . . . . . . . 19 + 8. Protocol Performance requirements . . . . . . . . . . . . . . 20 + 9. Mobility requirements . . . . . . . . . . . . . . . . . . . . 20 + 10. Manageability requirements . . . . . . . . . . . . . . . . . . 21 + 11. Antagonistic requirements . . . . . . . . . . . . . . . . . . 22 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 25 + 15.3. External Informative References . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Information Technology (IT) is already, and increasingly will be applied to industrial Control Technology (CT) in application areas where those IT technologies can be constrained sufficiently by Service Level Agreements (SLA) or other modest change that they are able to meet the operational needs of industrial CT. When that happens, the CT benefits from the large intellectual, experiential and training investment that has already occurred in those IT @@ -569,21 +570,21 @@ 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. -4. Traffic Characteristics +4. Requirements related to Traffic Characteristics [ISA100.11a] selected IPv6 as its Network Layer for a number of reasons, including the huge address space and the large potential size of a subnet, which can range up to 10K nodes in a plant deployment. In the ISA100 model, industrial applications fall into four large service categories: 1. Periodic data (aka buffered). Data that is generated periodically and has a well understood data bandwidth requirement, both deterministic and predictable. Timely delivery @@ -609,21 +610,21 @@ milliseconds is typical. This type of request is statistically multiplexed over the LLN and cost-based fair-share best-effort service is usually expected. 4. Bulk transfer. Bulk transfers involve the transmission of blocks of data in multiple packets where temporary resources are assigned to meet a transaction time constraint. Transient resources are assigned for a limited time (related to file size and data rate) to meet the bulk transfers service requirements. -4.1. Service Parameters +4.1. Service Requirements The following service parameters can affect routing decisions in a resource-constrained network: o Data bandwidth - the bandwidth might be allocated permanently or for a period of time to a specific flow that usually exhibits well defined properties of burstiness and throughput. Some bandwidth will also be statistically shared between flows in a best effort fashion. @@ -651,66 +652,91 @@ For reception, a device has to decide how to store a received packet. The field devices are memory constrained and receive buffers may become full. Packet priority is used to select which packets are stored or discarded. The routing protocol MUST also support different metric types for each link used to compute the path according to some objective function (e.g. minimize latency) depending on the nature of the traffic. - For these reasons, the ROLL routing infrastructure is required to + For these reasons, the ROLL routing infrastructure is REQUIRED to compute and update constrained routes on demand, and it can be expected that this model will become more prevalent for field device to field device connectivity as well as for some field device to Infrastructure devices over time. Industrial application data flows between field devices are not necessarily symmetric. In particular, asymmetrical cost and unidirectional routes are common for published data and alerts, which represent the most part of the sensor traffic. The routing protocol MUST be able to compute a set of unidirectional routes with potentially different costs that are composed of one or more non- congruent paths. As multiple paths are set up and a variety of flows traverse the network towards a same destination, for instance a node acting as a sink for the LLN, the use of an additional marking/tagging mechanism - based on an upper layer information will be required for intermediate + based on an upper layer information will be REQUIRED for intermediate routers to discriminate the flows and perform the appropriate routing decision using only the content of the IPv6 packet (e.g. use of DSCP, Flow Label). 4.2. Configurable Application Requirement Time-varying user requirements for latency and bandwidth may require changes in the provisioning of the underlying L2 protocols. A technician may initiate a query/response session or bulk transfer to diagnose or configure a field device. A level sensor device may need to perform a calibration and send a bulk file to a plant. The - routing protocol MUST route on paths that are changed to - appropriately provision the application requirements. The routing - protocol MUST support the ability to recompute paths based on Network - Layer abstractions of the underlying link attributes/metric that may - change dynamically. + routing protocol MUST support the ability to recompute paths based on + Network Layer abstractions of the underlying link attributes/metric + that may change dynamically. 4.3. Different Routes for Different Flows Because different services categories have different service requirements, it is often desirable to have different routes for different data flows between the same two endpoints. For example, alarm or periodic data from A to Z may require path diversity with specific latency and reliability. A file transfer between A and Z may not need path diversity. The routing algorithm MUST be able to - generate different routes with different characteritics (e.g. + generate different routes with different characteristics (e.g. Optimized according to different cost, etc...). + Dynanic or configured states of links and nodes influence the + capability of a given path to fulfill operational requirements such + as stability, battery cost or latency. Constraints such as battery + lifetime derive from the application itself, and because industrial + applications data flows are typically well-defined and well- + controlled, it is usually possible to estimate the battery + consumption of a router for a given topology. + + The routing protocol MUST support the ability to (re)compute paths + based on Network Layer abstractions of upper layer constraints to + maintain the level of operation within required parameters. Such + information MAY be advertised by the routing protocol as metrics that + enable routing algorithms to establish appropriate paths that fit the + upper layer constraints. + + The handling of an IPv6 packet by the Network Layer operates on the + standard properties and the settings of the IPv6 packet header + fields. These fields include the 3-tuple of the Flow Label and the + Source and Destination Address that can be used to identify a flow + and the Traffic Class octet that can be used to influence the Per Hop + Behavior in intermediate routers. + + An application MAY choose how to set those fields for each packet or + for streams of packets, and the routing protocol specification SHOULD + state how different field settings will be handled to perform + different routing decisions. + 5. Reliability Requirements LLN reliability constitutes several unrelated aspects: 1) Availability of source to destination connectivity when the application needs it, expressed in number of succeses / number of attempts 2) Availability of source to destination connectivity when the application might need it, expressed in number of potential @@ -831,21 +857,21 @@ non-critical parameter in an easily accessed location may have a lifetime requirement that is shorter and tolerate more statistical variation than a mission-critical sensor in a hard-to-reach place that requires a plant shutdown in order to replace. The routing algorithm MUST support node-constrained routing (e.g. taking into account the existing energy state as a node constraint). Node constraints include power and memory, as well as constraints placed on the device by the user, such as battery life. -7. Broadcast/Multicast +7. Broadcast/Multicast requirements Some existing industrial plant applications do not use broadcast or multicast addressing to communicate to field devices. Unicast address support is sufficient for them. In some other industrial process automation environments, multicast over IP is used to deliver to multiple nodes that may be functionally-similar or not. Example usages are: 1) Delivery of alerts to multiple similar servers in an automation @@ -862,57 +888,60 @@ physically separated backbone routers that can inject messages into different portions of the same larger LLN. 3) Publication of measurement data to more than one subscriber. This feature is useful in some peer to peer control applications. For example, level position may be useful to a controller that operates the flow valve and also to the overfill alarm indicator. Both controller and alarm indicator would receive the same publication sent as a multicast by the level gauge. - Both of these uses require an 1:N security mechanism as well; they + All of these uses require an 1:N security mechanism as well; they aren't of any use if the end-to-end security is only point-to-point. It is quite possible that first-generation wireless automation field networks can be adequately useful without either of these capabilities, but in the near future, wireless field devices with communication controllers and protocol stacks will require control and configuration, such as firmware downloading, that may benefit from broadcast or multicast addressing. - The routing protocol SHOULD support broadcast or multicast - addressing. + The routing protocol SHOULD support multicast addressing. -8. Route Establishment Time +8. Protocol Performance requirements - During network formation, installers with no networking skill must be - able to determine if their devices are "in the network" with - sufficient connectivity to perform their function. Installers will - have sufficient skill to provision the devices with a sample rate or - activity profile. The routing algorithm MUST find the appropriate - route(s) and report success or failure within several minutes, and - SHOULD report success or failure within tens of seconds. + The routing protocol MUST converge after the addition of a new device + within several minutes, and SHOULD converge within tens of seconds + such that a device is able to establish connectivity to any other + point in the network or determine that there is a connectivity issue. + Any routing algorithm used to determine how to route packets in the + network, MUST be capable of routing packets to and from a newly added + device within the several minutes of its addition, and SHOULD be able + to perform this function within tens of seconds. - 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 - recalculating the route in response to changing link statistics. The - routing algorithm MUST recalculate the paths when field devices - change due to insertion, removal or failure, and this recalculation - MUST NOT cause latencies greater than the specified constraints - (typically seconds to minutes). + The routing protocol MUST distribute sufficient information about + link failures to enable traffic to be routed such that all service + requirements (especially latency) continue to be met. This places a + requirement on the speed of distribution and convergence of this + information as well as the responsiveness of any routing algorithms + used to determine how to route packets. This requirement only + applies at normal link failure rates (see Section 5) and MAY degrade + during failure storms. -9. Mobility + Any algorithm that computes routes for packets in the network MUST be + able to perform route computations in advance of needing to use the + route. Since such algorithms are required to react to link failures, + link usage information, and other dynamic link properties as the + information is distributed by the routing protocol, the algorithms + SHOULD recompute route based on new the receipt of new information. + +9. Mobility requirements Various economic factors have contributed to a reduction of trained workers in the plant. The industry as a whole appears to be trying to solve this problem with what is called the "wireless worker". Carrying a PDA or something similar, this worker will be able to accomplish more work in less time than the older, better-trained workers that he or she replaces. Whether the premise is valid, the use case is commonly presented: the worker will be wirelessly connected to the plant IT system to download documentation, instructions, etc., and will need to be able to connect "directly" to @@ -936,68 +965,96 @@ device and the handheld device of the wireless worker. The routing protocol SHOULD support walking speeds for maintaining network connectivity as the handheld device changes position in the wireless network. Some field devices will be mobile. These devices may be located on moving parts such as rotating components or they may be located on vehicles such as cranes or fork lifts. The routing protocol SHOULD support vehicular speeds of up to 35 kmph. -10. Manageability +10. Manageability requirements The process and control industry is manpower constrained. The aging demographics of plant personnel are causing a looming manpower problem for industry across many markets. The goal for the industrial networks is to have the installation process not require any new skills for the plant personnel. The person would install the wireless sensor or wireless actuator the same way the wired sensor or wired actuator is installed, except the step to connect wire is eliminated. Most users in fact demand even much further simplified provisioning - methods, whereby automatically any new device will connect and report - at the LLN access point. This requires availability of open and - untrusted side channels for new joiners, and it requires strong and - automated authentication so that networks can automatically accept or - reject new joiners. Ideally, for a user, adding new devices should + methods, a plug and play operation that would be fully transparent to + the user. This requires availability of open and untrusted side + channels for new joiners, and it requires strong and automated + authentication so that networks can automatically accept or reject + new joiners. Ideally, for a user, adding new routing devices should be as easy as dragging and dropping an icon from a pool of authenticated new joiners into a pool for the wired domain that this new sensor should connect to. Under the hood, invisible to the user, auditable security mechanisms should take care of new device authentication, and secret join key distribution. These more sophisticated 'over the air' secure provisioning methods should eliminate the use of traditional configuration tools for setting up devices prior to being ready to securely join a LLN access point. + The routing protocol SHOULD be fully configurable over the air as + part of the joining process of a new routing device. + There will be many new applications where even without any human intervention at the plant, devices that have never been on site before, should be allowed, based on their credentials and crypto capabilities, to connect anyway. Examples are 3rd party road tankers, rail cargo containers with overfill protection sensors, or consumer cars that need to be refueled with hydrogen by robots at future petrol stations. The routing protocol for LLNs is expected to be easy to deploy and manage. Because the number of field devices in a network is large, - provisioning the devices manually may not make sense. The routing - MAY require commissioning of information about the node itself, like - identity, security tokens, radio standards and frequencies, etc. The - routing protocol SHOULD NOT require to preprovision information about - the environment where the node will be deployed. The routing + provisioning the devices manually may not make sense. The proper + operation of the routing protocol MAY require that the node be + commissioned with information about itself, like identity, security + tokens, radio standards and frequencies, etc... + + The routing protocol SHOULD NOT require to preprovision information + about the environment where the node will be deployed. The routing protocol MUST enable the full discovery and setup of the environment (available links, selected peers, reachable network).The protocol - also MUST support the distribution of configuration from a - centralized management controller if operator-initiated configuration - change is allowed. + MUST enable the distribution of its own configuration to be performed + by some external mechanism from a centralized management controller. -11. Security +11. Antagonistic requirements + + This document contains a number of strongly required constraints on + the ROLL routing protocol. Some of those strong requirements might + appear antagonistic and as such impossible to fulfill at a same time. + + For instance, the strong requirement of power economy applies on + general routing but is variant since it is reasonable to spend more + energy on ensuring the availability of a short emergency closed loop + path than it is to maintain an alert path that is used for regular + updates on the operating status of the device. In a same fashion, + the strong requirement on easy provisionning does not match easily + the strong security requirements that can be needed to implement a + factory policy. Then again, a non default non trivial setup can be + acceptable long as the default enables to join without configuration + and yet some degree of security. + + Convergence time and network size are also antagonistic. The values + expressed in the Protocol Performance requirements section apply to + an average network with tens of devices. The use of a backbone can + maintain that level of performance and still enable to grow the + network to thousands of node. In any case, it is acceptable to grow + reasonabily the convergence time with the network size. + +12. Security Considerations Given that wireless sensor networks in industrial automation operate in systems that have substantial financial and human safety implications, security is of considerable concern. Levels of security violation that are tolerated as a "cost of doing business" in the banking industry are not acceptable when in some cases literally thousands of lives may be at risk. Security is easily confused with guarantee for availability. When discussing wireless security, it's important to distinguish clearly @@ -1012,23 +1069,23 @@ wireless backdoors that may allow an attacker outside the fence to access typically non-secured process control and/or office networks, are typically the ones that do create exposures where lives are at risk. This implies that the LLN access point on its own must possess functionality that guarantees domain segregation, and thus prohibits many types of traffic further upstream. Current generation industrial wireless device manufactures are specifying security at the MAC layer and the transport layer. A shared key is used to authenticate messages at the MAC layer. At the - transport layer, commands are encrypted with unique randomly- - generated end-to-end Session keys. HART7 and ISA100.11a are examples - of security systems for industrial wireless networks. + transport layer, commands are encrypted with statistically unique + randomly-generated end-to-end Session keys. HART7 and ISA100.11a are + examples of security systems for industrial wireless networks. Although such symmetric key encryption and authentication mechanisms at MAC and transport layers may protect reasonably well during the lifecycle, the initial network boot (provisioning) step in many cases requires more sophisticated steps to securely land the initial secret keys in field devices. It is vital that also during these steps, the ease of deployment and the freedom of mixing and matching products from different suppliers does not complicate life for those that deploy and commission. Given average skill levels in the field, and given serious resource constraints in the market, investing a little @@ -1067,52 +1124,54 @@ the hardware of devices is outside of the scope this document. Note that because nodes are usually expected to be capable of routing, the end node security requirements are usually a superset of the router requirements, in order to prevent a end node from being used to inject forged information into the network that could alter the plant operations. Additional details of security across all application scenarios are provided in the ROLL security Framework - [I-D.tsao-roll-security-framework]. + [I-D.tsao-roll-security-framework]. Implications of these security + requirements for the routing protocol itself are a topic for future + work. -12. IANA Considerations +13. IANA Considerations This document includes no request to IANA. -13. Acknowledgements +14. Acknowledgements Many thanks to Rick Enns, Alexander Chernoguzov and Chol Su Kang for their contributions. -14. References +15. References -14.1. Normative References +15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. -14.2. Informative References +15.2. Informative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy - Networks", draft-ietf-roll-terminology-00 (work in - progress), October 2008. + Networks", draft-ietf-roll-terminology-01 (work in + progress), May 2009. [I-D.tsao-roll-security-framework] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", draft-tsao-roll-security-framework-00 (work in progress), February 2009. -14.3. External Informative References +15.3. External Informative References [HART] www.hartcomm.org, "Highway Addressable Remote Transducer", a group of specifications for industrial process and control devices administered by the HART Foundation". [ISA100.11a] ISA, "ISA100, Wireless Systems for Automation", May 2008, < http://www.isa.org/Community/ SP100WirelessSystemsforAutomation>.