<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-detnet-controller-plane-framework-15"
     ipr="trust200902"> number="9938" ipr="trust200902" obsoletes="" updates="" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="DetNet Controller Plane">A Framework for the Deterministic Networking (DetNet)
    Controller Plane</title>
    <seriesInfo name="RFC" value="9938"/>
    <author fullname="Andrew G. Malis" initials="A." surname="Malis">
      <organization>Independent</organization>
      <address>
        <email>agmalis@gmail.com</email>
      </address>
    </author>
    <author fullname="Xuesong Geng" initials="X." surname="Geng, Ed."> surname="Geng" role="editor">
      <organization>Huawei</organization>
      <address>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>
    <author fullname="Mach (Guoyi) Chen" (Guoyi)Chen" initials="M." surname="Chen"> surname="(Guoyi)Chen">
      <organization>Huawei</organization>
      <address>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>
    <author fullname="Balazs Varga" initials="B." surname="Varga">
      <organization>Ericsson</organization>
      <address>
        <email>balazs.a.varga@ericsson.com</email>
      </address>
    </author>
    <author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
      <organization abbrev="UC3M">Universidad Carlos III de Madrid</organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>

          <city>28911 Leganes,
          <city>Leganes, Madrid</city>

          <region/>

          <code/>
	  <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>
    <date month="February" year="2026"/>
    <area>RTG</area>
    <workgroup>detnet</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>This document provides a framework overview for the Deterministic
      Networking (DetNet) controller plane. Controller Plane. It discusses concepts and
      requirements for the DetNet controller plane Controller Plane, which could be the basis for a future
      solution specification.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction">
      <t>DetNet (Deterministic Networking) numbered="true" toc="default">
      <name>Introduction</name>
      <t>Deterministic Networking (DetNet) provides the ability to carry
      specified unicast or multicast data flows for real-time applications
      with extremely low packet loss rates and assured maximum end-to-end
      delivery latency. A description of the general background and concepts
      of DetNet can be found in <xref target="RFC8655"/>.</t> target="RFC8655" format="default"/>.</t>

<!-- [rfced] We're having trouble understanding the parentheses in
this sentence. Is the "set of documents" referring to A) all of
the subsequently listed RFCs or B) just RFC 8938? Please let us
know how we may update for clarity.

Original:
   The DetNet data plane is defined in a set of documents that are
   anchored by the DetNet data plane framework [RFC8938] (as well as the
   associated DetNet MPLS defined in [RFC8964], the DetNet IP defined in
   [RFC8939], and other data plane specifications defined in [RFC9023],
   [RFC9024], [RFC9025], [RFC9037], and [RFC9056]).

Perhaps A:
   The DetNet data plane is defined in a set of documents that are
   anchored by the DetNet data plane framework [RFC8938], which
   includes the associated DetNet MPLS defined in [RFC8964], the
   DetNet IP defined in [RFC8939], and other data plane specifications
   defined in [RFC9023], [RFC9024], [RFC9025], [RFC9037], and
   [RFC9056].

or
Perhaps B:
   The DetNet data plane is defined in the DetNet data plane framework
   [RFC8938] (and is further explained in the associated DetNet MPLS
   [RFC8964], the DetNet IP [RFC8939], and other data plane
   specifications [RFC9023] [RFC9024] [RFC9025] [RFC9037] [RFC9056]).
-->

      <t>The DetNet data plane is defined in a set of documents that are anchored
      by the DetNet Data Plane Framework data plane framework <xref target="RFC8938"/> (and target="RFC8938" format="default"/> (as well as the
      associated DetNet MPLS defined in <xref target="RFC8964"/> and target="RFC8964" format="default"/>, the DetNet IP
      defined in <xref target="RFC8939"/> target="RFC8939" format="default"/>, and other data plane specifications
      defined in <xref target="RFC9023"/>, target="RFC9023" format="default"/>, <xref target="RFC9024"/>, target="RFC9024" format="default"/>, <xref
      target="RFC9025"/>, target="RFC9025" format="default"/>, <xref target="RFC9037"/> target="RFC9037" format="default"/>, and <xref
      target="RFC9056"/>).</t> target="RFC9056" format="default"/>).</t>
      <t>Note that in the DetNet overall architecture, the controller plane
      includes what are more traditionally considered separate control and
      management planes (see section 4.4.2 of <xref target="RFC8655"/>). target="RFC8655" section="4.4.2"/>). Traditionally, the management plane is primarily
      involved with fault management, configuration management management, and performance
      management (sometimes accounting management and security management is are
      also considered in the management plane (see section 4.2 of <xref (<xref target="RFC6632" />), section="4.2"/>) but not in they are out of the scope of this
      document), while
      document). At the same time, the control plane is primarily responsible for the
      instantiation and maintenance of flows, MPLS label allocation and
      distribution, and active in-band or out-of-band signaling to support
      DetNet functions. In the DetNet architecture, all of this functionality
      is combined into a single controller plane. See Section 4.4.2 of <xref
      target="RFC8655"/> target="RFC8655" section="4.4.2"/> and the aggregation of control and management planes
      in <xref target="RFC7426"/> target="RFC7426" format="default"/> for further details.</t>
      <t>While the DetNet Architecture architecture and Data Plane data plane documents are primarily
      concerned with data plane operations, they do contain some requirements, requirements and considerations
      for functions that would be required in order to automate DetNet service
      provisioning and monitoring via a DetNet controller plane Controller Plane (e.g., section 4 of see <xref target="RFC8938"/>). target="RFC8938" section="4"/>). The purpose
      of this document is to take these requirements and considerations into a single document
      and extend and discuss how various possible DetNet controller plane Controller Plane architectures
      could be used to satisfy these requirements, while not providing the
      protocol details for a DetNet controller plane Controller Plane solution. Such controller
      plane protocol solutions will be the subject of subsequent
      documents. Therefore, this document should be considered as the authoritative reference to be considered if/when protocol work on the DetNet controller plane Controller Plane starts.</t>
    </section>
    <section anchor="requirements"
             title="DetNet numbered="true" toc="default">
      <name>DetNet Controller Plane Requirements"> Requirements</name>
      <t>Other DetNet documents, including <xref target="RFC8655"/> , target="RFC8655" format="default"/>, <xref
      target="RFC8938"/>, target="RFC8938" format="default"/>, <xref target="RFC9551"/> target="RFC9551" format="default"/>, and <xref target="RFC9055"/>, target="RFC9055" format="default"/>, among others, contain requirements for the Controller Plane. controller plane. For
      convenience, these requirements have been compiled here. These
      requirements have been organized into 3 groups three groups: 1) requirements
      primarily applicable to the control plane, 2) requirements primarily applicable
      to the management plane plane, and 3) requirements applicable to both planes. In addition, security
   requirements for the DetNet Controller Plane have been discussed in <xref target="RFC9055"/>, target="RFC9055" format="default"/>, and a summary of those requirements is provided in
   Section 2.4.

