Independent

agmalis@gmail.com

Huawei

gengxuesong@huawei.com

Huawei

mach.chen@huawei.com

Ericsson

balazs.a.varga@ericsson.com

Universidad Carlos III de Madrid

Av. Universidad, 30 Leganes, Madrid 28911 Spain +34 91624 6236 cjbc@it.uc3m.es http://www.it.uc3m.es/cjbc/

RTG detnet DetNet Controller plane SDN This document provides a framework overview for the Deterministic Networking (DetNet) Controller Plane. It discusses concepts and requirements for the DetNet Controller Plane, which could be the basis for a future solution specification.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  DetNet Controller Plane Requirements
  • .  DetNet Control Plane Requirements
  • .  DetNet Management Plane Requirements
  • .  Requirements for Both Planes
• .  DetNet Control Plane Architecture
  • .  Distributed Control Plane and Signaling Protocols
  • .  Fully Centralized Control Plane
  • .  Hybrid Control Plane (Partly Centralized and Partly Distributed)
• .  DetNet Control Plane for DetNet Mechanisms
  • .  Explicit Paths
  • .  Resource Reservation
  • .  PREOF Support
  • .  Data-Plane-Specific Considerations
    • .  DetNet in an MPLS Domain
    • .  DetNet in an IP Domain
    • .  DetNet in a Segment Routing Domain
  • .  Encapsulation and Metadata Support
• .  Management Plane Overview
  • .  DetNet Operations, Administration, and Maintenance (OAM)
    • .  OAM for Performance Monitoring (PM)
    • .  OAM for Connectivity and Fault Management (CFM)
• .  Multi-Domain Aspects
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Contributors
• Authors' Addresses

Introduction Deterministic Networking (DetNet) provides the ability to carry specified unicast or multicast data flows for real-time applications with extremely low packet loss rates and assured maximum end-to-end delivery latency. A description of the general background and concepts of DetNet can be found in . The DetNet data plane is defined in the DetNet data plane framework (and is further explained in the associated DetNet MPLS , the DetNet IP , and other data plane specifications ). Note that in the DetNet overall architecture, the controller plane includes what are more usually considered separate control and management planes (see ). The management plane is primarily involved with fault management, configuration management, and performance management (sometimes accounting management and security management are also considered in the management plane () but they are out of the scope of this document). At the same time, the control plane is primarily responsible for the instantiation and maintenance of flows, MPLS label allocation and distribution, and active in-band or out-of-band signaling to support DetNet functions. In the DetNet architecture, all of this functionality is combined into a single controller plane. See and the aggregation of control and management planes in for further details. While the DetNet architecture and data plane documents are primarily concerned with data plane operations, they do contain some requirements and considerations for functions that would be required in order to automate DetNet service provisioning and monitoring via a DetNet Controller Plane (e.g., see ). The purpose of this document is to take these requirements and considerations into a single document and extend and discuss how various possible DetNet Controller Plane architectures could be used to satisfy these requirements, while not providing the protocol details for a DetNet Controller Plane solution. Such controller plane protocol solutions will be the subject of subsequent documents. Therefore, this document should be considered as the authoritative reference to be considered if/when protocol work on the DetNet Controller Plane starts.

DetNet Controller Plane Requirements Other DetNet documents, including , , , and , among others, contain requirements for the controller plane. For convenience, these requirements have been compiled here. These requirements have been organized into three groups: 1) requirements primarily applicable to the control plane, 2) requirements primarily applicable to the management plane, and 3) requirements applicable to both planes. In addition, security requirements for the DetNet Controller Plane have been discussed in , and a summary of those requirements is provided in . For the sake of clarity, when applicable, the document in which the requirements originally appear is referenced.

DetNet Control Plane Requirements The primary requirements for the DetNet Control Plane are as follows:

