idnits 2.17.1 draft-geng-coms-problem-statement-04.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 (March 5, 2018) is 2241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NONE L. Geng 3 Internet-Draft China Mobile 4 Intended status: Informational S. Kuklinski 5 Expires: September 6, 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 March 5, 2018 16 Problem Statement of Common Operation and Management of Network Slicing 17 draft-geng-coms-problem-statement-04 19 Abstract 21 This document discusses the problem statement of Common Operation and 22 Management of Network Slicing (COMS). The purpose of this document 23 is to identify the problem space of COMS and discuss the approach 24 COMS is using to match the top-down network slice management concern 25 with the underlay technologies. Furthermore, the role of a common 26 information model is introduced and corresponding design principles 27 are also discussed. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 6, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. The Concept of COMS and Problem Space . . . . . . . . . . . . 4 67 3. How Top-down Matches with Bottom-up approach . . . . . . . . 6 68 4. Resources under Supervision of COMS . . . . . . . . . . . . . 7 69 4.1. Connectivity Resources . . . . . . . . . . . . . . . . . 7 70 4.2. Computing Resources . . . . . . . . . . . . . . . . . . . 8 71 4.3. Storage Resources . . . . . . . . . . . . . . . . . . . . 8 72 4.4. Service Function . . . . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 The concept of network slicing is not new but energized greatly under 84 the 5G work in 3GPP. It is expected that further 5G network should 85 be capable of providing dedicated private network for different 86 verticals according to their specific requirements, which are created 87 by diversity of new services such as high definition (HD) video, 88 virtual reality (VR) and V2X applications. Looking at the 89 development of future network, no matter the service is connected via 90 5G cellular RAN, FTTx optical access network or other dedicated 91 connections, this resource dedication has become a fundamental 92 enabler for services requiring extreme quality of user experience. 93 The best effort transport is not good enough as both subscribers and 94 application providers are looking for and willing to pay for certain 95 level of dedication. Therefore it is inevitable for service 96 providers (i.e. Telecommunication infrastructure owners) to rethink 97 the means of management and operation of their networks, which should 98 support end-to-end slicing capabilities. 100 The requirements from different verticals may be extremely 101 diversified. Typical examples includes high bandwidth, low latency, 102 high level of isolation, specific security and encryption 103 requirements and etc. These requirements may also change dynamically 104 along time since the services of certain industry vertical change 105 very fast, and sometime spontaneously (i.e. burst bandwidth/latency 106 requirement from on-line shopping provider during sale period). It 107 is expected that the configuration of certain network slice instances 108 are very dynamic in a case-by-case manner. Meanwhile, there are many 109 technology options to fulfil particular requirements depending on 110 considerations on many aspects including cost, TTM and etc. The 111 diversity of both requirements and technology options make the 112 management of network slices significantly heterogeneous. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 1.2. Terminology 122 Network Slice - A set of infrastructure resources and service 123 functions that has attributes specifically designed to meet the needs 124 of an industry vertical or a service. 126 Network Slicing - A management mechanism that Network Slice Provider 127 can use to allocate dedicated infrastructure resources and service 128 functions to Network Slice Tenant. 130 Network Slice Provider - A network slice provider (NSP), typically a 131 telecommunication service provider, is the owner or tenant of the 132 infrastructures from which network slices can be created. The 133 network slice provider takes the responsibilities of managing, 134 orchestrating and monitoring the corresponding resources to implement 135 a network slice and provide the Network slice tenant certain level of 136 management capability. 138 Network Slice Tenant - A network slice tenant (NST) is the user of 139 specific network slice, in which customized services are hosted. 140 Network slice tenants can make requests of the creation of new 141 network slice through a COMS service model. This request will be 142 delivered to network slice orchestrator via service delivery model 143 for service implementation purposes. 145 2. The Concept of COMS and Problem Space 147 COMS is a management mechanism where an NSP can use to allocate 148 dedicated network infrastructures and service functions to an NST. 149 This dedication may be presented in various forms depending on 150 specific NSP's network availabilities. Typical examples include 151 physical and logical isolation of network connectivity, bare metal or 152 virtualized computing resources, dedicated storage resources and 153 specific pre-define service functions such as NAT server, SDN 154 controller and etc. COMS gives the NSP full flexibility to either 155 logically or physically lease a partition of their resources to the 156 NST with required functionalities and performances. It is 157 anticipated that new business models may be created with COMS. More 158 flexible, elastic and modularized resource allocation capability 159 enables a network slice to be offered as a service to end users in a 160 much finer granularity. For instance, a network with certain 161 bandwidth and latency guarantee and dedicated connections to required 162 data center nodes can be provided as turn-key service to a HD video 163 content provider who would like to implement it service on the NSP's 164 network. In this model, the NSP will use COMS to coordinate the 165 underlay heterogeneous resources to deliver this network slice as a 166 service (NSaaS). 168 Customer Service 169 +-----------+ Interface (CSI) +-----------+ 170 | NST +------------------+ NSP | 171 |(Customer) | | | 172 +-----------+ +------+----+ 173 | 174 | Service Delivery 175 | Interface (SDI) 176 | 177 +-----------------------------------+-------------+ 178 | Network Slice Orchestrator (NSO) | 179 +---------|------------+-------------------+------+ 180 SDI | | | 181 +------|-----+ | | 182 | NSO | | | 183 +------------+ | | 184 Network Configuration Model 185 ~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~ 186 Available NS-aware | | 187 Technologies | | 188 +-----------------------+-+ +------------+------------+ 189 |Controller/Orchestrator/ | |Controller/Orchestrator/ | 190 |Manager of Implementation| |Manager of Implementation| 191 |Technology A | |Technology B | 192 +---------------+---------+ +-------------+-----------+ 193 | | 194 | Device Configuration Model | 195 +---------------+----------------------------+-------------+ 196 | Underlying Network Resources/Functions | 197 +----------------------------------------------------------+ 199 Figure 1: Schematic Diagram of COMS 201 Figure 1 illustrated the concept of how COMS is implemented within a 202 heterogeneous network. A customer (NST) request NSaaS via service 203 model. The service model describe the network slice in user's 204 language. This model is technology-agnostic. A NSP translates the 205 service profile to service delivery model which describe how a NSP 206 engineering it's resource for the service. The service delivery 207 model is sent to the network slice orchestrator, where it is further 208 decomposed to network configuration model in different technology 209 domains. Finally the device configuration models are used to setup 210 the parameters of the underlay infrastructures and functions. 212 COMS focuses on the cross-domain management of network infrastructure 213 and service functions which are considered as elements of a given 214 network slice. COMS will only design service model and service 215 delivery models for network slice services. It will not try to 216 duplicate works in existing WGs regarding network configuration 217 models and device configuration models. The associated the slice- 218 level operation, administration and maintenance will also be the 219 concern of COMS. 221 3. How Top-down Matches with Bottom-up approach 223 COMS indeed takes a top-down approach to look at the management of 224 network, where the requirement of network slice and its management 225 are triggered by new vertical industry services and business model. 226 However, this top-down approach does not directly ask for any 227 specific new forwarding technology. It asks for a slice-level 228 management which coordinates various underlay technology domains to 229 enable NSaaS. Nowadays, existing IETF technologies either evolves 230 (e.g. DETNET) or naturally support (e.g. VPN) certain resource 231 dedication mechanism in a bottom-up view. This is in line with the 232 concept of network slicing. However, A big problem is that IETF has 233 little tools for cross-domain management 234 [draft-arkko-arch-virtualization], without which the creation of an 235 end-to-end network slicing would not be possible. COMS makes the 236 convergence between top-down and bottom-up view of network slicing. 238 +--------------------------------------+ 239 | Service & Service Delivery Model | 240 | | 241 +--------------------------------------+ 242 Provide Design /|\ 243 Guidance | 244 +-----------------------------+ 245 | | 246 | COMS Information Model | 247 | | 248 +-----------------------------+ 249 | | | 250 | \|/ | 251 | +--------------+ \|/ 252 | | Subset +------------------+ 253 \|/ | 1 | | Subset | 254 +-----------+ | | 3 | 255 | Subset | | | | | 256 | 2 | | +------------------+ 257 | | | | 258 | +--------------+ 259 | | 260 +-----------+ 262 Figure 2: COMS Information Model Design Principle 264 The information model of COMS serves as the key element for this 265 convergence. It provides guidance for the design of service deliver 266 model. And it also provides slice-level abstraction reference for 267 existing IETF forwarding technologies. This mean the although COMS 268 does not directly define network configuration model for each domain. 269 The models defined elsewhere should refer to COMS information model 270 in order to be used as a part of a network slice. This information 271 model is than a comprehensive set of abstraction. Each single 272 technology typically refer to a subset of this information model for 273 slice-level abstraction process. 275 4. Resources under Supervision of COMS 277 In order to provide cost-effective and efficient network slice 278 configuration, service provider needs to understand specifically the 279 components it can make use to create a network slice instance and how 280 these components map with the customer requirements. These 281 components include both infrastructure resources and service 282 functions. There are many existing technologies which focus on the 283 management of those entities. For example, various type of domain 284 SDN controllers supervise the connectivity resources within each 285 technology or geographical domains, and MANO supervises the NFV 286 infrastructures. In contrast, COMS provides an end-to-end management 287 mechanism which integrate various underlay technology domains to 288 create a network slice. It oversees all these resources and decides 289 the placement of specific resources according to certain path and 290 topology constraints. 292 COMS does not have any particular constraints on what type of 293 resources it manages. This is defined by its information model and 294 will have to adapt to what a NST really needs. Meanwhile, whether a 295 certain type of resource is available to be used in COMS is subjected 296 to NSP's policy. However, for the ease of management and operation, 297 it is worthy to have a guideline to categorize the common resources 298 that NSP may offer to NST as a network slice service. This section 299 endeavours to provide a prototype catalogue of the resource 300 components for network slice creation. More detailed description can 301 be found in [draft-qiang-coms-netslicing-information-model-02] In 302 general, the components that an NSP can use to create a network slice 303 include connectivity, computing, storage infrastructures and service 304 functions. 306 4.1. Connectivity Resources 308 Connectivity is one of the essential components for a network slice. 309 It can be as simple as a best effort point-to-point VPN or a physical 310 link using a dedicated wavelength. It may also have more complex 311 topology with other specific requirements including bandwidth, 312 latency and etc. 314 4.2. Computing Resources 316 If an NST would like to host virtualized functions in a network 317 slice, it may be interested in asking for specific computing resource 318 including both bare metal servers and virtual machines. 320 4.3. Storage Resources 322 It is necessary for NSP to provide storage components in a network 323 slice since NSTs may want to host contents on dedicated resources. 324 Meanwhile, NSP may also prefer to use dedicated storage for specific 325 service policies, authentication information and other management 326 profiles. 328 4.4. Service Function 330 Many dedicated service/network functions, either physical or virtual, 331 may requested by a NST. Typical example include common network 332 functions as DHCP server, DNS, NAT, Firewall, SDN controller. 333 Application- level functions may also exist in a network slice, such 334 as session management, mobility management and etc. NSP should be 335 able to provide such service function blocks according to NST's 336 request. 338 5. IANA Considerations 340 This document makes no request of IANA. 342 6. Security Considerations 344 TBD 346 7. Acknowledgements 348 The author would like to thank Benoit Claise, Xavier de Foy,Warren 349 Kumari, Jari Arkko and Jeff Tantsura for discussion on this work. 351 8. References 353 8.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 8.2. Informative References 362 [draft-arkko-arch-virtualization] 363 "Considerations on Network Virtualization and Slicing", 364 . 367 [draft-qiang-coms-netslicing-information-model-02] 368 "Considerations on Network Virtualization and Slicing", 369 . 372 Authors' Addresses 374 Liang Geng 375 China Mobile 376 Beijing 100053 377 China 379 Email: gengliang@chinamobile.com 381 Slawomir Kuklinski 382 Orange 384 Email: slawomir.kuklinski@orange.com 386 Li Qiang 387 Huawei Technologies 388 Huawei Campus, No. 156 Beiqing Rd. 389 Beijing 100095 390 China 392 Email: qiangli3@huawei.com 394 Satoru Matsushima 395 Softbank 397 Email: kiran.makhijani@huawei.com 398 Alex Galis 399 University College London 400 London 401 U.K. 403 Email: a.galis@ucl.ac.uk 405 Luis Miguel Contreras Murillo 406 Telefonica 408 Email: luismiguel.contrerasmurillo@telefonica.com