<!-- [rfced] We note that RFC 9055 and this document do not contain
"Section 2.4". Please clarify if Section 2.3 of this document was
perhaps intended.

Current:
   In addition, security requirements for the DetNet Controller Plane
   have been discussed in [RFC9055], and a summary of those requirements
   is provided in Section 2.4.

Perhaps:
   In addition, security requirements for the DetNet Controller Plane
   have been discussed in [RFC9055], and a summary of those requirements
   is provided in Section 2.3 of this document.
-->

For the sake of clarity, when applicable, the document where in which the requirements originally appears appear is referenced.</t>
      <section anchor="detnet-control-plane-requirements"
               title="DetNet numbered="true" toc="default">
        <name>DetNet Control Plane Requirements"> Requirements</name>
        <t>The primary requirements for the DetNet Control Plane include:</t>

        <t><list style="symbols"> are as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Support the dynamic instantiation, modification, and deletion of
            DetNet flows. This may include some or all of explicit path
            determination, link bandwidth reservations, restricting restriction of flows to
            specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN)
            links), node buffer and other resource reservations, specification
            of required queuing disciplines along the path, the ability to manage
            bidirectional flows, etc., as needed for a flow <xref target="RFC8938"/>.</t> target="RFC8938" format="default"/>.</t>
          </li>
          <li>
            <t>Support DetNet flow aggregation and de-aggregation via the
            ability to dynamically create and delete flow aggregates (FAs), (FAs)
            and be able to modify existing FAs by adding or deleting
            participating flows <xref target="RFC8938"/>.</t> target="RFC8938" format="default"/>.</t>
          </li>
          <li>
            <t>Allow flow instantiation requests to originate in an end
            application (via an Application Programming Interface (API), (API) via
            static provisioning, provisioning or via a dynamic control plane, such as an
            SDN (Software-Defined Networking) a
            Software-Defined Networking (SDN) controller or distributed signaling protocols. protocols). See
            <xref target="control-plane-architecture"/> target="control-plane-architecture" format="default"/> for further discussion
            of these options.</t>

            <t>In
          </li>
          <li>
            <t>Manage, in the case of the DetNet MPLS data plane, manage DetNet
            Service Label (S-Label), Forwarding Label (F-Label), and
            Aggregation Label (A-Label) <xref target="RFC8964"/> target="RFC8964" format="default"/> allocation
            and distribution <xref target="RFC8938"/>.</t>

            <t>Also target="RFC8938" format="default"/>.</t>
          </li>
          <li>
            <t>Support, also in the case of the DetNet MPLS data plane, support the
            DetNet service sub-layer, which provides DetNet service functions functions,
            such as protection and reordering through the use of packet
            replication, elimination, Packet
            Replication, Elimination, and ordering functions Ordering Functions
            (PREOF) <xref target="RFC8655"/>.</t> target="RFC8655" format="default"/>.</t>
          </li>
          <li>
            <t>Support the queue control techniques defined in Section 4.5 of
            <xref target="RFC8655"/> target="RFC8655" section="4.5" sectionFormat="comma"/> and <xref target="RFC9320"/> target="RFC9320" format="default"/> that require
            time synchronization among the network data plane nodes.</t>
          </li>
          <li>
            <t>Advertise static and dynamic node and link characteristics characteristics, such
            as capabilities and adjacencies to other network nodes (for
            dynamic signaling approaches) or to network controllers (for
            centralized approaches) <xref target="RFC8938"/>.</t> target="RFC8938" format="default"/>.</t>
          </li>
          <li>
            <t>Scale to handle the number of DetNet flows expected in a domain
            (which may require per-flow signaling or provisioning) <xref target="RFC8938"/>.</t> target="RFC8938" format="default"/>.</t>
          </li>
          <li>
            <t>Provision flow identification information at each of the nodes
            along the path. Flow identification may differ depending on the
            location in the network and the DetNet functionality (e.g., transit
            node vs. relay node) <xref target="RFC8938"/>.</t>
          </list></t> target="RFC8938" format="default"/>.</t>
          </li>
        </ul>
      </section>
      <section anchor="detnet-management-plane-requirements"
               title="DetNet numbered="true" toc="default">
        <name>DetNet Management Plane Requirements"> Requirements</name>
        <t>The primary requirements of for the DetNet management plane are that it
        must be able to:</t>

        <t><list style="symbols"> as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Monitor the performance of DetNet flows and nodes to ensure
            that they are meeting required objectives, both proactively and
            on-demand
            on demand <xref target="RFC9551"/>.</t> target="RFC9551" format="default"/>.</t>
          </li>
          <li>
            <t>Support DetNet flow continuity check and connectivity
            verification functions <xref target="RFC9551"/>.</t> target="RFC9551" format="default"/>.</t>
          </li>
          <li>
            <t>Support testing and monitoring of packet replication, duplicate
            elimination, and packet ordering functionality in the DetNet
            domain <xref target="RFC9551"/>.</t>
          </list></t> target="RFC9551" format="default"/>.</t>
          </li>
        </ul>
      </section>
      <section anchor="requirements-for-both-planes"
               title="Requirements For numbered="true" toc="default">
        <name>Requirements for Both Planes"> Planes</name>
        <t>The following requirements apply to both the DetNet control and
        management planes:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Operate in a converged network domain that contains both DetNet
            and non-DetNet flows <xref target="RFC8655"/>.</t> target="RFC8655" format="default"/>.</t>
          </li>
          <li>
            <t>Adapt to DetNet domain topology changes such as links link or nodes node
            failures (fault recovery/restoration), additions additions, and removals <xref target="RFC8655"/>.</t>
          </list></t> target="RFC8655" format="default"/>.</t>
          </li>
        </ul>
        <t>In addition to the above, the DetNet controller Controller Plane should also satisfy security requirements derived from <xref target="RFC9055"/>, target="RFC9055" format="default"/>,
   which defines the security framework for DetNet. The following
   requirements are especially relevant:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Integrity and authenticity of control/signaling packets: The controller plane should ensure that signaling and control messages cannot be modified or injected by unauthorized entities and should prevent spoofing and segmentation attacks.</t>
          </li>
          <li>
            <t>Protection against controller compromise: Mechanisms should exist to verify the legitimacy of controllers and to prevent unauthorized components from impersonating them.</t>
          </li>
          <li>
            <t>System-wide security design: The architecture must account for the possibility of compromised nodes or controllers, ensuring resilience so that the failure or subversion of a single component does not cause catastrophic impact.</t>
          </li>
          <li>
            <t>Timely delivery of control plane messages: The controller plane should ensure that control and signaling messages are delivered without undue delay to prevent disruption of DetNet services without resource leakage.</t>
          </list></t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="control-plane-architecture"
             title="DetNet numbered="true" toc="default">
      <name>DetNet Control Plane Architecture"> Architecture</name>
      <t>As noted in the Introduction, <xref target="introduction" format="title"/>, the DetNet control plane Control Plane is responsible
      for the instantiation and maintenance of flows, the allocation and
      distribution of flow related flow-related information (e.g., MPLS label), and active
      in-band or out-of-band information distribution to support these
      functions.</t>
      <t>The following sections define three types of DetNet control plane Control Plane
      architectures: 1) a fully distributed control plane utilizing dynamic
      signaling protocols, 2) a fully centralized SDN-like control plane, and 3) a
      hybrid control plane containing both distributed protocols and
      centralized controlling. This document describes the various
      information exchanges between entities in the network for each type of
      these architectures and the corresponding advantages and
      disadvantages.</t>

      <t>In each of
      <t>The examples in the following sections, there are examples to sections illustrate
      possible mechanisms that could be used in each type of the
      architectures. They are not meant to be exhaustive or to preclude any
      other possible mechanism that could be used in place of those used in
      the examples.</t>
      <section anchor="distributed-control-plane"
               title="Distributed numbered="true" toc="default">
        <name>Distributed Control Plane and Signaling Protocols"> Protocols</name>
        <t>In a fully distributed configuration model, User-to-Network the User-Network
        Interface (UNI) information is transmitted over a DetNet UNI protocol
        from the user side to the network side. Then Then, the UNI and network
        configuration information propagate propagates in the network via distributed
        control plane signaling protocols. Such a DetNet UNI protocol is not
        necessary when the End-systems end systems are DetNet capable.</t>
        <t>Taking an RSVP-TE <xref target="RFC3209"/> target="RFC3209" format="default"/> MPLS network as an example, where end systems are
        not part of the DetNet domain:</t>

        <t><list style="numbers">
        <ol spacing="normal" type="1">
	  <li>
            <t>Network nodes collect topology information and DetNet
            capabilities of the network nodes through IGP;</t> IGP.</t>
          </li>
          <li>
            <t>The ingress edge node receives a flow establishment request from
            the UNI and calculates one or more valid path(s);</t> paths.</t>
          </li>
          <li>
            <t>The ingress node sends a PATH message with an explicit route
            through RSVP-TE. After receiving the PATH
            message, the egress edge node sends a RESV message with the
            distributed label and resource reservation request.</t>
          </list>
          </li>
        </ol>
        <t> In this example, both the IGP and RSVP-TE may require extensions
        for DetNet.</t>
      </section>
      <section anchor="sdnfully-centralized-control-plane"
               title="SDN/Fully numbered="true" toc="default">

