A Control Plane Framework for Multi-Domain Deterministic Networking (DetNet)

The Deterministic Networking (DetNet) architecture, as defined in , provides a service for flows requiring bounded latency, and/or extremely low packet loss, and/or reliable service. The initial focus of DetNet has largely been on single-domain networks, where a single controller or administrative entity has full visibility and control over all network resources. However, many use cases, such as industrial automation, professional audio/video, and smart grids, require deterministic connectivity that spans multiple networks. These networks may be operated by different providers (administrative domains), utilize different underlying link-layer technologies (technological domains), or be structured as separate control areas for scalability. To support such scenarios, a control plane framework is needed to coordinate the establishment of end-to-end DetNet paths across domain boundaries. The DetNet Controller Plane Framework provides the basis for controller-plane operations; this document extends that work specifically to multi-domain scenarios. The framework defined here is intentionally technology-agnostic with respect to the controller-plane implementation. Centralized path computation elements, distributed controllers, Software-Defined Networking (SDN) controllers, and other approaches can all be mapped onto the architectural models described herein. The Path Computation Element (PCE) and its associated protocols are used as a concrete example throughout this document to illustrate how the framework can be realized, but they do not represent the only valid instantiation. This document proposes a foundational framework by:

Defining what constitutes a "domain" in the context of multi-domain DetNet control.
Describing high-level architectural models for managing multi-domain paths.
Identifying key considerations for establishing and maintaining DetNet flows across domain boundaries.

The goal is to establish the necessary foundational concepts before addressing specific technology implementations, such as multi-domain RAW (Reliable and Available Wireless) .

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. This document uses the terminology defined in . The following additional terms are used:

Domain Controller:: A logical entity responsible for path computation and resource management within a single DetNet domain. A Domain Controller has full visibility into the topology and resources of its own domain. A PCE is one example of a technology that can fulfil the Domain Controller role.
Hierarchical Controller:: A logical entity that has an abstracted, partial view of multiple domains and is responsible for coordinating inter-domain path computation by interacting with the Domain Controllers of each constituent domain. A Parent PCE (P-PCE) in the H-PCE architecture is one example of a Hierarchical Controller.

For the purpose of multi-domain DetNet control, a clear definition of a "domain" is essential. A domain represents a collection of network resources (nodes, links) that are managed and controlled as a single entity for the purpose of DetNet path computation and resource allocation.

A DetNet domain is characterized by a set of network nodes that are subject to a single, consistent set of DetNet control and management policies. From a control plane perspective, this typically implies that:

A single Domain Controller instance (or a coordinated set of redundant controllers) has complete topological visibility within the domain.
This Domain Controller is responsible for computing paths and managing the allocation of DetNet-specific resources (e.g., buffer space, link schedules, queue reservations) for all nodes within that domain.
There is a trusted relationship and a secure communication channel between the Domain Controller and all the nodes it controls within the domain.

The boundaries of a DetNet domain can be defined based on several factors, which may overlap:

Administrative Domain:: A set of network elements under the control of a single network operator or administrative entity. This is the most common interpretation. Inter-domain communication occurs when a path must cross from one operator's network to another's.
Controller Domain:: A domain is defined as the set of nodes controlled by a single Domain Controller instance. This is the primary definition used within this framework. A large administrative domain might be divided into multiple smaller controller domains for scalability.
Technological Domain:: A domain could be defined by the consistent use of a specific data plane technology (e.g., a TSN domain, a 3GPP 5G domain) or queuing mechanism (e.g., queuing solutions within the categories as per ). While paths may cross technological boundaries, this document posits that this does not inherently define a control plane domain boundary. A single Domain Controller SHOULD be capable of managing a domain comprising multiple technologies. Similarly, the specific queuing mechanisms (e.g., ) supported by devices do not define a domain boundary; a single domain can contain devices supporting multiple queuing solutions, which can be used concurrently. The Domain Controller needs to select a specific queuing mechanism along the path for a DetNet flow within each domain.

