Internet-Draft Multi-Domain DetNet Framework June 2026
Bernardos, et al. Expires 31 December 2026 [Page]
Workgroup:
DETNET WG
Internet-Draft:
draft-ietf-detnet-multi-domain-framework-01
Published:
Intended Status:
Informational
Expires:
Authors:
C.J. Bernardos, Ed.
Universidad Carlos III de Madrid
L. Contreras
Telefonica
Q. Xiong
ZTE Corporation
A. Mourad
InterDigital

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

Abstract

Deterministic Networking (DetNet) provides the capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency over a path or network. As DetNet deployments expand, they will inevitably need to span multiple domains that may be under separate administrative or technological control. This creates a need for a control plane solution that can establish and maintain end-to-end DetNet services across these domain boundaries.

This document defines a generic framework for a multi-domain DetNet control plane. It first establishes a working definition of a "DetNet Domain" for the purpose of path computation and control. It then describes two high-level architectural approaches for inter-domain path computation and resource reservation: a Hierarchical model and a peer-to-peer "stitching" model. While a Path Computation Element (PCE)-based realization is used as an illustrative example, the framework is designed to be applicable to any controller-plane technology that satisfies the stated functional requirements. This framework provides the foundation for more specific work on multi-domain DetNet solutions.

Status of This Memo

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 31 December 2026.

▲

Table of Contents

1. Introduction

The Deterministic Networking (DetNet) architecture, as defined in [RFC8655], 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 [I-D.ietf-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 [RFC4655] [RFC5440] 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 framework is intended to be aligned with related DetNet work. The use of multiple queuing mechanisms within and across domains, are described in [I-D.ietf-detnet-scaling-requirements] (in particular its Section 3.8); the classification of data plane queuing mechanisms (including time-bounded ones) and the considerations for interoperability between domains are provided in [I-D.ietf-detnet-dataplane-taxonomy]. This document reuses the terminology and categories of those documents and aims to remain consistent with them as they evolve.

This document proposes a foundational framework by:

The goal is to establish the necessary foundational concepts before addressing specific technology implementations, such as multi-domain RAW (Reliable and Available Wireless) [I-D.bernardos-detnet-raw-multidomain].

2. Conventions and Terminology

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.

This document uses the terminology defined in [RFC8655]. 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 [RFC6805] is one example of a Hierarchical Controller.
Admission Control:
The process by which a controller decides whether a new DetNet flow (or aggregate) can be accepted on a path segment without violating the DetNet QoS guarantees (bounded latency, bounded jitter, zero congestion loss) already committed to previously admitted flows. In a multi-domain setting, admission control is performed within each domain and coordinated across domains, so that an end-to-end flow is admitted only if every traversed domain can admit its segment. The flow admission considerations of [