<!-- [rfced] We note "SDN/Fully Centralized" vs. "fully
SDN/centralized". May we remove the slashes and rephrase using
"and" for clarity as shown below? Please let us know if this
retains the intended meaning or if you prefer otherwise.

Original:
3.2.  SDN/Fully Centralized Control Plane">
        <t>In Plane

   In the fully SDN/centralized configuration model, flow/UNI
   information is transmitted from a centralized user controller or from
   applications via an API/ northbound interface to a centralized
   controller.

Perhaps:
3.2.  SDN and Fully Centralized Control Plane

   In the SDN and fully centralized configuration model, both flow and
   UNI information can be transmitted from a centralized user
   controller or from other applications, via an API or northbound
   interface, to a centralized controller.
-->

        <name>SDN/Fully Centralized Control Plane</name>
        <t>In the fully SDN/centralized configuration model, flow/UNI
        information is transmitted either from a centralized user controller or from
        applications via an API/northbound interface to a centralized
        controller.

<!--[rfced] How may we clarify/expand the first mention of "PCE-CC"?
Perhaps "PCE-based central controller (PCE-CC)"?

Original:
   Network node configurations for DetNet flows are performed by the
   controller using a protocol such as NETCONF [RFC6241], YANG
   [RFC6020] [RFC7950], DetNet YANG [RFC9633], or PCE-CC [RFC8283].