Consider the scenario depicted in the figure below, where a DetNet flow is established between a source S and a destination D. The path for the flow traverses three different domains. Domain 1 is a wired domain, which could for example be a TSN-based DetNet MPLS or DetNet IP network. Domain 2 is a wireless (RAW) domain. Domain 3 is again a wired domain. The RAW domain provides connectivity between the two wired domains. Note that this is just an example, and other combinations of wired/wireless domains could exist (e.g., a DetNet flow traversing a wired domain providing connectivity between two RAW domains).

<---- Domain 2 ----> <-- Domain 3 --> (wired) (RAW) (wired) S, D: end-systems (source and destination) DC: Domain Controller Rx: DetNet routers/bridges ==: wired link --: wireless link ]]> Each domain has its own Domain Controller (DC), which is responsible for path computation and resource management within that domain. Routers R2 and R3 are border routers of Domain 2 (RAW), and R3 and R4 are border routers of Domains 2 and 3, respectively. A Hierarchical Controller is responsible for end-to-end path computation and orchestration across the different Domain Controllers. In a PCE-based realization of this framework, each Domain Controller maps to a Child PCE (C-PCE) and the Hierarchical Controller maps to a Parent PCE (P-PCE) as defined in . Other controller-plane technologies (e.g., YANG/NETCONF-based SDN controllers, BGPLS-based systems) can equally fill these roles, provided they satisfy the functional requirements described in .

Regardless of the specific technology used to realize the control plane, any multi-domain DetNet framework MUST satisfy the following high-level functional requirements:

Each domain's controller must be able to compute an intra-domain path segment that meets a specified portion of the end-to-end DetNet QoS budget (latency, jitter, loss).
A mechanism must exist for domain controllers to advertise an abstracted representation of their domain's capabilities (reachability, available latency budget, bandwidth) to an inter-domain coordination entity, without exposing confidential internal topology details.
An inter-domain coordination mechanism must be able to compose an end-to-end path from individual per-domain path segments, allocating the end-to-end QoS budget across domains.
The framework must support both a centralized (hierarchical) coordination model and a distributed (peer-to-peer) coordination model.
Resource reservation, whether performed transactionally or sequentially, must be coordinated across all participating domains.

In a multi-domain environment, no single controller has end-to-end visibility of the full network topology. The challenge is to compute an end-to-end path that meets the strict latency, jitter, and loss requirements of a DetNet flow, while respecting the administrative and confidentiality boundaries of each participating domain. Each domain's controller is responsible for its own internal path computation and resource allocation. The multi-domain architecture must define how these individual controllers cooperate to create a seamless end-to-end service. Two primary coordination models are considered: Hierarchical and Peer-to-Peer.

In the Hierarchical model, a Hierarchical Controller has a partial, abstracted view of the child domains. It does not see the detailed topology within each domain but knows the reachability and characteristics (e.g., available latency budget, cost) of paths to and through them. Each Domain Controller has full visibility of its own domain's topology and resources, and is responsible for all intra-domain path computations. The H-PCE architecture is one well-defined realization of this model, where the Hierarchical Controller is a Parent PCE and each Domain Controller is a Child PCE. Other SDN-based hierarchical controller architectures follow the same conceptual structure. In a multi-domain DetNet context, path establishment under this model proceeds as follows:

A request for an end-to-end DetNet path is sent to the Hierarchical Controller. This request includes the source, destination, and required QoS parameters (e.g., maximum end-to-end latency).
The Hierarchical Controller computes a high-level, domain-sequence path: a sequence of domains the flow must traverse, together with the entry and exit boundary nodes for each domain.
The Hierarchical Controller then sends requests to the Domain Controller of each domain in the path sequence. Each request asks for an intra-domain path segment between the specified entry and exit nodes that meets a portion of the end-to-end QoS requirements.
Each Domain Controller computes its path segment, reserves the necessary resources locally, and reports success or failure back to the Hierarchical Controller.
If all Domain Controllers succeed, the Hierarchical Controller confirms the end-to-end path. If any Domain Controller fails, the Hierarchical Controller may attempt to find an alternate domain-sequence path.

