| Internet-Draft | Inter-Operator ACTN | July 2026 |
| Miyasaka & Tochio | Expires 7 January 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-miyatoch-teas-actn-inter-operator-extension/.¶
Discussion of this document takes place on the TEAS Working Group mailing list (mailto:teas@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/teas/. Subscribe at https://www.ietf.org/mailman/listinfo/teas/.¶
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 7 January 2027.¶
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.¶
The Abstraction and Control of TE Networks (ACTN) framework [RFC8453] 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 [IGF-MD-FA].¶
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 [RFC9731], the TE topology model [RFC8795], and the applicability of ACTN to packet-optical integration [I-D.ietf-teas-actn-poi-applicability] and to network slicing [I-D.ietf-teas-applicability-actn-slicing].¶
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 [RFC2119] [RFC8174] 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 [RFC8453]. This document additionally uses the following terms.¶
An independent administrative entity that owns and operates its own ACTN stack, comprising a CNC, an MDSC, and one or more PNCs.¶
A network controlled by a single PNC, as in [RFC8453]. A domain belongs to one operator.¶
Involving multiple domains within a single operator, as in [RFC8453].¶
Involving multiple independent operators.¶
Between independent operators. This document defines inter-operator coordination between MDSCs.¶
The symmetric peer interface between the MDSCs of different operators, defined in this document.¶
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.¶
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 [IGF-MD-FA]. 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.¶
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.¶
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.¶
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. [RFC8795] 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 [MEF55.1], 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.¶
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.¶
+---------+ +---------+
| CNC | | CNC |
+---------+ +---------+
| |
| |
Boundary =====|==================|===============
between | |
Customer & | CMI |
Network | |
Operator | |
+------------+ MMI +------------+
| MDSC |-------| MDSC |
+------------+ +------------+
| | |
| MPI | MPI |
| | |
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
| SBI / | |
| / | SBI |
--------- ----- | -----
( ) ( ) | ( )
- Control - ( Phys. ) | ( Phys. )
( Plane ) ( Net ) | ( Net )
( Physical ) ----- | -----
( Network ) -----
- - ( )
( ) ( Phys. )
--------- ( Net )
-----
Figure 2: ACTN architecture extended for inter-operator operation
¶
In the figure, each operator runs its own MDSC over its own PNCs and serves its own customers through the CMI, exactly as in [RFC8453]. 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 [IGF-MD-FA]:¶
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 [RFC8453], and the extension does not change them. The functions carried over the MMI, and the information it exchanges, are described in the following sections.¶
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.¶
in section 3.2 of [RFC8453], 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))¶
to be added if needed.¶
to be added if needed.¶
to be added if needed.¶
to be considered...¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