Perhaps:
   Network node configurations for DetNet flows are performed by the
   controller using a protocol such as NETCONF [RFC6241], YANG
   [RFC6020] [RFC7950], DetNet YANG [RFC9633], or a PCE-based central
   controller (PCE-CC) [RFC8283].
-->

	Network node configurations for DetNet flows are
        performed by the controller using a protocol such as NETCONF
        <xref target="RFC6241" format="default"/>, YANG <xref target="RFC6241"/>/YANG target="RFC6020" format="default"/> <xref target="RFC6020"/><xref target="RFC7950"/> target="RFC7950" format="default"/>, DetNet YANG <xref
        target="RFC9633"/> target="RFC9633" format="default"/>, or PCE-CC <xref target="RFC8283"/>.</t> target="RFC8283" format="default"/>.</t>
        <t>Take the following case as an example:</t>

        <t><list style="numbers">
        <ol spacing="normal" type="1">
	  <li>
            <t>A centralized controller collects topology information and
            DetNet capabilities of the network nodes via NETCONF/YANG;</t> NETCONF/YANG.</t>
          </li>
          <li>
            <t>The controller receives a flow establishment request from a UNI
            and calculates one or more valid path(s) paths through the network;</t> network.</t>
          </li>
          <li>
            <t>The controller chooses the optimal path and configures the
            devices along that path for DetNet flow transmission via
            PCE-CC.</t>
          </list></t>

        <t>Protocols
          </li>
        </ol>
        <t>The protocols in the above example may require extensions for
        DetNet.</t>
      </section>
      <section anchor="combined-control-plane-partly-centralized-partly-distributed"
               title="Hybrid numbered="true" toc="default">
        <name>Hybrid Control Plane (partly centralized, partly distributed)"> (Partly Centralized and Partly Distributed)</name>
        <t>In the hybrid model, the controller and control plane protocols work
        together to provide DetNet services, and there are a number of
        possible combinations.</t>
        <t>In the following case, the RSVP-TE and controller are used
        together:</t>

        <t><list style="numbers">
        <ol spacing="normal" type="1">
	  <li>
            <t>A controller collects topology information and DetNet
            capabilities of the network nodes via an IGP and/or BGP-LS <xref
            target="RFC9552"/>;</t> the Border Gateway Protocol - Link State (BGP-LS) <xref target="RFC9552" format="default"/>.</t>
          </li>
          <li>
            <t>A controller receives a flow establishment request through API
            and calculates one or more valid path(s) paths through the network;</t> network.</t>
          </li>
          <li>
            <t>Based on the calculation result, the controller distributes
            flow path information to the ingress edge node and configures
            network nodes along the path with necessary DetNet information
            (e.g., for replication/duplicate elimination)</t> elimination).</t>
          </li>
          <li>
            <t>Using RSVP-TE, the ingress edge node sends a PATH message with
            an explicit route. After receiving the PATH message, the egress
            edge node sends a RESV message with the distributed label and
            resource reservation request.</t>
          </list></t>
          </li>
        </ol>
        <t>There are many other variations that could be included in a hybrid
        control plane. The requested DetNet extensions for a protocol in each
        possible case is for future work.</t>
      </section>
    </section>
    <section anchor="detnet-control-plane-additional-details-and-issues"
             title="DetNet numbered="true" toc="default">
      <name>DetNet Control Plane for DetNet Mechanisms"> Mechanisms</name>
      <t>This section discusses the requested control plane features for DetNet
      mechanisms as defined in <xref target="RFC8655"/>, target="RFC8655" format="default"/>, including explicit
      path, resource reservation, service protection (PREOF). PREOF. Different DetNet
      services may implement any or all of these based on the requirements.</t>
      <section anchor="explicit-paths" title="Explicit Paths"> numbered="true" toc="default">
        <name>Explicit Paths</name>
        <t>Explicit paths are required in DetNet to provide a stable
        forwarding service and guarantee that the DetNet service is not impacted
        when the network topology changes. The following features are
        necessary in the control plane to implement explicit paths in DetNet:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Path computation: DetNet explicit paths need to meet the SLA
            (Service
            Service Level Agreement) Agreement (SLA) requirements of the application, which
            include bandwidth, maximum end- to-end end-to-end delay, maximum end-to-end
            delay variation, maximum loss ratio, etc. In a distributed network
            system, an IGP with CSPF (Constrained Constrained Shortest Path First) First (CSPF) may be
            used to compute a set of feasible paths for a DetNet service. In a
            centralized network system, the controller can compute paths
            satisfying the requirements of DetNet based on the network
            information collected from the DetNet domain.</t>
          </li>
          <li>
            <t>Path establishment: The computed path for the DetNet service
            has to be sent/configured/signaled to the network device, device so that the
            corresponding DetNet flow could can pass through the network domain
            following the specified path.</t>
          </list></t>
          </li>
        </ul>
      </section>
      <section anchor="resource-reservation" title="Resource Reservation"> numbered="true" toc="default">
        <name>Resource Reservation</name>
        <t>DetNet flows are supposed to be protected from congestion, so
        sufficient resource reservation for a DetNet service could protect
        a service from congestion. There are multiple types of resources in the
        network that could be allocated to DetNet flows, e.g., packet
        processing resources, buffer resources, and the bandwidth of the output
        port. The network resource requested by a specified DetNet service is
        determined by the SLA requirements and network capability.</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Resource Allocation: Port bandwidth is one of the basic
            attributes of a network device which that is easy to obtain or
            calculate. In current traffic engineering implementations, network
            resource allocation is synonymous with bandwidth allocation.

