idnits 2.17.1 draft-thubert-raw-technologies-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 (May 21, 2019) is 1800 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'IEEE802154' is defined on line 249, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-20 Summary: 0 errors (**), 0 flaws (~~), 6 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 May 21, 2019 5 Expires: November 22, 2019 7 Reliable and Available Wireless Technologies 8 draft-thubert-raw-technologies-00 10 Abstract 12 This document presents a series of recent technologies that are 13 capable of time synchronization and scheduling of transmission, 14 making them suitable to carry time-sensitive flows with requirements 15 of both reliable delivery in bounded time, and availability at all 16 times, regardless of packet transmission or individual equipement 17 failures. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 22, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. On Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Benefits of Scheduling on Wires . . . . . . . . . . . . . 4 57 3.2. Benefits of Scheduling on Wireless . . . . . . . . . . . 4 58 4. tech X . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Provenance and Documents . . . . . . . . . . . . . . . . 5 60 4.2. General Characteristics . . . . . . . . . . . . . . . . . 5 61 4.3. Applicability to deterministic flows . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 When used in math or philosophy, the term "deterministic" generally 73 refers to a perfection where all aspect are understood and 74 predictable. A perfectly Deterministic Network would ensure that 75 every packet reach its destination following a predetermined path 76 along a predefined schedule to be delivered at the exact due time. 77 In a real and imperfect world, a Deterministic Network must highly 78 predictable, which is a combination of reliability and availability. 79 On the one hand the network must be reliable, meaning that it will 80 perform as expected for all packets and in particular that it will 81 always deliver the packet at the destination in due time. On the 82 other hand, the network must be available, meaning that it is 83 resilient to any single outage, whether the cause is a software, a 84 hardware or a transmission issue. 86 RAW (Reliable and Available Wireless) is an effort to provide 87 Deterministic Networking on across a path that include a a wireless 88 physical layer. Making Wireless Reliable and Available is even more 89 challenging than it is with wires, due to the numerous causes of loss 90 in transmission that add up to the congestion losses and the delays 91 caused by overbooked shared resources. In order to maintain a 92 similar quality of service along a multihop path that is composed of 93 wired and wireless hops, additional methods that are specific to 94 wireless must be leveraged to combat the sources of loss that are 95 also specific to wireless. 97 Such wireless-specific methods include per-hop retransmissions (HARQ) 98 and P2MP overhearing whereby multiple receivers are scheduled to 99 receive the same transmission, which balances the adverse effects of 100 the transmission losses that are eperienced when a radio is used as 101 pure P2P. 103 2. Terminology 105 This specification uses a number of terms that are uncommon on 106 protocols that ensure bets effort transmissions for stochastics 107 flows, such as found in the traditional Internet and other 108 statistically multiplexed packet networks. 110 Reliable: That consistently performs as expected, the expectation 111 for a network being to always deliver a packet in due time. 113 Available: That is exempt of unscheduled outage, the expectation for 114 a network being that the flow is maintained in the face of any 115 single breakage. 117 PAREO (functions): the wireless extension of DetNet PREOF. PAREO 118 functions include scheduled ARQ at selected hops, and expect 119 the use of new operations like overhearing where available. 121 Track: A DODAG oriented to a destination,and that enables Packet 122 ARQ, Replication, Elimination, and Ordering Functions. 124 ARQ: Automatic Repeat Request, enabling an acknowledged 125 transmission, which is the typical model at Layer-2 on a 126 wireless medium. 128 HARQ: Forward error correction, sending redundant coded data to help 129 the receiver recover transmission errors. 131 HARQ: Hybrid ARQ, a combination of FEC and ARQ . 133 3. On Scheduling 135 The operations of a Deterministic Network often rely on precisely 136 applying a tight schedule, in order to avoid collision loss and 137 guarantee the worst case time of delivery . To achieve this, there 138 must be a shared sense of time throughout the network. The sense of 139 time is usually provided by the lower layer and is not in scope for 140 RAW. 142 3.1. Benefits of Scheduling on Wires 144 A network is reliable when the statistical effects that affect the 145 packet transmission are eliminated. This involves maintaining at all 146 time the amount of critical packets within the physical capabilities 147 of the hardware and that of the radio medium. This is achieved by 148 controlling the use of time-shared resources such as CPUs and 149 buffers, by shaping the flows and by scheduling the time of 150 transmission of the packets that compose the flow at every hop. 152 Equipment failure, such as an access point rebooting, a broken radio 153 adapter, or a permanent obstacle to the transmission, is a secondary 154 source of packet loss. When a breakage occurs, multiple packets are 155 lost in a row before the flows are rerouted or the system may 156 recover. This is not acceptable for critical applications such as 157 related to safety. A typical process control loop will tolerate an 158 occasional packet loss, but a loss of several packets in a row will 159 cause an emergency stop (e.g., after 4 packets lost, within a period 160 of 1 second). 162 Network Availability is obtained by making the transmission resilient 163 against hardware failures and radio transmission losses due to 164 uncontrolled events such as co-channel interferers, multipath fading 165 or moving obstacles. The best results are typically achieved by 166 pseudo randomly cumulating all forms of diversity, in the spatial 167 domain with replication and elimination, in the time domain with ARQ 168 and diverse scheduled transmissions, and in the frequency domain with 169 frequency hopping or channel hopping between frames. 171 3.2. Benefits of Scheduling on Wireless 173 In addition to the benefits listed in Section 3.1, scheduling 174 transmissions provides specific value to the wireless medium. 176 On the one hand, scheduling avoids collisions between scheduled 177 transmissions and can ensure both time and frequency diversity 178 between retries in order to defeat co-channel interference from 179 uncontroller transmitters as well as multipath fading. Transmissions 180 can be scheduled on multiple channels in parallel, which enables to 181 use the full available spectrum while avoiding the hidden terminal 182 problem, e.g., when the next packet in a same flow interferes on a 183 same channel with the previous one that progressed a few hops 184 farther. 186 On the other hand, scheduling optimizes the bandwidth usage: compared 187 to classical Collision Avoidance techniques, there is no blank time 188 related to inter-frame space (IFS) and exponential back-off in 189 scheduled operations. A minimal Clear Channel Assessment may be 190 needed to comply with the local regulations such as ETSI 300-328, but 191 that will not detect a collision when the senders are synchronized. 192 And because scheduling allows a time sharing operation, there is no 193 limit to the ratio of isolated critical traffic. 195 Finally, scheduling plays a critical role to save energy. In IOT, 196 energy is the foremost concern, and synchronizing sender and listener 197 enables to maintain them in deep sleep at all times when there is no 198 scheduled transmission. This avoids idle listening and long 199 preambles and enables long sleep periods between traffic and 200 resynchronization, allowing battery-operated nodes to operate in a 201 mesh topology for multiple years. 203 4. tech X 205 4.1. Provenance and Documents 207 4.2. General Characteristics 209 4.3. Applicability to Deterministic Flows 211 5. IANA Considerations 213 This specification does not require IANA action. 215 6. Security Considerations 217 Most RAW technologies integrate some authentication or encryption 218 mechanisms that were defined outside the IETF. 220 7. Acknowledgments 222 Many thanks to the participants of the RAW WG where a lot of the work 223 discussed here happened. 225 8. References 227 8.1. Normative References 229 [I-D.ietf-6tisch-architecture] 230 Thubert, P., "An Architecture for IPv6 over the TSCH mode 231 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 232 in progress), March 2019. 234 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 235 (IPv6) Specification", STD 86, RFC 8200, 236 DOI 10.17487/RFC8200, July 2017, 237 . 239 8.2. Informative References 241 [IEEE80211] 242 "IEEE Standard 802.11 - IEEE Standard for Information 243 Technology - Telecommunications and information exchange 244 between systems Local and metropolitan area networks - 245 Specific requirements - Part 11: Wireless LAN Medium 246 Access Control (MAC) and Physical Layer (PHY) 247 Specifications.". 249 [IEEE802154] 250 IEEE standard for Information Technology, "IEEE Std. 251 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 252 and Physical Layer (PHY) Specifications for Low-Rate 253 Wireless Personal Area Networks". 255 Author's Address 257 Pascal Thubert (editor) 258 Cisco Systems, Inc 259 Building D 260 45 Allee des Ormes - BP1200 261 MOUGINS - Sophia Antipolis 06254 262 FRANCE 264 Phone: +33 497 23 26 34 265 Email: pthubert@cisco.com