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