idnits 2.17.00 (12 Aug 2021) /tmp/idnits5828/draft-ietf-raw-framework-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 (29 November 2021) is 166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7799' is defined on line 614, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-raw-architecture-01 == Outdated reference: A later version (-05) exists of draft-ietf-raw-technologies-04 == Outdated reference: A later version (-05) exists of draft-ietf-raw-use-cases-03 == Outdated reference: A later version (-04) exists of draft-ietf-detnet-ip-oam-03 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-11 == Outdated reference: A later version (-04) exists of draft-ietf-raw-oam-support-02 == Outdated reference: A later version (-13) exists of draft-mirsky-ippm-hybrid-two-step-11 == Outdated reference: A later version (-11) exists of draft-mirsky-bfd-mpls-demand-10 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-16 Summary: 0 errors (**), 0 flaws (~~), 11 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 L. Berger 5 Expires: 2 June 2022 LabN Consulting, L.L.C. 6 29 November 2021 8 Reliable and Available Wireless Framework 9 draft-ietf-raw-framework-00 11 Abstract 13 Reliable and Available Wireless (RAW) provides for high reliability 14 and availability for IP connectivity over a wireless medium. The 15 wireless medium presents significant challenges to achieve 16 deterministic properties such as low packet error rate, bounded 17 consecutive losses, and bounded latency. This document defines the 18 RAW Architecture following an OODA loop that involves OAM, PCE, PSE 19 and PAREO functions. It builds on the DetNet Architecture and 20 discusses specific challenges and technology considerations needed to 21 deliver DetNet service utilizing scheduled wireless segments and 22 other media, e.g., frequency/time-sharing physical media resources 23 with stochastic traffic. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 2 June 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Use Cases and Requirements Served . . . . . . . . . . . . . . 4 60 2.1. Radio Access Protection . . . . . . . . . . . . . . . . . 4 61 2.2. End-to-End Protection in a Wireless Mesh . . . . . . . . 5 62 3. Related Work at The IETF . . . . . . . . . . . . . . . . . . 5 63 4. Scope and Prerequisites . . . . . . . . . . . . . . . . . . . 6 64 5. Wireless Tracks . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Flow Identification vs. Path Identification . . . . . . . . . 7 66 7. Source-Routed vs. Distributed Forwarding Decision . . . . . . 10 67 8. Encapsulation and Decapsulation . . . . . . . . . . . . . . . 11 68 9. Operations Administration and Maintenance . . . . . . . . . . 11 69 9.1. DetNet OAM . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.2. RAW Extensions . . . . . . . . . . . . . . . . . . . . . 12 71 9.3. Observed Metrics . . . . . . . . . . . . . . . . . . . . 13 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 10.1. Forced Access . . . . . . . . . . . . . . . . . . . . . 13 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 13.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 Wireless networks operate on a shared medium where uncontrolled 84 interference, including the self-induced multipath fading, cause 85 random transmission losses and add new dimensions to the statistical 86 effects that affect reachability and packet delivery. 88 To defeat those additional causes of transmission delay and loss, 89 Reliable and Available Wireless (RAW) leverages deterministic layer-2 90 capabilities with diversity in the spatial, time, code, technology, 91 and frequency domains. The challenge is to provide enough diversity 92 and redundancy to ensure the timely packet delivery while preserving 93 energy and optimizing the use of the shared spectrum. 95 The "RAW Architecture" [RAW-ARCHI] document presents the RAW problem 96 and architectural concepts such as path and Tracks to provide IPv6 97 [IPv6] flows with Service Level Objectives (SLO) in terms of packet 98 delivery ratio (PDR), maximum contiguous losses or lantency 99 boundaries over wireless access and meshes. 101 RAW distinguishes the longer time scale at which routes are computed 102 from the the shorter forwarding time scale where per-packet decisions 103 are made. RAW operates within the Network Plane at the forwarding 104 time scale on one DetNet flow over a complex path called a Track. 105 The Track is preestablished and installed by means outside of the 106 scope of RAW; it may be strict or loose depending on whether each or 107 just a subset of the hops are observed and controlled by RAW. 109 The RAW Architecture is structured as an OODA Loop (Observe, Orient, 110 Decide, Act). It involves: 112 1. Network Plane measurement protocols for Operations, 113 Administration and Maintenance (OAM) to Observe some or all hops 114 along a Track as well as the end-to-end packet delivery 116 2. Controller plane elements to reports the links statistics to a 117 Path computation Element (PCE) in a centralized controller that 118 computes and installs the Tracks and provides meta data to Orient 119 the routing decision 121 3. A Runtime distributed Path Selection Engine (PSE) that Decides 122 which subTrack to use for the next packet(s) that are routed 123 along the Track 125 4. Packet (hybrid) ARQ, Replication, Elimination and Ordering 126 Dataplane actions that operate at the DetNet Service Layer to 127 increase the reliability of the end-to-end transmission. The RAW 128 architecture also covers in-situ signalling when the decision is 129 Acted by a node that down the Track from the PSE. 131 The RAW Framework combines IETF specification to enable RAW Service 132 Level Agreements (SLA) over a selected technologies [RAW-TECHNOS]. 133 The framework implements the OODA loop to optimizes the use of 134 redundancy while minimizing the use of constrained resources such as 135 spectrum and battery. 137 2. Use Cases and Requirements Served 139 In order to focus on real-worlds issues and assert the feasibility of 140 the proposed capabilities, RAW focuses on selected technologies that 141 can be scheduled at the lower layers: IEEE Std. 802.15.4 timeslotted 142 channel hopping (TSCH), 3GPP 5G ultra-reliable low latency 143 communications (URLLC), IEEE 802.11ax/be where 802.11be is extreme 144 high throughput (EHT), and L-band Digital Aeronautical Communications 145 System (LDACS). See [RAW-TECHNOS] for more. 147 "Deterministic Networking Use Cases" [RFC8578] presents a number of 148 wireless use cases including Wireless, such as application to 149 Industrial Applications, Pro-Audio, and SmartGrid Automation. 150 [RAW-USE-CASES] adds a number of use cases that demonstrate the need 151 for RAW capabilities for new applications such as Pro-Gaming and 152 drones. The use cases can be abstracted in two families, Loose 153 Protection, e.g., protecting the first hop in Radio Access Protection 154 and Strict Protection, e.g., providing End-to-End Protection in a 155 wireless mesh. 157 2.1. Radio Access Protection 159 To maintain the required SLA at all times, a wireless Host may use 160 more than one Radio Access Network (RAN) in parallel. 162 ... .. 163 RAN 1 ----- ... .. ... 164 / . .. .... 165 +--------+ / . .... +-----------+ 166 |Wireless|- . ..... | Service | 167 | Device |-***-- RAN 2 -- . Internet ....---| / | 168 |(STA/UE)|- .. ..... |Application| 169 +--------+ $$$ . ....... +-----------+ 170 \ ... ... ..... 171 RAN n -------- ... ..... 173 *** = flapping at this time $$$ expensive 175 Figure 1: Radio Access Protection 177 The RANs may be heterogeneous, e.g., 3GPP 5G [RAW-5G] and Wi-Fi 178 [RAW-TECHNOS] for high-speed communication, in which case a Layer-3 179 abstraction becomes useful to select which of the RANs are used at a 180 particular point of time, and the amount of traffic that is 181 distributed over each RAN. 183 The idea is that the rest of the path to the destination(s) is 184 protected separately (e.g., uses non-congruent paths, leverages 185 DetNet / TSN, etc...) and is a lot more reliable, e.g., wired. In 186 that case, RAW observes the reliability of the end-to-end operation 187 through each of the RANs but only observes and controls the wireless 188 operation the first hop. 190 A variation of that use case has a pair of wireless Hosts connected 191 over a wired core / backbone network. In that case, RAW observes and 192 controls the Ingress and Egress RANs, while neglecting the hops in 193 the core. The resulting loose Track may be instantiated, e.g., using 194 tunneling or loose source routing between the RANs. 196 2.2. End-to-End Protection in a Wireless Mesh 198 In radio technologies that support mesh networking (e.g., Wi-Fi and 199 TSCH), a Track is a complex path with distributed PAREO capabilities. 200 In that case, RAW operates through the multipath and makes decisions 201 either at the Ingress or at every hop (more in Section 5). 203 A-------B-------C-----D 204 / \ / / \ 205 Ingress ----M-------N--zzzzz--- Egress 206 \ \ / / 207 P--zzz--Q-------------R 209 zzz = flapping now 211 Figure 2: End-to-End Protection 213 The Protection may be imposed by the source based on end-to-end OAM, 214 or performed hop-by-hop, in which case the OAM must enables the 215 intermediate Nodes to estimate the quality of the rest of the 216 feasible paths in the remainder of the Track to the destination. 218 3. Related Work at The IETF 220 RAW intersects with protocols or practices in development at the IETF 221 as follows: 223 * The Dynamic Link Exchange Protocol (DLEP) [RFC8175] from [MANET] 224 can be leveraged at each hop to derive generic radio metrics 225 (e.g., based on LQI, RSSI, queueing delays and ETX) on individual 226 hops. 228 * [detnet] provides an OAM framework with [DetNet-OAM] that applies 229 within the DetNet dataplane described in [DetNet-DP],which is 230 typically based on MPLS or IPv6 pseudowires. 232 * [BFD] detect faults in the path between an Ingress and an Egress 233 forwarding engines, but is unaware of the complexity of a path 234 with replication, and expects bidirectionality. BFD asynchronous 235 mode considers delivery as success whereas with DetNet and RAW, 236 the bounded latency can be as important as the delivery itself, 237 and delivering too late is actually a failure. Note that the BFD 238 Demand mode with unsolicited notifications may be more suitable 239 then the Asynchronous BFD mode. The use of the Demand mode in 240 MPLS is analyzed in [I-D.mirsky-bfd-mpls-demand] and similar 241 considerations could apply to IP as well. 243 * [SPRING] and [BIER] define in-band signaling that influences the 244 routing when decided at the head-end on the path. There's already 245 one RAW-related draft at BIER [BIER-PREF] more may follow. RAW 246 will need new in-band signaling when the decision is distributed, 247 e.g., required chances of reliable delivery to destination within 248 latency. This signaling enables relays to tune retries and 249 replication to meet the required SLA. 251 * [CCAMP] defines protocol-independent metrics and parameters 252 (measurement attributes) for describing links and paths that are 253 required for routing and signaling in technology-specific 254 networks. RAW would be a source of requirements for CCAMP to 255 define metrics that are significant to the focus radios. 257 * [IPPM] develops and maintains standard metrics that can be applied 258 to the quality, performance, and reliability of Internet data 259 delivery services and applications running over transport layer 260 protocols (e.g. TCP, UDP) over IP. 262 4. Scope and Prerequisites 264 A prerequisite to the RAW operation is that an end-to-end routing 265 function computes a complex sub-topology along which forwarding can 266 happen between a source and one or more destinations. The concept of 267 Track is specified in the 6TiSCH Architecture [6TiSCH-ARCHI] to 268 represent that complex sub-topology. Tracks provide a high degree of 269 redundancy and diversity and enable the DetNet PREOF, network coding, 270 and possibly RAW specific techniques such as PAREO, leveraging 271 frequency diversity, time diversity, and possibly other forms of 272 diversity as well. 274 How the routing operation (e.g., PCE) in the Controller Plane 275 computes the Track is out of scope for RAW. The scope of the RAW 276 operation is one Track, and the goal of the RAW operation is to 277 optimize the use of the Track at the forwarding timescale to maintain 278 the expected SLA while optimizing the usage of constrained resources 279 such as energy and spectrum. 281 Another prerequisite is that an IP link can be established over the 282 radio with some guarantees in terms of service reliability, e.g., it 283 can be relied upon to transmit a packet within a bounded latency and 284 provides a guaranteed BER/PDR outside rare but existing transient 285 outage windows that can last from split seconds to minutes. The 286 radio layer can be programmed with abstract parameters, and can 287 return an abstract view of the state of the Link to help the Network 288 Layer forwarding decision (think DLEP from MANET). 290 How the radio interface manages its lower layers is out of control 291 and out of scope for RAW. In the same fashion, the non-RAW portion 292 along a loose Track is by definition out of control and out of scope 293 for RAW. Whether it is a single hop or a mesh is also unknown and 294 out of scope. 296 5. Wireless Tracks 298 The "6TiSCH Architecture" [6TiSCH-ARCHI] introduces the concept of 299 Track. RAW extends the concept to any wireless mesh technology, 300 including, e.g., Wi-Fi. A simple Track is composed of a direct 301 sequence of reserved hops to ensure the transmission of a single 302 packet from a source Node to a destination Node across a multihop 303 path. 305 A Complex Track provides multiple N-ECMP forwarding solutions. The 306 Complex Track enables to support multi-path redundant forwarding by 307 employing PRE functions [RFC8655] and the ingress and within the 308 Track. For example, a Complex Track may branch off and rejoin over 309 non-congruent segments. 311 In the context of RAW, some links or segments in the Track may be 312 reversible, meaning that they can be used in either direction. In 313 that case, an indication in the packet signals the direction of the 314 reversible links or segments that the packet traverses and thus 315 places a constraint that prevents loops from occurring. An 316 individual packet follows a destination-oriented directed acyclic 317 graph (DODAG) towards a destination Node inside the Complex Track. 319 6. Flow Identification vs. Path Identification 321 Section 4.7 of the DetNet Architecture [RFC8655] ties the app-flow 322 identification which is an application-layer concept with the network 323 path identification that depends on the networking technology by 324 "exporting of flow identification", e.g., to a MPLS label. 326 With RAW, this exporting operation is injective but not bijective. 327 e.g., a flow is fully placed within one RAW Track, but not all 328 packets along that Track are necessarily part of the same flow. For 329 instance, out-of-band OAM packets must circulate in the exact same 330 fashion as the flows that they observe. It results that the flow 331 identification that maps to an application layer flowat the network 332 layer must be separate from the path identification that is used to 333 forward a packet. 335 Section 3.4 of the DetNet data-plane framework [DetNet-DP] indicates 336 that for a DetNet IP Data Plane, a flow is identified by an IPv6 337 6-tuple. With RAW, that 6-tuple is not what indicates the Track, in 338 other words, the flow ID is not the Track ID. 340 For instance, the 6TiSCH Architecture [6TiSCH-ARCHI] uses a 341 combination of the address of the Egress End System and an instance 342 identifier in a Hop-by-hop option to indicate a Track. This way, if 343 a packet "escapes" the Track, it will reach the Track Egress point 344 through normal routing and be treated at the service layer through, 345 say, elimination and reordering. 347 The RAW service includes forwarding over a subset of the Links that 348 form the Track (a subTrack). Packets from the same or a different 349 flow that are routed through the same Track will not necessarily 350 traverse the same Links. The PSE selects a subTrack for a packet 351 based on the links that are preferred and those that should be 352 avoided at this time. 354 Each packet is forwarded within the subTrack that provides the best 355 adequation with the SLA of the flow and the energy and bandwidth 356 constraints of the network. 358 Flow 1 (6-tuple) ----+ 359 | 360 Flow 2 (6-tuple) ---+ | 361 | | 362 OAM -----------+ | | 363 | | | 364 | | | 365 | | | | | 366 | v v v | 367 | | 368 +---------+---------+ 369 | 370 | 371 Track i (Ingress IP Address, RPLinstanceId) 372 | 373 | 374 | 375 +---------+-----+--....-------+ 376 | | | 377 | | | 378 subTrack 1 subTrack 2 subTrack n 379 | | | 380 | | | 381 V V V 382 +-----------------------------------+ 383 | | 384 | Destination | 385 | | 386 +-----------------------------------+ 388 Figure 3: Flow Injection 390 With 6TiSCH, packets are tagged with the same (destination address, 391 instance ID) will experience the same RAW service regardless of the 392 IPv6 6-tuple that indicates the flow. The forwarding does not depend 393 on whether the packets transport application flows or OAM. In the 394 generic case, the Track or the subTrack can be signaled in the packet 395 through other means, e.g., encoded in the suffix of the destination 396 address as a Segment Routing Service Instruction [SR-ARCHI], or 397 leveraging Bit Index Explicit Replication [BIER] Traffic Engineering 398 [BIER-TE]. 400 7. Source-Routed vs. Distributed Forwarding Decision 402 Within a large routed topology, the route-over mesh operation builds 403 a particular complex Track with one source and one or more 404 destinations; within the Track, packets may follow different paths 405 and may be subject to RAW forwarding operations that include 406 replication, elimination, retries, overhearing and reordering. 408 The RAW forwarding decisions include the selection of points of 409 replication and elimination, how many retries can take place, and a 410 limit of validity for the packet beyond which the packet should be 411 destroyed rather than forwarded uselessly further down the Track. 413 The decision to apply the RAW techniques must be done quickly, and 414 depends on a very recent and precise knowledge of the forwarding 415 conditions within the complex Track. There is a need for an 416 observation method to provide the RAW Data Plane with the specific 417 knowledge of the state of the Track for the type of flow of interest 418 (e.g., for a QoS level of interest). To observe the whole Track in 419 quasi real time, RAW considers existing tools such as L2-triggers, 420 DLEP, BFD and leverages in-band and out-of-band OAM to capture and 421 report that information to the PSE. 423 One possible way of making the RAW forwarding decisions within a 424 Track is to position a unique PSE at the Ingress and express its 425 decision in-band in the packet, which requires the explicit signaling 426 of the subTrack within the Track. In that case, the RAW forwarding 427 operation along the Track is encoded by the source, e.g., by 428 indicating the subTrack in the Segment Routing (SRv6) Service 429 Instruction, or by leveraging BIER-TE such as done with [BIER-PREF]. 431 The alternate way is to operate the PSE in each forwarding Node, 432 which makes the RAW forwarding decisions for a packet on its own, 433 based on its knowledge of the expectation (timeliness and 434 reliability) for that packet and a recent observation of the rest of 435 the way across the possible paths based on OAM. Information about 436 the desired service should be placed in the packet and matched with 437 the forwarding Node's capabilities and policies. 439 In either case, a per-track/subTrack state is installed in all the 440 intermediate Nodes to recognize the packets that are following a 441 Track and determine the forwarding operation to be applied. 443 8. Encapsulation and Decapsulation 445 In the generic case where the Track Ingress Node is not the source of 446 the Packet, the Ingress Node needs to encapsulate IP-in-IP to ensure 447 that the Destination IP Address is that of the Egress Node and that 448 the necessary Headers (Routing Header, Segment Routing Header and/or 449 Hop-By-Hop Header) can be added to the packet to signal the Track or 450 the subTrack, conforming [IPv6] that discourages the insertion of a 451 Header on the fly. 453 In the specific case where the Ingress Node is the source of the 454 packet, the encapsulation can be avoided, provided that the source 455 adds the necessary headers and that the destination is set to the 456 Egress Node. Forwarding to a final destination beyond the Egress 457 Node is possible, e.g., with a Segment Routing Header that signals 458 the rest of the way. In that case a Hop-by-Hop Header is not 459 recommmended since its validity is within the Track only. 461 9. Operations Administration and Maintenance 463 9.1. DetNet OAM 465 [detnet] provides an OAM framework with [DetNet-OAM] that applies 466 within the DetNet dataplane described in [DetNet-DP],which is 467 typically based on MPLS or IPv6 pseudowires. How the framework 468 applies to IPv6 is detailed in [DetNet-IP-OAM]. Within that 469 framework, OAM messages follow the same forward path as the data 470 packets and gather information about their individual treatment at 471 each hop. When the destination receives an OAM message, it gets a 472 view on the full path or at least of a segment of the path from the 473 source of the flow. 475 In-situ OAM (IOAM) adds telemetry information about the experience of 476 one packet within the packet itself [I-D.ietf-ippm-ioam-data], with 477 the caveats that the measurement and the consecutive update of the 478 packet interfere with the operation being observed, e.g., may 479 increase the latency of the packet for which it is measured and into 480 which it is stamped. 482 Note: IOAM and analogous on-path telemetry methods are capable of 483 facilitating collection of useful telemetry information that 484 characterizes the state of a system as experienced by the packet. 485 But because of statistical character of a packet network, these 486 methods may not be used to monitor the continuity of a path (Track) 487 or proper connectivity of the Track (no leaking packets across 488 Tracks). 490 This effect can be alleviated by measuring on the fly but reporting 491 later, e.g., by exporting the data as a separate management packet 492 [I-D.ietf-ippm-ioam-direct-export]. 493 [I-D.mirsky-ippm-hybrid-two-step] proposes an hybrid two-steps method 494 (HTS) where a trigger message starts the measurement and a follow up 495 along the Track packet gathers the measured data. 497 "Error Performance Measurement" [I-D.mirsky-ippm-epm] uses Fault 498 Management (FM) and Performance Management (PM) OAM mechanisms to 499 determine availability/unavailability of a path according to 500 predefined SLA. 502 9.2. RAW Extensions 504 Classical OAM typically measures information at the transmitter, 505 e.g., residence time in the node or transmit queue size. With RAW, 506 there is a need to combine information at the sender (number of 507 retries) with that at the receiver (LQI, RSSI). This doubles the 508 operating cost of an IAOM processing that would gather the experience 509 of a single packet. 511 The RAW PSE may be centralized at the Track Ingress, or distributed 512 long the Track. Either way, the PSE needs instant information about 513 the rest of the way to the destination over the possible next-hop 514 adjacencies along the Track in order to decide how to perform simple 515 forwarding, load balancing, and/or replication, as well as 516 determining how much latency credit is available for ARQ. 518 To provide that information timely, it makes sense that the OAM 519 packets that gather instantaneous values from the radio senders and 520 receivers at each hop flow on the reverse path and inform the PSE at 521 the source and/or the PAREO relays about the state of the rest of the 522 way. This is achieved using Reverse OAM packets that flow along the 523 Reversed Track, West to East. 525 Because the quality of transmission over a wireless medium varies 526 continuously, it is important that RAW OAM captures the state of the 527 medium across an adjacency over multiple transmission and over a 528 recent period of time, whether the transmitted packets belong to this 529 flow or another. Some of the measured information relates to the 530 medium itself. In other words, the captured information does not 531 only relate to the experience of one packet as is the case for IOAM, 532 but also to the medium itself. This makes an approach like HTS more 533 suitable as it can trigger the capture of multiple measurements over 534 a short period of time. On the other hand, the PSE needs a 535 continuous measurement stream where a single trigger is followed by a 536 periodic follow up capture. 538 In other words, the best suited OAM method to enable the PSE make 539 accurate PAREO forwarding decisions is a periodic variation of the 540 two-steps method flowing along the reverse Track, as an upstream OAM 541 technique. [RAW-OAM] provides more information on the RAW OAM 542 problem and solution approaches. 544 9.3. Observed Metrics 546 The Dynamic Link Exchange Protocol (DLEP) [RFC8175] from [MANET] can 547 be leveraged at each hop to derive generic radio metrics (e.g., based 548 on LQI, RSSI, queueing delays and ETX) on individual hops. 550 Those lower-layer metrics are aggregated along a multihop segment 551 into abstract layer 3 information that reflect the instant 552 reliability and latency of the observed path. 554 10. Security Considerations 556 RAW uses all forms of diversity including radio technology and 557 physical path to increase the reliability and availability in the 558 face of unpredictable conditions. While this is not done 559 specifically to defeat an attacker, the amount of diversity used in 560 RAW makes an attack harder to achieve. 562 10.1. Forced Access 564 RAW will typically select the cheapest collection of links that 565 matches the requested SLA, for instance, leverage free WI-Fi vs. paid 566 3GPP access. By defeating the cheap connectivity (e.g., PHY-layer 567 interference) the attacker can force an End System to use the paid 568 access and increase the cost of the transmission for the user. 570 11. IANA Considerations 572 This document has no IANA actions. 574 12. Acknowledgments 576 The editor wishes to thank: 578 Xavi Vilajosana: Wireless Networks Research Lab, Universitat Oberta 579 de Catalunya 581 Remous-Aris Koutsiamanis: IMT Atlantique 583 Nicolas Montavont: IMT Atlantique 585 Georgios Z. Papadopoulos: IMT Atlantique 586 Rex Buddenberg: Individual contributor 588 Greg Mirsky: ZTE 590 for their contributions to the text and ideas exposed in this 591 document. 593 13. References 595 13.1. Normative References 597 [6TiSCH-ARCHI] 598 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 599 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 600 RFC 9030, DOI 10.17487/RFC9030, May 2021, 601 . 603 [RAW-ARCHI] 604 Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 605 and Available Wireless Architecture/Framework", Work in 606 Progress, Internet-Draft, draft-ietf-raw-architecture-01, 607 28 July 2021, . 610 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 611 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 612 . 614 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 615 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 616 May 2016, . 618 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 619 RFC 8578, DOI 10.17487/RFC8578, May 2019, 620 . 622 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 623 (IPv6) Specification", STD 86, RFC 8200, 624 DOI 10.17487/RFC8200, July 2017, 625 . 627 [SR-ARCHI] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 628 Decraene, B., Litkowski, S., and R. Shakir, "Segment 629 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 630 July 2018, . 632 [BIER] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 633 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 634 Explicit Replication (BIER)", RFC 8279, 635 DOI 10.17487/RFC8279, November 2017, 636 . 638 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 639 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 640 DOI 10.17487/RFC8175, June 2017, 641 . 643 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 644 "Deterministic Networking Architecture", RFC 8655, 645 DOI 10.17487/RFC8655, October 2019, 646 . 648 13.2. Informative References 650 [RAW-TECHNOS] 651 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 652 and J. Farkas, "Reliable and Available Wireless 653 Technologies", Work in Progress, Internet-Draft, draft- 654 ietf-raw-technologies-04, 3 August 2021, 655 . 658 [RAW-USE-CASES] 659 Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. 660 Bernardos, "RAW use cases", Work in Progress, Internet- 661 Draft, draft-ietf-raw-use-cases-03, 20 October 2021, 662 . 665 [DetNet-DP] 666 Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 667 Bryant, "Deterministic Networking (DetNet) Data Plane 668 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 669 . 671 [BIER-PREF] 672 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 673 TE extensions for Packet Replication and Elimination 674 Function (PREF) and OAM", Work in Progress, Internet- 675 Draft, draft-thubert-bier-replication-elimination-03, 3 676 March 2018, . 679 [DetNet-IP-OAM] 680 Mirsky, G., Chen, M., and D. Black, "Operations, 681 Administration and Maintenance (OAM) for Deterministic 682 Networks (DetNet) with IP Data Plane", Work in Progress, 683 Internet-Draft, draft-ietf-detnet-ip-oam-03, 19 September 684 2021, . 687 [RAW-5G] Farkas, J., Dudda, T., Shapin, A., and S. Sandberg, "5G - 688 Ultra-Reliable Wireless Technology with Low Latency", Work 689 in Progress, Internet-Draft, draft-farkas-raw-5g-00, 1 690 April 2020, . 693 [BIER-TE] Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 694 for Bit Index Explicit Replication (BIER-TE)", Work in 695 Progress, Internet-Draft, draft-ietf-bier-te-arch-11, 15 696 November 2021, . 699 [RAW-OAM] Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J. 700 Bernardos, "Operations, Administration and Maintenance 701 (OAM) features for RAW", Work in Progress, Internet-Draft, 702 draft-ietf-raw-oam-support-02, 3 June 2021, 703 . 706 [I-D.ietf-ippm-ioam-direct-export] 707 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 708 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 709 OAM Direct Exporting", Work in Progress, Internet-Draft, 710 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 711 . 714 [DetNet-OAM] 715 Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos, 716 C. J., Varga, B., and J. Farkas, "Framework of Operations, 717 Administration and Maintenance (OAM) for Deterministic 718 Networking (DetNet)", Work in Progress, Internet-Draft, 719 draft-ietf-detnet-oam-framework-05, 14 October 2021, 720 . 723 [I-D.mirsky-ippm-hybrid-two-step] 724 Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid 725 Two-Step Performance Measurement Method", Work in 726 Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two- 727 step-11, 8 July 2021, 728 . 731 [I-D.mirsky-ippm-epm] 732 Mirsky, G., Halpern, J., Min, X., and L. Han, "Error 733 Performance Measurement in Packet-switched Networks", Work 734 in Progress, Internet-Draft, draft-mirsky-ippm-epm-04, 24 735 October 2021, . 738 [I-D.mirsky-bfd-mpls-demand] 739 Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS 740 LSP", Work in Progress, Internet-Draft, draft-mirsky-bfd- 741 mpls-demand-10, 1 October 2021, 742 . 745 [I-D.ietf-ippm-ioam-data] 746 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 747 for In-situ OAM", Work in Progress, Internet-Draft, draft- 748 ietf-ippm-ioam-data-16, 8 November 2021, 749 . 752 [MANET] IETF, "Mobile Ad hoc Networking", 753 . 755 [detnet] IETF, "Deterministic Networking", 756 . 758 [SPRING] IETF, "Source Packet Routing in Networking", 759 . 761 [BIER] IETF, "Bit Indexed Explicit Replication", 762 . 764 [BFD] IETF, "Bidirectional Forwarding Detection", 765 . 767 [CCAMP] IETF, "Common Control and Measurement Plane", 768 . 770 [IPPM] IETF, "IP Performance Measurement", 771 . 773 Authors' Addresses 774 Pascal Thubert (editor) 775 Cisco Systems, Inc 776 Building D 777 45 Allee des Ormes - BP1200 778 06254 MOUGINS - Sophia Antipolis 779 France 781 Phone: +33 497 23 26 34 782 Email: pthubert@cisco.com 784 Lou Berger 785 LabN Consulting, L.L.C. 786 United States of America 788 Email: lberger@labn.net