A Control Plane Framework for Multi-Domain Deterministic Networking (DetNet)
draft-ietf-detnet-multi-domain-framework-02

DETNET WG                                            C.J. Bernardos, Ed.
Internet-Draft                          Universidad Carlos III de Madrid
Intended status: Informational                              L. Contreras
Expires: 26 January 2027                                      Telefonica
                                                                Q. Xiong
                                                         ZTE Corporation
                                                               A. Mourad
                                                            InterDigital
                                                            25 July 2026

  A Control Plane Framework for Multi-Domain Deterministic Networking
                                (DetNet)
              draft-ietf-detnet-multi-domain-framework-02

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

Bernardos, et al.        Expires 26 January 2027                [Page 1]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   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 26 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
   3.  Defining a DetNet Domain  . . . . . . . . . . . . . . . . . .   5
     3.1.  Domain Characteristics  . . . . . . . . . . . . . . . . .   5
     3.2.  Scope of a DetNet Domain  . . . . . . . . . . . . . . . .   5
   4.  Multi-Domain DetNet Architectures . . . . . . . . . . . . . .   6
     4.1.  Exemplary Use Case  . . . . . . . . . . . . . . . . . . .   6
     4.2.  Functional Requirements . . . . . . . . . . . . . . . . .   7
     4.3.  Problem Statement . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Hierarchical Coordination Model . . . . . . . . . . . . .   9
     4.5.  Peer-to-Peer (Stitching) Model  . . . . . . . . . . . . .  10
   5.  Multi-Domain DetNet Flow Considerations . . . . . . . . . . .  10
     5.1.  End-to-End Path Computation . . . . . . . . . . . . . . .  10
     5.2.  Resource Reservation and Admission Control  . . . . . . .  11
     5.3.  End-System Awareness  . . . . . . . . . . . . . . . . . .  12
     5.4.  Flow Aggregation  . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

Bernardos, et al.        Expires 26 January 2027                [Page 2]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

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 [RFC9938] 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:

   *  Defining what constitutes a "domain" in the context of multi-
      domain DetNet control.