<!--[rfced] FYI: Per RFC 9016, we updated "Maximum Packets Per
Interval" and "Maximum Payload Size" to "MaxPacketsPerInterval"
and "MaxPayloadSize", respectively. Please let us know if this is
incorrect.

Original:
   A DetNet flow is characterized with a traffic specification as
   defined in <xref target="RFC9016"/>, [RFC9016], including attributes such as Interval,
   Maximum Packets Per Interval, and Maximum Payload Size.

Current:
   A DetNet flow is characterized with a traffic specification as
   defined in [RFC9016], including attributes such as Interval,
   MaxPacketsPerInterval, and MaxPayloadSize.
-->
	    A
            DetNet flow is characterized by a traffic specification, as
            defined in <xref target="RFC9016" format="default"/>, including attributes such as
            Interval, MaxPacketsPerInterval, and MaxPayloadSize.
            The traffic specification describes the worst case, rather than
            the average case, for the traffic, traffic to ensure that sufficient
            bandwidth and buffering resources are reserved to satisfy the
            traffic specification. However, in the case of DetNet, resource
            allocation is more than simple bandwidth reservation. For example,
            allocation of buffers and required queuing disciplines during
            forwarding may be required as well. Furthermore, resources must be
            ensured to execute DetNet service sub-layer functions on the node,
            such as protection and reordering through the use of packet
            replication, duplicate elimination, and packet ordering functions
            (PREOF).</t> PREOF.</t>
          </li>
          <li>
            <t>Device configuration with or without flow discrimination: The
            resource allocation can be guaranteed by device configuration. For
            example, an output port bandwidth reservation can be configured as
            a parameter of queue management and the port scheduling algorithm.
            When DetNet flows are aggregated, a group of DetNet flows share
            the allocated resource in the network device. When the DetNet
            flows are treated independently, the device should maintain a
            mapping relationship between a DetNet flow and its corresponding
            resources.</t>
          </list></t>
          </li>
        </ul>
      </section>
      <section anchor="preof-support" title="PREOF Support"> numbered="true" toc="default">
        <name>PREOF Support</name>
        <t>DetNet path redundancy is supported via packet replication,
        duplicate elimination, Packet Replication,
        Elimination, and packet ordering functions Ordering Functions (PREOF). A DetNet
        flow is replicated and forwarded by multiple networks paths to avoid
        packet loss caused by device or link failures. In general, current
        control plane mechanisms that can be used to establish an explicit
        path, whether distributed or centralized, support point-to-point (P2P)
        and point-to-multipoint (P2MP) path establishment. PREOF requires the
        ability to compute and establish a set of multiple paths (e.g.,
        multiple LSP Label Switched Path (LSP) segments in an MPLS network) from the point(s) of packet
        replication to the point(s) of packet merging and ordering.

<!-- [rfced] Are the parentheses around "member" essential to the
sentence, or may we remove them?

Current:
   Mapping of DetNet (member) flows to explicit path segments has to
   be ensured as well.

Perhaps:
   Mapping of DetNet member flows to explicit path segments has to be
   ensured as well.
-->

Mapping of
        DetNet (member) flows to explicit path segments has to be ensured as
        well. Protocol extensions will be required to support these new
        features. Terminology will also be required to refer to this
        coordinated set of path segments (such as an 'LSP graph' "LSP graph"
        in the case of the DetNet MPLS data plane).</t>
      </section>
      <section anchor="dp-specific" title="Data Plane specific considerations"> numbered="true" toc="default">
        <name>Data-Plane-Specific Considerations</name>
        <section anchor="traditional-mpls" title="DetNet numbered="true" toc="default">
          <name>DetNet in an MPLS Domain"> Domain</name>
          <t>For the purposes of this document, 'traditional MPLS' "traditional MPLS"
          is defined as MPLS without the use of segment routing (see <xref
          target="SR"/> target="SR" format="default"/> for a discussion of MPLS with segment routing) or
          MPLS-TP
          MPLS Transport Profile (MPLS-TP) <xref target="RFC5960"/>.</t> target="RFC5960" format="default"/>.</t>
          <t>In traditional MPLS domains, a dynamic control plane using
          distributed signaling protocols is typically used for the
          distribution of MPLS labels used for forwarding MPLS packets.

<!--[rfced] Please clarify if "BGP/MPLS-based" means "BGP and
MPLS-based" (option A) or "BGP-based and MPLS-based" (option B)
in the following.

