idnits 2.17.00 (12 Aug 2021) /tmp/idnits2982/draft-ietf-teas-ietf-network-slices-00.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 (April 14, 2021) is 402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EP1' is mentioned on line 821, but not defined == Missing Reference: 'EP2' is mentioned on line 821, but not defined == Missing Reference: 'EPm' is mentioned on line 825, but not defined == Missing Reference: 'EPn' is mentioned on line 825, but not defined == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-03 == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-yang-06 == Outdated reference: A later version (-10) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-10) exists of draft-ietf-teas-te-service-mapping-yang-05 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel, Ed. 3 Internet-Draft Old Dog Consulting 4 Intended status: Informational E. Gray 5 Expires: October 16, 2021 Ericsson 6 J. Drake 7 Juniper Networks 8 R. Rokui 9 Nokia 10 S. Homma 11 NTT 12 K. Makhijani 13 Futurewei 14 LM. Contreras 15 Telefonica 16 J. Tantsura 17 Juniper Networks 18 April 14, 2021 20 Framework for IETF Network Slices 21 draft-ietf-teas-ietf-network-slices-00 23 Abstract 25 27 This memo discusses setting up special-purpose network connections 28 using existing IETF technologies. These connections are called IETF 29 network slices for the purposes of this memo. The memo discusses the 30 general framework for this setup, the necessary system components and 31 interfaces, and how abstract requests can be mapped to more specific 32 technologies. The memo also discusses related considerations with 33 monitoring and security. 35 This memo is intended for discussing interfaces and technologies. It 36 is not intended to be a new set of concrete interfaces or 37 technologies. Rather, it should be seen as an explanation of how 38 some existing, concrete IETF VPN and traffic-engineering technologies 39 can be used to create IETF network slices. Note that there are a 40 number of these technologies, and new technologies or capabilities 41 keep being added. This memo is also not intended presume any 42 particular technology choice. 44 46 This document provides a definition of the term "IETF Network Slice" 47 for use within the IETF and specifically as a reference for other 48 IETF documents that describe or use aspects of network slices. 50 The document also describes the characteristics of an IETF network 51 slice, related terms and their meanings, and explains how IETF 52 network slices can be used in combination with end-to-end network 53 slices or independent of them. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on October 16, 2021. 72 Copyright Notice 74 Copyright (c) 2021 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (https://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 6 91 3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 7 92 3.1. Definition and Scope of IETF Network Slice . . . . . . . 7 93 4. IETF Network Slice System Characteristics . . . . . . . . . . 8 94 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 8 95 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 9 96 4.1.2. Minimal Set of SLOs . . . . . . . . . . . . . . . . . 9 97 4.1.3. Other Objectives . . . . . . . . . . . . . . . . . . 11 99 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 11 100 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 13 101 4.3. IETF Network Slice Composition . . . . . . . . . . . . . 13 102 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14 103 5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 15 104 5.2. Management Systems or Other Applications . . . . . . . . 15 105 5.3. Expressing Connectivity Intents . . . . . . . . . . . . . 16 106 5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 17 107 5.5. IETF Network Slice Controller (NSC) . . . . . . . . . . . 19 108 5.5.1. IETF Network Slice Controller Interfaces . . . . . . 20 109 5.5.2. Northbound Interface (NBI) . . . . . . . . . . . . . 21 110 5.6. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 22 111 5.7. Realizing IETF Network Slice . . . . . . . . . . . . . . 22 112 5.7.1. Underlying Technology . . . . . . . . . . . . . . . . 22 113 6. Applicability of ACTN to IETF Network Slices . . . . . . . . 23 114 7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 25 115 7.1. Isolation as a Service Requirement . . . . . . . . . . . 25 116 7.2. Isolation in IETF Network Slice Realization . . . . . . . 26 117 8. Management Considerations . . . . . . . . . . . . . . . . . . 26 118 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 119 9.1. Privacy Considerations . . . . . . . . . . . . . . . . . 28 120 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 121 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 122 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 123 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 124 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 125 13.2. Informative References . . . . . . . . . . . . . . . . . 30 126 Appendix A. Unused Material . . . . . . . . . . . . . . . . . . 34 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 129 1. Introduction 131 ===================== EDITOR'S NOTE ===================== 133 This document is a merge of the text in 134 [I-D.ietf-teas-ietf-network-slice-definition] and 135 [I-D.ietf-teas-ietf-network-slice-framework]. In this version, the 136 text is presented as a simple inclusion of all text from the 137 contributing documents. The only work performed by the Editor in 138 this revision is the assignment of text to the sections of the 139 document, and the marking of the text to indicate its origin, as well 140 as simple editorial fixes to resolve the most basic typographic and 141 formatting issues. 143 For this purpose, the text in this revision is tagged to show its 144 origin using the format or where the letters 'D' and 145 'F' indicate the definitions draft 146 [I-D.ietf-teas-ietf-network-slice-definition] and the framework draft 148 [I-D.ietf-teas-ietf-network-slice-framework] respectively, and the 149 subsequent numbers indicate the the section of the source document. 151 In the case that the source text is not used within the document, it 152 is presented in Appendix A. 154 It is expected that this is a short term measure and that later 155 revisions will be presented as text in its own right. 157 =================== END EDITOR'S NOTE =================== 159 161 A number of use cases benefit from network connections that along 162 with the connectivity provide assurance of meeting a specific set of 163 objectives wrt network resources use. In this document, as detailed 164 in the subsequent sections, we refer to this connectivity and 165 resource commitment as an IETF Network Slice. Services that might 166 benefit from the network slices include but not limited to: 168 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501]) 170 o Network wholesale services 172 o Network infrastructure sharing among operators 174 o NFV connectivity and Data Center Interconnect 176 The use cases are further described in 177 [I-D.ietf-teas-ietf-network-slice-framework]. 179 This document defines the concept of IETF network slices that provide 180 connectivity coupled with a set of specific commitments of network 181 resources between a number of endpoints over a shared network 182 infrastructure. Since the term network slice is rather generic, the 183 qualifying term 'IETF' is used in this document to limit the scope of 184 network slice to network technologies described and standardized by 185 the IETF. 187 IETF network slices are created and managed within the scope of one 188 or more network technologies (e.g., IP, MPLS, optical). They are 189 intended to enable a diverse set of applications that have different 190 requirements to coexist on the shared network infrastructure. A 191 request for an IETF network slice is technology-agnostic so as to 192 allow a consumer to describe their network connectivity objectives in 193 a common format, independent of the underlying technologies used. 195 196 This document provides a framework for discussing IETF network 197 slices, as defined in [I-D.ietf-teas-ietf-network-slice-definition]. 198 It is the intention in this document to use terminology consistent 199 with this and other definitions provided in that document. 201 In particular, this document uses the following terminology defined 202 in the definitions document: 204 o IETF Network Slice 206 o IETF Network Slice Controller (NSC) 208 o Network Controller (NC) 210 o Northbound Interface (NBI) 212 o Southbound Interface (SBI) 214 This framework is intended as a structure for discussing interfaces 215 and technologies. It is not intended to specify a new set of 216 concrete interfaces or technologies. Rather, the idea is that 217 existing or under-development IETF technologies (plural) can be used 218 to realize the concepts expressed herein. 220 For example, virtual private networks (VPNs) have served the industry 221 well as a means of providing different groups of users with logically 222 isolated access to a common network. The common or base network that 223 is used to provide the VPNs is often referred to as an underlay 224 network, and the VPN is often called an overlay network. As an 225 example technology, a VPN may in turn serve as an underlay network 226 for IETF network slices. 228 Note: It is conceivable that extensions to these IETF technologies 229 are needed in order to fully support all the ideas that can be 230 implemented with slices, but at least in the beginning there is no 231 plan for the creation of new protocols or interfaces. 233 Driven largely by needs surfacing from 5G, the concept of network 234 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 235 and [BBF-SD406]). In [TS23501], Network Slice is defined as "a 236 logical network that provides specific network capabilities and 237 network characteristics", and a Network Slice Instance is defined as 238 "A set of Network Function instances and the required resources (e.g. 239 compute, storage and networking resources) which form a deployed 240 Network Slice." According to [TS28530], an end-to-end network slice 241 consists of three major types of network segments: Radio Access 242 Network (RAN), Transport Network (TN) and Core Network (CN). IETF 243 network slice provides the required connectivity between different 244 entities in RAN and CN segments of an end-to-end network slice, with 245 a specific performance commitment. For each end-to-end network 246 slice, the topology and performance requirement on a consumer's use 247 of IETF network slice can be very different, which requires the 248 underlay network to have the capability of supporting multiple 249 different IETF network slices. 251 While network slices are commonly discussed in the context of 5G, it 252 is important to note that IETF network slices are a narrower concept, 253 and focus primarily on particular network connectivity aspects. 254 Other systems, including 5G deployments, may use IETF network slices 255 as a component to create entire systems and concatenated constructs 256 that match their needs, including end-to-end connectivity. 258 A IETF network slice could span multiple technologies and multiple 259 administrative domains. Depending on the IETF network slice 260 consumer's requirements, an IETF network slice could be isolated from 261 other, often concurrent IETF network slices in terms of data, control 262 and management planes. 264 The consumer expresses requirements for a particular IETF network 265 slice by specifying what is required rather than how the requirement 266 is to be fulfilled. That is, the IETF network slice consumer's view 267 of a IETF network slice is an abstract one. 269 Thus, there is a need to create logical network structures with 270 required characteristics. The consumer of such a logical network can 271 require a degree of isolation and performance that previously might 272 not have been satisfied by traditional overlay VPNs. Additionally, 273 the IETF network slice consumer might ask for some level of control 274 of their virtual networks, e.g., to customize the service paths in a 275 network slice. 277 This document specifies a framework for the use of existing 278 technologies as components to provide a IETF network slice service, 279 and might also discuss (or reference) modified and potential new 280 technologies, as they develop (such as candidate technologies 281 described in section 5 of [I-D.ietf-teas-enhanced-vpn]). 283 2. Terms and Abbreviations 285 287 The terms and abbreviations used in this document are listed below. 289 o NS: Network Slice 291 o NSC: Network Slice Controller 292 o NBI: NorthBound Interface 294 o SBI: SouthBound Interface 296 o SLI: Service Level Indicator 298 o SLO: Service Level Objective 300 o SLA: Service Level Agreement 302 The above terminology is defined in greater details in the remainder 303 of this document. 305 3. IETF Network Slice Objectives 307 309 It is intended that IETF network slices can be created to meet 310 specific requirements, typically expressed as bandwidth, latency, 311 latency variation, and other desired or required characteristics. 312 Creation is initiated by a management system or other application 313 used to specify network-related conditions for particular traffic 314 flows. 316 And it is intended that, once created, these slices can be monitored, 317 modified, deleted, and otherwise managed. 319 It is also intended that applications and components will be able to 320 use these IETF network slices to move packets between the specified 321 end-points in accordance with specified characteristics. 323 As an example of requirements that might apply to IETF network 324 slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3). 326 3.1. Definition and Scope of IETF Network Slice 328 330 The definition of a network slice in IETF context is as follows: 332 An IETF network slice is a logical network topology connecting a 333 number of endpoints using a set of shared or dedicated network 334 resources that are used to satisfy specific Service Level Objectives 335 (SLOs). 337 An IETF network slice combines the connectivity resource requirements 338 and associated network behaviors such as bandwidth, latency, jitter, 339 and network functions with other resource behaviors such as compute 340 and storage availability. IETF network slices are independent of the 341 underlying infrastructure connectivity and technologies used. This 342 is to allow an IETF network slice consumer to describe their network 343 connectivity and relevant objectives in a common format, independent 344 of the underlying technologies used. 346 IETF network slices may be combined hierarchically, so that a network 347 slice may itself be sliced. They may also be combined sequentially 348 so that various different networks can each be sliced and the network 349 slices placed into a sequence to provide an end-to-end service. This 350 form of sequential combination is utilized in some services such as 351 in 3GPP's 5G network [TS23501]. 353 An IETF network slice is technology-agnostic, and the means for IETF 354 network slice realization can be chosen depending on several factors 355 such as: service requirements, specifications or capabilities of 356 underlying infrastructure. The structure and different 357 characteristics of IETF network slices are described in the following 358 sections. 360 Term "Slice" refers to a set of characteristics and behaviours that 361 separate one type of user-traffic from another. IETF network slice 362 assumes that an underlying network is capable of changing the 363 configurations of the network devices on demand, through in-band 364 signaling or via controller(s) and fulfilling all or some of SLOs to 365 all of the traffic in the slice or to specific flows. 367 4. IETF Network Slice System Characteristics 369 371 The following subsections describe the characteristics of IETF 372 network slices. 374 4.1. Objectives for IETF Network Slices 376 378 An IETF network slice is defined in terms of several quantifiable 379 characteristics or service level objectives (SLOs). SLOs along with 380 terms Service Level Indicator (SLI) and Service Level Agreement (SLA) 381 are used to define the performance of a service at different levels. 383 A Service Level Indicator (SLI) is a quantifiable measure of an 384 aspect of the performance of a network. For example, it may be a 385 measure of throughput in bits per second, or it may be a measure of 386 latency in milliseconds. 388 A Service Level Objective (SLO) is a target value or range for the 389 measurements returned by observation of an SLI. For example, an SLO 390 may be expressed as "SLI <= target", or "lower bound <= SLI <= upper 391 bound". A network slice is expressed in terms of the set of SLOs 392 that are to be delivered for the different connections between 393 endpoints. 395 A Service Level Agreement (SLA) is an explicit or implicit contract 396 between the consumer of an IETF network slice and the provider of the 397 slice. The SLA is expressed in terms of a set of SLOs and may 398 include commercial terms as well as the consequences of missing/ 399 violating the SLOs they contain. 401 Additional descriptions of IETF network slice attributes is covered 402 in [I-D.contreras-teas-slice-nbi]. 404 4.1.1. Service Level Objectives 406 408 SLOs define a set of network attributes and characteristics that 409 describe an IETF network slice. SLOs do not describe 'how' the IETF 410 network slices are implemented or realized in the underlying network 411 layers. Instead, they are defined in terms of dimensions of 412 operation (time, capacity, etc.), availability, and other attributes. 413 An IETF network slice can have one or more SLOs associated with it. 414 The SLOs are combined in an SLA. The SLOs are defined for sets of 415 two or more endpoints and apply to specific directions of traffic 416 flow. That is, they apply to specific source endpoints and specific 417 connections between endpoints within the set of endpoints and 418 connections in the network slice. 420 4.1.2. Minimal Set of SLOs 422 424 This document defines a minimal set of SLOs and later systems or 425 standards could extend this set as per Section 4.1.3. 427 SLOs can be categorized in to 'Directly Measurable Objectives' or 428 'Indirectly Measurable Objectives'. Objectives such as guaranteed 429 minimum bandwidth, guaranteed maximum latency, maximum permissible 430 delay variation, maximum permissible packet loss rate, and 431 availability are 'Directly Measurable Objectives'. While 'Indirectly 432 Measurable Objectives' include security, geographical restrictions, 433 maximum occupancy level objectives. The later standard might define 434 other SLOs as needed. 436 Editor's Note TODO: replace Minimal set to most commonly used 437 objectives to describe network behavior. Other directly or 438 indirectly measurable objectives may be requested by that consumer of 439 an IETF network slice. 441 The definition of these objectives are as follows: 443 Guaranteed Minimum Bandwidth 445 Minimum guaranteed bandwidth between two endpoints at any time. 446 The bandwidth is measured in data rate units of bits per second 447 and is measured unidirectionally. 449 Guaranteed Maximum Latency 451 Upper bound of network latency when transmitting between two 452 endpoints. The latency is measured in terms of network 453 characteristics (excluding application-level latency). 454 [RFC2681] and [RFC7679] discuss round trip times and one-way 455 metrics, respectively. 457 Maximum Permissible Delay Variation 459 Packet delay variation (PDV) as defined by [RFC3393], is the 460 difference in the one-way delay between sequential packets in a 461 flow. This SLO sets a maximum value PDV for packets between 462 two endpoints. 464 Maximum permissible packet loss rate 466 The ratio of packets dropped to packets transmitted between two 467 endpoints over a period of time. See [RFC7680]. 469 Availability 471 The ratio of uptime to the sum of uptime and downtime, where 472 uptime is the time the IETF network slice is available in 473 accordance with the SLOs associated with it. 475 Security 477 An IETF network slice consumer may request that the network 478 applies encryption or other security techniques to traffic 479 flowing between endpoints. 481 Note that the use of security or the violation of this SLO is 482 not directly observable by the IETF network slice consumer and 483 cannot be measured as a quantifiable metric. 485 Also note that the objective may include request for encryption 486 (e.g., [RFC4303]) between the two endpoints explicitly to meet 487 architecture recommendations as in [TS33.210] or for compliance 488 with [HIPAA] and/or [PCI]. 490 Editor's Note: Please see more discussion on security in 491 Section 9. 493 4.1.3. Other Objectives 495 497 Additional SLOs may be defined to provide additional description of 498 the IETF network slice that a consumer requests. 500 If the IETF network slice consumer service is traffic aware, other 501 traffic specific characteristics may be valuable including MTU, 502 traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a 503 higher-level behavior to process traffic according to user- 504 application (which may be realized using network functions). 506 Maximal occupancy for an IETF network slice should be provided. 507 Since it carries traffic for multiple flows between the two 508 endpoints, the objectives should also say if they are for the entire 509 connection, group of flows or on per flow basis. Maximal occupancy 510 should specify the scale of the flows (i.e., maximum number of flows 511 to be admitted) and optionally a maximum number of countable resource 512 units, e.g., IP or MAC addresses a slice might consume. 514 4.2. IETF Network Slice Endpoints 516 518 As noted in Section 3.1, an IETF network slice describes connectivity 519 between multiple endpoints across the underlying network. These 520 connectivity types are: point-to-point, point-to-multipoint, 521 multipoint-to-point multipoint-to-point, or multipoint-to-multipoint. 523 Figure 1 shows an IETF network slice along with its NSEs. 525 The characteristics of IETF network slice endpoints (NSEs) are as 526 follows: 528 o The IETF network slice endpoints (NSEs) are conceptual points of 529 connection to IETF network slice. As such, they serve as the IETF 530 network slice ingress/egress points. 532 o Each endpoint could map to a device, application or a network 533 function. A non-exhaustive list of devices, applications or 534 network functions might include but not limited to: routers, 535 switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, 536 application acceleration, Deep Packet Inspection (DPI), server 537 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 538 enrichment functions, and TCP optimizers. 540 o An NSE should be identified by a unique ID in the context of an 541 IETF network slice consumer. 543 o In addition to an identifier, each NSE should contain a subset of 544 attributes such as IPv4/IPv6 addresses, encapsulation type (i.e., 545 VLAN tag, MPLS Label etc.), interface/port numbers, node ID etc. 547 o A combination of NSE unique ID and NSE attributes defines an NSE 548 in the context of the IETF network slice controller. 550 o During the realization of the IETF network slice, in addition to 551 SLOs, all or subset of IETF NSE attributes will be utilized by 552 IETF network slice controller (NSC) to find the optimal 553 realization in the IETF network. 555 o Similarly to IETF network slices, the IETF network slice endpoints 556 are logical entities that are mapped to services/tunnels/paths 557 endpoints in IETF network slice during its initialization and 558 realization. 560 Note that there are various IETF TE terms such as access points (AP) 561 defined in [RFC8453], Termination Point (TP) defined in [RFC8345], 562 and Link Termination Point (LTP) defined in [RFC8795] which are 563 tightly coupled with TE network type and various realization 564 techniques. At the time of realization of the IETF network slice, 565 the NSE could be mapped to one or more of these based on the network 566 slice realization technique in use. 568 |----------------------------------| 569 NSE1 | | NSE2 570 O.....| |.....O 571 . | | . 572 . | | . 573 . | | . 574 | | 575 NSEm | | NSEn 576 O.....| |.....O 577 | | 578 |----------------------------------| 580 <------------ IETF Network Slice --------------> 581 between endpoints NSE1 to NSEn 583 Legend: 584 NSE: IETF Network Slice Endpoint 585 O: Represents IETF Network Slice Endpoints 587 Figure 1: An IETF Network Slice Endpoints (NSE) 589 4.2.1. IETF Network Slice Connectivity Types 591 593 The IETF Network Slice connection types can be point to point (P2P), 594 point to multipoint (P2MP), multi-point to point (MP2P), or multi- 595 point to multi-point (MP2MP). They will requested by the higher 596 level operation system. 598 4.3. IETF Network Slice Composition 600 602 Operationally, an IETF network slice may be decomposed in two or more 603 IETF network slices as specified below. Decomposed network slices 604 are then independently realized and managed. 606 o Hierarchical (i.e., recursive) composition: An IETF network slice 607 can be further sliced into other network slices. Recursive 608 composition allows an IETF network slice at one layer to be used 609 by the other layers. This type of multi-layer vertical IETF 610 network slice associates resources at different layers. 612 o Sequential composition: Different IETF network slices can be 613 placed into a sequence to provide an end-to-end service. In 614 sequential composition, each IETF network slice would potentially 615 support different dataplanes that need to be stitched together. 617 5. Framework 619 621 A number of IETF network slice services will typically be provided 622 over a shared underlying network infrastructure. Each IETF network 623 slice consists of both the overlay connectivity and a specific set of 624 dedicated network resources and/or functions allocated in a shared 625 underlay network to satisfy the needs of the IETF network slice 626 consumer. In at least some examples of underlying network 627 technologies, the integration between the overlay and various 628 underlay resources is needed to ensure the guaranteed performance 629 requested for different IETF network slices. 631 IETF Network Slice Definition 632 ([I-D.ietf-teas-ietf-network-slice-definition] defines the role of a 633 Customer (or User) and a IETF Network Slice Controller. That 634 document also defines a NSC Northbound Interface (NBI). 636 A IETF network slice user is served by the IETF Network Slice 637 Controller (NSC), as follows: 639 o The NSC takes requests from a management system or other 640 application, which are then communicated via an NBI. This 641 interface carries data objects the IETF network slice user 642 provides, describing the needed IETF network slices in terms of 643 topology, applicable service level objectives (SLO), and any 644 monitoring and reporting requirements that may apply. Note that - 645 in this context - "topology" means what the IETF network slice 646 connectivity is meant to look like from the user's perspective; it 647 may be as simple as a list of mutually (and symmetrically) 648 connected end points, or it may be complicated by details of 649 connection asymmetry, per-connection SLO requirements, etc. 651 o These requests are assumed to be translated by one or more 652 underlying systems, which are used to establish specific IETF 653 network slice instances on top of an underlying network 654 infrastructure. 656 o The NSC maintains a record of the mapping from user requests to 657 slice instantiations, as needed to allow for subsequent control 658 functions (such as modification or deletion of the requested 659 slices), and as needed for any requested monitoring and reporting 660 functions. 662 Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example 663 architecture that might apply in using the technology described in 664 that document. 666 5.1. IETF Network Slice Stakeholders 668 670 An IETF network slice and its realization involves the following 671 stakeholders and it is relevant to define them for consistent 672 terminology. 674 Consumer: A consumer is the requester of an IETF network slice. 675 Consumers may request monitoring of SLOs. A consumer may manage 676 the IETF network slice service directly by interfacing with the 677 IETF network slice controller or indirectly through an 678 orchestrator. 680 Orchestrator: An orchestrator is an entity that composes different 681 services, resource and network requirements. It interfaces with 682 the IETF network slice controllers. 684 IETF Network Slice Controller (NSC): It realizes an IETF network 685 lice in the underlying network, maintains and monitors the run- 686 time state of resources and topologies associated with it. A 687 well-defined interface is needed between different types of IETF 688 network slice controllers and different types of orchestrators. 689 An IETF network slice operator (or slice operator for short) 690 manages one or more IETF network slices using the IETF network 691 slice Controller(s). 693 Network Controller: is a form of network infrastructure controller 694 that offers network resources to NSC to realize a particular 695 network slice. These may be existing network controllers 696 associated with one or more specific technologies that may be 697 adapted to the function of realizing IETF network slices in a 698 network. 700 5.2. Management Systems or Other Applications 702 704 The IETF network slice system is used by a management system or other 705 application. These systems and applications may also be a part of a 706 higher level function in the system, e.g., putting together network 707 functions, access equipment, application specific components, as well 708 as the IETF network slices. 710 5.3. Expressing Connectivity Intents 712 714 The IETF Network Slice Controller (NSC) northbound interface (NBI) 715 can be used to communicate between IETF network slice users (or 716 consumers) and the NSC. 718 A IETF network slice user may be a network operator who, in turn, 719 provides the IETF network slice to another IETF network slice user or 720 consumer. 722 Using the NBI, a consumer expresses requirements for a particular 723 slice by specifying what is required rather than how that is to be 724 achieved. That is, the consumer's view of a slice is an abstract 725 one. Consumers normally have limited (or no) visibility into the 726 provider network's actual topology and resource availability 727 information. 729 This should be true even if both the consumer and provider are 730 associated with a single administrative domain, in order to reduce 731 the potential for adverse interactions between IETF network slice 732 consumers and other users of the underlay network infrastructure. 734 The benefits of this model can include: 736 o Security: because the underlay network (or network operator) does 737 not need to expose network details (topology, capacity, etc.) to 738 IETF network slice consumers the underlay network components are 739 less exposed to attack; 741 o Layered Implementation: the underlay network comprises network 742 elements that belong to a different layer network than consumer 743 applications, and network information (advertisements, protocols, 744 etc.) that a consumer cannot interpret or respond to (note - a 745 consumer should not use network information not exposed via the 746 NSC NBI, even if that information is available); 748 o Scalability: consumers do not need to know any information beyond 749 that which is exposed via the NBI. 751 The general issues of abstraction in a TE network is described more 752 fully in [RFC7926]. 754 This framework document does not assume any particular layer at which 755 IETF network slices operate as a number of layers (including virtual 756 L2, Ethernet or IP connectivity) could be employed. 758 Data models and interfaces are of course needed to set up IETF 759 network slices, and specific interfaces may have capabilities that 760 allow creation of specific layers. 762 Layered virtual connections are comprehensively discussed in IETF 763 documents and are widely supported. See, for instance, GMPLS-based 764 networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and 765 [RFC8454]). The principles and mechanisms associated with layered 766 networking are applicable to IETF network slices. 768 There are several IETF-defined mechanisms for expressing the need for 769 a desired logical network. The NBI carries data either in a 770 protocol-defined format, or in a formalism associated with a modeling 771 language. 773 For instance: 775 o Path Computation Element (PCE) Communication Protocol (PCEP) 776 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 777 [RFC4208] use a TLV-based binary encoding to transmit data. 779 o Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 780 Protocol [RFC8040] use XML abnd JSON encoding. 782 o gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 783 programmable interface; 785 o SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding 786 (ASN.1). 788 o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 789 model configuration and other data for NETCONF, RESTCONF, and GNMI 790 - among others; ProtoBufs can be used to model gRPC and GNMI data; 791 Structure of Management Information (SMI) [RFC2578] may be used to 792 define Management Information Base (MIB) modules for SNMP, using 793 an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 794 1988). 796 While several generic formats and data models for specific purposes 797 exist, it is expected that IETF network slice management may require 798 enhancement or augmentation of existing data models. 800 5.4. IETF Network Slice Structure 802 804 Editor's note: This content of this section merged with Relationship 805 with E2E slice discussion. 807 An IETF network slice is a set of connections among various endpoints 808 to form a logical network that meets the SLOs agreed upon. 810 |------------------------------------------| 811 NSE1 O....| |....O NSE2 812 . | | . 813 . | IETF Network Slice | . 814 . | (SLOs e.g. B/W > x bps, Delay < y ms) | . 815 NSEm O....| |....O NSEn 816 |------------------------------------------| 818 == == == == == == == == == == == == == == == == == == == == == == 820 .--. .--. 821 [EP1] ( )- . ( )- . [EP2] 822 . .' IETF ' SLO .' IETF ' . 823 . ( Network-1 ) ... ( Network-p ) . 824 `-----------' `-----------' 825 [EPm] [EPn] 827 Legend 828 NSE: IETF Network Slice Endpoints 829 EP: Serivce/tunnels/path Endpoints used to realize the 830 IETF Network Slice 832 Figure 2: IETF Network slice 834 Figure 2 illustrates a case where an IETF network slice provides 835 connectivity between a set of IEFT network slice endpoints (NSE) 836 pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps 837 and guaranteed delay of no more than y ms). The IETF network slice 838 endpoints are mapped to the underlay IETF networks endpoints (EP). 839 Also, the IETF network slice endpoints on the same IETF network slice 840 may belong to the same or different address spaces. 842 IETF Network slice structure fits into a broader concept of end-to- 843 end network slices. A network operator may be responsible for 844 delivering services over a number of technologies (such as radio 845 networks) and for providing specific and fine-grained services (such 846 as CCTV feed or High definition realtime traffic data). That 847 operator may need to combine slices of various networks to produce an 848 end-to-end network service. Each of these networks may include 849 multiple physical or virtual nodes and may also provide network 850 functions beyond simply carrying of technology-specific protocol data 851 units. An end-to-end network slice is defined by the 3GPP as a 852 complete logical network that provides a service in its entirety with 853 a specific assurance to the consumer [TS23501]. 855 An end-to-end network slice may be composed from other network slices 856 that include IETF network slices. This composition may include the 857 hierarchical (or recursive) use of underlying network slices and the 858 sequential (or stitched) combination of slices of different networks. 860 5.5. IETF Network Slice Controller (NSC) 862 864 The IETF Network Slice Controller takes abstract requests for IETF 865 network slices and implements them using a suitable underlying 866 technology. A IETF Network Slice Controller is the key building 867 block for control and management of the IETF network slice. It 868 provides the creation/modification/deletion, monitoring and 869 optimization of IETF network slices in a multi-domain, a multi- 870 technology and multi-vendor environment. 872 A NSC northbound interface (NBI) is needed for communicating details 873 of a IETF network slice (configuration, selected policies, 874 operational state, etc.), as well as providing information to a slice 875 requester/consumer about IETF network slice status and performance. 876 The details for this NBI are not in scope for this document. 878 The controller provides the following functions: 880 o Provides a technology-agnostic NBI for creation/modification/ 881 deletion of the IETF network slices. The API exposed by this NBI 882 communicates the endpoints of the IETF network slice, IETF network 883 slice SLO parameters (and possibly monitoring thresholds), 884 applicable input selection (filtering) and various policies, and 885 provides a way to monitor the slice. 887 o Determines an abstract topology connecting the endpoints of the 888 IETF network slice that meets criteria specified via the NBI.The 889 NSC also retains information about the mapping of this abstract 890 topology to underlying components of the IETF network slice as 891 necessary to monitor IETF network slice status and performance. 893 o Provides "Mapping Functions" for the realization of IETF network 894 slices. In other words, it will use the mapping functions that: 896 * map technology-agnostic NBI request to technology-specific SBIs 898 * map filtering/selection information as necessary to entities in 899 the underlay network. 901 o Via an SBI, the controller collects telemetry data (e.g., OAM 902 results, statistics, states etc.) for all elements in the abstract 903 topology used to realize the IETF network slice. 905 o Using the telemetry data from the underlying realization of a IETF 906 network slice (i.e. services/paths/tunnels), evaluates the current 907 performance against IETF network slice SLO parameters and exposes 908 them to the IETF network slice consumer via the NBI. The NSC NBI 909 may also include a capability to provide notification in case the 910 IETF network slice performance reaches threshold values defined by 911 the IETF network slice consumer. 913 5.5.1. IETF Network Slice Controller Interfaces 915 917 The interworking and interoperability among the different 918 stakeholders to provide common means of provisioning, operating and 919 monitoring the IETF network slices is enabled by the following 920 communication interfaces (see Figure 3). 922 NSC Northbound Interface (NBI): The NSC Northbound Interface is an 923 interface between a consumer's higher level operation system 924 (e.g., a network slice orchestrator) and the NSC. It is a 925 technology agnostic interface. The consumer can use this 926 interface to communicate the requested characteristics and other 927 requirements (i.e., the SLOs) for the IETF network slice, and the 928 NSC can use the interface to report the operational state of an 929 IETF network slice to the consumer. 931 NSC Southbound Interface (SBI): The NSC Southbound Interface is an 932 interface between the NSC and network controllers. It is 933 technology-specific and may be built around the many network 934 models defined within the IETF. 936 +------------------------------------------+ 937 | Consumer higher level operation system | 938 | (e.g E2E network slice orchestrator) | 939 +------------------------------------------+ 940 A 941 | NSC NBI 942 V 943 +------------------------------------------+ 944 | IETF Network Slice Controller (NSC) | 945 +------------------------------------------+ 946 A 947 | NSC SBI 948 V 949 +------------------------------------------+ 950 | Network Controllers | 951 +------------------------------------------+ 953 Figure 3: Interface of IETF Network Slice Controller 955 5.5.2. Northbound Interface (NBI) 957 959 The IETF Network Slice Controller provides a Northbound Interface 960 (NBI) that allows consumers of network slices to request and monitor 961 IETF network slices. Consumers operate on abstract IETF network 962 slices, with details related to their realization hidden. 964 The NBI complements various IETF services, tunnels, path models by 965 providing an abstract layer on top of these models. 967 The NBI is independent of type of network functions or services that 968 need to be connected, i.e., it is independent of any specific 969 storage, software, protocol, or platform used to realize physical or 970 virtual network connectivity or functions in support of IETF network 971 slices. 973 The NBI uses protocol mechanisms and information passed over those 974 mechanisms to convey desired attributes for IETF network slices and 975 their status. The information is expected to be represented as a 976 well-defined data model, and should include at least endpoint and 977 connectivity information, SLO specification, and status information. 979 To accomplish this, the NBI needs to convey information needed to 980 support communication across the NBI, in terms of identifying the 981 IETF network slices, as well providing the above model information. 983 5.6. Mapping 985 987 The main task of the IETF network slice controller is to map abstract 988 IETF network slice requirements to concrete technologies and 989 establish required connectivity, and ensuring that required resources 990 are allocated to the IETF network slice. 992 5.7. Realizing IETF Network Slice 994 996 Realization of IETF network slices is out of scope of this document. 997 It is a mapping of the definition of the IETF network slice to the 998 underlying infrastructure and is necessarily technology-specific and 999 achieved by the NSC over the SBI. 1001 The realization can be achieved in a form of either physical or 1002 logical connectivity through VPNs (see, for example, 1003 [I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies 1004 such as Segment Routing, MPLS, etc. Accordingly, endpoints may be 1005 realized as physical or logical service or network functions. 1007 5.7.1. Underlying Technology 1009 1011 There are a number of different technologies that can be used, 1012 including physical connections, MPLS, TSN, Flex-E, etc. 1014 See Section 5 of [I-D.ietf-teas-enhanced-vpn] for instance, for 1015 example underlying technologies. 1017 Also, as outlined in "applicability of ACTN to IETF Network Slices" 1018 below, ACTN ([RFC8453]) offers a framework that is used elsewhere in 1019 IETF specifications to create virtual network (VN) services similar 1020 to IETF network slices. 1022 A IETF network slice can be realized in a network, using specific 1023 underlying technology or technologies. The creation of a new IETF 1024 network slice will be initiated with following three steps: 1026 o Step 1: A higher level system requests connections with specific 1027 characteristics via NBI. 1029 o Step 2: This request will be processed by a IETF Network Slice 1030 Controller which specifies a mapping between northbound request to 1031 any IETF Services, Tunnels, and paths models. 1033 o Step 3: A series of requests for creation of services, tunnels and 1034 paths will be sent to the network to realize the trasport slice. 1036 It is very clear that regardless of how IETF network slice is 1037 realized in the network (i.e., using tunnels of type RSVP or SR), the 1038 definition of IETF network slice does not change at all but rather 1039 its realization. 1041 6. Applicability of ACTN to IETF Network Slices 1043 1045 Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an 1046 example of similar IETF work. ACTN defines three controllers to 1047 support virtual network (VN) services - 1049 o Customer Network Controller (CNC), 1051 o Multi-Domain Service Coordinator (MDSC) and 1053 o Provisioning Network Controller (PNC). 1055 A CNC is responsible for communicating a customer's VN requirements. 1057 A MDSC is responsible for multi-domain coordination, virtualization 1058 (or abstraction), customer mapping/translation and virtual service 1059 coordination to realize the VN requirement. Its key role is to 1060 detach the network/service requirements from the underlying 1061 technology. 1063 A PNC oversees the configuration, monitoring and collection of the 1064 network topology. The PNC is a underlay technology specific 1065 controller. 1067 While the ACTN framework is a generic VN framework that is used for 1068 various VN service beyond the IETF network slice, it is still a 1069 suitable basis to understand how the various controllers interact to 1070 realize a IETF network slice. 1072 One possible mapping between the IETF network slice, and ACTN, 1073 definitions is as shown in Figure 4. 1075 IETF Network Slice | ACTN analogous 1076 Terminology / Concepts Terminology 1077 | and Concepts 1078 +--------------------------------------+ 1079 |Consumer higher level operation system| | +-----+ 1080 | (e.g E2E network slice orchestrator) | =====> | CNC | 1081 +--------------------------------------+ | +-----+ 1082 ^ ^ 1083 | NSC NBI | | CMI 1084 v v 1085 +-------------------------------------+ | +------+ 1086 | IETF Network Slice Controller (NSC) | =====> | MDSC | 1087 +-------------------------------------+ | +------+ 1088 ^ ^ 1089 | NSC SBI | | MPI 1090 v v 1091 +-------------------------------------+ | +-----+ 1092 | Network Controller(s) | =====> | PNC | 1093 +-------------------------------------+ | +-----+ 1095 Figure 4: Mapping between IETF network slices and ACTN 1097 Note that the left-hand side of this figure comes from IETF Network 1098 Slice Definition ([I-D.ietf-teas-ietf-network-slice-definition]). 1100 The NSC NBI conveys the generic IETF network slice requirements. 1101 These may then be realized using an SBI within the NSC. 1103 As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC 1104 Interface (CMI) is used to convey the virtual network service 1105 requirements along with the service models and the MDSC-PNC Interface 1106 (MPI) is used to realize the service along network configuration 1107 models. [I-D.ietf-teas-te-service-mapping-yang] further describe how 1108 the VPN services can be mapped to the underlying TE resources. 1110 The Network Controller is depicted as a single block, analogous to a 1111 Provisioning Network Controller (PNC - in this example). In the ACTN 1112 framework, however, it is also possible that the NC function is 1113 decomposed into MDSC and PNC - that is, the NC may comprise hierarchy 1114 as needed to handle the multiple domains and various underlay 1115 technologies, whereas a PNC in ACTN is intended to be specific to at 1116 most a single underlay technology and (likely) to individual devices 1117 (or functional components). 1119 Note that the details of potential implementations of everything that 1120 is below the NSC in Section 6 are out of scope in this document - 1121 hence the specifics of the relationship between NC and PNC, and the 1122 possibility that the MDSC and PNC may be combined are at most 1123 academically interesting in this context. Another way to view this 1124 is that, in the same way that ACTN might combine MDSC and PNC, the 1125 NSC might also directly include NC functionality. 1127 [RFC8453] also describes TE Network Slicing in the context of ACTN as 1128 a collection of resources that is used to establish a logically 1129 dedicated virtual network over one or more TE networks. In case of 1130 TE enabled underlying network, ACTN VN can be used as a base to 1131 realize the IETF network slicing by coordination among multiple peer 1132 domains as well as underlay technology domains. 1134 Section 6 shows only one possible mapping as each ACTN component (or 1135 interface) in the figure may be a composed differently in other 1136 mappings, and the exact role of both components and subcomponents 1137 will not be always an exact analogy between the concepts used in this 1138 document and those defined in ACTN. 1140 This is - in part - shown in a previous paragraph in this section 1141 where it is pointed out that the NC may actually subsume some aspects 1142 of both the MDSC and PNC. 1144 Similarly, in part depending on how "customer" is interpreted, CNC 1145 might merge some aspects of the higher level system and the NSC. As 1146 in the NC/PNC case, this way of comparing ACTN to this work is not 1147 useful as the NSC and NSC NBI are the focus on this document. 1149 7. Isolation in IETF Network Slices 1151 1153 An IETF network slice consumer may request, that the IETF Network 1154 Slice delivered to them is isolated from any other network slices of 1155 services delivered to any other consumers. It is expected that the 1156 changes to the other network slices of services do not have any 1157 negative impact on the delivery of the IETF network slice. 1159 7.1. Isolation as a Service Requirement 1161 1163 Isolation may be an important requirement of IETF network slices for 1164 some critical services. A consumer may express this request as an 1165 SLO. 1167 This requirement can be met by simple conformance with other SLOs. 1168 For example, traffic congestion (interference from other services) 1169 might impact on the latency experienced by an IETF network slice. 1171 Thus, in this example, conformance to a latency SLO would be the 1172 primary requirement for delivery of the IETF network slice service, 1173 and isolation from other services might be only a means to that end. 1175 It should be noted that some aspects of isolation may be measurable 1176 by a consumer who have the information about the traffic on a number 1177 of IETF network slices or other services. 1179 7.2. Isolation in IETF Network Slice Realization 1181 1183 Delivery of isolation is achieved in the realization of IETF network 1184 slices, with existing, in-development, and potential new technologies 1185 in IETF. It depends on how a network operator decides to operate 1186 their network and deliver services. 1188 Isolation may be achieved in the underlying network by various forms 1189 of resource partitioning ranging from dedicated allocation of 1190 resources for a specific IETF network slice, to sharing or resources 1191 with safeguards. For example, traffic separation between different 1192 IETF network slices may be achieved using VPN technologies, such as 1193 L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by 1194 network capacity planning, allocating dedicated network resources, 1195 traffic policing or shaping, prioritizing in using shared network 1196 resources, etc. Finally, service continuity may be ensured by 1197 reserving backup paths for critical traffic, dedicating specific 1198 network resources for a selected number of network slices, etc. 1200 8. Management Considerations 1202 1204 IETF network slice realization needs to be instrumented in order to 1205 track how it is working, and it might be necessary to modify the IETF 1206 network slice as requirements change. Dynamic reconfiguration might 1207 be needed. 1209 9. Security Considerations 1211 1213 This document specifies terminology and has no direct effect on the 1214 security of implementations or deployments. In this section, a few 1215 of the security aspects are identified. 1217 o Conformance to security constraints: Specific security requests 1218 from consumer defined IETF network slices will be mapped to their 1219 realization in the unerlay networks. It will be required by 1220 underlay networks to have capabilities to conform to consumer's 1221 requests as some aspects of security may be expressed in SLOs. 1223 o IETF network slice controller authentication: Unerlying networks 1224 need to be protected against the attacks from an adversary NSC as 1225 they can destablize overall network operations. It is 1226 particularly critical since an IETF network slice may span across 1227 different networks, therefore, IETF NSC should have strong 1228 authentication with each those networks. Futhermore, both SBI and 1229 NBI need to be secured. 1231 o Specific isolation criteria: The nature of conformance to 1232 isolation requests means that it should not be possible to attack 1233 an IETF network slice service by varying the traffic on other 1234 services or slices carried by the same underlay network. In 1235 general, isolation is expected to strengthen the IETF network 1236 slice security. 1238 o Data Integrity of an IETF network slice: A consumer wanting to 1239 secure their data and keep it private will be responsible for 1240 applying appropriate security measures to their traffic and not 1241 depending on the network operator that provides the IETF network 1242 slice. It is expected that for data integrity, a consumer is 1243 responsible for end-to-end encryption of its own traffic. 1245 Note: see NGMN document[NGMN_SEC] on 5G network slice security for 1246 discussion relevant to this section. 1248 1250 IETF network slices might use underlying virtualized networking. All 1251 types of virtual networking require special consideration to be given 1252 to the separation of traffic between distinct virtual networks, as 1253 well as some degree of protection from effects of traffic use of 1254 underlying network (and other) resources from other virtual networks 1255 sharing those resources. 1257 For example, if a service requires a specific upper bound of latency, 1258 then that service can be degraded by added delay in transmission of 1259 service packets through the activities of another service or 1260 application using the same resources. 1262 Similarly, in a network with virtual functions, noticeably impeding 1263 access to a function used by another IETF network slice (for 1264 instance, compute resources) can be just as service degrading as 1265 delaying physical transmission of associated packet in the network. 1267 While a IETF network slice might include encryption and other 1268 security features as part of the service, consumers might be well 1269 advised to take responsibility for their own security needs, possibly 1270 by encrypting traffic before hand-off to a service provider. 1272 9.1. Privacy Considerations 1274 1276 Privacy of IETF network slice service consumers must be preserved. 1277 It should not be possible for one IETF network slice consumer to 1278 discover the presence of other consumers, nor should sites that are 1279 members of one IETF network slice be visible outside the context of 1280 that IETF network slice. 1282 In this sense, it is of paramount importance that the system use the 1283 privacy protection mechanism defined for the specific underlying 1284 technologies used, including in particular those mechanisms designed 1285 to preclude acquiring identifying information associated with any 1286 IETF network slice consumer. 1288 10. IANA Considerations 1290 1292 There are no requests to IANA in this framework document. 1294 11. Acknowledgments 1296 1298 The entire TEAS NS design team and everyone participating in those 1299 discussion has contributed to this draft. Particularly, Eric Gray, 1300 Xufeng Liu, Jie Dong, Adrian Farrel, and Jari Arkko for a thorough 1301 review among other contributions. 1303 1305 The entire TEAS NS design team and everyone participating in related 1306 discussions has contributed to this document. Some text fragments in 1307 the document have been copied from the [I-D.ietf-teas-enhanced-vpn], 1308 for which we are grateful. 1310 Significant contributions to this document were gratefully received 1311 from the contributing authors listed in the "Contributors" section. 1312 In addition we would like to also thank those others who have 1313 attended one or more of the design team meetings, including: 1315 o Aihua Guo 1317 o Bo Wu 1319 o Greg Mirsky 1321 o Jeff Tantsura 1323 o Kiran Makhijani 1325 o Lou Berger 1327 o Luis M. Contreras 1329 o Rakesh Gandhi 1331 o Ran Chen 1333 o Sergio Belotti 1335 o Shunsuke Homma 1337 o Stewart Bryant 1339 o Tomonobu Niwa 1341 o Xuesong Geng 1343 12. Contributors 1345 The following authors contributed significantly to this document: 1347 Jari Arkko 1348 Ericsson 1349 Email: jari.arkko@piuha.net 1351 Dhruv Dhody 1352 Huawei, India 1353 Email: dhruv.ietf@gmail.com 1355 Jie Dong 1356 Huawei 1357 Email: jie.dong@huawei.com 1359 Xufeng Liu 1360 Volta Networks 1361 Email: xufeng.liu.ietf@gmail.com 1363 13. References 1365 13.1. Normative References 1367 [I-D.ietf-teas-ietf-network-slice-definition] 1368 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1369 Tantsura, "Definition of IETF Network Slices", draft-ietf- 1370 teas-ietf-network-slice-definition-00 (work in progress), 1371 January 2021. 1373 [I-D.ietf-teas-ietf-network-slice-framework] 1374 Gray, E. and J. Drake, "Framework for IETF Network 1375 Slices", draft-ietf-teas-ietf-network-slice-framework-00 1376 (work in progress), March 2021. 1378 13.2. Informative References 1380 [BBF-SD406] 1381 Broadband Forum, ., "End-to-end network slicing", BBF 1382 SD-406 , n.d.. 1384 [HIPAA] HHS, "Health Insurance Portability and Accountability Act 1385 - The Security Rule", February 2003, 1386 . 1389 [I-D.contreras-teas-slice-nbi] 1390 Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF 1391 Network Slice use cases and attributes for Northbound 1392 Interface of controller", draft-contreras-teas-slice- 1393 nbi-03 (work in progress), October 2020. 1395 [I-D.ietf-teas-actn-yang] 1396 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 1397 Shin, J., and S. Belotti, "Applicability of YANG models 1398 for Abstraction and Control of Traffic Engineered 1399 Networks", draft-ietf-teas-actn-yang-06 (work in 1400 progress), August 2020. 1402 [I-D.ietf-teas-enhanced-vpn] 1403 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1404 Framework for Enhanced Virtual Private Networks (VPN+) 1405 Service", draft-ietf-teas-enhanced-vpn-06 (work in 1406 progress), July 2020. 1408 [I-D.ietf-teas-te-service-mapping-yang] 1409 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 1410 and J. Tantsura, "Traffic Engineering (TE) and Service 1411 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 1412 yang-05 (work in progress), November 2020. 1414 [I-D.openconfig-rtgwg-gnmi-spec] 1415 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 1416 C., and C. Morrow, "gRPC Network Management Interface 1417 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 1418 progress), March 2018. 1420 [NGMN-NS-Concept] 1421 NGMN Alliance, ., "Description of Network Slicing 1422 Concept", https://www.ngmn.org/uploads/ 1423 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 1424 2016. 1426 [NGMN_SEC] 1427 NGMN Alliance, "NGMN 5G Security - Network Slicing", April 1428 2016, . 1431 [PCI] PCI Security Standards Council, "PCI DSS", May 2018, 1432 . 1434 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1435 Schoenwaelder, Ed., "Structure of Management Information 1436 Version 2 (SMIv2)", STD 58, RFC 2578, 1437 DOI 10.17487/RFC2578, April 1999, 1438 . 1440 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1441 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1442 September 1999, . 1444 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1445 Address Translator (Traditional NAT)", RFC 3022, 1446 DOI 10.17487/RFC3022, January 2001, 1447 . 1449 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1450 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1451 DOI 10.17487/RFC3393, November 2002, 1452 . 1454 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1455 "Message Processing and Dispatching for the Simple Network 1456 Management Protocol (SNMP)", STD 62, RFC 3412, 1457 DOI 10.17487/RFC3412, December 2002, 1458 . 1460 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1461 (USM) for version 3 of the Simple Network Management 1462 Protocol (SNMPv3)", STD 62, RFC 3414, 1463 DOI 10.17487/RFC3414, December 2002, 1464 . 1466 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 1467 Network Management Protocol (SNMP)", STD 62, RFC 3417, 1468 DOI 10.17487/RFC3417, December 2002, 1469 . 1471 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1472 "Generalized Multiprotocol Label Switching (GMPLS) User- 1473 Network Interface (UNI): Resource ReserVation Protocol- 1474 Traffic Engineering (RSVP-TE) Support for the Overlay 1475 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 1476 . 1478 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1479 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1480 . 1482 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 1483 Interpretation of Generalized Multiprotocol Label 1484 Switching (GMPLS) Terminology within the Context of the 1485 ITU-T's Automatically Switched Optical Network (ASON) 1486 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 1487 2006, . 1489 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1490 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 1491 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 1492 DOI 10.17487/RFC5212, July 2008, 1493 . 1495 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1496 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1497 DOI 10.17487/RFC5440, March 2009, 1498 . 1500 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1501 the Network Configuration Protocol (NETCONF)", RFC 6020, 1502 DOI 10.17487/RFC6020, October 2010, 1503 . 1505 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1506 NAT64: Network Address and Protocol Translation from IPv6 1507 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1508 April 2011, . 1510 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1511 and A. Bierman, Ed., "Network Configuration Protocol 1512 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1513 . 1515 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1516 Ed., "A One-Way Delay Metric for IP Performance Metrics 1517 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1518 2016, . 1520 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1521 Ed., "A One-Way Loss Metric for IP Performance Metrics 1522 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1523 2016, . 1525 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1526 Ceccarelli, D., and X. Zhang, "Problem Statement and 1527 Architecture for Information Exchange between 1528 Interconnected Traffic-Engineered Networks", BCP 206, 1529 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1530 . 1532 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1533 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1534 . 1536 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1537 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1538 . 1540 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1541 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1542 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1543 2018, . 1545 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1546 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1547 DOI 10.17487/RFC8453, August 2018, 1548 . 1550 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 1551 Yoon, "Information Model for Abstraction and Control of TE 1552 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 1553 September 2018, . 1555 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1556 O. Gonzalez de Dios, "YANG Data Model for Traffic 1557 Engineering (TE) Topologies", RFC 8795, 1558 DOI 10.17487/RFC8795, August 2020, 1559 . 1561 [TS23501] 3GPP, ., "System architecture for the 5G System (5GS)", 1562 3GPP TS 23.501 , 2019. 1564 [TS28530] 3GPP, ., "Management and orchestration; Concepts, use 1565 cases and requirements", 3GPP TS 28.530 , 2019. 1567 [TS33.210] 1568 3GPP, "3G security; Network Domain Security (NDS); IP 1569 network layer security (Release 14).", December 2016, 1570 . 1573 Appendix A. Unused Material 1575 This section includes material from the source documents that is not 1576 used in the body of this document. It is intended for deletion. 1578 Authors' Addresses 1580 Adrian Farrel (editor) 1581 Old Dog Consulting 1583 Email: adrian@olddog.co.uk 1585 Eric Gray 1586 Ericsson 1588 Email: ewgray@graiymage.com 1589 John Drake 1590 Juniper Networks 1592 Email: jdrake@juniper.net 1594 Reza Rokui 1595 Nokia 1597 Email: reza.rokui@nokia.com 1599 Shunsuke Homma 1600 NTT 1602 Email: shunsuke.homma.ietf@gmail.com 1604 Kiran Makhijani 1605 Futurewei 1607 Email: kiranm@futurewei.com 1609 Luis M. Contreras 1610 Telefonica 1611 Spain 1613 Email: luismiguel.contrerasmurillo@telefonica.com 1615 Jeff Tantsura 1616 Juniper Networks 1618 Email: jefftant.ietf@gmail.com