



DetNet                                                            J. Yan
Internet-Draft                                           ZTE Corporation
Intended status: Informational                                    Z. Han
Expires: 19 April 2026                                      China Unicom
                                                                  X. ZHU
                                                         ZTE Corporation
                                                         16 October 2025


                OAM Requirements for Enhanced DetNet OAM
            draft-yan-detnet-oam-requirements-enhancement-02

Abstract

   This document describes the specific requirements of the Operations,
   Administration, and Maintenance (OAM) in Enhanced DetNet, and
   analyzes the gaps with existing OAM methods.  The document also
   presents considerations for potential OAM solutions to address these
   requirements.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 19 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Yan, et al.               Expires 19 April 2026                 [Page 1]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements and Gap Analysis . . . . . . . . . . . . . . . .   3
     3.1.  Support Microsecond-level Measurement Precision . . . . .   3
     3.2.  Support Per-packet Performance Monitoring . . . . . . . .   4
     3.3.  Support High-speed Detection and Response . . . . . . . .   5
   4.  Consideration for Enhanced DetNet OAM Solutions . . . . . . .   5
     4.1.  Based on Traditional OAM Protection Mechanism . . . . . .   6
     4.2.  Supporting PREF Protection Function in DetNet . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The framework of OAM for DetNet has been specified in [RFC9551].  As
   per [RFC8655], DetNet functionality is divided into forwarding sub-
   layer and service sub-layer.  [RFC9551] lists general functional
   requirements for DetNet OAM as well as functional requirements in
   each of the DetNet sub-layers of a DetNet domain.  The IP and MPLS
   DetNet data plane have been defined in [RFC9634] and [RFC9546],
   respectively.

   The DetNet data plane enhancement requirements are described in
   [I-D.ietf-detnet-scaling-requirements] , which calls for enhancements
   based on the existing bounded latency mechanisms and the
   corresponding data plane.  The data plane enhancement solutions such
   as ECQF[IEEE 802.1Qdv], Multi-
   CQF[I-D.dang-queuing-with-multiple-cyclic-buffers],
   TCQF[I-D.eckert-detnet-tcqf],
   CSQF[I-D.chen-detnet-sr-based-bounded-latency],
   TQF[I-D.peng-detnet-packet-timeslot-mechanism],
   C-SCORE[I-D.joung-detnet-stateless-fair-queuing],



Yan, et al.               Expires 19 April 2026                 [Page 2]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   EDF[I-D.peng-detnet-deadline-based-forwarding],
   gLBF[I-D.eckert-detnet-glbf]have been proposed and discussed, with
   the criteria for classifying them provided
   in[I-D.ietf-detnet-dataplane-taxonomy]. These queuing mechanisms
   demand high precision to achieve deterministic latency especially as
   link speeds increase from 100Mbps to 1Gbps, 10Gbps, 100Gbps, or even
   higher. 

   For DetNet OAM, it is essential to provide DetNet services with
   high precision in a large-scale network, ensuring OAM performance
   requirements are strictly met.  Existing OAM methods
   including proactive and reactive techniques are insufficient to meet
   the monitoring and measurement requirements for Enhanced DetNet.

   Based on these considerations, this document specifies the
   requirements of the OAM for Enhanced DetNet, analyzes the gaps with
   the existing OAM methods, and presents considerations for potential
   OAM solutions.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Terminology

   The terminology is defined as[RFC8655].

3.  Requirements and Gap Analysis

   This section presents the enhanced requirements for Enhanced DetNet
   OAM and analyzes the technical gaps when applying OAM technologies as
   per [RFC9551]in large-scale networks.

