idnits 2.17.1 draft-ietf-raw-oam-support-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates draft-ietf-raw-oam-support-01, 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 (June 3, 2021) is 1050 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-01 G. Papadopoulos 5 (if approved) IMT Atlantique 6 Intended status: Informational G. Mirsky 7 Expires: December 5, 2021 ZTE Corp. 8 CJ. Bernardos 9 UC3M 10 June 3, 2021 12 Operations, Administration and Maintenance (OAM) features for RAW 13 draft-ietf-raw-oam-support-02 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 providing high reliability and a low delay is challenging. This 23 document lists the requirements of the Operation, Administration, and 24 Maintenance (OAM) features recommended to construct a predictable 25 communication infrastructure on top of a collection of wireless 26 segments. This document describes the benefits, problems, and trade- 27 offs for using OAM in wireless networks to achieve Service Level 28 Objectives (SLO). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 5, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 68 2. Role of OAM in RAW . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. Link concept and quality . . . . . . . . . . . . . . . . 7 70 2.2. Broadcast Transmissions . . . . . . . . . . . . . . . . . 7 71 2.3. Complex Layer 2 Forwarding . . . . . . . . . . . . . . . 8 72 2.4. End-to-end delay . . . . . . . . . . . . . . . . . . . . 8 73 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1. Information Collection . . . . . . . . . . . . . . . . . 8 75 3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 9 76 3.3. Connectivity Verification . . . . . . . . . . . . . . . . 9 77 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 78 3.5. Fault Verification/detection . . . . . . . . . . . . . . 10 79 3.6. Fault Isolation/identification . . . . . . . . . . . . . 10 80 4. Administration . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.1. Worst-case metrics . . . . . . . . . . . . . . . . . . . 11 82 4.2. Efficient data retrieval . . . . . . . . . . . . . . . . 11 83 4.3. Reporting OAM packets to the source . . . . . . . . . . . 12 84 5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 5.1. Soft transition after reconfiguration . . . . . . . . . . 13 86 5.2. Predictive maintenance . . . . . . . . . . . . . . . . . 13 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 90 9. Informative References . . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 Reliable and Available Wireless (RAW) is an effort that extends 96 DetNet to approach end-to-end deterministic performances over a 97 network that includes scheduled wireless segments. In wired 98 networks, many approaches try to enable Quality of Service (QoS) by 99 implementing traffic differentiation so that routers handle each type 100 of packets differently. However, this differentiated treatment was 101 expensive for most applications. 103 Deterministic Networking (DetNet) [RFC8655] has proposed to provide a 104 bounded end-to-end latency on top of the network infrastructure, 105 comprising both Layer 2 bridged and Layer 3 routed segments. Their 106 work encompasses the data plane, OAM, time synchronization, 107 management, control, and security aspects. 109 However, wireless networks create specific challenges. First of all, 110 radio bandwidth is significantly lower than for wired networks. In 111 these conditions, the volume of signaling messages has to be very 112 limited. Even worse, wireless links are lossy: a Layer 2 113 transmission may or may not be decoded correctly by the receiver, 114 depending on a broad set of parameters. Thus, providing high 115 reliability through wireless segments is particularly challenging. 117 Wired networks rely on the concept of _links_. All the devices 118 attached to a link receive any transmission. The concept of a link 119 in wireless networks is somewhat different from what many are used to 120 in wireline networks. A receiver may or may not receive a 121 transmission, depending on the presence of a colliding transmission, 122 the radio channel's quality, and the external interference. Besides, 123 a wireless transmission is broadcast by nature: any _neighboring_ 124 device may be able to decode it. This document includes detailed 125 information on what the implications for the OAM features are. 127 Last but not least, radio links present volatile characteristics. If 128 the wireless networks use an unlicensed band, packet losses are not 129 anymore temporally and spatially independent. Typically, links may 130 exhibit a very bursty characteristic, where several consecutive 131 packets may be dropped, because of e.g. temporary external 132 interference. Thus, providing availability and reliability on top of 133 the wireless infrastructure requires specific Layer 3 mechanisms to 134 counteract these bursty losses. 136 Operations, Administration, and Maintenance (OAM) Tools are of 137 primary importance for IP networks [RFC7276]. They define 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 L3 network. A L2 scheduler may be used to allocate 258 transmission opportunities, based on the radio link characteristics, 259 SLO of the flows, the number of packets to forward. The PSE exploits 260 the L2 ressources reserved by the scheduler, and organizes the L3 261 paths to introduce redundancy, fault tolerance, and create backup 262 paths. OAM represents the core of the pre-provisioning process by 263 supervising the network. It maintains maintains a global view of the 264 network resources, to detect defects, faults, over-provisionning, 265 anomalies. 267 Fault-tolerance also assumes that multiple paths have to be 268 provisioned so that an end-to-end circuit keeps on existing whatever 269 the conditions. The Packet Replication and Elimination Function 270 ([PREF-draft]) on a node is typically controlled by the PSE. OAM 271 mechanisms can be used to monitor that PREOF is working correctly on 272 a node and within the domain. 274 To be energy-efficient, reserving some dedicated out-of-band 275 resources for OAM seems idealistic, and only in-band solutions are 276 considered here. 278 RAW supports both proactive and on-demand troubleshooting. 279 Proactively, it is necessary to detect anomalies, to report defects, 280 or to reduce over-provisionning if it is not required. However, on- 281 demand may also be required to identify the cause of a specific 282 defect. Indeed, some specific faults may only be detected with a 283 global, detailed view of the network, which is too expensive to 284 acquire in the normal operating mode. 286 The specific characteristics of RAW are discussed below. 288 2.1. Link concept and quality 290 In wireless networks, a _link_ does not exist physically. A device 291 has a set of *neighbors* that correspond to all the devices that have 292 a non null probability of receiving correctly its packets. We make a 293 distinction between: 295 o point-to-point (p2p) link with one transmitter and one receiver. 296 These links are used to transmit unicast packets. 298 o point-to-multipoint (p2m) link associates one transmitter and a 299 collection of receivers. For instance, broadcast packets assume 300 the existence of p2m links to avoid duplicating a broadcast packet 301 to reach each possible radio neighbor. 303 In scheduled radio networks, p2m and p2p links are commonly not 304 scheduled simultaneously to save energy, and/or to reduce the number 305 of collisions. More precisely, only one part of the neighbors may 306 wake-up at a given instant. 308 Anycast are used in p2m links to improve the reliability. A 309 collection of receivers are scheduled to wake-up simutaneously, so 310 that the transmission fails only if none of the receivers is able to 311 decode the packet. 313 Each wireless link is associated with a link quality, often measured 314 as the Packet Delivery Ratio (PDR), i.e., the probability that the 315 receiver can decode the packet correctly. It is worth noting that 316 this link quality depends on many criteria, such as the level of 317 external interference, the presence of concurrent transmissions, or 318 the radio channel state. This link quality is even time-variant. 319 For p2m links, we have consequently a collection of PDR (one value 320 per receiver). Other more sophisticated, aggregated metrics exist 321 for these p2m links, such as [anycast-property] 323 2.2. Broadcast Transmissions 325 In modern switching networks, the unicast transmission is delivered 326 uniquely to the destination. Wireless networks are much closer to 327 the ancient *shared access* networks. Practically, unicast and 328 broadcast frames are handled similarly at the physical layer. The 329 link layer is just in charge of filtering the frames to discard 330 irrelevant receptions (e.g., different unicast MAC address). 332 However, contrary to wired networks, we cannot be sure that a packet 333 is received by *all* the devices attached to the Layer 2 segment. It 334 depends on the radio channel state between the transmitter(s) and the 335 receiver(s). In particular, concurrent transmissions may be possible 336 or not, depending on the radio conditions (e.g., do the different 337 transmitters use a different radio channel or are they sufficiently 338 spatially separated?) 340 2.3. Complex Layer 2 Forwarding 342 Multiple neighbors may receive a transmission. Thus, anycast Layer 2 343 forwarding helps to maximize the reliability by assigning multiple 344 receivers to a single transmission. That way, the packet is lost 345 only if *none* of the receivers decode it. Practically, it has been 346 proven that different neighbors may exhibit very different radio 347 conditions, and that reception independency may hold for some of them 348 [anycast-property]. 350 2.4. End-to-end delay 352 In a wireless network, additionnal transmissions opportunities are 353 provisionned to accomodate packet losses. Thus, the end-to-end delay 354 consists of: 356 o Transmission delay, which is fixed and depends mainly on the data 357 rate, and the presence or absence of an acknowledgement. 359 o Residence time, corresponds to the buffering delay and depends on 360 the schedule. To account for retransmisisons, the residence time 361 is equal to the difference between the time of last reception from 362 the previous hop (among all the retransmisions) and the time of 363 emission of the last retransmission. 365 3. Operation 367 OAM features will enable RAW with robust operation both for 368 forwarding and routing purposes. 370 3.1. Information Collection 372 The model to exchange information should be the same as for DetNet 373 network, for the sake of inter-operability. YANG may typically 374 fulfill this objective. 376 However, RAW networks imply specific constraints (e.g., low 377 bandwidth, packet losses, cost of medium access) that may require to 378 minimize the volume of information to collect. Thus, we discuss in 379 Section 4.2 different ways to collect information, i.e., transfer 380 physically the OAM information from the emitter to the receiver. 382 3.2. Continuity Check 384 Similarly to DetNet, we need to verify that the source and the 385 destination are connected (at least one valid path exists) 387 3.3. Connectivity Verification 389 As in DetNet, we have to verify the absence of misconnection. We 390 focus here on the RAW specificities. 392 Because of radio transmissions' broadcast nature, several receivers 393 may be active at the same time to enable anycast Layer 2 forwarding. 394 Thus, the connectivity verification must test any combination. We 395 also consider priority-based mechanisms for anycast forwarding, i.e., 396 all the receivers have different probabilities of forwarding a 397 packet. To verify a delay SLO for a given flow, we must also 398 consider all the possible combinations, leading to a probability 399 distribution function for end-to-end transmissions. If this 400 verification is implemented naively, the number of combinations to 401 test may be exponential and too costly for wireless networks with low 402 bandwidth. 404 3.4. Route Tracing 406 Wireless networks are broadcast by nature: a radio transmission can 407 be decoded by any radio neighbor. In multihop wireless networks, 408 several paths exist between two endpoints. In hub networks, a device 409 may be covered by several Access Points. We should choose the most 410 efficient path or AP, concerning specifically the reliability, and 411 the delay. 413 Thus, multipath routing / multi-attachment can be considered to make 414 the network fault-tolerant. Even better, we can exploit the 415 broadcast nature of wireless networks to exploit: we may have 416 multiple Maintenance Intermediate Endpoints (MIP) for each of this 417 kind of hop. While it may be reasonable in the multi-attachment 418 case, the complexity quickly increases with the path length. Indeed, 419 each Maintenance Intermediate Endpoint has several possible next hops 420 in the forwarding plane. Thus, all the possible paths between two 421 maintenance endpoints should be retrieved, which may quickly become 422 intractable if we apply a naive approach. 424 3.5. Fault Verification/detection 426 Wired networks tend to present stable performances. On the contrary, 427 wireless networks are time-variant. We must consequently make a 428 distinction between _normal_ evolutions and malfunction. 430 3.6. Fault Isolation/identification 432 The network has isolated and identified the cause of the fault. 433 While DetNet already expects to identify malfunctions, some problems 434 are specific to wireless networks. We must consequently collect 435 metrics and implement algorithms tailored for wireless networking. 437 For instance, the decrease in the link quality may be caused by 438 several factors: external interference, obstacles, multipath fading, 439 mobility. It it fundamental to be able to discriminate the different 440 causes to make the right decision. 442 4. Administration 444 The RAW network has to expose a collection of metrics to support an 445 operator making proper decisions, including: 447 o Packet losses: the time-window average and maximum values of the 448 number of packet losses have to be measured. Many critical 449 applications stop to work if a few consecutive packets are 450 dropped; 452 o Received Signal Strength Indicator (RSSI) is a very common metric 453 in wireless to denote the link quality. The radio chipset is in 454 charge of translating a received signal strength into a normalized 455 quality indicator; 457 o Delay: the time elapsed between a packet generation / enqueuing 458 and its reception by the next hop; 460 o Buffer occupancy: the number of packets present in the buffer, for 461 each of the existing flows. 463 o Battery lifetime: the expected remaining battery lifetime of the 464 device. Since many RAW devices might be battery powered, this is 465 an important metric for an operator to take proper decisions. 467 o Mobility: if a device is known to be mobile, this might be 468 considered by an operator to take proper decisions. 470 These metrics should be collected per device, virtual circuit, and 471 path, as detnet already does. However, we have to face in RAW to a 472 finer granularity: 474 o per radio channel to measure, e.g., the level of external 475 interference, and to be able to apply counter-measures (e.g., 476 blacklisting). 478 o per physical radio technology / interface if a device has multiple 479 NIC. 481 o per link to detect misbehaving link (assymetrical link, 482 fluctuating quality). 484 o per resource block: a collision in the schedule is particularly 485 challenging to identify in radio networks with spectrum reuse. In 486 particular, a collision may not be systematic (depending on the 487 radio characteristics and the traffic profile). 489 4.1. Worst-case metrics 491 RAW inherits the same requirements as DetNet: we need to know the 492 distribution of a collection of metrics. However, wireless networks 493 are known to be highly variable. Changes may be frequent, and may 494 exhibit a periodical pattern. Collecting and analyzing this amount 495 of measurements is challenging. 497 Wireless networks are known to be lossy, and RAW has to implement 498 strategies to improve reliability on top of unreliable links. 499 Reliability is typically achieved through Automatic Repeat Request 500 (ARQ), and Forward Error Correction (FEC). Since the different flows 501 have not the same SLO, RAW must adjust the ARQ and FEC based on the 502 link and path characteristics. 504 4.2. Efficient data retrieval 506 We have to minimize the number of statistics / measurements to 507 exchange: 509 o energy efficiency: low-power devices have to limit the volume of 510 monitoring information since every bit consumes energy. 512 o bandwidth: wireless networks exhibit a bandwidth significantly 513 lower than wired, best-effort networks. 515 o per-packet cost: it is often more expensive to send several 516 packets instead of combining them in a single link-layer frame. 518 In conclusion, we have to take care of power and bandwidth 519 consumption. The following techniques aim to reduce the cost of such 520 maintenance: 522 on-path collection: some control information is inserted in the 523 data packets if they do not fragment the packet (i.e., the MTU is 524 not exceeded). Information Elements represent a standardized way 525 to handle such information. IP hop by hop extension headers may 526 help to collect metrics all along the path; 528 flags/fields: we have to set-up flags in the packets to monitor to 529 be able to monitor the forwarding process accurately. A sequence 530 number field may help to detect packet losses. Similarly, path 531 inference tools such as [ipath] insert additional information in 532 the headers to identify the path followed by a packet a 533 posteriori. 535 hierarchical monitoring: localized and centralized mechanisms have 536 to be combined together. Typically, a local mechanism should 537 contiuously monitor a set of metrics and trigger distant OAM 538 exchances only when a fault is detected (but possibly not 539 identified). For instance, local temporary defects must not 540 trigger expensive OAM transmissions. Besides, the wireless 541 segments represent often the weakest parts of a path: the volume 542 of control information they produce has to be fixed accordingly. 544 4.3. Reporting OAM packets to the source 546 TODO: statistics are collected when a packet goes from the source to 547 the destination. However, it has to be also reported by the source. 548 Problem: resource may not be reserved bidirectionnaly. Even worse: 549 the inverse path may not exist. 551 Reporting everything exhaustively to the source may in most cases too 552 exensive. Thus, devices may take local decisions when possible, and 553 receive end-to-end information when possible. 555 5. Maintenance 557 Maintenance needs to facilitate the maintenance (repairs and 558 upgrades). In wireless networks, repairs are expected to occur much 559 more frequently, since the link quality may be highly time-variant. 560 Thus, maintenance represents a key feature for RAW. 562 5.1. Soft transition after reconfiguration 564 Because of the wireless medium, the link quality may fluctuate, and 565 the network needs to reconfigure itself continuously. During this 566 transient state, flows may begin to be gradually re-forwarded, 567 consuming resources in different parts of the network. OAM has to 568 make a distinction between a metric that changed because of a legal 569 network change (e.g., flow redirection) and an unexpected event 570 (e.g., a fault). 572 5.2. Predictive maintenance 574 RAW needs to implement self-optimization features. While the network 575 is configured to be fault-tolerant, a reconfiguration may be required 576 to keep on respecting long-term objectives. Obviously, the network 577 keeps on respecting the SLO after a node's crash, but a 578 reconfiguration is required to handle the future faults. In other 579 words, the reconfiguration delay MUST be strictly smaller than the 580 inter-fault time. 582 The network must continuously retrieve the state of the network, to 583 judge about the relevance of a reconfiguration, quantifying: 585 the cost of the sub-optimality: resources may not be used 586 optimally (e.g., a better path exists); 588 the reconfiguration cost: the controller needs to trigger some 589 reconfigurations. For this transient period, resources may be 590 twice reserved, and control packets have to be transmitted. 592 Thus, reconfiguration may only be triggered if the gain is 593 significant. 595 6. IANA Considerations 597 This document has no actionable requirements for IANA. This section 598 can be removed before the publication. 600 7. Security Considerations 602 This section will be expanded in future versions of the draft. 604 8. Acknowledgments 606 TBD 608 9. Informative References 610 [anycast-property] 611 Teles Hermeto, R., Gallais, A., and F. Theoleyre, "Is 612 Link-Layer Anycast Scheduling Relevant for IEEE 613 802.15.4-TSCH Networks?", 2019, 614 . 616 [detnet-oam] 617 Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J. 618 Bernardos, "Operations, Administration and Maintenance 619 (OAM) features for detnet", 2020, 620 . 623 [I-D.pthubert-raw-architecture] 624 Thubert, P., Papadopoulos, G. Z., and R. Buddenberg, 625 "Reliable and Available Wireless Architecture/Framework", 626 draft-pthubert-raw-architecture-05 (work in progress), 627 November 2020. 629 [ipath] Gao, Y., Dong, W., Chen, C., Bu, J., Wu, W., and X. Liu, 630 "iPath: path inference in wireless sensor networks.", 631 2016, . 633 [PREF-draft] 634 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 635 TE extensions for Packet Replication and Elimination 636 Function (PREF) and OAM", 2018, 637 . 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, 642 DOI 10.17487/RFC2119, March 1997, 643 . 645 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 646 Network Interconnect Devices", RFC 2544, 647 DOI 10.17487/RFC2544, March 1999, 648 . 650 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 651 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 652 Acronym in the IETF", BCP 161, RFC 6291, 653 DOI 10.17487/RFC6291, June 2011, 654 . 656 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 657 Weingarten, "An Overview of Operations, Administration, 658 and Maintenance (OAM) Tools", RFC 7276, 659 DOI 10.17487/RFC7276, June 2014, 660 . 662 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 663 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 664 May 2016, . 666 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 667 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 668 May 2017, . 670 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 671 "Deterministic Networking Architecture", RFC 8655, 672 DOI 10.17487/RFC8655, October 2019, 673 . 675 Authors' Addresses 677 Fabrice Theoleyre 678 CNRS 679 Building B 680 300 boulevard Sebastien Brant - CS 10413 681 Illkirch - Strasbourg 67400 682 FRANCE 684 Phone: +33 368 85 45 33 685 Email: theoleyre@unistra.fr 686 URI: http://www.theoleyre.eu 688 Georgios Z. Papadopoulos 689 IMT Atlantique 690 Office B00 - 102A 691 2 Rue de la Chataigneraie 692 Cesson-Sevigne - Rennes 35510 693 FRANCE 695 Phone: +33 299 12 70 04 696 Email: georgios.papadopoulos@imt-atlantique.fr 698 Greg Mirsky 699 ZTE Corp. 701 Email: gregory.mirsky@ztetx.com 702 Carlos J. Bernardos 703 Universidad Carlos III de Madrid 704 Av. Universidad, 30 705 Leganes, Madrid 28911 706 Spain 708 Phone: +34 91624 6236 709 Email: cjbc@it.uc3m.es 710 URI: http://www.it.uc3m.es/cjbc/