idnits 2.17.00 (12 Aug 2021) /tmp/idnits39291/draft-ietf-raw-oam-support-01.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 draft header indicates that this document updates draft-ietf-raw-oam-support-00, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2021) is 362 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-pthubert-raw-architecture-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW F. Theoleyre 3 Internet-Draft CNRS 4 Updates: draft-ietf-raw-oam-support-00 G. Papadopoulos 5 (if approved) IMT Atlantique 6 Intended status: Informational G. Mirsky 7 Expires: November 25, 2021 ZTE Corp. 8 CJ. Bernardos 9 UC3M 10 May 24, 2021 12 Operations, Administration and Maintenance (OAM) features for RAW 13 draft-ietf-raw-oam-support-01 15 Abstract 17 Some critical applications may use a wireless infrastructure. 18 However, wireless networks exhibit a bandwidth of several orders of 19 magnitude lower than wired networks. Besides, wireless transmissions 20 are lossy by nature; the probability that a packet cannot be decoded 21 correctly by the receiver may be quite high. In these conditions, 22 guaranteeing that the network infrastructure works properly is 23 particularly challenging, since we need to address some issues 24 specific to wireless networks. This document lists the requirements 25 of the Operation, Administration, and Maintenance (OAM) features 26 recommended to construct a predictable communication infrastructure 27 on top of a collection of wireless segments. This document describes 28 the benefits, problems, and trade-offs for using OAM in wireless 29 networks to achieve Service Level Objectives (SLO). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 25, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 69 2. Role of OAM in RAW . . . . . . . . . . . . . . . . . . . . . 6 70 2.1. Link concept and quality . . . . . . . . . . . . . . . . 7 71 2.2. Broadcast Transmissions . . . . . . . . . . . . . . . . . 7 72 2.3. Complex Layer 2 Forwarding . . . . . . . . . . . . . . . 8 73 2.4. End-to-end delay . . . . . . . . . . . . . . . . . . . . 8 74 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.1. Information Collection . . . . . . . . . . . . . . . . . 8 76 3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 9 77 3.3. Connectivity Verification . . . . . . . . . . . . . . . . 9 78 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 79 3.5. Fault Verification/detection . . . . . . . . . . . . . . 9 80 3.6. Fault Isolation/identification . . . . . . . . . . . . . 10 81 4. Administration . . . . . . . . . . . . . . . . . . . . . . . 10 82 4.1. Worst-case metrics . . . . . . . . . . . . . . . . . . . 11 83 4.2. Efficient data retrieval . . . . . . . . . . . . . . . . 11 84 4.3. Reporting OAM packets to the source . . . . . . . . . . . 12 85 5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 5.1. Soft transition after reconfiguration . . . . . . . . . . 12 87 5.2. Predictive maintenance . . . . . . . . . . . . . . . . . 12 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 91 9. Informative References . . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 Reliable and Available Wireless (RAW) is an effort that extends 97 DetNet to approach end-to-end deterministic performances over a 98 network that includes scheduled wireless segments. In wired 99 networks, many approaches try to enable Quality of Service (QoS) by 100 implementing traffic differentiation so that routers handle each type 101 of packets differently. However, this differentiated treatment was 102 expensive for most applications. 104 Deterministic Networking (DetNet) [RFC8655] has proposed to provide a 105 bounded end-to-end latency on top of the network infrastructure, 106 comprising both Layer 2 bridged and Layer 3 routed segments. Their 107 work encompasses the data plane, OAM, time synchronization, 108 management, control, and security aspects. 110 However, wireless networks create specific challenges. First of all, 111 radio bandwidth is significantly lower than for wired networks. In 112 these conditions, the volume of signaling messages has to be very 113 limited. Even worse, wireless links are lossy: a Layer 2 114 transmission may or may not be decoded correctly by the receiver, 115 depending on a broad set of parameters. Thus, providing high 116 reliability through wireless segments is particularly challenging. 118 Wired networks rely on the concept of _links_. All the devices 119 attached to a link receive any transmission. The concept of a link 120 in wireless networks is somewhat different from what many are used to 121 in wireline networks. A receiver may or may not receive a 122 transmission, depending on the presence of a colliding transmission, 123 the radio channel's quality, and the external interference. Besides, 124 a wireless transmission is broadcast by nature: any _neighboring_ 125 device may be able to decode it. The document includes detailed 126 information on what the implications for the OAM features are. 128 Last but not least, radio links present volatile characteristics. If 129 the wireless networks use an unlicensed band, packet losses are not 130 anymore temporally and spatially independent. Typically, links may 131 exhibit a very bursty characteristic, where several consecutive 132 packets may be dropped. Thus, providing availability and reliability 133 on top of the wireless infrastructure requires specific Layer 3 134 mechanisms to counteract these bursty losses. 136 Operations, Administration, and Maintenance (OAM) Tools are of 137 primary importance for IP networks [RFC7276]. It defines a toolset 138 for fault detection, isolation, and performance measurement. 140 The primary purpose of this document is to detail the specific 141 requirements of the OAM features recommended to construct a 142 predictable communication infrastructure on top of a collection of 143 wireless segments. This document describes the benefits, problems, 144 and trade-offs for using OAM in wireless networks to provide 145 availability and predictability. 147 1.1. Terminology 149 In this document, the term OAM will be used according to its 150 definition specified in [RFC6291]. We expect to implement an OAM 151 framework in RAW networks to maintain a real-time view of the network 152 infrastructure, and its ability to respect the Service Level 153 Objectives (SLO), such as delay and reliability, assigned to each 154 data flow. 156 We re-use here the same terminology as [detnet-oam]: 158 o OAM entity: a data flow to be monitored for defects and/or its 159 performance metrics measured.; 161 o Maintenance End Point (MEP): OAM devices crossed when entering/ 162 exiting the network. In RAW, it corresponds mostly to the source 163 or destination of a data flow. OAM message can be exchanged 164 between two MEPs; 166 o Maintenance Intermediate endPoint (MIP): an OAM system along the 167 flow; a MIP MAY respond to an OAM message generated by the MEP; 169 o control/management/data plane: the control and management planes 170 are used to configure and control the network (long-term). The 171 data plane takes the individual decision. Relative to a data 172 flow, the control and/or management plane can be out-of-band; 174 o Active measurement methods (as defined in [RFC7799]) modify a 175 normal data flow by inserting novel fields, injecting specially 176 constructed test packets [RFC2544]). It is critical for the 177 quality of information obtained using an active method that 178 generated test packets are in-band with the monitored data flow. 179 In other words, a test packet is required to cross the same 180 network nodes and links and receive the same Quality of Service 181 (QoS) treatment as a data packet. Active methods may implement 182 one of these two strategies: 184 * In-band: control information follows the same path as the data 185 packets. In other words, a failure in the data plane may 186 prevent the control information to reach the destination (e.g., 187 end-device or controller). 189 * out-of-band: control information is sent separately from the 190 data packets. Thus, the behavior of control vs. data packets 191 may differ; 193 o Passive measurement methods [RFC7799] infer information by 194 observing unmodified existing flows. 196 We also adopt the following terminology, which is particularly 197 relevant for RAW segments. 199 o piggybacking vs. dedicated control packets: control information 200 may be encapsulated in specific (dedicated) control packets. 201 Alternatively, it may be piggybacked in existing data packets, 202 when the MTU is larger than the actual packet length. 203 Piggybacking makes specifically sense in wireless networks, as the 204 cost (bandwidth and energy) is not linear with the packet size. 206 o router-over vs. mesh under: a control packet is either forwarded 207 directly to the layer-3 next hop (mesh under) or handled hop-by- 208 hop by each router. While the latter option consumes more 209 resources, it allows to collect additionnal intermediary 210 information, particularly relevant in wireless networks. 212 o Defect: a temporary change in the network (e.g., a radio link 213 which is broken due to a mobile obstacle); 215 o Fault: a definite change which may affect the network performance, 216 e.g., a node runs out of energy. 218 o End-to-end delay: the time between the packet generation and its 219 reception by the destination. 221 1.2. Acronyms 223 OAM Operations, Administration, and Maintenance 225 DetNet Deterministic Networking 227 PSE Path Selection Engine [I-D.pthubert-raw-architecture] 229 QoS Quality of Service 231 RAW Reliable and Available Wireless 233 SLO Service Level Objective 235 SNMP Simple Network Management Protocol 236 SDN Software-Defined Network 238 1.3. Requirements Language 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 242 "OPTIONAL" in this document are to be interpreted as described in BCP 243 14 [RFC2119] [RFC8174] when, and only when, they appear in all 244 capitals, as shown here. 246 2. Role of OAM in RAW 248 RAW networks expect to make the communications reliable and 249 predictable on top of a wireless network infrastructure. Most 250 critical applications will define an SLO to be required for the data 251 flows it generates. RAW considers network plane protocol elements 252 such as OAM to improve the RAW operation at the service and the 253 forwarding sub-layers. 255 To respect strict guarantees, RAW relies on the Path Selection Engine 256 (PSE) (as defined in [I-D.pthubert-raw-architecture] to monitor and 257 maintain the network. As an example, a Software-Defined Network 258 (SDN) controller may be used to schedule the transmissions in the 259 deployed network, based on the radio link characteristics, SLO of the 260 flows, the number of packets to forward. Thus, resources have to be 261 provisioned a priori to handle any defect. OAM represents the core 262 of the pre-provisioning process and maintains the network operational 263 by updating the schedule dynamically. 265 Fault-tolerance also assumes that multiple paths have to be 266 provisioned so that an end-to-end circuit keeps on existing whatever 267 the conditions. The Packet Replication and Elimination Function 268 ([PREF-draft]) on a node is typically controlled by the PSE. OAM 269 mechanisms can be used to monitor that PREOF is working correctly on 270 a node and within the domain. 272 To be energy-efficient, reserving some dedicated out-of-band 273 resources for OAM seems idealistic, and only in-band solutions are 274 considered here. 276 RAW supports both proactive and on-demand troubleshooting. 278 The specific characteristics of RAW are discussed below. 280 2.1. Link concept and quality 282 In wireless networks, a _link_ does not exist physically. A device 283 has a set of *neighbors* that correspond to all the devices that have 284 a non null probability of receiving correctly its packets. We make a 285 distinction between: 287 o point-to-point (p2p) link with one transmitter and one receiver. 288 These links are used to transmit unicast packets. 290 o point-to-multipoint (p2m) link associates one transmitter and a 291 collection of receivers. For instance, broadcast packets assume 292 the existence of p2m links to avoid duplicating a broadcast packet 293 to reach each possible radio neighbor. 295 In scheduled radio networks, p2m and p2p links are commonly not 296 scheduled simultaneously to save energy. More precisely, only one 297 part of the neighbors may wake-up at a given instant. 299 Anycast are used in p2m links to improve the reliability. A 300 collection of receivers are scheduled to wake-up simutaneously, so 301 that the transmission fails only if none of the receivers is able to 302 decode the packet. 304 Each wireless link is associated with a link quality, often measured 305 as the Packet Delivery Ratio (PDR), i.e., the probability that the 306 receiver can decode the packet correctly. It is worth noting that 307 this link quality depends on many criteria, such as the level of 308 external interference, the presence of concurrent transmissions, or 309 the radio channel state. This link quality is even time-variant. 310 For p2m links, we have consequently a collection of PDR (one value 311 per receiver). Other more sophisticated, aggregated metrics exist 312 for these p2m links, such as [anycast-property] 314 2.2. Broadcast Transmissions 316 In modern switching networks, the unicast transmission is delivered 317 uniquely to the destination. Wireless networks are much closer to 318 the ancient *shared access* networks. Practically, unicast and 319 broadcast frames are handled similarly at the physical layer. The 320 link layer is just in charge of filtering the frames to discard 321 irrelevant receptions (e.g., different unicast MAC address). 323 However, contrary to wired networks, we cannot be sure that a packet 324 is received by *all* the devices attached to the Layer 2 segment. It 325 depends on the radio channel state between the transmitter(s) and the 326 receiver(s). In particular, concurrent transmissions may be possible 327 or not, depending on the radio conditions (e.g., do the different 328 transmitters use a different radio channel or are they sufficiently 329 spatially separated?) 331 2.3. Complex Layer 2 Forwarding 333 Multiple neighbors may receive a transmission. Thus, anycast Layer 2 334 forwarding helps to maximize the reliability by assigning multiple 335 receivers to a single transmission. That way, the packet is lost 336 only if *none* of the receivers decode it. Practically, it has been 337 proven that different neighbors may exhibit very different radio 338 conditions, and that reception independency may hold for some of them 339 [anycast-property]. 341 2.4. End-to-end delay 343 In a wireless network, additionnal transmissions opportunities are 344 provisionned to accomodate packet losses. Thus, the end-to-end delay 345 consists of: 347 o Transmission delay, which is fixed and depends mainly on the data 348 rate, and the presence or absence of an acknowledgement. 350 o Residence time, corresponds to the buffering delay and depends on 351 the schedule. To account for retransmisisons, the residence time 352 is equal to the difference between the time of last reception from 353 the previous hop (among all the retransmisions) and the time of 354 emission of the last retransmission. 356 3. Operation 358 OAM features will enable RAW with robust operation both for 359 forwarding and routing purposes. 361 3.1. Information Collection 363 The model to exchange information should be the same as for DetNet 364 network, for the sake of inter-operability. YANG may typically 365 fulfill this objective. 367 However, RAW networks imply specific constraints (e.g., low 368 bandwidth, packet losses, cost of medium access) that may require to 369 minimize the volume of information to collect. Thus, we discuss in 370 Section 4.2 different ways to collect information, i.e., transfer 371 physically the OAM information from the emitter to the receiver. 373 3.2. Continuity Check 375 Similarly to DetNet, we need to verify that the source and the 376 destination are connected (at least one valid path exists) 378 3.3. Connectivity Verification 380 As in DetNet, we have to verify the absence of misconnection. We 381 focus here on the RAW specificities. 383 Because of radio transmissions' broadcast nature, several receivers 384 may be active at the same time to enable anycast Layer 2 forwarding. 385 Thus, the connectivity verification must test any combination. We 386 also consider priority-based mechanisms for anycast forwarding, i.e., 387 all the receivers have different probabilities of forwarding a 388 packet. To verify a delay SLO for a given flow, we must also 389 consider all the possible combinations, leading to a probability 390 distribution function for end-to-end transmissions. If this 391 verification is implemented naively, the number of combinations to 392 test may be exponential and too costly for wireless networks with low 393 bandwidth. 395 3.4. Route Tracing 397 Wireless networks are meshed by nature: we have many redundant radio 398 links. These meshed networks are both an asset and a drawback: while 399 several paths exist between two endpoints, and we should choose the 400 most efficient one(s), concerning specifically the reliability, and 401 the delay. 403 Thus, multipath routing can be considered to make the network fault- 404 tolerant. Even better, we can exploit the broadcast nature of 405 wireless networks to exploit meshed multipath routing: we may have 406 multiple Maintenance Intermediate Endpoints (MIP) for each hop in the 407 path. In that way, each Maintenance Intermediate Endpoint has 408 several possible next hops in the forwarding plane. Thus, all the 409 possible paths between two maintenance endpoints should be retrieved, 410 which may quickly become untractable if we apply a naive approach. 412 3.5. Fault Verification/detection 414 Wired networks tend to present stable performances. On the contrary, 415 wireless networks are time-variant. We must consequently make a 416 distinction between _normal_ evolutions and malfunction. 418 3.6. Fault Isolation/identification 420 The network has isolated and identified the cause of the fault. 421 While DetNet already expects to identify malfunctions, some problems 422 are specific to wireless networks. We must consequently collect 423 metrics and implement algorithms tailored for wireless networking. 425 For instance, the decrease in the link quality may be caused by 426 several factors: external interference, obstacles, multipath fading, 427 mobility. It it fundamental to be able to discriminate the different 428 causes to make the right decision. 430 4. Administration 432 The RAW network has to expose a collection of metrics to support an 433 operator making proper decisions, including: 435 o Packet losses: the time-window average and maximum values of the 436 number of packet losses have to be measured. Many critical 437 applications stop to work if a few consecutive packets are 438 dropped; 440 o Received Signal Strength Indicator (RSSI) is a very common metric 441 in wireless to denote the link quality. The radio chipset is in 442 charge of translating a received signal strength into a normalized 443 quality indicator; 445 o Delay: the time elapsed between a packet generation / enqueuing 446 and its reception by the next hop; 448 o Buffer occupancy: the number of packets present in the buffer, for 449 each of the existing flows. 451 o Battery lifetime: the expected remaining battery lifetime of the 452 device. Since many RAW devices might be battery powered, this is 453 an important metric for an operator to take proper decisions. 455 o Mobility: if a device is known to be mobile, this might be 456 considered by an operator to take proper decisions. 458 These metrics should be collected per device, virtual circuit, and 459 path, as detnet already does. However, we have to face in RAW to a 460 finer granularity: 462 o per radio channel to measure, e.g., the level of external 463 interference, and to be able to apply counter-measures (e.g., 464 blacklisting). 466 o per link to detect misbehaving link (assymetrical link, 467 fluctuating quality). 469 o per resource block: a collision in the schedule is particularly 470 challenging to identify in radio networks with spectrum reuse. In 471 particular, a collision may not be systematic (depending on the 472 radio characteristics and the traffic profile) 474 4.1. Worst-case metrics 476 RAW inherits the same requirements as DetNet: we need to know the 477 distribution of a collection of metrics. However, wireless networks 478 are known to be highly variable. Changes may be frequent, and may 479 exhibit a periodical pattern. Collecting and analyzing this amount 480 of measurements is challenging. 482 Wireless networks are known to be lossy, and RAW has to implement 483 strategies to improve reliability on top of unreliable links. Hybrid 484 Automatic Repeat reQuest (ARQ) has typically to enable 485 retransmissions based on the end-to-end reliability and latency 486 requirements. 488 4.2. Efficient data retrieval 490 We have to minimize the number of statistics / measurements to 491 exchange: 493 o energy efficiency: low-power devices have to limit the volume of 494 monitoring information since every bit consumes energy. 496 o bandwidth: wireless networks exhibit a bandwidth significantly 497 lower than wired, best-effort networks. 499 o per-packet cost: it is often more expensive to send several 500 packets instead of combining them in a single link-layer frame. 502 In conclusion, we have to take care of power and bandwidth 503 consumption. The following techniques aim to reduce the cost of such 504 maintenance: 506 on-path collection: some control information is inserted in the 507 data packets if they do not fragment the packet (i.e., the MTU is 508 not exceeded). Information Elements represent a standardized way 509 to handle such information; 511 flags/fields: we have to set-up flags in the packets to monitor to 512 be able to monitor the forwarding process accurately. A sequence 513 number field may help to detect packet losses. Similarly, path 514 inference tools such as [ipath] insert additional information in 515 the headers to identify the path followed by a packet a 516 posteriori. 518 hierarchical monitoring; localized and centralized mechanisms have 519 to be combined together. Typically, a local mechanism should 520 contiuously monitor a set of metrics and trigger distant OAM 521 exchances only when a fault is detected (but possibly not 522 identified). For instance, local temporary defects must not 523 trigger expensive OAM transmissions. 525 4.3. Reporting OAM packets to the source 527 TODO: statistics are collected when a packet goes from the source to 528 the destination. However, it has to be also reported by the source. 529 Problem: resource may not be reserved bidirectionnaly. Even worse: 530 the inverse path may not exist. 532 5. Maintenance 534 Maintenance needs to facilitate the maintenance (repairs and 535 upgrades). In wireless networks, repairs are expected to occur much 536 more frequently, since the link quality may be highly time-variant. 537 Thus, maintenance represents a key feature for RAW. 539 5.1. Soft transition after reconfiguration 541 Because of the wireless medium, the link quality may fluctuate, and 542 the network needs to reconfigure itself continuously. During this 543 transient state, flows may begin to be gradually re-forwarded, 544 consuming resources in different parts of the network. OAM has to 545 make a distinction between a metric that changed because of a legal 546 network change (e.g., flow redirection) and an unexpected event 547 (e.g., a fault). 549 5.2. Predictive maintenance 551 RAW needs to implement self-optimization features. While the network 552 is configured to be fault-tolerant, a reconfiguration may be required 553 to keep on respecting long-term objectives. Obviously, the network 554 keeps on respecting the SLO after a node's crash, but a 555 reconfiguration is required to handle the future faults. In other 556 words, the reconfiguration delay MUST be strictly smaller than the 557 inter-fault time. 559 The network must continuously retrieve the state of the network, to 560 judge about the relevance of a reconfiguration, quantifying: 562 the cost of the sub-optimality: resources may not be used 563 optimally (e.g., a better path exists); 565 the reconfiguration cost: the controller needs to trigger some 566 reconfigurations. For this transient period, resources may be 567 twice reserved, and control packets have to be transmitted. 569 Thus, reconfiguration may only be triggered if the gain is 570 significant. 572 6. IANA Considerations 574 This document has no actionable requirements for IANA. This section 575 can be removed before the publication. 577 7. Security Considerations 579 This section will be expanded in future versions of the draft. 581 8. Acknowledgments 583 TBD 585 9. Informative References 587 [anycast-property] 588 Teles Hermeto, R., Gallais, A., and F. Theoleyre, "Is 589 Link-Layer Anycast Scheduling Relevant for IEEE 590 802.15.4-TSCH Networks?", 2019, 591 . 593 [detnet-oam] 594 Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J. 595 Bernardos, "Operations, Administration and Maintenance 596 (OAM) features for detnet", 2020, 597 . 600 [I-D.pthubert-raw-architecture] 601 Thubert, P., Papadopoulos, G. Z., and R. Buddenberg, 602 "Reliable and Available Wireless Architecture/Framework", 603 draft-pthubert-raw-architecture-05 (work in progress), 604 November 2020. 606 [ipath] Gao, Y., Dong, W., Chen, C., Bu, J., Wu, W., and X. Liu, 607 "iPath: path inference in wireless sensor networks.", 608 2016, . 610 [PREF-draft] 611 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 612 TE extensions for Packet Replication and Elimination 613 Function (PREF) and OAM", 2018, 614 . 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 623 Network Interconnect Devices", RFC 2544, 624 DOI 10.17487/RFC2544, March 1999, 625 . 627 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 628 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 629 Acronym in the IETF", BCP 161, RFC 6291, 630 DOI 10.17487/RFC6291, June 2011, 631 . 633 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 634 Weingarten, "An Overview of Operations, Administration, 635 and Maintenance (OAM) Tools", RFC 7276, 636 DOI 10.17487/RFC7276, June 2014, 637 . 639 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 640 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 641 May 2016, . 643 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 645 May 2017, . 647 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 648 "Deterministic Networking Architecture", RFC 8655, 649 DOI 10.17487/RFC8655, October 2019, 650 . 652 Authors' Addresses 653 Fabrice Theoleyre 654 CNRS 655 Building B 656 300 boulevard Sebastien Brant - CS 10413 657 Illkirch - Strasbourg 67400 658 FRANCE 660 Phone: +33 368 85 45 33 661 Email: theoleyre@unistra.fr 662 URI: http://www.theoleyre.eu 664 Georgios Z. Papadopoulos 665 IMT Atlantique 666 Office B00 - 102A 667 2 Rue de la Chataigneraie 668 Cesson-Sevigne - Rennes 35510 669 FRANCE 671 Phone: +33 299 12 70 04 672 Email: georgios.papadopoulos@imt-atlantique.fr 674 Greg Mirsky 675 ZTE Corp. 677 Email: gregory.mirsky@ztetx.com 679 Carlos J. Bernardos 680 Universidad Carlos III de Madrid 681 Av. Universidad, 30 682 Leganes, Madrid 28911 683 Spain 685 Phone: +34 91624 6236 686 Email: cjbc@it.uc3m.es 687 URI: http://www.it.uc3m.es/cjbc/