Each Domain Controller is aware of the specific technologies used in its domain (e.g., RAW, DetNet IP, DetNet MPLS), and can compute a path taking into account the specific constraints of those technologies. For instance, in a RAW domain, the Domain Controller can select the path, the schedule, and the links to be used to guarantee a certain level of reliability.

In the peer-to-peer model, also known as "stitching," there is no parent-child hierarchy. Domain Controllers from adjacent domains cooperate as peers. Path computation is performed sequentially from one domain to the next. The BRPC procedure defined in for inter-area and inter-AS TE path computation is one example of how this model can be realized in a PCE context. In a multi-domain DetNet context, path establishment under this model proceeds as follows:

The Domain Controller in the source domain (DC-1) receives a path request for a flow destined for another domain.
DC-1 computes a path from the source node to a suitable exit border node in its domain.
DC-1 then sends a request to the Domain Controller of the adjacent domain (DC-2), specifying the entry border node and the final destination, along with the remaining QoS budget.
DC-2 computes a path through its domain to either the final destination (if it is within domain 2) or to another suitable exit border node. It then "stitches" this segment to the previous one.
This process repeats until the Domain Controller in the destination domain is reached. The path may be confirmed backward along the chain of Domain Controllers.

The end-to-end path is a concatenation of intra-domain path segments. The total latency and other QoS metrics are cumulative. The control plane must be able to allocate the end-to-end budget among the participating domains. The end-to-end path computation should select one of the end-to-end bounded latency metrics for all domains as defined in . The calculation of the bounded latency will differ depending on the queuing solutions and categories as per . The end-to-end bounded delay will be the sum of the per-domain delays, and the end-to-end variation will be either the sum of the per-domain variations or the maximum variation among all domains, depending on the queuing mechanism used. In the Hierarchical model, the Hierarchical Controller collects domain-specific capability information from each Domain Controller and divides the end-to-end QoS budget of a DetNet flow into per-domain sub-budgets, based on the capabilities (e.g., latency, jitter) available within each domain. In the peer-to-peer stitching model, the end-to-end budget is divided starting from the source domain's controller and passed along to each successive adjacent domain, until reaching the destination domain's controller. The controller within each domain computes the latency bound as per considering the bounded latency metric.

Resources MAY be reserved in each domain for the flow. If any domain in the path cannot provide the required resources, the end-to-end path setup fails. A mechanism for transactional, all-or-nothing resource commitment across domains is highly desirable. The control plane also needs to advertise inter-domain resource information, including bandwidth, delay, and jitter with related queuing mechanisms for QoS coordination.

A critical aspect is whether the end-systems (source and destination) are DetNet-aware.

DetNet-aware End-Systems:: The end-systems can signal their QoS requirements and participate in the DetNet control plane.
DetNet-unaware End-Systems:: The requirements for these systems must be configured at the edge of the DetNet domain by a proxy or network management system. In a multi-domain scenario, the entry node of the first DetNet domain acts as this ingress point.

Flow aggregation is recommended in the multi-domain scenario to achieve end-to-end QoS guarantees for aggregated flows that span across multiple domains. Multiple flows may be aggregated in one domain and disaggregated in another. The network parameters of an aggregated flow should be exchanged among different domain controllers. Path computation should consider the end-to-end budget of the aggregated flow, which must cover the requirements of all its member flows.

Multi-domain operations introduce significant security challenges. The communication between Domain Controllers in different domains MUST be secured, ensuring authentication, integrity, and confidentiality. Each domain must be protected from misbehaving or compromised peer domains. Topology and resource information exposed by a Domain Controller to an external entity (a Hierarchical Controller or a peer Domain Controller) is sensitive. The framework must allow for policy-based control over the level of abstraction and detail that is shared, so that internal topology information is not unnecessarily disclosed across administrative boundaries. Where a PCE-based realization is used, the security considerations of also apply.

This document makes no requests of IANA.

The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe MultiX (Grant Agreement No. 101192521) and DISCO6G-CM.