Current:
   The dynamic signaling protocols most commonly used for label
   distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277]
   (which enables BGP/MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs
   [RFC4664], and EVPNs [RFC7432]).

Perhaps A:
   The dynamic signaling protocols most commonly used for label
   distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277]
   (which enables BGP and MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs
   [RFC4664], and EVPNs [RFC7432]).

or
Perhaps B:
   The dynamic signaling protocols most commonly used for label
   distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277]
   (which enables BGP-/MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs
   [RFC4664], and EVPNs [RFC7432]).
-->

	  The
          dynamic signaling protocols most commonly used for label
          distribution are LDP <xref target="RFC5036" format="default"/>, RSVP-TE <xref target="RFC5036"/>, RSVP-TE<xref target="RFC4875"/>, target="RFC4875" format="default"/>, and BGP
          <xref target="RFC8277"/> target="RFC8277" format="default"/> (which enables BGP/MPLS-based Layer 3 VPNs
          <xref target="RFC4384"/> target="RFC4384" format="default"/>, Layer 2 VPNs <xref
          target="RFC4664"/> target="RFC4664" format="default"/>, and EVPN EVPNs <xref
          target="RFC7432"/>).</t> target="RFC7432" format="default"/>).</t>
          <t>Any of these protocols could be used to distribute DetNet Service
          Labels (S-Labels) and Aggregation Labels (A-Labels) <xref
          target="RFC8964"/>. target="RFC8964" format="default"/>. As discussed in <xref target="RFC8938"/>, target="RFC8938" format="default"/>,
          S-Labels are similar to other MPLS service labels, such as
          pseudowire,
          pseudowire and L3 VPN, VPN and L2 VPN labels, and could be distributed in a
          similar manner, such as through the use of targeted LDP or BGP. If
          these were to be used for DetNet, they would require extensions to
          support DetNet-specific features features, such as PREOF, aggregation
          (A-Labels), node resource allocation, and queue placement.</t>
        </section>
        <section anchor="detnet-in-an-ip-domain"
                 title="DetNet numbered="true" toc="default">
          <name>DetNet in an IP Domain"> Domain</name>

<!-- [rfced] Section 4.4.2: This section states that it will "discuss
possible protocol extensions to existing IP routing protocols";
however, it does not appear to do that. Please review and let us
know if content should be added to this section or if it should
be rephrased for clarity.

Current:
   For the purposes of this document, "traditional IP" is defined as IP
   without the use of segment routing (see Section 4.4.3 for a
   discussion of IP with segment routing).  This section will discuss
   possible protocol extensions to existing IP routing protocols.  It
   should be noted that a DetNet IP data plane [RFC8939] is simpler than
   a DetNet MPLS data plane [RFC8964] and doesn't support PREOF, so only
   one path per flow or flow aggregate is required.
