idnits 2.17.1 draft-homma-slice-provision-models-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 (November 3, 2019) is 1630 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PNF' is mentioned on line 646, but not defined == Missing Reference: 'VM' is mentioned on line 839, but not defined == Missing Reference: 'APL' is mentioned on line 1035, but not defined == Missing Reference: 'AP' is mentioned on line 836, but not defined == Missing Reference: 'FW' is mentioned on line 838, but not defined == Missing Reference: 'SV' is mentioned on line 840, but not defined == Outdated reference: A later version (-04) exists of draft-defoy-coms-subnet-interconnection-01 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual S. Homma 3 Internet-Draft H. Nishihara 4 Intended status: Informational NTT 5 Expires: May 6, 2020 T. Miyasaka 6 KDDI Research 7 A. Galis 8 University College London 9 V. Ram OV 10 Independent Research Consultant India 11 D. Lopez 12 LM. Contreras 13 J. Ordonez-Lucena 14 Telefonica I+D 15 P. Martinez-Julia 16 NICT 17 L. Qiang 18 Huawei Technologies 19 R. Rokui 20 L. Ciavaglia 21 Nokia 22 X. de Foy 23 InterDigital Inc. 24 November 3, 2019 26 Network Slice Provision Models 27 draft-homma-slice-provision-models-02 29 Abstract 31 Network slicing is an approach to provide separate virtual network 32 based on service requirements, and it's a key feature of the 5G. 33 3GPP has standardized the specifications for network slicing in the 34 5GS, but there are still some problems for realization of end-to-end 35 network slices. For complementing the lacks or expanding the 36 usability, several organizations are proceeding standardization. 37 However, the definitions and scopes of network slicing vary to some 38 degree from one organization to another. This document provides 39 classification of provisioning models of network slice for clarifying 40 the differences on the definitions and scopes. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on May 6, 2020. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 77 1.1. Roles in Network Slice Provisioning . . . . . . . . . . . 3 78 1.1.1. Definitions in 3GPP on NS Provision Roles . . . . . . 4 79 1.2. High-level Problem Statement . . . . . . . . . . . . . . 5 80 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 81 3. General Requirements for Network Slicing . . . . . . . . . . 8 82 4. Network Slice Structure . . . . . . . . . . . . . . . . . . . 8 83 4.1. Resources for Structuring Network Slices . . . . . . . . 9 84 4.2. Basic Network Slice Structure . . . . . . . . . . . . . . 12 85 4.3. Stakeholders in the Structuring Network Slices . . . . . 15 86 5. Variations of Network Slice Creation . . . . . . . . . . . . 15 87 5.1. Ready-made Network Slice . . . . . . . . . . . . . . . . 16 88 5.2. Custom-made Network Slice . . . . . . . . . . . . . . . . 16 89 5.3. semi-Custom-made Network Slice . . . . . . . . . . . . . 16 90 6. Network Slice Provision Models . . . . . . . . . . . . . . . 16 91 6.1. Categorization of NS Provision Models . . . . . . . . . . 16 92 6.1.1. SaaS-like Model . . . . . . . . . . . . . . . . . . . 17 93 6.1.2. PaaS-like Model . . . . . . . . . . . . . . . . . . . 17 94 6.1.3. IaaS-like Model . . . . . . . . . . . . . . . . . . . 17 95 6.2. Mapping of NS Provision Models and Infrastructure 96 Layering . . . . . . . . . . . . . . . . . . . . . . . . 18 98 6.3. Configurable Parameters/Attributes for NS . . . . . . . . 20 99 6.4. Capability of NS Tenant on each Provision Model . . . . . 20 100 6.4.1. Capability in SaaS-like Model . . . . . . . . . . . . 21 101 6.4.2. Capability in PaaS-like Model . . . . . . . . . . . . 21 102 6.4.3. Capability in IaaS-like Model . . . . . . . . . . . . 21 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 105 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 106 10. Informative References . . . . . . . . . . . . . . . . . . . 22 107 Appendix A. NS Structure in the 3GPP 5GS . . . . . . . . . . . . 23 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 110 1. Introduction and Motivation 112 Network slicing is an approach to provide separate virtual networks 113 depending on requirements of each service. Network slicing receives 114 attention due to factors such as diversity of services and devices, 115 and it is also a fundamental concept of the 5G for applying networks 116 to such various types of requirements. 118 In addition, network slicing is expected to enable a business model 119 to provide dedicated logical networks to 3rd parties or vertical 120 customers on-demand, called NSaaS (Network Slice as a Service). For 121 such usage, in network slicing, provision of networks able to 122 guarantee communication characteristics end to end would be required. 123 However, the definitions are not harmonized over several SDOs 124 (Standards Developing Organizations). 126 This document clarifies provision patterns of network slice, and 127 provides the definitions and scope of network slicing which are 128 available over several organizations. Furthermore, the deliverables 129 would be help for evaluating applicability of existing technologies/ 130 solutions to network slicing. 132 1.1. Roles in Network Slice Provisioning 134 The widespread of system and network virtualization technologies has 135 conducted to new business opportunities, enlarging the offer of IT 136 resources in the form of Network Slices (NS). As a consequence, 137 there is a clear differentiation between the owner of physical 138 resources, the infrastructure operator, and the intermediary that 139 conforms and delivers network services to the final customers, the 140 Virtual Network Operator (VNO). 142 VNOs aim to exploit the virtualized infrastructures to deliver new 143 and improved services to their customers. However, current NS 144 techniques offer poor support for VNOs to control their resources. 145 It has been considered that the infrastructure operator is 146 responsible of the reliability of the NS elements but several 147 situations advocate the VNO to gain a finer control on its resources. 148 For instance, dynamic events, such as the identification of new 149 requirements or the detection of incidents within the virtual system, 150 might urge a VNO to quickly reform its virtual infrastructure and 151 resource allocation. However, the interfaces offered by current 152 virtualization platforms do not offer the necessary functions for 153 VNOs to perform the elastic adaptations they require to tackle with 154 their dynamic operation environments. 156 1.1.1. Definitions in 3GPP on NS Provision Roles 158 3GPP has defined multiple roles related to 5G networks and network 159 slicing management in [TS.28.540-3GPP] and they include: 161 o Communication Service Customer (CSC): Uses communication services, 162 e.g. end user, tenant, vertical 164 o Communication Service Provider (CSP): Provides communication 165 services. Designs, builds and operates its communication 166 services. The CSP provided communication service can be built 167 with or without network slice. 169 o Network Operator (NOP): Provides network services. Designs, 170 builds and operates its networks to offer such services. 172 o Network Equipment Provider (NEP): Supplies network equipment to 173 network. For sake of simplicity, VNF Supplier is considered here 174 as a type of Network Equipment Provider. This can be provided 175 also in the f orm of one or more appropriate VNF(s). 177 o Virtualization Infrastructure Service Provider (VISP): Provides 178 virtualized infrastructure services. Designs, builds and operates 179 its virtualization infrastructure(s). Virtualization 180 Infrastructure Service Providers may also offer their virtualized 181 infrastructure services to other types of customers including to 182 Communication Service Providers directly, i.e. without going 183 through the Network Operator. 185 o Data Centre Service Provider (DCSP): Provides data centre 186 services. Designs, builds and operates its data centres. 188 o NFVI Supplier: Supplies network function virtualization 189 infrastructure to its customers. 191 o Hardware Supplier: Supplies hardware. 193 In case of Network Slice as a Service (NSaaS), the Communication 194 Service Provider (CSP) role can be refined into Network Slice 195 Provider (NSP). The Communication Service Customer (CSC) role can be 196 refined into Network Slice Customer (NSC). A NSC can, in turn, offer 197 its own communication services to its own customers, being thus CSP 198 at the same time. 200 1.2. High-level Problem Statement 202 Beyond their heterogeneity, which can be resolved by software 203 adapters, NS platforms do not offer common methods and functions, so 204 it is difficult for the virtual network controllers used by the VNOs 205 to actually manage and control virtual resources instantiated on 206 different platforms, not even considering different infrastructure 207 operators. Therefore, it is necessary to reach a common definition 208 of the functions that should be offered by underlying platforms to 209 enable such overlay controllers with the possibility of allocate and 210 deallocate resources dynamically and get monitoring data about them. 212 Such common methods should be offered by all underlying controllers, 213 regardless of being network-oriented (e.g., ODL, ONOS, Ryu) or 214 computing-oriented (e.g., OpenStack, OpenNebula, Eucalyptus). 215 Furthermore, it is also important for those platforms to offer some 216 "PUSH" function to report resource state, avoiding the need for the 217 VNO's controller to "POLL" for such data. A starting point to get 218 proper notifications within current REST APIs could be to consider 219 the protocol proposed by the [WEBPUSH-WG]. 221 Finally, in order to establish a proper order and allow the 222 coexistence and collaboration of different systems, a common ontology 223 regarding network and system virtualization should be defined and 224 agreed, so different and heterogeneous systems can understand each 225 other without requiring to rely on specific adaptation mechanisms 226 that might break with any update on any side of the relation. 228 2. Definition of Terms 230 This section lists definitions and terms related to network slicing. 231 This document refers terms and view points on network slicing in some 232 SDOs, such as 3GPP([TS.23.501-3GPP], [TS.28.530-3GPP], 233 [TS.28.540-3GPP], [TR.28.801-3GPP]and [TR.28.804-3GPP]), and NGMN 234 ([NGMN-5G-White-Paper]). However the scope of this document is not 235 network slicing which is mobile specific but one for general 236 networks, and thus some of definitions in this document may be 237 different from ones of those documents. 239 Network Slicing: Network slicing indicates a technology, an 240 approach, or a concept to create logical separate networks in 241 support of services, depending on several requirements, on the 242 same physical resources. This is possible by combinations of 243 several network technologies. 245 Network Slice (NS): An NS is a logical separate network that 246 provides specific network capabilities and characteristics. In 247 3GPP definitions, an NS potentially includes both data plane and 248 control plane resources/functions. An NS can have multiple 249 network slice subnets (Radio Access Network/RAN, Transport 250 Network/TN, Core Network/CN, etc.). 252 Network Slice Instance (NSI): An NSI is a logical network instance 253 composed with required infrastructure resources, including 254 networking (WAN), computing (NFVI) resources, and some include 255 additional network service functions such as firewall or load- 256 balancer. It is composed of one or more Network Slice Subnet 257 Instances. 259 Network Slice Subnet: A Network Slice Subnet is a representation of 260 a set of required resources. It is composed and managed as a 261 group of network elements. 263 Network Slice Subnet Instance (NSSI): An NSSI is a partial logical 264 network instance represented as a network slicce instance. It is 265 a minimul unit managed or provided as a network slice. One or 266 more NSSI structure an NSI or an E2E-NSI. 268 End-to-End Network Slice Instance (E2E-NSI): An E2E-NSI is a virtual 269 network connecting among end points. It is composed of one or 270 multiple NSSIs. This term is original of this document and is 271 used when it should be emphasized that the target NSI provides 272 connectivity from end to end. As an example, for providing an 273 E2E-NSI on the 3GPP 5G network, combining three types of NSIs: 274 RAN-, TRN-, and CN-NSIs would be required. 276 Transport Network(TN)-NSSI: A set of connections between various 277 network functions (VNF or PNF) with deterministic SLAs. They can 278 be implemented (aka realized) with various technologies (e.g. IP, 279 Optics, FN, Microwave) and various transport (e.g. RSVP, Segment 280 routing, ODU, OCH etc). The overview of NSI composed with TRN- 281 NSSI is shown in Appendix A. 283 Radio Access Network(RAN)-NSSI: Regardless of RAN deployment (e.g. 284 distributed-RAN, Centralized-RAN or Cloud-RAN, a RAN-NSSI creates 285 a dedicate and logical resource on RAN for each NSI which are 286 completely. The overview of NSI composed with RAN-NSSI is shown 287 in Appendix A. 289 Core Network(CN)-NSSI: Regardless of Core deployment, a CN-NSI 290 creates a dedicate and logical resource on Core network for each 291 NSI which are completely. The overview of NSI composed with CN- 292 NSSI is shown in Appendix A. 294 Network Slice as a Service (NSaaS): An NSaaS is a service delivery 295 model in which a third-party provider or a vertical customer hosts 296 NSIs and makes them available to customers. In this model, there 297 mainly two roles: NS provider and NS tenant. 299 Network Slice Provider (NS Provider): An NS provider is a person or 300 group that designs and instantiates one or more NSIs/NSSIs, and 301 provides them to NS tenants. In some cases, an NS provider is an 302 infrastructure operator simultaneously. This includes NSI, NSSI, 303 and E2E-NSI providers. 305 Network Slice Tenant (NS Tenant): An NS tenant is a person or group 306 that rents and occupies NSIs from NS providers. 308 Network Slice Stakeholder (NS Stakeholder): An NS stakeholder is an 309 actor in network slicing, and has roles of either NS provider or 310 tenant. 312 Infrastructure Operator: An infrastructure operator is an 313 organization who manages infrastructure networks or data centers 314 for running NSIs. In the most of cases, infrastructure operators 315 are initial NS providers on NSaaS. Also, some of them may be NS 316 tenants simultaneously. 318 Vertical Customer: A vertical customer is a organization who 319 provides some communicating services with using NSIs on NSaaS 320 model. In many cases, a vertical customer become the final NS 321 tenant on NSaaS. For example, video gaming companies or vehicle 322 vendors will possibly be vertical customers. 324 Virtual Network Operator (VNO): A VNO is a person or group that 325 operates virtual networks composed with resources or NSSIs rent 326 from infrastructure operators and provides such virtual networks 327 as NSIs to vertical customers who are final NS tenants. In some 328 cases, infrastructure operators have this role in addition to 329 operating their own infrastructure simultaneously. 331 Domain: A domain is a group of a network and devices administrated 332 under a policy-based common set of rules and procedures. 334 Resource: A resource is an element used to create virtual networks. 335 There are several types of resources, i.e., connectivity, 336 computing and storage. The details are described Section 4.1 338 Virtual Network: A virtual network is a network running a number of 339 virtual network functions. 341 Virtual Network Function (VNF): A virtual network function (VNF) is 342 a network function whose functional software is decoupled from 343 hardware. One or more VNFs run as different software and 344 processes on top of industry-standard high-volume servers, 345 switches and storage, or cloud computing infrastructure. They are 346 capable of implementing network functions traditionally 347 implemented via custom hardware appliances and middleboxes (e.g., 348 router, NAT, firewall, load balancer, etc.). 350 Network Operation System: A network operation system is an entity or 351 a group of entities for operating network nodes and functions as 352 compositions of infrastructure network. For example, OSS/BSS, 353 orchestrator, and EMS are considered to be network operation 354 systems. 356 3. General Requirements for Network Slicing 358 On network slice operations, capabilities for dynamic instantiation, 359 change, and deletion should be required because an NSI is established 360 based on received orders from tenants in NSaaS. From this aspect, 361 some mechanisms to design a network based on service requirements and 362 to convert those to concrete configurations based on the design would 363 be required. 365 In addition, each NS has to maintain concrete communication 366 characteristics end to end, and resource reservations on data plane 367 and isolation among NSIs would be required. Isolation is a concept 368 to prevent the reduction of communication quality caused by 369 disturbance from other NSs, and it may have some levels of 370 enforcement, such as hard or soft isolations. In some cases, for 371 providing appropriate communication between client and server, it 372 would be allowed for NS tenants to put their applications as contents 373 server on NSIs by using computing resources. 375 The required agility of slice operation and granularity of end to end 376 communication quality requested can vary depending on provision 377 model. 379 4. Network Slice Structure 381 This section describes resources used for structuring NSs and the 382 basic structure of E2E-NS. 384 4.1. Resources for Structuring Network Slices 386 A network slice is structured as combinations of the resources it 387 uses. Such resources are mainly categorized into three classes: 388 network/WAN, computing/NFVI, and functionality resources. Variations 389 of each resources are described below. (Note that the lists are not 390 exhaustive.) 392 Network(WAN) Resources: 394 * Connectivity: 396 + (v)Link 398 - Bandwidth per link/session 400 - Connected area/end points 402 - Forwarding route/path (e.g., for traffic engineering, 403 redundancy) 405 - Communication Priority (e.g., QoS class) 407 - Range of jitter amount 409 + Interface of vNode 411 - QoS setting (e.g., Queue size, DSCP remarking, PIR/CIR) 413 - Filter setting 415 + vRouter/vSwitch (# Treated as a set of (v)links and 416 interfaces of vNodes.) 418 * Multicast support 420 * Encryption support 422 * Authentication support 424 * Metadata conveyance (e.g., subscriber ID) 426 * Protocols for slice data plane: 428 + VLAN 430 + IPoE (IPv4 or IPv6) 431 + MAP-E 433 + DS-Lite 435 + PPPoE 437 + L2TP 439 + GRE 441 + MPLS 443 + VxLAN 445 + Geneve 447 + GTP-U 449 + Segment Routing MPLS 451 + Segment Routing IPv6 453 + NSH 455 + FlexE 457 + Other 459 Computing(NFVI) Resources: 461 * (v)CPU core 463 * Storage 465 * Memory 467 * Disk 469 * vNIC 471 * Connectivity to VNF instances 473 * Virtual Deployment Unit: 475 + Virtual Machine (VM) 477 + container 478 + micro kernel 480 * Resource Deployment Location (i.e., edge DC, central DC, public 481 cloud, ..., etc.) 483 Functionality Resources: 485 * Image: 487 + Data Plane(DP) NF: 489 - GateWay(GW) function: 491 o Access Point Type (e.g., for radio, Wi-Fi, and fixed 492 accesses) 494 o Slice Selection Setting 496 o Terminate protocol 498 o Authentication 500 - Security Appliance: 502 o IPS (Intrusion Prevention System) 504 o IDS (Intrusion Detection System) 506 o WAF (Web Application Firewall) 508 - DPI 510 - Load Balancer 512 - TCP Accelerator 514 - Video Optimizer 516 - Parental Control 518 - Mobile DP functions (Ref. 3GPP 5GS) 520 gNB 522 UPF 524 Uplink Classifier 526 + Control Plane(CP) NF: 528 - DHCP 530 o Fixed IP address allocation 532 o Dynamic IP address allocation 534 o The number of registered devices 536 - DNS 538 - VoIP (SBC, SIP server) 540 - Mobile CP function (Ref. 3GPP 5GS) 542 o AMF (Access and Mobility management Function) 544 o SMF (Session Management Function) 546 o PCF (Policy Control Function) 548 o UDM (Unified Data Management) 550 o NEF (Network Exposure Function) 552 * Provided VNF Type (e.g., open source, product of vender#A, ..., 553 etc.) 555 * Function location (e.g., edge DC, central DC, Public cloud, 556 etc.) 558 In terms of security or usability for NS tenants, some abstraction on 559 resource information would be required, however both setting 560 parameters of underlay infrastructure and abstracted information may 561 coexist in these lists. 563 For abstraction of parameters of underlay networks, some additional 564 protocols or functions (like [RFC8453] ) would be required. 565 Moreover, for providing strict communication qualities, combinations 566 of some technologies may be useful (ref. 567 [I-D.dong-teas-enhanced-vpn]). 569 4.2. Basic Network Slice Structure 571 An E2E-NSI is constructed by stitching NSSIs instantiated on each 572 participating domain. This includes the simplest case of a single 573 NSSI as an E2E NS. Domain types where some NSSIs are established are 574 described below: 576 o Fixed access network 578 o Mobile access network 580 o Transport network 582 o Fixed core network 584 o Mobile core network 586 o Data center (DC) 588 * Edge DC 590 * Central DC 592 o Private network 594 * Enterprise 596 * Factory 598 * Utilities 600 * Farming 602 * Home/SOHO 604 * Other 606 Figure 1 describes the overview of this structure. Resources in each 607 domain (e.g., access, core networks, and DC) are handled by 608 management entities and constitute an NSSI. An E2E-NSI is 609 established by stitching these NSSIs. Ways to stitch NS-subnets are 610 described in [I-D.defoy-coms-subnet-interconnection] and 611 [I-D.homma-nfvrg-slice-gateway]. 613 ___________________________________________ 614 / / 615 /__________________________________________/ 616 E2E-NSI 617 A A A 618 | | | 619 ____________ ___________ ______________ 620 / / / / / / 621 /___________/ /__________/ /_____________/ 622 NSSI#1 NSSI#2 NSSI#3 623 A A A 624 | | | 626 o---o [PNF] /----[VM] 627 / `--. / `----. /----[VM] 628 o---o-----o...o---------o...o---o----[VM] 630 NW Rsrc#1 NW Rsrc+PNF NW+CMP Rsrcs 631 A A A 632 | | | 634 ,-------. ,-------. ,----------. 635 / Access \ / Core \ / \ 636 | Network |-TN-| Network |-TN-| DC Domain | 637 \ Domain / \ Domain / \ / 638 `-------' `--------' `----------' 640 *Legends 641 NW Rsrc : Network Resource 642 CMP Rsrc: Computing Resource 643 o : virtual/physical node structuring NSI 644 -- : virtual/physical link structuring NSI 645 -TN-: Transport Network 646 [PNF]: Physical Network Function Appliance on NSI 647 [VM] : Virtual Machine Instance on NSI 649 Figure 1: Overview of NS Structure 651 Although it is shown that an NSSI belongs to just only one E2E-NSI in 652 Figure 1, it may be allowed that multiple E2E-NSIs share an NSSI. 653 Some resources may belong to multiple NSSI as well. 655 In addition, structure on composition of NSI may be recursive. In 656 other words, even though Figure 1 shows a case where NSSIs compose 657 directly an E2E-NSI, in some cases, NSSIs compose an NSI which is a 658 part of an E2E-NSI. The overview is shown in Figure 2. In this 659 figure, NSI#4 is composed of NSSI#1 and NSSI#2, and it structures 660 E2E-NSI#5 with NSSI#3. 662 ___________________________________________ 663 / / 664 /__________________________________________/ 665 E2E-NSI#5 666 A A 667 | | 668 ___________________________ | 669 / / | 670 /__________________________/ | 671 NSI#4 (= NSSI#1 + NSSI#2) | 672 A A | 673 | | | 674 ____________ ___________ _____________ 675 / / / / / / 676 /___________/ /__________/ /____________/ 677 NSSI#1 NSSI#2 NSSI#3 679 Figure 2: Overview of NS recursive structure 681 4.3. Stakeholders in the Structuring Network Slices 683 Potential stakeholders in network slicing are described below: 685 o NSSI provider: infrastructure operator 687 o Intermediate-NSI provider: infrastructure operator, VNO 689 o E2E-NSI provider: infrastructure operator, VNO, service provider 691 o NS tenant: infrastructure operator, VNO, service provider, 692 enterprise, mass user 694 o End customer: enterprise, mass user, etc. 696 5. Variations of Network Slice Creation 698 NSs can be classified according to their creation pattern into two 699 types: ready-made(RM) NS, custom-made(CM), and semi-custom-made(sCM) 700 NS. This section describes the features of these types. 702 5.1. Ready-made Network Slice 704 RM-NS is an NS creation pattern in which an infrastructure operator 705 decides service requirements by itself, and established based on the 706 requirements in advance. NS tenants select one of RM-NSs whose 707 features are closer to their requirements. 709 This model doesn't need immediacy on designing of NSI and enables to 710 mitigate the difficulty of implementation compared with other models. 712 5.2. Custom-made Network Slice 714 CM-NS is an NS creation pattern in which an NS is established based 715 on an order from a tenant and is provided to it. As examples of 716 usage of CM-NS, an enterprise builds and operates a virtual private 717 network for connecting several bases, or OTT (Over The Top) or other 718 industrial service providers create NSs based on their own 719 requirements and use them as a part of their own services (e.g., 720 connected vehicles/drones, online video games, or remote surgery). 722 In this model, network operation system would be required to have 723 incorporate intelligence for designing appropriate NSs on-demand. 725 5.3. semi-Custom-made Network Slice 727 sCM-NS is a derivation of a CM-NS. In sCM-NS, an NS provider designs 728 the outline of NSs in advance, and a tenant tunes an NS with deciding 729 some parameters or applications run on resources. For example, an 730 infrastructure operator designs a logical network presenting 731 connectivity, and tenants install their own applications on servers 732 running on the logical network. 734 6. Network Slice Provision Models 736 This document classifis NS provision models into three categories 737 defined in the following section. The capabilities which NS tenants 738 can have on management of NSs would vary depending on the selected 739 provision model. 741 6.1. Categorization of NS Provision Models 743 The provision models are categorized into three models: SaaS 744 (Software as a Service) -like Model, PaaS (Platform as a Service) 745 -like Model, and IaaS (Infrastructure as a Service) -like Model. 747 6.1.1. SaaS-like Model 749 In SaaS-like Model, underlay infrastructure is hidden from tenants, 750 and tenants can receive desired communication environment without 751 deep knowledge about network and servers. An NS tenant decides 752 attribute values of its NS, such as bandwidth or latency, based on 753 their requirements, and NS providers design and create NSIs which 754 fulfill the values. 756 NS tenants need not to grasp detailed configurations in underlay 757 networks in this model. However, it may not be possible to provide 758 strictly desired NS to tenants because of abstruction of configurable 759 parameters. Moreover, it may cause complexity on designing NS 760 catalog due to quantities of selected attributes. 762 6.1.2. PaaS-like Model 764 In PaaS-like Model, an NS is represented with several components such 765 as nodes and connectivities among them. An NS tenant can design and 766 customize its desired NS with combining such components. NS 767 providers breakdown the NS designed by the NS tenant to concrete 768 configurations of their infrastructure, and create/change NSSIs by 769 inputting the configurations. An NS tenant is also able to 770 incorporate its own functions or applications into its NSI by using 771 computing resources provided from NS providers. 773 This model potentially has high customizability of NS rather than 774 SaaS-like model, but needs NS tenants to have some knowledge about 775 network management. In terms of designing NS, the tenants provide 776 outline of their NSs, and thus it would make creation of concrete 777 configurations be easier. 779 6.1.3. IaaS-like Model 781 In IaaS-like model, an NS is represented with concrete configurations 782 of underlay infrastructure. NS tenants are able to structure or 783 change their desired NS by controlling infrastructure resources 784 directly. 786 This model potentially has high customizability of NS rather than 787 other models, but needs NS tenants to have deep knowledge about 788 network and server operation. Also, NS providers need not to 789 recognize NSs on their infrastructure because NS tenants directly 790 manage their NS. Meanwhile, in terms of security and prevention of 791 disturbances among NSs, some limitations on expositions of resources 792 to tenants would be needed. 794 6.2. Mapping of NS Provision Models and Infrastructure Layering 796 An example of mapping of each NS provision model is shown in 797 Figure 3. 799 manage 800 [NS Tenant] ---------------------------+ 801 | 802 | 803 . . . . . . . . . . . . . . . . . . . . . . . . | 804 *Service Layer | 805 .--. | 806 .------. ( )-. | 807 | Area#A |<==== Connectivity ====> .' [APL] ' SaaS-like| 808 `------' [BW:100Mbps, Delay<10ms]( ) <---------+ 809 .------. ( [APL] -' | 810 | Area#B |<==== Connectivity ====> '-( ) | 811 `------' [BW:100Mbps, Delay<10ms] '---' | 812 Virtual Private | 813 Cloud | 814 . . . . . . . . . . . . . . . . . . . . . . . . | 815 *NS Layer | 816 __________________________________ | 817 / / | 818 / [AP]----o / PaaS-like| 819 / / `--. /---[VM] / <---------+ 820 / [AP]---o-----o--[FW]--[VM] / | 821 /_________________________________/ | 822 NSI | 823 . . . . . . . . . . . . . . . . . . . . . . . . | 824 *Infra Layer | 825 | 826 | 827 [AP]----o /---[SV] | 828 / `--. /---[SV] IaaS-like| 829 [AP]---o-----o--[FW]--[SV] <---------+ 830 .---' /---[SV] 831 [AP]----' 833 *Legends 834 o : virtual/physical node 835 -- : virtual/physical link 836 [AP] : Access point 837 [APL]: Application owned by NS Tenant 838 [FW] : Firewall Function 839 [VM] : Virtual Machine Instance on Sever 840 [SV] : Server as Infrastructure 842 Figure 3: Mapping of NS provision models 844 In some cases, NSIs provided based on IaaS- or PaaS-like models are 845 coordinated to a form of SaaS-like model by an NS broker , and the NS 846 broker or by the tenant, becoming a NS provider in a recursive 847 manner. For example, a vertical customer sends its high-level 848 requirements to an NS broker create an appropriate NSI with resources 849 provided by infrastructure operators. 851 6.3. Configurable Parameters/Attributes for NS 853 In the NS creating procedure, configuration parameters are decided 854 based on requirements which the intended service has. Such service 855 requirements are expressible in the following attribute values. 857 o Attributes for Network Resource 859 * bandwidth 861 * latency 863 * jitter 865 * packet loss rate 867 * reliability (e.g., MTBF, MTTF) 869 o Attributes for Functionalities Resources 871 * function type (e.g., security, parental control) 873 * throughput 875 * packet error rate 877 * availability 879 Configurable parameters of components in underlay infrastructure will 880 vary depending on the implementation and structure. Controlled 881 resource types are described in Section 4.1. 883 6.4. Capability of NS Tenant on each Provision Model 885 Capability of NS tenants on NS management would vary depending on the 886 NS provision model. This section describes clarification about such 887 capability in each model. 889 6.4.1. Capability in SaaS-like Model 891 In SaaS-like Model, an NS is represented for a tenant with attributes 892 values listed in Section 6.3. In other words, an NS tenant never 893 know the concrete configurations of components in underlay 894 infrastructure. 896 An NS tenant chooses a value from the range presented by the NS 897 provider in each attribute. The NS provider creates or changes a NS 898 by configuraing components in underlay infrastructures based on the 899 decided attribute values. 901 In terms of telemetry for assurance of service qualities on a NS, a 902 tenant can obtain telemetry information with unit of NSI, and never 903 know ones of underlay components structuring the NS. 905 6.4.2. Capability in PaaS-like Model 907 In PaaS-like model, an NS is represented with NF nodes and their 908 connectivities. An NS tenant can indicate functionalities of NF 909 nodes and thier locations. Also, the tenant decides attribute values 910 of connectivities. An NS provider creates or changes an NSI by 911 configuring underlay nodes and links depending on the indication of 912 the tenant. An NS tenant is also able to deploy its own NF as 913 software with provided computing resources. 915 In terms of telemetry, an NS tenant can obtain telemetry information 916 of NF nodes and connectivities structuring an NS, in addition to 917 whole of NSI. 919 6.4.3. Capability in IaaS-like Model 921 In IaaS-like Model, an NS is represented with configurations of 922 (virtual) nodes and (virtual) links connecting the nodes. An NS 923 tenant is able to configure nodes and links in underlay 924 infrastructure. In short, an NS tenant directly design detailed NS 925 and manages it. In addition, an NS tenant inserts its own functions 926 or applications in the NS with using computing resources. 928 In terms of telemetry, an NS tenant can obtain telemetry information 929 of nodes and links in addition of whole of NSI. 931 7. Security Considerations 933 In NSaaS, parts of controls of infrastructures are opened to 934 externals, and thus some mechanisms, such as authentication for APIs, 935 to prevent illegal access would be required. 937 Other considerations are TBD 939 8. IANA Considerations 941 This memo includes no request to IANA. 943 9. Acknowledgement 945 The author would like to thank Toru Okugawa for his kind review and 946 valuable feedback. 948 10. Informative References 950 [I-D.defoy-coms-subnet-interconnection] 951 Foy, X., Rahman, A., Galis, A., 952 kiran.makhijani@huawei.com, k., and L. Qiang, 953 "Interconnecting (or Stitching) Network Slice Subnets", 954 draft-defoy-coms-subnet-interconnection-01 (work in 955 progress), October 2017. 957 [I-D.dong-teas-enhanced-vpn] 958 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 959 Framework for Enhanced Virtual Private Networks (VPN+) 960 Service", draft-dong-teas-enhanced-vpn-03 (work in 961 progress), November 2018. 963 [I-D.homma-nfvrg-slice-gateway] 964 Homma, S., Foy, X., and A. Galis, "Gateway Function for 965 Network Slicing", draft-homma-nfvrg-slice-gateway-00 (work 966 in progress), July 2018. 968 [NGMN-5G-White-Paper] 969 NGMN, "NGMN 5G White Paper", February 2015, 970 . 972 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 973 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 974 DOI 10.17487/RFC8453, August 2018, 975 . 977 [TR.28.801-3GPP] 978 3rd Generation Partnership Project (3GPP), "3GPP TR 28.801 979 (V15.1.0): Study on Management and Orchestration of 980 Network Slicing for next generation network (Release 15)", 981 June 2018, . 984 [TR.28.804-3GPP] 985 3rd Generation Partnership Project (3GPP), "3GPP TR 28.804 986 (V16.1.0): Study on tenancy concept in 5G networks and 987 network slicing management (Release 16)", October 2019, 988 . 991 [TS.23.501-3GPP] 992 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 993 (V16.0.0): System Architecture for 5G System; Stage 2", 994 September 2018, . 997 [TS.28.530-3GPP] 998 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 999 (V1.0.0): Management and orchestration of networks and 1000 network slicing; Concepts, use cases and requirements 1001 (work in progress)", June 2018, 1002 . 1005 [TS.28.540-3GPP] 1006 3rd Generation Partnership Project (3GPP), "3GPP TS 28.540 1007 (V16.0.0): 5G Netowkr Resource Model (NRM); Stage 1008 1(Release 16)", June 2019, 1009 . 1012 [TS.28.541-3GPP] 1013 3rd Generation Partnership Project (3GPP), "3GPP TS 28.541 1014 (V15.1.0): 5G Netowkr Resource Model (NRM); Stage 2 and 1015 stage 3 (Release 15)", June 2018, 1016 . 1019 [WEBPUSH-WG] 1020 IETF, "Web-Based Push Notifications(webpush)", 1021 . 1023 Appendix A. NS Structure in the 3GPP 5GS 1025 The overview of structure of NS in the 3GPP 5GS is shown in Figure 4. 1026 The terms are described in the 3GPP documents (e.g., [TS.23.501-3GPP] 1027 and [TS.28.530-3GPP]). 1029 <================== E2E-NSI =======================> 1030 : : : : : 1031 : : : : : 1032 <====== RAN-NSSI ======><= TN-NSSI=><====== CN-NSSI ======>VL[APL] 1033 : : : : : : : : : 1034 : : : : : : : : : 1035 RW[NFs ]<= TN-NSSI=>[NFs ]<= TN-NSSI=>[NFs ]<= TN-NSSI=>[NFs ]VL[APL] 1037 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 1038 .,----. ,----. ,----.. ,----. .,----. ,----. ,----.. 1039 UE--|RAN |---| TN |---|RAN |---| TN |---|CN |---| TN |---|CN |--[APL] 1040 .|NFs | `----' |NFs |. `----' .|NFs | `----' |NFs |. 1041 .`----' `----'. .`----' `----'. 1042 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 1044 RW RAN MBH CN DN 1046 *Legends 1047 UE: User Equipment 1048 RAN: Radio Access Network 1049 CN: Core Network 1050 DN: Data Network 1051 TN: Transport Network 1052 MBH: Mobile Backhaul 1053 RW: Radio Wave 1054 NF: Network Function 1055 APL: Application Server 1057 Figure 4: Overview of Structure of NS in 3GPP 5GS 1059 Authors' Addresses 1061 Shunsuke Homma 1062 NTT 1063 Japan 1065 Email: shunsuke.homma.fp@hco.ntt.co.jp 1067 Hidetaka Nishihara 1068 NTT 1069 Japan 1071 Email: nishihara.hidetaka@lab.ntt.co.jp 1072 Takuya Miyasaka 1073 KDDI Research 1074 Japan 1076 Email: ta-miyasaka@kddi-research.jp 1078 Alex Galis 1079 University College London 1080 UK 1082 Email: a.galis@ucl.ac.uk 1084 Vishnu Ram OV 1085 Independent Research Consultant India 1086 India 1088 Email: vishnu.u@ieee.org 1090 Diego R. Lopez 1091 Telefonica I+D 1092 Spain 1094 Email: diego.r.lopez@telefonica.com 1096 Luis M. Contreras 1097 Telefonica I+D 1098 Spain 1100 Email: luismiguel.contrerasmurillo@telefonica.com 1102 Jose A. Ordonez-Lucena 1103 Telefonica I+D 1104 Spain 1106 Email: joseantonio.ordonezlucena@telefonica.com 1108 Pedro Martinez-Julia 1109 NICT 1110 Japan 1112 Email: pedro@nict.go.jp 1113 Li Qiang 1114 Huawei Technologies 1115 China 1117 Email: qiangli3@huawei.com 1119 Reza Rokui 1120 Nokia 1121 Canada 1123 Email: reza.rokui@nokia.com 1125 Laurent Ciavaglia 1126 Nokia 1127 France 1129 Email: Laurent.ciavaglia@nokia.com 1131 Xavier de Foy 1132 InterDigital Inc. 1133 Canada 1135 Email: Xavier.Defoy@InterDigital.com