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