-->

          <t>For the purposes of this document, 'traditional IP' "traditional IP"
          is defined as IP without the use of segment routing (see <xref
          target="SR"/> target="SR" format="default"/> for a discussion of IP with segment routing). This
          section will discuss possible protocol extensions to existing IP
          routing protocols. It should be noted that a DetNet IP data plane
          <xref target="RFC8939"/> target="RFC8939" format="default"/> is simpler than a DetNet MPLS data plane
          <xref target="RFC8964"/>, target="RFC8964" format="default"/> and doesn't support PREOF, so only one
          path per flow or flow aggregate is required.</t>
        </section>
        <section anchor="SR" title="DetNet numbered="true" toc="default">
          <name>DetNet in a Segment Routing Domain"> Domain</name>
          <t>Segment Routing <xref target="RFC8402"/> target="RFC8402" format="default"/> is a scalable approach
          to building network domains that provides explicit routing via
          source routing encoded in packet headers headers, and it is combined with
          centralized network control to compute paths through the network.
          Forwarding paths are distributed with associated policy policies to network
          edge nodes for use in packet headers. Segment Routing reduces
          the amount of network signaling associated with distributed
          signaling protocols protocols, such as RSVP-TE, and also reduces the amount of
          state in core nodes compared with that required for traditional MPLS
          and IP routing, as the state is now in the packets rather than in
          the routers. This could be useful for DetNet, where a very large
          number of flows through a network domain are expected, which would
          otherwise require the instantiation of state for each flow
          traversing each node in the network.</t>
          <t>Note that the DetNet MPLS and IP data planes described in <xref
          target="RFC8964"/> target="RFC8964" format="default"/> and <xref target="RFC8939"/> target="RFC8939" format="default"/> were constructed to
          be compatible with both types of segment routing, SR-MPLS routing: Segment Routing over MPLS (SR-MPLS) <xref
          target="RFC8660"/> target="RFC8660" format="default"/> and SRv6 Segment Routing over IPv6 (SRv6) <xref target="RFC8754"/> target="RFC8754" format="default"/> <xref target="RFC8986"/>.</t> target="RFC8986" format="default"/>.</t>
        </section>
      </section>
      <section anchor="encapsulation-support" title="Encapsulation numbered="true" toc="default">
        <name>Encapsulation and metadata support"> Metadata Support</name>
        <t>To effectively manage DetNet flows, the controller plane will need to have a clear understanding of the encapsulation and metadata capabilities of the underlying network nodes. This will require a control mechanism that can discover, configure, and manage these parameters for each flow.</t>
        <t>The controller plane needs to understand and manage the encapsulation and metadata capabilities of the network nodes to provision DetNet flows effectively. This process might need a discovery phase, phase in which the controller discovers which encapsulation types (e.g., MPLS, IP) and metadata schemes (e.g., sequencing, timestamping) that each node supports. After discovery, the controller might instruct nodes on the specific encapsulation and companion metadata to apply for a given flow. This ensures that DetNet packets are handled consistently across the network. For example, the controller might instruct a node to use an MPLS header and add a sequence number for a particular flow.
        </t>
      </section>
    </section>
    <section anchor="management-plane-overview"
             title="Management numbered="true" toc="default">
      <name>Management Plane Overview"> Overview</name>
      <t>The management plane includes the ability to statically provision
      network nodes and to use OAM Operations, Administration, and Maintenance (OAM) to monitor DetNet performance and to detect
      outages or other issues at the DetNet layer.</t>
      <section anchor="detnet-operations-administration-and-maintenance-oam"
               title="DetNet numbered="true" toc="default">
        <name>DetNet Operations, Administration Administration, and Maintenance (OAM)"> (OAM)</name>
        <t>This document covers the general considerations for OAM.</t>
        <section anchor="oam-for-performance-monitoring-pm"
                 title="OAM numbered="true" toc="default">
          <name>OAM for Performance Monitoring (PM)"> (PM)</name>
          <section anchor="active-pm" title="Active PM"> numbered="true" toc="default">
            <name>Active PM</name>
            <t>Active PM is performed by injecting OAM packets into the
            network to estimate the performance of the network and by then measuring
            the performance of the those OAM packets. Adding extra traffic can
            affect the delay and throughput performance of the network, and
            for this reason active reason, Active PM is not recommended for use in
            operational DetNet domains. However, it is a useful test tool when
            commissioning a new network or during troubleshooting.</t>
          </section>
          <section anchor="passive-pm" title="Passive PM"> numbered="true" toc="default">
            <name>Passive PM</name>
            <t>Passive PM, such as IOAM In Situ Operations, Administration, and Maintenance (IOAM) <xref target="RFC9197"/>, target="RFC9197" format="default"/>, monitors the actual service traffic in a network
            domain in order to measure its performance without having a
            detrimental effect on the network. As compared to Active PM,
            Passive PM is much preferred for use in DetNet domains.</t>
          </section>
        </section>
        <section anchor="oam-for-connectivity-and-faultdefect-management-cfm"
                 title="OAM numbered="true" toc="default">
          <name>OAM for Connectivity and Fault/Defect Fault Management (CFM)"> (CFM)</name>
          <t>The detailed requirements for connectivity and fault/defect
          detection and management CFM
          in a DetNet IP domain and a DetNet MPLS domain
          are defined in <xref target="RFC9551"/> target="RFC9551" format="default"/>, <xref target="RFC9634"/> target="RFC9634" format="default"/>, and <xref target="RFC9546"/>, target="RFC9546" format="default"/>, respectively.</t>
        </section>
      </section>
    </section>
    <section title="Multidomain Aspects">
      <t>When numbered="true" toc="default">
      <name>Multi-Domain Aspects</name>

<!-- [rfced] We're having trouble parsing how "one ... controller
plane function" can "collaborate". How may we update for clarity?
Note that we updated the capitalization of the expansions for CPF
and FME to match RFC 8655.

Current:
   When there are multiple domains involved, one or multiple controller
      plane functions (CPF) Controller
   Plane Functions (CPFs) would have to collaborate to implement the
   requests received from the flow management entity (FME, Flow Management Entity (FME) [RFC8655] as defined
   per-flow, per-hop behaviors installed in the DetNet nodes for each
   individual flow.

Perhaps A:
   When there are multiple domains involved, multiple Controller
   Plane Functions (CPFs) would have to collaborate to implement the
   requests received from the Flow Management Entity (FME) [RFC8655] as
   per-flow, per-hop behaviors installed in the DetNet nodes for each
   individual flow.

or
Perhaps B:
   When there are multiple domains involved, one Controller Plane
   Function (CPF) (or multiple CPFs in collaboration) would have to
   implement the requests received from the Flow Management Entity
   (FME) [RFC8655] as per-flow, per-hop behaviors installed in the
   DetNet nodes for each individual flow.
-->

      <t>When there are multiple domains involved, one or multiple Controller
      Plane Functions (CPFs) would have to collaborate to implement the
      requests received from the Flow Management Entity (FME)
      <xref target="RFC8655"/>) target="RFC8655" format="default"/> as per-flow, per-hop behaviors installed in
      the DetNet nodes for each individual flow. Adding multi-domain support
      might require some support at the CPF. For example, CPFs of different
      domains, e.g., PCEs PCEs, need to discover each other, other and then authenticate and
      negotiate per-hop behaviors.

<!--[rfced] We rephrased the following text to expand "RAW" and to
avoid hyphenating "RAW-specific functions". Please let us know if
this retains the intended meaning.

Original:
   Furthermore, in the case of wireless domains, the per-domain RAW <xref target="I-D.ietf-raw-architecture"/>
   [I-D.ietf-raw-architecture] specific functions like the PLR (Point
   of Local Repair)s Repairs have to be also considered, e.g., in addition to
   the PCEs.

Current:
   Furthermore, in the case of wireless domains, per-domain functions
   specific to Reliable and Available Wireless (RAW) [RAW-ARCH], such
   as Point of Local Repairs (PLRs), have to also be considered, e.g.,
   in addition to the PCEs.