• Support the dynamic instantiation, modification, and deletion of DetNet flows. This may include some or all of explicit path determination, link bandwidth reservations, restriction of flows to specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN) links), node buffer and other resource reservations, specification of required queuing disciplines along the path, the ability to manage bidirectional flows, etc., as needed for a flow .
• Support DetNet flow aggregation and de-aggregation via the ability to dynamically create and delete flow aggregates (FAs) and modify existing FAs by adding or deleting participating flows .
• Allow flow instantiation requests to originate in an end application (via an Application Programming Interface (API) via static provisioning or via a dynamic control plane, such as a Software-Defined Networking (SDN) controller or distributed signaling protocols). See for further discussion of these options.
• Manage, in the case of the DetNet MPLS data plane, DetNet Service Label (S-Label), Forwarding Label (F-Label), and Aggregation Label (A-Label) allocation and distribution .
• Support, also in the case of the DetNet MPLS data plane, the DetNet service sub-layer, which provides DetNet service functions, such as protection and reordering through the use of Packet Replication, Elimination, and Ordering Functions (PREOF) .
• Support the queue control techniques defined in and that require time synchronization among the network data plane nodes.
• Advertise static and dynamic node and link characteristics, such as capabilities and adjacencies to other network nodes (for dynamic signaling approaches) or to network controllers (for centralized approaches) .
• Scale to handle the number of DetNet flows expected in a domain (which may require per-flow signaling or provisioning) .
• Provision flow identification information at each of the nodes along the path. Flow identification may differ depending on the location in the network and the DetNet functionality (e.g., transit node vs. relay node) .

DetNet Management Plane Requirements The primary requirements for the DetNet management plane are as follows:

• Monitor the performance of DetNet flows and nodes to ensure that they are meeting required objectives, both proactively and on demand .
• Support DetNet flow continuity check and connectivity verification functions .
• Support testing and monitoring of packet replication, duplicate elimination, and packet ordering functionality in the DetNet domain .

Requirements for Both Planes The following requirements apply to both the DetNet control and management planes:

• Operate in a converged network domain that contains both DetNet and non-DetNet flows .
• Adapt to DetNet domain topology changes such as link or node failures (fault recovery/restoration), additions, and removals .

In addition to the above, the DetNet Controller Plane should also satisfy security requirements derived from , which defines the security framework for DetNet. The following requirements are especially relevant:

• Integrity and authenticity of control/signaling packets: The controller plane should ensure that signaling and control messages cannot be modified or injected by unauthorized entities and should prevent spoofing and segmentation attacks.
• Protection against controller compromise: Mechanisms should exist to verify the legitimacy of controllers and to prevent unauthorized components from impersonating them.
• System-wide security design: The architecture must account for the possibility of compromised nodes or controllers, ensuring resilience so that the failure or subversion of a single component does not cause catastrophic impact.
• Timely delivery of control plane messages: The controller plane should ensure that control and signaling messages are delivered without undue delay to prevent disruption of DetNet services without resource leakage.

DetNet Control Plane Architecture As noted in the , the DetNet Control Plane is responsible for the instantiation and maintenance of flows, the allocation and distribution of flow-related information (e.g., MPLS label), and active in-band or out-of-band information distribution to support these functions. The following sections define three types of DetNet Control Plane architectures: 1) a fully distributed control plane utilizing dynamic signaling protocols, 2) a fully centralized SDN-like control plane, and 3) a hybrid control plane containing both distributed protocols and centralized controlling. This document describes the various information exchanges between entities in the network for each type of these architectures and the corresponding advantages and disadvantages. The examples in the following sections illustrate possible mechanisms that could be used in each type of the architectures. They are not meant to be exhaustive or to preclude any other possible mechanism that could be used in place of those used in the examples.

Distributed Control Plane and Signaling Protocols In a fully distributed configuration model, the User-Network Interface (UNI) information is transmitted over a DetNet UNI protocol from the user side to the network side. Then, the UNI and network configuration information propagates in the network via distributed control plane signaling protocols. Such a DetNet UNI protocol is not necessary when the end systems are DetNet capable. Taking an RSVP-TE MPLS network as an example, where end systems are not part of the DetNet domain:

