idnits 2.17.1 draft-geng-netslices-architecture-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 date (March 13, 2017) is 2595 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Network-Slice-White-Paper' is defined on line 528, but no explicit reference was found in the text 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. Geng 3 Internet-Draft China Mobile 4 Intended status: Informational S. Bryant 5 Expires: September 14, 2017 J. Dong 6 Huawei Technologies 7 March 13, 2017 9 Network Slicing Architecture 10 draft-geng-netslices-architecture-00 12 Abstract 14 This document defines the overall architecture of network slicing. 15 Base on the general architecture, basic concepts of network slicing 16 and examples of network slicing instances are introduced for 17 clarification purposes. Some architectural considerations about the 18 data plane, control plane, management and orchestration of network 19 slicing are described to give a general view of network slicing 20 implementation principles. This also helps to identify the gaps in 21 existing IETF works relating to network slicing. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 14, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Demand for Network Slicing . . . . . . . . . . . . . . . . . 3 59 2.1. Guaranteed Service Performance . . . . . . . . . . . . . 4 60 2.2. End-to-end Customization . . . . . . . . . . . . . . . . 4 61 2.3. Network Slicing as a Service . . . . . . . . . . . . . . 4 62 3. Network Slicing Architecture . . . . . . . . . . . . . . . . 5 63 3.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . 5 64 3.1.1. Network Slicing Service Provider . . . . . . . . . . 5 65 3.1.2. Network Slice Instance . . . . . . . . . . . . . . . 5 66 3.1.3. Network Slice Type . . . . . . . . . . . . . . . . . 6 67 3.1.4. Network Slice Template . . . . . . . . . . . . . . . 6 68 3.1.5. Network Slice Tenant . . . . . . . . . . . . . . . . 6 69 3.2. General Architecture . . . . . . . . . . . . . . . . . . 6 70 4. Data Plane of Network Slicing . . . . . . . . . . . . . . . . 8 71 4.1. Propagation of Guarantees . . . . . . . . . . . . . . . . 8 72 4.2. The Underlying Physical Layer . . . . . . . . . . . . . . 8 73 4.3. Hard vs Soft Slicing in the Data-plane . . . . . . . . . 9 74 4.4. The Role of Deterministic Networking . . . . . . . . . . 9 75 4.5. The Role of VPNs . . . . . . . . . . . . . . . . . . . . 10 76 4.6. Dynamic Reprovisioning . . . . . . . . . . . . . . . . . 10 77 4.7. Non-IP Data Plane . . . . . . . . . . . . . . . . . . . . 10 78 5. Control Plane of Network Slicing . . . . . . . . . . . . . . 10 79 6. Management and Orchestration of Network Slicing . . . . . . . 11 80 7. Service Functions . . . . . . . . . . . . . . . . . . . . . . 11 81 8. OAM and Telemetry . . . . . . . . . . . . . . . . . . . . . . 11 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 12. Normative References . . . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The Internet has always been designed to support a variety of 91 services. The emerging 5G market is expected to bring this diversity 92 of services to a new level. Typical examples of new bandwidth-hungry 93 services enabled by 5G include high definition (HD) video, virtual 94 reality (VR) and augmented reality (AR). The high bandwidth 95 requirement of these services is not particularly challenging thanks 96 to the continuing advancing technologies. However, the guarantee of 97 high bandwidth performance of these services based-on a spontaneous 98 on-demand pattern is fairly challenging. Moreover, providing high 99 bandwidth with strict packet loss tolerances and high mobility is 100 also difficult for the current networks which are commonly designed 101 for best effort purposes. 103 Given that most Internet protocols are designed to comply with a best 104 effort, or enhanced best effort paradigm, it is inevitable that the 105 network will suffer from performance degradation in case of 106 congestion. Recent work on deterministic networking (DetNet) aim to 107 improve this situation by providing a ceiling on latency for a 108 particular traffic flow, which significant improves packet error rate 109 for specific DetNet services. This pioneering work gives a great 110 example that new approaches are investigated to make the Internet 111 aware of certain performance requirement other than the bandwidth. 113 Taking a look at the network infrastructure, service provider used to 114 build dedicated network and resources for services requiring 115 guaranteed performance. This is simply not cost-effective, neither 116 is it flexible. The emergence of virtualization and VPN technologies 117 make it possible to set up logically isolated computing and network 118 instances from shared infrastructures. This can be used dedicatedly 119 by specific services for improved performances. However, many 120 questions are still to be answered as different technologies in 121 various domains need to be combined to build network slices, which 122 may require the separation of different resources and various types 123 of performance guarantees. 125 2. Demand for Network Slicing 127 It is expected that a diversity of new services will emerge in 5G 128 network. These services including smart home, industrial control, 129 remote healthcare, Vehicle-to-Everything (V2X) and etc. will 130 eventually create an ecosystem of "Internet of Everything". With 131 hundreds of billions of devices from different business sectors 132 connected, the future network needs to meet the diversified Quality 133 of Experience (QoE) demands of different vertical industries. 134 Typical QoE requirements for the end users or the applications are 135 extremely low latency and high reliability, whilst the purchaser of 136 the slice is looking for short time-to-market and rapid deployment of 137 the service infrastructure needed to provide the technical 138 underpinning of their business. Service providers' networks need to 139 continuously evolve to adapt to this change. As a result, it is 140 believed that future networks should be able to provide services with 141 guaranteed performances together with the existing best-effort 142 services. In order to achieve this, it is preferred that dedicated 143 resources in the network could be used by different vertical industry 144 customers. Network slicing is proposed as an end-to-end solution for 145 this purpose. 147 2.1. Guaranteed Service Performance 149 One of the most challenging requirements for future network is to 150 provide guaranteed performance for varieties of new services whilst 151 maintaining the economies of scale that accrue through resource 152 sharing. It has been foreseen that the requirements of different 153 services would be diversified and complex. 155 Taking augmented reality (AR) service as an example, it requires high 156 bandwidth to provide a local video feed to the augmenter, and high 157 quality augmented video back to the user. At the same time, it also 158 requires extremely low latency since the created reality and the 159 user's view must be synchronized to avoid reaction mismatch. Another 160 example is the vehicular communications where the delay in traffic 161 control system may directly jeopardize the road safety. 163 Network slicing can deal with these challenges by mapping the 164 performance requirements to physically or logically dedicated 165 resources. 167 2.2. End-to-end Customization 169 Customization is another significant feature of future services. 170 Many vertical industries are expected to offer customization 171 capabilities as a service to both internal manufacturing processes 172 and specific end users. Meanwhile, these customized services need to 173 be deployed with short time-to-market. The network needs to adapt to 174 this challenge since customers may frequently adjust and refine their 175 customization requirements. 177 There is ongoing work such as network orchestration, software defined 178 networks and network function virtualization that aims to address 179 this problem. In principle, these new technologies share a common 180 request for the network to provide the ability to provide agile 181 resource allocation. 183 2.3. Network Slicing as a Service 185 It is anticipated that the operation of 5G and future networks will 186 involve new business models. Given that the network is more 187 flexible, elastic, modularized and customized, the shared network 188 infrastructure can be sliced and offered as a service to the 189 customer. For instance, dedicated, isolated, end-to-end network 190 resources with a customized topology can be provided as a network 191 slice service to the tenant of this network slice.The tenants are 192 allowed to have a certain level of provisioning of their network 193 slices. 195 3. Network Slicing Architecture 197 This section introduces the general system architecture of network 198 slicing. 200 3.1. Basic Concepts 202 Network slicing is a collection of technologies that are used to 203 establish logically dedicated resources including but not limited to 204 connectivity, computing, storage, provisioning and specific network 205 functions. The logical resources are a part of the larger common 206 network infrastructures that are shared among various network slice 207 instances. These dedicated resources can be customized to meet the 208 diversified requirements of different vertical industries. 210 The following sections describe some basic concepts of network 211 slicing. 213 3.1.1. Network Slicing Service Provider 215 A network slicing service provider, typically a telecommunication 216 service provider, is the owner of the network infrastructures from 217 which network slices are created. The network slicing service 218 provider takes the responsibilities of managing and orchestrating 219 corresponding resources that network slicing uses. 221 3.1.2. Network Slice Instance 223 A network slice instance (NSI) is the end-to-end realization of 224 network slicing, which consists of the combination of physically or 225 logically dedicated resources. An NSI typically associates with 226 components from different network domains including core network, 227 transport network and access network. It may also require cloud 228 resources from data centres. Furthermore, end-user terminals may 229 also allocate dedicated resource to a specific NSI. 231 Each NSI is defined and created for specific service-oriented 232 requirements. The logically dedicated resources allocated to NSIs 233 may be intrinsically isolated physical instances. They may also 234 share common physical infrastructures according to implementation 235 choices. 237 3.1.3. Network Slice Type 239 Network slices are categorized into different types according to the 240 abstraction of characteristics of the services they facilitate. The 241 methodology used for defining network slice types may be different 242 for the owners of network slicing infrastructure. Some typical 243 examples of network slice types according to 5G implementation 244 include eMMB, mMTC and URLLC. Network slice type may be used to map 245 specific network resources, VPNs, QoS categories according to real 246 implementation. It is advised that mutual types should be defined 247 according to existing main-stream service implementation scenarios. 248 Extensions should be allowed for network slicing service provider to 249 make according to new requirements. 251 3.1.4. Network Slice Template 253 A network slice template is an abstraction of the resource 254 requirement for a set of similar network slice instances. Different 255 templates are defined for individual network slice types. These 256 templates are used to create certain network slice instances. 258 3.1.5. Network Slice Tenant 260 A network slice tenant is the user of specific NSIs, with which 261 specific services can be provided to end customers. Network slice 262 tenants can make requests of the creation of new network slice 263 instances. Certain level of management capability should be exposed 264 to network slice tenant from network slice service provider. 266 3.2. General Architecture 268 Figure 1 illustrates the general architecture of network slicing. It 269 can be seen that two network slice instances are created from the 270 shared network infrastructures. In principle, the network elements 271 (NEs) represent any general network infrastructures for demonstration 272 purposes. The two instances created do not know the existence of 273 each other. However, they may share the computing, connectivity and 274 storage resources of the NE, whether they are in physical or virtual 275 forms. Meanwhile, the owner of a particular network slice instance 276 is allowed to adjust the instance by requesting changes via the 277 network slicing management and orchestration system. 279 +-----------------------------------------------------------+ 280 | Network Slice Management and Orchestration | 281 | +------------+ +-------------+ +--------------------+ | 282 | | Template | | E2E Slice | | Life cycle Mngt. | | 283 | | Management | |Orchestration| | and monitoring | | 284 | +------------+ +-------------+ +--------------------+ | 285 | Created Network Slice Instances | 286 | +-------------------------------------------------------+ | 287 | | | | 288 | | +---+ +---+ +---+ | | 289 | | |NE1+----+ |NE3| |NE5| | | 290 | | +---+ | +-+-+ +-+-+ | | 291 | | +-+-+ | | | | 292 | | |NE2+-----+ | | | 293 | | +-+-+ | Network Slice | | 294 | | | | Instance 1 | | 295 | | +------------------------+ | | 296 | +-------------------------------------------------------+ | 297 | +-------------------------------------------------------+ | 298 | | | | 299 | | +---+ +---+ +---+ | | 300 | | |NE1+----+ +--+NE5+------+NE6| | | 301 | | +---+ | | +-+-+ +---+ | | 302 | | +-+-+ +---+ | | | | 303 | | |NE2| |NE4+-+ | | | 304 | | +-+-+ +-+-+ | Network Slice | | 305 | | | | | Instance 2 | | 306 | | +------------------------+ | | 307 | +-------------------------------------------------------+ | 308 +-----------------------------------------------------------+ 310 +-----------------------------------------------------------+ 311 | Physical Network Infrastructures | 312 | +---+ +---+ +---+ +---+ | 313 | |NE1+----+ |NE3+------+ +--+NE5+------+NE6| | 314 | +---+ | +-+-+ | | +-+-+ +---+ | 315 | +-+-+ | +-+-+ | | | 316 | |NE2+----+ |NE4+-+ | | 317 | +-+-+ +-+-+ | | 318 | | | | | 319 | +------------------------+ | 320 +-----------------------------------------------------------+ 321 Figure 1. Network Slicing Architecture 323 It is fundamental to network slicing that slices may be created, the 324 topology and/or its resources modified, and that the slices may be 325 decommissioned in a timely manner with minimum work by the network 326 slicing provider or the customer. This is not however unique to 327 network slicing, it is a goal of modern classical networks to be able 328 to do this. 330 4. Data Plane of Network Slicing 332 In the network slicing architecture, the data plane in the edge and 333 core of the network will likely be one or more of the standard IETF 334 data planes: IPv4/IPv6, MPLS or Pseudowires (PW). This section 335 assumes that the IETF protocol stack exists as-is, and describes the 336 performance consideration in different layers of the data plane. 338 4.1. Propagation of Guarantees 340 Guarantees of delay start at the physical layer and propagate up the 341 stack layer by layer. Any layer can add delay, and can take various 342 steps to minimize the impact of delay on its layer, but no layer can 343 reduce the delay introduced by a lower layer. 345 Guarantees of loss and jitter can, by contrast be upheld or improved 346 at any layer of the protocol stack, but usually at a cost of 347 increased delay. Where delay is a constrain as it is in some 5G 348 applications the option of trading delay for better loss or jitter 349 characteristics is not an option. In these circumstances it is 350 critical that the quality characteristics start at the physical layer 351 and be maintained at each layer of the protocol stack. 353 4.2. The Underlying Physical Layer 355 A point to point dedicated physical channel provides the delay, 356 jitter and loss characteristics limited only by the media itself. 357 This does not fulfil the need for rapid reconfiguration of the 358 network to provision new services. 360 To address the need to provision a slice of the data-plane one 361 approach that can be deployed is to time-slice access to the physical 362 service. Ignoring many of the classic TDM offering as being too 363 slow, a number of technologies are available that might be applied 364 including OTN and FlexE. Whilst the provisioning of the channel 365 provided by underlays such as FlexE and the interconnection of FlexE 366 channels is within the scope of this architecture the operation of 367 the underlay is outside its scope. 369 The logical sub-division of a physical channel be that a single 370 channel with the full bandwidth available or a channel multiplexed at 371 the physical layer such as is provided by FlexE we will consider in 372 the following section. 374 4.3. Hard vs Soft Slicing in the Data-plane 376 Hard slicing refers to the provision of resources in such a way that 377 they are dedicated to a specific NSI. Data-plane resources are 378 provided in the data-plane through the allocation of a lambda, 379 through the allocation of a time domain multiplexed resource such as 380 a FlexE channel or through a service such as an MPLS hard-pipe. Note 381 that although hard-pipes can be used to allocate dedicated, non- 382 shared resources to an NSI, the using of allocation is bandwidth, 383 which can result in more "lumpiness" in the physical channel that 384 would not be present with a true physical layer multiplexing scheme. 386 Soft slicing refers to the provision of resources in such a way that 387 whilst the slices are separated such that they cannot statically 388 interfere with each other (one cannot receive the others packets or 389 observe or interfere with the other's storage), they can interact 390 dynamically (one may find the other is sending a packet just when it 391 wants to, or the other may be using CPU cycles just when the other 392 needs to process some information), which means they may compete for 393 some particular resource at some specific time. Soft slicing is 394 achieved through logically multiplexing the data-plane over a 395 physical channel include various types of tunnel (IP or MPLS) or 396 various types of pseudowire (again IP or MPLS). Although the design 397 of deterministic networking techniques helps, it is not possible to 398 achieve the same degree of isolation with these techniques as it is 399 possible to achieve with pure physical layer multiplexing techniques. 400 However where such techniques provide sufficient isolation their use 401 leads to a network design that may be deployed on existing equipment 402 designs and which can make unused bandwidth available to best effort 403 traffic. 405 4.4. The Role of Deterministic Networking 407 Deterministic networking is a technology under development in the 408 IETF that aims to both minimize congestion loss and set an upper 409 bound on per hop latency. It allows a packet layer to emulate the 410 behaviour of a fully partitioned underlay such might be provided 411 through some physical layer multiplexing system such as FlexE. 413 Deterministic networking works by policing the ingress rate of a flow 414 to an agreed maximum and then scheduling the transmission time of 415 each flow to reduce the "lumpiness" and hence the possible buildup of 416 queues and hence congestion loss. 418 Whilst deterministic networking is not as perfect as physical layer 419 multiplexing in terms of latency minimization, because the scheduling 420 is hop by hop and not end to end meaning that at each hop a packet 421 has to wait for the transmission slot allocated to its flow, it has 422 the advantage that it is able to allocate slots not needed by the 423 allocated traffic to best effort traffic. This reallocation of the 424 unused transmission slots to background traffic significantly 425 improves the efficiency of the network by amortizing the cost between 426 the scheduled high priority users and the best effort users. 428 4.5. The Role of VPNs 430 VPNs are considered candidate technologies for network slicing. The 431 existing VPN technologies mainly focus on the isolation of forwarding 432 tables between different tenants and provide a virtual topology for 433 the connectivity between different sites of a tenant. The VPN layer 434 and the underlying network resources are usually loosely coupled, and 435 statistical multiplexing is adopted to improve network utilization. 437 Although VPNs have been widely used to provide enterprise services in 438 service provide networks, it is unclear that whether VPNs along with 439 existing underlying tunnel technologies can meet the performance and 440 isolation requirements of critical services in the vertical 441 industries. 443 4.6. Dynamic Reprovisioning 445 A requirement of the network slicing system is that it can be 446 dynamically and non-disruptively reprovisioned. That is not an 447 unusual requirement of a modern network. However the frequency of 448 reprovisioning with network slicing will be relatively high, such 449 that it in many cases it is not possible to hide any disruption 450 during a "quiet" time. 452 Physical multiplexing methods such as FlexE have the ability to 453 seamlessly reprovision multiplex slots. At the network layer 454 techniques such as make-before-break, segment routing, and loop-free- 455 convergence can be used to provide uninterrupted operation during a 456 topology change. 458 4.7. Non-IP Data Plane 460 Non-IP data plane in support of Information Centric Networking (ICN), 461 some of the IoT services and other similar requirements will be added 462 in a future version. 464 5. Control Plane of Network Slicing 466 There are two control plane systems that need to be considered. The 467 first is the control plane of the slicing infrastructure itself, the 468 second is the control plane of an individual slice. 470 The network slicing control plane receives instructions from the 471 orchestration layer and creates the required network slices and 472 manages them throughout their life cycle. The slices need to satisfy 473 a diverse set requirements and need to be dynamically managed as the 474 collective requirements of the set of network slices changes, and as 475 the resource and capabilities of the physical network change with 476 time. Changes occur as resources fail, and resources are added. 477 They also occur as the slices are added and deleted possibly needing 478 a garbage collection and defagmantation service. 480 The control plane of the network slicing system needs to comply with 481 the SDN architecture, while still using distributed control protocols 482 when it is necessary or proved to have advantages. 484 Within a slice the full range of existing control plane technologies 485 needs to be permissible. Some slices will run the existing IGP 486 protocols (such as IS-IS or OSPF) whilst others may use BGP. Some 487 slices may be controlled by their own SDN controllers. However the 488 architecture needs to be sufficiently general so as not to restrict 489 the control protocols that may be used within a slice. 491 6. Management and Orchestration of Network Slicing 493 The management and orchestration layer of network slicing system is 494 responsible for the slice template management, slice orchestration 495 and life cycle management and monitoring of network slices. Network 496 slice templates can be generated according to the functional and 497 performance requirements of the tenants. In different network 498 domains, different technologies may be used for network slicing, and 499 orchestration is needed to build E2E network slice. The 500 provisioning, runtime assurance and decommissioning of E2E network 501 slices is also the key function of this layer. 503 It is expected that the management and orchestration layer would use 504 state of the art management technologies to support short time-to- 505 market, and help the operators to build an open ecosystem for new 506 services in vertical industries. 508 7. Service Functions 510 To be provided in a future version. 512 8. OAM and Telemetry 514 To be provided in a future version. 516 9. IANA Considerations 518 This document makes no request of IANA. 520 10. Security Considerations 522 Each layer of the system has its own security requirements. 524 11. Acknowledgements 526 12. Normative References 528 [Network-Slice-White-Paper] 529 China Mobile Communication Corporation, Huawei 530 Technologies Co. Deutsche Telekom AG,Volkswagen, "5G 531 Service-Guaranteed Network Slicing White Paper", 2017, 532 . 535 [TD126_DraftRec_Y_IMT2020-NetSoft] 536 Nakao, A., Shimizu, T., and T. Kinoshita, "High level 537 technical characteristics of network softwarization for 538 IMT-2020", 2017. 540 [TD127_DrafSup_NetSoft-and-OSS_v0214-19H] 541 Goto, Y. and N. Morita, "Draft supplement to Y.IMT2020 542 series "Standardization and open source activities related 543 to network softwarization of IMT-2020"", 2017. 545 Authors' Addresses 547 Liang Geng 548 China Mobile 550 Email: gengliang@chinamobile.com 552 Stewart Bryant 553 Huawei Technologies 555 Email: stewart.bryant@gmail.com 557 Jie Dong 558 Huawei Technologies 560 Email: jie.dong@huawei.com