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