idnits 2.17.1 draft-malis-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 seems to have RFC 2119 boilerplate text. -- The document date (July 05, 2019) is 1757 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-01 == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-03 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-01 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-04 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-01 == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-04 == Outdated reference: A later version (-02) exists of draft-geng-detnet-dp-sol-srv6-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-02 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-01 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-00 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-mpls-over-tsn-00 == Outdated reference: A later version (-08) exists of draft-ietf-detnet-mpls-over-udp-ip-01 == Outdated reference: A later version (-01) exists of draft-ietf-detnet-topology-yang-00 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-tsn-vpn-over-mpls-00 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-02 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-04 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Malis 3 Internet-Draft Futurewei Technologies 4 Intended status: Informational X. Geng 5 Expires: January 6, 2020 M. Chen 6 Huawei 7 F. Qin 8 China Mobile 9 July 05, 2019 11 Deterministic Networking (DetNet) Controller Plane Framework 12 draft-malis-detnet-controller-plane-framework-01 14 Abstract 16 This document provides a framework overview for the Deterministic 17 Networking (DetNet) controller plane. It discusses concepts and 18 requirements that will be basis for Detnet controller plane solution 19 documents. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 6, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. DetNet Controller Plane Requirements . . . . . . . . . . . . 4 58 3. DetNet Control Plane Architecture . . . . . . . . . . . . . . 5 59 3.1. Distributed Control Plane and Signaling Protocols . . . . 5 60 3.2. SDN/Fully Centralized Control Plane . . . . . . . . . . . 6 61 3.3. Hybrid Control Plane . . . . . . . . . . . . . . . . . . 7 62 4. DetNet Control Plane Additional Details and Issues . . . . . 8 63 4.1. Explicit Paths . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Resource Reservation . . . . . . . . . . . . . . . . . . 8 65 4.3. PREOF Support . . . . . . . . . . . . . . . . . . . . . . 9 66 4.4. DetNet in a Traditional MPLS Domain . . . . . . . . . . . 9 67 4.5. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.6. DetNet with Segment Routing (SR) . . . . . . . . . . . . 10 69 5. Management Plane Overview . . . . . . . . . . . . . . . . . . 12 70 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 12 71 5.2. DetNet Operations, Administration and Maintenance (OAM) . 12 72 5.2.1. OAM for Performance Monitoring (PM) . . . . . . . . . 12 73 5.2.2. OAM for Fault/Defect Management (FM) . . . . . . . . 13 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 9.2. Informative References . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 Deterministic Networking (DetNet) provides the capability to carry 85 specified unicast and/or multicast data flows for real-time 86 applications with extremely low data loss rates and bounded latency 87 within a network domain. As discussed in the Deterministic 88 Networking Architecture [I-D.ietf-detnet-architecture], techniques 89 used to provide this capability include reserving data plane 90 resources for individual (or aggregated) DetNet flows in some or all 91 of the intermediate nodes along the path of the flow, providing 92 explicit routes for DetNet flows that do not immediately change with 93 the network topology, and distributing data from DetNet flow packets 94 over time and/or space to ensure delivery of each packet's data in 95 spite of the loss of a path. 97 The DetNet data plane is defined in a set of documents that are 98 anchored by the DetNet Data Plane Framework 99 [I-D.ietf-detnet-data-plane-framework] and the associated DetNet MPLS 100 [I-D.ietf-detnet-mpls] and IP [I-D.ietf-detnet-ip] data plane 101 specifications, with additional details and subnet mappings provided 102 in [I-D.ietf-detnet-ip-over-mpls], 103 [I-D.ietf-detnet-mpls-over-udp-ip], [I-D.ietf-detnet-mpls-over-tsn], 104 [I-D.ietf-detnet-ip-over-tsn], and 105 [I-D.ietf-detnet-tsn-vpn-over-mpls]. 107 While the Detnet Architecture and Data Plane Framework documents are 108 primarily concerned with data plane operations, they do contain some 109 references and requirements for functions that would be required in 110 order to automate DetNet service provisioning and monitoring via a 111 DetNet controller plane. The purpose of this document is to gather 112 these references and requirements into a single document and discuss 113 how various possible DetNet controller plane architectures could be 114 used to satisfy these requirements, while not providing the actual 115 protocol details for a DetNet controller plane solution. Such 116 controller plane protocol solutions will be the subject of subsequent 117 documents. 119 Note that in the DetNet overall architecture, the controller plane 120 includes what are more traditionally considered separate control and 121 management planes. Traditionally, the management plane is primarily 122 involved with node and network provisioning, operational OAM for 123 performance monitoring, and troubleshooting network behaviors and 124 outages, while the control plane is primarily responsible for the 125 instantiation and maintenance of flows, MPLS label allocation and 126 distribution, and active in-band or out-of-band signaling to support 127 these functions. In the DetNet architecture, all of this 128 functionality is combined into a single Controller Plane. See 129 Section 4.4.2 of [I-D.ietf-detnet-architecture] and the aggregation 130 of Control and Management planes in [RFC7426] for further details. 132 1.1. Terminology 134 This document uses the terminology established in the DetNet 135 Architecture [I-D.ietf-detnet-architecture], and the reader is 136 assumed to be familiar with that document and its terminology. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2. DetNet Controller Plane Requirements 146 Other DetNet documents, including [I-D.ietf-detnet-architecture] and 147 [I-D.ietf-detnet-data-plane-framework], contain requirements for the 148 Controller Plane. For convenience, these requirements have been 149 compiled here. The primary requirements of the DetNet Controller 150 Plane are that it must be able to: 152 o Support the dynamic creation, modification, and deletion of DetNet 153 flows. This may include some or all of explicit path 154 determination, link bandwidth reservations, restricting flows to 155 IEEE 802.1 Time-Sensitive Networking (TSN) links, node buffer and 156 other resource reservations, specification of required queuing 157 disciplines along the path, ability to manage bidirectional flows, 158 etc., as needed for a flow. 160 o Support DetNet flow aggregation and de-aggregation via the ability 161 to dynamically create and delete flow aggregates (FAs), and be 162 able to modify existing FAs by adding or deleting members. 164 o Operate in a converged network domain that contains both DetNet 165 and non-DetNet flows. 167 o Allow flow instantiation requests to originate in an end 168 application (via an Application Programming Interface (API), via 169 static provisioning, or via a dynamic control plane, such as a 170 centralized SDN controller or distributed signaling protocols. 171 See Section 3 for further discussion of these options. 173 o In the case of the DetNet MPLS data plane, manage DetNet S-Label 174 and F-Label allocation and distribution. 176 o Also in the case of the DetNet MPLS data plane, support packet 177 replication, duplicate elimination, and packet ordering functions 178 (PREOF), and to be able to place these functions at appropriate 179 places in the network. 181 o Support applications that require the ability to synchronize the 182 clocks in end systems to the extent supported by the DetNet data 183 plane. 185 o Support queue control techniques defined in Section 4.5 of 186 [I-D.ietf-detnet-architecture] and 187 [I-D.finn-detnet-bounded-latency] that require time 188 synchronization among network nodes. 190 o Advertise static and dynamic node and link resources such as 191 capabilities and adjacencies to other network nodes (for dynamic 192 signaling approaches) or to network controllers (for centralized 193 approaches). 195 o Adapt to network topology changes such as links or nodes failures. 197 o Scale to handle the number of DetNet flows expected in a domain 198 (which may require per-flow signaling or provisioning). This is 199 similar to scalability requirements associated with network 200 slicing [I-D.dong-spring-sr-for-enhanced-vpn]. 202 o Provision flow identification information at each of the nodes 203 along the path. Flow identification may differ depending on the 204 location in the network and the DetNet functionality (e.g. transit 205 node vs. relay node). 207 o Monitor the performance of DetNet flows to ensure that they are 208 meeting required objectives. 210 3. DetNet Control Plane Architecture 212 As noted in the Introduction, the DetNet control plane is responsible 213 for the instantiation and maintenance of flows, MPLS label allocation 214 and distribution, and active in-band or out-of-band signaling to 215 support these functions. 217 The following sections define three possible classes of DetNet 218 control plane architectures: a fully distributed control plane 219 utilizing dynamic signaling protocols, a fully centralized SDN-like 220 control plane, and a hybrid control plane. They discuss the various 221 information exchanges between entities in the network in each of 222 these architectures and the advantages and disadvantages of each 223 option. 225 In each of the following sections, examples are used to illustrate 226 possible mechanisms that could be used in each of the architectures. 227 These are not meant to be exhaustive or to preclude any other 228 possible mechanism that could be used in place of those used in the 229 examples. 231 3.1. Distributed Control Plane and Signaling Protocols 233 In a fully distributed configuration model, User-to-Network Interface 234 (UNI) information is transmitted over a (to-be-defined) DetNet UNI 235 protocol from the user side to the network side, and then UNI and 236 network configuration information propagate in the network via 237 distributed control plane signaling protocols. Using an RSVP-TE 238 traffic-engineered MPLS network as an example: 240 1. An IGP collects topology information and DetNet capabilities of 241 the network [draft-geng-detnet-info-distribution]; 243 2. The control plane of the ingress edge node receives a flow 244 establishment request from the UNI and calculates one or more 245 valid path(s); 247 3. Using RSVP-TE [RFC3209], the ingress edge node sends a PATH 248 message with an explicit route. After receiving the PATH 249 message, the egress edge node sends a RESV message with the 250 distributed label and resource reservation request. 252 Current reservation-oriented distributed control plane protocols, 253 e.g. RSVP-TE and Stream Reservation Protocol (SRP) 254 [IEEE.802.1Qcc-2018], can only reserve bandwidth along the path, 255 while the configuration of a fine-grained schedule, e.g., Time Aware 256 Shaping (TAS) [IEEE.802.1QBV_2015], is not supported. If RSVP-TE or 257 SRP were to be used for a DetNet application, it would require 258 extensions in order to support queue and scheduler reservations in 259 addition to bandwidth reservation. 261 As discussed in Section 4.9 of [I-D.ietf-detnet-architecture], 262 scalability is a primary concern for DetNet, given the large number 263 of expected flows in a DetNet domain. This could potentially be much 264 larger than, for example, the number of MPLS traffic tunnels in a 265 network using MPLS traffic engineering, which would typically be 266 N*(N-1) tunnels, where N is the number of edge routers in the domain. 268 Even when flow aggregation is used, DetNet domains can be expected to 269 support a very large number of flows that will need particular 270 queuing disciplines and/or resource allocation, depending on the 271 requirements for each flow. This could require a large amount of 272 dynamic signaling, such as an RSVP-TE session to establish and 273 maintain each flow. Other RSVP-TE scalability concerns are further 274 discussed in [RFC5439]. 276 All of the above tends to argue against a purely distributed control 277 plane for DetNet domains. 279 3.2. SDN/Fully Centralized Control Plane 281 In the fully SDN/centralized configuration model, UNI information is 282 transmitted from a Centralized User Configuration (CUC) or from 283 applications via an API or northbound interface to a Centralized 284 Controller, which is the sole source of routing and forwarding 285 information for the domain. Configurations of nodes for DetNet flows 286 are performed by the controller using a protocol such as NETCONF 287 [RFC6241]/YANG [RFC6020] or PCE-CC [RFC8283]. For example: 289 1. The controller collects topology information and DetNet 290 capabilities of the network via NETCONF/YANG; 292 2. The controller receives a flow establishment request from a UNI 293 and calculates one or more valid path(s) through the network; 295 3. The controller chooses the optimal path and configures the 296 devices along that path for flow transmission via PCE-CC. 298 3.3. Hybrid Control Plane 300 In the hybrid model, a controller and control plane protocols work 301 together to provide DetNet services, and there are a number of 302 possible combinations. For example: 304 1. A Centralized Controller collects topology information and DetNet 305 capabilities of the network via an IGP and/or BGP-LS [RFC7752]; 307 2. The controller receives a flow establishment request from a UNI 308 and calculates one or more valid path(s) through the network; 310 3. Based on the calculation result, the CNC distributes flow path 311 information to the ingress edge node and other information (e.g. 312 replication/duplicate elimination) to the relevant nodes. 314 4. Using RSVP-TE, the ingress edge node sends a PATH message with an 315 explicit route. After receiving the PATH message, the egress 316 edge node sends a RESV message with the distributed label and 317 resource reservation request. 319 or 321 1. The controller collects topology information and DetNet 322 capability of the network via an IGP or BGP-LS; 324 2. The control plane of the ingress edge node receives a flow 325 establishment request via a UNI; 327 3. The Ingress edge node sends the path establishment request to the 328 controller through PCEP [RFC5440]; 330 4. After path calculation, the CNC sends the path information of the 331 flow to the ingress edge node via PCEP; 333 5. Using RSVP-TE, the ingress edge node sends a PATH message with an 334 explicit route. After receiving the PATH message, the egress 335 edge node sends a RESV message with the distributed label and 336 resource reservation request. 338 There are many other variations that could be included in a hybrid 339 control plane. This document cannot discuss all the possible control 340 plane mechanisms that could be used in hybrid configuration models. 341 Every solution has its own mechanisms and corresponding parameters 342 that are required for it to work. 344 4. DetNet Control Plane Additional Details and Issues 346 This section discusses some additional DetNet control plane details 347 and issues. 349 4.1. Explicit Paths 351 Explicit paths are required in DetNet to provide a stable transport 352 service and guarantee that DetNet service is not effected when the 353 network topology changes. The following features are necessary to 354 have explicit paths in DetNet: 356 o Path computation: DetNet explicit paths need to meet the SLA 357 (Service Level Agreement) requirements and/or resource guarantees 358 from the application/client, which include bandwidth, maximum end- 359 to-end delay, maximum end-to-end delay variation, maximum loss 360 ratio, etc. In an distributed system with IGP-TE, CSPF 361 (Constrained Shortest Path First) can be used to compute a set of 362 feasible paths for a DetNet service. In a system with a network 363 controller, a PCE (Path Computation Engine) can compute paths 364 satisfying the requirements of DetNet with the network information 365 collected from the DetNet domain. 367 o Path establishment: Once the path has been computed, the options 368 discussed in Section 3 can be used to establish the path. Also 369 see Section 4.4 and Section 4.6 for some additional considerations 370 depending on the details of the network infrastructure. 372 o Strict or loose paths: An explicit path is strict when every 373 intermediate hop is specified so that its route can't change. An 374 explicit path is loose when any IGP route is allowed along the 375 path. Generally, end-to-end SLA guarantees require a strict 376 explicit path in DetNet. However, when the IGP route is known to 377 be able to meet the SLA requirements, loose explicit paths are 378 also acceptable. 380 4.2. Resource Reservation 382 Network congestion could cause uncontrolled delay and/or packet loss. 383 DetNet flows are supposed to be protected from congestion, so 384 sufficient resource reservation for DetNet service is necessary. 385 Resources in the network are complex and hard to quantize, and may 386 include such entities as packet processing resources, packet 387 buffering, port and link bandwidth, and so on. The resources a 388 particular flow requires are determined by the flow's characteristics 389 and SLA. 391 o Resource Allocation: Port bandwidth is one of the basic attributes 392 of a network device which is easy to obtain or calculate. In 393 current traffic engineering implementations, network resource 394 allocation is synonymous with bandwidth allocation. A DetNet flow 395 is characterized with a traffic specification as defined in 396 [I-D.ietf-detnet-flow-information-model], including attributes 397 such as Interval, Maximum Packets Per Interval, and Maximum 398 Payload Size. The traffic specification describes the worst case, 399 rather than the average case, for the traffic, to ensure that 400 sufficient bandwidth and buffering resources are reserved to 401 satisfy the traffic specification. 403 o Device configuration with or without flow discrimination: The 404 resource allocation can be guaranteed by device configuration. 405 For example, an output port bandwidth reservation can be 406 configured as a parameter of queue management and the port 407 scheduling algorithm. When DetNet flows are aggregated, a group 408 of DetNet flows share the allocated resource in the network 409 device. When the DetNet flows are treated independently, the 410 device should maintains a mapping relationship between a DetNet 411 flow and its corresponding resources. 413 4.3. PREOF Support 415 DetNet path redundancy is supported via packet replication and 416 duplicate elimination (PREOF). A DetNet flow is replicated and goes 417 through multiple networks paths to avoid packet loss caused by device 418 or link failures. In general, current control plane mechanisms that 419 can be used to establish an explicit path, whether distributed or 420 centralized, support point-to-point (P2P) and point-to-multipoint 421 (P2MP) path establishment. PREOF requires the ability to compute and 422 establish a point-to-multipoint-to-point (P2MP2P) path. Protocol 423 extensions will be required to support this new feature. 425 4.4. DetNet in a Traditional MPLS Domain 427 For the purposes of this document, "traditional MPLS" is defined as 428 MPLS without the use of segment routing (see Section 4.6 for a 429 discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. 431 In traditional MPLS domains, a dynamic control plane using 432 distributed signaling protocols is typically used for the 433 distribution of MPLS labels used for forwarding MPLS packets. The 434 dynamic signaling protocols most commonly used for label distribution 435 are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/ 436 MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]). 438 Any of these protocols could be used to distribute DetNet Service 439 Labels (S-Labels) and Aggregation Labels 440 (A-Labels)[I-D.ietf-detnet-mpls]. As discussed in 441 [I-D.ietf-detnet-data-plane-framework], S-Labels are similar to other 442 MPLS service labels, such as pseudowire, L3 VPN, and L2 VPN labels, 443 and could be distributed in a similar manner, such as through the use 444 of targeted LDP or BGP. If these were to be used for DetNet, they 445 would require extensions to support DetNet-specific features such as 446 PREOF, aggregation (A-Labels), node resource allocation, and queue 447 placement. 449 However, as discussed in Section 3.1, distributed signaling protocols 450 may have difficulty meeting DetNet's scalability requirements. MPLS 451 also allows SDN-like centralized label management and distribution as 452 an alternative to distributed signaling protocols, using protocols 453 such as PCEP and OpenFlow [OPENFLOW]. 455 PCEP, particularly when used as a part of PCE-CC, is a possible 456 candidate protocol to use for centralized management of traditional 457 MPLS-based DetNet domains. However, PCE path calculation algorithms 458 would need to be extended to include the location determination for 459 PREOF nodes in a path, and the means to signal the necessary resource 460 reservation and PREOF function placement information to network 461 nodes. See ((?I-D.ietf-pce-pcep-extension-for-pce-controller)) for 462 further discussion of PCE-CC and PCEP for centralized control of an 463 MPLS domain. 465 4.5. IP 467 In a later revision of this document, this section will discuss 468 necessary protocol extensions to existing IP routing protocols such 469 as IS-IS and BGP. It should be noted that a DetNet IP domain is 470 simpler than a DetNet MPLS domain, and doesn't support PREOF, so only 471 one path per flow or flow aggregate is required, with no path 472 merging. 474 4.6. DetNet with Segment Routing (SR) 476 Segment Routing [RFC8402] is a scalable approach to building network 477 domains that utilizes a combination of source routing in packet 478 headers and centralized network control to compute paths through the 479 network and distribute those paths with associated policy to network 480 edge nodes for use in packet headers. It greatly reduces the amount 481 of network signaling associated with distributed signaling protocols 482 such as RSVP-TE, and also greatly reduces the amount of state in core 483 nodes compared with that required for traditional MPLS and IP 484 routing, as the state is now in the packets rather than in the 485 routers. This is especially useful for DetNet, where a very large 486 number of flows through a network domain are expected, which would 487 otherwise require the instantiation of state for each flow traversing 488 each node in the network. 490 The DetNet MPLS and IP data planes were specifically constructed to 491 allow the use of DetNet with both types of segment routing, SR-MPLS 492 [I-D.ietf-spring-segment-routing-mpls] and SRv6 493 [I-D.ietf-6man-segment-routing-header]. 495 In the DetNet context, DetNet in an SR-MPLS or SRv6 data plane could 496 be used in conjunction with centralized flow management and complete 497 label stack distribution to Detnet domain entry nodes via a 498 centralized controller. Extensions to PCEP to allow the use of PCE- 499 CC with SR-MPLS 501 One possible architecture is PCE-CC combined with SR-MPLS or SRv6. 502 Extensions to PCEP to allow the use of PCE-CC with SR-MPLS are 503 described in [I-D.zhao-pce-pcep-extension-pce-controller-sr], with 504 SRv6 in [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 506 This approach would allow the details of packet or flow treatment to 507 be encoded directly in the SIDs on each packet in a flow to reduce 508 the amount of state in network nodes. This approach also allows the 509 integration of DetNet domains with general SR-based backbone networks 510 in a converged domain. In this approach, a new set of functions for 511 DetNet queuing treatments available in the DetNet domain would need 512 to be defined for inclusion in the SR stack. 514 This is not the only possible approach. There is ongoing work on a 515 number of alternative signaling mechanisms for MPLS-SR and SRv6, 516 including extensions to IGPs and BGP to support distributed 517 signaling. In addition, BGP-LS and BGP route reflectors could be 518 added for a hybrid solution. 520 A possible mostly centralized hybrid approach could be to use a PCE- 521 CC to push paths represented by SID lists while using BGP-LS to 522 collect network topology and link state information. An IGP is used 523 for the usual link state flooding in order to establish adjacencies, 524 but not for DetNet flow path calculations, only for best effort 525 traffic as usual. 527 A similar approach for network slicing that could be leveraged for 528 DetNet is described in [I-D.dong-spring-sr-for-enhanced-vpn]. 530 Also, note that SR cannot currently support DetNet PREOF 531 functionality without extensions. One possible approach could be to 532 combine SR with BIER-TE, as discussed in [I-D.ietf-bier-te-arch]. 533 Another possible approach specific to SRv6 is discussed in 534 [I-D.geng-detnet-dp-sol-srv6]. 536 5. Management Plane Overview 538 The Management Plane includes the ability to statically provision 539 network nodes and to use OAM to monitor DetNet performance and detect 540 outages or other issues at the DetNet layer. 542 5.1. Provisioning 544 Static provisioning in a Detnet network will be performed via the use 545 of appropriate YANG models, including [I-D.ietf-detnet-yang] and 546 [I-D.ietf-detnet-topology-yang]. 548 5.2. DetNet Operations, Administration and Maintenance (OAM) 550 The overall framework and requirements for DetNet OAM are discussed 551 in [I-D.mirsky-detnet-oam]. This document currently includes 552 additional OAM details that may eventually be merged into that 553 document. 555 5.2.1. OAM for Performance Monitoring (PM) 557 5.2.1.1. Active PM 559 Active PM is performed by injecting OAM packets into the network to 560 estimate the performance of the network by measuring the performance 561 of the OAM packets. Adding extra traffic can affect the delay and 562 throughput performance of the network, and for this reason active PM 563 is not recommended for use in operational DetNet domains. However, 564 it is a useful test tool when commissioning a new network. 566 5.2.1.2. Passive PM 568 Passive PM monitors the actual service traffic in a network domain in 569 order to measure its performance without having a detrimental affect 570 on the network. As compared to Active PM, Passive PM is much 571 preferred for use in DetNet domains. 573 A proposal for DetNet passive performance measurement is contained in 574 [I-D.chen-detnet-loss-delay]. 576 5.2.2. OAM for Fault/Defect Management (FM) 578 [I-D.mirsky-detnet-oam] contains requirements for fault/defect 579 detection and management in a DetNet domain. 581 6. IANA Considerations 583 This document has no actions for IANA. 585 Note to RFC Editor: this section may be removed on publication as an 586 RFC. 588 7. Security Considerations 590 The overall security considerations of DetNet are discussed in 591 [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. For 592 DetNet networks that make use of Segment Routing (whether SR-MPLS or 593 SRv6), the security considerations in [RFC8402] also apply. 595 DetNet networks that make use of a centralized controller plane may 596 be threatened by the loss of connectivity (whether accidental or 597 malicious) between the central controller and the network nodes, and/ 598 or the spoofing of control messages from the controller to the 599 network nodes. This is important since such networks depend on 600 centralized controllers to calculate flow paths and instantiate flow 601 state in the network nodes. For networks that use both DetNet and 602 Segment Routing with a centralized controller, this would also 603 include the calculation of SID lists and their installation in edge/ 604 border routers. 606 In both cases, such threats may be mitigated through redundant 607 controllers, the use of authentication between the controller(s) and 608 the network nodes, and other mechanisms for protection against DOS 609 attacks. A mechanism for supporting one or more alternative central 610 controllers and the ability to fail over to such an alternative 611 controller will be required. 613 8. Acknowledgments 615 Thanks to Jim Guichard, Donald Eastlake, and Stewart Bryant for their 616 review comments. 618 9. References 619 9.1. Normative References 621 [I-D.ietf-detnet-architecture] 622 Finn, N., Thubert, P., Varga, B., and J. Farkas, 623 "Deterministic Networking Architecture", draft-ietf- 624 detnet-architecture-13 (work in progress), May 2019. 626 [I-D.ietf-detnet-data-plane-framework] 627 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 628 Bryant, S., and J. Korhonen, "DetNet Data Plane 629 Framework", draft-ietf-detnet-data-plane-framework-01 630 (work in progress), July 2019. 632 [I-D.ietf-detnet-flow-information-model] 633 Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet 634 Flow Information Model", draft-ietf-detnet-flow- 635 information-model-03 (work in progress), March 2019. 637 [I-D.ietf-detnet-ip] 638 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 639 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 640 draft-ietf-detnet-ip-01 (work in progress), July 2019. 642 [I-D.ietf-detnet-mpls] 643 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 644 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 645 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 647 [I-D.ietf-detnet-security] 648 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 649 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 650 Networking (DetNet) Security Considerations", draft-ietf- 651 detnet-security-04 (work in progress), March 2019. 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 659 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 660 Defined Networking (SDN): Layers and Architecture 661 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 662 2015, . 664 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 665 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 666 May 2017, . 668 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 669 Decraene, B., Litkowski, S., and R. Shakir, "Segment 670 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 671 July 2018, . 673 9.2. Informative References 675 [I-D.chen-detnet-loss-delay] 676 Chen, M. and A. Malis, "DetNet Packet Loss and Delay 677 Performance Measurement", draft-chen-detnet-loss-delay-01 678 (work in progress), October 2018. 680 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 681 Negi, M., Li, Z., and X. Geng, "PCEP Procedures and 682 Protocol Extensions for Using PCE as a Central Controller 683 (PCECC) for SRv6", draft-dhody-pce-pcep-extension-pce- 684 controller-srv6-01 (work in progress), February 2019. 686 [I-D.dong-spring-sr-for-enhanced-vpn] 687 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and 688 Z. Li, "Segment Routing for Enhanced VPN Service", draft- 689 dong-spring-sr-for-enhanced-vpn-04 (work in progress), 690 July 2019. 692 [I-D.finn-detnet-bounded-latency] 693 Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, 694 B., and J. Farkas, "DetNet Bounded Latency", draft-finn- 695 detnet-bounded-latency-04 (work in progress), June 2019. 697 [I-D.geng-detnet-dp-sol-srv6] 698 Geng, X., Chen, M., and Y. Zhu, "DetNet SRv6 Data Plane 699 Encapsulation", draft-geng-detnet-dp-sol-srv6-01 (work in 700 progress), July 2019. 702 [I-D.ietf-6man-segment-routing-header] 703 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 704 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 705 Routing Header (SRH)", draft-ietf-6man-segment-routing- 706 header-21 (work in progress), June 2019. 708 [I-D.ietf-bier-te-arch] 709 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 710 Engineering for Bit Index Explicit Replication (BIER-TE)", 711 draft-ietf-bier-te-arch-02 (work in progress), May 2019. 713 [I-D.ietf-detnet-ip-over-mpls] 714 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 715 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over 716 MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in 717 progress), July 2019. 719 [I-D.ietf-detnet-ip-over-tsn] 720 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 721 Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time 722 Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- 723 tsn-00 (work in progress), May 2019. 725 [I-D.ietf-detnet-mpls-over-tsn] 726 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 727 Korhonen, "DetNet Data Plane: MPLS over IEEE 802.1 Time 728 Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over- 729 tsn-00 (work in progress), May 2019. 731 [I-D.ietf-detnet-mpls-over-udp-ip] 732 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 733 and J. Korhonen, "DetNet Data Plane: MPLS over UDP/IP", 734 draft-ietf-detnet-mpls-over-udp-ip-01 (work in progress), 735 July 2019. 737 [I-D.ietf-detnet-topology-yang] 738 Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic 739 Networking (DetNet) Topology YANG Model", draft-ietf- 740 detnet-topology-yang-00 (work in progress), January 2019. 742 [I-D.ietf-detnet-tsn-vpn-over-mpls] 743 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 744 Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive 745 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 746 mpls-00 (work in progress), May 2019. 748 [I-D.ietf-detnet-yang] 749 Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic 750 Networking (DetNet) Configuration YANG Model", draft-ietf- 751 detnet-yang-02 (work in progress), March 2019. 753 [I-D.ietf-spring-segment-routing-mpls] 754 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 755 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 756 data plane", draft-ietf-spring-segment-routing-mpls-22 757 (work in progress), May 2019. 759 [I-D.mirsky-detnet-oam] 760 Mirsky, G. and M. Chen, "Operations, Administration and 761 Maintenance (OAM) for Deterministic Networks (DetNet)", 762 draft-mirsky-detnet-oam-03 (work in progress), May 2019. 764 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 765 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 766 and Protocol Extensions for Using PCE as a Central 767 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 768 extension-pce-controller-sr-04 (work in progress), 769 February 2019. 771 [IEEE.802.1QBV_2015] 772 IEEE, "IEEE Standard for Local and metropolitan area 773 networks -- Bridges and Bridged Networks - Amendment 25: 774 Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, 775 DOI 10.1109/IEEESTD.2016.7572858, March 2016, 776 . 779 [IEEE.802.1Qcc-2018] 780 IEEE, "IEEE Standard for Local and Metropolitan Area 781 Networks -- Bridges and Bridged Networks -- Amendment 31: 782 Stream Reservation Protocol (SRP) Enhancements and 783 Performance Improvements", IEEE 802.1Qcc-2018, 784 DOI 10.1109/ieeestd.2018.8514112, October 2018, 785 . 788 [OPENFLOW] 789 Open Networking Foundation, "OpenFlow Switch 790 Specification, Version 1.5.1 (Protocol version 0x06)", 791 ONF TS-025, March 2015, . 794 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 795 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 796 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 797 . 799 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 800 RFC 4384, DOI 10.17487/RFC4384, February 2006, 801 . 803 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 804 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 805 October 2007, . 807 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 808 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 809 DOI 10.17487/RFC5439, February 2009, 810 . 812 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 813 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 814 DOI 10.17487/RFC5440, March 2009, 815 . 817 [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS 818 Transport Profile Data Plane Architecture", RFC 5960, 819 DOI 10.17487/RFC5960, August 2010, 820 . 822 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 823 the Network Configuration Protocol (NETCONF)", RFC 6020, 824 DOI 10.17487/RFC6020, October 2010, 825 . 827 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 828 and A. Bierman, Ed., "Network Configuration Protocol 829 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 830 . 832 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 833 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 834 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 835 2015, . 837 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 838 S. Ray, "North-Bound Distribution of Link-State and 839 Traffic Engineering (TE) Information Using BGP", RFC 7752, 840 DOI 10.17487/RFC7752, March 2016, 841 . 843 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 844 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 845 . 847 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 848 Architecture for Use of PCE and the PCE Communication 849 Protocol (PCEP) in a Network with Central Control", 850 RFC 8283, DOI 10.17487/RFC8283, December 2017, 851 . 853 Authors' Addresses 855 Andrew G. Malis 856 Futurewei Technologies 858 Email: agmalis@gmail.com 860 Xuesong Geng 861 Huawei 863 Email: gengxuesong@huawei.com 865 Mach (Guoyi) Chen 866 Huawei 868 Email: mach.chen@huawei.com 870 Fengwei Qin 871 China Mobile 873 Email: qinfengwei@chinamobile.com