Operations and Management Area Working Group L. M. Contreras Internet-Draft Telefonica Intended status: Standards Track V. Lopez Expires: 3 April 2027 Nokia Q. Wu Huawei 30 September 2026 A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests draft-ietf-opsawg-scheduling-oam-tests-10 Abstract This document defines two YANG Data Models to support scheduled network diagnosis using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam- sequence-test' YANG modules to manage the lifecycle of network diagnosis procedures, intended for use by external management and orchestration systems (including SDN controllers and network orchestrators), rather than by individual network nodes. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://vlopezalvarez.github.io/draft-contreras-opsawg-scheduling- oam-tests/draft-ietf-opsawg-scheduling-oam-tests.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-scheduling-oam- tests/. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (mailto:opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Subscribe at https://www.ietf.org/mailman/listinfo/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling- oam-tests. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Contreras, et al. Expires 3 April 2027 [Page 1] Internet-Draft Scheduling OAM YANG September 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Notations . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.3. Prefix in Data Node Names . . . . . . . . . . . . . . . . 6 2. Sample OAM Test Scheduling Network Model Usage . . . . . . . 7 3. Network-wide OAM Use Cases . . . . . . . . . . . . . . . . . 8 3.1. Troubleshooting . . . . . . . . . . . . . . . . . . . . . 8 3.2. Birth Certificate . . . . . . . . . . . . . . . . . . . . 8 3.3. Proactive Supervision . . . . . . . . . . . . . . . . . . 9 3.4. Performance-based Traffic Engineering and Routing . . . . 10 4. Modelling the Scheduling of OAM Tests . . . . . . . . . . . . 10 4.1. OAM Unitary Test . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Unitary Test Status State Machine . . . . . . . . . . 13 4.2. OAM Sequence Test . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Sequence Test Status State Machine . . . . . . . . . 17 5. YANG Data Models for Scheduling OAM Tests . . . . . . . . . . 18 5.1. YANG Model for Scheduling OAM Unitary Test . . . . . . . 18 5.2. YANG Model for OAM Sequence Test . . . . . . . . . . . . 25 6. Using Device Model Within OAM Scheduling Models . . . . . . . 28 7. Operational Considerations . . . . . . . . . . . . . . . . . 29 Contreras, et al. Expires 3 April 2027 [Page 2] Internet-Draft Scheduling OAM YANG September 2026 7.1. Conflict Resolution and Reporting Among Scheduled OAM Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2. Coverage of Input Parameters and Output Results . . . . . 31 7.3. Use of the Managed Leaf . . . . . . . . . . . . . . . . . 31 7.4. Performance impact and Operational Guidance for concurrent OAM task scheduling . . . . . . . . . . . . . . . . . . . 32 7.5. Impact on Security Operations . . . . . . . . . . . . . . 32 7.6. Schedule Health Verification . . . . . . . . . . . . . . 33 7.7. Operational Considerations for Auditing and Results Tracking . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9.1. Updates to the IETF XML Registry for New YANG Module . . 35 9.2. Updates to the YANG Module Names Registry for New YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . . . 36 Informative References . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 42 A.1. Create a TWAMP OAM test . . . . . . . . . . . . . . . . . 42 A.2. Ping OAM Test Template . . . . . . . . . . . . . . . . . 45 Appendix B. Change between Revision . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 1. Introduction Operations, Administration, and Maintenance (OAM) tasks are fundamental functions of the network management (see, e.g., [RFC7276]). Given the emergence of data models and their utilization in Service Provider's network management and the need to automate the overall service management lifecycle [RFC8969], managing OAM operations is also essential. Relevant data models are still missing to cover specific needs. The term OAM is used in this document as defined in [RFC6291] and further characterized according to the classification guidelines in [RFC10014]. The scope of this document applies primarily to active and hybrid OAM mechanisms, as scheduling tests generally implies the generation of additional OAM traffic. Passive OAM mechanisms are not the focus of this work. Specifically, OAM functions provide the means to identify and isolate faults, measure and report the network performance (see section 4.2, [RFC6632]). For example, [RFC5860] defines the three main areas involved in OAM: Contreras, et al. Expires 3 April 2027 [Page 3] Internet-Draft Scheduling OAM YANG September 2026 * Fault management, which allows network operators quickly identify and isolate faults in the network. Examples of these mechanisms for fault detection and isolation are: continuity check, link trace, and loopback. * Performance management enables monitoring network performance and diagnosing performance issues (i.e., degradation). Some of the measurements such as packet delay measurement, packet delay variation measurement, and packet loss measurement. * Security management defines mechanisms to protect OAM communications from unauthorized access and tampering. [RFC7276] presents OAM tools for detecting and isolating failures in networks and for performance monitoring, some examples are: * Continuity Check: This function verifies that a path exists between two points in a network and that the path is operational. Some technologies following this approach are Y.1731 Continuity Check [ITU-T-Y1731], Ethernet OAM Continuity Check [IEEE-8021Q], MPLS-TP BFD CC [RFC6428]. * Loopback: This function allows a device to loop back a received packet back to the sender for diagnostic purposes. There are multiple technologies for this function, like IP Ping [RFC0792], [RFC4443], VCCV Ping [RFC5085], LSP Ping [RFC4379] or Ethernet Loopback [IEEE-8021Q]. * Link Trace: This function allows a network operator to trace a path through a network from one device to another. Some technologies following this approach are Y.1731 Linktrace [ITU-T-Y1731] or IP traceroute [RFC0792], [RFC4443]. * Performance Monitoring: This function allows a network operator to monitor the performance of a network and to identify and diagnose performance issues. Protocols like TWAMP [RFC5357], STAMP [RFC8762], Alternative Marking [RFC9341], IOAM (In Situ OAM) [RFC9197], or Y.1731 DMM/SLM [ITU-T-Y1731] can obtain performance measurements. More recently, Incident Management [I-D.ietf-nmop-network-incident-yang] focuses on the network incident diagnosis, which can be favored by dynamic invocation of OAM tests. [RFC8531], [RFC8532], [RFC8533] defined YANG models for OAM technologies: Contreras, et al. Expires 3 April 2027 [Page 4] Internet-Draft Scheduling OAM YANG September 2026 o [RFC8531] "A YANG Data Model for Connection Oriented OAM": defines a YANG data model for connection-oriented OAM protocols. The main aim of this document is to define a generic YANG data model that can be used to configure, control, and monitor connection-oriented OAM protocols such as MPLS-TP OAM [RFC6371] and TRILL OAM [RFC7174]. o [RFC8532] "A YANG Data Model for Connectionless OAM Protocols": provides a generic YANG data model that can be used to configure, control, and monitor connectionless OAM protocols such as BFD (Bidirectional Forwarding Detection) [RFC5880], ICMP Ping [RFC792] [RFC4443], and LSP Ping [RFC8029]. o [RFC8533] "A YANG Data Model for Retrieval Methods for the Management of OAM Protocols that Use Connectionless Communications": provides a YANG data model that can be used to retrieve information related to OAM protocols such as BFD (Bidirectional Forwarding Detection) [RFC5880], ICMP Ping [RFC792] [RFC4443], and LSP Ping [RFC8029]. These OAM related YANG data models at the device level defined parameters required for each of the different tests that are used in network elements today. This work aims to reuse and build upon existing YANG models for OAM technologies, such as those defined in [RFC8531], [RFC8532], and [RFC8533]. By leveraging these foundational models, this document specifies two Network Models [RFC8969] for scheduling and coordinating sequences of OAM tests, enabling more advanced and automated network diagnosis procedures. In addition to reusing the device-level OAM YANG models from [RFC8531], [RFC8532], and [RFC8533], this document builds upon the generic scheduling framework defined in [RFC9922]. The ietf-schedule module provides reusable groupings and mechanisms for specifying periods of time, recurrence rules, and scheduling status. These constructs are directly imported and used in the OAM unitary test and OAM sequence test models defined in this document, enabling precise scheduling, repetition, and conflict reporting for OAM tasks in a network-wide context. 1.1. Terminology and Notations This document assumes that the reader is familiar with the contents of [RFC7950] "The YANG 1.1 Data Modeling Language". Following terms are used for the representation of this data model: o OAM Unitary Test: A single OAM test which is executed at each scheduled time. Contreras, et al. Expires 3 April 2027 [Page 5] Internet-Draft Scheduling OAM YANG September 2026 o OAM sequence test: A set of OAM Unitary Tests that are executed on a specified order at each scheduled time. Tree diagrams used in this document follow the notation defined in [RFC8340]. This document adopts the OAM characterization defined in [RFC10014]: o Active OAM – uses dedicated OAM packets to assess network performance or verify continuity. o Passive OAM – observes existing data traffic without injecting OAM packets. o Hybrid OAM – combines active and passive methods. The use of the terms in-band and out-of-band is avoided in this document, consistent with [RFC10014]. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Prefix in Data Node Names In this document, names of data nodes and other data model objects will be prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in the following table. +========+========================+===========+ | Prefix | Yang Module | Reference | +========+========================+===========+ | oamut | ietf-oam-unitary-test | RFCXXXX | +--------+------------------------+-----------+ | oamts | ietf-oam-sequence-test | RFCXXXX | +--------+------------------------+-----------+ | yang | ietf-yang-types | [RFC6991] | +--------+------------------------+-----------+ Table 1: Prefixes and Corresponding YANG Modules Contreras, et al. Expires 3 April 2027 [Page 6] Internet-Draft Scheduling OAM YANG September 2026 RFC Editor Note: Please replace XXXX with the RFC number assigned to this document if the document becomes a RFC. Please remove this note in that case. 2. Sample OAM Test Scheduling Network Model Usage A service provider network's management operations can be automated using a variety of means such as interfaces based on YANG modules [RFC8969] [RFC6241] [RFC8040]. From that standpoint, and considering the architecture depicted in Figure 1, The goal of this document is to provide a mechanism to via a YANG-based northbound interface using ietf-oam-unitary-test and ietf-oam-sequence-test, manage the lifecycle of network diagnosis procedure from the network controller to network elements with a focus on scheduling Network Diagnosis. In addition, both the service orchestrator and the network controller can use schema mount mechanism [RFC8528] to retrieve ietf-yang- library data from the underlying network element and instantiate specific device-level OAM modules the network element supports under the designated data node (labeled as a mount-point) through YANG based interface or device CLI, a local script. If multiple identical devices are being managed, the network controller can reference a shared schema entry configured in its own/schema-mounts state data to mount the same model structure across all those network element locations. For more details on how schema mount works please refer to [RFC8528]. +-----------------+ | Customer | +--------+--------+ Customer Service Models | (e.g., L3SM, L2SM) | +--------+--------+ | Service | | Orchestration | +------+---+------+ Network Models | | OAM Test Scheduling (e.g., L3NM, L2NM) | | Network Model | | e.g.,ietf-oam-unitary-test +------+---+------+ | Network | | Controller | +--------+--------+ | Device OAM Model | (e.g., BFD, Connection | -oriented OAM) +---------------------+---------------------+ | Network | +-------------------------------------------+ Contreras, et al. Expires 3 April 2027 [Page 7] Internet-Draft Scheduling OAM YANG September 2026 Figure 1: OAM Test Scheduling Network Model Usage 3. Network-wide OAM Use Cases This document covers how to use OAM for network-wide use cases. These use cases rely primarily on active or hybrid OAM methods, depending on whether dedicated test packets or augmented data packets are used, following [RFC10014]. The following illustrative examples are provided. 3.1. Troubleshooting After the detection of a problem [RFC9940] in the network, OAM tests are performed to find the root cause for the detected problem. However, a detected problem can be caused by a variety of factors, such as a misconfiguration, hardware failure, or a software bug. OAM tests can help identify likely root causes by testing specific components of the network and looking for anomalies or issues. Also, the reliability and efficiency of the tests depend on the nature of the test itself. There are a variety of OAM tests that can be executed as a function of the target scenario. For example, if the issue is related to a Layer 2 capability, specific tests can be designed and run to check the status of the path via Ethernet Linktrace and later run an Ethernet Loopback to a concrete network element. These tests can be coupled with others to test if any filtering is in place by varying, e.g., some Layer 2 fields or checking the configuration of relevant nodes. If these tests are correct, the operator may want to check the availability of the service (or its delivered performance). Even though the troubleshooting process may be different depending on the problem detected, there are certain common procedures or logics that can be executed in order to narrow down the cause of the problem and thus help locate candidate root cause. 3.2. Birth Certificate The aim of a birth certificate process is to validate that all relevant parameters are set appropriately in accordance with the target network service. The birth certificate process is done once the configuration of the network elements is completed, and they are ready for service. Contreras, et al. Expires 3 April 2027 [Page 8] Internet-Draft Scheduling OAM YANG September 2026 If the birth certificate is successful, it means that the network service is functioning correctly (that is, measured service is matching the expected service) and meets the requirements defined by the operator. The process requires running a set of OAM tasks (e.g., tests) to verify that the service is performing as expected. The set of OAM tests conducted as part of a birth certificate process depends on the network service that is tested. For example, if the service is a Virtual Private Network (VPN), Two-Way Active Measurement Protocol (TWAMP) Light [RFC5357] will be used, while if the service is an E-LINE, ITU-T Y.1731 Ethernet PM tests [ITU-T-Y1731] will be executed. Typically, once the birth certificate process has been completed and the OAM tests have been executed, the test results are stored as part of the documentation process performed by the operator. Many of these tasks take place during pre-deployment phases. 3.3. Proactive Supervision Some network services require fulfillment of strict Service Level Agreements (SLAs). An SLA defines the performance parameters that the service must fulfill in order to meet the requirements of the customer or end user (e.g., IP Connectivity Provisioning Profile (CPP) [RFC7297] and Network Slice Service [RFC9543]). As part of service fulfillment and assurance (e.g., Section 2.3.3 of [RFC4176]), proactive verification is undertaken to assess whether SLAs are met and implement appropriate adjustment measures when service distortion is observed. Proactive supervision requires running tests not only end-to-end, but also on service components to identify early symptoms and resolve issues before they impact the customer or end user. This help prevent or minimize the impact of the end user. Mitigation action may be enforced to alleviate the impact of networks incidents and nullify the impact on services that are delivered via that network. Proactive testing might be done via OAM tests. These tests can be run periodically at regular intervals depending on the specific SLA requirements and the network operator procedures. These procedures may require documenting the test results for future auditing processes with the customers (eventually, negotiated and agreed with a customer as part of service assurance). Contreras, et al. Expires 3 April 2027 [Page 9] Internet-Draft Scheduling OAM YANG September 2026 3.4. Performance-based Traffic Engineering and Routing Path Computation Elements (PCEs) are used to compute end-to-end paths in a network [RFC4655]. PCEs are used for Traffic Engineering (TE) purposes (e.g., optimize network performance, reduce congestion, and improve the overall user experience). There are different algorithms to calculate a path in the network for some of them the PCE requires traffic engineering information. TE information includes data such as link metrics, bandwidth availability, and routing constraints. By using this information, the PCE can compute the optimal path for a particular service [RFC8233], taking into account its constraints and requirements. In addition to TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810], OAM techniques also allow obtaining link metrics like delay and loss which can be used in the PCE algorithms. 4. Modelling the Scheduling of OAM Tests This document specifies two models: OAM Unitary Test and OAM sequence test models. 4.1. OAM Unitary Test The OAM unitary test model encompasses parameters that define a specific type of OAM test to be performed. The YANG model includes a container named "oam-unitary-tests" that serves as a container for activating OAM unitary tests for network diagnosis procedures. Within the container, there is a list called "oam-unitary-test" representing a list of specific OAM unitary tests. The list key is defined as "name", which provides a unique name for each test. Each OAM test in the list conains "ne-config" list with "ne-id" as list key and references a test type with its concrete parameters. The test type indicate which OAM test YANG module, is mounted at the "root" mount point for that "ne-config" list entry. In addition, each OAM unitary test has two temporal parameters: "period" container and "recurrence" container. Both import groupings from the "ietf-schedule" module from [RFC9922]. "period" container identifies the one shot period values that contain a precise period of time and can be used to support on-demand troubleshooting, while "recurrence" container identifies the properties that contain a recurrence rule specification and can be used to periodic troubleshooting. To support on-demand troubleshooting and periodical troubleshooting, this document relies on standard data store configuration writes (like NETCONF edit-config or RESTCONF POST/PUT) rather than creating a custom RPC, while reading state via NETCONF get operations [RFC6241] or subscription to YANG notifications to Contreras, et al. Expires 3 April 2027 [Page 10] Internet-Draft Scheduling OAM YANG September 2026 dynamically stream the unitary-test-status [RFC8639], [RFC8641]. Moreover, "schedule:schedule-status" grouping has been imported from [RFC9922] to describe common properties of scheduling status. Wrap- around of the "counter" and "failure-counter" leaves is as specified in [RFC9922]. "unitary-test-status" leaf indicates the state of the OAM unitary test (see the state machine in Figure 3). Each oam-unitary-test instance defined by this model is conceptually an instance of an active or hybrid OAM operation, since it triggers the generation or coordination of OAM packets. The YANG model allows such differentiation by referencing the underlying test type identity. Figure 2 shows the structure of OAM Unitary Test module: Contreras, et al. Expires 3 April 2027 [Page 11] Internet-Draft Scheduling OAM YANG September 2026 module: ietf-oam-unitary-test +--rw oam-unitary-tests +--rw oam-unitary-test* [name] +--rw name string +--rw ne-config* [ne-id] | +--rw ne-id union | +--rw managed? boolean | +--rw test-type? identityref | +--rw root +--rw state? identityref +--rw version? uint16 +--rw schedule-type? identityref +--ro local-time? yang:date-and-time +--ro last-update? yang:date-and-time +--ro counter? yang:counter32 +--ro last-occurrence? yang:date-and-time +--ro upcoming-occurrence? yang:date-and-time +--ro last-failed-occurrence? yang:date-and-time +--ro failure-counter? yang:counter32 +--ro unitary-test-status? identityref +--rw (schedule-class)? +--:(period) | +--rw period | +--rw period-description? string | +--rw period-start? yang:date-and-time | +--rw time-zone-identifier? sys:timezone-name | +--rw (period-type)? | +--:(explicit) | | +--rw period-end? yang:date-and-time | +--:(duration) | +--rw duration? duration +--:(recurrence) +--rw recurrence +--rw recurrence-first | +--rw start-time-utc? yang:date-and-time | +--rw duration? uint32 +--rw (recurrence-end)? | +--:(until) | | +--rw utc-until? yang:date-and-time | +--:(count) | +--rw count? uint32 +--rw recurrence-description? string +--rw frequency? identityref +--rw interval? uint32 Figure 2: Tree Structure of OAM Unitary Test Contreras, et al. Expires 3 April 2027 [Page 12] Internet-Draft Scheduling OAM YANG September 2026 4.1.1. Unitary Test Status State Machine The 'unitary-test-status' state machine is shown in Figure 3. The state machine includes the following states: * "planned": The initial state where the test is planned by the management and hasn't been applied to any network element. * "configured": The state where the test is being configured. This state is triggered when the planned test configuration is applied to one or more network element(s). * "ready": The state where the test is ready to be executed. This state is triggered after the planned test configuration is applied and before the test is executed. * "on-going": The state where the test is currently running. This state is triggered when the test has been executed but the test results haven't been produced. * "error": The state where an error occurs during the test. This state is triggered when the test has not been conducted successfully. Implementations may report a more specific error cause using child identities such as "resource-contention" or "priority-conflict". * "stop": The state where the test is manually stopped. This state is triggered when the test is manually interrupted, using mechanisms which are outside the scope of this document. A manual stop is not a successful completion and is not an execution error; the next cycle, if any, starts from "planned". * "success": The final state where the test is completed. This state is triggered when the test has been conducted successfully. Note that how state transition triggering generation of YANG notifications and how external management and orchestration systems subscribe to these YANG notifications are not in the scope of this document. Contreras, et al. Expires 3 April 2027 [Page 13] Internet-Draft Scheduling OAM YANG September 2026 +---------+ +----------+ +---------+ +->| planned |----->|configured|----->| ready | | +---------+ +----------+ +---------+ | A A A | | | | | | | V | | | | +-------+ | +----------+ | | | ---| error |<--+----------| on-going | | | | +-------+ +----------+ | | | | | | | +--------+ | | | +----------| stop |<------------+ | | +--------+ | | | | | +---------+ | +-| success |<-----------------------------+ +---------+ Figure 3: OAM Unitary Test State Machine 4.2. OAM Sequence Test The OAM sequence test model consists of a collection of OAM unitary tests that are executed based on specified time constraints, repetitions, ordering, and reporting outputs. These sequences provide a structured approach to running multiple OAM tests in a coordinated manner. Note that each test sequence is local sequence configuration, any later changes to the configured unitary test template in the ietf-oam-unitary-test should not silently change an already configured sequence. Each OAM unitary test in Each OAM test sequence references an OAM unitary test type with its concrete parameters to indicate which OAM Test YANG module, is mounted at the "root" mount point for that "ne- config" list entry. Each OAM test sequence has two temporal parameters related to time constraints: "period" container and "recurrence" container and one constraint related to ordering: "ordered-by user". Time constraints parameters are imported from the "ietf-schedule" module from [RFC9922]. "period" identifies the one shot period values that contain a precise period of time and can be used to support on demand troubleshooting, while "recurrence" identifies the properties that contain a recurrence rule specification and can be used to support periodical troubleshooting. Note that the "recurrence" is only intended to expose current and latest summary state, per occurrence result history is outside the scope of this document. Future extension can choose to define notifications or other result model to report per occurence result history. Contreras, et al. Expires 3 April 2027 [Page 14] Internet-Draft Scheduling OAM YANG September 2026 To support on-demand troubleshooting and periodical troubleshooting, this document relies on standard data store configuration writes (like NETCONF edit-config or RESTCONF POST/PUT) rather than creating a custom RPC, while reading state via NETCONF get operations [RFC6241] or subscription to YANG notifications to dynamically stream the sequence-test-status [RFC8639], [RFC8641]. Moreover, "ordered-by user" YANG statement indicates that the user is responsible for the ordering on a collection of OAM unitary tests. "sequence-test-status" shows the state of the OAM test sequence. "state" imported from the "ietf-schedule" module indicates the current state of the schedule. Note that repetition is specified by "count" parameter and only applies to the recurrence schedule type. If no count is indicated, the test is considered to run indefinitely. In case of the recurrence schedule type, both frequency and interval should be specified. Each execution runs at the scheduled recurrence interval. Since the OAM sequence test model consists of a collection of OAM unitary tests, one or more tests on one or multiple ne nodes in the sequence might get an error, however error in one or more tests doesn't prevent the subsequent tests or remaining tests on the same ne nodes or on various different ne nodes to execute. In addition, any change to the ordering of the OAM sequence test will lead to different reporting output results therefore the user should have full control on the ordering and "ordered-by user" YANG statement needs to be specified. "ordered-by user" YANG statement indicates that the user is responsible for the ordering on a collection of OAM unitary tests. If two or more tests are to run concurrently, they MUST be run in the order specified by the user. Figure 4 shows the structure of OAM sequence test module: Contreras, et al. Expires 3 April 2027 [Page 15] Internet-Draft Scheduling OAM YANG September 2026 module: ietf-oam-sequence-test +--rw oam-sequence-test +--rw sequence-test* [name] +--rw name string +--rw unitary-test* [name] | +--rw name string | +--rw ne-config* [ne-id] | +--rw ne-id union | +--rw managed? boolean | +--rw test-type? identityref | +--rw root +--rw state? identityref +--rw version? uint16 +--rw schedule-type? identityref +--ro local-time? yang:date-and-time +--ro last-update? yang:date-and-time +--ro counter? yang:counter32 +--ro last-occurrence? yang:date-and-time +--ro upcoming-occurrence? yang:date-and-time +--ro last-failed-occurrence? yang:date-and-time +--ro failure-counter? yang:counter32 +--ro sequence-test-status? identityref +--rw (schedule-class)? +--:(period) | +--rw period | +--rw period-description? string | +--rw period-start? yang:date-and-time | +--rw time-zone-identifier? sys:timezone-name | +--rw (period-type)? | +--:(explicit) | | +--rw period-end? yang:date-and-time | +--:(duration) | +--rw duration? duration +--:(recurrence) +--rw recurrence +--rw recurrence-first | +--rw start-time-utc? yang:date-and-time | +--rw duration? uint32 +--rw (recurrence-end)? | +--:(until) | | +--rw utc-until? yang:date-and-time | +--:(count) | +--rw count? uint32 +--rw recurrence-description? string +--rw frequency? identityref +--rw interval? uint32 Figure 4: OAM sequence test Contreras, et al. Expires 3 April 2027 [Page 16] Internet-Draft Scheduling OAM YANG September 2026 4.2.1. Sequence Test Status State Machine The 'sequence-test-status' state machine is shown in Figure 5. The state machine includes the following states: * "planned": The initial state where the sequence test is planned by the management and hasn't been applied to any network element. * "configured": The state where the sequence test is being configured. This state is triggered when the planned test configuration is applied to one or more network element. * "ready": The state where the sequence test is ready to be executed. This state is triggered after the planned test configuration is applied and before the test is executed. * "on-going": The state where the sequence test is currently running. This state is triggered when the test has been executed but the test results haven't been produced. * "error": The state where an error occurs during the sequence test. This state is triggered when one or more tests haven't been conducted successfully. Implementations may report a more specific error cause using child identities such as "resource- contention" or "priority-conflict". * "stop": The state where the sequence test is manually stopped. This state is triggered when the test is manually interrupted,, using mechanisms which are outside the scope of this document. A manual stop is not a sequence failure and is not a successful completion; the next cycle, if any, starts from "planned". * "failure": The state when error occurs for one or more unitary tests in the sequence test while the sequence test continues to execute remaining unitary tests. * "success": The final state where all Unitary Tests in the sequence test are completed. This state is triggered when all unitary tests in the sequence test have been conducted successfully. Note that how state transition triggering generation of YANG notifications and how external management and orchestration systems subscribe to these YANG notifications are not in the scope of this document. Contreras, et al. Expires 3 April 2027 [Page 17] Internet-Draft Scheduling OAM YANG September 2026 +---------+ +----------+ +---------+ +->| planned |----->|configured|----->| ready | | +---------+ +----------+ +---------+ | A A A | | | | | | | V | | | | +-------+ | +----------+ | | | +-| error |<--+----------| on-going | | | | +-------+ +----------+ | | | | | | | +--------+ | | | +---------| stop |<------------+ | | +--------+ | | | | | | +---------+ | | +---------| failure |<---------------+ | +---------+ | | | | +---------+ | +-| success |<----------------------------+ +---------+ Figure 5: OAM sequence test state machine 5. YANG Data Models for Scheduling OAM Tests 5.1. YANG Model for Scheduling OAM Unitary Test This module imports typedefs from [RFC9922], [RFC8528] and [RFC9911], and it uses references defined in [RFC8531], [RFC8532], [RFC9617], [RFC8913], [RFC8029], [RFC9107]. file ietf-oam-unitary-test@2026-09-14.yang module ietf-oam-unitary-test { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-oam-unitary-test"; prefix "oamut"; import ietf-schedule { prefix schedule; reference "RFC 9922: A Common YANG Data Model for Scheduling"; } import ietf-yang-schema-mount { prefix yangmnt; reference "RFC 8528: YANG Schema Mount"; Contreras, et al. Expires 3 April 2027 [Page 18] Internet-Draft Scheduling OAM YANG September 2026 } import ietf-inet-types { prefix inet; reference "RFC 9911: Common YANG Data Types"; } import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: WG List: Author: Luis Miguel Contreras Murillo Author: Victor Lopez Author: Qin Wu "; description "This module defines the 'ietf-oam-unitary-test' YANG model for activation of network diagnosis procedures. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. "; // RFC Ed.: update the date below with the date of RFC // publication and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove // this note. Contreras, et al. Expires 3 April 2027 [Page 19] Internet-Draft Scheduling OAM YANG September 2026 revision "2026-09-14" { description "Initial version"; reference "RFCXXXX: A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests"; // Update with the correct RFC number when assigned } /* Identities */ identity unitary-test-status { description "Base identity for unitary test status. Note that it only allows extensible error reporting such as resource contention, priority conflict."; } identity planned { base unitary-test-status; description "Identity for planned."; } identity configured { base unitary-test-status; description "Identity for configured."; } identity ready { base unitary-test-status; description "Identity for ready."; } identity on-going { base unitary-test-status; description "Identity for on-going."; } identity stop { base unitary-test-status; description "Identity for stop."; } identity success { base unitary-test-status; description "Identity for success."; } identity error { Contreras, et al. Expires 3 April 2027 [Page 20] Internet-Draft Scheduling OAM YANG September 2026 base unitary-test-status; description "Identity for error."; } identity resource-contention { base error; description "Identity for resource contention conflict. Resource contention conflict is referred to two OAM tests require exclusive access to the same resource at the same time."; } identity priority-conflict { base error; description "Identity for priority based conflict. The prioritization-related conflict occurs when a higher-priority OAM test preempts, defers, or cancels a lower-priority OAM test because they are competing for the exact same network execution resources at the same time."; } identity test-type { description "Base identity of the test type."; } identity connection-oriented-oam { base test-type; description "Base identity of connection oriented oam test type."; reference "RFC 8531: Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols"; } identity connectionless-oam { base test-type; description "Base identity of connectionless oam test type."; reference "RFC 8532: Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications"; } identity in-situ-oam { base test-type; description Contreras, et al. Expires 3 April 2027 [Page 21] Internet-Draft Scheduling OAM YANG September 2026 "Base identity of In Situ OAM test type."; reference "RFC 9617: A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity twamp { base test-type; description "Base identity of TWAMP test type."; reference "RFC 8913: Two-Way Active Measurement Protocol (TWAMP) YANG Data Model"; } identity ip-ping { base connectionless-oam; description "Base identity of IP Ping test type."; reference "RFC 792: nternet Control Message Protocol"; } identity lsp-ping { base connection-oriented-oam; description "Base identity of MPLS LSP Ping test type."; reference "RFC 8029: Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"; } identity srmpls-ping { base connection-oriented-oam; description "Base identity of SR MPLS Ping test type."; reference "RFC 9716: Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks"; } identity bfd { base test-type; description "Base identity of BFD test type."; reference "RFC 9107: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } grouping oam-unitary-test { description "Specifies a grouping for OAM unitary test for network diagnosis procedures. This grouping has been defined to allow being imported and Contreras, et al. Expires 3 April 2027 [Page 22] Internet-Draft Scheduling OAM YANG September 2026 reused by other YANG modules."; leaf name { type string; description "Defines the name of the test."; } list ne-config { key ne-id; description "List of node configurations required to enable the unitary tests."; leaf ne-id { type union { type inet:host; type nw:node-id; } description "This is identification of a network node within an autonomous system such as router, switch, firewalls, etc. It should be as fine-grained as possible to both guide the operator and guarantee uniqueness of the network element."; } leaf managed { type boolean; default "true"; description "True if the host can access oam unitary test using the root mount point. This value may not be modifiable in all implementations."; } leaf test-type { type identityref { base test-type; } description "Choose the type of test. Note that for the same unitary test, if the test is conducted on multiple ne node, the test type should be same, but test configuration on each ne node might be different."; } container root { description "Container for mount point."; yangmnt:mount-point "root" { Contreras, et al. Expires 3 April 2027 [Page 23] Internet-Draft Scheduling OAM YANG September 2026 description "Root for models supported per oam unitary test. This mount point may or may not be inline based on the server implementation. When the associated 'managed' leaf is 'false', any operation that attempts to access information below the root should fail with an error-tag of 'access-denied' and an error-app-tag of 'oamut-not-managed'."; } } } } container oam-unitary-tests { description "Container for OAM unitary tests activation for network diagnosis procedures."; list oam-unitary-test { key name; description "List of OAM unitary tests activation for network diagnosis procedures."; uses oam-unitary-test; uses schedule:schedule-status; leaf unitary-test-status { type identityref { base unitary-test-status; } config false; description "Status of the test."; } choice schedule-class { description "Choice based on the type of the time range."; container period { description "The OAM Test takes effect based on a precise period of time."; uses schedule:period-of-time; } container recurrence { description "The OAM test takes effect based on a recurrence rule."; uses schedule:recurrence-utc; } Contreras, et al. Expires 3 April 2027 [Page 24] Internet-Draft Scheduling OAM YANG September 2026 } } } } 5.2. YANG Model for OAM Sequence Test This module imports typedefs from [RFC9922]. For the model design overview, please refer to Section 4.2. file ietf-oam-test-sequence@2026-09-14.yang module ietf-oam-sequence-test { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-oam-sequence-test"; prefix "oamts"; import ietf-oam-unitary-test { prefix "oamut"; reference "RFC XXXX: A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests"; } import ietf-schedule { prefix "schedule"; reference "RFC 9922: A Common YANG Data Model for Scheduling"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: WG List: Author: Luis Miguel Contreras Murillo Author: Victor Lopez Author: Qin Wu "; description "This module defines the 'ietf-oam-sequence-test' YANG model for management of network diagnosis procedures. Contreras, et al. Expires 3 April 2027 [Page 25] Internet-Draft Scheduling OAM YANG September 2026 Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC // publication and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove // this note. revision "2026-09-14" { description "Initial version"; reference "RFCXXXX"; } /* Identities */ identity sequence-test-status { description "Base identity for sequence-test-status."; } identity planned { base sequence-test-status; description "Identity for planned."; } identity configured { base sequence-test-status; description "Identity for configured."; } identity ready { base sequence-test-status; description "Identity for ready."; } identity on-going { base sequence-test-status; description "Identity for on-going."; Contreras, et al. Expires 3 April 2027 [Page 26] Internet-Draft Scheduling OAM YANG September 2026 } identity stop { base sequence-test-status; description "Identity for stop."; } identity success { base sequence-test-status; description "Identity for success."; } identity failure { base sequence-test-status; description "Identity for failure"; } identity error { base sequence-test-status; description "Identity for error."; } identity resource-contention { base error; description "Identity for resource-contention error cause."; } identity priority { base error; description "Identity for priority error cause."; } /* Data model definition */ container oam-sequence-tests { description "Container for executing a sequence of ietf-oam-unitary-tests N times."; list oam-sequence-test { key "name"; description "List of test sequences. note that each test sequence is local sequence configuration, any later changes to the configured unitary test template in the ietf-oam-unitary-test should not silently change an already configured sequence."; leaf name { type string; Contreras, et al. Expires 3 April 2027 [Page 27] Internet-Draft Scheduling OAM YANG September 2026 description "Unique name for the sequence test."; } list unitary-test { key "name"; description "Reuses the ietf-oam-unitary-tests template for each unitary test in the test seqence. it support both ordered-by user and ordered-by system."; uses "oamut:oam-unitary-test"; } uses schedule:schedule-status; leaf sequence-test-status { type identityref { base sequence-test-status; } config false; description "Status of the sequence test execution."; } choice schedule-class { description "Choice based on the type of the time range."; container period { description "The OAM Test takes effect based on a precise period of time."; uses schedule:period-of-time; } container recurrence { description "The OAM test takes effect based on a recurrence rule."; uses schedule:recurrence-utc; } } } } } 6. Using Device Model Within OAM Scheduling Models This section discusses the issues related to reusing device models already defined in IETF within the context of scheduling OAM tests. There are two main approaches to enable OAM scheduling models: Contreras, et al. Expires 3 April 2027 [Page 28] Internet-Draft Scheduling OAM YANG September 2026 * Importing YANG model into the OAM scheduling models. This approach will copy the device model into the OAM unitary test model to enable the configuration and utilization of the desired OAM test. This approach requires recreating new YANG models for each new test type or variation of the device models. * Schema-mount allows mounting a data model at a specified location of another (parent) schema. The main difference with importing the YANG modules is that they don't have to be prepared for mounting; any existing modules such as "ietf-twamp" can be mounted without any modifications. The "test-type" leaf and the schema mount are complementary. The "test-type" leaf (identityref to "test-type") explicitly indicates which OAM test type, and thus which YANG module, is mounted at the "root" mount point for that "ne-config" list entry. Each "ne-config" entry therefore pairs a test-type identity with the corresponding mounted module configuration under "root", so that management systems and implementations know which OAM module applies to that node. This document defines the base identity "test-type" and a set of child identities for OAM test type; YANG modules that augment "ietf-oam- unitary-test" may define additional child identities derived from "test-type" for other OAM test types. As an example, we will use [RFC8913], which defines a YANG data model for TWAMP, to illustrate how device models could be used in Appendix A.1. 7. Operational Considerations 7.1. Conflict Resolution and Reporting Among Scheduled OAM Tasks When multiple OAM tasks are scheduled to run concurrently or overlap in time, conflicts may arise due to resource contention or operational constraints. This document leverages the scheduling status groupings defined in the common schedule YANG module (see [RFC9922] A Common YANG Data Model for Scheduling]) to detect and report such conflicts. The YANG models defined in this document (both for unitary test and sequence test) use the unitary-test-status and sequence-test-status leaves to indicate the current scheduling state of each OAM task. These leaves are of type identityref, allowing extensible error reporting. If a conflict is detected (e.g., two tests require exclusive access to the same resource at the same time), the server sets the corresponding status to error or to a more specific error- cause identity derived from error: resource-contention for resource conflicts, or priority based conflict for prioritization-related Contreras, et al. Expires 3 April 2027 [Page 29] Internet-Draft Scheduling OAM YANG September 2026 conflicts Section 4.1, Section 4.2. This error-cause indication allows operators and management systems to distinguish the reasons for the failure. Note that it is intention to allow extensibility for the error codes rather than extend states in the state machine. Operators and management systems SHOULD monitor the scheduling status of OAM tasks and take appropriate action if a conflict is reported. To support deterministic operations across heterogeneous multi-vendor environments, implementations SHOULD perform a commit-time validation on multi-node configuration, e.g., if a scheduling conflict (e.g., the number of schedule conflict exceeds the specific threshold) or resource over-allocation is detectable a priori, the configuration commit SHOULD be rejected by the server rather than accepted for delayed resolution. Another example is when manually running OAM test is colliding with previously scheduled OAM tests, we need to make sure to check the existence of schedule tests before running manual OAM testing. In both examples, the conflict MUST be clearly reported via the YANG model status leaves. If a conflict cannot be caught a priori or occurs dynamically during runtime execution, the server resolves the resource friction using a well-defined precedence model. OAM task categories are prioritized according to the following operational hierarchy: * On-Demand Troubleshooting: Manually triggered diagnostics designed to pinpoint live issues MUST take absolute precedence, overriding and preempting any scheduled or proactive monitoring sequences. * Birth-Certificate/Verification Tests: Initial service activation verification sequences take secondary precedence, superseding background tasks but yielding to active troubleshooting if system resources are exhausted. * Proactive SLA Supervision: Routine, recurring performance verification tests operate under lowest relative priority and may be systematically deferred, rescheduled, or canceled when high- priority tasks claim the required execution resources. When an active test or upcoming schedule is modified or aborted by a higher-priority operation, the server must update the corresponding unitary-test-status or sequence-test-status leaf. It must also log the preempted event alongside an error notification to ensure observability across the network management layer. In addition, the preemption applies only to the OAM sessions being setup using the YANG data models defined in this document, while other OAM sessions being running on the devices through other mechanims should not be preempted (e.g., through CLI or by configuring the device YANG data model directly) to avoid operaetional impact on other OAM sessions. Contreras, et al. Expires 3 April 2027 [Page 30] Internet-Draft Scheduling OAM YANG September 2026 7.2. Coverage of Input Parameters and Output Results The YANG models defined in this document are designed to schedule OAM tests at a network-wide level. The input parameters required to configure and execute specific OAM functions (such as test type, target, and configuration options) are referenced or reused from the existing device-level OAM YANG models (e.g., [RFC8531], [RFC8532], [RFC8533], [RFC8913]). This approach avoids duplication and ensures consistency with established models. Similarly, the output results of OAM tests such as test status, performance metrics, and diagnostic information,are expected to be reported using the mechanisms and data nodes defined in those foundational YANG modules. The scheduling models in this document provide references to these output results and enable their collection and correlation across multiple tests and devices, but do not redefine the detailed input/output parameters of each OAM function. In summary, this document focuses on the scheduling, coordination, and status tracking of OAM tests, while relying on existing YANG models for the detailed specification of test parameters and results. 7.3. Use of the Managed Leaf The "managed" leaf in each "ne-config" entry defaults to "true", meaning that the orchestrator or controller hosting this model is expected to configure the device OAM function through the "root" schema-mount point. The orchestrator or controller can rely on the YANG Library (RFC 8525) to discover which structural OAM modules are supported by a network element before scheduling tests. This capability discovery allows the orchestrator or controller to determine supported standard schemas, such as TWAMP or ICMP, and works in conjunction with YANG Schema Mount (RFC 8528) to dynamically mount native OAM modules into the scheduling framework. Operators set "managed" to "false" when the OAM function on that network element is configured outside this model, for example by a device CLI, a local script, or a different controller. In that case, any attempt to access data below "root" fails with error-tag "access- denied" and error-app-tag "oamut-not-managed", as specified in the YANG module. Contreras, et al. Expires 3 April 2027 [Page 31] Internet-Draft Scheduling OAM YANG September 2026 Scheduling of the unitary test or sequence test still applies when "managed" is "false": time constraints and status reporting remain in this model, but the device-level OAM configuration is not pushed through the mount point to support smooth migration. Implementations that cannot disable mount access may keep "managed" as a read-only value of "true". 7.4. Performance impact and Operational Guidance for concurrent OAM task scheduling Concurrent OAM task scheduling introduces significant resource strain across managed devices. Management and orchestration systems need to make sure to have sufficient resource before conducting those multiple concurrent OAM tasks. To plan capacity at scale and safeguard network stability, implementations SHOULD adhere to the following operational boundaries: * Concurrency Limits: Devices SHOULD enforce limits on concurrent active tests to prevent CPU starvation. Active traffic per interface MUST be bounded to a minimal fraction (e.g., <1%) of link capacity. Network-wide tasks MUST be staggered using random jitter to avoid synchronized telemetry and processing spikes. * Preemptive Control: Implementations SHOULD NOT rely solely on reporting resource-contention errors after a failure. Managed nodes SHOULD apply local rate limiting and preemptive traffic- shaping. If resource thresholds are approached, devices SHOULD automatically defer or back off pending tests, while prioritizing vital keep-alives over ad-hoc diagnostics. * SLA and Windowing Considerations: High-frequency proactive supervision MUST use various different QoS markings to reflect real line-rate conditions without degrading SLAs. Bulk diagnostics SHOULD run at low priority. Routine supervision is suited for in-service periods, whereas intrusive OAM loopbacks [ITU-T-Y1731] and multi-path tracing SHOULD be restricted to maintenance windows, where false alarms must be suppressed. 7.5. Impact on Security Operations Centrally orchestrated and scheduled OAM tests introduce specific traffic patterns—characterized by distinct timing, predictable volumes, and targeted path probing—that differ from normal network traffic. Network operators MUST evaluate the impact of these automated patterns on security operations systems: Contreras, et al. Expires 3 April 2027 [Page 32] Internet-Draft Scheduling OAM YANG September 2026 * Anomaly Detection & IDS/IPS: Automated OAM traffic may trigger false positives in flow-based Intrusion Detection/Prevention Systems (IDS/IPS) or behavioral anomaly detectors, which might flag rapid, scheduled path probing as network scanning. Operators SHOULD configure security baseline policies to recognize authorized OAM orchestration boundaries or whitelist controlled test sources. * Packet Capture & Parsing Observability: Centralized scheduling can significantly increase packet volume during test windows. Network monitoring tools, packet capture systems, and protocol parsing MUST be capable of identifying, parsing, and filtering these scheduled OAM packets. This ensures that synthetic test traffic does not overwhelm log storage, degrade packet processing performance, or obscure genuine malicious payloads hidden within traffic flows. 7.6. Schedule Health Verification Operators SHOULD follow a post-configuration validation checklist to verify schedule health and configuration deployment. verification focuses on two primary phases: * Schedule Acceptance Verification: Operators must inspect the root schedule instance to ensure it has been successfully accepted by the controller. This is validated by verifying that the upcoming- occurrence leaf and status counters imported from the ietf- schedule module reflect a valid, upcoming execution timestamp rather than an error or inactive state. * Mount Application Verification: Operators must verify that the OAM configuration nested under the schema mount root has been successfully propagated to each target network element (ne-id). This is achieved by querying the local state of the mounted OAM unitary test or sequence test modules on individual network elements to confirm that the configuration was applied correctly and the elements are primed for the upcoming schedule trigger. 7.7. Operational Considerations for Auditing and Results Tracking To support the accounting and auditing requirements described in Section 2.2 and Section 2.3, the test results of the scheduling model including mounted device-level OAM Test results (e.g., TWAMP Test results in Appendix A.1 ) or audit nodes (i.e., ne-config list) should be associated with each schedule instance (e.g., 'oam-unitary- test' or 'oam-sequence-test' list instance) to ensure that automated audit tools and operators can seamlessly validate test execution, correlate schedules with actual performance data, and maintain a Contreras, et al. Expires 3 April 2027 [Page 33] Internet-Draft Scheduling OAM YANG September 2026 verifiable audit trail. 8. Security Considerations This section is modeled after the template described in Section 3.7.1 of [RFC9907]. Both "ietf-oam-unitary-test " YANG module and "ietf-oam-sequence- test" YANG module define data models that are designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) MUST use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) MUST use mutual authentication. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities: * /oamut:oam-unitary-tests/oamut:oam-unitary-test: This list specifies all the oam unitary test entries for network diagnosis procedures. Unauthorized write access to this list can allow intruders to modify the entries so as to forge an unitary test name that does not exist or maliciously delete an existing unitary test, which could be used to craft an attack. * /oamts:oam-sequence-test/oamts:sequence-test: This list specifies all the oam sequence test entries for network diagnosis procedures. Unauthorized write access to this list can allow intruders to modify the entries so as to forge an sequence test name that does not exist or maliciously delete an existing sequence test, which could be used to craft an attack. This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to the Security Considerations of [RFC9922] for information as to which nodes may be considered sensitive or vulnerable in network environments. Contreras, et al. Expires 3 April 2027 [Page 34] Internet-Draft Scheduling OAM YANG September 2026 9. IANA Considerations 9.1. Updates to the IETF XML Registry for New YANG Module IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]. URI: urn:ietf:params:xml:ns:yang:ietf-oam-unitary-test Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-oam-sequence-test Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 9.2. Updates to the YANG Module Names Registry for New YANG Module IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group. Name: ietf-oam-unitary-test Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-oam-unitary-test Prefix: oamut Reference: RFC XXXX Name: ietf-oam-sequence-test Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-oam-sequence-test Prefix: oamts Reference: RFC XXXX 10. Implementation Status There are currently no known implementations of the YANG modules defined in this document. This section is intended to track implementation experience as it becomes available and is expected to be removed if the document is published as an RFC. Acknowledgments Thanks Joe Clark, Daniel King, Qiufang Ma, Italo Busi, Fung Lim, Xiao Min, Saumya Dikshit for valuable review and comments. Contreras, et al. Expires 3 April 2027 [Page 35] Internet-Draft Scheduling OAM YANG September 2026 The work of Luis M. Contreras has been partially supported by the European Union’s Horizon Program through the 6G DAta and ML operations automation via an end-to-end AI framework (6G-DALI) Project under Grant 101192750. References Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, DOI 10.17487/RFC5860, May 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . Contreras, et al. Expires 3 April 2027 [Page 36] Internet-Draft Scheduling OAM YANG September 2026 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, "Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, . Contreras, et al. Expires 3 April 2027 [Page 37] Internet-Draft Scheduling OAM YANG September 2026 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907, March 2026, . [RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025, . [RFC9922] Ma, Q., Ed., Wu, Q., Boucadair, M., Ed., and D. King, "A Common YANG Data Model for Scheduling", RFC 9922, DOI 10.17487/RFC9922, March 2026, . [RFC10014] Pignataro, C., Farrel, A., and T. Mizrahi, "Guidelines for Characterizing the Term "OAM"", BCP 161, RFC 10014, DOI 10.17487/RFC10014, June 2026, . Informative References [I-D.ietf-nmop-network-incident-yang] Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network- incident-yang-17, 24 September 2026, . Contreras, et al. Expires 3 April 2027 [Page 38] Internet-Draft Scheduling OAM YANG September 2026 [I-D.tt-netmod-yang-config-templates] Watsen, K., Ma, Q., and D. Rajaram, "YANG Configuration Templates", Work in Progress, Internet-Draft, draft-tt- netmod-yang-config-templates-04, 22 September 2026, . [IEEE-8021ag] "IEEE Standard for Local and Metropolitan Area Networks – Bridges and Bridged Networks – Connectivity Fault Management", 2007, . [IEEE-8021Q] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012, . [ITU-T-G81131] "Operation and maintenance mechanism for T-MPLS layer networks", April 2007, . [ITU-T-Y1731] "OAM Functions and Mechanisms for Ethernet-based Networks", 13 June 2023, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC792, September 1981, . [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC792, September 1981, . [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005, . [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, . Contreras, et al. Expires 3 April 2027 [Page 39] Internet-Draft Scheduling OAM YANG September 2026 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, . [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, . [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, . [RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, DOI 10.17487/RFC6632, June 2012, . [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, . Contreras, et al. Expires 3 April 2027 [Page 40] Internet-Draft Scheduling OAM YANG September 2026 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, . [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, . [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, . [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols", RFC 8531, DOI 10.17487/RFC8531, April 2019, . [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8532, DOI 10.17487/RFC8532, April 2019, . [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, "A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8533, DOI 10.17487/RFC8533, April 2019, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8913] Civil, R., Morton, A., Rahman, R., Jethanandani, M., and K. Pentikousis, Ed., "Two-Way Active Measurement Protocol (TWAMP) YANG Data Model", RFC 8913, DOI 10.17487/RFC8913, November 2021, . Contreras, et al. Expires 3 April 2027 [Page 41] Internet-Draft Scheduling OAM YANG September 2026 [RFC9107] Raszuk, R., Ed., Decraene, B., Ed., Cassar, C., Åman, E., and K. Wang, "BGP Optimal Route Reflection (BGP ORR)", RFC 9107, DOI 10.17487/RFC9107, August 2021, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, December 2022, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [RFC9617] Zhou, T., Ed., Guichard, J., Brockners, F., and S. Raghavan, "A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9617, DOI 10.17487/RFC9617, August 2024, . [RFC9940] Davis, N., Ed., Farrel, A., Ed., Graf, T., Wu, Q., and C. Yu, "Some Key Terms for Network Fault and Problem Management", RFC 9940, DOI 10.17487/RFC9940, April 2026, . Appendix A. Examples This section includes a non-exhaustive list of examples to illustrate the use of the models defined in this document. A.1. Create a TWAMP OAM test [RFC8913] defines a YANG model for TWAMP. The following example demonstrates how scheduled test results look like from mounted device models surface through NMDA retrieval from the operational datastore. This example uses the "twamp" identity defined in the ietf-oam- unitary-test module (derived from "test-type") to indicate the test type; the TWAMP device model configuration is mounted at the "root" of each "ne-config" entry and has been applied in the operational datastore. The example contains the information for the two configurations (Session-Sender and Session-Reflector). Contreras, et al. Expires 3 April 2027 [Page 42] Internet-Draft Scheduling OAM YANG September 2026 An example of a request message body to create a TWAMP OAM test is shown in Figure 6. Session-Sender and Session-Reflector as expanded for illustrative purposes. The TWAMP Test scheduled in this configuration is a one-hour performance monitoring test that runs daily at 9 AM UTC. This test session is configured to start on October 17, 2023, at 09:00 UTC and recur at the same time every day. The duration of each test run is one hour, as specified by the unint32 format "3600", with the test status marked as "configured". The test provides insight into network performance by monitoring the selected parameters, allowing for the detection of any potential degradations in service quality over time. =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-oam-unitary-test:oam-unitary-tests": { "oam-unitary-test": [ { "name": "TWAMP-Test-scheduled-daily", "recurrence": { "recurrence-first": { "start-time-utc": "2026-10-17T09:00:00Z", "duration": "3600" }, "utc-until": "2026-12-31T23:59:59Z", "recurrence-description": "TWAMP Test Reccurence, Daily at \ 9 AM UTC", "frequency": "ietf-schedule:daily", "interval": 1 }, "unitary-test-status": "configured", "ne-config": [ { "ne-id": "203.0.113.3", "managed": true, "test-type": "twamp", "root": { "twamp": { "session-sender": { "admin-state": true, "test-session": [ { "name": "Test1", "ctrl-connection-name": "RouterA", "fill-mode": "zero", "number-of-packets": 900, "periodic-interval": 1, "sent-packets": 2, Contreras, et al. Expires 3 April 2027 [Page 43] Internet-Draft Scheduling OAM YANG September 2026 "rcv-packets": 2, "last-sent-seq": 1, "last-rcv-seq": 1 }, { "name": "Test2", "ctrl-connection-name": "RouterA", "fill-mode": "random", "number-of-packets": 900, "lambda": 1, "max-interval": 2, "sent-packets": 21, "rcv-packets": 21, "last-sent-seq": 20, "last-rcv-seq": 20 } ] } } } }, { "ne-id": "203.0.113.4", "managed": "true", "test-type": "twamp", "root": { "twamp": { "session-reflector": { "admin-state": true, "test-session": [ { "sid": 1232, "sender-ip": "203.0.113.3", "sender-udp-port": 54000, "reflector-ip": "203.0.113.4", "reflector-udp-port": 55000, "parent-connection-client-ip": "203.0.113.1", "parent-connection-client-tcp-port": 16341, "parent-connection-server-ip": "203.0.113.2", "parent-connection-server-tcp-port": 862, "test-packet-dscp": 32, "sent-packets": 2, "rcv-packets": 2, "last-sent-seq": 1, "last-rcv-seq": 1 }, { "sid": 178943, Contreras, et al. Expires 3 April 2027 [Page 44] Internet-Draft Scheduling OAM YANG September 2026 "sender-ip": "203.0.113.1", "sender-udp-port": 54001, "reflector-ip": "192.0.2.2", "reflector-udp-port": 55001, "parent-connection-client-ip": "203.0.113.1", "parent-connection-client-tcp-port": 16341, "parent-connection-server-ip": "203.0.113.2", "parent-connection-server-tcp-port": 862, "test-packet-dscp": 32, "sent-packets": 21, "rcv-packets": 21, "last-sent-seq": 20, "last-rcv-seq": 20 } ] } } } } ] } ] } } Figure 6: Example of a Message Body to Create a TWAMP OAM test A.2. Ping OAM Test Template Ping OAM Test Template can be defined using YANG-based configuration template specified in [I-D.tt-netmod-yang-config-templates] as follows: Contreras, et al. Expires 3 April 2027 [Page 45] Internet-Draft Scheduling OAM YANG September 2026 Figure 7: Example of OAM Test Template Definition Template application is indicated using the "apply-templates" metadata. For example, the following OAM unitary tests configuration may be provided with the container node "oam-unitary-tests" applying the template defined in Figure 7. As described in [I-D.tt-netmod-yang-config-templates], a template node can be overriden by having its value changed, but it can't be deleted. As an example of overriding a node in a template, a client may configure physically present OAM Unitary Tests "lsp-ping", "ip-ping" and "srmpls-ping" inheriting the template defined in Figure 7, but the "ne-id" value of "srmpls-ping" needs to be "203.0.113.4": Contreras, et al. Expires 3 April 2027 [Page 46] Internet-Draft Scheduling OAM YANG September 2026 lsp-ping eth0 true ... ip-ping srmpls-ping 203.0.113.4 ... Figure 8: Example of Applying OAM Test Template And the above OAM Unitary Tests configuration renders the following expanded configuration: Contreras, et al. Expires 3 April 2027 [Page 47] Internet-Draft Scheduling OAM YANG September 2026 lsp-ping eth0 true ... 2025-10-01T08:00:00Z hourly ip-ping eth1 true ... 2025-10-01T08:00:00Z hourly srmpls-ping 203.0.113.4 ... Appendix B. Change between Revision v07 - v08 * Change ne-id data type to inet:host; * Add Child identities for unitary-test-type; * Add references for imported types and used reference in the YANG model section; * Change recurrence-basic to recurrence-utc; * Point counter wrapp-around to RFC9922; * Explain when operators set managed to false; * Align stop transitions in unitary and sequence state machines; Contreras, et al. Expires 3 April 2027 [Page 48] Internet-Draft Scheduling OAM YANG September 2026 * Operational Consideration Update; * Sample OAM Test Scheduling Network Model Usage; v06 - v07 * Some Editorial changes based on Hansai's comments; * Add schedule status descrption in the section OAM Unitary Test; * Change temporal parameter into YANG statement; * Change to Both Frequency and Interval are required; * Fix indentation issue based on Hansai's comments; * Fix indentation issue based on Hansai's comments; * Change two yang module prefixes; * Follow Security Considerations template defined by RFC 9907; * OAM Teminology Consistency; * Fix ne-id description; Authors' Addresses Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Victor Lopez Nokia Email: victor.lopez@nokia.com Qin Wu Huawei Email: bill.wu@huawei.com Contreras, et al. Expires 3 April 2027 [Page 49]