idnits 2.17.1 draft-ietf-roll-nsa-extension-02.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 24, 2019) is 1766 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 462, but not defined -- Looks like a reference, but probably isn't: '1' on line 563 -- Looks like a reference, but probably isn't: '2' on line 566 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-22 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 26, 2019 IMT Atlantique 6 P. Thubert 7 Cisco 8 June 24, 2019 10 RPL DAG Metric Container Node State and Attribute object type extension 11 draft-ietf-roll-nsa-extension-02 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 26, 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 Industrial network applications have stringent requirements on 79 reliability and predictability, and typically leverage 1+1 80 redundancy, aka Packet Replication and Elimination (PRE) 81 [I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order 82 for wireless networks to be able to be used in such applications, the 83 principles of Deterministic Networking [I-D.ietf-detnet-architecture] 84 lead to designs that aim at maximizing packet delivery rate and 85 minimizing latency and jitter. Additionally, given that the network 86 nodes often do not have an unlimited power supply, energy consumption 87 needs to be minimized as well. 89 As an example, to meet this goal, IEEE Std. 802.15.4 90 [IEEE802154-2015] provides Time-Slotted Channel Hopping (TSCH), a 91 mode of operation which uses a fixed communication schedule to allow 92 deterministic medium access as well as channel hopping to work around 93 radio interference. However, since TSCH uses retransmissions in the 94 event of a failed transmission, end-to-end delay and jitter 95 performance can deteriorate. 97 Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE 98 Std. 802.15.4-TSCH, has worked on the issues previously highlighted 99 and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] 100 to address that case. Building on this architecture, "Exploiting 101 Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs" 102 [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the 103 Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end 104 latency, and limit jitter. 106 PRE is a general method of maximizing packet delivery rate and 107 potentially minimizing latency and jitter, not limited to 6TiSCH. 108 More specifically, PRE achieves a controlled redundancy by laying 109 multiple forwarding paths through the network and using them in 110 parallel for different copies of a same packet. PRE can follow the 111 Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL 112 from a node to the root. Building a multi-path DODAG can be achieved 113 based on the RPL capability of having multiple parents for each node 114 in a network, a subset of which is used to forward packets. In order 115 for this subset to be defined, a RPL parent subset selection 116 mechanism, which falls within the remit of the RPL Objective Function 117 (OF), needs to have specific path information. The specification of 118 the transmission of this information is the focus of this document. 120 More concretely, this specification focuses on the extensions to the 121 DAG Metric Container [RFC6551] required for providing the PRE 122 mechanism a part of the information it needs to operate. This 123 information is the RPL [RFC6550] parent address set of a node and it 124 must be sent to potential children nodes of the node. The RPL DIO 125 Control Message is the canonical way of broadcasting this kind of 126 information and therefore its DAG Metric Container [RFC6551] field is 127 used to append a Node State and Attribute (NSA) object. The node's 128 parent address set is stored as an optional TLV within the NSA 129 object. This specification defines the type value and structure for 130 this TLV. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 The draft uses the following Terminology: 140 Packet Replication and Elimination (PRE): The sending of multiple 141 copies of a packet using multi-path forwarding over a multi-hop 142 network and the consolidation of multiple received packet copies 143 to control flooding. See "Exploiting Packet Replication and 144 Elimination in Complex Tracks in 6TiSCH LLNs" 145 [I-D.papadopoulos-6tisch-pre-reqs] for more. 147 Alternative Parent (AP) Selection: The problem of how to select the 148 next hop target node for a packet copy to be forwarded to when 149 performing packet replication. 151 3. Alternative Parent Selection 153 In the RPL protocol, each node maintains a list of potential parents. 154 For PRE, the PP node is defined to be the same as the RPL DODAG 155 Preferred Parent (PP) node. Furthermore, to construct an alternative 156 path toward the root, in addition to the PP node, each node in the 157 network registers an AP node as well from its Parent Set (PS). There 158 are multiple alternative methods of selecting the AP node, 159 functionality which is included in the operation of the RPL Objective 160 Function (OF). A scheme which allows the two paths to remain 161 correlated is detailed here. More specifically, in this scheme a 162 node will select an AP node close to its PP node to allow the 163 operation of overhearing between parents. If multiple potential APs 164 match this condition, the AP with the lowest rank will be registered. 166 There are at least three methods of performing the AP selection based 167 on common ancestors (CA), named Common Ancestor Strict, Common 168 Ancestor Medium, and Common Ancestor Relaxed, depending on how 169 restrictive the selection process is. A more restrictive method will 170 limit flooding but might fail to select an appropriate AP, while a 171 less restrictive one will more often find an appropriate AP but might 172 increase flooding. 174 3.1. Common Ancestor Strict 176 In CA Strict, the node will check if its Preferred Grand Parent 177 (PGP), the PP of its PP, is the same as the PP of the potential AP. 179 ( R ) root 180 . PS(S) = {A, B, C, D} 181 . PP(S) = C 182 . PP(PP(S)) = Y 183 . 184 PS(A) = {W, X} 185 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 186 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 187 | \ // | \ // || \ / || PS(B) = {W, X, Y} 188 | // | // || / || PP(B) = Y 189 | // \ | // \ || / \ || 190 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 191 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 192 ^ ^ ^^ ^ 193 \ \ || / PS(D) = {Y, Z} 194 \ \ || / PP(D) = Z 195 \ \ || / 196 \----\\ || / || Preferred Parent 197 ( S ) source | Potential Alternative Parent 199 Figure 1: Example Common Ancestor Strict Alternative Parent Selection 200 method 202 For example, in Figure 1, the source node S must know its grandparent 203 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 204 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 205 of the figure. The CA Strict parent selection method will select an 206 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 207 Y: 209 o Node A: PP(A) = X and therefore it is different than PP(PP(S)) 211 o Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 213 o Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 215 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 216 PP(B). 218 3.2. Common Ancestor Medium 220 In CA Medium, the node will check if its Preferred Grand Parent 221 (PGP), the PP of its PP, is contained in the PS of the potential AP. 223 Using the same example, in Figure 1, the CA Medium parent selection 224 method will select an AP for node S for which PP(PP(S)) is in PS(AP). 225 Given that PP(PP(S)) = Y: 227 o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 229 o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 231 o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 233 node S can decide to use node B or D as its AP node. 235 3.3. Common Ancestor Relaxed 237 In CA Relaxed, the node will check if the Parent Set (PS) of its 238 Preferred Parent (PP) has a node in common with the PS of the 239 potential AP. 241 Using the same example, in Figure 1, the CA Relaxed parent selection 242 method will select an AP for node S for which PS(PP(S)) has at least 243 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 245 o Node A: PS(A) = {W, X} and the common nodes are {X} 247 o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 249 o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 251 node S can decide to use node A, B or D as its AP node. 253 3.4. Usage 255 The PS information can be used by any of the described AP selection 256 methods or other ones not described here, depending on requirements. 257 This document does not suggest a specific AP selection method. 258 Additionally, it is optional for all nodes to use the same AP 259 selection method. Different nodes may use different AP selection 260 methods, since the selection method is local to each node. For 261 example, using different methods can be used to vary the transmission 262 reliability in each hop. 264 4. Node State and Attribute (NSA) object type extension 266 In order to select their AP node, nodes need to be aware of their 267 grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG 268 Information Object (DIO) Control Message to broadcast information 269 about themselves to potential children. However, RPL [RFC6550], does 270 not define how to propagate parent set related information, which is 271 what this document addresses. 273 DIO messages can carry multiple options, out of which the DAG Metric 274 Container option [RFC6551] is the most suitable structurally and 275 semantically for the purpose of carrying the parent set. The DAG 276 Metric Container option itself can carry different nested objects, 277 out of which the Node State and Attribute (NSA) [RFC6551] is 278 appropriate for transferring generic node state data. Within the 279 Node State and Attribute it is possible to store optional TLVs 280 representing various node characteristics. As per the Node State and 281 Attribute (NSA) [RFC6551] description, no TLV has been defined for 282 use. This document defines one TLV for the purpose of transmitting a 283 node's parent set. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | RPLInstanceID |Version Number | Rank | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |G|0| MOP | Prf | DTSN | Flags | Reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 + + 294 | | 295 + DODAGID + 296 | | 297 + + 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | DAGMC Type (2)| DAGMC Length | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 302 | | 303 // DAG Metric Container data // 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 2: Example DIO Message with a DAG Metric Container option 309 Figure 2 shows the structure of the DIO Control Message when a DAG 310 Metric Container option is included. The DAG Metric Container option 311 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 312 registry for the RPL Control Message Options, and is defined in 313 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 314 Figure 2) expresses the DAG Metric Container length in bytes. DAG 315 Metric Container data holds the actual data and is shown expanded in 316 Figure 3. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Res | Flags |A|O| PS type | PS Length | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA 325 | 6LoRH type | 6LoRH-compressed PS IPv6 address(es) ... | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 3: DAG Metric Container (MC) data with Node State and 329 Attribute (NSA) object body and a TLV 331 The structure of the DAG Metric Container data in the form of a Node 332 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 333 field is shown in Figure 3. The first 32 bits comprise the DAG 334 Metric Container header and all the following bits are part of the 335 Node State and Attribute object body, as defined in [RFC6551]. This 336 document defines a new TLV, which CAN be carried in the Node State 337 and Attribute (NSA) object Optional TLVs field. The TLV is named 338 Parent Set and is abbreviated as PS in Figure 3. 340 PS type: The type of the Parent Set TLV. The value is TBD1. 342 PS Length: The total length of the TLV value field (PS IPv6 343 address(es)) in bytes. 345 6LoRH type: The type of 6LoRH compression applied to the PS IPv6 346 addresses. For detailed usage see Section 5.1 of [RFC8138]. 347 As an overview, the compressed size of each IPv6 address in the 348 "6LoRH-compressed PS IPv6 address(es)" field depending on the 349 value of "6LoRH type" is shown in Figure 4. 351 +-----------+----------------------+ 352 | 6LoRH | Length of compressed | 353 | Type | IPv6 address (bytes) | 354 +-----------+----------------------+ 355 | 0 | 1 | 356 | 1 | 2 | 357 | 2 | 4 | 358 | 3 | 8 | 359 | 4 | 16 | 360 +-----------+----------------------+ 362 Figure 4: The SRH-6LoRH Types 364 6LoRH-compressed PS IPv6 address(es): A sequence of zero or more 365 IPv6 addresses belonging to a node's parent set. Each address 366 requires 16 bytes. The order of the parents in the parent set 367 is in decreasing preference based on the Objective Function 368 [RFC6550] used by the node. 370 4.1. Usage 372 The PS SHOULD be used in the process of parent selection, and 373 especially in AP selection, since it can help the alternative path to 374 not significantly deviate from the preferred path. The Parent Set is 375 information local to the node that broadcasts it. 377 The PS is used only within NSA objects configured as constraints and 378 is used as per [RFC6551]. 380 4.2. Compression 382 The PS IPv6 address(es) field in the Parent Set TLV add overhead due 383 to their size. Therefore, compression is highly desirable in order 384 for this extension to be usable. To meet this goal, a good 385 compression method candidate is [RFC8138] 6LoWPAN Routing Header 386 (6LoRH). Furthermore, the PS IPv6 address(es) belong by definition 387 to nodes in the same RPL DODAG and are stored in the form of a list 388 of addresses. This makes this field a good candidate for the use of 389 the same compression as in Source Routing Header 6LoRH (SRH-6LoRH), 390 achieving efficiency and implementation reuse. Therefore, the PS 391 IPv6 address(es) field SHOULD be compressed using the compression 392 method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138]. 394 5. Controlling PRE 396 PRE is very helpful when the aim is to increase reliability for a 397 certain path, however its use creates additional traffic as part of 398 the replication process. It is conceivable that not all paths have 399 stringent reliability requirements. Therefore, a way to control 400 whether PRE is applied to a path's packets SHOULD be implemented. 401 For example, a traffic class label can be used to determine this 402 behaviour per flow type as described in Deterministic Networking 403 Architecture [I-D.ietf-detnet-architecture]. 405 6. Security Considerations 407 The structure of the DIO control message is extended, within the pre- 408 defined DIO options. Therefore, the security mechanisms defined in 409 RPL [RFC6550] apply to this proposed extension. 411 7. IANA Considerations 413 This proposal requests the allocation of a new value TBD1 for the 414 "Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry 415 from IANA. 417 8. References 419 8.1. Informative references 421 [I-D.ietf-6tisch-architecture] 422 Thubert, P., "An Architecture for IPv6 over the TSCH mode 423 of IEEE 802.15.4", draft-ietf-6tisch-architecture-22 (work 424 in progress), June 2019. 426 [I-D.ietf-detnet-architecture] 427 Finn, N., Thubert, P., Varga, B., and J. Farkas, 428 "Deterministic Networking Architecture", draft-ietf- 429 detnet-architecture-13 (work in progress), May 2019. 431 [I-D.papadopoulos-6tisch-pre-reqs] 432 Papadopoulos, G., Montavont, N., and P. Thubert, 433 "Exploiting Packet Replication and Elimination in Complex 434 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 435 reqs-02 (work in progress), July 2018. 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 443 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 444 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 445 Low-Power and Lossy Networks", RFC 6550, 446 DOI 10.17487/RFC6550, March 2012, 447 . 449 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 450 and D. Barthel, "Routing Metrics Used for Path Calculation 451 in Low-Power and Lossy Networks", RFC 6551, 452 DOI 10.17487/RFC6551, March 2012, 453 . 455 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 456 "IPv6 over Low-Power Wireless Personal Area Network 457 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 458 April 2017, . 460 8.2. Other Informative References 462 [IEEE802154-2015] 463 IEEE standard for Information Technology, "IEEE Std 464 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 465 Networks (WPANs)", December 2015. 467 8.3. URIs 469 [1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll- 470 nsa-extension 472 [2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit 473 ;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138 475 Appendix A. Implementation Status 477 A research-stage implementation of the PRE mechanism using the 478 proposed extension as part of a 6TiSCH IOT use case was developed at 479 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 480 Koutsiamanis. It was implemented on the open-source Contiki OS and 481 tested with the Cooja simulator. The DIO DAGMC NSA extension is 482 implemented with a configurable number of parents from the parent set 483 of a node to be reported. 485 ( R ) 487 (11) (12) (13) (14) (15) (16) 489 (21) (22) (23) (24) (25) (26) 491 (31) (32) (33) (34) (35) (36) 493 (41) (42) (43) (44) (45) (46) 495 (51) (52) (53) (54) (55) (56) 497 ( S ) 499 Figure 5: Simulation Topology 501 The simulation setup is: 503 Topology: 32 nodes structured in regular grid as show in Figure 5. 504 Node S (source) is the only data packet sender, and send data to 505 node R (root). The parent set of each node (except R) is all the 506 nodes in the immediately higher row, the immediately above 6 507 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 508 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 509 14, 15, 16 have a single upwards link to R. 511 MAC: TSCH with 1 retransmission 513 Platform: Cooja 515 Schedule: Static, 2 timeslots per link from each node to each parent 516 in its parent set, 1 broadcast EB slot, 1 sender-based shared 517 timeslot (for DIO and DIS) per node (total of 32). 519 Simulation lifecycle: Allow link formation for 100 seconds before 520 starting to send data packets. Afterwards, S sends data packets 521 to R. The simulation terminates when 1000 packets have been sent 522 by S. 524 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 525 drawn for each link, with a uniform distribution spanning the 70% 526 to 100% interval. 528 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 529 seconds to R. 531 PS extension size: 3 parents. 533 Routing Methods: 535 * RPL: The default RPL non-PRE implementation in Contiki OS. 537 * 2nd ETX: PRE with a parent selection method which picks as AP 538 the 2nd best parent in the parent set based on ETX. 540 * CA Strict: As described in Section 3.1. 542 * CA Medium: As described in Section 3.2. 544 Simulation results: 546 +----------+---------------+------------------+---------------------+ 547 | Routing | Average | Average | Average | 548 | Method | Packet | Traversed | Duplications/packet | 549 | | Delivery Rate | Nodes/packet (#) | (#) | 550 | | (%) | | | 551 +----------+---------------+------------------+---------------------+ 552 | RPL | 82.70 | 5.56 | 7.02 | 553 | 2nd ETX | 99.38 | 14.43 | 31.29 | 554 | CA | 97.32 | 9.86 | 18.23 | 555 | Strict | | | | 556 | CA | 99.66 | 13.75 | 28.86 | 557 | Medium | | | | 558 +----------+---------------+------------------+---------------------+ 560 Links: 562 o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 563 extension branch) [1] 565 o Wireshark dissectors (for the optional TLV, i.e., PS) - currently 566 merged / in master [2] 568 Authors' Addresses 570 Remous-Aris Koutsiamanis (editor) 571 IMT Atlantique 572 Office B00 - 126A 573 2 Rue de la Chataigneraie 574 Cesson-Sevigne - Rennes 35510 575 FRANCE 577 Phone: +33 299 12 70 49 578 Email: aris@ariskou.com 580 Georgios Papadopoulos 581 IMT Atlantique 582 Office B00 - 114A 583 2 Rue de la Chataigneraie 584 Cesson-Sevigne - Rennes 35510 585 FRANCE 587 Phone: +33 299 12 70 04 588 Email: georgios.papadopoulos@imt-atlantique.fr 589 Nicolas Montavont 590 IMT Atlantique 591 Office B00 - 106A 592 2 Rue de la Chataigneraie 593 Cesson-Sevigne - Rennes 35510 594 FRANCE 596 Phone: +33 299 12 70 23 597 Email: nicolas.montavont@imt-atlantique.fr 599 Pascal Thubert 600 Cisco Systems, Inc 601 Building D 602 45 Allee des Ormes - BP1200 603 MOUGINS - Sophia Antipolis 06254 604 FRANCE 606 Phone: +33 497 23 26 34 607 Email: pthubert@cisco.com