idnits 2.17.00 (12 Aug 2021) /tmp/idnits1261/draft-pthubert-raw-problem-statement-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 16, 2019) is 978 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CCAMP' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'PCE' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'TEAS' is defined on line 313, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-bernardos-raw-use-cases-00 == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: draft-ietf-detnet-architecture has been published as RFC 8655 == Outdated reference: A later version (-05) exists of draft-thubert-raw-technologies-03 Summary: 2 errors (**), 0 flaws (~~), 8 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 September 16, 2019 5 Expires: March 19, 2020 7 Reliable and Available Wireless Problem Statement 8 draft-pthubert-raw-problem-statement-00 10 Abstract 12 This document describes the problem space for Reliable and Available 13 Wireless at the IETF. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on March 19, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Use Cases and Requirements Served . . . . . . . . . . . . . . 4 51 3. Routing Scale vs. Forwarding Scale . . . . . . . . . . . . . 4 52 4. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 5 53 5. Functional Gaps . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 56 6.2. Informative References . . . . . . . . . . . . . . . . . 7 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 59 1. Introduction 61 IP networks become more predictable when the effects of statistical 62 multiplexing (jitter and collision loss) are eliminated. This 63 requires a tight control of the physical resources to maintain the 64 amount of traffic within the physical capabilities of the underlying 65 technology, e.g., by the use of time-shared resources (bandwidth and 66 buffers) per circuit, and/or by shaping and/or scheduling the packets 67 at every hop. 69 Deterministic Networking is an attempt to mostly eliminate packet 70 loss for a committed bandwidth with a guaranteed worst-case end-to- 71 end latency, even when co-existing with best-effort traffic in a 72 shared network. It is getting traction in various industries 73 including manufacturing, online gaming, professional A/V, cellular 74 radio and others, making possible many cost and performance 75 optimizations. 77 This innovation is enabled by recent developments in technologies 78 including IEEE 802.1 TSN (for Ethernet LANs) and IETF DetNet (for 79 wired IP networks). Reliable and Available Wireless (RAW) networking 80 services extend DetNet services to approach end-to-end deterministic 81 performances in a network with scheduled wireless segments, possibly 82 combined with wired segments, and possibly sharing physical resources 83 with non-deterministic traffic. 85 Wireless networks operate on a shared medium, and thus transmissions 86 cannot be fully deterministic due to uncontrolled interferences, 87 including the self-induced multipath fading. However, scheduling of 88 transmissions can alleviate those effects by leveraging diversity in 89 the spatial, time and frequency domains, providing a more predictable 90 and available service. 92 The wireless and wired media are fundamentally different at the 93 physical level, and while the generic Problem Statement for DetNet 94 applies to the wired as well as the wireless medium, the methods to 95 achieve RAW will differ from those used to support time-sensitive 96 networking over wires, and a RAW solution will need to address less 97 consistent transmissions, energy conservation and shared spectrum 98 efficiency. 100 The development of RAW technologies has been lagging behind 101 deterministic efforts for wired systems both at the IEEE and the 102 IETF. But recent efforts at the IEEE and 3GPP indicate that wireless 103 is finally catching up at the lower layer and that it is now possible 104 for the IETF to extend DetNet for wireless segments that are capable 105 of scheduled wireless transmissions. 107 The establishment of the path is out of scope, and may inherit from a 108 centralized Architecture as described for DetNet and 6TiSCH, with a 109 primary focus on scheduled wireless operations. As opposed to wire, 110 the action of setting up a path on a wireless network may be slow 111 compared to the speed at which the transmission conditions vary, and 112 the extra medium used for redundancy may be expensive. So in 113 wireless, it makes sense for a centralized router to provide multiple 114 forwarding solutions and leave it to the data plane to select which 115 of those solutions are used fir a given packet based on the current 116 conditions. 118 The scope of the RAW WG will be protocol elements such as OAM to 119 improve the forwarding decision along a path where intermediate nodes 120 are capable of transmission redundancy, e.g., using packet 121 replication and elimination, Hybrid ARQ and coding, but is 122 constrained so as not to overuse this methods, eg., because energy 123 and spectrum are limited. 125 RAW should stay abstract to the radio layer (keep a layered 126 approach). How the PHY is programmed, and whether the radio is 127 single-hop or meshed, are unknown at the IP layer and not part of the 128 RAW abstraction. 130 Still, in order to focus on real-worlds issues and assert the 131 feasibility of the proposed capabilities, RAW will focus on selected 132 technologies that can be scheduled at the lower layers: IEEE Std. 133 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable 134 low latency communications (URLLC), IEEE 802.11ax/be where 802.11be 135 is extreme high throughput (EHT), and L-band Digital Aeronautical 136 Communications System (LDACS). See [I-D.thubert-raw-technologies] 137 for more. 139 RAW distinguishes the time scale at which routes are computed that we 140 qualify as slow from the forwarding time scale where per-packet 141 decisions are made. RAW operates at the forwarding time scale on one 142 DetNet flow over one Track that is preestablished and installed by 143 means outside of the scope of RAW. This is discussed in more details 144 in Section 3 and the next sections. 146 2. Use Cases and Requirements Served 148 [RFC8578] presents a number of wireless use cases including Wireless 149 for Industrial Applications. [I-D.bernardos-raw-use-cases] adds a 150 number of use cases that demonstrate the need for RAW capabilities in 151 Pro-Audio, gaming and robotics. 153 3. Routing Scale vs. Forwarding Scale 155 RAW extends DetNet to focus on issues that are mostly a concern on 156 wireless links. See [I-D.ietf-detnet-architecture] for more on 157 DetNet. With DetNet, the end-to-end routing can be centralized and 158 can reside outside the network. In wireless, and in particular in a 159 wireless mesh, the path to the controller that performs the route 160 computation and maintenance may be slow and expensive in terms of 161 critical resources such as air time and energy. 163 Reaching to the routing computation can be slow in regards to the 164 speed of events that affect the forwarding operation at the radio 165 layer. Due to the cost and latency to perform a route computation, 166 routing is not expected to be sensitive/reactive to transient 167 changes. The abstraction of a link at the routing level is expected 168 to use statistical operational metrics that aggregate the behavior of 169 a link over long periods of time, and represent its availability as a 170 shade of gray as opposed to either up or down. 172 In the case of wireless, the changes that affect the forwarding 173 decision can happen frequently and often for shot durations, e.g., a 174 mobile object moves between a transmitter and a receiver, and will 175 cancel the line of sight transmission for a few seconds, or a radar 176 measures the depth of a pool and interferes on a particular channel 177 for a split second. 179 There is thus a desire to separate the long term computation of the 180 route and the short term forwarding decision. In such a model, the 181 routing operation computes a complex Track that enables multiple non- 182 equal cost multipath (N-ECMP) forwarding solutions, and leaves it to 183 the forwarding plane to make the per-packet decision of which of 184 these possibilities should be used. 186 In the case of wires, the concept is known in traffic engineering 187 where an alternate path can be used upon the detection of a failure 188 in the main path, e.g., using OAM in MPLS-TP or BFD over a collection 189 of SD-WAN tunnels. RAW formalizes a routing time scale that is order 190 of magnitude longer than the forwarding time scale, and separates the 191 protocols and metrics that are used at both scales. Routing can 192 operate on long term statistics such as delivery ratio over minutes 193 to hours, but as a first approximation can ignore flapping. On the 194 other hand, the RAW forwarding decision is made at packet speed, and 195 uses information that must be pertinent at the present time for the 196 current transmission. 198 4. Prerequisites 200 A prerequisite to the RAW work is that an end-to-end routing function 201 computes a complex sub-topology along which forwarding can happen 202 between a source and one or more destinations. For 6TiSCH, this is a 203 Track. The concept of Track is specified in the 204 [I-D.ietf-6tisch-architecture]. Tracks provide a high degree of 205 redundancy and diversity and enable DetNet PREOF, end-to-end network 206 coding, and possibly radio-specific abstracted techniques such as 207 ARQ, overhearing, frequency diversity, time slotting, and possibly 208 others. 210 How the routing operation computes the Track is out of scope for RAW. 211 The scope of the RAW operation is one Track, and the goal of the RAW 212 operation is to optimize the use of the Track at the forwarding 213 timescale to maintain the expected service while optimizing the usage 214 of constrained resources such as energy and spectrum. 216 Another prerequisite is that an IP link can be established over the 217 radio with some guarantees in terms of service reliability, e.g., it 218 can be relied upon to transmit a packet within a bounded latency and 219 provides a guaranteed BER/PDR outside rare but existing transient 220 outage windows that can last from split seconds to minutes. The 221 radio layer can be programmed with abstract parameters, and can 222 return an abstract view of the state of the Link to help forwarding 223 decision (think DLEP from MANET). In the layered approach, how the 224 radio manages its PHY layer is out of control and out of scope. 225 Whether it is single hop or meshed is also unknown and out of scope. 227 5. Functional Gaps 229 Within a large routed topology, the routing operation builds a 230 particular complex Track with one source and one or more 231 destinations; within the Track, packets may follows different paths 232 and may be subject to RAW forwarding operations that include 233 replication, elimination, retries, overhearing and reordering. 235 The RAW forwarding decisions include the selection of points of 236 replication and elimination, how many retries can take place, and 237 cccccckehblnlcbljtkbcdkrhrjgiibvcidbklbglndf a limit of validity for 238 the packet beyond which the packet should be destroyed rather than 239 forwarded uselessly further down the Track. 241 The decision to apply the RAW techniques must be done quickly, and 242 depends on a very recent and precise knowledge of the forwarding 243 conditions withing the complex Track. There is a need for an 244 observation method to provide the RAW forwarding plane with the 245 specific knowledge of the state of the Track for the type of flow of 246 interest (e.g., for a QoS level of interest). To observe the whole 247 Track in quasi real time, RAW will consider existing tools such as 248 L2-triggers, DLEP, BFD and inband and out-of-band OAM. 250 One possible way of making the RAW forwarding decisions is to make 251 them all at the ingress and express them in-band in the packet, which 252 requires new loose or strict Hop-by-hop signaling. To control the 253 RAW forwarding operation along a Track for the individual packets, 254 RAW may leverage and extend known techniques such as Segment Routing 255 (SRv6) or BIER-TE such as done with 256 [I-D.thubert-bier-replication-elimination]. 258 An alternate way is to enable each forwarding node to make the RAW 259 forwarding decisions for a packet on its own, based on its knowledge 260 of the expectation (timeliness and reliability) for that packet and a 261 recent observation of the rest of the way across the possible paths 262 within the Track. Information about the service should be placed in 263 the packet and matched with the forwarding node's capabilities and 264 policies. 266 In either case, a per-flow state is installed in all intermediate 267 nodes to recognize the flow and determine the forwarding policy to be 268 applied. 270 6. References 272 6.1. Normative References 274 [I-D.bernardos-raw-use-cases] 275 Papadopoulos, G., Thubert, P., Theoleyre, F., and C. 276 Bernardos, "RAW use cases", draft-bernardos-raw-use- 277 cases-00 (work in progress), July 2019. 279 [I-D.ietf-6tisch-architecture] 280 Thubert, P., "An Architecture for IPv6 over the TSCH mode 281 of IEEE 802.15.4", draft-ietf-6tisch-architecture-26 (work 282 in progress), August 2019. 284 [I-D.ietf-detnet-architecture] 285 Finn, N., Thubert, P., Varga, B., and J. Farkas, 286 "Deterministic Networking Architecture", draft-ietf- 287 detnet-architecture-13 (work in progress), May 2019. 289 [I-D.thubert-raw-technologies] 290 Thubert, P., Cavalcanti, D., Vilajosana, X., and C. 291 Schmitt, "Reliable and Available Wireless Technologies", 292 draft-thubert-raw-technologies-03 (work in progress), July 293 2019. 295 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 296 RFC 8578, DOI 10.17487/RFC8578, May 2019, 297 . 299 6.2. Informative References 301 [CCAMP] IETF, "Common Control and Measurement Plane", 302 . 304 [I-D.thubert-bier-replication-elimination] 305 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 306 TE extensions for Packet Replication and Elimination 307 Function (PREF) and OAM", draft-thubert-bier-replication- 308 elimination-03 (work in progress), March 2018. 310 [PCE] IETF, "Path Computation Element", 311 . 313 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 314 . 316 Author's Address 318 Pascal Thubert (editor) 319 Cisco Systems, Inc 320 Building D 321 45 Allee des Ormes - BP1200 322 MOUGINS - Sophia Antipolis 06254 323 FRANCE 325 Phone: +33 497 23 26 34 326 Email: pthubert@cisco.com