idnits 2.17.1 draft-nsdt-teas-ns-framework-04.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 (13 July 2020) is 1376 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-03 == 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: 14 January 2021 Juniper Networks 6 13 July 2020 8 Framework for Transport Network Slices 9 draft-nsdt-teas-ns-framework-04 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 a number 26 of these technologies, and new technologies or capabilities keep 27 being added. This memo is also not intended presume any particular 28 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 14 January 2021. 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 Interface (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 . . . . . . . . . . . . . . . . . 13 76 5.3. Privacy Considerations . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 This draft provides a framework for discussing transport slices, as 88 defined in [I-D.nsdt-teas-transport-slice-definition] It is the 89 intention in this document to use terminology consistent with this 90 and other definitions provided in that draft. 92 In particular, this document uses the following terminology defined 93 in the definitions document: 95 * Transport Slice 97 * Transport Slice Controller (TSC) 99 * Transport Network Controller (TNC) 101 * Northbound Interface (NBI) 103 * Southbound Interface (SBI) 105 This framework is intended as a structure for discussing interfaces 106 and technologies. It is not intended to be a new set of concrete 107 interfaces or technologies. Rather, the idea is that existing or 108 under-development IETF technologies (plural) can be used to realize 109 the ideas expressed here. 111 For example, virtual private networks (VPNs) have served the industry 112 well as a means of providing different groups of users with logically 113 isolated access to a common network. The common or base network that 114 is used to provide the VPNs is often referred to as an underlay 115 network, and the VPN is often called an overlay network. As an 116 example technology, a VPN may in turn serve as an underlay network 117 for transport slices. 119 Note: It is conceivable that extensions to these IETF technologies 120 are needed in order to fully support all the ideas that can be 121 implemented with slices, but at least in the beginning there is no 122 plan for the creation of new protocols or interfaces. 124 Driven largely by needs surfacing from 5G, the concept of network 125 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 126 and [BBF-SD406]). In [TS23501], Network Slice is defined as "a 127 logical network that provides specific network capabilities and 128 network characteristics", and a Network Slice Instance is defined as 129 "A set of Network Function instances and the required resources (e.g. 130 compute, storage and networking resources) which form a deployed 131 Network Slice". According to [TS28530], an end-to-end network slice 132 consists of three major types of network segments: Radio Access 133 Network (RAN), Transport Network (TN) and Core Network (CN). 134 Transport network provides the required connectivity between 135 different entities in RAN and CN segments of an end-to-end network 136 slice, with a specific performance commitment. For each end-to-end 137 network slice, the topology and performance requirement on transport 138 network can be very different, which requires the transport network 139 to have the capability of supporting multiple different transport 140 slices. 142 While network slices are commonly discussed in the context of 5G, it 143 is important to note that transport slices are a narrower concept, 144 and focus primarily on particular network connectivity aspects. 145 Other systems, including 5G deployments, may use transport slices as 146 a component to create entire systems and concatenated constructs that 147 match their needs, including end-to-end connectivity. 149 A transport slice could span multiple technologies and multiple 150 administrative domains. Depending on the transport slice consumer's 151 requirements, a transport slice could be isolated from other, often 152 concurrent transport slices in terms of data, control and management 153 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 user's 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 users of the transport network infrastructure. 268 The benefits of this model can include: 270 * Security: because the transport network (or network operator) does 271 not need to expose network details (topology, capacity, etc.) to 272 transport slice consumers the transport network components are 273 less exposed to attack; 275 * Layered Implementation: the transport network comprises network 276 elements that belong to a different layer network than consumer 277 applications, and network information (advertisements, protocols, 278 etc.) that a consumer cannot interpret or respond to (note - a 279 consumer should not use network information not exposed via the 280 TSC NBI, even if that information is available); 282 * Scalability: consumers do not need to know any information beyond 283 that which is exposed via the NBI. 285 The general issues of abstraction in a TE network is described more 286 fully in [RFC7926]. 288 This framework document does not assume any particular layer at which 289 transport slices operate as a number of layers (including virtual L2, 290 Ethernet or IP connectivity) could be employed. 292 Data models and interfaces are of course needed to set up transport 293 slices, and specific interfaces may have capabilities that allow 294 creation of specific layers. 296 Layered virtual connections are comprehensively discussed in IETF 297 documents and are widely supported. See, for instance, GMPLS-based 298 networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and 299 [RFC8454]). The principles and mechanisms associated with layered 300 networking are applicable to transport slices. 302 There are several IETF-defined mechanisms for expressing the need for 303 a desired logical network. The NBI carries data either in a 304 protocol-defined format, or in a formalism associated with a modeling 305 language. 307 For instance: 309 * Path Computation Element (PCE) Communication Protocol (PCEP) 310 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 311 [RFC4208] use a TLV-based binary encoding to transmit data. 313 * Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 314 Protocol [RFC8040] use XML abnd JSON encoding. 316 * gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 317 programmable interface; 319 * SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding 320 (ASN.1). 322 * For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 323 model configuration and other data for NETCONF, RESTCONF, and GNMI 324 - among others; ProtoBufs can be used to model gRPC and GNMI data; 325 Structure of Management Information (SMI) [RFC2578] may be used to 326 define Management Information Base (MIB) modules for SNMP, using 327 an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 328 1988). 330 While several generic formats and data models for specific purposes 331 exist, it is expected that transport slice management may require 332 enhancement or augmentation of existing data models. 334 3.3. Transport Slice Controller (TSC) 336 The transport slice controller takes abstract requests for transport 337 slices and implements them using a suitable underlying technology. A 338 transport slice controller is the key building block for control and 339 management of the transport slice. It provides the 340 creation/modification/deletion, monitoring and optimization of 341 transport Slices in a multi-domain, a multi-technology and multi- 342 vendor environment. 344 A TSC northbound interface (NBI) is needed for communicating details 345 of a transport slice (configuration, selected policies, operational 346 state, etc.), as well as providing information to a slice requester/ 347 consumer about transport slice status and performance. The details 348 for this NBI are not in scope for this document. 350 The controller provides the following functions: 352 * Provides a technology-agnostic NBI for creation/modification/ 353 deletion of the transport slices. The API exposed by this NBI 354 communicates the endpoints of the transport slice, transport slice 355 SLO parameters (and possibly monitoring thresholds), applicable 356 input selection (filtering) and various policies, and provides a 357 way to monitor the slice. 359 * Determines an abstract topology connecting the endpoints of the 360 transport slice that meets criteria specified via the NBI.The TSC 361 also retains information about the mapping of this abstract 362 topology to underlying components of the transport slice as 363 necessary to monitor transport slice status and performance. 365 * Provides "Mapping Functions" for the realization of transport 366 slices. In other words, it will use the mapping functions that: 368 map technology-agnostic NBI request to technology-specific SBIs. 370 map filtering/selection information as necessary to entities in 371 the underlay network. 373 * Via an SBI, the controller collects telemetry data (e.g. OAM 374 results, statistics, states etc.) for all elements in the abstract 375 topology used to realize the transport slice. 377 * Using the telemetry data from the underlying realization of a 378 transport slice (i.e. services/paths/tunnels), evaluates the 379 current performance against transport slice SLO parameters and 380 exposes them to the transport slice consumer via the NBI. The TSC 381 NBI may also include a capability to provide notification in case 382 the transport slice performance reaches threshold values defined 383 by the transport slice consumer. 385 3.3.1. Northbound Interface (NBI) 387 The Transport Slice Controller provides a Northbound Interface (NBI) 388 that allows consumers of network slices to request and monitor 389 transport slices. Consumers operate on abstract transport slices, 390 with details related to their realization hidden. 392 The NBI complements various IETF services, tunnels, path models by 393 providing an abstract layer on top of these models. 395 The NBI is independent of type of network functions or services that 396 need to be connected, i.e. it is independent of any specific storage, 397 software, protocol, or platform used to realize physical or virtual 398 network connectivity or functions in support of transport slices. 400 The NBI uses protocol mechanisms and information passed over those 401 mechanisms to convey desired attributes for transport slices and 402 their status. The information is expected to be represented as a 403 well-defined data model, and should include at least endpoint and 404 connectivity information, SLO specification, and status information. 406 To accomplish this, the NBI needs to convey information needed to 407 support communication across the NBI, in terms of identifying the 408 transport slices, as well providing the above model information. 410 3.4. Mapping 412 The main task of the transport slice controller is to map abstract 413 transport slice requirements to concrete technologies and establish 414 the required connectivity, and ensuring that required resources are 415 allocated to the transport slice. 417 3.5. Underlying technology 419 There are a number of different technologies that can be used, 420 including physical connections, MPLS, TSN, Flex-E, etc. 422 See [I-D.ietf-teas-enhanced-vpn] - section 5 - for instance, for 423 example underlying technologies. 425 Also, as outlined in "applicability of ACTN to Transport Slices" 426 below, ACTN ([RFC8453]) offers a framework that is used elsewhere in 427 IETF specifications to create virtual network (VN) services similar 428 to Transport Slices. 430 A transport slice can be realized in a network, using specific 431 underlying technology or technologies. The creation of a new 432 transport slice will be initiated with following three steps: 434 * Step 1: A higher level system requests connections with specific 435 characteristics via NBI. 437 * Step 2: This request will be processed by a Transport Slice 438 Controller which specifies a mapping between northbound request to 439 any IETF Services, Tunnels, and paths models. 441 * Step 3: A series of requests for creation of services, tunnels and 442 paths will be sent to the network to realize the trasport slice. 444 It is very clear that regardless of how transport slice is realized 445 in the network (i.e. using tunnels of type RSVP or SR), the 446 definition of transport slice does not change at all but rather its 447 realization. 449 4. Applicability of ACTN to Transport Slices 451 Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an 452 example of similar IETF work. ACTN defines three controllers to 453 support virtual network (VN) services - 455 * Customer Network Controller (CNC), 457 * Multi-Domain Service Coordinator (MDSC) and 459 * Provisioning Network Controller (PNC). 461 A CNC is responsible for communicating a customer's VN requirements. 463 A MDSC is responsible for multi-domain coordination, virtualization 464 (or abstraction), customer mapping/translation and virtual service 465 coordination to realize the VN requirement. Its key role is to 466 detach the network/service requirements from the underlying 467 technology. 469 A PNC oversees the configuration, monitoring and collection of the 470 network topology. The PNC is a underlay technology specific 471 controller. 473 While the ACTN framework is a generic VN framework that is used for 474 various VN service beyond the transport slice, it is still a suitable 475 basis to understand how the various controllers interact to realize a 476 transport slice. 478 One possible mapping between the transport slice, and ACTN, 479 definitions is as shown in Figure 1 below. 481 +-------------------------------------+ 482 | Customer | | 483 +-------------------------------------+ 484 ^ | ACTN 485 | Terminology 486 v | and Concepts 487 +-------------------------------------+ 488 | A higher level operation system | | +-----+ 489 |(e.g. e2e network slice orchestrator)| ===> | CNC | 490 +-------------------------------------+ | +-----+ 491 ^ ^ 492 | TSC NBI | | CMI 493 v v 494 +-------------------------------------+ | +------+ 495 | Transport Slice Controller | ===> | MDSC | 496 +-------------------------------------+ | +------+ 497 ^ ^ 498 | TSC SBI | | MPI 499 v v 500 +-------------------------------------+ | +-----+ 501 | Transport Network Controller(s) | ===> | PNC | 502 +-------------------------------------+ | +-----+ 504 Terminology/Concepts | 505 Used in this Document 506 | 508 Figure 1 510 Note that the left-hand side of this figure comes from Transport 511 Slice Definition ([I-D.nsdt-teas-transport-slice-definition]). 513 The TSC NBI conveys the generic transport slice requirements. These 514 may then be realized using an SBI within the TSC. 516 As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC 517 Interface (CMI) is used to convey the virtual network service 518 requirements along with the service models and the MDSC-PNC Interface 519 (MPI) is used to realize the service along network configuration 520 models. [I-D.ietf-teas-te-service-mapping-yang] further describe how 521 the VPN services can be mapped to the underlying TE resources. 523 The Transport Network Controller (TNC) is depicted as a single block, 524 analogous to the Provisioning Network Controller (in this example). 525 In the ACTN framework, however, it is also possible that the TNC 526 function is decomposed into MDSC and PNC - that is, the TNC may 527 comprise hierarchy as needed to handle the multiple domains and 528 various underlay technologies, whereas a PNC in ACTN is intended to 529 be specific to at most a single underlay technology and (likely) to 530 individual devices (or functional components). 532 Note that the details of potential implementations of everything that 533 is below the TSC in Figure 1 are out of scope in this document - 534 hence the specifics of the relationship between TNC and PNC, and the 535 possibility that the MDSC and PNC may be combined are at most 536 academically interesting in this context. Another way to view this 537 is that, in the same way that ACTN might combine MDSC and PNC, the 538 TSC might also directly include TNC functionality. 540 [RFC8453] also describes TE Network Slicing in the context of ACTN as 541 a collection of resources that is used to establish a logically 542 dedicated virtual network over one or more TE networks. In case of 543 TE enabled underlying network, ACTN VN can be used as a base to 544 realize the transport network slicing by coordination among multiple 545 peer domains as well as underlay technology domains. 547 Figure 1 shows only one possible mapping as each ACTN component (or 548 interface) in the figure may be a composed differently in other 549 mappings, and the exact role of both components and subcomponents 550 will not be always an exact analogy between the concepts used in this 551 document and those defined in ACTN. 553 This is - in part - shown in a previous paragraph in this section 554 where it is pointed out that the TNC may actually subsume some 555 aspects of both the MDSC and PNC. 557 Similarly, in part depending on how "customer" is interpreted, CNC 558 might merge some aspects of the higher level system and the TSC. As 559 in the TNC/PNC case, this way of comparing ACTN to this work is not 560 useful as the TSC and TSC NBI are the focus on this document. 562 5. Considerations 564 5.1. Monitoring 566 Transport slice realization needs to be instrumented in order to 567 track how it is working, and it might be necessary to modify the 568 transport slice as requirements change. Dynamic reconfiguration 569 might be needed. 571 5.2. Security Considerations 573 Transport slices might use underlying virtualized networking. All 574 types of virtual networking require special consideration to be given 575 to the separation of traffic between distinct virtual networks, as 576 well as some degree of protection from effects of traffic use of 577 underlying network (and other) resources from other virtual networks 578 sharing those resources. 580 For example, if a service requires a specific upper bound of latency, 581 then that service can be degraded by added delay in transmission of 582 service packets through the activities of another service or 583 application using the same resources. 585 Similarly, in a network with virtual functions, noticeably impeding 586 access to a function used by another transport slice (for instance, 587 compute resources) can be just as service degrading as delaying 588 physical transmission of associated packet in the network. 590 While a transport slice might include encryption and other security 591 features as part of the service, consumers might be well advised to 592 take responsibility for their own security needs, possibly by 593 encrypting traffic before hand-off to a service provider. 595 5.3. Privacy Considerations 597 Privacy of transport network slice service consumers must be 598 preserved. It should not be possible for one transport slice 599 consumer to discover the presence of other consumers, nor should 600 sites that are members of one transport slice be visible outside the 601 context of that transport slice. 603 In this sense, it is of paramount importance that the system use the 604 privacy protection mechanism defined for the specific underlying 605 technologies used, including in particular those mechanisms designed 606 to preclude acquiring identifying information associated with any 607 transport slice consumer. 609 5.4. IANA Considerations 611 There are no requests to IANA in this framework document. 613 6. Acknowledgments 615 The entire TEAS NS design team and everyone participating in related 616 discussions has contributed to this draft. Some text fragments in 617 the draft have been copied from the [I-D.ietf-teas-enhanced-vpn], for 618 which we are grateful. 620 Significant contributions to this document were gratefully received 621 from the contributing authors listed in the "Contributors" section. 622 In addition we would like to also thank those others who have 623 attended one or more of the design team meetings, including: 625 * Aihua Guo 627 * Bo Wu 629 * Greg Mirsky 631 * Jeff Tantsura 633 * Kiran Makhijani 635 * Lou Berger 637 * Luis M. Contreras 639 * Rakesh Gandhi 641 * Ren Chen 643 * Sergio Belotti 645 * Shunsuke Homma 647 * Stewart Bryant 649 * Tomonobu Niwa 651 * Xuesong Geng 653 7. References 655 7.1. Normative References 657 [I-D.nsdt-teas-transport-slice-definition] 658 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 659 Tantsura, "IETF Definition of Transport Slice", Work in 660 Progress, Internet-Draft, draft-nsdt-teas-transport-slice- 661 definition-03, 12 July 2020, . 665 7.2. Informative References 667 [BBF-SD406] 668 Broadband Forum, ., "End-to-end network slicing", BBF 669 SD-406 , n.d.. 671 [I-D.ietf-teas-actn-yang] 672 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 673 Shin, J., and S. Belotti, "Applicability of YANG models 674 for Abstraction and Control of Traffic Engineered 675 Networks", Work in Progress, Internet-Draft, draft-ietf- 676 teas-actn-yang-05, 19 February 2020, . 679 [I-D.ietf-teas-enhanced-vpn] 680 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 681 Framework for Enhanced Virtual Private Networks (VPN+) 682 Services", Work in Progress, Internet-Draft, draft-ietf- 683 teas-enhanced-vpn-05, 18 February 2020, 684 . 687 [I-D.ietf-teas-te-service-mapping-yang] 688 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 689 and J. Tantsura, "Traffic Engineering (TE) and Service 690 Mapping Yang Model", Work in Progress, Internet-Draft, 691 draft-ietf-teas-te-service-mapping-yang-03, 8 March 2020, 692 . 695 [I-D.openconfig-rtgwg-gnmi-spec] 696 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 697 C., and C. Morrow, "gRPC Network Management Interface 698 (gNMI)", Work in Progress, Internet-Draft, draft- 699 openconfig-rtgwg-gnmi-spec-01, 5 March 2018, 700 . 703 [NGMN-NS-Concept] 704 NGMN Alliance, ., "Description of Network Slicing 705 Concept", https://www.ngmn.org/uploads/ 706 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 707 2016. 709 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 710 Schoenwaelder, Ed., "Structure of Management Information 711 Version 2 (SMIv2)", STD 58, RFC 2578, 712 DOI 10.17487/RFC2578, April 1999, 713 . 715 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 716 "Message Processing and Dispatching for the Simple Network 717 Management Protocol (SNMP)", STD 62, RFC 3412, 718 DOI 10.17487/RFC3412, December 2002, 719 . 721 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 722 (USM) for version 3 of the Simple Network Management 723 Protocol (SNMPv3)", STD 62, RFC 3414, 724 DOI 10.17487/RFC3414, December 2002, 725 . 727 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 728 Network Management Protocol (SNMP)", STD 62, RFC 3417, 729 DOI 10.17487/RFC3417, December 2002, 730 . 732 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 733 "Generalized Multiprotocol Label Switching (GMPLS) User- 734 Network Interface (UNI): Resource ReserVation Protocol- 735 Traffic Engineering (RSVP-TE) Support for the Overlay 736 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 737 . 739 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 740 Interpretation of Generalized Multiprotocol Label 741 Switching (GMPLS) Terminology within the Context of the 742 ITU-T's Automatically Switched Optical Network (ASON) 743 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 744 2006, . 746 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 747 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 748 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 749 DOI 10.17487/RFC5212, July 2008, 750 . 752 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 753 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 754 DOI 10.17487/RFC5440, March 2009, 755 . 757 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 758 the Network Configuration Protocol (NETCONF)", RFC 6020, 759 DOI 10.17487/RFC6020, October 2010, 760 . 762 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 763 and A. Bierman, Ed., "Network Configuration Protocol 764 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 765 . 767 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 768 Ceccarelli, D., and X. Zhang, "Problem Statement and 769 Architecture for Information Exchange between 770 Interconnected Traffic-Engineered Networks", BCP 206, 771 RFC 7926, DOI 10.17487/RFC7926, July 2016, 772 . 774 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 775 RFC 7950, DOI 10.17487/RFC7950, August 2016, 776 . 778 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 779 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 780 . 782 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 783 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 784 DOI 10.17487/RFC8453, August 2018, 785 . 787 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 788 Yoon, "Information Model for Abstraction and Control of TE 789 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 790 September 2018, . 792 [TS23501] 3GPP, ., "System architecture for the 5G System (5GS)", 793 3GPP TS 23.501 , 2019. 795 [TS28530] 3GPP, ., "Management and orchestration; Concepts, use 796 cases and requirements", 3GPP TS 28.530 , 2019. 798 Contributors 800 The following authors contributed significantly to this document: 802 Jari Arkko 803 Ericsson 805 Email: jari.arkko@piuha.net 807 Dhruv Dhody 808 Huawei, India 810 Email: dhruv.ietf@gmail.com 812 Reza Rokui 813 Nokia 815 Email: reza.rokui@nokia.com 817 Xufeng Liu 819 Email: xufeng.liu.ietf@gmail.com 821 Jie Dong 822 Huawei 824 Email: jie.dong@huawei.com 826 Authors' Addresses 828 Eric Gray (editor) 829 Ericsson 831 Email: eric.gray@ericsson.com 833 John Drake (editor) 834 Juniper Networks 836 Email: jdrake@juniper.net