]> KDDI

Japan ta-miyasaka@kddi.com

1Finity

Japan tochio@fujitsu.com

RTG TEAS Working Group ACTN MDSC inter-operator traffic engineering optical This document specifies an extension to the ACTN framework (RFC 8453) that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators, in which neither MDSC has authority over the other, and which complements rather than modifies the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. Status information for this document may be found at . Discussion of this document takes place on the TEAS Working Group mailing list (), which is archived at . Subscribe at .

Introduction The Abstraction and Control of TE Networks (ACTN) framework defines a three-tier hierarchy of controllers, the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controllers (PNCs), connected by the CNC-MDSC Interface (CMI) and the MDSC-PNC Interface (MPI). ACTN also addresses multi-domain networks through a hierarchical arrangement in which a higher-level MDSC (MDSC-H) coordinates lower-level MDSCs (MDSC-L) by applying the MPI recursively. This arrangement assumes that all MDSCs belong to a single administrative domain, or that the MDSC-H holds administrative authority over every MDSC-L, and in either case the MDSCs are owned and operated by a single operator. A growing driver of network operation across different operators is the rapid growth of AI workloads and the data center interconnection (DCI) traffic they generate. Distributed training and inference for large-scale AI models demand high-bandwidth, low-latency, and highly reliable connectivity between data centers, which are frequently owned by data center or cloud operators that are distinct from the network operators owning the wide-area transport infrastructure between them. Satisfying this demand requires high-quality traffic-engineered paths, and increasingly end-to-end optical paths, that are established cooperatively across the data center operator's network and the networks of one or more other operators . In these deployments the networks are operated by different operators, so no operator controls another and no single entity can see or manage all of the networks. The current ACTN framework does not address this case, because it assumes that the MDSC is owned and operated by a single operator and coordinates multiple domains only under that single authority. In a multi-operator setting each operator owns and operates its own MDSC, but ACTN defines no interface between the MDSCs of different operators. This gap is analyzed in detail later in this document. This document specifies an extension to the ACTN framework that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators. Unlike the hierarchical use of the MPI between an MDSC-H and an MDSC-L, the MMI assumes no subordination, and neither MDSC has authority over the other. The MMI complements, and does not modify, the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. While the primary scenario is coordination between different operators, the same mechanism also applies within a single operator to networks that have independent control planes, for example where organizational, technological, or historical reasons prevent a single MDSC from having authority over all of them. It relates to and where possible reuses existing IETF work, including the ACTN VN model , the TE topology model , and the applicability of ACTN to packet-optical integration and to network slicing .

Conventions and Definitions 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 BCP 14 when, and only when, they appear in all capitals, as shown here. The terms CNC, MDSC, PNC, CMI, and MPI are used as defined in . This document additionally uses the following terms.

Operator:

An independent administrative entity that owns and operates its own ACTN stack, comprising a CNC, an MDSC, and one or more PNCs.

Domain:

A network controlled by a single PNC, as in . A domain belongs to one operator.

Multi-domain:

Involving multiple domains within a single operator, as in .

Multi-operator:

Involving multiple independent operators.

Inter-operator:

Between independent operators. This document defines inter-operator coordination between MDSCs.

MMI (MDSC-MDSC Interface):

The symmetric peer interface between the MDSCs of different operators, defined in this document.

Usecase This section presents representative cases that motivate coordination between the MDSCs of different operators. In each case the participating networks belong to different operators, and an end-to-end service has to be built across them without any operator revealing its internal network.

Inter-operator optical connectivity A customer such as an enterprise, a broadcaster, or a research network needs a high-capacity, deterministic optical circuit between two sites that are reached through different operators' optical networks. Each operator operates its own optical transport network based on WDM and OTN, and the circuit has to cross more than one of them. Where the operators' networks support it, the circuit can be realized as an end-to-end all-optical path across their optical networks, avoiding optical-electrical-optical conversion at the boundaries . The operators' MDSCs coordinate to assign wavelength or spectrum at the border between their networks, to validate optical feasibility across the boundary, and to agree on the end-to-end optical budget such as OSNR and latency, while each operator exposes only its border capabilities and an abstracted view of its reachability.

Inter-operator IP traffic engineering A service such as low-latency financial connectivity, real-time media transport, or an enterprise VPN needs a traffic-engineered path that spans more than one operator's IP/MPLS network. Each operator operates its own IP/MPLS network, and inter-operator connectivity today relies on static peering with little dynamic TE coordination. The operators' MDSCs coordinate to reserve bandwidth at the inter-operator links and to compute a TE path that meets the end-to-end objective, while each operator keeps control of how the path is realized inside its own network.

