< draft-ietf-roll-nsa-extension-00.txt   draft-ietf-roll-nsa-extension-01.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: June 21, 2019 IMT Atlantique Expires: September 12, 2019 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
December 18, 2018 March 11, 2019
RPL DAG Metric Container Node State and Attribute object type extension RPL DAG Metric Container Node State and Attribute object type extension
draft-ietf-roll-nsa-extension-00 draft-ietf-roll-nsa-extension-01
Abstract Abstract
Implementing 6TiSCH Packet Replication and Elimination from / to the Implementing Packet Replication and Elimination from / to the RPL
RPL root requires the ability to forward copies of packets over root requires the ability to forward copies of packets over different
different paths via different RPL parents. Selecting the appropriate paths via different RPL parents. Selecting the appropriate parents
parents to achieve ultra-low latency and jitter requires information to achieve ultra-low latency and jitter requires information about a
about a node's parents. This document details what information needs node's parents. This document details what information needs to be
to be transmitted and how it is encoded within a packet to enable transmitted and how it is encoded within a packet to enable this
this functionality. functionality.
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 June 21, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Alternative Parent Selection . . . . . . . . . . . . . . . . 4 3. Alternative Parent Selection . . . . . . . . . . . . . . . . 4
3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 4 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 4
3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 5 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 5
3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 5 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 5
3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Node State and Attribute (NSA) object type extension . . . . 6 4. Node State and Attribute (NSA) object type extension . . . . 6
4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. DAG Metric Container fields . . . . . . . . . . . . . 8 4.1.1. DAG Metric Container fields . . . . . . . . . . . . . 9
4.1.2. Node State and Attribute fields . . . . . . . . . . . 9 4.1.2. Node State and Attribute fields . . . . . . . . . . . 9
4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9
5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 9 5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Informative references . . . . . . . . . . . . . . . . . 10 8.1. Informative references . . . . . . . . . . . . . . . . . 10
8.2. Other Informative References . . . . . . . . . . . . . . 10 8.2. Other Informative References . . . . . . . . . . . . . . 11
Appendix A. Implementation Status . . . . . . . . . . . . . . . 11 Appendix A. Implementation Status . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Industrial network applications have stringent requirements on Industrial network applications have stringent requirements on
reliability and predictability, and typically leverage 1+1 reliability and predictability, and typically leverage 1+1
redundancy, aka Packet Replication and Elimination (PRE) redundancy, aka Packet Replication and Elimination (PRE)
[I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order [I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order
for wireless networks to be able to be used in such applications, the for wireless networks to be able to be used in such applications, the
principles of Deterministic Networking [I-D.ietf-detnet-architecture] principles of Deterministic Networking [I-D.ietf-detnet-architecture]
lead to designs that aim at maximizing packet delivery rate and lead to designs that aim at maximizing packet delivery rate and
minimizing latency and jitter. Additionally, given that the network minimizing latency and jitter. Additionally, given that the network
nodes often do not have an unlimited power supply, energy consumption nodes often do not have an unlimited power supply, energy consumption
needs to be minimized as well. needs to be minimized as well.
To meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015] provides As an example, to meet this goal, IEEE Std. 802.15.4
Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a [IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a
fixed communication schedule to allow deterministic medium access as mode of operation which uses a fixed communication schedule to allow
well as channel hopping to work around radio interference. However, deterministic medium access as well as channel hopping to work around
since TSCH uses retransmissions in the event of a failed radio interference. However, since TSCH uses retransmissions in the
transmission, end-to-end delay and jitter performance can event of a failed transmission, end-to-end delay and jitter
deteriorate. performance can deteriorate.
The 6TiSCH working group, focusing on IPv6 over IEEE Std. Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE
802.15.4-TSCH, has worked on the issues previously highlighted and Std. 802.15.4-TSCH, has worked on the issues previously highlighted
produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture]
address that case. Building on this architecture, "Exploiting Packet to address that case. Building on this architecture, "Exploiting
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), provide a hard bound to the end-to-end Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end
latency, and limit jitter. latency, and limit jitter.
PRE achieves a controlled redundancy by laying multiple forwarding PRE is a general method of maximizing packet delivery rate and
paths through the network and using them in parallel for different potentially minimizing latency and jitter, not limited to 6TiSCH.
copies of a same packet. PRE can follow the Destination-Oriented More specifically, PRE achieves a controlled redundancy by laying
Directed Acyclic Graph (DODAG) formed by RPL from a node to the root. multiple forwarding paths through the network and using them in
Building a multi-path DODAG can be achieved based on the RPL parallel for different copies of a same packet. PRE can follow the
capability of having multiple parents for each node in a network, a Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL
subset of which is used to forward packets. In order for this subset from a node to the root. Building a multi-path DODAG can be achieved
to be defined, a RPL parent subset selection mechanism, which falls based on the RPL capability of having multiple parents for each node
within the remit of the RPL Objective Function (OF), needs to have in a network, a subset of which is used to forward packets. In order
specific path information. The specification of the transmission of for this subset to be defined, a RPL parent subset selection
this information is the focus of this document. mechanism, which falls within the remit of the RPL Objective Function
(OF), needs to have specific path information. The specification of
the transmission of this information is the focus of this document.
More concretely, this specification focuses on the extensions to the More concretely, this specification focuses on the extensions to the
DAG Metric Container [RFC6551] required for providing the PRE DAG Metric Container [RFC6551] required for providing the PRE
mechanism a part of the information it needs to operate. This mechanism a part of the information it needs to operate. This
information is the RPL [RFC6550] parent address set of a node and it information is the RPL [RFC6550] parent address set of a node and it
must be sent to potential children nodes of the node. The RPL DIO must be sent to potential children nodes of the node. The RPL DIO
Control Message is the canonical way of broadcasting this kind of Control Message is the canonical way of broadcasting this kind of
information and therefore its DAG Metric Container [RFC6551] field is information and therefore its DAG Metric Container [RFC6551] field is
used to append a Node State and Attribute (NSA) object. The node's 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 parent address set is stored as an optional TLV within the NSA
skipping to change at page 3, line 46 skipping to change at page 3, line 50
this TLV. this 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:
Track A sequence of 6TiSCH schedule resources to support a single-
path multi-hop transmission of a packet. See "6TiSCH
Architecture" [I-D.ietf-6tisch-architecture] for more.
Complex Track A Track which supports a multi-path multi-hop
transmission of a packet. See "6TiSCH Architecture"
[I-D.ietf-6tisch-architecture] for more.
Packet Replication and Elimination (PRE) The sending of multiple Packet Replication and Elimination (PRE) The sending of multiple
copies of a packet using multi-path forwarding over a multi-hop copies of a packet using multi-path forwarding over a multi-hop
network and the consolidation of multiple received packet copies network and the consolidation of multiple received packet copies
to control flooding. See "Exploiting Packet Replication and to control flooding. See "Exploiting Packet Replication and
Elimination in Complex Tracks in 6TiSCH LLNs" Elimination in Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs] for more. [I-D.papadopoulos-6tisch-pre-reqs] for more.
Alternative Parent (AP) Selection The problem of how to select the Alternative Parent (AP) Selection The problem of how to select the
next hop target node for a packet copy to be forwarded to when next hop target node for a packet copy to be forwarded to when
performing packet replication. performing packet replication.
3. Alternative Parent Selection 3. Alternative Parent Selection
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 PP node is defined to be the same as the RPL DODAG For PRE, the PP node is defined to be the same as the RPL DODAG
Preferred Parent (PP) node. Furthermore, to construct an alternative Preferred Parent (PP) node. Furthermore, to construct an alternative
path toward the root, in addition to the PP node, each 6TiSCH node in path toward the root, in addition to the PP node, each node in the
the network registers an AP node as well from its Parent Set (PS). network registers an AP node as well from its Parent Set (PS). There
There are multiple alternative methods of selecting the AP node, are multiple alternative methods of selecting the AP node,
functionality which is included in operation of the RPL Objective functionality which is included in operation of the RPL Objective
Function (OF). A scheme which allows the two paths to remain Function (OF). A scheme which allows the two paths to remain
correlated is detailed here. More specifically, in this scheme a correlated is detailed here. More specifically, in this scheme a
6TiSCH node will select an alternative parent node close to its PP node will select an alternative parent node close to its PP node to
node to allow the operation of overhearing between parents. If allow the operation of overhearing between parents. If multiple
multiple potential APs match this condition, the AP with the lowest potential APs match this condition, the AP with the lowest rank will
rank will be registered. be registered.
There are at least three methods of performing the alternative parent There are at least three methods of performing the alternative parent
selection based on common ancestors (CA), named Common Ancestor selection based on common ancestors (CA), named Common Ancestor
Strict, Common Ancestor Medium, and Common Ancestor Relaxed, Strict, Common Ancestor Medium, and Common Ancestor Relaxed,
depending on how restrictive the selection process is. A more depending on how restrictive the selection process is. A more
restrictive method will limit flooding but might fail to select an restrictive method will limit flooding but might fail to select an
appropriate alternative parent, while a less restrictive one will appropriate alternative parent, while a less restrictive one will
more often find an appropriate alterantive parent but might increase more often find an appropriate alterantive parent but might increase
flooding. flooding.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
^ ^ ^^ ^ ^ ^ ^^ ^
\ \ || / 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 method
For example, in Figure 1, the source 6TiSCH node S must know its For example, in Figure 1, the source node S must know its grandparent
grandparent sets both through nodes A, B, C, and D. The Parent Sets sets both through nodes A, B, C, and D. The Parent Sets (PS) and the
(PS) and the Preferred Parents (PS) of nodes A, B, C, and D are shown Preferred Parents (PS) of nodes A, B, C, and D are shown on the side
on the side of the figure. The CA Strict parent selection method of the figure. The CA Strict parent selection method will select an
will select an AP for node S for which PP(PP(S)) = PP(AP). AP for node S for which PP(PP(S)) = PP(AP). Therefore, node S can
Therefore, node S can decide to use node B as its AP node, since decide to use node B as its AP node, since PP(PP(S)) = Y = PP(B).
PP(PP(S)) = Y = 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 CA Medium, 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)) in PS(AP). method will select an AP for node S for which PP(PP(S)) in PS(AP).
Therefore, node S can decide to use node B or D as its AP node, since Therefore, node S can decide to use node B or D as its AP node, since
given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D
skipping to change at page 6, line 17 skipping to change at page 6, line 17
empty intersection with PS(AP). Therefore, node S can decide to use empty intersection with PS(AP). Therefore, node S can decide to use
node A, B or D as its AP node. Given that PS(PP(S)) = {X, Y, Z} the node A, B or D as its AP node. Given that PS(PP(S)) = {X, Y, Z} the
alternative parent selection process evaluates the nodes: alternative parent selection process evaluates the nodes:
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}
3.4. Usage
The PS information can be used by any of the described Alternative
Parent selection methods or other ones not described here, depending
on requirements. This document does not suggest a specific AP
selection method. Additionally, it is OPTIONAL for all nodes to use
the same AP selection method. Different nodes MAY use different AP
selection methods, since the selection method is local to each node.
For 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, 6TiSCH nodes need to be aware of In order to select their AP node, nodes need to be aware of their
their grandparent node sets. Within RPL [RFC6550], the nodes use the grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG
DODAG Information Object (DIO) Control Message to broadcast Information Object (DIO) Control Message to broadcast information
information about themselves to potential children. However, RPL about themselves to potential children. However, RPL [RFC6550], does
[RFC6550], does not define how to propagate parent set related not define how to propagate parent set related information, which is
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
semantically for the purpose of carrying the parent set. The DAG semantically for the purpose of carrying the parent set. The DAG
Metric Container option itself can carry different nested objects, Metric Container option itself can carry different nested objects,
out of which the Node State and Attribute (NSA) [RFC6551] is out of which the Node State and Attribute (NSA) [RFC6551] is
appropriate for transferring generic node state data. Within the appropriate for transferring generic node state data. Within the
Node State and Attribute it is possible to store optional TLVs Node State and Attribute it is possible to store optional TLVs
representing various node characteristics. As per the Node State and representing various node characteristics. As per the Node State and
Attribute (NSA) [RFC6551] description, no TLV has been defined for Attribute (NSA) [RFC6551] description, no TLV has been defined for
skipping to change at page 7, line 38 skipping to change at page 7, line 38
Figure 2 shows the structure of the DIO Control Message when a DAG Figure 2 shows the structure of the DIO Control Message when a DAG
Metric Container option is included. The DAG Metric Container option Metric Container option is included. The DAG Metric Container option
type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA
registry for the RPL Control Message Options, and is defined in registry for the RPL Control Message Options, and is defined in
[RFC6550]. The DAG Metric Container option length (DAGMC Length in [RFC6550]. The DAG Metric Container option length (DAGMC Length in
Figure 2) expresses the DAG Metric Container length in bytes. DAG Figure 2) expresses the DAG Metric Container length in bytes. DAG
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
| PS IPv6 address(es) ... | | 6LoRH type | 6LoRH-compressed 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 TBD1.
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.
PS IPv6 address(es): A sequence of zero or more IPv6 addresses 6LoRH type: The type of 6LoRH compression applied to the PS IPv6
belonging to a node's parent set. Each address requires 16 addresses.https://tools.ietf.org/html/rfc8138#section-5.1 For
bytes. The order of the parents in the parent set is in detailed usage see Section 5.1 of [RFC8138]. As an overview,
decreasing preference based on the Objective Function [RFC6550] the compressed size of each IPv6 address in the "6LoRH-
used by the node. 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 alternative parent selection, since it can help the especially in alternative parent selection, since it can help the
alternative path from significantly deviating from the preferred alternative path from significantly deviating from the preferred
path. The Parent Set is information local to the node that path. The Parent Set is information local to the node that
broadcasts it. broadcasts it.
4.1.1. DAG Metric Container fields 4.1.1. DAG Metric Container fields
skipping to change at page 9, line 28 skipping to change at page 9, line 48
to nodes in the same RPL DODAG and are stored in the form of a list 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 of addresses. This makes this field a good candidate for the use of
the same compression as in Source Routing Header 6LoRH (SRH-6LoRH), the same compression as in Source Routing Header 6LoRH (SRH-6LoRH),
achieving efficiency and implementation reuse. Therefore, the PS achieving efficiency and implementation reuse. Therefore, the PS
IPv6 address(es) field SHOULD be compressed using the compression IPv6 address(es) field SHOULD be compressed using the compression
method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138]. 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 track, however it's use creates additional traffic as part of certain path, however it's use creates additional traffic as part of
the replication process. It is conceivable that not all tracks 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 track'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 behaviour 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.
skipping to change at page 10, line 4 skipping to change at page 10, line 20
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 a new value TBD1 for the
"Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry "Parent Set" TLV in 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-19 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work
in progress), December 2018. in progress), March 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-09 (work in progress), October 2018. detnet-architecture-12 (work in progress), March 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,
skipping to change at page 11, line 37 skipping to change at page 12, 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 4: Simulation Topology Figure 5: Simulation Topology
The simulation setup is: The simulation setup is:
Topology: 32 nodes structured in regular grid as show in Figure 4. Topology: 32 nodes structured in regular grid as show in Figure 5.
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 immediatelly higher row, the immediatelly above 6 nodes in the immediatelly higher row, the immediatelly 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. 28 change blocks. 
90 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/