Bernardos, et al.        Expires 26 January 2027                [Page 3]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   *  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)
   [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:  This document does not redefine admission control
      or resource reservation, which are established concepts in both
      traffic engineering and DetNet (see [RFC9320] and Section 4.2 of
      [RFC9938]).  This document only specifies how these per-domain
      decisions need to be coordinated across domain boundaries (see
      Section 5.2).

   Time-bounded Queuing Mechanism:  A queuing mechanism that achieves
      bounded latency by constraining, for each flow, the interval
      (e.g., a lower and/or upper bound) within which a packet may be
      forwarded at each hop.  This does not necessarily imply periodic
      operation: cyclic/slotted mechanisms, where transmission
      opportunities recur on a fixed cycle, are one instance of this

Bernardos, et al.        Expires 26 January 2027                [Page 4]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

      category, but non-periodic time-bounded mechanisms also exist.
      The categories of queuing mechanisms are described in
      [I-D.ietf-detnet-dataplane-taxonomy].

3.  Defining a DetNet Domain

   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.

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

Bernardos, et al.        Expires 26 January 2027                [Page 5]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   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.  Multi-Domain DetNet Architectures

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

Bernardos, et al.        Expires 26 January 2027                [Page 6]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

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

                 Figure 1: Exemplary multi-domain scenario

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

Bernardos, et al.        Expires 26 January 2027                [Page 7]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

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

   *  Each domain's controller must be able to perform admission control
      for a new flow or aggregate on its intra-domain segment, accepting
      it only if the segment's contribution to the end-to-end DetNet QoS
      budget can be met without disrupting already admitted flows; these
      admission decisions must be coordinated across domains so that an
      end-to-end flow is admitted only when every traversed domain
      admits its segment.

   *  Where adjacent domains use cyclic (slotted) time-bounded queuing
      mechanisms, the inter-domain coordination mechanism must allow the
      domain controllers to exchange the information needed to allocate
      and align transmission cycles/slots and their phases at the domain
      boundary, so that the per-domain bounds compose into the end-to-
      end bound.

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

Bernardos, et al.        Expires 26 January 2027                [Page 8]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

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.

Bernardos, et al.        Expires 26 January 2027                [Page 9]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

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.  Multi-Domain DetNet Flow Considerations

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.

Bernardos, et al.        Expires 26 January 2027               [Page 10]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   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 Reservation and Admission Control

   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.

   Resource reservation and admission control within a single domain are
   as defined in [RFC9320] and Section 4.2 of [RFC9938]; this document
   does not redefine them.  What this framework specifies is how these
   per-domain, intra-domain decisions are coordinated across domain
   boundaries: an end-to-end flow is admitted only if every traversed
   domain admits its corresponding segment.  As noted in Section 3.8 of
   [I-D.ietf-detnet-scaling-requirements], the computation and time
   needed to admit a new flow without disrupting admitted flows depend
   on the queuing mechanisms in use.

   For domains that rely on cyclic (slotted) time-bounded queuing
   mechanisms (e.g., cyclic mechanisms within the categories described
   in [I-D.ietf-detnet-dataplane-taxonomy]), reserving resources implies
   allocating specific transmission cycles or time slots along the
   intra-domain segment.  At the boundary between two such domains, the

Bernardos, et al.        Expires 26 January 2027               [Page 11]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   Domain Controllers (or the Hierarchical Controller) need to
   coordinate the mapping and phase alignment of cycles/slots between
   the domains, since differences in scheduling granularity, cycle time,
   or phase introduce additional latency, jitter, and potentially packet
   loss.  This is the multi-domain mechanism switchover problem
   identified in Section 3.8 of [I-D.ietf-detnet-scaling-requirements].
   The control plane needs to account for this boundary cost when
   dividing the end-to-end budget into per-domain sub-budgets (see
   Section 5.1).

   The specific protocol elements needed to advertise per-domain
   admission-control state (e.g., available slots/cycles, remaining
   queue and buffer capacity) and to request slot/cycle allocation
   across a domain boundary are expected to be detailed in future,
   solution-specific documents.

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.

6.  Security Considerations

   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.

Bernardos, et al.        Expires 26 January 2027               [Page 12]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   Where a PCE-based realization is used, the security considerations of
   [RFC8253] also apply.

7.  IANA Considerations

   This document makes no requests of IANA.

8.  Acknowledgments

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

   The authors would like to thank Adrian Farrel, Christian Esteve
   Rothenberg, Jinoo Joung, Peng Liu, Xueyan Song, Tianji Jiang and Mike
   Blanche for their valuable comments and feedback on this document,
   and the DetNet WG chairs, Janos Farkas and Lou Berger, for their
   guidance during the adoption process.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

9.2.  Informative References

   [I-D.bernardos-detnet-raw-multidomain]
              Bernardos, C. J. and A. Mourad, "DetNet multidomain
              extensions", Work in Progress, Internet-Draft, draft-
              bernardos-detnet-raw-multidomain-07, 16 April 2026,
              <https://datatracker.ietf.org/doc/html/draft-bernardos-
              detnet-raw-multidomain-07>.

Bernardos, et al.        Expires 26 January 2027               [Page 13]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   [I-D.ietf-detnet-dataplane-taxonomy]
              Joung, J., Geng, X., Peng, S., and T. T. Eckert,
              "Dataplane Enhancement Taxonomy", Work in Progress,
              Internet-Draft, draft-ietf-detnet-dataplane-taxonomy-06, 4
              July 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-detnet-dataplane-taxonomy-06>.

   [I-D.ietf-detnet-scaling-requirements]
              Liu, P., Li, Y., Eckert, T. T., Xiong, Q., Ryoo, J.,
              zhushiyin, and X. Geng, "Requirements for Scaling
              Deterministic Networks", Work in Progress, Internet-Draft,
              draft-ietf-detnet-scaling-requirements-10, 14 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
              scaling-requirements-10>.

   [I-D.xiong-pce-detnet-bounded-latency]
              Xiong, Q., Liu, P., and R. Gandhi, "PCEP Extension for
              Bounded Latency", Work in Progress, Internet-Draft, draft-
              xiong-pce-detnet-bounded-latency-07, 29 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-xiong-pce-
              detnet-bounded-latency-07>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <https://www.rfc-editor.org/info/rfc5441>.

   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              DOI 10.17487/RFC6805, November 2012,
              <https://www.rfc-editor.org/info/rfc6805>.

Bernardos, et al.        Expires 26 January 2027               [Page 14]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane:
              IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
              <https://www.rfc-editor.org/info/rfc8939>.

   [RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
              S., and J. Korhonen, "Deterministic Networking (DetNet)
              Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
              2021, <https://www.rfc-editor.org/info/rfc8964>.

   [RFC9016]  Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
              Fedyk, "Flow and Service Information Model for
              Deterministic Networking (DetNet)", RFC 9016,
              DOI 10.17487/RFC9016, March 2021,
              <https://www.rfc-editor.org/info/rfc9016>.

   [RFC9320]  Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J.,
              and B. Varga, "Deterministic Networking (DetNet) Bounded
              Latency", RFC 9320, DOI 10.17487/RFC9320, November 2022,
              <https://www.rfc-editor.org/info/rfc9320>.

   [RFC9938]  Malis, A., Geng, X., Ed., Chen, M., Varga, B., and CJ.
              Bernardos, "A Framework for the Deterministic Networking
              (DetNet) Controller Plane", RFC 9938,
              DOI 10.17487/RFC9938, March 2026,
              <https://www.rfc-editor.org/info/rfc9938>.

Authors' Addresses

   Carlos J. Bernardos (editor)
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   28911 Leganes Madrid
   Spain
   Phone: +34 91624 6235
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc

   Luis M. Contreras
   Telefonica
   Spain

Bernardos, et al.        Expires 26 January 2027               [Page 15]
Internet-Draft        Multi-Domain DetNet Framework            July 2026

   Email: luismiguel.contrerasmurillo@telefonica.com

   Quan Xiong
   ZTE Corporation
   China
   Email: xiong.quan@zte.com.cn

   Alain Mourad
   InterDigital Europe
   Email: Alain.Mourad@InterDigital.com
   URI:   http://www.InterDigital.com/

Bernardos, et al.        Expires 26 January 2027               [Page 16]