idnits 2.17.1 draft-homma-slice-provision-models-00.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 (February 1, 2019) is 1911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PNF' is mentioned on line 579, but not defined == Missing Reference: 'VM' is mentioned on line 743, but not defined == Missing Reference: 'APL' is mentioned on line 853, but not defined == Missing Reference: 'AP' is mentioned on line 740, but not defined == Missing Reference: 'FW' is mentioned on line 742, but not defined == Missing Reference: 'SV' is mentioned on line 744, 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: August 5, 2019 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 February 1, 2019 26 Network Slice Provision Models 27 draft-homma-slice-provision-models-00 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 August 5, 2019. 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 4. Network Slice Structure . . . . . . . . . . . . . . . . . . . 7 80 4.1. Resources for Structuring Network Slices . . . . . . . . 7 81 4.2. Basic Network Slice Structure . . . . . . . . . . . . . . 11 82 4.3. Stakeholders in the Structuring Network Slices . . . . . 14 83 5. Variations of Network Slice Creation . . . . . . . . . . . . 14 84 5.1. Ready-made Network Slice . . . . . . . . . . . . . . . . 14 85 5.2. Custom-made Network Slice . . . . . . . . . . . . . . . . 15 86 5.3. semi-Custom-made Network Slice . . . . . . . . . . . . . 15 87 6. Network Slice Provision Models . . . . . . . . . . . . . . . 15 88 6.1. Three Provision Models . . . . . . . . . . . . . . . . . 15 89 6.2. Configurable Parameters/Attributes on each Provision 90 Models . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 6.3. Capability of NS Tenant on each Provision Model . . . . . 18 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 95 10. Informative References . . . . . . . . . . . . . . . . . . . 18 96 Appendix A. NS Structure in the 3GPP 5GS . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction and Motivation 101 Network slicing is an approach to provide separate virtual networks 102 depending on requirements of each service. Network slicing receives 103 attention due to factors such as diversity of services and devices, 104 and it is also a fundamental concept of the 5G for applying networks 105 to such various types of requirements. 107 In addition, network slicing is expected to enable a business model 108 to provide dedicated logical networks to 3rd parties or vertical 109 customers on-demand, called NSaaS (Network Slice as a Service). For 110 such usage, in network slicing, provision of networks able to 111 guarantee communication characteristics end to end would be required. 112 However, the definitions are not harmonized over several SDOs 113 (Standards Developing Organizations). 115 This document clarifies provision patterns of network slice, and 116 provides the definitions and scope of network slicing which are 117 available over several organizations. Furthermore, the deliverables 118 would be help for evaluating applicabilities of existing 119 technologies/solutions to network slicing. 121 1.1. Differentiated Roles in Network Slice Provisioning 123 The widespread of system and network virtualization technologies has 124 conducted to new business opportunities, enlarging the offer of IT 125 resources in the form of Network Slices (NS). As a consequence, 126 there is a clear differentiation between the owner of physical 127 resources, the infrastructure operator, and the intermediary that 128 conforms and delivers network services to the final customers, the 129 Virtual Network Operator (VNO). 131 VNOs aim to exploit the virtualized infrastructures to deliver new 132 and improved services to their customers. However, current NS 133 techniques offer poor support for VNOs to control their resources. 134 It has been considered that the infrastructure operator is 135 responsible of the reliability of the NS elements but several 136 situations advocate the VNO to gain a finer control on its resources. 137 For instance, dynamic events, such as the identification of new 138 requirements or the detection of incidents within the virtual system, 139 might urge a VNO to quickly reform its virtual infrastructure and 140 resource allocation. However, the interfaces offered by current 141 virtualization platforms do not offer the necessary functions for 142 VNOs to perform the elastic adaptations they require to tackle with 143 their dynamic operation environments. 145 1.2. High-level Problem Statement 147 Beyond their heterogeneity, which can be resolved by software 148 adapters, NS platforms do not offer common methods and functions, so 149 it is difficult for the virtual network controllers used by the VNOs 150 to actually manage and control virtual resources instantiated on 151 different platforms, not even considering different infrastructure 152 operators. Therefore, it is necessary to reach a common definition 153 of the functions that should be offered by underlying platforms to 154 enable such overlay controllers with the possibility of allocate and 155 deallocate resources dynamically and get monitoring data about them. 157 Such common methods should be offered by all underlying controllers, 158 regardless of being network-oriented (e.g., ODL, ONOS, Ryu) or 159 computing-oriented (e.g., OpenStack, OpenNebula, Eucalyptus). 160 Furthermore, it is also important for those platforms to offer some 161 "PUSH" function to report resource state, avoiding the need for the 162 VNO's controller to "POLL" for such data. A starting point to get 163 proper notifications within current REST APIs could be to consider 164 the protocol proposed by the [WEBPUSH-WG]. 166 Finally, in order to establish a proper order and allow the 167 coexistence and collaboration of different systems, a common ontology 168 regarding network and system virtualization should be defined and 169 agreed, so different and heterogeneous systems can understand each 170 other without requiring to rely on specific adaptation mechanisms 171 that might break with any update on any side of the relation. 173 2. Definition of Terms 175 This section lists definitions and terms related to network slicing. 176 Although this document refers terms and viewpoints on network slicing 177 in 3GPP documents ([TS.28.530-3GPP] and [TS.28.801-3GPP]) and 178 [NGMN-5G-White-Paper], some of definitions in this document may be 179 different from ones of those documents. 181 Network Slicing: Network slicing indicates a technology, an 182 approach, or a concept to create logical separate networks in 183 support of services, depending on several requirements, on the 184 same physical resources. This is possible by combinations of 185 several network technologies. 187 Network Slice (NS): An NS is a general name of logical separate 188 networks instantiated on a network infrastructure. It includes 189 Network Slice Instance, Network Slice Subnet Instance, and End-to- 190 End Network Slice Instance. 192 Network Slice Instance (NSI): An NSI is a logical network 193 instantiated with network(WAN) and computing(NFVI), and some 194 include additional network service functions such as firewall or 195 load-balancer. It is composed of one or more Network Slice Subnet 196 Instances. When it provides connectivity from end to end for end 197 users, it is called End-to-End Network Slice Instance. An NSI is 198 basically an overlay network and is independent of the underlay 199 network's topology. 201 Network Slice Subnet Instance (NSSI): An NSSI is a partially virtual 202 network instantiated within a single domain, and it basically 203 provides connectivity to other domains or end points. Ways to 204 construct an NSSI depends on the specifications of underlay 205 networks. 207 End-to-End Network Slice Instance (E2E-NSI): An E2E-NSI is a virtual 208 network connecting among end points. It is composed of one or 209 multiple NSSIs. This term is used in this document when it should 210 be emphasized that the NSI is structured from end to end. As an 211 example, for providing an E2E-NSI on the 3GPP 5G network, 212 combining three types of NSIs: RAN-, TRN-, and CN-NSIs would be 213 required. 215 Transport(TRN)-NSSI: A set of connections between various network 216 functions (VNF or PNF) with deterministic SLAs. They can be 217 implemented (aka realized) with various technologies (e.g. IP, 218 Optics, FN, Microwave) and various transport (e.g. RSVP, Segment 219 routing, ODU, OCH etc). The overview of NSI composed with TRN- 220 NSSI is shown in Appendix A. 222 RAN-NSSI: Regardless of RAN deployment (e.g. distributed-RAN, 223 Centralized-RAN or Cloud-RAN, a RAN-NSSI creates a dedicate and 224 logical resource on RAN for each NSI which are completely. The 225 overview of NSI composed with RAN-NSSI is shown in Appendix A. 227 Core(CN)-NSSI: Regardless of Core deployment, a CN-NSI creates a 228 dedicate and logical resource on Core network for each NSI which 229 are completely. The overview of NSI composed with CN-NSSI is 230 shown in Appendix A. 232 Network Slice as a Service (NSaaS): An NSaaS is a service delivery 233 model in which a third-party provider or a vertical customer hosts 234 NSIs and makes them available to customers. In this model, there 235 mainly two roles: NS provider and NS tenant. 237 Network Slice Provider (NS Provider): An NS provider is a person or 238 group that designs and instantiates one or more NSIs/NSSIs, and 239 provides them to NS tenants. In some cases, an NS provider is an 240 infrastructure operator simultaneously. This includes NSI, NSSI, 241 and E2E-NSI providers. 243 Network Slice Tenant (NS Tenant): An NS tenant is a person or group 244 that rents and occupies NSIs from NS providers. 246 Network Slice Stakeholder (NS Stakeholder): An NS stakeholder is an 247 actor in network slicing, and has roles of either NS provider or 248 tenant. 250 Infrastructure Operator: An infrastructure operator is an 251 organization who manages infrastructure networks or data centers 252 for running NSIs. In the most of cases, infrastructure operators 253 are initial NS providers on NSaaS. Also, some of them may be NS 254 tenants simultaneously. 256 Vertical Customer: A vertical customer is a organization who 257 provides some communicating services with using NSIs on NSaaS 258 model. In many cases, a vertical customer become the final NS 259 tenant on NSaaS. For example, video gaming companies or vehicle 260 vendors will possibly be vertical customers. 262 Virtual Network Operator (VNO): A VNO is a person or group that 263 operates virtual networks composed with resources or NSSIs rent 264 from infrastructure operators and provides such virtual networks 265 as NSIs to vertical customers who are final NS tenants. In some 266 cases, infrastructure operators have this role in addition to 267 operating their own infrastructure simultaneously. 269 Domain: A domain is a group of a network and devices administrated 270 under a policy-based common set of rules and procedures. 272 Resource: A resource is an element used to create virtual networks. 273 There are several types of resources, i.e., connectivity, 274 computing and storage. The details are described Section 4.1 276 Virtual Network: A virtual network is a network running a number of 277 virtual network functions. 279 Virtual Network Function (VNF): A virtual network function (VNF) is 280 a network function whose functional software is decoupled from 281 hardware. One or more VNFs run as different software and 282 processes on top of industry-standard high-volume servers, 283 switches and storage, or cloud computing infrastructure. They are 284 capable of implementing network functions traditionally 285 implemented via custom hardware appliances and middleboxes (e.g., 286 router, NAT, firewall, load balancer, etc.). 288 Network Operation System: A network operation system is an entity or 289 a group of entities for operating network nodes and functions as 290 compositions of infrastructure network. For example, OSS/BSS, 291 orchestrator, and EMS are considered to be network operation 292 systems. 294 3. General Requirements for Network Slicing 296 On network slice operations, capabilities for dynamic instantiation, 297 change, and deletion should be required because an NSI is established 298 based on received orders from tenants in NSaaS. From this aspect, 299 some mechanisms to design a network based on service requirements and 300 to convert those to concrete configurations based on the design would 301 be required. 303 In addition, each NS has to maintain concrete communication 304 characteristics end to end, and resource reservations on data plane 305 and isolation among NSIs would be required. Isolation is a concept 306 to prevent the reduction of communication quality caused by 307 disturbance from other NSs, and it may have some levels of 308 enforcement, such as hard or soft isolations. In some cases, for 309 providing appropriate communication between client and server, it 310 would be allowed for NS tenants to put their applications as contents 311 server on NSIs by using computing resources. 313 The required agility of slice operation and granularity of end to end 314 communication quality requested can vary depending on provision 315 model. 317 4. Network Slice Structure 319 This section describes resources used for structuring NSs and the 320 basic structure of E2E-NS. 322 4.1. Resources for Structuring Network Slices 324 A network slice is structured as combinations of the resources it 325 uses. Such resources are mainly categorized into three classes: 326 network/WAN, computing/NFVI, and functionality resources. Variations 327 of each resources are described below. (Note that the lists are not 328 exhaustive.) 330 Network(WAN) Resources: 332 * Connectivity: 334 + (v)Link 335 - Bandwidth per link/session 337 - Connected area/end points 339 - Forwarding route/path (e.g., for traffic engineering, 340 redundancy) 342 - Communication Priority (e.g., QoS class) 344 - Range of jitter amount 346 + Interface of vNode 348 - QoS setting (e.g., Queue size, DSCP remarking, PIR/CIR) 350 - Filter setting 352 + vRouter/vSwitch (# Treated as a set of (v)links and 353 interfaces of vNodes.) 355 * Multicast support 357 * Encryption support 359 * Authentication support 361 * Metadata conveyance (e.g., subscriber ID) 363 * Protocols for slice data plane: 365 + VLAN 367 + IPoE (IPv4 or IPv6) 369 + MAP-E 371 + DS-Lite 373 + PPPoE 375 + L2TP 377 + GRE 379 + MPLS 381 + VxLAN 382 + Geneve 384 + GTP-U 386 + Segment Routing MPLS 388 + Segment Routing IPv6 390 + NSH 392 + Other 394 Computing(NFVI) Resources: 396 * (v)CPU core 398 * Storage 400 * Memory 402 * Disk 404 * vNIC 406 * Connectivity to VNF instances 408 * Virtual Deployment Unit: 410 + Virtual Machine (VM) 412 + container 414 + micro kernel 416 * Resource Deployment Location (i.e., edge DC, central DC, public 417 cloud, ..., etc.) 419 Functionality Resources: 421 * Image: 423 + Data Plane(DP) NF: 425 - GateWay(GW) function: 427 o Access Point Type (e.g., for radio, Wi-Fi, and fixed 428 accesses) 430 o Slice Selection Setting 432 o Terminate protocol 434 o Authentication 436 - Security Appliance: 438 o IPS (Intrusion Prevention System) 440 o IDS (Intrusion Detection System) 442 o WAF (Web Application Firewall) 444 - DPI 446 - Load Balancer 448 - TCP Accelerator 450 - Video Optimizer 452 - Parental Control 454 - Mobile DP functions (Ref. 3GPP 5GS) 456 gNB 458 UPF 460 Uplink Classifier 462 + Control Plane(CP) NF: 464 - DHCP 466 o Fixed IP address allocation 468 o Dynamic IP address allocation 470 o The number of registered devices 472 - DNS 474 - VoIP (SBC, SIP server) 476 - Mobile CP function (Ref. 3GPP 5GS) 477 o AMF (Access and Mobility management Function) 479 o SMF (Session Management Function) 481 o PCF (Policy Control Function) 483 o UDM (Unified Data Management) 485 o NEF (Network Exposure Function) 487 * Provided VNF Type (e.g., open source, product of vender#A, ..., 488 etc.) 490 * Function location (e.g., edge DC, central DC, Public cloud, 491 etc.) 493 In terms of security or usability for NS tenants, some abstraction on 494 resource information would be required, however both setting 495 parameters of underlay infrastructure and abstracted information may 496 coexist in these lists. 498 For abstraction of parameters of underlay networks, some additional 499 protocols or functions (like [RFC8453] ) would be required. 500 Moreover, for providing strict communication qualities, combinations 501 of some technologies may be useful (ref. 502 [I-D.dong-teas-enhanced-vpn]). 504 4.2. Basic Network Slice Structure 506 An E2E-NSI is constructed by stitching NSSIs instantiated on each 507 participating domain. This includes the simplest case of a single 508 NSSI as an E2E NS. Domain types where some NSSIs are established are 509 described below: 511 o Fixed access network 513 o Mobile access network 515 o Transport network 517 o Fixed core network 519 o Mobile core network 521 o Data center (DC) 523 * Edge DC 524 * Central DC 526 o Private network 528 * Enterprise 530 * Factory 532 * Utilities 534 * Farming 536 * Home/SOHO 538 * Other 540 Figure 1 describes the overview of this structure. Resources in each 541 domain (e.g., access, core networks, and DC) are handled by 542 management entities and constitute an NSSI. An E2E-NSI is 543 established by stitching these NSSIs. Ways to stitch NS-subnets are 544 described in [I-D.defoy-coms-subnet-interconnection] and 545 [I-D.homma-nfvrg-slice-gateway]. 547 ___________________________________________ 548 / / 549 /__________________________________________/ 550 E2E-NSI 551 A A A 552 | | | 554 ____________ ___________ ______________ 555 / / / / / / 556 /___________/ /__________/ /_____________/ 557 NSSI#1 NSSI#2 NSSI#3 558 A A A 559 | | | 561 o---o [PNF] /----[VM] 562 / `--. / `----. /----[VM] 563 o---o-----o...o---------o...o---o----[VM] 564 NW Rsrc#1 NW Rsrc+PNF NW+CMP Rsrcs 565 A A A 566 | | | 568 ,--------. ,--------. ,-----------. 569 / Access \ / Core \ / \ 570 | Network | | Network | | DC Domain | 571 \ Domain / \ Domain / \ / 572 `--------' `--------' `-----------' 574 *Legends 575 NW Rsrc : Network Resource 576 CMP Rsrc: Computing Resource 577 o : virtual/physical node structuring NSI 578 -- : virtual/physical link structuring NSI 579 [PNF]: Physical Network Function Appliance on NSI 580 [VM] : Virtual Machine Instance on NSI 582 Figure 1: Overview of NS Structure 584 Although it is shown that an NSSI belongs to just only one E2E-NSI in 585 Figure 1, it may be allowed that multiple E2E-NSIs share an NSSI. 586 Some resources may belong to multiple NSSI as well. 588 In addition, structure on composition of NSI may be recursive. In 589 other words, even though Figure 1 shows a case where NSSIs compose 590 directly an E2E-NSI, in some cases, NSSIs compose an NSI which is a 591 part of an E2E-NSI. The overview is shown in Figure 2. In this 592 figure, NSI#4 is composed of NSSI#1 and NSSI#2, and it structures 593 E2E-NSI#5 with NSSI#3. 595 ___________________________________________ 596 / / 597 /__________________________________________/ 598 E2E-NSI#5 599 A A 600 | | 601 ___________________________ | 602 / / | 603 /__________________________/ | 604 NSI#4 (= NSSI#1 + NSSI#2) | 605 A A | 606 | | | 607 ____________ ___________ _____________ 608 / / / / / / 609 /___________/ /__________/ /____________/ 610 NSSI#1 NSSI#2 NSSI#3 612 Figure 2: Overview of NS recursive structure 614 4.3. Stakeholders in the Structuring Network Slices 616 Potential stakeholders in network slicing are described below: 618 o NSSI provider: infrastructure operator 620 o Intermediate-NSI provider: infrastructure operator, VNO 622 o E2E-NSI provider: infrastructure operator, VNO, service provider 624 o NS tenant: infrastructure operator, VNO, service provider, 625 enterprise, mass user 627 o End customer: enterprise, mass user, etc. 629 5. Variations of Network Slice Creation 631 NSs can be classified according to their creation pattern into two 632 types: ready-made(RM) NS, custom-made(CM), and semi-custom-made(sCM) 633 NS. This section describes the features of these types. 635 5.1. Ready-made Network Slice 637 RM-NS is an NS creation pattern in which an infrastructure operator 638 decides service requirements by itself, and established based on the 639 requirements in advance. NS tenants select one of RM-NSs whose 640 features are closer to their requirements. 642 This model doesn't need immediacy on designing of NSI and enables to 643 mitigate the difficulty of implementation compared with other models. 645 5.2. Custom-made Network Slice 647 CM-NS is an NS creation pattern in which an NS is established based 648 on an order from a tenant and is provided to it. As examples of 649 usage of CM-NS, an enterprise builds and operates a virtual private 650 network for connecting several bases, or OTT (Over The Top) or other 651 industrial service providers create NSs based on their own 652 requirements and use them as a part of their own services (e.g., 653 connected vehicles/drones, online video games, or remote surgery). 655 In this model, network operation system would be required to have 656 incorporate intelligence for designing appropriate NSs on-demand. 658 5.3. semi-Custom-made Network Slice 660 sCM-NS is a derivation of a CM-NS. In sCM-NS, an NS provider designs 661 the outline of NSs in advance, and a tenant tunes an NS with deciding 662 some parameters or applications run on resources. For example, an 663 infrastructure operator designs a logical network presenting 664 connectivity, and tenants install their own applications on servers 665 running on the logical network. 667 6. Network Slice Provision Models 669 This document classifis NS provision models into three categories 670 defined in the following section. The capabilities which NS tenants 671 can have on management of NSs would vary depending on the selected 672 provision model. 674 6.1. Three Provision Models 676 The provision models are categorized into three models: SaaS 677 (Software as a Service), PaaS (Platform as a Service), IaaS 678 (Infrastructure as a Service) like models as below. 680 SaaS-like Model: In this model, an NS provider designs NS templates 681 in advance, and a tenant selects and uses one which fulfills most 682 its requirement among the templates. The specifications of NSs 683 are abstracted to KPIs as networks and servers and shown to 684 tenants. In short, detailed parameters of infrastructure network 685 are hidden from tenants. 687 PaaS-like Model: In this model, a tenant makes its request, 688 including connected area, path routes, the KPIs, and included 689 service functions, and a NS provider designs an NS template and 690 instantiate an NS based on the request dynamically. The 691 configurable values would vary depending on the policy of each NS 692 provider. 694 IaaS-like Model: In this model, a tenant designs its own NS 695 templates and instantiates NSs by indicating concrete resources to 696 infrastructure operators. In other words, infrastructure 697 operators provide just their resources, and NSs are coordinated by 698 the tenant. 700 An example of mapping of each NS provision model is shown in 701 Figure 3. 703 manage 704 [NS Tenant] ---------------------------+ 705 | 706 | 707 . . . . . . . . . . . . . . . . . . . . . . . . | 708 *Service Layer | 709 .--. | 710 .------. ( )-. | 711 | Area#A |<==== Connectivity ====> .' [APL] ' SaaS-like| 712 `------' [BW:100Mbps, Delay<10ms]( ) <---------+ 713 .------. ( [APL] -' | 714 | Area#B |<==== Connectivity ====> '-( ) | 715 `------' [BW:100Mbps, Delay<10ms] '---' | 716 Virtual Private | 717 Cloud | 718 . . . . . . . . . . . . . . . . . . . . . . . . | 719 *NS Layer | 720 __________________________________ | 721 / / | 722 / [AP]----o / PaaS-like| 723 / / `--. /---[VM] / <---------+ 724 / [AP]---o-----o--[FW]--[VM] / | 725 /_________________________________/ | 726 NSI | 727 . . . . . . . . . . . . . . . . . . . . . . . . | 728 *Infra Layer | 729 | 730 | 731 [AP]----o /---[SV] | 732 / `--. /---[SV] IaaS-like| 733 [AP]---o-----o--[FW]--[SV] <---------+ 734 .---' /---[SV] 735 [AP]----' 737 *Legends 738 o : virtual/physical node 739 -- : virtual/physical link 740 [AP] : Access point 741 [APL]: Application owned by NS Tenant 742 [FW] : Firewall Function 743 [VM] : Virtual Machine Instance on Sever 744 [SV] : Server as Infrastructure 746 Figure 3: Mapping of NS provision models 748 In some cases, NSIs provided based on IaaS- or PaaS-like models are 749 coordinated to a form of SaaS-like model by an NS broker , and the NS 750 broker or by the tenant, becoming a NS provider in a recursive 751 manner. For example, a vertical customer sends its high-level 752 requirements to an NS broker create an appropriate NSI with resources 753 provided by infrastructure operators. 755 6.2. Configurable Parameters/Attributes on each Provision Models 757 TBD 759 6.3. Capability of NS Tenant on each Provision Model 761 TBD 763 7. Security Considerations 765 In NSaaS, parts of controls of infrastructures are opened to 766 externals, and thus some mechanisms, such as authentication for APIs, 767 to prevent illegal access would be required. 769 Other considerations are TBD 771 8. IANA Considerations 773 This memo includes no request to IANA. 775 9. Acknowledgement 777 The author would like to thank Toru Okugawa for his kind review and 778 valuable feedback. 780 10. Informative References 782 [I-D.defoy-coms-subnet-interconnection] 783 Foy, X., Rahman, A., Galis, A., 784 kiran.makhijani@huawei.com, k., and L. Qiang, 785 "Interconnecting (or Stitching) Network Slice Subnets", 786 draft-defoy-coms-subnet-interconnection-01 (work in 787 progress), October 2017. 789 [I-D.dong-teas-enhanced-vpn] 790 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 791 Framework for Enhanced Virtual Private Networks (VPN+) 792 Service", draft-dong-teas-enhanced-vpn-03 (work in 793 progress), November 2018. 795 [I-D.homma-nfvrg-slice-gateway] 796 Homma, S., Foy, X., and A. Galis, "Gateway Function for 797 Network Slicing", draft-homma-nfvrg-slice-gateway-00 (work 798 in progress), July 2018. 800 [NGMN-5G-White-Paper] 801 NGMN, "NGMN 5G White Paper", February 2015, 802 . 804 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 805 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 806 DOI 10.17487/RFC8453, August 2018, 807 . 809 [TS.23.501-3GPP] 810 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 811 (V15.3.0): System Architecture for 5G System; Stage 2", 812 September 2018, . 815 [TS.28.530-3GPP] 816 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 817 (V1.0.0): Management and orchestration of networks and 818 network slicing; Concepts, use cases and requirements 819 (work in progress)", June 2018, 820 . 823 [TS.28.541-3GPP] 824 3rd Generation Partnership Project (3GPP), "3GPP TS 28.541 825 (V15.1.0): 5G Netowkr Resource Model (NRM); Stage 2 and 826 stage 3 (Release 15)", June 2018, 827 . 830 [TS.28.801-3GPP] 831 3rd Generation Partnership Project (3GPP), "3GPP TS 28.801 832 (V15.1.0): Study on Management and Orchestration of 833 Network Slicing for next generation network (Release 15)", 834 June 2018, . 837 [WEBPUSH-WG] 838 IETF, "Web-Based Push Notifications(webpush)", 839 . 841 Appendix A. NS Structure in the 3GPP 5GS 843 The overview of structure of NS in the 3GPP 5GS is shown in Figure 4. 844 The terms are described in the 3GPP documents (e.g., [TS.23.501-3GPP] 845 and [TS.28.530-3GPP]). 847 <================== E2E-NSI =======================> 848 : : : : : 849 : : : : : 850 <====== RAN-NSSI ======><=TRN-NSSI=><====== CN-NSSI ======>VL[APL] 851 : : : : : : : : : 852 : : : : : : : : : 853 RW[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]VL[APL] 855 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 856 .,----. ,----. ,----.. ,----. .,----. ,----. ,----.. 857 UE--|RAN |---| TN |---|RAN |---| TN |---|CN |---| TN |---|CN |--[APL] 858 .|NFs | `----' |NFs |. `----' .|NFs | `----' |NFs |. 859 .`----' `----'. .`----' `----'. 860 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 862 RW RAN MBH CN DN 864 *Legends 865 UE: User Equipment 866 RAN: Radio Access Network 867 CN: Core Network 868 DN: Data Network 869 TN: Transport Network 870 MBH: Mobile Backhaul 871 RW: Radio Wave 872 NF: Network Function 873 APL: Application Server 875 Figure 4: Overview of Structure of NS in 3GPP 5GS 877 Authors' Addresses 879 Shunsuke Homma 880 NTT 881 Japan 883 Email: shunsuke.homma.fp@hco.ntt.co.jp 884 Hidetaka Nishihara 885 NTT 886 Japan 888 Email: nishihara.hidetaka@lab.ntt.co.jp 890 Takuya Miyasaka 891 KDDI Research 892 Japan 894 Email: ta-miyasaka@kddi-research.jp 896 Alex Galis 897 University College London 898 UK 900 Email: a.galis@ucl.ac.uk 902 Vishnu Ram OV 903 Independent Research Consultant India 904 India 906 Email: vishnu.u@ieee.org 908 Diego R. Lopez 909 Telefonica I+D 910 Spain 912 Email: diego.r.lopez@telefonica.com 914 Luis M. Contreras-Murillo 915 Telefonica I+D 916 Spain 918 Email: luismiguel.contrerasmurillo@telefonica.com 920 Jose A. Ordonez-Lucena 921 Telefonica I+D 922 Spain 924 Email: joseantonio.ordonezlucena@telefonica.com 925 Pedro Martinez-Julia 926 NICT 927 Japan 929 Email: pedro@nict.go.jp 931 Li Qiang 932 Huawei Technologies 933 China 935 Email: qiangli3@huawei.com 937 Reza Rokui 938 Nokia 939 Canada 941 Email: reza.rokui@nokia.com 943 Laurent Ciavaglia 944 Nokia 945 France 947 Email: Laurent.ciavaglia@nokia.com 949 Xavier de Foy 950 InterDigital Inc. 951 Canada 953 Email: Xavier.Defoy@InterDigital.com