rfc9938v1.txt   rfc9938.txt 
Internet Engineering Task Force (IETF) A. Malis Internet Engineering Task Force (IETF) A. Malis
Request for Comments: 9938 Independent Request for Comments: 9938 Independent
Category: Informational X. Geng, Ed. Category: Informational X. Geng, Ed.
ISSN: 2070-1721 M. (Guoyi)Chen ISSN: 2070-1721 M. (Guoyi)Chen
Huawei Huawei
B. Varga B. Varga
Ericsson Ericsson
CJ. Bernardos CJ. Bernardos
UC3M UC3M
February 2026 March 2026
A Framework for the Deterministic Networking (DetNet) Controller Plane A Framework for the Deterministic Networking (DetNet) Controller Plane
Abstract Abstract
This document provides a framework overview for the Deterministic 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 the DetNet Controller Plane, which could be the requirements for the DetNet Controller Plane, which could be the
basis for a future solution specification. basis for a future solution specification.
skipping to change at line 62 skipping to change at line 62
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. DetNet Controller Plane Requirements 2. DetNet Controller Plane Requirements
2.1. DetNet Control Plane Requirements 2.1. DetNet Control Plane Requirements
2.2. DetNet Management Plane Requirements 2.2. DetNet Management Plane Requirements
2.3. Requirements for Both Planes 2.3. Requirements for Both Planes
3. DetNet Control Plane Architecture 3. DetNet Control Plane Architecture
3.1. Distributed Control Plane and Signaling Protocols 3.1. Distributed Control Plane and Signaling Protocols
3.2. SDN/Fully Centralized Control Plane 3.2. Fully Centralized Control Plane
3.3. Hybrid Control Plane (Partly Centralized and Partly 3.3. Hybrid Control Plane (Partly Centralized and Partly
Distributed) Distributed)
4. DetNet Control Plane for DetNet Mechanisms 4. DetNet Control Plane for DetNet Mechanisms
4.1. Explicit Paths 4.1. Explicit Paths
4.2. Resource Reservation 4.2. Resource Reservation
4.3. PREOF Support 4.3. PREOF Support
4.4. Data-Plane-Specific Considerations 4.4. Data-Plane-Specific Considerations
4.4.1. DetNet in an MPLS Domain 4.4.1. DetNet in an MPLS Domain
4.4.2. DetNet in an IP Domain 4.4.2. DetNet in an IP Domain
4.4.3. DetNet in a Segment Routing Domain 4.4.3. DetNet in a Segment Routing Domain
skipping to change at line 96 skipping to change at line 96
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
Deterministic Networking (DetNet) provides the ability to carry 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 delivery latency. A description of the general background and
concepts of DetNet can be found in [RFC8655]. concepts of DetNet can be found in [RFC8655].
The DetNet data plane is defined in a set of documents that are The DetNet data plane is defined in the DetNet data plane framework
anchored by the DetNet data plane framework [RFC8938] (as well as the [RFC8938] (and is further explained in the associated DetNet MPLS
associated DetNet MPLS defined in [RFC8964], the DetNet IP defined in [RFC8964], the DetNet IP [RFC8939], and other data plane
[RFC8939], and other data plane specifications defined in [RFC9023], specifications [RFC9023] [RFC9024] [RFC9025] [RFC9037] [RFC9056]).
[RFC9024], [RFC9025], [RFC9037], and [RFC9056]).
Note that in the DetNet overall architecture, the controller plane Note that in the DetNet overall architecture, the controller plane
includes what are more traditionally considered separate control and includes what are more usually considered separate control and
management planes (see Section 4.4.2 of [RFC8655]). Traditionally, management planes (see Section 4.4.2 of [RFC8655]). The management
the management plane is primarily involved with fault management, plane is primarily involved with fault management, configuration
configuration management, and performance management (sometimes management, and performance management (sometimes accounting
accounting management and security management are also considered in management and security management are also considered in the
the management plane (Section 4.2 of [RFC6632]) but they are out of management plane (Section 4.2 of [RFC6632]) but they are out of the
the scope of this document). At the same time, the control plane is scope of this document). At the same time, the control plane is
primarily responsible for the instantiation and maintenance of flows, primarily responsible for the instantiation and maintenance of flows,
MPLS label allocation and distribution, and active in-band or out-of- MPLS label allocation and distribution, and active in-band or out-of-
band signaling to support DetNet functions. In the DetNet band signaling to support DetNet functions. In the DetNet
architecture, all of this functionality is combined into a single architecture, all of this functionality is combined into a single
controller plane. See Section 4.4.2 of [RFC8655] and the aggregation controller plane. See Section 4.4.2 of [RFC8655] and the aggregation
of control and management planes in [RFC7426] for further details. of control and management planes in [RFC7426] for further details.
While the DetNet architecture and data plane documents are primarily While the DetNet architecture and data plane documents are primarily
concerned with data plane operations, they do contain some concerned with data plane operations, they do contain some
requirements and considerations for functions that would be required requirements and considerations for functions that would be required
skipping to change at line 297 skipping to change at line 296
the UNI and calculates one or more valid paths. the UNI and calculates one or more valid paths.
3. The ingress node sends a PATH message with an explicit route 3. The ingress node sends a PATH message with an explicit route
through RSVP-TE. After receiving the PATH message, the egress through RSVP-TE. 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. resource reservation request.
In this example, both the IGP and RSVP-TE may require extensions for In this example, both the IGP and RSVP-TE may require extensions for
DetNet. DetNet.
3.2. SDN/Fully Centralized Control Plane 3.2. Fully Centralized Control Plane
In the fully SDN/centralized configuration model, flow/UNI In the fully centralized configuration model (e.g., using an SDN
information is transmitted either from a centralized user controller controller), both flow and UNI information can be transmitted from a
or from applications via an API/northbound interface to a centralized centralized user controller or from other applications, via an API or
controller. Network node configurations for DetNet flows are northbound interface, to a centralized controller. Network node
performed by the controller using a protocol such as NETCONF configurations for DetNet flows are performed by the controller using
[RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], or PCE-CC a protocol such as NETCONF [RFC6241], YANG [RFC6020] [RFC7950],
DetNet YANG [RFC9633], or a PCE-based central controller (PCE-CC)
[RFC8283]. [RFC8283].
Take the following case as an example: Take the following case as an example:
1. A centralized controller collects topology information and DetNet 1. A centralized controller collects topology information and DetNet
capabilities of the network nodes via NETCONF/YANG. capabilities of the network nodes via NETCONF/YANG.
2. The controller receives a flow establishment request from a UNI 2. The controller receives a flow establishment request from a UNI
and calculates one or more valid paths through the network. and calculates one or more valid paths through the network.
skipping to change at line 428 skipping to change at line 428
DetNet path redundancy is supported via Packet Replication, DetNet path redundancy is supported via Packet Replication,
Elimination, and Ordering Functions (PREOF). A DetNet flow is Elimination, and Ordering Functions (PREOF). A DetNet flow is
replicated and forwarded by multiple networks paths to avoid packet replicated and forwarded by multiple networks paths to avoid packet
loss caused by device or link failures. In general, current control loss caused by device or link failures. In general, current control
plane mechanisms that can be used to establish an explicit path, plane mechanisms that can be used to establish an explicit path,
whether distributed or centralized, support point-to-point (P2P) and whether distributed or centralized, support point-to-point (P2P) and
point-to-multipoint (P2MP) path establishment. PREOF requires the 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 Label Switched Path (LSP) segments in an MPLS network) from multiple Label Switched Path (LSP) segments in an MPLS network) from
the point(s) of packet replication to the point(s) of packet merging the point(s) of packet replication to the point(s) of packet merging
and ordering. Mapping of DetNet (member) flows to explicit path and ordering. Mapping of DetNet flows or DetNet member flows to
segments has to be ensured as well. Protocol extensions will be explicit path segments has to be ensured as well. Protocol
required to support these new features. Terminology will also be extensions will be required to support these new features.
required to refer to this coordinated set of path segments (such as Terminology will also be required to refer to this coordinated set of
an "LSP graph" in the case of the DetNet MPLS data plane). path segments (such as an "LSP graph" in the case of the DetNet MPLS
data plane).
4.4. Data-Plane-Specific Considerations 4.4. Data-Plane-Specific Considerations
4.4.1. DetNet in an MPLS Domain 4.4.1. DetNet in an MPLS Domain
For the purposes of this document, "traditional MPLS" is defined as For the purposes of this document, "legacy MPLS" is defined as MPLS
MPLS without the use of segment routing (see Section 4.4.3 for a without the use of Segment Routing (see Section 4.4.3 for a
discussion of MPLS with segment routing) or MPLS Transport Profile discussion of MPLS with Segment Routing) or MPLS Transport Profile
(MPLS-TP) [RFC5960]. (MPLS-TP) [RFC5960].
In traditional MPLS domains, a dynamic control plane using In legacy MPLS domains, a dynamic control plane using distributed
distributed signaling protocols is typically used for the signaling protocols is typically used for the distribution of MPLS
distribution of MPLS labels used for forwarding MPLS packets. The labels used for forwarding MPLS packets. The dynamic signaling
dynamic signaling protocols most commonly used for label distribution protocols most commonly used for label distribution are LDP
are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which enables BGP-
enables BGP/MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs based MPLS Layer 3 VPNs [RFC4384], Layer 2 VPNs [RFC4664], and EVPNs
[RFC4664], and EVPNs [RFC7432]). [RFC7432]).
Any of these protocols could be used to distribute DetNet Service Any of these protocols could be used to distribute DetNet Service
Labels (S-Labels) and Aggregation Labels (A-Labels) [RFC8964]. As Labels (S-Labels) and Aggregation Labels (A-Labels) [RFC8964]. As
discussed in [RFC8938], S-Labels are similar to other MPLS service discussed in [RFC8938], S-Labels are similar to other MPLS service
labels, such as pseudowire and L3 VPN and L2 VPN labels, and could be labels, such as pseudowire and L3 VPN and L2 VPN labels, and could be
distributed in a similar manner, such as through the use of targeted 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 LDP or BGP. If these were to be used for DetNet, they would require
extensions to support DetNet-specific features, such as PREOF, extensions to support DetNet-specific features, such as PREOF,
aggregation (A-Labels), node resource allocation, and queue aggregation (A-Labels), node resource allocation, and queue
placement. placement.
4.4.2. DetNet in an IP Domain 4.4.2. DetNet in an IP Domain
For the purposes of this document, "traditional IP" is defined as IP For the purposes of this document, "legacy IP" is defined as IP
without the use of segment routing (see Section 4.4.3 for a without the use of Segment Routing (see Section 4.4.3 for a
discussion of IP with segment routing). This section will discuss discussion of IP with Segment Routing). It should be noted that a
possible protocol extensions to existing IP routing protocols. It DetNet IP data plane [RFC8939] is simpler than a DetNet MPLS data
should be noted that a DetNet IP data plane [RFC8939] is simpler than plane [RFC8964] and doesn't support PREOF, so only one path per flow
a DetNet MPLS data plane [RFC8964] and doesn't support PREOF, so only or flow aggregate is required. Therefore, possible protocol
one path per flow or flow aggregate is required. extensions are expected to be limited, e.g., to existing IP routing
protocols.
4.4.3. DetNet in a Segment Routing Domain 4.4.3. DetNet in a Segment Routing Domain
Segment Routing [RFC8402] is a scalable approach to building network Segment Routing [RFC8402] is a scalable approach to building network
domains that provides explicit routing via source routing encoded in domains that provides explicit routing via source routing encoded in
packet headers, and it is combined with centralized network control packet headers, and it is combined with centralized network control
to compute paths through the network. Forwarding paths are to compute paths through the network. Forwarding paths are
distributed with associated policies to network edge nodes for use in distributed with associated policies to network edge nodes for use in
packet headers. Segment Routing reduces the amount of network packet headers. Segment Routing reduces the amount of network
signaling associated with distributed signaling protocols, such as signaling associated with distributed signaling protocols, such as
RSVP-TE, and also reduces the amount of state in core nodes compared 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 with that required for legacy MPLS and IP routing, as the state is
is now in the packets rather than in the routers. This could be now in the packets rather than in the routers. This could be useful
useful for DetNet, where a very large number of flows through a for DetNet, where a very large number of flows through a network
network domain are expected, which would otherwise require the domain are expected, which would otherwise require the instantiation
instantiation of state for each flow traversing each node in the of state for each flow traversing each node in the network.
network.
Note that the DetNet MPLS and IP data planes described in [RFC8964] Note that the DetNet MPLS and IP data planes described in [RFC8964]
and [RFC8939] were constructed to be compatible with both types of and [RFC8939] were constructed to be compatible with both types of
segment routing: Segment Routing over MPLS (SR-MPLS) [RFC8660] and Segment Routing: Segment Routing over MPLS (SR-MPLS) [RFC8660] and
Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986]. Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986].
4.5. Encapsulation and Metadata Support 4.5. Encapsulation and Metadata Support
To effectively manage DetNet flows, the controller plane will need to To effectively manage DetNet flows, the controller plane will need to
have a clear understanding of the encapsulation and metadata have a clear understanding of the encapsulation and metadata
capabilities of the underlying network nodes. This will require a capabilities of the underlying network nodes. This will require a
control mechanism that can discover, configure, and manage these control mechanism that can discover, configure, and manage these
parameters for each flow. parameters for each flow.
skipping to change at line 552 skipping to change at line 553
PM is much preferred for use in DetNet domains. PM is much preferred for use in DetNet domains.
5.1.2. OAM for Connectivity and Fault Management (CFM) 5.1.2. OAM for Connectivity and Fault Management (CFM)
The detailed requirements for CFM in a DetNet IP domain and a DetNet The detailed requirements for CFM in a DetNet IP domain and a DetNet
MPLS domain are defined in [RFC9551], [RFC9634], and [RFC9546], MPLS domain are defined in [RFC9551], [RFC9634], and [RFC9546],
respectively. respectively.
6. Multi-Domain Aspects 6. Multi-Domain Aspects
When there are multiple domains involved, one or multiple Controller When there are multiple domains involved, multiple Controller Plane
Plane Functions (CPFs) would have to collaborate to implement the Functions (CPFs) would have to collaborate to implement the requests
requests received from the Flow Management Entity (FME) [RFC8655] as received from the Flow Management Entity (FME) [RFC8655] as per-flow,
per-flow, per-hop behaviors installed in the DetNet nodes for each per-hop behaviors installed in the DetNet nodes for each individual
individual flow. Adding multi-domain support might require some flow. Adding multi-domain support might require some support at the
support at the CPF. For example, CPFs of different domains, e.g., CPF. For example, CPFs of different domains, e.g., PCEs, need to
PCEs, need to discover each other and then authenticate and negotiate discover each other and then authenticate and negotiate per-hop
per-hop behaviors. Furthermore, in the case of wireless domains, behaviors. Furthermore, in the case of wireless domains, per-domain
per-domain functions specific to Reliable and Available Wireless functions specific to Reliable and Available Wireless (RAW)
(RAW) [RAW-ARCH], such as Point of Local Repairs (PLRs), have to also [RAW-ARCH], such as Point of Local Repairs (PLRs), have to also be
be considered, e.g., in addition to the PCEs. Depending on the considered, e.g., in addition to the PCEs. Depending on the multi-
multi-domain support provided by the application plane, the domain support provided by the application plane, the controller
controller plane might be relieved from some responsibilities (e.g., plane might be relieved from some responsibilities (e.g., if the
if the application plane takes care of splitting what needs to be application plane takes care of splitting what needs to be provided
provided by each domain). by each domain).
7. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
8. Security Considerations 8. Security Considerations
This document provides a framework for the DetNet Controller Plane 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 specification that is defined to support the DetNet Controller Plane
 End of changes. 13 change blocks. 
65 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.48.