< draft-ietf-roll-nsa-extension-06.txt   draft-ietf-roll-nsa-extension-07.txt >
ROLL R. Koutsiamanis, Ed. ROLL R. Koutsiamanis, Ed.
Internet-Draft G. Papadopoulos Internet-Draft G. Papadopoulos
Intended status: Standards Track N. Montavont Intended status: Standards Track N. Montavont
Expires: August 13, 2020 IMT Atlantique Expires: September 10, 2020 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
February 10, 2020 March 9, 2020
Common Ancestor Objective Function and Parent Set DAG Metric Container Common Ancestor Objective Function and Parent Set DAG Metric Container
Extension Extension
draft-ietf-roll-nsa-extension-06 draft-ietf-roll-nsa-extension-07
Abstract Abstract
Implementing Packet Replication and Elimination from/to the RPL root Packet Replication and Elimination is a method in which several
requires the ability to forward copies of packets over different copies of a data packet are sent in the network in order to achieve
paths via different RPL parents. Selecting the appropriate parents high reliability and low jitter. This document details how to apply
to achieve ultra-low latency and jitter requires information about a Packet Replication and Elimination in RPL, especially how to exchange
node's parents. This document details what information needs to be information within RPL control packets to let a node better select
transmitted and how it is encoded within RPL control packets to the different parents that will be used to forward the multiple
enable this functionality. This document also describes Objective copies of a packet. This document also describes the Objective
Function which take advantage of this information to implement multi- Function which takes advantage of this information to implement
path routing. multi-path routing.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 13, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Common Ancestor Objective Function . . . . . . . . . . . . . 4 3. Common Ancestor AP Selection Policies . . . . . . . . . . . . 4
3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 6 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 5
3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 7 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 6
3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 8 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6
3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Common Ancestor Objective Function . . . . . . . . . . . . . 6
4. Node State and Attribute (NSA) object type extension . . . . 8 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Node State and Attribute (NSA) object type extension . . . . 9
5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Informative references . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Other Informative References . . . . . . . . . . . . . . 12 9.1. Informative references . . . . . . . . . . . . . . . . . 12
9.2. Other Informative References . . . . . . . . . . . . . . 13
Appendix A. Implementation Status . . . . . . . . . . . . . . . 13 Appendix A. Implementation Status . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Choosing an AP selection policy . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Network-enabled applications in the industrial context must provide Networks in the industrial context must provide stringent guarantees
stringent guarantees in terms of reliability and predictability. in terms of reliability and predictability, with this domain being
one of main ones addressed by Deterministic Networking [RFC8557].
Packet Replication and Elimination (PRE) Packet Replication and Elimination (PRE)
[I-D.papadopoulos-6tisch-pre-reqs] is a technique which allows [I-D.papadopoulos-6tisch-pre-reqs] is a technique which allows
redundant paths in the network to be utilized for traffic requiring redundant paths in the network to be utilized for traffic requiring
higher reliability. Allowing these kinds of applications to function higher reliability. Allowing industrial applications to function
over wireless networks requires the application of the principles of over wireless networks requires the application of the principles and
Deterministic Networking [I-D.ietf-detnet-architecture]. This architecture of Deterministic Networking [RFC8655]. This results in
results in designs which aim at optimizing packet delivery rate and designs which aim at optimizing packet delivery rate and bounding
bounding latency. Additionally, given that the network nodes often latency. Additionally, nodes operating on battery need to minimize
do not have an unlimited power supply, energy consumption needs to be their energy consumption.
minimized as well.
As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154] As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154]
provides Time-Slotted Channel Hopping (TSCH), a mode of operation provides Time-Slotted Channel Hopping (TSCH), a mode of operation
which uses a common communication schedule based on timeslots to which uses a common communication schedule based on timeslots to
allow deterministic medium access as well as channel hopping to work allow deterministic medium access as well as channel hopping to work
around radio interference. However, since TSCH uses retransmissions around radio interference. However, since TSCH uses retransmissions
in the event of a failed transmission, end-to-end delay and jitter in the event of a failed transmission, end-to-end latency and jitter
performance can deteriorate. performance can deteriorate.
Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE
Std. 802.15.4-TSCH, has worked on the issues previously highlighted Std. 802.15.4-TSCH, has worked on these issues and produced the
and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to address that
to address that case. Building on this architecture, "Exploiting case. Building on this architecture, "Exploiting Packet Replication
Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs" and Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the
Packet Delivery Ratio (PDR), to provide a hard bound to the end-to- Packet Delivery Ratio (PDR), to provide a hard bound to the end-to-
end latency, and to limit jitter. end latency, and thus to limit jitter.
PRE is a general method of maximizing packet delivery rate and PRE is a general method of maximizing packet delivery rate and
potentially minimizing latency and jitter, not limited to 6TiSCH. potentially minimizing latency and jitter, not limited to 6TiSCH.
More specifically, PRE achieves controlled redundancy by laying More specifically, PRE achieves controlled redundancy by laying
multiple forwarding paths through the network and using them in multiple forwarding paths through the network and using them in
parallel for different copies of a same packet. PRE can follow the parallel for different copies of a same packet. PRE can follow the
Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL
from a node to the root. Building a multi-path DODAG can be achieved from a node to the root. Building a multi-path DODAG can be achieved
based on the RPL capability of having multiple parents for each node based on the RPL capability of having multiple parents for each node
in a network, a subset of which is used to forward packets. In order in a network, a subset of which is used to forward packets. In order
for this subset to be defined, a RPL parent subset selection to select parents to be part of this subset, the RPL Objective
mechanism, which is among the responsibilities of the RPL Objective Function (OF) needs additional information regarding the multi-path
Function (OF), needs to have specific path information. This nature of PRE. This document describes an OF which implements multi-
document describes OFs which implement multi-path routing for PRE and path routing for PRE and specifies the transmission of this specific
specifies the transmission of this specific path information. path information.
This document describes a new objective function (OF) called the This document describes a new Objective Function (OF) called the
Common Ancestor (CA) OF. A detailed description is given of how the Common Ancestor (CA) OF. A detailed description is given of how the
path information is used within the CA OF and how the subset of path information is used within the CA OF and how the subset of
parents for forwarding packets is selected. This specification parents for forwarding packets is selected. This specification
defines a new Objective Code Point (OCP) for the CA OF. defines a new Objective Code Point (OCP) for the CA OF.
For the path information, this specification focuses on the For the path information, this specification focuses on the
extensions to the DAG Metric Container [RFC6551] required for extensions to the DAG Metric Container [RFC6551] required for
providing the PRE mechanism a part of the information it needs to providing the PRE mechanism a part of the information it needs to
operate. This information is the RPL [RFC6550] parent address set of operate. This information is the RPL [RFC6550] parent address set of
a node and it must be sent to potential children of the node. The a node and it must be sent to potential children of the node. The
skipping to change at page 4, line 13 skipping to change at page 4, line 15
the parent address set TLV. the parent address set TLV.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The draft uses the following Terminology: The draft uses the following Terminology:
Packet Replication and Elimination (PRE): A method which transmits Packet Replication and Elimination (PRE): A method which consists of
multiple copies of a packet using multi-path forwarding over a transmitting multiple copies of a packet using multi-path
multi-hop network and which consolidates multiple received packet forwarding over a multi-hop network and which consolidates
copies to control flooding. See "Exploiting Packet Replication multiple received packet copies to control flooding. See
and Elimination in Complex Tracks in 6TiSCH LLNs" "Exploiting Packet Replication and Elimination in Complex Tracks
[I-D.papadopoulos-6tisch-pre-reqs] for more details. in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs] for more
details.
Parent Set (PS): Given a RPL node, the set of its neighbor nodes Parent Set (PS): Given a RPL node, the set of its neighbor nodes
which participate in the same RPL DODAG and which can potentially which participate in the same RPL DODAG and which can potentially
take the role of the node's preferred parent. take the role of the node's preferred parent.
Alternative Parent (AP): A RPL parent in the parent set of a node Alternative Parent (AP): A RPL parent in the parent set of a node
which is used to forward a packet copy when replicating packets. which is used to forward a packet copy when replicating packets.
Alternative Parent (AP) Selection: The mechanism for choosing the Alternative Parent (AP) Selection: The mechanism for choosing the
next hop node to forward a packet copy when replicating packets. next hop node to forward a packet copy when replicating packets.
Preferred Grand Parent (PGP): The preferred parent of the preferred Preferred Grand Parent (PGP): The preferred parent of the preferred
parent of a node. parent of a node.
3. Common Ancestor Objective Function 3. Common Ancestor AP Selection Policies
In the RPL protocol, each node maintains a list of potential parents. In the RPL protocol, each node maintains a list of potential parents.
For PRE, the Preferred Parent (PP) node is defined to be the same as For PRE, the Preferred Parent (PP) node is defined to be the same as
the RPL DODAG Preferred Parent node. Furthermore, to construct an the RPL DODAG Preferred Parent node. Furthermore, to construct an
alternative path toward the root, in addition to the PP node, each alternative path toward the root, in addition to the PP node, each
node in the network registers an AP node as well from its Parent Set node in the network selects additional parent(s), called alternative
(PS). parent(s), from its Parent Set (PS).
There are multiple alternative methods of selecting the AP node.
This functionality is included in the operation of the RPL Objective
Function (OF). An OF which allows the two paths to remain correlated
is detailed here. More specifically, when using this OF a node will
select an AP node close to its PP node to allow the operation of
overhearing between parents. For more details about overhearing and
its use in this context see Section 4.3. "Promiscuous Overhearing"
in "Exploiting Packet Replication and Elimination in Complex Tracks
in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs]. If multiple
potential APs match this condition, the AP with the lowest rank will
be registered.
The OF described here is an extension of the The Minimum Rank with
Hysteresis Objective Function [RFC6719] (MRHOF). In general, this OF
extends MRHOF by specifying how an AP is selected. Importantly, the
calculation of the rank of the node through each candidate neighbor
and the selection of the PP is kept the same as in MRHOF.
The ways in which the CA OF modifies MRHOF in a section-by-section
manner follows in detail:
3. The Minimum Rank with Hysteresis Objective Function:
Same as MRHOF extended to AP selection. Minimum Rank path
selection and switching applies correspondingly to the AP with the
extra CA requirement of having some match between ancestors.
3.1. Computing the Path Cost: Same as MRHOF extended to AP
selection. If a candidate neighbor does not fulfill the CA
requirement then the path through that neighbor SHOULD be set to
MAX_PATH_COST, the same value used by MRHOF. As a result, the
node MUST NOT select the candidate neighbor as its AP.
3.2. Parent Selection: Same as MRHOF extended to AP selection. To
allow hysteresis, AP selection maintains a variable,
cur_ap_min_path_cost, which is the path cost of the current AP.
3.2.1. When Parent Selection Runs: Same as MRHOF.
3.2.2. Parent Selection Algorithm: Same as MRHOF extended to AP
selection. If the smallest path cost for paths through the
candidate neighbors is smaller than cur_ap_min_path_cost by less
than PARENT_SWITCH_THRESHOLD (the same variable as MRHOF uses),
the node MAY continue to use the current AP. Additionally, if
there is no PP selected, there MUST NOT be any AP selected as
well. Finally, as with MRHOF, a node MAY include up to
PARENT_SET_SIZE-1 additional candidate neighbors in its
alternative parent set. The value of PARENT_SET_SIZE is the same
as in MRHOF.
3.3. Computing Rank: Same as MRHOF.
3.4. Advertising the Path Cost: Same as MRHOF.
3.5. Working without Metric Containers: It is not possible to work
without metric containers, since CA AP selection requires
information from parents regarding their parent sets, which is
transmitted via the NSA object in the DIO Mectric Container.
4. Using MRHOF for Metric Maximization: Same as MRHOF.
5. MRHOF Variables and Parameters: Same as MRHOF extended to AP
selection. The CA OFs operate like MRHOF for AP selection by
maintaining separate:
AP: Corresponding to the MRHOF PP. Hysteresis is configured for
AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF.
The AP MUST NOT be the same as the PP.
Alternative parent set: Corresponding to the MRHOF parent set.
The size is defined by the same PARENT_SET_SIZE parameter as in
MRHOF. The Alternative parent set MUST be a non-strict subset
of the parent set.
cur_ap_min_path_cost: Corresponding to the MRHOF
cur_min_path_cost variable. To support the operation of the
hysteresis function for AP selection.
6. Manageability: Same as MRHOF.
6.1. Device Configuration: Same as MRHOF.
6.2. Device Monitoring: Same as MRHOF. There are multiple possible policies of selecting the AP node. This
section details three such possible policies.
Three OFs are defined which perform AP selection based on common All three policies defined perform AP selection based on common
ancestors, named Common Ancestor Strict, Common Ancestor Medium, and ancestors, named Common Ancestor Strict, Common Ancestor Medium, and
Common Ancestor Relaxed, depending on how restrictive the selection Common Ancestor Relaxed, depending on how restrictive the selection
process is. A more restrictive method will limit flooding but might process is. A more restrictive policy will limit flooding but might
fail to select an appropriate AP, while a less restrictive one will fail to select an appropriate AP, while a less restrictive one will
more often find an appropriate AP but might increase flooding. The more often find an appropriate AP but might increase flooding.
OFs are all represented with the same Objective Code Point (OCP):
TBD1.
All three OFs apply their corresponding common ancestor criterion to All three policies apply their corresponding common ancestor
filter the list of candidate neighbours in the alternative parent criterion to filter the list of candidate neighbours in the
set. The AP is then selected from the alternative parent set based alternative parent set.
on Rank and using hysteresis as is done for the PP in MRHOF.
3.1. Common Ancestor Strict 3.1. Common Ancestor Strict
In the CA Strict OF the node will check if its Preferred Grand Parent In the CA Strict OF the node will check if its Preferred Grand Parent
(PGP), the PP of its PP, is the same as the PP of the potential AP. (PGP), the PP of its PP, is the same as the PP of the potential AP.
( R ) root ( R ) root
. PS(S) = {A, B, C, D} . PS(S) = {A, B, C, D}
. PP(S) = C . PP(S) = C
. PP(PP(S)) = Y . PP(PP(S)) = Y
skipping to change at page 7, line 26 skipping to change at page 5, line 37
| // \ | // \ || / \ || PS(C) = {X, Y, Z} | // \ | // \ || / \ || PS(C) = {X, Y, Z}
( A ) ( B ) ( C ) ( D ) PP(C) = Y ( A ) ( B ) ( C ) ( D ) PP(C) = Y
^ ^ ^^ ^ ^ ^ ^^ ^
\ \ || / PS(D) = {Y, Z} \ \ || / PS(D) = {Y, Z}
\ \ || / PP(D) = Z \ \ || / PP(D) = Z
\ \ || / \ \ || /
\----\\ || / || Preferred Parent \----\\ || / || Preferred Parent
( S ) source | Potential Alternative Parent ( S ) source | Potential Alternative Parent
Figure 1: Example Common Ancestor Strict Alternative Parent Selection Figure 1: Example Common Ancestor Strict Alternative Parent Selection
method policy
For example, in Figure 1, the source node S must know its grandparent For example, in Figure 1, the source node S must know its grandparent
sets through nodes A, B, C, and D. The Parent Sets (PS) and the sets through nodes A, B, C, and D. The Parent Sets (PS) and the
Preferred Parents (PS) of nodes A, B, C, and D are shown on the side Preferred Parents (PS) of nodes A, B, C, and D are shown on the side
of the figure. The CA Strict parent selection method will select an of the figure. The CA Strict parent selection policy will select an
AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) =
Y: Y:
o Node A: PP(A) = X and therefore it is different than PP(PP(S)) o Node A: PP(A) = X and therefore it is different than PP(PP(S))
o Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) o Node B: PS(B) = Y and therefore it is equal to PP(PP(S))
o Node D: PS(D) = Z and therefore it is different than PP(PP(S)) o Node D: PS(D) = Z and therefore it is different than PP(PP(S))
node S can decide to use node B as its AP node, since PP(PP(S)) = Y = node S can decide to use node B as its AP node, since PP(PP(S)) = Y =
PP(B). PP(B).
3.2. Common Ancestor Medium 3.2. Common Ancestor Medium
In the CA Medium OF the node will check if its Preferred Grand Parent In the CA Medium OF the node will check if its Preferred Grand Parent
(PGP), the PP of its PP, is contained in the PS of the potential AP. (PGP), the PP of its PP, is contained in the PS of the potential AP.
Using the same example, in Figure 1, the CA Medium parent selection Using the same example, in Figure 1, the CA Medium parent selection
method will select an AP for node S for which PP(PP(S)) is in PS(AP). policy will select an AP for node S for which PP(PP(S)) is in PS(AP).
Given that PP(PP(S)) = Y: Given that PP(PP(S)) = Y:
o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set
o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set
o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set
node S can decide to use node B or D as its AP node. node S can decide to use node B or D as its AP node.
3.3. Common Ancestor Relaxed 3.3. Common Ancestor Relaxed
In the CA Relaxed OF the node will check if the Parent Set (PS) of In the CA Relaxed OF the node will check if the Parent Set (PS) of
its Preferred Parent (PP) has a node in common with the PS of the its Preferred Parent (PP) has a node in common with the PS of the
potential AP. potential AP.
Using the same example, in Figure 1, the CA Relaxed parent selection Using the same example, in Figure 1, the CA Relaxed parent selection
method will select an AP for node S for which PS(PP(S)) has at least policy will select an AP for node S for which PS(PP(S)) has at least
one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}:
o Node A: PS(A) = {W, X} and the common nodes are {X} o Node A: PS(A) = {W, X} and the common nodes are {X}
o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y}
o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z}
node S can decide to use node A, B or D as its AP node. node S can decide to use node A, B or D as its AP node.
3.4. Usage 4. Common Ancestor Objective Function
An OF which allows the multiple paths to remain correlated is
detailed here. More specifically, when using this OF a node will
select an AP node close to its PP node to allow the operation of
overhearing between parents. For more details about overhearing and
its use in this context see Section 4.3. "Promiscuous Overhearing"
in "Exploiting Packet Replication and Elimination in Complex Tracks
in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs]. If multiple
potential APs match this condition, the AP with the lowest rank will
be registered.
The OF described here is an extension of the The Minimum Rank with
Hysteresis Objective Function [RFC6719] (MRHOF). In general, this OF
extends MRHOF by specifying how an AP is selected. Importantly, the
calculation of the rank of the node through each candidate neighbor
and the selection of the PP is kept the same as in MRHOF.
The ways in which the CA OF modifies MRHOF in a section-by-section
manner follows in detail:
MRHOF Section 3. "The Minimum Rank with Hysteresis Objective
Function":
Same as MRHOF extended to AP selection. Minimum Rank path
selection and switching applies correspondingly to the AP with the
extra CA requirement of having some match between ancestors.
MRHOF Section 3.1. "Computing the Path Cost": Same as MRHOF
extended to AP selection. If a candidate neighbor does not
fulfill the CA requirement then the path through that neighbor
SHOULD be set to MAX_PATH_COST, the same value used by MRHOF. As
a result, the node MUST NOT select the candidate neighbor as its
AP.
MRHOF Section 3.2. "Parent Selection": Same as MRHOF extended to AP
selection. To allow hysteresis, AP selection maintains a
variable, cur_ap_min_path_cost, which is the path cost of the
current AP.
MRHOF Section 3.2.1. "When Parent Selection Runs": Same as MRHOF.
MRHOF Section 3.2.2. "Parent Selection Algorithm": Same as MRHOF
extended to AP selection. If the smallest path cost for paths
through the candidate neighbors is smaller than
cur_ap_min_path_cost by less than PARENT_SWITCH_THRESHOLD (the
same variable as MRHOF uses), the node MAY continue to use the
current AP. Additionally, if there is no PP selected, there MUST
NOT be any AP selected as well. Finally, as with MRHOF, a node
MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors
in its alternative parent set. The value of PARENT_SET_SIZE is
the same as in MRHOF.
MRHOF Section 3.3. "Computing Rank": Same as MRHOF.
MRHOF Section 3.4. "Advertising the Path Cost": Same as MRHOF.
MRHOF Section 3.5. "Working without Metric Containers":
It is not possible to work without metric containers, since CA AP
selection requires information from parents regarding their parent
sets, which is transmitted via the NSA object in the DIO Mectric
Container.
MRHOF Section 4. "Using MRHOF for Metric Maximization":
Same as MRHOF.
MRHOF Section 5. "MRHOF Variables and Parameters": Same as MRHOF
extended to AP selection. The CA OF operates like MRHOF for AP
selection by maintaining separate:
AP: Corresponding to the MRHOF PP. Hysteresis is configured for
AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF.
The AP MUST NOT be the same as the PP.
Alternative parent set: Corresponding to the MRHOF parent set.
The size is defined by the same PARENT_SET_SIZE parameter as in
MRHOF. The Alternative parent set MUST be a non-strict subset
of the parent set.
cur_ap_min_path_cost: Corresponding to the MRHOF
cur_min_path_cost variable. To support the operation of the
hysteresis function for AP selection.
MRHOF Section 6. "Manageability": Same as MRHOF.
MRHOF Section 6.1. "Device Configuration": Same as MRHOF.
MRHOF Section 6.2. "Device Monitoring": Same as MRHOF.
4.1. Usage
All OF policies apply their corresponding criterion to filter the
list of candidate neighbours in the alternative parent set. The AP
is then selected from the alternative parent set based on Rank and
using hysteresis as is done for the PP in MRHOF. It is noteworthy
that the OF uses the same Objective Code Point (OCP): TBD1 for all
policies used.
The PS information can be used by any of the described AP selection The PS information can be used by any of the described AP selection
methods or other ones not described here, depending on requirements. policies or other ones not described here, depending on requirements.
It is optional for all nodes to use the same AP selection method. It is optional for all nodes to use the same AP selection policies.
Different nodes may use different AP selection methods, since the Different nodes may use different AP selection policies, since the
selection method is local to each node. For example, using different selection policy is local to each node. For example, using different
methods can be used to vary the transmission reliability in each hop. policies can be used to vary the transmission reliability in each
hop.
4. Node State and Attribute (NSA) object type extension 5. Node State and Attribute (NSA) object type extension
In order to select their AP node, nodes need to be aware of their In order to select their AP node, nodes need to be aware of their
grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG
Information Object (DIO) Control Message to broadcast information Information Object (DIO) Control Message to broadcast information
about themselves to potential children. However, RPL [RFC6550], does about themselves to potential children. However, RPL [RFC6550], does
not define how to propagate parent set related information, which is not define how to propagate parent set related information, which is
what this document addresses. what this document addresses.
DIO messages can carry multiple options, out of which the DAG Metric DIO messages can carry multiple options, out of which the DAG Metric
Container option [RFC6551] is the most suitable structurally and Container option [RFC6551] is the most suitable structurally and
skipping to change at page 10, line 44 skipping to change at page 11, line 5
separator between them. The field consists of one IPv6 address separator between them. The field consists of one IPv6 address
per parent in the parent set. The parent addresses are listed per parent in the parent set. The parent addresses are listed
in decreasing order of preference and not all parents in the in decreasing order of preference and not all parents in the
parent set need to be included. The selection of how many parent set need to be included. The selection of how many
parents from the parent set are to be included is left to the parents from the parent set are to be included is left to the
implementation. The number of parent addresses in the PS IPv6 implementation. The number of parent addresses in the PS IPv6
address(es) field can be deduced by dividing the length of the address(es) field can be deduced by dividing the length of the
PS IPv6 address(es) field in bytes by 16, the number of bytes PS IPv6 address(es) field in bytes by 16, the number of bytes
in an IPv6 address. in an IPv6 address.
4.1. Usage 5.1. Usage
The PS SHOULD be used in the process of parent selection, and The PS SHOULD be used in the process of parent selection, and
especially in AP selection, since it can help the alternative path to especially in AP selection, since it can help the alternative path to
not significantly deviate from the preferred path. The Parent Set is not significantly deviate from the preferred path. The Parent Set is
information local to the node that broadcasts it. information local to the node that broadcasts it.
The PS is used only within NSA objects configured as constraints and The PS is used only within NSA objects configured as a metric,
is used as per [RFC6551]. As a result, the PS does not affect the therefore the DAG Metric Container field "C" MUST be 0.
calculation of the rank through candidate neighbors. It is only used Additionally, since the information in the PS needs to be propagated
with the CA OF to remove nodes which do not fulfill the CA OF downstream but it cannot be aggregated, the DAG Metric Container
criteria from the candidate neighbor list. field "R" MUST be 1. Finally, since the information contained is by
definition partial, more specifically just the parent set of the DIO-
sending node, the DAG Metric Container field "P" MUST be 1.
5. Controlling PRE It is important that the PS does not affect the calculation of the
rank through candidate neighbors. It is only used with the CA OF to
remove nodes which do not fulfill the CA OF criteria from the
candidate neighbor list.
6. Controlling PRE
PRE is very helpful when the aim is to increase reliability for a PRE is very helpful when the aim is to increase reliability for a
certain path, however its use creates additional traffic as part of certain path, however its use creates additional traffic as part of
the replication process. It is conceivable that not all paths have the replication process. It is conceivable that not all paths have
stringent reliability requirements. Therefore, a way to control stringent reliability requirements. Therefore, a way to control
whether PRE is applied to a path's packets SHOULD be implemented. whether PRE is applied to a path's packets SHOULD be implemented.
For example, a traffic class label can be used to determine this For example, a traffic class label can be used to determine this
behavior per flow type as described in Deterministic Networking behavior per flow type as described in Deterministic Networking
Architecture [I-D.ietf-detnet-architecture]. Architecture [RFC8655].
6. Security Considerations 7. Security Considerations
The structure of the DIO control message is extended, within the pre- The structure of the DIO control message is extended, within the pre-
defined DIO options. Therefore, the security mechanisms defined in defined DIO options. The additional information are the IPv6
RPL [RFC6550] apply to this proposed extension. addresses of the parent set of the node transmitting the DIO. This
use of this additional information can have the following potential
consequences:
7. IANA Considerations o A malicious node that can receive and read the DIO can "see"
further than it's own neighbourhood by one hop, learning the
addresses of it's two hop neighbors. This is a privacy / network
discovery issue.
o A malicious node that can send DIOs can use the parent set
extension to convince neighbours to route through itself, instead
of the normal preferred parent they would use. However, this is
already possible with other OFs (like OF0 [RFC6552] and MRHOF
[RFC6719]) by reporting a fake rank value in the DIO, thus
masquerading as the DODAG root.
8. IANA Considerations
This proposal requests the allocation of a new value TBD1 from the This proposal requests the allocation of a new value TBD1 from the
"Objective Code Point (OCP)" sub-registry of the "Routing Protocol "Objective Code Point (OCP)" sub-registry of the "Routing Protocol
for Low Power and Lossy Networks (RPL)" registry. for Low Power and Lossy Networks (RPL)" registry.
This proposal also requests the allocation of a new value TBD2 for This proposal also requests the allocation of a new value TBD2 for
the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub- the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-
registry from IANA. registry from IANA.
8. References 9. References
8.1. Informative references 9.1. Informative references
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work
in progress), October 2019. in progress), October 2019.
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019.
[I-D.papadopoulos-6tisch-pre-reqs] [I-D.papadopoulos-6tisch-pre-reqs]
Papadopoulos, G., Montavont, N., and P. Thubert, Papadopoulos, G., Montavont, N., and P. Thubert,
"Exploiting Packet Replication and Elimination in Complex "Exploiting Packet Replication and Elimination in Complex
Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre-
reqs-02 (work in progress), July 2018. reqs-02 (work in progress), July 2018.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 29 skipping to change at page 13, line 5
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>. <https://www.rfc-editor.org/info/rfc6551>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012,
<https://www.rfc-editor.org/info/rfc6552>.
[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, Hysteresis Objective Function", RFC 6719,
DOI 10.17487/RFC6719, September 2012, DOI 10.17487/RFC6719, September 2012,
<https://www.rfc-editor.org/info/rfc6719>. <https://www.rfc-editor.org/info/rfc6719>.
8.2. Other Informative References [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
<https://www.rfc-editor.org/info/rfc8557>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
9.2. Other Informative References
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE Std IEEE standard for Information Technology, "IEEE Std
802.15.4 Standard for Low-Rate Wireless Personal Area 802.15.4 Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", December 2015. Networks (WPANs)", December 2015.
8.3. URIs 9.3. URIs
[1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll- [1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll-
nsa-extension nsa-extension
[2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit [2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit
;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138 ;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138
Appendix A. Implementation Status Appendix A. Implementation Status
A research-stage implementation of the PRE mechanism using the A research-stage implementation of the PRE mechanism using the
skipping to change at page 15, line 8 skipping to change at page 15, line 43
+-----------+---------------+-----------------+---------------------+ +-----------+---------------+-----------------+---------------------+
Links: Links:
o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa-
extension branch) [1] extension branch) [1]
o Wireshark dissectors (for the optional PS TLV) - currently merged o Wireshark dissectors (for the optional PS TLV) - currently merged
/ in master [2] / in master [2]
Appendix B. Choosing an AP selection policy
The manner of choosing an AP selection policy is left to the
implementation, for maximum flexibility.
For example, a different policy can be used per traffic type. The
network configurator can choose the CA Relaxed policy to increase
reliability (thus producing some flooding) for specific, extremely
important, alert packets. On the other hand, all normal data traffic
uses the CA Strict policy. Therefore, an exception is made just for
the alert packets.
Another option would be to devise a new disjoint policy, where the
paths are on purpose non-correlated, to increase path diversity and
resilience against whole groups of nodes failing. The disadvantage
may be increased jitter.
Finally, a network configurator may provide the CA policies with a
preference order of Strict > Medium > Relaxed as a means of falling
back to more flood-prone policies to maintain reliability.
Authors' Addresses Authors' Addresses
Remous-Aris Koutsiamanis (editor) Remous-Aris Koutsiamanis (editor)
IMT Atlantique IMT Atlantique
Office B00 - 126A Office B00 - 126A
2 Rue de la Chataigneraie 2 Rue de la Chataigneraie
Cesson-Sevigne - Rennes 35510 Cesson-Sevigne - Rennes 35510
FRANCE FRANCE
Phone: +33 299 12 70 49 Phone: +33 299 12 70 49
 End of changes. 44 change blocks. 
181 lines changed or deleted 249 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/