< draft-phinney-roll-rpl-industrial-applicability-01.txt   draft-phinney-roll-rpl-industrial-applicability-02.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: April 25, 2013 Cisco Expires: August 26, 2013 Cisco
RA. Assimiti RA. Assimiti
Nivis Nivis
October 22, 2012 February 22, 2013
RPL applicability in industrial networks RPL applicability in industrial networks
draft-phinney-roll-rpl-industrial-applicability-01 draft-phinney-roll-rpl-industrial-applicability-02
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 April 25, 2013. This Internet-Draft will expire on August 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 36
2.1.5. Peer-to-peer (P2P) communication paradigm . . . . . . 14 2.1.5. Peer-to-peer (P2P) communication paradigm . . . . . . 14
2.1.6. Peer-to-multipeer (P2MP) communication paradigm . . . 15 2.1.6. Peer-to-multipeer (P2MP) communication paradigm . . . 15
2.1.7. Additional considerations: Duocast and N-cast . . . . 15 2.1.7. Additional considerations: Duocast and N-cast . . . . 15
2.1.8. RPL applicability per communication paradigm . . . . . 17 2.1.8. RPL applicability per communication paradigm . . . . . 17
2.2. Layer 2 applicability. . . . . . . . . . . . . . . . . . . 19 2.2. Layer 2 applicability. . . . . . . . . . . . . . . . . . . 19
3. Using RPL to Meet Functional Requirements . . . . . . . . . . 20 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 20
4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 23 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 23 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 23
4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 25 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 25
4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 25 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 26 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 26
4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 26 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 26
4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 26 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 27
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 27 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 28
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 27 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 28
4.2. Layer-two features . . . . . . . . . . . . . . . . . . . . 28 4.2. Layer-two features . . . . . . . . . . . . . . . . . . . . 28
4.2.1. Need layer-2 expert here. . . . . . . . . . . . . . . 28 4.2.1. Need layer-2 expert here. . . . . . . . . . . . . . . 28
4.2.2. Security functions provided by layer-2. . . . . . . . 28 4.2.2. Security functions provided by layer-2. . . . . . . . 28
4.2.3. 6LowPAN options assumed. . . . . . . . . . . . . . . . 28 4.2.3. 6LowPAN options assumed. . . . . . . . . . . . . . . . 28
4.2.4. MLE and other things . . . . . . . . . . . . . . . . . 28 4.2.4. MLE and other things . . . . . . . . . . . . . . . . . 28
4.3. Recommended Configuration Defaults and Ranges . . . . . . 28 4.3. Recommended Configuration Defaults and Ranges . . . . . . 28
4.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 28 4.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 28
4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . . 29 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . . 29
5. Manageability Considerations . . . . . . . . . . . . . . . . . 30 5. Manageability Considerations . . . . . . . . . . . . . . . . . 30
skipping to change at page 4, line 48 skipping to change at page 4, line 48
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) The Routing Protocol for Low Power and Lossy Networks (RPL) [RFC6550]
[I-D.ietf-roll-rpl] specification and its point to point extension/ specification and its point to point extension/optimization
optimization [I-D.ietf-roll-p2p-rpl] define a generic Distance Vector [I-D.ietf-roll-p2p-rpl] define a generic Distance Vector protocol
protocol that is adapted to a variety of Low Power and Lossy Networks that is adapted to a variety of Low Power and Lossy Networks (LLN)
(LLN) types by the application of specific Objective Functions (OFs). types by the application of specific Objective Functions (OFs). RPL
forms Destination Oriented Directed Acyclic Graphs (DODAGs) within
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) instances of the protocol, each instance being associated with an
within instances of the protocol, each instance being associated with Objective Function to form a routing topology.
an 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.
A RPL OF states the outcome of the process used by a RPL node to A RPL OF states the outcome of the process used by a RPL node to
select and optimize routes within a RPL Instance based on the select and optimize routes within a RPL Instance based on the
skipping to change at page 15, line 42 skipping to change at page 15, line 42
multicast group destination, and/or due to the large message payloads multicast group destination, and/or due to the large message payloads
that often occur when P2MP is used for group downloads. However, in that often occur when P2MP is used for group downloads. However, in
general, message aggregation negatively impacts the delivery success general, message aggregation negatively impacts the delivery success
rate for each of the aggregated messages, since the probability of rate for each of the aggregated messages, since the probability of
error in a received message increases with message length> Together error in a received message increases with message length> Together
these considerations often lead to a policy of non-aggregation for these considerations often lead to a policy of non-aggregation for
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
skipping to change at page 17, line 39 skipping to change at page 17, line 39
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 [I-D.ietf-roll-rpl], section 6.3.1, No downward route: defined in [RFC6550], section 6.3.1, MOP of 0.
MOP of 0. This mode allows only upward routing, that is from This mode allows only upward routing, that is from nodes (devices)
nodes (devices) that reside inside the RPL network toward the that reside inside the RPL network toward the outside via the
outside via the DODAG root. DODAG root.
Non-storing mode: defined in [I-D.ietf-roll-rpl], section 6.3.1, MOP Non-storing mode: defined in [RFC6550], section 6.3.1, MOP of 1.
of 1. This mode improves MOP 0 by adding the capability to use This mode improves MOP 0 by adding the capability to use source
source routing from the root towards registered targets within the routing from the root towards registered targets within the
instance DODAG. instance DODAG.
Storing mode without multicast support: defined in Storing mode without multicast support: defined in [RFC6550],
[I-D.ietf-roll-rpl], section 6.3.1, MOP of 2. This mode improves section 6.3.1, MOP of 2. This mode improves MOP 0 by adding the
MOP 0 by adding the capability to use stateful routing from the capability to use stateful routing from the root towards
root towards registered targets within the instance DODAG. registered targets within the instance DODAG.
Storing mode with link-scope multicast DAO: defined in Storing mode with link-scope multicast DAO: defined in [RFC6550]
[I-D.ietf-roll-rpl] section 9.10, this mode improves MOP 2 by section 9.10, this mode improves MOP 2 by adding the capability to
adding the capability to send Destination Advertisements to all send Destination Advertisements to all nodes over a single Layer 2
nodes over a single Layer 2 link (e.g. a wireless hop) and enables link (e.g. a wireless hop) and enables line-of-sight direct
line-of-sight direct communication. communication.
Storing mode with multicast support: defined in [I-D.ietf-roll-rpl], Storing mode with multicast support: defined in [RFC6550], Mode-of-
Mode-of-operation (MOP) of 3. This mode improves MOP 2 by adding operation (MOP) of 3. This mode improves MOP 2 by adding the
the capability to register multicast groups and perform multicast capability to register multicast groups and perform multicast
forwarding along the instance DODAG (or a spanning subtree within forwarding along the instance DODAG (or a spanning subtree within
the DODAG). the DODAG).
Reactive: defined in [I-D.ietf-roll-p2p-rpl], the reactive mode Reactive: defined in [I-D.ietf-roll-p2p-rpl], the reactive mode
creates on-demand additional DAGs that are used to reach a given creates on-demand additional DAGs that are used to reach a given
node acting as DODAG root within a certain number of hops. This node acting as DODAG root within a certain number of hops. This
mode can typically be used for an ad-hoc closed-loop mode 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
skipping to change at page 20, line 8 skipping to change at page 20, line 8
Figure 4: RPL applicability per communication paradigm 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]
The routing protocol MUST be capable of supporting the The routing protocol MUST be capable of supporting the
organization of a large number of nodes into regions, usually organization of a large number of nodes into regions, usually
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
skipping to change at page 23, line 21 skipping to change at page 23, line 21
4.1. RPL Features 4.1. RPL Features
4.1.1. RPL Instances 4.1.1. RPL Instances
RPL allows formation of multiple instances that operate independently RPL allows formation of multiple instances that operate independently
of each other. Each instance may use a different objective function of each other. Each instance may use a different objective function
and different modes of operation. It is highly recommended that and different modes of operation. It is highly recommended that
wireless field devices participate in different instances that wireless field devices participate in different instances that
utilize objective functions that meet different optimization goals. utilize objective functions that meet different optimization goals.
These optimization goals target: 1) Minimizing and ensuring that a These optimization goals target:
guaranteed latency is being met 2) Maximizing the communication
reliability of the packets transferred over the wireless media 3) 1. Minimizing and ensuring that a guaranteed latency is being met
Minimizing aggregate power consumption for multi-hop LLNs that are
composed of battery powered field devices. Some of these 2. Maximizing the communication reliability of the packets
optimization goals will have to be met concurrently in a single transferred over the wireless media
instance by imposing various constraints. Each wireless field device
should participate in a set composed of a minimum of three instances 3. Minimizing aggregate power consumption for multi-hop LLNs that
that meet optimization goals associated with three traffic flows are composed of battery powered field devices.
which need to be supported by all industrial LLNs. Management
Instance: Wireless industrial networks are highly deterministic in Some of these optimization goals will have to be met concurrently in
nature, meaning that wireless field devices do not make any decisions a single instance by imposing various constraints.
locally but are managed by a centralized System Manager that oversees
the join process as well as all communication and security settings Each wireless field device should participate in a set composed of a
present in the devices. The management traffic flow is downward minimum of three instances that meet optimization goals associated
traffic and needs to meet strictly enforced latency and reliability with three traffic flows which need to be supported by all industrial
requirements in order to ensure proper operation of the wireless LLN. LLNs.
Hence each field device should participate in an instance dedicated
to management traffic. All decisions made while constructing this Management Instance: Wireless industrial networks are highly
instance will need to be approved by the Path Computaton Engine deterministic in nature, meaning that wireless field devices do
present in the System Manager due to the deterministic, centralized not make any decisions locally but are managed by a centralized
nature of wireless industrial LLNs. Shallow LLNs with a hop count of System Manager that oversees the join process as well as all
up to one, accommodate this downward traffic using non-storing communication and security settings present in the devices. The
mode.Non-storing involves source routing that is detrimental to the management traffic flow is downward traffic and needs to meet
packet size. For large transfers such as image download and strictly enforced latency and reliability requirements in order to
configuration files, this can be factorized for a large packet. In ensure proper operation of the wireless LLN. Hence each field
that case, a method such as draft-thubert-roll-forwarding-frags-00 is device should participate in an instance dedicated to management
required over multi-hop networks to forward and recover individual traffic. All decisions made while constructing this instance will
fragments without the overhead of the source route information in need to be approved by the Path Computaton Engine present in the
each fragment. If the hop count in the wireless LLN grows (LLN System Manager due to the deterministic, centralized nature of
becomes deeper) it is higly recommended that the management instance wireless industrial LLNs. Shallow LLNs with a hop count of up to
rely on storing mode in order to relay management related packets. one, accommodate this downward traffic using non-storing mode.Non-
storing involves source routing that is detrimental to the packet
size. For large transfers such as image download and
configuration files, this can be factorized for a large packet.
In that case, a method such as [I-D.thubert-roll-forwarding-frags]
is required over multi-hop networks to forward and recover
individual fragments without the overhead of the source route
information in each fragment. If the hop count in the wireless
LLN grows (LLN becomes deeper) it is higly recommended that the
management instance rely on storing mode in order to relay
management related packets.
Operational Instance: The bulk of the data that is transferred over
wireless LLN consists of process automation related payloads.
This data is of paramount importance to the smooth operation of
the process that is being monitored. Hence data reliabiliy is of
paramount importance. It is also important to note that a vast
majority of the wireless field devices that operate in industrial
LLNs are battery powered. The operational instance should hence
ensure high reliability of the data transmitted while also
minimizing the aggregate power consumption of the field devices
operating in the LLN. All decisions made while constructing this
instance will need to be approved by the Path Computaton Engine
present in the System Manager. This is due to the deterministic,
centralized nature of wireless LLNs.
Autonomous instance: An autonomous instance requires limited to no
configuration. It, primary purpose is to serve as a backup for
the operational instance in case the operational instance fails.
It is also useful in non-production phases of the network, when
the plant is installed or dismantled. [I-D.thubert-roll-asymlink]
provides rules and mechanisms whereby an instance can be used as a
fallback to another upon failure to forward a packet further. The
autonomic instance should always be active and during normal
operations it should be maintained through local repair
mechanisms. In normal operation global repairs should be
sparingly employed in order to conserve batteries. But a global
repair is also probably the fastest and most economical technique
in the case the network is extensively damaged. It is recommended
to rely on automation that will trigger a global repair upon the
detection of a large scale incident such as an explosion or a
crash. As the name suggests, the autonomous instance is formed
without any dependence on the System Manager. Decisions made
during the construcstion of the autonomous instance do not need
approval from the Path Computation Engine present in the in the
System Manager.
Operational Instance: The bulk of the data that is transferred over
wireless LLN consists of process automation related payloads. This
data is of paramount importance to the smooth operation of the
process that is being monitored. Hence data reliabiliy is of
paramount importance. It is also important to note that a vast
majority of the wireless field devices that operate in industrial
LLNs are battery powered. The operational instance should hence
ensure high reliability of the data transmitted while also minimizing
the aggregate power consumption of the field devices operating in the
LLN. All decisions made while constructing this instance will need
to be approved by the Path Computaton Engine present in the System
Manager. This is due to the deterministic, centralized nature of
wireless LLNs. Autonomous instance: An autonomous instance requires
limited to no configuration. It, primary purpose is to serve as a
backup for the operational instance in case the operational instance
fails. It is also useful in non-production phases of the network,
when the plant is installed or dismantled.
[draft-thubert-roll-asymlink] provides rules and mechanisms whereby
an instance can be used as a fallback to another upon failure to
forward a packet further. The autonomic instance should always be
active and during normal operations it should be maintained through
local repair mechanisms. In normal operation global repairs should
be sparingly employed in order to conserve batteries. But a global
repair is also probably the fastest and most economical technique in
the case the network is extensively damaged. It is recommended to
rely on automation that will trigger a global repair upon the
detection of a large scale incident such as an explosion or a crash.
As the name suggests, the autonomous instance is formed without any
dependence on the System Manager. Decisions made during the
construcstion of the autonomous instance do not need approval from
the Path Computation Engine present in the in the 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
skipping to change at page 26, line 12 skipping to change at page 26, line 25
that wireless field devices in LLNs will typically participate in that wireless field devices in LLNs will typically participate in
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, OF0 and MRHOF, both of which define the time of this writing, the RPL Objective Function 0 [RFC6552] and the
selection of a preferred parent and backup parents, and are suitable Minimum Rank with Hysteresis Objective Function [RFC6719], both of
for industrial automation network deployments. which define a selection method for a preferred parent and backup
parents, and are suitable for industrial automation network
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. Management instance: Should utilize an objective functions.
objective function that focuses on optimization of latency and data
reliability. Operational instance: Should utilize an objective Management Instance: Should utilize an objective function that
function that focuses on data reliability and minimizing aggregate focuses on optimization of latency and data reliability.
power consumption for battery operated field devices. Autonomous
instance: Should utilize an objective function that optimizes data Operational instance: Should utilize an objective function that
latency. The primary purpose of the autonomous instance is as a focuses on data reliability and minimizing aggregate power
fallback instance in case the operational instance fails. Data consumption for battery operated field devices.
latency is hence paramount for ensuring that the wireless field
devices can exchange packets in order to repair the operational Autonomous instance: Should utilize an objective function that
instance. optimizes data latency. The primary purpose of the autonomous
instance is as a fallback instance in case the operational
instance fails. Data latency is hence paramount for ensuring that
the wireless field devices can exchange packets in order to repair
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
companion RFCs. companion RFCs.
4.1.6. DODAG Repair 4.1.6. DODAG Repair
To effectively handle time-varying link characteristics and To effectively handle time-varying link characteristics and
availability, industrial automation network deployments SHOULD availability, industrial automation network deployments SHOULD
utilize the local repair mechanisms in RPL. utilize the local repair mechanisms in RPL.
Local repair is triggered by broken link detection, and in storing Local repair is triggered by broken link detection, and in storing
mode also by loop detection. mode also by loop detection.
The first local repair mechanism consists of a node detaching from a The first local repair mechanism consists of a node detaching from a
DODAG and then re-attaching to the same or to a different DODAG at a DODAG and then re-attaching to the same or to a different DODAG at a
later time. While detached, a node advertises an infinite rank value later time. While detached, a node advertises an infinite rank value
so that its children can select a different parent. This process is so that its children can select a different parent. This process is
known as poisoning and is described in Section 8.2.2.5 of [I-D.ietf- known as poisoning and is described in Section 8.2.2.5 of [RFC6550].
roll-rpl]. While RPL provides an option to form a local DODAG, doing While RPL provides an option to form a local DODAG, doing so in
so in industrial automation network deployments is of little benefit industrial automation network deployments is of little benefit since
since applications typically communicate through a LBR. After the applications typically communicate through a LBR. After the detached
detached node has made sufficient effort to send notification to its node has made sufficient effort to send notification to its children
children that it is detached, the node can rejoin the same DODAG with that it is detached, the node can rejoin the same DODAG with a higher
a higher rank value. The configured duration of the poisoning rank value. The configured duration of the poisoning mechanism needs
mechanism needs to take into account the disconnection time to take into account the disconnection time applications running over
applications running over the network can tolerate. Note that when the network can tolerate. Note that when joining a different DODAG,
joining a different DODAG, the node need not perform poisoning. the node need not perform poisoning.
The second local repair mechanism controls how much a node can The second local repair mechanism controls how much a node can
increase its rank within a given DODAG Version (e.g., after detaching increase its rank within a given DODAG Version (e.g., after detaching
from the DODAG as a result of broken link or loop detection). from the DODAG as a result of broken link or loop detection).
Setting the DAGMaxRankIncrease to a non-zero value enables this Setting the DAGMaxRankIncrease to a non-zero value enables this
mechanism, and setting it to a value of less than infinity limits the mechanism, and setting it to a value of less than infinity limits the
cost of count-to-infinity scenarios when they occur, thus controlling cost of count-to-infinity scenarios when they occur, thus controlling
the duration of disconnection applications may experience. the duration of disconnection applications may experience.
4.1.7. Multicast 4.1.7. Multicast
skipping to change at page 35, line 13 skipping to change at page 35, line 13
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-rpl]
Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
Winter, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[I-D.ietf-roll-p2p-rpl] [I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-14 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16
(work in progress), October 2012. (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-06 (work in Networks", draft-ietf-roll-terminology-11 (work in
progress), September 2011. progress), February 2013.
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R.,
Vicisano, L., and M. Luby, "The Reliable Multicast Design
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 5826, April 2010. RFC 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.
[I-D.ietf-roll-of0] [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
Thubert, P., "RPL Objective Function Zero", "The Trickle Algorithm", RFC 6206, March 2011.
draft-ietf-roll-of0-20 (work in progress), September 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6552] Thubert, P., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, March 2012.
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with
Hysteresis Objective Function", RFC 6719, September 2012.
[I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress),
December 2011.
[I-D.thubert-roll-forwarding-frags]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-roll-forwarding-frags-00 (work in
progress), March 2012.
[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", draft-tsao-roll-security-framework-02 (work in
progress), March 2010. progress), 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,
 End of changes. 25 change blocks. 
141 lines changed or deleted 179 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/