idnits 2.17.00 (12 Aug 2021) /tmp/idnits16290/draft-papadopoulos-paw-pre-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1146 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 394, but not defined == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: draft-ietf-detnet-architecture has been published as RFC 8655 == Outdated reference: A later version (-10) exists of draft-ietf-roll-nsa-extension-01 Summary: 0 errors (**), 0 flaws (~~), 5 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 R. Koutsiamanis 4 Intended status: Standards Track N. Montavont 5 Expires: September 26, 2019 IMT Atlantique 6 P. Thubert 7 Cisco 8 March 25, 2019 10 Exploiting Packet Replication and Elimination in Complex Tracks in LLNs 11 draft-papadopoulos-paw-pre-reqs-01 13 Abstract 15 The Packet Replication and Elimination (PRE) mechanism duplicates 16 data packets into several paths in the network to increase 17 reliability and provide low jitter. Over a wireless medium, this 18 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 PRE. 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 September 26, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 Promiscuous Overhearing . . . . . 7 70 5.4. Requirements Related to Packet Elimination . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Informative references . . . . . . . . . . . . . . . . . 8 75 8.2. Other Informative References . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 any specific solution or 84 design for the PAW architecture or protocols. These are the subjects 85 of other PAW drafts. The PAW use cases are not considered to be 86 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 Some more details for Deterministic Network PRE techniques are 119 presented in the following Section. 121 4. Packet Replication and Elimination principles 123 In a nutshell, PRE establishes several paths in a network to provide 124 redundancy and parallel transmissions to bound the end-to-end delay 125 to traverse the network. Optionally, promiscuous listening between 126 paths is possible, such that the nodes on one path may overhear 127 transmissions along the other path. Considering the scenario shown 128 in Figure 1, many different paths are possible for S to reach R. A 129 simple way to benefit from this topology could be to use the two 130 independent paths via nodes A, C, E and via B, D, F. But more 131 complex paths are possible by interleaving transmissions from the 132 lower level of the path to the upper level. 134 PRE may also take advantage of the shared properties of the wireless 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 also 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 in a 140 dedicated transmission towards B. 142 (A) (C) (E) 144 source (S) (R) (root) 146 (B) (D) (F) 148 Figure 1: A Typical Ladder Shape with Two Parallel Paths Toward the 149 Destination 151 The PRE model can be implemented in both centralized and distributed 152 scheduling approaches. In the centralized approach, a Path 153 Computation Element (PCE) scheduler calculates the routes and 154 schedules the communication among the nodes along a circuit such as a 155 Label switched path. In the distributed approach, each node selects 156 its route to the destination, typically using a source routing 157 header. In both cases, at each node in the paths, a default parent 158 and alternative parent(s) should be selected to set up complex 159 tracks. 161 In the following Subsections, all the required operations defined by 162 PRE, namely, Alternative Path Selection, Packet Replication, Packet 163 Elimination and Promiscuous Overhearing, are described. 165 4.1. Packet Replication 167 The objective of PRE is to provide deterministic networking 168 properties: high reliability and bounded latency. To achieve this 169 goal, determinism in every hop of the forwarding paths MUST be 170 guaranteed. By employing a Packet Replication procedure, each node 171 forwards a copy of each data packet to multiple parents: its Default 172 Parent (DP) and multiple Alternative Parents (APs). To do so, each 173 node (i.e., source and intermediate node) transmits the data packet 174 multiple times in unicast to each parent. For instance, in Figure 2, 175 the source node S is transmitting the packet to both parents, nodes A 176 and B, in two different timeslots within the same TSCH slotframe. An 177 example TSCH schedule is shown in Figure 3. Thus, the packet 178 eventually obtains parallel paths to the destination. 180 ===> (A) => (C) => (E) === 181 // \\// \\// \\ 182 source (S) //\\ //\\ (R) (root) 183 \\ // \\ // \\ // 184 ===> (B) => (D) => (F) === 186 Figure 2: Packet Replication: S transmits twice the same data packet, 187 to its DP (A) and to its AP (B). 189 Timeslot 190 +---------++------+------+------+------+------+------+------+ 191 | Channel || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 192 +---------++======+======+======+======+======+======+======+ 193 | 0 || S->A | S->B | B->C | B->D | C->F | E->R | F->R | 194 +---------++------+------+------+------+------+------+------+ 195 | 1 || | A->C | A->D | C->E | D->E | D->F | | 196 +---------++------+------+------+------+------+------+------+ 198 Figure 3: Packet Replication: Sample TSCH schedule 200 4.2. Packet Elimination 202 The replication operation increases the traffic load in the network, 203 due to packet duplications. Thus, a Packet Elimination operation 204 SHOULD be applied at each RPL DODAG level to reduce the unnecessary 205 traffic. To this aim, once a node receives the first copy of a data 206 packet, it discards the subsequent copies. Because the first copy 207 that reaches a node is the one that matters, it is the only copy that 208 will be forwarded upward. Then, once a node performs the Packet 209 Elimination operation, it will proceed with the Packet Replication 210 operation to forward the packet toward the RPL DODAG Root. 212 4.3. Promiscuous Overhearing 214 Considering that the wireless medium is broadcast by nature, any 215 neighbor of a transmitter may overhear a transmission. By employing 216 the Promiscuous Overhearing operation, a DP and some AP(s) eventually 217 have more chances to receive the data packets. In Figure 4, when 218 node A is transmitting to its DP (node C), the AP (node D) and its 219 sibling (node B) may decode this data packet as well. As a result, 220 by employing corellated paths, a node may have multiple opportunities 221 to receive a given data packet. This feature not only enhances the 222 end-to-end reliability but also it reduces the end-to-end delay and 223 increases energy efficiency. 225 ===> (A) ====> (C) ====> (E) ==== 226 // ^ | \\ \\ 227 source (S) | | \\ (R) (root) 228 \\ | v \\ // 229 ===> (B) ====> (D) ====> (F) ==== 231 Figure 4: Unicast to DP with Overhearing: by employing Promiscuous 232 Overhearing, DP, AP and the sibling nodes have more opportunities to 233 receive the same data packet. 235 5. Requirements 237 5.1. Requirements Related to Alternative Parent Selection 239 To perform the Packet Replication procedure, it is necessary to 240 define the Alternative Parent(s) and, consequently, the path to the 241 destination node, for each node in the wireless network. An AP can 242 be selected in many different ways, and is dependent on the 243 implementation. 245 The requirements are: 247 Req1.1: The routing protocol SHOULD be extended to allow for each 248 node to select AP(s) in addition to the DP. This enables 249 packet replication to multiple parents. 251 Req1.2: Considering that the Packet Replication procedure 252 significantly increases the traffic in a network, when 253 proposing solutions for Alternative Parent Selection, they 254 should be efficient enough to mitigate the potential 255 uncontrolled packet duplications. 257 Req1.3: The topology SHOULD be defined when proposing solutions for 258 Alternative Parent Selection. For instance, the ladder 259 topology should be defined explicitly e.g., number of parallel 260 paths, density. 262 5.2. Requirements Related to Propagated Information 264 For Alternative Parent(s) selection, nodes MAY need additional 265 information about the network topology. This draft does not 266 prescribe the information required for AP selcetion or how it is to 267 be propagated to the nodes that need to select AP(s). TODO: To be 268 discussed. 270 The requirement is: 272 Req2.1: Nodes MUST have a way of receiving the required information 273 for efficient Alternative Parent Selection. 275 As an example, it is possible to use and extend the RPL [RFC6550] 276 DODAG Information Object (DIO) Control Message to allow nodes to 277 propagate information about themselves to potential children. For 278 instance, "RPL DAG Metric Container (MC) Node State and Attribute 279 (NSA) object type extension" [I-D.ietf-roll-nsa-extension] focuses on 280 extending the DAG Metric Container [RFC6551] by defining a new type- 281 length-value (TLV), entitled Parent Set (PS) which can be carried in 282 the Node State and Attribute (NSA) object. 284 5.3. Requirements Related to Promiscuous Overhearing 286 As stated previously, to further increase the network reliability and 287 to achieve deterministic packet deliveries at the destination node, 288 Promiscuous Overhearing can be considered. 290 As it is described in BCP 210 [RFC8180], in TSCH mode, the data 291 frames are transmitted in unicast mode and are acknowledged by the 292 receiving neighbor. To perform the promiscuous overhearing 293 procedure, there SHOULD be an option for the transmitted frames, 294 i.e., in unicast, to be overheard by the potential neighborhood node. 296 Destination address filtering is performed at the Medium Access 297 Control (MAC) layer. For example, according to IEEE std. 802.15.4 298 [IEEE802154-2015], a node receiving a packet with a destination 299 address different than its own and different to 0xFF discards the 300 packet. A change is needed to be able to receive packets whose 301 destination address is neither multicast nor the overhearing node's 302 MAC address. 304 The requirements are: 306 Req3.1: The MAC implementation MUST be able to disable MAC address 307 filtering to accept the overheard frame. 309 Req3.2: The 6top Protocol [RFC8480] specification MUST be extended 310 to indicate disabling MAC filtering in a receiving cell. This 311 can be achieved by reserving a bit in the 6P CellOptions Bitmap 312 (Section 6.2.6 [RFC8480]) for this purpose. 314 Req3.3: The overhearing node can be configured with the timeslot set 315 to shared reception, thus, there will be no acknowledgement 316 from it. However, there is the security issue that needs to be 317 considered. Since the overhearing case implies that it is not 318 possible to have per-pair keying, there MUST be a key that the 319 overhearing node will be aware of. Hence, the Minimal Security 320 Framework for 6TiSCH [I-D.ietf-6tisch-architecture] 321 specification should consider such a scenario. 323 5.4. Requirements Related to Packet Elimination 325 By employing Packet Replication, the wireless network is expected to 326 also perform Packet Elimination to restrict the number of the 327 duplicated packets, i.e., the unnecessary traffic. As per the 6TiSCH 328 Architecture [I-D.ietf-6tisch-architecture], 6TiSCH has no position 329 about how the sequence numbers would be tagged in the packet. 331 The requirement is: 333 Req4.1: To perform Packet Elimination the packet copies MUST contain 334 a sequence number which allows identifying the copies. 336 6. Security Considerations 338 TODO. 340 7. IANA Considerations 342 This document has no IANA considerations. 344 8. References 346 8.1. Informative references 348 [I-D.ietf-6tisch-architecture] 349 Thubert, P., "An Architecture for IPv6 over the TSCH mode 350 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 351 in progress), March 2019. 353 [I-D.ietf-detnet-architecture] 354 Finn, N., Thubert, P., Varga, B., and J. Farkas, 355 "Deterministic Networking Architecture", draft-ietf- 356 detnet-architecture-12 (work in progress), March 2019. 358 [I-D.ietf-roll-nsa-extension] 359 Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. 360 Thubert, "RPL DAG Metric Container Node State and 361 Attribute object type extension", draft-ietf-roll-nsa- 362 extension-01 (work in progress), March 2019. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 370 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 371 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 372 Low-Power and Lossy Networks", RFC 6550, 373 DOI 10.17487/RFC6550, March 2012, 374 . 376 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 377 and D. Barthel, "Routing Metrics Used for Path Calculation 378 in Low-Power and Lossy Networks", RFC 6551, 379 DOI 10.17487/RFC6551, March 2012, 380 . 382 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 383 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 384 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 385 May 2017, . 387 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 388 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 389 DOI 10.17487/RFC8480, November 2018, 390 . 392 8.2. Other Informative References 394 [IEEE802154-2015] 395 IEEE standard for Information Technology, "IEEE standard 396 for Information Technology, "IEEE Std 802.15.4-2015 397 Standard for Low-Rate Wireless Personal Area Networks 398 (WPANs)", December 2015". 400 Authors' Addresses 402 Georgios Papadopoulos (editor) 403 IMT Atlantique 404 Office B00 - 102A 405 2 Rue de la Chataigneraie 406 Cesson-Sevigne - Rennes 35510 407 FRANCE 409 Phone: +33 299 12 70 04 410 Email: georgios.papadopoulos@imt-atlantique.fr 411 Remous-Aris Koutsiamanis 412 IMT Atlantique 413 Office B00 - 126A 414 2 Rue de la Chataigneraie 415 Cesson-Sevigne - Rennes 35510 416 FRANCE 418 Phone: +33 299 12 70 49 419 Email: aris@ariskou.com 421 Nicolas Montavont 422 IMT Atlantique 423 Office B00 - 106A 424 2 Rue de la Chataigneraie 425 Cesson-Sevigne - Rennes 35510 426 FRANCE 428 Phone: +33 299 12 70 23 429 Email: nicolas.montavont@imt-atlantique.fr 431 Pascal Thubert 432 Cisco Systems, Inc 433 Building D 434 45 Allee des Ormes - BP1200 435 MOUGINS - Sophia Antipolis 06254 436 FRANCE 438 Phone: +33 497 23 26 34 439 Email: pthubert@cisco.com