idnits 2.17.1 draft-geng-coms-problem-statement-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 25, 2017) is 2404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.finn-detnet-architecture' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'I-D.qin-netslices-use-cases' is defined on line 385, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Geng 3 Internet-Draft China Mobile 4 Intended status: Informational S. Kuklinski 5 Expires: March 29, 2018 Orange 6 L. Qiang 7 Huawei Technologies 8 S. Matsushima 9 Softbank 10 A. Galis 11 University College London 12 Luis. Contreras 13 Telefonica 14 September 25, 2017 16 Problem Statement of Supervised Heterogeneous Network Slicing 17 draft-geng-coms-problem-statement-00 19 Abstract 21 This document discusses the general requirements and problem 22 statement of supervised heterogeneous network slicing. The purpose 23 of this document is to identify the key network components that are 24 used to create a network slice instance. Base on this information, a 25 general network slice template can be visualized. Furthermore, the 26 requirement of a common information model is identified and 27 corresponding management consideration of heterogeneous network slice 28 instance is also discussed. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 29, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. The components for a network slice instance . . . . . . . . . 4 68 2.1. Connectivity of network slice instance . . . . . . . . . 5 69 2.2. Computing for network slice instance . . . . . . . . . . 5 70 2.3. Storage for network slice instance . . . . . . . . . . . 6 71 2.4. Pre-defined function block for network slice instance . . 6 72 3. The requirements of common information model for supervised 73 heterogeneous network slice . . . . . . . . . . . . . . . . . 7 74 3.1. Management of heterogeneous network slice . . . . . . . . 8 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 7.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 The concept of network slicing is not new but energized greatly under 86 5G work in 3GPP. It is expected that further 5G network should be 87 capable of providing dedicated private network for different 88 verticals according to their specific requirements, which are created 89 by diversity of new services such as high definition (HD) video, 90 virtual reality (VR) and V2X applications. Looking at the 91 development of future network, no matter the service is connected via 92 5G cellular RAN, FTTx optical access network or other dedicated 93 connections, this resource dedication has become a fundamental 94 technology for services requiring extreme quality of user experience. 96 The best effort transport is not good enough as both subscribers and 97 application providers are looking for and willing to pay for certain 98 level of quality dedication. Therefore it is inevitable for service 99 providers (telecommunication infrastructure owners) to rethink the 100 means of management and operation of their networks, which should 101 support end-to-end slicing capabilities. 103 The requirements from different verticals may be extremely 104 diversified. Typical examples includes high bandwidth, low latency, 105 high level of isolation, specific security and encryption 106 requirements and etc. These requirements may also change dynamically 107 along time since the services of certain industry vertical changes 108 very fast, and sometime spontaneously (i.e. burst bandwidth/latency 109 requirement from on-line shopping provider on certain period). It is 110 expected that the configuration of certain network slice instances 111 are very dynamic in a case-by-case manner. Meanwhile, there are many 112 technology options to fulfil particular requirements depending on 113 considerations on many aspects including cost, TTM and etc. The 114 diversity of both requirements and technology options makes network 115 slices significantly heterogeneous. 117 In order to provide cost-effective and efficient network slice 118 configuration, service provider needs to understand specifically the 119 components it can make use to create a network slice instance and how 120 these components map with the customer requirements. These 121 components include both network resources and management entities. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119. 129 1.2. Terminology 131 Network Slice Instance - A network slice instance (NSI) is a managed 132 group of subsets of network resources, network functions and network 133 management entities, forming a complete instantiated logical/physical 134 network to meet certain network characteristics required by the 135 network slice tenant(s). A network slice instance may also be shared 136 across multiple services provided by the network slice tenant. It is 137 re-configurable and is managed by network slice provider. 139 Network Slice Provider - A network slicing provider (NSP), typically 140 a telecommunication service provider, is the owner or tenant of the 141 network infrastructures from which network slices are created. The 142 network slicing provider takes the responsibilities of managing and 143 orchestrating corresponding resource and management components that 144 the network slicing consists of. 146 Network Slice End-point - A network slice end-point (NSE) is a 147 network-slice-aware terminal, typically subscribed to the service 148 which is hosted in a network slice instance. A network slice end- 149 point may be capable of subscribing to multiple services hosted 150 independently in different network slice instance simultaneously. 152 Network Slice Tenant - A network slice tenant (NST) is the user of 153 specific NSIs, in which specific services are hosted and can be 154 provided to NSEs. Network slice tenants can make requests of the 155 creation of new network slice instances. Certain level of management 156 capability should be exposed to network slice tenant from network 157 slice service provider by pre-allocated outsource management 158 entities. 160 End-to-end Network Slice - A cross-domain network slice which may 161 consist of access network (fixed or cellular), transport network, 162 (mobile) core network and etc. End-to-end network slice can be 163 customized according to the requirements of network slice tenants 165 Network Function (NF) - A processing function in a network. It 166 includes but is not limited to network nodes functionality, e.g. 167 session management, mobility management, switching, routing 168 functions, which has defined functional behaviour and interfaces. 169 Network functions can be implemented as a network node on a dedicated 170 hardware or as a virtualized software functions. Data, Control, 171 Management, Orchestration planes functions are Network Functions. 173 Virtual Network Function (VNF) - A network function whose functional 174 software is decoupled from hardware. One or more virtual machines 175 running different software and processes on top of industry-standard 176 high-volume servers, switches and storage, or cloud computing 177 infrastructure, and capable of implementing network functions 178 traditionally implemented via custom hardware appliances and middle- 179 boxes (e.g. router, NAT, firewall, load balancer, etc.) 181 2. The components for a network slice instance 183 Fundamentally, NSIs are created based on the shared network 184 infrastructures. One can not create or define an NSI with components 185 that are not available in the shared infrastructure. Hence, it is 186 extremely important, both for NST and NSP, to understand a clear 187 scope of the usable components for NSI construction. An NSP can 188 therefore refer to this general scope to decide how each component 189 can be orchestrated and provided as a packaged network slice service 190 to NSTs. Based on this information, NSP can also further outline and 191 figure out the what capability each component can offer and how they 192 meet NST's demands. Overall, it is not possible to map the offered 193 capability of a network slice instance with the specific demands from 194 an NST if an NSP is not clear on what components and corresponding 195 characteristics can be provided. 197 Network slice instance consists of dedicated network resources which 198 are orchestrated using all the available components offered by a NSP 199 network. In general, the components that an NSP can use to create an 200 NSI include connectivity, computing, storage, and management entity. 202 2.1. Connectivity of network slice instance 204 Connectivity is one of the essential components for an NSI. It can 205 be as simple as a best effort point-to-point VPN or a dedicated 206 complex topology with other specific requirements including 207 bandwidth, latency and etc. The characteristics of the connectivity 208 component should include the following aspects. 210 o Connection topology - The description of connection topology of a 211 NSI. It should explicitly describe the connectivity relationship 212 between each access point of the NSI. An NSP should be able to 213 understand the overall connectivity requirement of an NSI from 214 this topology information. 216 o Bandwidth - The description of bandwidth requirements of specific 217 links within an NSI. The requirements includes exactly amounts of 218 assured bandwidth, maximum bandwidth and other bandwidth QoS- 219 specific requirements 221 o Latency - The description of link latency requirements within an 222 NSI. It should identify the exact amount of latency between a 223 link defined in connection topology. 225 o Determinism - The description of the determinism of a link 226 latency. This should be defined in addition to the latency, which 227 further specify the jitter of the latency for a given link. 229 o Isolation level - The description of isolation level of an NSI. A 230 NST may request logical isolation which can be mapped to 231 tunnelling technologies. It may also request explicitly a 232 dedicated lamda or even physical link for specific services. 234 2.2. Computing for network slice instance 236 If an NST would like to host virtualized functions in an NSI, it may 237 be interested in asking for specific computing resource including 238 both bare metal common servers and virtual machines. This resource 239 should also be specified considering the following characteristics. 241 o CPU resources - The physical and virtual CPU specifications a NST 242 may request a NSP to provide. 244 o GPU resources - The GPU specifications a NST may request a NSP to 245 provide. 247 o RAM resources - The RAM size associated with the requested 248 computing resources in a NSI. 250 Instead of providing bare metal resources, NSP may also provide 251 ready-to-used virtual machines and containers as part of the NSI. 252 This virtual resources need also be specified with virtulization 253 technology options, CPU/Virtual CPU requirements and etc. 255 2.3. Storage for network slice instance 257 It is necessary for NSP to provide storage components in an NSI since 258 NSTs may want to host contents on dedicated resources. Meanwhile, 259 NSP may also prefer to use dedicated storage for specific service 260 policies,authentication information and other management profiles. 262 o General storage - The description of storage resource in a NSI. 263 This may include the location, type, size and usage of the storage 264 resource. The general storage requirements may closely related to 265 the connectivity topology as well. 267 o CDN service - If an NSP can provide a turn-key CDN solution for 268 the NST. It can also include CDN service withing an NSI 270 2.4. Pre-defined function block for network slice instance 272 Many dedicated network functions, either physical or virtual, may 273 requested by a NST. Typical example include common network functions 274 as DHCP server, DNS, NAT, Firewall, SDN controller. Application- 275 level functions may also exist in a NSI, such as session management, 276 mobility management and etc. NSP should be able to provide such pre- 277 defined function blocks according to NST's request. 279 o Physical network function blocks- The description of dedicated 280 physical network functions. Physical network functions are 281 network equipments with dedicated software and hardware, which are 282 strictly coupled for the purpose of a providing specific network 283 function. 285 o Virtual network function blocks- The description of virtualized 286 network functions. VNFs are software entities which are normally 287 hosted within pre-allocated virtual machines (or containers). The 288 virtual resources which are required by the VNF should be also 289 specified in terms of computing resources as described previously. 291 3. The requirements of common information model for supervised 292 heterogeneous network slice 294 As NSTs are not expected to be "network experts", the requirements 295 injected to a NSP may be diversified in forms. NSP may have 296 different preferences for the network slice service model provided to 297 potential NSTs. However, there is a need for a common information 298 model which explicitly describes the components and parameters within 299 a NSI. 301 Slice Tenant 302 | 303 +---------------v------------------+ 304 | Slice Provider | 305 +---------------+------------------+ 306 | 307 +---------------v------------------+ 308 | Slice Manager | 309 | +------------------------+ | 310 | |Common Information Model| | 311 | +------------------------+ | 312 +----------------------------------+ 313 | | 314 +------------|---------v-------------------------+ 315 | | | 316 | +----------|---------------------------+ | 317 | | +--------v-------+ +--------------+ | | 318 | | | Mngt Agent | |IntraNS Mngt | +----+ | 319 | | +----------------+ +--------------+ | | | 320 | | +---------------------------------+ | | | 321 | | | Connectivity, Computing | | | | 322 | | | Storage, Pre-defined Functions | | | | 323 | | | | | | | 324 | | +---------------------------------+ | | | 325 | | NSI | | | 326 | +----+---------------------------------+ | | 327 | | NSI | | 328 | +--------------------------------------+ | 329 | Network Infrastructure | 330 +------------------------------------------------+ 332 Figure 1: Supervised heterogeneous network slice 334 As seen in Figure 1. The common information model is used to 335 describe a NSI according to the service model provided by NSTs. It 336 is then further de-composited to models that are used by various 337 management domain within the NSP's network infrastructure. 339 3.1. Management of heterogeneous network slice 341 The network slice management include two levels. One is network- 342 slice level management which is maintained by NSP, the other is 343 intra-slice management which is maintained by NST but supervised by 344 NSP. 346 o Network slice management agent - This is the NS-level management 347 agent provided by NSP. Each created NSI should have a logical 348 entity serving as a network slice management agent. It executes 349 the OAM messages received from the NSP network slice manager 350 including life-cycle management, monitoring and etc. A profile of 351 the created NSI should also be maintained within this agent, where 352 the status of each element can be managed. 354 o Intra-slice management - As per agreement between NST and NSP, 355 intra-slice management may be provide by NSP to oversee an given 356 NSI as a general private network. NST are authorized to use this 357 management capability to maintain the NSI. The NSI-level 358 information is transparent to intra-slice management, which means 359 the management system does not know the existence of network slice 360 instances. The exposed management capability should be supervised 361 by the NSP, so that the NSI will not violate NSI-level policies. 362 Meanwhile, intra-slice management 364 o 366 4. IANA Considerations 368 This document makes no request of IANA. 370 5. Security Considerations 372 Each layer of the system has its own security requirements. 374 6. Acknowledgements 376 7. References 378 7.1. Normative References 380 [I-D.finn-detnet-architecture] 381 Finn, N. and P. Thubert, "Deterministic Networking 382 Architecture", draft-finn-detnet-architecture-08 (work in 383 progress), August 2016. 385 [I-D.qin-netslices-use-cases] 386 Qin, J., kiran.makhijani@huawei.com, k., Dong, J., Qiang, 387 L., and S. Peng, "Network Slicing Use Cases: Network 388 Customization for Different Services", draft-qin- 389 netslices-use-cases-00 (work in progress), March 2017. 391 7.2. Informative References 393 [NS_WP] China Mobile Communication Corporation, Huawei 394 Technologies Co. Deutsche Telekom AG,Volkswagen, "5G 395 Service-Guaranteed Network Slicing White Paper", 2016, 396 . 399 Authors' Addresses 401 Liang Geng 402 China Mobile 403 Beijing 404 China 406 Email: gengliang@chinamobile.com 408 Slawomir Kuklinski 409 Orange 411 Email: slawomir.kuklinski@orange.com 413 Li Qiang 414 Huawei Technologies 415 Huawei Campus, No. 156 Beiqing Rd. 416 Beijing 100095 418 Email: qiangli3@huawei.com 420 Satoru Matsushima 421 Softbank 423 Email: satoru.matsushima@g.softbank.co.jp 425 Alex Galis 426 University College London 428 Email: a.galis@ucl.ac.uk 430 Luis Miguel Contreras Murillo 431 Telefonica 433 Email: luismiguel.contrerasmurillo@telefonica.com