draft-ietf-roll-nsa-extension-01.txt   draft-ietf-roll-nsa-extension-02.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: September 12, 2019 IMT Atlantique Expires: December 26, 2019 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
March 11, 2019 June 24, 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-01 draft-ietf-roll-nsa-extension-02
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 12, 2019. This Internet-Draft will expire on December 26, 2019.
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . 6
3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. DAG Metric Container 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 . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Informative references . . . . . . . . . . . . . . . . . 10 8.1. Informative references . . . . . . . . . . . . . . . . . 10
8.2. Other Informative References . . . . . . . . . . . . . . 11 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
skipping to change at page 3, line 50 skipping to change at page 3, line 48
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:
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 node in the 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 (PS). There network registers an AP node as well from its Parent Set (PS). 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 the 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
node will select an alternative parent node close to its PP node to node will select an AP node close to its PP node to allow the
allow the operation of overhearing between parents. If multiple operation of overhearing between parents. If multiple potential APs
potential APs match this condition, the AP with the lowest rank will match this condition, the AP with the lowest 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 AP selection based
selection based on common ancestors (CA), named Common Ancestor on common ancestors (CA), named Common Ancestor Strict, Common
Strict, Common Ancestor Medium, and Common Ancestor Relaxed, Ancestor Medium, and Common Ancestor Relaxed, depending on how
depending on how restrictive the selection process is. A more restrictive the selection process is. A more restrictive method will
restrictive method will limit flooding but might fail to select an limit flooding but might fail to select an appropriate AP, while a
appropriate alternative parent, while a less restrictive one will less restrictive one will more often find an appropriate AP but might
more often find an appropriate alterantive parent but might increase increase flooding.
flooding.
3.1. Common Ancestor Strict 3.1. Common Ancestor Strict
In CA Strict, the node will check if its Preferred Grand Parent In CA Strict, the node will check if its Preferred Grand Parent
(PGP), the PP of its PP, is the same as the PP of the potential AP. (PGP), the PP of its PP, is the same as the PP of the potential AP.
( R ) root ( R ) root
. PS(S) = {A, B, C, D} . PS(S) = {A, B, C, D}
. PP(S) = C . PP(S) = C
. PP(PP(S)) = Y . PP(PP(S)) = Y
skipping to change at page 5, line 29 skipping to change at page 5, line 29
\ \ || / 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 node S must know its grandparent For example, in Figure 1, the source node S must know its grandparent
sets both through nodes A, B, C, and D. The Parent Sets (PS) and the sets through nodes A, B, C, and D. The Parent Sets (PS) and the
Preferred Parents (PS) of nodes A, B, C, and D are shown on the side Preferred Parents (PS) of nodes A, B, C, and D are shown on the side
of the figure. The CA Strict parent selection method will select an of the figure. The CA Strict parent selection method will select an
AP for node S for which PP(PP(S)) = PP(AP). Therefore, node S can AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) =
decide to use node B as its AP node, since PP(PP(S)) = Y = PP(B). Y:
o Node A: PP(A) = X and therefore it is different than PP(PP(S))
o Node B: PS(B) = Y and therefore it is equal to PP(PP(S))
o Node 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 =
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)) is in PS(AP).
Therefore, node S can decide to use node B or D as its AP node, since Given that PP(PP(S)) = Y:
given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D
PD(D) = {Y, Z}. 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 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.
3.3. Common Ancestor Relaxed 3.3. Common Ancestor Relaxed
In CA Relaxed, the node will check if its the Parent Set (PS) of its In CA Relaxed, the node will check if the Parent Set (PS) of its
Preferred Parent (PP), has a common node with the PS of the potential Preferred Parent (PP) has a node in common with the PS of the
AP. potential AP.
Using the same example, in Figure 1, the CA Relaxed parent selection Using the same example, in Figure 1, the CA Relaxed parent selection
method will select an AP for node S for which PS(PP(S)) has a non- method will select an AP for node S for which PS(PP(S)) has at least
empty intersection with PS(AP). Therefore, node S can decide to use one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}:
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:
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.
3.4. Usage 3.4. Usage
The PS information can be used by any of the described Alternative The PS information can be used by any of the described AP selection
Parent selection methods or other ones not described here, depending methods or other ones not described here, depending on requirements.
on requirements. This document does not suggest a specific AP This document does not suggest a specific AP selection method.
selection method. Additionally, it is OPTIONAL for all nodes to use Additionally, it is optional for all nodes to use the same AP
the same AP selection method. Different nodes MAY use different AP selection method. Different nodes may use different AP selection
selection methods, since the selection method is local to each node. methods, since the selection method is local to each node. For
For example, using different methods can be used to vary the example, using different methods can be used to vary the transmission
transmission reliability in each hop. 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 20 skipping to change at page 8, line 33
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.
6LoRH type: The type of 6LoRH compression applied to the PS IPv6 6LoRH type: The type of 6LoRH compression applied to the PS IPv6
addresses.https://tools.ietf.org/html/rfc8138#section-5.1 For addresses. For detailed usage see Section 5.1 of [RFC8138].
detailed usage see Section 5.1 of [RFC8138]. As an overview, As an overview, the compressed size of each IPv6 address in the
the compressed size of each IPv6 address in the "6LoRH- "6LoRH-compressed PS IPv6 address(es)" field depending on the
compressed PS IPv6 address(es)" field depending on the value of value of "6LoRH type" is shown in Figure 4.
"6LoRH type" is shown in Figure 4.
+-----------+----------------------+ +-----------+----------------------+
| 6LoRH | Length of compressed | | 6LoRH | Length of compressed |
| Type | IPv6 address (bytes) | | Type | IPv6 address (bytes) |
+-----------+----------------------+ +-----------+----------------------+
| 0 | 1 | | 0 | 1 |
| 1 | 2 | | 1 | 2 |
| 2 | 4 | | 2 | 4 |
| 3 | 8 | | 3 | 8 |
| 4 | 16 | | 4 | 16 |
skipping to change at page 8, line 48 skipping to change at page 9, line 14
6LoRH-compressed PS IPv6 address(es): A sequence of zero or more 6LoRH-compressed PS IPv6 address(es): A sequence of zero or more
IPv6 addresses belonging to a node's parent set. Each address IPv6 addresses belonging to a node's parent set. Each address
requires 16 bytes. The order of the parents in the parent set requires 16 bytes. The order of the parents in the parent set
is in decreasing preference based on the Objective Function is in decreasing preference based on the Objective Function
[RFC6550] used by the node. [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 AP selection, since it can help the alternative path to
alternative path from significantly deviating from the preferred not significantly deviate from the preferred path. The Parent Set is
path. The Parent Set is information local to the node that information local to the node that broadcasts it.
broadcasts it.
4.1.1. DAG Metric Container fields
Given the intended usage, when using the PS, the NSA object it is
contained in MUST be used as a constraint in the DAG Metric
Container. More specifically, using the PS places the following
requirements on the DAG Metric Container header fields:
o 'P' flag: MUST be cleared, since PS is used only with constraints.
o 'C' flag: MUST be set, since PS is used only with constraints.
o 'O' flag: Used as per [RFC6550], to indicated optionality.
o 'R' flag: MUST be cleared, since PS is used only with constraints.
o 'A' Field: MUST be set to 0 and ignored, since PS is used only
with constraints.
o 'Prec' Field: Used as per [RFC6550].
4.1.2. Node State and Attribute fields
For clarity reasons, the usage of the PS places no additional The PS is used only within NSA objects configured as constraints and
restrictions on the NSA flags ('A' and 'O'), which can be used as is used as per [RFC6551].
normally defined in [RFC6550].
4.2. Compression 4.2. Compression
The PS IPv6 address(es) field in the Parent Set TLV add overhead due The PS IPv6 address(es) field in the Parent Set TLV add overhead due
to their size. Therefore, compression is highly desirable in order to their size. Therefore, compression is highly desirable in order
for this extension to be usable. To meet this goal, a good for this extension to be usable. To meet this goal, a good
compression method candidate is [RFC8138] 6LoWPAN Routing Header compression method candidate is [RFC8138] 6LoWPAN Routing Header
(6LoRH). Furthermore, the PS IPv6 address(es) belong by definition (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 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 path, however it's 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 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-
skipping to change at page 10, line 25 skipping to change at page 10, line 17
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-20 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-22 (work
in progress), March 2019. in progress), June 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-12 (work in progress), March 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-
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 12, line 26 skipping to change at page 12, line 8
( S ) ( S )
Figure 5: 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 5. 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 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
Schedule: Static, 2 timeslots per link from each node to each parent Schedule: Static, 2 timeslots per link from each node to each parent
in its parent set, 1 broadcast EB slot, 1 sender-based shared in its parent set, 1 broadcast EB slot, 1 sender-based shared
timeslot (for DIO and DIS) per node (total of 32). timeslot (for DIO and DIS) per node (total of 32).
Simulation lifecycle: Allow link formation for 100 seconds before Simulation lifecycle: Allow link formation for 100 seconds before
starting to send data packets. Afterwards, S sends data packets starting to send data packets. Afterwards, S sends data packets
to R. The simulation terminates when 1000 packets have been sent to R. The simulation terminates when 1000 packets have been sent
by S. by S.
Radio Links: Links are reset uniformly randomly between 70% and 100% Radio Links: Every 60 s, a new Packet Delivery Rate is randomly
every 60 seconds. drawn for each link, with a uniform distribution spanning the 70%
to 100% interval.
Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5
seconds to R. seconds to R.
PS extension size: 3 parents. PS extension size: 3 parents.
Routing Methods: Routing Methods:
* RPL: The default RPL non-PRE implementation in Contiki OS. * RPL: The default RPL non-PRE implementation in Contiki OS.
 End of changes. 27 change blocks. 
87 lines changed or deleted 74 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/