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