-->

      Furthermore, in the case of wireless domains,
      per-domain functions specific to Reliable and Available Wireless (RAW) <xref target="I-D.ietf-raw-architecture" format="default"/>, such as Point of Local Repairs (PLRs), have to also be
      considered, e.g., in addition to the PCEs. Depending on the multi-domain
      support provided by the application plane, the controller plane might be
      relieved from some responsibilities (e.g., if the application plane
      takes care of splitting what needs to be provided by each domain).</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t> IANA actions.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document provides a framework for the DetNet controller plane, Controller Plane
      and does not include any protocol specifications. Any future
      specification that is defined to support the DetNet controller plane Controller Plane is
      expected to include the appropriate security considerations. For overall
      security considerations of DetNet DetNet, see <xref target="RFC8655"/> target="RFC8655" format="default"/> and <xref
      target="RFC9055"/></t>
    </section>

    <section anchor="acknowledgments" title="Acknowledgments">
      <t>Thanks to Jim Guichard, Donald Eastlake, and Stewart Bryant for their
      review comments.</t>

      <t>Authors would also like to thank Deb Cooley, Mike Bishop, Mohamed Boucadair, Gorry Fairhurst and Dave Thaler for their comments during the different directorate and IESG reviews.</t>
    </section>

    <section title="Contributors">
      <t>Fengwei Qin</t>

      <t>China Mobile</t>

      <t>Email: qinfengwei@chinamobile.com</t> target="RFC9055" format="default"/>.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    <displayreference target="I-D.ietf-raw-architecture" to="RAW-ARCH"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9016.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9016.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9551.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9551.xml"/>
      </references>

    <references title="Informative References">
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9634.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9634.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9056.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9056.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9025.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9025.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9037.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9037.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9023.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9023.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9024.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9024.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9320.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9320.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9633.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9633.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5960.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5960.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4384.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4384.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4664.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/>

	  <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-raw-architecture"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/>

<!-- [I-D.ietf-raw-architecture]
draft-ietf-raw-architecture-30
IESG State: in AUTH48-DONE (RFC 9912) as of 02/20/26
-->
<reference anchor="I-D.ietf-raw-architecture" target="https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-30">
   <front>
      <title>Reliable and Available Wireless Architecture</title>
      <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
         <organization>Without Affiliation</organization>
      </author>
      <date month="July" day="25" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-raw-architecture-30" />

</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6632.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6632.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"
                  xmlns:xi="http://www.w3.org/2001/XInclude"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
      </references>
    </references>

    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to <contact fullname="Jim Guichard"/>, <contact
      fullname="Donald Eastlake 3rd"/>, and <contact fullname="Stewart Bryant"/>
      for their reviews and comments.</t>
      <t>The authors would also like to thank <contact fullname="Deb Cooley"/>,
      <contact fullname="Mike Bishop"/>, <contact fullname="Mohamed
      Boucadair"/>, <contact fullname="Gorry Fairhurst"/>, and <contact
      fullname="Dave Thaler"/> for their comments during the different
      directorate and IESG reviews.</t>
    </section>

    <section numbered="false" toc="default">
      <name>Contributors</name>

      <contact fullname="Fengwei Qin">
	<organization>China Mobile</organization>
	<address>
	  <email>qinfengwei@chinamobile.com</email>
	</address>
      </contact>

    </section>

  </back>

 <!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how
they may be made consistent.

 Segment Routing vs. segment routing
   (not including "Segment Routing over MPLS" or "Segment Routing over IPv6")

b) Note that we updated the text to reflect the forms on the right for
consistency. Please let us know if any further changes are needed.

 Controller Plane -> controller plane (per RFCs 9016 and 9055)
 Data Plane -> data plane (per RFCs 9016, 9055, and 9551)
 DetNet Architecture -> DetNet architecture (per RFCs 8939 and 9016)
 DetNet control plane -> DetNet Control Plane (per RFC 9551)
 DetNet controller plane -> DetNet Controller Plane (per RFCs 9055 and 9551)
 DetNet Data Plane Framework -> DetNet data plane framework (per RFC 8938)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

In addition, please consider whether "tradition" should be updated for clarity.
While the NIST website <https://web.archive.org/web/20250214092458/
https://www.nist.gov/nist-research-library/nist-technical-series-publications-
author-instructions#table1> indicates that this term is potentially biased, it
is also ambiguous. "Tradition" is a subjective term, as it is not the same for
everyone.

A):
   Note that in the DetNet overall architecture, the controller plane
   includes what are more traditionally considered separate control and
   management planes (see Section 4.4.2 of [RFC8655]).

B):
   Traditionally, the management plane is primarily involved with
   fault management, configuration management, and performance
   management (sometimes accounting management and security management
   are also considered in the management plane (Section 4.2 of
   [RFC6632]) but they are not in the scope of this document).

C):
   For the purposes of this document, "traditional MPLS" is defined as
   MPLS without the use of segment routing (see Section 4.4.3 for a
   discussion of MPLS with segment routing) or MPLS-TP [RFC5960].

D):
   In traditional MPLS domains, a dynamic control plane using
   distributed signaling protocols is typically used for the
   distribution of MPLS labels used for forwarding MPLS packets.

E):
   For the purposes of this document, "traditional IP" is defined as IP
   without the use of segment routing (see Section 4.4.3 for a
   discussion of IP with segment routing).

F):
   Segment Routing reduces the amount of network signaling associated
   with distributed signaling protocols, such as RSVP-TE, and also
   reduces the amount of state in core nodes compared with that
   required for traditional MPLS and IP routing, as the state is now
   in the packets rather than in the routers.
-->

</rfc>