Multi-layer interconnection for AI data centers Large-scale AI workloads, together with the power and siting constraints of large data centers, are driving operators to distribute data centers across multiple sites, which increases the traffic between them. These data centers are run by a data center or cloud operator, while the wide-area connectivity between the sites is provided by one or more network operators. The data center operator runs an IP or packet-optical network at each site, and the network operators provide the transport between the sites over OTN and optical (WDM) infrastructure, so the end-to-end service is both multi-layer and multi-operator. The data center operator's MDSC and the network operators' MDSCs coordinate to build a packet or IP connection that is carried over OTN or optical paths across those operators, agreeing on the interconnection points, the end-to-end latency and bandwidth, and the management of the shared resources, while each operator keeps its internal topology private.

Gap Analysis

Current ACTN and related IETF work defines the ACTN reference architecture shown in Figure 1. A single MDSC sits between the customer, reached through the CMI, and one or more PNCs, reached through the MPI, and it abstracts and coordinates the domains below it. For larger networks, ACTN allows the MDSC to be arranged hierarchically, with a higher-level MDSC (MDSC-H) coordinating lower-level MDSCs (MDSC-L) over a recursive MPI. In both the flat and the hierarchical case, the whole controller hierarchy belongs to a single operator, or to a single entity that has authority over every MDSC.

Figure 1 shows that multiple PNCs, each controlling one domain, are coordinated by a single MDSC. ACTN is defined together with, and complemented by, a number of other IETF specifications, summarized below; all of them assume the single-authority model described above. Base framework and models: the ACTN framework and the ACTN information model . Virtual network operations: the VN operations model . Packet-optical and optical transport: the applicability of ACTN to packet-optical integration and the optical transport network management model . Slicing and performance: the applicability of ACTN to network slicing and ACTN PM telemetry and autonomics .

What is missing None of the work above defines coordination between the MDSCs of different operators. The specific gaps are the following. No peer relationship between MDSCs. ACTN covers control within a single operator, including coordination across multiple domains and layers, but it does not define how the MDSCs of different operators coordinate as peers, where neither has authority over the other. This is the core gap, and the points below are consequences of it. Hierarchical MDSC does not fill this gap. The MDSC-H and MDSC-L model needs a root MDSC with authority over and full visibility into the domains below it, which different operators do not grant to each other. No confidentiality-preserving information exchange. Each operator needs to limit and negotiate how much of its topology and resources it reveals to a peer. defines abstraction levels such as black-box and white-box views, but not a way for two operators to negotiate this between themselves. No coordinated provisioning or assurance across operators. There is no defined way for different operators to commit their per-domain segments together and roll back together on failure, nor to monitor an end-to-end service and isolate faults across operator boundaries. Service orchestration exists, but not at the TE-control layer. Inter-operator service orchestration is already defined outside the IETF, for example the MEF (now Mplify) LSO architecture , whose inter-provider reference points cover business functions such as ordering and billing and operational functions such as service assurance. These operate at the service and business layer and rely on an underlying network control system for the traffic engineering itself; the MEF intra-provider control reference point corresponds to the ACTN MPI. They do not define how the MDSCs of different operators coordinate to exchange abstracted TE topology, to compute an end-to-end path cooperatively, or to provision it across the operator boundary. The first gap, the missing peer interface between MDSCs, is the foundation for the others, and it is the focus of the extension defined in this document. The control-layer coordination defined here is complementary to service-layer orchestration such as MEF LSO, which can build on top of it.

Framework This document extends the ACTN architecture so that the MDSCs of different operators can coordinate directly as peers. Each operator keeps its own ACTN stack, namely a CNC, an MDSC, and one or more PNCs, unchanged. The extension adds the MMI between the MDSCs of different operators, as shown in Figure 2.

