idnits 2.17.00 (12 Aug 2021) /tmp/idnits13084/draft-thubert-raw-technologies-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 817: '... the 6TiSCH LLN MUST be swapped into ...' RFC 2119 keyword, line 834: '...he configuration MUST enable correlate...' RFC 2119 keyword, line 836: '...a 'AND' relation MUST be configurable ...' RFC 2119 keyword, line 846: '... transmissions SHOULD NOT be attempt...' RFC 2119 keyword, line 851: '... any of branches MUST be attempted reg...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2019) is 1067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE80211' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: 'IEEE80211ak' is defined on line 1442, but no explicit reference was found in the text == Unused Reference: 'IEEE8021Qat' is defined on line 1462, but no explicit reference was found in the text == 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: draft-ietf-6tisch-msf has been published as RFC 9033 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-02 == Outdated reference: A later version (-10) exists of draft-ietf-roll-nsa-extension-01 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational D. Cavalcanti 5 Expires: December 21, 2019 Intel 6 X. Vilajosana 7 Universitat Oberta de Catalunya 8 June 19, 2019 10 Reliable and Available Wireless Technologies 11 draft-thubert-raw-technologies-02 13 Abstract 15 This document presents a series of recent technologies that are 16 capable of time synchronization and scheduling of transmission, 17 making them suitable to carry time-sensitive flows with requirements 18 of both reliable delivery in bounded time, and availability at all 19 times, regardless of packet transmission or individual equipement 20 failures. 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 December 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4 60 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 5 61 4. IEEE 802 standards . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1.1. Provenance and Documents . . . . . . . . . . . . . . 6 64 4.1.2. 802.11ax High Efficiency (HE) . . . . . . . . . . . . 8 65 4.1.2.1. General Characteristics . . . . . . . . . . . . . 8 66 4.1.2.1.1. Multi-User OFDMA and Trigger-based Scheduled 67 Access . . . . . . . . . . . . . . . . . . . 8 68 4.1.2.1.2. Improved PHY Robustness . . . . . . . . . . . 8 69 4.1.2.1.3. Support for 6GHz band . . . . . . . . . . . . 9 70 4.1.2.2. Applicability to deterministic flows . . . . . . 9 71 4.1.2.2.1. 802.11 Managed network operation and 72 admission control . . . . . . . . . . . . . . 9 73 4.1.2.2.2. Scheduling for bounded latency and diversity 10 74 4.1.3. 802.11be Extreme High Throughput (EHT) . . . . . . . 10 75 4.1.3.1. General Characteristics . . . . . . . . . . . . . 10 76 4.1.3.2. Applicability to deterministic flows . . . . . . 11 77 4.1.3.2.1. Enhanced scheduled operation for bounded 78 latency . . . . . . . . . . . . . . . . . . . 11 79 4.1.3.2.2. Multi-AP coordination . . . . . . . . . . . . 11 80 4.1.3.2.3. Multi-band operation . . . . . . . . . . . . 12 81 4.1.4. 802.11ad and 802.11ay (mmWave operation) . . . . . . 12 82 4.1.4.1. General Characteristics . . . . . . . . . . . . . 12 83 4.1.4.2. Applicability to deterministic flows . . . . . . 12 84 4.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 13 85 4.2.1. Provenance and Documents . . . . . . . . . . . . . . 13 86 4.2.2. TimeSlotted Channel Hopping . . . . . . . . . . . . . 15 87 4.2.2.1. General Characteristics . . . . . . . . . . . . . 15 88 4.2.2.2. Applicability to Deterministic Flows . . . . . . 16 89 4.2.2.2.1. Centralized Path Computation . . . . . . . . 16 90 4.2.2.2.2. 6TiSCH Tracks . . . . . . . . . . . . . . . . 22 91 5. 3GPP standards . . . . . . . . . . . . . . . . . . . . . . . 29 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 94 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 97 9.2. Informative References . . . . . . . . . . . . . . . . . 30 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 100 1. Introduction 102 When used in math or philosophy, the term "deterministic" generally 103 refers to a perfection where all aspect are understood and 104 predictable. A perfectly Deterministic Network would ensure that 105 every packet reach its destination following a predetermined path 106 along a predefined schedule to be delivered at the exact due time. 107 In a real and imperfect world, a Deterministic Network must highly 108 predictable, which is a combination of reliability and availability. 109 On the one hand the network must be reliable, meaning that it will 110 perform as expected for all packets and in particular that it will 111 always deliver the packet at the destination in due time. On the 112 other hand, the network must be available, meaning that it is 113 resilient to any single outage, whether the cause is a software, a 114 hardware or a transmission issue. 116 RAW (Reliable and Available Wireless) is an effort to provide 117 Deterministic Networking on across a path that include a wireless 118 physical layer. Making Wireless Reliable and Available is even more 119 challenging than it is with wires, due to the numerous causes of loss 120 in transmission that add up to the congestion losses and the delays 121 caused by overbooked shared resources. In order to maintain a 122 similar quality of service along a multihop path that is composed of 123 wired and wireless hops, additional methods that are specific to 124 wireless must be leveraged to combat the sources of loss that are 125 also specific to wireless. 127 Such wireless-specific methods include per-hop retransmissions (HARQ) 128 and P2MP overhearing whereby multiple receivers are scheduled to 129 receive the same transmission, which balances the adverse effects of 130 the transmission losses that are experienced when a radio is used as 131 pure P2P. 133 2. Terminology 135 This specification uses several terms that are uncommon on protocols 136 that ensure bets effort transmissions for stochastics flows, such as 137 found in the traditional Internet and other statistically multiplexed 138 packet networks. 140 ARQ: Automatic Repeat Request, enabling an acknowledged transmission 141 and retries. ARQ is a typical model at Layer-2 on a wireless 142 medium. It is typically avoided end-to-end on deterministic 143 flows because it introduces excessive indetermination in 144 latency, but a limited number of retries within a bounded time 145 may be used over a wireless link and yet respect end-to-end 146 constraints. 148 Available: That is exempt of unscheduled outage, the expectation for 149 a network being that the flow is maintained in the face of any 150 single breakage. 152 FEC: Forward error correction, sending redundant coded data to help 153 the receiver recover transmission errors without the delays 154 incurred with ARQ. 156 HARQ: Hybrid ARQ, a combination of FEC and ARQ. 158 PCE: Path Computation Element. 160 PAREO (functions): the wireless extension of DetNet PREOF. PAREO 161 functions include scheduled ARQ at selected hops, and expect 162 the use of new operations like overhearing where available. 164 Reliable: That consistently performs as expected, the expectation 165 for a network being to always deliver a packet in due time. 167 Track: A DODAG oriented to a destination, and that enables Packet 168 ARQ, Replication, Elimination, and Ordering Functions. 170 3. On Scheduling 172 The operations of a Deterministic Network often rely on precisely 173 applying a tight schedule, in order to avoid collision loss and 174 guarantee the worst-case time of delivery. To achieve this, there 175 must be a shared sense of time throughout the network. The sense of 176 time is usually provided by the lower layer and is not in scope for 177 RAW. 179 3.1. Benefits of Scheduling on Wires 181 A network is reliable when the statistical effects that affect the 182 packet transmission are eliminated. This involves maintaining at all 183 time the amount of critical packets within the physical capabilities 184 of the hardware and that of the radio medium. This is achieved by 185 controlling the use of time-shared resources such as CPUs and 186 buffers, by shaping the flows and by scheduling the time of 187 transmission of the packets that compose the flow at every hop. 189 Equipment failure, such as an access point rebooting, a broken radio 190 adapter, or a permanent obstacle to the transmission, is a secondary 191 source of packet loss. When a breakage occurs, multiple packets are 192 lost in a row before the flows are rerouted or the system may 193 recover. This is not acceptable for critical applications such as 194 related to safety. A typical process control loop will tolerate an 195 occasional packet loss, but a loss of several packets in a row will 196 cause an emergency stop (e.g., after 4 packets lost, within a period 197 of 1 second). 199 Network Availability is obtained by making the transmission resilient 200 against hardware failures and radio transmission losses due to 201 uncontrolled events such as co-channel interferers, multipath fading 202 or moving obstacles. The best results are typically achieved by 203 pseudo randomly cumulating all forms of diversity, in the spatial 204 domain with replication and elimination, in the time domain with ARQ 205 and diverse scheduled transmissions, and in the frequency domain with 206 frequency hopping or channel hopping between frames. 208 3.2. Benefits of Scheduling on Wireless 210 In addition to the benefits listed in Section 3.1, scheduling 211 transmissions provides specific value to the wireless medium. 213 On the one hand, scheduling avoids collisions between scheduled 214 transmissions and can ensure both time and frequency diversity 215 between retries in order to defeat co-channel interference from un- 216 controlled transmitters as well as multipath fading. Transmissions 217 can be scheduled on multiple channels in parallel, which enables to 218 use the full available spectrum while avoiding the hidden terminal 219 problem, e.g., when the next packet in a same flow interferes on a 220 same channel with the previous one that progressed a few hops 221 farther. 223 On the other hand, scheduling optimizes the bandwidth usage: compared 224 to classical Collision Avoidance techniques, there is no blank time 225 related to inter-frame space (IFS) and exponential back-off in 226 scheduled operations. A minimal Clear Channel Assessment may be 227 needed to comply with the local regulations such as ETSI 300-328, but 228 that will not detect a collision when the senders are synchronized. 229 And because scheduling allows a time-sharing operation, there is no 230 limit to the ratio of isolated critical traffic. 232 Finally, scheduling plays a critical role to save energy. In IOT, 233 energy is the foremost concern, and synchronizing sender and listener 234 enables to always maintain them in deep sleep when there is no 235 scheduled transmission. This avoids idle listening and long 236 preambles and enables long sleep periods between traffic and 237 resynchronization, allowing battery-operated nodes to operate in a 238 mesh topology for multiple years. 240 4. IEEE 802 standards 242 With an active portfolio of nearly 1,300 standards and projects under 243 development, IEEE is a leading developer of industry standards in a 244 broad range of technologies that drive the functionality, 245 capabilities, and interoperability of products and services, 246 transforming how people live, work, and communicate. 248 The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains 249 networking standards and recommended practices for local, 250 metropolitan, and other area networks, using an open and accredited 251 process, and advocates them on a global basis. The most widely used 252 standards are for Ethernet, Bridging and Virtual Bridged LANs 253 Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media 254 Independent Handover Services, and Wireless RAN. An individual 255 Working Group provides the focus for each area. Standards produced 256 by the IEEE 802 SC are freely available from the IEEE GET Program 257 after they have been published in PDF for six months. 259 4.1. IEEE 802.11 261 4.1.1. Provenance and Documents 263 The IEEE 802.11 LAN standards define the underlying MAC and PHY 264 layers for the Wi-Fi technology. Wi-Fi/802.11 is one of the most 265 successful wireless technologies, supporting many application 266 domains. While previous 802.11 generations, such as 802.11n and 267 802.11ac, have focused mainly on improving peak throughput, more 268 recent generations are also considering other performance vectors, 269 such as efficiency enhancements for dense environments in 802.11ax, 270 and latency and support for Time-Sensitive Networking (TSN) 271 capabilities in 802.11be. 273 IEEE 802.11 already supports some 802.1 TSN standards and it is 274 undergoing efforts to support for other 802.1 TSN capabilities 275 required to address the use cases that require time synchronization 276 and timeliness (bounded latency) guarantees with high reliability and 277 availability. The IEEE 802.11 working group has been working in 278 collaboration with the IEEE 802.1 group for several years extending 279 802.1 features over 802.11. As with any wireless media, 802.11 280 imposes new constraints and restrictions to TSN-grade QoS, and 281 tradeoffs between latency and reliability guarantees must be 282 considered as well as managed deployment requirements. An overview 283 of 802.1 TSN capabilities and their extensions to 802.11 are 284 discussed in [Cavalcanti_2019]. 286 Wi-Fi Alliance (WFA) is the worldwide network of companies that 287 drives global Wi-Fi adoption and evolution through thought 288 leadership, spectrum advocacy, and industry-wide collaboration. The 289 WFA work helps ensure that Wi-Fi devices and networks provide users 290 the interoperability, security, and reliability they have come to 291 expect. 293 The following IEEE 802.11 specifications/certifications are relevant 294 in the context of reliable and available wireless services and 295 support for time-sensitive networking capabilities: 297 Time Synchronization: IEEE802.11-2016 with IEEE802.1AS; WFA TimeSync 298 Certification. 300 Congestion Control: IEEE802.11-2016 Admission Control; WFA Admission 301 Control. 303 Security: WFA Wi-Fi Protected Access, WPA2 and WPA3. 305 Interoperating with IEEE802.1Q bridges: IEEE802.11ak. 307 Stream Reservation Protocol (part of IEEE802.1Qat): 308 AIEEE802.11-2016. 310 Scheduled channel access: IEEE802.11ad Enhancements for very 311 high throughput in the 60 GHz band [IEEE80211ad]. 313 802.11 Real-Time Applications: Topic Interest Group (TIG) 314 ReportDoc [IEEE_doc_11-18-2009-06]. 316 In addition, major amendments being developed by the IEEE802.11 317 Working Group include capabilities that can be used as the basis for 318 providing more reliable and predictable wireless connectivity and 319 support time-sensitive applications: 321 IEEE 802.11ax D4.0: Enhancements for High Efficiency (HE). [IEEE802 322 11ax] 324 IEEE 802.11be Extreme High Throughput (EHT). [IEEE80211be] 326 IEE 802.11ay Enhanced throughput for operation in license-exempt 327 bands above 45 GHz. [IEEE80211ay] 329 The main 802.11ax and 802.11be capabilities and their relevance to 330 RAW are discussed in the remainder of this document. 332 4.1.2. 802.11ax High Efficiency (HE) 334 4.1.2.1. General Characteristics 336 The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax 337 amendment [IEEE80211ax], which includes new capabilities to increase 338 efficiency, control and reduce latency. Some of the new features 339 include higher order 1024-QAM modulation, support for uplink multi- 340 user MIMO, OFDMA, trigger-based access and Target Wake time (TWT) for 341 enhanced power savings. The OFDMA mode and trigger-based access 342 enable scheduled operation, which is a key capability required to 343 support deterministic latency and reliability for time-sensitive 344 flows. 802.11ax can operate in up to 160 MHz channels and it includes 345 support for operation in the new 6 GHz band, which is expected to be 346 open to unlicensed use by the FCC and other regulatory agencies 347 worldwide. 349 4.1.2.1.1. Multi-User OFDMA and Trigger-based Scheduled Access 351 802.11ax introduced a new orthogonal frequency-division multiple 352 access (OFDMA) mode in which multiple users can be scheduled across 353 the frequency domain. In this mode, the Access Point (AP) can 354 initiate multi-user (MU) Uplink (UL) transmissions in the same PHY 355 Protocol Data Unit (PPDU) by sending a trigger frame. This 356 centralized scheduling capability gives the AP much more control of 357 the channel, and it can remove contention between devices for uplink 358 transmissions, therefore reducing the randomness caused by CSMA-based 359 access between stations. The AP can also transmit simultaneously to 360 multiple users in the downlink direction by using a Downlink (DL) MU 361 OFDMA PPDU. In order to initiate a contention free Transmission 362 Opportunity (TXOP) using the OFDMA mode, the AP still follows the 363 typical listen before talk procedure to acquire the medium, which 364 ensures interoperability and compliance with unlicensed band access 365 rules. However, 802.11ax also includes a multi-user Enhanced 366 Distributed Channel Access (MU-EDCA) capability, which allows the AP 367 to get higher channel access priority. 369 4.1.2.1.2. Improved PHY Robustness 371 The 802.11ax PHY can operate with 0.8, 1.6 or 3.2 microsecond guard 372 interval (GI). The larger GI options provide better protection 373 against multipath, which is expected to be a challenge in industrial 374 environments. The possibility to operate with smaller resource units 375 (e.g. 2 MHz) enabled by OFDMA also helps reduce noise power and 376 improve SNR, leading to better packet error rate (PER) performance. 378 802.11ax supports beamforming as in 802.11ac, but introduces UL MU 379 MIMO, which helps improve reliability. The UL MU MIMO capability is 380 also enabled by the trigger based access operation in 802.11ax. 382 4.1.2.1.3. Support for 6GHz band 384 The 802.11ax specification [IEEE80211ax] includes support for 385 operation in the new 6 GHz band. Given the amount of new spectrum 386 available as well as the fact that no legacy 802.11 device (prior 387 802.11ax) will be able to operate in this new band, 802.11ax 388 operation in this new band can be even more efficient. 390 4.1.2.2. Applicability to deterministic flows 392 TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide 393 the underlying mechanism for supporting deterministic flows in a 394 Local Area Network (LAN). The 802.11 working group has already 395 incorporated support for several TSN capabilities, so that time- 396 sensitive flow can experience precise time synchronization and 397 timeliness when operating over 802.11 links. TSN capabilities 398 supported over 802.11 (which also extends to 802.11ax), include: 400 1. 802.1AS based Time Synchronization (other time synchronization 401 techniques may also be used) 403 2. Interoperating with IEEE802.1Q bridges 405 3. Time-sensitive Traffic Stream identification 407 The exiting 802.11 TSN capabilities listed above, and the 802.11ax 408 OFDMA and scheduled access provide a new set of tools to better 409 server time-sensitive flows. However, it is important to understand 410 the tradeoffs and constraints associated with such capabilities, as 411 well as redundancy and diversity mechanisms that can be used to 412 provide more predictable and reliable performance. 414 4.1.2.2.1. 802.11 Managed network operation and admission control 416 Time-sensitive applications and TSN standards are expected to operate 417 under a managed network (e.g. industrial/enterprise network). Thus, 418 the Wi-Fi operation must also be carefully managed and integrated 419 with the overall TSN management framework, as defined in the IEEE 420 Std. 802.1Qcc specification [IEEE8021Qcc]. 422 Some of the random-access latency and interference from legacy/ 423 unmanaged devices can be minimized under a centralized management 424 mode as defined in IEEE Std. 802.1Qcc, in which admission control 425 procedures are enforced. 427 Existing traffic stream identification, configuration and admission 428 control procedures defined in IEEE Std. 802.11 QoS mechanism can be 429 re-used. However, given the high degree of determinism required by 430 many time-sensitive applications, additional capabilities to manage 431 interference and legacy devices within tight time-constraints need to 432 be explored. 434 4.1.2.2.2. Scheduling for bounded latency and diversity 436 As discussed earlier, the 802.11ax OFDMA mode introduces the 437 possibility of assigning different RUs (frequency resources) to users 438 within a PPDU. Several RU sizes are defined in the specification 439 (26, 52, 106, 242, 484, 996 subcarriers). In addition, the AP can 440 also decide on MCS and grouping of users within a given OFMDA PPDU. 441 Such flexibility can be leveraged to support time-sensitive 442 applications with bounded latency, especially in a managed network 443 where stations can be configured to operate under the control of the 444 AP. 446 As shown in [Cavalcanti_2019], it is possible to achieve latencies in 447 the order of 1msec with high reliability in an interference free 448 environment. Obviously, there are latency, reliability and capacity 449 tradeoffs to be considered. For instance, smaller Resource Units 450 (RU)s result in longer transmission durations, which may impact the 451 minimal latency that can be achieved, but the contention latency and 452 randomness elimination due to multi-user transmission is a major 453 benefit of the OFDMA mode. 455 The flexibility to dynamically assign RUs to each transmission also 456 enables the AP to provide frequency diversity, which can help 457 increase reliability. 459 4.1.3. 802.11be Extreme High Throughput (EHT) 461 4.1.3.1. General Characteristics 463 The 802.11be is the next major 802.11 amendment (after 802.11ax) for 464 operation in the 2.4, 5 and 6 GHz bands. 802.11be is expected to 465 include new PHY and MAC features and it is targeting extremely high 466 throughput (at least 30 Gbps), as well as enhancements to worst case 467 latency and jitter. It is also expected to improve the integration 468 with 802.1 TSN to support time-sensitive applications over Ethernet 469 and Wireless LANs. 471 The 802.11be Task Group started its operation in May 2019, therefore, 472 detailed information about specific features is not yet available. 473 Only high level candidate features have been discussed so far, 474 including: 476 1. 320MHz bandwidth and more efficient utilization of non- 477 contiguous spectrum. 479 2. Multi-band/multi-channel aggregation and operation. 481 3. 16 spatial streams and related MIMO enhancements. 483 4. Multi-Access Point (AP) Coordination. 485 5. Enhanced link adaptation and retransmission protocol, e.g. 486 Hybrid Automatic Repeat Request (HARQ). 488 6. Any required adaptations to regulatory rules for the 6 GHz 489 spectrum. 491 4.1.3.2. Applicability to deterministic flows 493 The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) 494 provided detailed information on use cases, issues and potential 495 solution directions to improve support for time-sensitive 496 applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] 497 was used as input to the 802.11be project scope. 499 Improvements for worst-case latency, jitter and reliability were the 500 main topics identified in the RTA report, which were motivated by 501 applications in gaming, industrial automation, robotics, etc. The 502 RTA report also highlighted the need to support additional TSN 503 capabilities, such as time-aware (802.1Qbv) shaping and packet 504 replication and elimination as defined in 802.1CB. 506 802.11be is expected to build on and enhance 802.11ax capabilities to 507 improve worst case latency and jitter. Some of the enhancement areas 508 are discussed next. 510 4.1.3.2.1. Enhanced scheduled operation for bounded latency 512 In addition to the throughput enhancements, 802.11be will leverage 513 the trigger-based scheduled operation enabled by 802.11ax to provide 514 efficient and more predictable medium access. 802.11be is expected to 515 include enhancements to reduce overhead and enable more efficient 516 operation in managed network deployments [IEEE_doc_11-19-0373-00]. 518 4.1.3.2.2. Multi-AP coordination 520 Multi-AP coordination is one of the main new candidate features in 521 802.11be. It can provide benefits in throughput and capacity and has 522 the potential to address some of the issues that impact worst case 523 latency and reliability. Multi-AP coordination is expected to 524 address the contention due to overlapping Basic Service Sets (OBSS), 525 which is one of the main sources of random latency variations. 526 802.11be can define methods to enable better coordination between 527 APs, for instance, in a managed network scenario, in order to reduce 528 latency due to unmanaged contention. 530 Several multi-AP coordination approaches have been discussed with 531 different levels of complexities and benefits, but specific 532 coordination methods have not yet been defined. 534 4.1.3.2.3. Multi-band operation 536 802.11be will introduce new features to improve operation over 537 multiple bands and channels. By leveraging multiple bands/channels, 538 802.11be can isolate time-sensitive traffic from network congestion, 539 one of the main causes of large latency variations. In a managed 540 802.11be network, it should be possible to steer traffic to certain 541 bands/channels to isolate time-sensitive traffic from other traffic 542 and help achieve bounded latency. 544 4.1.4. 802.11ad and 802.11ay (mmWave operation) 546 4.1.4.1. General Characteristics 548 The IEEE 802.11ad amendment defines PHY and MAC capabilities to 549 enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) 550 band. The standard addresses the adverse mmWave signal propagation 551 characteristics and provides directional communication capabilities 552 that take advantage of beamforming to cope with increased 553 attenuation. An overview of the 802.11ad standard can be found in 554 [Nitsche_2015] . 556 The IEEE 802.11ay is currently developing enhancements to the 557 802.11ad standard to enable the next generation mmWave operation 558 targeting 100 Gbps throughput. Some of the main enhancements in 559 802.11ay include MIMO, channel bonding, improved channel access and 560 beamforming training. An overview of the 802.11ay capabilities can 561 be found in [Ghasempour_2017] 563 4.1.4.2. Applicability to deterministic flows 565 The high data rates achievable with 802.11ad and 802.11ay can 566 significantly reduce latency down to microsecond levels. Limited 567 interference from legacy and other unlicensed devices in 60 GHz is 568 also a benefit. However, directionality and short range typical in 569 mmWave operation impose new challenges such as the overhead required 570 for beam training and blockage issues, which impact both latency and 571 reliability. Therefore, it is important to understand the use case 572 and deployment conditions in order to properly apply and configure 573 802.11ad/ay networks for time sensitive applications. 575 The 802.11ad standard include a scheduled access mode in which 576 stations can be allocated contention-free service periods by a 577 central controller. This scheduling capability is also available in 578 802.11ay, and it is one of the mechanisms that can be used to provide 579 bounded latency to time-sensitive data flows. An analysis of the 580 theoretical latency bounds that can be achieved with 802.11ad service 581 periods is provided in [Cavalcanti_2019]. 583 4.2. IEEE 802.15.4 585 4.2.1. Provenance and Documents 587 The IEEE802.15.4 Task Group has been driving the development of low- 588 power low-cost radio technology. The IEEE802.15.4 physical layer has 589 been designed to support demanding low-power scenarios targeting the 590 use of unlicensed bands, both the 2.4 GHz and sub GHz Industrial, 591 Scientific and Medical (ISM) bands. This has imposed requirements in 592 terms of frame size, data rate and bandwidth to achieve reduced 593 collision probability, reduced packet error rate, and acceptable 594 range with limited transmission power. The PHY layer supports frames 595 of up to 127 bytes. The Medium Access Control (MAC) sublayer 596 overhead is in the order of 10-20 bytes, leaving about 100 bytes to 597 the upper layers. IEEE802.15.4 uses spread spectrum modulation such 598 as the Direct Sequence Spread Spectrum (DSSS). 600 The Timeslotted Channel Hopping (TSCH) mode was added to the 2015 601 revision of the IEEE802.15.4 standard [IEEE802154]. TSCH is targeted 602 at the embedded and industrial world, where reliability, energy 603 consumption and cost drive the application space. 605 At the IETF, the 6TiSCH Working Group (WG) [TiSCH] deals with best 606 effort operation of IPv6 [RFC8200] over TSCH. 6TiSCH has enabled 607 distributed scheduling to exploit the deterministic access 608 capabilities provided by TSCH. The group designed the essential 609 mechanisms to enable the management plane operation while ensuring 610 IPv6 is supported. Yet the charter did not focus to providing a 611 solution to establish end to end Tracks while meeting quality of 612 service requirements. 6TiSCH, through the RFC8480 [RFC8480] defines 613 the 6P protocol which provides a pairwise negotiation mechanism to 614 the control plane operation. The protocol supports agreement on a 615 schedule between neighbors, enabling distributed scheduling. 6P goes 616 hand-in-hand with a Scheduling Function (SF), the policy that decides 617 how to maintain cells and trigger 6P transactions. The Minimal 618 Scheduling Function (MSF) [I-D.ietf-6tisch-msf] is the default SF 619 defined by the 6TiSCH WG; other standardized SFs can be defined in 620 the future. MSF extends the minimal schedule configuration, and is 621 used to add child-parent links according to the traffic load. 623 Time sensitive networking on low power constrained wireless networks 624 have been partially addressed by ISA100.11a [ISA100.11a] and 625 WirelessHART [WirelessHART]. Both technologies involve a central 626 controller that computes redundant paths for industrial process 627 control traffic over a TSCH mesh. Moreover, ISA100.11a introduces 628 IPv6 capabilities with a Link-Local Address for the join process and 629 a global unicast addres for later exchanges, but the IPv6 traffic 630 typically ends at a local application gateway and the full power of 631 IPv6 for end-to-end communication is not enabled. Compared to that 632 state of the art, work at the IETF and in particular at RAW could 633 provide additional techniques such as optimized P2P routing, PAREO 634 functions, and end-to-end secured IPv6/CoAP connectivity. 636 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] identifies 637 different models to schedule resources along so-called Tracks (see 638 Section 4.2.2.2.2) exploiting the TSCH schedule structure however the 639 focus at 6TiSCH is on best effort traffic and the group was never 640 chartered to produce standard work related to Tracks. 642 Useful References include: 644 1. IEEE Std 802.15.4: "IEEE Std. 802.15.4, Part. 15.4: Wireless 645 Medium Access Control (MAC) and Physical Layer (PHY) 646 Specifications for Low-Rate Wireless Personal Area Networks" 647 [IEEE802154]. The latest version at the time of this writing is 648 dated year 2015. 650 2. Morell, A. , Vilajosana, X. , Vicario, J. L. and Watteyne, T. 651 (2013), Label switching over IEEE802.15.4e networks. Trans. 652 Emerging Tel. Tech., 24: 458-475. doi:10.1002/ett.2650" 653 [morell13]. 655 3. De Armas, J., Tuset, P., Chang, T., Adelantado, F., Watteyne, 656 T., Vilajosana, X. (2016, September). Determinism through path 657 diversity: Why packet replication makes sense. In 2016 658 International Conference on Intelligent Networking and 659 Collaborative Systems (INCoS) (pp. 150-154). IEEE. [dearmas16]. 661 4. X. Vilajosana, T. Watteyne, M. Vucinic, T. Chang and K. S. 662 J. Pister, "6TiSCH: Industrial Performance for IPv6 Internet- 663 of-Things Networks," in Proceedings of the IEEE, vol. 107, no. 664 6, pp. 1153-1165, June 2019. [vilajosana19]. 666 4.2.2. TimeSlotted Channel Hopping 668 4.2.2.1. General Characteristics 670 As a core technique in IEEE802.15.4, TSCH splits time in multiple 671 time slots that repeat over time. The structure is referred as a 672 Slotframe (see Section 4.2.2.2.1.4). For each timeslot, a set of 673 available frequencies can be used, resulting in a matrix-like 674 schedule (see Fig. Figure 1). 676 timeslot offset 677 | 0 1 2 3 4 | 0 1 2 3 4 | Nodes 678 +------------------------+------------------------+ +-----+ 679 | | | | | | | | | | | | C | 680 CH-1 | EB | | |C->B| | EB | | |C->B| | | | 681 | | | | | | | | | | | +-----+ 682 +-------------------------------------------------+ | 683 | | | | | | | | | | | | 684 CH-2 | | |B->C| |B->A| | |B->C| |B->A| +-----+ 685 | | | | | | | | | | | | B | 686 +-------------------------------------------------+ | | 687 ... +-----+ 688 | 689 +-------------------------------------------------+ | 690 | | | | | | | | | | | +-----+ 691 CH-15| |A->B| | | | |A->B| | | | | A | 692 | | | | | | | | | | | | | 693 +-------------------------------------------------+ +-----+ 694 ch. 695 offset 697 Figure 1: Slotframe example with scheduled cells between nodes A, B 698 and C 700 This schedule represents the possible communications of a node with 701 its neighbors, and is managed by a Scheduling Function such as The 702 Minimal Scheduling Function (MSF) [I-D.ietf-6tisch-msf]. Each cell 703 in the schedule is identified by its slotoffset and channeloffset 704 coordinates. A cell's timeslot offset indicates its position in 705 time, relative to the beginning of the slotframe. A cell's channel 706 offset is an index which maps to a frequency at each iteration of the 707 slotframe. Each packet exchanged between neighbors happens within 708 one cell. An Absolute Slot Number (ASN) indicates the number of 709 slots elapsed since the network started. It increments at every 710 slot. This is a 5 byte counter that can support networks running for 711 more than 300 years without wrapping (assuming a 10 ms timeslot). 712 Channel hopping provides increased reliability to multi-path fading 713 and external interference. It is handled by TSCH through a channel 714 hopping sequence referred as macHopSeq in the IEEE802.15.4 715 specification. 717 The Time-Frequency Division Multiple Access provided by TSCH enables 718 the orchestration of traffic flows, spreading them in time and 719 frequency, and hence enabling an efficient management of the 720 bandwidth utilization. Such efficient bandwidth utilization can be 721 combined to OFDM modulations also supported by the IEEE802.15.4 722 standard [IEEE802154] since the 2015 version. 724 In the RAW context, low power reliable networks should address non- 725 critical control scenarios such as Class 2 and monitoring scenarios 726 such as Class 4 defined by the RFC5673 [RFC5673]. As a low power 727 technology targeting industrial scenarios radio transducers provide 728 low data rates (typically between 50kbps to 250kbps) and robust 729 modulations to trade-off performance to reliability. TSCH networks 730 are organized in mesh topologies and connected to a backbone. 731 Latency in the mesh network is mainly influenced by propagation 732 aspects such as interference. ARQ methods and redundancy techniques 733 such as replication and elimination should be studied to provide the 734 needed performance to address deterministic scenarios. 736 4.2.2.2. Applicability to Deterministic Flows 738 Nodes in a TSCH network are tightly synchronized. This enables to 739 build the slotted structure and ensure efficient utilization of 740 resources thanks to proper scheduling policies. Scheduling is a key 741 to orchestrate the resources that different nodes in a Track or a 742 path are using. Slotframes can be split in resource blocks reserving 743 the needed capacity to certain flows. Periodic and bursty traffic 744 can be handled independently in the schedule, using active and 745 reactive policies and taking advantage of overprovisionned cells to 746 measu reth excursion. Along a Track, resource blocks can be chained 747 so nodes in previous hops transmit their data before the next packet 748 comes. This provides a tight control to latency along a Track. 749 Collision loss is avoided for best effort traffic by 750 overprovisionning resources, giving time to the management plane of 751 the network to dedicate more resources if needed. 753 4.2.2.2.1. Centralized Path Computation 755 In a controlled environment, a 6TiSCH device usually does not place a 756 request for bandwidth between itself and another device in the 757 network. Rather, an Operation Control System (OCS) invoked through 758 an Human/Machine Interface (HMI) iprovides the Traffic Specification, 759 in particular in terms of latency and reliability, and the end nodes, 760 to a PCE. With this, the PCE computes a Track between the end nodes 761 and provisions every hop in the Track with per-flow state that 762 describes the per-hop operation for a given packet, the corresponding 763 timeSlots, and the flow identification to recognize which packet is 764 placed in which Track, sort out duplicates, etc... 766 For a static configuration that serves a certain purpose for a long 767 period of time, it is expected that a node will be provisioned in one 768 shot with a full schedule, which incorporates the aggregation of its 769 behavior for multiple Tracks. The 6TiSCH Architecture expects that 770 the programing of the schedule is done over COAP as discussed in 771 "6TiSCH Resource Management and Interaction using CoAP" 772 [I-D.ietf-6tisch-coap]. 774 But an Hybrid mode may be required as well whereby a single Track is 775 added, modified, or removed, for instance if it appears that a Track 776 does not perform as expected for, say, PDR. For that case, the 777 expectation is that a protocol that flows along a Track (to be), in a 778 fashion similar to classical Traffic Engineering (TE) [CCAMP], may be 779 used to update the state in the devices. 6TiSCH provides means for a 780 device to negotiate a timeSlot with a neighbor, but in general that 781 flow was not designed and no protocol was selected and it is expected 782 that DetNet will determine the appropriate end-to-end protocols to be 783 used in that case. 785 Stream Management Entity 787 Operational System and HMI 789 -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 791 PCE PCE PCE PCE 793 -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 795 --- 6TiSCH------6TiSCH------6TiSCH------6TiSCH-- 796 6TiSCH / Device Device Device Device \ 797 Device- - 6TiSCH 798 \ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device 799 ----Device------Device------Device------Device-- 801 Figure 2 803 4.2.2.2.1.1. Packet Marking and Handling 805 Section "Packet Marking and Handling" of 806 [I-D.ietf-6tisch-architecture] describes the packet tagging and 807 marking that is expected in 6TiSCH networks. 809 4.2.2.2.1.1.1. Tagging Packets for Flow Identification 811 For packets that are routed by a PCE along a Track, the tuple formed 812 by the IPv6 source address and a local RPLInstanceID is tagged in the 813 packets to identify uniquely the Track and associated transmit bundle 814 of timeSlots. 816 It results that the tagging that is used for a DetNet flow outside 817 the 6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the 818 packet enters and then leaves the 6TiSCH network. 820 Note: The method and format used for encoding the RPLInstanceID at 821 6lo is generalized to all 6TiSCH topological Instances, which 822 includes Tracks. 824 4.2.2.2.1.1.2. Replication, Retries and Elimination 826 6TiSCH expects elimination and replication of packets along a complex 827 Track, but has no position about how the sequence numbers would be 828 tagged in the packet. 830 As it goes, 6TiSCH expects that timeSlots corresponding to copies of 831 a same packet along a Track are correlated by configuration, and does 832 not need to process the sequence numbers. 834 The semantics of the configuration MUST enable correlated timeSlots 835 to be grouped for transmit (and respectively receive) with a 'OR' 836 relations, and then a 'AND' relation MUST be configurable between 837 groups. The semantics is that if the transmit (and respectively 838 receive) operation succeeded in one timeSlot in a 'OR' group, then 839 all the other timeSLots in the group are ignored. Now, if there are 840 at least two groups, the 'AND' relation between the groups indicates 841 that one operation must succeed in each of the groups. 843 On the transmit side, timeSlots provisioned for retries along a same 844 branch of a Track are placed a same 'OR' group. The 'OR' relation 845 indicates that if a transmission is acknowledged, then further 846 transmissions SHOULD NOT be attempted for timeSlots in that group. 847 There are as many 'OR' groups as there are branches of the Track 848 departing from this node. Different 'OR' groups are programmed for 849 the purpose of replication, each group corresponding to one branch of 850 the Track. The 'AND' relation between the groups indicates that 851 transmission over any of branches MUST be attempted regardless of 852 whether a transmission succeeded in another branch. It is also 853 possible to place cells to different next-hop routers in a same 'OR' 854 group. This allows to route along multi-path Tracks, trying one 855 next-hop and then another only if sending to the first fails. 857 On the receive side, all timeSlots are programmed in a same 'OR' 858 group. Retries of a same copy as well as converging branches for 859 elimination are converged, meaning that the first successful 860 reception is enough and that all the other timeSlots can be ignored. 862 4.2.2.2.1.1.3. Differentiated Services Per-Hop-Behavior 864 Additionally, an IP packet that is sent along a Track uses the 865 Differentiated Services Per-Hop-Behavior Group called Deterministic 866 Forwarding, as described in 867 [I-D.svshah-tsvwg-deterministic-forwarding]. 869 4.2.2.2.1.2. Topology and capabilities 871 6TiSCH nodes are usually IoT devices, characterized by very limited 872 amount of memory, just enough buffers to store one or a few IPv6 873 packets, and limited bandwidth between peers. It results that a node 874 will maintain only a small number of peering information, and will 875 not be able to store many packets waiting to be forwarded. Peers can 876 be identified through MAC or IPv6 addresses. 878 Neighbors can be discovered over the radio using mechanism such as 879 beacons, but, though the neighbor information is available in the 880 6TiSCH interface data model, 6TiSCH does not describe a protocol to 881 pro-actively push the neighborhood information to a PCE. This 882 protocol should be described and should operate over CoAP. The 883 protocol should be able to carry multiple metrics, in particular the 884 same metrics as used for RPL operations [RFC6551] 886 The energy that the device consumes in sleep, transmit and receive 887 modes can be evaluated and reported. So can the amount of energy 888 that is stored in the device and the power that it can be scavenged 889 from the environment. The PCE SHOULD be able to compute Tracks that 890 will implement policies on how the energy is consumed, for instance 891 balance between nodes, ensure that the spent energy does not exceeded 892 the scavenged energy over a period of time, etc... 894 4.2.2.2.1.3. Schedule Management by a PCE 896 6TiSCH supports a mixed model of centralized routes and distributed 897 routes. Centralized routes can for example be computed by a entity 898 such as a Path Computation element (PCE) [PCE]. Distributed routes 899 are computed by RPL [RFC6550]. 901 Both methods may inject routes in the Routing Tables of the 6TiSCH 902 routers. In either case, each route is associated with a 6TiSCH 903 topology that can be a RPL Instance topology or a Track. The 6TiSCH 904 topology is indexed by a Instance ID, in a format that reuses the 905 RPLInstanceID as defined in RPL. 907 Both RPL and PCE rely on shared sources such as policies to define 908 Global and Local RPLInstanceIDs that can be used by either method. 909 It is possible for centralized and distributed routing to share a 910 same topology. Generally they will operate in different slotFrames, 911 and centralized routes will be used for scheduled traffic and will 912 have precedence over distributed routes in case of conflict between 913 the slotFrames. 915 4.2.2.2.1.4. SlotFrames and Priorities 917 A slotFrame is the base object that a PCE needs to manipulate to 918 program a schedule into an LLN node. Elaboration on that concept can 919 be fond in section "SlotFrames and Priorities" of 920 [I-D.ietf-6tisch-architecture] 922 IEEE802.15.4 TSCH avoids contention on the medium by formatting time 923 and frequencies in cells of transmission of equal duration. In order 924 to describe that formatting of time and frequencies, the 6TiSCH 925 architecture defines a global concept that is called a Channel 926 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 927 cells with an height equal to the number of available channels 928 (indexed by ChannelOffsets) and a width (in timeSlots) that is the 929 period of the network scheduling operation (indexed by slotOffsets) 930 for that CDU matrix. The size of a cell is a timeSlot duration, and 931 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to 932 accommodate for the transmission of a frame and an ack, including the 933 security validation on the receive side which may take up to a few 934 milliseconds on some device architecture. 936 The frequency used by a cell in the matrix rotates in a pseudo-random 937 fashion, from an initial position at an epoch time, as the matrix 938 iterates over and over. 940 A CDU matrix is computed by the PCE, but unallocated timeSlots may be 941 used opportunistically by the nodes for classical best effort IP 942 traffic. The PCE has precedence in the allocation in case of a 943 conflict. 945 In a given network, there might be multiple CDU matrices that operate 946 with different width, so they have different durations and represent 947 different periodic operations. It is recommended that all CDU 948 matrices in a 6TiSCH domain operate with the same cell duration and 949 are aligned, so as to reduce the chances of interferences from 950 slotted-aloha operations. The PCE MUST compute the CDU matrices and 951 shared that knowledge with all the nodes. The matrices are used in 952 particular to define slotFrames. 954 A slotFrame is a MAC-level abstraction that is common to all nodes 955 and contains a series of timeSlots of equal length and precedence. 956 It is characterized by a slotFrame_ID, and a slotFrame_size. A 957 slotFrame aligns to a CDU matrix for its parameters, such as number 958 and duration of timeSlots. 960 Multiple slotFrames can coexist in a node schedule, i.e., a node can 961 have multiple activities scheduled in different slotFrames, based on 962 the precedence of the 6TiSCH topologies. The slotFrames may be 963 aligned to different CDU matrices and thus have different width. 964 There is typically one slotFrame for scheduled traffic that has the 965 highest precedence and one or more slotFrame(s) for RPL traffic. The 966 timeSlots in the slotFrame are indexed by the SlotOffset; the first 967 cell is at SlotOffset 0. 969 The 6TiSCH architecture introduces the concept of chunks 970 ([I-D.ietf-6tisch-architecture]) to operate such spectrum 971 distribution for a whole group of cells at a time. The CDU matrix is 972 formatted into a set of chunks, each of them identified uniquely by a 973 chunk-ID. The PCE MUST compute the partitioning of CDU matrices into 974 chunks and shared that knowledge with all the nodes in a 6TiSCH 975 network. 977 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 978 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 979 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 980 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 981 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 982 ... 983 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 984 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 985 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 986 0 1 2 3 4 5 6 M 988 Figure 3: CDU matrix Partitioning in Chunks 990 The appropriation of a chunk can be requested explicitly by the PCE 991 to any node. After a successful appropriation, the PCE owns the 992 cells in that chunk, and may use them as hard cells to set up Tracks. 993 Then again, 6TiSCH did not propose a method for chunk definition and 994 a protocol for appropriation. This is to be done at PAW. 996 4.2.2.2.2. 6TiSCH Tracks 998 A Track at 6TiSCH is the application to wireless of the concept of a 999 path in the Detnet architecture [I-D.ietf-detnet-architecture]. A 1000 Track can follow a simple sequence of relay nodes or can be 1001 structured as a more complex destination oriented directed acyclic 1002 graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes 1003 reserve the resources to enable the efficient transmission of packets 1004 while aiming to optimize certain properties such as reliability and 1005 ensure small jitter or bounded latency. The Track structure enables 1006 Layer-2 forwarding schemes, reducing the overhead of taking routing 1007 decisions at the Layer-3. 1009 Serial Tracks can be understood as the concatenation of cells or 1010 bundles along a routing path from a node towards a destination. The 1011 serial Track concept is analogous to the circuit concept where 1012 resources are chained through the multi-hop topology. For example, A 1013 bundle of Tx Cells in a particular node is paired to a bundle of Rx 1014 Cells in the next hop node following a routing path. 1016 whereas scheduling ensures reliable delivery in bounded time along 1017 any Track, high availability requires the application of PAREO 1018 functions along a more complex DODAG Track structure. A DODAG has 1019 forking and joining nodes where the concepts such as Replication and 1020 Elimination can be exploited. Spatial redundancy increases the 1021 oveall energy consumption in the network but improves significantly 1022 the availability of the network as well as the packet delivery ratio. 1023 A Track may also branch off and rejoin, for the purpose of the so- 1024 called Packet Replication and Elimination (PRE), over non congruent 1025 branches. PRE may be used to complement layer-2 Automatic Repeat 1026 reQuest (ARQ) and and receiver-end Ordering to form the PAREO 1027 functions. PAREO functions enable to meet industrial expectations in 1028 Packet Delivery Ratio (PDR) within bounded delivery time over a Track 1029 that includes wireless links, even when the Track extends beyond the 1030 6TiSCH network. 1032 +-----+ 1033 | IoT | 1034 | G/W | 1035 +-----+ 1036 ^ <---- Elimination 1037 | | 1038 Track branch | | 1039 +-------+ +--------+ Subnet Backbone 1040 | | 1041 +--|--+ +--|--+ 1042 | | | Backbone | | | Backbone 1043 o | | | router | | | router 1044 +--/--+ +--|--+ 1045 o / o o---o----/ o 1046 o o---o--/ o o o o o 1047 o \ / o o LLN o 1048 o v <---- Replication 1049 o 1051 Figure 4: End-to-End deterministic Track 1053 In the example above, a Track is laid out from a field device in a 1054 6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN 1055 backbone. 1057 The Replication function in the field device sends a copy of each 1058 packet over two different branches, and a PCE schedules each hop of 1059 both branches so that the two copies arrive in due time at the 1060 gateway. In case of a loss on one branch, hopefully the other copy 1061 of the packet still makes it in due time. If two copies make it to 1062 the IoT gateway, the Elimination function in the gateway ignores the 1063 extra packet and presents only one copy to upper layers. 1065 At each 6TiSCH hop along the Track, the PCE may schedule more than 1066 one timeSlot for a packet, so as to support Layer-2 retries (ARQ). 1067 It is also possible that the field device only uses the second branch 1068 if sending over the first branch fails. 1070 In current deployments, a TSCH Track does not necessarily support PRE 1071 but is systematically multi-path. This means that a Track is 1072 scheduled so as to ensure that each hop has at least two forwarding 1073 solutions, and the forwarding decision is to try the preferred one 1074 and use the other in case of Layer-2 transmission failure as detected 1075 by ARQ. 1077 Methods to implement complex Tracks are described in 1078 [I-D.papadopoulos-paw-pre-reqs] and complemented by extensions to the 1079 RPL routing protocol in [I-D.ietf-roll-nsa-extension] for best effort 1080 traffic, but a centralized routing technique such as promoted in 1081 DetNet is still missing. 1083 4.2.2.2.2.1. Track Scheduling Protocol 1085 Section "Schedule Management Mechanisms" of the 6TiSCH architecture 1086 describes 4 paradigms to manage the TSCH schedule of the LLN nodes: 1087 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 1088 and scheduling management, and Hop-by-hop scheduling. The Track 1089 operation for DetNet corresponds to a remote monitoring and 1090 scheduling management by a PCE. 1092 Early work at 6TiSCH on a data model and a protocol to program the 1093 schedule in the 6TiSCH device was never concluded as the group 1094 focussed on best effort traffic. This work would be revived by PAW: 1096 The 6top interface document [RFC8480] (to be reopened at PAW) was 1097 intended to specify the generic data model that can be used to 1098 monitor and manage resources of the 6top sublayer. Abstract 1099 methods were suggested for use by a management entity in the 1100 device. The data model also enables remote control operations on 1101 the 6top sublayer. 1103 [I-D.ietf-6tisch-coap] (to be reopened at RAW) was intended to 1104 define a mapping of the 6top set of commands, which is described 1105 in RFC 8480, to CoAP resources. This allows an entity to interact 1106 with the 6top layer of a node that is multiple hops away in a 1107 RESTful fashion. 1109 [I-D.ietf-6tisch-coap] also defined a basic set CoAP resources and 1110 associated RESTful access methods (GET/PUT/POST/DELETE). The 1111 payload (body) of the CoAP messages is encoded using the CBOR 1112 format. The PCE commands are expected to be issued directly as 1113 CoAP requests or to be mapped back and forth into CoAP by a 1114 gateway function at the edge of the 6TiSCH network. For instance, 1115 it is possible that a mapping entity on the backbone transforms a 1116 non-CoAP protocol such as PCEP into the RESTful interfaces that 1117 the 6TiSCH devices support. 1119 4.2.2.2.2.2. Track Forwarding 1121 By forwarding, this specification means the per-packet operation that 1122 allows to deliver a packet to a next hop or an upper layer in this 1123 node. Forwarding is based on pre-existing state that was installed 1124 as a result of the routing computation of a Track by a PCE. The 1125 6TiSCH architecture supports three different forwarding model, G-MPLS 1126 Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 1127 Forwarding (6F) which is the classical IP operation. The DetNet case 1128 relates to the Track Forwarding operation under the control of a PCE. 1130 A Track is a unidirectional path between a source and a destination. 1131 In a Track cell, the normal operation of IEEE802.15.4 Automatic 1132 Repeat-reQuest (ARQ) usually happens, though the acknowledgment may 1133 be omitted in some cases, for instance if there is no scheduled cell 1134 for a retry. 1136 Track Forwarding is the simplest and fastest. A bundle of cells set 1137 to receive (RX-cells) is uniquely paired to a bundle of cells that 1138 are set to transmit (TX-cells), representing a layer-2 forwarding 1139 state that can be used regardless of the network layer protocol. 1140 This model can effectively be seen as a Generalized Multi-protocol 1141 Label Switching (G-MPLS) operation in that the information used to 1142 switch a frame is not an explicit label, but rather related to other 1143 properties of the way the packet was received, a particular cell in 1144 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 1145 Layer-2 security) accepts a frame, that frame can be switched 1146 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 1147 fragment, or a frame from an alternate protocol such as WirelessHART 1148 or ISA100.11a. 1150 A data frame that is forwarded along a Track normally has a 1151 destination MAC address that is set to broadcast - or a multicast 1152 address depending on MAC support. This way, the MAC layer in the 1153 intermediate nodes accepts the incoming frame and 6top switches it 1154 without incurring a change in the MAC header. In the case of 1155 IEEE802.15.4, this means effectively broadcast, so that along the 1156 Track the short address for the destination of the frame is set to 1157 0xFFFF. 1159 A Track is thus formed end-to-end as a succession of paired bundles, 1160 a receive bundle from the previous hop and a transmit bundle to the 1161 next hop along the Track, and a cell in such a bundle belongs to at 1162 most one Track. For a given iteration of the device schedule, the 1163 effective channel of the cell is obtained by adding a pseudo-random 1164 number to the channelOffset of the cell, which results in a rotation 1165 of the frequency that used for transmission. The bundles may be 1166 computed so as to accommodate both variable rates and 1167 retransmissions, so they might not be fully used at a given iteration 1168 of the schedule. The 6TiSCH architecture provides additional means 1169 to avoid waste of cells as well as overflows in the transmit bundle, 1170 as follows: 1172 In one hand, a TX-cell that is not needed for the current iteration 1173 may be reused opportunistically on a per-hop basis for routed 1174 packets. When all of the frame that were received for a given Track 1175 are effectively transmitted, any available TX-cell for that Track can 1176 be reused for upper layer traffic for which the next-hop router 1177 matches the next hop along the Track. In that case, the cell that is 1178 being used is effectively a TX-cell from the Track, but the short 1179 address for the destination is that of the next-hop router. It 1180 results that a frame that is received in a RX-cell of a Track with a 1181 destination MAC address set to this node as opposed to broadcast must 1182 be extracted from the Track and delivered to the upper layer (a frame 1183 with an unrecognized MAC address is dropped at the lower MAC layer 1184 and thus is not received at the 6top sublayer). 1186 On the other hand, it might happen that there are not enough TX-cells 1187 in the transmit bundle to accommodate the Track traffic, for instance 1188 if more retransmissions are needed than provisioned. In that case, 1189 the frame can be placed for transmission in the bundle that is used 1190 for layer-3 traffic towards the next hop along the Track as long as 1191 it can be routed by the upper layer, that is, typically, if the frame 1192 transports an IPv6 packet. The MAC address should be set to the 1193 next-hop MAC address to avoid confusion. It results that a frame 1194 that is received over a layer-3 bundle may be in fact associated to a 1195 Track. In a classical IP link such as an Ethernet, off-Track traffic 1196 is typically in excess over reservation to be routed along the non- 1197 reserved path based on its QoS setting. But with 6TiSCH, since the 1198 use of the layer-3 bundle may be due to transmission failures, it 1199 makes sense for the receiver to recognize a frame that should be re- 1200 Tracked, and to place it back on the appropriate bundle if possible. 1201 A frame should be re-Tracked if the Per-Hop-Behavior group indicated 1202 in the Differentiated Services Field in the IPv6 header is set to 1203 Deterministic Forwarding, as discussed in Section 4.2.2.2.1.1. A 1204 frame is re-Tracked by scheduling it for transmission over the 1205 transmit bundle associated to the Track, with the destination MAC 1206 address set to broadcast. 1208 There are 2 modes for a Track, transport mode and tunnel mode. 1210 4.2.2.2.2.2.1. Transport Mode 1212 In transport mode, the Protocol Data Unit (PDU) is associated with 1213 flow-dependant meta-data that refers uniquely to the Track, so the 1214 6top sublayer can place the frame in the appropriate cell without 1215 ambiguity. In the case of IPv6 traffic, this flow identification is 1216 transported in the Flow Label of the IPv6 header. Associated with 1217 the source IPv6 address, the Flow Label forms a globally unique 1218 identifier for that particular Track that is validated at egress 1219 before restoring the destination MAC address (DMAC) and punting to 1220 the upper layer. 1222 | ^ 1223 +--------------+ | | 1224 | IPv6 | | | 1225 +--------------+ | | 1226 | 6LoWPAN HC | | | 1227 +--------------+ ingress egress 1228 | 6top | sets +----+ +----+ restores 1229 +--------------+ dmac to | | | | dmac to 1230 | TSCH MAC | brdcst | | | | self 1231 +--------------+ | | | | | | 1232 | LLN PHY | +-------+ +--...-----+ +-------+ 1233 +--------------+ 1235 Track Forwarding, Transport Mode 1237 4.2.2.2.2.2.2. Tunnel Mode 1239 In tunnel mode, the frames originate from an arbitrary protocol over 1240 a compatible MAC that may or may not be synchronized with the 6TiSCH 1241 network. An example of this would be a router with a dual radio that 1242 is capable of receiving and sending WirelessHART or ISA100.11a frames 1243 with the second radio, by presenting itself as an Access Point or a 1244 Backbone Router, respectively. 1246 In that mode, some entity (e.g. PCE) can coordinate with a 1247 WirelessHART Network Manager or an ISA100.11a System Manager to 1248 specify the flows that are to be transported transparently over the 1249 Track. 1251 +--------------+ 1252 | IPv6 | 1253 +--------------+ 1254 | 6LoWPAN HC | 1255 +--------------+ set restore 1256 | 6top | +dmac+ +dmac+ 1257 +--------------+ to|brdcst to|nexthop 1258 | TSCH MAC | | | | | 1259 +--------------+ | | | | 1260 | LLN PHY | +-------+ +--...-----+ +-------+ 1261 +--------------+ | ingress egress | 1262 | | 1263 +--------------+ | | 1264 | LLN PHY | | | 1265 +--------------+ | | 1266 | TSCH MAC | | | 1267 +--------------+ | dmac = | dmac = 1268 |ISA100/WiHART | | nexthop v nexthop 1269 +--------------+ 1271 Figure 5: Track Forwarding, Tunnel Mode 1273 In that case, the flow information that identifies the Track at the 1274 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 1275 to this node but the flow information indicates that the frame must 1276 be tunneled over a particular Track so the frame is not passed to the 1277 upper layer. Instead, the dmac is forced to broadcast and the frame 1278 is passed to the 6top sublayer for switching. 1280 At the egress 6TiSCH router, the reverse operation occurs. Based on 1281 metadata associated to the Track, the frame is passed to the 1282 appropriate link layer with the destination MAC restored. 1284 4.2.2.2.2.2.3. Tunnel Metadata 1286 Metadata coming with the Track configuration is expected to provide 1287 the destination MAC address of the egress endpoint as well as the 1288 tunnel mode and specific data depending on the mode, for instance a 1289 service access point for frame delivery at egress. If the tunnel 1290 egress point does not have a MAC address that matches the 1291 configuration, the Track installation fails. 1293 In transport mode, if the final layer-3 destination is the tunnel 1294 termination, then it is possible that the IPv6 address of the 1295 destination is compressed at the 6LoWPAN sublayer based on the MAC 1296 address. It is thus mandatory at the ingress point to validate that 1297 the MAC address that was used at the 6LoWPAN sublayer for compression 1298 matches that of the tunnel egress point. For that reason, the node 1299 that injects a packet on a Track checks that the destination is 1300 effectively that of the tunnel egress point before it overwrites it 1301 to broadcast. The 6top sublayer at the tunnel egress point reverts 1302 that operation to the MAC address obtained from the tunnel metadata. 1304 4.2.2.2.2.2.4. OAM 1306 An Overview of Operations, Administration, and Maintenance (OAM) 1307 Tools [RFC7276] provides an overwiew of the existing tooling for OAM 1308 [RFC6291]. Tracks are complex paths and new tooling is necessary to 1309 manage them, with respect to load control, timing, and the Packet 1310 Replication and Elimination Functions (PREF). 1312 An example of such tooling can be found in the context of BIER 1313 [RFC8279] and more specifically BIER Traffic Engineering 1314 [I-D.ietf-bier-te-arch] (BIER-TE): 1315 [I-D.thubert-bier-replication-elimination] leverages BIER-TE to 1316 control the process of PREF, and to provide traceability of these 1317 operations, in the deterministic dataplane, along a complex Track. 1318 For the 6TiSCH type of constrained environment, 1319 [I-D.thubert-6lo-bier-dispatch] enables an efficient encoding of the 1320 BIER bitmap within the 6LoRH framework. 1322 5. 3GPP standards 1324 6. IANA Considerations 1326 This specification does not require IANA action. 1328 7. Security Considerations 1330 Most RAW technologies integrate some authentication or encryption 1331 mechanisms that were defined outside the IETF. 1333 8. Acknowledgments 1335 Many thanks to the participants of the RAW WG where a lot of the work 1336 discussed here happened. 1338 9. References 1340 9.1. Normative References 1342 [I-D.ietf-6tisch-architecture] 1343 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1344 of IEEE 802.15.4", draft-ietf-6tisch-architecture-21 (work 1345 in progress), June 2019. 1347 [I-D.ietf-detnet-architecture] 1348 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1349 "Deterministic Networking Architecture", draft-ietf- 1350 detnet-architecture-13 (work in progress), May 2019. 1352 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 1353 Phinney, "Industrial Routing Requirements in Low-Power and 1354 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 1355 2009, . 1357 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1358 (IPv6) Specification", STD 86, RFC 8200, 1359 DOI 10.17487/RFC8200, July 2017, 1360 . 1362 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 1363 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 1364 DOI 10.17487/RFC8480, November 2018, 1365 . 1367 9.2. Informative References 1369 [Cavalcanti_2019] 1370 Dave Cavalcanti et al., "Extending Time Distribution and 1371 Timeliness Capabilities over the Air to Enable Future 1372 Wireless Industrial Automation Systems, the Proceedings of 1373 IEEE", June 2019. 1375 [CCAMP] IETF, "Common Control and Measurement Plane", 1376 . 1378 [dearmas16] 1379 Jesica de Armas et al., "Determinism through path 1380 diversity: Why packet replication makes sense", September 1381 2016. 1383 [Ghasempour_2017] 1384 Yasaman Ghasempour et al., "802.11ay: Next-Generation 60 1385 GHz Communications for 100 Gb/s Wi-Fi", December 2017. 1387 [I-D.ietf-6tisch-coap] 1388 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 1389 Interaction using CoAP", draft-ietf-6tisch-coap-03 (work 1390 in progress), March 2015. 1392 [I-D.ietf-6tisch-msf] 1393 Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and 1394 D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", 1395 draft-ietf-6tisch-msf-03 (work in progress), April 2019. 1397 [I-D.ietf-bier-te-arch] 1398 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 1399 Engineering for Bit Index Explicit Replication (BIER-TE)", 1400 draft-ietf-bier-te-arch-02 (work in progress), May 2019. 1402 [I-D.ietf-roll-nsa-extension] 1403 Koutsiamanis, R., Papadopoulos, G., Montavont, N., and P. 1404 Thubert, "RPL DAG Metric Container Node State and 1405 Attribute object type extension", draft-ietf-roll-nsa- 1406 extension-01 (work in progress), March 2019. 1408 [I-D.papadopoulos-paw-pre-reqs] 1409 Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P. 1410 Thubert, "Exploiting Packet Replication and Elimination in 1411 Complex Tracks in LLNs", draft-papadopoulos-paw-pre- 1412 reqs-01 (work in progress), March 2019. 1414 [I-D.svshah-tsvwg-deterministic-forwarding] 1415 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 1416 draft-svshah-tsvwg-deterministic-forwarding-04 (work in 1417 progress), August 2015. 1419 [I-D.thubert-6lo-bier-dispatch] 1420 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 1421 6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-06 1422 (work in progress), January 2019. 1424 [I-D.thubert-bier-replication-elimination] 1425 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 1426 TE extensions for Packet Replication and Elimination 1427 Function (PREF) and OAM", draft-thubert-bier-replication- 1428 elimination-03 (work in progress), March 2018. 1430 [IEEE80211] 1431 "IEEE Standard 802.11 - IEEE Standard for Information 1432 Technology - Telecommunications and information exchange 1433 between systems Local and metropolitan area networks - 1434 Specific requirements - Part 11: Wireless LAN Medium 1435 Access Control (MAC) and Physical Layer (PHY) 1436 Specifications.". 1438 [IEEE80211ad] 1439 "802.11ad: Enhancements for very high throughput in the 60 1440 GHz band". 1442 [IEEE80211ak] 1443 "802.11ak: Enhancements for Transit Links Within Bridged 1444 Networks", 2017. 1446 [IEEE80211ax] 1447 "802.11ax D4.0: Enhancements for High Efficiency WLAN". 1449 [IEEE80211ay] 1450 "802.11ay: Enhanced throughput for operation in license- 1451 exempt bands above 45 GHz". 1453 [IEEE80211be] 1454 "802.11be: Extreme High Throughput". 1456 [IEEE802154] 1457 IEEE standard for Information Technology, "IEEE Std. 1458 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1459 and Physical Layer (PHY) Specifications for Low-Rate 1460 Wireless Personal Area Networks". 1462 [IEEE8021Qat] 1463 "802.1Qat: Stream Reservation Protocol". 1465 [IEEE8021Qcc] 1466 "802.1Qcc: IEEE Standard for Local and Metropolitan Area 1467 Networks--Bridges and Bridged Networks -- Amendment 31: 1468 Stream Reservation Protocol (SRP) Enhancements and 1469 Performance Improvements". 1471 [IEEE_doc_11-18-2009-06] 1472 "802.11 Real-Time Applications (RTA) Topic Interest Group 1473 (TIG) Report", November 2018. 1475 [IEEE_doc_11-19-0373-00] 1476 Kevin Stanton et Al., "Time-Sensitive Applications Support 1477 in EHT", March 2019. 1479 [ISA100.11a] 1480 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 1481 also IEC 62734", 2011, < http://www.isa100wci.org/en- 1482 US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- 1483 WEB-ETSI.aspx>. 1485 [morell13] 1486 Antoni Morell et al., "Label switching over IEEE802.15.4e 1487 networks", April 2013. 1489 [Nitsche_2015] 1490 Thomas Nitsche et al., "IEEE 802.11ad: directional 60 GHz 1491 communication for multi-Gigabit-per-second Wi-Fi", 1492 December 2014. 1494 [PCE] IETF, "Path Computation Element", 1495 . 1497 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1498 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1499 Acronym in the IETF", BCP 161, RFC 6291, 1500 DOI 10.17487/RFC6291, June 2011, 1501 . 1503 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1504 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1505 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1506 Low-Power and Lossy Networks", RFC 6550, 1507 DOI 10.17487/RFC6550, March 2012, 1508 . 1510 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1511 and D. Barthel, "Routing Metrics Used for Path Calculation 1512 in Low-Power and Lossy Networks", RFC 6551, 1513 DOI 10.17487/RFC6551, March 2012, 1514 . 1516 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1517 Weingarten, "An Overview of Operations, Administration, 1518 and Maintenance (OAM) Tools", RFC 7276, 1519 DOI 10.17487/RFC7276, June 2014, 1520 . 1522 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1523 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1524 Explicit Replication (BIER)", RFC 8279, 1525 DOI 10.17487/RFC8279, November 2017, 1526 . 1528 [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", 1529 . 1531 [vilajosana19] 1532 Xavier Vilajosana et al., "6TiSCH: Industrial Performance 1533 for IPv6 Internet-of-Things Networks", June 2019. 1535 [WirelessHART] 1536 www.hartcomm.org, "Industrial Communication Networks - 1537 Wireless Communication Network and Communication Profiles 1538 - WirelessHART - IEC 62591", 2010. 1540 Authors' Addresses 1542 Pascal Thubert (editor) 1543 Cisco Systems, Inc 1544 Building D 1545 45 Allee des Ormes - BP1200 1546 MOUGINS - Sophia Antipolis 06254 1547 FRANCE 1549 Phone: +33 497 23 26 34 1550 Email: pthubert@cisco.com 1552 Dave Cavalcanti 1553 Intel Corporation 1554 2111 NE 25th Ave 1555 Hillsboro, OR 97124 1556 USA 1558 Phone: 503 712 5566 1559 Email: dave.cavalcanti@intel.com 1561 Xavier Vilajosana 1562 Universitat Oberta de Catalunya 1563 156 Rambla Poblenou 1564 Barcelona, Catalonia 08018 1565 Spain 1567 Email: xvilajosana@uoc.edu