idnits 2.17.1 draft-dong-network-slicing-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 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 J. Dong 3 Internet-Draft S. Bryant 4 Intended status: Informational Huawei Technologies 5 Expires: May 4, 2017 October 31, 2016 7 Problem Statement of Network Slicing in IP/MPLS Networks 8 draft-dong-network-slicing-problem-statement-00 10 Abstract 12 The research and standardization of IMT-2020 (a.k.a. 5G) are in 13 progress in several industry communities and standard organizations. 14 The goal of 5G is to integrate various services, each of which has a 15 set of unique requirements, into a single network, such that each 16 service has a customized network suited to its needs. The concept 17 "Network Slicing" is widely discussed and considered as the key 18 mechanism to meet the diverse service requirements concurrently with 19 the same physical network infrastructure. This document provides an 20 overview of the concept "network slicing" in the current IMT-2020 21 (a.k.a. 5G) related works, and discusses the corresponding 22 requirements on IP/MPLS network, which will be used as the mobile 23 transport network for 5G. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 4, 2017. 48 Copyright Notice 50 Copyright (c) 2016 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 (http://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 2. Network Slicing Problem Statement . . . . . . . . . . . . . . 3 67 2.1. Isolation and Separation . . . . . . . . . . . . . . . . 3 68 2.2. Customization of the Topology . . . . . . . . . . . . . . 5 69 2.3. Flexibility of the Topology . . . . . . . . . . . . . . . 7 70 2.4. Guaranteed Quality of Service . . . . . . . . . . . . . . 7 71 2.5. Management Considerations . . . . . . . . . . . . . . . . 8 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 6. Informative References . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The research and standardization of IMT-2020 (a.k.a. 5G) are in 81 progress in several industry communities and standard organizations. 82 The goal of 5G is to integrate various services, each of which has a 83 set of unique requirements, into a single network, such that each 84 service has a customized network suited to its needs. The concept 85 "Network Slicing" is widely discussed and considered as the key 86 mechanism to meet diverse service requirements concurrently with the 87 same physical network infrastructure. 89 The Next Generation Mobile Networks (NGMN) gives the definition of 90 network slice in [Network-Slicing-Concept]: 92 "Network Slice Instance: a set of network functions, and resources to 93 run these network functions, forming a complete instantiated logical 94 network to meet certain network characteristics required by the 95 Service Instance(s)." 97 [TR23.799] of 3rd Generation Partnership Project (3GPP) identifies 98 the support of network slicing as one of the key issues to be 99 resolved in the NextGen system: 101 "Network slicing enables the operator to create networks customised 102 to provide optimized solutions for different market scenarios which 103 demands diverse requirements, e.g. in the areas of functionality, 104 performance and isolation." 106 In Focus Group (FG) IMT-2020, which is the Focus Group in ITU-T 107 working on 5G transport network, network slicing is discussed in the 108 Network Softwarization work item. [FG-IMT2020-Gaps] gives the 109 definition of slicing: Slicing allows logically isolated network 110 partitions (LINP) with a slice being considered as a unit of 111 programmable resources such as network, computation and storage. 113 In order to meet the diverse service requirements, end-to-end network 114 slicing is required in 5G, which includes the slicing of the User 115 Equipment (UE), Radio Access Network (RAN), mobile Core network and 116 also the mobile transport network. As one of the widely deployed 117 mobile transport networks, IP/MPLS networks need to provide the 118 functionality and capability required by network slicing. 120 2. Network Slicing Problem Statement 122 This section analyzes the requirements of network slicing on IP/MPLS 123 networks, and identifies the potential gaps between the existing 124 mechanisms and the network slicing requirements. 126 In IP/MPLS networks, Virtual Private Network (VPN) has been widely 127 deployed to provide many different virtual networks on the same 128 physical operator network. It would be beneficial to reuse the 129 existing VPN technologies when possible, with some enhancements from 130 the newly developed technologies such as SDN, NFV, SFC etc., to meet 131 the network slicing requirements. However, the method used to share 132 the resources of the underlying network with the VPNs results in 133 competition for resources between the VPNs, which can make it 134 difficult to provide the degree of isolation and performance needed 135 by some services. These issues are explored in greater detail in the 136 following sections. 138 2.1. Isolation and Separation 140 Network slicing provides a method that allows services with diverse 141 requirements to be provided on the same physical network with greater 142 independence than is usually provided in a packet switching network. 143 Each network slice appears to its users as an independent, dedicated 144 private network which is impervious to anything that is happening on 145 any of the other network slices. This requires a higher degree of 146 isolation than is found in a conventional VPN where traffic patterns 147 in one VPN can increase the latency and jitter in another VPN, and 148 where the shared control plane means that a high workload servicing 149 one VPN can result in less responsiveness to another VPN. The 150 isolation and other service requirements of each user service are 151 likely to be different,and it is important that this is represented 152 in the slices that carry these services to provide an efficient and 153 economic network design. 155 Where 5G is used as the bearer service for real time traffic in 156 applications such as Autonomous Driving, Virtual Reality or 157 industrial control, there is a requirement for ultra-low transport 158 latency and guaranteed bandwidth. In such cases, dedicated data- 159 plane resources may be needed to guarantee the performance of the 160 network slices carrying these services. This allows a high degree of 161 isolation between the network slices so that the required performance 162 is always met even when there is congestion or some other type of 163 degradation occurs in other network slices sharing the same 164 underlying packet network. 166 In addition to the data plane isolation requirement described above, 167 we need to consider the control plane isolation requirements of the 168 various network slices. As with the data plane isolation, the 169 required degree of isolation in control plane will also depend on the 170 application requirements. There are essentially three degrees of 171 control plane isolation that need to be considered: dedicated control 172 plane, hybrid control plane and shared control plane. A dedicated 173 control plane can provide control plane performance guarantees, and 174 allows customization of the control functions, which may be required 175 for the provisioning and optimization of some critical services. 176 With a hybrid control plane, some of the control functions are 177 dedicated to each network slice, while others are shared amongst a 178 number of network slices. The hybrid approach provides a flexible 179 way of achieving the balance between performance and efficiency. 180 With shared control plane, the network slices use the same control 181 plane functions and resources, regardless of whether their data plane 182 are isolated or not. This results in competition between network 183 slices for resources and thus less isolation. In this case, a high 184 computation or high bandwidth event in one slice will result in less 185 responsivity in another slice. 187 It is anticipated that many third-party or vertical industrial 188 networks will be created or migrated onto the 5G network. These 189 third-party or industrial services will be provided with different 190 network slices, and will typically have different requirements on the 191 operation and management of their own network slice. For some of the 192 services, the operation and management of the network slices can be 193 simply delegated to the network operator, as long as the performance 194 requirements and relative isolation of the network slices can be 195 guaranteed. This is much as happens with today's VPN networks. 196 However, for some other services, it is expected that the owner of 197 the service will require more control of the network slice, such as 198 the placement of the network functions, the establishment and 199 selection of the transport path, network resource allocation, etc. 200 In order to meet these requirements, network needs to provide 201 mechanisms to allow the third parties to configure, deploy and manage 202 their own network slice, with minimal intervention from the network 203 operator. 205 The different services will each have their own level of security 206 requirements and will probably deploy different security mechanisms. 207 For many applications the network slice must provide protection 208 against interception of traffic or interruption of service, by 209 unauthorised users. However security is always a balance between the 210 performance, complexity and resources needed, and the economics of 211 the service, including in the case of some Internet of Things (IoT) 212 the energy consumption requirements. The security requirements of 213 the service carried of the network slices may be markedly different 214 and the design needs to accommodate this. What is of critical 215 importance is that each slice is impervious to an attack on any or 216 all of the other network slices. Thus for example if there is a DDoS 217 attack on the elements of one slice, there MUST NOT be any impact on 218 the data plane or control plane of the other network slices. 220 The IP/MPLS network that is the bearer of these network slices needs 221 to provide the mechanisms required to meet the diverse isolation 222 requirements in data plane, control plane, network operation and 223 security. Existing VPN technologies use a mixture of logical 224 separation, and rely on network traffic engineering, either through 225 metric tuning, RSVP, or Segment Routing to provide a degree of 226 traffic isolation. However the isolation is only partial since the 227 VPNs compete for the same resources. Thus to provide the enhanced 228 degree of isolation needed to support more demanding service 229 requirements, a greater degree of isolation needs to be provided by 230 the packet network than is currently. 232 2.2. Customization of the Topology 234 In order to provide the bespoke network structure needed by each of 235 the network service domains, it is necessary to provide each of the 236 network slices with its own customized topology. There are a number 237 of well known methods of providing a virtual topology that can be 238 used to customize the topology: 240 o Multi-topology Routing 241 o Virtual Private Networks 243 o Overlay Networks 245 o Segment Routing 247 Multi-topology Routing (MTR) [RFC4915], [RFC5120], [RFC7307] is a way 248 of causing the underlying routing layer to concurrently form multiple 249 topologies over the physical network either applying a path metric to 250 a link that is specified per topology and computing a shortest path 251 tree that is customised to that topology. Another technique is to 252 use a different ships in the night routing protocol such as Maximally 253 Redundant Trees [RFC7812]. MRT relies on a common routing protocol 254 and a common compute engine to maintain the topology. MRT has only 255 limited application to specialist problems. In neither case is there 256 integration with the data-plane to maintain isolation between the 257 slices. Furthermore it can be difficult to set up and maintain the 258 metrics to get the degree of topology control needs by the various 259 services. In both cases a characteristic of the user packet needs to 260 be used to mark the packet into the correct topology. 262 VPNs are often used to create virtual topologies which separate and 263 isolate the traffic of different users or services. In some VPNs 264 [RFC4364] , [RFC4761], [RFC7432] a common control plane is used to 265 run the topology of the VPN and the topology of the bearer or 266 transport network. Where a separate protocol instance is used, for 267 example as a separate instance of BGP, the control plane of each 268 instance is isolated, but the control traffic and the user traffic of 269 all the instances normally fate shares. If the control plane engages 270 with a resource reservation protocol such as RSVP a further degree of 271 isolation is possible, but this may not be sufficient for the most 272 sensitive applications. 274 A overlay network is normally completely independent of the underlay 275 that provides it with transport services, and normally with no 276 coupling of the routing/signalling protocols and no way to reserve 277 the resources in the underlying data plane, the required degree of 278 isolation is not achieved for the most sensitive applications. 279 Furthermore with this approach the applications have no control over 280 the paths that their packets take across the network. 282 Segment routing (SR) [I-D.ietf-spring-segment-routing] is a technique 283 that bares further consideration in this application space. With the 284 strict source routing approach it is possible for an edge node to 285 precisely specify the network path for its traffic. With loose 286 source routing less control is available and it is a matter of 287 further study whether this provides the degree of isolation needed in 288 the network slicing environment. It is possible to have in effect a 289 control plane and topology per service with the SR approach. However 290 there would need to be co-ordination between the entity creating the 291 topologies and some entity managing the resources in the network. 292 The use of this approach needs further study. 294 2.3. Flexibility of the Topology 296 As described by NGMN, a network slice is formed by a set of network 297 functions, and resources to run these network functions. With the 298 introduction of Network Function Virtualisation (NFV) and Mobile Edge 299 Computing (MEC), the network functions can be dynamically created at 300 different locations, and can migrate from one place to another 301 dynamically. The flexible and dynamic positioning of network 302 functions in a network slice requires that the IP/MPLS networks be 303 enhanced to have the capability of dynamically provisioning the 304 customized network slice topology with on demand connectivity 305 instantiated between the network functions. 307 The requirements is for existing topologies to be modified and new 308 topologies added without any disruption to the other operating 309 topologies. This will require particular attention to the impact on 310 the data plane since reconfiguration of a topology of a network slice 311 may lead to detectable changes, possibly transient, possibly 312 permanent in the forwarding behaviour of other network slices. 314 2.4. Guaranteed Quality of Service 316 5G aims to provide diversified services on the same physical network. 317 One important type of 5G service is mission critical communication. 318 The typical use cases for this are autonomous driving, remote surgery 319 and industrial control systems, etc, which currently require direct 320 point to point communication, or a dedicated network over fixed 321 infrastructure. These services have stringent requirements on 322 latency, jitter, bandwidth, availability and reliability, etc. It is 323 thus necessary that network slices used to carry mission critical 324 services provide end-to-end guaranteed performance. In addition, 325 some enhanced Mobile BroadBand (eMBB) services such as Virtual 326 Reality (VR) which are also the target of 5G operators require 327 transport latency to be at the millisecond (ms) level, and the 328 bandwidth requirement will be several hundreds of Mbps. 330 With the exception of service carried over traffic engineered label 331 switched paths (LSPs) using resource reservation for that LSP, 332 existing VPN technologies share the resources of the underlying 333 network with other VPNs results in competition for resources between 334 them, which makes it difficult to provide the degree of performance 335 needed by the mission critical services. Even when traffic 336 engineering solutions are deployed, there is short term contention 337 for bandwidth making it difficult to achieve the very low latencies 338 some of these proposed new services demand. 340 [DETNET-WG] is working on the deterministic data paths over layer 2 341 and layer 3 network segments, such deterministic paths can provide 342 the bounds on latency, loss, and packet delay variation (jitter), and 343 high reliability that are required. Network slices of an IP/MPLS 344 network may take advantage of the mechanisms defined in Detnet to 345 meet the performance requirement of 5G services. 347 2.5. Management Considerations 349 As the sliced network evolves it will be necessary to provision, de- 350 provision and modify network slices. Great care needs to exercised 351 in this so as to avoid disrupting other slices. This is a more 352 difficult problem than we have historically addressed, except perhaps 353 in the case of specialist time transfer services, because changes in 354 topology can impact the latency of traffic running in the network. 355 The temptation is to avoid this by freezing the paths of existing 356 services. However the danger is that as the network ages, it will 357 become stale with resources stranded because the running services are 358 unable to be modified for fear of disrupting them, whilst new 359 services cannot be provisioned because it is not possible to glean 360 the resources they need from the fragments of discontinued services. 361 Some form of dynamic garbage collection may therefore be needed that 362 operates in such a way as not to introduce a transient into running 363 network slices. 365 3. IANA Considerations 367 This document makes no request of IANA. 369 Note to RFC Editor: this section may be removed on publication as an 370 RFC. 372 4. Security Considerations 374 The security of traffic into and over an network slice needs to be 375 addressed by the owner of the network slice, and it is expected that 376 this would use state of the art methods. Because of the diversity of 377 requirements these are outside the scope of this document. 379 The security of the slices themselves is an important consideration 380 in the design and operation of the network slicing technology. It is 381 important that an attack on the network slicing system is not used as 382 a method of disrupting, a targeted network slice, which may be of 383 high value, or of a critical nature, possibly with safety of life 384 consequences. 386 The nature of the vulnerability of a network slice may be more subtle 387 that we are ordinarily concerned with. Given the delay sensitive 388 nature of the traffic being carried over some network slices a 389 relatively minor congestion or modulated congestion may be sufficient 390 to cause disruption to the slice. It is therefore important to 391 police the ingress traffic of all services, and to take precautions 392 to protect any traffic metering technology deployed. 394 5. Acknowledgements 396 TBD 398 6. Informative References 400 [DETNET-WG] 401 "IETF Detnet Working Group", 2016, 402 . 404 [FG-IMT2020-Gaps] 405 "FG IMT-2020: Report on Standards Gap Analysis", 2015, 406 . 408 [I-D.ietf-spring-segment-routing] 409 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 410 and R. Shakir, "Segment Routing Architecture", draft-ietf- 411 spring-segment-routing-09 (work in progress), July 2016. 413 [Network-Slicing-Concept] 414 "Description of Network Slicing Concept", 2016, 415 . 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 424 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 425 2006, . 427 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 428 LAN Service (VPLS) Using BGP for Auto-Discovery and 429 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 430 . 432 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 433 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 434 RFC 4915, DOI 10.17487/RFC4915, June 2007, 435 . 437 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 438 Topology (MT) Routing in Intermediate System to 439 Intermediate Systems (IS-ISs)", RFC 5120, 440 DOI 10.17487/RFC5120, February 2008, 441 . 443 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 444 King, "LDP Extensions for Multi-Topology", RFC 7307, 445 DOI 10.17487/RFC7307, July 2014, 446 . 448 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 449 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 450 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 451 2015, . 453 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 454 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 455 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 456 . 458 [TR23.799] 459 "Study on Architecture for Next Generation System", 2012, 460 . 463 Authors' Addresses 465 Jie Dong 466 Huawei Technologies 468 Email: jie.dong@huawei.com 470 Stewart Bryant 471 Huawei Technologies 473 Email: stewart.bryant@gmail.com