3.1.  Support Microsecond-level Measurement Precision

   As per [I-D.ietf-detnet-scaling-requirements], deterministic networks
   can utilize higher-speed links.  With the increasing data rates, the
   network scheduling cycle can be shortened, provided that the amount
   of application data transmitted at any given time remains unchanged.
   This requires more precise time control, in the order of microseconds
   or sub-microseconds.  As per[RFC9551], the service protection
   provided by the DetNet Service sub-layer aims to mitigate network
   failures more rapidly than the expected response time of the DetNet
   Controller Plane.  Therefore, the time accuracy of the DetNet OAM
   mechanism must meet or exceed the accuracy requirements specified in
   SLAs.  For instance, if service delay measurements require



Yan, et al.               Expires 19 April 2026                 [Page 3]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   microsecond-level precision, the OAM mechanism should support sub-
   microsecond precision to assess whether service delay and jitter
   performance comply with SLA requirements.

   The precision of time measurements depends on both the time
   synchronization protocol utilized in the network and the specific
   location where timestamps are captured during the forwarding process.
   According to [I-D.ietf-detnet-scaling-requirements], , Enhanced
   DetNet, which targets large-scale networks, should accommodate time
   asynchrony, making the efficient one-way delay measurement critical.
   Furthermore, based on the assumption of time asynchrony,
   synchronization technologies leveraging network effects, especially
   in metropolitan area networks with spine-leaf topologies, provide
   solutions capable of achieving synchronization accuracy down to the
   microsecond level.

3.2.  Support Per-packet Performance Monitoring

   According to [I-D.ietf-detnet-scaling-requirements], large-scale
   networks are becoming increasingly complex to meet the growing
   demands for higher bandwidth, lower latency and jitter, customized
   traffic prioritization, and SLA-grade network resilience.  A more
   complex network infrastructure requires deeper visibility into
   Enhanced DetNet.  The OAM of Enhanced DetNet should be capable of
   analyzing network behavior at the packet level.  Legacy network
   monitoring technologies are insufficient since they do not provide
   real-time and granular visibility required for such detailed
   analysis.

   DetNet requires high reliability to meet the demands of service
   flows.  However, detecting SLA violations on a per-packet basis
   presents significant challenges in large-scale networks with
   thousands of service flows.  The feasibility of implementing per-
   packet monitoring with the OAM mechanism depends on device
   capabilities, including counter resources, CPU resources, and port
   speeds.  For instance, if the processing time for forwarding packets
   at line speed is 10 nanoseconds per packet in in-situ OAM mode, the
   network processor chip must parse the OAM data fields for each packet
   within this time frame.  Any delay exceeding 10 nanoseconds per
   packet would hinder the device's capability to forward packets at
   line speed.  In large-scale networks with thousands of services,
   mainstream equipment currently operates at capacities typically in
   the range of a few thousand, making it challenging to implement per-
   packet OAM effectively.







Yan, et al.               Expires 19 April 2026                 [Page 4]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


3.3.  Support High-speed Detection and Response

   In DetNet, due to the limited network scale, the impact of detection
   and response time on OAM performance is less noticeable.  However, in
   large-scale networks, long-distance transmission increases latency
   and the presence of a large number of devices leads to a higher
   likelihood of network link failures.  To achieve real-time monitoring
   and awareness of the network’s operating state, high-speed monitoring
   and rapid response are critical for ensuring that the services are
   not be interrupted for extended periods or that SLA violations do not
   occur.

   The traditional detection methods relying on switching and
   notification are ineffective in detecting millisecond-level latency
   variations and low-probability packet loss issues, making it
   unsuitable for Enhanced DetNet, as follows:

   1.  Active OAM protocols, such as Bidirectional Forwarding Detection
       (BFD) [RFC5880], typically operate at millisecond-level at most.

   2.  Currently, in-band detection methods include the Alternate-
       Marking Method [RFC8321]which operates with a detection duration
       of up to ten-second level, and IOAM Direct Export (DEX)[RFC9326],
       achieving near real-time monitoring but requires packet
       encapsulated with a sequence number field.  Out-of-band reporting
       methods such as extensions of[RFC6374]generally offer
       millisecond-level delay.

   3.  Telemetry can provide monitoring at minute or hour levels at
       most. A key limitation of telemetry is its reliance on uniform
       packet upload and processing.  Moreover, fixed round-trip time
       overhead across node-to-controller paths, node CPU performance,
       uplink bandwidth, and controller processing capability all serve
       as bottlenecks for Telemetry.

