idnits 2.17.1 draft-ietf-roll-nsa-extension-10.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 (29 October 2020) is 1237 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: 2 May 2021 IMT Atlantique 6 P. Thubert 7 Cisco 8 29 October 2020 10 Common Ancestor Objective Function and Parent Set DAG Metric Container 11 Extension 12 draft-ietf-roll-nsa-extension-10 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 2 May 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. Normative references . . . . . . . . . . . . . . . . . . 13 75 10.2. Informative references . . . . . . . . . . . . . . . . . 13 76 Appendix A. Implementation Status . . . . . . . . . . . . . . . 14 77 Appendix B. Choosing an AP selection policy . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Networks in the industrial context must provide stringent guarantees 83 in terms of reliability and predictability, with this domain being 84 one of main ones addressed by Deterministic Networking [RFC8557]. 85 Packet Replication and Elimination (PRE) (Section 4.5.3 of 86 [I-D.ietf-6tisch-architecture]) is a technique which allows redundant 87 paths in the network to be utilized for traffic requiring higher 88 reliability. Allowing industrial applications to function over 89 wireless networks requires the application of the principles and 90 architecture of Deterministic Networking [RFC8655]. This results in 91 designs which aim at optimizing packet delivery rate and bounding 92 latency. Additionally, nodes operating on battery need to minimize 93 their energy consumption. 95 As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154] 96 provides Time-Slotted Channel Hopping (TSCH), a mode of operation 97 which uses a common communication schedule based on timeslots to 98 allow deterministic medium access as well as channel hopping to work 99 around radio interference. However, since TSCH uses retransmissions 100 in the event of a failed transmission, end-to-end latency and jitter 101 performance can deteriorate. 103 Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE 104 Std. 802.15.4-TSCH, has worked on these issues and produced the 105 "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to address that 106 case. 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 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 to select parents to be part of this subset, the RPL Objective 118 Function (OF) needs additional information regarding the multi-path 119 nature of PRE. This document describes an OF which implements multi- 120 path routing for PRE and specifies the transmission of this specific 121 path information. 123 This document describes a new Objective Function (OF) called the 124 Common Ancestor (CA) OF (see Section 4). A detailed description is 125 given of how the path information is used within the CA OF and how 126 the subset of parents for forwarding packets is selected. This 127 specification defines a new Objective Code Point (OCP) for the CA OF. 129 For the path information, this specification focuses on the 130 extensions to the DAG Metric Container [RFC6551] required for 131 providing the PRE mechanism a part of the information it needs to 132 operate. This information is the [RPL] parent address set of a node 133 and it must be sent to potential children of the node. The RPL DIO 134 Control Message is the canonical way of broadcasting this kind of 135 information and therefore its DAG Metric Container [RFC6551] field is 136 used to append a Node State and Attribute (NSA) object. The node's 137 parent address set is stored as an optional TLV within the NSA 138 object. This specification defines the type value and structure for 139 the parent address set TLV (see Section 5). 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 The draft uses the following Terminology: 149 Packet Replication and Elimination (PRE): A method which consists of 150 transmitting multiple copies of a packet using multi-path 151 forwarding over a multi-hop network and which consolidates 152 multiple received packet copies to control flooding. See "Complex 153 Track with Replication and Elimination" in Section 4.5.3 of 154 [I-D.ietf-6tisch-architecture] for more details. 156 Parent Set (PS): Given a RPL node, the set of its neighbor nodes 157 which participate in the same RPL DODAG and which can potentially 158 take the role of the node's preferred parent. 160 Alternative Parent (AP): A RPL parent in the parent set of a node 161 which is used to forward a packet copy when replicating packets. 163 Alternative Parent (AP) Selection: The mechanism for choosing the 164 next hop node to forward a packet copy when replicating packets. 166 Preferred Grand Parent (PGP): The preferred parent of the preferred 167 parent of a node. 169 3. Common Ancestor AP Selection Policies 171 In the RPL protocol, each node maintains a list of potential parents. 172 For PRE, the Preferred Parent (PP) node is defined to be the same as 173 the RPL DODAG Preferred Parent node. Furthermore, to construct an 174 alternative path toward the root, in addition to the PP node, each 175 node in the network selects additional parent(s), called alternative 176 parent(s), from its Parent Set (PS). 178 There are multiple possible policies of selecting the AP node. This 179 section details three such possible policies. 181 All three policies defined perform AP selection based on common 182 ancestors, named Common Ancestor Strict, Common Ancestor Medium, and 183 Common Ancestor Relaxed, depending on how restrictive the selection 184 process is. A more restrictive policy will limit flooding but might 185 fail to select an appropriate AP, while a less restrictive one will 186 more often find an appropriate AP but might increase flooding. 188 All three policies apply their corresponding common ancestor 189 criterion to filter the list of candidate neighbours in the 190 alternative parent set. 192 3.1. Common Ancestor Strict 194 In the CA Strict OF the node will check if its Preferred Grand Parent 195 (PGP), the PP of its PP, is the same as the PP of the potential AP. 197 ( R ) root 198 . PS(S) = {A, B, C, D} 199 . PP(S) = C 200 . PP(PP(S)) = Y 201 . 202 PS(A) = {W, X} 203 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 204 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 205 | \ // | \ // || \ / || PS(B) = {W, X, Y} 206 | // | // || / || PP(B) = Y 207 | // \ | // \ || / \ || 208 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 209 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 210 ^ ^ ^^ ^ 211 \ \ || / PS(D) = {Y, Z} 212 \ \ || / PP(D) = Z 213 \ \ || / 214 \----\\ || / || Preferred Parent 215 ( S ) source | Potential Alt. Parent 217 Figure 1: Example Common Ancestor Strict Alternative Parent 218 Selection policy 220 For example, in Figure 1, the source node S must know its grandparent 221 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 222 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 223 of the figure. The CA Strict parent selection policy will select an 224 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 225 Y: 227 * Node A: PP(A) = X and therefore it is different than PP(PP(S)) 229 * Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 231 * Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 233 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 234 PP(B). 236 3.2. Common Ancestor Medium 238 In the CA Medium OF the node will check if its Preferred Grand Parent 239 (PGP), the PP of its PP, is contained in the PS of the potential AP. 241 Using the same example, in Figure 1, the CA Medium parent selection 242 policy will select an AP for node S for which PP(PP(S)) is in PS(AP). 243 Given that PP(PP(S)) = Y: 245 * Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 247 * Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 249 * Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 251 node S can decide to use node B or D as its AP node. 253 3.3. Common Ancestor Relaxed 255 In the CA Relaxed OF the node will check if the Parent Set (PS) of 256 its Preferred Parent (PP) has a node in common with the PS of the 257 potential AP. 259 Using the same example, in Figure 1, the CA Relaxed parent selection 260 policy will select an AP for node S for which PS(PP(S)) has at least 261 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 263 * Node A: PS(A) = {W, X} and the common nodes are {X} 265 * Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 267 * Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 269 node S can decide to use node A, B or D as its AP node. 271 4. Common Ancestor Objective Function 273 An OF which allows the multiple paths to remain correlated is 274 detailed here. More specifically, when using this OF a node will 275 select an AP node close to its PP node to allow the operation of 276 overhearing between parents. For more details about overhearing and 277 its use in this context see the "Complex Track with Replication and 278 Elimination" in Section 4.5.3 of [I-D.ietf-6tisch-architecture]. If 279 multiple potential APs match this condition, the AP with the lowest 280 rank will be registered. 282 The OF described here is an extension of The Minimum Rank with 283 Hysteresis Objective Function [MRHOF]. In general, this OF extends 284 MRHOF by specifying how an AP is selected. Importantly, the 285 calculation of the rank of the node through each candidate neighbor 286 and the selection of the PP is kept the same as in MRHOF. 288 The ways in which the CA OF modifies MRHOF in a section-by-section 289 manner follows in detail: 291 [MRHOF], Section 2: "Terminology". Term "Selected Metric": 292 The CA OF uses only one metric, like MRHOF, for rank calculation, 293 with the same MRHOF semantics. For selecting the AP, the PS TLV 294 (stored in the DIO Metric Container Node State and Attribute (NSA) 295 object body, see Section 5) is used. This additional NSA metric 296 is disregarded for the purposes of rank calculation. 298 [MRHOF], Section 3 "The Minimum Rank with Hysteresis Objective 299 Function": 300 Same as MRHOF extended to AP selection. Minimum Rank path 301 selection and switching applies correspondingly to the AP with the 302 extra CA requirement of having some match between ancestors. 304 [MRHOF], Section 3.1 "Computing the Path Cost": 305 Same as MRHOF extended to AP selection. If a candidate neighbor 306 does not fulfill the CA requirement then the path through that 307 neighbor SHOULD be set to MAX_PATH_COST, the same value used by 308 MRHOF. As a result, the node MUST NOT select the candidate 309 neighbor as its AP. 311 [MRHOF], Section 3.2 "Parent Selection": 312 Same as MRHOF extended to AP selection. To allow hysteresis, AP 313 selection maintains a variable, cur_ap_min_path_cost, which is the 314 path cost of the current AP. 316 [MRHOF], Section 3.2.1 "When Parent Selection Runs": 317 Same as MRHOF. 319 [MRHOF], Section 3.2.2 "Parent Selection Algorithm": 320 Same as MRHOF extended to AP selection. If the smallest path cost 321 for paths through the candidate neighbors is smaller than 322 cur_ap_min_path_cost by less than PARENT_SWITCH_THRESHOLD (the 323 same variable as MRHOF uses), the node MAY continue to use the 324 current AP. Additionally, if there is no PP selected, there MUST 325 NOT be any AP selected as well. Finally, as with MRHOF, a node 326 MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors 327 in its alternative parent set. The value of PARENT_SET_SIZE is 328 the same as in MRHOF. 330 [MRHOF], Section 3.3 "Computing Rank": 331 Same as MRHOF. 333 [MRHOF], Section 3.4 "Advertising the Path Cost": 334 Same as MRHOF. 336 [MRHOF], Section 3.5 "Working without Metric Containers": 337 It is not possible to work without metric containers, since CA AP 338 selection requires information from parents regarding their parent 339 sets, which is transmitted via the NSA object in the DIO Mectric 340 Container. 342 [MRHOF], Section 4 "Using MRHOF for Metric Maximization": 343 Same as MRHOF. 345 [MRHOF], Section 5 "MRHOF Variables and Parameters": 346 Same as MRHOF extended to AP selection. The CA OF operates like 347 MRHOF for AP selection by maintaining separate: 349 AP: Corresponding to the MRHOF PP. Hysteresis is configured for 350 AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF. 351 The AP MUST NOT be the same as the PP. 353 Alternative parent set: Corresponding to the MRHOF parent set. 354 The size is defined by the same PARENT_SET_SIZE parameter as in 355 MRHOF. The Alternative parent set MUST be a non-strict subset 356 of the parent set. 358 cur_ap_min_path_cost: Corresponding to the MRHOF 359 cur_min_path_cost variable. To support the operation of the 360 hysteresis function for AP selection. 362 [MRHOF], Section 6 "Manageability": 363 Same as MRHOF. 365 [MRHOF], Section 6.1 "Device Configuration": 366 Same as MRHOF. 368 [MRHOF], Section 6.2 "Device Monitoring": 369 Same as MRHOF. 371 4.1. Usage 373 All OF policies apply their corresponding criterion to filter the 374 list of candidate neighbours in the alternative parent set. The AP 375 is then selected from the alternative parent set based on Rank and 376 using hysteresis as is done for the PP in MRHOF. It is noteworthy 377 that the OF uses the same Objective Code Point (OCP): TBD1 for all 378 policies used. 380 The PS information can be used by any of the described AP selection 381 policies or other ones not described here, depending on requirements. 382 It is optional for all nodes to use the same AP selection policies. 383 Different nodes may use different AP selection policies, since the 384 selection policy is local to each node. For example, using different 385 policies can be used to vary the transmission reliability in each 386 hop. 388 5. Node State and Attribute (NSA) object type extension 390 In order to select their AP node, nodes need to be aware of their 391 grandparent node sets. Within [RPL], the nodes use the DODAG 392 Information Object (DIO) Control Message to broadcast information 393 about themselves to potential children. However, [RPL], does not 394 define how to propagate parent set related information, which is what 395 this document addresses. 397 DIO messages can carry multiple options, out of which the DAG Metric 398 Container option [RFC6551] is the most suitable structurally and 399 semantically for the purpose of carrying the parent set. The DAG 400 Metric Container option itself can carry different nested objects, 401 out of which the Node State and Attribute (NSA) [RFC6551] is 402 appropriate for transferring generic node state data. Within the 403 Node State and Attribute it is possible to store optional TLVs 404 representing various node characteristics. As per the Node State and 405 Attribute (NSA) [RFC6551] description, no TLV has been defined for 406 use. This document defines one TLV for the purpose of transmitting a 407 node's parent set. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | RPLInstanceID |Version Number | Rank | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |G|0| MOP | Prf | DTSN | Flags | Reserved | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 + + 418 | | 419 + DODAGID + 420 | | 421 + + 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | DAGMC Type (2)| DAGMC Length | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 426 | | 427 // DAG Metric Container data // 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 2: Example DIO Message with a DAG Metric Container option 433 Figure 2 shows the structure of the DIO Control Message when a DAG 434 Metric Container option is included. The DAG Metric Container option 435 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 436 registry for the RPL Control Message Options, and is defined in 437 [RPL]. The DAG Metric Container option length (DAGMC Length in 438 Figure 2) expresses the DAG Metric Container length in bytes. DAG 439 Metric Container data holds the actual data and is shown expanded in 440 Figure 3. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Res | Flags |A|O| PS type | PS Length | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | PS IPv6 address(es) ... 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 3: DAG Metric Container (MC) data with Node State and 453 Attribute (NSA) object body and a TLV 455 The structure of the DAG Metric Container data in the form of a Node 456 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 457 field is shown in Figure 3. The first 32 bits comprise the DAG 458 Metric Container header and all the following bits are part of the 459 Node State and Attribute object body, as defined in [RFC6551]. This 460 document defines a new TLV, which MAY be carried in the Node State 461 and Attribute (NSA) object Optional TLVs field. The TLV is named 462 Parent Set and is abbreviated as PS in Figure 3. 464 PS type: The type of the Parent Set TLV. The value is TBD2. 466 PS Length: The total length of the TLV value field (PS IPv6 467 address(es)) in bytes. The length is an integral multiple of 468 16, the number of bytes in an IPv6 address. 470 PS IPv6 address(es) One or more 128-bit IPv6 address(es) without any 471 separator between them. The field consists of one IPv6 address 472 per parent in the parent set. The parent addresses are listed 473 in decreasing order of preference and not all parents in the 474 parent set need to be included. The selection of how many 475 parents from the parent set are to be included is left to the 476 implementation. The number of parent addresses in the PS IPv6 477 address(es) field can be deduced by dividing the length of the 478 PS IPv6 address(es) field in bytes by 16, the number of bytes 479 in an IPv6 address. 481 5.1. Usage 483 The PS SHOULD be used in the process of parent selection, and 484 especially in AP selection, since it can help the alternative path to 485 not significantly deviate from the preferred path. The Parent Set is 486 information local to the node that broadcasts it. 488 The PS is used only within NSA objects configured as a metric, 489 therefore the DAG Metric Container field "C" MUST be 0. 490 Additionally, since the information in the PS needs to be propagated 491 downstream but it cannot be aggregated, the DAG Metric Container 492 field "R" MUST be 1. Finally, since the information contained is by 493 definition partial, more specifically just the parent set of the DIO- 494 sending node, the DAG Metric Container field "P" MUST be 1. 496 It is important that the PS does not affect the calculation of the 497 rank through candidate neighbors. It is only used with the CA OF to 498 remove nodes which do not fulfill the CA OF criteria from the 499 candidate neighbor list. 501 6. Controlling PRE 503 PRE is very helpful when the aim is to increase reliability for a 504 certain path, however its use creates additional traffic as part of 505 the replication process. It is conceivable that not all paths have 506 stringent reliability requirements. Therefore, a way to control 507 whether PRE is applied to a path's packets SHOULD be implemented. 508 For example, a traffic class label can be used to determine this 509 behavior per flow type as described in Deterministic Networking 510 Architecture [RFC8655]. 512 7. Security Considerations 514 The structure of the DIO control message is extended, within the pre- 515 defined DIO options. The additional information are the IPv6 516 addresses of the parent set of the node transmitting the DIO. This 517 use of this additional information can have the following potential 518 consequences: 520 * A malicious node that can receive and read the DIO can "see" 521 further than it's own neighbourhood by one hop, learning the 522 addresses of it's two hop neighbors. This is a privacy / network 523 discovery issue. 525 * A malicious node that can send DIOs can use the parent set 526 extension to convince neighbours to route through itself, instead 527 of the normal preferred parent they would use. However, this is 528 already possible with other OFs (like [OF0] and [MRHOF]) by 529 reporting a fake rank value in the DIO, thus masquerading as the 530 DODAG root. 532 8. IANA Considerations 534 This proposal requests the allocation of a new value TBD1 from the 535 "Objective Code Point (OCP)" sub-registry of the "Routing Protocol 536 for Low Power and Lossy Networks (RPL)" registry. 538 This proposal also requests the allocation of a new value TBD2 for 539 the "Parent Set" TLV from the "Routing Metric/Constraint TLVs" sub- 540 registry of the "Routing Protocol for Low Power and Lossy Networks 541 (RPL) Routing Metric/Constraint" registry. 543 9. Acknowledgments 545 We are very grateful to Dominique Barthel, Rahul Jadhav, Fabrice 546 Theoleyre, Diego Dujovne, Derek Jianqiang Hou, and Michael Richardson 547 for their comments, feedback, and support which lead to many 548 improvements to this document. We would also like to thank Tomas 549 Lagos Jenschke very much for helping in the implementation and 550 evaluation of the proposals of this document. 552 10. References 554 10.1. Normative references 556 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 557 and D. Barthel, "Routing Metrics Used for Path Calculation 558 in Low-Power and Lossy Networks", RFC 6551, 559 DOI 10.17487/RFC6551, March 2012, 560 . 562 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 563 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 564 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 565 Low-Power and Lossy Networks", RFC 6550, 566 DOI 10.17487/RFC6550, March 2012, 567 . 569 10.2. Informative references 571 [I-D.ietf-6tisch-architecture] 572 Thubert, P., "An Architecture for IPv6 over the TSCH mode 573 of IEEE 802.15.4", Work in Progress, Internet-Draft, 574 draft-ietf-6tisch-architecture-29, 27 August 2020, 575 . 578 [IEEE802154] 579 IEEE standard for Information Technology, "IEEE Std. 580 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 581 and Physical Layer (PHY) Specifications for Low-Rate 582 Wireless Personal Area Networks", December 2015, 583 . 586 [MRHOF] Gnawali, O. and P. Levis, "The Minimum Rank with 587 Hysteresis Objective Function", RFC 6719, 588 DOI 10.17487/RFC6719, September 2012, 589 . 591 [OF0] Thubert, P., Ed., "Objective Function Zero for the Routing 592 Protocol for Low-Power and Lossy Networks (RPL)", 593 RFC 6552, DOI 10.17487/RFC6552, March 2012, 594 . 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 602 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 603 . 605 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 606 "Deterministic Networking Architecture", RFC 8655, 607 DOI 10.17487/RFC8655, October 2019, 608 . 610 Appendix A. Implementation Status 612 A research-stage implementation of the PRE mechanism using the 613 proposed extension as part of a 6TiSCH IOT use case was developed at 614 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 615 Koutsiamanis. It was implemented on the open-source Contiki OS and 616 tested with the Cooja simulator. The DIO DAGMC NSA extension is 617 implemented with a configurable number of parents from the parent set 618 of a node to be reported. 620 ( R ) 622 (11) (12) (13) (14) (15) (16) 624 (21) (22) (23) (24) (25) (26) 626 (31) (32) (33) (34) (35) (36) 628 (41) (42) (43) (44) (45) (46) 630 (51) (52) (53) (54) (55) (56) 632 ( S ) 633 Figure 4: Simulation Topology 635 The simulation setup is: 637 Topology: 32 nodes structured in regular grid as show in Figure 4. 638 Node S (source) is the only data packet sender, and send data to 639 node R (root). The parent set of each node (except R) is all the 640 nodes in the immediately higher row, the immediately above 6 641 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 642 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 643 14, 15, 16 have a single upwards link to R. 645 MAC: TSCH with 1 retransmission 647 Platform: Cooja 649 Schedule: Static, 2 timeslots per link from each node to each parent 650 in its parent set, 1 broadcast EB slot, 1 sender-based shared 651 timeslot (for DIO and DIS) per node (total of 32). 653 Simulation lifecycle: Allow link formation for 100 seconds before 654 starting to send data packets. Afterwards, S sends data packets 655 to R. The simulation terminates when 1000 packets have been sent 656 by S. 658 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 659 drawn for each link, with a uniform distribution spanning the 70% 660 to 100% interval. 662 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 663 seconds to R. 665 PS extension size: 3 parents. 667 Routing Methods: 668 * RPL: The default RPL non-PRE implementation in Contiki OS. 670 * 2nd ETX: PRE with a parent selection method which picks as AP 671 the 2nd best parent in the parent set based on ETX. 673 * CA Strict: As described in Section 3.1. 675 * CA Medium: As described in Section 3.2. 677 Simulation results: 679 +=========+===================+===================+===============+ 680 | Routing | Average Packet | Average Traversed | Average | 681 | Method | Delivery Rate (%) | Nodes/packet (#) | Duplications/ | 682 | | | | packet (#) | 683 +=========+===================+===================+===============+ 684 | RPL | 82.70 | 5.56 | 7.02 | 685 +---------+-------------------+-------------------+---------------+ 686 | 2nd ETX | 99.38 | 14.43 | 31.29 | 687 +---------+-------------------+-------------------+---------------+ 688 | CA | 97.32 | 9.86 | 18.23 | 689 | Strict | | | | 690 +---------+-------------------+-------------------+---------------+ 691 | CA | 99.66 | 13.75 | 28.86 | 692 | Medium | | | | 693 +---------+-------------------+-------------------+---------------+ 695 Table 1 697 Links: 699 * Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 700 extension branch) (https://github.com/ariskou/contiki/tree/draft- 701 koutsiamanis-roll-nsa-extension) 703 * Wireshark dissectors (for the optional PS TLV) - currently merged 704 / in master (https://code.wireshark.org/review/gitweb?p=wireshark. 705 git;a=commit;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138) 707 Appendix B. Choosing an AP selection policy 709 The manner of choosing an AP selection policy is left to the 710 implementation, for maximum flexibility. 712 For example, a different policy can be used per traffic type. The 713 network configurator can choose the CA Relaxed policy to increase 714 reliability (thus producing some flooding) for specific, extremely 715 important, alert packets. On the other hand, all normal data traffic 716 uses the CA Strict policy. Therefore, an exception is made just for 717 the alert packets. 719 Another option would be to devise a new disjoint policy, where the 720 paths are on purpose non-correlated, to increase path diversity and 721 resilience against whole groups of nodes failing. The disadvantage 722 may be increased jitter. 724 Finally, a network configurator may provide the CA policies with a 725 preference order of Strict > Medium > Relaxed as a means of falling 726 back to more flood-prone policies to maintain reliability. 728 Authors' Addresses 730 Remous-Aris Koutsiamanis (editor) 731 IMT Atlantique 732 Office B215 733 4 rue Alfred Kastler, BP 20722 734 44307 Nantes Cedex 3 735 France 737 Email: aris@ariskou.com 739 Georgios Papadopoulos 740 IMT Atlantique 741 Office B00 - 114A 742 2 Rue de la Chataigneraie 743 35510 Cesson-Sevigne - Rennes 744 France 746 Phone: +33 299 12 70 04 747 Email: georgios.papadopoulos@imt-atlantique.fr 749 Nicolas Montavont 750 IMT Atlantique 751 Office B00 - 106A 752 2 Rue de la Chataigneraie 753 35510 Cesson-Sevigne - Rennes 754 France 756 Phone: +33 299 12 70 23 757 Email: nicolas.montavont@imt-atlantique.fr 759 Pascal Thubert 760 Cisco Systems, Inc 761 Building D 762 45 Allee des Ormes - BP1200 763 06254 MOUGINS - Sophia Antipolis 764 France 766 Phone: +33 497 23 26 34 767 Email: pthubert@cisco.com