idnits 2.17.1 draft-ietf-roll-nsa-extension-04.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 (July 8, 2019) is 1753 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 514, but not defined -- Looks like a reference, but probably isn't: '1' on line 615 -- Looks like a reference, but probably isn't: '2' on line 618 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-24 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: January 9, 2020 IMT Atlantique 6 P. Thubert 7 Cisco 8 July 8, 2019 10 Common Ancestor Objective Functions and Parent Set DAG Metric Container 11 Extension 12 draft-ietf-roll-nsa-extension-04 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 January 9, 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 new 128 Objective Code Points (OCPs) 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. The 184 selection of the PP is kept the same as in MRHOF. 186 The ways in which the CA OFs modify MRHOF in a section-by-section 187 manner follows: 189 3. The Minimum Rank with Hysteresis Objective Function: Same as 190 MRHOF extended to AP selection. Minimum Rank path selection and 191 switching applies correspondingly to the AP with the extra CA 192 requirement of having some match between ancestors, depending on 193 the specific variant of CA OF used. 195 3.1. Computing the Path Cost: Same as MRHOF extended to AP 196 selection. If a candidate neighbor does not fulfill the CA 197 requirement then the path through that neighbor SHOULD be set to 198 MAX_PATH_COST. As a result, the node MUST NOT select the 199 candidate neighbor as its AP. 201 3.2. Parent Selection: Same as MRHOF extended to AP selection. To 202 allow hysteresis, AP selection maintains a variable, 203 cur_ap_min_path_cost, which is the path cost of the current AP. 205 3.2.1. When Parent Selection Runs: Same as MRHOF. 207 3.2.2. Parent Selection Algorithm: Same as MRHOF extended to AP 208 selection. If the smallest path cost for paths through the 209 candidate neighbors is smaller than cur_ap_min_path_cost by less 210 than PARENT_SWITCH_THRESHOLD, the node MAY continue to use the 211 current AP. Additionally, if there is no PP selected, there MUST 212 NOT be any AP selected as well. Finally, as with MRHOF, a node 213 MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors 214 in its alternative parent set. 216 3.3. Computing Rank: Same as MRHOF. 218 3.4. Advertising the Path Cost: Same as MRHOF. 220 3.5. Working without Metric Containers: It is not possible to work 221 without metric containers, since CA AP selection requires 222 information from parents regarding their parent sets, which is 223 transmitted via the NSA object in the DIO Mectric Container. 225 4. Using MRHOF for Metric Maximization: Same as MRHOF. 227 5. MRHOF Variables and Parameters: Same as MRHOF extended to AP 228 selection. The CA OFs operate like MRHOF for AP selection by 229 maintaining separate: 231 AP: Corresponding to the MRHOF PP. Hysteresis is configured for 232 AP with the same PARENT_SWITCH_THRESHOLD parameter as in MRHOF. 233 The AP MUST NOT be the same as the PP. 235 Alternative parent set: Corresponding to the MRHOF parent set. 236 The size is defined by the same PARENT_SET_SIZE parameter as in 237 MRHOF. The Alternative parent set MUST be a non-strict subset 238 of the parent set. 240 cur_ap_min_path_cost: Corresponding to the MRHOF 241 cur_min_path_cost variable. To support the operation of the 242 hysteresis function for AP selection. 244 6. Manageability: Same as MRHOF. 246 6.1. Device Configuration: Same as MRHOF. 248 6.2. Device Monitoring: Same as MRHOF. 250 Three OFs are defined which perform AP selection based on common 251 ancestors, named Common Ancestor Strict, Common Ancestor Medium, and 252 Common Ancestor Relaxed, depending on how restrictive the selection 253 process is. A more restrictive method will limit flooding but might 254 fail to select an appropriate AP, while a less restrictive one will 255 more often find an appropriate AP but might increase flooding. 257 All three OFs apply their corresponding common ancestor criterion to 258 filter the list of candidate neighbours in the alternative parent 259 set. The AP is then selected from the alternative parent set based 260 on Rank and using hysteresis as is done for the PP in MRHOF. 262 3.1. Common Ancestor Strict 264 In the CA Strict OF, represented with Objective Code Point (OCP) 265 TBD1, the node will check if its Preferred Grand Parent (PGP), the PP 266 of its PP, is the same as the PP of the potential AP. 268 ( R ) root 269 . PS(S) = {A, B, C, D} 270 . PP(S) = C 271 . PP(PP(S)) = Y 272 . 273 PS(A) = {W, X} 274 ( W ) ( X ) ( Y ) ( Z ) PP(A) = X 275 ^ ^ ^^ ^ ^ ^^^^ ^ ^ ^^ 276 | \ // | \ // || \ / || PS(B) = {W, X, Y} 277 | // | // || / || PP(B) = Y 278 | // \ | // \ || / \ || 279 | // \ | // \ || / \ || PS(C) = {X, Y, Z} 280 ( A ) ( B ) ( C ) ( D ) PP(C) = Y 281 ^ ^ ^^ ^ 282 \ \ || / PS(D) = {Y, Z} 283 \ \ || / PP(D) = Z 284 \ \ || / 285 \----\\ || / || Preferred Parent 286 ( S ) source | Potential Alternative Parent 288 Figure 1: Example Common Ancestor Strict Alternative Parent Selection 289 method 291 For example, in Figure 1, the source node S must know its grandparent 292 sets through nodes A, B, C, and D. The Parent Sets (PS) and the 293 Preferred Parents (PS) of nodes A, B, C, and D are shown on the side 294 of the figure. The CA Strict parent selection method will select an 295 AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = 296 Y: 298 o Node A: PP(A) = X and therefore it is different than PP(PP(S)) 300 o Node B: PS(B) = Y and therefore it is equal to PP(PP(S)) 302 o Node D: PS(D) = Z and therefore it is different than PP(PP(S)) 304 node S can decide to use node B as its AP node, since PP(PP(S)) = Y = 305 PP(B). 307 3.2. Common Ancestor Medium 309 In the CA Medium OF, represented with Objective Code Point (OCP) 310 TBD2, the node will check if its Preferred Grand Parent (PGP), the PP 311 of its PP, is contained in the PS of the potential AP. 313 Using the same example, in Figure 1, the CA Medium parent selection 314 method will select an AP for node S for which PP(PP(S)) is in PS(AP). 315 Given that PP(PP(S)) = Y: 317 o Node A: PS(A) = {W, X} and therefore PP(PP(S)) is not in the set 319 o Node B: PS(B) = {W, X, Y} and therefore PP(PP(S)) is in the set 321 o Node D: PS(D) = {Y, Z} and therefore PP(PP(S)) is in the set 323 node S can decide to use node B or D as its AP node. 325 3.3. Common Ancestor Relaxed 327 In the CA Relaxed OF, represented with Objective Code Point (OCP) 328 TBD3, the node will check if the Parent Set (PS) of its Preferred 329 Parent (PP) has a node in common with the PS of the potential AP. 331 Using the same example, in Figure 1, the CA Relaxed parent selection 332 method will select an AP for node S for which PS(PP(S)) has at least 333 one node in common with PS(AP). Given that PS(PP(S)) = {X, Y, Z}: 335 o Node A: PS(A) = {W, X} and the common nodes are {X} 337 o Node B: PS(B) = {W, X, Y} and the common nodes are {X, Y} 339 o Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} 341 node S can decide to use node A, B or D as its AP node. 343 3.4. Usage 345 The PS information can be used by any of the described AP selection 346 methods or other ones not described here, depending on requirements. 347 It is optional for all nodes to use the same AP selection method. 348 Different nodes may use different AP selection methods, since the 349 selection method is local to each node. For example, using different 350 methods can be used to vary the transmission reliability in each hop. 352 4. Node State and Attribute (NSA) object type extension 354 In order to select their AP node, nodes need to be aware of their 355 grandparent node sets. Within RPL [RFC6550], the nodes use the DODAG 356 Information Object (DIO) Control Message to broadcast information 357 about themselves to potential children. However, RPL [RFC6550], does 358 not define how to propagate parent set related information, which is 359 what this document addresses. 361 DIO messages can carry multiple options, out of which the DAG Metric 362 Container option [RFC6551] is the most suitable structurally and 363 semantically for the purpose of carrying the parent set. The DAG 364 Metric Container option itself can carry different nested objects, 365 out of which the Node State and Attribute (NSA) [RFC6551] is 366 appropriate for transferring generic node state data. Within the 367 Node State and Attribute it is possible to store optional TLVs 368 representing various node characteristics. As per the Node State and 369 Attribute (NSA) [RFC6551] description, no TLV has been defined for 370 use. This document defines one TLV for the purpose of transmitting a 371 node's parent set. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | RPLInstanceID |Version Number | Rank | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |G|0| MOP | Prf | DTSN | Flags | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 + + 382 | | 383 + DODAGID + 384 | | 385 + + 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | DAGMC Type (2)| DAGMC Length | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 390 | | 391 // DAG Metric Container data // 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 2: Example DIO Message with a DAG Metric Container option 397 Figure 2 shows the structure of the DIO Control Message when a DAG 398 Metric Container option is included. The DAG Metric Container option 399 type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA 400 registry for the RPL Control Message Options, and is defined in 401 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 402 Figure 2) expresses the DAG Metric Container length in bytes. DAG 403 Metric Container data holds the actual data and is shown expanded in 404 Figure 3. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Res | Flags |A|O| PS type | PS Length | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA 413 | PS IPv6 address(es) ... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 3: DAG Metric Container (MC) data with Node State and 417 Attribute (NSA) object body and a TLV 419 The structure of the DAG Metric Container data in the form of a Node 420 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 421 field is shown in Figure 3. The first 32 bits comprise the DAG 422 Metric Container header and all the following bits are part of the 423 Node State and Attribute object body, as defined in [RFC6551]. This 424 document defines a new TLV, which CAN be carried in the Node State 425 and Attribute (NSA) object Optional TLVs field. The TLV is named 426 Parent Set and is abbreviated as PS in Figure 3. 428 PS type: The type of the Parent Set TLV. The value is TBD4. 430 PS Length: The total length of the TLV value field (PS IPv6 431 address(es)) in bytes. 433 4.1. Usage 435 The PS SHOULD be used in the process of parent selection, and 436 especially in AP selection, since it can help the alternative path to 437 not significantly deviate from the preferred path. The Parent Set is 438 information local to the node that broadcasts it. 440 The PS is used only within NSA objects configured as constraints and 441 is used as per [RFC6551]. 443 5. Controlling PRE 445 PRE is very helpful when the aim is to increase reliability for a 446 certain path, however its use creates additional traffic as part of 447 the replication process. It is conceivable that not all paths have 448 stringent reliability requirements. Therefore, a way to control 449 whether PRE is applied to a path's packets SHOULD be implemented. 450 For example, a traffic class label can be used to determine this 451 behavior per flow type as described in Deterministic Networking 452 Architecture [I-D.ietf-detnet-architecture]. 454 6. Security Considerations 456 The structure of the DIO control message is extended, within the pre- 457 defined DIO options. Therefore, the security mechanisms defined in 458 RPL [RFC6550] apply to this proposed extension. 460 7. IANA Considerations 462 This proposal requests the allocation of new values TBD1, TBD2, TBD3 463 from the "Objective Code Point (OCP)" sub-registry of the "Routing 464 Protocol for Low Power and Lossy Networks (RPL)" registry. This 465 proposal also requests the allocation of a new value TBD4 for the 466 "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-registry 467 from IANA. 469 8. References 471 8.1. Informative references 473 [I-D.ietf-6tisch-architecture] 474 Thubert, P., "An Architecture for IPv6 over the TSCH mode 475 of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work 476 in progress), July 2019. 478 [I-D.ietf-detnet-architecture] 479 Finn, N., Thubert, P., Varga, B., and J. Farkas, 480 "Deterministic Networking Architecture", draft-ietf- 481 detnet-architecture-13 (work in progress), May 2019. 483 [I-D.papadopoulos-6tisch-pre-reqs] 484 Papadopoulos, G., Montavont, N., and P. Thubert, 485 "Exploiting Packet Replication and Elimination in Complex 486 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 487 reqs-02 (work in progress), July 2018. 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 495 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 496 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 497 Low-Power and Lossy Networks", RFC 6550, 498 DOI 10.17487/RFC6550, March 2012, 499 . 501 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 502 and D. Barthel, "Routing Metrics Used for Path Calculation 503 in Low-Power and Lossy Networks", RFC 6551, 504 DOI 10.17487/RFC6551, March 2012, 505 . 507 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 508 Hysteresis Objective Function", RFC 6719, 509 DOI 10.17487/RFC6719, September 2012, 510 . 512 8.2. Other Informative References 514 [IEEE802154] 515 IEEE standard for Information Technology, "IEEE Std 516 802.15.4 Standard for Low-Rate Wireless Personal Area 517 Networks (WPANs)", December 2015. 519 8.3. URIs 521 [1] https://github.com/ariskou/contiki/tree/draft-koutsiamanis-roll- 522 nsa-extension 524 [2] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit 525 ;h=e2f6ba229f45d8ccae2a6405e0ef41f1e61da138 527 Appendix A. Implementation Status 529 A research-stage implementation of the PRE mechanism using the 530 proposed extension as part of a 6TiSCH IOT use case was developed at 531 IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris 532 Koutsiamanis. It was implemented on the open-source Contiki OS and 533 tested with the Cooja simulator. The DIO DAGMC NSA extension is 534 implemented with a configurable number of parents from the parent set 535 of a node to be reported. 537 ( R ) 539 (11) (12) (13) (14) (15) (16) 541 (21) (22) (23) (24) (25) (26) 543 (31) (32) (33) (34) (35) (36) 545 (41) (42) (43) (44) (45) (46) 547 (51) (52) (53) (54) (55) (56) 549 ( S ) 551 Figure 4: Simulation Topology 553 The simulation setup is: 555 Topology: 32 nodes structured in regular grid as show in Figure 4. 556 Node S (source) is the only data packet sender, and send data to 557 node R (root). The parent set of each node (except R) is all the 558 nodes in the immediately higher row, the immediately above 6 559 nodes. For example, each node in {51, 52, 53, 54, 55, 56} is 560 connected to all of {41, 42, 43, 44, 45, 46}. Node 11, 12, 13, 561 14, 15, 16 have a single upwards link to R. 563 MAC: TSCH with 1 retransmission 565 Platform: Cooja 567 Schedule: Static, 2 timeslots per link from each node to each parent 568 in its parent set, 1 broadcast EB slot, 1 sender-based shared 569 timeslot (for DIO and DIS) per node (total of 32). 571 Simulation lifecycle: Allow link formation for 100 seconds before 572 starting to send data packets. Afterwards, S sends data packets 573 to R. The simulation terminates when 1000 packets have been sent 574 by S. 576 Radio Links: Every 60 s, a new Packet Delivery Rate is randomly 577 drawn for each link, with a uniform distribution spanning the 70% 578 to 100% interval. 580 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 581 seconds to R. 583 PS extension size: 3 parents. 585 Routing Methods: 587 * RPL: The default RPL non-PRE implementation in Contiki OS. 589 * 2nd ETX: PRE with a parent selection method which picks as AP 590 the 2nd best parent in the parent set based on ETX. 592 * CA Strict: As described in Section 3.1. 594 * CA Medium: As described in Section 3.2. 596 Simulation results: 598 +----------+---------------+------------------+---------------------+ 599 | Routing | Average | Average | Average | 600 | Method | Packet | Traversed | Duplications/packet | 601 | | Delivery Rate | Nodes/packet (#) | (#) | 602 | | (%) | | | 603 +----------+---------------+------------------+---------------------+ 604 | RPL | 82.70 | 5.56 | 7.02 | 605 | 2nd ETX | 99.38 | 14.43 | 31.29 | 606 | CA | 97.32 | 9.86 | 18.23 | 607 | Strict | | | | 608 | CA | 99.66 | 13.75 | 28.86 | 609 | Medium | | | | 610 +----------+---------------+------------------+---------------------+ 612 Links: 614 o Contiki OS DIO DAGMC NSA extension (draft-koutsiamanis-roll-nsa- 615 extension branch) [1] 617 o Wireshark dissectors (for the optional PS TLV) - currently merged 618 / in master [2] 620 Authors' Addresses 621 Remous-Aris Koutsiamanis (editor) 622 IMT Atlantique 623 Office B00 - 126A 624 2 Rue de la Chataigneraie 625 Cesson-Sevigne - Rennes 35510 626 FRANCE 628 Phone: +33 299 12 70 49 629 Email: aris@ariskou.com 631 Georgios Papadopoulos 632 IMT Atlantique 633 Office B00 - 114A 634 2 Rue de la Chataigneraie 635 Cesson-Sevigne - Rennes 35510 636 FRANCE 638 Phone: +33 299 12 70 04 639 Email: georgios.papadopoulos@imt-atlantique.fr 641 Nicolas Montavont 642 IMT Atlantique 643 Office B00 - 106A 644 2 Rue de la Chataigneraie 645 Cesson-Sevigne - Rennes 35510 646 FRANCE 648 Phone: +33 299 12 70 23 649 Email: nicolas.montavont@imt-atlantique.fr 651 Pascal Thubert 652 Cisco Systems, Inc 653 Building D 654 45 Allee des Ormes - BP1200 655 MOUGINS - Sophia Antipolis 06254 656 FRANCE 658 Phone: +33 497 23 26 34 659 Email: pthubert@cisco.com