idnits 2.17.00 (12 Aug 2021) /tmp/idnits59444/draft-ietf-detnet-controller-plane-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (25 October 2021) is 201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-detnet-flow-information-model' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC5439' is defined on line 758, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-detnet-bounded-latency-07 == Outdated reference: draft-ietf-detnet-flow-information-model has been published as RFC 9016 == Outdated reference: A later version (-04) exists of draft-ietf-detnet-ip-oam-03 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-mpls-oam-05 == Outdated reference: draft-ietf-detnet-security has been published as RFC 9055 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-yang-06 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Malis 3 Internet-Draft Independent 4 Intended status: Informational X. Geng, Ed. 5 Expires: 28 April 2022 M. Chen 6 Huawei 7 F. Qin 8 China Mobile 9 B. Varga 10 Ericsson 11 25 October 2021 13 Deterministic Networking (DetNet) Controller Plane Framework 14 draft-ietf-detnet-controller-plane-framework-01 16 Abstract 18 This document provides a framework overview for the Deterministic 19 Networking (DetNet) controller plane. It discusses concepts and 20 requirements for DetNet controller plane which could be basis for 21 future solution specification. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 28 April 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. DetNet Controller Plane Requirements . . . . . . . . . . . . 4 59 2.1. DetNet Control Plane Requirements . . . . . . . . . . . . 4 60 2.2. DetNet Management Plane Requirements . . . . . . . . . . 5 61 2.3. Requirements For Both Planes . . . . . . . . . . . . . . 5 62 3. DetNet Control Plane Architecture . . . . . . . . . . . . . . 6 63 3.1. Distributed Control Plane and Signaling Protocols . . . . 6 64 3.2. SDN/Fully Centralized Control Plane . . . . . . . . . . . 7 65 3.3. Hybrid Control Plane (partly centralized, partly 66 distributed) . . . . . . . . . . . . . . . . . . . . . . 7 67 4. DetNet Control Plane for DetNet Mechanisms . . . . . . . . . 8 68 4.1. Explicit Paths . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. Resource Reservation . . . . . . . . . . . . . . . . . . 8 70 4.3. PREOF Support . . . . . . . . . . . . . . . . . . . . . . 9 71 4.4. Data Plane specific considerations . . . . . . . . . . . 9 72 4.4.1. DetNet in an MPLS Domain . . . . . . . . . . . . . . 9 73 4.4.2. DetNet in an IP Domain . . . . . . . . . . . . . . . 10 74 4.4.3. DetNet in a Segment Routing Domain . . . . . . . . . 11 75 5. Management Plane Overview . . . . . . . . . . . . . . . . . . 11 76 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 11 77 5.2. DetNet Operations, Administration and Maintenance 78 (OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.2.1. OAM for Performance Monitoring (PM) . . . . . . . . . 12 80 5.2.2. OAM for Connectivity and Fault/Defect Management 81 (CFM) . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 88 10.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 Deterministic Networking (DetNet) provides the capability to carry 94 specified unicast and/or multicast data flows for real-time 95 applications with extremely low data loss rates and bounded latency 96 within a network domain. As defined in [RFC8655], techniques used to 97 provide DetNet capability include reserving data plane resources for 98 individual (or aggregated) DetNet flows in some or all of the 99 intermediate nodes along the path of the flow, providing explicit 100 routes for DetNet flows that do not immediately change with the 101 network topology, and distributing data from DetNet flow packets over 102 time and/or space to ensure delivery of each packet's data in spite 103 of the loss of a path. 105 DetNet data plane is defined in a set of documents that are anchored 106 by the DetNet Data Plane Framework[RFC8938] (and the associated 107 DetNet MPLS defined in [RFC8964] and DetNet IP defined in [RFC8939] 108 and other data plane specifications defined in [RFC9023], [RFC9024], 109 [RFC9025], [RFC9037] and [RFC9056]) 111 While the Detnet Architecture and Data Plane documents are primarily 112 concerned with data plane operations, they do contain some 113 requirements for functions that would be required in order to 114 automate DetNet service provisioning and monitoring via a DetNet 115 controller plane. The purpose of this document is to gather these 116 requirements into a single document and discuss how various possible 117 DetNet controller plane architectures could be used to satisfy these 118 requirements, while not providing the protocol details for a DetNet 119 controller plane solution. Such controller plane protocol solutions 120 will be the subject of subsequent documents. 122 Note that in the DetNet overall architecture, the controller plane 123 includes what are more traditionally considered separate control and 124 management planes. Traditionally, the management plane is primarily 125 involved with fault management, configuration management and 126 performance management(sometimes accounting management and security 127 management is also considered in the management plane, but not in the 128 scope of this document). , while the control plane is primarily 129 responsible for the instantiation and maintenance of flows, MPLS 130 label allocation and distribution, and active in-band or out-of-band 131 signaling to support DetNet functions. In the DetNet architecture, 132 all of this functionality is combined into a single Controller Plane. 133 See Section 4.4.2 of [RFC8655] and the aggregation of Control and 134 Management planes in [RFC7426] for further details. 136 1.1. Terminology 138 This document uses the terminology established in the DetNet 139 Architecture [RFC8655], and the reader is assumed to be familiar with 140 that document and its terminology. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174]when, and only when, they appear in all 146 capitals, as shown here. 148 2. DetNet Controller Plane Requirements 150 Other DetNet documents, including [RFC8655] and [RFC8938], contain 151 requirements for the Controller Plane. For convenience, these 152 requirements have been compiled here. These requirements have been 153 organized into 3 groups, including: requirements primarily applicable 154 to control plane, requirements primarily applicable to management 155 plane and requirements applicable to both planes. 157 2.1. DetNet Control Plane Requirements 159 The primary requirements for the DetNet Control Plane include: 161 * Support the dynamic creation, modification, and deletion of DetNet 162 flows. This may include some or all of explicit path 163 determination, link bandwidth reservations, restricting flows to 164 specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN) 165 links), node buffer and other resource reservations, specification 166 of required queuing disciplines along the path, ability to manage 167 bidirectional flows, etc., as needed for a flow. 169 * Support DetNet flow aggregation and de-aggregation via the ability 170 to dynamically create and delete flow aggregates (FAs), and be 171 able to modify existing FAs by adding or deleting participating 172 flows. 174 * Allow flow instantiation requests to originate in an end 175 application (via an Application Programming Interface (API), via 176 static provisioning, or via a dynamic control plane, such as a 177 centralized SDN controller or distributed signaling protocols. 178 See Section 3 for further discussion of these options. 180 * In the case of the DetNet MPLS data plane, manage DetNet Service 181 Label (S-Label), Forwarding Label (F-Label), and Aggregation Label 182 (A-Label) [RFC8964] allocation and distribution. 184 * Also in the case of the DetNet MPLS data plane, support the DetNet 185 service sub-layer, which provides DetNet service functions such as 186 protection and reordering through the use of packet replication, 187 duplicate elimination, and packet ordering functions (PREOF). 189 * Support queue control techniques defined in Section 4.5 of 190 [RFC8655] and [I-D.ietf-detnet-bounded-latency] that require time 191 synchronization among network nodes. 193 * Advertise static and dynamic node and link resources such as 194 capabilities and adjacencies to other network nodes (for dynamic 195 signaling approaches) or to network controllers (for centralized 196 approaches). 198 * Scale to handle the number of DetNet flows expected in a domain 199 (which may require per-flow signaling or provisioning). 201 * Provision flow identification information at each of the nodes 202 along the path. Flow identification may differ depending on the 203 location in the network and the DetNet functionality (e.g. transit 204 node vs. relay node). 206 2.2. DetNet Management Plane Requirements 208 The primary requirements of the DetNet Management Plane are that it 209 must be able to: 211 * Monitor the performance of DetNet flows and nodes to ensure that 212 they are meeting required objectives, both proactively and on- 213 demand. 215 * Support DetNet flow continuity check and connectivity verification 216 functions. 218 * Support testing and monitoring of packet replication, duplicate 219 elimination, and packet ordering functionality in the DetNet 220 domain. 222 2.3. Requirements For Both Planes 224 The following requirements apply to both the DetNet Controller and 225 Management Planes: 227 * Operate in a converged network domain that contains both DetNet 228 and non-DetNet flows. 230 * Adapt to DetNet domain topology changes such as links or nodes 231 failures (fault recovery/restoration), additions and removals. 233 3. DetNet Control Plane Architecture 235 As noted in the Introduction, the DetNet control plane is responsible 236 for the instantiation and maintenance of flows, allocation and 237 distribution of flow related information (e.g., MPLS label), and 238 active in-band or out-of-band information distribution to support 239 these functions. 241 The following sections define three types of DetNet control plane 242 architectures: a fully distributed control plane utilizing dynamic 243 signaling protocols, a fully centralized SDN-like control plane, and 244 a hybrid control plane containing both distributed protocols and 245 centralized controlling . This document describes the various 246 information exchanges between entities in the network for Each type 247 of these architectures and the corresponding advantages and 248 disadvantages. 250 In each of the following sections, there are examples to illustrate 251 possible mechanisms that could be used in each type of the 252 architectures. They are not meant to be exhaustive or to preclude 253 any other possible mechanism that could be used in place of those 254 used in the examples. 256 3.1. Distributed Control Plane and Signaling Protocols 258 In a fully distributed configuration model, User-to-Network Interface 259 (UNI) information is transmitted over a DetNet UNI protocol from the 260 user side to the network side.Then UNI and network configuration 261 information propagate in the network via distributed control plane 262 signaling protocols. Such a DetNet UNI protocol is not necessary in 263 case that the End-systems are DetNet capable. 265 Taking an RSVP-TE MPLS network as an example, where end systems are 266 not part of the DetNet domain: 268 1. Network nodes collects topology information and DetNet 269 capabilities of the network nodes through IGP; 271 2. Ingress edge node receives a flow establishment request from the 272 UNI and calculates one or more valid path(s); 274 3. The ingress node sends a PATH message with an explicit route 275 through RSVP-TE [RFC3209]. After receiving the PATH message, the 276 egress edge node sends a RESV message with the distributed label 277 and resource reservation request. 279 In this example, both IGP and RSVT-TE may request extensions for 280 DetNet. 282 3.2. SDN/Fully Centralized Control Plane 284 In the fully SDN/centralized configuration model, flow/UNI 285 information is transmitted from a Centralized User Controller or from 286 applications via an API/ northbound interface to a Centralized 287 Controlle. Network node configurations for DetNet flows are 288 performed by the controller using a protocol such as NETCONF 289 [RFC6241]/YANG [RFC6020] or PCE-CC [RFC8283]. 291 Take the following case as an example:: 293 1. A Centralized Controller collects topology information and DetNet 294 capabilities of the network nodes via NETCONF/YANG; 296 2. The Controller receives a flow establishment request from a UNI 297 and calculates one or more valid path(s) through the network; 299 3. The Controller chooses the optimal path and configures the 300 devices along that path for DetNet flow transmission via PCE-CC. 302 Protocols in the above example may require extensions for DetNet. 304 3.3. Hybrid Control Plane (partly centralized, partly distributed) 306 In the hybrid model, controller and control plane protocols work 307 together to provide DetNet services, and there are a number of 308 possible combinations. 310 In the following case, RSVP-TE and controller are used together: 312 1. Controller collects topology information and DetNet capabilities 313 of the network nodes via an IGP and/or BGP-LS [RFC7752]; 315 2. Controller receives a flow establishment request through API and 316 calculates one or more valid path(s) through the network ; 318 3. Based on the calculation result, the Controller distributes flow 319 path information to the ingress edge node and configures network 320 nodes along the path with necessary DetNet information (e.g. for 321 replication/duplicate elimination) 323 4. Using RSVP-TE, the ingress edge node sends a PATH message with an 324 explicit route. After receiving the PATH message, the egress 325 edge node sends a RESV message with the distributed label and 326 resource reservation request. 328 There are many other variations that could be included in a hybrid 329 control plane. The requested DetNet extensions for protocol in each 330 possible case is for future work. 332 4. DetNet Control Plane for DetNet Mechanisms 334 This section discusses requested control plane features for DetNet 335 mechanisms as defined in [RFC8655], including explicit path, resource 336 reservation, service protection(PREOF). Different DetNet service may 337 implement part/all of them based on the requirements. 339 4.1. Explicit Paths 341 Explicit paths are required in DetNet to provide a stable forwarding 342 service and guarantee that DetNet service is not impacted when the 343 network topology changes. The following features are necessary in 344 control plane to implement explicit paths in DetNet: 346 * Path computation: DetNet explicit paths need to meet the SLA 347 (Service Level Agreement) requirements of the application, which 348 include bandwidth, maximum end- to-end delay, maximum end-to-end 349 delay variation, maximum loss ratio, etc. In a distributed 350 network system, IGP with CSPF (Constrained Shortest Path First) 351 may be used to compute a set of feasible paths for a DetNet 352 service. In a centralized network system, controller can compute 353 paths satisfying the requirements of DetNet based on the network 354 information collected from the DetNet domain. 356 * Path establishment: The computed path for the DetNet service has 357 to be sent/configured/signaled to the network device, so the 358 corresponding DetNet flow could pass through the network domain 359 following the specified path. 361 4.2. Resource Reservation 363 DetNet flows are supposed to be protected from congestion, so 364 sufficient resource reservation for DetNet service could protect 365 service from congestion. There are multiple types of resources in 366 the network that could be allocated to DetNet flows, e.g., packet 367 processing resource, buffer resource, and bandwidth of the output 368 port. The network resource requested by a specified DetNet service 369 is determined by the SLA requirements and network capability. 371 * Resource Allocation: Port bandwidth is one of the basic attributes 372 of a network device which is easy to obtain or calculate. In 373 current traffic engineering implementations, network resource 374 allocation is synonymous with bandwidth allocation. A DetNet flow 375 is characterized with a traffic specification as defined in 377 [RFC9016], including attributes such as Interval, Maximum Packets 378 Per Interval, and Maximum Payload Size. The traffic specification 379 describes the worst case, rather than the average case, for the 380 traffic, to ensure that sufficient bandwidth and buffering 381 resources are reserved to satisfy the traffic specification. 382 However, in case of DetNet, resource allocation is more than 383 simple bandwidth reservation. For example, allocation of buffers 384 and required queuing disciplines during forwarding may be required 385 as well. Furthermore, resources must be ensured to execute DetNet 386 service sub-layer functions on the node, such as protection and 387 reordering through the use of packet replication, duplicate 388 elimination, and packet ordering functions (PREOF). 390 * Device configuration with or without flow discrimination: The 391 resource allocation can be guaranteed by device configuration. 392 For example, an output port bandwidth reservation can be 393 configured as a parameter of queue management and the port 394 scheduling algorithm. When DetNet flows are aggregated, a group 395 of DetNet flows share the allocated resource in the network 396 device. When the DetNet flows are treated independently, the 397 device should maintains a mapping relationship between a DetNet 398 flow and its corresponding resources. 400 4.3. PREOF Support 402 DetNet path redundancy is supported via packet replication, duplicate 403 elimination, and packet ordering functions (PREOF). A DetNet flow is 404 replicated and goes through multiple networks paths to avoid packet 405 loss caused by device or link failures. In general, current control 406 plane mechanisms that can be used to establish an explicit path, 407 whether distributed or centralized, support point-to-point (P2P) and 408 point-to-multipoint (P2MP) path establishment. PREOF requires the 409 ability to compute and establish a set of multiple paths (e.g., 410 multiple LSP segments in an MPLS network) from the point(s) of packet 411 replication to the point(s) of packet merging and ordering. Mapping 412 of DetNet (member) flows to explicit path segments has to be ensured 413 as well. Protocol extensions will be required to support these new 414 features. Terminology will also be required to refer to this 415 coordinated set of path segments (such as an "LSP graph" in case of 416 DetNet MPLS data plane). 418 4.4. Data Plane specific considerations 420 4.4.1. DetNet in an MPLS Domain 422 For the purposes of this document, "traditional MPLS" is defined as 423 MPLS without the use of segment routing (see Section 4.4.3 for a 424 discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. 426 In traditional MPLS domains, a dynamic control plane using 427 distributed signaling protocols is typically used for the 428 distribution of MPLS labels used for forwarding MPLS packets. The 429 dynamic signaling protocols most commonly used for label distribution 430 are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/ 431 MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]). 433 Any of these protocols could be used to distribute DetNet Service 434 Labels (S-Labels) and Aggregation Labels (A-Labels) [RFC8964]. As 435 discussed in [RFC8938], S-Labels are similar to other MPLS service 436 labels, such as pseudowire, L3 VPN, and L2 VPN labels, and could be 437 distributed in a similar manner, such as through the use of targeted 438 LDP or BGP. If these were to be used for DetNet, they would require 439 extensions to support DetNet-specific features such as PREOF, 440 aggregation (A-Labels), node resource allocation, and queue 441 placement. 443 However, as discussed in Section 3.1, distributed signaling protocols 444 may have difficulty meeting DetNet's scalability requirements. MPLS 445 also allows SDN-like centralized label management and distribution as 446 an alternative to distributed signaling protocols, using protocols 447 such as PCEP and OpenFlow [OPENFLOW]. 449 PCEP, particularly when used as a part of PCE-CC, is a possible 450 candidate protocol to use for centralized management of traditional 451 MPLS-based DetNet domains. However, PCE path calculation algorithms 452 would need to be extended to include the location determination for 453 PREOF nodes in a path, and the means to signal the necessary resource 454 reservation and PREOF function placement information to network 455 nodes. See ((?I-D.ietf-pce-pcep-extension-for-pce-controller)) for 456 further discussion of PCE-CC and PCEP for centralized control of an 457 MPLS domain. 459 4.4.2. DetNet in an IP Domain 461 For the purposes of this document, "traditional IP" is defined as IP 462 without the use of segment routing (see Section 4.4.3 for a 463 discussion of IP with segment routing). In a later revision of this 464 document, this section will discuss possible protocol extensions to 465 existing IP routing protocols such as OSPF, IS-IS, and BGP. It 466 should be noted that a DetNet IP data plane [RFC8939] is simpler than 467 a DetNet MPLS data plane [RFC8964], and doesn't support PREOF, so 468 only one path per flow or flow aggregate is required. 470 4.4.3. DetNet in a Segment Routing Domain 472 Segment Routing [RFC8402] is a scalable approach to building network 473 domains that provides explicit routing via source routing encoded in 474 packet headers and it is combined with centralized network control to 475 compute paths through the network. Forwarding paths are distributed 476 with associated policy to network edge nodes for use in packet 477 headers. As such, segment routing can be considered as a new data 478 plane for both MPLS and IP. It reduces the amount of network 479 signaling associated with distributed signaling protocols such as 480 RSVP-TE, and also reduces the amount of state in core nodes compared 481 with that required for traditional MPLS and IP routing, as the state 482 is now in the packets rather than in the routers. This could be 483 useful for DetNet, where a very large number of flows through a 484 network domain are expected, which would otherwise require the 485 instantiation of state for each flow traversing each node in the 486 network. However, further analysis is needed on the expected gain, 487 as DetNet flows may require various type of DetNet specific resources 488 as well. 490 In a later revision of this document, this section will discuss the 491 impact of DetNet on the Segment Routing Control and Management 492 planes. Note that the DetNet MPLS and IP data planes described in 493 [RFC8964] and [RFC8939] were constructed to be compatible with both 494 types of segment routing, SR-MPLS [RFC8660] and SRv6 495 [I-D.ietf-6man-segment-routing-header]. However, as of this writing, 496 traffic engineering and resource reservation for segment routing are 497 currently unsolved problems. 499 Editor's note: this section may be collapsed to previous sections and 500 listing MPLS segment routing in the MPLS section as one of the 501 possible explicit routing techniques for MPLS, and do the same for 502 IP. 504 5. Management Plane Overview 506 The Management Plane includes the ability to statically provision 507 network nodes and to use OAM to monitor DetNet performance and detect 508 outages or other issues at the DetNet layer. 510 5.1. Provisioning 512 Static provisioning in a Detnet network nodes will be performed via 513 the use of appropriate YANG models, including [I-D.ietf-detnet-yang] 514 and [I-D.ietf-detnet-topology-yang]. 516 5.2. DetNet Operations, Administration and Maintenance (OAM) 518 This document covers the general considerations for OAM. 520 5.2.1. OAM for Performance Monitoring (PM) 522 5.2.1.1. Active PM 524 Active PM is performed by injecting OAM packets into the network to 525 estimate the performance of the network by measuring the performance 526 of the OAM packets. Adding extra traffic can affect the delay and 527 throughput performance of the network, and for this reason active PM 528 is not recommended for use in operational DetNet domains. However, 529 it is a useful test tool when commissioning a new network or during 530 troubleshooting. 532 5.2.1.2. Passive PM 534 Passive PM monitors the actual service traffic in a network domain in 535 order to measure its performance without having a detrimental affect 536 on the network. As compared to Active PM, Passive PM is much 537 preferred for use in DetNet domains. 539 5.2.2. OAM for Connectivity and Fault/Defect Management (CFM) 541 The detailed requirements for connectivity and fault/defect detection 542 and management in DetNet IP domain and DetNet MPLS domain are defined 543 in respectively in [I-D.ietf-detnet-ip-oam] and 544 [I-D.ietf-detnet-mpls-oam]. 546 6. Gap Analysis 548 In a later revision of this document, this section will contain a gap 549 analysis of existing IETF control and management plane protocols not 550 already discussed elsewhere in this document for their ability (or 551 inability) to satisfy the requirements in Section 2, and discuss 552 possible protocol extensions to existing protocols to fill the gaps, 553 if any. 555 7. IANA Considerations 557 This document has no actions for IANA. 559 Note to RFC Editor: this section may be removed on publication as an 560 RFC. 562 8. Security Considerations 564 Editor's note: This section needs more details. 566 The overall security considerations of DetNet are discussed in 567 [RFC8655] and [I-D.ietf-detnet-security]. For DetNet networks that 568 make use of Segment Routing (whether SR-MPLS or SRv6), the security 569 considerations in [RFC8402] also apply. 571 DetNet networks that make use of a centralized controller plane may 572 be threatened by the loss of connectivity (whether accidental or 573 malicious) between the central controller and the network nodes, and/ 574 or the spoofing of control messages from the controller to the 575 network nodes. This is important since such networks depend on 576 centralized controllers to calculate flow paths and instantiate flow 577 state in the network nodes. For networks that use both DetNet and 578 Segment Routing with a centralized controller, this would also 579 include the calculation of SID lists and their installation in edge/ 580 border routers. 582 In both cases, such threats may be mitigated through redundant 583 controllers, the use of authentication between the controller(s) and 584 the network nodes, and other mechanisms for protection against DOS 585 attacks. A mechanism for supporting one or more alternative central 586 controllers and the ability to fail over to such an alternative 587 controller will be required. 589 9. Acknowledgments 591 Thanks to Jim Guichard, Donald Eastlake, and Stewart Bryant for their 592 review comments. 594 10. References 596 10.1. Normative References 598 [I-D.ietf-detnet-bounded-latency] 599 Finn, N., Boudec, J. L., Mohammadpour, E., Zhang, J., 600 Varga, B., and J. Farkas, "DetNet Bounded Latency", Work 601 in Progress, Internet-Draft, draft-ietf-detnet-bounded- 602 latency-07, 1 September 2021, 603 . 606 [I-D.ietf-detnet-flow-information-model] 607 Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 608 Fedyk, "DetNet Flow Information Model", Work in Progress, 609 Internet-Draft, draft-ietf-detnet-flow-information-model- 610 10, 15 May 2020, . 613 [I-D.ietf-detnet-ip-oam] 614 Mirsky, G., Chen, M., and D. Black, "Operations, 615 Administration and Maintenance (OAM) for Deterministic 616 Networks (DetNet) with IP Data Plane", Work in Progress, 617 Internet-Draft, draft-ietf-detnet-ip-oam-03, 19 September 618 2021, . 621 [I-D.ietf-detnet-mpls-oam] 622 Mirsky, G. and M. Chen, "Operations, Administration and 623 Maintenance (OAM) for Deterministic Networks (DetNet) with 624 MPLS Data Plane", Work in Progress, Internet-Draft, draft- 625 ietf-detnet-mpls-oam-05, 18 October 2021, 626 . 629 [I-D.ietf-detnet-security] 630 Mizrahi, T. and E. Grossman, "Deterministic Networking 631 (DetNet) Security Considerations", Work in Progress, 632 Internet-Draft, draft-ietf-detnet-security-10, 30 May 633 2020, . 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, 638 DOI 10.17487/RFC2119, March 1997, 639 . 641 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 642 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 643 Defined Networking (SDN): Layers and Architecture 644 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 645 2015, . 647 [RFC8174] "". 649 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 650 Decraene, B., Litkowski, S., and R. Shakir, "Segment 651 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 652 July 2018, . 654 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 655 "Deterministic Networking Architecture", RFC 8655, 656 DOI 10.17487/RFC8655, October 2019, 657 . 659 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 660 Bryant, "Deterministic Networking (DetNet) Data Plane 661 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 662 . 664 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 665 Bryant, "Deterministic Networking (DetNet) Data Plane: 666 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 667 . 669 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 670 S., and J. Korhonen, "Deterministic Networking (DetNet) 671 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 672 2021, . 674 [RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 675 Fedyk, "Flow and Service Information Model for 676 Deterministic Networking (DetNet)", RFC 9016, 677 DOI 10.17487/RFC9016, March 2021, 678 . 680 [RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, 681 "Deterministic Networking (DetNet) Data Plane: IP over 682 IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, 683 DOI 10.17487/RFC9023, June 2021, 684 . 686 [RFC9024] Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. 687 Fedyk, "Deterministic Networking (DetNet) Data Plane: IEEE 688 802.1 Time-Sensitive Networking over MPLS", RFC 9024, 689 DOI 10.17487/RFC9024, June 2021, 690 . 692 [RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 693 Bryant, "Deterministic Networking (DetNet) Data Plane: 694 MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April 695 2021, . 697 [RFC9037] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, 698 "Deterministic Networking (DetNet) Data Plane: MPLS over 699 IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9037, 700 DOI 10.17487/RFC9037, June 2021, 701 . 703 [RFC9056] Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. 704 Korhonen, "Deterministic Networking (DetNet) Data Plane: 705 IP over MPLS", RFC 9056, DOI 10.17487/RFC9056, October 706 2021, . 708 10.2. Informative References 710 [I-D.ietf-6man-segment-routing-header] 711 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 712 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 713 (SRH)", Work in Progress, Internet-Draft, draft-ietf-6man- 714 segment-routing-header-26, 22 October 2019, 715 . 718 [I-D.ietf-detnet-topology-yang] 719 Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic 720 Networking (DetNet) Topology YANG Model", Work in 721 Progress, Internet-Draft, draft-ietf-detnet-topology-yang- 722 00, 25 January 2019, . 725 [I-D.ietf-detnet-yang] 726 Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D. 727 Fedyk, "Deterministic Networking (DetNet) Configuration 728 YANG Model", Work in Progress, Internet-Draft, draft-ietf- 729 detnet-yang-06, 11 June 2020, . 732 [IEEE.802.1QBV_2015] 733 IEEE, "IEEE Standard for Local and metropolitan area 734 networks -- Bridges and Bridged Networks - Amendment 25: 735 Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, 736 DOI 10.1109/IEEESTD.2016.7572858, 18 March 2016, 737 . 740 [OPENFLOW] Open Networking Foundation, "OpenFlow Switch 741 Specification, Version 1.5.1 (Protocol version 0x06)", 742 ONF TS-025, March 2015, . 745 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 746 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 747 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 748 . 750 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 751 RFC 4384, DOI 10.17487/RFC4384, February 2006, 752 . 754 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 755 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 756 October 2007, . 758 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 759 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 760 DOI 10.17487/RFC5439, February 2009, 761 . 763 [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS 764 Transport Profile Data Plane Architecture", RFC 5960, 765 DOI 10.17487/RFC5960, August 2010, 766 . 768 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 769 the Network Configuration Protocol (NETCONF)", RFC 6020, 770 DOI 10.17487/RFC6020, October 2010, 771 . 773 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 774 and A. Bierman, Ed., "Network Configuration Protocol 775 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 776 . 778 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 779 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 780 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 781 2015, . 783 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 784 S. Ray, "North-Bound Distribution of Link-State and 785 Traffic Engineering (TE) Information Using BGP", RFC 7752, 786 DOI 10.17487/RFC7752, March 2016, 787 . 789 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 790 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 791 . 793 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 794 Architecture for Use of PCE and the PCE Communication 795 Protocol (PCEP) in a Network with Central Control", 796 RFC 8283, DOI 10.17487/RFC8283, December 2017, 797 . 799 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 800 Decraene, B., Litkowski, S., and R. Shakir, "Segment 801 Routing with the MPLS Data Plane", RFC 8660, 802 DOI 10.17487/RFC8660, December 2019, 803 . 805 Authors' Addresses 807 Andrew G. Malis 808 Independent 810 Email: agmalis@gmail.com 812 Xuesong Geng 813 Huawei 815 Email: gengxuesong@huawei.com 817 Mach (Guoyi) Chen 818 Huawei 820 Email: mach.chen@huawei.com 822 Fengwei Qin 823 China Mobile 825 Email: qinfengwei@chinamobile.com 827 Balazs Varga 828 Ericsson 830 Email: balazs.a.varga@ericsson.com