idnits 2.17.1 draft-homma-slice-provision-models-01.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 (July 8, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PNF' is mentioned on line 619, but not defined == Missing Reference: 'VM' is mentioned on line 851, but not defined == Missing Reference: 'APL' is mentioned on line 953, but not defined == Missing Reference: 'AP' is mentioned on line 848, but not defined == Missing Reference: 'FW' is mentioned on line 850, but not defined == Missing Reference: 'SV' is mentioned on line 852, 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: January 9, 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 L. Contreras-Murillo 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 July 8, 2019 26 Network Slice Provision Models 27 draft-homma-slice-provision-models-01 29 Abstract 31 Network slicing is an approach to provide separate virtual network 32 based on service requirements. It's a fundamental concept of the 5G, 33 and the architecture and specification is under standardization in 34 several organizations. However, the definitions and scopes of 35 network slicing vary to some degree from one organization to another. 36 This document provides classification of provisioning models of 37 network slice for clarifying the differences on the definitions and 38 scopes. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on January 9, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 75 1.1. Differentiated Roles in Network Slice Provisioning . . . 3 76 1.2. High-level Problem Statement . . . . . . . . . . . . . . 4 77 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 78 3. General Requirements for Network Slicing . . . . . . . . . . 7 79 3.1. Requirements/Attributes for Network Slice . . . . . . . . 7 80 4. Network Slice Structure . . . . . . . . . . . . . . . . . . . 8 81 4.1. Resources for Structuring Network Slices . . . . . . . . 8 82 4.2. Basic Network Slice Structure . . . . . . . . . . . . . . 12 83 4.3. Stakeholders in the Structuring Network Slices . . . . . 14 84 5. Variations of Network Slice Creation . . . . . . . . . . . . 15 85 5.1. Ready-made Network Slice . . . . . . . . . . . . . . . . 15 86 5.2. Custom-made Network Slice . . . . . . . . . . . . . . . . 15 87 5.3. semi-Custom-made Network Slice . . . . . . . . . . . . . 15 88 6. Network Slice Provision Models . . . . . . . . . . . . . . . 15 89 6.1. SaaS-like Model . . . . . . . . . . . . . . . . . . . . . 16 90 6.1.1. Capability in SaaS-like Model . . . . . . . . . . . . 16 91 6.2. PaaS-like Model . . . . . . . . . . . . . . . . . . . . . 16 92 6.2.1. Capability in PaaS-like Model . . . . . . . . . . . . 17 93 6.3. IaaS-like Model . . . . . . . . . . . . . . . . . . . . . 17 94 6.3.1. Capability in IaaS-like Model . . . . . . . . . . . . 17 95 6.4. Mapping of NS Provision Models and Infrastructure 96 Layering . . . . . . . . . . . . . . . . . . . . . . . . 17 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 99 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 100 10. Informative References . . . . . . . . . . . . . . . . . . . 19 101 Appendix A. NS Structure in the 3GPP 5GS . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction and Motivation 106 Network slicing is an approach to provide separate virtual networks 107 depending on requirements of each service. Network slicing receives 108 attention due to factors such as diversity of services and devices, 109 and it is also a fundamental concept of the 5G for applying networks 110 to such various types of requirements. 112 In addition, network slicing is expected to enable a business model 113 to provide dedicated logical networks to 3rd parties or vertical 114 customers on-demand, called NSaaS (Network Slice as a Service). For 115 such usage, in network slicing, provision of networks able to 116 guarantee communication characteristics end to end would be required. 117 However, the definitions are not harmonized over several SDOs 118 (Standards Developing Organizations). 120 This document clarifies provision patterns of network slice, and 121 provides the definitions and scope of network slicing which are 122 available over several organizations. Furthermore, the deliverables 123 would be help for evaluating applicabilities of existing 124 technologies/solutions to network slicing. 126 1.1. Differentiated Roles in Network Slice Provisioning 128 The widespread of system and network virtualization technologies has 129 conducted to new business opportunities, enlarging the offer of IT 130 resources in the form of Network Slices (NS). As a consequence, 131 there is a clear differentiation between the owner of physical 132 resources, the infrastructure operator, and the intermediary that 133 conforms and delivers network services to the final customers, the 134 Virtual Network Operator (VNO). 136 VNOs aim to exploit the virtualized infrastructures to deliver new 137 and improved services to their customers. However, current NS 138 techniques offer poor support for VNOs to control their resources. 139 It has been considered that the infrastructure operator is 140 responsible of the reliability of the NS elements but several 141 situations advocate the VNO to gain a finer control on its resources. 142 For instance, dynamic events, such as the identification of new 143 requirements or the detection of incidents within the virtual system, 144 might urge a VNO to quickly reform its virtual infrastructure and 145 resource allocation. However, the interfaces offered by current 146 virtualization platforms do not offer the necessary functions for 147 VNOs to perform the elastic adaptations they require to tackle with 148 their dynamic operation environments. 150 1.2. High-level Problem Statement 152 Beyond their heterogeneity, which can be resolved by software 153 adapters, NS platforms do not offer common methods and functions, so 154 it is difficult for the virtual network controllers used by the VNOs 155 to actually manage and control virtual resources instantiated on 156 different platforms, not even considering different infrastructure 157 operators. Therefore, it is necessary to reach a common definition 158 of the functions that should be offered by underlying platforms to 159 enable such overlay controllers with the possibility of allocate and 160 deallocate resources dynamically and get monitoring data about them. 162 Such common methods should be offered by all underlying controllers, 163 regardless of being network-oriented (e.g., ODL, ONOS, Ryu) or 164 computing-oriented (e.g., OpenStack, OpenNebula, Eucalyptus). 165 Furthermore, it is also important for those platforms to offer some 166 "PUSH" function to report resource state, avoiding the need for the 167 VNO's controller to "POLL" for such data. A starting point to get 168 proper notifications within current REST APIs could be to consider 169 the protocol proposed by the [WEBPUSH-WG]. 171 Finally, in order to establish a proper order and allow the 172 coexistence and collaboration of different systems, a common ontology 173 regarding network and system virtualization should be defined and 174 agreed, so different and heterogeneous systems can understand each 175 other without requiring to rely on specific adaptation mechanisms 176 that might break with any update on any side of the relation. 178 2. Definition of Terms 180 This section lists definitions and terms related to network slicing. 181 This document refers terms and view points on network slicing in some 182 SDOs, such as 3GPP([TS.23.501-3GPP], [TS.28.530-3GPP], and 183 [TS.28.801-3GPP]), and NGMN ([NGMN-5G-White-Paper]). However the 184 scope of this document is not network slicing which is mobile 185 specific but one for general networks, and thus some of definitions 186 in this document may be different from ones of those documents. 188 Network Slicing: Network slicing indicates a technology, an 189 approach, or a concept to create logical separate networks in 190 support of services, depending on several requirements, on the 191 same physical resources. This is possible by combinations of 192 several network technologies. 194 Network Slice (NS): An NS is a logical separate network that 195 provides specific network capabilities and characteristics. In 196 3GPP definitions, an NS potentially includes both data plane and 197 control plane resources/functions. 199 Network Slice Instance (NSI): An NSI is a logical network instance 200 composed with required infrastructure resources, including 201 networking (WAN), computing (NFVI) resources, and some include 202 additional network service functions such as firewall or load- 203 balancer. It is composed of one or more Network Slice Subnet 204 Instances. 206 Network Slice Subnet: A Network Slice Subnet is a representation of 207 a set of required resources. It is composed and managed as a 208 group of network elements. 210 Network Slice Subnet Instance (NSSI): An NSSI is a partial logical 211 network instance represented as a network slicce instance. It is 212 a minimul unit managed or provided as a network slice. One or 213 more NSSI structure an NSI or an E2E-NSI. 215 End-to-End Network Slice Instance (E2E-NSI): An E2E-NSI is a virtual 216 network connecting among end points. It is composed of one or 217 multiple NSSIs. This term is original of this document and is 218 used when it should be emphasized that the target NSI provides 219 connectivity from end to end. As an example, for providing an 220 E2E-NSI on the 3GPP 5G network, combining three types of NSIs: 221 RAN-, TRN-, and CN-NSIs would be required. 223 Transport(TRN)-NSSI: A set of connections between various network 224 functions (VNF or PNF) with deterministic SLAs. They can be 225 implemented (aka realized) with various technologies (e.g. IP, 226 Optics, FN, Microwave) and various transport (e.g. RSVP, Segment 227 routing, ODU, OCH etc). The overview of NSI composed with TRN- 228 NSSI is shown in Appendix A. 230 RAN-NSSI: Regardless of RAN deployment (e.g. distributed-RAN, 231 Centralized-RAN or Cloud-RAN, a RAN-NSSI creates a dedicate and 232 logical resource on RAN for each NSI which are completely. The 233 overview of NSI composed with RAN-NSSI is shown in Appendix A. 235 Core(CN)-NSSI: Regardless of Core deployment, a CN-NSI creates a 236 dedicate and logical resource on Core network for each NSI which 237 are completely. The overview of NSI composed with CN-NSSI is 238 shown in Appendix A. 240 Network Slice as a Service (NSaaS): An NSaaS is a service delivery 241 model in which a third-party provider or a vertical customer hosts 242 NSIs and makes them available to customers. In this model, there 243 mainly two roles: NS provider and NS tenant. 245 Network Slice Provider (NS Provider): An NS provider is a person or 246 group that designs and instantiates one or more NSIs/NSSIs, and 247 provides them to NS tenants. In some cases, an NS provider is an 248 infrastructure operator simultaneously. This includes NSI, NSSI, 249 and E2E-NSI providers. 251 Network Slice Tenant (NS Tenant): An NS tenant is a person or group 252 that rents and occupies NSIs from NS providers. 254 Network Slice Stakeholder (NS Stakeholder): An NS stakeholder is an 255 actor in network slicing, and has roles of either NS provider or 256 tenant. 258 Infrastructure Operator: An infrastructure operator is an 259 organization who manages infrastructure networks or data centers 260 for running NSIs. In the most of cases, infrastructure operators 261 are initial NS providers on NSaaS. Also, some of them may be NS 262 tenants simultaneously. 264 Vertical Customer: A vertical customer is a organization who 265 provides some communicating services with using NSIs on NSaaS 266 model. In many cases, a vertical customer become the final NS 267 tenant on NSaaS. For example, video gaming companies or vehicle 268 vendors will possibly be vertical customers. 270 Virtual Network Operator (VNO): A VNO is a person or group that 271 operates virtual networks composed with resources or NSSIs rent 272 from infrastructure operators and provides such virtual networks 273 as NSIs to vertical customers who are final NS tenants. In some 274 cases, infrastructure operators have this role in addition to 275 operating their own infrastructure simultaneously. 277 Domain: A domain is a group of a network and devices administrated 278 under a policy-based common set of rules and procedures. 280 Resource: A resource is an element used to create virtual networks. 281 There are several types of resources, i.e., connectivity, 282 computing and storage. The details are described Section 4.1 284 Virtual Network: A virtual network is a network running a number of 285 virtual network functions. 287 Virtual Network Function (VNF): A virtual network function (VNF) is 288 a network function whose functional software is decoupled from 289 hardware. One or more VNFs run as different software and 290 processes on top of industry-standard high-volume servers, 291 switches and storage, or cloud computing infrastructure. They are 292 capable of implementing network functions traditionally 293 implemented via custom hardware appliances and middleboxes (e.g., 294 router, NAT, firewall, load balancer, etc.). 296 Network Operation System: A network operation system is an entity or 297 a group of entities for operating network nodes and functions as 298 compositions of infrastructure network. For example, OSS/BSS, 299 orchestrator, and EMS are considered to be network operation 300 systems. 302 3. General Requirements for Network Slicing 304 On network slice operations, capabilities for dynamic instantiation, 305 change, and deletion should be required because an NSI is established 306 based on received orders from tenants in NSaaS. From this aspect, 307 some mechanisms to design a network based on service requirements and 308 to convert those to concrete configurations based on the design would 309 be required. 311 In addition, each NS has to maintain concrete communication 312 characteristics end to end, and resource reservations on data plane 313 and isolation among NSIs would be required. Isolation is a concept 314 to prevent the reduction of communication quality caused by 315 disturbance from other NSs, and it may have some levels of 316 enforcement, such as hard or soft isolations. In some cases, for 317 providing appropriate communication between client and server, it 318 would be allowed for NS tenants to put their applications as contents 319 server on NSIs by using computing resources. 321 The required agility of slice operation and granularity of end to end 322 communication quality requested can vary depending on provision 323 model. 325 3.1. Requirements/Attributes for Network Slice 327 NS tenants will have specific requirements for network slices 328 depending on the usages or service characteristics. Such 329 requirements or the assosiated attributes are broken down into 330 concrete design including network topology and configurations of 331 infrastructure resources, and NS is established based on the design. 332 The requirements or attributes on NSs are listed below: 334 o Requirements/Attributes of Network Resource 336 * bandwidth 337 * latency 339 * jitter 341 * packet loss rate 343 * reliability (e.g., MTBF, MTTF) 345 o Requirements/Attributes of Functionalities Resources 347 * function type (e.g., security, parental control) 349 * throughput 351 * packet error rate 353 * availability 355 4. Network Slice Structure 357 This section describes resources used for structuring NSs and the 358 basic structure of E2E-NS. 360 4.1. Resources for Structuring Network Slices 362 A network slice is structured as combinations of the resources it 363 uses. Such resources are mainly categorized into three classes: 364 network/WAN, computing/NFVI, and functionality resources. Variations 365 of each resources are described below. (Note that the lists are not 366 exhaustive.) 368 Network(WAN) Resources: 370 * Connectivity: 372 + (v)Link 374 - Bandwidth per link/session 376 - Connected area/end points 378 - Forwarding route/path (e.g., for traffic engineering, 379 redundancy) 381 - Communication Priority (e.g., QoS class) 383 - Range of jitter amount 385 + Interface of vNode 387 - QoS setting (e.g., Queue size, DSCP remarking, PIR/CIR) 389 - Filter setting 391 + vRouter/vSwitch (# Treated as a set of (v)links and 392 interfaces of vNodes.) 394 * Multicast support 396 * Encryption support 398 * Authentication support 400 * Metadata conveyance (e.g., subscriber ID) 402 * Protocols for slice data plane: 404 + VLAN 406 + IPoE (IPv4 or IPv6) 408 + MAP-E 410 + DS-Lite 412 + PPPoE 414 + L2TP 416 + GRE 418 + MPLS 420 + VxLAN 422 + Geneve 424 + GTP-U 426 + Segment Routing MPLS 428 + Segment Routing IPv6 430 + NSH 432 + Other 434 Computing(NFVI) Resources: 436 * (v)CPU core 438 * Storage 440 * Memory 442 * Disk 444 * vNIC 446 * Connectivity to VNF instances 448 * Virtual Deployment Unit: 450 + Virtual Machine (VM) 452 + container 454 + micro kernel 456 * Resource Deployment Location (i.e., edge DC, central DC, public 457 cloud, ..., etc.) 459 Functionality Resources: 461 * Image: 463 + Data Plane(DP) NF: 465 - GateWay(GW) function: 467 o Access Point Type (e.g., for radio, Wi-Fi, and fixed 468 accesses) 470 o Slice Selection Setting 472 o Terminate protocol 474 o Authentication 476 - Security Appliance: 478 o IPS (Intrusion Prevention System) 480 o IDS (Intrusion Detection System) 481 o WAF (Web Application Firewall) 483 - DPI 485 - Load Balancer 487 - TCP Accelerator 489 - Video Optimizer 491 - Parental Control 493 - Mobile DP functions (Ref. 3GPP 5GS) 495 gNB 497 UPF 499 Uplink Classifier 501 + Control Plane(CP) NF: 503 - DHCP 505 o Fixed IP address allocation 507 o Dynamic IP address allocation 509 o The number of registered devices 511 - DNS 513 - VoIP (SBC, SIP server) 515 - Mobile CP function (Ref. 3GPP 5GS) 517 o AMF (Access and Mobility management Function) 519 o SMF (Session Management Function) 521 o PCF (Policy Control Function) 523 o UDM (Unified Data Management) 525 o NEF (Network Exposure Function) 527 * Provided VNF Type (e.g., open source, product of vender#A, ..., 528 etc.) 530 * Function location (e.g., edge DC, central DC, Public cloud, 531 etc.) 533 In terms of security or usability for NS tenants, some abstraction on 534 resource information would be required, however both setting 535 parameters of underlay infrastructure and abstracted information may 536 coexist in these lists. 538 For abstraction of parameters of underlay networks, some additional 539 protocols or functions (like [RFC8453] ) would be required. 540 Moreover, for providing strict communication qualities, combinations 541 of some technologies may be useful (ref. 542 [I-D.dong-teas-enhanced-vpn]). 544 4.2. Basic Network Slice Structure 546 An E2E-NSI is constructed by stitching NSSIs instantiated on each 547 participating domain. This includes the simplest case of a single 548 NSSI as an E2E NS. Domain types where some NSSIs are established are 549 described below: 551 o Fixed access network 553 o Mobile access network 555 o Transport network 557 o Fixed core network 559 o Mobile core network 561 o Data center (DC) 563 * Edge DC 565 * Central DC 567 o Private network 569 * Enterprise 571 * Factory 573 * Utilities 575 * Farming 577 * Home/SOHO 578 * Other 580 Figure 1 describes the overview of this structure. Resources in each 581 domain (e.g., access, core networks, and DC) are handled by 582 management entities and constitute an NSSI. An E2E-NSI is 583 established by stitching these NSSIs. Ways to stitch NS-subnets are 584 described in [I-D.defoy-coms-subnet-interconnection] and 585 [I-D.homma-nfvrg-slice-gateway]. 587 ___________________________________________ 588 / / 589 /__________________________________________/ 590 E2E-NSI 591 A A A 592 | | | 594 ____________ ___________ ______________ 595 / / / / / / 596 /___________/ /__________/ /_____________/ 597 NSSI#1 NSSI#2 NSSI#3 598 A A A 599 | | | 601 o---o [PNF] /----[VM] 602 / `--. / `----. /----[VM] 603 o---o-----o...o---------o...o---o----[VM] 604 NW Rsrc#1 NW Rsrc+PNF NW+CMP Rsrcs 605 A A A 606 | | | 608 ,--------. ,--------. ,-----------. 609 / Access \ / Core \ / \ 610 | Network | | Network | | DC Domain | 611 \ Domain / \ Domain / \ / 612 `--------' `--------' `-----------' 614 *Legends 615 NW Rsrc : Network Resource 616 CMP Rsrc: Computing Resource 617 o : virtual/physical node structuring NSI 618 -- : virtual/physical link structuring NSI 619 [PNF]: Physical Network Function Appliance on NSI 620 [VM] : Virtual Machine Instance on NSI 622 Figure 1: Overview of NS Structure 624 Although it is shown that an NSSI belongs to just only one E2E-NSI in 625 Figure 1, it may be allowed that multiple E2E-NSIs share an NSSI. 626 Some resources may belong to multiple NSSI as well. 628 In addition, structure on composition of NSI may be recursive. In 629 other words, even though Figure 1 shows a case where NSSIs compose 630 directly an E2E-NSI, in some cases, NSSIs compose an NSI which is a 631 part of an E2E-NSI. The overview is shown in Figure 2. In this 632 figure, NSI#4 is composed of NSSI#1 and NSSI#2, and it structures 633 E2E-NSI#5 with NSSI#3. 635 ___________________________________________ 636 / / 637 /__________________________________________/ 638 E2E-NSI#5 639 A A 640 | | 641 ___________________________ | 642 / / | 643 /__________________________/ | 644 NSI#4 (= NSSI#1 + NSSI#2) | 645 A A | 646 | | | 647 ____________ ___________ _____________ 648 / / / / / / 649 /___________/ /__________/ /____________/ 650 NSSI#1 NSSI#2 NSSI#3 652 Figure 2: Overview of NS recursive structure 654 4.3. Stakeholders in the Structuring Network Slices 656 Potential stakeholders in network slicing are described below: 658 o NSSI provider: infrastructure operator 660 o Intermediate-NSI provider: infrastructure operator, VNO 662 o E2E-NSI provider: infrastructure operator, VNO, service provider 664 o NS tenant: infrastructure operator, VNO, service provider, 665 enterprise, mass user 667 o End customer: enterprise, mass user, etc. 669 5. Variations of Network Slice Creation 671 NSs can be classified according to their creation pattern into two 672 types: ready-made(RM) NS, custom-made(CM), and semi-custom-made(sCM) 673 NS. This section describes the features of these types. 675 5.1. Ready-made Network Slice 677 RM-NS is an NS creation pattern in which an infrastructure operator 678 decides service requirements by itself, and established based on the 679 requirements in advance. NS tenants select one of RM-NSs whose 680 features are closer to their requirements. 682 This model doesn't need immediacy on designing of NSI and enables to 683 mitigate the difficulty of implementation compared with other models. 685 5.2. Custom-made Network Slice 687 CM-NS is an NS creation pattern in which an NS is established based 688 on an order from a tenant and is provided to it. As examples of 689 usage of CM-NS, an enterprise builds and operates a virtual private 690 network for connecting several bases, or OTT (Over The Top) or other 691 industrial service providers create NSs based on their own 692 requirements and use them as a part of their own services (e.g., 693 connected vehicles/drones, online video games, or remote surgery). 695 In this model, network operation system would be required to have 696 incorporate intelligence for designing appropriate NSs on-demand. 698 5.3. semi-Custom-made Network Slice 700 sCM-NS is a derivation of a CM-NS. In sCM-NS, an NS provider designs 701 the outline of NSs in advance, and a tenant tunes an NS with deciding 702 some parameters or applications run on resources. For example, an 703 infrastructure operator designs a logical network presenting 704 connectivity, and tenants install their own applications on servers 705 running on the logical network. 707 6. Network Slice Provision Models 709 This section classifis NS provision models into three categories 710 defined from aspect that granularity of information exposed to 711 tenants. The provision models are categorized into three models: 712 SaaS (Software as a Service) -like Model, PaaS (Platform as a 713 Service) -like Model, and IaaS (Infrastructure as a Service) -like 714 Model. The capabilities which NS tenants can have on management of 715 NSs would vary depending on the selected provision model. 717 6.1. SaaS-like Model 719 In SaaS-like Model, underlay infrastructure is hidden from tenants, 720 and tenants can receive desired communication environment without 721 deep knowledge about network and servers. An NS tenant decides 722 attribute values of its NS, such as bandwidth or latency, based on 723 their requirements, and NS providers design and create NSIs which 724 fulfill the values. 726 NS tenants need not to grasp detailed configurations in underlay 727 networks in this model. However, it may not be possible to provide 728 strictly desired NS to tenants because of abstruction of configurable 729 parameters. Moreover, it may cause complexity on designing NS 730 catalog due to quantities of selected attributes. 732 6.1.1. Capability in SaaS-like Model 734 In SaaS-like Model, an NS is represented for a tenant with attributes 735 values listed in Section 3.1. In other words, an NS tenant never 736 know the concrete configurations of components in underlay 737 infrastructure. 739 An NS tenant chooses a value from the range presented by the NS 740 provider in each attribute. The NS provider creates or changes a NS 741 by configuraing components in underlay infrastructures based on the 742 decided attribute values. 744 In terms of telemetry for assurance of service qualities on a NS, a 745 tenant can obtain telemetry information with unit of NSI, and never 746 know ones of underlay components structuring the NS. 748 6.2. PaaS-like Model 750 In PaaS-like Model, an NS is represented with several components such 751 as nodes and connectivities among them. An NS tenant can design and 752 customize its desired NS with combining such components. NS 753 providers breakdown the NS designed by the NS tenant to concrete 754 configurations of their infrastructure, and create/change NSSIs by 755 inputting the configurations. An NS tenant is also able to 756 incorporate its own functions or applications into its NSI by using 757 computing resources provided from NS providers. 759 This model potentially has high customizability of NS rather than 760 SaaS-like model, but needs NS tenants to have some knowledge about 761 network management. In terms of designing NS, the tenants provide 762 outline of their NSs, and thus it would make creation of concrete 763 configurations be easier. 765 6.2.1. Capability in PaaS-like Model 767 In PaaS-like model, an NS is represented with NF nodes and their 768 connectivities. An NS tenant can indicate functionalities of NF 769 nodes and thier locations. Also, the tenant decides attribute values 770 of connectivities. An NS provider creates or changes an NSI by 771 configuring underlay nodes and links depending on the indication of 772 the tenant. An NS tenant is also able to deploy its own NF as 773 software with provided computing resources. 775 In terms of telemetry, an NS tenant can obtain telemetry information 776 of NF nodes and connectivities structuring an NS, in addition to 777 whole of NSI. 779 6.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.3.1. Capability in IaaS-like Model 796 In IaaS-like Model, an NS is represented with configurations of 797 (virtual) nodes and (virtual) links connecting the nodes. An NS 798 tenant is able to configure nodes and links in underlay 799 infrastructure. In short, an NS tenant directly design detailed NS 800 and manages it. In addition, an NS tenant inserts its own functions 801 or applications in the NS with using computing resources. 803 In terms of telemetry, an NS tenant can obtain telemetry information 804 of nodes and links in addition of whole of NSI. 806 6.4. Mapping of NS Provision Models and Infrastructure Layering 808 An example of mapping of each NS provision model is shown in 809 Figure 3. 811 manage 812 [NS Tenant] ---------------------------+ 813 | 814 | 815 . . . . . . . . . . . . . . . . . . . . . . . . | 816 *Service Layer | 817 .--. | 818 .------. ( )-. | 819 | Area#A |<==== Connectivity ====> .' [APL] ' SaaS-like| 820 `------' [BW:100Mbps, Delay<10ms]( ) <---------+ 821 .------. ( [APL] -' | 822 | Area#B |<==== Connectivity ====> '-( ) | 823 `------' [BW:100Mbps, Delay<10ms] '---' | 824 Virtual Private | 825 Cloud | 826 . . . . . . . . . . . . . . . . . . . . . . . . | 827 *NS Layer | 828 __________________________________ | 829 / / | 830 / [AP]----o / PaaS-like| 831 / / `--. /---[VM] / <---------+ 832 / [AP]---o-----o--[FW]--[VM] / | 833 /_________________________________/ | 834 NSI | 835 . . . . . . . . . . . . . . . . . . . . . . . . | 836 *Infra Layer | 837 | 838 | 839 [AP]----o /---[SV] | 840 / `--. /---[SV] IaaS-like| 841 [AP]---o-----o--[FW]--[SV] <---------+ 842 .---' /---[SV] 843 [AP]----' 845 *Legends 846 o : virtual/physical node 847 -- : virtual/physical link 848 [AP] : Access point 849 [APL]: Application owned by NS Tenant 850 [FW] : Firewall Function 851 [VM] : Virtual Machine Instance on Sever 852 [SV] : Server as Infrastructure 854 Figure 3: Mapping of NS provision models 856 In some cases, NSIs provided based on IaaS- or PaaS-like models are 857 coordinated to a form of SaaS-like model by an NS broker , and the NS 858 broker or by the tenant, becoming a NS provider in a recursive 859 manner. For example, a vertical customer sends its high-level 860 requirements to an NS broker create an appropriate NSI with resources 861 provided by infrastructure operators. 863 7. Security Considerations 865 In NSaaS, parts of controls of infrastructures are opened to 866 externals, and thus some mechanisms, such as authentication for APIs, 867 to prevent illegal access would be required. 869 Other considerations are TBD 871 8. IANA Considerations 873 This memo includes no request to IANA. 875 9. Acknowledgement 877 The author would like to thank Toru Okugawa for his kind review and 878 valuable feedback. 880 10. Informative References 882 [I-D.defoy-coms-subnet-interconnection] 883 Foy, X., Rahman, A., Galis, A., 884 kiran.makhijani@huawei.com, k., and L. Qiang, 885 "Interconnecting (or Stitching) Network Slice Subnets", 886 draft-defoy-coms-subnet-interconnection-01 (work in 887 progress), October 2017. 889 [I-D.dong-teas-enhanced-vpn] 890 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 891 Framework for Enhanced Virtual Private Networks (VPN+) 892 Service", draft-dong-teas-enhanced-vpn-03 (work in 893 progress), November 2018. 895 [I-D.homma-nfvrg-slice-gateway] 896 Homma, S., Foy, X., and A. Galis, "Gateway Function for 897 Network Slicing", draft-homma-nfvrg-slice-gateway-00 (work 898 in progress), July 2018. 900 [NGMN-5G-White-Paper] 901 NGMN, "NGMN 5G White Paper", February 2015, 902 . 904 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 905 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 906 DOI 10.17487/RFC8453, August 2018, 907 . 909 [TS.23.501-3GPP] 910 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 911 (V16.0.0): System Architecture for 5G System; Stage 2", 912 September 2018, . 915 [TS.28.530-3GPP] 916 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 917 (V1.0.0): Management and orchestration of networks and 918 network slicing; Concepts, use cases and requirements 919 (work in progress)", June 2018, 920 . 923 [TS.28.541-3GPP] 924 3rd Generation Partnership Project (3GPP), "3GPP TS 28.541 925 (V15.1.0): 5G Netowkr Resource Model (NRM); Stage 2 and 926 stage 3 (Release 15)", June 2018, 927 . 930 [TS.28.801-3GPP] 931 3rd Generation Partnership Project (3GPP), "3GPP TS 28.801 932 (V15.1.0): Study on Management and Orchestration of 933 Network Slicing for next generation network (Release 15)", 934 June 2018, . 937 [WEBPUSH-WG] 938 IETF, "Web-Based Push Notifications(webpush)", 939 . 941 Appendix A. NS Structure in the 3GPP 5GS 943 The overview of structure of NS in the 3GPP 5GS is shown in Figure 4. 944 The terms are described in the 3GPP documents (e.g., [TS.23.501-3GPP] 945 and [TS.28.530-3GPP]). 947 <================== E2E-NSI =======================> 948 : : : : : 949 : : : : : 950 <====== RAN-NSSI ======><=TRN-NSSI=><====== CN-NSSI ======>VL[APL] 951 : : : : : : : : : 952 : : : : : : : : : 953 RW[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]VL[APL] 955 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 956 .,----. ,----. ,----.. ,----. .,----. ,----. ,----.. 957 UE--|RAN |---| TN |---|RAN |---| TN |---|CN |---| TN |---|CN |--[APL] 958 .|NFs | `----' |NFs |. `----' .|NFs | `----' |NFs |. 959 .`----' `----'. .`----' `----'. 960 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 962 RW RAN MBH CN DN 964 *Legends 965 UE: User Equipment 966 RAN: Radio Access Network 967 CN: Core Network 968 DN: Data Network 969 TN: Transport Network 970 MBH: Mobile Backhaul 971 RW: Radio Wave 972 NF: Network Function 973 APL: Application Server 975 Figure 4: Overview of Structure of NS in 3GPP 5GS 977 Authors' Addresses 979 Shunsuke Homma 980 NTT 981 Japan 983 Email: shunsuke.homma.fp@hco.ntt.co.jp 985 Hidetaka Nishihara 986 NTT 987 Japan 989 Email: nishihara.hidetaka@lab.ntt.co.jp 990 Takuya Miyasaka 991 KDDI Research 992 Japan 994 Email: ta-miyasaka@kddi-research.jp 996 Alex Galis 997 University College London 998 UK 1000 Email: a.galis@ucl.ac.uk 1002 Vishnu Ram OV 1003 Independent Research Consultant India 1004 India 1006 Email: vishnu.u@ieee.org 1008 Diego R. Lopez 1009 Telefonica I+D 1010 Spain 1012 Email: diego.r.lopez@telefonica.com 1014 Luis M. Contreras-Murillo 1015 Telefonica I+D 1016 Spain 1018 Email: luismiguel.contrerasmurillo@telefonica.com 1020 Jose A. Ordonez-Lucena 1021 Telefonica I+D 1022 Spain 1024 Email: joseantonio.ordonezlucena@telefonica.com 1026 Pedro Martinez-Julia 1027 NICT 1028 Japan 1030 Email: pedro@nict.go.jp 1031 Li Qiang 1032 Huawei Technologies 1033 China 1035 Email: qiangli3@huawei.com 1037 Reza Rokui 1038 Nokia 1039 Canada 1041 Email: reza.rokui@nokia.com 1043 Laurent Ciavaglia 1044 Nokia 1045 France 1047 Email: Laurent.ciavaglia@nokia.com 1049 Xavier de Foy 1050 InterDigital Inc. 1051 Canada 1053 Email: Xavier.Defoy@InterDigital.com