idnits 2.17.1 draft-geng-coms-problem-statement-01.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 30, 2017) is 2360 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 651, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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 L. Wang 4 Intended status: Informational China Mobile 5 Expires: May 3, 2018 S. Kuklinski 6 Orange 7 L. Qiang 8 Huawei Technologies 9 S. Matsushima 10 Softbank 11 A. Galis 12 University College London 13 Luis. Contreras 14 Telefonica 15 October 30, 2017 17 Problem Statement of Supervised Heterogeneous Network Slicing 18 draft-geng-coms-problem-statement-01 20 Abstract 22 This document discusses the general requirements and problem 23 statement of supervised heterogeneous network slicing. The purpose 24 of this document is to identify the key network components that are 25 used to create a network slice instance. Base on this information, a 26 general network slice template can be visualized. Furthermore, the 27 requirement of a common information model is identified and 28 corresponding management consideration of heterogeneous network slice 29 instance is also discussed. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 3, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. The Concept of Supervised Heterogeneous Network Slicing . . . 4 69 2.1. Heterogeneity . . . . . . . . . . . . . . . . . . . . . . 7 70 2.2. The requirement of general supervision of network slicing 7 71 3. Network Resources for Supervised Heterogeneous Network Slice 8 72 3.1. Connectivity Resources . . . . . . . . . . . . . . . . . 8 73 3.2. Computing Resources . . . . . . . . . . . . . . . . . . . 9 74 3.3. Storage Resources . . . . . . . . . . . . . . . . . . . . 10 75 3.4. Generalized Function Blocks . . . . . . . . . . . . . . . 10 76 3.5. Other Resources . . . . . . . . . . . . . . . . . . . . . 10 77 4. The Requirement of Common Operation and Management for 78 Supervised Heterogeneous Network Slice . . . . . . . . . . . 11 79 4.1. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 13 80 5. Management of Heterogeneous Network Slice . . . . . . . . . . 14 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 84 9. Normative References . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 The concept of network slicing is not new but energized greatly under 90 5G work in 3GPP. It is expected that further 5G network should be 91 capable of providing dedicated private network for different 92 verticals according to their specific requirements, which are created 93 by diversity of new services such as high definition (HD) video, 94 virtual reality (VR) and V2X applications. Looking at the 95 development of future network, no matter the service is connected via 96 5G cellular RAN, FTTx optical access network or other dedicated 97 connections, this resource dedication has become a fundamental 98 technology for services requiring extreme quality of user experience. 99 The best effort transport is not good enough as both subscribers and 100 application providers are looking for and willing to pay for certain 101 level of quality dedication. Therefore it is inevitable for service 102 providers (telecommunication infrastructure owners) to rethink the 103 means of management and operation of their networks, which should 104 support end-to-end slicing capabilities. 106 The requirements from different verticals may be extremely 107 diversified. Typical examples includes high bandwidth, low latency, 108 high level of isolation, specific security and encryption 109 requirements and etc. These requirements may also change dynamically 110 along time since the services of certain industry vertical changes 111 very fast, and sometime spontaneously (i.e. burst bandwidth/latency 112 requirement from on-line shopping provider on certain period). It is 113 expected that the configuration of certain network slice instances 114 are very dynamic in a case-by-case manner. Meanwhile, there are many 115 technology options to fulfil particular requirements depending on 116 considerations on many aspects including cost, TTM and etc. The 117 diversity of both requirements and technology options makes network 118 slices significantly heterogeneous. 120 In order to provide cost-effective and efficient network slice 121 configuration, service provider needs to understand specifically the 122 components it can make use to create a network slice instance and how 123 these components map with the customer requirements. These 124 components include both network resources and management entities. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119. 132 1.2. Terminology 134 Network Slicing - A management mechanism that Network Slice Provider 135 can use to allocate dedicated network resources from shared network 136 infrastructures to Network Slice Tenant. 138 Network Slice - A network slice is a managed group of dedicated 139 network resources to meet certain network functionality and 140 performance characteristics required by the network slice tenant(s). 141 It is re-configurable and is supervised by the network slice 142 provider. 144 Network Slice Provider - A network slice provider (NSP), typically a 145 telecommunication service provider, is the owner or tenant of the 146 network infrastructures from which network slices can be created. 147 The network slice provider takes the responsibilities of managing, 148 orchestrating and monitoring the corresponding resources to implement 149 a network slice and provide the Network slice tenant certain level of 150 management. 152 Network Slice Tenant - A network slice tenant (NST) is the user of 153 specific network slice, in which customized services are hosted. 154 Network slice tenants can make requests of the creation of new 155 network slice through NSaaS platform. This request will be delivered 156 to network slice controller for implementation purposes. 158 2. The Concept of Supervised Heterogeneous Network Slicing 160 Network slicing is a management mechanism that an NSP can use to 161 allocate dedicated network resources from shared network 162 infrastructures to an NST. This dedication may be performed in 163 various forms on a diversity of resources depending on specific NSP's 164 network availabilities. Typical examples include physical and 165 logical isolation of network connectivity with certain QoS 166 guarantees, bare metal and virtualized computing resources, dedicated 167 storage and specific pre-define network functions such as NAT server, 168 SDN controller and etc. Other network technologies such as ICN and 169 CDN may also be part of the resource dedication. Network slicing 170 gives the NSP full flexibility to either logically or physically 171 lease a partition of their networks to the NST with required 172 functionalities and performances. 174 +----------------------------------------------------------+ 175 | Network Slice as a Ser^ice | 176 | +-------------------------------------+ +--------------+ | 177 | | Network Slice Template | | | | 178 | | +---------+ +---------+ +---------+ | | Customized | | 179 | | | 5G | | Internet| |Verticals| | | Network Slice| | 180 | | | centric | | VPN | |Industry | | | | | 181 | | +---------+ +---------+ +---------+ | | | | 182 | +-------------------------------------+ +----+---------+ | 183 | | | | 184 | | | | 185 | +------v----------------------------v----+ | 186 | | Network Slice Service Profile | | 187 | +----------------+-----------------------+ | 188 | | | 189 +----------------------------------------------------------+ 190 | 191 +---------v----------+ 192 | Cross-Segment | 193 +------------+ Slice Manager +--------------+ 194 | +---------+----------+ | 195 | | | 196 | | | 197 +----v----+ +--------------v-----------------+ +-----v----+ 198 | RAN | | Network Slice Domain Controller| | CN | 199 | Slice | | | | Slice | 200 | Ctrlr | +--------+----------+---------+-++ | Ctrlr | 201 +---------+ | | | | | +----------+ 202 | | | | | 203 +---+ | | | +----------+ 204 | | | | | 205 +------+-----+ +----+----+ +---+----+ +--+--------+ +-+---+ 206 |Connectivity| |Computing| | Storage| |Generalized| | | 207 | | | | | | |Functions | | ... | 208 +------------+ +---------+ +--------+ +-----------+ +-----+ 210 Figure 1: The concept of supervised heterogeneous network slicing 212 As network slicing is introduced to overall network management, it is 213 anticipated that new business models may be created. With a more 214 flexible, elastic and modularized network, the shared network 215 infrastructures can be sliced and offered as a service to end users 216 and verticals. For instance, a network slice with dedicated network 217 resources with a customized topology can be provided as a service 218 (NSaaS)to the NST. 220 Figure 1 illustrated the concept of how NSaaS is supervised within a 221 heterogeneous network. In this concept, a network slice can either 222 be implemented according to pre-defined network slice templates or 223 customized requirements. On one hand, network slice template is 224 designed by NSPs for the ease of mapping NST's request to a NSaaS 225 with rather common resources and performance requirements. This 226 includes but not limited to 5G-centric services such as eMBB and 227 URLLC network slices, dedicated internet VPNs for game acceleration 228 and video delivery, specific vertical industrial internet dedications 229 such as smart factory and so on. On the other hand, implementing 230 network slicing using customized approach provides NST with the full 231 flexibility of composing its own network resource pools according to 232 various requirements and constraints respectively. As the NST 233 defines a preferred network slice service either from a pre-defined 234 template or full customization, a network slice service profile is 235 therefore generated. 237 The network slice service profile is sent to cross-segment slice 238 manager, which coordinate resource from different network segment. 239 The cross-segment network slice manager decomposes the network slice 240 service profile and assigns corresponding segment network slice 241 information to multiple network slice domain controllers. In this 242 illustration, radio access network, transport network and core 243 network are used as common examples of network segments with network 244 slice domain controllers. However, it is worthy of mentioning that 245 backhauling is only one of the use cases of transport segment network 246 slicing. 248 In the slice controller within a specific network segment, NSaaS 249 information is translated to resource-level description of a network 250 slice for implementation purposes. In particular, it visualizes a 251 network slice with specific resource components that comprise 252 computing, storage, and generalized functions etc. The slice 253 controller also coordinates heterogeneous domain controllers/managers 254 for network slice implementation. 256 Although a general network slice may consist of resource components 257 from various network segments, the supervised heterogeneous network 258 slicing in this document refers only to IETF segment and sees the 259 managed network slice a stand-alone one within IETF scope. It may be 260 used by the cross-segment network slice manager to create a more 261 comprehensive end-to-end network slice including other network 262 segments that are out of scope of IETF. 264 2.1. Heterogeneity 266 Heterogeneity is the nature of network slicing since the requests of 267 NSaaS from the NST are diversified. The slice controller has to 268 supervise heterogeneous resources in various domains in response to 269 NSaaS demands. The different types of resources a network slice 270 controller needs to supervise includes connectivity, storage, 271 computing, generalized functions and others. Furthermore, even for a 272 single type of resources, an NSP may have difference management 273 domains because of either technical or geographical variations. For 274 example, the network slice controller is supposed to have the ability 275 to coordinate multiple typical existing technology domains including 276 optical transport network, IP routing network and layer-2 switched 277 network. It also needs to integrate network domains with different 278 management/control mechanism. For instance, the slice controller is 279 necessary to be compatible with both SDN-enabled ACTN-aware networks 280 and traditional EMS-managed networks. Another case is the management 281 of virtualized resources using VIMs such as Openstack. In order to 282 provide computing/storage resource support for network slicing, these 283 domains are also inevitable required to be coordinated. 285 No matter it is a green field or brown field implementation, the 286 network resources used to create a network slice are very likely to 287 reside in different heterogeneous management domains. The supervised 288 heterogeneous network slicing provides the capability of coordination 289 and orchestrate the resources from different domains. 291 2.2. The requirement of general supervision of network slicing 293 Supervision is required by NSP, making use of OAM tools to 294 maintenance the network slice. The slice controller needs to provide 295 this capability to NSP to supervise the all the network slices that 296 are implemented. 298 There are varieties of reasons why supervision is crucial in the case 299 the network slicing. First of all, the network slice controller 300 would not be able to deal with the lifecycle management of network 301 slices without supervision abilities. Besides, given the 302 characteristic of heterogeneous environment, the network slice 303 controller must be crystal clear of the underlay resource information 304 that is reported and synchronized by the domain controllers/managers. 305 If this is seen as a network resource capability exposure approach, 306 the network slice controller must supervise this approach to define 307 how this information gathered and used. Furthermore, the network 308 slice controller need to provide slice-level monitoring ability 309 during the complete life circle of a network slice. This is 310 essential for the claim benefits of quality guarantee by the 311 implementation of network slicing. For example, the slice controller 312 need to supervise and monitor the jitter of a certain link in a 313 network slice with deterministic property requirement by NST. This 314 jitter performance should also be provided to NST for SLA references. 316 Last but not the least, it is common that some NST would like to 317 participate in the management of its network slice. The slice 318 controller should provide this capability by using the intra-slice 319 management (discussed later in section 5). This management 320 capability exposer must be supervised by NSP to avoid any resource/ 321 performance conflicts with other network slices. 323 3. Network Resources for Supervised Heterogeneous Network Slice 325 Fundamentally, network slices are created based on the shared network 326 resources. There are many existing technologies which focus on the 327 management of those network resources. For example, various type of 328 domain SDN controllers supervise the connectivity resources within 329 each technology or geographical domains, and MANO supervises the NFV 330 infrastructures. As previously discussed, network slicing provides a 331 management mechanism for NSP to create network slices from the 332 underlay resources. It oversees all these resources and decides the 333 placement of specific resources according to certain path and 334 topology constraints. 336 Network slicing does not have any constraints on what type of 337 resources NSPs may or may not use as part of the network slice 338 creation. This is completely subjected to NSP's policy. However, 339 for the ease of management and operation, it is worthy to have a 340 guideline to at least categorize the common resources that NSP may 341 offer to NST as a network slice service. The section endeavours to 342 provide a prototype catalogue of the resource components for network 343 slice creation. In general, the components that an NSP can use to 344 create a network slice include connectivity, computing, storage and 345 generalized functions. Other wide-scale network functionalities 346 including ICN and CDN are also regarded as customized network 347 resources. 349 3.1. Connectivity Resources 351 Connectivity is one of the essential components for a network slice. 352 It can be as simple as a best effort point-to-point VPN or a physical 353 link using a dedicated wavelength. It may also have more complex 354 topology with other specific requirements including bandwidth, 355 latency and etc. The characteristics of the connectivity component 356 may include the following aspects. 358 o Node - The description of a network node at network slice level 359 abstraction. The abstraction level depends on the provided node 360 resource information from the south bound interface of the 361 transport network slice controller. 363 o Link - The description of a network link between two nodes in a 364 network slice. 366 o Topology - The description of connection topology of a network 367 slice. It should explicitly describe the connectivity 368 relationship between each access point of the network slice. An 369 NSP should be able to understand the overall connectivity 370 requirement of a network slice from this topology information. 372 o Bandwidth - The description of bandwidth requirements of specific 373 links within a network slice. The requirements includes exactly 374 amounts of assured bandwidth, maximum bandwidth and other 375 bandwidth QoS-specific requirements 377 o Latency - The description of link latency requirements within a 378 network slice. It should identify the exact amount of latency 379 between a link defined in connection topology. 381 o Determinism - The description of the determinism of a link 382 latency. This should be defined in addition to the latency, which 383 further specify the jitter of the latency for a given link. 385 o Isolation level - The description of isolation level of a network 386 slice. A NST may request logical isolation which can be mapped to 387 tunnelling technologies. It may also request explicitly a 388 dedicated lamda or even physical link for specific services. 390 3.2. Computing Resources 392 If an NST would like to host virtualized functions in a network 393 slice, it may be interested in asking for specific computing resource 394 including both bare metal servers and virtual machines. The 395 computing resource can be specified considering the following 396 characteristics. 398 o CPU resources - The CPU specification including CPU model, 399 frequency, quantity of physical/virtual CPU and etc. 401 o RAM resources - The RAM size associated with the requested 402 computing resources in a network slice. 404 o Virtual resources - The pre-defined virtual resources including 405 both virtual machines and containers associated with a specific 406 network slice. 408 o Other - This may include GPU requirements and other specific 409 computing resources 411 3.3. Storage Resources 413 It is necessary for NSP to provide storage components in a network 414 slice since NSTs may want to host contents on dedicated resources. 415 Meanwhile, NSP may also prefer to use dedicated storage for specific 416 service policies, authentication information and other management 417 profiles. 419 o General storage - The description of storage resource in a network 420 slice. This may include the location, type, size and usage of the 421 storage resource. The general storage requirements may closely 422 related to the connectivity topology as well. 424 o CDN service - If an NSP can provide a turn-key CDN solution for 425 the NST. It can also include CDN service within a network slice. 427 3.4. Generalized Function Blocks 429 Many dedicated network functions, either physical or virtual, may 430 requested by a NST. Typical example include common network functions 431 as DHCP server, DNS, NAT, Firewall, SDN controller. Application- 432 level functions may also exist in a network slice, such as session 433 management, mobility management and etc. NSP should be able to 434 provide such generalized function blocks according to NST's request. 436 o Physical network function blocks- The description of dedicated 437 physical network functions. Physical network functions are 438 network equipments with dedicated software and hardware, which are 439 strictly coupled for the purpose of a providing specific network 440 function. 442 o Virtual network function blocks- The description of virtualized 443 network functions. VNFs are software entities which are normally 444 hosted within pre-allocated virtual machines (or containers). The 445 virtual resources which are required by the VNF should be also 446 specified in terms of computing resources as described previously. 448 3.5. Other Resources 450 A category of customized resources is reserved for network slicing 451 since NSPs may have unique capabilities that may be used as part of 452 the network slicing to provide even greater innovative functionality. 453 Resources such as ICN-aware subnet, CDN network and etc. are some t 454 potential attributes in this category. 456 4. The Requirement of Common Operation and Management for Supervised 457 Heterogeneous Network Slice 459 Network slice can only be created with resource components that are 460 available in its network. It is expected that different NSPs have 461 various constraints and policies. The abstraction of resources is 462 gathered from the network configuration models whose attributes are 463 maintained by heterogeneous domain controllers/managers. Based on 464 this information, a full set of resource capabilities is established. 465 In order to provide network-slice-level OAM, it is extremely 466 important for the heterogeneous transport network slice controller to 467 visualize a network slice in terms of systematic association of these 468 individual resources. This visualization model describes the network 469 slice at a resource granularity and abstraction level that are 470 provided by the underlay heterogeneous domain controllers and 471 managers. It is a technology-unspecific model since how each 472 partition of a network slice should map to specific resource 473 capability is implementation-specific. 475 In addition, the heterogeneous transport network slice controller 476 receives service delivery model from the cross-segment network slice 477 manager with high level network slice requirements described in the 478 network slice service profile. The service delivery model includes 479 network slice service description in business view point. Before it 480 can be mapped to resources capabilities, it has to be translated to a 481 network-slice level abstraction in network resource view point, with 482 the compatible granularity the is exposed from the underlay resource 483 capabilities. 485 A common information model is required for the operation and 486 management in the heterogeneous network slice controller to provide 487 the above abilities. It acts as an intermediate guideline model, 488 which provides comprehensive technology-unspecific description of a 489 network slice. This model does not specify the allocation of certain 490 partition of network slice to underlay technology domain or the 491 mapping of certain protocol to network slice performance 492 requirements. However, it is the fundamental model that specifies 493 each node, link, function blocks and corresponding performance 494 requirements in an established network slice. 496 +------------------------------------------+ 497 | Network Slice Tenant | 498 NSaaS and +-+----------------------------------------+ 499 Cross-segment | Requests a NSaaS Service 500 Network | 501 Slice +-v----------------------------------------+ 502 Management | Network Slice Service Profile | 503 +-+----------------------------------------+ 504 | Generates a Service Deliviery Model 505 | 506 ^ +-v----------------------------------------+ 507 | | Global Service Delivery Model | 508 | +-+----------------------------------------+ 509 | | Decomposed by Cross-segment Network Slice Manager 510 | | 511 +------------+-v----------------------------------------+ 512 | | Segment Service Delivery Model | 513 | +-+----------------------------------------+ 514 | | Translated by Domain Slice Controller 515 | | 516 v +-v----------------------------------------+ 517 | Common Information Model | 518 Segment-specific+-+---------------+---------------+--------+ 519 Network Slice | | | 520 Management | | | 521 and +---v---------+ +---v---------+ +---v---------+ 522 Implementation| Network | | Network | | Network | 523 |Configuration| |Configuration| |Configuration| 524 | Model I | | Model II | | Model III | 525 +-------------+ +-------------+ +-------------+ 527 Figure 2: Common Information Model in Network Slicing 529 Figure 2 demonstrates the relationship between different models in 530 the scope of supervised heterogeneous network slicing management. A 531 service profile is created upon the request from a NST for a network 532 slice service. This service profile is sent to cross-segment slice 533 manager by global service delivery model. The global service 534 delivery model is further decomposed to various segment service 535 delivery model. In IETF's concern, the transport segment service 536 delivery model is the starting point for a network-slice-aware 537 service implementation. 539 Within the transport domain, the service delivery model is translated 540 into a common information model, which strictly aligns with the 541 underlay resource constraints. A common information model is created 542 for each network slice, and it comprehensively visualizes all the 543 components topologies within the slice and corresponding 544 functionality and performance parameters 546 In order to coordinate different technology domains to create the 547 corresponding network slice, the common information model is mapped 548 to network configuration models for different domains respectively. 550 The common operation and management is essential for network slicing 551 since a network slice consist of resource components typically from 552 diversity of management domains. There is yet a network-slice-aware 553 approach that is able to orchestrate and coordinate these domains. 554 The common operation and management of network slicing is designed 555 for this purpose. At the same time, there are other requirements in 556 terms of heterogeneous network slice management, which are enabled by 557 this approach: 559 o common resource negotiation and abstraction 561 o exchanging information between multiple management domains 563 o operations and monitoring across multiple management domains 565 o network-slice operational control (i.e. life-cycle management) and 566 management capability exposure to NST 568 4.1. Problem Scope 570 The common information model acts as the key element in common 571 operation and management of network slicing. Foresee derivative 572 including network slice monitoring, life cycle management, network 573 slice interconnect, fault detection and protection mechanisms are 574 also interesting and inevitable matters that supervised heterogeneous 575 network slicing need to investigate. 577 More work is also needed to define a north interface for the slice 578 controller, we can envision how the slice controller could interface 579 with existing systems (e.g. using the NFV-MANO architecture as a 580 guide), and by extension delimit the scope of the slice controller 581 function. 583 In one scenario, the slice controller can interface with a virtual 584 infrastructure manager (VIM), such as OpenStack. The slice 585 controller can in this case be considered as a lower layer component 586 of the VIM, or as a network management component controlled by the 587 VIM. In another scenario, the slice controller can implement a VIM, 588 and present an interface to an orchestrator. 590 5. Management of Heterogeneous Network Slice 592 +----------------------------------+ 593 | Slice Manager/Controller | 594 | +-------------+ +--------------+ | Management 595 | | Common | | Intra-slice | | Capability 596 | | Information | | Management +---->Exposure 597 | | Model | | | | 598 | +-----+-------+ +-----+--------+ | 599 | | | | 600 +----------------------------------+ 601 | | 602 +--------------+---------------------------------+ 603 | | | 604 | +----------------------------+--+ | 605 | | | | 606 | | +--------------------------+ +----+ | 607 | | | Connectivity | | | | 608 | | | Computing | | +----+ | 609 | | | Storage | | | | | 610 | | | generalized function | | | | | 611 | | | Others | | | | | 612 | | +--------------------------+ | | | | 613 | | Network Slice I | | | | 614 | +----+--------------------------- | | | 615 | | Network Slice II | | | 616 | +----+--------------------------- | | 617 | | Network Slice III | | 618 | +-------------------------------+ | 619 | Network Infrastructure | 620 +------------------------------------------------+ 622 Figure 3: Common Information Model in Network Slicing 624 Given that common information models are set up for various network 625 slice. The network-slice-level management is carried out by the 626 slice controller accordingly. Meanwhile, an intra-network-slice 627 controller is need for each network slice. The controller oversees 628 the OAM of a single network slice and report to the heterogeneous 629 transport network slice controller. As per agreement between NST and 630 NSP, certain capabilities of intra-slice management may be exposed to 631 NST. NST are authorized to use these capabilities to maintain its 632 network slice in a view of dedicated networks and resources. The 633 network slice-level information must not be exposed, which means the 634 NST should not know he existence of any other network slices through 635 intra-slice manager. The exposed controller capability should be 636 supervised by the NSP, so that the network slice will not violate 637 network slice-level policies. 639 6. IANA Considerations 641 This document makes no request of IANA. 643 7. Security Considerations 645 Each layer of the system has its own security requirements. 647 8. Acknowledgements 649 9. Normative References 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, 653 DOI 10.17487/RFC2119, March 1997, 654 . 656 Authors' Addresses 658 Liang Geng 659 China Mobile 660 Beijing 661 China 663 Email: gengliang@chinamobile.com 665 Lei Wang 666 China Mobile 667 Beijing 668 China 670 Email: wangleiyjy@chinamobile.com 672 Slawomir Kuklinski 673 Orange 675 Email: slawomir.kuklinski@orange.com 677 Li Qiang 678 Huawei Technologies 679 Huawei Campus, No. 156 Beiqing Rd. 680 Beijing 100095 682 Email: qiangli3@huawei.com 683 Satoru Matsushima 684 Softbank 686 Email: satoru.matsushima@g.softbank.co.jp 688 Alex Galis 689 University College London 691 Email: a.galis@ucl.ac.uk 693 Luis Miguel Contreras Murillo 694 Telefonica 696 Email: luismiguel.contrerasmurillo@telefonica.com