idnits 2.17.1 draft-papadopoulos-raw-pareo-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 (December 22, 2019) is 1586 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 416, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 == Outdated reference: A later version (-12) exists of draft-ietf-roll-nsa-extension-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW G. Papadopoulos, Ed. 3 Internet-Draft R. Koutsiamanis 4 Intended status: Standards Track N. Montavont 5 Expires: June 24, 2020 IMT Atlantique 6 P. Thubert 7 Cisco 8 December 22, 2019 10 Exploiting Packet Replication and Elimination in Complex Tracks in LLNs 11 draft-papadopoulos-raw-pareo-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. PRE may be used to complement 18 layer-2 Automatic Repeat reQuest (ARQ) and receiver-end Ordering to 19 form the PAREO functions. Over a wireless medium, this technique can 20 take advantage of communication Overhearing, when parallel 21 transmissions over two adjacent paths are scheduled. This document 22 presents the concept and details the required changes to the current 23 specifications that will be necessary to enable the PAREO functions. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 24, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Tracks Overview . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 3 64 4. Packet Replication and Elimination principles . . . . . . . . 3 65 4.1. Packet Replication . . . . . . . . . . . . . . . . . . . 4 66 4.2. Packet Elimination . . . . . . . . . . . . . . . . . . . 5 67 4.3. Promiscuous Overhearing . . . . . . . . . . . . . . . . . 5 68 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Requirements Related to Alternative Parent Selection . . 6 70 5.2. Requirements Related to Propagated Information . . . . . 6 71 5.3. Requirements Related to Promiscuous Overhearing . . . . . 7 72 5.4. Requirements Related to Packet Elimination . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Informative references . . . . . . . . . . . . . . . . . 8 77 8.2. Other Informative References . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 This draft describes industrial use cases which require deterministic 83 flows over wireless multi-hop paths. 85 The RAW use cases explicitly do not propose any specific solution or 86 design for the RAW architecture or protocols. These are the subjects 87 of other RAW drafts. The RAW use cases are not considered to be 88 concrete requirements by the RAW Working Group. 90 The industrial use cases covered in this draft are professional 91 audio, wireless for industrial applications and amusement parks. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Tracks 101 3.1. Tracks Overview 103 The 6TiSCH architecture introduces the concept of Tracks in 6TiSCH 104 Architecture [I-D.ietf-6tisch-architecture]. A simple track is 105 composed of a sequence of cells (a combination of a transmitter, a 106 receiver and a given channel offset) to ensure the transmission of a 107 single packet from a source node to a destination node across a 108 multihop path. 110 3.2. Complex Tracks 112 A Complex Track is designed as a directed acyclic graph from a source 113 node towards a destination node to support multi-path forwarding, as 114 introduced in 6TiSCH Architecture [I-D.ietf-6tisch-architecture]. By 115 employing DetNet [I-D.ietf-detnet-architecture] Packet Replication 116 and Elimination (PRE) functions, several paths may be computed, and 117 these paths may be more or less independent. For example, a complex 118 Track may branch off and rejoin over non-congruent paths (branches). 120 Some more details for Deterministic Network PRE techniques are 121 presented in the following Section. 123 4. Packet Replication and Elimination principles 125 In a nutshell, PRE establishes several paths in a network to provide 126 redundancy and parallel transmissions to bound the end-to-end delay 127 to traverse the network. Optionally, promiscuous listening between 128 paths is possible, such that the nodes on one path may overhear 129 transmissions along the other path. Considering the scenario shown 130 in Figure 1, many different paths are possible for S to reach R. A 131 simple way to benefit from this topology could be to use the two 132 independent paths via nodes A, C, E and via B, D, F. But more 133 complex paths are possible by interleaving transmissions from the 134 lower level of the path to the upper level. 136 PRE may also take advantage of the shared properties of the wireless 137 medium to compensate for the potential loss that is incurred with 138 radio transmissions. For instance, when the source sends to A, B may 139 listen also and get a second chance to receive the frame without an 140 additional transmission. Note that B would not have to listen if it 141 already received that particular frame at an earlier timeslot in a 142 dedicated transmission towards B. 144 (A) (C) (E) 146 source (S) (R) (root) 148 (B) (D) (F) 150 Figure 1: A Typical Ladder Shape with Two Parallel Paths Toward the 151 Destination 153 The PRE model can be implemented in both centralized and distributed 154 scheduling approaches. In the centralized approach, a Path 155 Computation Element (PCE) scheduler calculates the routes and 156 schedules the communication among the nodes along a circuit such as a 157 Label switched path. In the distributed approach, each node selects 158 its route to the destination, typically using a source routing 159 header. 161 In both cases, at each node in the paths, a default parent and 162 alternative parent(s) should be selected to set up complex tracks. 164 In the following Subsections, all the required operations defined by 165 PRE, namely, Alternative Path Selection, Packet Replication, Packet 166 Elimination and Promiscuous Overhearing, are described. 168 4.1. Packet Replication 170 The objective of PRE is to provide deterministic networking 171 properties: high reliability and bounded latency. To achieve this 172 goal, determinism in every hop of the forwarding paths MUST be 173 guaranteed. 175 By employing a Packet Replication procedure, each node forwards a 176 copy of each data packet to multiple parents: its Default Parent (DP) 177 and multiple Alternative Parents (APs). To do so, each node (i.e., 178 source and intermediate node) transmits the data packet multiple 179 times in unicast to each parent. For instance, in Figure 2, the 180 source node S is transmitting the packet to both parents, nodes A and 181 B, in two different timeslots within the same TSCH slotframe. An 182 example TSCH schedule is shown in Figure 3. Thus, the packet 183 eventually obtains parallel paths to the destination. 185 ===> (A) => (C) => (E) === 186 // \\// \\// \\ 187 source (S) //\\ //\\ (R) (root) 188 \\ // \\ // \\ // 189 ===> (B) => (D) => (F) === 191 Figure 2: Packet Replication: S transmits twice the same data packet, 192 to its DP (A) and to its AP (B). 194 Timeslot 195 +---------++------+------+------+------+------+------+------+ 196 | Channel || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 197 +---------++======+======+======+======+======+======+======+ 198 | 0 || S->A | S->B | B->C | B->D | C->F | E->R | F->R | 199 +---------++------+------+------+------+------+------+------+ 200 | 1 || | A->C | A->D | C->E | D->E | D->F | | 201 +---------++------+------+------+------+------+------+------+ 203 Figure 3: Packet Replication: Sample TSCH schedule 205 4.2. Packet Elimination 207 The replication operation increases the traffic load in the network, 208 due to packet duplications. Thus, a Packet Elimination operation 209 SHOULD be applied at each RPL DODAG level to reduce the unnecessary 210 traffic. To this aim, once a node receives the first copy of a data 211 packet, it discards the subsequent copies. 213 Because the first copy that reaches a node is the one that matters, 214 it is the only copy that will be forwarded upward. Then, once a node 215 performs the Packet Elimination operation, it will proceed with the 216 Packet Replication operation to forward the packet toward the RPL 217 DODAG Root. 219 4.3. Promiscuous Overhearing 221 Considering that the wireless medium is broadcast by nature, any 222 neighbor of a transmitter may overhear a transmission. By employing 223 the Promiscuous Overhearing operation, a DP and some AP(s) eventually 224 have more chances to receive the data packets. In Figure 4, when 225 node A is transmitting to its DP (node C), the AP (node D) and its 226 sibling (node B) may decode this data packet as well. As a result, 227 by employing corellated paths, a node may have multiple opportunities 228 to receive a given data packet. This feature not only enhances the 229 end-to-end reliability but also it reduces the end-to-end delay and 230 increases energy efficiency. 232 ===> (A) ====> (C) ====> (E) ==== 233 // ^ | \\ \\ 234 source (S) | | \\ (R) (root) 235 \\ | v \\ // 236 ===> (B) ====> (D) ====> (F) ==== 238 Figure 4: Unicast to DP with Overhearing: by employing Promiscuous 239 Overhearing, DP, AP and the sibling nodes have more opportunities to 240 receive the same data packet. 242 5. Requirements 244 5.1. Requirements Related to Alternative Parent Selection 246 To perform the Packet Replication procedure, it is necessary to 247 define the Alternative Parent(s) and, consequently, the path to the 248 destination node, for each node in the wireless network. An AP can 249 be selected in many different ways, and is dependent on the 250 implementation. 252 The requirements are: 254 Req1.1: The routing protocol SHOULD be extended to allow for each 255 node to select AP(s) in addition to the DP. This enables 256 packet replication to multiple parents. 258 Req1.2: Considering that the Packet Replication procedure 259 significantly increases the traffic in a network, when 260 proposing solutions for Alternative Parent Selection, they 261 should be efficient enough to mitigate the potential 262 uncontrolled packet duplications. 264 Req1.3: The topology SHOULD be defined when proposing solutions for 265 Alternative Parent Selection. For instance, the ladder 266 topology should be defined explicitly e.g., number of parallel 267 paths, density. 269 5.2. Requirements Related to Propagated Information 271 For Alternative Parent(s) selection, nodes MAY need additional 272 information about the network topology. 274 This draft does not prescribe the information required for AP 275 selcetion or how it is to be propagated to the nodes that need to 276 select AP(s). TODO: To be discussed. 278 The requirement is: 280 Req2.1: Nodes MUST have a way of receiving the required information 281 for efficient Alternative Parent Selection. 283 As an example, it is possible to use and extend the RPL [RFC6550] 284 DODAG Information Object (DIO) Control Message to allow nodes to 285 propagate information about themselves to potential children. For 286 instance, "RPL DAG Metric Container (MC) Node State and Attribute 287 (NSA) object type extension" [I-D.ietf-roll-nsa-extension] focuses on 288 extending the DAG Metric Container [RFC6551] by defining a new type- 289 length-value (TLV), entitled Parent Set (PS) which can be carried in 290 the Node State and Attribute (NSA) object. 292 5.3. Requirements Related to Promiscuous Overhearing 294 As stated previously, to further increase the network reliability and 295 to achieve deterministic packet deliveries at the destination node, 296 Promiscuous Overhearing can be considered. 298 As it is described in BCP 210 [RFC8180], in TSCH mode, the data 299 frames are transmitted in unicast mode and are acknowledged by the 300 receiving neighbor. To perform the promiscuous overhearing 301 procedure, there SHOULD be an option for the transmitted frames, 302 i.e., in unicast, to be overheard by the potential neighborhood node. 304 Destination address filtering is performed at the Medium Access 305 Control (MAC) layer. For example, according to IEEE std. 802.15.4 306 [IEEE802154-2015], a node receiving a packet with a destination 307 address different than its own and different to 0xFF discards the 308 packet. A change is needed to be able to receive packets whose 309 destination address is neither multicast nor the overhearing node's 310 MAC address. 312 The requirements are: 314 Req3.1: 316 Req3.1: The MAC implementation MUST be able to disable MAC address 317 filtering to 319 Req3.1: accept the overheard frame. 321 Req3.2: The 6top Protocol [RFC8480] specification MUST be extended 322 to indicate disabling MAC filtering in a receiving cell. This 323 can be achieved by reserving a bit in the 6P CellOptions Bitmap 324 (Section 6.2.6 [RFC8480]) for this purpose. 326 Req3.3: The overhearing node can be configured with the timeslot set 327 to shared reception, thus, there will be no acknowledgement 328 from it. However, there is the security issue that needs to be 329 considered. Since the overhearing case implies that it is not 330 possible to have per-pair keying, there MUST be a key that the 331 overhearing node will be aware of. Hence, the Minimal Security 332 Framework for 6TiSCH [I-D.ietf-6tisch-architecture] 333 specification should consider such a scenario. 335 5.4. Requirements Related to Packet Elimination 337 By employing Packet Replication, the wireless network is expected to 338 also perform Packet Elimination 340 to restrict the number of the duplicated packets, i.e., the 341 unnecessary traffic. As per the 6TiSCH Architecture 342 [I-D.ietf-6tisch-architecture], 6TiSCH has no position about how the 343 sequence numbers would be tagged in the packet. 345 The requirement is: 347 Req4.1: To perform Packet Elimination the packet copies MUST contain 348 a sequence number which allows identifying the copies. 350 Req4.1: 352 Req4.1: 354 Req4.1: 356 Req4.1: 358 6. Security Considerations 360 TODO. 362 7. IANA Considerations 364 This document has no IANA considerations. 366 8. References 368 8.1. Informative references 370 [I-D.ietf-6tisch-architecture] 371 Thubert, P., "An Architecture for IPv6 over the TSCH mode 372 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work 373 in progress), October 2019. 375 [I-D.ietf-detnet-architecture] 376 Finn, N., Thubert, P., Varga, B., and J. Farkas, 377 "Deterministic Networking Architecture", draft-ietf- 378 detnet-architecture-13 (work in progress), May 2019. 380 [I-D.ietf-roll-nsa-extension] 381 Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. 382 Thubert, "Common Ancestor Objective Functions and Parent 383 Set DAG Metric Container Extension", draft-ietf-roll-nsa- 384 extension-05 (work in progress), November 2019. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 392 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 393 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 394 Low-Power and Lossy Networks", RFC 6550, 395 DOI 10.17487/RFC6550, March 2012, 396 . 398 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 399 and D. Barthel, "Routing Metrics Used for Path Calculation 400 in Low-Power and Lossy Networks", RFC 6551, 401 DOI 10.17487/RFC6551, March 2012, 402 . 404 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 405 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 406 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 407 May 2017, . 409 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 410 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 411 DOI 10.17487/RFC8480, November 2018, 412 . 414 8.2. Other Informative References 416 [IEEE802154-2015] 417 IEEE standard for Information Technology, "IEEE standard 418 for Information Technology, "IEEE Std 802.15.4-2015 419 Standard for Low-Rate Wireless Personal Area Networks 420 (WPANs)", December 2015". 422 Authors' Addresses 424 Georgios Papadopoulos (editor) 425 IMT Atlantique 426 Office B00 - 102A 427 2 Rue de la Chataigneraie 428 Cesson-Sevigne - Rennes 35510 429 FRANCE 431 Phone: +33 299 12 70 04 432 Email: georgios.papadopoulos@imt-atlantique.fr 434 Remous-Aris Koutsiamanis 435 IMT Atlantique 436 Office B00 - 126A 437 2 Rue de la Chataigneraie 438 Cesson-Sevigne - Rennes 35510 439 FRANCE 441 Phone: +33 299 12 70 49 442 Email: aris@ariskou.com 444 Nicolas Montavont 445 IMT Atlantique 446 Office B00 - 106A 447 2 Rue de la Chataigneraie 448 Cesson-Sevigne - Rennes 35510 449 FRANCE 451 Phone: +33 299 12 70 23 452 Email: nicolas.montavont@imt-atlantique.fr 454 Pascal Thubert 455 Cisco Systems, Inc 456 Building D 457 45 Allee des Ormes - BP1200 458 MOUGINS - Sophia Antipolis 06254 459 FRANCE 461 Phone: +33 497 23 26 34 462 Email: pthubert@cisco.com