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

3.1. Domain Characteristics

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.¶

3.2. Scope of a DetNet 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 [I-D.ietf-detnet-dataplane-taxonomy]). 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., [RFC9016]) 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.¶

4.1. Exemplary Use Case

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 [RFC8964] or DetNet IP [RFC8939] 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).¶

                    .------------------------------------.
                    |            Parent PCE              |
                    '------------------------------------'
                           ^      |      ^
                           |      |      |
                           v      v      v
      .----------------.   .----------------.   .----------------.
      | Child PCE (d1) |   | Child PCE (d2) |   | Child PCE (d3) |
      '----------------'   '----------------'   '----------------'
            | |                  | |                  | |
 S ---- R1 ======== R2 -------- R3 ======== R4 -------- R5 ---- D
        <-- Domain 1 -->   <---- 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.¶

4.2. Problem Statement

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.¶

4.3. Hierarchical PCE (H-PCE) Approach

The Hierarchical PCE (H-PCE) architecture [RFC6805] 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:¶

1. 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).¶
2. 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.¶
3. 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.¶
4. Each C-PCE computes its path segment, reserves the necessary resources locally, and reports success or failure back to the P-PCE.¶
5. 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.¶

4.4. Peer-to-Peer (Stitching) PCE Approach

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 [RFC5441] for inter-area and inter-AS TE path computation.¶

In a multi-domain DetNet context:¶

1. The PCE in the source domain (PCE-1) receives a path request for a flow destined for another domain.¶
2. PCE-1 computes a path from the source node to a suitable exit border node in its domain.¶
3. 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.¶
4. 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.¶
5. This process repeats until the PCE in the destination domain is reached. The path is confirmed backward along the chain of PCEs.¶

5.1. End-to-End Path Computation

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 [RFC9320] considering the bounded latency metric.¶

5.2. Resource Management

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.¶

5.3. End-System awareness

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.¶

5.4. Flow Aggregation

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.¶