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

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

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 [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 Domain Controller 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. The Domain Controller needs to select a specific queuing mechanism along the path for a DetNet flow within each domain.¶

4.1. Exemplary Use Case

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

               .----------------------------------------.
               |        Hierarchical Controller         |
               '----------------------------------------'
                      ^          |          ^
                      |          |          |
                      v          v          v
      .--------------.   .--------------.   .--------------.
      | DC (domain1) |   | DC (domain2) |   | DC (domain3) |
      '--------------'   '--------------'   '--------------'
            | |                  | |                  | |
 S ---- R1 ======== R2 -------- R3 ======== R4 -------- R5 ---- D
        <-- Domain 1 -->   <---- 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 [RFC6805]. 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 Section 4.2.¶

4.2. Functional Requirements

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

4.3. Problem Statement

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

4.4. Hierarchical Coordination Model

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 [RFC6805] 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:¶

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

4.5. Peer-to-Peer (Stitching) Model

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 [RFC5441] 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:¶

1. The Domain Controller in the source domain (DC-1) receives a path request for a flow destined for another domain.¶
2. DC-1 computes a path from the source node to a suitable exit border node in its domain.¶
3. 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.¶
4. 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.¶
5. 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.¶

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

The end-to-end path computation should select one of the end-to-end bounded latency metrics for all domains as defined in [I-D.xiong-pce-detnet-bounded-latency]. The calculation of the bounded latency will differ depending on the queuing solutions and categories as per [I-D.ietf-detnet-dataplane-taxonomy]. 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 [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, and 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 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.¶