idnits 2.17.1 draft-nsdt-teas-ns-framework-02.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 (25 March 2020) is 1487 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-01 == 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: 26 September 2020 Juniper Networks 6 25 March 2020 8 Framework for Transport Network Slices 9 draft-nsdt-teas-ns-framework-02 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 26 September 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 defintions document: - Transport Slice - Transport Slice 95 Controller (TSC) - Transport Network Controller (TNC) - Nothrbound 96 Interface (NBI) - Southbound Interface (SBI) 98 This framework is intended as a structure for discussing interfaces 99 and technologies. It is not intended to be a new set of concrete 100 interfaces or technologies. Rather, the idea is that existing or 101 under-development IETF technologies (plural) can be used to realize 102 the ideas expressed here. 104 For example, virtual private networks (VPNs) have served the industry 105 well as a means of providing different groups of users with logically 106 isolated access to a common network. The common or base network that 107 is used to provide the VPNs is often referred to as an underlay 108 network, and the VPN is often called an overlay network. As an 109 example technology, a VPN may in turn serve as an underlay network 110 for transport slices. 112 Note: It is conceivable that extensions to these IETF technologies 113 are needed in order to fully support all the ideas that can be 114 implemented with slices, but at least in the beginning there is no 115 plan for the creation of new protocols or interfaces. 117 Driven largely by needs surfacing from 5G, the concept of network 118 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 119 and [BBF-SD406]). In [TS23501], Network Slice is defined as "a 120 logical network that provides specific network capabilities and 121 network characteristics", and a Network Slice Instance is defined as 122 "A set of Network Function instances and the required resources (e.g. 123 compute, storage and networking resources) which form a deployed 124 Network Slice". According to [TS28530], an end-to-end network slice 125 consists of three major types of network segments: Radio Access 126 Network (RAN), Transport Network (TN) and Core Network (CN). 127 Transport network provides the required connectivity between 128 different entities in RAN and CN segments of an end-to-end network 129 slice, with a specific performance commitment. For each end-to-end 130 network slice, the topology and performance requirement on transport 131 network can be very different, which requires the transport network 132 to have the capability of supporting multiple different transport 133 slices. 135 While network slices are commonly discussed in the context of 5G, it 136 is important to note that transport slices are a narrower concept, 137 and focus primarily on particular network connectivity aspects. 138 Other systems, including 5G deployments, may use transport slices as 139 a component to create entire systems and concatenated constructs that 140 match their needs, including end-to-end connectivity. 142 A Transport Slice could span multiple technologies and multiple 143 administrative domains. Depending on the consumer's requirements, a 144 transport slice could be isolated from other, often concurrent 145 transport slices in terms of data, control and management planes. 147 The consumer expresses requirements for a particular transport slice 148 by specifying what is required rather than how the requirement is to 149 be fulfilled. That is, the Transport Slice consumer's view of a 150 transport slice is an abstract one. 152 Thus, there is a need to create logical network structures with 153 required characteristics. The consumer of such a logical network can 154 require a degree of isolation and performance that previously might 155 not have been satisfied by traditional overlay VPNs. Additionally, 156 the transport slice consumer might ask for some level of control of 157 their virtual networks, e.g., to customize the service paths in a 158 network slice. 160 This document specifies a framework for the use of existing 161 technologies as components to provide a transport slice service, and 162 might also discuss (or reference) modified and potential new 163 technologies, as they develop (such as candidate technologies 164 described in section 5 of [I-D.ietf-teas-enhanced-vpn]). 166 2. Transport Slice Objectives 168 It is intended that transport slices can be created to meet specific 169 requirements, typically expressed as bandwidth, latency, latency 170 variation, and other desired or required characteristics. Creation 171 is initiated by a management system or other application used to 172 specify network-related conditions for particular traffic flows. 174 And it is intended that, once created, these slices can be monitored, 175 modified, deleted, and otherwise managed. 177 It is also intended that applications and components will be able to 178 use these transport slices to move packets between the specified end- 179 points in accordance with specified characteristics. 181 As an example of requirements that might apply to transport slices, 182 see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3). 184 3. Framework 186 A number of transport slice services will typically be provided over 187 a shared underlying network infrastructure. Each transport slice 188 consists of both the overlay connectivity and a specific set of 189 dedicated network resources and/or functions allocated in a shared 190 underlay network to satisfy the needs of the transport slice 191 consumer. In at least some examples of underlying network 192 technologies, the integration between the overlay and various 193 underlay resources is needed to ensure the guaranteed performance 194 requested for different transport slices. 196 Transport Slice Definition 197 ([I-D.nsdt-teas-transport-slice-definition]) defines the role of a 198 Customer (or User) and a Transport Slice Controller. That draft also 199 defines a TSC Northbound Interface (NBI). 201 A transport slice user is served by the Transport Slice Controller 202 (TSC), as follows: 204 * The TSC takes requests from a management system or other 205 application, which are then communicated via an NBI. This 206 interface carries data objects the transport slice user provides, 207 describing the needed transport slices in terms of topology, 208 applicable service level objectives (SLO), and any monitoring and 209 reporting requirements that may apply. Note that - in this 210 context - "topology" means what the transport slice connectivity 211 is meant to look like from the users perspective; it may be as 212 simple as a list of mutually (and symmetrically) connected end 213 points, or it may be complicated by details of connection 214 asymmetry, per-connection SLO requirements, etc. 216 * These requests are assumed to be translated by one or more 217 underlying systems, which are used to establish specific transport 218 slice instances on top of an underlying network infrastructure. 220 * The TSC maintains a record of the mapping from user requests to 221 slice instantiations, as needed to allow for subsequent control 222 functions (such as modification or deletion of the requested 223 slices), and as needed for any requested monitoring and reporting 224 functions. 226 Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example 227 architecture that might apply in using the technology described in 228 that document. 230 3.1. Management systems or other applications 232 The transport slice system is used by a management system or other 233 application. These systems and applications may also be a part of a 234 higher level function in the system, e.g., putting together network 235 functions, access equipment, application specific components, as well 236 as the transport slices. 238 3.2. Expressing connectivity intents 240 The Transport Slice Controller (TSC) northbound interface (NBI) can 241 be used to communicate between transport slice users (or consumers) 242 and the TSC. 244 A transport slice user may be a network operator who, in turn, 245 provides the transport slice to another transport slice user or 246 consumer. 248 Using the NBI, a consumer expresses requirements for a particular 249 slice by specifying what is required rather than how that is to be 250 achieved. That is, the consumer's view of a slice is an abstract 251 one. Consumers normally have limited (or no) visibility into the 252 provider network's actual topology and resource availability 253 information. 255 This should be true even if both the consumer and provider are 256 associated with a single administrative domain, in order to reduce 257 the potential for adverse interactions between transport slice 258 consumers and other uses/users of the transport network 259 infrastructure. 261 The benefits of this model can include: 263 * Security: because the transport network (or network operator) does 264 not need to expose network details (topology, capacity, etc.) to 265 transport slice consumers the transport network components are 266 less exposed to attack; 268 * Layered Implementation: the transport network comprises network 269 elements that belong to a different layer network than consumer 270 applications, and network information (advertisements, protocols, 271 etc.) that a consumer cannot interpret or respond to (note - a 272 consumer should not use network information not exposed via the 273 TSC NBI, even if that information is available); 275 * Scalability: consumers do not need to know any information beyond 276 that which is exposed via the NBI. 278 The general issues of abstraction in a TE network is described more 279 fully in [RFC7926]. 281 This framework document does not assume any particular layer at which 282 transport slices operate as a number of layers (including virtual L2, 283 Ethernet or IP connectivity) could be employed. 285 Data models and interfaces are of course needed to set up transport 286 slices, and specific interfaces may have capabilities that allow 287 creation of specific layers. 289 Layered virtual connections are comprehensively discussed in IETF 290 documents and are widely supported. See, for instance, GMPLS-based 291 networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8353] and 292 [RFC8353]). The principles and mechanisms associated with layered 293 networking are applicable to transport slices. 295 There are several IETF-defined mechanisms for expressing the need for 296 a desired logical network. The NBI carries data either in a 297 protocol-defined format, or in a formalism associated with a modeling 298 language. 300 For instance: 302 * Path Computation Element (PCE) Communication Protocol (PCEP) 303 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 304 [RFC4208] use a TLV-based binary encoding to transmit data. 306 * Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 307 Protocol [RFC8040] use XML abnd JSON encoding. 309 * gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 310 programmable interface; 312 * SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding 313 (ASN.1). 315 * For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 316 model configuration and other data for NETCONF, RESTCONF, and GNMI 317 - among others; ProtoBufs can be used to model gRPC and GNMI data; 318 Structure of Management Information (SMI) [RFC2578] may be used to 319 define Management Information Base (MIB) modules for SNMP, using 320 an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 321 1988). 323 While several generic formats and data models for specific purposes 324 exist, it is expected that transport slice management may require 325 enhancement or augmentation of existing data models. 327 3.3. Transport Slice Controller (TSC) 329 The transport slice controller takes abstract requests for transport 330 slices and implements them using a suitable underlying technology. A 331 transport slice controller is the key building block for control and 332 management of the transport slice. It provides the 333 creation/modification/deletion, monitoring and optimization of 334 transport Slices in a multi-domain, a multi-technology and multi- 335 vendor environment. 337 A TSC northbound interface (NBI) is needed for communicating details 338 of a transport slice (configuration, selected policies, operational 339 state, etc.), as well as providing information to a slice requester/ 340 consumer about transport slice status and performance. The details 341 for this NBI are not in scope for this document. 343 The controller provides the following functions: 345 * Provides a technology-agnostic NBI for creation/modification/ 346 deletion of the transport slices. The API exposed by this NBI 347 communicates the endpoints of the transport slice, transport slice 348 SLO parameters (and possibly monitoring thresholds), applicable 349 input selection (filtering) and various policies, and provides a 350 way to monitor the slice. 352 * Determines an abstract topology connecting the endpoints of the 353 transport slice that meets criteria specified via the NBI.The TSC 354 also retains information about the mapping of this abstract 355 topology to underlying components of the transport slice as 356 necessary to monitor transport slice status and performance. 358 * Provides "Mapping Functions" for the realization of transport 359 slices. In other words, it will use the mapping functions that: 361 map technology-agnostic NBI request to technology-specific SBIs. 363 map filtering/selection information as necessary to entities in 364 the underlay network. 366 * Via an SBI, the controller collects Telemetry data (e.g. OAM 367 results, Statistics, States etc.) for all elements in the abstract 368 topology used to realize the transport slice. 370 * Using the Telemetry data from the underlying realization of a 371 transport slice (i.e. services/paths/tunnels), evaluates the 372 current performance against transport slice SLO parameters and 373 exposes them to the transport slice consumer via the NBI. The TSC 374 NBI may also include a capability to provide notification in case 375 the transport slice performance reaches threshold values defined 376 by the transport slice consumer. 378 3.3.1. Northbound Inteface (NBI) 380 The Transport Slice Controller provides a Northbound Interface (NBI) 381 that allows consumers of network slices to request and monitor 382 transport slices. Consumers operate on abstract transport slices, 383 with details related to their realization hidden. 385 The NBI complements various IETF services, tunnels, path models by 386 providing an abstract layer on top of these models. 388 The NBI is independent of type of network functions or services that 389 need to be connected, i.e. it is independent of any specific storage, 390 software, protocol, or platform used to realize physical or virtual 391 network connectivity or functions in support of transport slices. 393 The NBI uses protocol mechanisms and information passed over passed 394 over those mechanisms to convey desired attributes for transport 395 slices and their status. The information is expected to be 396 represented as a well-defined data model, and should include at least 397 endpoint and connectivity information, SLO specification, and status 398 information. 400 To accomplish this, the NBI needs to convey information needed to 401 support communication across the NBI, in terms of identifying the 402 transport slices, as well providing the above model information. 404 3.4. Mapping 406 The main task of the transport slice controller is to map abstract 407 transport slice requirements to concrete technologies and establish 408 the required connectivity, and ensuring that required resources are 409 allocated to the transport slice. 411 3.5. Underlying technology 413 There are a number of different technologies that can be used, 414 including physical connections, MPLS, TSN, Flex-E, etc. 416 See [I-D.ietf-teas-enhanced-vpn] - section 5 - for instance, for 417 example underlying technologies. 419 Also, as outlined in "applicability of ACTN to Transport Slices" 420 below, ACTN ([RFC8453]) offers a framework that is used elsewhere in 421 IETF specifications to create virtual network (VN) services similar 422 to Transport Slices. 424 A transport slice can be realized in a network, using specific 425 underlying technology or technologies. The creation of a new 426 transport slice will be initiated with following three steps: 428 * Step 1: A higher level system requests connections with specific 429 characteristics via NBI. 431 * Step 2: This request will be processed by a Transport Slice 432 Controller which specifies a mapping between northbound request to 433 any IETF Services, Tunnels, and paths models. 435 * Step 3: A series of requests for creation of services, tunnels and 436 paths will be sent to the network to realize the trasport slice. 438 It is very clear that regardless of how transport slice is realized 439 in the network (i.e. using tunnels of type RSVP or SR), the 440 definition of transport slice does not change at all but rather its 441 realization. 443 4. Applicability of ACTN to Transport Slices 445 [RFC8453] defined three controllers as per the framework for 446 Abstraction and Control of TE Networks (ACTN) to support virtual 447 network (VN) services - Customer Network Controller (CNC), Multi- 448 Domain Service Coordinator (MDSC) and Provisioning Network Controller 449 (PNC). A CNC is responsible for communicating a customer's virtual 450 network requirements, a MDSC is responsible for multi-domain 451 coordination, virtualization/abstraction, customer mapping/ 452 translation and virtual service coordination to realize the virtual 453 network requirement. Its key role is to detach the network/service 454 requirements from the underlying technology. A PNC oversees the 455 configuration, monitoring and collection of the network topology. 456 The PNC is a underlay technology specific controller. 458 While the ACTN framework is a generic VN framework that is used for 459 various VN service beyond the transport slice, it is still a suitable 460 based to understand how the various controllers interact to realize 461 the Transport slice. 463 A mapping between the Transport Slice definitions and ACTN 464 definitions is as shown in Figure 1 below. 466 ------------------------------------+ 467 | Customer | | 468 +------------------------------------+ 469 A | ACTN 470 | Terminology 471 V | and Concepts 472 +------------------------------------+ 473 | A highter level system | | 474 |(e.g e2e network slice orchestrator)| 475 +------------------------------------+ | 476 A 477 | TSC NBI | 478 V 479 +------------------------------------+ | +-----+ 480 | Transport Slice Controller | ===> | CNC | 481 +------------------------------------+ | +-----+ 482 A A 483 | TSC SBI | | CMI 484 V V 485 +------------------------------------+ | +-----+ 486 | Network Controller(s) | ===> |MDSC | 487 +------------------------------------+ | +-----+ 488 A 489 Terminology/Concepts | | MPI 490 Used in this Document V 491 | +-----+ 492 | PNC | 493 | +-----+ 495 Figure 1 497 The TSC NBI conveys the generic transport slice requirements. These 498 may then be realized using an SBI. 500 As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC 501 Interface (CMI) is used to convey the virtual network service 502 requirements along with the service models and the MDSC-PNC Interface 503 (MPI) is used to realize the service along network configuration 504 models. [I-D.ietf-teas-te-service-mapping-yang] further describe how 505 the VPN services can be mapped to the underlying TE resources. 507 The Transport Network Controller is depicted as a single block, where 508 as in the ACTN framework this has been decomposed into MDSC and PNC 509 to handle multiple domains and various underlay technologies. 511 [RFC8453] also describes TE Network Slicing in the context of ACTN as 512 a collection of resources that is used to establish a logically 513 dedicated virtual network over one or more TE networks. In case of 514 TE enabled underlying network, ACTN VN can be used as a base to 515 realize the transport network slicing by coordination among multiple 516 peer domains as well as underlay technology domains. 518 5. Considerations 520 5.1. Monitoring 522 Transport slice realization needs to be instrumented in order to 523 track how it is working, and it might be necessary to modify the 524 transport slice as requirements change. Dynamic reconfiguration 525 might be needed. 527 5.2. Security Considerations 529 Transport slices might use underlying virtualized networking. All 530 types of virtual networking require special consideration to be given 531 to the separation of traffic between distinct virtual networks, as 532 well as some degree of protection from effects of traffic use of 533 underlying network (and other) resources from other virtual networks 534 sharing those resources. 536 For example, if a service requires a specific upper bound of latency, 537 then that service can be degraded by added delay in transmission of 538 service packets through the activities of another service or 539 application using the same resources. 541 Similarly, in a network with virtual functions, noticeably impeding 542 access to a function used by another transport slice (for instance, 543 compute resources) can be just as service degrading as delaying 544 physical transmission of associated packet in the network. 546 While a transport slice might include encryption and other security 547 features as part of the service, consumers might be well advised to 548 take responsibility for their own security needs, possibly by 549 encrypting traffic before hand-off to a service provider. 551 5.3. Privacy Considerations 553 Privacy of transport nework slice service consumers must be 554 preserved. It should not be possible for one transport slice 555 consumer to discover the presence of other consumers, nor should 556 sites that are members of one transport slice be visible outside the 557 context of that transport slice. 559 In this sense, it is of paramount importance that the system use the 560 privacy protection mechanism defined for the specific underlying 561 technologies used, including in particular those mechanisms designed 562 to preclude acquiring identifying information associated with any 563 transport slice consumer. 565 5.4. IANA Considerations 567 There are no requests to IANA in this framework document. 569 6. Acknowledgments 571 The entire TEAS NS design team and everyone participating in related 572 discussions has contributed to this draft. Some text fragments in 573 the draft have been copied from the [I-D.ietf-teas-enhanced-vpn], for 574 which we are grateful. 576 Significant contributions to this document were gratefully received 577 from the contributing authors listed in the "Contributors" section. 578 In addition we would like to also thank those others who have 579 attended one or more of the design team meetings, including: 581 * Aihua Guo 583 * Bo Wu 585 * Greg Mirsky 587 * Jeff Tantsura 589 * Jie Dong 591 * Kiran Makhijani 593 * Lou Berger 595 * Luis M. Contreras 597 * Rakesh Gandhi 599 * Ren Chen 601 * Sergio Belotti 603 * Shunsuke Homma 605 * Stewart Bryant 607 * Tomonobu Niwa 609 * Xuesong Geng 610 * Xufeng Liu 612 7. References 614 7.1. Normative References 616 [I-D.nsdt-teas-transport-slice-definition] 617 Rokui, R., Homma, S., Makhijani, K., and L. Contreras, 618 "IETF Definition of Transport Slice", Work in Progress, 619 Internet-Draft, draft-nsdt-teas-transport-slice- 620 definition-01, 9 March 2020, . 624 7.2. Informative References 626 [BBF-SD406] 627 Broadband Forum, ., "End-to-end network slicing", BBF 628 SD-406 , n.d.. 630 [I-D.ietf-teas-actn-yang] 631 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 632 Shin, J., and S. Belotti, "Applicability of YANG models 633 for Abstraction and Control of Traffic Engineered 634 Networks", Work in Progress, Internet-Draft, draft-ietf- 635 teas-actn-yang-05, 19 February 2020, . 638 [I-D.ietf-teas-enhanced-vpn] 639 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 640 Framework for Enhanced Virtual Private Networks (VPN+) 641 Services", Work in Progress, Internet-Draft, draft-ietf- 642 teas-enhanced-vpn-05, 18 February 2020, 643 . 646 [I-D.ietf-teas-te-service-mapping-yang] 647 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 648 and J. Tantsura, "Traffic Engineering (TE) and Service 649 Mapping Yang Model", Work in Progress, Internet-Draft, 650 draft-ietf-teas-te-service-mapping-yang-03, 8 March 2020, 651 . 654 [I-D.openconfig-rtgwg-gnmi-spec] 655 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 656 C., and C. Morrow, "gRPC Network Management Interface 657 (gNMI)", Work in Progress, Internet-Draft, draft- 658 openconfig-rtgwg-gnmi-spec-01, 5 March 2018, 659 . 662 [NGMN-NS-Concept] 663 NGMN Alliance, ., "Description of Network Slicing 664 Concept", https://www.ngmn.org/uploads/ 665 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 666 2016. 668 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 669 Schoenwaelder, Ed., "Structure of Management Information 670 Version 2 (SMIv2)", STD 58, RFC 2578, 671 DOI 10.17487/RFC2578, April 1999, 672 . 674 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 675 "Message Processing and Dispatching for the Simple Network 676 Management Protocol (SNMP)", STD 62, RFC 3412, 677 DOI 10.17487/RFC3412, December 2002, 678 . 680 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 681 (USM) for version 3 of the Simple Network Management 682 Protocol (SNMPv3)", STD 62, RFC 3414, 683 DOI 10.17487/RFC3414, December 2002, 684 . 686 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 687 Network Management Protocol (SNMP)", STD 62, RFC 3417, 688 DOI 10.17487/RFC3417, December 2002, 689 . 691 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 692 "Generalized Multiprotocol Label Switching (GMPLS) User- 693 Network Interface (UNI): Resource ReserVation Protocol- 694 Traffic Engineering (RSVP-TE) Support for the Overlay 695 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 696 . 698 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 699 Interpretation of Generalized Multiprotocol Label 700 Switching (GMPLS) Terminology within the Context of the 701 ITU-T's Automatically Switched Optical Network (ASON) 702 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 703 2006, . 705 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 706 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 707 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 708 DOI 10.17487/RFC5212, July 2008, 709 . 711 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 712 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 713 DOI 10.17487/RFC5440, March 2009, 714 . 716 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 717 the Network Configuration Protocol (NETCONF)", RFC 6020, 718 DOI 10.17487/RFC6020, October 2010, 719 . 721 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 722 and A. Bierman, Ed., "Network Configuration Protocol 723 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 724 . 726 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 727 Ceccarelli, D., and X. Zhang, "Problem Statement and 728 Architecture for Information Exchange between 729 Interconnected Traffic-Engineered Networks", BCP 206, 730 RFC 7926, DOI 10.17487/RFC7926, July 2016, 731 . 733 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 734 RFC 7950, DOI 10.17487/RFC7950, August 2016, 735 . 737 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 738 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 739 . 741 [RFC8353] Upadhyay, M., Malkani, S., and W. Wang, "Generic Security 742 Service API Version 2: Java Bindings Update", RFC 8353, 743 DOI 10.17487/RFC8353, May 2018, 744 . 746 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 747 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 748 DOI 10.17487/RFC8453, August 2018, 749 . 751 [TS23501] 3GPP, ., "System architecture for the 5G System (5GS)", 752 3GPP TS 23.501 , 2019. 754 [TS28530] 3GPP, ., "Management and orchestration; Concepts, use 755 cases and requirements", 3GPP TS 28.530 , 2019. 757 Contributors 759 The following authors contributed significantly to this document: 761 Jari Arkko 762 Ericsson 764 Email: jari.arkko@piuha.net 766 Dhruv Dhody 767 Huawei, India 769 Email: dhruv.ietf@gmail.com 771 Reza Rokui 772 Nokia 774 Email: reza.rokui@nokia.com 776 Xufeng Liu 778 Email: xufeng.liu.ietf@gmail.com 780 Jie Dong 781 Huawei 783 Email: jie.dong@huawei.com 785 Authors' Addresses 787 Eric Gray (editor) 788 Ericsson 790 Email: eric.gray@ericsson.com 792 John Drake (editor) 793 Juniper Networks 795 Email: jdrake@juniper.net