idnits 2.17.00 (12 Aug 2021) /tmp/idnits37890/draft-qiang-coms-use-cases-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 (February 02, 2018) is 1562 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 Network Working Group L. Qiang 3 Internet-Draft Huawei Technologies 4 Intended status: Informational L. Geng 5 Expires: August 6, 2018 China Mobile 6 K. Makhijani, ed 7 Huawei Technologies 8 X. de Foy 9 InterDigital Inc. 10 A. Galis 11 University College London 12 February 02, 2018 14 The Use Cases of Common Operation and Management of Network Slicing 15 draft-qiang-coms-use-cases-00 17 Abstract 19 The Common Operation and Management of network Slicing (COMS) intends 20 to provide a comprehensive approach for the overall operation and 21 management of network slicing in the scope if IETF. The system is 22 designed in a hierarchical and inter-operative manner. COMS is 23 capable of recursive adaption in a hierarchical network management 24 system. It is also independent of data plane technologies used in 25 different administrative domains. Both network slice operator and 26 network slice tenant may benefit for COMS for the purpose of slice 27 management and maitenance.The purpose of this document is to discuss 28 the use cases of COMS in different views. 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 August 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Heterogeneous Resource Management for Network Slicing . . . . 4 67 2.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 4 68 2.1.1. Combination of Networking and Computing . . . . . . . 4 69 2.1.2. Technology Diversity of Network Infrastructure . . . 5 70 2.1.3. Network and Service Functions Variety . . . . . . . . 6 71 2.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 6 72 3. Interoperation between Multiple Slice-aware Administrative 73 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 6 75 3.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 7 76 4. End-to-end Orchestration of Network Slicing . . . . . . . . . 7 77 4.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 7 78 4.1.1. Resource Registration . . . . . . . . . . . . . . . . 7 79 4.1.2. Life-cycle Management . . . . . . . . . . . . . . . . 8 80 4.1.3. Network Slice Template and Repository . . . . . . . . 9 81 4.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 9 82 5. Customized OAM for Network Slice Tenant . . . . . . . . . . . 9 83 5.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 9 84 5.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 10 85 6. Interaction with 3GPP Network Slicing . . . . . . . . . . . . 10 86 6.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 10 87 6.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 10 88 7. Network Slice FCAPS . . . . . . . . . . . . . . . . . . . . . 10 89 7.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 11 90 7.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 11 91 8. Network Slice Stiching and Recursion . . . . . . . . . . . . 11 92 8.1. Use Case Introduction . . . . . . . . . . . . . . . . . . 11 93 8.2. Use Case Analysis . . . . . . . . . . . . . . . . . . . . 11 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 96 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 97 12. Normative References . . . . . . . . . . . . . . . . . . . . 11 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 100 1. Introduction 102 Network Slicing is a mechanism which a network slice provider can use 103 to allocate dedicated infrastructures and services from shared 104 systems to a network slice tenant. COMS acts as a technology- 105 independent and resource-centric approach according to which the 106 operation and management of network slice can be performed. 108 This document lists the use cases of COMS from various OAM aspects of 109 network slicing. It provides a general reference of how COMS may be 110 used from both network slice provider and network slice tenant 111 viewpoint. The COMS community (the proposed WG) will consider these 112 use cases and decide which related technology is going to be 113 investigated under the problem scope of COMS. 115 All of the use cases are introduced in this document followed by a 116 brief analysis regarding the relationship with COMS. As the document 117 is being continuously worked on, the list of use cases is as follows: 119 o Heterogeneous Resource Management for Network Slicing 121 o Interoperation between Multiple Slice-aware Administrative Domain 123 o End-to-end Orchestration of Network Slicing 125 o Customized OAM for Network Slice Tenant 127 o Interaction with 3GPP Network Slicing 129 o Network Slice FCAPS - to be specified in -01 version 131 o Network Slice Stiching and Recursion - to be specified in -01 132 version 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2. Heterogeneous Resource Management for Network Slicing 142 2.1. Use Case Introduction 144 Network slice is a specific partition of resources. The resources 145 are deliberately associated together for the purpose of fulfilling 146 both functional and performance requirements of various applications. 147 Heterogeneity is the nature of those underlay resources based-on 148 which network slices are created. In order to provide end-to-end 149 orchestration of network slices, it is required that all resources 150 are manageable by a network slice provider. COMS will be used as the 151 fundamental technology for the purpose of heterogeneous resource 152 management. 154 2.1.1. Combination of Networking and Computing 156 Networking used to be the absolute major asset and resources of a 157 telecommunication service provider. As the rapid development of 158 cloud computing and NFV technology in recent years, computing 159 infrastructures such as data center, distributed edge cloud, CDN and 160 cache facilities start to play more and more important roles. 161 Nowadays, not only is the amount of data centers dramatically growing 162 in service providers' network, but also network/service functions are 163 migrating to NFV deployment, which depends heavily on common 164 computing and storage resources. An obvious trend of more 165 interactive relationship between networking and computing resources 166 (computing resource referred in this section also includes storage 167 resources) deployment is seen worldwide. 169 The goal of network slicing is to provide a "turn-key" solution for 170 vertical application provider, where certain performance and 171 functional demands can be met according to specific SLAs. This is 172 achieved by providing infrastructure and functional dedication to 173 vertical application providers. It is expected that a vertical 174 application provider, as a network slice tenant, will purchase a 175 network slice which is equipped with both preferred connectivity 176 topology and associated computing/storage resources. Hence, the 177 vertical application provider is able to deploy whatever applications 178 according to its preference. 180 Relying on the underlay network infrastructure, computing resource 181 has become an inevitable part of the network slice. In general, it 182 may comes in various forms in a manner of IaaS as follows. 184 o Bare metal equipment with required specifications 186 o Hypervisor-based virtual machine 187 o Container-based infrastructures 189 o Other customized type of presentation of computing resources 191 Under the regime of network slicing, computing (including storage) 192 resources provided in any form above need to be specified with 193 geographical or logical location information. These computing 194 resources may distributed among the network slice topology as 195 terminal or intermediate network nodes. This location information is 196 essential for the purpose of associating these resources with 197 connectivity components within a network slice. 199 It is not always easy to jointly manage both computing resources and 200 the underlay networking. Connectivity is normally supervised by 201 using traditional EMS of the connected devices, or by using more 202 advanced SDN approaches for more advanced systems. In contrast, 203 computing resources are typically managed by VIMs. A manager who 204 understands both EMS/SDN controller and VIMs is requirement for 205 overall orchestration of an end-to-end network slice. 207 2.1.2. Technology Diversity of Network Infrastructure 209 Due to architectural and commercial reasons, the underlay technology 210 choices for different administrative domains are unlikely to be the 211 same. For example, regional administrative domains may be favor of 212 choosing single-vendor solutions for its backbone network. This 213 minimize the complexity of intra-domain OAM. However, adjacent 214 regional administrative domains may use equipments from different 215 vendors. This makes the overall backbone network infrastructure 216 resources heterogeneous. The technology diversity of the resource 217 consisting a network slice mainly results from the following reasons. 219 o Various technology choices for access, aggregation and backbone 220 networks 222 o Legacy equipments due to deployment iteration 224 o Administrative concerns caused by geographical reasons 226 o Vendor-specific technology for customized deployment 228 It is common for an end-to-end network slice asking for resources 229 from various administrative domains with distinctive technology 230 options. This include data plane, control plane and management plane 231 technologies. COMS, as an management tool, can be used for operation 232 and management of such systems. 234 2.1.3. Network and Service Functions Variety 236 A complete network slice may consist of many types of network ans 237 service functions. This functions are likely to be deployed either 238 in NFV or physical forms. In practice, virtualized network functions 239 are managed by VNFM under MANO system, whilst physical network 240 functions are managed by resource management system (RMS). 241 Meanwhile, the management plane of service functions is even more 242 diversified which may associated with extremely customized service 243 management platforms. 245 In order to make network and service function usable and manageable 246 as a part of network slice, it is necessary to have an overall 247 management system on which the orchestration of such functions can 248 rely. Existing technology such as SFC already provides a 249 comprehensive solution for the purpose of service-level integration. 250 It would be interesting to investigate how underlay network 251 infrastructure can better serve and map with requirements of 252 particular SFC or interconnection between SFCs under network slice 253 regime. Such system should be capable of associating service 254 function resources to required network infrastructure, making the 255 formation of an end-to-end network slice possible. 257 2.2. Use Case Analysis 259 It is always preferred to have more diversified resources on which 260 network slices can be built. Heterogeneity becomes an inevitable 261 issue caused by this nature of variety. At present, countless 262 management systems are being used by service providers for different 263 types of resource domains. COMS may help to aggregate and coordinate 264 the management plane of such systems and provide unified slice-level 265 OAM. 267 3. Interoperation between Multiple Slice-aware Administrative Domain 269 3.1. Use Case Introduction 271 As mentioned in section 2, the slice orchestrator need to supervise 272 heterogeneous resources in various administrative domains in response 273 to diversified demand from the network slice tenants. For example, 274 the network slice orchestrator needs to supervise some heterogeneous 275 technology domains, which obviously have separated administrative 276 systems. Examples include optical transport network, IP routing 277 network in terms of network infrastructure and SFCs in terms of 278 service function. Administrative domain may also isolated for 279 technology-evolution reasons. For instance, the slice orchestrator 280 is necessary to be compatible with either controller-based networks 281 or EMS-based networks. Furthermore, as computing plays more and more 282 significant role as infrastructure resource, the requirement of 283 coordinating between networking and computing in management plane is 284 obvious. 286 3.2. Use Case Analysis 288 Either it is a green field implementation or not, given the 289 heterogeneity property of resources, the administrative domains can 290 only be more diversified. Meshed interoperation between these 291 administrative domains is infeasible. Hence, a higher level 292 management entity is one of the most cost effective and straight 293 forward solution. 295 4. End-to-end Orchestration of Network Slicing 297 4.1. Use Case Introduction 299 When a network slice tenant purchases a network slice service, it 300 does not necessarily know the what underlay resources exactly are 301 allocated for the purpose of the network slice creation. It is the 302 network slice orchestrator who takes care of this process. As the 303 network slice orchestrator receives network slice service delivery 304 model from service provider's OSS/BSS, it executes slice-level 305 operation and management accordingly. End-to-end orchestration is an 306 essential part of this process. 308 The main functionality of end-to-end network slice orchestration may 309 include the following aspects: 311 1. Coordinating underlay network infrastructure and service function 312 resources 314 2. Life-cycle management, which includes the common operation of 315 network slice creation, activation/de-activation, modification, 316 deletion and status monitoring. 318 3. Pre-defining templates of common types of network slices and 319 provide repository for network slice instances created by 320 templates or full customization 322 4.1.1. Resource Registration 324 In the process of end-to-end orchestration of network slice, resource 325 registration is one of the fundamental prerequisite. The network 326 slice orchestrator needs to know exactly what resources are available 327 under the overall management. The information for resource 328 registration may include the the following aspects: 330 o The type of resources (whether it is a connectivity, computing, 331 storage or pre-defined network/sevice function) 333 o The physical/logical location of the resources 335 o Data plane and control plane technology capabilities 337 o Performance capabilities 339 o Availability information 341 o Domain topology information 343 The network slice orchestrator can only use registered resources in 344 the process of network slice creation. Any change of resource 345 information caused by equipment upgrading, new deployment or 346 abolishing of legacy system need to be reported to the network slice 347 orchestrator. 349 4.1.2. Life-cycle Management 351 It is important that the network slice orchestrator can continuously 352 manage the creation, activation/de-activation, modification, deletion 353 and status monitoring processes of the network slice for a complete 354 life cycle. In general, a network slice profile can be created in 355 several ways: 357 o A network slice profile can be created according to the network 358 slice templates. In this way, the network slice profile is create 359 by direct configuration of the parameters in a pre-defined network 360 slice template according to exciting index. 362 o A network slice profile can be created by customized parameter 363 index and value. 365 In both cases, the value of parameters come from the service delivery 366 interface of the network slice orchestrator. Particularly for the 367 latter case, a complete network slice profile is needed from the 368 service delivery interface. 370 Additionally, the operation of life cycle management also comes from 371 the OSS/BSS service delivery model. After receive such operation 372 request, the orchestrator need to map certain them to different 373 administrative domains respectively. 375 4.1.3. Network Slice Template and Repository 377 As mentioned in section 3.1.2, network slice orchestrator can use 378 templates to create network slice profiles. Templates are extremely 379 useful in cases where multiple network slice tenants require exact 380 same type of network slices. For example, URLLC is regarded as one 381 of the most popular scenario in 5G application. It would be useful 382 to pre-define a URLLC network slice template, to which the network 383 slice orchestrator can refer, upon request of network slice tenants. 385 A network slice repository make it handy to manage the templates of 386 different types. It also helps to categorize different network slice 387 profiles created under given templates. A category of "Customized 388 network slice" might also be useful for the cases where network slice 389 is created from scratch. 391 4.2. Use Case Analysis 393 End-to-end orchestration is the most essential functionality of 394 network slicing management. COMS information model will act as a 395 significant reference for resource registration, network slice 396 template definition and and the creation of network slice profile. 397 At the same time, life-cycle management will be enabled by the COMS 398 service delivery model. 400 5. Customized OAM for Network Slice Tenant 402 5.1. Use Case Introduction 404 As a network slice instance is activated, the network slice tenant is 405 able to access the network slice and apply intra-slice configuration 406 under network slice provider's policies. This include operation and 407 management functionalities, which are likely to be a subset of the 408 overall network slice management. Typical functionalities a network 409 slice tenant may prefer to have include the following aspects: 411 1. Network slice life-cycle status monitoring 413 2. Performance dash board of individual/set of resource components 414 in a network slice 416 3. Slice-level parameter adjustments under network slice providers' 417 policies, strictly avoiding conflicts with other network slices. 419 4. Slice subset operation and management based on COMS at network 420 slice provider's permission 422 5.2. Use Case Analysis 424 The network slice orchestrator has two NBI interfaces respectively. 425 One of them is designed for the purpose of customized OAM. A network 426 slice tenant may use this interface to perform the actions listed in 427 section 5.1. COMS is in the position of defining the NBI interface 429 6. Interaction with 3GPP Network Slicing 431 6.1. Use Case Introduction 433 3GPP is the born-place of the concept of 5G network slicing. However 434 in 3GPP, only radio access network and core network are considered as 435 the resource pool for network slices. The transport network is 436 modelled as a link between them. Technically in 3GPP language, 437 network slicing does not include transport network. 439 In 5G, the requirements of network slicing focus on the guaranteed 440 end-to-end quality in terms of Bandwidth (eMBBs), Latency (URLLC) and 441 connections (eMTC). For the purpose of end-to-end network slicing is 442 to provide guaranteed service for vertical user. Transport network 443 will also play an important role in this scenario. One of the most 444 straight forward solution for service-guaranteed mapping to the 445 sliced 3GPP network is to make the TN also slice-aware. 447 As 3GPP SA5 delivers the performance requirements from 3GPP slice 448 manager to IETF network slice orchestrator, the orchestrator will 449 treat the requirements similarly to a general service delivery model 450 received from OSS/BSS. It is not 3GPP's concern weather IETF is 451 using slice or not toe fulfill this requirements 453 6.2. Use Case Analysis 455 Network slicing is one of the key technology in 5G network. It is 456 important that transport network can provide certain quality 457 guarantee, so that the end-to-end network slice run over can fulfill 458 the overall requirements. COMS provides NBI for the purpose of 459 gathering transport network requirements. These requirements will be 460 further broken down into underlay systems requirements accordingly, 461 where COMS can help the mapping by providing the general information 462 model. 464 7. Network Slice FCAPS 465 7.1. Use Case Introduction 467 This is a place holder for slice-level FCAPS use cases for COMS. It 468 is due to be updated in 01 version of this document 470 7.2. Use Case Analysis 472 8. Network Slice Stiching and Recursion 474 8.1. Use Case Introduction 476 This is a place holder for inter-slice operation use cases for COMS. 477 It is due to be updated in 01 version of this document 479 8.2. Use Case Analysis 481 9. IANA Considerations 483 This document makes no request of IANA. 485 10. Security Considerations 487 There is no security consideration in this draft. 489 11. Acknowledgements 491 The authors would like to acknowledge Benoit Claise, Warren Kumari 492 and Adrian Farrel for valuable discussions. 494 12. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, 499 . 501 Authors' Addresses 503 Li Qiang 504 Huawei Technologies 505 Huawei Campus, No. 156 Beiqing Rd. 506 Beijing 100095 507 China 509 Email: qiangli3@huawei.com 510 Liang Geng 511 China Mobile 512 Beijing 100053 513 China 515 Email: gengliang@chinamobile.com 517 Kiran Makhijani 518 Huawei Technologies 519 2890 Central Expressway 520 Santa Clara CA 95050 521 USA 523 Email: kiran.makhijani@huawei.com 525 Xavier de Foy 526 InterDigital Inc. 527 1000 Sherbrooke West 528 Montreal 529 Canada 531 Email: Xavier.Defoy@InterDigital.com 533 Alex Galis 534 University College London 535 London 536 U.K. 538 Email: a.galis@ucl.ac.uk