1. Network nodes collect topology information and DetNet capabilities of the network nodes through IGP.
2. The ingress edge node receives a flow establishment request from the UNI and calculates one or more valid paths.
3. The ingress node sends a PATH message with an explicit route through RSVP-TE. After receiving the PATH message, the egress edge node sends a RESV message with the distributed label and resource reservation request.

In this example, both the IGP and RSVP-TE may require extensions for DetNet.

Fully Centralized Control Plane In the fully centralized configuration model (e.g., using an SDN controller), 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. Network node configurations for DetNet flows are performed by the controller using a protocol such as NETCONF , YANG , DetNet YANG , or a PCE-based central controller (PCE-CC) . Take the following case as an example:

1. A centralized controller collects topology information and DetNet capabilities of the network nodes via NETCONF/YANG.
2. The controller receives a flow establishment request from a UNI and calculates one or more valid paths through the network.
3. The controller chooses the optimal path and configures the devices along that path for DetNet flow transmission via PCE-CC.

The protocols in the above example may require extensions for DetNet.

Hybrid Control Plane (Partly Centralized and Partly Distributed) In the hybrid model, the controller and control plane protocols work together to provide DetNet services, and there are a number of possible combinations. In the following case, the RSVP-TE and controller are used together:

1. A controller collects topology information and DetNet capabilities of the network nodes via an IGP and/or the Border Gateway Protocol - Link State (BGP-LS) .
2. A controller receives a flow establishment request through API and calculates one or more valid paths through the network.
3. Based on the calculation result, the controller distributes flow path information to the ingress edge node and configures network nodes along the path with necessary DetNet information (e.g., for replication/duplicate elimination).
4. Using RSVP-TE, the ingress edge node sends a PATH message with an explicit route. After receiving the PATH message, the egress edge node sends a RESV message with the distributed label and resource reservation request.

There are many other variations that could be included in a hybrid control plane. The requested DetNet extensions for a protocol in each possible case is for future work.

DetNet Control Plane for DetNet Mechanisms This section discusses the requested control plane features for DetNet mechanisms as defined in , including PREOF. Different DetNet services may implement any or all of these based on the requirements.

Explicit Paths Explicit paths are required in DetNet to provide a stable forwarding service and guarantee that the DetNet service is not impacted when the network topology changes. The following features are necessary in the control plane to implement explicit paths in DetNet:

• Path computation: DetNet explicit paths need to meet the Service Level Agreement (SLA) requirements of the application, which include bandwidth, maximum end-to-end delay, maximum end-to-end delay variation, maximum loss ratio, etc. In a distributed network 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 centralized network system, the controller can compute paths satisfying the requirements of DetNet based on the network information collected from the DetNet domain.
• Path establishment: The computed path for the DetNet service has to be sent/configured/signaled to the network device so that the corresponding DetNet flow can pass through the network domain following the specified path.

Resource Reservation DetNet flows are supposed to be protected from congestion, so sufficient resource reservation for a DetNet service could protect a service from congestion. There are multiple types of resources in the network that could be allocated to DetNet flows, e.g., packet processing resources, buffer resources, and the bandwidth of the output port. The network resource requested by a specified DetNet service is determined by the SLA requirements and network capability.

• Resource Allocation: Port bandwidth is one of the basic attributes of a network device that is easy to obtain or calculate. In current traffic engineering implementations, network resource allocation is synonymous with bandwidth allocation. A DetNet flow is characterized by a traffic specification, as defined in , including attributes such as Interval, MaxPacketsPerInterval, and MaxPayloadSize. The traffic specification describes the worst case, rather than the average case, for the traffic to ensure that sufficient bandwidth and buffering resources are reserved to satisfy the traffic specification. However, in the case of DetNet, resource allocation is more than simple bandwidth reservation. For example, allocation of buffers and required queuing disciplines during forwarding may be required as well. Furthermore, resources must be ensured to execute DetNet service sub-layer functions on the node, such as protection and reordering through the use of PREOF.
• Device configuration with or without flow discrimination: The resource allocation can be guaranteed by device configuration. For example, an output port bandwidth reservation can be configured as a parameter of queue management and the port scheduling algorithm. When DetNet flows are aggregated, a group of DetNet flows share the allocated resource in the network device. When the DetNet flows are treated independently, the device should maintain a mapping relationship between a DetNet flow and its corresponding resources.

