< draft-ietf-roll-nsa-extension-03.txt   draft-ietf-roll-nsa-extension-04.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: December 30, 2019 IMT Atlantique Expires: January 9, 2020 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
June 28, 2019 July 8, 2019
RPL DAG Metric Container Node State and Attribute object type extension Common Ancestor Objective Functions and Parent Set DAG Metric Container
draft-ietf-roll-nsa-extension-03 Extension
draft-ietf-roll-nsa-extension-04
Abstract Abstract
Implementing Packet Replication and Elimination from / to the RPL Implementing Packet Replication and Elimination from / to the RPL
root requires the ability to forward copies of packets over different root requires the ability to forward copies of packets over different
paths via different RPL parents. Selecting the appropriate parents paths via different RPL parents. Selecting the appropriate parents
to achieve ultra-low latency and jitter requires information about a to achieve ultra-low latency and jitter requires information about a
node's parents. This document details what information needs to be node's parents. This document details what information needs to be
transmitted and how it is encoded within a packet to enable this transmitted and how it is encoded within a packet to enable this
functionality. functionality. This document also describes Objective Functions
which take advantage of this information to implement 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 December 30, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alternative Parent Selection . . . . . . . . . . . . . . . . 4 3. Common Ancestor Objective Functions . . . . . . . . . . . . . 4
3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 4 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 6
3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 5 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 7
3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 8
3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Node State and Attribute (NSA) object type extension . . . . 6 4. Node State and Attribute (NSA) object type extension . . . . 8
4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 10
5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Informative references . . . . . . . . . . . . . . . . . 11
8.1. Informative references . . . . . . . . . . . . . . . . . 10 8.2. Other Informative References . . . . . . . . . . . . . . 12
8.2. Other Informative References . . . . . . . . . . . . . . 11 Appendix A. Implementation Status . . . . . . . . . . . . . . . 12
Appendix A. Implementation Status . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Network-enabled applications in the industrial context must provide Network-enabled applications in the industrial context must provide
stringent guarantees in terms of reliability and predictability. To stringent guarantees in terms of reliability and predictability. To
achieve this they typically leverage 1+1 redundancy, also known as achieve this they typically leverage 1+1 redundancy, also known as
Packet Replication and Elimination (PRE) Packet Replication and Elimination (PRE)
[I-D.papadopoulos-6tisch-pre-reqs]. Allowing these kinds of [I-D.papadopoulos-6tisch-pre-reqs]. Allowing these kinds of
applications to function over wireless networks requires the applications to function over wireless networks requires the
application of the principles of Deterministic Networking application of the principles of Deterministic Networking
[I-D.ietf-detnet-architecture]. This results in designs which aim at [I-D.ietf-detnet-architecture]. This results in designs which aim at
maximizing packet delivery rate and minimizing latency and jitter. optimizing packet delivery rate and bounding latency. Additionally,
Additionally, given that the network nodes often do not have an given that the network nodes often do not have an unlimited power
unlimited power supply, energy consumption needs to be minimized as supply, energy consumption needs to be minimized as well.
well.
As an example, to meet this goal, IEEE Std. 802.15.4 As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154]
[IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a provides Time-Slotted Channel Hopping (TSCH), a mode of operation
mode of operation which uses a common communication schedule based on which uses a common communication schedule based on timeslots to
timeslots to allow deterministic medium access as well as channel allow deterministic medium access as well as channel hopping to work
hopping to work around radio interference. However, since TSCH uses around radio interference. However, since TSCH uses retransmissions
retransmissions in the event of a failed transmission, end-to-end in the event of a failed transmission, end-to-end delay and jitter
delay 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 the issues previously highlighted
and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture]
to address that case. Building on this architecture, "Exploiting to address that case. Building on this architecture, "Exploiting
Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs" Packet Replication 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 to limit jitter.
skipping to change at page 3, line 28 skipping to change at page 3, line 29
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 for this subset to be defined, a RPL parent subset selection
mechanism, which is among the responsibilities of the RPL Objective mechanism, which is among the responsibilities of the RPL Objective
Function (OF), needs to have specific path information. This Function (OF), needs to have specific path information. This
document focuses on the specification of the transmission of this document describes OFs which implement multi-path routing for PRE and
specific path information. specifies the transmission of this specific path information.
More concretely, this specification focuses on the extensions to the For the OFs, this document specifies a group of OFs called Common
DAG Metric Container [RFC6551] required for providing the PRE Ancestor (CA) OFs. A detailed description is made of how the path
mechanism a part of the information it needs to operate. This information is used within the CA OF and how the subset of parents
information is the RPL [RFC6550] parent address set of a node and it for forwarding packets is selected. This specification defines new
must be sent to potential children of the node. The RPL DIO Control Objective Code Points (OCPs) for these CA OFs.
Message is the canonical way of broadcasting this kind of information
and therefore its DAG Metric Container [RFC6551] field is used to For the path information, this specification focuses on the
append a Node State and Attribute (NSA) object. The node's parent extensions to the DAG Metric Container [RFC6551] required for
address set is stored as an optional TLV within the NSA object. This providing the PRE mechanism a part of the information it needs to
specification defines the type value and structure for the parent operate. This information is the RPL [RFC6550] parent address set of
address set TLV. a node and it must be sent to potential children of the node. The
RPL DIO Control Message is the canonical way of broadcasting this
kind of information and therefore its DAG Metric Container [RFC6551]
field is used to append a Node State and Attribute (NSA) object. The
node's parent address set is stored as an optional TLV within the NSA
object. This specification defines the type value and structure for
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 transmits
multiple copies of a packet using multi-path forwarding over a multiple copies of a packet using multi-path forwarding over a
multi-hop network and which consolidates multiple received packet multi-hop network and which consolidates multiple received packet
copies to control flooding. See "Exploiting Packet Replication copies to control flooding. See "Exploiting Packet Replication
and Elimination in Complex Tracks in 6TiSCH LLNs" and Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs] for more details. [I-D.papadopoulos-6tisch-pre-reqs] for more details.
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.
3. Alternative Parent Selection 3. Common Ancestor Objective Functions
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 registers an AP node as well from its Parent Set
(PS). There are multiple alternative methods of selecting the AP (PS).
node. This functionality is included in the operation of the RPL
Objective Function (OF). A scheme which allows the two paths to There are multiple alternative methods of selecting the AP node.
remain correlated is detailed here. More specifically, in this This functionality is included in the operation of the RPL Objective
scheme a node will select an AP node close to its PP node to allow Function (OF). A group of OFs which allow the two paths to remain
the operation of overhearing between parents. For more details about correlated is detailed here. More specifically, when using these OFs
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. overhearing and its use in this context see Section 4.3.
"Promiscuous Overhearing" in "Exploiting Packet Replication and "Promiscuous Overhearing" in "Exploiting Packet Replication and
Elimination in Complex Tracks in 6TiSCH LLNs" Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match [I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match
this condition, the AP with the lowest rank will be registered. this condition, the AP with the lowest rank will be registered.
There are at least three methods of performing the AP selection based The OFs described here are an extension of the The Minimum Rank with
on common ancestors (CA), named Common Ancestor Strict, Common Hysteresis Objective Function [RFC6719] (MRHOF) OF. In general,
Ancestor Medium, and Common Ancestor Relaxed, depending on how these OFs extend MRHOF by specifying how an AP is selected. The
restrictive the selection process is. A more restrictive method will selection of the PP is kept the same as in MRHOF.
limit flooding but might fail to select an appropriate AP, while a
less restrictive one will more often find an appropriate AP but might The ways in which the CA OFs modify MRHOF in a section-by-section
increase flooding. manner follows:
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, depending on
the specific variant of CA OF used.
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. 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 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.
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.
Three OFs are defined which perform AP selection based on common
ancestors, named Common Ancestor Strict, Common Ancestor Medium, and
Common Ancestor Relaxed, depending on how restrictive the selection
process is. A more restrictive method will limit flooding but might
fail to select an appropriate AP, while a less restrictive one will
more often find an appropriate AP but might increase flooding.
All three OFs apply their corresponding common ancestor 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.
3.1. Common Ancestor Strict 3.1. Common Ancestor Strict
In CA Strict, the node will check if its Preferred Grand Parent In the CA Strict OF, represented with Objective Code Point (OCP)
(PGP), the PP of its PP, is the same as the PP of the potential AP. TBD1, 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.
( 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
. .
PS(A) = {W, X} PS(A) = {W, X}
( W ) ( X ) ( Y ) ( Z ) PP(A) = X ( W ) ( X ) ( Y ) ( Z ) PP(A) = X
^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^
| \ // | \ // || \ / || PS(B) = {W, X, Y} | \ // | \ // || \ / || PS(B) = {W, X, Y}
skipping to change at page 5, line 46 skipping to change at page 7, line 46
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 CA Medium, the node will check if its Preferred Grand Parent In the CA Medium OF, represented with Objective Code Point (OCP)
(PGP), the PP of its PP, is contained in the PS of the potential AP. TBD2, the node will check if its Preferred Grand Parent (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). method 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 CA Relaxed, the node will check if the Parent Set (PS) of its In the CA Relaxed OF, represented with Objective Code Point (OCP)
Preferred Parent (PP) has a node in common with the PS of the TBD3, the node will check if the Parent Set (PS) of its Preferred
potential AP. Parent (PP) has a node in common with the PS of the 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 method 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 3.4. Usage
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. methods or other ones not described here, depending on requirements.
This document does not suggest a specific AP selection method. It is optional for all nodes to use the same AP selection method.
Additionally, it is optional for all nodes to use the same AP Different nodes may use different AP selection methods, since the
selection method. Different nodes may use different AP selection selection method is local to each node. For example, using different
methods, since the selection method is local to each node. For methods can be used to vary the transmission reliability in each hop.
example, using different methods can be used to vary the transmission
reliability in each hop.
4. Node State and Attribute (NSA) object type extension 4. 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.
skipping to change at page 8, line 12 skipping to change at page 10, line 12
Metric Container data holds the actual data and is shown expanded in Metric Container data holds the actual data and is shown expanded in
Figure 3. Figure 3.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Flags |A|O| PS type | PS Length | | | Res | Flags |A|O| PS type | PS Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA
| 6LoRH type | 6LoRH-compressed PS IPv6 address(es) ... | | PS IPv6 address(es) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DAG Metric Container (MC) data with Node State and Figure 3: DAG Metric Container (MC) data with Node State and
Attribute (NSA) object body and a TLV Attribute (NSA) object body and a TLV
The structure of the DAG Metric Container data in the form of a Node The structure of the DAG Metric Container data in the form of a Node
State and Attribute (NSA) object with a TLV in the NSA Optional TLVs State and Attribute (NSA) object with a TLV in the NSA Optional TLVs
field is shown in Figure 3. The first 32 bits comprise the DAG field is shown in Figure 3. The first 32 bits comprise the DAG
Metric Container header and all the following bits are part of the Metric Container header and all the following bits are part of the
Node State and Attribute object body, as defined in [RFC6551]. This Node State and Attribute object body, as defined in [RFC6551]. This
document defines a new TLV, which CAN be carried in the Node State document defines a new TLV, which CAN be carried in the Node State
and Attribute (NSA) object Optional TLVs field. The TLV is named and Attribute (NSA) object Optional TLVs field. The TLV is named
Parent Set and is abbreviated as PS in Figure 3. Parent Set and is abbreviated as PS in Figure 3.
PS type: The type of the Parent Set TLV. The value is TBD1. PS type: The type of the Parent Set TLV. The value is TBD4.
PS Length: The total length of the TLV value field (PS IPv6 PS Length: The total length of the TLV value field (PS IPv6
address(es)) in bytes. address(es)) in bytes.
6LoRH type: The type of 6LoRH compression applied to the PS IPv6
addresses. For detailed usage see Section 5.1 of [RFC8138].
As an overview, the compressed size of each IPv6 address in the
"6LoRH-compressed PS IPv6 address(es)" field depending on the
value of "6LoRH type" is shown in Figure 4.
+-----------+----------------------+
| 6LoRH | Length of compressed |
| Type | IPv6 address (bytes) |
+-----------+----------------------+
| 0 | 1 |
| 1 | 2 |
| 2 | 4 |
| 3 | 8 |
| 4 | 16 |
+-----------+----------------------+
Figure 4: The SRH-6LoRH Types
6LoRH-compressed PS IPv6 address(es): A sequence of zero or more
IPv6 addresses belonging to a node's parent set. Each address
requires 16 bytes. The order of the parents in the parent set
is in decreasing preference based on the Objective Function
[RFC6550] used by the node.
4.1. Usage 4.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 constraints and
is used as per [RFC6551]. is used as per [RFC6551].
4.2. Compression
The PS IPv6 address(es) field in the Parent Set TLV add overhead due
to their size. Therefore, compression is highly desirable in order
for this extension to be usable. To meet this goal, a good
compression method candidate is [RFC8138] 6LoWPAN Routing Header
(6LoRH). Furthermore, the PS IPv6 address(es) belong by definition
to nodes in the same RPL DODAG and are stored in the form of a list
of addresses. This makes this field a good candidate for the use of
the same compression as in Source Routing Header 6LoRH (SRH-6LoRH),
achieving efficiency and implementation reuse. Therefore, the PS
IPv6 address(es) field SHOULD be compressed using the compression
method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138].
5. Controlling PRE 5. 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
behaviour per flow type as described in Deterministic Networking behavior per flow type as described in Deterministic Networking
Architecture [I-D.ietf-detnet-architecture]. Architecture [I-D.ietf-detnet-architecture].
6. Security Considerations 6. 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. Therefore, the security mechanisms defined in
RPL [RFC6550] apply to this proposed extension. RPL [RFC6550] apply to this proposed extension.
7. IANA Considerations 7. IANA Considerations
This proposal requests the allocation of a new value TBD1 for the This proposal requests the allocation of new values TBD1, TBD2, TBD3
"Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry from the "Objective Code Point (OCP)" sub-registry of the "Routing
Protocol for Low Power and Lossy Networks (RPL)" registry. This
proposal also requests the allocation of a new value TBD4 for the
"Parent Set" TLV from the Routing Metric/Constraint TLVs sub-registry
from IANA. from IANA.
8. References 8. References
8.1. Informative references 8.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-23 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work
in progress), June 2019. in progress), July 2019.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019. 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-
skipping to change at page 10, line 49 skipping to change at page 12, line 11
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>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with
"IPv6 over Low-Power Wireless Personal Area Network Hysteresis Objective Function", RFC 6719,
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, DOI 10.17487/RFC6719, September 2012,
April 2017, <https://www.rfc-editor.org/info/rfc8138>. <https://www.rfc-editor.org/info/rfc6719>.
8.2. Other Informative References 8.2. Other Informative References
[IEEE802154-2015] [IEEE802154]
IEEE standard for Information Technology, "IEEE Std IEEE standard for Information Technology, "IEEE Std
802.15.4-2015 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 8.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
skipping to change at page 11, line 44 skipping to change at page 13, line 19
(21) (22) (23) (24) (25) (26) (21) (22) (23) (24) (25) (26)
(31) (32) (33) (34) (35) (36) (31) (32) (33) (34) (35) (36)
(41) (42) (43) (44) (45) (46) (41) (42) (43) (44) (45) (46)
(51) (52) (53) (54) (55) (56) (51) (52) (53) (54) (55) (56)
( S ) ( S )
Figure 5: Simulation Topology Figure 4: Simulation Topology
The simulation setup is: The simulation setup is:
Topology: 32 nodes structured in regular grid as show in Figure 5. Topology: 32 nodes structured in regular grid as show in Figure 4.
Node S (source) is the only data packet sender, and send data to Node S (source) is the only data packet sender, and send data to
node R (root). The parent set of each node (except R) is all the node R (root). The parent set of each node (except R) is all the
nodes in the immediately higher row, the immediately above 6 nodes in the immediately higher row, the immediately above 6
nodes. For example, each node in {51, 52, 53, 54, 55, 56} is nodes. For example, each node in {51, 52, 53, 54, 55, 56} is
connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13,
14, 15, 16 have a single upwards link to R. 14, 15, 16 have a single upwards link to R.
MAC: TSCH with 1 retransmission MAC: TSCH with 1 retransmission
Platform: Cooja Platform: Cooja
 End of changes. 29 change blocks. 
128 lines changed or deleted 174 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/