idnits 2.17.1 draft-ietf-roll-nsa-extension-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2019) is 1764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE802154-2015' is mentioned on line 468, but not defined -- Looks like a reference, but probably isn't: '1' on line 569 -- Looks like a reference, but probably isn't: '2' on line 572 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-23 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Koutsiamanis, Ed. 3 Internet-Draft G. Papadopoulos 4 Intended status: Standards Track N. Montavont 5 Expires: December 30, 2019 IMT Atlantique 6 P. Thubert 7 Cisco 8 June 28, 2019 10 RPL DAG Metric Container Node State and Attribute object type extension 11 draft-ietf-roll-nsa-extension-03 13 Abstract 15 Implementing Packet Replication and Elimination from / to the RPL 16 root requires the ability to forward copies of packets over different 17 paths via different RPL parents. Selecting the appropriate parents 18 to achieve ultra-low latency and jitter requires information about a 19 node's parents. This document details what information needs to be 20 transmitted and how it is encoded within a packet to enable this 21 functionality. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 30, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Alternative Parent Selection . . . . . . . . . . . . . . . . 4 60 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 4 61 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 5 62 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6 63 3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Node State and Attribute (NSA) object type extension . . . . 6 65 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8.1. Informative references . . . . . . . . . . . . . . . . . 10 72 8.2. Other Informative References . . . . . . . . . . . . . . 11 73 Appendix A. Implementation Status . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 Network-enabled applications in the industrial context must provide 79 stringent guarantees in terms of reliability and predictability. To 80 achieve this they typically leverage 1+1 redundancy, also known as 81 Packet Replication and Elimination (PRE) 82 [I-D.papadopoulos-6tisch-pre-reqs]. Allowing these kinds of 83 applications to function over wireless networks requires the 84 application of the principles of Deterministic Networking 85 [I-D.ietf-detnet-architecture]. This results in designs which aim at 86 maximizing packet delivery rate and minimizing latency and jitter. 87 Additionally, given that the network nodes often do not have an 88 unlimited power supply, energy consumption needs to be minimized as 89 well. 91 As an example, to meet this goal, IEEE Std. 802.15.4 92 [IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a 93 mode of operation which uses a common communication schedule based on 94 timeslots to allow deterministic medium access as well as channel 95 hopping to work around radio interference. However, since TSCH uses 96 retransmissions in the event of a failed transmission, end-to-end 97 delay and jitter performance can deteriorate. 99 Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE 100 Std. 802.15.4-TSCH, has worked on the issues previously highlighted 101 and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] 102 to address that case. Building on this architecture, "Exploiting 103 Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs" 104 [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the 105 Packet Delivery Ratio (PDR), to provide a hard bound to the end-to- 106 end latency, and to limit jitter. 108 PRE is a general method of maximizing packet delivery rate and 109 potentially minimizing latency and jitter, not limited to 6TiSCH. 110 More specifically, PRE achieves controlled redundancy by laying 111 multiple forwarding paths through the network and using them in 112 parallel for different copies of a same packet. PRE can follow the 113 Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL 114 from a node to the root. Building a multi-path DODAG can be achieved 115 based on the RPL capability of having multiple parents for each node 116 in a network, a subset of which is used to forward packets. In order 117 for this subset to be defined, a RPL parent subset selection 118 mechanism, which is among the responsibilities of the RPL Objective 119 Function (OF), needs to have specific path information. This 120 document focuses on the specification of the transmission of this 121 specific path information. 123 More concretely, this specification focuses on the extensions to the 124 DAG Metric Container [RFC6551] required for providing the PRE 125 mechanism a part of the information it needs to operate. This 126 information is the RPL [RFC6550] parent address set of a node and it 127 must be sent to potential children of the node. The RPL DIO Control 128 Message is the canonical way of broadcasting this kind of information 129 and therefore its DAG Metric Container [RFC6551] field is used to 130 append a Node State and Attribute (NSA) object. The node's parent 131 address set is stored as an optional TLV within the NSA object. This 132 specification defines the type value and structure for the parent 133 address set TLV. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 The draft uses the following Terminology: 143 Packet Replication and Elimination (PRE): A method which transmits 144 multiple copies of a packet using multi-path forwarding over a 145 multi-hop network and which consolidates multiple received packet 146 copies to control flooding. See "Exploiting Packet Replication 147 and Elimination in Complex Tracks in 6TiSCH LLNs" 148 [I-D.papadopoulos-6tisch-pre-reqs] for more details. 150 Alternative Parent (AP) Selection: The mechanism for choosing the 151 next hop node to forward a packet copy when replicating packets. 153 3. Alternative Parent Selection 155 In the RPL protocol, each node maintains a list of potential parents. 156 For PRE, the Preferred Parent (PP) node is defined to be the same as 157 the RPL DODAG Preferred Parent node. Furthermore, to construct an 158 alternative path toward the root, in addition to the PP node, each 159 node in the network registers an AP node as well from its Parent Set 160 (PS). There are multiple alternative methods of selecting the AP 161 node. This functionality is included in the operation of the RPL 162 Objective Function (OF). A scheme which allows the two paths to 163 remain correlated is detailed here. More specifically, in this 164 scheme a node will select an AP node close to its PP node to allow 165 the operation of overhearing between parents. For more details about 166 overhearing and its use in this context see Section 4.3. 167 "Promiscuous Overhearing" in "Exploiting Packet Replication and 168 Elimination in Complex Tracks in 6TiSCH LLNs" 169 [I-D.papadopoulos-6tisch-pre-reqs]. If multiple potential APs match 170 this condition, the AP with the lowest rank will be registered. 172 There are at least three methods of performing the AP selection based 173 on common ancestors (CA), named Common Ancestor Strict, Common 174 Ancestor Medium, and Common Ancestor Relaxed, depending on how 175 restrictive the selection process is. A more restrictive method will 176 limit flooding but might fail to select an appropriate AP, while a 177 less restrictive one will more often find an appropriate AP but might 178 increase flooding. 180 3.1. Common Ancestor Strict 182 In CA Strict, the node will check if its Preferred Grand Parent 183 (PGP), the PP of its PP, is the same as the PP of the potential AP. 185 ( R ) root 186 . PS(S) = {A, B, C, D} 187 . PP(S) = C 188 . PP(PP(S)) = Y 189 . 190 PS(A) = {W, X} 191 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 192 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 193 | \ // | \ // || \ / || PS(B) = {W, X, Y} 194 | // | // || / || PP(B) = Y 195 | // \ | // \ || / \ || 196 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 197 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 198 ^ ^ ^^ ^ 199 \ \ || / PS(D) = {Y, Z} 200 \ \ || / PP(D) = Z 201 \ \ || / 202 \----\\ || / || Preferred Parent 203 ( S ) source | Potential Alternative Parent 205 Figure 1: Example Common Ancestor Strict Alternative Parent Selection 206 method 208 For example, in Figure 1, the source node S must know its grandparent 209 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 210 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 211 of the figure. The CA Strict parent selection method will select an 212 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 213 Y: 215 o Node A: PP(A) = X and therefore it is different than PP(PP(S)) 217 o Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 219 o Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 221 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 222 PP(B). 224 3.2. Common Ancestor Medium 226 In CA Medium, the node will check if its Preferred Grand Parent 227 (PGP), the PP of its PP, is contained in the PS of the potential AP. 229 Using the same example, in Figure 1, the CA Medium parent selection 230 method will select an AP for node S for which PP(PP(S)) is in PS(AP). 231 Given that PP(PP(S)) = Y: 233 o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 235 o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 237 o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 239 node S can decide to use node B or D as its AP node. 241 3.3. Common Ancestor Relaxed 243 In CA Relaxed, the node will check if the Parent Set (PS) of its 244 Preferred Parent (PP) has a node in common with the PS of the 245 potential AP. 247 Using the same example, in Figure 1, the CA Relaxed parent selection 248 method will select an AP for node S for which PS(PP(S)) has at least 249 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 251 o Node A: PS(A) = {W, X} and the common nodes are {X} 253 o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 255 o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 257 node S can decide to use node A, B or D as its AP node. 259 3.4. Usage 261 The PS information can be used by any of the described AP selection 262 methods or other ones not described here, depending on requirements. 263 This document does not suggest a specific AP selection method. 264 Additionally, it is optional for all nodes to use the same AP 265 selection method. Different nodes may use different AP selection 266 methods, since the selection method is local to each node. For 267 example, using different methods can be used to vary the transmission 268 reliability in each hop. 270 4. Node State and Attribute (NSA) object type extension 272 In order to select their AP node, nodes need to be aware of their 273 grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG 274 Information Object (DIO) Control Message to broadcast information 275 about themselves to potential children. However, RPL [RFC6550], does 276 not define how to propagate parent set related information, which is 277 what this document addresses. 279 DIO messages can carry multiple options, out of which the DAG Metric 280 Container option [RFC6551] is the most suitable structurally and 281 semantically for the purpose of carrying the parent set. The DAG 282 Metric Container option itself can carry different nested objects, 283 out of which the Node State and Attribute (NSA) [RFC6551] is 284 appropriate for transferring generic node state data. Within the 285 Node State and Attribute it is possible to store optional TLVs 286 representing various node characteristics. As per the Node State and 287 Attribute (NSA) [RFC6551] description, no TLV has been defined for 288 use. This document defines one TLV for the purpose of transmitting a 289 node's parent set. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | RPLInstanceID |Version Number | Rank | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |G|0| MOP | Prf | DTSN | Flags | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 + + 300 | | 301 + DODAGID + 302 | | 303 + + 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | DAGMC Type (2)| DAGMC Length | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 308 | | 309 // DAG Metric Container data // 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 2: Example DIO Message with a DAG Metric Container option 315 Figure 2 shows the structure of the DIO Control Message when a DAG 316 Metric Container option is included. The DAG Metric Container option 317 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 318 registry for the RPL Control Message Options, and is defined in 319 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 320 Figure 2) expresses the DAG Metric Container length in bytes. DAG 321 Metric Container data holds the actual data and is shown expanded in 322 Figure 3. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Res | Flags |A|O| PS type | PS Length | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA 331 | 6LoRH type | 6LoRH-compressed PS IPv6 address(es) ... | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 3: DAG Metric Container (MC) data with Node State and 335 Attribute (NSA) object body and a TLV 337 The structure of the DAG Metric Container data in the form of a Node 338 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 339 field is shown in Figure 3. The first 32 bits comprise the DAG 340 Metric Container header and all the following bits are part of the 341 Node State and Attribute object body, as defined in [RFC6551]. This 342 document defines a new TLV, which CAN be carried in the Node State 343 and Attribute (NSA) object Optional TLVs field. The TLV is named 344 Parent Set and is abbreviated as PS in Figure 3. 346 PS type: The type of the Parent Set TLV. The value is TBD1. 348 PS Length: The total length of the TLV value field (PS IPv6 349 address(es)) in bytes. 351 6LoRH type: The type of 6LoRH compression applied to the PS IPv6 352 addresses. For detailed usage see Section 5.1 of [RFC8138]. 353 As an overview, the compressed size of each IPv6 address in the 354 "6LoRH-compressed PS IPv6 address(es)" field depending on the 355 value of "6LoRH type" is shown in Figure 4. 357 +-----------+----------------------+ 358 | 6LoRH | Length of compressed | 359 | Type | IPv6 address (bytes) | 360 +-----------+----------------------+ 361 | 0 | 1 | 362 | 1 | 2 | 363 | 2 | 4 | 364 | 3 | 8 | 365 | 4 | 16 | 366 +-----------+----------------------+ 368 Figure 4: The SRH-6LoRH Types 370 6LoRH-compressed PS IPv6 address(es): A sequence of zero or more 371 IPv6 addresses belonging to a node's parent set. Each address 372 requires 16 bytes. The order of the parents in the parent set 373 is in decreasing preference based on the Objective Function 374 [RFC6550] used by the node. 376 4.1. Usage 378 The PS SHOULD be used in the process of parent selection, and 379 especially in AP selection, since it can help the alternative path to 380 not significantly deviate from the preferred path. The Parent Set is 381 information local to the node that broadcasts it. 383 The PS is used only within NSA objects configured as constraints and 384 is used as per [RFC6551]. 386 4.2. Compression 388 The PS IPv6 address(es) field in the Parent Set TLV add overhead due 389 to their size. Therefore, compression is highly desirable in order 390 for this extension to be usable. To meet this goal, a good 391 compression method candidate is [RFC8138] 6LoWPAN Routing Header 392 (6LoRH). Furthermore, the PS IPv6 address(es) belong by definition 393 to nodes in the same RPL DODAG and are stored in the form of a list 394 of addresses. This makes this field a good candidate for the use of 395 the same compression as in Source Routing Header 6LoRH (SRH-6LoRH), 396 achieving efficiency and implementation reuse. Therefore, the PS 397 IPv6 address(es) field SHOULD be compressed using the compression 398 method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138]. 400 5. Controlling PRE 402 PRE is very helpful when the aim is to increase reliability for a 403 certain path, however its use creates additional traffic as part of 404 the replication process. It is conceivable that not all paths have 405 stringent reliability requirements. Therefore, a way to control 406 whether PRE is applied to a path's packets SHOULD be implemented. 407 For example, a traffic class label can be used to determine this 408 behaviour per flow type as described in Deterministic Networking 409 Architecture [I-D.ietf-detnet-architecture]. 411 6. Security Considerations 413 The structure of the DIO control message is extended, within the pre- 414 defined DIO options. Therefore, the security mechanisms defined in 415 RPL [RFC6550] apply to this proposed extension. 417 7. IANA Considerations 419 This proposal requests the allocation of a new value TBD1 for the 420 "Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry 421 from IANA. 423 8. References 425 8.1. Informative references 427 [I-D.ietf-6tisch-architecture] 428 Thubert, P., "An Architecture for IPv6 over the TSCH mode 429 of IEEE 802.15.4", draft-ietf-6tisch-architecture-23 (work 430 in progress), June 2019. 432 [I-D.ietf-detnet-architecture] 433 Finn, N., Thubert, P., Varga, B., and J. Farkas, 434 "Deterministic Networking Architecture", draft-ietf- 435 detnet-architecture-13 (work in progress), May 2019. 437 [I-D.papadopoulos-6tisch-pre-reqs] 438 Papadopoulos, G., Montavont, N., and P. Thubert, 439 "Exploiting Packet Replication and Elimination in Complex 440 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 441 reqs-02 (work in progress), July 2018. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 449 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 450 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 451 Low-Power and Lossy Networks", RFC 6550, 452 DOI 10.17487/RFC6550, March 2012, 453 . 455 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 456 and D. Barthel, "Routing Metrics Used for Path Calculation 457 in Low-Power and Lossy Networks", RFC 6551, 458 DOI 10.17487/RFC6551, March 2012, 459 . 461 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 462 "IPv6 over Low-Power Wireless Personal Area Network 463 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 464 April 2017, . 466 8.2. Other Informative References 468 [IEEE802154-2015] 469 IEEE standard for Information Technology, "IEEE Std 470 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 471 Networks (WPANs)", December 2015. 473 8.3. URIs 475 [1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll- 476 nsa-extension 478 [2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit 479 ;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138 481 Appendix A. Implementation Status 483 A research-stage implementation of the PRE mechanism using the 484 proposed extension as part of a 6TiSCH IOT use case was developed at 485 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 486 Koutsiamanis. It was implemented on the open-source Contiki OS and 487 tested with the Cooja simulator. The DIO DAGMC NSA extension is 488 implemented with a configurable number of parents from the parent set 489 of a node to be reported. 491 ( R ) 493 (11) (12) (13) (14) (15) (16) 495 (21) (22) (23) (24) (25) (26) 497 (31) (32) (33) (34) (35) (36) 499 (41) (42) (43) (44) (45) (46) 501 (51) (52) (53) (54) (55) (56) 503 ( S ) 505 Figure 5: Simulation Topology 507 The simulation setup is: 509 Topology: 32 nodes structured in regular grid as show in Figure 5. 510 Node S (source) is the only data packet sender, and send data to 511 node R (root). The parent set of each node (except R) is all the 512 nodes in the immediately higher row, the immediately above 6 513 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 514 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 515 14, 15, 16 have a single upwards link to R. 517 MAC: TSCH with 1 retransmission 519 Platform: Cooja 521 Schedule: Static, 2 timeslots per link from each node to each parent 522 in its parent set, 1 broadcast EB slot, 1 sender-based shared 523 timeslot (for DIO and DIS) per node (total of 32). 525 Simulation lifecycle: Allow link formation for 100 seconds before 526 starting to send data packets. Afterwards, S sends data packets 527 to R. The simulation terminates when 1000 packets have been sent 528 by S. 530 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 531 drawn for each link, with a uniform distribution spanning the 70% 532 to 100% interval. 534 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 535 seconds to R. 537 PS extension size: 3 parents. 539 Routing Methods: 541 * RPL: The default RPL non-PRE implementation in Contiki OS. 543 * 2nd ETX: PRE with a parent selection method which picks as AP 544 the 2nd best parent in the parent set based on ETX. 546 * CA Strict: As described in Section 3.1. 548 * CA Medium: As described in Section 3.2. 550 Simulation results: 552 +----------+---------------+------------------+---------------------+ 553 | Routing | Average | Average | Average | 554 | Method | Packet | Traversed | Duplications/packet | 555 | | Delivery Rate | Nodes/packet (#) | (#) | 556 | | (%) | | | 557 +----------+---------------+------------------+---------------------+ 558 | RPL | 82.70 | 5.56 | 7.02 | 559 | 2nd ETX | 99.38 | 14.43 | 31.29 | 560 | CA | 97.32 | 9.86 | 18.23 | 561 | Strict | | | | 562 | CA | 99.66 | 13.75 | 28.86 | 563 | Medium | | | | 564 +----------+---------------+------------------+---------------------+ 566 Links: 568 o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 569 extension branch) [1] 571 o Wireshark dissectors (for the optional PS TLV) - currently merged 572 / in master [2] 574 Authors' Addresses 576 Remous-Aris Koutsiamanis (editor) 577 IMT Atlantique 578 Office B00 - 126A 579 2 Rue de la Chataigneraie 580 Cesson-Sevigne - Rennes 35510 581 FRANCE 583 Phone: +33 299 12 70 49 584 Email: aris@ariskou.com 586 Georgios Papadopoulos 587 IMT Atlantique 588 Office B00 - 114A 589 2 Rue de la Chataigneraie 590 Cesson-Sevigne - Rennes 35510 591 FRANCE 593 Phone: +33 299 12 70 04 594 Email: georgios.papadopoulos@imt-atlantique.fr 595 Nicolas Montavont 596 IMT Atlantique 597 Office B00 - 106A 598 2 Rue de la Chataigneraie 599 Cesson-Sevigne - Rennes 35510 600 FRANCE 602 Phone: +33 299 12 70 23 603 Email: nicolas.montavont@imt-atlantique.fr 605 Pascal Thubert 606 Cisco Systems, Inc 607 Building D 608 45 Allee des Ormes - BP1200 609 MOUGINS - Sophia Antipolis 06254 610 FRANCE 612 Phone: +33 497 23 26 34 613 Email: pthubert@cisco.com