PREOF Support DetNet path redundancy is supported via Packet Replication, Elimination, and Ordering Functions (PREOF). A DetNet flow is replicated and forwarded by multiple networks paths to avoid packet loss caused by device or link failures. In general, current control plane mechanisms that can be used to establish an explicit path, whether distributed or centralized, support point-to-point (P2P) and point-to-multipoint (P2MP) path establishment. PREOF requires the ability to compute and establish a set of multiple paths (e.g., multiple Label Switched Path (LSP) segments in an MPLS network) from the point(s) of packet replication to the point(s) of packet merging and ordering. Mapping of DetNet flows or DetNet member flows to explicit path segments has to be ensured as well. Protocol extensions will be required to support these new features. Terminology will also be required to refer to this coordinated set of path segments (such as an "LSP graph" in the case of the DetNet MPLS data plane).

Data-Plane-Specific Considerations

DetNet in an MPLS Domain For the purposes of this document, "legacy MPLS" is defined as MPLS without the use of Segment Routing (see for a discussion of MPLS with Segment Routing) or MPLS Transport Profile (MPLS-TP) . In legacy MPLS domains, a dynamic control plane using distributed signaling protocols is typically used for the distribution of MPLS labels used for forwarding MPLS packets. The dynamic signaling protocols most commonly used for label distribution are LDP , RSVP-TE , and BGP (which enables BGP-based MPLS Layer 3 VPNs , Layer 2 VPNs , and EVPNs ). Any of these protocols could be used to distribute DetNet Service Labels (S-Labels) and Aggregation Labels (A-Labels) . As discussed in , S-Labels are similar to other MPLS service 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 LDP or BGP. If these were to be used for DetNet, they would require extensions to support DetNet-specific features, such as PREOF, aggregation (A-Labels), node resource allocation, and queue placement.

DetNet in an IP Domain For the purposes of this document, "legacy IP" is defined as IP without the use of Segment Routing (see for a discussion of IP with Segment Routing). It should be noted that a DetNet IP data plane is simpler than a DetNet MPLS data plane and doesn't support PREOF, so only one path per flow or flow aggregate is required. Therefore, possible protocol extensions are expected to be limited, e.g., to existing IP routing protocols.

DetNet in a Segment Routing Domain Segment Routing is a scalable approach to building network domains that provides explicit routing via source routing encoded in packet headers, and it is combined with centralized network control to compute paths through the network. Forwarding paths are distributed with associated policies to network edge nodes for use in packet headers. Segment Routing reduces the amount of network signaling associated with distributed signaling protocols, such as RSVP-TE, and also reduces the amount of state in core nodes compared with that required for legacy MPLS and IP routing, as the state is now in the packets rather than in the routers. This could be useful for DetNet, where a very large number of flows through a network domain are expected, which would otherwise require the instantiation of state for each flow traversing each node in the network. Note that the DetNet MPLS and IP data planes described in and were constructed to be compatible with both types of Segment Routing: Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6) .

Encapsulation and Metadata Support To effectively manage DetNet flows, the controller plane will need to have a clear understanding of the encapsulation and metadata capabilities of the underlying network nodes. This will require a control mechanism that can discover, configure, and manage these parameters for each flow. The controller plane needs to understand and manage the encapsulation and metadata capabilities of the network nodes to provision DetNet flows effectively. This process might need a discovery phase in which the controller discovers which encapsulation types (e.g., MPLS, IP) and metadata schemes (e.g., sequencing, timestamping) that each node supports. After discovery, the controller might instruct nodes on the specific encapsulation and companion metadata to apply for a given flow. This ensures that DetNet packets are handled consistently across the network. For example, the controller might instruct a node to use an MPLS header and add a sequence number for a particular flow.

