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