idnits 2.17.1 draft-malis-detnet-controller-plane-framework-05.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 (November 19, 2020) is 1248 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-10 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-ip-oam-00 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-09 == Outdated reference: A later version (-15) exists of draft-ietf-detnet-mpls-oam-01 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-10 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-06 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-03 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-mpls-over-tsn-03 == Outdated reference: A later version (-08) exists of draft-ietf-detnet-mpls-over-udp-ip-06 == 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-03 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-06 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 14 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 Independent 4 Intended status: Informational X. Geng 5 Expires: May 23, 2021 M. Chen 6 Huawei 7 F. Qin 8 China Mobile 9 B. Varga 10 Ericsson 11 November 19, 2020 13 Deterministic Networking (DetNet) Controller Plane Framework 14 draft-malis-detnet-controller-plane-framework-05 16 Abstract 18 This document provides a framework overview for the Deterministic 19 Networking (DetNet) controller plane. It discusses concepts and 20 requirements that will be basis for Detnet controller plane solution 21 documents. 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 May 23, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. DetNet Controller Plane Requirements . . . . . . . . . . . . 4 60 2.1. DetNet Control Plane Requirements . . . . . . . . . . . . 4 61 2.2. DetNet Management Plane Requirements . . . . . . . . . . 5 62 2.3. Requirements For Both Planes . . . . . . . . . . . . . . 5 63 3. DetNet Control Plane Architecture . . . . . . . . . . . . . . 6 64 3.1. Distributed Control Plane and Signaling Protocols . . . . 6 65 3.2. SDN/Fully Centralized Control Plane . . . . . . . . . . . 7 66 3.3. Combined Control Plane (partly centralized, partly 67 distributed) . . . . . . . . . . . . . . . . . . . . . . 8 68 4. DetNet Control Plane Additional Details and Issues . . . . . 8 69 4.1. Explicit Paths . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. Resource Reservation . . . . . . . . . . . . . . . . . . 9 71 4.3. PREOF Support . . . . . . . . . . . . . . . . . . . . . . 10 72 4.4. Data Plane specific considerations . . . . . . . . . . . 10 73 4.4.1. DetNet in an MPLS Domain . . . . . . . . . . . . . . 10 74 4.4.2. DetNet in an IP Domain . . . . . . . . . . . . . . . 11 75 4.4.3. DetNet in a Segment Routing Domain . . . . . . . . . 12 76 5. Management Plane Overview . . . . . . . . . . . . . . . . . . 12 77 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 12 78 5.2. DetNet Operations, Administration and Maintenance (OAM) . 13 79 5.2.1. OAM for Performance Monitoring (PM) . . . . . . . . . 13 80 5.2.2. OAM for Connectivity and Fault/Defect Management 81 (CFM) . . . . . . . . . . . . . . . . . . . . . . . . 13 82 6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 13 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 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 discussed in the Deterministic 97 Networking Architecture [RFC8655], techniques used to provide this 98 capability include reserving data plane resources for individual (or 99 aggregated) DetNet flows in some or all of the intermediate nodes 100 along the path of the flow, providing explicit routes for DetNet 101 flows that do not immediately change with the network topology, and 102 distributing data from DetNet flow packets over time and/or space to 103 ensure delivery of each packet's data in spite of the loss of a path. 105 The DetNet data plane is defined in a set of documents that are 106 anchored by the DetNet Data Plane Framework 107 [I-D.ietf-detnet-data-plane-framework] and the associated DetNet MPLS 108 [I-D.ietf-detnet-mpls] and DetNet IP [I-D.ietf-detnet-ip] data plane 109 specifications, with additional details and subnet mappings provided 110 in [I-D.ietf-detnet-ip-over-mpls], 111 [I-D.ietf-detnet-mpls-over-udp-ip], [I-D.ietf-detnet-mpls-over-tsn], 112 [I-D.ietf-detnet-ip-over-tsn], and interconnection of TSN networks 113 [I-D.ietf-detnet-tsn-vpn-over-mpls]. 115 While the Detnet Architecture and Data Plane Framework documents are 116 primarily concerned with data plane operations, they do contain some 117 references and requirements for functions that would be required in 118 order to automate DetNet service provisioning and monitoring via a 119 DetNet controller plane. The purpose of this document is to gather 120 these references and requirements into a single document and discuss 121 how various possible DetNet controller plane architectures could be 122 used to satisfy these requirements, while not providing the actual 123 protocol details for a DetNet controller plane solution. Such 124 controller plane protocol solutions will be the subject of subsequent 125 documents. 127 Note that in the DetNet overall architecture, the controller plane 128 includes what are more traditionally considered separate control and 129 management planes. Traditionally, the management plane is primarily 130 involved with node and network provisioning, operational OAM for 131 performance monitoring, and troubleshooting network behaviors and 132 outages, while the control plane is primarily responsible for the 133 instantiation and maintenance of flows, MPLS label allocation and 134 distribution, and active in-band or out-of-band signaling to support 135 these functions. In the DetNet architecture, all of this 136 functionality is combined into a single Controller Plane. See 137 Section 4.4.2 of [RFC8655] and the aggregation of Control and 138 Management planes in [RFC7426] for further details. 140 1.1. Terminology 142 This document uses the terminology established in the DetNet 143 Architecture [RFC8655], and the reader is assumed to be familiar with 144 that document and its terminology. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 2. DetNet Controller Plane Requirements 154 Other DetNet documents, including [RFC8655] and 155 [I-D.ietf-detnet-data-plane-framework], contain requirements for the 156 Controller Plane. For convenience, these requirements have been 157 compiled here. These requirements have been organized to show those 158 primarily related to the control plane, those primarily relate to the 159 management plane, and those applicable to both planes. 161 2.1. DetNet Control Plane Requirements 163 The primary requirements of the DetNet Control Plane are that it must 164 be able to: 166 o Support the dynamic creation, modification, and deletion of DetNet 167 flows. This may include some or all of explicit path 168 determination, link bandwidth reservations, restricting flows to 169 specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN) 170 links), node buffer and other resource reservations, specification 171 of required queuing disciplines along the path, ability to manage 172 bidirectional flows, etc., as needed for a flow. 174 o Support DetNet flow aggregation and de-aggregation via the ability 175 to dynamically create and delete flow aggregates (FAs), and be 176 able to modify existing FAs by adding or deleting participating 177 flows. 179 o Allow flow instantiation requests to originate in an end 180 application (via an Application Programming Interface (API), via 181 static provisioning, or via a dynamic control plane, such as a 182 centralized SDN controller or distributed signaling protocols. 183 See Section 3 for further discussion of these options. 185 o In the case of the DetNet MPLS data plane, manage DetNet Service 186 Label (S-Label), Forwarding Label (F-Label), and Aggregation Label 187 (A-Label) [I-D.ietf-detnet-mpls] allocation and distribution. 189 o Also in the case of the DetNet MPLS data plane, support the DetNet 190 service sub-layer, which provides DetNet service functions such as 191 protection and reordering through the use of packet replication, 192 duplicate elimination, and packet ordering functions (PREOF). 194 o Support queue control techniques defined in Section 4.5 of 195 [RFC8655] and [I-D.finn-detnet-bounded-latency] that require time 196 synchronization among network nodes. 198 o Advertise static and dynamic node and link resources such as 199 capabilities and adjacencies to other network nodes (for dynamic 200 signaling approaches) or to network controllers (for centralized 201 approaches). 203 o Scale to handle the number of DetNet flows expected in a domain 204 (which may require per-flow signaling or provisioning). 206 o Provision flow identification information at each of the nodes 207 along the path. Flow identification may differ depending on the 208 location in the network and the DetNet functionality (e.g. transit 209 node vs. relay node). 211 2.2. DetNet Management Plane Requirements 213 The primary requirements of the DetNet Management Plane are that it 214 must be able to: 216 o Monitor the performance of DetNet flows and nodes to ensure that 217 they are meeting required objectives, both proactively and on- 218 demand. 220 o Support DetNet flow continuity check and connectivity verification 221 functions. 223 o Support testing and monitoring of packet replication, duplicate 224 elimination, and packet ordering functionality in the DetNet 225 domain. 227 2.3. Requirements For Both Planes 229 The following requirements apply to both the DetNet Controller and 230 Management Planes: 232 o Operate in a converged network domain that contains both DetNet 233 and non-DetNet flows. 235 o Adapt to DetNet domain topology changes such as links or nodes 236 failures (fault recovery/restoration), additions and removals. 238 3. DetNet Control Plane Architecture 240 As noted in the Introduction, the DetNet control plane is responsible 241 for the instantiation and maintenance of flows, allocation and 242 distribution of flow related information (e.g., MPLS label), and 243 active in-band or out-of-band information distribution to support 244 these functions. 246 The following sections define three possible classes of DetNet 247 control plane architectures: a fully distributed control plane 248 utilizing dynamic signaling protocols, a fully centralized SDN-like 249 control plane, and a control plane combining these two. They discuss 250 the various information exchanges between entities in the network in 251 each of these architectures and the advantages and disadvantages of 252 each option. 254 In each of the following sections, examples are used to illustrate 255 possible mechanisms that could be used in each of the architectures. 256 These are not meant to be exhaustive or to preclude any other 257 possible mechanism that could be used in place of those used in the 258 examples. 260 3.1. Distributed Control Plane and Signaling Protocols 262 In a fully distributed configuration model, User-to-Network Interface 263 (UNI) information is transmitted over a (to-be-defined) DetNet UNI 264 protocol from the user side to the network side, and then UNI and 265 network configuration information propagate in the network via 266 distributed control plane signaling protocols. Such a DetNet UNI 267 protocol are not visible in case of DetNet capable End-systems. 269 Taking an RSVP-TE traffic-engineered MPLS network, where End systems 270 are not part of the DetNet domain, as a theoretical example: 272 1. An IGP collects topology information and DetNet capabilities of 273 the network nodes 275 2. The control plane of the ingress edge node receives a flow 276 establishment request from the UNI and calculates one or more 277 valid path(s); 279 3. Using RSVP-TE [RFC3209], the ingress edge node sends a PATH 280 message with an explicit route. After receiving the PATH 281 message, the egress edge node sends a RESV message with the 282 distributed label and resource reservation request. 284 IGP in the above example would require extensions to incorporate 285 DetNet capabilities. Similarly, current reservation-oriented 286 distributed control plane protocols, e.g. RSVP-TE, can only reserve 287 bandwidth along the path, while the configuration of a fine-grained 288 schedule, e.g., Enhancements for Scheduled Traffic 289 [IEEE.802.1QBV_2015], is not supported. If RSVP-TE were to be used 290 for serving a DetNet flow, it would require extensions in order to 291 support queue and scheduler reservations in addition to bandwidth 292 reservation. 294 As discussed in Section 4.9 of [RFC8655], scalability is a primary 295 concern for DetNet, given the large number of expected flows in a 296 DetNet domain. This could potentially be much larger than, for 297 example, the number of full-mesh MPLS traffic tunnels in a network 298 using MPLS traffic engineering, which would typically be N*(N-1) 299 tunnels, where N is the number of edge routers in the domain. 301 Even when flow aggregation is used, DetNet domains can be expected to 302 support a very large number of flows that will need particular 303 queuing disciplines and/or resource allocation, depending on the 304 requirements for each flow. This could require a large amount of 305 dynamic signaling, such as an RSVP-TE session to establish and 306 maintain each flow. Other RSVP-TE scalability concerns are further 307 discussed in [RFC5439]. 309 All of the above tends to argue against a purely distributed control 310 plane for DetNet domains. 312 3.2. SDN/Fully Centralized Control Plane 314 In the fully SDN/centralized configuration model, flow/UNI 315 information is transmitted from a Centralized User Configuration or 316 from applications via an API or northbound interface to a Centralized 317 Controller, which is the sole source of routing and forwarding 318 information for the domain. Configurations of nodes for DetNet flows 319 are performed by the controller using a protocol such as NETCONF 320 [RFC6241]/YANG [RFC6020] or PCE-CC [RFC8283]. 322 Taking again an MPLS network, where End systems are not part of the 323 DetNet domain, as a theoretical example: 325 1. A Centralized Controller collects topology information and DetNet 326 capabilities of the network nodes via NETCONF/YANG; 328 2. The Controller receives a flow establishment request from a UNI 329 and calculates one or more valid path(s) through the network; 331 3. The Controller chooses the optimal path and configures the 332 devices along that path for flow transmission via PCE-CC. 334 Protocols in the above example may require extensions to incorporate 335 DetNet specific parameters. 337 3.3. Combined Control Plane (partly centralized, partly distributed) 339 In the combined model, a Controller and control plane protocols work 340 together to provide DetNet services, and there are a number of 341 possible combinations. 343 Using an RSVP-TE traffic-engineered MPLS network with centralized PCE 344 (Path Computation Engine), where End systems are not part of the 345 DetNet domain, as a theoretical example: 347 1. A Centralized Controller collects topology information and DetNet 348 capabilities of the network nodes via an IGP and/or BGP-LS 349 [RFC7752]; 351 2. The Controller receives a flow establishment request from a 352 Network Management System and calculates one or more valid 353 path(s) through the network; 355 3. Based on the calculation result, the Controller distributes flow 356 path information to the ingress edge node and other information 357 (e.g. replication/duplicate elimination) to the relevant nodes. 359 4. Using RSVP-TE, the ingress edge node sends a PATH message with an 360 explicit route. After receiving the PATH message, the egress 361 edge node sends a RESV message with the distributed label and 362 resource reservation request. 364 Similarly to Distributed Control Plane and SDN/Fully Centralized 365 Control Plane scenarios extensions of protocols are required to 366 incorporate DetNet specific parameters. 368 There are many other variations that could be included in a combined 369 control plane. This document cannot discuss all the possible control 370 plane mechanisms that could be used in combined configuration models. 371 Every solution has its own mechanisms and corresponding parameters 372 that are required for it to work. 374 4. DetNet Control Plane Additional Details and Issues 376 This section discusses some additional DetNet control plane details 377 and issues. 379 4.1. Explicit Paths 381 Explicit paths are required in DetNet to provide a stable forwarding 382 service and guarantee that DetNet service is not impacted when the 383 network topology changes. The following features are necessary to 384 have explicit paths in DetNet: 386 o Path computation: DetNet explicit paths need to meet the SLA 387 (Service Level Agreement) requirements and/or resource guarantees 388 from the application/client, which include bandwidth, maximum end- 389 to-end delay, maximum end-to-end delay variation, maximum loss 390 ratio, etc. In a distributed system with IGP-TE, CSPF 391 (Constrained Shortest Path First) can be used to compute a set of 392 feasible paths for a DetNet service. In a system with a network 393 controller, a PCE (Path Computation Engine) can compute paths 394 satisfying the requirements of DetNet based on the network 395 information collected from the DetNet domain. 397 o Path establishment: Once the path has been computed, the options 398 discussed in Section 3 can be used to establish the path. Also 399 see Section 4.4.1 for some additional considerations depending on 400 the details of the network infrastructure. 402 o Strict or loose paths: An explicit path is strict when every 403 intermediate hop is specified so that its route can't change. An 404 explicit path is loose when any IGP route is allowed along the 405 path. Generally, end-to-end SLA guarantees require a strict 406 explicit path in DetNet. However, when the IGP route is known to 407 be able to meet the SLA requirements, loose explicit paths are 408 also acceptable. 410 4.2. Resource Reservation 412 Network congestion could cause uncontrolled delay and/or packet loss. 413 DetNet flows are supposed to be protected from congestion, so 414 sufficient resource reservation for DetNet service is necessary. 415 Resources in the network are complex and hard to quantize, and may 416 include such entities as packet processing resources, packet 417 buffering, port and link bandwidth, and so on. The resources a 418 particular flow requires are determined by the flow's characteristics 419 and SLA. 421 o Resource Allocation: Port bandwidth is one of the basic attributes 422 of a network device which is easy to obtain or calculate. In 423 current traffic engineering implementations, network resource 424 allocation is synonymous with bandwidth allocation. A DetNet flow 425 is characterized with a traffic specification as defined in 426 [I-D.ietf-detnet-flow-information-model], including attributes 427 such as Interval, Maximum Packets Per Interval, and Maximum 428 Payload Size. The traffic specification describes the worst case, 429 rather than the average case, for the traffic, to ensure that 430 sufficient bandwidth and buffering resources are reserved to 431 satisfy the traffic specification. However, in case of DetNet, 432 resource allocation is more than simple bandwidth reservation. 433 For example, allocation of buffers and required queuing 434 disciplines during forwarding may be required as well. 435 Furthermore, resources must be ensured to execute DetNet service 436 sub-layer functions on the node, such as protection and reordering 437 through the use of packet replication, duplicate elimination, and 438 packet ordering functions (PREOF). 440 o Device configuration with or without flow discrimination: The 441 resource allocation can be guaranteed by device configuration. 442 For example, an output port bandwidth reservation can be 443 configured as a parameter of queue management and the port 444 scheduling algorithm. When DetNet flows are aggregated, a group 445 of DetNet flows share the allocated resource in the network 446 device. When the DetNet flows are treated independently, the 447 device should maintains a mapping relationship between a DetNet 448 flow and its corresponding resources. 450 4.3. PREOF Support 452 DetNet path redundancy is supported via packet replication, duplicate 453 elimination, and packet ordering functions (PREOF). A DetNet flow is 454 replicated and goes through multiple networks paths to avoid packet 455 loss caused by device or link failures. In general, current control 456 plane mechanisms that can be used to establish an explicit path, 457 whether distributed or centralized, support point-to-point (P2P) and 458 point-to-multipoint (P2MP) path establishment. PREOF requires the 459 ability to compute and establish a set of multiple paths (e.g., 460 multiple LSP segments in an MPLS network) from the point(s) of packet 461 replication to the point(s) of packet merging and ordering. Mapping 462 of DetNet (member) flows to explicit path segments has to be ensured 463 as well. Protocol extensions will be required to support these new 464 features. Terminology will also be required to refer to this 465 coordinated set of path segments (such as an "LSP graph" in case of 466 DetNet MPLS data plane). 468 4.4. Data Plane specific considerations 470 4.4.1. DetNet in an MPLS Domain 472 For the purposes of this document, "traditional MPLS" is defined as 473 MPLS without the use of segment routing (see Section 4.4.3 for a 474 discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. 476 In traditional MPLS domains, a dynamic control plane using 477 distributed signaling protocols is typically used for the 478 distribution of MPLS labels used for forwarding MPLS packets. The 479 dynamic signaling protocols most commonly used for label distribution 480 are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/ 481 MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]). 483 Any of these protocols could be used to distribute DetNet Service 484 Labels (S-Labels) and Aggregation Labels (A-Labels) 485 [I-D.ietf-detnet-mpls]. As discussed in 486 [I-D.ietf-detnet-data-plane-framework], S-Labels are similar to other 487 MPLS service labels, such as pseudowire, L3 VPN, and L2 VPN labels, 488 and could be distributed in a similar manner, such as through the use 489 of targeted LDP or BGP. If these were to be used for DetNet, they 490 would require extensions to support DetNet-specific features such as 491 PREOF, aggregation (A-Labels), node resource allocation, and queue 492 placement. 494 However, as discussed in Section 3.1, distributed signaling protocols 495 may have difficulty meeting DetNet's scalability requirements. MPLS 496 also allows SDN-like centralized label management and distribution as 497 an alternative to distributed signaling protocols, using protocols 498 such as PCEP and OpenFlow [OPENFLOW]. 500 PCEP, particularly when used as a part of PCE-CC, is a possible 501 candidate protocol to use for centralized management of traditional 502 MPLS-based DetNet domains. However, PCE path calculation algorithms 503 would need to be extended to include the location determination for 504 PREOF nodes in a path, and the means to signal the necessary resource 505 reservation and PREOF function placement information to network 506 nodes. See ((?I-D.ietf-pce-pcep-extension-for-pce-controller)) for 507 further discussion of PCE-CC and PCEP for centralized control of an 508 MPLS domain. 510 4.4.2. DetNet in an IP Domain 512 For the purposes of this document, "traditional IP" is defined as IP 513 without the use of segment routing (see Section 4.4.3 for a 514 discussion of IP with segment routing). In a later revision of this 515 document, this section will discuss possible protocol extensions to 516 existing IP routing protocols such as OSPF, IS-IS, and BGP. It 517 should be noted that a DetNet IP data plane [I-D.ietf-detnet-ip] is 518 simpler than a DetNet MPLS data plane [I-D.ietf-detnet-mpls], and 519 doesn't support PREOF, so only one path per flow or flow aggregate is 520 required. 522 4.4.3. DetNet in a Segment Routing Domain 524 Segment Routing [RFC8402] is a scalable approach to building network 525 domains that provides explicit routing via source routing encoded in 526 packet headers and it is combined with centralized network control to 527 compute paths through the network. Forwarding paths are distributed 528 with associated policy to network edge nodes for use in packet 529 headers. As such, segment routing can be considered as a new data 530 plane for both MPLS and IP. It reduces the amount of network 531 signaling associated with distributed signaling protocols such as 532 RSVP-TE, and also reduces the amount of state in core nodes compared 533 with that required for traditional MPLS and IP routing, as the state 534 is now in the packets rather than in the routers. This could be 535 useful for DetNet, where a very large number of flows through a 536 network domain are expected, which would otherwise require the 537 instantiation of state for each flow traversing each node in the 538 network. However, further analysis is needed on the expected gain, 539 as DetNet flows may require various type of DetNet specific resources 540 as well. 542 In a later revision of this document, this section will discuss the 543 impact of DetNet on the Segment Routing Control and Management 544 planes. Note that the DetNet MPLS and IP data planes described in 545 [I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip] were constructed to 546 be compatible with both types of segment routing, SR-MPLS [RFC8660] 547 and SRv6 [I-D.ietf-6man-segment-routing-header]. However, as of this 548 writing, traffic engineering and resource reservation for segment 549 routing are currently unsolved problems. 551 Editor's note: this section may be collapsed to previous sections and 552 listing MPLS segment routing in the MPLS section as one of the 553 possible explicit routing techniques for MPLS, and do the same for 554 IP. 556 5. Management Plane Overview 558 The Management Plane includes the ability to statically provision 559 network nodes and to use OAM to monitor DetNet performance and detect 560 outages or other issues at the DetNet layer. 562 5.1. Provisioning 564 Static provisioning in a Detnet network nodes will be performed via 565 the use of appropriate YANG models, including [I-D.ietf-detnet-yang] 566 and [I-D.ietf-detnet-topology-yang]. 568 5.2. DetNet Operations, Administration and Maintenance (OAM) 570 This document covers the general considerations for OAM. 572 5.2.1. OAM for Performance Monitoring (PM) 574 5.2.1.1. Active PM 576 Active PM is performed by injecting OAM packets into the network to 577 estimate the performance of the network by measuring the performance 578 of the OAM packets. Adding extra traffic can affect the delay and 579 throughput performance of the network, and for this reason active PM 580 is not recommended for use in operational DetNet domains. However, 581 it is a useful test tool when commissioning a new network or during 582 troubleshooting. 584 5.2.1.2. Passive PM 586 Passive PM monitors the actual service traffic in a network domain in 587 order to measure its performance without having a detrimental affect 588 on the network. As compared to Active PM, Passive PM is much 589 preferred for use in DetNet domains. 591 5.2.2. OAM for Connectivity and Fault/Defect Management (CFM) 593 The detailed requirements for connectivity and fault/defect detection 594 and management in DetNet IP domain and DetNet MPLS domain are defined 595 in respectively in [I-D.ietf-detnet-ip-oam] and 596 [I-D.ietf-detnet-mpls-oam]. 598 6. Gap Analysis 600 In a later revision of this document, this section will contain a gap 601 analysis of existing IETF control and management plane protocols not 602 already discussed elsewhere in this document for their ability (or 603 inability) to satisfy the requirements in Section 2, and discuss 604 possible protocol extensions to existing protocols to fill the gaps, 605 if any. 607 7. IANA Considerations 609 This document has no actions for IANA. 611 Note to RFC Editor: this section may be removed on publication as an 612 RFC. 614 8. Security Considerations 616 Editor's note: This section needs more details. 618 The overall security considerations of DetNet are discussed in 619 [RFC8655] and [I-D.ietf-detnet-security]. For DetNet networks that 620 make use of Segment Routing (whether SR-MPLS or SRv6), the security 621 considerations in [RFC8402] also apply. 623 DetNet networks that make use of a centralized controller plane may 624 be threatened by the loss of connectivity (whether accidental or 625 malicious) between the central controller and the network nodes, and/ 626 or the spoofing of control messages from the controller to the 627 network nodes. This is important since such networks depend on 628 centralized controllers to calculate flow paths and instantiate flow 629 state in the network nodes. For networks that use both DetNet and 630 Segment Routing with a centralized controller, this would also 631 include the calculation of SID lists and their installation in edge/ 632 border routers. 634 In both cases, such threats may be mitigated through redundant 635 controllers, the use of authentication between the controller(s) and 636 the network nodes, and other mechanisms for protection against DOS 637 attacks. A mechanism for supporting one or more alternative central 638 controllers and the ability to fail over to such an alternative 639 controller will be required. 641 9. Acknowledgments 643 Thanks to Jim Guichard, Donald Eastlake, and Stewart Bryant for their 644 review comments. 646 10. References 648 10.1. Normative References 650 [I-D.ietf-detnet-data-plane-framework] 651 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 652 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 653 data-plane-framework-06 (work in progress), May 2020. 655 [I-D.ietf-detnet-flow-information-model] 656 Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 657 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 658 flow-information-model-10 (work in progress), May 2020. 660 [I-D.ietf-detnet-ip] 661 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 662 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 663 (work in progress), July 2020. 665 [I-D.ietf-detnet-ip-oam] 666 Mirsky, G., Chen, M., and D. Black, "Operations, 667 Administration and Maintenance (OAM) for Deterministic 668 Networks (DetNet) with IP Data Plane", draft-ietf-detnet- 669 ip-oam-00 (work in progress), September 2020. 671 [I-D.ietf-detnet-mpls] 672 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 673 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 674 detnet-mpls-09 (work in progress), July 2020. 676 [I-D.ietf-detnet-mpls-oam] 677 Mirsky, G. and M. Chen, "Operations, Administration and 678 Maintenance (OAM) for Deterministic Networks (DetNet) with 679 MPLS Data Plane", draft-ietf-detnet-mpls-oam-01 (work in 680 progress), July 2020. 682 [I-D.ietf-detnet-security] 683 Mizrahi, T. and E. Grossman, "Deterministic Networking 684 (DetNet) Security Considerations", draft-ietf-detnet- 685 security-10 (work in progress), May 2020. 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 693 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 694 Defined Networking (SDN): Layers and Architecture 695 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 696 2015, . 698 [RFC8174] . 700 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 701 Decraene, B., Litkowski, S., and R. Shakir, "Segment 702 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 703 July 2018, . 705 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 706 "Deterministic Networking Architecture", RFC 8655, 707 DOI 10.17487/RFC8655, October 2019, 708 . 710 10.2. Informative References 712 [I-D.finn-detnet-bounded-latency] 713 Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, 714 B., and J. Farkas, "DetNet Bounded Latency", draft-finn- 715 detnet-bounded-latency-04 (work in progress), June 2019. 717 [I-D.ietf-6man-segment-routing-header] 718 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 719 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 720 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 721 progress), October 2019. 723 [I-D.ietf-detnet-ip-over-mpls] 724 Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. 725 Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- 726 detnet-ip-over-mpls-06 (work in progress), May 2020. 728 [I-D.ietf-detnet-ip-over-tsn] 729 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 730 Data Plane: IP over IEEE 802.1 Time Sensitive Networking 731 (TSN)", draft-ietf-detnet-ip-over-tsn-03 (work in 732 progress), June 2020. 734 [I-D.ietf-detnet-mpls-over-tsn] 735 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 736 Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking 737 (TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in 738 progress), June 2020. 740 [I-D.ietf-detnet-mpls-over-udp-ip] 741 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 742 Bryant, "DetNet Data Plane: MPLS over UDP/IP", draft-ietf- 743 detnet-mpls-over-udp-ip-06 (work in progress), May 2020. 745 [I-D.ietf-detnet-topology-yang] 746 Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic 747 Networking (DetNet) Topology YANG Model", draft-ietf- 748 detnet-topology-yang-00 (work in progress), January 2019. 750 [I-D.ietf-detnet-tsn-vpn-over-mpls] 751 Varga, B., Farkas, J., Malis, A., Bryant, S., and D. 752 Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive 753 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 754 mpls-03 (work in progress), June 2020. 756 [I-D.ietf-detnet-yang] 757 Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D. 758 Fedyk, "Deterministic Networking (DetNet) Configuration 759 YANG Model", draft-ietf-detnet-yang-06 (work in progress), 760 June 2020. 762 [IEEE.802.1QBV_2015] 763 IEEE, "IEEE Standard for Local and metropolitan area 764 networks -- Bridges and Bridged Networks - Amendment 25: 765 Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, 766 DOI 10.1109/IEEESTD.2016.7572858, March 2016, 767 . 770 [OPENFLOW] 771 Open Networking Foundation, "OpenFlow Switch 772 Specification, Version 1.5.1 (Protocol version 0x06)", 773 ONF TS-025, March 2015, . 776 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 777 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 778 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 779 . 781 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 782 RFC 4384, DOI 10.17487/RFC4384, February 2006, 783 . 785 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 786 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 787 October 2007, . 789 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 790 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 791 DOI 10.17487/RFC5439, February 2009, 792 . 794 [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS 795 Transport Profile Data Plane Architecture", RFC 5960, 796 DOI 10.17487/RFC5960, August 2010, 797 . 799 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 800 the Network Configuration Protocol (NETCONF)", RFC 6020, 801 DOI 10.17487/RFC6020, October 2010, 802 . 804 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 805 and A. Bierman, Ed., "Network Configuration Protocol 806 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 807 . 809 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 810 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 811 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 812 2015, . 814 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 815 S. Ray, "North-Bound Distribution of Link-State and 816 Traffic Engineering (TE) Information Using BGP", RFC 7752, 817 DOI 10.17487/RFC7752, March 2016, 818 . 820 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 821 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 822 . 824 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 825 Architecture for Use of PCE and the PCE Communication 826 Protocol (PCEP) in a Network with Central Control", 827 RFC 8283, DOI 10.17487/RFC8283, December 2017, 828 . 830 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 831 Decraene, B., Litkowski, S., and R. Shakir, "Segment 832 Routing with the MPLS Data Plane", RFC 8660, 833 DOI 10.17487/RFC8660, December 2019, 834 . 836 Authors' Addresses 838 Andrew G. Malis 839 Independent 841 Email: agmalis@gmail.com 842 Xuesong Geng 843 Huawei 845 Email: gengxuesong@huawei.com 847 Mach (Guoyi) Chen 848 Huawei 850 Email: mach.chen@huawei.com 852 Fengwei Qin 853 China Mobile 855 Email: qinfengwei@chinamobile.com 857 Balazs Varga 858 Ericsson 860 Email: balazs.a.varga@ericsson.com