draft-ietf-roll-nsa-extension-05.txt   draft-ietf-roll-nsa-extension-06.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: May 7, 2020 IMT Atlantique Expires: August 13, 2020 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
November 4, 2019 February 10, 2020
Common Ancestor Objective Functions and Parent Set DAG Metric Container Common Ancestor Objective Function and Parent Set DAG Metric Container
Extension Extension
draft-ietf-roll-nsa-extension-05 draft-ietf-roll-nsa-extension-06
Abstract Abstract
Implementing Packet Replication and Elimination from / to the RPL Implementing Packet Replication and Elimination from/to the RPL root
root requires the ability to forward copies of packets over different 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 RPL control packets to
functionality. This document also describes Objective Functions enable this functionality. This document also describes Objective
which take advantage of this information to implement multi-path Function which take advantage of this information to implement multi-
routing. 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 May 7, 2020. This Internet-Draft will expire on August 13, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 Functions . . . . . . . . . . . . . 4 3. Common Ancestor Objective Function . . . . . . . . . . . . . 4
3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 6 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 6
3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 7 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 7
3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 8 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 8
3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Node State and Attribute (NSA) object type extension . . . . 8 4. Node State and Attribute (NSA) object type extension . . . . 8
4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 10 5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Informative references . . . . . . . . . . . . . . . . . 11 8.1. Informative references . . . . . . . . . . . . . . . . . 11
8.2. Other Informative References . . . . . . . . . . . . . . 12 8.2. Other Informative References . . . . . . . . . . . . . . 12
Appendix A. Implementation Status . . . . . . . . . . . . . . . 12 Appendix A. Implementation Status . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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.
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] is a technique which allows
applications to function over wireless networks requires the redundant paths in the network to be utilized for traffic requiring
application of the principles of Deterministic Networking higher reliability. Allowing these kinds of applications to function
[I-D.ietf-detnet-architecture]. This results in designs which aim at over wireless networks requires the application of the principles of
optimizing packet delivery rate and bounding latency. Additionally, Deterministic Networking [I-D.ietf-detnet-architecture]. This
given that the network nodes often do not have an unlimited power results in designs which aim at optimizing packet delivery rate and
supply, energy consumption needs to be minimized as well. bounding latency. Additionally, given that the network nodes often
do not have an unlimited power supply, energy consumption needs to be
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 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
skipping to change at page 3, line 32 skipping to change at page 3, line 33
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 describes OFs which implement multi-path routing for PRE and document describes OFs which implement multi-path routing for PRE and
specifies the transmission of this specific path information. specifies the transmission of this specific path information.
For the OFs, this document specifies a group of OFs called Common This document describes a new objective function (OF) called the
Ancestor (CA) OFs. A detailed description is made of how the path Common Ancestor (CA) OF. A detailed description is given of how the
information is used within the CA OF and how the subset of parents path information is used within the CA OF and how the subset of
for forwarding packets is selected. This specification defines a new parents for forwarding packets is selected. This specification
shared Objective Code Point (OCP) for these CA OFs. 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
RPL DIO Control Message is the canonical way of broadcasting this RPL DIO Control Message is the canonical way of broadcasting this
kind of information and therefore its DAG Metric Container [RFC6551] kind of information and therefore its DAG Metric Container [RFC6551]
field is used to append a Node State and Attribute (NSA) object. The 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 node's parent address set is stored as an optional TLV within the NSA
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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.
Parent Set (PS): Given a RPL node, the set of its neighbor nodes
which participate in the same RPL DODAG and which can potentially
take the role of the node's preferred parent.
Alternative Parent (AP): A RPL parent in the parent set of a node
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.
3. Common Ancestor Objective Functions Preferred Grand Parent (PGP): The preferred parent of the preferred
parent of a node.
3. Common Ancestor Objective Function
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). (PS).
There are multiple alternative methods of selecting the AP node. There are multiple alternative methods of selecting the AP node.
This functionality is included in the operation of the RPL Objective This functionality is included in the operation of the RPL Objective
Function (OF). A group of OFs which allow the two paths to remain Function (OF). An OF which allows the two paths to remain correlated
correlated is detailed here. More specifically, when using these OFs is detailed here. More specifically, when using this OF a node will
a node will select an AP node close to its PP node to allow the select an AP node close to its PP node to allow the operation of
operation of overhearing between parents. For more details about overhearing between parents. For more details about overhearing and
overhearing and its use in this context see Section 4.3. its use in this context see Section 4.3. "Promiscuous Overhearing"
"Promiscuous Overhearing" in "Exploiting Packet Replication and in "Exploiting Packet Replication and Elimination in Complex Tracks
Elimination in Complex Tracks in 6TiSCH LLNs" in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs]. If multiple
[I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match potential APs match this condition, the AP with the lowest rank will
this condition, the AP with the lowest rank will be registered. be registered.
The OFs described here are an extension of the The Minimum Rank with The OF described here is an extension of the The Minimum Rank with
Hysteresis Objective Function [RFC6719] (MRHOF) OF. In general, Hysteresis Objective Function [RFC6719] (MRHOF). In general, this OF
these OFs extend MRHOF by specifying how an AP is selected. extends MRHOF by specifying how an AP is selected. Importantly, the
Importantly, the calculation of the rank of the node though each calculation of the rank of the node through each candidate neighbor
candidate neighbor and the selection of the PP is kept the same as in and the selection of the PP is kept the same as in MRHOF.
MRHOF.
The ways in which the CA OFs modify MRHOF in a section-by-section The ways in which the CA OF modifies MRHOF in a section-by-section
manner follows in detail: manner follows in detail:
3. The Minimum Rank with Hysteresis Objective Function: Same as 3. The Minimum Rank with Hysteresis Objective Function:
MRHOF extended to AP selection. Minimum Rank path selection and Same as MRHOF extended to AP selection. Minimum Rank path
switching applies correspondingly to the AP with the extra CA selection and switching applies correspondingly to the AP with the
requirement of having some match between ancestors, depending on extra CA requirement of having some match between ancestors.
the specific variant of CA OF used.
3.1. Computing the Path Cost: Same as MRHOF extended to AP 3.1. Computing the Path Cost: Same as MRHOF extended to AP
selection. If a candidate neighbor does not fulfill the CA selection. If a candidate neighbor does not fulfill the CA
requirement then the path through that neighbor SHOULD be set to requirement then the path through that neighbor SHOULD be set to
MAX_PATH_COST. As a result, the node MUST NOT select the MAX_PATH_COST, the same value used by MRHOF. As a result, the
candidate neighbor as its AP. node MUST NOT select the candidate neighbor as its AP.
3.2. Parent Selection: Same as MRHOF extended to AP selection. To 3.2. Parent Selection: Same as MRHOF extended to AP selection. To
allow hysteresis, AP selection maintains a variable, allow hysteresis, AP selection maintains a variable,
cur_ap_min_path_cost, which is the path cost of the current AP. 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.1. When Parent Selection Runs: Same as MRHOF.
3.2.2. Parent Selection Algorithm: Same as MRHOF extended to AP 3.2.2. Parent Selection Algorithm: Same as MRHOF extended to AP
selection. If the smallest path cost for paths through the selection. If the smallest path cost for paths through the
candidate neighbors is smaller than cur_ap_min_path_cost by less candidate neighbors is smaller than cur_ap_min_path_cost by less
than PARENT_SWITCH_THRESHOLD, the node MAY continue to use the than PARENT_SWITCH_THRESHOLD (the same variable as MRHOF uses),
current AP. Additionally, if there is no PP selected, there MUST the node MAY continue to use the current AP. Additionally, if
NOT be any AP selected as well. Finally, as with MRHOF, a node there is no PP selected, there MUST NOT be any AP selected as
MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors well. Finally, as with MRHOF, a node MAY include up to
in its alternative parent set. 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.3. Computing Rank: Same as MRHOF.
3.4. Advertising the Path Cost: Same as MRHOF. 3.4. Advertising the Path Cost: Same as MRHOF.
3.5. Working without Metric Containers: It is not possible to work 3.5. Working without Metric Containers: It is not possible to work
without metric containers, since CA AP selection requires without metric containers, since CA AP selection requires
information from parents regarding their parent sets, which is information from parents regarding their parent sets, which is
transmitted via the NSA object in the DIO Mectric Container. transmitted via the NSA object in the DIO Mectric Container.
skipping to change at page 8, line 35 skipping to change at page 8, line 35
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.
It is optional for all nodes to use the same AP selection method, and It is optional for all nodes to use the same AP selection method.
because the CA OFs share the same OCP, they can do that withing the Different nodes may use different AP selection methods, since the
same RPL Instance. 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 10, line 30 skipping to change at page 10, line 30
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 TBD2. PS type: The type of the Parent Set TLV. The value is TBD2.
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. The length is an integral multiple of
16, the number of bytes in an IPv6 address.
PS IPv6 address(es) One or more 128-bit IPv6 address(es) without any
separator between them. The field consists of one IPv6 address
per parent in the parent set. The parent addresses are listed
in decreasing order of preference and not all parents in the
parent set need to be included. The selection of how many
parents from the parent set are to be included is left to the
implementation. The number of parent addresses in the PS IPv6
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
in an IPv6 address.
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]. As a result, the PS does not affect the is used as per [RFC6551]. As a result, the PS does not affect the
calculation of the rank through candidate neighbors. It is only used calculation of the rank through candidate neighbors. It is only used
with the CA OFs to remove nodes which do not fulfill the CA OF with the CA OF to remove nodes which do not fulfill the CA OF
criteria from the candidate neighbor list. criteria from the candidate neighbor list.
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
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 [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 11, line 19 skipping to change at page 11, line 32
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 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. This proposal also for Low Power and Lossy Networks (RPL)" registry.
requests the allocation of a new value TBD2 for the "Parent Set" TLV
from the Routing Metric/Constraint TLVs sub-registry from IANA. This proposal also requests the allocation of a new value TBD2 for
the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-
registry 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-28 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work
in progress), October 2019. in progress), October 2019.
skipping to change at page 14, line 23 skipping to change at page 14, line 35
* 2nd ETX: PRE with a parent selection method which picks as AP * 2nd ETX: PRE with a parent selection method which picks as AP
the 2nd best parent in the parent set based on ETX. the 2nd best parent in the parent set based on ETX.
* CA Strict: As described in Section 3.1. * CA Strict: As described in Section 3.1.
* CA Medium: As described in Section 3.2. * CA Medium: As described in Section 3.2.
Simulation results: Simulation results:
+----------+---------------+------------------+---------------------+ +-----------+---------------+-----------------+---------------------+
| Routing | Average | Average | Average | | Routing | Average | Average | Average |
| Method | Packet | Traversed | Duplications/packet | | Method | Packet | Traversed | Duplications/packet |
| | Delivery Rate | Nodes/packet (#) | (#) | | | Delivery Rate | Nodes/packet | (#) |
| | (%) | | | | | (%) | (#) | |
+----------+---------------+------------------+---------------------+ +-----------+---------------+-----------------+---------------------+
| RPL | 82.70 | 5.56 | 7.02 | | RPL | 82.70 | 5.56 | 7.02 |
| 2nd ETX | 99.38 | 14.43 | 31.29 | | 2nd ETX | 99.38 | 14.43 | 31.29 |
| CA | 97.32 | 9.86 | 18.23 | | CA Strict | 97.32 | 9.86 | 18.23 |
| Strict | | | | | CA Medium | 99.66 | 13.75 | 28.86 |
| CA | 99.66 | 13.75 | 28.86 | +-----------+---------------+-----------------+---------------------+
| Medium | | | |
+----------+---------------+------------------+---------------------+
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]
Authors' Addresses Authors' Addresses
 End of changes. 28 change blocks. 
84 lines changed or deleted 104 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/