Management Plane Overview The management plane includes the ability to statically provision 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.

DetNet Operations, Administration, and Maintenance (OAM) This document covers the general considerations for OAM.

OAM for Performance Monitoring (PM)

Active PM Active PM is performed by injecting OAM packets into the network to estimate the performance of the network and by then measuring the performance of those OAM packets. Adding extra traffic can affect the delay and throughput performance of the network, and for this reason, Active PM is not recommended for use in operational DetNet domains. However, it is a useful test tool when commissioning a new network or during troubleshooting.

Passive PM Passive PM, such as In Situ Operations, Administration, and Maintenance (IOAM) , monitors the actual service traffic in a network domain in order to measure its performance without having a detrimental effect on the network. As compared to Active PM, Passive PM is much preferred for use in DetNet domains.

OAM for Connectivity and Fault Management (CFM) The detailed requirements for CFM in a DetNet IP domain and a DetNet MPLS domain are defined in , , and , respectively.

Multi-Domain Aspects 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) as per-flow, per-hop behaviors installed in the DetNet nodes for each individual flow. Adding multi-domain support might require some support at the CPF. For example, CPFs of different domains, e.g., PCEs, need to discover each other and then authenticate and negotiate per-hop behaviors. Furthermore, in the case of wireless domains, per-domain functions specific to Reliable and Available Wireless (RAW) , such as Point of Local Repairs (PLRs), have to also be considered, e.g., in addition to the PCEs. Depending on the multi-domain support provided by the application plane, the controller plane might be relieved from some responsibilities (e.g., if the application plane takes care of splitting what needs to be provided by each domain).

IANA Considerations This document has no IANA actions.

Security Considerations This document provides a framework for the DetNet Controller Plane and does not include any protocol specifications. Any future specification that is defined to support the DetNet Controller Plane is expected to include the appropriate security considerations. For overall security considerations of DetNet, see and .

References Normative References This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1. This document provides an overall framework for the Deterministic Networking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well. This document describes the flow and service information model for Deterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes. A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties. This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection. This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents. Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow. Informative References Without Affiliation Work in Progress This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community. This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK] The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK] The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes. Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations. This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938). This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs. This document specifies the Deterministic Networking data plane when Time-Sensitive Networking (TSN) networks are interconnected over a DetNet MPLS network. This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology. This document specifies the Deterministic Networking (DetNet) MPLS data plane when operating over an IEEE 802.1 Time-Sensitive Networking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, they are taken from normative text in the referenced RFCs. This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network. In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. This document presents a timing model for sources, destinations, and Deterministic Networking (DetNet) transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods. The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service. This document defines format and usage principles of the Deterministic Networking (DetNet) service Associated Channel over a DetNet network with the MPLS data plane. The DetNet service Associated Channel can be used to carry test packets of active Operations, Administration, and Maintenance (OAM) protocols that are used to detect DetNet failures and measure performance metrics. In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. This document contains the specification for the Deterministic Networking (DetNet) YANG data model for configuration and operational data for DetNet flows. The model allows the provisioning of an end-to-end DetNet service on devices along the path without depending on any signaling protocol. It also specifies operational status for flows. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane.

Acknowledgments Thanks to , , and for their reviews and comments. The authors would also like to thank , , , , and for their comments during the different directorate and IESG reviews.

Contributors China Mobile

qinfengwei@chinamobile.com

Authors' Addresses Independent

agmalis@gmail.com

Huawei

gengxuesong@huawei.com

Huawei

mach.chen@huawei.com

Ericsson

balazs.a.varga@ericsson.com

Universidad Carlos III de Madrid

Av. Universidad, 30 Leganes, Madrid 28911 Spain +34 91624 6236 cjbc@it.uc3m.es http://www.it.uc3m.es/cjbc/