In the figure, each operator runs its own MDSC over its own PNCs and serves its own customers through the CMI, exactly as in . The new element is the MMI between the two MDSCs, which connects the operators as peers rather than placing one above the other. The MMI differs from the hierarchical use of the MPI between an MDSC-H and an MDSC-L in the following ways. Symmetry. Both MDSCs have the same role, and either one can initiate a request, so there is no parent and no child. No authority across the boundary. Neither MDSC can provision, change, or release resources in the other operator's network, and every action across the boundary follows from mutual agreement. Policy-governed disclosure. Each operator decides what topology and resource information it exposes to the peer, subject to negotiation between the two operators. At a high level, peer MDSCs use the MMI for the following interactions : Exchange of abstracted topology and resource information, at a level of detail each operator agrees to disclose. Cooperative establishment of end-to-end services, including agreement on the interconnection points and on the per-domain segments. Coordinated provisioning of the per-domain segments that make up an end-to-end service. Exchange of performance-monitoring information for the shared services, supporting end-to-end assurance. Within each operator, the CMI and the MPI between the MDSC and its PNCs continue to work as defined in , and the extension does not change them. The functions carried over the MMI, and the information it exchanges, are described in the following sections.

Policy and information exchange between operators Because the MMI operates across administrative boundaries, the two operators first agree, bilaterally, on what information they exchange and under which policy. This agreement covers the level of topology and resource abstraction each side discloses, the categories of information shared, and how often it is updated. The MMI is more than a per-service connection request: beyond requesting an end-to-end connection, it also carries the exchange of abstracted topology and resource information, cooperative path computation, coordinated provisioning, and end-to-end assurance. This document describes these interactions at a high level; the detailed agreement mechanism and the MDSC-to-MDSC workflow are left for a future revision.

Requirements

Requirements on MDSC for inter-operator operation in section 3.2 of , multi-domain coordination and virtualization/abstraction are defined as the functions in MDSC. The Multi-domain means the domains that MDSC operates via PNCs and the coordination means that among MDSC and PNCs. Multi-domain operation is supported with the coordination and virtualization/abstraction. In inter-operator operation, each operator is responsible for providing an end-to-end service in coordination with other operators. Each operator is not required to expose the detail of internal topology, network resources and network elements to other operators, but is required to address the minimum information to provide an end-to-end path. So MDSC SHOULD have capability for creating and address the network information minimum enough to communicate with other MDSC(s) . Therefore, the requirements on MDSC for inter-operator operation are as below. MDSC SHOULD request to other MDSCs to create an end-to-end path per request from CNC connected to the MDSC. MDSC SHOULD have the capability of path calculation, path provisioning, and path management (e.g., fault management, performance management) in the domain MDSC controls and manages. The attributes of the path SHOULD be advertised to other MDSC(s) to create an end-to-end path as above mentioned. MDSC SHOULD have the capability of managing the network resource information addressed from other domains to create the path in the domain, with coordination of the request of an end-to-end path. MDSC SHOULD address the network resource information and network status information, e.g., performance monitoring and fault notification, to other MDSCs. In addressing, the network information SHOULD be abstracted and minimized enough to provisioning and maintaining the end-to-end service path as requested from CNC. MDSC SHOULD address the network resource information immediately when it is changed and impacts on the management of end-to-end service path. MDSC MAY request other MDSCs for their network status information regarding the end-to-end service path. For the request, MDSC SHOULD reply in the scope of agreement between them. MDSC SHOULD NOT directly manage PNCs that belong to another operator; those PNCs are managed by that operator's own MDSC. A PNC SHOULD be managed by an MDSC of the same operator and SHOULD NOT be managed by an MDSC of another operator. ((Requirements on the relationship between MDSC and CNC will be added))

Requirements for Interfaces

Requirements for the MMI to be added if needed.

Requirements for MPI interface between PNC and MDSC to be added if needed.

Requirements for MPI interface between CNC and MDSC to be added if needed.

Interface Protocols and YANG Data Models for the MPIs to be considered...

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IOWN Glogal Forum MEF Forum A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453). This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. FiberCop Vodafone Huawei Old Dog Consulting Cisco This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture Old Dog Consulting Independent Huawei Technologies Old Dog Consulting Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN and indicates where ACTN might be extended. This document provides an information model for Abstraction and Control of TE Networks (ACTN). China Unicom CAICT Huawei Technologies Old Dog Consulting Old Dog Consulting Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for detailed YANG Configuration and Management, effectively adding support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. Huawei Lancaster University CTTC Huawei Technologies Cisco This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for Traffic Engineering (TE) tunnels and Virtual Networks (VNs). Their performance monitoring parameters are exposed as the key telemetry data for tunnels and VNs. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN.

Acknowledgments TODO acknowledge.

Contributors 1Finity

Japan kuroiwa.reiko@fujitsu.com