4.  Consideration for Enhanced DetNet OAM Solutions

   OAM methods can be classified into three types according to
   [RFC7799]:












Yan, et al.               Expires 19 April 2026                 [Page 5]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   1.  Active OAM mode (e.g., TWAMP [RFC5357]).[RFC9546]defines DetNet
       OAM with the MPLS Data Plane, while [I-D.ietf-detnet-ip-
       oam] discusses DetNet OAM with the IP Data Plane.  These drafts
       focusing on the active OAM mode, indicate that the fate sharing
       between test packets and service packets is theoretically
       achievable.  However, in practical implementation, it encounters
       significant challenges.  While path sharing is relatively simple,
       achieving fate sharing between test packets and service packets
       without causing congestion remains a difficult task for network
       operators.

   2.  Passive OAM mode.  In a strict sense, passive methods do not
       modify packet encapsulation, making it difficult to calculate
       packet loss when packets do not carry sequence numbers.

   3.  Hybrid OAM mode.  At present, the two most popular in-band OAM
       technologies are the Alternate-Marking (coloring) Method
       [RFC8321]and In-situ Network Telemetry (INT)[RFC9197], , which
       are both hybrid OAM methods and offer solutions for achieving
       fate-sharing among test packets and service packets on the
       forwarding plane.  Based on forwarding plane detection
       technologies utilizing coloring and INT, there are two main OAM
       solutions:

       *  The head-end or tail-end node performs local OAM data
          computations, such as packet loss rates and delay.  Out-of-
          band OAM technologies (such as[RFC6374], STWAP[RFC8762], and
          their extensions) May optionally be used for information
          exchange between head-end and tail-end nodes.

       *  Telemetry methods (like iFIT
          [I-D.song-opsawg-ifit-framework]).  The head-end and tail-end
          nodes transmit their local data to a controller or cloud
          platform via southbound interfaces.  Here, third-party nodes
          then perform OAM-related computations and notify the nodes to
          generate responses, also via southbound interfaces.

   Based on the above analysis, there are two technical approaches for
   Enhanced DetNet OAM to meet the high-reliability requirements.

4.1.  Based on Traditional OAM Protection Mechanism

   Traditional protection switching networks employ the following three
   types of protection methods, each with different response speeds:

   1.  End-to-end 1+1 protection: There is a working link serving as the
       primary path and a protection link as the backup path, both pre-
       established.  At the head-end node, service traffic is replicated



Yan, et al.               Expires 19 April 2026                 [Page 6]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


       and transmitted over both the working link and the protection
       link.  If the working link fails, the tail-end node switches to
       receiving traffic from the protection link, a process known as
       single-end switching.  While this method switches relatively
       quickly, it has low bandwidth utilization as both links are
       allocated for a single service.

   2.  End-to-end 1:1 protection: Service traffic is transmitted only
       over the working link, leaving the protection link idle or
       available for low-priority services.  If the working link fails,
       the tail-end node notifies the head-end node to switch protected
       service flows from the working link to the protection link.  This
       switching requires actions at both ends, resulting in slower
       switching but achieving higher bandwidth utilization.

   3.  Fast Reroute (FRR): Enhanced DetNet requires explicit paths,
       making rerouting based on distributed protocols unsuitable.

   For Enhanced DetNet, where OAM protection is best-effort and
   primarily focused on deploying protection switching mechanisms,
   traditional forwarding sub-layer OAM protection methods can be
   utilized:

   1.  The INT mechanism which carryies the sequence number and collects
       data in Direct Export mode offers near real-time detection under
       limited packet disordering, while the response time depends on
       the protection method used.  This approach achieves optimal
       detection speed but requires encapsulating/decapsulating in-situ
       OAM message headers as required and supporting Direct Export
       Type.

   2.  The in-situ flow detection mechanism with traffic coloring offers
       a detection granularity ranging from 1 second to 300 seconds
       (with an approximate average of 10 seconds), aligning performance
       monitoring duration within at least the second range.

   3.  Active OAM mechanisms based on fate sharing compromise the
       requirements in Chapters 3.1 and 3.2.  The CC-CV method relies on
       protocols such as BFD.

   Observability technologies introduce extra latency and are thus
   unsuitable for real-time OAM detection of online services.









