idnits 2.17.1 draft-ietf-teas-ietf-network-slices-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2021) is 1070 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EP1' is mentioned on line 934, but not defined == Missing Reference: 'EP2' is mentioned on line 934, but not defined == Missing Reference: 'EPm' is mentioned on line 938, but not defined == Missing Reference: 'EPn' is mentioned on line 938, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-07 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: November 24, 2021 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 Juniper Networks 18 May 23, 2021 20 Framework for IETF Network Slices 21 draft-ietf-teas-ietf-network-slices-03 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 November 24, 2021. 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 4. IETF Network Slice System Characteristics . . . . . . . . . . 7 82 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 7 83 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 8 84 4.1.2. Service Level Expectations . . . . . . . . . . . . . 10 85 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 12 86 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 14 87 4.3. IETF Network Slice Decomposition . . . . . . . . . . . . 14 88 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . . 15 90 5.2. Expressing Connectivity Intents . . . . . . . . . . . . . 15 91 5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 17 92 5.3.1. IETF Network Slice Controller Interfaces . . . . . . 19 93 5.3.2. Northbound Interface (NBI) . . . . . . . . . . . . . 20 94 5.4. IETF Network Slice Structure . . . . . . . . . . . . . . 21 95 6. Realizing IETF Network Slices . . . . . . . . . . . . . . . . 22 96 6.1. Procedures to Realize IETF Network Slices . . . . . . . . 22 97 6.2. Applicability of ACTN to IETF Network Slices . . . . . . 23 98 6.3. Applicability of Enhanced VPNs to IETF Network Slices . . 23 99 6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 24 100 7. Isolation in IETF Network Slices . . . . . . . . . . . . . . 24 101 7.1. Isolation as a Service Requirement . . . . . . . . . . . 24 102 7.2. Isolation in IETF Network Slice Realization . . . . . . . 24 103 8. Management Considerations . . . . . . . . . . . . . . . . . . 25 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 105 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 107 12. Informative References . . . . . . . . . . . . . . . . . . . 26 108 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 112 1. Introduction 114 A number of use cases benefit from network connections that along 115 with the connectivity provide assurance of meeting a specific set of 116 objectives with respect to network resources use. This connectivity 117 and resource commitment is referred to as a network slice. Since the 118 term network slice is rather generic, the qualifying term "IETF" is 119 used in this document to limit the scope of network slice to network 120 technologies described and standardized by the IETF. This document 121 defines the concept of IETF Network Slices that provide connectivity 122 coupled with a set of specific commitments of network resources 123 between a number of endpoints over a shared network infrastructure. 124 Services that might benefit from IETF Network Slices include, but are 125 not limited to: 127 o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS23501]) 129 o Network wholesale services 131 o Network infrastructure sharing among operators 133 o NFV connectivity and Data Center Interconnect 135 IETF Network Slices are created and managed within the scope of one 136 or more network technologies (e.g., IP, MPLS, optical). They are 137 intended to enable a diverse set of applications that have different 138 requirements to coexist on the shared network infrastructure. A 139 request for an IETF Network Slice is technology-agnostic so as to 140 allow a customer to describe their network connectivity objectives in 141 a common format, independent of the underlying technologies used. 143 This document also provides a framework for discussing IETF Network 144 Slices. This framework is intended as a structure for discussing 145 interfaces and technologies. It is not intended to specify a new set 146 of concrete interfaces or technologies. Rather, the idea is that 147 existing or under-development IETF technologies (plural) can be used 148 to realize the concepts expressed herein. 150 For example, virtual private networks (VPNs) have served the industry 151 well as a means of providing different groups of users with logically 152 isolated access to a common network. The common or base network that 153 is used to support the VPNs is often referred to as an underlay 154 network, and the VPN is often called an overlay network. An overlay 155 network may, in turn, serve as an underlay network to support another 156 overlay network. 158 Note that it is conceivable that extensions to these IETF 159 technologies are needed in order to fully support all the ideas that 160 can be implemented with slices. Evaluation of existing technologies, 161 proposed extensions to existing protocols and interfaces, and the 162 creation of new protocols or interfaces is outside the scope of this 163 document. 165 1.1. Background 167 Driven largely by needs surfacing from 5G, the concept of network 168 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 169 and [BBF-SD406]). In [TS23501], a Network Slice is defined as "a 170 logical network that provides specific network capabilities and 171 network characteristics", and a Network Slice Instance is defined as 172 "A set of Network Function instances and the required resources (e.g. 173 compute, storage and networking resources) which form a deployed 174 Network Slice." According to [TS28530], an end-to-end network slice 175 consists of three major types of network segments: Radio Access 176 Network (RAN), Transport Network (TN) and Core Network (CN). An IETF 177 Network Slice provides the required connectivity between different 178 entities in RAN and CN segments of an end-to-end network slice, with 179 a specific performance commitment. For each end-to-end network 180 slice, the topology and performance requirement on a customer's use 181 of IETF Network Slice can be very different, which requires the 182 underlay network to have the capability of supporting multiple 183 different IETF Network Slices. 185 While network slices are commonly discussed in the context of 5G, it 186 is important to note that IETF Network Slices are a narrower concept, 187 and focus primarily on particular network connectivity aspects. 188 Other systems, including 5G deployments, may use IETF Network Slices 189 as a component to create entire systems and concatenated constructs 190 that match their needs, including end-to-end connectivity. 192 A IETF Network Slice could span multiple technologies and multiple 193 administrative domains. Depending on the IETF Network Slice 194 customer's requirements, an IETF Network Slice could be isolated from 195 other, often concurrent IETF Network Slices in terms of data, control 196 and management planes. 198 The customer expresses requirements for a particular IETF Network 199 Slice by specifying what is required rather than how the requirement 200 is to be fulfilled. That is, the IETF Network Slice customer's view 201 of an IETF Network Slice is an abstract one. 203 Thus, there is a need to create logical network structures with 204 required characteristics. The customer of such a logical network can 205 require a degree of isolation and performance that previously might 206 not have been satisfied by traditional overlay VPNs. Additionally, 207 the IETF Network Slice customer might ask for some level of control 208 of their virtual networks, e.g., to customize the service paths in a 209 network slice. 211 This document specifies definitions and a framework for the provision 212 of an IETF Network Slice service. Section 6 briefly indicates some 213 candidate technologies for realizing IETF Network Slices. 215 2. Terms and Abbreviations 217 The following abbreviations are used in this document. 219 o NBI: NorthBound Interface 221 o NSC: Network Slice Controller 223 o NSE: Network Slice Endpoint 225 o SBI: SouthBound Interface 227 o SLA: Service Level Agreement 229 o SLI: Service Level Indicator 231 o SLO: Service Level Objective 233 The meaning of these abbreviations is defined in greater details in 234 the remainder of this document. 236 2.1. Core Terminology 238 The following terms are presented here to give context. Other 239 terminology is defined in the remainder of this document. 241 Customer: A customer is the requester of an IETF Network Slice 242 service. Customers may request monitoring of SLOs. A customer 243 may be an entity such as an enterprise network or a network 244 operator, an individual working at such an entity, a private 245 individual contracting for a service, or an application or 246 software component. A customer may be an external party 247 (classically a paying customer) or a division of a network 248 operator that uses the service provided by another division of the 249 same operator. Other terms that have been applied to the customer 250 role are "client" and "consumer". 252 Provider: A provider is the organization that delivers an IETF 253 Network Slice service. A provider is the network operator that 254 controls the network resources used to construct the network slice 255 (that is, the network that is sliced). The provider's network 256 maybe a physical network or may be a virtual network supplied by 257 another service provider. 259 3. IETF Network Slice Objectives 261 It is intended that IETF Network Slices can be created to meet 262 specific requirements, typically expressed as bandwidth, latency, 263 latency variation, and other desired or required characteristics. 264 Creation is initiated by a management system or other application 265 used to specify network-related conditions for particular traffic 266 flows. 268 It is also intended that, once created, these slices can be 269 monitored, modified, deleted, and otherwise managed. 271 It is also intended that applications and components will be able to 272 use these IETF Network Slices to move packets between the specified 273 end-points in accordance with specified characteristics. 275 3.1. Definition and Scope of IETF Network Slice 277 The definition of a network slice in IETF context is as follows: 279 An IETF Network Slice is a logical network topology connecting a 280 number of endpoints using a set of shared or dedicated network 281 resources that are used to satisfy specific Service Level Objectives 282 (SLOs). 284 An IETF Network Slice combines the connectivity resource requirements 285 and associated network behaviors such as bandwidth, latency, jitter, 286 and network functions with other resource behaviors such as compute 287 and storage availability. IETF Network Slices are independent of the 288 underlying infrastructure connectivity and technologies used. This 289 is to allow an IETF Network Slice service customer to describe their 290 network connectivity and relevant objectives in a common format, 291 independent of the underlying technologies used. 293 IETF Network Slices may be combined hierarchically, so that a network 294 slice may itself be sliced. They may also be combined sequentially 295 so that various different networks can each be sliced and the network 296 slices placed into a sequence to provide an end-to-end service. This 297 form of sequential combination is utilized in some services such as 298 in 3GPP's 5G network [TS23501]. 300 An IETF Network Slice is technology-agnostic, and the means for IETF 301 Network Slice realization can be chosen depending on several factors 302 such as: service requirements, specifications or capabilities of 303 underlying infrastructure. The structure and different 304 characteristics of IETF Network Slices are described in the following 305 sections. 307 Term "Slice" refers to a set of characteristics and behaviours that 308 separate one type of user-traffic from another. IETF Network Slice 309 assumes that an underlying network is capable of changing the 310 configurations of the network devices on demand, through in-band 311 signaling or via controller(s) and fulfilling all or some of SLOs to 312 all of the traffic in the slice or to specific flows. 314 4. IETF Network Slice System Characteristics 316 The following subsections describe the characteristics of IETF 317 Network Slices. 319 4.1. Objectives for IETF Network Slices 321 An IETF Network Slice service is defined in terms of quantifiable 322 characteristics known as Service Level Objectives (SLOs) and 323 unquantifiable characteristics known as Service Level Expectations 324 (SLEs). SLOs are expressed in terms Service Level Indicators (SLIs), 325 and together with the SLEs form the contractual agreement between 326 service customer and service provider known as a Service Level 327 Agreement (SLA). 329 The terms are defined as follows: 331 o A Service Level Indicator (SLI) is a quantifiable measure of an 332 aspect of the performance of a network. For example, it may be a 333 measure of throughput in bits per second, or it may be a measure 334 of latency in milliseconds. 336 o A Service Level Objective (SLO) is a target value or range for the 337 measurements returned by observation of an SLI. For example, an 338 SLO may be expressed as "SLI <= target", or "lower bound <= SLI <= 339 upper bound". A customer can determine whether the provider is 340 meeting the SLOs by performing measurements on the traffic. 342 o A Service Level Expectation (SLE) is an expression of an 343 unmeasurable service-related request that a customer of an IETF 344 network slice makes of the provider. An SLE is distinct from an 345 SLO because the customer may have little or no way of determining 346 whether the SLE is being met, but they still contract with the 347 provider for a service that meets the expectation. 349 o A Service Level Agreement (SLA) is an explicit or implicit 350 contract between the customer of an IETF Network Slice and the 351 provider of the slice. The SLA is expressed in terms of a set of 352 SLOs and SLEs that are to be applied to the connections between 353 the service endpoints, and may include commercial terms as well as 354 the consequences of missing/violating the SLOs they contain. 356 4.1.1. Service Level Objectives 358 SLOs define a set of network attributes and characteristics that 359 describe an IETF Network Slice. SLOs do not describe how the IETF 360 Network Slices are implemented or realized in the underlying network 361 layers. Instead, they are defined in terms of dimensions of 362 operation (time, capacity, etc.), availability, and other attributes. 363 An IETF Network Slice can have one or more SLOs associated with it. 364 The SLOs are combined in an SLA. The SLOs are defined for sets of 365 two or more endpoints and apply to specific directions of traffic 366 flow. That is, they apply to specific source endpoints and specific 367 connections between endpoints within the set of endpoints and 368 connections in the IETF Network Slice. 370 SLOs define a set of measurable network attributes and 371 characteristics that describe an IETF Network Slice service. SLOs do 372 not describe how the IETF network slices are implemented or realized 373 in the underlying network layers. Instead, they are defined in terms 374 of dimensions of operation (time, capacity, etc.), availability, and 375 other attributes. An IETF Network Slice service can have one or more 376 SLOs associated with it. The SLOs are combined with Service Level 377 Expectations in an SLA. 379 An IETF network slice service may include multiple connection 380 constructs that associate sets of endpoints. SLOs apply to sets of 381 two or more endpoints and apply to specific directions of traffic 382 flow. That is, they apply to a specific source endpoint and the 383 connection to specific destination endpoints. 385 4.1.1.1. Some Common SLOs 387 SLOs can be described as 'Directly Measurable Objectives': they are 388 always measurable. See Section 4.1.2 for the description of Service 389 Level Expectations which are unmeasurable service-related requests 390 sometimes known as 'Indirectly Measurable Objectives'. 392 Objectives such as guaranteed minimum bandwidth, guaranteed maximum 393 latency, maximum permissible delay variation, maximum permissible 394 packet loss rate, and availability are 'Directly Measurable 395 Objectives'. Future specifications (such as IETF Network Slice 396 service YANG models) may precisely define these SLOs, and other SLOs 397 may be introduced as described in Section 4.1.1.2. 399 The definition of these objectives are as follows: 401 Guaranteed Minimum Bandwidth 403 Minimum guaranteed bandwidth between two endpoints at any time. 404 The bandwidth is measured in data rate units of bits per second 405 and is measured unidirectionally. 407 Guaranteed Maximum Latency 409 Upper bound of network latency when transmitting between two 410 endpoints. The latency is measured in terms of network 411 characteristics (excluding application-level latency). 412 [RFC2681] and [RFC7679] discuss round trip times and one-way 413 metrics, respectively. 415 Maximum Permissible Delay Variation 417 Packet delay variation (PDV) as defined by [RFC3393], is the 418 difference in the one-way delay between sequential packets in a 419 flow. This SLO sets a maximum value PDV for packets between 420 two endpoints. 422 Maximum Permissible Packet Loss Rate 424 The ratio of packets dropped to packets transmitted between two 425 endpoints over a period of time. See [RFC7680]. 427 Availability 429 The ratio of uptime to the sum of uptime and downtime, where 430 uptime is the time the IETF Network Slice is available in 431 accordance with the SLOs associated with it. 433 4.1.1.2. Other Service Level Objectives 435 Additional SLOs may be defined to provide additional description of 436 the IETF Network Slice service that a customer requests. These would 437 be specified in further documents. 439 If the IETF network slice service is traffic aware, other traffic 440 specific characteristics may be valuable including MTU, traffic-type 441 (e.g., IPv4, IPv6, Ethernet or unstructured), or a higher-level 442 behavior to process traffic according to user-application (which may 443 be realized using network functions). 445 4.1.2. Service Level Expectations 447 SLEs define a set of network attributes and characteristics that 448 describe an IETF Network Slice service, but which are not directly 449 measurable by the customer. Even though the delivery of an SLE 450 cannot usually be determined by the customer, the SLEs form an 451 important part of the contract between customer and provider. 453 Quite often, an SLE will imply some details of how an IETF Network 454 Slice service is realized by the provider, although most aspects of 455 the implementation in the underlying network layers remain a free 456 choice for the provider. 458 SLEs may be seen as aspirational on the part of the customer, and 459 they are expressed as behaviors that the provider is expected to 460 apply to the network resources used to deliver the IETF Network Slice 461 service. An IETF network slice service can have one or more SLEs 462 associated with it. The SLEs are combined with SLOs in an SLA. 464 An IETF Network Slice service may include multiple connection 465 constructs that associate sets of endpoints. SLEs apply to sets of 466 two or more endpoints and apply to specific directions of traffic 467 flow. That is, they apply to a specific source endpoint and the 468 connection to specific destination endpoints. However, being more 469 general in nature, SLEs may commonly be applied to all connection 470 constructs in an IETF Network Slice service. 472 4.1.2.1. Some Common SLEs 474 SLEs can be described as 'Indirectly Measurable Objectives': they are 475 not generally directly measurable by the customer. 477 Security, geographic restrictions, maximum occupancy level, and 478 isolation are example SLEs as follows. 480 Security 482 A customer may request that the provider applies encryption or 483 other security techniques to traffic flowing between endpoints 484 of an IETF Network Slice service. For example, the customer 485 could request that only network links that have MACsec [MACsec] 486 enabled are used to realize the IETF Network Slice service. 488 This SLE may include the request for encryption (e.g., 489 [RFC4303]) between the two endpoints explicitly to meet 490 architecture recommendations as in [TS33.210] or for compliance 491 with [HIPAA] or [PCI]. 493 Whether or not the provider has met this SLE is generally not 494 directly observable by the customer and cannot be measured as a 495 quantifiable metric. 497 Please see further discussion on security in Section 9. 499 Geographic Restrictions 501 A customer may request that certain geographic limits are 502 applied to how the provider routes traffic for the IETF Network 503 Slice service. For example, the customer may have a preference 504 that its traffic does not pass through a particular country for 505 political or security reasons. 507 Whether or not the provider has met this SLE is generally not 508 directly observable by the customer and cannot be measured as a 509 quantifiable metric. 511 Maximal Occupancy Level 513 The maximal occupancy level specifies the number of flows to be 514 admitted and optionally a maximum number of countable resource 515 units (e.g., IP or MAC addresses) an IETF network slice service 516 can consume. Since an IETF Network Slice service may include 517 multiple connection constructs, this SLE should also say 518 whether it applies for the entire IETF Network Service slice, 519 for group of connections, or on a per connection basis. 521 Again, a customer may not be able to fully determine whether 522 this SLE is being met by the provider. 524 Isolation 526 As described in Section 7, a customer may request that its 527 traffic within its IETF Network Slice service is isolated from 528 the effects of other network services supported by the same 529 provider. That is, if another service exceeds capacity or has 530 a burst of traffic, the customer's IETF Network Slice service 531 should remain unaffected and there should be no noticeable 532 change to the quality of traffic delivered. 534 In general, a customer cannot tell whether a service provider 535 is meeting this SLE. They cannot tell whether the variation of 536 an SLI is because of changes in the underlying network or 537 because of interference from other services carried by the 538 network. And if the service varies within the allowed bounds 539 of the SLOs, there may be no noticeable indication that this 540 SLE has been violated. 542 Diversity 544 A customer may request that traffic on the connection between 545 one set of endpoints should use different network resources 546 from the traffic between another set of endpoints. This might 547 be done to enhance the availability of the IETF Network Slice 548 service. 550 While availability is a measurable objective (see 551 Section 4.1.1.1) this SLE requests a finer grade of control and 552 is not directly measurable (although the customer might become 553 suspicious if two connections fail at the same time). 555 4.2. IETF Network Slice Endpoints 557 As noted in Section 3.1, an IETF Network Slice describes connectivity 558 between multiple endpoints across the underlying network. These 559 connectivity types are: point-to-point, point-to-multipoint, 560 multipoint-to-point, or multipoint-to-multipoint. 562 Figure 1 shows an IETF Network Slice along with its Network Slice 563 Endpoints (NSEs). 565 The characteristics of IETF NSEs are as follows: 567 o The IETF NSEs are conceptual points of connection to IETF network 568 slice. As such, they serve as the IETF Network Slice ingress/ 569 egress points. 571 o Each endpoint could map to a device, application or a network 572 function. A non-exhaustive list of devices, applications or 573 network functions might include but not limited to: routers, 574 switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, 575 application acceleration, Deep Packet Inspection (DPI), server 576 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 577 enrichment functions, and TCP optimizers. 579 o An NSE should be identified by a unique ID in the context of an 580 IETF Network Slice customer. 582 o In addition to an identifier, each NSE should contain a subset of 583 attributes such as IPv4/IPv6 addresses, encapsulation type (i.e., 584 VLAN tag, MPLS Label etc.), interface/port numbers, node ID etc. 586 o A combination of NSE unique ID and NSE attributes defines an NSE 587 in the context of the IETF Network Slice Controller (NSC). 589 o During the realization of the IETF Network Slice, in addition to 590 SLOs, all or subset of IETF NSE attributes will be utilized by the 591 IETF NSC to find the optimal realization in the IETF network. 593 o Similarly to IETF Network Slices, the IETF Network Slice Endpoints 594 are logical entities that are mapped to services/tunnels/paths 595 endpoints in IETF Network Slice during its initialization and 596 realization. 598 Note that there are various IETF TE terms such as access points (AP) 599 defined in [RFC8453], Termination Point (TP) defined in [RFC8345], 600 and Link Termination Point (LTP) defined in [RFC8795] which are 601 tightly coupled with TE network type and various realization 602 techniques. At the time of realization of the IETF Network Slice, 603 the NSE could be mapped to one or more of these based on the network 604 slice realization technique in use. 606 |----------------------------------| 607 NSE1 | | NSE2 608 O.....| |.....O 609 . | | . 610 . | | . 611 . | | . 612 | | 613 NSEm | | NSEn 614 O.....| |.....O 615 | | 616 |----------------------------------| 618 <------------ IETF Network Slice --------------> 619 between endpoints NSE1 to NSEn 621 Legend: 622 NSE: IETF Network Slice Endpoint 623 O: Represents IETF Network Slice Endpoints 625 Figure 1: An IETF Network Slice Endpoints (NSE) 627 4.2.1. IETF Network Slice Connectivity Types 629 The IETF Network Slice connection types can be point to point (P2P), 630 point-to-multipoint (P2MP), multipoint-to-point (MP2P), or 631 multipoint-to-multipoint (MP2MP). They will requested by the higher 632 level operation system. 634 4.3. IETF Network Slice Decomposition 636 Operationally, an IETF Network Slice may be decomposed in two or more 637 IETF Network Slices as specified below. Decomposed network slices 638 are then independently realized and managed. 640 o Hierarchical (i.e., recursive) composition: An IETF Network Slice 641 can be further sliced into other network slices. Recursive 642 composition allows an IETF Network Slice at one layer to be used 643 by the other layers. This type of multi-layer vertical IETF 644 Network Slice associates resources at different layers. 646 o Sequential composition: Different IETF Network Slices can be 647 placed into a sequence to provide an end-to-end service. In 648 sequential composition, each IETF Network Slice would potentially 649 support different dataplanes that need to be stitched together. 651 5. Framework 653 A number of IETF Network Slice services will typically be provided 654 over a shared underlying network infrastructure. Each IETF Network 655 Slice consists of both the overlay connectivity and a specific set of 656 dedicated network resources and/or functions allocated in a shared 657 underlay network to satisfy the needs of the IETF Network Slice 658 customer. In at least some examples of underlying network 659 technologies, the integration between the overlay and various 660 underlay resources is needed to ensure the guaranteed performance 661 requested for different IETF Network Slices. 663 5.1. IETF Network Slice Stakeholders 665 An IETF Network Slice and its realization involves the following 666 stakeholders and it is relevant to define them for consistent 667 terminology. The IETF Network Slice Customer and IETF network Slice 668 provider (see Section 2.1) are also stakeholders. 670 Orchestrator: An orchestrator is an entity that composes different 671 services, resource and network requirements. It interfaces with 672 the IETF NSC. 674 IETF Network Slice Controller (NSC): It realizes an IETF Network 675 Slice in the underlying network, maintains and monitors the run- 676 time state of resources and topologies associated with it. A 677 well-defined interface is needed between different types of IETF 678 NSCs and different types of orchestrators. An IETF Network Slice 679 operator (or slice operator for short) manages one or more IETF 680 Network Slices using the IETF NSCs. 682 Network Controller: is a form of network infrastructure controller 683 that offers network resources to the NSC to realize a particular 684 network slice. These may be existing network controllers 685 associated with one or more specific technologies that may be 686 adapted to the function of realizing IETF Network Slices in a 687 network. 689 5.2. Expressing Connectivity Intents 691 The NSC northbound interface (NBI) can be used to communicate between 692 IETF Network Slice customers and the NSC. 694 An IETF Network Slice customer may be a network operator who, in 695 turn, provides the IETF Network Slice to another IETF Network Slice 696 customer. 698 Using the NBI, a customer expresses requirements for a particular 699 slice by specifying what is required rather than how that is to be 700 achieved. That is, the customer's view of a slice is an abstract 701 one. Customers normally have limited (or no) visibility into the 702 provider network's actual topology and resource availability 703 information. 705 This should be true even if both the customer and provider are 706 associated with a single administrative domain, in order to reduce 707 the potential for adverse interactions between IETF Network Slice 708 customers and other users of the underlay network infrastructure. 710 The benefits of this model can include: 712 o Security: because the underlay network (or network operator) does 713 not need to expose network details (topology, capacity, etc.) to 714 IETF Network Slice customers the underlay network components are 715 less exposed to attack; 717 o Layered Implementation: the underlay network comprises network 718 elements that belong to a different layer network than customer 719 applications, and network information (advertisements, protocols, 720 etc.) that a customer cannot interpret or respond to (note - a 721 customer should not use network information not exposed via the 722 NSC NBI, even if that information is available); 724 o Scalability: customers do not need to know any information beyond 725 that which is exposed via the NBI. 727 The general issues of abstraction in a TE network is described more 728 fully in [RFC7926]. 730 This framework document does not assume any particular layer at which 731 IETF Network Slices operate as a number of layers (including virtual 732 L2, Ethernet or IP connectivity) could be employed. 734 Data models and interfaces are of course needed to set up IETF 735 Network Slices, and specific interfaces may have capabilities that 736 allow creation of specific layers. 738 Layered virtual connections are comprehensively discussed in IETF 739 documents and are widely supported. See, for instance, GMPLS-based 740 networks [RFC5212] and [RFC4397], or Abstraction and Control of TE 741 Networks (ACTN) [RFC8453] and [RFC8454]. The principles and 742 mechanisms associated with layered networking are applicable to IETF 743 Network Slices. 745 There are several IETF-defined mechanisms for expressing the need for 746 a desired logical network. The NBI carries data either in a 747 protocol-defined format, or in a formalism associated with a modeling 748 language. 750 For instance: 752 o Path Computation Element (PCE) Communication Protocol (PCEP) 753 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 754 [RFC4208] use a TLV-based binary encoding to transmit data. 756 o Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 757 Protocol [RFC8040] use XML and JSON encoding. 759 o gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 760 programmable interface; 762 o For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 763 model configuration and other data for NETCONF, RESTCONF, and GNMI 764 - among others; ProtoBufs can be used to model gRPC and GNMI data. 766 While several generic formats and data models for specific purposes 767 exist, it is expected that IETF Network Slice management may require 768 enhancement or augmentation of existing data models. 770 5.3. IETF Network Slice Controller (NSC) 772 The IETF NSC takes abstract requests for IETF Network Slices and 773 implements them using a suitable underlying technology. An IETF NSC 774 is the key building block for control and management of the IETF 775 Network Slice. It provides the creation/modification/deletion, 776 monitoring and optimization of IETF Network Slices in a multi-domain, 777 a multi-technology and multi-vendor environment. 779 The main task of the IETF NSC is to map abstract IETF Network Slice 780 requirements to concrete technologies and establish required 781 connectivity, and ensuring that required resources are allocated to 782 the IETF Network Slice. 784 An NSC northbound interface (NBI) is needed for communicating details 785 of a IETF Network Slice (configuration, selected policies, 786 operational state, etc.), as well as providing information to a slice 787 requester/customer about IETF Network Slice status and performance. 788 The details for this NBI are not in scope for this document. 790 The controller provides the following functions: 792 o Provides a technology-agnostic NBI for creation/modification/ 793 deletion of the IETF Network Slices. The API exposed by this NBI 794 communicates the endpoints of the IETF network slice, IETF Network 795 Slice SLO parameters (and possibly monitoring thresholds), 796 applicable input selection (filtering) and various policies, and 797 provides a way to monitor the slice. 799 o Determines an abstract topology connecting the endpoints of the 800 IETF Network Slice that meets criteria specified via the NBI. The 801 NSC also retains information about the mapping of this abstract 802 topology to underlying components of the IETF network slice as 803 necessary to monitor IETF Network Slice status and performance. 805 o Provides "Mapping Functions" for the realization of IETF Network 806 Slices. In other words, it will use the mapping functions that: 808 * map technology-agnostic NBI request to technology-specific SBIs 810 * map filtering/selection information as necessary to entities in 811 the underlay network. 813 o Via an SBI, the controller collects telemetry data (e.g., OAM 814 results, statistics, states, etc.) for all elements in the 815 abstract topology used to realize the IETF Network Slice. 817 o Using the telemetry data from the underlying realization of a IETF 818 Network Slice (i.e., services/paths/tunnels), evaluates the 819 current performance against IETF Network Slice SLO parameters and 820 exposes them to the IETF Network Slice customer via the NBI. The 821 NSC NBI may also include a capability to provide notification in 822 case the IETF Network Slice performance reaches threshold values 823 defined by the IETF Network Slice customer. 825 An IETF Network Slice customer is served by the IETF Network Slice 826 Controller (NSC), as follows: 828 o The NSC takes requests from a management system or other 829 application, which are then communicated via an NBI. This 830 interface carries data objects the IETF Network Slice customer 831 provides, describing the needed IETF Network Slices in terms of 832 topology, applicable service level objectives (SLO), and any 833 monitoring and reporting requirements that may apply. Note that - 834 in this context - "topology" means what the IETF Network Slice 835 connectivity is meant to look like from the customer's 836 perspective; it may be as simple as a list of mutually (and 837 symmetrically) connected end points, or it may be complicated by 838 details of connection asymmetry, per-connection SLO requirements, 839 etc. 841 o These requests are assumed to be translated by one or more 842 underlying systems, which are used to establish specific IETF 843 Network Slice instances on top of an underlying network 844 infrastructure. 846 o The NSC maintains a record of the mapping from customer requests 847 to slice instantiations, as needed to allow for subsequent control 848 functions (such as modification or deletion of the requested 849 slices), and as needed for any requested monitoring and reporting 850 functions. 852 5.3.1. IETF Network Slice Controller Interfaces 854 The interworking and interoperability among the different 855 stakeholders to provide common means of provisioning, operating and 856 monitoring the IETF Network Slices is enabled by the following 857 communication interfaces (see Figure 2). 859 NSC Northbound Interface (NBI): The NSC Northbound Interface is an 860 interface between a customer's higher level operation system 861 (e.g., a network slice orchestrator) and the NSC. It is a 862 technology agnostic interface. The customer can use this 863 interface to communicate the requested characteristics and other 864 requirements (i.e., the SLOs) for the IETF Network Slice, and the 865 NSC can use the interface to report the operational state of an 866 IETF Network Slice to the customer. 868 NSC Southbound Interface (SBI): The NSC Southbound Interface is an 869 interface between the NSC and network controllers. It is 870 technology-specific and may be built around the many network 871 models defined within the IETF. 873 +------------------------------------------+ 874 | Customer higher level operation system | 875 | (e.g E2E network slice orchestrator) | 876 +------------------------------------------+ 877 A 878 | NSC NBI 879 V 880 +------------------------------------------+ 881 | IETF Network Slice Controller (NSC) | 882 +------------------------------------------+ 883 A 884 | NSC SBI 885 V 886 +------------------------------------------+ 887 | Network Controllers | 888 +------------------------------------------+ 890 Figure 2: Interface of IETF Network Slice Controller 892 5.3.2. Northbound Interface (NBI) 894 The IETF Network Slice Controller provides a Northbound Interface 895 (NBI) that allows customers of network slices to request and monitor 896 IETF Network Slices. Customers operate on abstract IETF Network 897 Slices, with details related to their realization hidden. 899 The NBI complements various IETF services, tunnels, path models by 900 providing an abstract layer on top of these models. 902 The NBI is independent of type of network functions or services that 903 need to be connected, i.e., it is independent of any specific 904 storage, software, protocol, or platform used to realize physical or 905 virtual network connectivity or functions in support of IETF Network 906 Slices. 908 The NBI uses protocol mechanisms and information passed over those 909 mechanisms to convey desired attributes for IETF Network Slices and 910 their status. The information is expected to be represented as a 911 well-defined data model, and should include at least endpoint and 912 connectivity information, SLO specification, and status information. 914 To accomplish this, the NBI needs to convey information needed to 915 support communication across the NBI, in terms of identifying the 916 IETF Network Slices, as well providing the above model information. 918 5.4. IETF Network Slice Structure 920 An IETF Network Slice is a set of connections among various endpoints 921 to form a logical network that meets the SLOs agreed upon. 923 |------------------------------------------| 924 NSE1 O....| |....O NSE2 925 . | | . 926 . | IETF Network Slice | . 927 . | (SLOs e.g. B/W > x bps, Delay < y ms) | . 928 NSEm O....| |....O NSEn 929 |------------------------------------------| 931 == == == == == == == == == == == == == == == == == == == == == == 933 .--. .--. 934 [EP1] ( )- . ( )- . [EP2] 935 . .' IETF ' SLO .' IETF ' . 936 . ( Network-1 ) ... ( Network-p ) . 937 `-----------' `-----------' 938 [EPm] [EPn] 940 Legend 941 NSE: IETF Network Slice Endpoints 942 EP: Serivce/tunnel/path Endpoints used to realize the 943 IETF Network Slice 945 Figure 3: IETF Network Slice 947 Figure 3 illustrates a case where an IETF Network Slice provides 948 connectivity between a set of IETF network slice endpoints (NSE) 949 pairs with specific SLOs (e.g., guaranteed minimum bandwidth of x bps 950 and guaranteed delay of no more than y ms). The IETF Network Slice 951 endpoints are mapped to the service/tunnel/path Endpoints (EPs) in 952 the underlay network. Also, the IETF NSEs in the same IETF network 953 slice may belong to the same or different address spaces. 955 IETF Network Slice structure fits into a broader concept of end-to- 956 end network slices. A network operator may be responsible for 957 delivering services over a number of technologies (such as radio 958 networks) and for providing specific and fine-grained services (such 959 as CCTV feed or High definition realtime traffic data). That 960 operator may need to combine slices of various networks to produce an 961 end-to-end network service. Each of these networks may include 962 multiple physical or virtual nodes and may also provide network 963 functions beyond simply carrying of technology-specific protocol data 964 units. An end-to-end network slice is defined by the 3GPP as a 965 complete logical network that provides a service in its entirety with 966 a specific assurance to the customer [TS23501]. 968 An end-to-end network slice may be composed from other network slices 969 that include IETF Network Slices. This composition may include the 970 hierarchical (or recursive) use of underlying network slices and the 971 sequential (or stitched) combination of slices of different networks. 973 6. Realizing IETF Network Slices 975 Realization of IETF Network Slices is out of scope of this document. 976 It is a mapping of the definition of the IETF Network Slice to the 977 underlying infrastructure and is necessarily technology-specific and 978 achieved by the NSC over the SBI. 980 The realization can be achieved in a form of either physical or 981 logical connectivity using VPNs, virtual networks (VNs), or a variety 982 of tunneling technologies such as Segment Routing, MPLS, etc. 983 Accordingly, endpoints (NSEs) may be realized as physical or logical 984 service or network functions. 986 6.1. Procedures to Realize IETF Network Slices 988 There are a number of different technologies that can be used in the 989 underlay, including physical connections, MPLS, time-sensitive 990 networking (TSN), Flex-E, etc. 992 An IETF Network Slice can be realized in a network, using specific 993 underlying technology or technologies. The creation of a new IETF 994 Network Slice will be initiated with following three steps: 996 o Step 1: A higher level system requests connections with specific 997 characteristics via the NBI. 999 o Step 2: This request will be processed by an IETF NSC which 1000 specifies a mapping between northbound request to any IETF 1001 Services, Tunnels, and paths models. 1003 o Step 3: A series of requests for creation of services, tunnels and 1004 paths will be sent to the network to realize the transport slice. 1006 It is very clear that, regardless of how IETF Network Slice is 1007 realized in the network (i.e., using tunnels of different types), the 1008 definition of the IETF Network Slice does not change at all. The 1009 only difference is how the slice is realized. The following sections 1010 briefly introduce some existing architectural approaches that can be 1011 applied to realize IETF Network Slices. 1013 6.2. Applicability of ACTN to IETF Network Slices 1015 Abstraction and Control of TE Networks (ACTN - [RFC8453]) is a 1016 management architecture and toolkit used to create virtual networks 1017 (VNs) on top of a traffic engineering (TE) underlay network. The VNs 1018 can be presented to customers for them to operate as private 1019 networks. 1021 In many ways, the function of ACTN is similar to IETF network 1022 slicing. Customer requests for connectivity-based overlay services 1023 are mapped to dedicated or shared resources in the underlay network 1024 in a way that meets customer guarantees for service level objectives 1025 and for separation from other customers' traffic. [RFC8453] the 1026 function of ACTN as collecting resources to establish a logically 1027 dedicated virtual network over one or more TE networks. Thus, in the 1028 case of a TE-enabled underlying network, the ACTN VN can be used as a 1029 basis to realize an IETF network slicing. 1031 While the ACTN framework is a generic VN framework that can be used 1032 for VN services beyond the IETF network slice, it also a suitable 1033 basis for delivering and realizing IETF network slices. 1035 Further discussion of the applicability of ACTN to IETF network 1036 slices including a discussion of the relevant YANG models can be 1037 found in [I-D.king-teas-applicability-actn-slicing]. 1039 6.3. Applicability of Enhanced VPNs to IETF Network Slices 1041 An enhanced VPN (VPN+) is designed to support the needs of new 1042 applications, particularly applications that are associated with 5G 1043 services, by utilizing an approach that is based on existing VPN and 1044 Traffic Engineering (TE) technologies and adds characteristics that 1045 specific services require over and above traditional VPNs. 1047 An enhanced VPN can be used to provide enhanced connectivity services 1048 between customer sites (a concept similar to an IETF Network Slice) 1049 and can be used to create the infrastructure to underpin network 1050 slicing. 1052 It is envisaged that enhanced VPNs will be delivered using a 1053 combination of existing, modified, and new networking technologies. 1055 [I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced 1056 Virtual Private Network (VPN+) services. 1058 6.4. Network Slicing and Slice Aggregation in IP/MPLS Networks 1060 Network slicing provides the ability to partition a physical network 1061 into multiple isolated logical networks of varying sizes, structures, 1062 and functions so that each slice can be dedicated to specific 1063 services or customers. 1065 Many approaches are currently being worked on to support IETF Network 1066 Slices in IP and MPLS networks with or without the use of Segment 1067 Routing. Most of these approaches utilize a way of marking packets 1068 so that network nodes can apply specific routing and forwarding 1069 behaviors to packets that belong to different IETF Network Slices. 1070 Different mechanisms for marking packets have been proposed 1071 (including using MPLS labels and Segment Rouing segment IDs) and 1072 those mechanisms are agnostic to the path control technology used 1073 within the underlay network. 1075 These approaches are also sensitive to the scaling concerns of 1076 supporting a large number of IETF Network Slices within a single IP 1077 or MPLS network, and so offer ways to aggregate the slices so that 1078 the packet markings indicate an aggregate or grouping of IETF Network 1079 Slices where all of the packets are subject to the same routing and 1080 forwarding behavior. 1082 At this stage, it is inappropriate to mention any of these proposed 1083 solutions that are currently work in progress and not yet adopted as 1084 IETF work. 1086 7. Isolation in IETF Network Slices 1088 7.1. Isolation as a Service Requirement 1090 An IETF network slice customer may request that the IETF network 1091 slice delivered to them is delivered such that changes to other IETF 1092 network slices or services do not have any negative impact on the 1093 delivery of the IETF Network Slice. The IETF Network Slice customer 1094 may specify the degree to which their IETF Network Slice is 1095 unaffected by changes in the provider network or by the behavior of 1096 other IETF Network Slice customers. The customer may express this 1097 via an SLE it agrees with the provider. This concept is termed 1098 'isolation' 1100 7.2. Isolation in IETF Network Slice Realization 1102 Isolation may be achieved in the underlying network by various forms 1103 of resource partitioning ranging from dedicated allocation of 1104 resources for a specific IETF Network Slice, to sharing of resources 1105 with safeguards. For example, traffic separation between different 1106 IETF Network Slices may be achieved using VPN technologies, such as 1107 L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by 1108 network capacity planning, allocating dedicated network resources, 1109 traffic policing or shaping, prioritizing in using shared network 1110 resources, etc. Finally, service continuity may be ensured by 1111 reserving backup paths for critical traffic, dedicating specific 1112 network resources for a selected number of IETF Network Slices. 1114 8. Management Considerations 1116 IETF Network Slice realization needs to be instrumented in order to 1117 track how it is working, and it might be necessary to modify the IETF 1118 Network Slice as requirements change. Dynamic reconfiguration might 1119 be needed. 1121 9. Security Considerations 1123 This document specifies terminology and has no direct effect on the 1124 security of implementations or deployments. In this section, a few 1125 of the security aspects are identified. 1127 o Conformance to security constraints: Specific security requests 1128 from customer defined IETF Network Slices will be mapped to their 1129 realization in the underlay networks. It will be required by 1130 underlay networks to have capabilities to conform to customer's 1131 requests as some aspects of security may be expressed in SLEs. 1133 o IETF NSC authentication: Underlying networks need to be protected 1134 against the attacks from an adversary NSC as they can destabilize 1135 overall network operations. It is particularly critical since an 1136 IETF Network Slice may span across different networks, therefore, 1137 IETF NSC should have strong authentication with each those 1138 networks. Furthermore, both SBI and NBI need to be secured. 1140 o Specific isolation criteria: The nature of conformance to 1141 isolation requests means that it should not be possible to attack 1142 an IETF Network Slice service by varying the traffic on other 1143 services or slices carried by the same underlay network. In 1144 general, isolation is expected to strengthen the IETF Network 1145 Slice security. 1147 o Data Integrity of an IETF Network Slice: A customer wanting to 1148 secure their data and keep it private will be responsible for 1149 applying appropriate security measures to their traffic and not 1150 depending on the network operator that provides the IETF Network 1151 Slice. It is expected that for data integrity, a customer is 1152 responsible for end-to-end encryption of its own traffic. 1154 Note: see NGMN document[NGMN_SEC] on 5G network slice security for 1155 discussion relevant to this section. 1157 IETF Network Slices might use underlying virtualized networking. All 1158 types of virtual networking require special consideration to be given 1159 to the separation of traffic between distinct virtual networks, as 1160 well as some degree of protection from effects of traffic use of 1161 underlying network (and other) resources from other virtual networks 1162 sharing those resources. 1164 For example, if a service requires a specific upper bound of latency, 1165 then that service can be degraded by added delay in transmission of 1166 service packets through the activities of another service or 1167 application using the same resources. 1169 Similarly, in a network with virtual functions, noticeably impeding 1170 access to a function used by another IETF Network Slice (for 1171 instance, compute resources) can be just as service degrading as 1172 delaying physical transmission of associated packet in the network. 1174 While a IETF Network Slice might include encryption and other 1175 security features as part of the service, customers might be well 1176 advised to take responsibility for their own security needs, possibly 1177 by encrypting traffic before hand-off to a service provider. 1179 10. Privacy Considerations 1181 Privacy of IETF Network Slice service customers must be preserved. 1182 It should not be possible for one IETF Network Slice customer to 1183 discover the presence of other customers, nor should sites that are 1184 members of one IETF Network Slice be visible outside the context of 1185 that IETF Network Slice. 1187 In this sense, it is of paramount importance that the system use the 1188 privacy protection mechanism defined for the specific underlying 1189 technologies used, including in particular those mechanisms designed 1190 to preclude acquiring identifying information associated with any 1191 IETF Network Slice customer. 1193 11. IANA Considerations 1195 This document makes no requests for IANA action. 1197 12. Informative References 1199 [BBF-SD406] 1200 Broadband Forum, "End-to-end network slicing", BBF SD-406, 1201 . 1204 [HIPAA] HHS, "Health Insurance Portability and Accountability Act 1205 - The Security Rule", February 2003, 1206 . 1209 [I-D.ietf-teas-enhanced-vpn] 1210 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1211 Framework for Enhanced Virtual Private Network (VPN+) 1212 Services", draft-ietf-teas-enhanced-vpn-07 (work in 1213 progress), February 2021. 1215 [I-D.king-teas-applicability-actn-slicing] 1216 King, D., Drake, J., Zheng, H., and A. Farrel, 1217 "Applicability of Abstraction and Control of Traffic 1218 Engineered Networks (ACTN) to Network Slicing", draft- 1219 king-teas-applicability-actn-slicing-10 (work in 1220 progress), March 2021. 1222 [I-D.openconfig-rtgwg-gnmi-spec] 1223 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 1224 C., and C. Morrow, "gRPC Network Management Interface 1225 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 1226 progress), March 2018. 1228 [MACsec] IEEE, "IEEE Standard for Local and metropolitan area 1229 networks - Media Access Control (MAC) Security", 2018, 1230 . 1232 [NGMN-NS-Concept] 1233 NGMN Alliance, "Description of Network Slicing Concept", 1234 https://www.ngmn.org/uploads/ 1235 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 1236 2016. 1238 [NGMN_SEC] 1239 NGMN Alliance, "NGMN 5G Security - Network Slicing", April 1240 2016, . 1243 [PCI] PCI Security Standards Council, "PCI DSS", May 2018, 1244 . 1246 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1247 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1248 September 1999, . 1250 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1251 Address Translator (Traditional NAT)", RFC 3022, 1252 DOI 10.17487/RFC3022, January 2001, 1253 . 1255 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1256 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1257 DOI 10.17487/RFC3393, November 2002, 1258 . 1260 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1261 "Generalized Multiprotocol Label Switching (GMPLS) User- 1262 Network Interface (UNI): Resource ReserVation Protocol- 1263 Traffic Engineering (RSVP-TE) Support for the Overlay 1264 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 1265 . 1267 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1268 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1269 . 1271 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 1272 Interpretation of Generalized Multiprotocol Label 1273 Switching (GMPLS) Terminology within the Context of the 1274 ITU-T's Automatically Switched Optical Network (ASON) 1275 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 1276 2006, . 1278 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1279 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 1280 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 1281 DOI 10.17487/RFC5212, July 2008, 1282 . 1284 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1285 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1286 DOI 10.17487/RFC5440, March 2009, 1287 . 1289 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1290 the Network Configuration Protocol (NETCONF)", RFC 6020, 1291 DOI 10.17487/RFC6020, October 2010, 1292 . 1294 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1295 NAT64: Network Address and Protocol Translation from IPv6 1296 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1297 April 2011, . 1299 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1300 and A. Bierman, Ed., "Network Configuration Protocol 1301 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1302 . 1304 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1305 Ed., "A One-Way Delay Metric for IP Performance Metrics 1306 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1307 2016, . 1309 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1310 Ed., "A One-Way Loss Metric for IP Performance Metrics 1311 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1312 2016, . 1314 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1315 Ceccarelli, D., and X. Zhang, "Problem Statement and 1316 Architecture for Information Exchange between 1317 Interconnected Traffic-Engineered Networks", BCP 206, 1318 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1319 . 1321 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1322 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1323 . 1325 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1326 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1327 . 1329 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1330 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1331 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1332 2018, . 1334 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1335 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1336 DOI 10.17487/RFC8453, August 2018, 1337 . 1339 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 1340 Yoon, "Information Model for Abstraction and Control of TE 1341 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 1342 September 2018, . 1344 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1345 O. Gonzalez de Dios, "YANG Data Model for Traffic 1346 Engineering (TE) Topologies", RFC 8795, 1347 DOI 10.17487/RFC8795, August 2020, 1348 . 1350 [TS23501] 3GPP, "System architecture for the 5G System (5GS)", 1351 3GPP TS 23.501, 2019. 1353 [TS28530] 3GPP, "Management and orchestration; Concepts, use cases 1354 and requirements", 3GPP TS 28.530, 2019. 1356 [TS33.210] 1357 3GPP, "3G security; Network Domain Security (NDS); IP 1358 network layer security (Release 14).", December 2016, 1359 . 1362 Acknowledgments 1364 The entire TEAS Network Slicing design team and everyone 1365 participating in related discussions has contributed to this 1366 document. Some text fragments in the document have been copied from 1367 the [I-D.ietf-teas-enhanced-vpn], for which we are grateful. 1369 Significant contributions to this document were gratefully received 1370 from the contributing authors listed in the "Contributors" section. 1371 In addition we would like to also thank those others who have 1372 attended one or more of the design team meetings, including the 1373 following people not listed elsewhere: 1375 o Aihua Guo 1377 o Bo Wu 1379 o Greg Mirsky 1381 o Lou Berger 1383 o Rakesh Gandhi 1385 o Ran Chen 1386 o Sergio Belotti 1388 o Stewart Bryant 1390 o Tomonobu Niwa 1392 o Xuesong Geng 1394 Further useful comments were received from Daniele Ceccarelli, Uma 1395 Chunduri, Pavan Beeram, Tarek Saad, Med Boucadair, Kenichi Okagi, 1396 Oscar Gonzalez de Dios, and Xiaobing Niu. 1398 This work is partially supported by the European Commission under 1399 Horizon 2020 grant agreement number 101015857 Secured autonomic 1400 traffic management for a Tera of SDN flows (Teraflow). 1402 Contributors 1404 The following authors contributed significantly to this document: 1406 Jari Arkko 1407 Ericsson 1408 Email: jari.arkko@piuha.net 1410 Dhruv Dhody 1411 Huawei, India 1412 Email: dhruv.ietf@gmail.com 1414 Jie Dong 1415 Huawei 1416 Email: jie.dong@huawei.com 1418 Xufeng Liu 1419 Volta Networks 1420 Email: xufeng.liu.ietf@gmail.com 1422 Authors' Addresses 1424 Adrian Farrel (editor) 1425 Old Dog Consulting 1426 UK 1428 Email: adrian@olddog.co.uk 1429 Eric Gray 1430 Independent 1431 USA 1433 Email: ewgray@graiymage.com 1435 John Drake 1436 Juniper Networks 1437 USA 1439 Email: jdrake@juniper.net 1441 Reza Rokui 1442 Nokia 1444 Email: reza.rokui@nokia.com 1446 Shunsuke Homma 1447 NTT 1448 Japan 1450 Email: shunsuke.homma.ietf@gmail.com 1452 Kiran Makhijani 1453 Futurewei 1454 USA 1456 Email: kiranm@futurewei.com 1458 Luis M. Contreras 1459 Telefonica 1460 Spain 1462 Email: luismiguel.contrerasmurillo@telefonica.com 1464 Jeff Tantsura 1465 Juniper Networks 1467 Email: jefftant.ietf@gmail.com