idnits 2.17.1 draft-ietf-roll-nsa-extension-06.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 (February 10, 2020) is 1531 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' is mentioned on line 543, but not defined -- Looks like a reference, but probably isn't: '1' on line 641 -- Looks like a reference, but probably isn't: '2' on line 644 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 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: August 13, 2020 IMT Atlantique 6 P. Thubert 7 Cisco 8 February 10, 2020 10 Common Ancestor Objective Function and Parent Set DAG Metric Container 11 Extension 12 draft-ietf-roll-nsa-extension-06 14 Abstract 16 Implementing Packet Replication and Elimination from/to the RPL root 17 requires the ability to forward copies of packets over different 18 paths via different RPL parents. Selecting the appropriate parents 19 to achieve ultra-low latency and jitter requires information about a 20 node's parents. This document details what information needs to be 21 transmitted and how it is encoded within RPL control packets to 22 enable this functionality. This document also describes Objective 23 Function which take advantage of this information to implement multi- 24 path routing. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 13, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Common Ancestor Objective Function . . . . . . . . . . . . . 4 63 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 6 64 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 7 65 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 8 66 3.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Node State and Attribute (NSA) object type extension . . . . 8 68 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8.1. Informative references . . . . . . . . . . . . . . . . . 11 74 8.2. Other Informative References . . . . . . . . . . . . . . 12 75 Appendix A. Implementation Status . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 Network-enabled applications in the industrial context must provide 81 stringent guarantees in terms of reliability and predictability. 82 Packet Replication and Elimination (PRE) 83 [I-D.papadopoulos-6tisch-pre-reqs] is a technique which allows 84 redundant paths in the network to be utilized for traffic requiring 85 higher reliability. Allowing these kinds of applications to function 86 over wireless networks requires the application of the principles of 87 Deterministic Networking [I-D.ietf-detnet-architecture]. This 88 results in designs which aim at optimizing packet delivery rate and 89 bounding latency. Additionally, given that the network nodes often 90 do not have an unlimited power supply, energy consumption needs to be 91 minimized as well. 93 As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154] 94 provides Time-Slotted Channel Hopping (TSCH), a mode of operation 95 which uses a common communication schedule based on timeslots to 96 allow deterministic medium access as well as channel hopping to work 97 around radio interference. However, since TSCH uses retransmissions 98 in the event of a failed transmission, end-to-end delay and jitter 99 performance can deteriorate. 101 Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE 102 Std. 802.15.4-TSCH, has worked on the issues previously highlighted 103 and produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] 104 to address that case. Building on this architecture, "Exploiting 105 Packet Replication and Elimination in Complex Tracks in 6TiSCH LLNs" 106 [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the 107 Packet Delivery Ratio (PDR), to provide a hard bound to the end-to- 108 end latency, and to limit jitter. 110 PRE is a general method of maximizing packet delivery rate and 111 potentially minimizing latency and jitter, not limited to 6TiSCH. 112 More specifically, PRE achieves controlled redundancy by laying 113 multiple forwarding paths through the network and using them in 114 parallel for different copies of a same packet. PRE can follow the 115 Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL 116 from a node to the root. Building a multi-path DODAG can be achieved 117 based on the RPL capability of having multiple parents for each node 118 in a network, a subset of which is used to forward packets. In order 119 for this subset to be defined, a RPL parent subset selection 120 mechanism, which is among the responsibilities of the RPL Objective 121 Function (OF), needs to have specific path information. This 122 document describes OFs which implement multi-path routing for PRE and 123 specifies the transmission of this specific path information. 125 This document describes a new objective function (OF) called the 126 Common Ancestor (CA) OF. A detailed description is given of how the 127 path information is used within the CA OF and how the subset of 128 parents for forwarding packets is selected. This specification 129 defines a new Objective Code Point (OCP) for the CA OF. 131 For the path information, this specification focuses on the 132 extensions to the DAG Metric Container [RFC6551] required for 133 providing the PRE mechanism a part of the information it needs to 134 operate. This information is the RPL [RFC6550] parent address set of 135 a node and it must be sent to potential children of the node. The 136 RPL DIO Control Message is the canonical way of broadcasting this 137 kind of information and therefore its DAG Metric Container [RFC6551] 138 field is used to append a Node State and Attribute (NSA) object. The 139 node's parent address set is stored as an optional TLV within the NSA 140 object. This specification defines the type value and structure for 141 the parent address set TLV. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 The draft uses the following Terminology: 151 Packet Replication and Elimination (PRE): A method which transmits 152 multiple copies of a packet using multi-path forwarding over a 153 multi-hop network and which consolidates multiple received packet 154 copies to control flooding. See "Exploiting Packet Replication 155 and Elimination in Complex Tracks in 6TiSCH LLNs" 156 [I-D.papadopoulos-6tisch-pre-reqs] for more details. 158 Parent Set (PS): Given a RPL node, the set of its neighbor nodes 159 which participate in the same RPL DODAG and which can potentially 160 take the role of the node's preferred parent. 162 Alternative Parent (AP): A RPL parent in the parent set of a node 163 which is used to forward a packet copy when replicating packets. 165 Alternative Parent (AP) Selection: The mechanism for choosing the 166 next hop node to forward a packet copy when replicating packets. 168 Preferred Grand Parent (PGP): The preferred parent of the preferred 169 parent of a node. 171 3. Common Ancestor Objective Function 173 In the RPL protocol, each node maintains a list of potential parents. 174 For PRE, the Preferred Parent (PP) node is defined to be the same as 175 the RPL DODAG Preferred Parent node. Furthermore, to construct an 176 alternative path toward the root, in addition to the PP node, each 177 node in the network registers an AP node as well from its Parent Set 178 (PS). 180 There are multiple alternative methods of selecting the AP node. 181 This functionality is included in the operation of the RPL Objective 182 Function (OF). An OF which allows the two paths to remain correlated 183 is detailed here. More specifically, when using this OF a node will 184 select an AP node close to its PP node to allow the operation of 185 overhearing between parents. For more details about overhearing and 186 its use in this context see Section 4.3. "Promiscuous Overhearing" 187 in "Exploiting Packet Replication and Elimination in Complex Tracks 188 in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs]. If multiple 189 potential APs match this condition, the AP with the lowest rank will 190 be registered. 192 The OF described here is an extension of the The Minimum Rank with 193 Hysteresis Objective Function [RFC6719] (MRHOF). In general, this OF 194 extends MRHOF by specifying how an AP is selected. Importantly, the 195 calculation of the rank of the node through each candidate neighbor 196 and the selection of the PP is kept the same as in MRHOF. 198 The ways in which the CA OF modifies MRHOF in a section-by-section 199 manner follows in detail: 201 3. The Minimum Rank with Hysteresis Objective Function: 202 Same as MRHOF extended to AP selection. Minimum Rank path 203 selection and switching applies correspondingly to the AP with the 204 extra CA requirement of having some match between ancestors. 206 3.1. Computing the Path Cost: Same as MRHOF extended to AP 207 selection. If a candidate neighbor does not fulfill the CA 208 requirement then the path through that neighbor SHOULD be set to 209 MAX_PATH_COST, the same value used by MRHOF. As a result, the 210 node MUST NOT select the candidate neighbor as its AP. 212 3.2. Parent Selection: Same as MRHOF extended to AP selection. To 213 allow hysteresis, AP selection maintains a variable, 214 cur_ap_min_path_cost, which is the path cost of the current AP. 216 3.2.1. When Parent Selection Runs: Same as MRHOF. 218 3.2.2. Parent Selection Algorithm: Same as MRHOF extended to AP 219 selection. If the smallest path cost for paths through the 220 candidate neighbors is smaller than cur_ap_min_path_cost by less 221 than PARENT_SWITCH_THRESHOLD (the same variable as MRHOF uses), 222 the node MAY continue to use the current AP. Additionally, if 223 there is no PP selected, there MUST NOT be any AP selected as 224 well. Finally, as with MRHOF, a node MAY include up to 225 PARENT_SET_SIZE-1 additional candidate neighbors in its 226 alternative parent set. The value of PARENT_SET_SIZE is the same 227 as in MRHOF. 229 3.3. Computing Rank: Same as MRHOF. 231 3.4. Advertising the Path Cost: Same as MRHOF. 233 3.5. Working without Metric Containers: It is not possible to work 234 without metric containers, since CA AP selection requires 235 information from parents regarding their parent sets, which is 236 transmitted via the NSA object in the DIO Mectric Container. 238 4. Using MRHOF for Metric Maximization: Same as MRHOF. 240 5. MRHOF Variables and Parameters: Same as MRHOF extended to AP 241 selection. The CA OFs operate like MRHOF for AP selection by 242 maintaining separate: 244 AP: Corresponding to the MRHOF PP. Hysteresis is configured for 245 AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF. 246 The AP MUST NOT be the same as the PP. 248 Alternative parent set: Corresponding to the MRHOF parent set. 249 The size is defined by the same PARENT_SET_SIZE parameter as in 250 MRHOF. The Alternative parent set MUST be a non-strict subset 251 of the parent set. 253 cur_ap_min_path_cost: Corresponding to the MRHOF 254 cur_min_path_cost variable. To support the operation of the 255 hysteresis function for AP selection. 257 6. Manageability: Same as MRHOF. 259 6.1. Device Configuration: Same as MRHOF. 261 6.2. Device Monitoring: Same as MRHOF. 263 Three OFs are defined which perform AP selection based on common 264 ancestors, named Common Ancestor Strict, Common Ancestor Medium, and 265 Common Ancestor Relaxed, depending on how restrictive the selection 266 process is. A more restrictive method will limit flooding but might 267 fail to select an appropriate AP, while a less restrictive one will 268 more often find an appropriate AP but might increase flooding. The 269 OFs are all represented with the same Objective Code Point (OCP): 270 TBD1. 272 All three OFs apply their corresponding common ancestor criterion to 273 filter the list of candidate neighbours in the alternative parent 274 set. The AP is then selected from the alternative parent set based 275 on Rank and using hysteresis as is done for the PP in MRHOF. 277 3.1. Common Ancestor Strict 279 In the CA Strict OF the node will check if its Preferred Grand Parent 280 (PGP), the PP of its PP, is the same as the PP of the potential AP. 282 ( R ) root 283 . PS(S) = {A, B, C, D} 284 . PP(S) = C 285 . PP(PP(S)) = Y 286 . 287 PS(A) = {W, X} 288 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 289 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 290 | \ // | \ // || \ / || PS(B) = {W, X, Y} 291 | // | // || / || PP(B) = Y 292 | // \ | // \ || / \ || 293 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 294 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 295 ^ ^ ^^ ^ 296 \ \ || / PS(D) = {Y, Z} 297 \ \ || / PP(D) = Z 298 \ \ || / 299 \----\\ || / || Preferred Parent 300 ( S ) source | Potential Alternative Parent 302 Figure 1: Example Common Ancestor Strict Alternative Parent Selection 303 method 305 For example, in Figure 1, the source node S must know its grandparent 306 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 307 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 308 of the figure. The CA Strict parent selection method will select an 309 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 310 Y: 312 o Node A: PP(A) = X and therefore it is different than PP(PP(S)) 314 o Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 316 o Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 318 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 319 PP(B). 321 3.2. Common Ancestor Medium 323 In the CA Medium OF the node will check if its Preferred Grand Parent 324 (PGP), the PP of its PP, is contained in the PS of the potential AP. 326 Using the same example, in Figure 1, the CA Medium parent selection 327 method will select an AP for node S for which PP(PP(S)) is in PS(AP). 328 Given that PP(PP(S)) = Y: 330 o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 332 o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 334 o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 336 node S can decide to use node B or D as its AP node. 338 3.3. Common Ancestor Relaxed 340 In the CA Relaxed OF the node will check if the Parent Set (PS) of 341 its Preferred Parent (PP) has a node in common with the PS of the 342 potential AP. 344 Using the same example, in Figure 1, the CA Relaxed parent selection 345 method will select an AP for node S for which PS(PP(S)) has at least 346 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 348 o Node A: PS(A) = {W, X} and the common nodes are {X} 350 o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 352 o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 354 node S can decide to use node A, B or D as its AP node. 356 3.4. Usage 358 The PS information can be used by any of the described AP selection 359 methods or other ones not described here, depending on requirements. 360 It is optional for all nodes to use the same AP selection method. 361 Different nodes may use different AP selection methods, since the 362 selection method is local to each node. For example, using different 363 methods can be used to vary the transmission reliability in each hop. 365 4. Node State and Attribute (NSA) object type extension 367 In order to select their AP node, nodes need to be aware of their 368 grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG 369 Information Object (DIO) Control Message to broadcast information 370 about themselves to potential children. However, RPL [RFC6550], does 371 not define how to propagate parent set related information, which is 372 what this document addresses. 374 DIO messages can carry multiple options, out of which the DAG Metric 375 Container option [RFC6551] is the most suitable structurally and 376 semantically for the purpose of carrying the parent set. The DAG 377 Metric Container option itself can carry different nested objects, 378 out of which the Node State and Attribute (NSA) [RFC6551] is 379 appropriate for transferring generic node state data. Within the 380 Node State and Attribute it is possible to store optional TLVs 381 representing various node characteristics. As per the Node State and 382 Attribute (NSA) [RFC6551] description, no TLV has been defined for 383 use. This document defines one TLV for the purpose of transmitting a 384 node's parent set. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | RPLInstanceID |Version Number | Rank | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |G|0| MOP | Prf | DTSN | Flags | Reserved | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 + + 395 | | 396 + DODAGID + 397 | | 398 + + 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | DAGMC Type (2)| DAGMC Length | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 403 | | 404 // DAG Metric Container data // 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Figure 2: Example DIO Message with a DAG Metric Container option 410 Figure 2 shows the structure of the DIO Control Message when a DAG 411 Metric Container option is included. The DAG Metric Container option 412 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 413 registry for the RPL Control Message Options, and is defined in 414 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 415 Figure 2) expresses the DAG Metric Container length in bytes. DAG 416 Metric Container data holds the actual data and is shown expanded in 417 Figure 3. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Res | Flags |A|O| PS type | PS Length | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA 426 | PS IPv6 address(es) ... | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 3: DAG Metric Container (MC) data with Node State and 430 Attribute (NSA) object body and a TLV 432 The structure of the DAG Metric Container data in the form of a Node 433 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 434 field is shown in Figure 3. The first 32 bits comprise the DAG 435 Metric Container header and all the following bits are part of the 436 Node State and Attribute object body, as defined in [RFC6551]. This 437 document defines a new TLV, which CAN be carried in the Node State 438 and Attribute (NSA) object Optional TLVs field. The TLV is named 439 Parent Set and is abbreviated as PS in Figure 3. 441 PS type: The type of the Parent Set TLV. The value is TBD2. 443 PS Length: The total length of the TLV value field (PS IPv6 444 address(es)) in bytes. The length is an integral multiple of 445 16, the number of bytes in an IPv6 address. 447 PS IPv6 address(es) One or more 128-bit IPv6 address(es) without any 448 separator between them. The field consists of one IPv6 address 449 per parent in the parent set. The parent addresses are listed 450 in decreasing order of preference and not all parents in the 451 parent set need to be included. The selection of how many 452 parents from the parent set are to be included is left to the 453 implementation. The number of parent addresses in the PS IPv6 454 address(es) field can be deduced by dividing the length of the 455 PS IPv6 address(es) field in bytes by 16, the number of bytes 456 in an IPv6 address. 458 4.1. Usage 460 The PS SHOULD be used in the process of parent selection, and 461 especially in AP selection, since it can help the alternative path to 462 not significantly deviate from the preferred path. The Parent Set is 463 information local to the node that broadcasts it. 465 The PS is used only within NSA objects configured as constraints and 466 is used as per [RFC6551]. As a result, the PS does not affect the 467 calculation of the rank through candidate neighbors. It is only used 468 with the CA OF to remove nodes which do not fulfill the CA OF 469 criteria from the candidate neighbor list. 471 5. Controlling PRE 473 PRE is very helpful when the aim is to increase reliability for a 474 certain path, however its use creates additional traffic as part of 475 the replication process. It is conceivable that not all paths have 476 stringent reliability requirements. Therefore, a way to control 477 whether PRE is applied to a path's packets SHOULD be implemented. 478 For example, a traffic class label can be used to determine this 479 behavior per flow type as described in Deterministic Networking 480 Architecture [I-D.ietf-detnet-architecture]. 482 6. Security Considerations 484 The structure of the DIO control message is extended, within the pre- 485 defined DIO options. Therefore, the security mechanisms defined in 486 RPL [RFC6550] apply to this proposed extension. 488 7. IANA Considerations 490 This proposal requests the allocation of a new value TBD1 from the 491 "Objective Code Point (OCP)" sub-registry of the "Routing Protocol 492 for Low Power and Lossy Networks (RPL)" registry. 494 This proposal also requests the allocation of a new value TBD2 for 495 the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub- 496 registry from IANA. 498 8. References 500 8.1. Informative references 502 [I-D.ietf-6tisch-architecture] 503 Thubert, P., "An Architecture for IPv6 over the TSCH mode 504 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work 505 in progress), October 2019. 507 [I-D.ietf-detnet-architecture] 508 Finn, N., Thubert, P., Varga, B., and J. Farkas, 509 "Deterministic Networking Architecture", draft-ietf- 510 detnet-architecture-13 (work in progress), May 2019. 512 [I-D.papadopoulos-6tisch-pre-reqs] 513 Papadopoulos, G., Montavont, N., and P. Thubert, 514 "Exploiting Packet Replication and Elimination in Complex 515 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 516 reqs-02 (work in progress), July 2018. 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, 520 DOI 10.17487/RFC2119, March 1997, 521 . 523 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 524 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 525 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 526 Low-Power and Lossy Networks", RFC 6550, 527 DOI 10.17487/RFC6550, March 2012, 528 . 530 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 531 and D. Barthel, "Routing Metrics Used for Path Calculation 532 in Low-Power and Lossy Networks", RFC 6551, 533 DOI 10.17487/RFC6551, March 2012, 534 . 536 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 537 Hysteresis Objective Function", RFC 6719, 538 DOI 10.17487/RFC6719, September 2012, 539 . 541 8.2. Other Informative References 543 [IEEE802154] 544 IEEE standard for Information Technology, "IEEE Std 545 802.15.4 Standard for Low-Rate Wireless Personal Area 546 Networks (WPANs)", December 2015. 548 8.3. URIs 550 [1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll- 551 nsa-extension 553 [2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit 554 ;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138 556 Appendix A. Implementation Status 558 A research-stage implementation of the PRE mechanism using the 559 proposed extension as part of a 6TiSCH IOT use case was developed at 560 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 561 Koutsiamanis. It was implemented on the open-source Contiki OS and 562 tested with the Cooja simulator. The DIO DAGMC NSA extension is 563 implemented with a configurable number of parents from the parent set 564 of a node to be reported. 566 ( R ) 568 (11) (12) (13) (14) (15) (16) 570 (21) (22) (23) (24) (25) (26) 572 (31) (32) (33) (34) (35) (36) 574 (41) (42) (43) (44) (45) (46) 576 (51) (52) (53) (54) (55) (56) 578 ( S ) 580 Figure 4: Simulation Topology 582 The simulation setup is: 584 Topology: 32 nodes structured in regular grid as show in Figure 4. 585 Node S (source) is the only data packet sender, and send data to 586 node R (root). The parent set of each node (except R) is all the 587 nodes in the immediately higher row, the immediately above 6 588 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 589 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 590 14, 15, 16 have a single upwards link to R. 592 MAC: TSCH with 1 retransmission 594 Platform: Cooja 595 Schedule: Static, 2 timeslots per link from each node to each parent 596 in its parent set, 1 broadcast EB slot, 1 sender-based shared 597 timeslot (for DIO and DIS) per node (total of 32). 599 Simulation lifecycle: Allow link formation for 100 seconds before 600 starting to send data packets. Afterwards, S sends data packets 601 to R. The simulation terminates when 1000 packets have been sent 602 by S. 604 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 605 drawn for each link, with a uniform distribution spanning the 70% 606 to 100% interval. 608 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 609 seconds to R. 611 PS extension size: 3 parents. 613 Routing Methods: 615 * RPL: The default RPL non-PRE implementation in Contiki OS. 617 * 2nd ETX: PRE with a parent selection method which picks as AP 618 the 2nd best parent in the parent set based on ETX. 620 * CA Strict: As described in Section 3.1. 622 * CA Medium: As described in Section 3.2. 624 Simulation results: 626 +-----------+---------------+-----------------+---------------------+ 627 | Routing | Average | Average | Average | 628 | Method | Packet | Traversed | Duplications/packet | 629 | | Delivery Rate | Nodes/packet | (#) | 630 | | (%) | (#) | | 631 +-----------+---------------+-----------------+---------------------+ 632 | RPL | 82.70 | 5.56 | 7.02 | 633 | 2nd ETX | 99.38 | 14.43 | 31.29 | 634 | CA Strict | 97.32 | 9.86 | 18.23 | 635 | CA Medium | 99.66 | 13.75 | 28.86 | 636 +-----------+---------------+-----------------+---------------------+ 638 Links: 640 o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 641 extension branch) [1] 643 o Wireshark dissectors (for the optional PS TLV) - currently merged 644 / in master [2] 646 Authors' Addresses 648 Remous-Aris Koutsiamanis (editor) 649 IMT Atlantique 650 Office B00 - 126A 651 2 Rue de la Chataigneraie 652 Cesson-Sevigne - Rennes 35510 653 FRANCE 655 Phone: +33 299 12 70 49 656 Email: aris@ariskou.com 658 Georgios Papadopoulos 659 IMT Atlantique 660 Office B00 - 114A 661 2 Rue de la Chataigneraie 662 Cesson-Sevigne - Rennes 35510 663 FRANCE 665 Phone: +33 299 12 70 04 666 Email: georgios.papadopoulos@imt-atlantique.fr 668 Nicolas Montavont 669 IMT Atlantique 670 Office B00 - 106A 671 2 Rue de la Chataigneraie 672 Cesson-Sevigne - Rennes 35510 673 FRANCE 675 Phone: +33 299 12 70 23 676 Email: nicolas.montavont@imt-atlantique.fr 678 Pascal Thubert 679 Cisco Systems, Inc 680 Building D 681 45 Allee des Ormes - BP1200 682 MOUGINS - Sophia Antipolis 06254 683 FRANCE 685 Phone: +33 497 23 26 34 686 Email: pthubert@cisco.com