< draft-ietf-roll-indus-routing-reqs-05.txt   draft-ietf-roll-indus-routing-reqs-06.txt >
Networking Working Group K. Pister, Ed. Networking Working Group K. Pister, Ed.
Internet-Draft Dust Networks Internet-Draft Dust Networks
Intended status: Informational P. Thubert, Ed. Intended status: Informational P. Thubert, Ed.
Expires: October 22, 2009 Cisco Systems Expires: December 7, 2009 Cisco Systems
S. Dwars S. Dwars
Shell Shell
T. Phinney T. Phinney
April 20, 2009 June 5, 2009
Industrial Routing Requirements in Low Power and Lossy Networks 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 October 22, 2009. This Internet-Draft will expire on December 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Applications and Traffic Patterns . . . . . . . . . . . . 5 3.1. Applications and Traffic Patterns . . . . . . . . . . . . 5
3.2. Network Topology of Industrial Applications . . . . . . . 8 3.2. Network Topology of Industrial Applications . . . . . . . 8
3.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10 3.2.1. The Physical Topology . . . . . . . . . . . . . . . . 10
3.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 12 3.2.2. Logical Topologies . . . . . . . . . . . . . . . . . . 12
4. Traffic Characteristics . . . . . . . . . . . . . . . . . . . 13 4. Requirements related to Traffic Characteristics . . . . . . . 13
4.1. Service Parameters . . . . . . . . . . . . . . . . . . . . 14 4.1. Service Requirements . . . . . . . . . . . . . . . . . . . 14
4.2. Configurable Application Requirement . . . . . . . . . . . 15 4.2. Configurable Application Requirement . . . . . . . . . . . 15
4.3. Different Routes for Different Flows . . . . . . . . . . . 15 4.3. Different Routes for Different Flows . . . . . . . . . . . 15
5. Reliability Requirements . . . . . . . . . . . . . . . . . . . 15 5. Reliability Requirements . . . . . . . . . . . . . . . . . . . 16
6. Device-Aware Routing Requirements . . . . . . . . . . . . . . 17 6. Device-Aware Routing Requirements . . . . . . . . . . . . . . 18
7. Broadcast/Multicast . . . . . . . . . . . . . . . . . . . . . 18 7. Broadcast/Multicast requirements . . . . . . . . . . . . . . . 19
8. Route Establishment Time . . . . . . . . . . . . . . . . . . . 19 8. Protocol Performance requirements . . . . . . . . . . . . . . 20
9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Mobility requirements . . . . . . . . . . . . . . . . . . . . 20
10. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Manageability requirements . . . . . . . . . . . . . . . . . . 21
11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Antagonistic requirements . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 24 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.3. External Informative References . . . . . . . . . . . . . 24 15.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 15.3. External Informative References . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Information Technology (IT) is already, and increasingly will be Information Technology (IT) is already, and increasingly will be
applied to industrial Control Technology (CT) in application areas applied to industrial Control Technology (CT) in application areas
where those IT technologies can be constrained sufficiently by where those IT technologies can be constrained sufficiently by
Service Level Agreements (SLA) or other modest change that they are Service Level Agreements (SLA) or other modest change that they are
able to meet the operational needs of industrial CT. When that able to meet the operational needs of industrial CT. When that
happens, the CT benefits from the large intellectual, experiential happens, the CT benefits from the large intellectual, experiential
and training investment that has already occurred in those IT and training investment that has already occurred in those IT
skipping to change at page 13, line 12 skipping to change at page 13, line 12
of the routes might range from minutes for a mobile workers to tens of the routes might range from minutes for a mobile workers to tens
of years for a command and control closed loop. Finally, time- of years for a command and control closed loop. Finally, time-
varying user requirements for latency and bandwidth will change the varying user requirements for latency and bandwidth will change the
constraints on the routes, which might either trigger a constrained constraints on the routes, which might either trigger a constrained
route recomputation, a reprovisioning of the underlying L2 protocols, route recomputation, a reprovisioning of the underlying L2 protocols,
or both in that order. For instance, a wireless worker may initiate or both in that order. For instance, a wireless worker may initiate
a bulk transfer to configure or diagnose a field device. A level 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 sensor device may need to perform a calibration and send a bulk file
to a plant. to a plant.
4. Traffic Characteristics 4. Requirements related to Traffic Characteristics
[ISA100.11a] selected IPv6 as its Network Layer for a number of [ISA100.11a] selected IPv6 as its Network Layer for a number of
reasons, including the huge address space and the large potential reasons, including the huge address space and the large potential
size of a subnet, which can range up to 10K nodes in a plant size of a subnet, which can range up to 10K nodes in a plant
deployment. In the ISA100 model, industrial applications fall into deployment. In the ISA100 model, industrial applications fall into
four large service categories: four large service categories:
1. Periodic data (aka buffered). Data that is generated 1. Periodic data (aka buffered). Data that is generated
periodically and has a well understood data bandwidth periodically and has a well understood data bandwidth
requirement, both deterministic and predictable. Timely delivery requirement, both deterministic and predictable. Timely delivery
skipping to change at page 14, line 5 skipping to change at page 14, line 5
milliseconds is typical. This type of request is statistically milliseconds is typical. This type of request is statistically
multiplexed over the LLN and cost-based fair-share best-effort multiplexed over the LLN and cost-based fair-share best-effort
service is usually expected. 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. Transient assigned to meet a transaction time constraint. Transient
resources are assigned for a limited time (related to file size resources are assigned for a limited time (related to file size
and data rate) to meet the bulk transfers service requirements. 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 The following service parameters can affect routing decisions in a
resource-constrained network: resource-constrained network:
o Data bandwidth - the bandwidth might be allocated permanently or o Data bandwidth - the bandwidth might be allocated permanently or
for a period of time to a specific flow that usually exhibits well for a period of time to a specific flow that usually exhibits well
defined properties of burstiness and throughput. Some bandwidth defined properties of burstiness and throughput. Some bandwidth
will also be statistically shared between flows in a best effort will also be statistically shared between flows in a best effort
fashion. fashion.
skipping to change at page 14, line 47 skipping to change at page 14, line 47
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.
The routing protocol MUST also support different metric types for The routing protocol MUST also support different metric types for
each link used to compute the path according to some objective each link used to compute the path according to some objective
function (e.g. minimize latency) depending on the nature of the function (e.g. minimize latency) depending on the nature of the
traffic. 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 compute and update constrained routes on demand, and it can be
expected that this model will become more prevalent for field device expected that this model will become more prevalent for field device
to field device connectivity as well as for some field device to to field device connectivity as well as for some field device to
Infrastructure devices over time. Infrastructure devices over time.
Industrial application data flows between field devices are not Industrial application data flows between field devices are not
necessarily symmetric. In particular, asymmetrical cost and necessarily symmetric. In particular, asymmetrical cost and
unidirectional routes are common for published data and alerts, which unidirectional routes are common for published data and alerts, which
represent the most part of the sensor traffic. The routing protocol represent the most part of the sensor traffic. The routing protocol
MUST be able to compute a set of unidirectional routes with MUST be able to compute a set of unidirectional routes with
potentially different costs that are composed of one or more non- potentially different costs that are composed of one or more non-
congruent paths. congruent paths.
As multiple paths are set up and a variety of flows traverse the 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 network towards a same destination, for instance a node acting as a
sink for the LLN, the use of an additional marking/tagging mechanism 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 routers to discriminate the flows and perform the appropriate routing
decision using only the content of the IPv6 packet (e.g. use of DSCP, decision using only the content of the IPv6 packet (e.g. use of DSCP,
Flow Label). Flow Label).
4.2. Configurable Application Requirement 4.2. Configurable Application Requirement
Time-varying user requirements for latency and bandwidth may require Time-varying user requirements for latency and bandwidth may require
changes in the provisioning of the underlying L2 protocols. A changes in the provisioning of the underlying L2 protocols. A
technician may initiate a query/response session or bulk transfer to technician may initiate a query/response session or bulk transfer to
diagnose or configure a field device. A level sensor device may need 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 to perform a calibration and send a bulk file to a plant. The
routing protocol MUST route on paths that are changed to routing protocol MUST support the ability to recompute paths based on
appropriately provision the application requirements. The routing Network Layer abstractions of the underlying link attributes/metric
protocol MUST support the ability to recompute paths based on Network that may change dynamically.
Layer abstractions of the underlying link attributes/metric that may
change dynamically.
4.3. Different Routes for Different Flows 4.3. Different Routes for Different Flows
Because different services categories have different service Because different services categories have different service
requirements, it is often desirable to have different routes for requirements, it is often desirable to have different routes for
different data flows between the same two endpoints. For example, different data flows between the same two endpoints. For example,
alarm or periodic data from A to Z may require path diversity with alarm or periodic data from A to Z may require path diversity with
specific latency and reliability. A file transfer between A and Z specific latency and reliability. A file transfer between A and Z
may not need path diversity. The routing algorithm MUST be able to 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...). 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 5. Reliability Requirements
LLN reliability constitutes several unrelated aspects: LLN reliability constitutes several unrelated aspects:
1) Availability of source to destination connectivity when the 1) Availability of source to destination connectivity when the
application needs it, expressed in number of succeses / number of application needs it, expressed in number of succeses / number of
attempts attempts
2) Availability of source to destination connectivity when the 2) Availability of source to destination connectivity when the
application might need it, expressed in number of potential application might need it, expressed in number of potential
skipping to change at page 18, line 39 skipping to change at page 19, line 13
non-critical parameter in an easily accessed location may have a non-critical parameter in an easily accessed location may have a
lifetime requirement that is shorter and tolerate more statistical lifetime requirement that is shorter and tolerate more statistical
variation than a mission-critical sensor in a hard-to-reach place variation than a mission-critical sensor in a hard-to-reach place
that requires a plant shutdown in order 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.
7. Broadcast/Multicast 7. Broadcast/Multicast requirements
Some existing industrial plant applications do not use broadcast or Some 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 for them. address support is sufficient for them.
In some other industrial process automation environments, multicast In some other industrial process automation environments, multicast
over IP is used to deliver to multiple nodes that may be over IP is used to deliver to multiple nodes that may be
functionally-similar or not. Example usages are: functionally-similar or not. Example usages are:
1) Delivery of alerts to multiple similar servers in an automation 1) Delivery of alerts to multiple similar servers in an automation
skipping to change at page 19, line 26 skipping to change at page 19, line 44
physically separated backbone routers that can inject messages physically separated backbone routers that can inject messages
into different portions of the same larger LLN. into different portions of the same larger LLN.
3) Publication of measurement data to more than one subscriber. 3) Publication of measurement data to more than one subscriber.
This feature is useful in some peer to peer control applications. This feature is useful in some peer to peer control applications.
For example, level position may be useful to a controller that For example, level position may be useful to a controller that
operates the flow valve and also to the overfill alarm indicator. operates the flow valve and also to the overfill alarm indicator.
Both controller and alarm indicator would receive the same Both controller and alarm indicator would receive the same
publication sent as a multicast by the level gauge. 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. 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 It is quite possible that first-generation wireless automation field
networks can be adequately useful without either of these networks can be adequately useful without either of these
capabilities, but in the near future, wireless field devices with capabilities, but in the near future, 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 and configuration, such as firmware downloading, that may benefit
from broadcast or multicast addressing. from broadcast or multicast addressing.
The routing protocol SHOULD support broadcast or multicast The routing protocol SHOULD support multicast addressing.
addressing.
8. Route Establishment Time 8. Protocol Performance requirements
During network formation, installers with no networking skill must be The routing protocol MUST converge after the addition of a new device
able to determine if their devices are "in the network" with within several minutes, and SHOULD converge within tens of seconds
sufficient connectivity to perform their function. Installers will such that a device is able to establish connectivity to any other
have sufficient skill to provision the devices with a sample rate or point in the network or determine that there is a connectivity issue.
activity profile. The routing algorithm MUST find the appropriate Any routing algorithm used to determine how to route packets in the
route(s) and report success or failure within several minutes, and network, MUST be capable of routing packets to and from a newly added
SHOULD report success or failure within tens of seconds. 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 The routing protocol MUST distribute sufficient information about
time constants from seconds to months. So long as the underlying link failures to enable traffic to be routed such that all service
connectivity has not been compromised, this link churn should not requirements (especially latency) continue to be met. This places a
substantially affect network operation. The routing algorithm MUST requirement on the speed of distribution and convergence of this
respond to normal link failure rates with routes that meet the information as well as the responsiveness of any routing algorithms
Service requirements (especially latency) throughout the routing used to determine how to route packets. This requirement only
response. The routing algorithm SHOULD always be in the process of applies at normal link failure rates (see Section 5) and MAY degrade
recalculating the route in response to changing link statistics. The during failure storms.
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).
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 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
skipping to change at page 21, line 5 skipping to change at page 21, line 28
device and the handheld device of the wireless worker. The routing device and the handheld device of the wireless worker. The routing
protocol SHOULD support walking speeds for maintaining network protocol SHOULD support walking speeds for maintaining network
connectivity as the handheld device changes position in the wireless connectivity as the handheld device changes position in the wireless
network. 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.
10. Manageability 10. Manageability requirements
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 have the installation process not require industrial networks is to have the installation process not require
any new skills for the plant personnel. The person would install the any new skills for the plant personnel. The person would install the
wireless sensor or wireless actuator the same way the wired sensor or wireless sensor or wireless actuator the same way the wired sensor or
wired actuator is installed, except the step to connect wire is wired actuator is installed, except the step to connect wire is
eliminated. eliminated.
Most users in fact demand even much further simplified provisioning Most users in fact demand even much further simplified provisioning
methods, whereby automatically any new device will connect and report methods, a plug and play operation that would be fully transparent to
at the LLN access point. This requires availability of open and the user. This requires availability of open and untrusted side
untrusted side channels for new joiners, and it requires strong and channels for new joiners, and it requires strong and automated
automated authentication so that networks can automatically accept or authentication so that networks can automatically accept or reject
reject new joiners. Ideally, for a user, adding new devices should new joiners. Ideally, for a user, adding new routing devices should
be as easy as dragging and dropping an icon from a pool of 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 authenticated new joiners into a pool for the wired domain that this
new sensor should connect to. Under the hood, invisible to the user, new sensor should connect to. Under the hood, invisible to the user,
auditable security mechanisms should take care of new device auditable security mechanisms should take care of new device
authentication, and secret join key distribution. These more authentication, and secret join key distribution. These more
sophisticated 'over the air' secure provisioning methods should sophisticated 'over the air' secure provisioning methods should
eliminate the use of traditional configuration tools for setting up eliminate the use of traditional configuration tools for setting up
devices prior to being ready to securely join a LLN access point. 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 There will be many new applications where even without any human
intervention at the plant, devices that have never been on site intervention at the plant, devices that have never been on site
before, should be allowed, based on their credentials and crypto before, should be allowed, based on their credentials and crypto
capabilities, to connect anyway. Examples are 3rd party road capabilities, to connect anyway. Examples are 3rd party road
tankers, rail cargo containers with overfill protection sensors, or tankers, rail cargo containers with overfill protection sensors, or
consumer cars that need to be refueled with hydrogen by robots at consumer cars that need to be refueled with hydrogen by robots at
future petrol stations. future petrol stations.
The routing protocol for LLNs is expected to be easy to deploy and 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, manage. Because the number of field devices in a network is large,
provisioning the devices manually may not make sense. The routing provisioning the devices manually may not make sense. The proper
MAY require commissioning of information about the node itself, like operation of the routing protocol MAY require that the node be
identity, security tokens, radio standards and frequencies, etc. The commissioned with information about itself, like identity, security
routing protocol SHOULD NOT require to preprovision information about tokens, radio standards and frequencies, etc...
the environment where the node will be deployed. The routing
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 protocol MUST enable the full discovery and setup of the environment
(available links, selected peers, reachable network).The protocol (available links, selected peers, reachable network). The protocol
also MUST support the distribution of configuration from a MUST enable the distribution of its own configuration to be performed
centralized management controller if operator-initiated configuration by some external mechanism from a centralized management controller.
change is allowed.
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 Given that wireless sensor networks in industrial automation operate
in systems that have substantial financial and human safety in systems that have substantial financial and human safety
implications, security is of considerable concern. Levels of implications, security is of considerable concern. Levels of
security violation that are tolerated as a "cost of doing business" security violation that are tolerated as a "cost of doing business"
in the banking industry are not acceptable when in some cases in the banking industry are not acceptable when in some cases
literally thousands of lives may be at risk. literally thousands of lives may be at risk.
Security is easily confused with guarantee for availability. When Security is easily confused with guarantee for availability. When
discussing wireless security, it's important to distinguish clearly discussing wireless security, it's important to distinguish clearly
skipping to change at page 22, line 34 skipping to change at page 23, line 38
wireless backdoors that may allow an attacker outside the fence to wireless backdoors that may allow an attacker outside the fence to
access typically non-secured process control and/or office networks, access typically non-secured process control and/or office networks,
are typically the ones that do create exposures where lives are at 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 risk. This implies that the LLN access point on its own must possess
functionality that guarantees domain segregation, and thus prohibits functionality that guarantees domain segregation, and thus prohibits
many types of traffic further upstream. many types of traffic further upstream.
Current generation industrial wireless device manufactures are Current generation industrial wireless device manufactures are
specifying security at the MAC layer and the transport layer. A specifying security at the MAC layer and the transport layer. A
shared key is used to authenticate messages at the MAC layer. At the shared key is used to authenticate messages at the MAC layer. At the
transport layer, commands are encrypted with unique randomly- transport layer, commands are encrypted with statistically unique
generated end-to-end Session keys. HART7 and ISA100.11a are examples randomly-generated end-to-end Session keys. HART7 and ISA100.11a are
of security systems for industrial wireless networks. examples of security systems for industrial wireless networks.
Although such symmetric key encryption and authentication mechanisms Although such symmetric key encryption and authentication mechanisms
at MAC and transport layers may protect reasonably well during the at MAC and transport layers may protect reasonably well during the
lifecycle, the initial network boot (provisioning) step in many cases lifecycle, the initial network boot (provisioning) step in many cases
requires more sophisticated steps to securely land the initial secret requires more sophisticated steps to securely land the initial secret
keys in field devices. It is vital that also during these steps, the keys in field devices. It is vital that also during these steps, the
ease of deployment and the freedom of mixing and matching products ease of deployment and the freedom of mixing and matching products
from different suppliers does not complicate life for those that from different suppliers does not complicate life for those that
deploy and commission. Given average skill levels in the field, and deploy and commission. Given average skill levels in the field, and
given serious resource constraints in the market, investing a little given serious resource constraints in the market, investing a little
skipping to change at page 23, line 41 skipping to change at page 24, line 46
the hardware of devices is outside of the scope this document. the hardware of devices is outside of the scope this document.
Note that because nodes are usually expected to be capable of Note that because nodes are usually expected to be capable of
routing, the end node security requirements are usually a superset of routing, the end node security requirements are usually a superset of
the router requirements, in order to prevent a end node from being the router requirements, in order to prevent a end node from being
used to inject forged information into the network that could alter used to inject forged information into the network that could alter
the plant operations. the plant operations.
Additional details of security across all application scenarios are Additional details of security across all application scenarios are
provided in the ROLL security Framework 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. This document includes no request to IANA.
13. Acknowledgements 14. Acknowledgements
Many thanks to Rick Enns, Alexander Chernoguzov and Chol Su Kang for Many thanks to Rick Enns, Alexander Chernoguzov and Chol Su Kang for
their contributions. 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 [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 15.2. Informative References
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-00 (work in Networks", draft-ietf-roll-terminology-01 (work in
progress), October 2008. progress), May 2009.
[I-D.tsao-roll-security-framework] [I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
Lozano, "A Security Framework for Routing over Low Power Lozano, "A Security Framework for Routing over Low Power
and Lossy Networks", draft-tsao-roll-security-framework-00 and Lossy Networks", draft-tsao-roll-security-framework-00
(work in progress), February 2009. (work in progress), February 2009.
14.3. External Informative References 15.3. External Informative References
[HART] www.hartcomm.org, "Highway Addressable Remote Transducer", [HART] www.hartcomm.org, "Highway Addressable Remote Transducer",
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[ISA100.11a] [ISA100.11a]
ISA, "ISA100, Wireless Systems for Automation", May 2008, ISA, "ISA100, Wireless Systems for Automation", May 2008,
< http://www.isa.org/Community/ < http://www.isa.org/Community/
SP100WirelessSystemsforAutomation>. SP100WirelessSystemsforAutomation>.
 End of changes. 35 change blocks. 
83 lines changed or deleted 142 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/