rfc9938xml2.original.xml   rfc9938.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 --> <!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<rfc category="info" docName="draft-ietf-detnet-controller-plane-framework-15" ]>
ipr="trust200902">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-detnet-controller-plane-framework-15" number="9938" ipr="trust200902" obsole
tes="" updates="" consensus="true" submissionType="IETF" xml:lang="en" tocInclud
e="true" sortRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="DetNet Controller Plane">A Framework for Deterministic Networ king (DetNet) <title abbrev="DetNet Controller Plane">A Framework for the Deterministic Ne tworking (DetNet)
Controller Plane</title> Controller Plane</title>
<seriesInfo name="RFC" value="9938"/>
<author fullname="Andrew G. Malis" initials="A." surname="Malis"> <author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<email>agmalis@gmail.com</email> <email>agmalis@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Xuesong Geng" initials="X." surname="Geng" role="editor">
<author fullname="Xuesong Geng" initials="X." surname="Geng, Ed.">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>gengxuesong@huawei.com</email> <email>gengxuesong@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Mach (Guoyi)Chen" initials="M." surname="(Guoyi)Chen">
<author fullname="Mach (Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Balazs Varga" initials="B." surname="Varga"> <author fullname="Balazs Varga" initials="B." surname="Varga">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>balazs.a.varga@ericsson.com</email> <email>balazs.a.varga@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos"> <author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
<organization abbrev="UC3M">Universidad Carlos III de Madrid</organization > <organization abbrev="UC3M">Universidad Carlos III de Madrid</organization >
<address> <address>
<postal> <postal>
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city>
<city>28911 Leganes, Madrid</city> <code>28911</code>
<region/>
<code/>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone>+34 91624 6236</phone> <phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email> <email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri> <uri>http://www.it.uc3m.es/cjbc/</uri>
</address> </address>
</author> </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> <abstract>
<t>This document provides a framework overview for the Deterministic <t>This document provides a framework overview for the Deterministic
Networking (DetNet) controller plane. It discusses concepts and Networking (DetNet) Controller Plane. It discusses concepts and
requirements for DetNet controller plane which could be the basis for a fu requirements for the DetNet Controller Plane, which could be the basis for
ture a future
solution specification.</t> solution specification.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<t>DetNet (Deterministic Networking) provides the ability to carry <name>Introduction</name>
<t>Deterministic Networking (DetNet) provides the ability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low packet loss rates and assured maximum end-to-end with extremely low packet loss rates and assured maximum end-to-end
delivery latency. A description of the general background and concepts delivery latency. A description of the general background and concepts
of DetNet can be found in <xref target="RFC8655"/>.</t> of DetNet can be found in <xref target="RFC8655" format="default"/>.</t>
<t>The DetNet data plane is defined in a set of documents that are anchore <!-- [rfced] We're having trouble understanding the parentheses in
d this sentence. Is the "set of documents" referring to A) all of
by the DetNet Data Plane Framework <xref target="RFC8938"/> (and the the subsequently listed RFCs or B) just RFC 8938? Please let us
associated DetNet MPLS defined in <xref target="RFC8964"/> and DetNet IP know how we may update for clarity.
defined in <xref target="RFC8939"/> and other data plane specifications
defined in <xref target="RFC9023"/>, <xref target="RFC9024"/>, <xref Original:
target="RFC9025"/>, <xref target="RFC9037"/> and <xref The DetNet data plane is defined in a set of documents that are
target="RFC9056"/>).</t> 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 anchore
d
by the DetNet data plane framework <xref target="RFC8938" format="default"
/> (as well as the
associated DetNet MPLS defined in <xref target="RFC8964" format="default"/
>, the DetNet IP
defined in <xref target="RFC8939" format="default"/>, and other data plane
specifications
defined in <xref target="RFC9023" format="default"/>, <xref target="RFC902
4" format="default"/>, <xref target="RFC9025" format="default"/>, <xref target="
RFC9037" format="default"/>, and <xref target="RFC9056" format="default"/>).</t>
<t>Note that in the DetNet overall architecture, the controller plane <t>Note that in the DetNet overall architecture, the controller plane
includes what are more traditionally considered separate control and includes what are more traditionally considered separate control and
management planes (see section 4.4.2 of <xref target="RFC8655"/>). Traditi management planes (see <xref target="RFC8655" section="4.4.2"/>). Traditio
onally, the management plane is primarily nally, the management plane is primarily
involved with fault management, configuration management and performance involved with fault management, configuration management, and performance
management (sometimes accounting management and security management is management (sometimes accounting management and security management are
also considered in the management plane (see section 4.2 of <xref target=" also considered in the management plane (<xref target="RFC6632" section="4
RFC6632" />), but not in the scope of this .2"/>) but they are out of the scope of this
document), while the control plane is primarily responsible for the document). At the same time, the control plane is primarily responsible fo
r the
instantiation and maintenance of flows, MPLS label allocation and instantiation and maintenance of flows, MPLS label allocation and
distribution, and active in-band or out-of-band signaling to support distribution, and active in-band or out-of-band signaling to support
DetNet functions. In the DetNet architecture, all of this functionality DetNet functions. In the DetNet architecture, all of this functionality
is combined into a single controller plane. See Section 4.4.2 of <xref is combined into a single controller plane. See <xref target="RFC8655" sec
target="RFC8655"/> and the aggregation of control and management planes tion="4.4.2"/> and the aggregation of control and management planes
in <xref target="RFC7426"/> for further details.</t> in <xref target="RFC7426" format="default"/> for further details.</t>
<t>While the DetNet architecture and data plane documents are primarily
<t>While the DetNet Architecture and Data Plane documents are primarily concerned with data plane operations, they do contain some requirements an
concerned with data plane operations, they do contain some requirements, a d considerations
nd considerations
for functions that would be required in order to automate DetNet service for functions that would be required in order to automate DetNet service
provisioning and monitoring via a DetNet controller plane (e.g., section 4 of <xref target="RFC8938"/>). The purpose provisioning and monitoring via a DetNet Controller Plane (e.g., see <xref target="RFC8938" section="4"/>). The purpose
of this document is to take these requirements and considerations into a s ingle document of this document is to take these requirements and considerations into a s ingle document
and extend and discuss how various possible DetNet controller plane archit ectures and extend and discuss how various possible DetNet Controller Plane archit ectures
could be used to satisfy these requirements, while not providing the could be used to satisfy these requirements, while not providing the
protocol details for a DetNet controller plane solution. Such controller protocol details for a DetNet Controller Plane solution. Such controller
plane protocol solutions will be the subject of subsequent plane protocol solutions will be the subject of subsequent
documents. Therefore, this document should be considered as the authoritat ive reference to be considered if/when protocol work on the DetNet controller pl ane starts.</t> documents. Therefore, this document should be considered as the authoritat ive reference to be considered if/when protocol work on the DetNet Controller Pl ane starts.</t>
</section> </section>
<section anchor="requirements" numbered="true" toc="default">
<section anchor="requirements" <name>DetNet Controller Plane Requirements</name>
title="DetNet Controller Plane Requirements"> <t>Other DetNet documents, including <xref target="RFC8655" format="defaul
<t>Other DetNet documents, including <xref target="RFC8655"/> , <xref t"/>, <xref target="RFC8938" format="default"/>, <xref target="RFC9551" format="
target="RFC8938"/>, <xref target="RFC9551"/> and <xref target="RFC9055"/>, default"/>, and <xref target="RFC9055" format="default"/>, among others, contain
among others, contain requirements for the Controller Plane. For requirements for the controller plane. For
convenience, these requirements have been compiled here. These convenience, these requirements have been compiled here. These
requirements have been organized into 3 groups requirements requirements have been organized into three groups: 1) requirements
primarily applicable to the control plane, requirements primarily applicab primarily applicable to the control plane, 2) requirements primarily appli
le cable
to the management plane and requirements applicable to both planes. In add to the management plane, and 3) requirements applicable to both planes. In
ition, security addition, security
requirements for the DetNet Controller Plane have been discussed in <xref tar requirements for the DetNet Controller Plane have been discussed in <xref tar
get="RFC9055"/>, and a summary of those requirements is provided in get="RFC9055" format="default"/>, and a summary of those requirements is provide
Section 2.4. For the sake of clarity, when applicable, the document where the d in
requirements originally appears is referenced.</t> Section 2.4.
<section anchor="detnet-control-plane-requirements" <!-- [rfced] We note that RFC 9055 and this document do not contain
title="DetNet Control Plane Requirements"> "Section 2.4". Please clarify if Section 2.3 of this document was
<t>The primary requirements for the DetNet Control Plane include:</t> perhaps intended.
<t><list style="symbols"> 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 in which the requirements
originally appear is referenced.</t>
<section anchor="detnet-control-plane-requirements" numbered="true" toc="d
efault">
<name>DetNet Control Plane Requirements</name>
<t>The primary requirements for the DetNet Control Plane are as follows:
</t>
<ul spacing="normal">
<li>
<t>Support the dynamic instantiation, modification, and deletion of <t>Support the dynamic instantiation, modification, and deletion of
DetNet flows. This may include some or all of explicit path DetNet flows. This may include some or all of explicit path
determination, link bandwidth reservations, restricting flows to determination, link bandwidth reservations, restriction of flows to
specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN) specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN)
links), node buffer and other resource reservations, specification links), node buffer and other resource reservations, specification
of required queuing disciplines along the path, ability to manage of required queuing disciplines along the path, the ability to manag
bidirectional flows, etc., as needed for a flow <xref target="RFC893 e
8"/>.</t> bidirectional flows, etc., as needed for a flow <xref target="RFC893
8" format="default"/>.</t>
</li>
<li>
<t>Support DetNet flow aggregation and de-aggregation via the <t>Support DetNet flow aggregation and de-aggregation via the
ability to dynamically create and delete flow aggregates (FAs), ability to dynamically create and delete flow aggregates (FAs)
and be able to modify existing FAs by adding or deleting and modify existing FAs by adding or deleting
participating flows <xref target="RFC8938"/>.</t> participating flows <xref target="RFC8938" format="default"/>.</t>
</li>
<li>
<t>Allow flow instantiation requests to originate in an end <t>Allow flow instantiation requests to originate in an end
application (via an Application Programming Interface (API), via application (via an Application Programming Interface (API) via
static provisioning, or via a dynamic control plane, such as an static provisioning or via a dynamic control plane, such as a
SDN (Software-Defined Networking) controller or distributed signalin Software-Defined Networking (SDN) controller or distributed signalin
g protocols. See g protocols). See
<xref target="control-plane-architecture"/> for further discussion <xref target="control-plane-architecture" format="default"/> for fur
ther discussion
of these options.</t> of these options.</t>
</li>
<t>In the case of the DetNet MPLS data plane, manage DetNet <li>
<t>Manage, in the case of the DetNet MPLS data plane, DetNet
Service Label (S-Label), Forwarding Label (F-Label), and Service Label (S-Label), Forwarding Label (F-Label), and
Aggregation Label (A-Label) <xref target="RFC8964"/> allocation Aggregation Label (A-Label) <xref target="RFC8964" format="default"/
and distribution <xref target="RFC8938"/>.</t> > allocation
and distribution <xref target="RFC8938" format="default"/>.</t>
<t>Also in the case of the DetNet MPLS data plane, support the </li>
DetNet service sub-layer, which provides DetNet service functions <li>
such as protection and reordering through the use of packet <t>Support, also in the case of the DetNet MPLS data plane, the
replication, elimination, and ordering functions DetNet service sub-layer, which provides DetNet service functions,
(PREOF) <xref target="RFC8655"/>.</t> such as protection and reordering through the use of Packet
Replication, Elimination, and Ordering Functions
<t>Support queue control techniques defined in Section 4.5 of (PREOF) <xref target="RFC8655" format="default"/>.</t>
<xref target="RFC8655"/> and <xref target="RFC9320"/> that require </li>
time synchronization among network data plane nodes.</t> <li>
<t>Support the queue control techniques defined in
<t>Advertise static and dynamic node and link characteristics such <xref target="RFC8655" section="4.5" sectionFormat="comma"/> and <xr
ef 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, such
as capabilities and adjacencies to other network nodes (for as capabilities and adjacencies to other network nodes (for
dynamic signaling approaches) or to network controllers (for dynamic signaling approaches) or to network controllers (for
centralized approaches) <xref target="RFC8938"/>.</t> centralized approaches) <xref target="RFC8938" format="default"/>.</
t>
</li>
<li>
<t>Scale to handle the number of DetNet flows expected in a domain <t>Scale to handle the number of DetNet flows expected in a domain
(which may require per-flow signaling or provisioning) <xref target= (which may require per-flow signaling or provisioning) <xref target=
"RFC8938"/>.</t> "RFC8938" format="default"/>.</t>
</li>
<li>
<t>Provision flow identification information at each of the nodes <t>Provision flow identification information at each of the nodes
along the path. Flow identification may differ depending on the along the path. Flow identification may differ depending on the
location in the network and the DetNet functionality (e.g., transit location in the network and the DetNet functionality (e.g., transit
node vs. relay node) <xref target="RFC8938"/>.</t> node vs. relay node) <xref target="RFC8938" format="default"/>.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="detnet-management-plane-requirements" numbered="true" toc
<section anchor="detnet-management-plane-requirements" ="default">
title="DetNet Management Plane Requirements"> <name>DetNet Management Plane Requirements</name>
<t>The primary requirements of the DetNet management plane are that it <t>The primary requirements for the DetNet management plane are as follo
must be able to:</t> ws:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Monitor the performance of DetNet flows and nodes to ensure <t>Monitor the performance of DetNet flows and nodes to ensure
that they are meeting required objectives, both proactively and that they are meeting required objectives, both proactively and
on-demand <xref target="RFC9551"/>.</t> on demand <xref target="RFC9551" format="default"/>.</t>
</li>
<li>
<t>Support DetNet flow continuity check and connectivity <t>Support DetNet flow continuity check and connectivity
verification functions <xref target="RFC9551"/>.</t> verification functions <xref target="RFC9551" format="default"/>.</t
>
</li>
<li>
<t>Support testing and monitoring of packet replication, duplicate <t>Support testing and monitoring of packet replication, duplicate
elimination, and packet ordering functionality in the DetNet elimination, and packet ordering functionality in the DetNet
domain <xref target="RFC9551"/>.</t> domain <xref target="RFC9551" format="default"/>.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="requirements-for-both-planes" numbered="true" toc="defaul
<section anchor="requirements-for-both-planes" t">
title="Requirements For Both Planes"> <name>Requirements for Both Planes</name>
<t>The following requirements apply to both the DetNet control and <t>The following requirements apply to both the DetNet control and
management planes:</t> management planes:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Operate in a converged network domain that contains both DetNet <t>Operate in a converged network domain that contains both DetNet
and non-DetNet flows <xref target="RFC8655"/>.</t> and non-DetNet flows <xref target="RFC8655" format="default"/>.</t>
</li>
<t>Adapt to DetNet domain topology changes such as links or nodes <li>
failures (fault recovery/restoration), additions and removals <xref <t>Adapt to DetNet domain topology changes such as link or node
target="RFC8655"/>.</t> failures (fault recovery/restoration), additions, and removals <xref
</list></t> target="RFC8655" format="default"/>.</t>
</li>
<t>In addition to the above, the DetNet controller Plane should also sat </ul>
isfy security requirements derived from <xref target="RFC9055"/>, <t>In addition to the above, the DetNet Controller Plane should also sat
isfy security requirements derived from <xref target="RFC9055" format="default"/
>,
which defines the security framework for DetNet. The following which defines the security framework for DetNet. The following
requirements are especially relevant:</t> requirements are especially relevant:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Integrity and authenticity of control/signaling packets: The cont <t>Integrity and authenticity of control/signaling packets: The cont
roller plane should ensure that signaling and control messages cannot be modifie roller plane should ensure that signaling and control messages cannot be modifie
d or injected by unauthorized entities and prevent spoofing and segmentation att d or injected by unauthorized entities and should prevent spoofing and segmentat
acks.</t> ion attacks.</t>
</li>
<t>Protection against controller compromise: Mechanisms should exist <li>
to verify the legitimacy of controllers and prevent unauthorized components fro <t>Protection against controller compromise: Mechanisms should exist
m impersonating them.</t> to verify the legitimacy of controllers and to prevent unauthorized components
from impersonating them.</t>
<t>System-wide security design: The architecture must acc </li>
ount for the possibility of compromised nodes or controllers, ensuring resilienc <li>
e so that the failure or subversion of a single component does not cause catastr <t>System-wide security design: The architecture must account for th
ophic impact.</t> e possibility of compromised nodes or controllers, ensuring resilience so that t
he failure or subversion of a single component does not cause catastrophic impac
<t>Timely delivery of control plane messages: The control t.</t>
ler plane should ensure control and signaling messages are delivered without und </li>
ue delay to prevent disruption of DetNet services without resource leakage.</t> <li>
</list></t> <t>Timely delivery of control plane messages: The controller plane s
hould ensure that control and signaling messages are delivered without undue del
ay to prevent disruption of DetNet services without resource leakage.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="control-plane-architecture" numbered="true" toc="default">
<section anchor="control-plane-architecture" <name>DetNet Control Plane Architecture</name>
title="DetNet Control Plane Architecture"> <t>As noted in the <xref target="introduction" format="title"/>, the DetNe
<t>As noted in the Introduction, the DetNet control plane is responsible t Control Plane is responsible
for the instantiation and maintenance of flows, allocation and for the instantiation and maintenance of flows, the allocation and
distribution of flow related information (e.g., MPLS label), and active distribution of flow-related information (e.g., MPLS label), and active
in-band or out-of-band information distribution to support these in-band or out-of-band information distribution to support these
functions.</t> functions.</t>
<t>The following sections define three types of DetNet Control Plane
<t>The following sections define three types of DetNet control plane architectures: 1) a fully distributed control plane utilizing dynamic
architectures: a fully distributed control plane utilizing dynamic signaling protocols, 2) a fully centralized SDN-like control plane, and 3)
signaling protocols, a fully centralized SDN-like control plane, and a a
hybrid control plane containing both distributed protocols and hybrid control plane containing both distributed protocols and
centralized controlling. This document describes the various centralized controlling. This document describes the various
information exchanges between entities in the network for each type of information exchanges between entities in the network for each type of
these architectures and the corresponding advantages and these architectures and the corresponding advantages and
disadvantages.</t> disadvantages.</t>
<t>The examples in the following sections illustrate
<t>In each of the following sections, there are examples to illustrate
possible mechanisms that could be used in each type of the possible mechanisms that could be used in each type of the
architectures. They are not meant to be exhaustive or to preclude any 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 other possible mechanism that could be used in place of those used in
the examples.</t> the examples.</t>
<section anchor="distributed-control-plane" numbered="true" toc="default">
<section anchor="distributed-control-plane" <name>Distributed Control Plane and Signaling Protocols</name>
title="Distributed Control Plane and Signaling Protocols"> <t>In a fully distributed configuration model, the User-Network
<t>In a fully distributed configuration model, User-to-Network
Interface (UNI) information is transmitted over a DetNet UNI protocol Interface (UNI) information is transmitted over a DetNet UNI protocol
from the user side to the network side. Then UNI and network from the user side to the network side. Then, the UNI and network
configuration information propagate in the network via distributed configuration information propagates in the network via distributed
control plane signaling protocols. Such a DetNet UNI protocol is not control plane signaling protocols. Such a DetNet UNI protocol is not
necessary when the End-systems are DetNet capable.</t> necessary when the end systems are DetNet capable.</t>
<t>Taking an RSVP-TE <xref target="RFC3209" format="default"/> MPLS netw
<t>Taking an RSVP-TE <xref target="RFC3209"/> MPLS network as an example ork as an example, where end systems are
, where end systems are
not part of the DetNet domain:</t> not part of the DetNet domain:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>
<t>Network nodes collect topology information and DetNet <t>Network nodes collect topology information and DetNet
capabilities of the network nodes through IGP;</t> capabilities of the network nodes through IGP.</t>
</li>
<li>
<t>The ingress edge node receives a flow establishment request from <t>The ingress edge node receives a flow establishment request from
the UNI and calculates one or more valid path(s);</t> the UNI and calculates one or more valid paths.</t>
</li>
<li>
<t>The ingress node sends a PATH message with an explicit route <t>The ingress node sends a PATH message with an explicit route
through RSVP-TE. After receiving the PATH through RSVP-TE. After receiving the PATH
message, the egress edge node sends a RESV message with the message, the egress edge node sends a RESV message with the
distributed label and resource reservation request.</t> distributed label and resource reservation request.</t>
</list> In this example, both the IGP and RSVP-TE may require extensio </li>
ns </ol>
<t> In this example, both the IGP and RSVP-TE may require extensions
for DetNet.</t> for DetNet.</t>
</section> </section>
<section anchor="sdnfully-centralized-control-plane" numbered="true" toc=" default">
<section anchor="sdnfully-centralized-control-plane" <!-- [rfced] We note "SDN/Fully Centralized" vs. "fully
title="SDN/Fully Centralized Control Plane"> 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
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 <t>In the fully SDN/centralized configuration model, flow/UNI
information is transmitted from a centralized user controller or from information is transmitted either from a centralized user controller or
applications via an API/ northbound interface to a centralized from
controller. Network node configurations for DetNet flows are applications via an API/northbound interface to a centralized
performed by the controller using a protocol such as NETCONF controller.
<xref target="RFC6241"/>/YANG <xref target="RFC6020"/><xref target="RFC7
950"/> DetNet YANG <xref
target="RFC9633"/> or PCE-CC <xref target="RFC8283"/>.</t>
<t>Take the following case as an example:</t> <!--[rfced] How may we clarify/expand the first mention of "PCE-CC"?
Perhaps "PCE-based central controller (PCE-CC)"?
<t><list style="numbers"> Original:
<t>A centralized controller collects topology information and Network node configurations for DetNet flows are performed by the
DetNet capabilities of the network nodes via NETCONF/YANG;</t> controller using a protocol such as NETCONF [RFC6241], YANG
[RFC6020] [RFC7950], DetNet YANG [RFC9633], or PCE-CC [RFC8283].
<t>The controller receives a flow establishment request from a UNI Perhaps:
and calculates one or more valid path(s) through the network;</t> 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="RFC6020" f
ormat="default"/> <xref target="RFC7950" format="default"/>, DetNet YANG <xref t
arget="RFC9633" format="default"/>, or PCE-CC <xref target="RFC8283" format="def
ault"/>.</t>
<t>Take the following case as an example:</t>
<ol spacing="normal" type="1">
<li>
<t>A centralized controller collects topology information and
DetNet capabilities of the network nodes via NETCONF/YANG.</t>
</li>
<li>
<t>The controller receives a flow establishment request from a UNI
and calculates one or more valid paths through the network.</t>
</li>
<li>
<t>The controller chooses the optimal path and configures the <t>The controller chooses the optimal path and configures the
devices along that path for DetNet flow transmission via devices along that path for DetNet flow transmission via
PCE-CC.</t> PCE-CC.</t>
</list></t> </li>
</ol>
<t>Protocols in the above example may require extensions for <t>The protocols in the above example may require extensions for
DetNet.</t> DetNet.</t>
</section> </section>
<section anchor="combined-control-plane-partly-centralized-partly-distribu
<section anchor="combined-control-plane-partly-centralized-partly-distribu ted" numbered="true" toc="default">
ted" <name>Hybrid Control Plane (Partly Centralized and Partly Distributed)</
title="Hybrid Control Plane (partly centralized, partly distribut name>
ed)"> <t>In the hybrid model, the controller and control plane protocols work
<t>In the hybrid model, controller and control plane protocols work
together to provide DetNet services, and there are a number of together to provide DetNet services, and there are a number of
possible combinations.</t> possible combinations.</t>
<t>In the following case, the RSVP-TE and controller are used
<t>In the following case, RSVP-TE and controller are used
together:</t> together:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>
<t>A controller collects topology information and DetNet <t>A controller collects topology information and DetNet
capabilities of the network nodes via an IGP and/or BGP-LS <xref capabilities of the network nodes via an IGP and/or the Border Gatew
target="RFC9552"/>;</t> ay Protocol - Link State (BGP-LS) <xref target="RFC9552" format="default"/>.</t>
</li>
<li>
<t>A controller receives a flow establishment request through API <t>A controller receives a flow establishment request through API
and calculates one or more valid path(s) through the network;</t> and calculates one or more valid paths through the network.</t>
</li>
<li>
<t>Based on the calculation result, the controller distributes <t>Based on the calculation result, the controller distributes
flow path information to the ingress edge node and configures flow path information to the ingress edge node and configures
network nodes along the path with necessary DetNet information network nodes along the path with necessary DetNet information
(e.g., for replication/duplicate elimination)</t> (e.g., for replication/duplicate elimination).</t>
</li>
<li>
<t>Using RSVP-TE, the ingress edge node sends a PATH message with <t>Using RSVP-TE, the ingress edge node sends a PATH message with
an explicit route. After receiving the PATH message, the egress an explicit route. After receiving the PATH message, the egress
edge node sends a RESV message with the distributed label and edge node sends a RESV message with the distributed label and
resource reservation request.</t> resource reservation request.</t>
</list></t> </li>
</ol>
<t>There are many other variations that could be included in a hybrid <t>There are many other variations that could be included in a hybrid
control plane. The requested DetNet extensions for a protocol in each control plane. The requested DetNet extensions for a protocol in each
possible case is for future work.</t> possible case is for future work.</t>
</section> </section>
</section> </section>
<section anchor="detnet-control-plane-additional-details-and-issues" numbere
<section anchor="detnet-control-plane-additional-details-and-issues" d="true" toc="default">
title="DetNet Control Plane for DetNet Mechanisms"> <name>DetNet Control Plane for DetNet Mechanisms</name>
<t>This section discusses the requested control plane features for DetNet <t>This section discusses the requested control plane features for DetNet
mechanisms as defined in <xref target="RFC8655"/>, including explicit mechanisms as defined in <xref target="RFC8655" format="default"/>, includ
path, resource reservation, service protection (PREOF). Different DetNet ing PREOF. Different DetNet
services may implement any or all of these based on the requirements.</t> services may implement any or all of these based on the requirements.</t>
<section anchor="explicit-paths" numbered="true" toc="default">
<section anchor="explicit-paths" title="Explicit Paths"> <name>Explicit Paths</name>
<t>Explicit paths are required in DetNet to provide a stable <t>Explicit paths are required in DetNet to provide a stable
forwarding service and guarantee that DetNet service is not impacted forwarding service and guarantee that the DetNet service is not impacted
when the network topology changes. The following features are when the network topology changes. The following features are
necessary in the control plane to implement explicit paths in DetNet:</t > necessary in the control plane to implement explicit paths in DetNet:</t >
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Path computation: DetNet explicit paths need to meet the SLA <t>Path computation: DetNet explicit paths need to meet the
(Service Level Agreement) requirements of the application, which Service Level Agreement (SLA) requirements of the application, which
include bandwidth, maximum end- to-end delay, maximum end-to-end include bandwidth, maximum end-to-end delay, maximum end-to-end
delay variation, maximum loss ratio, etc. In a distributed network delay variation, maximum loss ratio, etc. In a distributed network
system, an IGP with CSPF (Constrained Shortest Path First) may be system, an IGP with Constrained Shortest Path First (CSPF) may be
used to compute a set of feasible paths for a DetNet service. In a used to compute a set of feasible paths for a DetNet service. In a
centralized network system, the controller can compute paths centralized network system, the controller can compute paths
satisfying the requirements of DetNet based on the network satisfying the requirements of DetNet based on the network
information collected from the DetNet domain.</t> information collected from the DetNet domain.</t>
</li>
<li>
<t>Path establishment: The computed path for the DetNet service <t>Path establishment: The computed path for the DetNet service
has to be sent/configured/signaled to the network device, so the has to be sent/configured/signaled to the network device so that the
corresponding DetNet flow could pass through the network domain corresponding DetNet flow can pass through the network domain
following the specified path.</t> following the specified path.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="resource-reservation" numbered="true" toc="default">
<section anchor="resource-reservation" title="Resource Reservation"> <name>Resource Reservation</name>
<t>DetNet flows are supposed to be protected from congestion, so <t>DetNet flows are supposed to be protected from congestion, so
sufficient resource reservation for a DetNet service could protect sufficient resource reservation for a DetNet service could protect
a service from congestion. There are multiple types of resources in the a service from congestion. There are multiple types of resources in the
network that could be allocated to DetNet flows, e.g., packet network that could be allocated to DetNet flows, e.g., packet
processing resources, buffer resources, and bandwidth of the output processing resources, buffer resources, and the bandwidth of the output
port. The network resource requested by a specified DetNet service is port. The network resource requested by a specified DetNet service is
determined by the SLA requirements and network capability.</t> determined by the SLA requirements and network capability.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Resource Allocation: Port bandwidth is one of the basic <t>Resource Allocation: Port bandwidth is one of the basic
attributes of a network device which is easy to obtain or attributes of a network device that is easy to obtain or
calculate. In current traffic engineering implementations, network calculate. In current traffic engineering implementations, network
resource allocation is synonymous with bandwidth allocation. A resource allocation is synonymous with bandwidth allocation.
DetNet flow is characterized with a traffic specification as
defined in <xref target="RFC9016"/>, including attributes such as <!--[rfced] FYI: Per RFC 9016, we updated "Maximum Packets Per
Interval, Maximum Packets Per Interval, and Maximum Payload Size. 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 [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 attr
ibutes such as
Interval, MaxPacketsPerInterval, and MaxPayloadSize.
The traffic specification describes the worst case, rather than The traffic specification describes the worst case, rather than
the average case, for the traffic, to ensure that sufficient the average case, for the traffic to ensure that sufficient
bandwidth and buffering resources are reserved to satisfy the bandwidth and buffering resources are reserved to satisfy the
traffic specification. However, in the case of DetNet, resource traffic specification. However, in the case of DetNet, resource
allocation is more than simple bandwidth reservation. For example, allocation is more than simple bandwidth reservation. For example,
allocation of buffers and required queuing disciplines during allocation of buffers and required queuing disciplines during
forwarding may be required as well. Furthermore, resources must be forwarding may be required as well. Furthermore, resources must be
ensured to execute DetNet service sub-layer functions on the node, ensured to execute DetNet service sub-layer functions on the node,
such as protection and reordering through the use of packet such as protection and reordering through the use of PREOF.</t>
replication, duplicate elimination, and packet ordering functions </li>
(PREOF).</t> <li>
<t>Device configuration with or without flow discrimination: The <t>Device configuration with or without flow discrimination: The
resource allocation can be guaranteed by device configuration. For resource allocation can be guaranteed by device configuration. For
example, an output port bandwidth reservation can be configured as example, an output port bandwidth reservation can be configured as
a parameter of queue management and the port scheduling algorithm. a parameter of queue management and the port scheduling algorithm.
When DetNet flows are aggregated, a group of DetNet flows share When DetNet flows are aggregated, a group of DetNet flows share
the allocated resource in the network device. When the DetNet the allocated resource in the network device. When the DetNet
flows are treated independently, the device should maintain a flows are treated independently, the device should maintain a
mapping relationship between a DetNet flow and its corresponding mapping relationship between a DetNet flow and its corresponding
resources.</t> resources.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="preof-support" numbered="true" toc="default">
<section anchor="preof-support" title="PREOF Support"> <name>PREOF Support</name>
<t>DetNet path redundancy is supported via packet replication, <t>DetNet path redundancy is supported via Packet Replication,
duplicate elimination, and packet ordering functions (PREOF). A DetNet Elimination, and Ordering Functions (PREOF). A DetNet
flow is replicated and forwarded by multiple networks paths to avoid flow is replicated and forwarded by multiple networks paths to avoid
packet loss caused by device or link failures. In general, current packet loss caused by device or link failures. In general, current
control plane mechanisms that can be used to establish an explicit control plane mechanisms that can be used to establish an explicit
path, whether distributed or centralized, support point-to-point (P2P) path, whether distributed or centralized, support point-to-point (P2P)
and point-to-multipoint (P2MP) path establishment. PREOF requires the and point-to-multipoint (P2MP) path establishment. PREOF requires the
ability to compute and establish a set of multiple paths (e.g., ability to compute and establish a set of multiple paths (e.g.,
multiple LSP segments in an MPLS network) from the point(s) of packet multiple Label Switched Path (LSP) segments in an MPLS network) from the
replication to the point(s) of packet merging and ordering. Mapping of 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 DetNet (member) flows to explicit path segments has to be ensured as
well. Protocol extensions will be required to support these new well. Protocol extensions will be required to support these new
features. Terminology will also be required to refer to this features. Terminology will also be required to refer to this
coordinated set of path segments (such as an 'LSP graph' coordinated set of path segments (such as an "LSP graph"
in the case of the DetNet MPLS data plane).</t> in the case of the DetNet MPLS data plane).</t>
</section> </section>
<section anchor="dp-specific" numbered="true" toc="default">
<section anchor="dp-specific" title="Data Plane specific considerations"> <name>Data-Plane-Specific Considerations</name>
<section anchor="traditional-mpls" title="DetNet in an MPLS Domain"> <section anchor="traditional-mpls" numbered="true" toc="default">
<t>For the purposes of this document, 'traditional MPLS' <name>DetNet in an MPLS Domain</name>
is defined as MPLS without the use of segment routing (see <xref <t>For the purposes of this document, "traditional MPLS"
target="SR"/> for a discussion of MPLS with segment routing) or is defined as MPLS without the use of segment routing (see <xref targe
MPLS-TP <xref target="RFC5960"/>.</t> t="SR" format="default"/> for a discussion of MPLS with segment routing) or
MPLS Transport Profile (MPLS-TP) <xref target="RFC5960" format="defaul
t"/>.</t>
<t>In traditional MPLS domains, a dynamic control plane using <t>In traditional MPLS domains, a dynamic control plane using
distributed signaling protocols is typically used for the distributed signaling protocols is typically used for the
distribution of MPLS labels used for forwarding MPLS packets. The distribution of MPLS labels used for forwarding MPLS packets.
dynamic signaling protocols most commonly used for label
distribution are LDP <xref target="RFC5036"/>, RSVP-TE<xref target="RF <!--[rfced] Please clarify if "BGP/MPLS-based" means "BGP and
C4875"/>, and BGP MPLS-based" (option A) or "BGP-based and MPLS-based" (option B)
<xref target="RFC8277"/> (which enables BGP/MPLS-based Layer 3 VPNs in the following.
<xref target="RFC4384"/> Layer 2 VPNs <xref
target="RFC4664"/> and EVPN <xref Current:
target="RFC7432"/>).</t> 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-T
E <xref target="RFC4875" format="default"/>, and BGP
<xref target="RFC8277" format="default"/> (which enables BGP/MPLS-base
d Layer 3 VPNs
<xref target="RFC4384" format="default"/>, Layer 2 VPNs <xref target="
RFC4664" format="default"/>, and EVPNs <xref target="RFC7432" format="default"/>
).</t>
<t>Any of these protocols could be used to distribute DetNet Service <t>Any of these protocols could be used to distribute DetNet Service
Labels (S-Labels) and Aggregation Labels (A-Labels) <xref Labels (S-Labels) and Aggregation Labels (A-Labels) <xref target="RFC8
target="RFC8964"/>. As discussed in <xref target="RFC8938"/>, 964" format="default"/>. As discussed in <xref target="RFC8938" format="default"
/>,
S-Labels are similar to other MPLS service labels, such as S-Labels are similar to other MPLS service labels, such as
pseudowire, L3 VPN, and L2 VPN labels, and could be distributed in a pseudowire and L3 VPN and L2 VPN labels, and could be distributed in a
similar manner, such as through the use of targeted LDP or BGP. If 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 these were to be used for DetNet, they would require extensions to
support DetNet-specific features such as PREOF, aggregation support DetNet-specific features, such as PREOF, aggregation
(A-Labels), node resource allocation, and queue placement.</t> (A-Labels), node resource allocation, and queue placement.</t>
</section> </section>
<section anchor="detnet-in-an-ip-domain" numbered="true" toc="default">
<name>DetNet in an IP Domain</name>
<section anchor="detnet-in-an-ip-domain" <!-- [rfced] Section 4.4.2: This section states that it will "discuss
title="DetNet in an IP Domain"> possible protocol extensions to existing IP routing protocols";
<t>For the purposes of this document, 'traditional IP' however, it does not appear to do that. Please review and let us
is defined as IP without the use of segment routing (see <xref know if content should be added to this section or if it should
target="SR"/> for a discussion of IP with segment routing). This 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"
is defined as IP without the use of segment routing (see <xref target=
"SR" format="default"/> for a discussion of IP with segment routing). This
section will discuss possible protocol extensions to existing IP section will discuss possible protocol extensions to existing IP
routing protocols. It should be noted that a DetNet IP data plane routing protocols. It should be noted that a DetNet IP data plane
<xref target="RFC8939"/> is simpler than a DetNet MPLS data plane <xref target="RFC8939" format="default"/> is simpler than a DetNet MPL
<xref target="RFC8964"/>, and doesn't support PREOF, so only one S data plane
<xref target="RFC8964" format="default"/> and doesn't support PREOF, s
o only one
path per flow or flow aggregate is required.</t> path per flow or flow aggregate is required.</t>
</section> </section>
<section anchor="SR" numbered="true" toc="default">
<section anchor="SR" title="DetNet in a Segment Routing Domain"> <name>DetNet in a Segment Routing Domain</name>
<t>Segment Routing <xref target="RFC8402"/> is a scalable approach <t>Segment Routing <xref target="RFC8402" format="default"/> is a scal
able approach
to building network domains that provides explicit routing via to building network domains that provides explicit routing via
source routing encoded in packet headers and it is combined with source routing encoded in packet headers, and it is combined with
centralized network control to compute paths through the network. centralized network control to compute paths through the network.
Forwarding paths are distributed with associated policy to network Forwarding paths are distributed with associated policies to network
edge nodes for use in packet headers. Segment Routing reduces edge nodes for use in packet headers. Segment Routing reduces
the amount of network signaling associated with distributed the amount of network signaling associated with distributed
signaling protocols such as RSVP-TE, and also reduces the amount of signaling protocols, such as RSVP-TE, and also reduces the amount of
state in core nodes compared with that required for traditional MPLS 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 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 the routers. This could be useful for DetNet, where a very large
number of flows through a network domain are expected, which would number of flows through a network domain are expected, which would
otherwise require the instantiation of state for each flow otherwise require the instantiation of state for each flow
traversing each node in the network.</t> traversing each node in the network.</t>
<t>Note that the DetNet MPLS and IP data planes described in <xref tar
<t>Note that the DetNet MPLS and IP data planes described in <xref get="RFC8964" format="default"/> and <xref target="RFC8939" format="default"/> w
target="RFC8964"/> and <xref target="RFC8939"/> were constructed to ere constructed to
be compatible with both types of segment routing, SR-MPLS <xref be compatible with both types of segment routing: Segment Routing over
target="RFC8660"/> and SRv6 <xref target="RFC8754"/> <xref target="RFC MPLS (SR-MPLS) <xref target="RFC8660" format="default"/> and Segment Routing ov
8986"/>.</t> er IPv6 (SRv6) <xref target="RFC8754" format="default"/> <xref target="RFC8986"
format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="encapsulation-support" numbered="true" toc="default">
<section anchor="encapsulation-support" title="Encapsulation and metadata <name>Encapsulation and Metadata Support</name>
support"> <t>To effectively manage DetNet flows, the controller plane will need to
<t>To effectively manage DetNet flows, the controller plane will need ha have a clear understanding of the encapsulation and metadata capabilities of th
ve a clear understanding of the encapsulation and metadata capabilities of the u e underlying network nodes. This will require a control mechanism that can disco
nderlying network nodes. This will require a control mechanism that can discover ver, configure, and manage these parameters for each flow.</t>
, 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 effect
<t>The controller plane needs to understand and manage the encapsulation ively. This process might need a discovery phase in which the controller discove
and metadata capabilities of the network nodes to provision DetNet flows effect rs which encapsulation types (e.g., MPLS, IP) and metadata schemes (e.g., sequen
ively. This process might need a discovery phase, in which the controller discov cing, timestamping) that each node supports. After discovery, the controller mig
ers which encapsulation types (e.g., MPLS, IP) and metadata schemes (e.g., seque ht instruct nodes on the specific encapsulation and companion metadata to apply
ncing, timestamping) each node supports. After discovery, the controller might i for a given flow. This ensures that DetNet packets are handled consistently acro
nstruct nodes on the specific encapsulation and companion metadata to apply for ss the network. For example, the controller might instruct a node to use an MPLS
a given flow. This ensures that DetNet packets are handled consistently across t header and add a sequence number for a particular flow.
he network. For example, the controller might instruct a node to use an MPLS hea
der and add a sequence number for a particular flow.
</t> </t>
</section> </section>
</section> </section>
<section anchor="management-plane-overview" numbered="true" toc="default">
<section anchor="management-plane-overview" <name>Management Plane Overview</name>
title="Management Plane Overview">
<t>The management plane includes the ability to statically provision <t>The management plane includes the ability to statically provision
network nodes and to use OAM to monitor DetNet performance and detect network nodes and to use Operations, Administration, and Maintenance (OAM) to monitor DetNet performance and to detect
outages or other issues at the DetNet layer.</t> outages or other issues at the DetNet layer.</t>
<section anchor="detnet-operations-administration-and-maintenance-oam" num
<section anchor="detnet-operations-administration-and-maintenance-oam" bered="true" toc="default">
title="DetNet Operations, Administration and Maintenance (OAM)"> <name>DetNet Operations, Administration, and Maintenance (OAM)</name>
<t>This document covers the general considerations for OAM.</t> <t>This document covers the general considerations for OAM.</t>
<section anchor="oam-for-performance-monitoring-pm" numbered="true" toc=
<section anchor="oam-for-performance-monitoring-pm" "default">
title="OAM for Performance Monitoring (PM)"> <name>OAM for Performance Monitoring (PM)</name>
<section anchor="active-pm" title="Active PM"> <section anchor="active-pm" numbered="true" toc="default">
<name>Active PM</name>
<t>Active PM is performed by injecting OAM packets into the <t>Active PM is performed by injecting OAM packets into the
network to estimate the performance of the network by measuring network to estimate the performance of the network and by then measu
the performance of the OAM packets. Adding extra traffic can ring
the performance of those OAM packets. Adding extra traffic can
affect the delay and throughput performance of the network, and affect the delay and throughput performance of the network, and
for this reason active PM is not recommended for use in for this reason, Active PM is not recommended for use in
operational DetNet domains. However, it is a useful test tool when operational DetNet domains. However, it is a useful test tool when
commissioning a new network or during troubleshooting.</t> commissioning a new network or during troubleshooting.</t>
</section> </section>
<section anchor="passive-pm" numbered="true" toc="default">
<section anchor="passive-pm" title="Passive PM"> <name>Passive PM</name>
<t>Passive PM, such as IOAM <xref target="RFC9197"/>, monitors the a <t>Passive PM, such as In Situ Operations, Administration, and Maint
ctual service traffic in a network enance (IOAM) <xref target="RFC9197" format="default"/>, monitors the actual ser
vice traffic in a network
domain in order to measure its performance without having a domain in order to measure its performance without having a
detrimental effect on the network. As compared to Active PM, detrimental effect on the network. As compared to Active PM,
Passive PM is much preferred for use in DetNet domains.</t> Passive PM is much preferred for use in DetNet domains.</t>
</section> </section>
</section> </section>
<section anchor="oam-for-connectivity-and-faultdefect-management-cfm" nu
<section anchor="oam-for-connectivity-and-faultdefect-management-cfm" mbered="true" toc="default">
title="OAM for Connectivity and Fault/Defect Management (CFM)"> <name>OAM for Connectivity and Fault Management (CFM)</name>
<t>The detailed requirements for connectivity and fault/defect <t>The detailed requirements for CFM
detection and management in DetNet IP domain and DetNet MPLS domain in a DetNet IP domain and a DetNet MPLS domain
are defined in <xref target="RFC9551"/> <xref target="RFC9634"/> and < are defined in <xref target="RFC9551" format="default"/>, <xref target
xref target="RFC9546"/>, respectively.</t> ="RFC9634" format="default"/>, and <xref target="RFC9546" format="default"/>, re
spectively.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Multi-Domain Aspects</name>
<section title="Multidomain Aspects"> <!-- [rfced] We're having trouble parsing how "one ... controller
<t>When there are multiple domains involved, one or multiple controller plane function" can "collaborate". How may we update for clarity?
plane functions (CPF) would have to collaborate to implement the Note that we updated the capitalization of the expansions for CPF
requests received from the flow management entity (FME, as defined in and FME to match RFC 8655.
<xref target="RFC8655"/>) as per-flow, per-hop behaviors installed in
Current:
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) [RFC8655] as
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" format="default"/> as per-flow, per-hop behaviors i
nstalled in
the DetNet nodes for each individual flow. Adding multi-domain support the DetNet nodes for each individual flow. Adding multi-domain support
might require some support at the CPF. For example, CPFs of different might require some support at the CPF. For example, CPFs of different
domains, e.g., PCEs need to discover each other, authenticate and domains, e.g., PCEs, need to discover each other and then authenticate and
negotiate per-hop behaviors. Furthermore, in the case of wireless domains, negotiate per-hop behaviors.
the per-domain RAW <xref target="I-D.ietf-raw-architecture"/> specific fun
ctions like the PLR (Point of Local Repair)s have to be also <!--[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
[I-D.ietf-raw-architecture] specific functions like the PLR (Point
of Local 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) <xr
ef 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 considered, e.g., in addition to the PCEs. Depending on the multi-domain
support provided by the application plane, the controller plane might be support provided by the application plane, the controller plane might be
relieved from some responsibilities (e.g., if the application plane relieved from some responsibilities (e.g., if the application plane
takes care of splitting what needs to be provided by each domain).</t> takes care of splitting what needs to be provided by each domain).</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no actions for IANA.</t> <t>This document has no IANA actions.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security Considerations"> <name>Security Considerations</name>
<t>This document provides a framework for the DetNet controller plane, <t>This document provides a framework for the DetNet Controller Plane
and does not include any protocol specifications. Any future and does not include any protocol specifications. Any future
specification that is defined to support the DetNet controller plane is specification that is defined to support the DetNet Controller Plane is
expected to include appropriate security considerations. For overall expected to include the appropriate security considerations. For overall
security considerations of DetNet see <xref target="RFC8655"/> and <xref security considerations of DetNet, see <xref target="RFC8655" format="defa
target="RFC9055"/></t> ult"/> and <xref target="RFC9055" format="default"/>.</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 Bouca
dair, Gorry Fairhurst and Dave Thaler for their comments during the different di
rectorate and IESG reviews.</t>
</section>
<section title="Contributors">
<t>Fengwei Qin</t>
<t>China Mobile</t>
<t>Email: qinfengwei@chinamobile.com</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-raw-architecture" to="RAW-ARCH"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <references>
RFC.8655.xml" <name>References</name>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
.8938.xml" 655.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
938.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
.9055.xml" 055.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
016.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
.9016.xml" 551.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> </references>
<references>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <name>Informative References</name>
RFC.9551.xml" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
xmlns:xi="http://www.w3.org/2001/XInclude"/> 634.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</references> 546.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references title="Informative References"> 964.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
.9634.xml" 939.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
056.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
.9546.xml" 025.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
037.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
.8964.xml" 023.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
024.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
.8939.xml" 320.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
633.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
.9056.xml" 754.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
.9025.xml" 209.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
426.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
.9037.xml" 960.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
283.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
.9023.xml" 384.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
277.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
.9024.xml" 241.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
036.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
.9320.xml" 432.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
.9633.xml" 402.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
875.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
197.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!-- [I-D.ietf-raw-architecture]
.8754.xml" draft-ietf-raw-architecture-30
xmlns:xi="http://www.w3.org/2001/XInclude"/> IESG State: in AUTH48-DONE (RFC 9912) as of 02/20/26
-->
<reference anchor="I-D.ietf-raw-architecture" target="https://datatracker.ietf.o
rg/doc/html/draft-ietf-raw-architecture-30">
<front>
<title>Reliable and Available Wireless Architecture</title>
<author initials="P." surname="Thubert" fullname="Pascal Thubert" role="ed
itor">
<organization>Without Affiliation</organization>
</author>
<date month="July" day="25" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-raw-architecture-30" />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC </reference>
.6020.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
.3209.xml" 632.xml"/>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
950.xml"/>
</references>
</references>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <section anchor="acknowledgments" numbered="false" toc="default">
.7426.xml" <name>Acknowledgments</name>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <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>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <section numbered="false" toc="default">
.5960.xml" <name>Contributors</name>
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <contact fullname="Fengwei Qin">
.8283.xml" <organization>China Mobile</organization>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <address>
<email>qinfengwei@chinamobile.com</email>
</address>
</contact>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC </section>
.4384.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC </back>
.8277.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!-- [rfced] Terminology
.6241.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC a) Throughout the text, the following terminology appears to be used
.5036.xml" inconsistently. Please review these occurrences and let us know if/how
xmlns:xi="http://www.w3.org/2001/XInclude"/> they may be made consistent.
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC Segment Routing vs. segment routing
.7432.xml" (not including "Segment Routing over MPLS" or "Segment Routing over IPv6")
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC b) Note that we updated the text to reflect the forms on the right for
.8660.xml" consistency. Please let us know if any further changes are needed.
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC Controller Plane -> controller plane (per RFCs 9016 and 9055)
.8402.xml" Data Plane -> data plane (per RFCs 9016, 9055, and 9551)
xmlns:xi="http://www.w3.org/2001/XInclude"/> 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)
-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!-- [rfced] Please review the "Inclusive Language" portion of the online
.9552.xml" Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
xmlns:xi="http://www.w3.org/2001/XInclude"/> and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. In addition, please consider whether "tradition" should be updated for clarity.
RFC.4875.xml" While the NIST website <https://web.archive.org/web/20250214092458/
xmlns:xi="http://www.w3.org/2001/XInclude"/> 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.
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. A):
RFC.4664.xml" Note that in the DetNet overall architecture, the controller plane
xmlns:xi="http://www.w3.org/2001/XInclude"/> includes what are more traditionally considered separate control and
management planes (see Section 4.4.2 of [RFC8655]).
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. B):
RFC.8986.xml" Traditionally, the management plane is primarily involved with
xmlns:xi="http://www.w3.org/2001/XInclude"/> 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).
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. C):
RFC.9197.xml" For the purposes of this document, "traditional MPLS" is defined as
xmlns:xi="http://www.w3.org/2001/XInclude"/> MPLS without the use of segment routing (see Section 4.4.3 for a
discussion of MPLS with segment routing) or MPLS-TP [RFC5960].
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-r D):
aw-architecture" In traditional MPLS domains, a dynamic control plane using
xmlns:xi="http://www.w3.org/2001/XInclude"/> distributed signaling protocols is typically used for the
distribution of MPLS labels used for forwarding MPLS packets.
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC E):
.6632.xml" For the purposes of this document, "traditional IP" is defined as IP
xmlns:xi="http://www.w3.org/2001/XInclude"/> without the use of segment routing (see Section 4.4.3 for a
discussion of IP with segment routing).
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC F):
.7950.xml" Segment Routing reduces the amount of network signaling associated
xmlns:xi="http://www.w3.org/2001/XInclude"/> 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.
-->
</references>
</back>
</rfc> </rfc>
 End of changes. 148 change blocks. 
529 lines changed or deleted 795 lines changed or added

This html diff was produced by rfcdiff 1.48.