idnits 2.17.1 draft-papadopoulos-6tisch-pre-reqs-02.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 26, 2018) is 2100 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154-2015' is mentioned on line 453, but not defined == Unused Reference: 'I-D.ietf-6tisch-minimal-security' is defined on line 412, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-06 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-06 == Outdated reference: A later version (-04) exists of draft-koutsiamanis-roll-nsa-extension-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH G. Papadopoulos, Ed. 3 Internet-Draft N. Montavont 4 Intended status: Informational IMT Atlantique 5 Expires: January 27, 2019 P. Thubert 6 Cisco 7 July 26, 2018 9 Exploiting Packet Replication and Elimination in Complex Tracks in 10 6TiSCH LLNs 11 draft-papadopoulos-6tisch-pre-reqs-02 13 Abstract 15 6TiSCH Packet Replication and Elimination mechanism consists in 16 duplicating data packets into several paths in the network to 17 increase reliability and provide low jitter. Over a wireless medium, 18 this technique can take advantage of communication overhearing, when 19 parallel transmissions over two adjacent paths are scheduled. This 20 document presents the concept and details the required changes to the 21 current specifications that will be necessary to enable this. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 27, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Tracks Overview . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 3 62 4. Packet Replication and Elimination principles . . . . . . . . 3 63 4.1. Packet Replication . . . . . . . . . . . . . . . . . . . 4 64 4.2. Packet Elimination . . . . . . . . . . . . . . . . . . . 5 65 4.3. Promiscuous Overhearing . . . . . . . . . . . . . . . . . 5 66 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Requirements Related to Alternative Parent Selection . . 6 68 5.2. Requirements Related to Propagated Information . . . . . 6 69 5.3. Requirements Related to Cell Reservation . . . . . . . . 7 70 5.4. Requirements Related to Cells without ACKs . . . . . . . 8 71 5.5. Requirements Related to Packet Elimination . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Informative references . . . . . . . . . . . . . . . . . 9 76 8.2. Other Informative References . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Some applications (such as Wireless Industrial IoT) require robust 82 communications framework that guarantees data packet delivery in a 83 given delay. For example, a periodic process may need to be repeated 84 identically every time. To reach this ambition, the network must not 85 only be reliable but also deterministic. 87 A deterministic network ensures that the transported data packet will 88 be carried out in a pre-defined and in a tight window of time, 89 whatever the quality of the wireless links and the network 90 congestion. The goal of such network is to exhibit ultra-low jitter 91 performance, i.e., close to 0. IEEE std. 802.15.4 [IEEE802154-2015] 92 has provision to provide guarantees for deterministic networks. 93 Time-Slotted Channel Hopping (TSCH) provides transmission schedule to 94 avoid random access to the medium and channel diversity to fight 95 interferences. However, TSCH is prone to retransmissions when the 96 actual transmission was unsuccessful, due to external interference or 97 potential collision and, consequently, it increases the end-to-end 98 delay performance. 100 This document is mainly motivated by the ongoing work in the 6TiSCH 101 working group. The architecture of a 6TiSCH network is detailed in 102 6TiSCH Architecture [I-D.ietf-6tisch-architecture] draft, which is 103 used for the remainder of this document. In this specification, we 104 focus on Complex Track with Replication and Elimination. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Tracks 114 3.1. Tracks Overview 116 The 6TiSCH architecture introduces the concept of Tracks in 6TiSCH 117 Architecture [I-D.ietf-6tisch-architecture]. A simple track is 118 composed of a sequence of cells (a combination of a transmitter, a 119 receiver and a given channel offset) to ensure the transmission of a 120 single packet from a source 6TiSCH node to a destination 6TiSCH node 121 across a 6TiSCH multihop path. 123 3.2. Complex Tracks 125 A Complex Track is designed as a directed acyclic graph from a source 126 6TiSCH node towards a destination 6TiSCH node to support multi-path 127 forwarding, as introduced in 6TiSCH Architecture 128 [I-D.ietf-6tisch-architecture]. By employing DetNet 129 [I-D.ietf-detnet-architecture] Packet Replication and Elimination 130 (PRE) functions, several paths may be computed, and these paths may 131 be more or less independent. For example, a complex Track may branch 132 off and rejoin over non-congruent paths (branches). 134 In the following Section, we will detail Deterministic Networks PRE 135 techniques. 137 4. Packet Replication and Elimination principles 139 In a nutshell, PRE consists in establishing several paths in a 140 network to provide redundancy and parallel transmissions to bound the 141 delay to traverse the network. Optionally, promiscuous listening 142 between paths is possible, such that the nodes on one path may 143 overhear transmissions along the other path. Considering the 144 scenario depicted in Figure 1, many different paths are possible for 145 S to reach R. A simple way to take benefit from this topology could 146 be to use the two independent paths via nodes A, C, E and via B, D, 147 F. But more complex paths are possible by interleaving transmissions 148 from one level of the path to the upper level. 150 The 6TiSCH PRE may also take advantage of the shared properties of 151 the medium to compensate for the potential loss that is incurred with 152 radio transmissions. For instance, when the source sends to A, B may 153 listen and get a second chance to receive the frame without an 154 additional transmission. Note that B would not have to listen if it 155 already received that particular frame at an earlier timeslot. 157 (A) (C) (E) 159 source (S) (R) (root) 161 (B) (D) (F) 163 Figure 1: A Typical Ladder Shape with Two Parallel Paths Toward the 164 Destination 166 PRE model can be implemented in both centralized and distributed 167 scheduling approach. In the centralized approach, a Path Computation 168 Element (PCE) scheduler calculates the routes and schedules the 169 communication among the nodes along a circuit such as a Label 170 switched path. In the distributed approach, each node selects its 171 route to the destination, typically using a source routing header. 172 In both cases, a default parent and alternate parent(s) should be 173 selected to set up complex tracks. 175 In the following Subsections, detailed description of all required 176 operations defined by PRE, namely, Alternative Path Selection, Packet 177 Replication, Packet Elimination and Promiscuous Overhearing, will be 178 described. 180 4.1. Packet Replication 182 The objective of PRE is to provide deterministic networking 183 properties, with high reliability and bounded latency. To achieve 184 this goal, determinism in every hop of the forwarding paths MUST be 185 guaranteed. By employing Packet Replication procedure, each node 186 transmits (i.e., replicates) each data packet to both its Default 187 Parent (DP) and Alternative Parent (AP). To do so, each node (i.e., 188 source and intermediate 6TiSCH nodes) transmits the data packet twice 189 in unicast to each parent. For instance, in Figure 2, the source 190 6TiSCH node S is transmitting the packet to both parents, nodes A and 191 B, in two different timeslots within the same TSCH slotframe. Thus, 192 the packet eventually obtains parallel paths to the destination. 194 ===> (A) => (C) => (E) === 195 // \\// \\// \\ 196 source (S) //\\ //\\ (R) (root) 197 \\ // \\ // \\ // 198 ===> (B) => (D) => (F) === 200 Figure 2: Packet Replication: S transmits twice the same data packet, 201 to its DP (A) and to its AP (B). 203 4.2. Packet Elimination 205 The replication operation increases the traffic load in the network, 206 due to packet duplications. Thus, Packet Elimination operation 207 should be applied at each RPL DODAG level to reduce the unnecessary 208 traffic. To this aim, once a node receives the first copy of a data 209 packet, it discards the following copies. Because the first copy 210 that reaches a node is the one that counts, it is the only copy that 211 will be forwarded upward. Then, once a node performed the Packet 212 Elimination operation, it will proceed with Packet Replication 213 operation to forward the packet toward the RPL DODAG Root. 215 4.3. Promiscuous Overhearing 217 Considering that the wireless medium is broadcast by nature, any 218 neighbor of a transmitter may overhear a transmission. By employing 219 the Promiscuous Overhearing operation, DP and AP eventually have more 220 chances to receive the data packets. In Figure 3, when node A is 221 transmitting to its DP (node C), the AP (node D) and its Sibling 222 (node B) may decode this data packet as well. As a result, by 223 employing correlated paths, a node may have multiple opportunities to 224 receive a given data packet. This feature not only enhances the end- 225 to-end reliability but also it reduces the end-to-end delay. 227 ===> (A) ====> (C) ====> (E) ==== 228 // ^ | \\ \\ 229 source (S) | | \\ (R) (root) 230 \\ | v \\ // 231 ===> (B) ====> (D) ====> (F) ==== 233 Figure 3: Unicast to DP with Overhearing: by employing Promiscuous 234 Overhearing, DP, AP and the Sibling nodes have more opportunities to 235 receive the same data packet. 237 5. Requirements 239 5.1. Requirements Related to Alternative Parent Selection 241 To perform the Replication procedure, it is necessary to define the 242 Alternative Parent(s) and, consequently, the path to the destination 243 6TiSCH node, for each node in the 6TiSCH network. An AP can be 244 selected in many different ways, and is dependent on the 245 implementation. 247 Related requirements are: 249 Req1.1: The routing protocol SHOULD be extended to allow for each 250 6TiSCH node to select AP(s) in addition to DP. Thus, packet 251 duplication (i.e., replication) to multiple parents could be 252 possible. 254 Req1.2: Considering that the Replication procedure significantly 255 increases the traffic in a network, when proposing solutions for 256 Alternative Parent Selection, it should be efficient enough to 257 mitigate the potential uncontrolled packet duplications. 259 Req1.3: The topology SHOULD be defined when proposing solutions for 260 Alternative Parent Selection. For instance, the ladder topology 261 should be defined explicitly e.g., number of parallel paths, density. 263 5.2. Requirements Related to Propagated Information 265 To select an Alternative Parent, 6TiSCH nodes MUST be aware of their 266 grandparent node sets. Thus, it is necessary nodes to propagate such 267 information to their neighbors. RPL [RFC6550] defines DODAG 268 Information Object (DIO) Control Message to allow nodes to propagate 269 information about themselves to potential children. In Figure 4, DIO 270 control message with a DAG Metric Container option is illustrated. 271 However, RPL [RFC6550], does not indicates how to propagate parent 272 set related information. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | RPLInstanceID |Version Number | Rank | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |G|0| MOP | Prf | DTSN | Flags | Reserved | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 + + 283 | | 284 + DODAGID + 285 | | 286 + + 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | DAGMC Type (2)| DAGMC Length | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 291 | | 292 // DAG Metric Container data // 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 4: Example DIO Message with a DAG Metric Container option 298 Related requirements are: 300 Req2.1: DIO control messages can include multiple options. DAG 301 Metric Container option [RFC6551] is structurally suitable for 302 transferring parent node set information. Therefore, to enable PRE, 303 nodes MUST broadcast their parent node set to their potential 304 children through the extended DIO control message. For instance, 305 "RPL DAG Metric Container (MC) Node State and Attribute (NSA) object 306 type extension" [I-D.koutsiamanis-roll-nsa-extension] focuses on 307 extending the DAG Metric Container [RFC6551] by defining new type- 308 length-value (TLV), entitled Parent Node Set (PNS) which CAN be 309 carried in the Node State and Attribute (NSA) object. 311 5.3. Requirements Related to Cell Reservation 313 As stated previously, to further increase the 6TiSCH network 314 reliability and to achieve deterministic packet deliveries at the 315 destination 6TiSCH node, Promiscuous Overhearing can be considered. 317 As it is described in BCP 210 [RFC8180], in TSCH mode, the data 318 frames are transmitted in unicast mode and are acknowledged by the 319 receiving neighbor. To perform the promiscuous overhearing 320 procedure, there SHOULD be an option for the transmitted frames, 321 i.e., in unicast, to be overheard by the potential neighborhood 322 6TiSCH node. 324 Related requirements are: 326 Req3.1: The destination address filtering is performed at the MAC 327 layer. According to IEEE std. 802.15.4 [IEEE802154-2015], a node 328 receiving a packet with a destination address different than its own 329 and different to 0xFF discards the packet. Thus, IEEE std. 802.15.4 330 implementation SHOULD bypass this filtering either by configuration 331 forcing to accept such the receiving frame or by using anycast/ 332 multicast address as destination. 334 Req3.2: The 6top Protocol [I-D.ietf-6tisch-6top-protocol] SHOULD be 335 extended to possibly allow a cell reservation with two receivers, 336 i.e., DP and AP. Considering that each frame may be transmitted 337 twice in unicast to each parent, then depending the transmission, 338 either DP will acknowledge the frame or AP will. 340 Req3.3: Next, to request the overhearing cells, the 6P ADD Request 341 Format SHOULD be transmitted either twice to each parent, i.e., DP 342 and AP, or once in multicast to both parents. This procedure SHOULD 343 be considered in 6top Protocol [I-D.ietf-6tisch-6top-protocol] 344 specification. 346 5.4. Requirements Related to Cells without ACKs 348 As stated in BCP 210 [RFC8180], each date frame is acknowledged by 349 the receiving 6TiSCH node. However, by employing promiscuous 350 overhearing operation, particular attention should be given to who 351 will acknowledge a transmission, i.e., the DP, and / or one of the 352 AP(s) 354 Related requirements are: 356 Req4.1: To avoid the ACK collision, the TSCH Schedule as per BCP 210 357 [RFC8180], only the destination node of a packet MUST acknowledge the 358 data packet. 360 Req4.2: The overhearing node can be configured with the timeslot set 361 to shared, thus, there will be no acknowledgement from it. However, 362 there is the security issue that needs to be considered. Since, the 363 overhearing case imply that it is not possible to have per-pair 364 keying, thus, there MUST be a key that the overhearing node will be 365 aware of. Hence, Minimal Security Framework for 6TiSCH 366 [I-D.ietf-6tisch-architecture] specification should consider such 367 scenario. 369 Req4.3: Optionally, to achieve further consistency the overheard 370 transmission need be acknowledged by both parents, i.e., DP and AP. 371 To do so, MAC layer operation MUST be extended accordingly. 373 5.5. Requirements Related to Packet Elimination 375 By employing packet replication operation, the 6TiSCH network expects 376 to perform the packet elimination operation along a complex Track to 377 bound the number of the duplicated packets, i.e., the unnecessary 378 traffic. 380 Related requirements are: 382 Req5.1: As per 6TiSCH Architecture [I-D.ietf-6tisch-architecture], 383 6TiSCH has no position about how the sequence numbers would be tagged 384 in the packet. However, it comes with Tagging Packets for Flow 385 Identification. More specifically, a 6TiSCH network expects that 386 timeslots corresponding to copies of a same frame along a complex 387 Track are correlated by configuration and, thus, does not need to 388 process the sequence numbers. 390 6. Security Considerations 392 TODO. 394 7. IANA Considerations 396 This document has no IANA considerations. 398 8. References 400 8.1. Informative references 402 [I-D.ietf-6tisch-6top-protocol] 403 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 404 Operation Sublayer Protocol (6P)", draft-ietf-6tisch-6top- 405 protocol-12 (work in progress), June 2018. 407 [I-D.ietf-6tisch-architecture] 408 Thubert, P., "An Architecture for IPv6 over the TSCH mode 409 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 410 in progress), April 2018. 412 [I-D.ietf-6tisch-minimal-security] 413 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 414 "Minimal Security Framework for 6TiSCH", draft-ietf- 415 6tisch-minimal-security-06 (work in progress), May 2018. 417 [I-D.ietf-detnet-architecture] 418 Finn, N., Thubert, P., Varga, B., and J. Farkas, 419 "Deterministic Networking Architecture", draft-ietf- 420 detnet-architecture-06 (work in progress), June 2018. 422 [I-D.koutsiamanis-roll-nsa-extension] 423 Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. 424 Thubert, "RPL DAG Metric Container Node State and 425 Attribute object type extension", draft-koutsiamanis-roll- 426 nsa-extension-02 (work in progress), July 2018. 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 434 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 435 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 436 Low-Power and Lossy Networks", RFC 6550, 437 DOI 10.17487/RFC6550, March 2012, 438 . 440 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 441 and D. Barthel, "Routing Metrics Used for Path Calculation 442 in Low-Power and Lossy Networks", RFC 6551, 443 DOI 10.17487/RFC6551, March 2012, 444 . 446 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 447 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 448 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 449 May 2017, . 451 8.2. Other Informative References 453 [IEEE802154-2015] 454 IEEE standard for Information Technology, "IEEE standard 455 for Information Technology, "IEEE Std 802.15.4-2015 456 Standard for Low-Rate Wireless Personal Area Networks 457 (WPANs)", December 2015". 459 Authors' Addresses 460 Georgios Papadopoulos (editor) 461 IMT Atlantique 462 Office B00 - 102A 463 2 Rue de la Chataigneraie 464 Cesson-Sevigne - Rennes 35510 465 FRANCE 467 Phone: +33 299 12 70 04 468 Email: georgios.papadopoulos@imt-atlantique.fr 470 Nicolas Montavont 471 IMT Atlantique 472 Office B00 - 106A 473 2 Rue de la Chataigneraie 474 Cesson-Sevigne - Rennes 35510 475 FRANCE 477 Phone: +33 299 12 70 23 478 Email: nicolas.montavont@imt-atlantique.fr 480 Pascal Thubert 481 Cisco Systems, Inc 482 Building D 483 45 Allee des Ormes - BP1200 484 MOUGINS - Sophia Antipolis 06254 485 FRANCE 487 Phone: +33 497 23 26 34 488 Email: pthubert@cisco.com