A PCE-based 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 these domain boundaries. The Path Computation Element (PCE) Communication Protocol (PCEP) provides a standard mechanism for a PCE to compute paths and a Path Computation Client (PCC) to request them. This makes PCE a suitable candidate for building a multi-domain DetNet control plane. This document builds on the DetNet Controller Plane Framework by focusing specifically on multi-domain challenges. It proposes a foundational framework by:

Defining what constitutes a "domain" in the context of DetNet path computation.
Describing high-level PCE-based architectures for managing multi-domain paths.
Identifying key considerations for establishing and maintaining DetNet flows across these domains.

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 , and .

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 PCE-based control plane perspective, this typically implies that:

A single PCE instance (or a coordinated set of redundant PCEs) has complete topological visibility within the domain.
This PCE instance 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 PCE 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.
PCE Control Domain:: A domain is defined as the set of nodes controlled by a single PCE instance. This is the primary definition used within this framework. A large administrative domain might be divided into multiple smaller PCE control 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, an 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 PCE 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. PCE needs to select a specific queuing mechanism along the path for a DetNet flow within each domain.

Let's 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).

Exemplary multi-domain scenario <---- Domain 2 ----> <-- Domain 3 --> (wired) (RAW) (wired) S, D: end-systems (source and destination) Rx: DetNet routers/bridges ==: wired link --: wireless link ]]> Each domain has its own PCE, which is responsible for path computation and resource management within the domain. These are referred to as Child PCEs (C-PCEs). Routers R2 and R3 are border routers of Domain 2 (RAW), and R3 and R4 are border routers of Domain 2 and 3, respectively. A Parent PCE (P-PCE) is responsible for the end-to-end path computation and orchestration among the different C-PCEs.

In a multi-domain environment, no single PCE 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 PCE is responsible for its own internal path computation and resource allocation. The multi-domain architecture must define how these individual PCEs cooperate to create a seamless end-to-end service. Two primary models are considered: Hierarchical PCE and Peer-to-Peer PCE.

The Hierarchical PCE (H-PCE) architecture defines a parent-child relationship between PCEs.

A Parent PCE (P-PCE) has a partial, abstracted view of the child domains. It does not see the detailed topology within each child domain but knows the reachability and characteristics (e.g., available latency budget, cost) of paths to and through them.
A Child PCE (C-PCE) has full visibility of its own domain's topology and resources. It is responsible for all intra-domain path computations.

In a multi-domain DetNet context:

A request for an end-to-end DetNet path is sent to the P-PCE. This request includes the source, destination, and required QoS parameters (e.g., maximum latency).
The P-PCE computes a high-level, domain-sequence path. This path is a sequence of domains that the flow must traverse, along with the entry and exit boundary nodes for each domain.
The P-PCE then sends requests to the C-PCE 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 C-PCE computes its path segment, reserves the necessary resources locally, and reports success or failure back to the P-PCE.
If all C-PCEs are successful, the P-PCE confirms the end-to-end path. If any C-PCE fails, the P-PCE may attempt to find an alternate domain path.

The Parent PCE (P-PCE) would be responsible for computing the multi-domain path based on an abstracted topology of the different domains. The Child PCEs (C-PCEs) are responsible for the path computation in their own domains. A C-PCE would be aware of the specific technologies used in its domain (e.g., RAW, DetNet IP, DetNet MPLS, etc.), being able to compute a path taking into account the specific constraints of the technology. For instance, in a RAW domain, the C-PCE would be able to select the path, the schedule and the links to be used to guarantee a certain level of reliability.

In a peer-to-peer approach, also known as "stitching," there is no parent-child hierarchy. PCEs from adjacent domains cooperate as peers. The path computation is performed sequentially from one domain to the next. This model is described in for inter-area and inter-AS TE path computation. In a multi-domain DetNet context:

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

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. In hierarchical PCE, the P-PCE needs to collect the domain-specific information from C-PCEs and the P-PCE will divide the end-to-end budget of a DetNet flow into sub-budgets to several domains based on the capabilities (e.g. latency, jitter) within each domain. In stitching PCE, the end-to-end budget of a DetNet will be divided from the source PCE, then to an adjacent domain, till to the destination PCE. The PCE within each domain needs to compute 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, 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 the end-to-end QoS guarantees for aggregated flow(s) that span across multiple domains. Multiple flows may be aggregated in a domain and disaggregated in another domain. The network parameters of an aggregated flow should be exchanged among different network domains. The path computation should consider to identify the end-to-end budget of the aggregated flow which should cover the requirements of all member flows.

Multi-domain operations introduce significant security challenges. The communication between PCEs 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's PCE to an external entity (a parent PCE or a peer PCE) is a sensitive matter. The framework must allow for policy-based control over the level of abstraction and detail that is shared. Considerations from also applies.

This document makes no requests of IANA.

The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe DESIRE6G (Grant 101096466), and UNICO I+D 6G-DATADRIVEN-04 project (TSI-063000-2021-132).