idnits 2.17.1 draft-ietf-teas-ietf-network-slices-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 (August 23, 2021) is 977 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EP1' is mentioned on line 1017, but not defined == Missing Reference: 'EP2' is mentioned on line 1017, but not defined == Missing Reference: 'EPm' is mentioned on line 1021, but not defined == Missing Reference: 'EPn' is mentioned on line 1021, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-08 Summary: 0 errors (**), 0 flaws (~~), 6 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: February 24, 2022 Independent 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 Microsoft 18 August 23, 2021 20 Framework for IETF Network Slices 21 draft-ietf-teas-ietf-network-slices-04 23 Abstract 25 This document describes network slicing in the context of networks 26 built from IETF technologies. It defines the term "IETF Network 27 Slice" and establishes the general principles of network slicing in 28 the IETF context. 30 The document discusses the general framework for requesting and 31 operating IETF Network Slices, the characteristics of an IETF Network 32 Slice, the necessary system components and interfaces, and how 33 abstract requests can be mapped to more specific technologies. The 34 document also discusses related considerations with monitoring and 35 security. 37 This document also provides definitions of related terms to enable 38 consistent usage in other IETF documents that describe or use aspects 39 of IETF Network Slices. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on February 24, 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 78 2.1. Core Terminology . . . . . . . . . . . . . . . . . . . . 6 79 3. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 6 80 3.1. Definition and Scope of IETF Network Slice . . . . . . . 6 81 3.2. IETF Network Slice Service . . . . . . . . . . . . . . . 7 82 4. IETF Network Slice System Characteristics . . . . . . . . . . 9 83 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 9 84 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 10 85 4.1.2. Service Level Expectations . . . . . . . . . . . . . 12 86 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 14 87 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 15 88 4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 16 89 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 16 91 5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 17 92 5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 18 93 5.3.1. IETF Network Slice Controller Interfaces . . . . . . 20 94 5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 21 95 5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 22 97 6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 23 98 6.1. Procedures to Realize IETF Network Slices . . . . . . . . 23 99 6.2. Applicability of ACTN to IETF Network Slices . . . . . . 24 100 6.3. Applicability of Enhanced VPNs to IETF Network Slices . . 24 101 6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 25 102 7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 25 103 7.1. Isolation as a Service Requirement . . . . . . . . . . . 25 104 7.2. Isolation in IETF Network Slice Realization . . . . . . . 26 105 8. Management Considerations . . . . . . . . . . . . . . . . . . 26 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 107 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 109 12. Informative References . . . . . . . . . . . . . . . . . . . 28 110 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 114 1. Introduction 116 A number of use cases benefit from network connections that along 117 with the connectivity provide assurance of meeting a specific set of 118 objectives with respect to network resources use. This connectivity 119 and resource commitment is referred to as a network slice. Since the 120 term network slice is rather generic, the qualifying term "IETF" is 121 used in this document to limit the scope of network slice to network 122 technologies described and standardized by the IETF. This document 123 defines the concept of IETF Network Slices that provide connectivity 124 coupled with a set of specific commitments of network resources 125 between a number of endpoints over a shared network infrastructure. 126 Services that might benefit from IETF Network Slices include, but are 127 not limited to: 129 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501]) 131 o Network wholesale services 133 o Network infrastructure sharing among operators 135 o NFV connectivity and Data Center Interconnect 137 IETF Network Slices are created and managed within the scope of one 138 or more network technologies (e.g., IP, MPLS, optical). They are 139 intended to enable a diverse set of applications that have different 140 requirements to coexist on the shared network infrastructure. A 141 request for an IETF Network Slice is technology-agnostic so as to 142 allow a customer to describe their network connectivity objectives in 143 a common format, independent of the underlying technologies used. 145 This document also provides a framework for discussing IETF Network 146 Slices. This framework is intended as a structure for discussing 147 interfaces and technologies. It is not intended to specify a new set 148 of concrete interfaces or technologies. Rather, the idea is that 149 existing or under-development IETF technologies (plural) can be used 150 to realize the concepts expressed herein. 152 For example, virtual private networks (VPNs) have served the industry 153 well as a means of providing different groups of users with logically 154 isolated access to a common network. The common or base network that 155 is used to support the VPNs is often referred to as an underlay 156 network, and the VPN is often called an overlay network. An overlay 157 network may, in turn, serve as an underlay network to support another 158 overlay network. 160 Note that it is conceivable that extensions to these IETF 161 technologies are needed in order to fully support all the ideas that 162 can be implemented with slices. Evaluation of existing technologies, 163 proposed extensions to existing protocols and interfaces, and the 164 creation of new protocols or interfaces is outside the scope of this 165 document. 167 1.1. Background 169 Driven largely by needs surfacing from 5G, the concept of network 170 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 171 and [BBF-SD406]). In [TS23501], a Network Slice is defined as "a 172 logical network that provides specific network capabilities and 173 network characteristics", and a Network Slice Instance is defined as 174 "A set of Network Function instances and the required resources (e.g. 175 compute, storage and networking resources) which form a deployed 176 Network Slice." According to [TS28530], an end-to-end network slice 177 consists of three major types of network segments: Radio Access 178 Network (RAN), Transport Network (TN) and Core Network (CN). An IETF 179 Network Slice provides the required connectivity between different 180 entities in RAN and CN segments of an end-to-end network slice, with 181 a specific performance commitment. For each end-to-end network 182 slice, the topology and performance requirement on a customer's use 183 of IETF Network Slice can be very different, which requires the 184 underlay network to have the capability of supporting multiple 185 different IETF Network Slices. 187 While network slices are commonly discussed in the context of 5G, it 188 is important to note that IETF Network Slices are a narrower concept, 189 and focus primarily on particular network connectivity aspects. 190 Other systems, including 5G deployments, may use IETF Network Slices 191 as a component to create entire systems and concatenated constructs 192 that match their needs, including end-to-end connectivity. 194 A IETF Network Slice could span multiple technologies and multiple 195 administrative domains. Depending on the IETF Network Slice 196 customer's requirements, an IETF Network Slice could be isolated from 197 other, often concurrent IETF Network Slices in terms of data, control 198 and management planes. 200 The customer expresses requirements for a particular IETF Network 201 Slice by specifying what is required rather than how the requirement 202 is to be fulfilled. That is, the IETF Network Slice customer's view 203 of an IETF Network Slice is an abstract one. 205 Thus, there is a need to create logical network structures with 206 required characteristics. The customer of such a logical network can 207 require a degree of isolation and performance that previously might 208 not have been satisfied by traditional overlay VPNs. Additionally, 209 the IETF Network Slice customer might ask for some level of control 210 of their virtual networks, e.g., to customize the service paths in a 211 network slice. 213 This document specifies definitions and a framework for the provision 214 of an IETF Network Slice service. Section 6 briefly indicates some 215 candidate technologies for realizing IETF Network Slices. 217 2. Terms and Abbreviations 219 The following abbreviations are used in this document. 221 o NBI: NorthBound Interface 223 o NSC: Network Slice Controller 225 o NSE: Network Slice Endpoint 227 o SBI: SouthBound Interface 229 o SLA: Service Level Agreement 231 o SLI: Service Level Indicator 233 o SLO: Service Level Objective 235 The meaning of these abbreviations is defined in greater details in 236 the remainder of this document. 238 2.1. Core Terminology 240 The following terms are presented here to give context. Other 241 terminology is defined in the remainder of this document. 243 Customer: A customer is the requester of an IETF Network Slice 244 service. Customers may request monitoring of SLOs. A customer 245 may be an entity such as an enterprise network or a network 246 operator, an individual working at such an entity, a private 247 individual contracting for a service, or an application or 248 software component. A customer may be an external party 249 (classically a paying customer) or a division of a network 250 operator that uses the service provided by another division of the 251 same operator. Other terms that have been applied to the customer 252 role are "client" and "consumer". 254 Provider: A provider is the organization that delivers an IETF 255 Network Slice service. A provider is the network operator that 256 controls the network resources used to construct the network slice 257 (that is, the network that is sliced). The provider's network 258 maybe a physical network or may be a virtual network supplied by 259 another service provider. 261 3. IETF Network Slice Objectives 263 It is intended that IETF Network Slices can be created to meet 264 specific requirements, typically expressed as bandwidth, latency, 265 latency variation, and other desired or required characteristics. 266 Creation is initiated by a management system or other application 267 used to specify network-related conditions for particular traffic 268 flows. 270 It is also intended that, once created, these slices can be 271 monitored, modified, deleted, and otherwise managed. 273 It is also intended that applications and components will be able to 274 use these IETF Network Slices to move packets between the specified 275 end-points in accordance with specified characteristics. 277 3.1. Definition and Scope of IETF Network Slice 279 The definition of a network slice in IETF context is as follows: 281 An IETF Network Slice is a logical network topology connecting a 282 number of endpoints using a set of shared or dedicated network 283 resources that are used to satisfy specific Service Level Objectives 284 (SLOs) and Service Level Expectations (SLEs). 286 An IETF Network Slice combines the connectivity resource requirements 287 and associated network behaviors such as bandwidth, latency, jitter, 288 and network functions with other resource behaviors such as compute 289 and storage availability. IETF Network Slices are independent of the 290 underlying infrastructure connectivity and technologies used. This 291 is to allow an IETF Network Slice service customer to describe their 292 network connectivity and relevant objectives in a common format, 293 independent of the underlying technologies used. 295 IETF Network Slices may be combined hierarchically, so that a network 296 slice may itself be sliced. They may also be combined sequentially 297 so that various different networks can each be sliced and the network 298 slices placed into a sequence to provide an end-to-end service. This 299 form of sequential combination is utilized in some services such as 300 in 3GPP's 5G network [TS23501]. 302 An IETF Network Slice is technology-agnostic, and the means for IETF 303 Network Slice realization can be chosen depending on several factors 304 such as: service requirements, specifications or capabilities of 305 underlying infrastructure. The structure and different 306 characteristics of IETF Network Slices are described in the following 307 sections. 309 The term "Slice" refers to a set of characteristics and behaviours 310 that separate one type of user-traffic from another. An IETF Network 311 Slice assumes that an underlying network is capable of changing the 312 configurations of the network devices on demand, through in-band 313 signaling or via controller(s) and fulfilling all or some of SLOs/ 314 SLEs to all of the traffic in the slice or to specific flows. 316 3.2. IETF Network Slice Service 318 A service provider instantiates an IETF network slice service for a 319 customer. The IETF network slice service is specified in terms of a 320 set of the customer's endpoints (CEs), a set of one or more 321 connectivity matrices (point-to-point (P2P), point-to-multipoint 322 (P2MP), multipoint-to-point (MP2P), or multipoint- to-multipoint 323 (MP2MP)) between subsets of these CEs, and a set of SLOs and SLEs for 324 each CE sending to each connectivity matrix. That is, in a given 325 IETF Network Slice Service there may be one or more connectivity 326 matrices of the same or different type, each connectivity matrix may 327 be between a different subset of CEs, and for a given connectivity 328 matrix each sending CE has its own set of SLOs and SLEs, and the SLOs 329 and SLEs in each set may be different. However, it is a free choice 330 for a service provider to decide whether to implement a single 331 connectivity matrix per IETF Network Slice Service, or to allow 332 multiple matrices per slice. 334 Note that in this context a "connectivity matrix" is a connection 335 between a set of senders and a set of receivers. Traffic sent by any 336 sender in the matrix is delivered to all receivers (except back to 337 itself). Thus, a connectivity matrix may be treated in the manner of 338 a virtual wire. 340 It is also the case that a given sending CE may be part of multiple 341 connectivity matrices within a single IETF network slice service, and 342 the CE may have different SLOs and SLEs for each connectivity matrix 343 to which it is sending. Note that a given sending CE's SLOs and SLEs 344 for a given connectivity matrix apply between it and each of the 345 receiving CEs for that connectivity matrix. 347 This approach results in the following possible connectivity 348 matrices: 350 o For an MP2MP connectivity matrix with N CEs, each of the N sending 351 CEs has its own set of SLOs and SLEs and they may all be 352 different. 354 o For a P2MP connectivity matrix, there is only one sending CE, and 355 there is only one set of SLOs and SLEs. 357 o For an MP2P connectivity matrix with N CEs, there is one receiving 358 CE and (N - 1) sending CEs. Each sending CE has its own set of 359 SLOs and SLEs and they may all be different. 361 o For a P2P unidirectional connectivity matrix, there is only one 362 sending CE and there is only one set of SLOs and SLEs. 364 o For a P2P bidirectional connectivity matrix, there are two sending 365 CEs, there are two sets of SLOs and SLEs which may be different. 367 If an IETF network slice service customer wants to ensure hub and 368 spoke connectivity between N CEs in order to control how traffic is 369 distributed between its CEs, it may request a set of N - 1 P2P 370 unidirectional connectivity matrices, each between a sending CE spoke 371 and the hub CE, and a P2MP connectivity matrix between the sending CE 372 hub and the spoke CEs. 374 An IETF network slice service provider may freely make a deployment 375 choice as to whether to offer a 1:1 relationship between IETF network 376 slice service and connectivity matrix, or to support multiple 377 connectivity matrices in a single IETF network slice service. In the 378 former case, the provider might need to deliver multiple IETF network 379 slice services to achive the function of the second case. 381 It should be noted that per Section 9 of [RFC4364] an IETF network 382 slice service customer may actually provide IETF network slice 383 services to other customers in a mode sometimes refered to as 384 "carrier's carrier". In this case, the underlying IETF network slice 385 service provider may be owned and operated by the same or a different 386 provider network. As noted in Section 3.1, network slices may be 387 composed hierarchically or serially. 389 Section 4.2 provides a description of endpoints in the context of 390 IETF network slicing. For a given IETF network slice service, the 391 IETF network slice customer and provider agree, on a per-CE basis 392 which end of the attachment circuit provides the service demarcation 393 point (i.e., whether the attachment circuit is inside or outside the 394 IETF network slice service). This determines whether the attachment 395 circuit is subject to the set of SLOs and SLEs for the specific CE. 397 4. IETF Network Slice System Characteristics 399 The following subsections describe the characteristics of IETF 400 Network Slices. 402 4.1. Objectives for IETF Network Slices 404 An IETF Network Slice service is defined in terms of quantifiable 405 characteristics known as Service Level Objectives (SLOs) and 406 unquantifiable characteristics known as Service Level Expectations 407 (SLEs). SLOs are expressed in terms Service Level Indicators (SLIs), 408 and together with the SLEs form the contractual agreement between 409 service customer and service provider known as a Service Level 410 Agreement (SLA). 412 The terms are defined as follows: 414 o A Service Level Indicator (SLI) is a quantifiable measure of an 415 aspect of the performance of a network. For example, it may be a 416 measure of throughput in bits per second, or it may be a measure 417 of latency in milliseconds. 419 o A Service Level Objective (SLO) is a target value or range for the 420 measurements returned by observation of an SLI. For example, an 421 SLO may be expressed as "SLI <= target", or "lower bound <= SLI <= 422 upper bound". A customer can determine whether the provider is 423 meeting the SLOs by performing measurements on the traffic. 425 o A Service Level Expectation (SLE) is an expression of an 426 unmeasurable service-related request that a customer of an IETF 427 network slice makes of the provider. An SLE is distinct from an 428 SLO because the customer may have little or no way of determining 429 whether the SLE is being met, but they still contract with the 430 provider for a service that meets the expectation. 432 o A Service Level Agreement (SLA) is an explicit or implicit 433 contract between the customer of an IETF Network Slice Service and 434 the provider of the slice. The SLA is expressed in terms of a set 435 of SLOs and SLEs that are to be applied to the connections between 436 the service endpoints, and may include commercial terms as well as 437 the consequences of missing/violating the SLOs they contain. 439 4.1.1. Service Level Objectives 441 SLOs define a set of network attributes and characteristics that 442 describe an IETF Network Slice. SLOs do not describe how the IETF 443 Network Slices are implemented or realized in the underlying network 444 layers. Instead, they are defined in terms of dimensions of 445 operation (time, capacity, etc.), availability, and other attributes. 446 An IETF Network Slice can have one or more SLOs associated with it. 447 The SLOs are combined in an SLA. The SLOs are defined for sets of 448 two or more endpoints and apply to specific directions of traffic 449 flow. That is, they apply to specific source endpoints and specific 450 connections between endpoints within the set of endpoints and 451 connections in the IETF Network Slice. 453 SLOs define a set of measurable network attributes and 454 characteristics that describe an IETF Network Slice service. SLOs do 455 not describe how the IETF network slices are implemented or realized 456 in the underlying network layers. Instead, they are defined in terms 457 of dimensions of operation (time, capacity, etc.), availability, and 458 other attributes. An IETF Network Slice service can have one or more 459 SLOs associated with it. The SLOs are combined with Service Level 460 Expectations in an SLA. 462 An IETF network slice service may include multiple connection 463 constructs that associate sets of endpoints. SLOs apply to sets of 464 two or more endpoints and apply to specific directions of traffic 465 flow. That is, they apply to a specific source endpoint and the 466 connection to specific destination endpoints. 468 4.1.1.1. Some Common SLOs 470 SLOs can be described as 'Directly Measurable Objectives': they are 471 always measurable. See Section 4.1.2 for the description of Service 472 Level Expectations which are unmeasurable service-related requests 473 sometimes known as 'Indirectly Measurable Objectives'. 475 Objectives such as guaranteed minimum bandwidth, guaranteed maximum 476 latency, maximum permissible delay variation, maximum permissible 477 packet loss rate, and availability are 'Directly Measurable 478 Objectives'. Future specifications (such as IETF Network Slice 479 service YANG models) may precisely define these SLOs, and other SLOs 480 may be introduced as described in Section 4.1.1.2. 482 The definition of these objectives are as follows: 484 Guaranteed Minimum Bandwidth 486 Minimum guaranteed bandwidth between two endpoints at any time. 487 The bandwidth is measured in data rate units of bits per second 488 and is measured unidirectionally. 490 Guaranteed Maximum Latency 492 Upper bound of network latency when transmitting between two 493 endpoints. The latency is measured in terms of network 494 characteristics (excluding application-level latency). 495 [RFC2681] and [RFC7679] discuss round trip times and one-way 496 metrics, respectively. 498 Maximum Permissible Delay Variation 500 Packet delay variation (PDV) as defined by [RFC3393], is the 501 difference in the one-way delay between sequential packets in a 502 flow. This SLO sets a maximum value PDV for packets between 503 two endpoints. 505 Maximum Permissible Packet Loss Rate 507 The ratio of packets dropped to packets transmitted between two 508 endpoints over a period of time. See [RFC7680]. 510 Availability 512 The ratio of uptime to the sum of uptime and downtime, where 513 uptime is the time the IETF Network Slice is available in 514 accordance with the SLOs associated with it. 516 4.1.1.2. Other Service Level Objectives 518 Additional SLOs may be defined to provide additional description of 519 the IETF Network Slice service that a customer requests. These would 520 be specified in further documents. 522 If the IETF network slice service is traffic aware, other traffic 523 specific characteristics may be valuable including MTU, traffic-type 524 (e.g., IPv4, IPv6, Ethernet or unstructured), or a higher-level 525 behavior to process traffic according to user-application (which may 526 be realized using network functions). 528 4.1.2. Service Level Expectations 530 SLEs define a set of network attributes and characteristics that 531 describe an IETF Network Slice service, but which are not directly 532 measurable by the customer. Even though the delivery of an SLE 533 cannot usually be determined by the customer, the SLEs form an 534 important part of the contract between customer and provider. 536 Quite often, an SLE will imply some details of how an IETF Network 537 Slice service is realized by the provider, although most aspects of 538 the implementation in the underlying network layers remain a free 539 choice for the provider. 541 SLEs may be seen as aspirational on the part of the customer, and 542 they are expressed as behaviors that the provider is expected to 543 apply to the network resources used to deliver the IETF Network Slice 544 service. An IETF network slice service can have one or more SLEs 545 associated with it. The SLEs are combined with SLOs in an SLA. 547 An IETF Network Slice service may include multiple connection 548 constructs that associate sets of endpoints. SLEs apply to sets of 549 two or more endpoints and apply to specific directions of traffic 550 flow. That is, they apply to a specific source endpoint and the 551 connection to specific destination endpoints. However, being more 552 general in nature, SLEs may commonly be applied to all connection 553 constructs in an IETF Network Slice service. 555 4.1.2.1. Some Common SLEs 557 SLEs can be described as 'Indirectly Measurable Objectives': they are 558 not generally directly measurable by the customer. 560 Security, geographic restrictions, maximum occupancy level, and 561 isolation are example SLEs as follows. 563 Security 565 A customer may request that the provider applies encryption or 566 other security techniques to traffic flowing between endpoints 567 of an IETF Network Slice service. For example, the customer 568 could request that only network links that have MACsec [MACsec] 569 enabled are used to realize the IETF Network Slice service. 571 This SLE may include the request for encryption (e.g., 572 [RFC4303]) between the two endpoints explicitly to meet 573 architecture recommendations as in [TS33.210] or for compliance 574 with [HIPAA] or [PCI]. 576 Whether or not the provider has met this SLE is generally not 577 directly observable by the customer and cannot be measured as a 578 quantifiable metric. 580 Please see further discussion on security in Section 9. 582 Geographic Restrictions 584 A customer may request that certain geographic limits are 585 applied to how the provider routes traffic for the IETF Network 586 Slice service. For example, the customer may have a preference 587 that its traffic does not pass through a particular country for 588 political or security reasons. 590 Whether or not the provider has met this SLE is generally not 591 directly observable by the customer and cannot be measured as a 592 quantifiable metric. 594 Maximal Occupancy Level 596 The maximal occupancy level specifies the number of flows to be 597 admitted and optionally a maximum number of countable resource 598 units (e.g., IP or MAC addresses) an IETF network slice service 599 can consume. Since an IETF Network Slice service may include 600 multiple connection constructs, this SLE should also say 601 whether it applies for the entire IETF Network Service slice, 602 for group of connections, or on a per connection basis. 604 Again, a customer may not be able to fully determine whether 605 this SLE is being met by the provider. 607 Isolation 609 As described in Section 7, a customer may request that its 610 traffic within its IETF Network Slice service is isolated from 611 the effects of other network services supported by the same 612 provider. That is, if another service exceeds capacity or has 613 a burst of traffic, the customer's IETF Network Slice service 614 should remain unaffected and there should be no noticeable 615 change to the quality of traffic delivered. 617 In general, a customer cannot tell whether a service provider 618 is meeting this SLE. They cannot tell whether the variation of 619 an SLI is because of changes in the underlying network or 620 because of interference from other services carried by the 621 network. And if the service varies within the allowed bounds 622 of the SLOs, there may be no noticeable indication that this 623 SLE has been violated. 625 Diversity 627 A customer may request that traffic on the connection between 628 one set of endpoints should use different network resources 629 from the traffic between another set of endpoints. This might 630 be done to enhance the availability of the IETF Network Slice 631 service. 633 While availability is a measurable objective (see 634 Section 4.1.1.1) this SLE requests a finer grade of control and 635 is not directly measurable (although the customer might become 636 suspicious if two connections fail at the same time). 638 4.2. IETF Network Slice Endpoints 640 As noted in Section 3.1, an IETF Network Slice describes connectivity 641 between multiple endpoints across the underlying network. These 642 connectivity types are: point-to-point, point-to-multipoint, 643 multipoint-to-point, or multipoint-to-multipoint. 645 Figure 1 shows an IETF Network Slice along with its Network Slice 646 Endpoints (NSEs). 648 The characteristics of IETF NSEs are as follows: 650 o The IETF NSEs are conceptual points of connection to IETF network 651 slice. As such, they serve as the IETF Network Slice ingress/ 652 egress points. 654 o Each endpoint could map to a device, application or a network 655 function. A non-exhaustive list of devices, applications or 656 network functions might include but not limited to: routers, 657 switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, 658 application acceleration, Deep Packet Inspection (DPI), server 659 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 660 enrichment functions, and TCP optimizers. 662 o An NSE should be identified by a unique ID in the context of an 663 IETF Network Slice customer. 665 o In addition to an identifier, each NSE should contain a subset of 666 attributes such as IPv4/IPv6 addresses, encapsulation type (i.e., 667 VLAN tag, MPLS Label etc.), interface/port numbers, node ID etc. 669 o A combination of NSE unique ID and NSE attributes defines an NSE 670 in the context of the IETF Network Slice Controller (NSC). 672 o During the realization of the IETF Network Slice, in addition to 673 SLOs, all or subset of IETF NSE attributes will be utilized by the 674 IETF NSC to find the optimal realization in the IETF network. 676 o Similarly to IETF Network Slices, the IETF Network Slice Endpoints 677 are logical entities that are mapped to services/tunnels/paths 678 endpoints in IETF Network Slice during its initialization and 679 realization. 681 Note that there are various IETF TE terms such as access points (AP) 682 defined in [RFC8453], Termination Point (TP) defined in [RFC8345], 683 and Link Termination Point (LTP) defined in [RFC8795] which are 684 tightly coupled with TE network type and various realization 685 techniques. At the time of realization of the IETF Network Slice, 686 the NSE could be mapped to one or more of these based on the network 687 slice realization technique in use. 689 |----------------------------------| 690 NSE1 | | NSE2 691 O.....| |.....O 692 . | | . 693 . | | . 694 . | | . 695 | | 696 NSEm | | NSEn 697 O.....| |.....O 698 | | 699 |----------------------------------| 701 <------------ IETF Network Slice --------------> 702 between endpoints NSE1 to NSEn 704 Legend: 705 NSE: IETF Network Slice Endpoint 706 O: Represents IETF Network Slice Endpoints 708 Figure 1: An IETF Network Slice Endpoints (NSE) 710 4.2.1. IETF Network Slice Connectivity Types 712 The IETF Network Slice connection types can be point to point (P2P), 713 point-to-multipoint (P2MP), multipoint-to-point (MP2P), or 714 multipoint-to-multipoint (MP2MP). They will requested by the higher 715 level operation system. 717 4.3. IETF Network Slice Decomposition 719 Operationally, an IETF Network Slice may be decomposed in two or more 720 IETF Network Slices as specified below. Decomposed network slices 721 are then independently realized and managed. 723 o Hierarchical (i.e., recursive) composition: An IETF Network Slice 724 can be further sliced into other network slices. Recursive 725 composition allows an IETF Network Slice at one layer to be used 726 by the other layers. This type of multi-layer vertical IETF 727 Network Slice associates resources at different layers. 729 o Sequential composition: Different IETF Network Slices can be 730 placed into a sequence to provide an end-to-end service. In 731 sequential composition, each IETF Network Slice would potentially 732 support different dataplanes that need to be stitched together. 734 5. Framework 736 A number of IETF Network Slice services will typically be provided 737 over a shared underlying network infrastructure. Each IETF Network 738 Slice consists of both the overlay connectivity and a specific set of 739 dedicated network resources and/or functions allocated in a shared 740 underlay network to satisfy the needs of the IETF Network Slice 741 customer. In at least some examples of underlying network 742 technologies, the integration between the overlay and various 743 underlay resources is needed to ensure the guaranteed performance 744 requested for different IETF Network Slices. 746 5.1. IETF Network Slice Stakeholders 748 An IETF Network Slice and its realization involves the following 749 stakeholders and it is relevant to define them for consistent 750 terminology. The IETF Network Slice Customer and IETF network Slice 751 provider (see Section 2.1) are also stakeholders. 753 Orchestrator: An orchestrator is an entity that composes different 754 services, resource and network requirements. It interfaces with 755 the IETF NSC. 757 IETF Network Slice Controller (NSC): It realizes an IETF Network 758 Slice in the underlying network, maintains and monitors the run- 759 time state of resources and topologies associated with it. A 760 well-defined interface is needed between different types of IETF 761 NSCs and different types of orchestrators. An IETF Network Slice 762 operator (or slice operator for short) manages one or more IETF 763 Network Slices using the IETF NSCs. 765 Network Controller: is a form of network infrastructure controller 766 that offers network resources to the NSC to realize a particular 767 network slice. These may be existing network controllers 768 associated with one or more specific technologies that may be 769 adapted to the function of realizing IETF Network Slices in a 770 network. 772 5.2. Expressing Connectivity Intents 774 The NSC northbound interface (NBI) can be used to communicate between 775 IETF Network Slice customers and the NSC. 777 An IETF Network Slice customer may be a network operator who, in 778 turn, provides the IETF Network Slice to another IETF Network Slice 779 customer. 781 Using the NBI, a customer expresses requirements for a particular 782 slice by specifying what is required rather than how that is to be 783 achieved. That is, the customer's view of a slice is an abstract 784 one. Customers normally have limited (or no) visibility into the 785 provider network's actual topology and resource availability 786 information. 788 This should be true even if both the customer and provider are 789 associated with a single administrative domain, in order to reduce 790 the potential for adverse interactions between IETF Network Slice 791 customers and other users of the underlay network infrastructure. 793 The benefits of this model can include: 795 o Security: because the underlay network (or network operator) does 796 not need to expose network details (topology, capacity, etc.) to 797 IETF Network Slice customers the underlay network components are 798 less exposed to attack; 800 o Layered Implementation: the underlay network comprises network 801 elements that belong to a different layer network than customer 802 applications, and network information (advertisements, protocols, 803 etc.) that a customer cannot interpret or respond to (note - a 804 customer should not use network information not exposed via the 805 NSC NBI, even if that information is available); 807 o Scalability: customers do not need to know any information beyond 808 that which is exposed via the NBI. 810 The general issues of abstraction in a TE network is described more 811 fully in [RFC7926]. 813 This framework document does not assume any particular layer at which 814 IETF Network Slices operate as a number of layers (including virtual 815 L2, Ethernet or IP connectivity) could be employed. 817 Data models and interfaces are of course needed to set up IETF 818 Network Slices, and specific interfaces may have capabilities that 819 allow creation of specific layers. 821 Layered virtual connections are comprehensively discussed in IETF 822 documents and are widely supported. See, for instance, GMPLS-based 823 networks [RFC5212] and [RFC4397], or Abstraction and Control of TE 824 Networks (ACTN) [RFC8453] and [RFC8454]. The principles and 825 mechanisms associated with layered networking are applicable to IETF 826 Network Slices. 828 There are several IETF-defined mechanisms for expressing the need for 829 a desired logical network. The NBI carries data either in a 830 protocol-defined format, or in a formalism associated with a modeling 831 language. 833 For instance: 835 o Path Computation Element (PCE) Communication Protocol (PCEP) 836 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 837 [RFC4208] use a TLV-based binary encoding to transmit data. 839 o Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 840 Protocol [RFC8040] use XML and JSON encoding. 842 o gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 843 programmable interface; 845 o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 846 model configuration and other data for NETCONF, RESTCONF, and GNMI 847 - among others; ProtoBufs can be used to model gRPC and GNMI data. 849 While several generic formats and data models for specific purposes 850 exist, it is expected that IETF Network Slice management may require 851 enhancement or augmentation of existing data models. 853 5.3. IETF Network Slice Controller (NSC) 855 The IETF NSC takes abstract requests for IETF Network Slices and 856 implements them using a suitable underlying technology. An IETF NSC 857 is the key building block for control and management of the IETF 858 Network Slice. It provides the creation/modification/deletion, 859 monitoring and optimization of IETF Network Slices in a multi-domain, 860 a multi-technology and multi-vendor environment. 862 The main task of the IETF NSC is to map abstract IETF Network Slice 863 requirements to concrete technologies and establish required 864 connectivity, and ensuring that required resources are allocated to 865 the IETF Network Slice. 867 An NSC northbound interface (NBI) is needed for communicating details 868 of a IETF Network Slice (configuration, selected policies, 869 operational state, etc.), as well as providing information to a slice 870 requester/customer about IETF Network Slice status and performance. 871 The details for this NBI are not in scope for this document. 873 The controller provides the following functions: 875 o Provides a technology-agnostic NBI for creation/modification/ 876 deletion of the IETF Network Slices. The API exposed by this NBI 877 communicates the endpoints of the IETF network slice, IETF Network 878 Slice SLO parameters (and possibly monitoring thresholds), 879 applicable input selection (filtering) and various policies, and 880 provides a way to monitor the slice. 882 o Determines an abstract topology connecting the endpoints of the 883 IETF Network Slice that meets criteria specified via the NBI. The 884 NSC also retains information about the mapping of this abstract 885 topology to underlying components of the IETF network slice as 886 necessary to monitor IETF Network Slice status and performance. 888 o Provides "Mapping Functions" for the realization of IETF Network 889 Slices. In other words, it will use the mapping functions that: 891 * map technology-agnostic NBI request to technology-specific SBIs 893 * map filtering/selection information as necessary to entities in 894 the underlay network. 896 o Via an SBI, the controller collects telemetry data (e.g., OAM 897 results, statistics, states, etc.) for all elements in the 898 abstract topology used to realize the IETF Network Slice. 900 o Using the telemetry data from the underlying realization of a IETF 901 Network Slice (i.e., services/paths/tunnels), evaluates the 902 current performance against IETF Network Slice SLO parameters and 903 exposes them to the IETF Network Slice customer via the NBI. The 904 NSC NBI may also include a capability to provide notification in 905 case the IETF Network Slice performance reaches threshold values 906 defined by the IETF Network Slice customer. 908 An IETF Network Slice customer is served by the IETF Network Slice 909 Controller (NSC), as follows: 911 o The NSC takes requests from a management system or other 912 application, which are then communicated via an NBI. This 913 interface carries data objects the IETF Network Slice customer 914 provides, describing the needed IETF Network Slices in terms of 915 topology, applicable service level objectives (SLO), and any 916 monitoring and reporting requirements that may apply. Note that - 917 in this context - "topology" means what the IETF Network Slice 918 connectivity is meant to look like from the customer's 919 perspective; it may be as simple as a list of mutually (and 920 symmetrically) connected end points, or it may be complicated by 921 details of connection asymmetry, per-connection SLO requirements, 922 etc. 924 o These requests are assumed to be translated by one or more 925 underlying systems, which are used to establish specific IETF 926 Network Slice instances on top of an underlying network 927 infrastructure. 929 o The NSC maintains a record of the mapping from customer requests 930 to slice instantiations, as needed to allow for subsequent control 931 functions (such as modification or deletion of the requested 932 slices), and as needed for any requested monitoring and reporting 933 functions. 935 5.3.1. IETF Network Slice Controller Interfaces 937 The interworking and interoperability among the different 938 stakeholders to provide common means of provisioning, operating and 939 monitoring the IETF Network Slices is enabled by the following 940 communication interfaces (see Figure 2). 942 NSC Northbound Interface (NBI): The NSC Northbound Interface is an 943 interface between a customer's higher level operation system 944 (e.g., a network slice orchestrator) and the NSC. It is a 945 technology agnostic interface. The customer can use this 946 interface to communicate the requested characteristics and other 947 requirements (i.e., the SLOs) for the IETF Network Slice, and the 948 NSC can use the interface to report the operational state of an 949 IETF Network Slice to the customer. 951 NSC Southbound Interface (SBI): The NSC Southbound Interface is an 952 interface between the NSC and network controllers. It is 953 technology-specific and may be built around the many network 954 models defined within the IETF. 956 +------------------------------------------+ 957 | Customer higher level operation system | 958 | (e.g E2E network slice orchestrator) | 959 +------------------------------------------+ 960 A 961 | NSC NBI 962 V 963 +------------------------------------------+ 964 | IETF Network Slice Controller (NSC) | 965 +------------------------------------------+ 966 A 967 | NSC SBI 968 V 969 +------------------------------------------+ 970 | Network Controllers | 971 +------------------------------------------+ 973 Figure 2: Interface of IETF Network Slice Controller 975 5.3.2. Northbound Interface (NBI) 977 The IETF Network Slice Controller provides a Northbound Interface 978 (NBI) that allows customers of network slices to request and monitor 979 IETF Network Slices. Customers operate on abstract IETF Network 980 Slices, with details related to their realization hidden. 982 The NBI complements various IETF services, tunnels, path models by 983 providing an abstract layer on top of these models. 985 The NBI is independent of type of network functions or services that 986 need to be connected, i.e., it is independent of any specific 987 storage, software, protocol, or platform used to realize physical or 988 virtual network connectivity or functions in support of IETF Network 989 Slices. 991 The NBI uses protocol mechanisms and information passed over those 992 mechanisms to convey desired attributes for IETF Network Slices and 993 their status. The information is expected to be represented as a 994 well-defined data model, and should include at least endpoint and 995 connectivity information, SLO specification, and status information. 997 To accomplish this, the NBI needs to convey information needed to 998 support communication across the NBI, in terms of identifying the 999 IETF Network Slices, as well providing the above model information. 1001 5.4. IETF Network Slice Structure 1003 An IETF Network Slice is a set of connections among various endpoints 1004 to form a logical network that meets the SLOs agreed upon. 1006 |------------------------------------------| 1007 NSE1 O....| |....O NSE2 1008 . | | . 1009 . | IETF Network Slice | . 1010 . | (SLOs e.g. B/W > x bps, Delay < y ms) | . 1011 NSEm O....| |....O NSEn 1012 |------------------------------------------| 1014 == == == == == == == == == == == == == == == == == == == == == == 1016 .--. .--. 1017 [EP1] ( )- . ( )- . [EP2] 1018 . .' IETF ' SLO .' IETF ' . 1019 . ( Network-1 ) ... ( Network-p ) . 1020 `-----------' `-----------' 1021 [EPm] [EPn] 1023 Legend 1024 NSE: IETF Network Slice Endpoints 1025 EP: Serivce/tunnel/path Endpoints used to realize the 1026 IETF Network Slice 1028 Figure 3: IETF Network Slice 1030 Figure 3 illustrates a case where an IETF Network Slice provides 1031 connectivity between a set of IETF network slice endpoints (NSE) 1032 pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps 1033 and guaranteed delay of no more than y ms). The IETF Network Slice 1034 endpoints are mapped to the service/tunnel/path Endpoints (EPs) in 1035 the underlay network. Also, the IETF NSEs in the same IETF network 1036 slice may belong to the same or different address spaces. 1038 IETF Network Slice structure fits into a broader concept of end-to- 1039 end network slices. A network operator may be responsible for 1040 delivering services over a number of technologies (such as radio 1041 networks) and for providing specific and fine-grained services (such 1042 as CCTV feed or High definition realtime traffic data). That 1043 operator may need to combine slices of various networks to produce an 1044 end-to-end network service. Each of these networks may include 1045 multiple physical or virtual nodes and may also provide network 1046 functions beyond simply carrying of technology-specific protocol data 1047 units. An end-to-end network slice is defined by the 3GPP as a 1048 complete logical network that provides a service in its entirety with 1049 a specific assurance to the customer [TS23501]. 1051 An end-to-end network slice may be composed from other network slices 1052 that include IETF Network Slices. This composition may include the 1053 hierarchical (or recursive) use of underlying network slices and the 1054 sequential (or stitched) combination of slices of different networks. 1056 6. Realizing IETF Network Slices 1058 Realization of IETF Network Slices is out of scope of this document. 1059 It is a mapping of the definition of the IETF Network Slice to the 1060 underlying infrastructure and is necessarily technology-specific and 1061 achieved by the NSC over the SBI. 1063 The realization can be achieved in a form of either physical or 1064 logical connectivity using VPNs, virtual networks (VNs), or a variety 1065 of tunneling technologies such as Segment Routing, MPLS, etc. 1066 Accordingly, endpoints (NSEs) may be realized as physical or logical 1067 service or network functions. 1069 6.1. Procedures to Realize IETF Network Slices 1071 There are a number of different technologies that can be used in the 1072 underlay, including physical connections, MPLS, time-sensitive 1073 networking (TSN), Flex-E, etc. 1075 An IETF Network Slice can be realized in a network, using specific 1076 underlying technology or technologies. The creation of a new IETF 1077 Network Slice will be initiated with following three steps: 1079 o Step 1: A higher level system requests connections with specific 1080 characteristics via the NBI. 1082 o Step 2: This request will be processed by an IETF NSC which 1083 specifies a mapping between northbound request to any IETF 1084 Services, Tunnels, and paths models. 1086 o Step 3: A series of requests for creation of services, tunnels and 1087 paths will be sent to the network to realize the transport slice. 1089 It is very clear that, regardless of how IETF Network Slice is 1090 realized in the network (i.e., using tunnels of different types), the 1091 definition of the IETF Network Slice does not change at all. The 1092 only difference is how the slice is realized. The following sections 1093 briefly introduce some existing architectural approaches that can be 1094 applied to realize IETF Network Slices. 1096 6.2. Applicability of ACTN to IETF Network Slices 1098 Abstraction and Control of TE Networks (ACTN - [RFC8453]) is a 1099 management architecture and toolkit used to create virtual networks 1100 (VNs) on top of a traffic engineering (TE) underlay network. The VNs 1101 can be presented to customers for them to operate as private 1102 networks. 1104 In many ways, the function of ACTN is similar to IETF network 1105 slicing. Customer requests for connectivity-based overlay services 1106 are mapped to dedicated or shared resources in the underlay network 1107 in a way that meets customer guarantees for service level objectives 1108 and for separation from other customers' traffic. [RFC8453] the 1109 function of ACTN as collecting resources to establish a logically 1110 dedicated virtual network over one or more TE networks. Thus, in the 1111 case of a TE-enabled underlying network, the ACTN VN can be used as a 1112 basis to realize an IETF network slicing. 1114 While the ACTN framework is a generic VN framework that can be used 1115 for VN services beyond the IETF network slice, it also a suitable 1116 basis for delivering and realizing IETF network slices. 1118 Further discussion of the applicability of ACTN to IETF network 1119 slices including a discussion of the relevant YANG models can be 1120 found in [I-D.king-teas-applicability-actn-slicing]. 1122 6.3. Applicability of Enhanced VPNs to IETF Network Slices 1124 An enhanced VPN (VPN+) is designed to support the needs of new 1125 applications, particularly applications that are associated with 5G 1126 services, by utilizing an approach that is based on existing VPN and 1127 Traffic Engineering (TE) technologies and adds characteristics that 1128 specific services require over and above traditional VPNs. 1130 An enhanced VPN can be used to provide enhanced connectivity services 1131 between customer sites (a concept similar to an IETF Network Slice) 1132 and can be used to create the infrastructure to underpin network 1133 slicing. 1135 It is envisaged that enhanced VPNs will be delivered using a 1136 combination of existing, modified, and new networking technologies. 1138 [I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced 1139 Virtual Private Network (VPN+) services. 1141 6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 1143 Network slicing provides the ability to partition a physical network 1144 into multiple isolated logical networks of varying sizes, structures, 1145 and functions so that each slice can be dedicated to specific 1146 services or customers. 1148 Many approaches are currently being worked on to support IETF Network 1149 Slices in IP and MPLS networks with or without the use of Segment 1150 Routing. Most of these approaches utilize a way of marking packets 1151 so that network nodes can apply specific routing and forwarding 1152 behaviors to packets that belong to different IETF Network Slices. 1153 Different mechanisms for marking packets have been proposed 1154 (including using MPLS labels and Segment Rouing segment IDs) and 1155 those mechanisms are agnostic to the path control technology used 1156 within the underlay network. 1158 These approaches are also sensitive to the scaling concerns of 1159 supporting a large number of IETF Network Slices within a single IP 1160 or MPLS network, and so offer ways to aggregate the slices so that 1161 the packet markings indicate an aggregate or grouping of IETF Network 1162 Slices where all of the packets are subject to the same routing and 1163 forwarding behavior. 1165 At this stage, it is inappropriate to mention any of these proposed 1166 solutions that are currently work in progress and not yet adopted as 1167 IETF work. 1169 7. Isolation in IETF Network Slices 1171 7.1. Isolation as a Service Requirement 1173 An IETF network slice customer may request that the IETF network 1174 slice delivered to them is delivered such that changes to other IETF 1175 network slices or services do not have any negative impact on the 1176 delivery of the IETF Network Slice. The IETF Network Slice customer 1177 may specify the degree to which their IETF Network Slice is 1178 unaffected by changes in the provider network or by the behavior of 1179 other IETF Network Slice customers. The customer may express this 1180 via an SLE it agrees with the provider. This concept is termed 1181 'isolation' 1183 7.2. Isolation in IETF Network Slice Realization 1185 Isolation may be achieved in the underlying network by various forms 1186 of resource partitioning ranging from dedicated allocation of 1187 resources for a specific IETF Network Slice, to sharing of resources 1188 with safeguards. For example, traffic separation between different 1189 IETF Network Slices may be achieved using VPN technologies, such as 1190 L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by 1191 network capacity planning, allocating dedicated network resources, 1192 traffic policing or shaping, prioritizing in using shared network 1193 resources, etc. Finally, service continuity may be ensured by 1194 reserving backup paths for critical traffic, dedicating specific 1195 network resources for a selected number of IETF Network Slices. 1197 8. Management Considerations 1199 IETF Network Slice realization needs to be instrumented in order to 1200 track how it is working, and it might be necessary to modify the IETF 1201 Network Slice as requirements change. Dynamic reconfiguration might 1202 be needed. 1204 9. Security Considerations 1206 This document specifies terminology and has no direct effect on the 1207 security of implementations or deployments. In this section, a few 1208 of the security aspects are identified. 1210 o Conformance to security constraints: Specific security requests 1211 from customer defined IETF Network Slices will be mapped to their 1212 realization in the underlay networks. It will be required by 1213 underlay networks to have capabilities to conform to customer's 1214 requests as some aspects of security may be expressed in SLEs. 1216 o IETF NSC authentication: Underlying networks need to be protected 1217 against the attacks from an adversary NSC as they can destabilize 1218 overall network operations. It is particularly critical since an 1219 IETF Network Slice may span across different networks, therefore, 1220 IETF NSC should have strong authentication with each those 1221 networks. Furthermore, both SBI and NBI need to be secured. 1223 o Specific isolation criteria: The nature of conformance to 1224 isolation requests means that it should not be possible to attack 1225 an IETF Network Slice service by varying the traffic on other 1226 services or slices carried by the same underlay network. In 1227 general, isolation is expected to strengthen the IETF Network 1228 Slice security. 1230 o Data Integrity of an IETF Network Slice: A customer wanting to 1231 secure their data and keep it private will be responsible for 1232 applying appropriate security measures to their traffic and not 1233 depending on the network operator that provides the IETF Network 1234 Slice. It is expected that for data integrity, a customer is 1235 responsible for end-to-end encryption of its own traffic. 1237 Note: see NGMN document[NGMN_SEC] on 5G network slice security for 1238 discussion relevant to this section. 1240 IETF Network Slices might use underlying virtualized networking. All 1241 types of virtual networking require special consideration to be given 1242 to the separation of traffic between distinct virtual networks, as 1243 well as some degree of protection from effects of traffic use of 1244 underlying network (and other) resources from other virtual networks 1245 sharing those resources. 1247 For example, if a service requires a specific upper bound of latency, 1248 then that service can be degraded by added delay in transmission of 1249 service packets through the activities of another service or 1250 application using the same resources. 1252 Similarly, in a network with virtual functions, noticeably impeding 1253 access to a function used by another IETF Network Slice (for 1254 instance, compute resources) can be just as service degrading as 1255 delaying physical transmission of associated packet in the network. 1257 While a IETF Network Slice might include encryption and other 1258 security features as part of the service, customers might be well 1259 advised to take responsibility for their own security needs, possibly 1260 by encrypting traffic before hand-off to a service provider. 1262 10. Privacy Considerations 1264 Privacy of IETF Network Slice service customers must be preserved. 1265 It should not be possible for one IETF Network Slice customer to 1266 discover the presence of other customers, nor should sites that are 1267 members of one IETF Network Slice be visible outside the context of 1268 that IETF Network Slice. 1270 In this sense, it is of paramount importance that the system use the 1271 privacy protection mechanism defined for the specific underlying 1272 technologies used, including in particular those mechanisms designed 1273 to preclude acquiring identifying information associated with any 1274 IETF Network Slice customer. 1276 11. IANA Considerations 1278 This document makes no requests for IANA action. 1280 12. Informative References 1282 [BBF-SD406] 1283 Broadband Forum, "End-to-end network slicing", BBF SD-406, 1284 . 1287 [HIPAA] HHS, "Health Insurance Portability and Accountability Act 1288 - The Security Rule", February 2003, 1289 . 1292 [I-D.ietf-teas-enhanced-vpn] 1293 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1294 Framework for Enhanced Virtual Private Network (VPN+) 1295 Services", draft-ietf-teas-enhanced-vpn-08 (work in 1296 progress), July 2021. 1298 [I-D.king-teas-applicability-actn-slicing] 1299 King, D., Drake, J., Zheng, H., and A. Farrel, 1300 "Applicability of Abstraction and Control of Traffic 1301 Engineered Networks (ACTN) to Network Slicing", draft- 1302 king-teas-applicability-actn-slicing-10 (work in 1303 progress), March 2021. 1305 [I-D.openconfig-rtgwg-gnmi-spec] 1306 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 1307 C., and C. Morrow, "gRPC Network Management Interface 1308 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 1309 progress), March 2018. 1311 [MACsec] IEEE, "IEEE Standard for Local and metropolitan area 1312 networks - Media Access Control (MAC) Security", 2018, 1313 . 1315 [NGMN-NS-Concept] 1316 NGMN Alliance, "Description of Network Slicing Concept", 1317 https://www.ngmn.org/uploads/ 1318 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 1319 2016. 1321 [NGMN_SEC] 1322 NGMN Alliance, "NGMN 5G Security - Network Slicing", April 1323 2016, . 1326 [PCI] PCI Security Standards Council, "PCI DSS", May 2018, 1327 . 1329 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1330 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1331 September 1999, . 1333 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1334 Address Translator (Traditional NAT)", RFC 3022, 1335 DOI 10.17487/RFC3022, January 2001, 1336 . 1338 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1339 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1340 DOI 10.17487/RFC3393, November 2002, 1341 . 1343 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1344 "Generalized Multiprotocol Label Switching (GMPLS) User- 1345 Network Interface (UNI): Resource ReserVation Protocol- 1346 Traffic Engineering (RSVP-TE) Support for the Overlay 1347 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 1348 . 1350 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1351 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1352 . 1354 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1355 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1356 2006, . 1358 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 1359 Interpretation of Generalized Multiprotocol Label 1360 Switching (GMPLS) Terminology within the Context of the 1361 ITU-T's Automatically Switched Optical Network (ASON) 1362 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 1363 2006, . 1365 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1366 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 1367 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 1368 DOI 10.17487/RFC5212, July 2008, 1369 . 1371 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1372 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1373 DOI 10.17487/RFC5440, March 2009, 1374 . 1376 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1377 the Network Configuration Protocol (NETCONF)", RFC 6020, 1378 DOI 10.17487/RFC6020, October 2010, 1379 . 1381 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1382 NAT64: Network Address and Protocol Translation from IPv6 1383 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1384 April 2011, . 1386 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1387 and A. Bierman, Ed., "Network Configuration Protocol 1388 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1389 . 1391 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1392 Ed., "A One-Way Delay Metric for IP Performance Metrics 1393 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1394 2016, . 1396 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1397 Ed., "A One-Way Loss Metric for IP Performance Metrics 1398 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1399 2016, . 1401 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1402 Ceccarelli, D., and X. Zhang, "Problem Statement and 1403 Architecture for Information Exchange between 1404 Interconnected Traffic-Engineered Networks", BCP 206, 1405 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1406 . 1408 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1409 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1410 . 1412 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1413 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1414 . 1416 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1417 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1418 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1419 2018, . 1421 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1422 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1423 DOI 10.17487/RFC8453, August 2018, 1424 . 1426 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 1427 Yoon, "Information Model for Abstraction and Control of TE 1428 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 1429 September 2018, . 1431 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1432 O. Gonzalez de Dios, "YANG Data Model for Traffic 1433 Engineering (TE) Topologies", RFC 8795, 1434 DOI 10.17487/RFC8795, August 2020, 1435 . 1437 [TS23501] 3GPP, "System architecture for the 5G System (5GS)", 1438 3GPP TS 23.501, 2019. 1440 [TS28530] 3GPP, "Management and orchestration; Concepts, use cases 1441 and requirements", 3GPP TS 28.530, 2019. 1443 [TS33.210] 1444 3GPP, "3G security; Network Domain Security (NDS); IP 1445 network layer security (Release 14).", December 2016, 1446 . 1449 Acknowledgments 1451 The entire TEAS Network Slicing design team and everyone 1452 participating in related discussions has contributed to this 1453 document. Some text fragments in the document have been copied from 1454 the [I-D.ietf-teas-enhanced-vpn], for which we are grateful. 1456 Significant contributions to this document were gratefully received 1457 from the contributing authors listed in the "Contributors" section. 1458 In addition we would like to also thank those others who have 1459 attended one or more of the design team meetings, including the 1460 following people not listed elsewhere: 1462 o Aihua Guo 1464 o Bo Wu 1466 o Greg Mirsky 1468 o Lou Berger 1470 o Rakesh Gandhi 1472 o Ran Chen 1474 o Sergio Belotti 1476 o Stewart Bryant 1478 o Tomonobu Niwa 1480 o Xuesong Geng 1482 Further useful comments were received from Daniele Ceccarelli, Uma 1483 Chunduri, Pavan Beeram, Tarek Saad, Med Boucadair, Kenichi Okagi, 1484 Oscar Gonzalez de Dios, and Xiaobing Niu. 1486 This work is partially supported by the European Commission under 1487 Horizon 2020 grant agreement number 101015857 Secured autonomic 1488 traffic management for a Tera of SDN flows (Teraflow). 1490 Contributors 1492 The following authors contributed significantly to this document: 1494 Jari Arkko 1495 Ericsson 1496 Email: jari.arkko@piuha.net 1498 Dhruv Dhody 1499 Huawei, India 1500 Email: dhruv.ietf@gmail.com 1502 Jie Dong 1503 Huawei 1504 Email: jie.dong@huawei.com 1506 Xufeng Liu 1507 Volta Networks 1508 Email: xufeng.liu.ietf@gmail.com 1510 Authors' Addresses 1512 Adrian Farrel (editor) 1513 Old Dog Consulting 1514 UK 1516 Email: adrian@olddog.co.uk 1518 Eric Gray 1519 Independent 1520 USA 1522 Email: ewgray@graiymage.com 1524 John Drake 1525 Juniper Networks 1526 USA 1528 Email: jdrake@juniper.net 1530 Reza Rokui 1531 Nokia 1533 Email: reza.rokui@nokia.com 1534 Shunsuke Homma 1535 NTT 1536 Japan 1538 Email: shunsuke.homma.ietf@gmail.com 1540 Kiran Makhijani 1541 Futurewei 1542 USA 1544 Email: kiranm@futurewei.com 1546 Luis M. Contreras 1547 Telefonica 1548 Spain 1550 Email: luismiguel.contrerasmurillo@telefonica.com 1552 Jeff Tantsura 1553 Microsoft Inc. 1555 Email: jefftant.ietf@gmail.com