detnet L. M. Contreras Internet-Draft M. Blanco-Caamaño Intended status: Informational Telefonica Expires: 6 May 2027 C. J. Bernardos UC3M C. E. Rothenberg UNICAMP 2 November 2026 Applicability of ACTN to Multi-Domain Deterministic Networking draft-bcbr-detnet-actn-00 Abstract End-to-end Deterministic Networking (DetNet) services may span multiple network domains using different technologies and controlled by independent domain-specific mechanisms. Coordinating these services requires an approach to abstract network resources and capabilities while preserving the requested service objectives across domain boundaries. This document investigates the applicability of the Abstraction and Control of Traffic Engineering Networks (ACTN) framework to multi- domain DetNet. It describes a functional mapping between ACTN entities and the DetNet Controller Plane, and considers the information needed for domain abstraction, service objective coordination and monitoring. It identifies areas for further work and questions for discussion in the DetNet and TEAS Working Groups. 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 6 May 2027. Contreras, et al. Expires 6 May 2027 [Page 1] Internet-Draft ACTN for DetNet November 2026 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 2. Terminology and Relationship to Existing Work . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Relationship to Existing Work . . . . . . . . . . . . . . 4 3. Architectural Overview and Use Cases . . . . . . . . . . . . 4 3.1. ACTN Hierarchy . . . . . . . . . . . . . . . . . . . . . 4 3.2. Representative Use Cases . . . . . . . . . . . . . . . . 5 4. ACTN-to-DetNet Functional Mapping . . . . . . . . . . . . . . 6 4.1. Mapping of Controller-Plane Functions . . . . . . . . . . 6 4.2. ACTN Functional Entities . . . . . . . . . . . . . . . . 6 4.2.1. CNC: DetNet Service Requirements . . . . . . . . . . 6 4.2.2. MDSC: End-to-End Coordination . . . . . . . . . . . . 7 4.2.3. PNC: Domain-Specific Realization . . . . . . . . . . 7 4.2.4. DetNet Domain Abstraction . . . . . . . . . . . . . . 7 4.3. Functional Mapping and Coordination Requirements . . . . 8 4.4. End-to-End Service Objective Coordination . . . . . . . . 8 4.4.1. Distribution of End-to-End Objectives . . . . . . . . 9 4.4.2. Boundary and Protection Considerations . . . . . . . 9 4.5. Service Monitoring and Re-evaluation . . . . . . . . . . 10 5. Applicability, Gap Analysis, and Questions for the Working Group . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Existing Building Blocks . . . . . . . . . . . . . . . . 11 5.2. Open Questions for further discussion . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Contreras, et al. Expires 6 May 2027 [Page 2] Internet-Draft ACTN for DetNet November 2026 1. Introduction Deterministic Networking (DetNet) supports applications with requirements for bounded latency, low packet loss and high reliability [RFC8655]. An end-to-end service may traverse several network domains, each with its own resources, forwarding technology and control mechanisms. Such a service may also involve Time- Sensitive Networking (TSN) subnetworks, wireless segments and supporting transport networks. The DetNet Controller Plane framework [RFC9938] describes the functions needed to establish and maintain DetNet services. The DetNet multi-domain framework [I-D.ietf-detnet-multi-domain-framework] considers coordination across controller domains, including hierarchical and peer approaches to path computation and resource reservation. However, applying these functions across heterogeneous domains requires information that individual domain controllers may not ordinarily expose. A coordinator needs to determine whether the domains can collectively support the requested service, translate its objectives into domain-level constraints, and maintain the service when conditions change. Domain controllers need to participate in these decisions while retaining control of their internal resources and mechanisms. The Abstraction and Control of Traffic Engineering (TE) Networks (ACTN) framework [RFC8453] separates customer requirements, multi- domain coordination and domain control. This hierarchy provides a basis for coordinating DetNet service objectives while domains retain control of their internal topology, resources and mechanisms. This document examines that mapping and the information needed at domain boundaries. This document identifies how ACTN can support multi-domain DetNet and where additional information or procedures are needed. It does not define a new DetNet architecture, data-plane technology or path- computation algorithm. Protocol and data-model extensions are left for subsequent work informed by working group discussion. 2. Terminology and Relationship to Existing Work Contreras, et al. Expires 6 May 2027 [Page 3] Internet-Draft ACTN for DetNet November 2026 2.1. Terminology The terminology of the DetNet architecture [RFC8655], the DetNet Controller Plane framework [RFC9938] and the ACTN framework [RFC8453] applies. A multi-domain DetNet service is an end-to-end service spanning domains under different controller responsibilities. A domain boundary may also be a technology, synchronization or administrative boundary, although these boundaries need not coincide. Network abstraction refers to the representation of topology, resources and capabilities needed for coordination while concealing internal domain details. In this document, a domain commitment refers to the constraints that a domain has agreed to meet for a service following its admission decision. 2.2. Relationship to Existing Work The DetNet Controller Plane framework identifies the control and management functions required for DetNet service provisioning. ACTN supplies the customer and controller hierarchy used here to organize those functions. The DetNet multi-domain framework addresses the more general problem of coordinating services across domains; this document examines the use of ACTN within its hierarchical approach. The mapping is functional, without requiring separate ACTN and DetNet control components or a one-to-one correspondence. One or more DetNet Controller Plane Functions (CPFs) may fulfil an ACTN role. 3. Architectural Overview and Use Cases 3.1. ACTN Hierarchy The ACTN hierarchy consists of a Customer Network Controller (CNC), a Multi-Domain Service Coordinator (MDSC) and Provisioning Network Controllers (PNCs). The CNC communicates customer requirements through the CNC-MDSC Interface (CMI). The MDSC coordinates domain controllers through the MDSC-PNC Interface (MPI), as shown in Figure 1. Contreras, et al. Expires 6 May 2027 [Page 4] Internet-Draft ACTN for DetNet November 2026 +----------------------+ | CNC | +----------+-----------+ | CMI +----------v-----------+ | MDSC | +----------+-----------+ | MPI +-------------+-------------+ | | | +----v----+ +----v----+ +----v----+ | PNC 1 | | PNC 2 | | PNC N | +----+----+ +----+----+ +----+----+ | | | +----v----+ +----v----+ +----v----+ | Domain 1| | Domain 2| | Domain N| +---------+ +---------+ +---------+ Figure 1: ACTN hierarchy for multi-domain service coordination. Each PNC remains responsible for admission and configuration within its domain, including interaction with technology-specific controllers. 3.2. Representative Use Cases The following scenarios illustrate the coordination requirements: * Heterogeneous DetNet data planes. A service may traverse MPLS or IP domains, or use SRv6 service protection under development [I-D.ietf-detnet-srv6-svc-protection]. Their forwarding, resource allocation and protection mechanisms may differ. Coordination needs to account for each domain's capabilities and constraints. * TSN and DetNet interworking. TSN islands may communicate across a routed DetNet network. Coordination needs to relate TSN stream requirements to DetNet capabilities and constraints, including traffic characteristics, resource availability and timing at the receiving island. Contreras, et al. Expires 6 May 2027 [Page 5] Internet-Draft ACTN for DetNet November 2026 * Wireless domains. Wireless DetNet connectivity depends on link conditions and available resources. The Reliable and Available Wireless (RAW) architecture [RFC9912] supports local repair. A wireless domain needs to expose the capabilities and constraints under which it can support the service. For 3GPP integration, the 5G System (5GS) can act as a logical DetNet transit router, with controller interaction through the Time Sensitive Communication and Time Synchronization Function (TSCTSF) [_3GPP-TS23501]. The related study provides background on DetNet integration with 5GS [_3GPP-TR23700-46]. * Supporting transport domains. Optical and Optical Transport Network (OTN) domains may provide connectivity beneath packet networks carrying DetNet services. Their capacity, delay, protection, restoration behavior and shared resources affect service feasibility and resource allocation. The abstraction needs to distinguish transport resources and performance contributions already included in the packet-domain service from those accounted for separately, avoiding double counting. 4. ACTN-to-DetNet Functional Mapping 4.1. Mapping of Controller-Plane Functions The MDSC coordinates domain CPFs through the MPI. PNCs retain responsibility for local paths, resource allocation and Packet Replication, Elimination and Ordering Functions (PREOF). When PREOF spans domains, the MDSC and responsible PNCs coordinate its placement and operation. 4.2. ACTN Functional Entities 4.2.1. CNC: DetNet Service Requirements At the CNC level, a service request identifies communicating endpoints, traffic characteristics and performance objectives independently of the technologies used along the path. These objectives may include bandwidth, maximum latency, packet delay variation, loss and protection requirements [RFC9016]. The CNC conveys the request over the CMI and receives the resulting service status from the MDSC. Contreras, et al. Expires 6 May 2027 [Page 6] Internet-Draft ACTN for DetNet November 2026 4.2.2. MDSC: End-to-End Coordination The MDSC determines whether a composition of domains can satisfy the request using their abstracted capabilities and resources. It coordinates the allocation of domain-level constraints and obtains the corresponding admission decisions from the PNCs. It also maintains the relationship between the customer service and the domain-level instances that realize it, so that later changes can be assessed in their end-to-end context. 4.2.3. PNC: Domain-Specific Realization The PNC role performs domain-specific service realization. One or more DetNet CPFs may fulfil this role, translating assigned constraints into local paths, reservations, queues and service functions. Admission considers current resource use and availability, including services requested through other control interfaces. In the centralized TSN configuration model [IEEE802.1Qcc], the TSN Centralized Network Configuration (CNC) function may perform the ACTN PNC role. The Centralized User Configuration (CUC) function may perform customer-facing ACTN CNC functions. This functional mapping does not require separate ACTN and TSN control components. 4.2.4. DetNet Domain Abstraction Deterministic properties depend on the ingress-egress border pair and the traffic to be carried. A bound for one pair may not apply to another, and the same pair may support different bounds for different rates, bursts or packet sizes. An abstraction therefore needs to associate the relevant properties with the border pair and the service traffic profile. Abstract transit links or connectivity matrices [RFC8795] can provide the corresponding connectivity representation. For DetNet coordination, the information also needs to describe latency and delay variation bounds, bandwidth and buffer availability, relevant queuing and synchronization characteristics, and supported functions such as PREOF. A PNC may advertise these properties or supply them in response to a service-specific query. The MDSC needs enough information to compare the candidate domains and request a service that each can admit. The amount of detail exposed can depend on the domain's technology and administrative policy. Contreras, et al. Expires 6 May 2027 [Page 7] Internet-Draft ACTN for DetNet November 2026 4.3. Functional Mapping and Coordination Requirements Table 1 summarizes the mapping and the principal coordination needs. +------------------+----------+-----------+------------------+----------------------+ | Function | Entity | Interface | DetNet Role | Coordination | +------------------+----------+-----------+------------------+----------------------+ | Requirement | CNC/MDSC | CMI C->M | Service request | E2E objectives; | | reception | | | | traffic profile | +------------------+----------+-----------+------------------+----------------------+ | Multi-domain | MDSC | Internal | Service | Domain selection; | | coordination | | | composition | objective allocation | +------------------+----------+-----------+------------------+----------------------+ | Domain resource | MDSC/PNC | MPI M->P | Domain control | Map constraints to | | control | | | | local mechanisms | +------------------+----------+-----------+------------------+----------------------+ | Capability | PNC/MDSC | MPI P->M | Topology, | Border-pair | | abstraction | | | capability | properties; admission| +------------------+----------+-----------+------------------+----------------------+ | Service | PNC/MDSC | MPI P->M | Operational state| Events linked to | | monitoring | | | | the service | +------------------+----------+-----------+------------------+----------------------+ | Service | MDSC/PNC | MPI bidir.| Modification | Revised constraints; | | adaptation | | | | admission | +------------------+----------+-----------+------------------+----------------------+ | Boundary/ | MDSC/PNCs| MPI bidir.| Boundary/PREOF | Ownership; ordering; | | protection coord.| | | | compatibility | +------------------+----------+-----------+------------------+----------------------+ | Flow ID/ | MDSC/PNCs| MPI bidir.| Flow/aggregate | Domain IDs for | | aggregation | | | assoc. | customer service | +------------------+----------+-----------+------------------+----------------------+ Table 1: Functional mapping across ACTN entities. 4.4. End-to-End Service Objective Coordination Domain information needs to distinguish supported capabilities, available resources, computed performance estimates, observed telemetry and the deterministic bounds accepted for a service. These descriptions serve different purposes in the coordination process. In particular, a measured latency value does not establish the upper latency bound that the domain can commit to for the requested traffic. Contreras, et al. Expires 6 May 2027 [Page 8] Internet-Draft ACTN for DetNet November 2026 4.4.1. Distribution of End-to-End Objectives The MDSC translates end-to-end objectives into constraints for the participating domains. For an additive latency assessment, the domain contributions and inter-domain contributions need to satisfy: L_1 + L_2 + ... + L_N + L_inter-domain <= L_E2E Here, L_i is the accepted latency bound for domain i, L_inter-domain covers contributions outside those domain bounds, and L_E2E is the end-to-end objective. The bounds need compatible traffic assumptions and reference points. Boundary functions and links are accounted for once, including their costs within a domain bound or in the inter- domain term. Other objectives require separate treatment. Delay variation depends on the delay intervals and packet treatment across the complete path. Reliability and loss depend on the failures being considered and on any shared risks between domains or protected paths. The MDSC needs to assess these conditions together with the latency allocation when deciding whether a service is feasible. 4.4.2. Boundary and Protection Considerations Delay variation in an upstream domain can increase the burstiness seen by a downstream domain, even when the source meets its traffic specification. Traffic regulation or shaping may be needed at the boundary [RFC9320]. The adjacent controllers need to agree where such functions are applied and include their resource and timing requirements in the service assessment. Domains may use different synchronization regimes. For example, a scheduled domain may rely on synchronized clocks, while an adjacent domain uses a different time base or operates asynchronously. Coordination needs to account for the resulting timing uncertainty when relating the upstream delivery behavior to the downstream arrival requirements. Protection may be provided within a domain, through local PREOF or RAW repair [RFC9912], or across several domains. The MDSC needs to understand the failure coverage and shared risks of the selected arrangement. Where copies merge, packet ordering may require additional delay and buffering [RFC9550]. The domain controllers and MDSC need to coordinate the placement and operation of these functions. Contreras, et al. Expires 6 May 2027 [Page 9] Internet-Draft ACTN for DetNet November 2026 4.5. Service Monitoring and Re-evaluation Multi-domain coordination continues after service establishment. Changes in resources, topology or operating conditions may affect a domain's ability to meet its assigned constraints. The PNC provides relevant operational information to the MDSC. A PNC can use local Operations, Administration, and Maintenance (OAM) [RFC9551] and protection mechanisms to adapt its realization while remaining within those constraints. Such recovery can be handled locally without requiring the MDSC to recompute the end-to-end service for each internal change. When a domain can no longer meet an assigned bound, it needs to notify the MDSC. This also applies when loss of protection redundancy invalidates the conditions on which the domain commitment was based, even if delivered traffic has not yet experienced a service violation. The MDSC maintains an association between the customer service and its domain-level instances, including relevant boundary functions and supporting resources. This association allows it to identify the services affected by a domain event or a change in a shared resource. The MDSC can then request a revised realization, reconsider the allocation of constraints among domains, or select another domain composition. Its assessment also takes account of the constraints and available resources of the other domains participating in the service. The resulting service status is reported to the CNC. If the requested objectives can no longer be maintained, further action follows the customer's service policy. Changes involving several domains also need coordination while their configurations are updated, so that the customer service remains associated with the intended realization. 5. Applicability, Gap Analysis, and Questions for the Working Group Existing ACTN, TE and DetNet mechanisms provide a starting point. Further analysis should distinguish the following coordination needs and determine which existing mechanisms can meet them: * Architectural or procedural gaps: functions or interactions needed for admission, coordination and service changes across domains. Contreras, et al. Expires 6 May 2027 [Page 10] Internet-Draft ACTN for DetNet November 2026 * Information-model gaps: the meaning of service objectives, domain capabilities, constraints and state, building on [RFC8454] and [RFC9016]. * Data-model gaps: representations needed to exchange that information through the CMI and MPI. * Protocol or signaling gaps: exchanges needed to carry the information and perform the agreed procedures. 5.1. Existing Building Blocks [RFC8795] provides TE topology abstractions, including connectivity matrices. These can represent domain connectivity, with further profiling or extensions to relate deterministic properties to the applicable traffic and timing conditions. [RFC9731] provides a Virtual Network (VN) YANG model, including endpoint and member relationships and a VN computation operation. The mapping needs to relate those objects and computation results to the service accepted by the participating domains. [RFC9016] and [RFC9633] describe DetNet flow and service information and device configuration. They provide useful local building blocks. Further work concerns the association of customer requirements with domain-level admission and the corresponding configured instances. [I-D.ietf-teas-actn-pm-telemetry-autonomics] addresses VN and TE performance monitoring and scaling intent. Its applicability includes associating reported information with the affected service and distinguishing observed performance from a change in a domain commitment. [RFC8685] supports hierarchical path computation using the Path Computation Element Communication Protocol (PCEP). Its use in an ACTN realization needs to be considered together with domain admission, boundary coordination and service activation. Contreras, et al. Expires 6 May 2027 [Page 11] Internet-Draft ACTN for DetNet November 2026 +------------------------+-----------------------+--------------------------------+ | Baseline | Building Block | Further Work | +------------------------+-----------------------+--------------------------------+ | TE topology [RFC8795] | Abstract connectivity/| Traffic-dependent border-pair | | | properties | properties | +------------------------+-----------------------+--------------------------------+ | VN YANG [RFC9731] | Endpoints, members, | Association with accepted | | | computation | domain services | +------------------------+-----------------------+--------------------------------+ | DetNet info/YANG | Flow objectives/local | Cross-domain service/ | | [RFC9016] [RFC9633] | configuration | flow association | +------------------------+-----------------------+--------------------------------+ | ACTN telemetry | VN/TE performance | Commitment changes/ | | [I-D.ietf-teas-actn-pm-| monitoring | service correlation | | telemetry-autonomics] | | | +------------------------+-----------------------+--------------------------------+ | Hierarchical PCEP | Parent/child path | Coordination with admission/ | | [RFC8685] | computation | boundaries | +------------------------+-----------------------+--------------------------------+ Table 2: Initial baselines for further applicability analysis. These areas may be addressed through agreed procedures and profiles, extensions to existing models, or protocol work where the required exchange is not already supported. 5.2. Open Questions for further discussion 1. What minimum information should a domain expose for an ingress- egress pair so that the MDSC can assess a requested deterministic service? 2. How should adjacent domains agree on traffic regulation, synchronization assumptions and protection functions at their boundary? 3. What division of responsibility best supports domain-local recovery and MDSC re-evaluation when an accepted constraint changes? 4. Which CMI and MPI needs can be met by profiling existing models and procedures, and where are specific extensions needed? 5. How should this ACTN applicability work be coordinated with the DetNet multi-domain framework, TEAS work and relevant IEEE activities? Contreras, et al. Expires 6 May 2027 [Page 12] Internet-Draft ACTN for DetNet November 2026 6. Security Considerations The security considerations of [RFC9055], [RFC8453] and [RFC8454] apply. CMI and MPI exchanges need authentication, integrity protection and authorization appropriate to the customer and controller relationships. Access to domain information and control operations also needs to respect administrative boundaries. The MDSC relies on information supplied by domain controllers about deterministic bounds, resource availability and shared risks. Inaccurate or malicious information can lead to an infeasible service or an unsuitable protection arrangement. Source identification, consistency checks and operational monitoring are relevant to establishing trust in these claims. Excessive service requests, reservations or traffic bursts can exhaust queues, buffers and protection resources, including functions at domain boundaries. Admission controls, traffic conditioning and limits on provisional resource allocations are needed to protect other services sharing those resources. Attacks on synchronization can affect schedules and timing assumptions. Manipulation of flow identifiers or sequence state can also interfere with replication, elimination and ordering. The selected domain mechanisms need to protect these functions and report changes that affect the accepted service conditions. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018, . Contreras, et al. Expires 6 May 2027 [Page 13] Internet-Draft ACTN for DetNet November 2026 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., and D. King, "Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture", RFC 8685, DOI 10.17487/RFC8685, December 2019, . [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, . [RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, "Flow and Service Information Model for Deterministic Networking (DetNet)", RFC 9016, DOI 10.17487/RFC9016, March 2021, . [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", RFC 9055, DOI 10.17487/RFC9055, June 2021, . [RFC9320] Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J., and B. Varga, "Deterministic Networking (DetNet) Bounded Latency", RFC 9320, DOI 10.17487/RFC9320, November 2022, . [RFC9550] Varga, B., Ed., Farkas, J., Kehrer, S., and T. Heer, "Deterministic Networking (DetNet): Packet Ordering Function", RFC 9550, DOI 10.17487/RFC9550, March 2024, . [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, . Contreras, et al. Expires 6 May 2027 [Page 14] Internet-Draft ACTN for DetNet November 2026 [RFC9633] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, "Deterministic Networking (DetNet) YANG Data Model", RFC 9633, DOI 10.17487/RFC9633, October 2024, . [RFC9731] Lee, Y., Ed., Dhody, D., Ed., Ceccarelli, D., Bryskin, I., and B. Yoon, "A YANG Data Model for Virtual Network (VN) Operations", RFC 9731, DOI 10.17487/RFC9731, March 2025, . [RFC9912] Thubert, P., Ed., "Reliable and Available Wireless (RAW) Architecture", RFC 9912, DOI 10.17487/RFC9912, April 2026, . [RFC9938] Malis, A., Geng, X., Ed., Chen, M., Varga, B., and CJ. Bernardos, "A Framework for the Deterministic Networking (DetNet) Controller Plane", RFC 9938, DOI 10.17487/RFC9938, March 2026, . 8.2. Informative References [I-D.ietf-detnet-multi-domain-framework] Bernardos, C. J., Contreras, L. M., Xiong, Q., and A. Mourad, "A Control Plane Framework for Multi-Domain Deterministic Networking (DetNet)", Work in Progress, Internet-Draft, draft-ietf-detnet-multi-domain-framework- 02, 25 July 2026, . [I-D.ietf-detnet-srv6-svc-protection] Varga, B. and F. Fejes, "Deterministic Networking SRv6 Data Plane for Service Protection", Work in Progress, Internet-Draft, draft-ietf-detnet-srv6-svc-protection-00, 17 June 2026, . [I-D.ietf-teas-actn-pm-telemetry-autonomics] Dhody, D., King, D., Vilalta, R., Busi, I., and D. Ceccarelli, "YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Work in Progress, Internet-Draft, draft-ietf- teas-actn-pm-telemetry-autonomics-19, 8 October 2026, . Contreras, et al. Expires 6 May 2027 [Page 15] Internet-Draft ACTN for DetNet November 2026 [IEEE802.1Qcc] "IEEE 802.1Qcc-2018, IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks-- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements", 2018, . [_3GPP-TR23700-46] "3GPP TR 23.700-46 Study on 5GS Deterministic Networking (DetNet) interworking, Version 18.0.0", March 2023, . [_3GPP-TS23501] "3GPP TS 23.501, System architecture for the 5G System (5GS), Version 18.6.0", July 2024, . Acknowledgements The work of Carlos J. Bernardos, Luis M. Contreras, and Marta Blanco Caamaño in this document has been partially supported by the Horizon Europe SNS-JU project PRIME-6G (Grant Agreement No.101272485). This work was partially supported by the Sao Paulo Research Foundation (FAPESP), grants 2021/00199-8 (SMARTNESS) and 2025/16251-0. Authors' Addresses Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Marta Blanco-Caamaño Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Carlos J. Bernardos UC3M Email: cjbc@it.uc3m.es Contreras, et al. Expires 6 May 2027 [Page 16] Internet-Draft ACTN for DetNet November 2026 Christian E. Rothenberg UNICAMP Email: chesteve@unicamp.br Contreras, et al. Expires 6 May 2027 [Page 17]