< draft-ietf-roll-rpl-industrial-applicability-00.txt   draft-ietf-roll-rpl-industrial-applicability-01.txt >
ROLL T. Phinney, Ed. ROLL T. Phinney, Ed.
Internet-Draft consultant Internet-Draft consultant
Intended status: Informational P. Thubert Intended status: Informational P. Thubert
Expires: September 13, 2013 Cisco Expires: March 11, 2014 cisco
RA. Assimiti RA. Assimiti
Nivis Nivis
March 12, 2013 September 09, 2013
RPL applicability in industrial networks RPL applicability in industrial networks
draft-ietf-roll-rpl-industrial-applicability-00 draft-ietf-roll-rpl-industrial-applicability-01
Abstract Abstract
The wide deployment of wireless devices, with their low installed The wide deployment of wireless devices, with their low installed
cost (compared to wired devices), will significantly improve the cost (compared to wired devices), will significantly improve the
productivity and safety of industrial plants. It will simultaneously productivity and safety of industrial plants. It will simultaneously
increase the efficiency and safety of the plant's workers, by increase the efficiency and safety of the plant's workers, by
extending and making more timely the information set available about extending and making more timely the information set available about
plant operations. The new Routing Protocol for Low Power and Lossy plant operations. The new Routing Protocol for Low Power and Lossy
Networks (RPL) defines a Distance Vector protocol that is designed Networks (RPL) defines a Distance Vector protocol that is designed
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 13, 2013. This Internet-Draft will expire on March 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Required Reading . . . . . . . . . . . . . . . . . . . . . 5 1.2. Required Reading . . . . . . . . . . . . . . . . . . . . . 4
1.3. Out of scope requirements . . . . . . . . . . . . . . . . 5 1.3. Out of scope requirements . . . . . . . . . . . . . . . . 4
2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 6 2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 5
2.1. Network Topologies . . . . . . . . . . . . . . . . . . . . 8 2.1. Network Topologies . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Traffic Characteristics . . . . . . . . . . . . . . . 8 2.1.1. Traffic Characteristics . . . . . . . . . . . . . . . 6
2.1.2. Topologies . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. Topologies . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Source-sink (SS) communication paradigm . . . . . . . 11 2.1.3. Source-sink (SS) communication paradigm . . . . . . . 10
2.1.4. Publish-subscribe (PS, or pub/sub) communication 2.1.4. Publish-subscribe (PS, or pub/sub) communication paradig 11
paradigm . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.5. Peer-to-peer (P2P) communication paradigm . . . . . . 13
2.1.5. Peer-to-peer (P2P) communication paradigm . . . . . . 14 2.1.6. Peer-to-multipeer (P2MP) communication paradigm . . . 14
2.1.6. Peer-to-multipeer (P2MP) communication paradigm . . . 15 2.1.7. Additional considerations: Duocast and N-cast . . . . 14
2.1.7. Additional considerations: Duocast and N-cast . . . . 15 2.1.8. RPL applicability per communication paradigm . . . . . 16
2.1.8. RPL applicability per communication paradigm . . . . . 17 2.2. Layer 2 applicability. . . . . . . . . . . . . . . . . . . 18
2.2. Layer 2 applicability. . . . . . . . . . . . . . . . . . . 19 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 18
3. Using RPL to Meet Functional Requirements . . . . . . . . . . 20 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 21
4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 21
4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 23 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 23
4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 25 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 26 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 26 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 25
4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 26 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 25
4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 27 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 26
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 28 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 26
4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 28 4.2. Layer-two features . . . . . . . . . . . . . . . . . . . . 26
4.2. Layer-two features . . . . . . . . . . . . . . . . . . . . 28 4.2.1. Need layer-2 expert here. . . . . . . . . . . . . . . 26
4.2.1. Need layer-2 expert here. . . . . . . . . . . . . . . 28 4.2.2. Security functions provided by layer-2. . . . . . . . 26
4.2.2. Security functions provided by layer-2. . . . . . . . 28 4.2.3. 6LowPAN options assumed. . . . . . . . . . . . . . . . 26
4.2.3. 6LowPAN options assumed. . . . . . . . . . . . . . . . 28 4.2.4. MLE and other things . . . . . . . . . . . . . . . . . 26
4.2.4. MLE and other things . . . . . . . . . . . . . . . . . 28 4.3. Recommended Configuration Defaults and Ranges . . . . . . 26
4.3. Recommended Configuration Defaults and Ranges . . . . . . 28 4.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 26
4.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 28 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . . 28
4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . . 29 5. Manageability Considerations . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
5. Manageability Considerations . . . . . . . . . . . . . . . . . 30 6.1. Security Considerations during initial deployment . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6.2. Security Considerations during incremental deployment . . 29
6.1. Security Considerations during initial deployment . . . . 31 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 29
6.2. Security Considerations during incremental deployment . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 10.3. External Informative References . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
10.3. External Informative References . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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 Automation and Control System (IACS) technology applied to Industrial Automation and Control System (IACS) technology
in application areas where those IT technologies can be constrained in application areas where those IT technologies can be constrained
sufficiently by Service Level Agreements (SLA) or other modest change sufficiently by Service Level Agreements (SLA) or other modest change
that they are able to meet the operational needs of IACS. When that that they are able to meet the operational needs of IACS. When that
happens, the IACS benefits from the large intellectual, experiential happens, the IACS 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 4, line 48 skipping to change at page 4, line 5
requirements for a LLN routing protocol, specified in: requirements for a LLN routing protocol, specified in:
Routing Requirements for Urban LLNs [RFC5548], Routing Requirements for Urban LLNs [RFC5548],
Industrial Routing Requirements in LLNs [RFC5673], Industrial Routing Requirements in LLNs [RFC5673],
Home Automation Routing Requirements in LLNs [RFC5826], and Home Automation Routing Requirements in LLNs [RFC5826], and
Building Automation Routing Requirements in LLNs [RFC5867]. Building Automation Routing Requirements in LLNs [RFC5867].
The Routing Protocol for Low Power and Lossy Networks (RPL) [RFC6550] The Routing Protocol for Low Power and Lossy Networks (RPL)
specification and its point to point extension/optimization [RFC6550] specification and its point to point extension/optimization
[I-D.ietf-roll-p2p-rpl] define a generic Distance Vector protocol [RFC6997] define a generic Distance Vector protocol that is adapted
that is adapted to a variety of Low Power and Lossy Networks (LLN) to a variety of Low Power and Lossy Networks (LLN) types by the
types by the application of specific Objective Functions (OFs). RPL application of specific Objective Functions (OFs). RPL forms
forms Destination Oriented Directed Acyclic Graphs (DODAGs) within Destination Oriented Directed Acyclic Graphs (DODAGs) within
instances of the protocol, each instance being associated with an instances of the protocol, each instance being associated with an
Objective Function to form a routing topology. Objective Function to form a routing topology.
A field device that belongs to an instance uses the OF to determine A field device that belongs to an instance uses the OF to determine
which DODAG and which Version of that DODAG the device should join. which DODAG and which Version of that DODAG the device should join.
The device also uses the OF to select a number of routers within the The device also uses the OF to select a number of routers within the
DODAG current and subsequent Versions to serve as parents or as DODAG current and subsequent Versions to serve as parents or as
feasible successors. A new Version of the DODAG is periodically feasible successors. A new Version of the DODAG is periodically
reconstructed to enable a global reoptimization of the graph. reconstructed to enable a global reoptimization of the graph.
skipping to change at page 5, line 33 skipping to change at page 4, line 39
industrial requirements for LLNs, in particular as specified in industrial requirements for LLNs, in particular as specified in
[RFC5673]. [RFC5673].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
Additionally, this document uses terminology from Additionally, this document uses terminology from [I-D.ietf-roll-
[I-D.ietf-roll-terminology], and uses usual terminology from the terminology], and uses usual terminology from the Process Control and
Process Control and Factory Automation industries, some of which is Factory Automation industries, some of which is recapitulated below:
recapitulated below:
FEC: Forward error correction FEC: Forward error correction
IACS: Industrial automation and control systems IACS: Industrial automation and control systems
RAND: reasonable and non-discriminatory (relative to licensing of RAND: reasonable and non-discriminatory (relative to licensing of
patents) patents)
1.2. Required Reading 1.2. Required Reading
skipping to change at page 6, line 40 skipping to change at page 5, line 40
P6: Post-emergency recovery and repair phase. P6: Post-emergency recovery and repair phase.
The deployment scenarios for wireless LLN devices may be different in The deployment scenarios for wireless LLN devices may be different in
each of these phases. In particular, during the Construction or each of these phases. In particular, during the Construction or
major modification phase (P1), LLN devices may be installed months major modification phase (P1), LLN devices may be installed months
before the intended LLN can become usefully operational (because before the intended LLN can become usefully operational (because
needed routers and infrastructure devices are not yet installed or needed routers and infrastructure devices are not yet installed or
active), and there are likely to be many personnel in whom the plant active), and there are likely to be many personnel in whom the plant
owner/operator has only limited trust, such as subcontractors and owner/operator has only limited trust, such as subcontractors and
others in the plant area who have undergone only a cursory background others in the plant area who have undergone only a cursory background
investigation (if any at all). In general, during this phase, plant investigation (if any at all). In general, during this phase, plant
instrumentation is not yet operational, so could be removed and instrumentation is not yet operational, so could be removed and
replaced by a Trojaned device without much likelihood of physical replaced by a Trojaned device without much likelihood of physical
detection of the substitution. Thus physical security of LLN devices detection of the substitution. Thus physical security of LLN devices
is generally a more significant risk factor during this phase than is generally a more significant risk factor during this phase than
once the plant is operational, where simple replacement of device once the plant is operational, where simple replacement of device
electronics is detectable. electronics is detectable.
Extra LLN devices and even extra LLN subnets may be employed during Extra LLN devices and even extra LLN subnets may be employed during
Planned startup (P2) and Planned shutdown (P4) phases, in support of Planned startup (P2) and Planned shutdown (P4) phases, in support of
the task of transitioning the plant or plant area between operational the task of transitioning the plant or plant area between operational
skipping to change at page 7, line 46 skipping to change at page 6, line 43
or employ an extended-axle heavy haul tractor-trailer to deliver a or employ an extended-axle heavy haul tractor-trailer to deliver a
multi-ton process vessel, and temporarily deploy and use very large multi-ton process vessel, and temporarily deploy and use very large
heavy-lift cranes to install it. In the former cases, nearby heavy-lift cranes to install it. In the former cases, nearby
equipment usually can continue normal operation while the equipment usually can continue normal operation while the
installation proceeds; in the latter case that is almost always installation proceeds; in the latter case that is almost always
impossible, due to safety and other concerns. impossible, due to safety and other concerns.
The domain of applicability for the RPL protocol may include all The domain of applicability for the RPL protocol may include all
phases but the Normal Operation phase, where the bandwidth allocation phases but the Normal Operation phase, where the bandwidth allocation
and the routes are usually optimized by an external Path Computing and the routes are usually optimized by an external Path Computing
Engine (PCE), e.g. an ISA100.11a System Manager. Engine (PCE), e.g. an ISA100.11a System Manager.
Additionally, it could be envisioned to include RPL in the normal Additionally, it could be envisioned to include RPL in the normal
operation provided that a new Objective Function is defined that operation provided that a new Objective Function is defined that
actually interacts with the PCE is order to establish the reference actually interacts with the PCE is order to establish the reference
topology, in which case RPL operations would only apply to emergency topology, in which case RPL operations would only apply to emergency
repair actions. when the reference topology becomes unusable for some repair actions. when the reference topology becomes unusable for
failure, and as long as the problem persists. some failure, and as long as the problem persists.
2.1. Network Topologies 2.1. Network Topologies
2.1.1. Traffic Characteristics 2.1.1. Traffic Characteristics
The industrial market classifies process applications into three The industrial market classifies process applications into three
broad categories and six classes. broad categories and six classes.
o Safety o Safety
skipping to change at page 9, line 6 skipping to change at page 7, line 45
In-time deliveries of messages becomes more relevant as the class In-time deliveries of messages becomes more relevant as the class
number decreases. number decreases.
Note that for a control application, the jitter is just as important Note that for a control application, the jitter is just as important
as latency and has a potential of destabilizing control algorithms. as latency and has a potential of destabilizing control algorithms.
The domain of applicability for the RPL protocol probably matches the The domain of applicability for the RPL protocol probably matches the
range of classes where industrial users are interested in deploying range of classes where industrial users are interested in deploying
wireless networks. This domain includes monitoring classes (4 and wireless networks. This domain includes monitoring classes (4 and
5), and the non-critical portions of control classes (2 and 3). RPL 5), and the non-critical portions of control classes (2 and 3). RPL
might also be considered as an additional repair mechanism in all might also be considered as an additional repair mechanism in all
situations, and independently of the flow classification and the situations, and independently of the flow classification and the
medium type. medium type.
It appears from the above sections that whether and the way RPL can It appears from the above sections that whether and the way RPL can
be applied for a given flow depends both on the deployment scenario be applied for a given flow depends both on the deployment scenario
and on the class of application / traffic. At a high level, this can and on the class of application / traffic. At a high level, this can
be summarized by the following matrix: be summarized by the following matrix:
+---------------------+------------------------------------------------+ +---------------------+------------------------------------------------+
| Phase \ Class | 0 1 2 3 4 5 | | Phase \ Class | 0 1 2 3 4 5 |
+=====================+================================================+ +=====================+================================================+
| Construction | X X X X | | Construction | X X X X |
+---------------------+------------------------------------------------+ +---------------------+------------------------------------------------+
| Planned startup | X X X X | | Planned startup | X X X X |
+---------------------+------------------------------------------------+ +---------------------+------------------------------------------------+
| Normal operation | ? ? ? | | Normal operation | ? ? ? |
+---------------------+------------------------------------------------+ +---------------------+------------------------------------------------+
| Planned shutdown | X X X X | | Planned shutdown | X X X X |
+---------------------+------------------------------------------------+ +---------------------+------------------------------------------------+
|Plant decommissioning| X X X X | |Plant decommissioning| X X X X |
+---------------------+------------------------------------------------+ +---------------------+------------------------------------------------+
| Recovery and repair | X X X X X X | | Recovery and repair | X X X X X X |
+---------------------+------------------------------------------------+ +---------------------+------------------------------------------------+
? : typically usable for all but higher-rate classes 0,1 PS traffic
Figure 1: RPL applicability matrix ? : typically usable for all but higher-rate classes 0,1 PS traffic
2.1.2. Topologies 2.1.2. Topologies
In an IACS, high-rate communications flows (e.g., 1 Hz or 4 Hz for a In an IACS, high-rate communications flows (e.g., 1 Hz or 4 Hz for a
traditional process automation network) typically are such that only traditional process automation network) typically are such that only
a single wireless LLN hop separates the source device from a LLN a single wireless LLN hop separates the source device from a LLN
Border Router (LBR) to a significantly higher data-rate backbone Border Router (LBR) to a significantly higher data-rate backbone
network, typically based on IEEE 802.3, IEEE 802.11, or IEEE 802.16, network, typically based on IEEE 802.3, IEEE 802.11, or IEEE 802.16,
as illustrated in Figure 2. as illustrated in Figure 2.
---+------------------------ ---+------------------------
| Plant Network | Plant Network
| |
+-----+ +-----+
| | Gateway | | Gateway
| | | |
+-----+ +-----+
| |
| Backbone | Backbone
+--------------------+------------------+ +--------------------+------------------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | LLN border | | LLN border | | LLN border | | LLN border | | LLN border | | LLN border
o | | router | | router | | router o | | router | | router | | router
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o
LLN LLN
o : stationary wireless field device, seldom acting as an LLN router o : stationary wireless field device, seldom acting as an LLN router
Figure 2: High-rate low-delay low-variance IACS topology
For factory automation networks, the basic communications cycle for For factory automation networks, the basic communications cycle for
control is typically much faster, on the order of 100 Hz or more. In control is typically much faster, on the order of 100 Hz or more. In
this case the LLN itself may be based on high-data-rate IEEE 802.11 this case the LLN itself may be based on high-data-rate IEEE 802.11
or a 100 Mbit/s or faster optical link, and the higher-rate network or a 100 Mbit/s or faster optical link, and the higher-rate network
used by the LBRs to connect the LLN to superior automation equipment used by the LBRs to connect the LLN to superior automation equipment
typically might be based on fiber-optic IEEE 802.3, with multiple typically might be based on fiber-optic IEEE 802.3, with multiple
LBRs around the periphery of the factory area, so that most high-rate LBRs around the periphery of the factory area, so that most high-rate
communications again requires only a single wireless LLN hop. communications again requires only a single wireless LLN hop.
Multi-hop LLN routing is used within the LLN portion of such networks Multi-hop LLN routing is used within the LLN portion of such networks
to provide backup communications paths when primary single-hop LLN to provide backup communications paths when primary single-hop LLN
paths fail, or for lower repetition rate communications where longer paths fail, or for lower repetition rate communications where longer
LLN transit times and higher variance are not an issue. Typically, LLN transit times and higher variance are not an issue. Typically,
the majority of devices in an IACS can tolerate such higher-delay the majority of devices in an IACS can tolerate such higher-delay
higher-variance paths, so routing choices often are driven by energy higher-variance paths, so routing choices often are driven by energy
considerations for the affected devices, rather than simply by IACS considerations for the affected devices, rather than simply by IACS
performance requirements, as illustrated in Figure 3. performance requirements, as illustrated in Figure 3.
---+------------------------ ---+------------------------
| Plant Network | Plant Network
| |
+-----+ +-----+
| | Gateway | | Gateway
| | | |
+-----+ +-----+
| |
| Backbone | Backbone
skipping to change at page 11, line 26 skipping to change at page 10, line 26
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone | | Backbone | | Backbone | | Backbone
| | router | | router | | router | | router | | router | | router
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o M o o o o o o o o o o o o o o o o M o o o o o
o o M o o o o o o o o o o o o o o o M o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o
o o o o o o o o o o
LLN LLN
o : stationary wireless field device, often acting as an LLN router o : stationary wireless field device, often acting as an LLN router
M : mobile wireless device M : mobile wireless device
Figure 3: Low-rate higher-delay higher-variance IACS topology
Two decades of experience with digital fieldbuses has shown that four Two decades of experience with digital fieldbuses has shown that four
communications paradigms dominate in IACS: communications paradigms dominate in IACS:
SS: Source-sink SS: Source-sink
PS: Publish-subscribe PS: Publish-subscribe
P2P: Peer-to-peer P2P: Peer-to-peer
P2MP: Peer-to-multipeer P2MP: Peer-to-multipeer
2.1.3. Source-sink (SS) communication paradigm 2.1.3. Source-sink (SS) communication paradigm
In SS, the source-sink communication paradigm, each of many devices In SS, the source-sink communication paradigm, each of many devices
in one set, S1, sends UDP-like messages, usually infrequently and in one set, S1, sends UDP-like messages, usually infrequently and
intermittently, to a second set of devices, S2, determined by a intermittently, to a second set of devices, S2, determined by a
common multicast address. A typical example would be that all common multicast address. A typical example would be that all
devices within a given process unit N are configured to send process devices within a given process unit N are configured to send process
alarm messages to the multicast address alarm messages to the multicast address
Receivers_of_process_alarms_for_unit_N. Receiving devices, typically Receivers_of_process_alarms_for_unit_N. Receiving devices, typically
skipping to change at page 12, line 19 skipping to change at page 11, line 16
communication. When the SS traffic conveys process alarms or device communication. When the SS traffic conveys process alarms or device
alerts, there is often a contractual requirement, and sometimes even alerts, there is often a contractual requirement, and sometimes even
a regulatory requirement, on the maximum end-to-end transit delay of a regulatory requirement, on the maximum end-to-end transit delay of
the SS message, including both the LLN and non-LLN components of that the SS message, including both the LLN and non-LLN components of that
delay. However, there is no requirement on relative jitter in the delay. However, there is no requirement on relative jitter in the
delivery of multiple SS messages from the same source, and message delivery of multiple SS messages from the same source, and message
reordering during transit is irrelevant. reordering during transit is irrelevant.
Within the LLN, the SS paradigm simply requires that messages so Within the LLN, the SS paradigm simply requires that messages so
addressed be forwarded to the responsible LBR (or set of equivalent addressed be forwarded to the responsible LBR (or set of equivalent
LBRs) for further forwarding outside the LLN. Within the LLN such LBRs) for further forwarding outside the LLN. Within the LLN such
traffic typically is device-to-LBR or device-to-redundant-set-of- traffic typically is device-to-LBR or device-to-redundant-set-of-
equivalent-LBRs. In general, SS traffic may be aggregated before equivalent-LBRs. In general, SS traffic may be aggregated before
forwarding when both the multicast destination address and other QoS forwarding when both the multicast destination address and other QoS
attributes are identical. If information on the target delivery attributes are identical. If information on the target delivery
times for SS messages is available to the aggregating forwarding times for SS messages is available to the aggregating forwarding
device, that device may intentionally delay forwarding somewhat to device, that device may intentionally delay forwarding somewhat to
facilitate further aggregation, which can significantly reduce LLN facilitate further aggregation, which can significantly reduce LLN
alarm-reporting traffic during major plant upset events. alarm-reporting traffic during major plant upset events.
2.1.4. Publish-subscribe (PS, or pub/sub) communication paradigm 2.1.4. Publish-subscribe (PS, or pub/sub) communication paradigm
skipping to change at page 13, line 32 skipping to change at page 12, line 26
relative matter. PS messaging is used for transfer of process relative matter. PS messaging is used for transfer of process
measurements and associated status from sensors to control measurements and associated status from sensors to control
computation elements, from control computation elements to actuators, computation elements, from control computation elements to actuators,
and of current commanded position and status from actuators back to and of current commanded position and status from actuators back to
control computation elements. The actual time interval of interest control computation elements. The actual time interval of interest
is that which starts with sensing of the physical process (which is that which starts with sensing of the physical process (which
necessarily occurs before the sensed value can be sent in the first necessarily occurs before the sensed value can be sent in the first
message) and which ends when the computed control correction is message) and which ends when the computed control correction is
applied to the physical process by the appropriate actuator (which applied to the physical process by the appropriate actuator (which
cannot occur until after the second message containing the computed cannot occur until after the second message containing the computed
control output has been received by that actuator). With rare control output has been received by that actuator). With rare
exception, the control algorithms used with PS messaging in the exception, the control algorithms used with PS messaging in the
process automation industries - those managing continuous material process automation industries - those managing continuous material
flows - rely on fixed-period sampling, computation and transfer of flows - rely on fixed-period sampling, computation and transfer of
outputs, while those in the factory automation industries - those outputs, while those in the factory automation industries - those
managing discrete manufacturing operations - rely on bounded delay managing discrete manufacturing operations - rely on bounded delay
between sampling of inputs, control computation and transfer of between sampling of inputs, control computation and transfer of
outputs to physical actuators that affect the controlled process. outputs to physical actuators that affect the controlled process.
Deliberately manipulated message delay and jitter in delivery of PS Deliberately manipulated message delay and jitter in delivery of PS
messaging has the potential to destabilize control loops. It is the messaging has the potential to destabilize control loops. It is the
skipping to change at page 14, line 7 skipping to change at page 13, line 7
jittered messages at delivery, converting them into instances of jittered messages at delivery, converting them into instances of
message loss. Thus network and data-link protocols such as IPv6 and message loss. Thus network and data-link protocols such as IPv6 and
Ethernet need not themselves address such issues, although their Ethernet need not themselves address such issues, although their
selection and employment should take the existence (or lack) of such selection and employment should take the existence (or lack) of such
higher-layer protection mechanisms, and the resulting consequences higher-layer protection mechanisms, and the resulting consequences
due to excessive delay and jitter, into consideration in their due to excessive delay and jitter, into consideration in their
parameterization. parameterization.
In general, PS traffic within the LLN is not aggregated before In general, PS traffic within the LLN is not aggregated before
forwarding, to minimize message loss and delay in reception by any forwarding, to minimize message loss and delay in reception by any
relevant controller(s) that are outside the LLN. However, if all relevant controller(s) that are outside the LLN. However, if all
intended destination controllers are within the LLN, and at least one intended destination controllers are within the LLN, and at least one
of those intended controllers also serves as an LLN router on a DODAG of those intended controllers also serves as an LLN router on a DODAG
to off-LLN destinations that all are not controllers, then the router to off-LLN destinations that all are not controllers, then the router
functions in that device may aggregate PS traffic before forwarding functions in that device may aggregate PS traffic before forwarding
when the required routing and other QoS attributes are identical. If when the required routing and other QoS attributes are identical. If
information on the target delivery times for PS messages to non- information on the target delivery times for PS messages to non-
controller devices is available to the aggregating forwarding device, controller devices is available to the aggregating forwarding device,
that device may intentionally delay forwarding somewhat to facilitate that device may intentionally delay forwarding somewhat to facilitate
further aggregation. further aggregation.
In some system architectures, message streams that use PS to convey In some system architectures, message streams that use PS to convey
current process measurements and status are compressed at the source current process measurements and status are compressed at the source
through a 2-dimensional winnowing process that compares through a 2-dimensional winnowing process that compares
1) the process measurement values and status of the about-to-be-sent 1) the process measurement values and status of the about-to-be-sent
message with that of the last actually-sent message, and message with that of the last actually-sent message, and
2) the current time vs. the queueing time for the last actually-sent 2) the current time vs. the queueing time for the last actually-sent
message. message.
If the interval since that last-sent message is less than a If the interval since that last-sent message is less than a
predefined maximum time, and the status is unchanged, and the process predefined maximum time, and the status is unchanged, and the process
measurement(s) conveyed in the message is within predefined measurement(s) conveyed in the message is within predefined
deadband(s) of the last-sent measurement value(s), then transmission deadband(s) of the last-sent measurement value(s), then transmission
of the new message is suppressed. Often this suppression takes the of the new message is suppressed. Often this suppression takes the
form of not queuing the new message for transmission, but in some form of not queuing the new message for transmission, but in some
protocols a brief placeholder message indicating "no significant protocols a brief placeholder message indicating "no significant
change" is queued in its stead. change" is queued in its stead.
skipping to change at page 15, line 14 skipping to change at page 14, line 18
a consequence, in general, message aggregation is permitted, although a consequence, in general, message aggregation is permitted, although
few opportunities are likely to present themselves for such few opportunities are likely to present themselves for such
aggregation due to the sporadic nature of such messaging to a single aggregation due to the sporadic nature of such messaging to a single
destination, and/or due to the large message payloads that often destination, and/or due to the large message payloads that often
occur in at least one direction of transmission. occur in at least one direction of transmission.
2.1.6. Peer-to-multipeer (P2MP) communication paradigm 2.1.6. Peer-to-multipeer (P2MP) communication paradigm
In P2MP, the peer-to-multipeer communication paradigm, a device sends In P2MP, the peer-to-multipeer communication paradigm, a device sends
UDP-like messages downward, from one device (D1) to a set of other UDP-like messages downward, from one device (D1) to a set of other
devices (Dn). Typical examples are bulk downloads to a set of devices (Dn). Typical examples are bulk downloads to a set of devices
devices that use identical code image segments or identically- that use identical code image segments or identically-structured
structured database segments; group commands to enable device state database segments; group commands to enable device state transitions
transitions that are quasi-synchronized across all or part of the that are quasi-synchronized across all or part of the local network
local network (e.g., switch to the next set of point-to-point (e.g., switch to the next set of point-to-point downloaded session
downloaded session keys, or notifying that the network is switching keys, or notifying that the network is switching to an emergency
to an emergency repair and recovery mode); etc. Multicast addressing repair and recovery mode); etc. Multicast addressing is used in the
is used in the downward direction of data flow. downward direction of data flow.
Devices can be assigned to a number of multicast groups, for instance Devices can be assigned to a number of multicast groups, for instance
by device type. Then, if it becomes necessary to reflash all devices by device type. Then, if it becomes necessary to reflash all devices
of a given type with a new load image, a multicast distribution of a given type with a new load image, a multicast distribution
mechanism can be leveraged to optimize the distribution operation. mechanism can be leveraged to optimize the distribution operation.
In general, P2MP traffic has only loose timeliness requirements. As In general, P2MP traffic has only loose timeliness requirements. As
a consequence, in general, message aggregation is permitted, although a consequence, in general, message aggregation is permitted, although
few opportunities are likely to present themselves for such few opportunities are likely to present themselves for such
aggregation due to the sporadic nature of such messaging to a single aggregation due to the sporadic nature of such messaging to a single
skipping to change at page 15, line 48 skipping to change at page 15, line 4
P2MP messaging. P2MP messaging.
Note: Reliable group download protocols, such as the no-longer- Note: Reliable group download protocols, such as the no-longer-
published IEEE 802.1E (ISO/IEC 15802-4) system load protocol, and published IEEE 802.1E (ISO/IEC 15802-4) system load protocol, and
reliable multicast protocols based on the guidance of [RFC2887], are reliable multicast protocols based on the guidance of [RFC2887], are
instructive in how P2MP can be used for initial bulk download, instructive in how P2MP can be used for initial bulk download,
followed by either P2MP or P2P selective retransmissions for missed followed by either P2MP or P2P selective retransmissions for missed
download segments. download segments.
2.1.7. Additional considerations: Duocast and N-cast 2.1.7. Additional considerations: Duocast and N-cast
In industrial automation systems, some traffic is from (relatively) In industrial automation systems, some traffic is from (relatively)
high-rate monitoring and control loops, of Class 0 and Class 1 as high-rate monitoring and control loops, of Class 0 and Class 1 as
described in [RFC5673]. In such systems, the wireless link protocol, described in [RFC5673]. In such systems, the wireless link protocol,
which typically uses immediate in-band acknowledgement to confirm which typically uses immediate in-band acknowledgement to confirm
delivery (or, on failure, conclude that a retransmission is delivery (or, on failure, conclude that a retransmission is
required), can be adapted to attempt simultaneous delivery to more required), can be adapted to attempt simultaneous delivery to more
than one receiving device, with separated, sequenced immediate in- than one receiving device, with separated, sequenced immediate in-
band acknowledgement by each of those intended receivers. (This band acknowledgement by each of those intended receivers. (This
mechanism is known colloquially as "duocast" (for two intended mechanism is known colloquially as "duocast" (for two intended
receivers), or more generically as "N-cast" (for N intended receivers), or more generically as "N-cast" (for N intended
receivers).) Transmission is deemed successful if at least one such receivers).) Transmission is deemed successful if at least one such
immediate acknowledgement is received by the sending device; immediate acknowledgement is received by the sending device;
otherwise the device queues the message for retransmission, up until otherwise the device queues the message for retransmission, up until
the maximum configured number of retries has been attempted. the maximum configured number of retries has been attempted.
The logic behind duocast/N-cast is very simple: In wireless systems The logic behind duocast/N-cast is very simple: In wireless systems
without FEC (forward error correction), the overall rate of success without FEC (forward error correction), the overall rate of success
for transactions consisting of an initial transmission and an for transactions consisting of an initial transmission and an
immediate acknowledgement is typically 95%. In other words, 5% of immediate acknowledgement is typically 95%. In other words, 5% of
such transactions fail, either because the initial message of the such transactions fail, either because the initial message of the
transaction is not received correctly by the intended receiver, or transaction is not received correctly by the intended receiver, or
because the immediate acknowledgment by that receiver is not received because the immediate acknowledgment by that receiver is not received
correctly by the transaction initiator. correctly by the transaction initiator.
In the generalized case of N-cast, where any received acknowledgement In the generalized case of N-cast, where any received acknowledgement
serves to complete the transaction, and where the N intended serves to complete the transaction, and where the N intended
receivers are spatially diverse, physically separated from each other receivers are spatially diverse, physically separated from each other
by multiple wavelengths, the probability that all such receivers fail by multiple wavelengths, the probability that all such receivers fail
to receive the initial message of the transaction, or that all to receive the initial message of the transaction, or that all
skipping to change at page 16, line 50 skipping to change at page 15, line 53
automation environment of class 1 process control loops, which automation environment of class 1 process control loops, which
typically repeat at a 1 Hz or 4 Hz rate, in a very large process typically repeat at a 1 Hz or 4 Hz rate, in a very large process
plant with thousands of field devices reporting at that rate, the plant with thousands of field devices reporting at that rate, the
maximum number of transmission retries that must be planned, and for maximum number of transmission retries that must be planned, and for
which capacity must be scheduled (within the requisite 250 ms or 1 s which capacity must be scheduled (within the requisite 250 ms or 1 s
interval) is seven (7) retries for unicast PS reporting, but only interval) is seven (7) retries for unicast PS reporting, but only
three (3) retries with duocast PS reporting. (This is determined by three (3) retries with duocast PS reporting. (This is determined by
the requirement to not miss four successive reports more than once the requirement to not miss four successive reports more than once
per year, across the entire plant, as such a loss typically triggers per year, across the entire plant, as such a loss typically triggers
fallback behavior in the controlled loop, which is considered a fallback behavior in the controlled loop, which is considered a
failure of the wireless system by the plant owner/operator.) In failure of the wireless system by the plant owner/operator.) In
practice, the enormous reduction in both planned and used practice, the enormous reduction in both planned and used
retransmission capacity provided by duocast/N-cast is what enables retransmission capacity provided by duocast/N-cast is what enables 4
4 Hz loops to be supported in large wireless systems. Hz loops to be supported in large wireless systems.
When available, duocast/N-cast typically is used only for one-hop PS When available, duocast/N-cast typically is used only for one-hop PS
traffic on Class 1 and Class 0 control loops. It may also be traffic on Class 1 and Class 0 control loops. It may also be
employed for rapid, reliable one-hop delivery of Class 0 and employed for rapid, reliable one-hop delivery of Class 0 and
sometimes Class 1 process alarms and device alerts, which use the SS sometimes Class 1 process alarms and device alerts, which use the SS
paradigm. Because it requires scheduling of multiple receivers that paradigm. Because it requires scheduling of multiple receivers that
are prepared to acknowledge the received message during the are prepared to acknowledge the received message during the
transaction, in general it is not appropriate for the other types of transaction, in general it is not appropriate for the other types of
traffic in such systems - P2P and P2MP - and is not needed for other traffic in such systems - P2P and P2MP - and is not needed for other
classes of control loops or other types of traffic, which do not have classes of control loops or other types of traffic, which do not have
skipping to change at page 17, line 39 skipping to change at page 16, line 38
not employed, the wireless retransmission capacity that is needed to not employed, the wireless retransmission capacity that is needed to
support such fast loops often is excessive, typically over 100x that support such fast loops often is excessive, typically over 100x that
actually used for retransmission (i.e., providing for seven retries actually used for retransmission (i.e., providing for seven retries
per transaction when the mean number used is only 0.06 retries). per transaction when the mean number used is only 0.06 retries).
2.1.8. RPL applicability per communication paradigm 2.1.8. RPL applicability per communication paradigm
To match the requirements above, RPL provides a number of RPL Modes To match the requirements above, RPL provides a number of RPL Modes
of Operation (MOP): of Operation (MOP):
No downward route: defined in [RFC6550], section 6.3.1, MOP of 0. No downward route: defined in [RFC6550], section 6.3.1, MOP of 0.
This mode allows only upward routing, that is from nodes (devices) This mode allows only upward routing, that is from
that reside inside the RPL network toward the outside via the nodes (devices) that reside inside the RPL network
DODAG root. toward the outside via the DODAG root.
Non-storing mode: defined in [RFC6550], section 6.3.1, MOP of 1. Non-storing mode: defined in [RFC6550], section 6.3.1, MOP of 1. This
This mode improves MOP 0 by adding the capability to use source mode improves MOP 0 by adding the capability to use
routing from the root towards registered targets within the source routing from the root towards registered
instance DODAG. targets within the instance DODAG.
Storing mode without multicast support: defined in [RFC6550], Storing mode without multicast support: defined in [RFC6550], section
section 6.3.1, MOP of 2. This mode improves MOP 0 by adding the 6.3.1, MOP of 2. This mode
capability to use stateful routing from the root towards improves MOP 0 by adding the
registered targets within the instance DODAG. capability to use stateful
routing from the root towards
registered targets within the
instance DODAG.
Storing mode with link-scope multicast DAO: defined in [RFC6550] Storing mode with link-scope multicast DAO: defined in [RFC6550]
section 9.10, this mode improves MOP 2 by adding the capability to section 9.10, this mode
send Destination Advertisements to all nodes over a single Layer 2 improves MOP 2 by adding
link (e.g. a wireless hop) and enables line-of-sight direct the capability to send
communication. Destination
Advertisements to all
nodes over a single Layer
2 link (e.g. a wireless
hop) and enables line-of-
sight direct
communication.
Storing mode with multicast support: defined in [RFC6550], Mode-of- Storing mode with multicast support: defined in [RFC6550], Mode-of-
operation (MOP) of 3. This mode improves MOP 2 by adding the operation (MOP) of 3. This mode
capability to register multicast groups and perform multicast improves MOP 2 by adding the
forwarding along the instance DODAG (or a spanning subtree within capability to register multicast
the DODAG). groups and perform multicast
forwarding along the instance
DODAG (or a spanning subtree
within the DODAG).
Reactive: defined in [I-D.ietf-roll-p2p-rpl], the reactive mode Reactive: defined in [RFC6997], the reactive mode creates on-demand
creates on-demand additional DAGs that are used to reach a given additional DAGs that are used to reach a given node acting
node acting as DODAG root within a certain number of hops. This as DODAG root within a certain number of hops. This mode
mode can typically be used for an ad-hoc closed-loop can typically be used for an ad-hoc closed-loop
communication. communication.
The RPL MOP that can be applied for a given flow depends on the The RPL MOP that can be applied for a given flow depends on the
communication paradigm. It must be noted that a DODAG that is used communication paradigm. It must be noted that a DODAG that is used
for PS traffic can also be used for SS traffic since the MOP 2 for PS traffic can also be used for SS traffic since the MOP 2
extends the MOP 0, and that a DODAG that is used for P2MP extends the MOP 0, and that a DODAG that is used for P2MP
distribution can also be used for downward PS since the MOP 3 extends distribution can also be used for downward PS since the MOP 3 extends
the MOP 2. the MOP 2.
On the other hand, an Objective Function (OF) that optimizes metrics On the other hand, an Objective Function (OF) that optimizes metrics
for a pure upwards DODAG might differ from the OF that optimizes a for a pure upwards DODAG might differ from the OF that optimizes a
mixed upward and downward DODAG. mixed upward and downward DODAG.
As a result, it can be expected that different RPL instances are As a result, it can be expected that different RPL instances are
installed with different OFs, different channel allocations, etc... installed with different OFs, different channel allocations, etc...
that result in different routing and forwarding topologies, sometimes that result in different routing and forwarding topologies, sometimes
with differing delay vs. energy profiles, optimized separately for with differing delay vs. energy profiles, optimized separately for
the different flows at hand. the different flows at hand.
This can be broadly summarized in the following table: This can be broadly summarized in the following table:
+---------------------+------------+-----------------------------------+ +---------------------+------------+-----------------------------------+
| Paradigm\RPL MOP | RPL spec | Mode of operation | | Paradigm\RPL MOP | RPL spec | Mode of operation |
+=====================+============+===================================+ +=====================+============+===================================+
| Peer-to-peer | RPL P2P | reactive (on-demand) | | Peer-to-peer | RPL P2P | reactive (on-demand) |
+---------------------+------------+-----------------------------------+ +---------------------+------------+-----------------------------------+
| P2P line-of-sight | RPL base | 2 (storing) with multicast DAO | | P2P line-of-sight | RPL base | 2 (storing) with multicast DAO |
+---------------------+------------+-----------------------------------+ +---------------------+------------+-----------------------------------+
| P2MP distribution | RPL base | 3 (storing with multicast) | | P2MP distribution | RPL base | 3 (storing with multicast) |
+---------------------+------------+-----------------------------------+ +---------------------+------------+-----------------------------------+
| Publish-subscribe | RPL base | 1 or 2 (storing or not-storing) | | Publish-subscribe | RPL base | 1 or 2 (storing or not-storing) |
+---------------------+------------+-----------------------------------+ +---------------------+------------+-----------------------------------+
| Source-sink | RPL base | 0 (no downward route) | | Source-sink | RPL base | 0 (no downward route) |
+---------------------+------------+-----------------------------------+ +---------------------+------------+-----------------------------------+
| N-cast publish | RPL base | 0 (no downward route) | | N-cast publish | RPL base | 0 (no downward route) |
+---------------------+------------+-----------------------------------+ +---------------------+------------+-----------------------------------+
Figure 4: RPL applicability per communication paradigm
2.2. Layer 2 applicability. 2.2. Layer 2 applicability.
To be completed. To be completed.
3. Using RPL to Meet Functional Requirements 3. Using RPL to Meet Functional Requirements
The functional requirements for most industrial automation The functional requirements for most industrial automation
deployments are similar to those listed in [RFC5673] deployments are similar to those listed in [RFC5673]
skipping to change at page 20, line 22 skipping to change at page 19, line 15
corresponding to partitions of the automated process, each corresponding to partitions of the automated process, each
containing on the order of 30 to 3000 nodes. containing on the order of 30 to 3000 nodes.
The routing protocol MUST provide mechanisms to support The routing protocol MUST provide mechanisms to support
configuration of the routing protocol itself. configuration of the routing protocol itself.
The routing protocol MUST provide mechanisms to support instructed The routing protocol MUST provide mechanisms to support instructed
configuration of explicit routing, so that in the absence of configuration of explicit routing, so that in the absence of
failure the routing used for selected flow classes is that which failure the routing used for selected flow classes is that which
has been remotely configured (typically by a centralized has been remotely configured (typically by a centralized
configurator). In such circumstances RPL is used configurator). In such circumstances RPL is used
for local network repair; for local network repair;
for flow classes to which explicit routing has not been for flow classes to which explicit routing has not been
assigned; assigned;
during bootstrapping of the network itself (which is really during bootstrapping of the network itself (which is really
just an instance of routing without such an externally-imposed just an instance of routing without such an externally-imposed
assignment). assignment).
The routing protocol SHOULD support directed flows with different The routing protocol SHOULD support directed flows with different
QoS characteristics, typically with different energy vs. delay QoS characteristics, typically with different energy vs. delay
tradeoffs, for traffic directed to LBRs. In practice only two tradeoffs, for traffic directed to LBRs. In practice only two
such sets of QoS are relevant: such sets of QoS are relevant:
one that emphasizes energy minimization for energy-constrained one that emphasizes energy minimization for energy-constrained
nodes at the expense of greater mean transit delay and variance nodes at the expense of greater mean transit delay and variance
in transit delay; and in transit delay; and
one that emphasizes minimization of mean transit delay and one that emphasizes minimization of mean transit delay and
transit delay variance at the expense of greater energy demand transit delay variance at the expense of greater energy demand
on originating and intermediary energy-constrained nodes, on originating and intermediary energy-constrained nodes,
skipping to change at page 22, line 6 skipping to change at page 20, line 48
Large-scale networks characterized by highly directed traffic Large-scale networks characterized by highly directed traffic
flows between each field device and servers close to the head-end flows between each field device and servers close to the head-end
of the automation network. To this end, RPL builds Directed of the automation network. To this end, RPL builds Directed
Acyclic Graphs (DAGs) rooted at LBRs. Acyclic Graphs (DAGs) rooted at LBRs.
Zero-touch configuration. This is done through in-band methods Zero-touch configuration. This is done through in-band methods
for configuring RPL variables using DIO messages. for configuring RPL variables using DIO messages.
The use of links with time-varying availability and quality The use of links with time-varying availability and quality
characteristics. This is accomplished by allowing the use of characteristics. This is accomplished by allowing the use of
metrics that effectively capture the quality of a path (e.g., in metrics that effectively capture the quality of a path (e.g., in
terms of the mean and maximum impact of use of that path on packet terms of the mean and maximum impact of use of that path on packet
delivery timing and on endpoint energy demands), and by limiting delivery timing and on endpoint energy demands), and by limiting
the impact of changing local conditions by discovering and the impact of changing local conditions by discovering and
maintaining multiple DAG parents, and by using local repair maintaining multiple DAG parents, and by using local repair
mechanisms when DAG links break. mechanisms when DAG links break.
For wireless installations of small size with undemanding For wireless installations of small size with undemanding
communication requirements, RPL is likely to generate satisfactory communication requirements, RPL is likely to generate satisfactory
routing without any special effort. However, in larger installations routing without any special effort. However, in larger installations
skipping to change at page 23, line 39 skipping to change at page 22, line 11
are composed of battery powered field devices. are composed of battery powered field devices.
Some of these optimization goals will have to be met concurrently in Some of these optimization goals will have to be met concurrently in
a single instance by imposing various constraints. a single instance by imposing various constraints.
Each wireless field device should participate in a set composed of a Each wireless field device should participate in a set composed of a
minimum of three instances that meet optimization goals associated minimum of three instances that meet optimization goals associated
with three traffic flows which need to be supported by all industrial with three traffic flows which need to be supported by all industrial
LLNs. LLNs.
Management Instance: Wireless industrial networks are highly Management Instance: Wireless industrial networks are highly
deterministic in nature, meaning that wireless field devices do deterministic in nature, meaning that wireless field devices do
not make any decisions locally but are managed by a centralized not make any decisions locally but are managed by a centralized
System Manager that oversees the join process as well as all System Manager that oversees the join process as well as all
communication and security settings present in the devices. The communication and security settings present in the devices. The
management traffic flow is downward traffic and needs to meet management traffic flow is downward traffic and needs to meet
strictly enforced latency and reliability requirements in order to strictly enforced latency and reliability requirements in order to
ensure proper operation of the wireless LLN. Hence each field ensure proper operation of the wireless LLN. Hence each field
device should participate in an instance dedicated to management device should participate in an instance dedicated to management
traffic. All decisions made while constructing this instance will traffic. All decisions made while constructing this instance will
need to be approved by the Path Computaton Engine present in the need to be approved by the Path Computaton Engine present in the
System Manager due to the deterministic, centralized nature of System Manager due to the deterministic, centralized nature of
wireless industrial LLNs. Shallow LLNs with a hop count of up to wireless industrial LLNs. Shallow LLNs with a hop count of up to
one, accommodate this downward traffic using non-storing mode.Non- one, accommodate this downward traffic using non-storing mode.Non-
storing involves source routing that is detrimental to the packet storing involves source routing that is detrimental to the packet
size. For large transfers such as image download and size. For large transfers such as image download and
configuration files, this can be factorized for a large packet. configuration files, this can be factorized for a large packet.
In that case, a method such as [I-D.thubert-roll-forwarding-frags] In that case, a method such as [I-D.thubert-roll-forwarding-frags]
is required over multi-hop networks to forward and recover is required over multi-hop networks to forward and recover
individual fragments without the overhead of the source route individual fragments without the overhead of the source route
information in each fragment. If the hop count in the wireless information in each fragment. If the hop count in the wireless
LLN grows (LLN becomes deeper) it is higly recommended that the LLN grows (LLN becomes deeper) it is higly recommended that the
management instance rely on storing mode in order to relay management instance rely on storing mode in order to relay
management related packets. management related packets.
Operational Instance: The bulk of the data that is transferred over Operational Instance: The bulk of the data that is transferred over
wireless LLN consists of process automation related payloads. wireless LLN consists of process automation related payloads.
This data is of paramount importance to the smooth operation of This data is of paramount importance to the smooth operation of
the process that is being monitored. Hence data reliabiliy is of the process that is being monitored. Hence data reliabiliy is of
paramount importance. It is also important to note that a vast paramount importance. It is also important to note that a vast
majority of the wireless field devices that operate in industrial majority of the wireless field devices that operate in industrial
LLNs are battery powered. The operational instance should hence LLNs are battery powered. The operational instance should hence
ensure high reliability of the data transmitted while also ensure high reliability of the data transmitted while also
minimizing the aggregate power consumption of the field devices minimizing the aggregate power consumption of the field devices
operating in the LLN. All decisions made while constructing this operating in the LLN. All decisions made while constructing this
instance will need to be approved by the Path Computaton Engine instance will need to be approved by the Path Computaton Engine
present in the System Manager. This is due to the deterministic, present in the System Manager. This is due to the deterministic,
centralized nature of wireless LLNs. centralized nature of wireless LLNs.
Autonomous instance: An autonomous instance requires limited to no Autonomous instance: An autonomous instance requires limited to no
configuration. It, primary purpose is to serve as a backup for configuration. It, primary purpose is to serve as a backup for
the operational instance in case the operational instance fails. the operational instance in case the operational instance fails.
It is also useful in non-production phases of the network, when It is also useful in non-production phases of the network, when
the plant is installed or dismantled. [I-D.thubert-roll-asymlink] the plant is installed or dismantled. [I-D.thubert-roll-asymlink]
provides rules and mechanisms whereby an instance can be used as a provides rules and mechanisms whereby an instance can be used as a
fallback to another upon failure to forward a packet further. The fallback to another upon failure to forward a packet further. The
autonomic instance should always be active and during normal autonomic instance should always be active and during normal
operations it should be maintained through local repair operations it should be maintained through local repair
mechanisms. In normal operation global repairs should be mechanisms. In normal operation global repairs should be
sparingly employed in order to conserve batteries. But a global sparingly employed in order to conserve batteries. But a global
repair is also probably the fastest and most economical technique repair is also probably the fastest and most economical technique
in the case the network is extensively damaged. It is recommended in the case the network is extensively damaged. It is recommended
to rely on automation that will trigger a global repair upon the to rely on automation that will trigger a global repair upon the
detection of a large scale incident such as an explosion or a detection of a large scale incident such as an explosion or a
crash. As the name suggests, the autonomous instance is formed crash. As the name suggests, the autonomous instance is formed
without any dependence on the System Manager. Decisions made without any dependence on the System Manager. Decisions made
during the construcstion of the autonomous instance do not need during the construcstion of the autonomous instance do not need
approval from the Path Computation Engine present in the in the approval from the Path Computation Engine present in the in the
System Manager. System Manager.
Participation of each wireless field device in at least one instance Participation of each wireless field device in at least one instance
that hosts a DODAG with a virtual root is highly recommended. that hosts a DODAG with a virtual root is highly recommended.
Wireless industrial networks are typically composed of multiple LLNs Wireless industrial networks are typically composed of multiple LLNs
that terminate in a LLN Border Router (LBR). The LBRs communicate that terminate in a LLN Border Router (LBR). The LBRs communicate
with each other and with other entities present on the backbone (such with each other and with other entities present on the backbone (such
as the Gateway and the System Manager) over a wired or wireless as the Gateway and the System Manager) over a wired or wireless
backbone infrastructure. When a device A that operates in LLN 1 backbone infrastructure. When a device A that operates in LLN 1
sends a packet to a device B that operates in LLN2, the packets sends a packet to a device B that operates in LLN2, the packets
egresses LLN1 through LBR1 and ingresses LLN2 through LBR2 after egresses LLN1 through LBR1 and ingresses LLN2 through LBR2 after
travelling over the backbone infrastructure that connects the LBRs. travelling over the backbone infrastructure that connects the LBRs.
In order to accommodate this packet flow that travels from one LLN to In order to accommodate this packet flow that travels from one LLN to
another, it is highly recommended that wireless field devices another, it is highly recommended that wireless field devices
participate in at least one instance that has a DODAG with a virtual participate in at least one instance that has a DODAG with a virtual
root. root.
4.1.2. Storing vs. Non-Storing Mode 4.1.2. Storing vs. Non-Storing Mode
In general, storing mode is required for high-reporting-rate devices In general, storing mode is required for high-reporting-rate devices
(where "high rate" is with respect to the underlying link data (where "high rate" is with respect to the underlying link data
conveyance capability). Such devices, in the absence of path conveyance capability). Such devices, in the absence of path failure,
failure, are typically only one hop from the LBR(s) that convey their are typically only one hop from the LBR(s) that convey their
messaging to other parts of the system. Fortunately, in such cases, messaging to other parts of the system. Fortunately, in such cases,
the routing tables required by such nodes are small, even when they the routing tables required by such nodes are small, even when they
include information on DODAGs that are used as backup alternate include information on DODAGs that are used as backup alternate
routes. routes.
Deeper multi-hop wireless LLNs (hop count > 1) should support storing Deeper multi-hop wireless LLNs (hop count > 1) should support storing
mode in order to minimize the overhead associated with source routing mode in order to minimize the overhead associated with source routing
given the limited header capacity associated with typical physical given the limited header capacity associated with typical physical
layers employed in wireless LLNs. Support for storing mode requires layers employed in wireless LLNs. Support for storing mode requires
additional RAM resources be present in the constrained wireless additional RAM resources be present in the constrained wireless
skipping to change at page 26, line 26 skipping to change at page 25, line 5
multiple RPL instances and DODAGs, it is highly recommended that both multiple RPL instances and DODAGs, it is highly recommended that both
the RPLInstance ID and the DODAGID be included in the DAO. the RPLInstance ID and the DODAGID be included in the DAO.
4.1.4. Path Metrics 4.1.4. Path Metrics
RPL relies on an Objective Function for selecting parents and RPL relies on an Objective Function for selecting parents and
computing path costs and rank. This objective function is decoupled computing path costs and rank. This objective function is decoupled
from the core RPL mechanisms and also from the metrics in use in the from the core RPL mechanisms and also from the metrics in use in the
network. Two objective functions for RPL have been defined at the network. Two objective functions for RPL have been defined at the
time of this writing, the RPL Objective Function 0 [RFC6552] and the time of this writing, the RPL Objective Function 0 [RFC6552] and the
Minimum Rank with Hysteresis Objective Function [RFC6719], both of Minimum Rank with Hysteresis Objective Function [RFC6719], both of
which define a selection method for a preferred parent and backup which define a selection method for a preferred parent and backup
parents, and are suitable for industrial automation network parents, and are suitable for industrial automation network
deployments. deployments.
4.1.5. Objective Function 4.1.5. Objective Function
Industrial wireless LLNs are subject to swift variations in terms of Industrial wireless LLNs are subject to swift variations in terms of
the propagation of the wireless signal, variations that can affect the propagation of the wireless signal, variations that can affect
the quality of the links between field devices. This is due to the the quality of the links between field devices. This is due to the
nature of the environment in which they operate which can be nature of the environment in which they operate which can be
characterized as metal jungles that cause wireles propagation characterized as metal jungles that cause wireles propagation
distortions, multi-path fading and scattering. Hence support for distortions, multi-path fading and scattering. Hence support for
hysteresis is needed in order to ensure relative link stability which hysteresis is needed in order to ensure relative link stability which
in turn ensures route stability. in turn ensures route stability.
As mentioned in previous sections of this document, different traffic As mentioned in previous sections of this document, different traffic
flows require different optimization goals. Wireless field devices flows require different optimization goals. Wireless field devices
should participate in multiple instances associated with multiple should participate in multiple instances associated with multiple
objective functions. objective functions.
Management Instance: Should utilize an objective function that Management Instance: Should utilize an objective function that
focuses on optimization of latency and data reliability. focuses on optimization of latency and data reliability.
Operational instance: Should utilize an objective function that Operational instance: Should utilize an objective function that
focuses on data reliability and minimizing aggregate power focuses on data reliability and minimizing aggregate power
consumption for battery operated field devices. consumption for battery operated field devices.
Autonomous instance: Should utilize an objective function that Autonomous instance: Should utilize an objective function that
optimizes data latency. The primary purpose of the autonomous optimizes data latency. The primary purpose of the autonomous
instance is as a fallback instance in case the operational instance is as a fallback instance in case the operational
instance fails. Data latency is hence paramount for ensuring that instance fails. Data latency is hence paramount for ensuring that
the wireless field devices can exchange packets in order to repair the wireless field devices can exchange packets in order to repair
the operational instance. the operational instance.
More complex objective functions are needed that take in More complex objective functions are needed that take in
consideration multiple constraints and utilize weighted sums of consideration multiple constraints and utilize weighted sums of
multiple additive and multiplicative metrics. Additional objective multiple additive and multiplicative metrics. Additional objective
functions specifically designed for such networks may be defined in functions specifically designed for such networks may be defined in
skipping to change at page 29, line 20 skipping to change at page 27, line 37
parameterized accordingly as described below. These values are parameterized accordingly as described below. These values are
appropriate for the timely distribution of DIO updates in both sparse appropriate for the timely distribution of DIO updates in both sparse
and dense scenarios while avoiding the short-term congestion that and dense scenarios while avoiding the short-term congestion that
might arise in dense scenarios. might arise in dense scenarios.
Because the actual link capacity depends on the particular link Because the actual link capacity depends on the particular link
technology used within an industrial automation network deployment, technology used within an industrial automation network deployment,
the Trickle parameters are specified in terms of the link's maximum the Trickle parameters are specified in terms of the link's maximum
capacity for conveying link-local multicast messages. If the link capacity for conveying link-local multicast messages. If the link
can convey m link-local multicast packets per second on average, the can convey m link-local multicast packets per second on average, the
expected time it takes to transmit a link-local multicast packet is expected time it takes to transmit a link-local multicast packet is 1
1/m seconds. /m seconds.
DIOIntervalMin: Industrial automation network deployments SHOULD set DIOIntervalMin: Industrial automation network deployments SHOULD set
DIOIntervalMin such that the Trickle Imin is at least 50 times as DIOIntervalMin such that the Trickle Imin is at least 50 times as
long as it takes to convey a link-local multicast packet. This value long as it takes to convey a link-local multicast packet. This value
is larger than that recommended in [RFC6206] to avoid congestion in is larger than that recommended in [RFC6206] to avoid congestion in
dense plant deployments as described above. dense plant deployments as described above.
DIOIntervalDoublings: Industrial automation network deployments DIOIntervalDoublings: Industrial automation network deployments
SHOULD set DIOIntervalDoublings such that the Trickle Imax is at SHOULD set DIOIntervalDoublings such that the Trickle Imax is at
least TBD minutes or more. least TBD minutes or more.
DIORedundancyConstant: Industrial automation network deployments DIORedundancyConstant: Industrial automation network deployments
SHOULD set DIORedundancyConstant to a value of at least 10. This is SHOULD set DIORedundancyConstant to a value of at least 10. This is
due to the larger chosen value for DIOIntervalMin and the due to the larger chosen value for DIOIntervalMin and the
proportional relationship between Imin and k suggested in [RFC6206]. proportional relationship between Imin and k suggested in [RFC6206].
This increase is intended to compensate for the increased This increase is intended to compensate for the increased
communication latency of DIO updates caused by the increase in the communication latency of DIO updates caused by the increase in the
DIOIntervalMin value, though the proportional relationship between DIOIntervalMin value, though the proportional relationship between
Imin and k suggested in [RFC6206] is not preserved. Instead, Imin and k suggested in [RFC6206] is not preserved. Instead,
DIORedundancyConstant is set to a lower value in order to reduce the DIORedundancyConstant is set to a lower value in order to reduce the
number of packet transmissions in dense environments. number of packet transmissions in dense environments.
skipping to change at page 32, line 4 skipping to change at page 29, line 36
In contrast to other types of LLNs, in industrial automation networks In contrast to other types of LLNs, in industrial automation networks
centralized administrative control and access to a permanent secure centralized administrative control and access to a permanent secure
infrastructure is available. As a result link-layer, transport-layer infrastructure is available. As a result link-layer, transport-layer
and/or application-layer security mechanisms are typically in place and/or application-layer security mechanisms are typically in place
and may make use of RPL's secure mode unnecessary. and may make use of RPL's secure mode unnecessary.
6.1. Security Considerations during initial deployment 6.1. Security Considerations during initial deployment
6.2. Security Considerations during incremental deployment 6.2. Security Considerations during incremental deployment
7. Other Related Protocols 7. Other Related Protocols
8. IANA Considerations 8. IANA Considerations
This specification has no requirement on IANA. This specification has no requirement on IANA.
9. Acknowledgements 9. Acknowledgements
10. References 10. References
10.1. Normative References 10.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.
10.2. Informative References 10.2. Informative References
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16
(work in progress), February 2013.
[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-11 (work in Networks", Internet-Draft draft-ietf-roll-terminology-12,
progress), February 2013. March 2013.
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R.,
Vicisano, L., and M. Luby, "The Reliable Multicast Design Vicisano, L. and M. Luby, "The Reliable Multicast Design
Space for Bulk Data Transfer", RFC 2887, August 2000. Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T. and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J. and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks", RFC
RFC 5826, April 2010. 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N. and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S. and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O. and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP. and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6552] Thubert, P., "Objective Function Zero for the Routing [RFC6552] Thubert, P., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)", RFC
RFC 6552, March 2012. 6552, March 2012.
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with
Hysteresis Objective Function", RFC 6719, September 2012. Hysteresis Objective Function", RFC 6719, September 2012.
[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A. and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low-Power and Lossy Networks", RFC 6997, August 2013.
[I-D.thubert-roll-asymlink] [I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links", Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress), Internet-Draft draft-thubert-roll-asymlink-02, December
December 2011. 2011.
[I-D.thubert-roll-forwarding-frags] [I-D.thubert-roll-forwarding-frags]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-roll-forwarding-frags-01 (work in Recovery", Internet-Draft draft-thubert-roll-forwarding-
progress), February 2013. frags-01, February 2013.
[I-D.tsao-roll-security-framework] [I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A Tsao, T., Alexander, R., Daza, V. and A. Lozano, "A
Security Framework for Routing over Low Power and Lossy Security Framework for Routing over Low Power and Lossy
Networks", draft-tsao-roll-security-framework-02 (work in Networks", Internet-Draft draft-tsao-roll-security-
progress), March 2010. framework-02, March 2010.
10.3. External Informative References 10.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>.
Authors' Addresses Authors' Addresses
Tom Phinney (editor) Tom Phinney, editor
consultant consultant
5012 W. Torrey Pines Circle 5012 W. Torrey Pines Circle
Glendale, AZ 85308-3221 Glendale, AZ 85308-3221
USA USA
Phone: +1 602 938 3163 Phone: +1 602 938 3163
Email: tom.phinney@cox.net Email: tom.phinney@cox.net
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems, Inc
Village d'Entreprises Green Side Building D
400, Avenue de Roumanille 45 Allee des Ormes - BP1200
Batiment T3 MOUGINS - Sophia Antipolis, 06254
Biot - Sophia Antipolis 06410
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Robert Assimiti Robert Assimiti
Nivis Nivis
1000 Circle 75 Parkway SE, Ste 300 1000 Circle 75 Parkway SE, Ste 300
Atlanta, GA 30339 Atlanta, GA 30339
USA USA
Phone: +1 678 202 6859 Phone: +1 678 202 6859
Email: robert.assimiti@nivis.com Email: robert.assimiti@nivis.com
 End of changes. 85 change blocks. 
226 lines changed or deleted 225 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/