Yan, et al.               Expires 19 April 2026                 [Page 7]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


4.2.  Supporting PREF Protection Function in DetNet

   PREF aims to guarantee forwarding sub-layer performance through
   service sub-layer functionality, employing multi-path packet
   duplication to mitigate the path-switching delay.  According to
   [IEEE802.1CB]and[RFC8655], ensuring high reliability for time-
   sensitive services is challenging without the deployment of PREF.
   When the network supports PREF configuration, it inherently meets
   reliability requirements including constraints on packet loss rate
   and latency violation, thus eliminating the need for enhanced
   detection speed.  Another key factor contributing to high reliability
   is the ability to provide protection at node level and link level
   rather than solely at the path level.  The PREF mechanism requires
   each packet to be encapsulated with a unique flow-id and a sequence
   number to facilitate selective receiving.

   While the network supports PREF can guarantee a packet loss rate as
   low as 0.0001%, it remains essential to proactively monitor the
   performance of each individual path to promptly detect path defects.
   This proactive approach helps prevent SLA violations such as link
   degradation to ensure stable transmission of service traffic under
   PREF protection.

5.  Security Considerations

   TBA

6.  IANA Considerations

   TBA

7.  Acknowledgements

   TBA

8.  References

8.1.  Normative References

   [I-D.chen-detnet-sr-based-bounded-latency]
              Chen, M., Geng, X., Li, Z., Joung, J., and J. Ryoo,
              "Segment Routing (SR) Based Bounded Latency", 7 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-chen-detnet-
              sr-based-bounded-latency-03>.







Yan, et al.               Expires 19 April 2026                 [Page 8]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   [I-D.dang-queuing-with-multiple-cyclic-buffers]
              Liu, B. and J. Dang, "A Queuing Mechanism with Multiple
              Cyclic Buffers", 22 February 2021,
              <https://datatracker.ietf.org/doc/html/draft-dang-queuing-
              with-multiple-cyclic-buffers-00>.

   [I-D.eckert-detnet-glbf]
              Eckert, T. T., Clemm, A., Bryant, S., and S. Hommes,
              "Deterministic Networking (DetNet) Data Plane - guaranteed
              Latency Based Forwarding (gLBF) for bounded latency with
              low jitter and asynchronous forwarding in Deterministic
              Networks", 5 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-eckert-
              detnet-glbf-04>.

   [I-D.eckert-detnet-tcqf]
              Eckert, T. T., Li, Y., Bryant, S., Malis, A. G., Ryoo, J.,
              Liu, P., Li, G., Ren, S., and F. Yang, "Deterministic
              Networking (DetNet) Data Plane - Tagged Cyclic Queuing and
              Forwarding (TCQF) for bounded latency with low jitter in
              large scale DetNets", 5 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-eckert-
              detnet-tcqf-07>.

   [I-D.ietf-detnet-dataplane-taxonomy]
              Joung, J., Geng, X., Peng, S., and T. T. Eckert,
              "Dataplane Enhancement Taxonomy", 24 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
              dataplane-taxonomy-04>.

   [I-D.ietf-detnet-scaling-requirements]
              Liu, P., Li, Y., Eckert, T. T., Xiong, Q., Ryoo, J.,
              zhushiyin, and X. Geng, "Requirements for Scaling
              Deterministic Networks", 22 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
              scaling-requirements-09>.

   [I-D.joung-detnet-stateless-fair-queuing]
              Joung, J., Ryoo, J., Cheung, T., Li, Y., and P. Liu,
              "Latency Guarantee with Stateless Fair Queuing", 29
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-joung-detnet-stateless-fair-queuing-05>.

   [I-D.peng-detnet-deadline-based-forwarding]
              Peng, S., Du, Z., Basu, K., cheng, Yang, D., and C. Liu,
              "Deadline Based Deterministic Forwarding", 20 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-peng-detnet-
              deadline-based-forwarding-18>.



