idnits 2.17.1 draft-defoy-netslices-3gpp-network-slicing-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 (October 16, 2017) is 2382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. de Foy 3 Internet-Draft A. Rahman 4 Intended status: Informational InterDigital Communications, LLC 5 Expires: April 19, 2018 October 16, 2017 7 Network Slicing - 3GPP Use Case 8 draft-defoy-netslices-3gpp-network-slicing-02 10 Abstract 12 This document describes work conducted at the 3GPP standard 13 organization on 5G Network Slicing. Its goal is to provide detailed 14 use cases, and help better define requirements, for Internet 15 Protocols supporting Network Slicing. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 19, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. NS Work in 3GPP Prior to 5G Phase 1 . . . . . . . . . . . 3 54 2. Network Slicing Requirements in 3GPP . . . . . . . . . . . . 3 55 3. Network Slicing in Logical 5G Architecture in 3GPP . . . . . 4 56 3.1. Early Work on RAN Slicing . . . . . . . . . . . . . . . . 7 57 4. Management Aspect of Network Slicing in 3GPP . . . . . . . . 8 58 5. 5G Virtual Infrastructure Management in 3GPP . . . . . . . . 8 59 6. Security for Network Slicing in 3GPP . . . . . . . . . . . . 10 60 7. Analysis and Input to IETF NETSLICES . . . . . . . . . . . . 12 61 7.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 12 62 7.1.1. Management Use Case: Create or Terminate a 3GPP 63 Network Slice Subnet . . . . . . . . . . . . . . . . 12 64 7.1.2. Management Use Case: Create or Terminate a Complete 65 3GPP Network Slice . . . . . . . . . . . . . . . . . 13 66 7.1.3. Management Use Case: Activate or Deactivate a 67 Complete 3GPP Network Slice . . . . . . . . . . . . . 14 68 7.1.4. Management Use Case: Update a Complete 3GPP Network 69 Slice . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1.5. Management Use Case: Monitor Network Slices . . . . . 15 71 7.1.6. Management Use Case: Slice Management Exposure . . . 15 72 7.1.7. Management Use Case: Support for Multi-Domain Network 73 Slice . . . . . . . . . . . . . . . . . . . . . . . . 16 74 7.1.8. Operational Use Case: Select Network Slices for a 75 Device . . . . . . . . . . . . . . . . . . . . . . . 16 76 7.1.9. Operational Use Case: Create or Terminate a PDU 77 Session . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.2. Additional Discussion on Security Related Requirements . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 82 11. Informative References . . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 This document describes work conducted at the 3GPP standard 88 organization on 5G Network Slicing. Its goal is to provide detailed 89 use cases, and help better define requirements, for Internet 90 Protocols supporting Network Slicing. 92 The concept of Network Slicing (NS) is considered a key mechanism for 93 5G networks to serve vertical industries with widely different 94 service needs, in term of latency, reliability, capacity, and domain 95 specific extra functionalities. It does so by exposing isolated 96 partitions of network resources and services. The IETF Bar-BoF 97 NETSLICES activity studies the need for supporting protocols. In 98 particular, [I-D.gdmb-netslices-intro-and-ps] defines NS in a broad 99 context and suggests related problems and work areas. It also 100 identifies the need to provide use cases such as, for example, ultra- 101 low latency and massive-connectivity machine communication services. 102 We propose to review ongoing NS work in 3GPP within the present 103 document. This constitutes in our view another valid type of use 104 case, since 3GPP architecture may ultimately use or integrate with NS 105 solutions defined in IETF. 107 Sections 2 to 6 aim to represent the current state of NS and related 108 aspects in 3GPP. We attempted to leave our own analysis out of these 109 sections and present it into section 7. For simplicity, 3GPP- 110 specific acronyms are defined in the section they are used, which is 111 mostly section 3. 113 1.1. Background 115 The 3GPP standard organization is in the process of developing 5G 116 system architecture, which includes NS. In the present document we 117 will use information collected from 3GPP Release 15 specifications 118 (as well as preliminary studies from Release 14 when specifications 119 are not yet available). This release aims to address a more urgent 120 subset of commercial needs in "5G Phase 1", with expected deployments 121 in 2020. Work on NS is split between different working and study 122 groups, reviewed here in separate sections. 124 1.2. NS Work in 3GPP Prior to 5G Phase 1 126 While the present document will only focus on NS in 5G Phase 1, an 127 early form of NS was introduced in Release 13, with the Dedicated 128 Core Network (DCN) or DECOR feature, where dedicated core network 129 nodes are forming a DCN serving subscribers or devices with a certain 130 "usage type" (e.g. machine-to-machine or enterprise). In the Release 131 14 eDECOR feature, the DCN selection mechanism was extended to be 132 assisted by the device, which can now send its usage type to the RAN. 133 This is specified in [_3GPP.23.401]. Deployments are expected in 134 2017 and 2018. 136 2. Network Slicing Requirements in 3GPP 138 NS requirements are included in [_3GPP.22.261]. There are 139 requirements related to: 141 o Provisioning: create/modify/delete Network Slices, provision 142 network functions to be used in Network Slices, define network 143 services and capabilities supported by a network slice. 145 o Managing association to slices: configure association of devices 146 and services to Network Slices, move/remove user between/from 147 slices. 149 o Interoperating: support roaming and non-roaming using the same 150 home slice, support devices simultaneously connected to multiple 151 slices. 153 o Supporting performance and isolation: support dynamic slice 154 elasticity, ensure performance isolation during normal and elastic 155 slice operation and during slice creation or deletion, enable 156 operators to differentiate performance and functionalities between 157 slices. 159 3. Network Slicing in Logical 5G Architecture in 3GPP 161 5G network architecture is entering its normative stage in 2017 with 162 a "5G System - Phase 1" Release 15 work item, which is in the process 163 of producing two technical specifications: 23.501 "System 164 Architecture for the 5G System" and 23.502 "Procedures for the 5G 165 System". At this early stage, though, we will still need to refer to 166 the earlier technical report [_3GPP.23.799]. The following text 167 summarizes what has been agreed about NS (refer to section 8.1 of 168 that report for more details). 170 A Network Slice is a complete logical network including Radio Access 171 Network (RAN) and Core Network (CN). It provides telecommunication 172 services and network capabilities, which may vary (or not) from slice 173 to slice. Distinct RAN and Core Network Slices will exist. A device 174 may access multiple Network Slices simultaneously through a single 175 RAN. 177 The device may provide Network Slice Selection Assistance Information 178 (NSSAI) parameters to the network to help it select a RAN and a core 179 network part of a slice instance for the device. A single NSSAI may 180 lead to the selection of several slices. The network may also use 181 device capabilities, subscription information and local operator 182 policies to do the selection. 184 A NSSAI is a collection of smaller components, Session Management 185 NSSAIs (SM-NSSAI), which each include a Slice Service Type (SST) and 186 possibly a Slice Differentiator (SD). Slice service type refers to 187 an expected network behavior in terms of features and services (e.g. 188 specialized for broadband or massive IoT), while the slice 189 differentiator can help selecting among several Network Slice 190 instances of the same type, e.g. to isolate traffic related to 191 different services into different slices. 193 A PDU session is a 5G concept for an association between the device 194 and a data network, which can be IP, Ethernet or Unstructured (i.e. 195 transparent to the 5G system). The device will associate an 196 application with one out of multiple parallel PDU sessions, each PDU 197 session correspond to one core Network Slice and one RAN slice. 198 Different PDU sessions may belong to different slices. More 199 precisely, an application will be associated with a SM-NSSAI (as 200 mentioned above, this includes a slice service type and may also 201 include a slice differentiator), and data for this application will 202 be routed to a PDU session associated to this SM-NSSAI. 204 Part of the control plane, the Common Control Network Function 205 (CCNF), is common to all or several slices. It includes the Access 206 and mobility Management Function (AMF) as well as the Network Slice 207 Selection Function (NSSF), which is in charge of selecting core 208 Network Slice instances. Besides those shared functions, different 209 Network Slices may also have dedicated control plane functions such 210 as the Session Management Function (SMF), which manages PDU sessions. 211 User plane functions are dedicated to each slice. The RAN selects a 212 CCNF for a new PDU session. CCNF may initiate the redirection of 213 service for a device towards another CCNF, initially at session 214 setup, or later on. 216 In figures 1 and 2 we attempt to represent the use of NS in 3GPP 217 logical architecture (those figures are our interpretation and are 218 not directly adapted from the report). Figure 1 represents the role 219 of NSSAI in network selection. Figure 2 represents the major network 220 functions and interfaces in the context of RAN and Core Network 221 Slicing. The terms used in these diagrams were introduced earlier. 222 System description and diagrams in section 4 of [_3GPP.23.501] can 223 provide additional context. 225 +-------+ 226 | | 227 |Device | 228 | | 229 RAN uses NSSAI +---+---+ 230 to select CCNF | 231 \ |(NSSAI) 232 \ | 233 +---+---+ 234 | +-------------+ 235 CCNF uses NSSAI | RAN +---------+ | 236 to select slice | | | | 237 or redirect to +---+---+ | | 238 another CCNF | | | 239 \ |(NSSAI) | | 240 \ | | | 241 +-------+--------+ | | 242 | Common Control | | | 243 | Plane Network | | | 244 | Functions | | | 245 | (CCNF) | | | 246 +-----+----+-----+ | | 247 | | | | 248 | | | | 249 | | | | 250 +---------|----+----------|---+-------+ 251 | | | | 252 +------------|---------------|-------+ | 253 | +---------++ +-----+----+ | | 254 | | | | | | | 255 | | +------+ | | +------+ | | | 256 | | | | | | | | | | | 257 | | |CP NF1| | | |UP NF1| | | | 258 | | | | | | | | | | | 259 | | +------+ | | +------+ | | | 260 | | ... | | ... | | | 261 | | | | | | | 262 | | +------+ | | +------+ | | | 263 | | | | | | | | | | | 264 | | |CP NFn| | | |UP NFn| | | | 265 | | | | | | | | | | | 266 | | +------+ | | +------+ | | | 267 | | | | | +---+ 268 | +----------+ +----------+ | 269 +------------------------------------+ 270 Core Network Slice Instances 272 Figure 1: Network Slice Selection in 3GPP architecture 273 CCNF Network Slice Instance 274 +-----------------+---------------------+ 275 | | | 276 | | | 277 | +--------+ | +--------+ | 278 | | Control| | | Control| | 279 +--------+ Plane +----------+ Plane | | 280 | | | AMF... | | | SMF... | | 281 | | +--------+ | +----+---+ | 282 | | | | | 283 | | | | | 284 | | | | | 285 +---+--+ +-----------------+ | | 286 |Device| | | | | 287 +---+--+ | | | | 288 | | | | | 289 | | +--------+ | +------+-----+ | 290 | | | | | | User Plane | | +---------------+ 291 +--------+ RAN +--------+ Functions +------+Data Network or| 292 | | | | | | | | The Internet | 293 | +--------+ | +------------+ | +---------------+ 294 | | | 295 | | | 296 +-----------------+---------------------+ 297 RAN Slice 299 Figure 2: Network Slices in 3GPP architecture 301 3.1. Early Work on RAN Slicing 303 In line with the logical architecture described above, early work on 304 RAN slicing is being conducted as part of the larger Release 14 305 "Study on New Radio Access Technology". Key principles are likely to 306 include the following, extracted from [_3GPP.38.801]: 308 1. RAN will support differentiated handling of traffic between pre- 309 configured, isolated RAN slices. How to perform this is left to 310 implementation. 312 2. Selection of the RAN slice will be based on IDs (which should be 313 the slice service type and slice differentiator defined above) 314 provided by the device or core network. 316 3. A RAN slice may or may not be available at a given location. 318 4. RAN will select the core network slice. 320 5. QoS differentiation within a RAN slice will be supported as well. 322 4. Management Aspect of Network Slicing in 3GPP 324 3GPP is developing a Release 14 "Study on management and 325 orchestration of NS for next generation network" technical report 326 [_3GPP.28.801], which defines an information model where the Network 327 Slice as well as physical and virtualized network functions belong to 328 the network operator domain, while the virtualized resources belong 329 to another domain operated by a virtualization infrastructure service 330 provider. 332 The concept of "Network Slice Subnet" is used in the model, as 333 defined originally in [NGMN_Network_Slicing]. Network Slice Subnet 334 instances are comprised of physical and virtual resources, have a 335 life cycle independent from Network Slices they belong to, can be 336 shared between several Network Slices and may be associated with 337 other Network Slice Subnet instances. 339 Multiple management use cases are described, ranging from creating 340 and monitoring a slice instance to configuring its SLA policy, 341 capacity and roaming support. It is also expected that some level of 342 slice management will be exposed to customers, and that operators 343 will have the possibility to create end-to-end Network Slices 344 involving multiple operators' networks. 346 Key issues are identified, including creating a slice across multiple 347 administrative domains, sharing a Network Slice between multiple 348 services, moving towards a more autonomous management, as well as 349 additional management specific key issues. 351 Finally, the life cycle of a slice is defined over 4 phases: 352 preparation phase including design and pre-provisioning, an 353 "instantiation, configuration and activation" phase, a run-time phase 354 including supervision and reporting, as well as upgrade, 355 reconfiguration and scaling, and a decommissioning phase. 357 5. 5G Virtual Infrastructure Management in 3GPP 359 To support the logical architecture defined earlier, some aspects of 360 virtualization infrastructure management are also being standardized 361 by 3GPP, through the activity "Management of mobile networks that 362 include virtualized network functions". This includes 5 work tasks, 363 the first of which deals with concept, architecture and requirements 364 [_3GPP.28.500], and 4 additional specialized work tasks on 365 configuration, fault, lifecycle and performance management, are in 366 the process of creating more detailed technical specification 367 documents. 369 The new 5G management system is tied to NFV-MANO, as defined by ETSI. 370 Its system architecture is described in [_3GPP.28.500] and 371 represented in Figure 3 (directly adapted from TS28.500). It defines 372 interconnections between the 3GPP management system and the NFV-MANO 373 system. NFV-MANO has the responsibility to manage NFV Infrastructure 374 (NFVI) and VNF lifecycle, and to report performance data, fault and 375 VNF instance information to 3GPP management system. 377 +--------------------------------------------+ +-------------+ 378 | +----------------------------------+OSS/BSS| | NFV |(3) 379 | | NM | | (1)|Orchestrator +--+ 380 | +--+--------------+--------------+-+ +----+ (NFVO) | | 381 +----|--------------|--------------|---------+ +-------------+ | 382 | | | |(2) | 383 | Itf-N | Itf-N | Itf-N | | 384 | | | +------+------+ | 385 | | | | | | 386 | +---------+------------+ | | | | 387 | |DM +----------------+ | | (5) | | | 388 | | | EM +------------------+ VNF | | 389 | | +-+--------+-----+ | | (5) | Manager | | 390 | +-----|--------|-------+ | +----------+ (VNFM) | | 391 | | | | | | | | 392 | | | | | | | | 393 | | | | | | | | 394 | | | | | | | | 395 +-+-+--+ | | +--+---++--+ (5) | | | 396 | | EM | | | | EM | +------+ | | 397 | +----+ | | +-------+ | +------+------+ | 398 | | | | | VNF | | | 399 | | +----++ +----+----+ +----+-----+ |(4) | 400 | | | | | | | | | 401 | | | | | VNF | | | | 402 | | | | | | |(7) | | 403 | | | | +-----+---+ | +------+------+ | 404 | | | | |(7) | | | | 405 | NE | | NE | +-----+----------+----+ | Virtualized | | 406 | (PNF)| |(PNF)| | | | Infrastruct.| | 407 | | | | | NFV Infrastructure | (6) | Manager +--+ 408 | | | | | (NFVI) +-------+ (VIM) | 409 | | | | | | | | 410 +------+ +-----+ +---------------------+ +-------------+ 412 Figure 3: 3GPP Network Management Architecture 414 The major building blocks on the left are from pre-existing 3GPP 415 architecture and on the right are from ETSI NFV architecture. Itf-N 416 is the traditional 3GPP management interface between the network 417 manager and domain and element managers, some of which will now be 418 collocated with VNFs. Other interfaces identified in the diagram are 419 defined as part of the NFV architecture and described in published 420 NFV specifications (which themselves do not make mention of NS). 422 o (1) Os-Ma-nfvo enables managing Network Service Descriptors (NSD), 423 network service lifecycle, performance, faults and VNF packages. 424 The NSD information model is specified by ETSI NFV as well. It 425 enables describing network connectivity topology graphs where VNFs 426 are connected together through virtual links. An NSD also 427 includes VNF descriptors, which include memory and CPU 428 requirements, a link to a software image, initial setup scripts, 429 etc. 431 o (2) Or-Vnfm includes package management, VNF lifecycle/fault/ 432 configuration management, virtualized resources management (in 433 indirect mode as seen below), and relays notifications from the 434 VNF or EM. 436 o (3) Or-Vi and (4) Vi-Vnfm are the northbound interface of the 437 Virtual Infrastructure Manager (VIM). The orchestrator can 438 basically use a direct interface to VIM, or indirectly go through 439 the VNF manager over Or-Vnfm. The orchestrator can add software 440 images, create/update/terminate virtualized compute/network/ 441 storage resources allocations, manage resource capacity, manage 442 network virtual paths, run and query performance collection jobs, 443 set quotas. Location/affinity constraints can be applied when 444 creating resources. 446 o (5) Ve-Vnfm is used both between VNFM and EM and between VNFM and 447 VNFs. It includes lifecycle, performance, fault and configuration 448 management, as well as notifications from the EM that VNFM can 449 subscribe to. 451 o (6) Nf-Vi is for assignment of virtualized resources, hardware 452 resource configuration and state information exchange. 454 o (7) Vn-Nf represents the execution environment provided to the 455 VNF. 457 6. Security for Network Slicing in 3GPP 459 The present section on NS security is based on the "Study on 460 Architecture and Security for Next Generation System", a Release 14 461 study item. Its related technical report is [_3GPP.33.899], and 462 covers, among other areas, a NS security area dealing with service 463 access, network function sharing and isolation. Multiple key issues 464 are summarized here (refer to [_3GPP.33.899] section 5.8 for more 465 details): 467 1. Isolation requirements, especially performance isolation, ask for 468 data plane actions on one slice to have no influence on other 469 Network Slices and for control plane actions (e.g. 470 creation/update/deletion) to have little influence on other 471 slices. Lack of isolation can enable DoS attacks from one slice 472 to another, especially since some functions can be shared between 473 slices. Moreover, a device can access multiple Network Slices, 474 which increases the possibility for leakage/breach type of issues 475 between Network Slices, both from the device and the service 476 side. 478 2. Different Network Slices may need to implement different security 479 policies, e.g. in term of authentication requirements (IoT vs. 480 mobile broadband user). Authentication may be centralized and/or 481 per-slice. 483 3. Security and privacy of devices' access to Network Slices is also 484 a concern. It may be possible to forge slice selection 485 information for a device. Slice selection information sent over 486 the access network can also lead to confidentiality issues. The 487 proposed key hierarchy supports having different keys for 488 different slices. How to enable security isolation of a common 489 control plane between different Network Slices is not addressed 490 at this point. 492 4. Security of sensitive shared network elements such as the HSS 493 (which holds customers' profiles) is identified as a key issue as 494 well. 496 5. Slice management functions should be secured, since an attacker 497 may use them, e.g. to delete a slice. Slice management 498 capabilities exposed through APIs for 3rd parties are especially 499 vulnerable. 501 6. Security on inter-slice communications is an issue in several 502 scenarios, for example when multiple Network Slices share control 503 plane functions, and when a RAN slice and a Core Network slice 504 are interconnected to form a complete slice. Each slice is 505 considered a different trusted domain. 507 7. A range of potential issues related to virtualization are yet to 508 be explored further, though it is not clear if they are in the 509 scope of 3GPP. Issues include for example isolation between VNFs 510 hosted by the same hypervisor, authentication between VNFs, 511 performance isolation between VNFs. 513 7. Analysis and Input to IETF NETSLICES 515 Earlier sections of this document summarized our understanding of 5G 516 architecture and requirements for NS, as defined by 3GPP, in their 517 current state. Our goal in these sections was to provide context to 518 IETF NETSLICES, since a protocol or framework defined by IETF for NS 519 may be used to implement or interoperate with 3GPP-compliant 5G 520 systems. In reference to Figure 3, the scope of IETF involvement 521 with NS could be within NFV Infrastructure, as well as some aspects 522 of the control plane on the right-hand side of the figure. The 523 concept of "Network Slice Subnet" discussed in section 4 may be 524 useful as a building block, e.g. a single-domain and composable 525 service chain that is used to assemble a network slice. Defining the 526 interfaces of such a component could help focusing on sharing between 527 Network Slices and extending Network Slices across domains. 529 We will now attempt to derive high level use cases and requirements 530 from this work. The goal is to serve as 3GPP-focused input to future 531 efforts to gather use cases and requirements for IETF NETSLICES. 533 7.1. Use Cases 535 The following 3GPP-focused use cases for NS are derived from the 536 reviewed 3GPP specifications and reports. Especially, management 537 related use cases are derived from [_3GPP.28.801] and operational use 538 cases are derived from [_3GPP.23.501]. 540 The goal here is to describe the use cases at high level only, with 541 the understanding that the IETF NETSLICES group may choose to define 542 selected use cases further if needed. 544 In the following text we will use the terms "Complete 3GPP Network 545 Slice" to refer to a "Network Slice Instance" used by 3GPP, and "3GPP 546 Network Slice Subnet" to refer to "Network Slice Subnet Instance". 547 Moreover, we consider that the (IETF) Network Slice concept is a 548 generalization of the "3GPP Network Slice Subnet", i.e. the "3GPP 549 Network Slice Subnet" is a particular Network Slice which happens to 550 be part of a 3GPP network. 552 7.1.1. Management Use Case: Create or Terminate a 3GPP Network Slice 553 Subnet 555 The operator's OSS/BSS provides a description of a Network Slice to 556 the Orchestrator, which, through the Virtual Infrastructure Manager, 557 configures compute and network elements to create a Network Slice 558 holding a specific set of interconnected virtual and/or physical 559 network functions. User plane Network Slices include one or more 560 bidirectional paths between network functions (i.e. one or more 561 service function chains). Control plane Network Slices can either 562 include a set of service function chains or alternatively can 563 interconnect multiple network functions in a virtual network. In all 564 cases, Network Slices are defined with a variable set of reserved 565 KPIs, including minimum and maximum throughput, delay, packet loss, 566 etc. 568 Potential requirements: 570 o A Network Slice can be a service function chain or a virtual 571 network 573 o A Network Slice can be associated with a variable set of resource 574 reservation with regards to KPIs such as minimum and maximum 575 throughput, delay, packet loss, etc. 577 7.1.2. Management Use Case: Create or Terminate a Complete 3GPP Network 578 Slice 580 The operator creates a Complete 3GPP Network Slice by composing 581 together smaller Network Slices together, which the highest level 582 Network Slices being: a RAN Network Slice, a Core Network slice 583 holding user plane (UPF) and control plane (SMF) network functions, 584 as well common Core Network functions. Those common core network 585 functions (AMF, PCF, etc.) may be placed in multiple Network Slices 586 since they can have different scaling properties. 588 The Common CN Function Network Slices (including AMF) may be shared 589 or dedicated to a given SMF. In the shared case, there will be 590 traffic flows terminated within a dedicated CN slice (e.g. SMF) and 591 the shared function. RAN Slices may similarly be shared or 592 dedicated. In the shared case, each user traffic flow passing 593 through a shared RAN slice will then pass through one out of multiple 594 dedicated CN slices interconnected with this shared RAN Slice. In 595 both (RAN and CN) shared cases, there should be reserved resources 596 within the shared Network Slice, to ensure that the whole flow has 597 reserved resources. 599 NS is not a required feature in 3GPP, especially not all Core Network 600 functions are required to belong to a slice with a specified level of 601 service. In some cases, common network functions like AMF and PCF 602 may be implemented outside of a Network Slice, or, equivalently, in a 603 Network Slice with no specified QoS. 605 A wide variation of cases, associating "n" Network Slices with "m" 606 network services or applications involving "p" end devices, is 607 supported. For example: a single slice instance could be associated 608 with multiple IoT applications, each connected to multiple devices. 610 In another example, an application may split its end users in 2 611 service categories with different SLAs, using different Network Slice 612 instances. 614 Potential requirements: 616 o Network Slices can be composed of smaller Network Slices which can 617 be dedicated or shared. 619 o Functions in Network Slices can interact with network functions 620 outside of a Network Slice. 622 7.1.3. Management Use Case: Activate or Deactivate a Complete 3GPP 623 Network Slice 625 Each Network Slice can be created in a deactivated state, and can be 626 later switched between activated and deactivated state. This can 627 provide multiple advantages, e.g. speeding up procedures, and 628 enabling using a pool of unused resources. Activation or 629 deactivation of a Complete 3GPP Network Slice can then be 630 orchestrated as the activation (resp. deactivation) of individual 631 Network Slices, possibly in a given order. 633 Potential requirement: 635 o A slice can be created deactivated, and can be switched between 636 activated and deactivated state. 638 7.1.4. Management Use Case: Update a Complete 3GPP Network Slice 640 The operator can modify the configuration (e.g. network or compute 641 capacity or capability) of one of the Network Slices composing the 642 Complete 3GPP Network Slice, while it is in use. Example of such 643 operations include: 645 o Increase the capacity of NFs 647 o Update the configuration of NFs 649 o Add, replace or remove a NFs 651 o Add, replace or remove a Network Slice 653 Some operations affecting a shared slice may not be possible without 654 affecting other Network Slices, and may be replaced by other 655 operations: for example, instead of changing the configuration of a 656 shared AMF to accommodate the needs of a SMF, another Network Slice 657 with an AMF may be created or activated, and replace the original 658 AMF's slice for this SMF. 660 Potential requirement: 662 o Ability to add, replace, remove NFs, and Network Slices without 663 affecting service, assuming that the network service's design 664 enables this. 666 7.1.5. Management Use Case: Monitor Network Slices 668 The 3GPP management system monitors performance of individual Network 669 Slice level and coalesce performance data for the whole Complete 3GPP 670 Network Slice. Individual Network Slice level performance data is 671 also useful to decide to scale up or down services within those 672 slices. Performance data (or events) includes user and control 673 traffic load data. It can also include QoS/SLA data, e.g. indicating 674 whether services were provided at expected QoS/SLA level. Alarms 675 notifications can be individually enabled. Events and alarms from a 676 shared Network Slice contain enough information to be attributed by 677 the 3GPP management system to one of the Complete 3GPP Network Slices 678 that contain this shared Network Slice. 680 Potential requirements: 682 o Performance monitoring (measure of KPIs and alarms) occurs at 683 Network Slice level. 685 o Performance monitoring should be able to identify flows which are 686 shared with other Network Slices, and enable matching performance 687 data with those flows and Network Slices. 689 7.1.6. Management Use Case: Slice Management Exposure 691 3GPP networks may in some cases expose partial 3GPP Network Slice 692 management to third party Communication Service Providers (CSP), who 693 may in turn consume this service or provide it to their own 694 customers. Using this management interface a third party can request 695 the creation of a Complete 3GPP Network Slice using specifications of 696 NFs, isolation, security, performance requirements (such as traffic 697 demand requirements for the coverage areas, QoS for service). 699 When a 3GPP operator exposes management data (e.g. fault management 700 data, performance data) about a Complete 3GPP Network Slice shared by 701 multiple customers of a CSP, exposed management data of each customer 702 is isolated from each other. 704 Potential requirement: 706 o Management data should enable identification of individual flows 707 in such a way that it can be match to different customer groups. 709 7.1.7. Management Use Case: Support for Multi-Domain Network Slice 711 To support roaming, a 3GPP operator configures one or more Complete 712 3GPP Network Slice to be selected to support roaming subscribers, to 713 act as visited Complete 3GPP Network Slices. Operators configure the 714 interconnection of a home Complete 3GPP Network Slice in one domain 715 and a visited Complete 3GPP Network Slice in the other domain. 716 Performance data is sent from the visited domain to the control 717 function in the home domain. 719 Potential requirement: 721 o Support secure inter-domain interconnection for exchanging user 722 plan traffic and performance data. 724 7.1.8. Operational Use Case: Select Network Slices for a Device 726 A subscriber's device initially connects to the network. It sends, 727 over a signaling path through the RAN, a message including a Network 728 Slice Selection Assistance Information (NSSAI), which is a set of one 729 or more tuples (slice type, slice differentiator). The RAN selects 730 an appropriate AMF and forwards the NSSAI to this function. The AMF 731 determines (possibly with the help of a Network Slice Selection 732 Function) the set of allowed (slice type, slice differentiator) for 733 this subscriber, using the NSSAI, device capabilities, subscriber's 734 profile, and operator policy. There is no physical resource 735 reservation at this stage. 737 Slice selection in this context is a preparation of control plane 738 functions and may probably be considered out of scope for a general 739 NS framework. Therefore no potential requirements are derived from 740 it. 742 7.1.9. Operational Use Case: Create or Terminate a PDU Session 744 At some point, the device needs a PDU session to transport flows for 745 a specific application. It sends, over a signaling path through the 746 RAN, a PDU session establishment request to the AMF, typically 747 including a tuple (slice type, slice differentiator) and a data 748 network name. If no such tuple is provided, the AMF will determine a 749 default one to use. The AMF will then determine which SMF (i.e. 750 which Core Network Slice) to use, taking into consideration: the 751 tuple (slice type, slice differentiator), data network name, 752 subscription information, local operator policies and load conditions 753 of the candidate SMFs. If this is a home-routed roaming case, the 754 AMF will select a SMF in the visited network and another SMF in the 755 home network. The SMF selects the user plane function (UPF) that 756 will handle the traffic, and transmits configuration information to 757 this UPF (e.g. packet detection, QoS enforcement and reporting rules 758 to be installed on the UPF for this PDU Session). 760 Potential requirement: 762 o A network slice control API should enable installing new flows and 763 associated reporting rules. 765 7.2. Additional Discussion on Security Related Requirements 767 In addition to potential requirements listed along with the use cases 768 above, here is a list of additional discussion points related to 769 security requirements and not directly described in a use case at 770 this point: 772 1. 3GPP architecture demonstrates a requirement for authenticating 773 users of Network Slice resources (which may or may not be within 774 the scope of an IETF framework). There is however a need for 775 separate per-slice security policies, e.g. having different 776 authentication requirements between IoT and broadband. 778 2. Interoperation between Network Slices is a major risk factor on 779 isolation and can occur in various scenarios: 781 * "Interoperation for extension" when data and control plane are 782 interconnected for extending a slice between RAN and CN, or 783 between visitor and home networks in a roaming scenario. 785 * "Interoperation through network function sharing" occurs in 786 3GPP when some control planes functions are performed by 787 common functions. 789 * "Interoperation through end points" can occur on user devices 790 connected to multiple Network Slices, or on an application 791 server side interacting with clients over different slices. 793 3. There is a strict requirement for security and performance 794 isolation from data plane and control plane actions between 795 slices. Should Network Slices be allowed to tap into currently 796 unused resource capacity? There is a possible tradeoff here 797 between performance/network efficiency and isolation, since in 798 this case, through its normal operation, a slice may influence 799 another slice by denying it this extra capacity. 801 8. Security Considerations 803 Security aspects of NS in 3GPP are covered in section 6. 805 9. IANA Considerations 807 This document requests no IANA actions. 809 10. Acknowledgements 811 The authors would like to thank Ulises Olvera-Hernandez for his 812 contribution and comments. 814 11. Informative References 816 [_3GPP.22.261] 817 3GPP, "Service requirements for next generation new 818 services and markets", 3GPP TS 22.261 1.1.0, February 819 2017, . 821 [_3GPP.23.401] 822 3GPP, "General Packet Radio Service (GPRS) enhancements 823 for Evolved Universal Terrestrial Radio Access Network 824 (E-UTRAN) access", 3GPP TS 23.401 14.2.0, 12 2016, 825 . 827 [_3GPP.23.501] 828 3GPP, "System Architecture for the 5G System", 3GPP 829 TS 23.501 0.2.0, 2 2017, 830 . 832 [_3GPP.23.799] 833 3GPP, "Study on Architecture for Next Generation System", 834 3GPP TR 23.799 14.0.0, 12 2016, 835 . 837 [_3GPP.28.500] 838 3GPP, "Telecommunication management; Management concept, 839 architecture and requirements for mobile networks that 840 include virtualized network functions", 3GPP TS 28.500 841 1.3.0, 11 2016, 842 . 844 [_3GPP.28.801] 845 3GPP, "Study on management and orchestration of network 846 slicing for next generation network", 3GPP TR 28.801 847 0.4.0, 1 2017, 848 . 850 [_3GPP.33.899] 851 3GPP, "Study on the security aspects of the next 852 generation system", 3GPP TR 33.899 0.6.0, 11 2016, 853 . 855 [_3GPP.38.801] 856 3GPP, "Study on the security aspects of the next 857 generation system", 3GPP TR 38.801 1.0.0, 12 2016, 858 . 860 [I-D.gdmb-netslices-intro-and-ps] 861 Galis, A., Dong, J., kiran.makhijani@huawei.com, k., 862 Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network 863 Slicing - Introductory Document and Revised Problem 864 Statement", draft-gdmb-netslices-intro-and-ps-02 (work in 865 progress), February 2017. 867 [NGMN_Network_Slicing] 868 NGMN, "Description of Network Slicing Concept", 1 2016, 869 . 872 Authors' Addresses 874 Xavier de Foy 875 InterDigital Communications, LLC 876 Montreal 877 Canada 879 Email: Xavier.Defoy@InterDigital.com 881 Akbar Rahman 882 InterDigital Communications, LLC 883 Montreal 884 Canada 886 Email: Akbar.Rahman@InterDigital.com