idnits 2.17.1 draft-ietf-roll-nsa-extension-01.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 (March 11, 2019) is 1873 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 476, but not defined -- Looks like a reference, but probably isn't: '1' on line 576 -- Looks like a reference, but probably isn't: '2' on line 579 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-20 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 Summary: 0 errors (**), 0 flaws (~~), 4 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: September 12, 2019 IMT Atlantique 6 P. Thubert 7 Cisco 8 March 11, 2019 10 RPL DAG Metric Container Node State and Attribute object type extension 11 draft-ietf-roll-nsa-extension-01 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 September 12, 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 . . . . . . . . . . . . . . . . . 5 63 3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Node State and Attribute (NSA) object type extension . . . . 6 65 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1.1. DAG Metric Container fields . . . . . . . . . . . . . 9 67 4.1.2. Node State and Attribute fields . . . . . . . . . . . 9 68 4.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Informative references . . . . . . . . . . . . . . . . . 10 74 8.2. Other Informative References . . . . . . . . . . . . . . 11 75 Appendix A. Implementation Status . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Industrial network applications have stringent requirements on 81 reliability and predictability, and typically leverage 1+1 82 redundancy, aka Packet Replication and Elimination (PRE) 83 [I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order 84 for wireless networks to be able to be used in such applications, the 85 principles of Deterministic Networking [I-D.ietf-detnet-architecture] 86 lead to designs that aim at maximizing packet delivery rate and 87 minimizing latency and jitter. Additionally, given that the network 88 nodes often do not have an unlimited power supply, energy consumption 89 needs to be minimized as 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 fixed communication schedule to allow 94 deterministic medium access as well as channel hopping to work around 95 radio interference. However, since TSCH uses retransmissions in the 96 event of a failed transmission, end-to-end delay and jitter 97 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), provide a hard bound to the end-to-end 106 latency, and 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 a 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 falls within the remit of the RPL Objective Function 119 (OF), needs to have specific path information. The specification of 120 the transmission of this information is the focus of this document. 122 More concretely, this specification focuses on the extensions to the 123 DAG Metric Container [RFC6551] required for providing the PRE 124 mechanism a part of the information it needs to operate. This 125 information is the RPL [RFC6550] parent address set of a node and it 126 must be sent to potential children nodes of the node. The RPL DIO 127 Control Message is the canonical way of broadcasting this kind of 128 information and therefore its DAG Metric Container [RFC6551] field is 129 used to append a Node State and Attribute (NSA) object. The node's 130 parent address set is stored as an optional TLV within the NSA 131 object. This specification defines the type value and structure for 132 this TLV. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 The draft uses the following Terminology: 142 Packet Replication and Elimination (PRE) The sending of multiple 143 copies of a packet using multi-path forwarding over a multi-hop 144 network and the consolidation of multiple received packet copies 145 to control flooding. See "Exploiting Packet Replication and 146 Elimination in Complex Tracks in 6TiSCH LLNs" 147 [I-D.papadopoulos-6tisch-pre-reqs] for more. 149 Alternative Parent (AP) Selection The problem of how to select the 150 next hop target node for a packet copy to be forwarded to when 151 performing packet replication. 153 3. Alternative Parent Selection 155 In the RPL protocol, each node maintains a list of potential parents. 156 For PRE, the PP node is defined to be the same as the RPL DODAG 157 Preferred Parent (PP) node. Furthermore, to construct an alternative 158 path toward the root, in addition to the PP node, each node in the 159 network registers an AP node as well from its Parent Set (PS). There 160 are multiple alternative methods of selecting the AP node, 161 functionality which is included in operation of the RPL Objective 162 Function (OF). A scheme which allows the two paths to remain 163 correlated is detailed here. More specifically, in this scheme a 164 node will select an alternative parent node close to its PP node to 165 allow the operation of overhearing between parents. If multiple 166 potential APs match this condition, the AP with the lowest rank will 167 be registered. 169 There are at least three methods of performing the alternative parent 170 selection based on common ancestors (CA), named Common Ancestor 171 Strict, Common Ancestor Medium, and Common Ancestor Relaxed, 172 depending on how restrictive the selection process is. A more 173 restrictive method will limit flooding but might fail to select an 174 appropriate alternative parent, while a less restrictive one will 175 more often find an appropriate alterantive parent but might increase 176 flooding. 178 3.1. Common Ancestor Strict 180 In CA Strict, the node will check if its Preferred Grand Parent 181 (PGP), the PP of its PP, is the same as the PP of the potential AP. 183 ( R ) root 184 . PS(S) = {A, B, C, D} 185 . PP(S) = C 186 . PP(PP(S)) = Y 187 . 188 PS(A) = {W, X} 189 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 190 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 191 | \ // | \ // || \ / || PS(B) = {W, X, Y} 192 | // | // || / || PP(B) = Y 193 | // \ | // \ || / \ || 194 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 195 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 196 ^ ^ ^^ ^ 197 \ \ || / PS(D) = {Y, Z} 198 \ \ || / PP(D) = Z 199 \ \ || / 200 \----\\ || / || Preferred Parent 201 ( S ) source | Potential Alternative Parent 203 Figure 1: Example Common Ancestor Strict Alternative Parent Selection 204 method 206 For example, in Figure 1, the source node S must know its grandparent 207 sets both through nodes A, B, C, and D. The Parent Sets (PS) and the 208 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 209 of the figure. The CA Strict parent selection method will select an 210 AP for node S for which PP(PP(S)) = PP(AP). Therefore, node S can 211 decide to use node B as its AP node, since PP(PP(S)) = Y = PP(B). 213 3.2. Common Ancestor Medium 215 In CA Medium, the node will check if its Preferred Grand Parent 216 (PGP), the PP of its PP, is contained in the PS of the potential AP. 218 Using the same example, in Figure 1, the CA Medium parent selection 219 method will select an AP for node S for which PP(PP(S)) in PS(AP). 220 Therefore, node S can decide to use node B or D as its AP node, since 221 given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D 222 PD(D) = {Y, Z}. 224 3.3. Common Ancestor Relaxed 226 In CA Relaxed, the node will check if its the Parent Set (PS) of its 227 Preferred Parent (PP), has a common node with the PS of the potential 228 AP. 230 Using the same example, in Figure 1, the CA Relaxed parent selection 231 method will select an AP for node S for which PS(PP(S)) has a non- 232 empty intersection with PS(AP). Therefore, node S can decide to use 233 node A, B or D as its AP node. Given that PS(PP(S)) = {X, Y, Z} the 234 alternative parent selection process evaluates the nodes: 236 o Node A: PS(A) = {W, X} and the common nodes are {X} 238 o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 240 o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 242 3.4. Usage 244 The PS information can be used by any of the described Alternative 245 Parent selection methods or other ones not described here, depending 246 on requirements. This document does not suggest a specific AP 247 selection method. Additionally, it is OPTIONAL for all nodes to use 248 the same AP selection method. Different nodes MAY use different AP 249 selection methods, since the selection method is local to each node. 250 For example, using different methods can be used to vary the 251 transmission reliability in each hop. 253 4. Node State and Attribute (NSA) object type extension 255 In order to select their AP node, nodes need to be aware of their 256 grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG 257 Information Object (DIO) Control Message to broadcast information 258 about themselves to potential children. However, RPL [RFC6550], does 259 not define how to propagate parent set related information, which is 260 what this document addresses. 262 DIO messages can carry multiple options, out of which the DAG Metric 263 Container option [RFC6551] is the most suitable structurally and 264 semantically for the purpose of carrying the parent set. The DAG 265 Metric Container option itself can carry different nested objects, 266 out of which the Node State and Attribute (NSA) [RFC6551] is 267 appropriate for transferring generic node state data. Within the 268 Node State and Attribute it is possible to store optional TLVs 269 representing various node characteristics. As per the Node State and 270 Attribute (NSA) [RFC6551] description, no TLV has been defined for 271 use. This document defines one TLV for the purpose of transmitting a 272 node's parent set. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | RPLInstanceID |Version Number | Rank | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |G|0| MOP | Prf | DTSN | Flags | Reserved | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 + + 283 | | 284 + DODAGID + 285 | | 286 + + 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | DAGMC Type (2)| DAGMC Length | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 291 | | 292 // DAG Metric Container data // 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 2: Example DIO Message with a DAG Metric Container option 298 Figure 2 shows the structure of the DIO Control Message when a DAG 299 Metric Container option is included. The DAG Metric Container option 300 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 301 registry for the RPL Control Message Options, and is defined in 302 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 303 Figure 2) expresses the DAG Metric Container length in bytes. DAG 304 Metric Container data holds the actual data and is shown expanded in 305 Figure 3. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Res | Flags |A|O| PS type | PS Length | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA 314 | 6LoRH type | 6LoRH-compressed PS IPv6 address(es) ... | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 3: DAG Metric Container (MC) data with Node State and 318 Attribute (NSA) object body and a TLV 320 The structure of the DAG Metric Container data in the form of a Node 321 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 322 field is shown in Figure 3. The first 32 bits comprise the DAG 323 Metric Container header and all the following bits are part of the 324 Node State and Attribute object body, as defined in [RFC6551]. This 325 document defines a new TLV, which CAN be carried in the Node State 326 and Attribute (NSA) object Optional TLVs field. The TLV is named 327 Parent Set and is abbreviated as PS in Figure 3. 329 PS type: The type of the Parent Set TLV. The value is TBD1. 331 PS Length: The total length of the TLV value field (PS IPv6 332 address(es)) in bytes. 334 6LoRH type: The type of 6LoRH compression applied to the PS IPv6 335 addresses.https://tools.ietf.org/html/rfc8138#section-5.1 For 336 detailed usage see Section 5.1 of [RFC8138]. As an overview, 337 the compressed size of each IPv6 address in the "6LoRH- 338 compressed PS IPv6 address(es)" field depending on the value of 339 "6LoRH type" is shown in Figure 4. 341 +-----------+----------------------+ 342 | 6LoRH | Length of compressed | 343 | Type | IPv6 address (bytes) | 344 +-----------+----------------------+ 345 | 0 | 1 | 346 | 1 | 2 | 347 | 2 | 4 | 348 | 3 | 8 | 349 | 4 | 16 | 350 +-----------+----------------------+ 352 Figure 4: The SRH-6LoRH Types 354 6LoRH-compressed PS IPv6 address(es): A sequence of zero or more 355 IPv6 addresses belonging to a node's parent set. Each address 356 requires 16 bytes. The order of the parents in the parent set 357 is in decreasing preference based on the Objective Function 358 [RFC6550] used by the node. 360 4.1. Usage 362 The PS SHOULD be used in the process of parent selection, and 363 especially in alternative parent selection, since it can help the 364 alternative path from significantly deviating from the preferred 365 path. The Parent Set is information local to the node that 366 broadcasts it. 368 4.1.1. DAG Metric Container fields 370 Given the intended usage, when using the PS, the NSA object it is 371 contained in MUST be used as a constraint in the DAG Metric 372 Container. More specifically, using the PS places the following 373 requirements on the DAG Metric Container header fields: 375 o 'P' flag: MUST be cleared, since PS is used only with constraints. 377 o 'C' flag: MUST be set, since PS is used only with constraints. 379 o 'O' flag: Used as per [RFC6550], to indicated optionality. 381 o 'R' flag: MUST be cleared, since PS is used only with constraints. 383 o 'A' Field: MUST be set to 0 and ignored, since PS is used only 384 with constraints. 386 o 'Prec' Field: Used as per [RFC6550]. 388 4.1.2. Node State and Attribute fields 390 For clarity reasons, the usage of the PS places no additional 391 restrictions on the NSA flags ('A' and 'O'), which can be used as 392 normally defined in [RFC6550]. 394 4.2. Compression 396 The PS IPv6 address(es) field in the Parent Set TLV add overhead due 397 to their size. Therefore, compression is highly desirable in order 398 for this extension to be usable. To meet this goal, a good 399 compression method candidate is [RFC8138] 6LoWPAN Routing Header 400 (6LoRH). Furthermore, the PS IPv6 address(es) belong by definition 401 to nodes in the same RPL DODAG and are stored in the form of a list 402 of addresses. This makes this field a good candidate for the use of 403 the same compression as in Source Routing Header 6LoRH (SRH-6LoRH), 404 achieving efficiency and implementation reuse. Therefore, the PS 405 IPv6 address(es) field SHOULD be compressed using the compression 406 method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138]. 408 5. Controlling PRE 410 PRE is very helpful when the aim is to increase reliability for a 411 certain path, however it's use creates additional traffic as part of 412 the replication process. It is conceivable that not all paths have 413 stringent reliability requirements. Therefore, a way to control 414 whether PRE is applied to a path's packets SHOULD be implemented. 415 For example, a traffic class label can be used to determine this 416 behaviour per flow type as described in Deterministic Networking 417 Architecture [I-D.ietf-detnet-architecture]. 419 6. Security Considerations 421 The structure of the DIO control message is extended, within the pre- 422 defined DIO options. Therefore, the security mechanisms defined in 423 RPL [RFC6550] apply to this proposed extension. 425 7. IANA Considerations 427 This proposal requests the allocation of a new value TBD1 for the 428 "Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry 429 from IANA. 431 8. References 433 8.1. Informative references 435 [I-D.ietf-6tisch-architecture] 436 Thubert, P., "An Architecture for IPv6 over the TSCH mode 437 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 438 in progress), March 2019. 440 [I-D.ietf-detnet-architecture] 441 Finn, N., Thubert, P., Varga, B., and J. Farkas, 442 "Deterministic Networking Architecture", draft-ietf- 443 detnet-architecture-12 (work in progress), March 2019. 445 [I-D.papadopoulos-6tisch-pre-reqs] 446 Papadopoulos, G., Montavont, N., and P. Thubert, 447 "Exploiting Packet Replication and Elimination in Complex 448 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 449 reqs-02 (work in progress), July 2018. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997, 454 . 456 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 457 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 458 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 459 Low-Power and Lossy Networks", RFC 6550, 460 DOI 10.17487/RFC6550, March 2012, 461 . 463 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 464 and D. Barthel, "Routing Metrics Used for Path Calculation 465 in Low-Power and Lossy Networks", RFC 6551, 466 DOI 10.17487/RFC6551, March 2012, 467 . 469 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 470 "IPv6 over Low-Power Wireless Personal Area Network 471 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 472 April 2017, . 474 8.2. Other Informative References 476 [IEEE802154-2015] 477 IEEE standard for Information Technology, "IEEE Std 478 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 479 Networks (WPANs)", December 2015. 481 8.3. URIs 483 [1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll- 484 nsa-extension 486 [2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit 487 ;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138 489 Appendix A. Implementation Status 491 A research-stage implementation of the PRE mechanism using the 492 proposed extension as part of a 6TiSCH IOT use case was developed at 493 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 494 Koutsiamanis. It was implemented on the open-source Contiki OS and 495 tested with the Cooja simulator. The DIO DAGMC NSA extension is 496 implemented with a configurable number of parents from the parent set 497 of a node to be reported. 499 ( R ) 501 (11) (12) (13) (14) (15) (16) 503 (21) (22) (23) (24) (25) (26) 505 (31) (32) (33) (34) (35) (36) 507 (41) (42) (43) (44) (45) (46) 509 (51) (52) (53) (54) (55) (56) 511 ( S ) 513 Figure 5: Simulation Topology 515 The simulation setup is: 517 Topology: 32 nodes structured in regular grid as show in Figure 5. 518 Node S (source) is the only data packet sender, and send data to 519 node R (root). The parent set of each node (except R) is all the 520 nodes in the immediatelly higher row, the immediatelly above 6 521 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 522 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 523 14, 15, 16 have a single upwards link to R. 525 MAC: TSCH with 1 retransmission 527 Platform: Cooja 529 Schedule: Static, 2 timeslots per link from each node to each parent 530 in its parent set, 1 broadcast EB slot, 1 sender-based shared 531 timeslot (for DIO and DIS) per node (total of 32). 533 Simulation lifecycle: Allow link formation for 100 seconds before 534 starting to send data packets. Afterwards, S sends data packets 535 to R. The simulation terminates when 1000 packets have been sent 536 by S. 538 Radio Links: Links are reset uniformly randomly between 70% and 100% 539 every 60 seconds. 541 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 542 seconds to R. 544 PS extension size: 3 parents. 546 Routing Methods: 548 * RPL: The default RPL non-PRE implementation in Contiki OS. 550 * 2nd ETX: PRE with a parent selection method which picks as AP 551 the 2nd best parent in the parent set based on ETX. 553 * CA Strict: As described in Section 3.1. 555 * CA Medium: As described in Section 3.2. 557 Simulation results: 559 +----------+---------------+------------------+---------------------+ 560 | Routing | Average | Average | Average | 561 | Method | Packet | Traversed | Duplications/packet | 562 | | Delivery Rate | Nodes/packet (#) | (#) | 563 | | (%) | | | 564 +----------+---------------+------------------+---------------------+ 565 | RPL | 82.70 | 5.56 | 7.02 | 566 | 2nd ETX | 99.38 | 14.43 | 31.29 | 567 | CA | 97.32 | 9.86 | 18.23 | 568 | Strict | | | | 569 | CA | 99.66 | 13.75 | 28.86 | 570 | Medium | | | | 571 +----------+---------------+------------------+---------------------+ 573 Links: 575 o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 576 extension branch) [1] 578 o Wireshark dissectors (for the optional TLV, i.e., PS) - currently 579 merged / in master [2] 581 Authors' Addresses 582 Remous-Aris Koutsiamanis (editor) 583 IMT Atlantique 584 Office B00 - 126A 585 2 Rue de la Chataigneraie 586 Cesson-Sevigne - Rennes 35510 587 FRANCE 589 Phone: +33 299 12 70 49 590 Email: aris@ariskou.com 592 Georgios Papadopoulos 593 IMT Atlantique 594 Office B00 - 114A 595 2 Rue de la Chataigneraie 596 Cesson-Sevigne - Rennes 35510 597 FRANCE 599 Phone: +33 299 12 70 04 600 Email: georgios.papadopoulos@imt-atlantique.fr 602 Nicolas Montavont 603 IMT Atlantique 604 Office B00 - 106A 605 2 Rue de la Chataigneraie 606 Cesson-Sevigne - Rennes 35510 607 FRANCE 609 Phone: +33 299 12 70 23 610 Email: nicolas.montavont@imt-atlantique.fr 612 Pascal Thubert 613 Cisco Systems, Inc 614 Building D 615 45 Allee des Ormes - BP1200 616 MOUGINS - Sophia Antipolis 06254 617 FRANCE 619 Phone: +33 497 23 26 34 620 Email: pthubert@cisco.com