idnits 2.17.1 draft-nsdt-teas-ns-framework-03.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 date (22 April 2020) is 1458 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-nsdt-teas-transport-slice-definition-02 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-05 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-05 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Gray, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational J. Drake, Ed. 5 Expires: 24 October 2020 Juniper Networks 6 22 April 2020 8 Framework for Transport Network Slices 9 draft-nsdt-teas-ns-framework-03 11 Abstract 13 This memo discusses setting up special-purpose transport connections 14 using existing IETF technologies. These connections are called 15 transport slices for the purposes of this memo. The memo discusses 16 the general framework for this setup, the necessary system components 17 and interfaces, and how abstract requests can be mapped to more 18 specific technologies. The memo also discusses related 19 considerations with monitoring and security. 21 This memo is intended for discussing interfaces and technologies. It 22 is not intended to be a new set of concrete interfaces or 23 technologies. Rather, it should be seen as an explanation of how 24 some existing, concrete IETF VPN and traffic-engineering technologies 25 can be used to create transport slices. Note that there are is a 26 rather large of these technologies, and new technologies or 27 capabilities keep being added. This memo is also not intended 28 presume any particular technology choice. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 24 October 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Transport Slice Objectives . . . . . . . . . . . . . . . . . 4 65 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Management systems or other applications . . . . . . . . 6 67 3.2. Expressing connectivity intents . . . . . . . . . . . . . 6 68 3.3. Transport Slice Controller (TSC) . . . . . . . . . . . . 8 69 3.3.1. Northbound Inteface (NBI) . . . . . . . . . . . . . . 9 70 3.4. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.5. Underlying technology . . . . . . . . . . . . . . . . . . 9 72 4. Applicability of ACTN to Transport Slices . . . . . . . . . . 10 73 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Security Considerations . . . . . . . . . . . . . . . . . 12 76 5.3. Privacy Considerations . . . . . . . . . . . . . . . . . 12 77 5.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 7.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 This draft provides a framework for discussing transport slices, as 88 defined in [I-D.nsdt-teas-transport-slice-definition] (to be replaced 89 by draft-rokui-teas-transport-slice-definition). It is the intention 90 in this document to use terminology consistent with this and other 91 definitions provided in that draft. 93 In particular, this document uses the following terminology defined 94 in the definitions document: 96 * Transport Slice 98 * Transport Slice Controller (TSC) 100 * Transport Network Controller (TNC) 102 * Northbound Interface (NBI) 104 * Southbound Interface (SBI) 106 This framework is intended as a structure for discussing interfaces 107 and technologies. It is not intended to be a new set of concrete 108 interfaces or technologies. Rather, the idea is that existing or 109 under-development IETF technologies (plural) can be used to realize 110 the ideas expressed here. 112 For example, virtual private networks (VPNs) have served the industry 113 well as a means of providing different groups of users with logically 114 isolated access to a common network. The common or base network that 115 is used to provide the VPNs is often referred to as an underlay 116 network, and the VPN is often called an overlay network. As an 117 example technology, a VPN may in turn serve as an underlay network 118 for transport slices. 120 Note: It is conceivable that extensions to these IETF technologies 121 are needed in order to fully support all the ideas that can be 122 implemented with slices, but at least in the beginning there is no 123 plan for the creation of new protocols or interfaces. 125 Driven largely by needs surfacing from 5G, the concept of network 126 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 127 and [BBF-SD406]). In [TS23501], Network Slice is defined as "a 128 logical network that provides specific network capabilities and 129 network characteristics", and a Network Slice Instance is defined as 130 "A set of Network Function instances and the required resources (e.g. 131 compute, storage and networking resources) which form a deployed 132 Network Slice". According to [TS28530], an end-to-end network slice 133 consists of three major types of network segments: Radio Access 134 Network (RAN), Transport Network (TN) and Core Network (CN). 135 Transport network provides the required connectivity between 136 different entities in RAN and CN segments of an end-to-end network 137 slice, with a specific performance commitment. For each end-to-end 138 network slice, the topology and performance requirement on transport 139 network can be very different, which requires the transport network 140 to have the capability of supporting multiple different transport 141 slices. 143 While network slices are commonly discussed in the context of 5G, it 144 is important to note that transport slices are a narrower concept, 145 and focus primarily on particular network connectivity aspects. 146 Other systems, including 5G deployments, may use transport slices as 147 a component to create entire systems and concatenated constructs that 148 match their needs, including end-to-end connectivity. 150 A Transport Slice could span multiple technologies and multiple 151 administrative domains. Depending on the consumer's requirements, a 152 transport slice could be isolated from other, often concurrent 153 transport slices in terms of data, control and management planes. 155 The consumer expresses requirements for a particular transport slice 156 by specifying what is required rather than how the requirement is to 157 be fulfilled. That is, the Transport Slice consumer's view of a 158 transport slice is an abstract one. 160 Thus, there is a need to create logical network structures with 161 required characteristics. The consumer of such a logical network can 162 require a degree of isolation and performance that previously might 163 not have been satisfied by traditional overlay VPNs. Additionally, 164 the transport slice consumer might ask for some level of control of 165 their virtual networks, e.g., to customize the service paths in a 166 network slice. 168 This document specifies a framework for the use of existing 169 technologies as components to provide a transport slice service, and 170 might also discuss (or reference) modified and potential new 171 technologies, as they develop (such as candidate technologies 172 described in section 5 of [I-D.ietf-teas-enhanced-vpn]). 174 2. Transport Slice Objectives 176 It is intended that transport slices can be created to meet specific 177 requirements, typically expressed as bandwidth, latency, latency 178 variation, and other desired or required characteristics. Creation 179 is initiated by a management system or other application used to 180 specify network-related conditions for particular traffic flows. 182 And it is intended that, once created, these slices can be monitored, 183 modified, deleted, and otherwise managed. 185 It is also intended that applications and components will be able to 186 use these transport slices to move packets between the specified end- 187 points in accordance with specified characteristics. 189 As an example of requirements that might apply to transport slices, 190 see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3). 192 3. Framework 194 A number of transport slice services will typically be provided over 195 a shared underlying network infrastructure. Each transport slice 196 consists of both the overlay connectivity and a specific set of 197 dedicated network resources and/or functions allocated in a shared 198 underlay network to satisfy the needs of the transport slice 199 consumer. In at least some examples of underlying network 200 technologies, the integration between the overlay and various 201 underlay resources is needed to ensure the guaranteed performance 202 requested for different transport slices. 204 Transport Slice Definition 205 ([I-D.nsdt-teas-transport-slice-definition]) defines the role of a 206 Customer (or User) and a Transport Slice Controller. That draft also 207 defines a TSC Northbound Interface (NBI). 209 A transport slice user is served by the Transport Slice Controller 210 (TSC), as follows: 212 * The TSC takes requests from a management system or other 213 application, which are then communicated via an NBI. This 214 interface carries data objects the transport slice user provides, 215 describing the needed transport slices in terms of topology, 216 applicable service level objectives (SLO), and any monitoring and 217 reporting requirements that may apply. Note that - in this 218 context - "topology" means what the transport slice connectivity 219 is meant to look like from the users perspective; it may be as 220 simple as a list of mutually (and symmetrically) connected end 221 points, or it may be complicated by details of connection 222 asymmetry, per-connection SLO requirements, etc. 224 * These requests are assumed to be translated by one or more 225 underlying systems, which are used to establish specific transport 226 slice instances on top of an underlying network infrastructure. 228 * The TSC maintains a record of the mapping from user requests to 229 slice instantiations, as needed to allow for subsequent control 230 functions (such as modification or deletion of the requested 231 slices), and as needed for any requested monitoring and reporting 232 functions. 234 Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example 235 architecture that might apply in using the technology described in 236 that document. 238 3.1. Management systems or other applications 240 The transport slice system is used by a management system or other 241 application. These systems and applications may also be a part of a 242 higher level function in the system, e.g., putting together network 243 functions, access equipment, application specific components, as well 244 as the transport slices. 246 3.2. Expressing connectivity intents 248 The Transport Slice Controller (TSC) northbound interface (NBI) can 249 be used to communicate between transport slice users (or consumers) 250 and the TSC. 252 A transport slice user may be a network operator who, in turn, 253 provides the transport slice to another transport slice user or 254 consumer. 256 Using the NBI, a consumer expresses requirements for a particular 257 slice by specifying what is required rather than how that is to be 258 achieved. That is, the consumer's view of a slice is an abstract 259 one. Consumers normally have limited (or no) visibility into the 260 provider network's actual topology and resource availability 261 information. 263 This should be true even if both the consumer and provider are 264 associated with a single administrative domain, in order to reduce 265 the potential for adverse interactions between transport slice 266 consumers and other uses/users of the transport network 267 infrastructure. 269 The benefits of this model can include: 271 * Security: because the transport network (or network operator) does 272 not need to expose network details (topology, capacity, etc.) to 273 transport slice consumers the transport network components are 274 less exposed to attack; 276 * Layered Implementation: the transport network comprises network 277 elements that belong to a different layer network than consumer 278 applications, and network information (advertisements, protocols, 279 etc.) that a consumer cannot interpret or respond to (note - a 280 consumer should not use network information not exposed via the 281 TSC NBI, even if that information is available); 283 * Scalability: consumers do not need to know any information beyond 284 that which is exposed via the NBI. 286 The general issues of abstraction in a TE network is described more 287 fully in [RFC7926]. 289 This framework document does not assume any particular layer at which 290 transport slices operate as a number of layers (including virtual L2, 291 Ethernet or IP connectivity) could be employed. 293 Data models and interfaces are of course needed to set up transport 294 slices, and specific interfaces may have capabilities that allow 295 creation of specific layers. 297 Layered virtual connections are comprehensively discussed in IETF 298 documents and are widely supported. See, for instance, GMPLS-based 299 networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8353] and 300 [RFC8353]). The principles and mechanisms associated with layered 301 networking are applicable to transport slices. 303 There are several IETF-defined mechanisms for expressing the need for 304 a desired logical network. The NBI carries data either in a 305 protocol-defined format, or in a formalism associated with a modeling 306 language. 308 For instance: 310 * Path Computation Element (PCE) Communication Protocol (PCEP) 311 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 312 [RFC4208] use a TLV-based binary encoding to transmit data. 314 * Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 315 Protocol [RFC8040] use XML abnd JSON encoding. 317 * gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 318 programmable interface; 320 * SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding 321 (ASN.1). 323 * For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 324 model configuration and other data for NETCONF, RESTCONF, and GNMI 325 - among others; ProtoBufs can be used to model gRPC and GNMI data; 326 Structure of Management Information (SMI) [RFC2578] may be used to 327 define Management Information Base (MIB) modules for SNMP, using 328 an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 329 1988). 331 While several generic formats and data models for specific purposes 332 exist, it is expected that transport slice management may require 333 enhancement or augmentation of existing data models. 335 3.3. Transport Slice Controller (TSC) 337 The transport slice controller takes abstract requests for transport 338 slices and implements them using a suitable underlying technology. A 339 transport slice controller is the key building block for control and 340 management of the transport slice. It provides the 341 creation/modification/deletion, monitoring and optimization of 342 transport Slices in a multi-domain, a multi-technology and multi- 343 vendor environment. 345 A TSC northbound interface (NBI) is needed for communicating details 346 of a transport slice (configuration, selected policies, operational 347 state, etc.), as well as providing information to a slice requester/ 348 consumer about transport slice status and performance. The details 349 for this NBI are not in scope for this document. 351 The controller provides the following functions: 353 * Provides a technology-agnostic NBI for creation/modification/ 354 deletion of the transport slices. The API exposed by this NBI 355 communicates the endpoints of the transport slice, transport slice 356 SLO parameters (and possibly monitoring thresholds), applicable 357 input selection (filtering) and various policies, and provides a 358 way to monitor the slice. 360 * Determines an abstract topology connecting the endpoints of the 361 transport slice that meets criteria specified via the NBI.The TSC 362 also retains information about the mapping of this abstract 363 topology to underlying components of the transport slice as 364 necessary to monitor transport slice status and performance. 366 * Provides "Mapping Functions" for the realization of transport 367 slices. In other words, it will use the mapping functions that: 369 map technology-agnostic NBI request to technology-specific SBIs. 371 map filtering/selection information as necessary to entities in 372 the underlay network. 374 * Via an SBI, the controller collects Telemetry data (e.g. OAM 375 results, Statistics, States etc.) for all elements in the abstract 376 topology used to realize the transport slice. 378 * Using the Telemetry data from the underlying realization of a 379 transport slice (i.e. services/paths/tunnels), evaluates the 380 current performance against transport slice SLO parameters and 381 exposes them to the transport slice consumer via the NBI. The TSC 382 NBI may also include a capability to provide notification in case 383 the transport slice performance reaches threshold values defined 384 by the transport slice consumer. 386 3.3.1. Northbound Inteface (NBI) 388 The Transport Slice Controller provides a Northbound Interface (NBI) 389 that allows consumers of network slices to request and monitor 390 transport slices. Consumers operate on abstract transport slices, 391 with details related to their realization hidden. 393 The NBI complements various IETF services, tunnels, path models by 394 providing an abstract layer on top of these models. 396 The NBI is independent of type of network functions or services that 397 need to be connected, i.e. it is independent of any specific storage, 398 software, protocol, or platform used to realize physical or virtual 399 network connectivity or functions in support of transport slices. 401 The NBI uses protocol mechanisms and information passed over passed 402 over those mechanisms to convey desired attributes for transport 403 slices and their status. The information is expected to be 404 represented as a well-defined data model, and should include at least 405 endpoint and connectivity information, SLO specification, and status 406 information. 408 To accomplish this, the NBI needs to convey information needed to 409 support communication across the NBI, in terms of identifying the 410 transport slices, as well providing the above model information. 412 3.4. Mapping 414 The main task of the transport slice controller is to map abstract 415 transport slice requirements to concrete technologies and establish 416 the required connectivity, and ensuring that required resources are 417 allocated to the transport slice. 419 3.5. Underlying technology 421 There are a number of different technologies that can be used, 422 including physical connections, MPLS, TSN, Flex-E, etc. 424 See [I-D.ietf-teas-enhanced-vpn] - section 5 - for instance, for 425 example underlying technologies. 427 Also, as outlined in "applicability of ACTN to Transport Slices" 428 below, ACTN ([RFC8453]) offers a framework that is used elsewhere in 429 IETF specifications to create virtual network (VN) services similar 430 to Transport Slices. 432 A transport slice can be realized in a network, using specific 433 underlying technology or technologies. The creation of a new 434 transport slice will be initiated with following three steps: 436 * Step 1: A higher level system requests connections with specific 437 characteristics via NBI. 439 * Step 2: This request will be processed by a Transport Slice 440 Controller which specifies a mapping between northbound request to 441 any IETF Services, Tunnels, and paths models. 443 * Step 3: A series of requests for creation of services, tunnels and 444 paths will be sent to the network to realize the trasport slice. 446 It is very clear that regardless of how transport slice is realized 447 in the network (i.e. using tunnels of type RSVP or SR), the 448 definition of transport slice does not change at all but rather its 449 realization. 451 4. Applicability of ACTN to Transport Slices 453 [RFC8453] defined three controllers as per the framework for 454 Abstraction and Control of TE Networks (ACTN) to support virtual 455 network (VN) services - Customer Network Controller (CNC), Multi- 456 Domain Service Coordinator (MDSC) and Provisioning Network Controller 457 (PNC). A CNC is responsible for communicating a customer's virtual 458 network requirements, a MDSC is responsible for multi-domain 459 coordination, virtualization/abstraction, customer mapping/ 460 translation and virtual service coordination to realize the virtual 461 network requirement. Its key role is to detach the network/service 462 requirements from the underlying technology. A PNC oversees the 463 configuration, monitoring and collection of the network topology. 464 The PNC is a underlay technology specific controller. 466 While the ACTN framework is a generic VN framework that is used for 467 various VN service beyond the transport slice, it is still a suitable 468 based to understand how the various controllers interact to realize 469 the Transport slice. 471 A mapping between the Transport Slice definitions and ACTN 472 definitions is as shown in Figure 1 below. 474 ------------------------------------+ 475 | Customer | | 476 +------------------------------------+ 477 A | ACTN 478 | Terminology 479 V | and Concepts 480 +------------------------------------+ 481 | A highter level system | | 482 |(e.g e2e network slice orchestrator)| 483 +------------------------------------+ | 484 A 485 | TSC NBI | 486 V 487 +------------------------------------+ | +-----+ 488 | Transport Slice Controller | ===> | CNC | 489 +------------------------------------+ | +-----+ 490 A A 491 | TSC SBI | | CMI 492 V V 493 +------------------------------------+ | +-----+ 494 | Network Controller(s) | ===> |MDSC | 495 +------------------------------------+ | +-----+ 496 A 497 Terminology/Concepts | | MPI 498 Used in this Document V 499 | +-----+ 500 | PNC | 501 | +-----+ 503 Figure 1 505 The TSC NBI conveys the generic transport slice requirements. These 506 may then be realized using an SBI. 508 As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC 509 Interface (CMI) is used to convey the virtual network service 510 requirements along with the service models and the MDSC-PNC Interface 511 (MPI) is used to realize the service along network configuration 512 models. [I-D.ietf-teas-te-service-mapping-yang] further describe how 513 the VPN services can be mapped to the underlying TE resources. 515 The Transport Network Controller is depicted as a single block, where 516 as in the ACTN framework this has been decomposed into MDSC and PNC 517 to handle multiple domains and various underlay technologies. 519 [RFC8453] also describes TE Network Slicing in the context of ACTN as 520 a collection of resources that is used to establish a logically 521 dedicated virtual network over one or more TE networks. In case of 522 TE enabled underlying network, ACTN VN can be used as a base to 523 realize the transport network slicing by coordination among multiple 524 peer domains as well as underlay technology domains. 526 5. Considerations 528 5.1. Monitoring 530 Transport slice realization needs to be instrumented in order to 531 track how it is working, and it might be necessary to modify the 532 transport slice as requirements change. Dynamic reconfiguration 533 might be needed. 535 5.2. Security Considerations 537 Transport slices might use underlying virtualized networking. All 538 types of virtual networking require special consideration to be given 539 to the separation of traffic between distinct virtual networks, as 540 well as some degree of protection from effects of traffic use of 541 underlying network (and other) resources from other virtual networks 542 sharing those resources. 544 For example, if a service requires a specific upper bound of latency, 545 then that service can be degraded by added delay in transmission of 546 service packets through the activities of another service or 547 application using the same resources. 549 Similarly, in a network with virtual functions, noticeably impeding 550 access to a function used by another transport slice (for instance, 551 compute resources) can be just as service degrading as delaying 552 physical transmission of associated packet in the network. 554 While a transport slice might include encryption and other security 555 features as part of the service, consumers might be well advised to 556 take responsibility for their own security needs, possibly by 557 encrypting traffic before hand-off to a service provider. 559 5.3. Privacy Considerations 561 Privacy of transport network slice service consumers must be 562 preserved. It should not be possible for one transport slice 563 consumer to discover the presence of other consumers, nor should 564 sites that are members of one transport slice be visible outside the 565 context of that transport slice. 567 In this sense, it is of paramount importance that the system use the 568 privacy protection mechanism defined for the specific underlying 569 technologies used, including in particular those mechanisms designed 570 to preclude acquiring identifying information associated with any 571 transport slice consumer. 573 5.4. IANA Considerations 575 There are no requests to IANA in this framework document. 577 6. Acknowledgments 579 The entire TEAS NS design team and everyone participating in related 580 discussions has contributed to this draft. Some text fragments in 581 the draft have been copied from the [I-D.ietf-teas-enhanced-vpn], for 582 which we are grateful. 584 Significant contributions to this document were gratefully received 585 from the contributing authors listed in the "Contributors" section. 586 In addition we would like to also thank those others who have 587 attended one or more of the design team meetings, including: 589 * Aihua Guo 591 * Bo Wu 593 * Greg Mirsky 595 * Jeff Tantsura 597 * Kiran Makhijani 599 * Lou Berger 601 * Luis M. Contreras 603 * Rakesh Gandhi 605 * Ren Chen 607 * Sergio Belotti 609 * Shunsuke Homma 611 * Stewart Bryant 613 * Tomonobu Niwa 615 * Xuesong Geng 617 7. References 618 7.1. Normative References 620 [I-D.nsdt-teas-transport-slice-definition] 621 Rokui, R., Homma, S., Makhijani, K., and L. Contreras, 622 "IETF Definition of Transport Slice", Work in Progress, 623 Internet-Draft, draft-nsdt-teas-transport-slice- 624 definition-02, 21 April 2020, . 628 7.2. Informative References 630 [BBF-SD406] 631 Broadband Forum, ., "End-to-end network slicing", BBF 632 SD-406 , n.d.. 634 [I-D.ietf-teas-actn-yang] 635 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 636 Shin, J., and S. Belotti, "Applicability of YANG models 637 for Abstraction and Control of Traffic Engineered 638 Networks", Work in Progress, Internet-Draft, draft-ietf- 639 teas-actn-yang-05, 19 February 2020, . 642 [I-D.ietf-teas-enhanced-vpn] 643 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 644 Framework for Enhanced Virtual Private Networks (VPN+) 645 Services", Work in Progress, Internet-Draft, draft-ietf- 646 teas-enhanced-vpn-05, 18 February 2020, 647 . 650 [I-D.ietf-teas-te-service-mapping-yang] 651 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 652 and J. Tantsura, "Traffic Engineering (TE) and Service 653 Mapping Yang Model", Work in Progress, Internet-Draft, 654 draft-ietf-teas-te-service-mapping-yang-03, 8 March 2020, 655 . 658 [I-D.openconfig-rtgwg-gnmi-spec] 659 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 660 C., and C. Morrow, "gRPC Network Management Interface 661 (gNMI)", Work in Progress, Internet-Draft, draft- 662 openconfig-rtgwg-gnmi-spec-01, 5 March 2018, 663 . 666 [NGMN-NS-Concept] 667 NGMN Alliance, ., "Description of Network Slicing 668 Concept", https://www.ngmn.org/uploads/ 669 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 670 2016. 672 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 673 Schoenwaelder, Ed., "Structure of Management Information 674 Version 2 (SMIv2)", STD 58, RFC 2578, 675 DOI 10.17487/RFC2578, April 1999, 676 . 678 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 679 "Message Processing and Dispatching for the Simple Network 680 Management Protocol (SNMP)", STD 62, RFC 3412, 681 DOI 10.17487/RFC3412, December 2002, 682 . 684 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 685 (USM) for version 3 of the Simple Network Management 686 Protocol (SNMPv3)", STD 62, RFC 3414, 687 DOI 10.17487/RFC3414, December 2002, 688 . 690 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 691 Network Management Protocol (SNMP)", STD 62, RFC 3417, 692 DOI 10.17487/RFC3417, December 2002, 693 . 695 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 696 "Generalized Multiprotocol Label Switching (GMPLS) User- 697 Network Interface (UNI): Resource ReserVation Protocol- 698 Traffic Engineering (RSVP-TE) Support for the Overlay 699 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 700 . 702 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 703 Interpretation of Generalized Multiprotocol Label 704 Switching (GMPLS) Terminology within the Context of the 705 ITU-T's Automatically Switched Optical Network (ASON) 706 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 707 2006, . 709 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 710 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 711 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 712 DOI 10.17487/RFC5212, July 2008, 713 . 715 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 716 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 717 DOI 10.17487/RFC5440, March 2009, 718 . 720 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 721 the Network Configuration Protocol (NETCONF)", RFC 6020, 722 DOI 10.17487/RFC6020, October 2010, 723 . 725 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 726 and A. Bierman, Ed., "Network Configuration Protocol 727 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 728 . 730 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 731 Ceccarelli, D., and X. Zhang, "Problem Statement and 732 Architecture for Information Exchange between 733 Interconnected Traffic-Engineered Networks", BCP 206, 734 RFC 7926, DOI 10.17487/RFC7926, July 2016, 735 . 737 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 738 RFC 7950, DOI 10.17487/RFC7950, August 2016, 739 . 741 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 742 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 743 . 745 [RFC8353] Upadhyay, M., Malkani, S., and W. Wang, "Generic Security 746 Service API Version 2: Java Bindings Update", RFC 8353, 747 DOI 10.17487/RFC8353, May 2018, 748 . 750 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 751 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 752 DOI 10.17487/RFC8453, August 2018, 753 . 755 [TS23501] 3GPP, ., "System architecture for the 5G System (5GS)", 756 3GPP TS 23.501 , 2019. 758 [TS28530] 3GPP, ., "Management and orchestration; Concepts, use 759 cases and requirements", 3GPP TS 28.530 , 2019. 761 Contributors 763 The following authors contributed significantly to this document: 765 Jari Arkko 766 Ericsson 768 Email: jari.arkko@piuha.net 770 Dhruv Dhody 771 Huawei, India 773 Email: dhruv.ietf@gmail.com 775 Reza Rokui 776 Nokia 778 Email: reza.rokui@nokia.com 780 Xufeng Liu 782 Email: xufeng.liu.ietf@gmail.com 784 Jie Dong 785 Huawei 787 Email: jie.dong@huawei.com 789 Authors' Addresses 791 Eric Gray (editor) 792 Ericsson 794 Email: eric.gray@ericsson.com 796 John Drake (editor) 797 Juniper Networks 799 Email: jdrake@juniper.net