idnits 2.17.1 draft-ietf-detnet-oam-framework-05.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (14 October 2021) is 918 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-15 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-06 == Outdated reference: A later version (-15) exists of draft-mirsky-ippm-hybrid-two-step-11 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Informational F. Theoleyre 5 Expires: 17 April 2022 CNRS 6 G.Z. Papadopoulos 7 IMT Atlantique 8 CJ. Bernardos 9 UC3M 10 B. Varga 11 J. Farkas 12 Ericsson 13 14 October 2021 15 Framework of Operations, Administration and Maintenance (OAM) for 16 Deterministic Networking (DetNet) 17 draft-ietf-detnet-oam-framework-05 19 Abstract 21 Deterministic Networking (DetNet), as defined in RFC 8655, is aimed 22 to provide a bounded end-to-end latency on top of the network 23 infrastructure, comprising both Layer 2 bridged and Layer 3 routed 24 segments. This document's primary purpose is to detail the specific 25 requirements of the Operation, Administration, and Maintenance (OAM) 26 recommended to maintain a deterministic network. With the 27 implementation of the OAM framework in DetNet, an operator will have 28 a real-time view of the network infrastructure regarding the 29 network's ability to respect the Service Level Objective, such as 30 packet delay, delay variation, and packet loss ratio, assigned to 31 each DetNet flow. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 17 April 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 2. Role of OAM in DetNet . . . . . . . . . . . . . . . . . . . . 5 71 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. Information Collection . . . . . . . . . . . . . . . . . 7 73 3.2. Continuity Check . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Connectivity Verification . . . . . . . . . . . . . . . . 7 75 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 8 76 3.5. Fault Verification/detection . . . . . . . . . . . . . . 8 77 3.6. Fault Localization and Characterization . . . . . . . . . 8 78 3.7. Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . 9 79 4. Administration . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Collection of metrics . . . . . . . . . . . . . . . . . . 10 81 4.2. Worst-case metrics . . . . . . . . . . . . . . . . . . . 10 82 5. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.1. Replication / Elimination . . . . . . . . . . . . . . . . 10 84 5.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 85 5.3. Soft transition after reconfiguration . . . . . . . . . . 11 86 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.1. Requirements on OAM for DetNet Forwarding Sub-layer . . . 12 88 6.2. Requirements on OAM for DetNet Service Sub-layer . . . . 12 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 94 10.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 Deterministic Networking (DetNet) [RFC8655] has proposed to provide a 100 bounded end-to-end latency on top of the network infrastructure, 101 comprising both Layer 2 bridged and Layer 3 routed segments. That 102 work encompasses the data plane, OAM, time synchronization, 103 management, control, and security aspects. 105 Operations, Administration, and Maintenance (OAM) Tools are of 106 primary importance for IP networks [RFC7276]. DetNet OAM should 107 provide a toolset for fault detection, localization, and performance 108 measurement. 110 This document's primary purpose is to detail the specific 111 requirements of the OAM features recommended to maintain a 112 deterministic/reliable network. Specifically, it investigates the 113 requirements for a deterministic network, supporting critical flows. 115 In this document, the term OAM will be used according to its 116 definition specified in [RFC6291]. DetNet expects to implement an 117 OAM framework to maintain a real-time view of the network 118 infrastructure, and its ability to respect the Service Level 119 Objectives (SLO), such as in-order packet delivery, packet delay, 120 delay variation, and packet loss ratio, assigned to each DetNet flow. 122 This document lists the functional requirements toward OAM for DetNet 123 domain. The list can further be used for gap analysis of available 124 OAM tools to identify possible enhancements of existing or whether 125 new OAM tools are required to support proactive and on-demand path 126 monitoring and service validation. 128 1.1. Terminology 130 This document uses definitions, particularly of a DetNet flow, 131 provided in Section 2.1 [RFC8655]. The following terms are used 132 throughout this document as defined below: 134 * DetNet OAM domain: a DetNet network used by the monitored DetNet 135 flow. A DetNet OAM domain (also referred to in this document as 136 "OAM domain") may have MEPs on its edge and MIPs within. 138 * DetNet OAM instance: a function that monitors a DetNet flow for 139 defects and/or measures its performance metrics. Within this 140 document, a shorter version, OAM instance, is used 141 interchangeably. 143 * Maintenance End Point (MEP): an OAM instance that is capable of 144 generating OAM test packets in the particular sub-layer of the 145 DetNet OAM domain. 147 * Maintenance Intermediate endPoint (MIP): an OAM instance along the 148 DetNet flow in the particular sub-layer of the DetNet OAM domain. 149 A MIP MAY respond to an OAM message generated by the MEP at its 150 sub-layer of the same DetNet OAM domain. 152 * Control and management plane: the control and management planes 153 are used to configure and control the network (long-term). 154 Relative to a DetNet flow, the control and/or management plane can 155 be out-of-band. 157 * Active measurement methods (as defined in [RFC7799]) modify a 158 DetNet flow by inserting novel fields, injecting specially 159 constructed test packets [RFC2544]). 161 * Passive measurement methods [RFC7799] infer information by 162 observing unmodified existing flows. 164 * Hybrid measurement methods [RFC7799] is the combination of 165 elements of both active and passive measurement methods. 167 * In-band OAM is an active OAM is considered in-band in the 168 monitored DetNet OAM domain when it traverses the same set of 169 links and interfaces receiving the same QoS and Packet 170 Replication, Elimination, and Ordering Functions (PREOF) treatment 171 as the monitored DetNet flow. 173 * Out-of-band OAM is an active OAM whose path through the DetNet 174 domain is not topologically identical to the path of the monitored 175 DetNet flow, or its test packets receive different QoS and/or 176 PREOF treatment, or both. 178 * On-path telemetry can be realized as a hybrid OAM method. The 179 origination of the telemetry information is inherently in-band as 180 packets in a DetNet flow are used as triggers. Collection of the 181 on-path telemetry information can be performed using in-band or 182 out-of-band OAM methods. 184 1.2. Acronyms 186 OAM: Operations, Administration, and Maintenance 188 DetNet: Deterministic Networking 190 PREOF: Packet Replication, Elimination and Ordering Functions 191 SLO: Service Level Objective 193 1.3. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in BCP 198 14 [RFC2119] [RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 2. Role of OAM in DetNet 203 DetNet networks expect to provide communications with predictable low 204 packet delay and packet loss. Most critical applications will define 205 an SLO to be required for the DetNet flows it generates. 207 To respect strict guarantees, DetNet can use an orchestrator able to 208 monitor and maintain the network. Typically, a Software-Defined 209 Network (SDN) controller places DetNet flows in the deployed network 210 based on their SLO. Thus, resources have to be provisioned a priori 211 for the regular operation of the network. OAM represents the 212 essential elements of the network operation and necessary for OAM 213 resources that need to be accounted for to maintain the network 214 operational. 216 Many legacy OAM tools can be used in DetNet networks, but they are 217 not able to cover all the aspects of deterministic networking. 218 Fulfilling strict guarantees is essential for DetNet flows, resulting 219 in new DetNet specific functionalities that must be covered with OAM. 220 Filling these gaps is inevitable and needs accurate consideration of 221 DetNet specifics. Similar to DetNet flows itself, their OAM needs 222 careful end-to-end engineering as well. 224 For example, appropriate placing of MEPs along the path of a DetNet 225 flow is not always a trivial task and may require proper design 226 together with the design of the service component of a given DetNet 227 flow. 229 There are several DetNet specific challenges for OAM. Bounded 230 network characteristics (e.g., delay, loss) are inseparable service 231 parameters; therefore, PM is a key topic for DetNet. OAM tools are 232 needed to prove the SLO without impacting the DetNet flow 233 characteristics. A further challenge is the strict resource 234 allocation. Resources used by OAM must be considered and allocated 235 to avoid disturbing DetNet flow(s). 237 The DetNet Working Group has defined two sub-layers: 239 DetNet service sub-layer, at which a DetNet service (e.g., service 240 protection) is provided. 242 DetNet forwarding sub-layer, which optionally provides resource 243 allocation for DetNet flows over paths provided by the underlying 244 network. 246 OAM mechanisms exist for the DetNet forwarding sub-layer, 247 nonetheless, OAM for the service sub-layer requires new OAM 248 procedures. These new OAM functions must allow, for example, to 249 recognize/discover DetNet relay nodes, to get information about their 250 configuration, and to check their operation or status. 252 DetNet service sub-layer functions using a sequence number. That 253 creates a challenge for inserting OAM packets in the DetNet flow. 255 Fault tolerance also assumes that multiple paths could be provisioned 256 to maintain an end-to-end circuit by adapting to the existing 257 conditions. The central controller/orchestrator typically controls 258 the PREOF on a node. OAM is expected to support monitoring and 259 troubleshooting PREOF on a particular node and within the domain. 261 Note that distributed controllers can also control PREOF in those 262 scenarios where DetNet solutions involve more than one single central 263 controller. 265 DetNet forwarding sub-layer is based on legacy technologies and has a 266 much better coverage regarding OAM. However, the forwarding sub- 267 layer is terminated at DetNet relay nodes, so the end-to-end OAM 268 state of forwarding may be created only based on the status of 269 multiple forwarding sub-layer segments serving a given DetNet flow 270 (e.g., in case of DetNet MPLS, there may be no end-to-end LSP below 271 the DetNet PW). 273 3. Operation 275 OAM features will enable DetNet with robust operation both for 276 forwarding and routing purposes. 278 It is worth noting that the test and data packets MUST follow the 279 same path, i.e., the connectivity verification has to be conducted 280 in-band without impacting the data traffic. Test packets MUST share 281 fate with the monitored data traffic without introducing congestion 282 in normal network conditions. 284 3.1. Information Collection 286 Information about the state of the network can be collected using 287 several mechanisms. Some protocols, e.g., Simple Network Management 288 Protocol, send queries. Others, e.g., YANG-based data models, 289 generate notifications based on the publish-subscribe method. In 290 either way, information is collected and sent to the controller. 292 Also, we can characterize methods of transporting OAM information 293 relative to the path of data. For instance, OAM information may be 294 transported in-band or out-of-band relative to the DetNet flow. In 295 case of the former, the telemetry information uses resources 296 allocated for the monitored DetNet flow. If an in-band method of 297 transporting telemetry is used, the amount of generated information 298 needs to be carefully analyzed, and additional resources must be 299 reserved. [I-D.ietf-ippm-ioam-data] defines the in-band transport 300 mechanism where telemetry information is collected in the data packet 301 on which information is generated. Two tracing methods are described 302 - end-to-end, i.e., from the ingress and egress nodes, and hop-by- 303 hop, i.e., like end-to-end with additional information from transit 304 nodes. [I-D.ietf-ippm-ioam-direct-export] and 305 [I-D.mirsky-ippm-hybrid-two-step] are examples of out-of-band 306 telemetry transport. In the former case, information is transported 307 by each node traversed by the data packet of the monitored DetNet 308 flow in a specially constructed packet. In the latter, information 309 is collected in a sequence of follow-up packets that traverse the 310 same path as the data packet of the monitored DetNet flow. In both 311 methods, transport of the telemetry can avoid using resources 312 allocated for the DetNet domain. 314 3.2. Continuity Check 316 Continuity check is used to monitor the continuity of a path, i.e., 317 that there exists a way to deliver the packets between two MEP A and 318 MEP B. The continuity check detects a network failure in one 319 direction, from the MEP transmitting test packets to the remote 320 egress MEP. 322 3.3. Connectivity Verification 324 In addition to the Continuity Check, DetNet solutions have to verify 325 the connectivity. This verification considers additional 326 constraints, i.e., the absence of misconnection. The misconnection 327 error state is entered after several consecutive test packets from 328 other DetNet flows are received. The definition of the conditions of 329 entry and exit for misconnection error state is outside the scope of 330 this document. 332 3.4. Route Tracing 334 Ping and traceroute are two ubiquitous tools that help localize and 335 characterize a failure in the network. They help to identify a 336 subset of the list of routers in the route. However, to be 337 predictable, resources are reserved per flow in DetNet. Thus, DetNet 338 needs to define route tracing tools able to track the route for a 339 specific flow. Also, tracing can be used for the discovery of the 340 Path Maximum Transmission Unit or location of elements of PREOF for 341 the particular route in the DetNet domain. 343 DetNet is NOT RECOMMENDED to use multiple paths or links, i.e., 344 Equal-Cost Multipath (ECMP) [RFC8939]. As the result, OAM in ECMP 345 environment is outside the scope of this document. 347 3.5. Fault Verification/detection 349 DetNet expects to operate fault-tolerant networks. Thus, mechanisms 350 able to detect faults before they impact the network performance are 351 needed. 353 The network has to detect when a fault occurred, i.e., the network 354 has deviated from its expected behavior. While the network must 355 report an alarm, the cause may not be identified precisely. For 356 instance, the end-to-end reliability has decreased significantly, or 357 a buffer overflow occurs. 359 DetNet OAM mechanisms SHOULD allow a fault detection in real time. 360 They MAY, when possible, predict faults based on current network 361 conditions. They MAY also identify and report the cause of the 362 actual/predicted network failure. 364 3.6. Fault Localization and Characterization 366 An ability to localize the network defect and provide its 367 characterization are necessary elements of network operation. 369 Fault localization, a process of deducing the location of a 370 network failure from a set of observed failure indications, might 371 be achieved, for example, by tracing the route of the DetNet flow 372 in which the network failure was detected. Another method of 373 fault localization can correlate reports of failures from a set of 374 interleaving sessions monitoring path continuity. 376 Fault characterization is a process of identifying the root cause 377 of the problem. For instance, misconfiguration or malfunction of 378 PREOF elements can be the cause of erroneous packet replication or 379 extra packets being flooded in the DetNet domain. 381 3.7. Use of Hybrid OAM in DetNet 383 Hybrid OAM methods are used in performance monitoring and defined in 384 [RFC7799] as: 386 Hybrid Methods are Methods of Measurement that use a combination 387 of Active Methods and Passive Methods. 389 A hybrid measurement method may produce metrics as close to passive, 390 but it still alters something in a data packet even if that is the 391 value of a designated field in the packet encapsulation. One example 392 of such a hybrid measurement method is the Alternate Marking method 393 (AMM) described in [RFC8321]. As with all on-path telemetry methods, 394 AMM in a DetNet domain with the IP data plane is natively in-band in 395 respect to the monitored DetNet flow. Because the marking is applied 396 to a data flow, measured metrics are directly applicable to the 397 DetNet flow. AMM minimizes the additional load on the DetNet domain 398 by using nodal collection and computation of performance metrics in 399 combination with optionally using out-of-band telemetry collection 400 for further network analysis. 402 4. Administration 404 The network SHOULD expose a collection of metrics to support an 405 operator making proper decisions, including: 407 * Queuing Delay: the time elapsed between a packet enqueued and its 408 transmission to the next hop. 410 * Buffer occupancy: the number of packets present in the buffer, for 411 each of the existing flows. 413 The following metrics SHOULD be collected: 415 * per a DetNet flow to measure the end-to-end performance for a 416 given flow. Each of the paths has to be isolated in multipath 417 routing strategies. 419 * per path to detect misbehaving path when multiple paths are 420 applied. 422 * per device to detect misbehaving device, when it relays the 423 packets of several flows. 425 4.1. Collection of metrics 427 DetNet OAM SHOULD optimize the number of statistics / measurements to 428 collected, frequency of collecting. Distributed and centralized 429 mechanisms MAY be used in combination. Periodic and event-triggered 430 collection information characterizing the state of a network MAY be 431 used. 433 4.2. Worst-case metrics 435 DetNet aims to enable real-time communications on top of a 436 heterogeneous multi-hop architecture. To make correct decisions, the 437 controller needs to know the distribution of packet losses/delays for 438 each flow, and each hop of the paths. In other words, the average 439 end-to-end statistics are not enough. The collected information must 440 be sufficient to allow the controller to predict the worst-case. 442 5. Maintenance 444 In the face of events that impact the network operation (e.g., link 445 up/down, device crash/reboot, flows starting and ending), the DetNet 446 Controller need to perform repair and re-optimization actions in 447 order to permanently ensure the SLO of all active flows with minimal 448 waste of resources The controller MUST be able to continuously 449 retrieve the state of the network, to evaluate conditions and trends 450 about the relevance of a reconfiguration, quantifying: 452 the cost of the sub-optimality: resources may not be used 453 optimally (e.g., a better path exists). 455 the reconfiguration cost: the controller needs to trigger some 456 reconfigurations. For this transient period, resources may be 457 twice reserved, and control packets have to be transmitted. 459 Thus, reconfiguration may only be triggered if the gain is 460 significant. 462 5.1. Replication / Elimination 464 When multiple paths are reserved between two MEPs, packet replication 465 may be used to introduce redundancy and alleviate transmission errors 466 and collisions. For instance, in Figure 1, the source device S is 467 transmitting the packet to both parents, devices A and B. Each MEP 468 will decide to trigger the packet replication, elimination or the 469 ordering process when a set of metrics passes a threshold value. 471 ===> (A) => (C) => (E) === 472 // \\// \\// \\ 473 source (S) //\\ //\\ (R) (root) 474 \\ // \\ // \\ // 475 ===> (B) => (D) => (F) === 477 Figure 1: Packet Replication: S transmits twice the same data 478 packet, to DP(A) and AP (B). 480 5.2. Resource Reservation 482 Because the quality of service criteria associated with a path may 483 degrade, the network has to provision additional resources along the 484 path. We need to provide mechanisms to patch the network 485 configuration. 487 5.3. Soft transition after reconfiguration 489 Since DetNet expects to support real-time flows, DetNet OAM MUST 490 support soft-reconfiguration, where the the additional resources are 491 reserved before the those previously reserved but not in use are 492 released. Some mechanisms have to be proposed so that packets are 493 forwarded through the novel track only when the resources are ready 494 to be used, while maintaining the global state consistent (no packet 495 reordering, duplication, etc.) 497 6. Requirements 499 According to [RFC8655], DetNet functionality is divided into 500 forwarding and service sub-layers. The DetNet forwarding sub-layer 501 includes DetNet transit nodes and may allocate resources for a DetNet 502 flow over paths provided by the underlay network. The DetNet service 503 sub-layer includes DetNet relay nodes and provides a DetNet service 504 (e.g., service protection). This section lists general requirements 505 for DetNet OAM as well as requirements in each of the DetNet sub- 506 layers of a DetNet domain. 508 1. It MUST be possible to initiate a DetNet OAM session from a MEP 509 located at a DetNet node towards downstream MEP(s) within the 510 given domain at a particular DetNet sub-layer. [Ed.note: FT: A 511 MEP may be inside the detnet domain: for instance, for PREOF, an 512 OAM session may be maintained between any pair of replicator / 513 eliminator / egress / ingress.] 515 2. It MUST be possible to initialize a DetNet OAM session from a 516 centralized controller. 518 3. DetNet OAM MUST support proactive and on-demand OAM monitoring 519 and measurement methods. 521 4. DetNet OAM MUST support unidirectional OAM methods, continuity 522 check, connectivity verification, and performance measurement. 524 5. OAM methods MAY combine in-band monitoring or measurement in the 525 forward direction and out-of-bound notification in the reverse 526 direction, i.e., towards the ingress MEP. 528 6. DetNet OAM MUST support bi-directional DetNet flows. 530 7. DetNet OAM MAY support bi-directional OAM methods for 531 bidirectional DetNet flows. OAM test packets used for 532 monitoring and measurements MUST be in-band in both directions. 534 8. DetNet OAM MUST support proactive monitoring of a DetNet device 535 reachability for a given DetNet flow. 537 9. DetNet OAM MAY support hybrid performance measurement methods. 539 10. DetNet OAM MUST support unidirectional performance measurement 540 methods. Calculated performance metrics MUST include but are 541 not limited to throughput, packet loss, out of order, delay and 542 delay variation metrics. [RFC6374] provides detailed 543 information on performance measurement and performance metrics. 545 6.1. Requirements on OAM for DetNet Forwarding Sub-layer 547 1. DetNet OAM MUST support Path Maximum Transmission Unit discovery. 549 2. DetNet OAM MUST support Remote Defect Indication notification to 550 the DetNet OAM instance performing continuity checking. 552 3. DetNet OAM MUST support monitoring levels of resources allocated 553 for the particular DetNet flow. Such resources include but not 554 limited to buffer utilization, scheduler transmission calendar. 556 4. DetNet OAM MUST support monitoring any sub-set of paths traversed 557 through the DetNet domain by the DetNet flow. 559 6.2. Requirements on OAM for DetNet Service Sub-layer 561 The OAM functions for the DetNet service sub-layer allow, for 562 example, to recognize/discover DetNet relay nodes, to get information 563 about their configuration, and to check their operation or status. 565 The requirements on OAM for a DetNet relay node are: 567 1. DetNet OAM MUST provide OAM functions for the DetNet service sub- 568 layer. 570 2. DetNet OAM MUST support the discovery of DetNet relay nodes in a 571 DetNet network. 573 3. DetNet OAM MUST support the discovery of Packet Replication, 574 Elimination, and Order preservation sub-functions locations in 575 the domain. 577 4. DetNet OAM MUST support the collection of the DetNet service sub- 578 layer specific (e.g., configuration/operation/status) information 579 from DetNet relay nodes. 581 5. DetNet OAM MUST support excercising functionality of Packet 582 Replication, Elimination, and Order preservation sub-functions in 583 the domain. 585 6. DetNet OAM MUST work for DetNet data planes - MPLS and IP. 587 7. DetNet OAM MUST support defect notification mechanism, like Alarm 588 Indication Signal. Any DetNet relay node within the given DetNet 589 flow MAY originate a defect notification addressed to any subset 590 of DetNet relay nodes within that flow. 592 8. DetNet OAM MUST be able to measure metrics (e.g. delay) inside a 593 collection of OAM sessions, specially for complex DetNet flows, 594 with PREOF features. 596 7. IANA Considerations 598 This document has no actionable requirements for IANA. This section 599 can be removed before the publication. 601 8. Security Considerations 603 This document lists the OAM requirements for a DetNet domain and does 604 not raise any security concerns or issues in addition to ones common 605 to networking and those specific to a DetNet discussed in [RFC9055]. 607 9. Acknowledgments 609 The authors express their appreciation and gratitude to Pascal 610 Thubert for the review, insightful questions, and helpful comments. 612 10. References 614 10.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 622 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 623 May 2017, . 625 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 626 "Deterministic Networking Architecture", RFC 8655, 627 DOI 10.17487/RFC8655, October 2019, 628 . 630 10.2. Informative References 632 [I-D.ietf-ippm-ioam-data] 633 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 634 for In-situ OAM", Work in Progress, Internet-Draft, draft- 635 ietf-ippm-ioam-data-15, 3 October 2021, 636 . 639 [I-D.ietf-ippm-ioam-direct-export] 640 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 641 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 642 OAM Direct Exporting", Work in Progress, Internet-Draft, 643 draft-ietf-ippm-ioam-direct-export-06, 8 August 2021, 644 . 647 [I-D.mirsky-ippm-hybrid-two-step] 648 Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid 649 Two-Step Performance Measurement Method", Work in 650 Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two- 651 step-11, 8 July 2021, 652 . 655 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 656 Network Interconnect Devices", RFC 2544, 657 DOI 10.17487/RFC2544, March 1999, 658 . 660 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 661 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 662 Acronym in the IETF", BCP 161, RFC 6291, 663 DOI 10.17487/RFC6291, June 2011, 664 . 666 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 667 Measurement for MPLS Networks", RFC 6374, 668 DOI 10.17487/RFC6374, September 2011, 669 . 671 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 672 Weingarten, "An Overview of Operations, Administration, 673 and Maintenance (OAM) Tools", RFC 7276, 674 DOI 10.17487/RFC7276, June 2014, 675 . 677 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 678 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 679 May 2016, . 681 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 682 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 683 "Alternate-Marking Method for Passive and Hybrid 684 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 685 January 2018, . 687 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 688 Bryant, "Deterministic Networking (DetNet) Data Plane: 689 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 690 . 692 [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, 693 "Deterministic Networking (DetNet) Security 694 Considerations", RFC 9055, DOI 10.17487/RFC9055, June 695 2021, . 697 Authors' Addresses 699 Greg Mirsky 700 Ericsson 702 Email: gregimirsky@gmail.com 704 Fabrice Theoleyre 705 CNRS 706 300 boulevard Sebastien Brant - CS 10413 707 67400 Illkirch - Strasbourg 708 France 710 Phone: +33 368 85 45 33 711 Email: theoleyre@unistra.fr 712 URI: http://www.theoleyre.eu 714 Georgios Z. Papadopoulos 715 IMT Atlantique 716 Office B00 - 102A 717 2 Rue de la Châtaigneraie 718 35510 Cesson-Sévigné - Rennes 719 France 721 Phone: +33 299 12 70 04 722 Email: georgios.papadopoulos@imt-atlantique.fr 724 Carlos J. Bernardos 725 Universidad Carlos III de Madrid 726 Av. Universidad, 30 727 28911 Leganes, Madrid 728 Spain 730 Phone: +34 91624 6236 731 Email: cjbc@it.uc3m.es 732 URI: http://www.it.uc3m.es/cjbc/ 734 Balazs Varga 735 Ericsson 736 Budapest 737 Magyar Tudosok krt. 11. 738 1117 739 Hungary 741 Email: balazs.a.varga@ericsson.com 743 Janos Farkas 744 Ericsson 745 Budapest 746 Magyar Tudosok krt. 11. 747 1117 748 Hungary 750 Email: janos.farkas@ericsson.com