idnits 2.17.1 draft-ietf-roll-nsa-extension-09.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 (26 September 2020) is 1306 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) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-29 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R.-A. Koutsiamanis, Ed. 3 Internet-Draft G.Z. Papadopoulos 4 Intended status: Standards Track N. Montavont 5 Expires: 30 March 2021 IMT Atlantique 6 P. Thubert 7 Cisco 8 26 September 2020 10 Common Ancestor Objective Function and Parent Set DAG Metric Container 11 Extension 12 draft-ietf-roll-nsa-extension-09 14 Abstract 16 Packet Replication and Elimination is a method in which several 17 copies of a data packet are sent in the network in order to achieve 18 high reliability and low jitter. This document details how to apply 19 Packet Replication and Elimination in RPL, especially how to exchange 20 information within RPL control packets to let a node better select 21 the different parents that will be used to forward the multiple 22 copies of a packet. This document also describes the Objective 23 Function which takes advantage of this information to implement 24 multi-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 30 March 2021. 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Common Ancestor AP Selection Policies . . . . . . . . . . . . 4 62 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 5 63 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 6 64 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6 65 4. Common Ancestor Objective Function . . . . . . . . . . . . . 6 66 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. Node State and Attribute (NSA) object type extension . . . . 9 68 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Informative references . . . . . . . . . . . . . . . . . 13 75 Appendix A. Implementation Status . . . . . . . . . . . . . . . 14 76 Appendix B. Choosing an AP selection policy . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Networks in the industrial context must provide stringent guarantees 82 in terms of reliability and predictability, with this domain being 83 one of main ones addressed by Deterministic Networking [RFC8557]. 84 Packet Replication and Elimination (PRE) (Section 4.5.3 of 85 [I-D.ietf-6tisch-architecture]) is a technique which allows redundant 86 paths in the network to be utilized for traffic requiring higher 87 reliability. Allowing industrial applications to function over 88 wireless networks requires the application of the principles and 89 architecture of Deterministic Networking [RFC8655]. This results in 90 designs which aim at optimizing packet delivery rate and bounding 91 latency. Additionally, nodes operating on battery need to minimize 92 their energy consumption. 94 As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154] 95 provides Time-Slotted Channel Hopping (TSCH), a mode of operation 96 which uses a common communication schedule based on timeslots to 97 allow deterministic medium access as well as channel hopping to work 98 around radio interference. However, since TSCH uses retransmissions 99 in the event of a failed transmission, end-to-end latency and jitter 100 performance can deteriorate. 102 Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE 103 Std. 802.15.4-TSCH, has worked on these issues and produced the 104 "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to address that 105 case. 107 PRE is a general method of maximizing packet delivery rate and 108 potentially minimizing latency and jitter, not limited to 6TiSCH. 109 More specifically, PRE achieves controlled redundancy by laying 110 multiple forwarding paths through the network and using them in 111 parallel for different copies of a same packet. PRE can follow the 112 Destination-Oriented Directed Acyclic Graph (DODAG) formed by [RPL] 113 from a node to the root. Building a multi-path DODAG can be achieved 114 based on the RPL capability of having multiple parents for each node 115 in a network, a subset of which is used to forward packets. In order 116 to select parents to be part of this subset, the RPL Objective 117 Function (OF) needs additional information regarding the multi-path 118 nature of PRE. This document describes an OF which implements multi- 119 path routing for PRE and specifies the transmission of this specific 120 path information. 122 This document describes a new Objective Function (OF) called the 123 Common Ancestor (CA) OF (see Section 4). A detailed description is 124 given of how the path information is used within the CA OF and how 125 the subset of parents for forwarding packets is selected. This 126 specification defines a new Objective Code Point (OCP) for the CA OF. 128 For the path information, this specification focuses on the 129 extensions to the DAG Metric Container [RFC6551] required for 130 providing the PRE mechanism a part of the information it needs to 131 operate. This information is the [RPL] parent address set of a node 132 and it must be sent to potential children of the node. The RPL DIO 133 Control Message is the canonical way of broadcasting this kind of 134 information and therefore its DAG Metric Container [RFC6551] field is 135 used to append a Node State and Attribute (NSA) object. The node's 136 parent address set is stored as an optional TLV within the NSA 137 object. This specification defines the type value and structure for 138 the parent address set TLV (see Section 5). 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 The draft uses the following Terminology: 148 Packet Replication and Elimination (PRE): A method which consists of 149 transmitting multiple copies of a packet using multi-path 150 forwarding over a multi-hop network and which consolidates 151 multiple received packet copies to control flooding. See "Complex 152 Track with Replication and Elimination" in Section 4.5.3 of 153 [I-D.ietf-6tisch-architecture] for more details. 155 Parent Set (PS): Given a RPL node, the set of its neighbor nodes 156 which participate in the same RPL DODAG and which can potentially 157 take the role of the node's preferred parent. 159 Alternative Parent (AP): A RPL parent in the parent set of a node 160 which is used to forward a packet copy when replicating packets. 162 Alternative Parent (AP) Selection: The mechanism for choosing the 163 next hop node to forward a packet copy when replicating packets. 165 Preferred Grand Parent (PGP): The preferred parent of the preferred 166 parent of a node. 168 3. Common Ancestor AP Selection Policies 170 In the RPL protocol, each node maintains a list of potential parents. 171 For PRE, the Preferred Parent (PP) node is defined to be the same as 172 the RPL DODAG Preferred Parent node. Furthermore, to construct an 173 alternative path toward the root, in addition to the PP node, each 174 node in the network selects additional parent(s), called alternative 175 parent(s), from its Parent Set (PS). 177 There are multiple possible policies of selecting the AP node. This 178 section details three such possible policies. 180 All three policies defined perform AP selection based on common 181 ancestors, named Common Ancestor Strict, Common Ancestor Medium, and 182 Common Ancestor Relaxed, depending on how restrictive the selection 183 process is. A more restrictive policy will limit flooding but might 184 fail to select an appropriate AP, while a less restrictive one will 185 more often find an appropriate AP but might increase flooding. 187 All three policies apply their corresponding common ancestor 188 criterion to filter the list of candidate neighbours in the 189 alternative parent set. 191 3.1. Common Ancestor Strict 193 In the CA Strict OF the node will check if its Preferred Grand Parent 194 (PGP), the PP of its PP, is the same as the PP of the potential AP. 196 ( R ) root 197 . PS(S) = {A, B, C, D} 198 . PP(S) = C 199 . PP(PP(S)) = Y 200 . 201 PS(A) = {W, X} 202 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 203 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 204 | \ // | \ // || \ / || PS(B) = {W, X, Y} 205 | // | // || / || PP(B) = Y 206 | // \ | // \ || / \ || 207 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 208 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 209 ^ ^ ^^ ^ 210 \ \ || / PS(D) = {Y, Z} 211 \ \ || / PP(D) = Z 212 \ \ || / 213 \----\\ || / || Preferred Parent 214 ( S ) source | Potential Alt. Parent 216 Figure 1: Example Common Ancestor Strict Alternative Parent 217 Selection policy 219 For example, in Figure 1, the source node S must know its grandparent 220 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 221 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 222 of the figure. The CA Strict parent selection policy will select an 223 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 224 Y: 226 * Node A: PP(A) = X and therefore it is different than PP(PP(S)) 228 * Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 230 * Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 232 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 233 PP(B). 235 3.2. Common Ancestor Medium 237 In the CA Medium OF the node will check if its Preferred Grand Parent 238 (PGP), the PP of its PP, is contained in the PS of the potential AP. 240 Using the same example, in Figure 1, the CA Medium parent selection 241 policy will select an AP for node S for which PP(PP(S)) is in PS(AP). 242 Given that PP(PP(S)) = Y: 244 * Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 246 * Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 248 * Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 250 node S can decide to use node B or D as its AP node. 252 3.3. Common Ancestor Relaxed 254 In the CA Relaxed OF the node will check if the Parent Set (PS) of 255 its Preferred Parent (PP) has a node in common with the PS of the 256 potential AP. 258 Using the same example, in Figure 1, the CA Relaxed parent selection 259 policy will select an AP for node S for which PS(PP(S)) has at least 260 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 262 * Node A: PS(A) = {W, X} and the common nodes are {X} 264 * Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 266 * Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 268 node S can decide to use node A, B or D as its AP node. 270 4. Common Ancestor Objective Function 272 An OF which allows the multiple paths to remain correlated is 273 detailed here. More specifically, when using this OF a node will 274 select an AP node close to its PP node to allow the operation of 275 overhearing between parents. For more details about overhearing and 276 its use in this context see the "Complex Track with Replication and 277 Elimination" in Section 4.5.3 of [I-D.ietf-6tisch-architecture]. If 278 multiple potential APs match this condition, the AP with the lowest 279 rank will be registered. 281 The OF described here is an extension of The Minimum Rank with 282 Hysteresis Objective Function [MRHOF]. In general, this OF extends 283 MRHOF by specifying how an AP is selected. Importantly, the 284 calculation of the rank of the node through each candidate neighbor 285 and the selection of the PP is kept the same as in MRHOF. 287 The ways in which the CA OF modifies MRHOF in a section-by-section 288 manner follows in detail: 290 [MRHOF], Section 2: "Terminology". Term "Selected Metric": 291 The CA OF uses only one metric, like MRHOF, for rank calculation, 292 with the same MRHOF semantics. For selecting the AP, the PS TLV 293 (stored in the DIO Metric Container Node State and Attribute (NSA) 294 object body, see Section 5) is used. This additional NSA metric 295 is disregarded for the purposes of rank calculation. 297 [MRHOF], Section 3 "The Minimum Rank with Hysteresis Objective 298 Function": 299 Same as MRHOF extended to AP selection. Minimum Rank path 300 selection and switching applies correspondingly to the AP with the 301 extra CA requirement of having some match between ancestors. 303 [MRHOF], Section 3.1 "Computing the Path Cost": 304 Same as MRHOF extended to AP selection. If a candidate neighbor 305 does not fulfill the CA requirement then the path through that 306 neighbor SHOULD be set to MAX_PATH_COST, the same value used by 307 MRHOF. As a result, the node MUST NOT select the candidate 308 neighbor as its AP. 310 [MRHOF], Section 3.2 "Parent Selection": 311 Same as MRHOF extended to AP selection. To allow hysteresis, AP 312 selection maintains a variable, cur_ap_min_path_cost, which is the 313 path cost of the current AP. 315 [MRHOF], Section 3.2.1 "When Parent Selection Runs": 316 Same as MRHOF. 318 [MRHOF], Section 3.2.2 "Parent Selection Algorithm": 319 Same as MRHOF extended to AP selection. If the smallest path cost 320 for paths through the candidate neighbors is smaller than 321 cur_ap_min_path_cost by less than PARENT_SWITCH_THRESHOLD (the 322 same variable as MRHOF uses), the node MAY continue to use the 323 current AP. Additionally, if there is no PP selected, there MUST 324 NOT be any AP selected as well. Finally, as with MRHOF, a node 325 MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors 326 in its alternative parent set. The value of PARENT_SET_SIZE is 327 the same as in MRHOF. 329 [MRHOF], Section 3.3 "Computing Rank": 330 Same as MRHOF. 332 [MRHOF], Section 3.4 "Advertising the Path Cost": 333 Same as MRHOF. 335 [MRHOF], Section 3.5 "Working without Metric Containers": 336 It is not possible to work without metric containers, since CA AP 337 selection requires information from parents regarding their parent 338 sets, which is transmitted via the NSA object in the DIO Mectric 339 Container. 341 [MRHOF], Section 4 "Using MRHOF for Metric Maximization": 342 Same as MRHOF. 344 [MRHOF], Section 5 "MRHOF Variables and Parameters": 345 Same as MRHOF extended to AP selection. The CA OF operates like 346 MRHOF for AP selection by maintaining separate: 348 AP: Corresponding to the MRHOF PP. Hysteresis is configured for 349 AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF. 350 The AP MUST NOT be the same as the PP. 352 Alternative parent set: Corresponding to the MRHOF parent set. 353 The size is defined by the same PARENT_SET_SIZE parameter as in 354 MRHOF. The Alternative parent set MUST be a non-strict subset 355 of the parent set. 357 cur_ap_min_path_cost: Corresponding to the MRHOF 358 cur_min_path_cost variable. To support the operation of the 359 hysteresis function for AP selection. 361 [MRHOF], Section 6 "Manageability": 362 Same as MRHOF. 364 [MRHOF], Section 6.1 "Device Configuration": 365 Same as MRHOF. 367 [MRHOF], Section 6.2 "Device Monitoring": 368 Same as MRHOF. 370 4.1. Usage 372 All OF policies apply their corresponding criterion to filter the 373 list of candidate neighbours in the alternative parent set. The AP 374 is then selected from the alternative parent set based on Rank and 375 using hysteresis as is done for the PP in MRHOF. It is noteworthy 376 that the OF uses the same Objective Code Point (OCP): TBD1 for all 377 policies used. 379 The PS information can be used by any of the described AP selection 380 policies or other ones not described here, depending on requirements. 381 It is optional for all nodes to use the same AP selection policies. 382 Different nodes may use different AP selection policies, since the 383 selection policy is local to each node. For example, using different 384 policies can be used to vary the transmission reliability in each 385 hop. 387 5. Node State and Attribute (NSA) object type extension 389 In order to select their AP node, nodes need to be aware of their 390 grandparent node sets. Within [RPL], the nodes use the DODAG 391 Information Object (DIO) Control Message to broadcast information 392 about themselves to potential children. However, [RPL], does not 393 define how to propagate parent set related information, which is what 394 this document addresses. 396 DIO messages can carry multiple options, out of which the DAG Metric 397 Container option [RFC6551] is the most suitable structurally and 398 semantically for the purpose of carrying the parent set. The DAG 399 Metric Container option itself can carry different nested objects, 400 out of which the Node State and Attribute (NSA) [RFC6551] is 401 appropriate for transferring generic node state data. Within the 402 Node State and Attribute it is possible to store optional TLVs 403 representing various node characteristics. As per the Node State and 404 Attribute (NSA) [RFC6551] description, no TLV has been defined for 405 use. This document defines one TLV for the purpose of transmitting a 406 node's parent set. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | RPLInstanceID |Version Number | Rank | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |G|0| MOP | Prf | DTSN | Flags | Reserved | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 + + 417 | | 418 + DODAGID + 419 | | 420 + + 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | DAGMC Type (2)| DAGMC Length | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 425 | | 426 // DAG Metric Container data // 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 2: Example DIO Message with a DAG Metric Container option 432 Figure 2 shows the structure of the DIO Control Message when a DAG 433 Metric Container option is included. The DAG Metric Container option 434 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 435 registry for the RPL Control Message Options, and is defined in 436 [RPL]. The DAG Metric Container option length (DAGMC Length in 437 Figure 2) expresses the DAG Metric Container length in bytes. DAG 438 Metric Container data holds the actual data and is shown expanded in 439 Figure 3. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Res | Flags |A|O| PS type | PS Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | PS IPv6 address(es) ... 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 3: DAG Metric Container (MC) data with Node State and 452 Attribute (NSA) object body and a TLV 454 The structure of the DAG Metric Container data in the form of a Node 455 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 456 field is shown in Figure 3. The first 32 bits comprise the DAG 457 Metric Container header and all the following bits are part of the 458 Node State and Attribute object body, as defined in [RFC6551]. This 459 document defines a new TLV, which MAY be carried in the Node State 460 and Attribute (NSA) object Optional TLVs field. The TLV is named 461 Parent Set and is abbreviated as PS in Figure 3. 463 PS type: The type of the Parent Set TLV. The value is TBD2. 465 PS Length: The total length of the TLV value field (PS IPv6 466 address(es)) in bytes. The length is an integral multiple of 467 16, the number of bytes in an IPv6 address. 469 PS IPv6 address(es) One or more 128-bit IPv6 address(es) without any 470 separator between them. The field consists of one IPv6 address 471 per parent in the parent set. The parent addresses are listed 472 in decreasing order of preference and not all parents in the 473 parent set need to be included. The selection of how many 474 parents from the parent set are to be included is left to the 475 implementation. The number of parent addresses in the PS IPv6 476 address(es) field can be deduced by dividing the length of the 477 PS IPv6 address(es) field in bytes by 16, the number of bytes 478 in an IPv6 address. 480 5.1. Usage 482 The PS SHOULD be used in the process of parent selection, and 483 especially in AP selection, since it can help the alternative path to 484 not significantly deviate from the preferred path. The Parent Set is 485 information local to the node that broadcasts it. 487 The PS is used only within NSA objects configured as a metric, 488 therefore the DAG Metric Container field "C" MUST be 0. 489 Additionally, since the information in the PS needs to be propagated 490 downstream but it cannot be aggregated, the DAG Metric Container 491 field "R" MUST be 1. Finally, since the information contained is by 492 definition partial, more specifically just the parent set of the DIO- 493 sending node, the DAG Metric Container field "P" MUST be 1. 495 It is important that the PS does not affect the calculation of the 496 rank through candidate neighbors. It is only used with the CA OF to 497 remove nodes which do not fulfill the CA OF criteria from the 498 candidate neighbor list. 500 6. Controlling PRE 502 PRE is very helpful when the aim is to increase reliability for a 503 certain path, however its use creates additional traffic as part of 504 the replication process. It is conceivable that not all paths have 505 stringent reliability requirements. Therefore, a way to control 506 whether PRE is applied to a path's packets SHOULD be implemented. 507 For example, a traffic class label can be used to determine this 508 behavior per flow type as described in Deterministic Networking 509 Architecture [RFC8655]. 511 7. Security Considerations 513 The structure of the DIO control message is extended, within the pre- 514 defined DIO options. The additional information are the IPv6 515 addresses of the parent set of the node transmitting the DIO. This 516 use of this additional information can have the following potential 517 consequences: 519 * A malicious node that can receive and read the DIO can "see" 520 further than it's own neighbourhood by one hop, learning the 521 addresses of it's two hop neighbors. This is a privacy / network 522 discovery issue. 524 * A malicious node that can send DIOs can use the parent set 525 extension to convince neighbours to route through itself, instead 526 of the normal preferred parent they would use. However, this is 527 already possible with other OFs (like [OF0] and [MRHOF]) by 528 reporting a fake rank value in the DIO, thus masquerading as the 529 DODAG root. 531 8. IANA Considerations 533 This proposal requests the allocation of a new value TBD1 from the 534 "Objective Code Point (OCP)" sub-registry of the "Routing Protocol 535 for Low Power and Lossy Networks (RPL)" registry. 537 This proposal also requests the allocation of a new value TBD2 for 538 the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub- 539 registry from IANA. 541 9. Acknowledgments 543 We are very grateful to Dominique Barthel, Rahul Jadhav, Fabrice 544 Theoleyre, Diego Dujovne, Derek Jianqiang Hou, and Michael Richardson 545 for their comments, feedback, and support which lead to many 546 improvements to this document. We would also like to thank Tomas 547 Lagos Jenschke very much for helping in the implementation and 548 evaluation of the proposals of this document. 550 10. References 552 10.1. Informative references 554 [I-D.ietf-6tisch-architecture] 555 Thubert, P., "An Architecture for IPv6 over the TSCH mode 556 of IEEE 802.15.4", Work in Progress, Internet-Draft, 557 draft-ietf-6tisch-architecture-29, 27 August 2020, 558 . 561 [IEEE802154] 562 IEEE standard for Information Technology, "IEEE Std. 563 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 564 and Physical Layer (PHY) Specifications for Low-Rate 565 Wireless Personal Area Networks", December 2015, 566 . 569 [MRHOF] Gnawali, O. and P. Levis, "The Minimum Rank with 570 Hysteresis Objective Function", RFC 6719, 571 DOI 10.17487/RFC6719, September 2012, 572 . 574 [OF0] Thubert, P., Ed., "Objective Function Zero for the Routing 575 Protocol for Low-Power and Lossy Networks (RPL)", 576 RFC 6552, DOI 10.17487/RFC6552, March 2012, 577 . 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 585 and D. Barthel, "Routing Metrics Used for Path Calculation 586 in Low-Power and Lossy Networks", RFC 6551, 587 DOI 10.17487/RFC6551, March 2012, 588 . 590 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 591 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 592 . 594 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 595 "Deterministic Networking Architecture", RFC 8655, 596 DOI 10.17487/RFC8655, October 2019, 597 . 599 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 600 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 601 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 602 Low-Power and Lossy Networks", RFC 6550, 603 DOI 10.17487/RFC6550, March 2012, 604 . 606 Appendix A. Implementation Status 608 A research-stage implementation of the PRE mechanism using the 609 proposed extension as part of a 6TiSCH IOT use case was developed at 610 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 611 Koutsiamanis. It was implemented on the open-source Contiki OS and 612 tested with the Cooja simulator. The DIO DAGMC NSA extension is 613 implemented with a configurable number of parents from the parent set 614 of a node to be reported. 616 ( R ) 618 (11) (12) (13) (14) (15) (16) 620 (21) (22) (23) (24) (25) (26) 622 (31) (32) (33) (34) (35) (36) 624 (41) (42) (43) (44) (45) (46) 626 (51) (52) (53) (54) (55) (56) 628 ( S ) 630 Figure 4: Simulation Topology 632 The simulation setup is: 634 Topology: 32 nodes structured in regular grid as show in Figure 4. 635 Node S (source) is the only data packet sender, and send data to 636 node R (root). The parent set of each node (except R) is all the 637 nodes in the immediately higher row, the immediately above 6 638 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 639 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 640 14, 15, 16 have a single upwards link to R. 642 MAC: TSCH with 1 retransmission 644 Platform: Cooja 646 Schedule: Static, 2 timeslots per link from each node to each parent 647 in its parent set, 1 broadcast EB slot, 1 sender-based shared 648 timeslot (for DIO and DIS) per node (total of 32). 650 Simulation lifecycle: Allow link formation for 100 seconds before 651 starting to send data packets. Afterwards, S sends data packets 652 to R. The simulation terminates when 1000 packets have been sent 653 by S. 655 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 656 drawn for each link, with a uniform distribution spanning the 70% 657 to 100% interval. 659 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 660 seconds to R. 662 PS extension size: 3 parents. 664 Routing Methods: 665 * RPL: The default RPL non-PRE implementation in Contiki OS. 667 * 2nd ETX: PRE with a parent selection method which picks as AP 668 the 2nd best parent in the parent set based on ETX. 670 * CA Strict: As described in Section 3.1. 672 * CA Medium: As described in Section 3.2. 674 Simulation results: 676 +=========+===================+===================+===============+ 677 | Routing | Average Packet | Average Traversed | Average | 678 | Method | Delivery Rate (%) | Nodes/packet (#) | Duplications/ | 679 | | | | packet (#) | 680 +=========+===================+===================+===============+ 681 | RPL | 82.70 | 5.56 | 7.02 | 682 +---------+-------------------+-------------------+---------------+ 683 | 2nd ETX | 99.38 | 14.43 | 31.29 | 684 +---------+-------------------+-------------------+---------------+ 685 | CA | 97.32 | 9.86 | 18.23 | 686 | Strict | | | | 687 +---------+-------------------+-------------------+---------------+ 688 | CA | 99.66 | 13.75 | 28.86 | 689 | Medium | | | | 690 +---------+-------------------+-------------------+---------------+ 692 Table 1 694 Links: 696 * Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 697 extension branch) (https://github.com/ariskou/contiki/tree/draft- 698 koutsiamanis-roll-nsa-extension) 700 * Wireshark dissectors (for the optional PS TLV) - currently merged 701 / in master (https://code.wireshark.org/review/gitweb?p=wireshark. 702 git;a=commit;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138) 704 Appendix B. Choosing an AP selection policy 706 The manner of choosing an AP selection policy is left to the 707 implementation, for maximum flexibility. 709 For example, a different policy can be used per traffic type. The 710 network configurator can choose the CA Relaxed policy to increase 711 reliability (thus producing some flooding) for specific, extremely 712 important, alert packets. On the other hand, all normal data traffic 713 uses the CA Strict policy. Therefore, an exception is made just for 714 the alert packets. 716 Another option would be to devise a new disjoint policy, where the 717 paths are on purpose non-correlated, to increase path diversity and 718 resilience against whole groups of nodes failing. The disadvantage 719 may be increased jitter. 721 Finally, a network configurator may provide the CA policies with a 722 preference order of Strict > Medium > Relaxed as a means of falling 723 back to more flood-prone policies to maintain reliability. 725 Authors' Addresses 727 Remous-Aris Koutsiamanis (editor) 728 IMT Atlantique 729 Office B215 730 4 rue Alfred Kastler, BP 20722 731 44307 Nantes Cedex 3 732 France 734 Email: aris@ariskou.com 736 Georgios Papadopoulos 737 IMT Atlantique 738 Office B00 - 114A 739 2 Rue de la Chataigneraie 740 35510 Cesson-Sevigne - Rennes 741 France 743 Phone: +33 299 12 70 04 744 Email: georgios.papadopoulos@imt-atlantique.fr 746 Nicolas Montavont 747 IMT Atlantique 748 Office B00 - 106A 749 2 Rue de la Chataigneraie 750 35510 Cesson-Sevigne - Rennes 751 France 753 Phone: +33 299 12 70 23 754 Email: nicolas.montavont@imt-atlantique.fr 756 Pascal Thubert 757 Cisco Systems, Inc 758 Building D 759 45 Allee des Ormes - BP1200 760 06254 MOUGINS - Sophia Antipolis 761 France 763 Phone: +33 497 23 26 34 764 Email: pthubert@cisco.com