idnits 2.17.1 draft-ietf-roll-nsa-extension-07.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 (March 9, 2020) is 1509 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 590, but not defined -- Looks like a reference, but probably isn't: '1' on line 689 -- Looks like a reference, but probably isn't: '2' on line 692 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Koutsiamanis, Ed. 3 Internet-Draft G. Papadopoulos 4 Intended status: Standards Track N. Montavont 5 Expires: September 10, 2020 IMT Atlantique 6 P. Thubert 7 Cisco 8 March 9, 2020 10 Common Ancestor Objective Function and Parent Set DAG Metric Container 11 Extension 12 draft-ietf-roll-nsa-extension-07 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 September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Common Ancestor AP Selection Policies . . . . . . . . . . . . 4 63 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 5 64 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 6 65 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6 66 4. Common Ancestor Objective Function . . . . . . . . . . . . . 6 67 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Node State and Attribute (NSA) object type extension . . . . 9 69 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Informative references . . . . . . . . . . . . . . . . . 12 75 9.2. Other Informative References . . . . . . . . . . . . . . 13 76 Appendix A. Implementation Status . . . . . . . . . . . . . . . 13 77 Appendix B. Choosing an AP selection policy . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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) 86 [I-D.papadopoulos-6tisch-pre-reqs] is a technique which allows 87 redundant paths in the network to be utilized for traffic requiring 88 higher reliability. Allowing industrial applications to function 89 over 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. Building on this architecture, "Exploiting Packet Replication 107 and Elimination in Complex Tracks in 6TiSCH LLNs" 108 [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the 109 Packet Delivery Ratio (PDR), to provide a hard bound to the end-to- 110 end latency, and thus to limit jitter. 112 PRE is a general method of maximizing packet delivery rate and 113 potentially minimizing latency and jitter, not limited to 6TiSCH. 114 More specifically, PRE achieves controlled redundancy by laying 115 multiple forwarding paths through the network and using them in 116 parallel for different copies of a same packet. PRE can follow the 117 Destination-Oriented Directed Acyclic Graph (DODAG) formed by RPL 118 from a node to the root. Building a multi-path DODAG can be achieved 119 based on the RPL capability of having multiple parents for each node 120 in a network, a subset of which is used to forward packets. In order 121 to select parents to be part of this subset, the RPL Objective 122 Function (OF) needs additional information regarding the multi-path 123 nature of PRE. This document describes an OF which implements multi- 124 path routing for PRE and specifies the transmission of this specific 125 path information. 127 This document describes a new Objective Function (OF) called the 128 Common Ancestor (CA) OF. A detailed description is given of how the 129 path information is used within the CA OF and how the subset of 130 parents for forwarding packets is selected. This specification 131 defines a new Objective Code Point (OCP) for the CA OF. 133 For the path information, this specification focuses on the 134 extensions to the DAG Metric Container [RFC6551] required for 135 providing the PRE mechanism a part of the information it needs to 136 operate. This information is the RPL [RFC6550] parent address set of 137 a node and it must be sent to potential children of the node. The 138 RPL DIO Control Message is the canonical way of broadcasting this 139 kind of information and therefore its DAG Metric Container [RFC6551] 140 field is used to append a Node State and Attribute (NSA) object. The 141 node's parent address set is stored as an optional TLV within the NSA 142 object. This specification defines the type value and structure for 143 the parent address set TLV. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 The draft uses the following Terminology: 153 Packet Replication and Elimination (PRE): A method which consists of 154 transmitting multiple copies of a packet using multi-path 155 forwarding over a multi-hop network and which consolidates 156 multiple received packet copies to control flooding. See 157 "Exploiting Packet Replication and Elimination in Complex Tracks 158 in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs] for more 159 details. 161 Parent Set (PS): Given a RPL node, the set of its neighbor nodes 162 which participate in the same RPL DODAG and which can potentially 163 take the role of the node's preferred parent. 165 Alternative Parent (AP): A RPL parent in the parent set of a node 166 which is used to forward a packet copy when replicating packets. 168 Alternative Parent (AP) Selection: The mechanism for choosing the 169 next hop node to forward a packet copy when replicating packets. 171 Preferred Grand Parent (PGP): The preferred parent of the preferred 172 parent of a node. 174 3. Common Ancestor AP Selection Policies 176 In the RPL protocol, each node maintains a list of potential parents. 177 For PRE, the Preferred Parent (PP) node is defined to be the same as 178 the RPL DODAG Preferred Parent node. Furthermore, to construct an 179 alternative path toward the root, in addition to the PP node, each 180 node in the network selects additional parent(s), called alternative 181 parent(s), from its Parent Set (PS). 183 There are multiple possible policies of selecting the AP node. This 184 section details three such possible policies. 186 All three policies defined perform AP selection based on common 187 ancestors, named Common Ancestor Strict, Common Ancestor Medium, and 188 Common Ancestor Relaxed, depending on how restrictive the selection 189 process is. A more restrictive policy will limit flooding but might 190 fail to select an appropriate AP, while a less restrictive one will 191 more often find an appropriate AP but might increase flooding. 193 All three policies apply their corresponding common ancestor 194 criterion to filter the list of candidate neighbours in the 195 alternative parent set. 197 3.1. Common Ancestor Strict 199 In the CA Strict OF the node will check if its Preferred Grand Parent 200 (PGP), the PP of its PP, is the same as the PP of the potential AP. 202 ( R ) root 203 . PS(S) = {A, B, C, D} 204 . PP(S) = C 205 . PP(PP(S)) = Y 206 . 207 PS(A) = {W, X} 208 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 209 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 210 | \ // | \ // || \ / || PS(B) = {W, X, Y} 211 | // | // || / || PP(B) = Y 212 | // \ | // \ || / \ || 213 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 214 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 215 ^ ^ ^^ ^ 216 \ \ || / PS(D) = {Y, Z} 217 \ \ || / PP(D) = Z 218 \ \ || / 219 \----\\ || / || Preferred Parent 220 ( S ) source | Potential Alternative Parent 222 Figure 1: Example Common Ancestor Strict Alternative Parent Selection 223 policy 225 For example, in Figure 1, the source node S must know its grandparent 226 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 227 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 228 of the figure. The CA Strict parent selection policy will select an 229 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 230 Y: 232 o Node A: PP(A) = X and therefore it is different than PP(PP(S)) 234 o Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 236 o Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 237 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 238 PP(B). 240 3.2. Common Ancestor Medium 242 In the CA Medium OF the node will check if its Preferred Grand Parent 243 (PGP), the PP of its PP, is contained in the PS of the potential AP. 245 Using the same example, in Figure 1, the CA Medium parent selection 246 policy will select an AP for node S for which PP(PP(S)) is in PS(AP). 247 Given that PP(PP(S)) = Y: 249 o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 251 o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 253 o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 255 node S can decide to use node B or D as its AP node. 257 3.3. Common Ancestor Relaxed 259 In the CA Relaxed OF the node will check if the Parent Set (PS) of 260 its Preferred Parent (PP) has a node in common with the PS of the 261 potential AP. 263 Using the same example, in Figure 1, the CA Relaxed parent selection 264 policy will select an AP for node S for which PS(PP(S)) has at least 265 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 267 o Node A: PS(A) = {W, X} and the common nodes are {X} 269 o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 271 o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 273 node S can decide to use node A, B or D as its AP node. 275 4. Common Ancestor Objective Function 277 An OF which allows the multiple paths to remain correlated is 278 detailed here. More specifically, when using this OF a node will 279 select an AP node close to its PP node to allow the operation of 280 overhearing between parents. For more details about overhearing and 281 its use in this context see Section 4.3. "Promiscuous Overhearing" 282 in "Exploiting Packet Replication and Elimination in Complex Tracks 283 in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs]. If multiple 284 potential APs match this condition, the AP with the lowest rank will 285 be registered. 287 The OF described here is an extension of the The Minimum Rank with 288 Hysteresis Objective Function [RFC6719] (MRHOF). In general, this OF 289 extends MRHOF by specifying how an AP is selected. Importantly, the 290 calculation of the rank of the node through each candidate neighbor 291 and the selection of the PP is kept the same as in MRHOF. 293 The ways in which the CA OF modifies MRHOF in a section-by-section 294 manner follows in detail: 296 MRHOF Section 3. "The Minimum Rank with Hysteresis Objective 297 Function": 298 Same as MRHOF extended to AP selection. Minimum Rank path 299 selection and switching applies correspondingly to the AP with the 300 extra CA requirement of having some match between ancestors. 302 MRHOF Section 3.1. "Computing the Path Cost": Same as MRHOF 303 extended to AP selection. If a candidate neighbor does not 304 fulfill the CA requirement then the path through that neighbor 305 SHOULD be set to MAX_PATH_COST, the same value used by MRHOF. As 306 a result, the node MUST NOT select the candidate neighbor as its 307 AP. 309 MRHOF Section 3.2. "Parent Selection": Same as MRHOF extended to AP 310 selection. To allow hysteresis, AP selection maintains a 311 variable, cur_ap_min_path_cost, which is the path cost of the 312 current AP. 314 MRHOF Section 3.2.1. "When Parent Selection Runs": Same as MRHOF. 316 MRHOF Section 3.2.2. "Parent Selection Algorithm": Same as MRHOF 317 extended to AP selection. If the smallest path cost for paths 318 through the candidate neighbors is smaller than 319 cur_ap_min_path_cost by less than PARENT_SWITCH_THRESHOLD (the 320 same variable as MRHOF uses), the node MAY continue to use the 321 current AP. Additionally, if there is no PP selected, there MUST 322 NOT be any AP selected as well. Finally, as with MRHOF, a node 323 MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors 324 in its alternative parent set. The value of PARENT_SET_SIZE is 325 the same as in MRHOF. 327 MRHOF Section 3.3. "Computing Rank": Same as MRHOF. 329 MRHOF Section 3.4. "Advertising the Path Cost": Same as MRHOF. 331 MRHOF Section 3.5. "Working without Metric Containers": 333 It is not possible to work without metric containers, since CA AP 334 selection requires information from parents regarding their parent 335 sets, which is transmitted via the NSA object in the DIO Mectric 336 Container. 338 MRHOF Section 4. "Using MRHOF for Metric Maximization": 339 Same as MRHOF. 341 MRHOF Section 5. "MRHOF Variables and Parameters": Same as MRHOF 342 extended to AP selection. The CA OF operates like MRHOF for AP 343 selection by maintaining separate: 345 AP: Corresponding to the MRHOF PP. Hysteresis is configured for 346 AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF. 347 The AP MUST NOT be the same as the PP. 349 Alternative parent set: Corresponding to the MRHOF parent set. 350 The size is defined by the same PARENT_SET_SIZE parameter as in 351 MRHOF. The Alternative parent set MUST be a non-strict subset 352 of the parent set. 354 cur_ap_min_path_cost: Corresponding to the MRHOF 355 cur_min_path_cost variable. To support the operation of the 356 hysteresis function for AP selection. 358 MRHOF Section 6. "Manageability": Same as MRHOF. 360 MRHOF Section 6.1. "Device Configuration": Same as MRHOF. 362 MRHOF Section 6.2. "Device Monitoring": Same as MRHOF. 364 4.1. Usage 366 All OF policies apply their corresponding criterion to filter the 367 list of candidate neighbours in the alternative parent set. The AP 368 is then selected from the alternative parent set based on Rank and 369 using hysteresis as is done for the PP in MRHOF. It is noteworthy 370 that the OF uses the same Objective Code Point (OCP): TBD1 for all 371 policies used. 373 The PS information can be used by any of the described AP selection 374 policies or other ones not described here, depending on requirements. 375 It is optional for all nodes to use the same AP selection policies. 376 Different nodes may use different AP selection policies, since the 377 selection policy is local to each node. For example, using different 378 policies can be used to vary the transmission reliability in each 379 hop. 381 5. Node State and Attribute (NSA) object type extension 383 In order to select their AP node, nodes need to be aware of their 384 grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG 385 Information Object (DIO) Control Message to broadcast information 386 about themselves to potential children. However, RPL [RFC6550], does 387 not define how to propagate parent set related information, which is 388 what this document addresses. 390 DIO messages can carry multiple options, out of which the DAG Metric 391 Container option [RFC6551] is the most suitable structurally and 392 semantically for the purpose of carrying the parent set. The DAG 393 Metric Container option itself can carry different nested objects, 394 out of which the Node State and Attribute (NSA) [RFC6551] is 395 appropriate for transferring generic node state data. Within the 396 Node State and Attribute it is possible to store optional TLVs 397 representing various node characteristics. As per the Node State and 398 Attribute (NSA) [RFC6551] description, no TLV has been defined for 399 use. This document defines one TLV for the purpose of transmitting a 400 node's parent set. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | RPLInstanceID |Version Number | Rank | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |G|0| MOP | Prf | DTSN | Flags | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 + + 411 | | 412 + DODAGID + 413 | | 414 + + 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | DAGMC Type (2)| DAGMC Length | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 419 | | 420 // DAG Metric Container data // 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 2: Example DIO Message with a DAG Metric Container option 426 Figure 2 shows the structure of the DIO Control Message when a DAG 427 Metric Container option is included. The DAG Metric Container option 428 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 429 registry for the RPL Control Message Options, and is defined in 430 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 431 Figure 2) expresses the DAG Metric Container length in bytes. DAG 432 Metric Container data holds the actual data and is shown expanded in 433 Figure 3. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Res | Flags |A|O| PS type | PS Length | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA 442 | PS IPv6 address(es) ... | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 3: DAG Metric Container (MC) data with Node State and 446 Attribute (NSA) object body and a TLV 448 The structure of the DAG Metric Container data in the form of a Node 449 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 450 field is shown in Figure 3. The first 32 bits comprise the DAG 451 Metric Container header and all the following bits are part of the 452 Node State and Attribute object body, as defined in [RFC6551]. This 453 document defines a new TLV, which CAN be carried in the Node State 454 and Attribute (NSA) object Optional TLVs field. The TLV is named 455 Parent Set and is abbreviated as PS in Figure 3. 457 PS type: The type of the Parent Set TLV. The value is TBD2. 459 PS Length: The total length of the TLV value field (PS IPv6 460 address(es)) in bytes. The length is an integral multiple of 461 16, the number of bytes in an IPv6 address. 463 PS IPv6 address(es) One or more 128-bit IPv6 address(es) without any 464 separator between them. The field consists of one IPv6 address 465 per parent in the parent set. The parent addresses are listed 466 in decreasing order of preference and not all parents in the 467 parent set need to be included. The selection of how many 468 parents from the parent set are to be included is left to the 469 implementation. The number of parent addresses in the PS IPv6 470 address(es) field can be deduced by dividing the length of the 471 PS IPv6 address(es) field in bytes by 16, the number of bytes 472 in an IPv6 address. 474 5.1. Usage 476 The PS SHOULD be used in the process of parent selection, and 477 especially in AP selection, since it can help the alternative path to 478 not significantly deviate from the preferred path. The Parent Set is 479 information local to the node that broadcasts it. 481 The PS is used only within NSA objects configured as a metric, 482 therefore the DAG Metric Container field "C" MUST be 0. 483 Additionally, since the information in the PS needs to be propagated 484 downstream but it cannot be aggregated, the DAG Metric Container 485 field "R" MUST be 1. Finally, since the information contained is by 486 definition partial, more specifically just the parent set of the DIO- 487 sending node, the DAG Metric Container field "P" MUST be 1. 489 It is important that the PS does not affect the calculation of the 490 rank through candidate neighbors. It is only used with the CA OF to 491 remove nodes which do not fulfill the CA OF criteria from the 492 candidate neighbor list. 494 6. Controlling PRE 496 PRE is very helpful when the aim is to increase reliability for a 497 certain path, however its use creates additional traffic as part of 498 the replication process. It is conceivable that not all paths have 499 stringent reliability requirements. Therefore, a way to control 500 whether PRE is applied to a path's packets SHOULD be implemented. 501 For example, a traffic class label can be used to determine this 502 behavior per flow type as described in Deterministic Networking 503 Architecture [RFC8655]. 505 7. Security Considerations 507 The structure of the DIO control message is extended, within the pre- 508 defined DIO options. The additional information are the IPv6 509 addresses of the parent set of the node transmitting the DIO. This 510 use of this additional information can have the following potential 511 consequences: 513 o A malicious node that can receive and read the DIO can "see" 514 further than it's own neighbourhood by one hop, learning the 515 addresses of it's two hop neighbors. This is a privacy / network 516 discovery issue. 518 o A malicious node that can send DIOs can use the parent set 519 extension to convince neighbours to route through itself, instead 520 of the normal preferred parent they would use. However, this is 521 already possible with other OFs (like OF0 [RFC6552] and MRHOF 523 [RFC6719]) by reporting a fake rank value in the DIO, thus 524 masquerading as the DODAG root. 526 8. IANA Considerations 528 This proposal requests the allocation of a new value TBD1 from the 529 "Objective Code Point (OCP)" sub-registry of the "Routing Protocol 530 for Low Power and Lossy Networks (RPL)" registry. 532 This proposal also requests the allocation of a new value TBD2 for 533 the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub- 534 registry from IANA. 536 9. References 538 9.1. Informative references 540 [I-D.ietf-6tisch-architecture] 541 Thubert, P., "An Architecture for IPv6 over the TSCH mode 542 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work 543 in progress), October 2019. 545 [I-D.papadopoulos-6tisch-pre-reqs] 546 Papadopoulos, G., Montavont, N., and P. Thubert, 547 "Exploiting Packet Replication and Elimination in Complex 548 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 549 reqs-02 (work in progress), July 2018. 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, 553 DOI 10.17487/RFC2119, March 1997, 554 . 556 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 557 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 558 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 559 Low-Power and Lossy Networks", RFC 6550, 560 DOI 10.17487/RFC6550, March 2012, 561 . 563 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 564 and D. Barthel, "Routing Metrics Used for Path Calculation 565 in Low-Power and Lossy Networks", RFC 6551, 566 DOI 10.17487/RFC6551, March 2012, 567 . 569 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 570 Protocol for Low-Power and Lossy Networks (RPL)", 571 RFC 6552, DOI 10.17487/RFC6552, March 2012, 572 . 574 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 575 Hysteresis Objective Function", RFC 6719, 576 DOI 10.17487/RFC6719, September 2012, 577 . 579 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 580 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 581 . 583 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 584 "Deterministic Networking Architecture", RFC 8655, 585 DOI 10.17487/RFC8655, October 2019, 586 . 588 9.2. Other Informative References 590 [IEEE802154] 591 IEEE standard for Information Technology, "IEEE Std 592 802.15.4 Standard for Low-Rate Wireless Personal Area 593 Networks (WPANs)", December 2015. 595 9.3. URIs 597 [1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll- 598 nsa-extension 600 [2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit 601 ;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138 603 Appendix A. Implementation Status 605 A research-stage implementation of the PRE mechanism using the 606 proposed extension as part of a 6TiSCH IOT use case was developed at 607 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 608 Koutsiamanis. It was implemented on the open-source Contiki OS and 609 tested with the Cooja simulator. The DIO DAGMC NSA extension is 610 implemented with a configurable number of parents from the parent set 611 of a node to be reported. 613 ( R ) 615 (11) (12) (13) (14) (15) (16) 617 (21) (22) (23) (24) (25) (26) 619 (31) (32) (33) (34) (35) (36) 621 (41) (42) (43) (44) (45) (46) 623 (51) (52) (53) (54) (55) (56) 625 ( S ) 627 Figure 4: Simulation Topology 629 The simulation setup is: 631 Topology: 32 nodes structured in regular grid as show in Figure 4. 632 Node S (source) is the only data packet sender, and send data to 633 node R (root). The parent set of each node (except R) is all the 634 nodes in the immediately higher row, the immediately above 6 635 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 636 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 637 14, 15, 16 have a single upwards link to R. 639 MAC: TSCH with 1 retransmission 641 Platform: Cooja 643 Schedule: Static, 2 timeslots per link from each node to each parent 644 in its parent set, 1 broadcast EB slot, 1 sender-based shared 645 timeslot (for DIO and DIS) per node (total of 32). 647 Simulation lifecycle: Allow link formation for 100 seconds before 648 starting to send data packets. Afterwards, S sends data packets 649 to R. The simulation terminates when 1000 packets have been sent 650 by S. 652 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 653 drawn for each link, with a uniform distribution spanning the 70% 654 to 100% interval. 656 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 657 seconds to R. 659 PS extension size: 3 parents. 661 Routing Methods: 663 * RPL: The default RPL non-PRE implementation in Contiki OS. 665 * 2nd ETX: PRE with a parent selection method which picks as AP 666 the 2nd best parent in the parent set based on ETX. 668 * CA Strict: As described in Section 3.1. 670 * CA Medium: As described in Section 3.2. 672 Simulation results: 674 +-----------+---------------+-----------------+---------------------+ 675 | Routing | Average | Average | Average | 676 | Method | Packet | Traversed | Duplications/packet | 677 | | Delivery Rate | Nodes/packet | (#) | 678 | | (%) | (#) | | 679 +-----------+---------------+-----------------+---------------------+ 680 | RPL | 82.70 | 5.56 | 7.02 | 681 | 2nd ETX | 99.38 | 14.43 | 31.29 | 682 | CA Strict | 97.32 | 9.86 | 18.23 | 683 | CA Medium | 99.66 | 13.75 | 28.86 | 684 +-----------+---------------+-----------------+---------------------+ 686 Links: 688 o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 689 extension branch) [1] 691 o Wireshark dissectors (for the optional PS TLV) - currently merged 692 / in master [2] 694 Appendix B. Choosing an AP selection policy 696 The manner of choosing an AP selection policy is left to the 697 implementation, for maximum flexibility. 699 For example, a different policy can be used per traffic type. The 700 network configurator can choose the CA Relaxed policy to increase 701 reliability (thus producing some flooding) for specific, extremely 702 important, alert packets. On the other hand, all normal data traffic 703 uses the CA Strict policy. Therefore, an exception is made just for 704 the alert packets. 706 Another option would be to devise a new disjoint policy, where the 707 paths are on purpose non-correlated, to increase path diversity and 708 resilience against whole groups of nodes failing. The disadvantage 709 may be increased jitter. 711 Finally, a network configurator may provide the CA policies with a 712 preference order of Strict > Medium > Relaxed as a means of falling 713 back to more flood-prone policies to maintain reliability. 715 Authors' Addresses 717 Remous-Aris Koutsiamanis (editor) 718 IMT Atlantique 719 Office B00 - 126A 720 2 Rue de la Chataigneraie 721 Cesson-Sevigne - Rennes 35510 722 FRANCE 724 Phone: +33 299 12 70 49 725 Email: aris@ariskou.com 727 Georgios Papadopoulos 728 IMT Atlantique 729 Office B00 - 114A 730 2 Rue de la Chataigneraie 731 Cesson-Sevigne - Rennes 35510 732 FRANCE 734 Phone: +33 299 12 70 04 735 Email: georgios.papadopoulos@imt-atlantique.fr 737 Nicolas Montavont 738 IMT Atlantique 739 Office B00 - 106A 740 2 Rue de la Chataigneraie 741 Cesson-Sevigne - Rennes 35510 742 FRANCE 744 Phone: +33 299 12 70 23 745 Email: nicolas.montavont@imt-atlantique.fr 746 Pascal Thubert 747 Cisco Systems, Inc 748 Building D 749 45 Allee des Ormes - BP1200 750 MOUGINS - Sophia Antipolis 06254 751 FRANCE 753 Phone: +33 497 23 26 34 754 Email: pthubert@cisco.com