idnits 2.17.1 draft-netslices-usecases-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 18, 2017) is 2381 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-bernardos-nfvrg-multidomain-03 == Outdated reference: A later version (-10) exists of draft-ietf-l2sm-l2vpn-service-model-03 ** Obsolete normative reference: RFC 8049 (Obsoleted by RFC 8299) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 None K. Makhijani, ed 3 Internet-Draft J. Qin 4 Intended status: Informational R. Ravindran 5 Expires: April 21, 2018 Huawei Technologies 6 L. Geng 7 China Mobile 8 L. Qiang 9 S. Peng 10 Huawei Technologies 11 X. de Foy 12 A. Rahman 13 InterDigital Inc. 14 A. Galis 15 University College London 16 G. Fioccola 17 Telecom Italia 18 October 18, 2017 20 Network Slicing Use Cases: Network Customization and Differentiated 21 Services 22 draft-netslices-usecases-02 24 Abstract 26 Network Slicing is meant to enable creating (end-to-end) partitioned 27 network infrastructure that may include the user equipment, access/ 28 core transport networks, edge and central data center resources to 29 provide differentiated connectivity behaviors to fulfill the 30 requirements of distinct services, applications and customers. In 31 this context, connectivity is not restricted to differentiated 32 forwarding capabilities but it covers also advanced service functions 33 that will be invoked when transferring data within a given domain. 35 The purpose of this document is to focus on use cases that benefit 36 from the use of network slicing. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 21, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 74 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. A Generalized Network Slice as a Service . . . . . . . . . . 6 77 3.1. Resource Centric Service Concept . . . . . . . . . . . . 6 78 3.2. Strict Resource Demand . . . . . . . . . . . . . . . . . 7 79 3.3. Network Customization . . . . . . . . . . . . . . . . . . 7 80 3.4. NSaaS of Different Granularity . . . . . . . . . . . . . 7 81 3.5. Service customization across multi-provider multi-domains 82 as NSaaS . . . . . . . . . . . . . . . . . . . . . . . . 8 83 4. Network Slicing in 3GPP Mobile Network . . . . . . . . . . . 10 84 4.1. Network Slices in 3GPP Systems . . . . . . . . . . . . . 10 85 4.2. Creating, Managing and Operating 3GPP Network Slices . . 11 86 5. Role of Virtualization in Network slicing . . . . . . . . . . 12 87 5.1. Virtualized Customer Premise Equipment . . . . . . . . . 12 88 5.2. Enhanced Broadband . . . . . . . . . . . . . . . . . . . 14 89 6. Services with Resource Assurance . . . . . . . . . . . . . . 16 90 6.1. Massive Machine to Machine Communication . . . . . . . . 16 91 6.2. Ultra-reliable Low Latency Communication . . . . . . . . 18 92 6.3. Critical Communications . . . . . . . . . . . . . . . . . 20 93 7. Network Infrastructure for new technologies . . . . . . . . . 23 94 7.1. ICN as a Network Slice . . . . . . . . . . . . . . . . . 23 95 7.2. New Verticals - ICN based service delivery . . . . . . . 24 96 7.2.1. Required Characteristics . . . . . . . . . . . . . . 25 97 8. Overall Use Case Analysis . . . . . . . . . . . . . . . . . . 26 98 8.1. Requirements Reference . . . . . . . . . . . . . . . . . 26 99 8.2. Mapping Common characteristics to Requirements . . . . . 26 100 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 102 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 106 13.2. Informative References . . . . . . . . . . . . . . . . . 30 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 109 1. Introduction 111 Network Slicing enables the creation of (end-to-end) partitioned 112 network infrastructure that may include the user equipment, access/ 113 core transport networks, edge and central data center resources to 114 provide differentiated connectivity behaviors to fulfill the 115 requirements of distinct services, applications and customers. In 116 this context, connectivity is not restricted to differentiated 117 forwarding capabilities but it also spans service, management and 118 control plane support offered to a slice instance. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119. 126 1.2. Terminology 128 Please refer to [I-D.geng-netslices-architecture] for related 129 terminologies and definitions. 131 Additionally, the following terms are used: 133 o V2X (Vehicle-to-everything): Is a communication of information 134 from a vehicle to any other entity that may be another vehicle, 135 road-side network element or application end point. 137 o ITS (Intelligent Transportation Systems): Considered as an aspect 138 of how using Internet of Things resource like road sensors can 139 creates a smart transport network. The network offers services 140 related to transport and traffic management systems through flow 141 of information between road-side sensors, vehicles, smart devices 142 and humans. 144 o Over-the-top (OTT): A service, e.g., content delivery using a CDN 145 or a social networking service, operated by a different service 146 providers to which the users of the NSP service are attached to, 147 and to whom it serves as a communication (or bit pipe) provider 149 o Industry vertical: A collection of services or tools specific to 150 an industry, trade or market sector. also, referred to as Service 151 Verticals in this document. 153 o TETRA: Terrestrial trunked radio is a digital trunked mobile radio 154 standard to meet needs of public safety, transportation and 155 utilities like organizations. 157 o SLA: Service Level Agreement - A contract between a service 158 provider and an end user that stipulates a specified level of 159 service, support option, a guaranteed level of system performance 160 as relates to downtime or up-time. 162 2. Scope 164 To maximize resource utilization and minimize infrastructure cost, 165 services will need to operate over a shared network infrastructure, 166 as against the traditional monolithic model operated either as 167 dedicated network or as an overlay. Service operators can utilize or 168 benefit from Network Slicing through multi-tenancy, enabling 169 different customized network infrastructures for different group of 170 services across different network domains and operating them 171 independently. 173 In this document, multi-domain refers to combination of different 174 kinds of connection-technology network domains. For example, it may 175 be a RAN, DSL etc. in access; a fixed, wireless or mobile service 176 provider network; as well as different technology domains, in 177 transport networks such as carrier Ethernet, optical, MPLS, TE-tunnel 178 etc. Often, a combination of technology domains is under the same 179 administrator's control but may also belong to different 180 administrative systems and may require cross-domain coordination. 182 The document covers generalized as well as resource guaranteed 183 service scenarios that can benefit by applying Network Slicing 184 principles as below in Figure 1 185 ---------------------------- 186 | Network Slice as a Service | 187 ---------------------------- 188 | _______ 189 -----------------|----------------_----->| 3GPP | 190 | | | |______| 191 | | | 192 | | | 193 __________+______ ______+______ _______+__________ 194 | Customization | | Resource | | New | 195 | | | assurance | | Technologies | 196 |_______________| |___________| |________________| 197 /\ /\ | 198 /| \ / |\ | 199 / | \ / | \ | 200 _____/_ | _\_____ ____/___| _\______ ____|__ 201 | vCPE | | | 5GEX | | mMTC || | uRLLC | | ICN | 202 |______| | |_______| |______|| |_______| |_____| 203 | | 204 | | 205 ____|___ ___|___ 206 | eMBB | | MCS | 207 |______| |_____| 209 Figure 1: Use case organization in the document 211 The remaining document is organized as below: 213 o In Section 3, Network Slice as a Service(NSaaS) delivery model is 214 described. 216 o Section 3.5, is a scenario for multi-domain network slice 217 coordination. 219 o In Section 4, 3GPP architecture for 5G is discussed as a use case 220 so that those requirements may be taken into consideration during 221 slicing activities in IETF. 223 o Other use cases are discussed from 2 perspectives 225 a Existing scenarios: Several already deployed use cases that 226 would further benefit operators when deployed through Network 227 Slice paradigm are discussed in Section 5. 229 b Differentiated service scenarios: that must absolutely meet 230 strict resource requirements, as if they use a dedicated 231 infrastructure. The example use cases are categorized in 232 Section 6. 234 o Section 7, has an example use case of cases where new technologies 235 can be verified or deployed using network slicing concept. 237 o In Section 8, the use case requirements are summarized which are 238 inputs to the [I-D.qiang-netslices-gap-analysis]. 240 3. A Generalized Network Slice as a Service 242 Network slicing instances share a common infrastructure, which 243 provide flexible design of a logical network with specific network 244 functions customized to support differentiated performance 245 requirements of vertical industry through logical or physical system 246 isolation and certain OAM tools. 248 Traditionally, vertical industries run their services in a shared 249 network environment upon which infrastructure owners and service 250 providers offer standalone network capabilities including 251 connections, storage and etc. Network slicing paradigm enables 252 supporting the requirements of a network slicing tenant to be met 253 individually. Hence it is anticipated that this type of new business 254 model where network slice instances are leased to industry verticals 255 as a service (i.e. Network Slicing as a Service, NSaaS) may become a 256 norm in the near future. 258 3.1. Resource Centric Service Concept 260 Network services specify a set of resource requirements to offer 261 desired Quality of Experience (QoE) to it consumers, using features 262 offered by the control and forwarding planes. Traditional service 263 guarantees are associated with resource attributes such as 264 throughput, packet loss, latency, network bandwidth/burst or other 265 bit rates and security. In addition, redundancy and reliability are 266 provided by the infrastructure to improve overall QoE. More 267 recently, concepts such as edge computing allow opportunistic 268 placement of services to meet stringent requirements of low latency 269 and/or high bandwidth applications. 271 Clearly the description of service delivery is more diverse now than 272 before and demands higher degree of resource engineering and agility. 273 The motivation behind Network slicing paradigm is to enable new 274 service deployments without having to build new network 275 infrastructures or causing disruptions to already deployed services 276 in the network. In this regard, there are two primary 277 characteristics NS should satisfy, a) Strict demand for network 278 resource, b) Network Customization. 280 3.2. Strict Resource Demand 282 Several services are sensitive to response times and/or amount of 283 bandwidth, e.g. real time interactive multimedia, high bandwidth 284 video feed or remote access to an enterprise network. Failure to 285 meet these criteria lead to service degradation. Moreover, new 286 industry verticals are evolving due to technological advancements in 287 sensors, IoT, robotics and multi-media, along with new type of 288 network interactions (both human-human or human-machine). These 289 impose even stricter resource and connectivity requirements. The 290 challenge lies in utilizing common network infrastructure and 291 judiciously allocating available infrastructure resources. 293 3.3. Network Customization 295 To a network slice tenant, the ability to customize services 296 dynamically is important. Customization gives control to the 297 operator of a slice to create, provision and change network resources 298 to suit their service demands. Customization enables decomposition 299 of resources from an underlying network infrastructure and logically 300 aggregate them as part of a slice. These customizations also include 301 placement and logical connection of the network functions based on 302 the service requirements. 304 3.4. NSaaS of Different Granularity 306 In order to meet various requirements from the network slice tenant, 307 NSaaS should be provided with different granularities. Some typical 308 examples of granularities that a provider may offer are as follows. 310 o Network Domain - Network slice instances of different networks 311 i.e. access (wireless, fixed) network, transport network and core 312 network. 314 o Access technologies - Network slice instances of different 315 generations of cellular and fixed network technologies, i.e. 4G, 316 WiFi, Passive Optical Network (PON) and DSL. 318 o SLA requirements - Network slice instances of different SLA 319 requirements, i.e. low-latency network, legacy best-effort network 320 and network with guaranteed-bandwidth. 322 o Vertical applications - Network slice instances of different 323 industry verticals. i.e. manufacturing site, V2X, industrial IoT 324 and smart city. 326 o OTT services - Network slice instances of different applications 327 provided by OTT, i.e. messaging, payment, video streaming and 328 gaming. 330 o Cross domain services - Network slice instances of different 331 services across multi-provider domains such as l2, l3 VPN 332 services. 334 During the realization of network slice instance, it is also very 335 important that sub-instance of a more general one can be provided 336 with a finer granularity. In practice, it is up to the provider to 337 decide the granularity to lease the network slice instances. 339 The customization of different granularities of a network slice 340 introduce many challenges, especially in terms of network management 341 and orchestration. As a network slice provider (provider of end-to- 342 end slice service), it is essential to have a comprehensive 343 understanding of the network capability. This requires that network 344 connectivity and resources can be exposed to the network slice 345 tenants (as the differentiated services). Accordingly, network slice 346 provider is able to orchestrate specific instances based on these 347 exposed capabilities. 349 3.5. Service customization across multi-provider multi-domains as NSaaS 351 L2 and L3 connectivity services can be deployed in a multi-provider 352 multi-domain scenario and, in the SDN era, this implies the 353 decoupling of network resources for different service provider and 354 domain orchestrators. The allocation of network resources within the 355 domain of each service provider, involved by the end-to-end service, 356 can be defined as a network slice. 358 Within a single domain, provider is aware of the entire topology and 359 its own resource availability and has complete control over those 360 resources. However, in a multi domain scenario, the overall 361 knowledge of the resources and topologies cannot be made across 362 providers. Therefore, the exchange of information across these 363 providers have to be enabled, as shown in Figure 2, inspired by 364 [I-D.bernardos-nfvrg-multidomain] and 365 [I-D.ietf-opsawg-service-model-explained]. 367 ---------------------------- 368 | Customer Service Requester | 369 ---------------------------- 370 | 371 (L2VPN/L3VPN | 372 Service | IF1 373 Model) | | 374 + + 375 _____|____ ____|_____ 376 | Multi | IF2 | Multi | 377 | Provider |<--------+---------->| Provider | 378 |____MdO_1_| |___ MdO_2_| 379 /\ /\ 380 / \ / \ 381 / \ IF3 / \ 382 _______/__ _\_________ ________/_ _\________ 383 | Domain | | Domain | | Domain | | Domain | 384 |___Orch___| |___Orch___| |___Orch___| |___Orch___| 386 Figure 2: Multi-domain, multi-provider connectivity services 388 The Figure 2 shows a multi provider MdO (MP-MdO) exposing an 389 interface 1 (IF1) to the tenant, interface 2 (IF2) to other multi 390 provider MdO (multi domain orchestrator) and an interface 3 (IF3) to 391 individual domain orchestrators. IF1 is exposed to the tenant who 392 could request his specific services and/or slices to be deployed. 393 IF2 is between the orchestrators and is a key interface to enable 394 multi-provider operation. IF3 focuses on abstracting the technology 395 or vendor dependent implementation details to support orchestration 396 in each network domain (see [!@I-D.bernardos-nfvrg-multidomain] for 397 details). The coordination alternatives between MP-MdOs are: * 398 Bilateral Cascading: providers can have long-lasting business 399 agreements only with their direct neighbors. * Full Mesh between MP- 400 MdOs: Providers can have long-lasting business agreement with any 401 provider (neighboring or remote). 403 This reference architecture is the main focus of the 5GEx European 404 Project. 406 Among applications, L2VPN and L3VPN wholesale end-to-end services in 407 a multi-provider and multi-domain scenario needs the following 408 characteristics for network slice management 410 o An automatic activation test and verification functionality (by 411 customer or orchestrator). 413 o Interface to modify parameters of L2VPN or L3VPN service such as 414 bandwidth or path redundancy. 416 Looking at Figure 2, the customer needs a new L2 end-to-end service 417 between CPEs across two domains (MP-MdO1 and MP-MdO2). As MP-MdO1 418 receives the service request, it is deployed as a network slice. In 419 this regards MP-Md01 has prior knowledge of topology and resource 420 across domains in some form, it then splits the service request into 421 a slice across each of the involved domain. Once service is set up: 422 MP-MdO1 allocates resources for the slice on SP1 domain while MP-MdO2 423 allocates on SP2 domain respectively. 425 [I-D.ietf-l2sm-l2vpn-service-model] and [RFC8049] can describe IF1 426 For L2 and L3 end-to-end services respectively. The ability to map 427 such services as network slice will be considerable opportunity for 428 dynamic cross-domain operations. 430 4. Network Slicing in 3GPP Mobile Network 432 Network Slicing is a core capability of the currently under 433 development 3GPP 5G phase 1 mobile system, as it makes it possible 434 for different service verticals, such as IoT and broadband 435 applications, to be deployed over a common shared infrastructure. 436 More details can be found in [TS_3GPP.23.501], [TS_3GPP.23.502], 437 [TR_3GPP.38.801], [TR_3GPP.33.899] and [TS_3GPP.28.500]. 439 3GPP is currently defining its own solution for network slicing. An 440 IETF effort in this field may, however, still be complementary in the 441 long run as IETF focuses on the IP infrastructure and protocols which 442 are generally out of scope of 3GPP. Challenges relevant to the IETF 443 include isolation between network slices, supporting sharing network 444 functions between several slices, building slices recursively from 445 smaller slice subnets, implementing slicing across different domains 446 for roaming, etc. 448 4.1. Network Slices in 3GPP Systems 450 In 3GPP systems a network slice is a complete logical network which 451 provides telecommunication services and network capabilities. 452 Distinct Radio Access Network (RAN) slices and core network slices 453 interwork to provide mobile connectivity. A device may access 454 multiple NS simultaneously through a single RAN. 3GPP defines slice 455 IDs (NSSAI) composed of a Slice Service Type (SST) and a Slice 456 Differentiator (SD). SST refers to an expected network behavior in 457 terms of features and services (e.g. specialized for broadband or 458 massive IoT), while SD helps distinguishing among several NS 459 instances. 461 Figure 3 describes the general layout of Network Slicing in mobile 462 networks. A core network slice includes, a Session Management 463 Function (SMF), which manages PDU sessions, and a User Plane Function 464 (UPF). Some functions such as the Access and Mobility management 465 Function (AMF) are common and shared between multiple RAN and core 466 network slices. 468 Common Functions Core Network Slice Instance 469 +-----------------+---------------------+ 470 | +--------+ | +--------+ | 471 | | Control| | | Control| | 472 +--------+ Plane +----------+ Plane | | 473 | | | AMF... | | | SMF... | | 474 +---+--+ | +--------+ | +----+---+ | 475 |Device| +-----------------+ | | 476 +---+--+ | +--------+ | +------+-----+ | 477 | | | | | | User Plane | | +---------------+ 478 +--------+ RAN +--------+ Functions +------+Data Network or| 479 | | | | | UPF... | | | The Internet | 480 | +--------+ | +------------+ | +---------------+ 481 +-----------------+---------------------+ 482 RAN Slice Instance 484 Figure 3: 3GPP Network Slices 486 4.2. Creating, Managing and Operating 3GPP Network Slices 488 To create a network slice instance, mobile network operators define 489 "Network Slice Subnets" into OSS/BSS management system. NS subnets 490 are NS components including NFs and reserved network resources. OSS/ 491 BSS communicates with the orchestrator, which, through the rest of 492 the NFV-MANO system, configures compute and network elements to 493 create, compose and activate slices. 495 Mobile network operators can modify the configuration of a RAN or 496 core network slice, while it is in use. To support this, the 497 operator needs to measure QoS/SLA data for hosted network services, 498 and associate results with the relevant network slice. Example of 499 operations include increase or decrease network capacity or compute 500 capacity of NFs; update the configuration of NFs; add, replace or 501 remove a NFs or a Network Slice Subnet. 503 Slice selection occurs in 2 phases: first, common functions 504 (including AMF) and available network slices are pre-selected when 505 the device registers with the network. Later on, the network 506 dynamically selects network slices when a device initiates 507 communication, based on a slice ID associated with the application 508 (on the device) that requests a new flow. 510 5. Role of Virtualization in Network slicing 512 Virtualization is a key enabler of network slices; Many network 513 services can be easily deployed using components of NFV framework 514 like network functions, hardware decoupling and resource placement 515 [#?NFVSLICE]. When deployed as a network slice, the resources 516 associated with virtualized network services are managed uniformly by 517 network slice provider. One such use case is described below. 519 5.1. Virtualized Customer Premise Equipment 521 A CPE is an equipment that connects the customer premises to the 522 provider's network. A CPE may either be a layer-2 or a layer-3 523 device (the routing gateway) performing different network functions 524 depending on the access technology (DSL modem, PON modem, etc.). Any 525 services provided such as Internet access, IPTV, VoIP, etc. or 526 network functions for example, local NAT, local DHCP, IGMP proxy- 527 routing, PPP sessions, routing, etc. are also part of CPE. The 528 installation of different on-premise devices, entails a high cost for 529 service providers in terms of both initial installation and 530 operational support, since they are typically responsible for the 531 end-to-end service. 533 Traditional CPE deployments are service provider network functions 534 installed on customer site to provide above mentioned functionalities 535 along with remote site connectivity. Communication Service provider 536 (CSP) is responsible for management and administration of connections 537 and state with proper policy, bandwidth, security and QoS 538 requirements. 540 |-----------------------| 541 | +------+ |------------------+-------+ campus 542 | |--| | | | vCPEx | -----[ ] 543 | | | | |------------------+-------+ 544 | | | | | <====Broadband ==> 545 | ----- | | vCPE | | -----------------+-------+ branch 546 | ( ) |->| | | | vCPEy |------[ ] 547 | ( CSP )| | | |------------------+-------+ 548 | (_____) | | | |<=== MPLS/4G. ==> 549 | | | | |------------------+-------+ main site 550 | |->| | | | vCPEz |----- [ ] 551 | +------+ |------------------+-------+ 552 |-----------------------| 554 Figure 4: Virtualized CPE with distributed architecture 556 Figure 4 shows a virtualized architecture in which many functions are 557 moved to CSP's cloud simplifying CPE on premises tremendously. 558 Additional details of deployment architecture models are captured in 559 [I-D.pularikkal-virtual-cpe] where full dissemination of data path 560 and control plane functions is described. The figure shows vCPEx, 561 vCPEy, vCPEz are virtualized CPEs on multiple sites of a specific 562 customer, there may be set of different network functions in each x, 563 y and z CPE. The vCPE instance in CSP cloud is integrated to each 564 site performing service chains of network functions and resource 565 allocations specific for ingress and egress path of each site. 567 A vCPE is a well-known concept[VCPEBBF] which when combined with WAN 568 technologies provides end to end visibility and reachability to 569 remote sites. However, there is no standard approach to connectivity 570 or management of various CPE functions. Using network slicing, a 571 greater level of agility can be achieved, with each customer 572 dynamically managing its own network with the assistance of network 573 slicing framework. 575 The benefit of self-managing a vCPE network slice is the capability 576 to move network functions on premise of to the cloud. An obvious use 577 case will be customer initiated gradual migration of network 578 functions from a site to CSP cloud. 580 +-------------+ 581 | Slice | 582 | Resource Mgr| 583 +-------------+ 584 | 585 | NS protocol or i/f 586 V 587 |--------------------------------------------------| 588 | | 589 | +-------------+ +-------------+ | 590 | | vCPE Slice | | CSP | | 591 | | Monitor | | vCPE subnet | | 592 | +-------------+ +-------------+ | 593 | | 594 | +--------+ +--------+ +--------+ +--------+ | 595 | | vCPEy | | vCPEy | | trans | | vCPEz | | 596 | | subnet | | subnet | | subnet | | subnet | | 597 | +--------+ +--------+ +--------+ +--------+ | 598 | | 599 |--------------------------------------------------| 600 | | 601 | NS transport protocol or i/f | 602 V V 603 [campus] [branch] [transport] [main site] 605 Figure 5: vCPE as a Network Slice 607 In Figure 5, a slice for vCPE is shown. Using slice subnet approach, 608 each vCPE site instance may be considered as an abstracted subnet, 609 along with the WAN transport as another subnet. The network 610 functions are chained in a distributed fashion between site vCPEs and 611 CSP vCPE subnet. A monitoring function interfaces with CSP's global 612 slice manager for resource management. A south-bound interface 613 through network slice transport protocol, realizes these functions on 614 the infrastructure. 616 5.2. Enhanced Broadband 618 Today, video consumes the largest amount of bandwidth over the 619 Internet. As the higher resolution formats enter mainstream, even 620 more bandwidth will be needed to stream 4K/8K/360 degree formats. 621 For example, connected Virtual Reality(VR)/Augmented Reality(AR) is 622 the future use case of eMBB services. Notably, media processing for 623 AR/VR will require in-network processing functions and high latencies 624 between components could lead to downgrade of user experience. 625 Therefore, an AR/VR stream requires a special infrastructure that 626 differs from best-effort network. 628 A purpose-built network slice for eMBB streaming shall ensure to 629 minimize processing overheads, it may be done by placement of network 630 functions closer to subscribers. Resource scaling for eMBB should be 631 dynamic because bandwidth is expensive and such vertical service 632 operators may not want to pay for unutilized bandwidth. Therefore, 633 slices should be able to monitor, negotiate and adjust the scale for 634 both bandwidth and service functions. Latency guarantees vary from 635 general services, therefore, as a first step, monitoring for quality 636 of service is needed and more advanced operation would involve 637 recovery and reparation of paths. 639 A typical eMBB slice Figure 6 from a network operator is a 640 performance oriented service customization. An eMBB service slice 641 template will allow a tenant to request or specify 643 (1) CDN components (as service functions) 645 * Regional network locations of CDN, encoders etc. 647 * Location of acquired content. 649 * Describes transport constraints for its own distribution 650 network comprising of connectivity between content 651 acquisition and Fan-out points. 653 (2) An interface to subscriber database perhaps as a network 654 function, from multiple access network types (cellular, fixed). 656 (3) Live performance monitoring and resource negotiation loop. 658 (4) A well-coordinated network slice protocol that enables resource 659 allocation across different network domains. 661 +-------------------------+ 662 | Slice Resource Manager | 663 +-------------------------+ 664 | | 665 | NS control | 666 | | 667 +------------------+ +----------------+ 668 | eMBB Network | | eMBB Network | 669 +------------------+ +----------------+ 670 | | 671 V V 672 ----------NS transport ---------------- 673 | | | 674 V V V 675 ---------------- ---------------- ----------- 676 | Infrastructure | |Infrastructure | | DC | 677 | Domain A | | Domain B | | Domain C | 678 ---------------- ---------------- ----------- 680 Figure 6: Transport provider network operator view. 682 6. Services with Resource Assurance 684 6.1. Massive Machine to Machine Communication 686 Sensor networks are widely deployed in industries such as 687 agriculture, environmental monitoring and manufacturing. The general 688 workflow of wireless sensor network is provided in Figure 7. 690 6.Decided Behavior 691 +-------------------+ 692 | | 693 +----v------+ | 694 | Sensor | | 695 |(1. Data | | 696 |Collection)| | 697 +----+------+ | 698 |2.Collected Data | 3.Aggregated +---------------------+ 699 +------------->+----------+ Data | Data Center | 700 | Sink Node/ |----------> (4. Data Analysis | 701 | Base Station| | & | 702 +---------->+--------------+--<------| Behavior Decision) | 703 |2.Collected Data | 5. Decided +---------------------+ 704 +----+------+ | Behavior 705 | Sensor | | 706 |(1. Data | | 707 |Collection)| | 708 +----^------+ | 709 | | 710 +-------------------+ 711 6.Decided Behavior 713 Figure 7: Workflow of wireless sensor network 715 Figure 7 shows, control of sensor data & behavior at scale, requiring 716 wide area coverage and power constrained communication. A few new 717 types of scenarios that require unique infrastructure are: 719 o Smart city networks: an integration of several public 720 infrastructures together through M2M communications. For example 721 Automatic metering (for gas, energy, water, etc.), environment 722 monitoring (for pollution, temperature, humidity, etc.), traffic 723 signal control etc. 725 o E-health communications that remote monitor the physical 726 conditions (e.g., heart rate, pulse, blood pressure etc.), and 727 accordingly take necessary measures remotely. E-health 728 communication network must be secure, reliable and fast but small- 729 size of data exchange. 731 mMTC Type Slices involves potentially a large number of small and 732 power-constrained devices, therefore, resource allocation at scale is 733 of particular importance in mMTC type slices. Furthermore, different 734 kind of IoT devices may exhibit delay sensitivity in industry 735 operations etc. The mMTC type slices should be conscious of 736 requirements of scale, variable data pattern, and energy efficient 737 communications. 739 6.2. Ultra-reliable Low Latency Communication 741 In uRLLC scenarios, data loss is not acceptable. Both data and 742 control planes may require significant enhancements to transmission 743 or information distribution protocols. [TR_3GPP_38.913] specifies 744 access network user plane latency as 1ms and reliability factor of 745 99.999% for transmission of a packet of size 32 bytes. The slices of 746 this type must be ensured that shared infrastructure absolutely does 747 not cause any adverse effects. 749 In the following sections three new uRLLC scenarios are described. 751 (1) Industrial operation: Operations in remote sites usually need 752 combined support of cellular and transport network. Operational 753 accuracy is characterized by 755 * Requires high-quality communication links between the control 756 site. 758 * Low latency and low jitter in communication path 760 * Closed control loop (Sensor -Controller - Actuator) as shown 761 in Figure 8, a typical control cycle time where network is 762 involved should be below 10ms [Tactile-Internet]. 764 ++++++++++ +++++++++++++++ 765 + Sensor +-->+ Transmitter +---+ 766 ++++++++++ +++++++++++++++ | 767 | ++++++++++++ ++++++++++++++ 768 +-->+ Base +---->+ Controller + 769 +---+ Station +<----+ + 770 | ++++++++++++ ++++++++++++++ 771 ++++++++++++ ++++++++++++++ | 772 + Actuator +<--+ Receiver + <--+ 773 ++++++++++++ ++++++++++++++ 775 Figure 8: Industrial closed control loop 777 (2) Remote surgery enables surgeons to perform critical specialized 778 medical procedures remotely, providing accurate control and 779 haptic feedback. 781 A uRLLC network slice only accepts service specific traffic and must 782 not receive any other type of traffic to avoid negative impact on the 783 service operation. Capabilities required by uRLLC service provider 784 include 785 o Locations of the access nodes for terminals (devices, vehicles) to 786 the transport network and locations of the controller to construct 787 its own network topology within the network slice. In high 788 mobility scenario such as automotive verticals, the dynamic 789 topology adjustments are required without loss of data. 791 o Each service vertical has different performance requirements in 792 terms of latency, reliability and data rate etc., therefore, the 793 uRLLC network slice should allow customization for these 794 parameters. 796 o A uRLLC service provider should be able to registers self with 797 access rights to resource monitoring and negotiation loop. 799 A network slice provider offers a uRLLC Slice with the following 800 considerations 802 o Should support/provide specific data and control planes protocols 803 with significant enhancements for deterministic latency and 804 reliability (e.g. DetNet[I-D.dt-detnet-dp-sol] in data plane). 806 o Allow uRLLC service operator to access user admission and 807 authentication to its network slice in advance. 809 o The network coverage for a uRLLC service provisioning may be 810 limited to a confined area, either indoor or outdoor, network 811 operator needs to be able to coordinate resource allocation across 812 different access types and network domains. 814 A high-level Figure 9, shows a URLLC slice provider and service view 815 of the network. The monitoring of resources is done in the context 816 of performance. A performance degradation would require resource 817 adjustment. As shown in Figure 9, in one possible sliced model will 818 have its own customizer that uses internal performance observing 819 logic with in its slice by coordinating with different subnets/ 820 domains using southbound NS transport protocol and transfers this 821 information to operator via a northbound NS protocol for resource 822 adjustment. 824 It is implied that domains maybe different access technologies and 825 need for a common performance metric propagation and resource 826 allocation is important for a uRLLC slice to function properly. 828 +-----------------------------+ 829 | | 830 | +---------+ | uRLLC service +---------+ 831 | | Resource|<-----|---------------| uRLLC | 832 | +------ | Manager | | template | service | 833 | | +---------+ | +---------+ 834 | | +----------+--------+ | 835 | +->|Performance Monitor| | 836 | +---------+------^--+ | 837 | | | | 838 |------------------------|-+--+ 839 | | resource adjustment 840 | | 841 performance metrics| | 842 | | 843 uRLLC slice | v 844 +---------+-------------+-------------+ 845 | +--------+--+ +-----------+ | 846 | | Subs |<-->|uRLLC slice| | 847 | | Mgmt. | |Customizer | | 848 | +-------+---+ +---------^-+ | 849 | +-------+------------| | 850 | | | +---v-----+ + 851 | +--------+ +-------+ | micro | | 852 | | GC-1 | | GC-2 | | resource| | 853 | | subnet | | subnet| | mgr. | | 854 | +--------+ +-------+ +---------+ | 855 | | | | 856 +----+----------+---------+-------+---+ 857 | | | | 858 V V V V 859 ------------NS transport -------------- 860 | | | 861 V V V 862 +--------------+ +------------+ +----------+ 863 | Domain A | | Domain B | | Domain C | 864 +--------------+ +------------+ +----------+ 866 Figure 9: Reference for uRLLC Network Slice. 868 6.3. Critical Communications 870 Critical communications are associated with emergency situations. 871 Often referred to as mission critical, the communication has to be 872 reliable and non-disruptive. Different scenarios of critical 873 communications relate to public safety responders (e.g. fire 874 fighters, paramedics), military, utility or commercial applications, 875 mainly using reliable voice or short data messaging over wireless 876 communication systems. 878 Next-generation public safety communications are planned to be built 879 with enhanced broadband voice, data and video communications services 880 beyond narrowband LMR with broadband LTE networks for high speed data 881 (ref 22.179 and FirstNet). 883 3GPP defined on-network critical communication can be established 884 both via (a) over the network infrastructure to manage the call, (b) 885 off-network, where the terminals communicate directly to each other. 886 In the network slicing context, over the network, involves transport 887 networks for an always available, reliable, and zero packet loss 888 quality of traffic support to meet critical services requirements. 890 Maintaining a separate broadband infrastructure for critical 891 communications incurs a heavy deployment cost. Especially, as the 892 coverage of this separate network has to be extended to large-scale 893 nationwide geographies and remain interoperable is too expensive. As 894 new communication technologies emerge, public safety systems will 895 have to bear the state of the art adoption cost. A separate 896 infrastructure lacks flexibility to add new value-added services or 897 to take advantage of available commercial services. 899 While shared infrastructure, brings out challenges of these kind: 901 (1) Reliable support: Of basic mission critical services: Such as 902 loss of information in voice communication is not acceptable in 903 emergency services, if common infrastructure is to be used, it 904 must assure no loss of information. 906 (2) Zero congestion: It is not acceptable for critical calls to be 907 delayed at call setup times or be subjected to any other 908 congestion scenarios. 910 Having the Mission Critical Service (MCS) as a network slice benefit 911 from the following: 913 o Insertion and authorization of subscribers in a group 914 communication: In a critical infrastructure, the subscriber 915 authentication may be done earlier at the entry point 916 automatically through slice selection functional entity. 918 o Pre-allocated QoS Class Identifiers (QCIs): Generally, QCIs are 919 requested on per session basis which could slow down overall call 920 control setup and is undesirable for emergency services. When 921 operating in a slice, these resources maybe reserved ahead of time 922 in a coarse-grained manner instead of per session. 924 MCS network slices are relatively straight forward as it only 925 concerns with guaranteed bit rate (GBR) on per media basis and 926 management of groups. From transport they should be able to request 927 transport services based on GBR for reliable communication. A 928 reference network slice in Figure 10 below, shows a mission critical 929 (MC) organization providing service agreement through a network slice 930 template with resource specification. The MCS slice sets up 931 different subnetworks of different subscriber groups and manages its 932 membership. These subnets are realized into the infrastructure 933 across different domains through a network slice transport mechanism. 934 The MCS must be capable of active resource monitoring to prevent 935 congestions to ever occur as well as request additional transport 936 resources in case of emergency event occurrence. 938 +----------------------------------+ 939 | | 940 | +------------------+ | service +------------------+ 941 | | Slice Resource | |<-----------| Mission Critical | 942 | +--> | Manager |---+ | agreement | Organization | 943 | | +------------------+ | | +------------------+ 944 | | | | 945 | | +----------+-------+ | | 946 | +--->| Resource Monitor|<--+ | 947 | +---------+--------+ | 948 | ^ | | 949 |-----------+-------------+--------+ 950 | | 951 | Resource request 952 | | prioritized resource adjustment 953 MC Network|Slice v dynamic group management 954 +------------+------------+-------------+ 955 | +----------+-------+ +-----------+ | 956 | | Group Subs Mgmt.|<-->| MC slice | | 957 | | | | Customizer| | 958 | +---------+--------+ +-----------+ | 959 | | | | +-+ 960 | | | +---------+ + +-->| | 961 | +--------+ +-------+ | GRP | | +-+ MC-UE 962 | | GC-1 | | GC-2 | | selector| | +-+ 963 | | subnet | | subnet| +---------+ | --->| | 964 | +--------+ +-------+ | +-+ MC-UE 965 | | | | 966 +----+----------+---------+-------+-----+ 967 | | | | 968 V V V V 969 ------------NS transport ---------------- 970 | | | 971 V V V 972 ---------------- ---------------- ----------- 973 | Infrastructure | |Infrastructure | | MC server| 974 | Domain A | | Domain B | | Domain C | 975 ---------------- ---------------- ----------- 977 Figure 10: Reference for Mission Critical Network Slice. 979 7. Network Infrastructure for new technologies 981 7.1. ICN as a Network Slice 983 ICN as in Information-Centric Networking is a culmination of multiple 984 future Internet research efforts in various parts of the world, now 985 being pursued under IRTF's research task group called [ICNRG]. 987 Information-Centric Networking (ICN) addresses Internet's network 988 architectural design gaps based on evolving applications requirements 989 and end user behavior that is significantly different from what IP 990 was designed for - which was optimized for host-to-host communication 991 paradigm. ICN is a non-IP paradigm based on name-based routing and 992 offers many desirable networking features to applications such as 993 naming, security, caching, mobility, multicasting and computing in a 994 manner different from traditional host-centric communication model. 995 ICN's name-based abstraction to application minimizes bootstrap 996 configuration from the network, making it suitable to several 997 communication modalities such as multi-point-to-multi-point, AR/VR, 998 D2D and Ad hoc communication. 1000 7.2. New Verticals - ICN based service delivery 1002 Services over ICN slices can take advantage of its features such as: 1004 (1) In ICN, applications, services and content are addressed using 1005 names, hence end host resolution services like DNS can be 1006 avoided, this achieves name resolution to edge content or 1007 services without incurring additional RTT delays. 1009 (2) Service flows will be offered mobility and multicasting support, 1010 as the networking is session-less and optimized towards 1011 efficient movement of named data or networking named services 1012 and host level communication. 1014 (3) Services can be deployed at the very edges with ease as ICN 1015 routers are compute friendly, this is because states in the 1016 forwarding table can be that of either content or service 1017 resources. 1019 (4) Further saving bandwidth in the upstream link through 1020 opportunistic caching is an inherent feature of ICN, this also 1021 leads to energy efficient networking. 1023 When offered as a programmable and customizable logical network 1024 slice, ICN based services can be offered as a network slice in 1025 parallel with traditional IP based services. ICN can be realized as 1026 a slice [_5GICN_] based on the choice of data plane resource offered 1027 by the operators in different domains of the network such as the 1028 access, core network or main data centers. While the same resources 1029 can be used to support services over IP, proper resource isolation 1030 shall allow it to co-exist with ICN slices as well. ICN slices can 1031 be offered over a network slicing framework built upon a programmable 1032 pool of software and/or hardware based data plane resources. 1034 7.2.1. Required Characteristics 1036 In ICN, applications use Interest/Data or Get/Put abstractions over 1037 named resources resolved by ICN's routing plane. An ICN slice shall 1038 be a programmable ICN-domain, in which content learning and 1039 distribution will be done using existing or new ICN aware distributed 1040 routing logic or through centralized application controllers. As a 1041 result, it should be possible to deploy software or hardware based 1042 network functions such as ICN routers and content producers and 1043 distributors that serve and speak ICN protocols, or enabled through 1044 service gateways at the edges of the network. Just as multiple 1045 service instances can be part of a slice, an ICN slices can multiplex 1046 heterogeneous services; on the other hand an ICN slice can be as 1047 granular as a single service instance too. The latter approach has 1048 implications with respect to consumer privacy, access control of name 1049 data objects, and granularity of mobility handling [_5GICN_]. 1051 A basic ICN slice can be manifested as a resource isolated logical 1052 network while sharing resources with other connectivity or IP based 1053 service slices. An ICN slice relies on programmability and 1054 virtualization framework to manage the service slices, to allow 1055 maximum flexibility through ICN aware logically centralized control 1056 plane for ICN service and slice management. 1058 o Through a network slice template -ICN service providing entity 1059 could specify specific locations (edge of network domains) to 1060 deploy ICN-routers or other ICN-NFs (ICN aware network functions). 1061 Its service definition varies with the type of service. 1063 o Application driven connectivity between ICN network elements in 1064 all segments and create an ICN based virtual topology. 1066 o Mechanisms to deliver ICN user traffic over the infrastructure 1067 such as overlay or, ICN NFs can be tightly integrated with the RAN 1068 such as the eNodeB or implicitly using traffic classification 1069 function at the edge and tunneled to ICN User Plane Function 1070 (UPF). 1072 o In addition, bandwidth and other network resources may be 1073 requested from the underlay depending on its capability of 1074 providing deterministic or statistically guarantees. 1076 How multiple services will be deployed within an ICN aware slice may 1077 or may not be exposed to the network operator, depending on if the 1078 ICN slices are natively managed by it or a by other service 1079 providers. 1081 8. Overall Use Case Analysis 1083 The discussion in above use cases can be summarized as following in 1084 terms of the requirements for network slicing framework. 1086 8.1. Requirements Reference 1088 The following functional requirements are derived from discussions in 1089 above sections. They are described in details in 1090 [I-D.qiang-netslices-gap-analysis] document. 1092 The differentiated services described in this document demonstrate 1093 several common functionalities. Therefore, a homogeneous approach 1094 towards deployment and management is absolutely necessary. 1096 8.2. Mapping Common characteristics to Requirements 1098 (1) Resource Reservation: Compute and network resources are reserved 1099 as part of initial creation and subsequently during the 1100 maintenance of a slice. For example, a service may initially 1101 reserve resources for its own control plane, and then later it 1102 may reserve user plane flows for applications on demand. 1103 Reference use cases: Differentiated services discussed in 1104 section "Services with Resource Assurance". A network slice 1105 aware infrastructure shall be able to support mechanisms for 1106 elastic scaling (up/down) of resources and their non-disruptive 1107 provisioning. 1109 (2) Resource Assurance: A network slice aware infrastructure allows 1110 operators to allocate part of the network resources to meet 1111 stringent resource characteristics. Scenarios in both Section 5 1112 and Section 6 require on demand and dynamic adjustments. It may 1113 not be possible to achieve this using centralize or API approach 1114 with finer granularity of resources participating in constrained 1115 path computation. 1117 (3) Multi-dimensional service vertical: Network slicing supports 1118 dynamic multi-services, multi-tenancy and the means for backing 1119 vertical market players. 1121 (4) Multi-domain coordination: Multi-domain refers to different 1122 technology related network domains. For example, it may be RAN, 1123 DSL etc., mobile core network, ISP or different domains in 1124 transport networks such as carrier Ethernet, MPLS, TE-tunnel 1125 etc. Often, they are under same administrator's control but may 1126 require coordination across different administrations. 1127 Furthoremore, capabilities of each domain must be known in order 1128 to validate if a slice can be created or not. All scenarios 1129 mentioned require multi-domain coordination to connect and 1130 administer different subnets. 1132 (5) Operational Isolation: A network slice represents logical group 1133 of network resources, functions and corresponding configurations 1134 separating its behavior and hence operation from the underlying 1135 physical network. Each network slice may have its own operator 1136 that sees this slice as a complete network (i.e. with router 1137 instances, policies, programmability, placement of virtual 1138 network functions according to traffic patterns etc.) and can 1139 manage as its own network. 1141 (6) Transparency: Network slicing does not change the functionality 1142 of a scenario; It only facilitates creation of an isolated, an 1143 independently run infrastructure for that use case over a common 1144 network. Transparency promotes inter-operability and a common 1145 resource specification enables it. 1147 (7) Reliability: It is an important resource attribute in the type 1148 of service verticals described above. Many services verticals 1149 cannot deliver functionality unless the network is reliable (See 1150 remote industry operation, remote surgery and other uRLLC 1151 applications). In this regard, monitoring probes are needed of 1152 each network slice and resources associated with it. 1154 +-------------------------------------+----------------------------+ 1155 | Requirements Illustrated above | Aggregated Requirements | 1156 +-------------------------------------+----------------------------+ 1157 |1) Resource reservation | | 1158 |6) Transparency | Req 1. Network Slicing | 1159 |4) Multi-access knowledge | Specification | 1160 |3) Multi-dimensional service vertical| | 1161 +-------------------------------------+----------------------------+ 1162 |4) Multi-Domain coordination | Req 2. Network Slicing | 1163 | | Cross-Domain | 1164 |2) Resource Assurance | Coordination | 1165 +-------------------------------------+----------------------------+ 1166 | | Req 3. Network Slicing | 1167 |5) Operational/performance Isolation | Performance Guarantee| 1168 | | and Isolation | 1169 +-------------------------------------+----------------------------+ 1170 |7) Reliability | Req 4. Network Slicing OAM | 1171 +-------------------------------------+----------------------------+ 1173 Figure 11: Mapping Common Characteristics to Requirements 1175 NSaaS is a key for network operators to deploy network slices. 1176 Having standard means to realize these use cases, enables (a) 1177 different usecases to be uniformly understood by a network slice 1178 provider, and (b) similar use cases to be understood in a similar 1179 fashion by different network slice providers. Both these cases 1180 should allow common mechanisms to map and allocate network slices 1181 over the network infrastructure. 1183 Due to the availability of diverse technologies in control and data 1184 planes; the first step should be a top-down means to realize a slice 1185 with a common technology independent information model. It may 1186 describe a resource-centric slice with connectivity, storage, and 1187 compute resources, network functions, and operational requirements, 1188 that further get mapped to infrastructure resources and capabilities 1189 for run-time operations and monitoring. This model may be used by an 1190 orchestrator onboarding function for creating instances of network 1191 slice services and distributing to network infrastructure providers. 1193 9. Conclusion 1195 A service should typically need a network slice for one of those 1196 reasons: 1198 (1) The service cannot provide optimal experience on a best-effort 1199 network. 1201 (2) It is inefficient and expensive to build a separate 1202 infrastructure. 1204 The separation from a generalized network, should allow new services 1205 to use newer or different protocols in network, transport and 1206 management layer/plane for that service (as in the case of ICN, mMTC, 1207 uRLL). The goal of Network slices is to offer enriched service 1208 verticals with very different network capability and performance 1209 demands but also simplify from the traditional service delivery 1210 models. 1212 There is need for a uniform framework for end to end network slicing 1213 specifications that spans across multiple technology domains and can 1214 drive extensions in those technolgy-areas for support of Network 1215 slices. 1217 10. Security Considerations 1219 The security considerations apply to each kind of slice. In addition 1220 general security considerations of underlying infrastructure whether 1221 isolated communication with in a slice apply for links using wireless 1222 technologies. 1224 11. IANA Considerations 1226 There are no IANA actions requested at this time. 1228 12. Acknowledgements 1230 Note, the 5GEX L2VPN and L3VPN usecase is an independent contribution 1231 by authors and is not endorsed by 5GEX. Many thanks to the following 1232 reviewers for providing details for several use cases and for helping 1233 with the review of the document. 1235 Stewart Bryant (stewart.bryant@gmail.com), Hannu Flinck 1236 (hannu.flinck@nokia-bell-labs.com), Med Boucadair 1237 (mohamed.boucadair@orange.com), Dong Jie (dong.jie@huawei.com). 1239 13. References 1241 13.1. Normative References 1243 [I-D.bernardos-nfvrg-multidomain] 1244 Bernardos, C., Contreras, L., Vaishnavi, I., and R. Szabo, 1245 "Multi-domain Network Virtualization", draft-bernardos- 1246 nfvrg-multidomain-03 (work in progress), September 2017. 1248 [I-D.dt-detnet-dp-sol] 1249 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 1250 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 1251 "DetNet Data Plane Encapsulation", draft-dt-detnet-dp- 1252 sol-02 (work in progress), September 2017. 1254 [I-D.geng-netslices-architecture] 1255 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 1256 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 1257 Architecture", draft-geng-netslices-architecture-02 (work 1258 in progress), July 2017. 1260 [I-D.ietf-l2sm-l2vpn-service-model] 1261 Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data 1262 Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 1263 service-model-03 (work in progress), September 2017. 1265 [I-D.ietf-opsawg-service-model-explained] 1266 Wu, Q., LIU, W., and A. Farrel, "Service Models 1267 Explained", draft-ietf-opsawg-service-model-explained-05 1268 (work in progress), October 2017. 1270 [I-D.pularikkal-virtual-cpe] 1271 Pularikkal, B., Fu, Q., Hui, D., Sundaram, G., and S. 1272 Gundavelli, "Virtual CPE Deployment Considerations", 1273 draft-pularikkal-virtual-cpe-02 (work in progress), 1274 February 2017. 1276 [I-D.qiang-netslices-gap-analysis] 1277 Qiang, L., Martinez-Julia, P., 67, 4., Dong, J., 1278 kiran.makhijani@huawei.com, k., Galis, A., Hares, S., and 1279 S. Slawomir, "Gap Analysis for Transport Network Slicing", 1280 draft-qiang-netslices-gap-analysis-01 (work in progress), 1281 July 2017. 1283 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 1284 Model for L3VPN Service Delivery", RFC 8049, 1285 DOI 10.17487/RFC8049, February 2017, 1286 . 1288 13.2. Informative References 1290 [_5GICN_] IEEE Communication, "Delivering ICN Services in 5G using 1291 Network Slicing. 'Asit Chakraborti, Syed Obaid Amin, 1292 Aytac Azgin, Ravi Ravindran, G.Q.Wang'", May 2017, 1293 . 1295 [ICNRG] IRTF, "ICN Routing Group", November 2016, 1296 . 1298 [Tactile-Internet] 1299 ITU-T, "Technology Watch Report, The Tactile Internet", 1300 August 2014, . 1302 [TR_3GPP.33.899] 1303 3GPP, "Study on the security aspects of the next 1304 generation system", 3GPP TR 33.899 0.6.0, November 2016, 1305 . 1307 [TR_3GPP.38.801] 1308 3GPP, "Study on new radio access technology Radio access 1309 architecture and interfaces", 3GPP TR 38.801 1.0.0, March 1310 2017, . 1312 [TR_3GPP_38.913] 1313 3GPP, "Study on scenarios and requirements for next 1314 generation access technologies", 3GPP TR 38.913 14.2.0, 1315 March 2017, 1316 . 1318 [TS_3GPP.23.501] 1319 3GPP, "System Architecture for the 5G System", 3GPP 1320 TS 23.501 0.2.0, February 2017, 1321 . 1323 [TS_3GPP.23.502] 1324 3GPP, "Procedures for the 5G System", 3GPP TS 23.502 1325 0.2.0, February 2017, 1326 . 1328 [TS_3GPP.28.500] 1329 3GPP, "Telecommunication management; Management concept, 1330 architecture and requirements for mobile networks that 1331 include virtualized network functions", 3GPP TS 28.500 1332 1.3.0, 11 2016, 1333 . 1335 [VCPEBBF] Broadband Forum, "TR-345 Broadband Network Gateway and 1336 Network Function Virtualization", Dec 2016, 1337 . 1340 Authors' Addresses 1342 Kiran Makhijani 1343 Huawei Technologies 1344 2890 Central Expressway 1345 Santa Clara CA 95050 1346 USA 1348 Email: kiran.makhijani@huawei.com 1350 Jun Qin 1351 Huawei Technologies 1352 Huawei Campus, No. 156 Beiqing Rd. 1353 Beijing 100095 1355 Email: qinjun4@huawei.com 1357 Ravi Ravindran 1358 Huawei Technologies 1359 2890 Central Expressway 1360 Santa Clara CA 95050 1361 USA 1363 Email: ravi.ravindran@huawei.com 1364 Liang Geng 1365 China Mobile 1366 Beijing 100095 1367 China 1369 Email: gengliang@chinamobile.com 1371 Li Qiang 1372 Huawei Technologies 1373 Huawei Campus, No. 156 Beiqing Rd. 1374 Beijing 100095 1375 China 1377 Email: qiangli3@huawei.com 1379 Shuping Peng 1380 Huawei Technologies 1381 Huawei Campus, No. 156 Beiqing Rd. 1382 Beijing 100095 1383 China 1385 Email: pengshuping@huawei.com 1387 Xavier de Foy 1388 InterDigital Inc. 1389 1000 Sherbrooke West 1390 Montreal 1391 Canada 1393 Email: Xavier.Defoy@InterDigital.com 1395 Akbar Rahman 1396 InterDigital Inc. 1397 1000 Sherbrooke West 1398 Montreal 1399 Canada 1401 Email: Akbar.Rahman@InterDigital.com 1402 Alex Galis 1403 University College London 1404 London 1405 U.K. 1407 Email: a.galis@ucl.ac.uk 1409 Giuseppe Fioccola 1410 Telecom Italia 1411 Italy 1413 Email: giuseppe.fioccola@telecomitalia.it