idnits 2.17.1 draft-ietf-roll-nsa-extension-08.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 March 2020) is 1491 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 602, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 Summary: 1 error (**), 0 flaws (~~), 3 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: 28 September 2020 IMT Atlantique 6 P. Thubert 7 Cisco 8 27 March 2020 10 Common Ancestor Objective Function and Parent Set DAG Metric Container 11 Extension 12 draft-ietf-roll-nsa-extension-08 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 28 September 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Informative references . . . . . . . . . . . . . . . . . 12 74 9.2. Other Informative References . . . . . . . . . . . . . . 14 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) 85 [I-D.papadopoulos-raw-pareo-reqs] is a technique which allows 86 redundant paths in the network to be utilized for traffic requiring 87 higher reliability. Allowing industrial applications to function 88 over 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. Building on this architecture, "Exploiting Packet Replication 106 and Elimination in Complex Tracks in LLNs" 107 [I-D.papadopoulos-raw-pareo-reqs] leverages PRE to improve the Packet 108 Delivery Ratio (PDR), to provide a hard bound to the end-to-end 109 latency, and thus to limit jitter. 111 PRE is a general method of maximizing packet delivery rate and 112 potentially minimizing latency and jitter, not limited to 6TiSCH. 113 More specifically, PRE achieves controlled redundancy by laying 114 multiple forwarding paths through the network and using them in 115 parallel for different copies of a same packet. PRE can follow the 116 Destination-Oriented Directed Acyclic Graph (DODAG) formed by [RPL] 117 from a node to the root. Building a multi-path DODAG can be achieved 118 based on the RPL capability of having multiple parents for each node 119 in a network, a subset of which is used to forward packets. In order 120 to select parents to be part of this subset, the RPL Objective 121 Function (OF) needs additional information regarding the multi-path 122 nature of PRE. This document describes an OF which implements multi- 123 path routing for PRE and specifies the transmission of this specific 124 path information. 126 This document describes a new Objective Function (OF) called the 127 Common Ancestor (CA) OF (see Section 4). A detailed description is 128 given of how the path information is used within the CA OF and how 129 the subset of parents for forwarding packets is selected. This 130 specification defines a new Objective Code Point (OCP) for the CA OF. 132 For the path information, this specification focuses on the 133 extensions to the DAG Metric Container [RFC6551] required for 134 providing the PRE mechanism a part of the information it needs to 135 operate. This information is the [RPL] parent address set of a node 136 and it must be sent to potential children of the node. The RPL DIO 137 Control Message is the canonical way of broadcasting this kind of 138 information and therefore its DAG Metric Container [RFC6551] field is 139 used to append a Node State and Attribute (NSA) object. The node's 140 parent address set is stored as an optional TLV within the NSA 141 object. This specification defines the type value and structure for 142 the parent address set TLV (see Section 5). 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 The draft uses the following Terminology: 152 Packet Replication and Elimination (PRE): A method which consists of 153 transmitting multiple copies of a packet using multi-path 154 forwarding over a multi-hop network and which consolidates 155 multiple received packet copies to control flooding. See 156 "Exploiting Packet Replication and Elimination in Complex Tracks 157 in LLNs" [I-D.papadopoulos-raw-pareo-reqs] for more details. 159 Parent Set (PS): Given a RPL node, the set of its neighbor nodes 160 which participate in the same RPL DODAG and which can potentially 161 take the role of the node's preferred parent. 163 Alternative Parent (AP): A RPL parent in the parent set of a node 164 which is used to forward a packet copy when replicating packets. 166 Alternative Parent (AP) Selection: The mechanism for choosing the 167 next hop node to forward a packet copy when replicating packets. 169 Preferred Grand Parent (PGP): The preferred parent of the preferred 170 parent of a node. 172 3. Common Ancestor AP Selection Policies 174 In the RPL protocol, each node maintains a list of potential parents. 175 For PRE, the Preferred Parent (PP) node is defined to be the same as 176 the RPL DODAG Preferred Parent node. Furthermore, to construct an 177 alternative path toward the root, in addition to the PP node, each 178 node in the network selects additional parent(s), called alternative 179 parent(s), from its Parent Set (PS). 181 There are multiple possible policies of selecting the AP node. This 182 section details three such possible policies. 184 All three policies defined perform AP selection based on common 185 ancestors, named Common Ancestor Strict, Common Ancestor Medium, and 186 Common Ancestor Relaxed, depending on how restrictive the selection 187 process is. A more restrictive policy will limit flooding but might 188 fail to select an appropriate AP, while a less restrictive one will 189 more often find an appropriate AP but might increase flooding. 191 All three policies apply their corresponding common ancestor 192 criterion to filter the list of candidate neighbours in the 193 alternative parent set. 195 3.1. Common Ancestor Strict 197 In the CA Strict OF the node will check if its Preferred Grand Parent 198 (PGP), the PP of its PP, is the same as the PP of the potential AP. 200 ( R ) root 201 . PS(S) = {A, B, C, D} 202 . PP(S) = C 203 . PP(PP(S)) = Y 204 . 205 PS(A) = {W, X} 206 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 207 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 208 | \ // | \ // || \ / || PS(B) = {W, X, Y} 209 | // | // || / || PP(B) = Y 210 | // \ | // \ || / \ || 211 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 212 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 213 ^ ^ ^^ ^ 214 \ \ || / PS(D) = {Y, Z} 215 \ \ || / PP(D) = Z 216 \ \ || / 217 \----\\ || / || Preferred Parent 218 ( S ) source | Potential Alternative Parent 220 Figure 1: Example Common Ancestor Strict Alternative Parent 221 Selection policy 223 For example, in Figure 1, the source node S must know its grandparent 224 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 225 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 226 of the figure. The CA Strict parent selection policy will select an 227 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 228 Y: 230 * Node A: PP(A) = X and therefore it is different than PP(PP(S)) 232 * Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 234 * Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 236 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 237 PP(B). 239 3.2. Common Ancestor Medium 241 In the CA Medium OF the node will check if its Preferred Grand Parent 242 (PGP), the PP of its PP, is contained in the PS of the potential AP. 244 Using the same example, in Figure 1, the CA Medium parent selection 245 policy will select an AP for node S for which PP(PP(S)) is in PS(AP). 246 Given that PP(PP(S)) = Y: 248 * Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 250 * Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 252 * Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 254 node S can decide to use node B or D as its AP node. 256 3.3. Common Ancestor Relaxed 258 In the CA Relaxed OF the node will check if the Parent Set (PS) of 259 its Preferred Parent (PP) has a node in common with the PS of the 260 potential AP. 262 Using the same example, in Figure 1, the CA Relaxed parent selection 263 policy will select an AP for node S for which PS(PP(S)) has at least 264 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 266 * Node A: PS(A) = {W, X} and the common nodes are {X} 268 * Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 270 * Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 272 node S can decide to use node A, B or D as its AP node. 274 4. Common Ancestor Objective Function 276 An OF which allows the multiple paths to remain correlated is 277 detailed here. More specifically, when using this OF a node will 278 select an AP node close to its PP node to allow the operation of 279 overhearing between parents. For more details about overhearing and 280 its use in this context see the "Promiscuous Overhearing" Section 4.3 281 of [I-D.papadopoulos-raw-pareo-reqs]. If multiple potential APs 282 match this condition, the AP with the lowest rank will be registered. 284 The OF described here is an extension of The Minimum Rank with 285 Hysteresis Objective Function [MRHOF]. In general, this OF extends 286 MRHOF by specifying how an AP is selected. Importantly, the 287 calculation of the rank of the node through each candidate neighbor 288 and the selection of the PP is kept the same as in MRHOF. 290 The ways in which the CA OF modifies MRHOF in a section-by-section 291 manner follows in detail: 293 [MRHOF], Section 2: "Terminology". Term "Selected Metric": 294 The CA OF uses only one metric, like MRHOF, for rank calculation, 295 with the same MRHOF semantics. For selecting the AP, the PS TLV 296 (stored in the DIO Metric Container Node State and Attribute (NSA) 297 object body, see Section 5) is used. This additional NSA metric 298 is disregarded for the purposes of rank calculation. 300 [MRHOF], Section 3 "The Minimum Rank with Hysteresis Objective 301 Function": 302 Same as MRHOF extended to AP selection. Minimum Rank path 303 selection and switching applies correspondingly to the AP with the 304 extra CA requirement of having some match between ancestors. 306 [MRHOF], Section 3.1 "Computing the Path Cost": 307 Same as MRHOF extended to AP selection. If a candidate neighbor 308 does not fulfill the CA requirement then the path through that 309 neighbor SHOULD be set to MAX_PATH_COST, the same value used by 310 MRHOF. As a result, the node MUST NOT select the candidate 311 neighbor as its AP. 313 [MRHOF], Section 3.2 "Parent Selection": 314 Same as MRHOF extended to AP selection. To allow hysteresis, AP 315 selection maintains a variable, cur_ap_min_path_cost, which is the 316 path cost of the current AP. 318 [MRHOF], Section 3.2.1 "When Parent Selection Runs": 319 Same as MRHOF. 321 [MRHOF], Section 3.2.2 "Parent Selection Algorithm": 322 Same as MRHOF extended to AP selection. If the smallest path cost 323 for paths through the candidate neighbors is smaller than 324 cur_ap_min_path_cost by less than PARENT_SWITCH_THRESHOLD (the 325 same variable as MRHOF uses), the node MAY continue to use the 326 current AP. Additionally, if there is no PP selected, there MUST 327 NOT be any AP selected as well. Finally, as with MRHOF, a node 328 MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors 329 in its alternative parent set. The value of PARENT_SET_SIZE is 330 the same as in MRHOF. 332 [MRHOF], Section 3.3 "Computing Rank": 333 Same as MRHOF. 335 [MRHOF], Section 3.4 "Advertising the Path Cost": 336 Same as MRHOF. 338 [MRHOF], Section 3.5 "Working without Metric Containers": 339 It is not possible to work without metric containers, since CA AP 340 selection requires information from parents regarding their parent 341 sets, which is transmitted via the NSA object in the DIO Mectric 342 Container. 344 [MRHOF], Section 4 "Using MRHOF for Metric Maximization": 345 Same as MRHOF. 347 [MRHOF], Section 5 "MRHOF Variables and Parameters": 348 Same as MRHOF extended to AP selection. The CA OF operates like 349 MRHOF for AP selection by maintaining separate: 351 AP: Corresponding to the MRHOF PP. Hysteresis is configured for 352 AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF. 353 The AP MUST NOT be the same as the PP. 355 Alternative parent set: Corresponding to the MRHOF parent set. 356 The size is defined by the same PARENT_SET_SIZE parameter as in 357 MRHOF. The Alternative parent set MUST be a non-strict subset 358 of the parent set. 360 cur_ap_min_path_cost: Corresponding to the MRHOF 361 cur_min_path_cost variable. To support the operation of the 362 hysteresis function for AP selection. 364 [MRHOF], Section 6 "Manageability": 365 Same as MRHOF. 367 [MRHOF], Section 6.1 "Device Configuration": 368 Same as MRHOF. 370 [MRHOF], Section 6.2 "Device Monitoring": 371 Same as MRHOF. 373 4.1. Usage 375 All OF policies apply their corresponding criterion to filter the 376 list of candidate neighbours in the alternative parent set. The AP 377 is then selected from the alternative parent set based on Rank and 378 using hysteresis as is done for the PP in MRHOF. It is noteworthy 379 that the OF uses the same Objective Code Point (OCP): TBD1 for all 380 policies used. 382 The PS information can be used by any of the described AP selection 383 policies or other ones not described here, depending on requirements. 384 It is optional for all nodes to use the same AP selection policies. 385 Different nodes may use different AP selection policies, since the 386 selection policy is local to each node. For example, using different 387 policies can be used to vary the transmission reliability in each 388 hop. 390 5. Node State and Attribute (NSA) object type extension 392 In order to select their AP node, nodes need to be aware of their 393 grandparent node sets. Within [RPL], the nodes use the DODAG 394 Information Object (DIO) Control Message to broadcast information 395 about themselves to potential children. However, [RPL], does not 396 define how to propagate parent set related information, which is what 397 this document addresses. 399 DIO messages can carry multiple options, out of which the DAG Metric 400 Container option [RFC6551] is the most suitable structurally and 401 semantically for the purpose of carrying the parent set. The DAG 402 Metric Container option itself can carry different nested objects, 403 out of which the Node State and Attribute (NSA) [RFC6551] is 404 appropriate for transferring generic node state data. Within the 405 Node State and Attribute it is possible to store optional TLVs 406 representing various node characteristics. As per the Node State and 407 Attribute (NSA) [RFC6551] description, no TLV has been defined for 408 use. This document defines one TLV for the purpose of transmitting a 409 node's parent set. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | RPLInstanceID |Version Number | Rank | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |G|0| MOP | Prf | DTSN | Flags | Reserved | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 + + 420 | | 421 + DODAGID + 422 | | 423 + + 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | DAGMC Type (2)| DAGMC Length | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 428 | | 429 // DAG Metric Container data // 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 2: Example DIO Message with a DAG Metric Container option 435 Figure 2 shows the structure of the DIO Control Message when a DAG 436 Metric Container option is included. The DAG Metric Container option 437 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 438 registry for the RPL Control Message Options, and is defined in 439 [RPL]. The DAG Metric Container option length (DAGMC Length in 440 Figure 2) expresses the DAG Metric Container length in bytes. DAG 441 Metric Container data holds the actual data and is shown expanded in 442 Figure 3. 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Res | Flags |A|O| PS type | PS Length | | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA 451 | PS IPv6 address(es) ... | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 3: DAG Metric Container (MC) data with Node State and 455 Attribute (NSA) object body and a TLV 457 The structure of the DAG Metric Container data in the form of a Node 458 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 459 field is shown in Figure 3. The first 32 bits comprise the DAG 460 Metric Container header and all the following bits are part of the 461 Node State and Attribute object body, as defined in [RFC6551]. This 462 document defines a new TLV, which MAY be carried in the Node State 463 and Attribute (NSA) object Optional TLVs field. The TLV is named 464 Parent Set and is abbreviated as PS in Figure 3. 466 PS type: The type of the Parent Set TLV. The value is TBD2. 468 PS Length: The total length of the TLV value field (PS IPv6 469 address(es)) in bytes. The length is an integral multiple of 470 16, the number of bytes in an IPv6 address. 472 PS IPv6 address(es) One or more 128-bit IPv6 address(es) without any 473 separator between them. The field consists of one IPv6 address 474 per parent in the parent set. The parent addresses are listed 475 in decreasing order of preference and not all parents in the 476 parent set need to be included. The selection of how many 477 parents from the parent set are to be included is left to the 478 implementation. The number of parent addresses in the PS IPv6 479 address(es) field can be deduced by dividing the length of the 480 PS IPv6 address(es) field in bytes by 16, the number of bytes 481 in an IPv6 address. 483 5.1. Usage 485 The PS SHOULD be used in the process of parent selection, and 486 especially in AP selection, since it can help the alternative path to 487 not significantly deviate from the preferred path. The Parent Set is 488 information local to the node that broadcasts it. 490 The PS is used only within NSA objects configured as a metric, 491 therefore the DAG Metric Container field "C" MUST be 0. 492 Additionally, since the information in the PS needs to be propagated 493 downstream but it cannot be aggregated, the DAG Metric Container 494 field "R" MUST be 1. Finally, since the information contained is by 495 definition partial, more specifically just the parent set of the DIO- 496 sending node, the DAG Metric Container field "P" MUST be 1. 498 It is important that the PS does not affect the calculation of the 499 rank through candidate neighbors. It is only used with the CA OF to 500 remove nodes which do not fulfill the CA OF criteria from the 501 candidate neighbor list. 503 6. Controlling PRE 505 PRE is very helpful when the aim is to increase reliability for a 506 certain path, however its use creates additional traffic as part of 507 the replication process. It is conceivable that not all paths have 508 stringent reliability requirements. Therefore, a way to control 509 whether PRE is applied to a path's packets SHOULD be implemented. 510 For example, a traffic class label can be used to determine this 511 behavior per flow type as described in Deterministic Networking 512 Architecture [RFC8655]. 514 7. Security Considerations 516 The structure of the DIO control message is extended, within the pre- 517 defined DIO options. The additional information are the IPv6 518 addresses of the parent set of the node transmitting the DIO. This 519 use of this additional information can have the following potential 520 consequences: 522 * A malicious node that can receive and read the DIO can "see" 523 further than it's own neighbourhood by one hop, learning the 524 addresses of it's two hop neighbors. This is a privacy / network 525 discovery issue. 527 * A malicious node that can send DIOs can use the parent set 528 extension to convince neighbours to route through itself, instead 529 of the normal preferred parent they would use. However, this is 530 already possible with other OFs (like [OF0] and [MRHOF]) by 531 reporting a fake rank value in the DIO, thus masquerading as the 532 DODAG root. 534 8. IANA Considerations 536 This proposal requests the allocation of a new value TBD1 from the 537 "Objective Code Point (OCP)" sub-registry of the "Routing Protocol 538 for Low Power and Lossy Networks (RPL)" registry. 540 This proposal also requests the allocation of a new value TBD2 for 541 the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub- 542 registry from IANA. 544 9. References 546 9.1. Informative references 548 [I-D.ietf-6tisch-architecture] 549 Thubert, P., "An Architecture for IPv6 over the TSCH mode 550 of IEEE 802.15.4", Work in Progress, Internet-Draft, 551 draft-ietf-6tisch-architecture-28, 29 October 2019, 552 . 555 [I-D.papadopoulos-raw-pareo-reqs] 556 Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P. 557 Thubert, "Exploiting Packet Replication and Elimination in 558 Complex Tracks in LLNs", Work in Progress, Internet-Draft, 559 draft-papadopoulos-raw-pareo-reqs-01, 2 January 2020, 560 . 563 [MRHOF] Gnawali, O. and P. Levis, "The Minimum Rank with 564 Hysteresis Objective Function", RFC 6719, 565 DOI 10.17487/RFC6719, September 2012, 566 . 568 [OF0] Thubert, P., Ed., "Objective Function Zero for the Routing 569 Protocol for Low-Power and Lossy Networks (RPL)", 570 RFC 6552, DOI 10.17487/RFC6552, March 2012, 571 . 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 579 and D. Barthel, "Routing Metrics Used for Path Calculation 580 in Low-Power and Lossy Networks", RFC 6551, 581 DOI 10.17487/RFC6551, March 2012, 582 . 584 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 585 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 586 . 588 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 589 "Deterministic Networking Architecture", RFC 8655, 590 DOI 10.17487/RFC8655, October 2019, 591 . 593 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 594 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 595 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 596 Low-Power and Lossy Networks", RFC 6550, 597 DOI 10.17487/RFC6550, March 2012, 598 . 600 9.2. Other Informative References 602 [IEEE802154] 603 IEEE standard for Information Technology, "IEEE Std 604 802.15.4 Standard for Low-Rate Wireless Personal Area 605 Networks (WPANs)", December 2015. 607 Appendix A. Implementation Status 609 A research-stage implementation of the PRE mechanism using the 610 proposed extension as part of a 6TiSCH IOT use case was developed at 611 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 612 Koutsiamanis. It was implemented on the open-source Contiki OS and 613 tested with the Cooja simulator. The DIO DAGMC NSA extension is 614 implemented with a configurable number of parents from the parent set 615 of a node to be reported. 617 ( R ) 619 (11) (12) (13) (14) (15) (16) 621 (21) (22) (23) (24) (25) (26) 623 (31) (32) (33) (34) (35) (36) 625 (41) (42) (43) (44) (45) (46) 627 (51) (52) (53) (54) (55) (56) 629 ( S ) 631 Figure 4: Simulation Topology 633 The simulation setup is: 635 Topology: 32 nodes structured in regular grid as show in Figure 4. 636 Node S (source) is the only data packet sender, and send data to 637 node R (root). The parent set of each node (except R) is all the 638 nodes in the immediately higher row, the immediately above 6 639 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 640 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 641 14, 15, 16 have a single upwards link to R. 643 MAC: TSCH with 1 retransmission 645 Platform: Cooja 647 Schedule: Static, 2 timeslots per link from each node to each parent 648 in its parent set, 1 broadcast EB slot, 1 sender-based shared 649 timeslot (for DIO and DIS) per node (total of 32). 651 Simulation lifecycle: Allow link formation for 100 seconds before 652 starting to send data packets. Afterwards, S sends data packets 653 to R. The simulation terminates when 1000 packets have been sent 654 by S. 656 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 657 drawn for each link, with a uniform distribution spanning the 70% 658 to 100% interval. 660 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 661 seconds to R. 663 PS extension size: 3 parents. 665 Routing Methods: * RPL: The default RPL non-PRE implementation in 666 Contiki OS. 668 * 2nd ETX: PRE with a parent selection method 669 which picks as AP the 2nd best parent in the parent set based 670 on ETX. 672 * CA Strict: As described in Section 3.1. 674 * CA Medium: As described in Section 3.2. 676 Simulation results: 678 +---------+-------------------+-------------------+---------------+ 679 | Routing | Average Packet | Average Traversed | Average | 680 | Method | Delivery Rate (%) | Nodes/packet (#) | Duplications/ | 681 | | | | packet (#) | 682 +=========+===================+===================+===============+ 683 | RPL | 82.70 | 5.56 | 7.02 | 684 +---------+-------------------+-------------------+---------------+ 685 | 2nd ETX | 99.38 | 14.43 | 31.29 | 686 +---------+-------------------+-------------------+---------------+ 687 | CA | 97.32 | 9.86 | 18.23 | 688 | Strict | | | | 689 +---------+-------------------+-------------------+---------------+ 690 | CA | 99.66 | 13.75 | 28.86 | 691 | Medium | | | | 692 +---------+-------------------+-------------------+---------------+ 694 Table 1 696 Links: 698 * Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 699 extension branch) (https://github.com/ariskou/contiki/tree/draft- 700 koutsiamanis-roll-nsa-extension) 702 * Wireshark dissectors (for the optional PS TLV) - currently merged 703 / in master (https://code.wireshark.org/review/gitweb?p=wireshark. 704 git;a=commit;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138) 706 Appendix B. Choosing an AP selection policy 708 The manner of choosing an AP selection policy is left to the 709 implementation, for maximum flexibility. 711 For example, a different policy can be used per traffic type. The 712 network configurator can choose the CA Relaxed policy to increase 713 reliability (thus producing some flooding) for specific, extremely 714 important, alert packets. On the other hand, all normal data traffic 715 uses the CA Strict policy. Therefore, an exception is made just for 716 the alert packets. 718 Another option would be to devise a new disjoint policy, where the 719 paths are on purpose non-correlated, to increase path diversity and 720 resilience against whole groups of nodes failing. The disadvantage 721 may be increased jitter. 723 Finally, a network configurator may provide the CA policies with a 724 preference order of Strict > Medium > Relaxed as a means of falling 725 back to more flood-prone policies to maintain reliability. 727 Authors' Addresses 729 Remous-Aris Koutsiamanis (editor) 730 IMT Atlantique 731 Office B00 - 126A 732 2 Rue de la Chataigneraie 733 35510 Cesson-Sevigne - Rennes 734 France 736 Phone: +33 299 12 70 49 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