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