idnits 2.17.1 draft-papadopoulos-6tisch-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 (July 2, 2017) is 2480 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154-2015' is mentioned on line 354, but not defined == Unused Reference: 'RFC6550' is defined on line 340, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-07 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-11 Summary: 0 errors (**), 0 flaws (~~), 5 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 3, 2018 P. Thubert 6 Cisco 7 July 2, 2017 9 Exploiting Packet Replication and Elimination in Complex Tracks in 10 6TiSCH LLNs 11 draft-papadopoulos-6tisch-pre-reqs-00 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 http://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 3, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 (http://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 Promiscuous Overhearing . . . . . 6 69 5.3. Requirements Related to Cells without ACKs . . . . . . . 7 70 5.4. Requirements Related to Packet Elimination . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Informative references . . . . . . . . . . . . . . . . . 8 75 8.2. Other Informative References . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Some applications (such as Wireless Industrial IoT) require robust 81 communications framework that guarantees data packet delivery in a 82 given delay. For example, a periodic process may need to be repeated 83 identically every time. To reach this ambition, the network must not 84 only be reliable but also deterministic. 86 A deterministic network ensures that the transported data packet will 87 be carried out in a pre-defined and in a tight window of time, 88 whatever the quality of the wireless links and the network 89 congestion. The goal of such network is to exhibit ultra-low jitter 90 performance, i.e., close to 0. IEEE std. 802.15.4 [IEEE802154-2015] 91 has provision to provide guarantees for deterministic networks. 92 Time-Slotted Channel Hopping (TSCH) provides transmission schedule to 93 avoid random access to the medium and channel diversity to fight 94 interferences. However, TSCH is prone to retransmissions when the 95 actual transmission was unsuccessful, due to external interference or 96 potential collision and, consequently, it increases the end-to-end 97 delay performance. 99 This document is mainly motivated by the ongoing work in the 6TiSCH 100 working group. The architecture of a 6TiSCH network is detailed in 101 6TiSCH Architecture [I-D.ietf-6tisch-architecture] draft, which is 102 used for the remainder of this document. In this specification, we 103 focus on Complex Track with Replication and Elimination. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. Tracks 113 3.1. Tracks Overview 115 The 6TiSCH architecture introduces the concept of Tracks in 6TiSCH 116 Architecture [I-D.ietf-6tisch-architecture]. A simple track is 117 composed of a sequence of cells (a combination of a transmitter, a 118 receiver and a given channel offset) to ensure the transmission of a 119 single packet from a source 6TiSCH node to a destination 6TiSCH node 120 across a 6TiSCH multihop path. 122 3.2. Complex Tracks 124 A Complex Track is designed as a directed acyclic graph from a source 125 6TiSCH node towards a destination 6TiSCH node to support multi-path 126 forwarding, as introduced in 6TiSCH Architecture 127 [I-D.ietf-6tisch-architecture]. By employing DetNet Packet 128 Replication and Elimination (PRE) techniques, several paths may be 129 computed, and these paths may be more or less independent. For 130 example, a complex Track may branch off and rejoin over non-congruent 131 paths (branches). 133 In the following Section, we will detail Deterministic Networks PRE 134 techniques. 136 4. Packet Replication and Elimination principles 138 In a nutshell, PRE consists in establishing several paths in a 139 network to provide redundancy and parallel transmissions to bound the 140 delay to traverse the network. Optionnally, promiscuous listening 141 between paths is possible, such that the nodes on one path may 142 overhear transmissions along the other path. Considering the 143 scenario depicted in Figure 1, many different paths are possible for 144 S to reach R. A simple way to take benefit from this topology could 145 be to use the two independent paths via nodes A, C, E and via B, D, 146 F. But more complex paths are possible by interleaving transmissions 147 from one level of the path to the upper level in a ship-in-the-night 148 fashion. The 6TiSCH PRE may also take advantage to the shared 149 properties of the medium to compensate for the potential loss that is 150 incurred with radio transmissions. For instance, when the source 151 sends to A, B may listen and get a second chance to receive the frame 152 without an additional transmission. Note that B would not have to 153 listen if it already received that particular frame at an earlier 154 time slot. 156 (A) (C) (E) 158 source (S) (R) (root) 160 (B) (D) (F) 162 Figure 1: A Typical Ladder Shape with Two Parallel Paths Toward the 163 Destination 165 PRE model can be implemented in both centralized and distributed 166 scheduling approach. In the centralized approach, a scheduler 167 calculates the routes and schedules the communication among the nodes 168 along a circuit such as a Label switched path. In the distributed 169 approach, each node selects its route to the destination. In both 170 cases, a default parent and alternate parent(s) should be selected to 171 set up complex tracks. 173 In the following Subsections, detailed description of all required 174 operations defined by PRE, namely, Alternative Path Selection, Packet 175 Replication, Packet Elimination and Promiscuous Overhearing, will be 176 described. 178 4.1. Packet Replication 180 The objective of PRE is to offer deterministic networking properties, 181 with high reliability and bounded latency. To achieve this goal, 182 determinism in every level of the forwarding path should be 183 guaranteed. By employing Packet Replication procedure, each node 184 transmits (i.e., replicates) each data packet to both its Default 185 Parent (DP) and Alternative Parent (AP). To do so, each node (i.e., 186 source and intermediate 6TiSCH nodes) transmits the data packet twice 187 in unicast to each parent. For instance, in Figure 2, the source 188 6TiSCH node S is transmitting the packet to both parents, nodes A and 189 B, in two different timeslots within the same TSCH slotframe. Thus, 190 the packet eventually obtains parallel paths to the destination. 192 ===> (A) ====> (C) ====> (E) ==== 193 // \\ 194 source (S) (R) (root) 195 \\ // 196 ===> (B) ====> (D) ====> (F) ==== 198 Figure 2: Packet Replication: S transmits twice the same data packet, 199 to its DP (A) and to its AP (B). 201 4.2. Packet Elimination 203 The replication operation increases the traffic load in the network, 204 due to packet duplications. Thus, Packet Elimination operation 205 should be applied at each RPL DAG level to reduce the unnecessary 206 traffic. To this aim, once a node receives the first copy of a data 207 packet, it discards the following copies. Because the first copy 208 that reaches a node is the one that counts, and thus will be the only 209 copy that will be forwarded upward. 211 4.3. Promiscuous Overhearing 213 Considering that the wireless medium is broadcast by nature, any 214 neighbor of a transmitter may overhear a transmission. By employing 215 the Promiscuous Overhearing operation, DP and AP eventually have more 216 chances to receive the data packets. In Figure 3, when node A is 217 transmitting to its DP (node C), the AP (node D) and its Sibling 218 (node B) may decode this data packet as well. As a result, by 219 employing correlated paths, a node may have multiple opportunities to 220 receive a given data packet. This feature not only enhances the end- 221 to-end reliability but also it reduces the end-to-end delay. 223 ===> (A) ====> (C) ====> (E) ==== 224 // ^ | \\ \\ 225 source (S) | | \\ (R) (root) 226 \\ | v \\ // 227 ===> (B) ====> (D) ====> (F) ==== 229 Figure 3: Unicast to DP with Overhearing: by employing Promiscuous 230 Overhearing, DP, AP and the Sibling nodes have more opportunities to 231 receive the same data packet. 233 5. Requirements 235 5.1. Requirements Related to Alternative Parent Selection 237 To perform the Replication procedure, it is necessary to define the 238 Alternative Parent(s) and, consequently, the path to the destination 239 6TiSCH node, for each node in the 6TiSCH network. An AP can be 240 selected in many different ways, and is dependent on the 241 implementation. However, control packets should give some metrics to 242 discriminate between different neighbors. 244 Related requirements are: 246 Req1.1: To design such algorithm, RPL DODAG Information Object (DIO) 247 message format SHOULD be extended with an option to allow for a 248 6TiSCH node to learn additional information for its potential parent 249 and its list of parents. 251 Req1.2: The routing protocol SHOULD be extended to allow for each 252 6TiSCH node to select AP(s) and duplicate a packet to several next 253 hops. 255 5.2. Requirements Related to Promiscuous Overhearing 257 As stated previously, to further increase the 6TiSCH network 258 reliability and to achieve deterministic packet deliveries at the 259 destination 6TiSCH node, promiscuous overhearing can be considered. 261 As it is described in BCP 210 [RFC8180], in TSCH mode, the data 262 frames are transmitted in unicast mode and are acknowledged by the 263 receiving neighbor. To perform the promiscuous overhearing 264 procedure, there SHOULD be an option for the transmitted frames, 265 i.e., in unicast, to be overheard by the potential neighborhood 266 6TiSCH node. 268 Related requirements are: 270 Req2.1: The 6top Protocol [I-D.ietf-6tisch-6top-protocol] SHOULD be 271 extended to allow optionally a cell reservation with two receivers, 272 i.e., DP and AP. Considering that each frame may be transmitted 273 twice in unicast to each parent, then depending the transmission, 274 either DP will acknowledge the frame or AP will. 276 Req2.2: Next, to request the overhearing cells, the 6P ADD Request 277 Format SHOULD be transmitted either twice to each parent, i.e., DP 278 and AP, or once in multicast to both parents. 280 5.3. Requirements Related to Cells without ACKs 282 As stated in BCP 210 [RFC8180], each date frame is acknowledged by 283 the receiving 6TiSCH node. However, by employing promiscuous 284 overhearing operation, particular attention should be given to who 285 will acknowledge a transmission, i.e., the DP, and / or one of the 286 AP(s) 288 Related requirements are: 290 Req4.1: To avoid the ACK collision, the TSCH Schedule as per BCP 210 291 [RFC8180], only the DP MUST acknowledge the data packet. 293 Req4.2: Alternatively, to achieve further consistency the overheard 294 transmission need be acknowledged by both parents, i.e., DP and AP. 295 To do so, BCP 210 [RFC8180] SHOULD be extended accordingly. 297 5.4. Requirements Related to Packet Elimination 299 By employing packet replication operation, the 6TiSCH network expects 300 to perform the packet elimination operation along a complex Track to 301 bound the number of the duplicated packets, i.e., the unnecessary 302 traffic. 304 Related requirements are: 306 Req5.1: As per 6TiSCH Architecture [I-D.ietf-6tisch-architecture], 307 6TiSCH has no position about how the sequence numbers would be tagged 308 in the packet. However, it comes with Tagging Packets for Flow 309 Identification. More specifically, a 6TiSCH network expects that 310 timeslots corresponding to copies of a same frame along a complex 311 Track are correlated by configuration and, thus, does not need to 312 process the sequence numbers. 314 6. Security Considerations 316 TODO. 318 7. IANA Considerations 320 This document has no IANA considerations. 322 8. References 323 8.1. Informative references 325 [I-D.ietf-6tisch-6top-protocol] 326 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 327 (6P)", draft-ietf-6tisch-6top-protocol-07 (work in 328 progress), June 2017. 330 [I-D.ietf-6tisch-architecture] 331 Thubert, P., "An Architecture for IPv6 over the TSCH mode 332 of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work 333 in progress), January 2017. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 341 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 342 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 343 Low-Power and Lossy Networks", RFC 6550, 344 DOI 10.17487/RFC6550, March 2012, 345 . 347 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 348 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 349 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 350 May 2017, . 352 8.2. Other Informative References 354 [IEEE802154-2015] 355 IEEE standard for Information Technology, "IEEE standard 356 for Information Technology, "IEEE Std 802.15.4-2015 357 Standard for Low-Rate Wireless Personal Area Networks 358 (WPANs)", December 2015". 360 Authors' Addresses 362 Georgios Papadopoulos (editor) 363 IMT Atlantique 364 Office B00 - 102A 365 2 Rue de la Chataigneraie 366 Cesson-Sevigne - Rennes 35510 367 FRANCE 369 Phone: +33 299 12 70 04 370 Email: georgios.papadopoulos@imt-atlantique.fr 371 Nicolas Montavont 372 IMT Atlantique 373 Office B00 - 106A 374 2 Rue de la Chataigneraie 375 Cesson-Sevigne - Rennes 35510 376 FRANCE 378 Phone: +33 299 12 70 23 379 Email: nicolas.montavont@imt-atlantique.fr 381 Pascal Thubert 382 Cisco Systems, Inc 383 Building D 384 45 Allee des Ormes - BP1200 385 MOUGINS - Sophia Antipolis 06254 386 FRANCE 388 Phone: +33 497 23 26 34 389 Email: pthubert@cisco.com