Yan, et al.               Expires 19 April 2026                 [Page 9]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   [I-D.peng-detnet-packet-timeslot-mechanism]
              Peng, S., Liu, P., Basu, K., Liu, A., Yang, D., and G.
              Peng, "Timeslot Queueing and Forwarding Mechanism", 20
              June 2024, <https://datatracker.ietf.org/doc/html/draft-
              peng-detnet-packet-timeslot-mechanism-13>.

   [I-D.song-opsawg-ifit-framework]
              Song, H., Qin, F., Chen, H., Jin, J., and J. Shin,
              "Framework for In-situ Flow Information Telemetry", 23
              October 2023, <https://datatracker.ietf.org/doc/html/
              draft-song-opsawg-ifit-framework-21>.

   [IEEE802.1CB]
              "IEEE Standard for Local and metropolitan area networks--
              Frame Replication and Elimination for Reliability", 2017,
              <https://ieeexplore.ieee.org/document/8091139>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc5357>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <https://www.rfc-editor.org/info/rfc8321>.






Yan, et al.               Expires 19 April 2026                [Page 10]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
              Two-Way Active Measurement Protocol", RFC 8762,
              DOI 10.17487/RFC8762, March 2020,
              <https://www.rfc-editor.org/info/rfc8762>.

   [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, <https://www.rfc-editor.org/info/rfc9197>.

   [RFC9326]  Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
              Mizrahi, "In Situ Operations, Administration, and
              Maintenance (IOAM) Direct Exporting", RFC 9326,
              DOI 10.17487/RFC9326, November 2022,
              <https://www.rfc-editor.org/info/rfc9326>.

   [RFC9546]  Mirsky, G., Chen, M., and B. Varga, "Operations,
              Administration, and Maintenance (OAM) for Deterministic
              Networking (DetNet) with the MPLS Data Plane", RFC 9546,
              DOI 10.17487/RFC9546, February 2024,
              <https://www.rfc-editor.org/info/rfc9546>.

   [RFC9551]  Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos,
              CJ., Varga, B., and J. Farkas, "Framework of Operations,
              Administration, and Maintenance (OAM) for Deterministic
              Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551,
              March 2024, <https://www.rfc-editor.org/info/rfc9551>.

   [RFC9634]  Mirsky, G., Chen, M., and D. Black, "Operations,
              Administration, and Maintenance (OAM) for Deterministic
              Networking (DetNet) with the IP Data Plane", RFC 9634,
              DOI 10.17487/RFC9634, October 2024,
              <https://www.rfc-editor.org/info/rfc9634>.

Authors' Addresses

   Jinjie Yan
   ZTE Corporation
   China
   Email: yan.jinjie@zte.com.cn






Yan, et al.               Expires 19 April 2026                [Page 11]

Internet-Draft    OAM Requirements for Enhanced DetNet      October 2025


   Zhengxin Han
   China Unicom
   China
   Email: hanzx21@chinaunicom.cn


   Xiangyang Zhu
   ZTE Corporation
   China
   Email: zhu.xiangyang@zte.com.cn









































Yan, et al.               Expires 19 April 2026                [Page 12]
