idnits 2.17.1
draft-qiang-netslices-gap-analysis-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 :
----------------------------------------------------------------------------
** There are 57 instances of too long lines in the document, the longest
one being 2 characters in excess of 72.
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 (July 3, 2017) is 2460 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC5440' is defined on line 1091, but no explicit
reference was found in the text
== Outdated reference: A later version (-22) exists of
draft-boucadair-connectivity-provisioning-protocol-14
== Outdated reference: A later version (-15) exists of
draft-ietf-spring-segment-routing-12
== Outdated reference: A later version (-04) exists of
draft-ooamdt-rtgwg-ooam-header-03
-- Obsolete informational reference (is this intentional?): RFC 2679
(Obsoleted by RFC 7679)
-- Obsolete informational reference (is this intentional?): RFC 2680
(Obsoleted by RFC 7680)
Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 none L. Qiang, Ed.
3 Internet-Draft Huawei
4 Intended status: Informational P. Martinez-Julia
5 Expires: January 4, 2018 NICT
6 L. Geng
7 China Mobile
8 J. Dong
9 K. Makhijani
10 Huawei
11 A. Galis
12 University College London
13 S. Hares
14 Hickory Hill Consulting
15 S. Kuklinski
16 Orange
17 July 3, 2017
19 Gap Analysis for Transport Network Slicing
20 draft-qiang-netslices-gap-analysis-01
22 Abstract
24 This document presents network slicing differentiation from the non-
25 partition network or from simply partition of connectivity resources.
26 It lists 7 standardization gaps related to 4 key requirements for
27 network slicing in transport network. It also presents an analysis
28 of existing related work and other potential solutions on network
29 slicing.
31 This gap analysis document aims to provide a basis for future works
32 in transport network slicing.
34 Status of This Memo
36 This Internet-Draft is submitted in full conformance with the
37 provisions of BCP 78 and BCP 79.
39 Internet-Drafts are working documents of the Internet Engineering
40 Task Force (IETF). Note that other groups may also distribute
41 working documents as Internet-Drafts. The list of current Internet-
42 Drafts is at http://datatracker.ietf.org/drafts/current/.
44 Internet-Drafts are draft documents valid for a maximum of six months
45 and may be updated, replaced, or obsoleted by other documents at any
46 time. It is inappropriate to use Internet-Drafts as reference
47 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on January 4, 2018.
50 Copyright Notice
52 Copyright (c) 2017 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
68 2. Terminology and Abbreviation . . . . . . . . . . . . . . . . 4
69 3. Overall Requirements in Network Slicing . . . . . . . . . . . 4
70 4. Network Slicing Specification . . . . . . . . . . . . . . . . 7
71 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7
72 4.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 8
73 4.2.1. YANG Data Models . . . . . . . . . . . . . . . . . . 8
74 4.2.2. Building NSS from Protocol Independent Traffic
75 Engineering Models . . . . . . . . . . . . . . . . . 9
76 5. Network Slicing Cross-Domain Coordination . . . . . . . . . . 10
77 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10
78 5.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 11
79 5.2.1. Autonomic Networking Integrated Model and Approach
80 (ANIMA) . . . . . . . . . . . . . . . . . . . . . . . 11
81 5.2.2. Connectivity Provisioning Negotiation Protocol (CPNP) 12
82 5.2.3. Abstraction and Control of Traffic Engineered
83 Networks (ACTN) . . . . . . . . . . . . . . . . . . . 13
84 5.3. Other Potential Solutions . . . . . . . . . . . . . . . . 14
85 6. Network Slicing Performance Guarantee and Isolation . . . . . 14
86 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14
87 6.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 15
88 6.2.1. Virtual Private Networks . . . . . . . . . . . . . . 15
89 6.2.2. NVO3 . . . . . . . . . . . . . . . . . . . . . . . . 15
90 6.2.3. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 15
91 6.2.4. Segment Routing . . . . . . . . . . . . . . . . . . . 16
92 6.2.5. Deterministic Networking . . . . . . . . . . . . . . 16
93 6.2.6. Flexible Ethernet . . . . . . . . . . . . . . . . . . 17
94 7. Network Slicing OAM with Customized Granularity . . . . . . . 17
95 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 17
96 7.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 18
97 7.2.1. Overview of OAM tools . . . . . . . . . . . . . . . . 18
98 7.2.2. Overlay OAM . . . . . . . . . . . . . . . . . . . . . 19
99 7.2.3. Service Function Chaining . . . . . . . . . . . . . . 19
100 7.2.4. Slice Identification . . . . . . . . . . . . . . . . 19
101 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
106 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
107 12.2. Informative References . . . . . . . . . . . . . . . . . 22
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
110 1. Introduction
112 Network slicing is an approach to enable flexible isolation of
113 network resources and functions for dedicated services, providing a
114 certain level of customization and quality guarantee. It establishes
115 customized dedicated network upon a common infrastructure for
116 vertical industries with flexible design of functions, different
117 performance requirements, system isolation and OAM tools.
119 Several SDOs have investigated network slicing. To list a few: NGMN
120 initiated a study of network slicing in the context of 5G from the
121 mobile network point of view [NGMN-2016]. Around the same time ITU-T
122 IMT 2020 and ITU-T SG13 studied network softwarization that also
123 included network slicing concept. ITU-T has issued a number of
124 recommendations, such as: Gap Analysis [IMT2020-2015], Network
125 Softwarization [IMT2020-2016], Terms & Definitions [IMT2020-2016bis].
126 Open Network Foundation (ONF) has developed a recommendation on
127 applying SDN architecture to Network Slicing [ONF-2016]. Finally,
128 3GPP standards development for 5G includes network slicing in radio
129 access and core networks. 3GPP issued TS 23.501 [TS23-501] about the
130 system architecture for 5G in 2017. BBF started the project SD-406
131 focusing on the end-to-end architecture enhancement and requirements
132 gathering for transport networks. Although these SDOs have done a
133 lot of work, potential requirements especially in the transport
134 network and end-to-end enabling need to be investigated in order to
135 elicit and identify the technical gaps in IETF for transport network
136 slicing.
138 In order to establish a network slice that meets various customer's
139 demands, an infrastructure owner needs to understand how these
140 demands map with the available network resources and accessible
141 capabilities. This also requires end-to-end coverage and inter-
142 domain coordination. Meanwhile, the slice provider provides
143 customized OAM to the tenants under provisioning. Slicing OAM
144 approach is a fundamental capability to guarantee stable, effective
145 and reliable services for the vertical industries. It is also
146 expected to be capable of operations with customized granularity
147 levels that provides robust management flexibilities.
149 This document presents the identified key requirements and
150 investigates potential technical gaps accordingly. To assist
151 understanding of this document, Section 2 outlines the terminology.
152 Section 3 introduces overall requirements of network slicing.
153 Sections 4~7 illustrates resource specification, end-to-end
154 consideration, performance guarantee and OAM concerns respectively.
155 Section 8 summarizes the identified gaps.
157 2. Terminology and Abbreviation
159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
161 document are to be interpreted as described in RFC 2119.
163 All of the network slicing related words used in this document are to
164 interpreted as described in [NS-Framework]
166 3. Overall Requirements in Network Slicing
168 This section introduces 4 key requirements of network slicing derived
169 from [NS-UseCase] as shown in Table 1. These 4 requirements are
170 organized according to a general network slice working process as
171 shown in Figure 1:
173 1: describe network slicing resource/functions and capture
174 requirements (Req. 1)
176 2: network slicing cross-domain coordination (Req. 2)
178 3: construct a performance guaranteed and isolated end-to-end
179 network slice (Req. 3)
181 4: provide necessary Operation & Maintenance & Administration (OAM)
182 (Req. 4)
184 +----------------------------------------------------------+
185 | network slice management and orchestration <-----+
186 +----------------------^-------^---------------------------+ |
187 | | resource/functions
188 | OAM | specification
189 | | |
190 +------------------------v-------+------------------------------+ |
191 | abstracted network slice instance 1 | |
192 +--------------------------------+------------------------------+ |
193 | |
194 +--------------------------------v------------------------------+ |
195 | abstracted network slice instance 2 | |
196 +---------------------------------------------------------------+ |
197 |
198 |
199 +---------+ +---------+ +---------+ |
200 |NS-Domain| cross-domain |NS-Domain| cross-domain |NS-Domain<-----+
201 | Manager <--------------> Manager <--------------> Manager |
202 +---------+ coordination +---------+ coordination +---------+
204 +---------+ +---------+ +---------+
205 | | | | | |
206 +-+---------+--------------+---------+--------------+---------+-+
207 | network slice instance 1 <---+
208 +-+---------+--------------+---------+--------------+---------+-+ |
209 | Domain 1| | Domain 2| | Domain 3| isolation
210 +-+---------+--------------+---------+--------------+---------+-+ |
211 | network slice instance 2 <---+
212 +-+---------+--------------+---------+--------------+---------+-+
213 | | | | | |
214 +---------+ +---------+ +---------+
216 Figure 1: Illustration of Key Requirements
218 Table 1: Requirement Association
220 +-----------------------------------------+------------------------------+
221 | Requirements Illustrated in NS UseCase | Extracted KEY Requirements |
222 +-----------------------------------------+------------------------------+
223 |1) Resource Reservation | |
224 |2) Abstraction | Req 1. Network Slicing |
225 |3) Multi-Access Knowledge | |
226 |4) Multi-Dimensional Service Vertical | Specification |
227 |5) Agile Resource Adjustment | |
228 +-----------------------------------------+------------------------------+
229 |6) Multi-Domain Coordination | Req 2. Network Slicing |
230 | | Cross-Domain |
231 |7) Resource Assurance | Coordination |
232 +-----------------------------------------+------------------------------+
233 | | Req 3. Network Slicing |
234 |8) Performance/Operation Isolation | Performance Guarantee |
235 | | and Isolation |
236 +-----------------------------------------+------------------------------+
237 |9) Independent Slice Management Plane | Req 4. Network Slicing OAM |
238 | Reliability | |
239 +-----------------------------------------+------------------------------+
241 Table 1: Requirements Association
243 o Req 1. Network Slicing Specification (NSS) - The management
244 systems of both network slice providers and operators need to know
245 what and how much resources/network functions they have, so that
246 they can accurately and abstractedly describe the available
247 resources/network functions to tenants or peers. The objective of
248 NSS is to deliver the network slicing requests without incurring
249 any over-utilization of resources. In order to cooperate and
250 provide consistent network slicing service, the way that
251 resources/network functions are described should be homogeneous
252 and compatible among all of the involved technology-specific
253 domains, provides, and slicing platforms.
255 o Req 2. Network Slicing Cross-Domain Coordination (NS-CDC) - From
256 terminal to server (or other terminal), an end-to-end network
257 slice will involve different infrastructural domains (e.g., AN,
258 TN, CN, etc. ) that may be owned by different providers/operators.
259 Each infrastructural domain may be further divided into different
260 administrative domains. That is an end-to-end slice is a logical
261 entity composed by multiple separated components, and the cross-
262 domain coordination is a way to integrate these components
263 together.
265 o Req 3. Network Slicing Performance Guarantee and Isolation (NS-
266 PGI) - In order to enable the safe, secure, privacy-preservation
267 service for multi-tenancy on a common physical network, the
268 isolation among network slices in each of the
269 Data/Control/Management/Service planes are needed. Furthermore,
270 network slices that provide differentiated services usually
271 require different resources. The resources allocated to a network
272 slice must be able to guarantee the service performance
273 requirement.
275 o Req 4. Network Slicing OAM (NS-OAM) - On one end of the spectrum
276 we have those operators that will require a finalized service that
277 they will simply commercialize. On the other end we have those
278 operators that may want to fine-tune all the low-level aspects of
279 the network resources that form their system or service.
280 Moreover, in the middle there is plenty of room for variations.
281 Therefore, the underlying network layers must offer different
282 levels of granularity for the management of their resources, that
283 the upper layer operators can choose according to their needs and
284 objectives.
286 4. Network Slicing Specification
288 4.1. Description
290 Network Slicing Specification (NSS) is meant to describe the network
291 slicing resources and capture requirements from tenants or peer
292 networks to characterize the service expected to be delivered by a
293 network. These requirements include (non-exhaustive): reachability
294 scope (e.g., limited scope, Internet-wide), direction, bandwidth
295 requirements, performance metrics (e.g., one-way delay [RFC2679],
296 loss [RFC2680], or one-way delay variation [RFC3393]), protection and
297 high-availability guidelines (e.g., uRLLC service restoration in less
298 than 50 ms, 100 ms, or 1 second), traffic isolation constraints, and
299 flow identification. NSS is used by a network provider to decide
300 whether existing network slice instances can be reused or (some of
301 them) even combined, or if another network slice instance is needed
302 for a given service.
304 Technology-specific actions are then derived from the technology-
305 agnostic requirements depicted in an NSS. Such actions include
306 configuration tasks and operational procedures. A standard
307 definition of NSS is needed to facilitate the dynamic/ automated
308 negotiation procedure of NSS parameters, but also to homogenize the
309 processing of service requirements.
311 To explain by an example, a network slice may cross multiple domains:
313 o A cloud deployed, NFV enabled, chain of network functions in a
314 virtualized 5G core.
316 o A segment routing [I-D.ietf-spring-segment-routing] based IGP
317 network transport/aggregation or slice-specific application
318 functions.
320 o A PCE [RFC4655] monitored TE-tunnel with ingress and egress
321 points.
323 o Optical, carrier Ethernet or cellular networks.
325 The network slice is a combination of the above technologies. It
326 creates a compelling need for a common resource specification
327 interface across these domains.
329 4.2. Related Work in IETF
331 4.2.1. YANG Data Models
333 As rightfully discussed in [I-D.wu-opsawg-service-model-explained],
334 the IETF has already published several YANG data models that are used
335 to model monolithic functions as well as very few services (e.g.,
336 L2SM, L3SM, EVPN). These models may be used in the context of
337 network slicing if corresponding technologies are required for a
338 given network slice, but none of them can be used to model an NSRD.
340 [RFC7297] describes the Connectivity Provisioning Profile (CPP) and
341 proposes a CPP template to capture connectivity requirements to be
342 met within a service delivery context. Such a generic CPP template
343 is meant to
345 o facilitate the automation of the service negotiation and
346 activation procedures, thus accelerating service provisioning;
348 o set (traffic) objectives of Traffic Engineering (TE) functions and
349 service management functions;
351 o improve service and network management systems with 'decision-
352 making' capabilities based upon negotiated/offered CPPs.
354 [RFC7297] may be considered as a candidate specification for NSRD.
355 Releasing a RFC7297-bis to take into account specific requirements
356 from network slicing is needed. Since [RFC7297] may not be
357 implemented by all providers, the [SLA-Exchange] may be adopted to
358 implement indirect SLA negotiation and SLA events report.
359 [SLA-Exchange] provides an in-band method to exchange the SLA
360 parameters, and then by the receiving devices to translate SLA in
361 technical specific provisioning languages. However, there still does
362 not exist any standard protocol to translate SLA agreements into
363 technical clauses and configurations.
365 4.2.2. Building NSS from Protocol Independent Traffic Engineering
366 Models
368 The NSS requirement for reachability, direction, bandwidth
369 requirements, performance metrics, traffic isolation constraints, and
370 flow identification can be built utilizing protocol which can perform
371 operations (read, write, notification, actions (aka rpcs)) on a yang
372 service layer that supports these traffic engineer and resource
373 definition at the service layers. The network slicing service data
374 model can extend existing work in the TEAS and I2RS working group for
375 protocol-independent topology models. These models support
376 configuration or the dynamic datastores defined in [NMDA] which will
377 be abbreviated as NMDA in this section. This section provides the
378 detail on how the NSS can be built from these models and the RESTCONF
379 protocol.
381 4.2.2.1. Basic Topology Model
383 The basic topology model is defined in [I2RS-Yang] to include a
384 service layer. This topology model is protocol independent and can
385 be utilized as a configuration data model or a dynamic datastores
386 model. The configuration data model must abide by the configuration
387 persistence and referential requirements. The dynamic datastores do
388 not need to abide by the same requirements as the configuration
389 datastore. I2RS is defining a dynamic datastores reference model for
390 a data store which ephemeral. The network slices may want to use
391 configuration, ephemeral datastores, or define a third type of
392 dynamic datastores. The I2RS WG provides a place to collaborate this
393 work on the dynamic datastores.
395 4.2.2.2. TEAS Model Utilization of Basic Topology Model
397 The TEAS topology model [TE-Yang] provides a general description of a
398 Traffic engineering model that provides:
400 o abstract topologies with TE constraints (bandwidth, delay metrics,
401 links to lower layers, some traffic isolation constraints, and
402 some link identifiers);
404 o templates for links or resources;
406 o functionality to read, write, notification, and rpcs.
408 Options that need to be consider are:
410 Augmenting TEAS - The TEAS models provide substantial traffic
411 engineering. It was envisioned in the early topology model that a
412 service resource model would be part of the service layer. This
413 work was delayed until the maturation of the service requirements
414 from L2VPN, L3VPN, and EVPN plus the maturation of resource
415 requirements from 5G. Network slicing provides a good application
416 use case for this work.
418 Why not Augment TEAS - The TEAS models are TE specific, lack of
419 the abstraction for Layer 3+ resources.
421 Dynamic models to combine TEAS models for network-slicing - The
422 network slicing controller operating across domains may wish to
423 create a multiple-domain data model based on the service layer
424 data models exposed by different providers. These service models
425 would not need to be configured, but only learned as providers
426 exchange data with one another. The rules for combining these
427 models could be defined as part of the dynamic datastore for
428 network-slicing.
430 Protocol within a domain - The RESTCONF and NETCONF protocol can
431 support read, write, notification and actions (rpcs) within a
432 domain.
434 Protocol across domains: The RESTCONF protocol currently supports
435 Configuration protocols and 90% of the dynamic datastores. The
436 RESTCONF protocol is being enhanced to support the push of
437 telemetry messages. The RESTCONF protocol could be used to
438 exchange a specific Yang network-slicing service-layer topology
439 (TE and Resources) and for the I2NSF security capabilities between
440 domains.
442 If a multicast of telemetry data is required between domains, then
443 the push model for telemetry information or the IPFIX protocol may
444 be utilized.
446 5. Network Slicing Cross-Domain Coordination
448 5.1. Description
450 The network slicing cross-domain coordination (NS-CDC) requirement
451 includes the following aspects:
453 o Network slice resource/functions coordination: for example, a
454 tenant requests for a network slice with at most 10 ms latency
455 from terminal to server. Different infrastructure/administrative
456 domains should coordinate and negotiate to reach an agreement such
457 as RAN provides at most 2 ms service, TN domain I provides at most
458 4ms service, TN domain II provides at most 2 ms service and CN
459 provides at most 2 ms service;
461 o Configuration information coordination: for example, for a given
462 TN domain, the configuration information such as VLAN ID, remote
463 IP address, physical port ID, etc. need to be coordinated with
464 other TN domains;
466 o Other coordination: for example, RAN (or other access network)
467 needs to notify TN about the information of new attachment point
468 when user moves.
470 From terminal to server, an end-to-end network slice will involve
471 different infrastructure domains (e.g., RAN, TN and CN). An
472 infrastructure domain may be further divided into multiple domains
473 due to geographic isolation, administrative isolation and other
474 reasons. There are two ways to enable an end-to-end network slice:
475 based on a common platform or based on cross-domain coordination.
477 If all of the involved domains belong to the same operator or the
478 same operator union, the common platform solution may be work. In
479 this case, all of the domain controllers only need to communicate
480 with the common platform, and follow the coordination management of
481 this common platform. Whilst the most common case is that the
482 domains belong to different owners/operators/administrators, making
483 it difficult to realize such a common platform. Consequently, the
484 cross-domain coordination will be essential throughout the whole
485 lifecycle of an end-to-end network slice.
487 5.2. Related Work in IETF
489 There are some related works studies the inter-operation/coordination
490 between different entities. Coordination of different components of
491 a slice requires automation. It can be achieved either by
493 1. Coordination protocols such as ANIMA, CPNP
495 2. Or through abstraction and corresponding interfaces as in ACTN.
497 This subsection will briefly review these related work to provide a
498 basis for the gap analysis.
500 5.2.1. Autonomic Networking Integrated Model and Approach (ANIMA)
502 Autonomic Networking Integrated Model and Approach (ANIMA) WG
503 provides a series of tools for distributed and automatic management,
504 which includes: Generic Autonomic Signaling Protocol (GRASP),
505 Autonomic Networking Infrastructure (ANI), etc.
507 GRASP [ANIMA-GRASP] is a protocol for the negotiation between ASAs
508 (Autonomic Service Agent). In GRASP, ASAs could be considered as
509 "APPs" installed on a device. Different ASAs fulfill different
510 management tasks such as parameter configuration, service delivery,
511 etc. Based on GRASP, the same purpose ASAs that installed on
512 different devices are able to inter-operate and negotiate with each
513 other. Network slicing could make use of GRASP for the coordination
514 among devices in the underlying infrastructure layer, as well as the
515 negotiation among different domain managers. However, the security
516 issue incurred by cross-domain usage should be fixed in GRASP.
518 ANI [ANI] is a technical packet consisting of BootStrap (for
519 authentication, domain certification distribution, etc.), ACP (a
520 separate control plane), and GRASP (for control message
521 coordination). ANI could be used to construct the management tunnel
522 among devices in underlying infrastructure layer within a single
523 domain. While the network slicing and cross-domain oriented
524 extensions are necessary.
526 5.2.2. Connectivity Provisioning Negotiation Protocol (CPNP)
528 [I-D.boucadair-connectivity-provisioning-protocol] defines the
529 Connectivity Provisioning Negotiation Protocol (CPNP) that is meant
530 to dynamically exchange and negotiate connectivity provisioning
531 parameters, and other service-specific parameters, between a Customer
532 and a Provider. CPNP is a tool that introduces automation in service
533 negotiation and activation procedures, thus fostering the overall
534 service provisioning process.
536 CPNP runs between a Customer and a Provider carrying service orders
537 from the Customer and respective responses from the Provider to the
538 end of reaching a connectivity service provisioning agreement. As
539 the services offered by the Provider are well-described, by means of
540 the CPP template, the negotiation process is essentially a value-
541 settlement process, where an agreement is pursued on the values of
542 the commonly understood information items (service parameters)
543 included in the service description template.
545 The protocol is transparent to the content that it carries and to the
546 negotiation logic, at Customer and Provider sides, that manipulates
547 the content.
549 The protocol aims at facilitating the execution of the negotiation
550 logic by providing the required generic communication primitives.
552 CPNP can be used in the context of network slicing to request for
553 network resources together with a set of requirements that need to be
554 satisfied by the Provider. Such requirements are not restricted to
555 basic IP forwarding capabilities, but may also include a
556 characterization of a set of service functions that may be invoked.
558 5.2.3. Abstraction and Control of Traffic Engineered Networks (ACTN)
560 ACTN [TEAS-ACTN] is an information model proposed by TEAS WG, which
561 enables the multi-domain coordination in Traffic Engineering (TE)
562 network. In order to enable network slicing in transport networks,
563 portion of transport domain will need to be engineered. In
564 particular, building a TE entity and stitching service for this
565 entity is within the scope of ACTN. As an end-to-end network slicing
566 solution, ACTN is able to provide cross-domain coordination. In
567 ACTN, each physical transport network domain is under the control of
568 a Physical Network Controller (PNC) as shown in Figure 2. A Multi-
569 Domain Service Coordinator (MDSC) controls multiple PNCs. Although
570 the MDSCs may form a hierarchical structure, a hierarchical MDSC can
571 still be regarded as a logical common platform. As Section 5.1
572 discussed, such a common platform solution has a strict presumption
573 that all domains are assumed to follow a common coordination
574 management.
576 While ACTN does carry out network slicing-related work, some proposed
577 concepts are similar the concepts of today's network slicing: in
578 particular, the virtual network (VN) is similar to a slice instance.
579 ACTN enables VN based on LSP technique, different LSP tunnels
580 correspond to different VNs. However, ACTN focuses on resource
581 abstraction and management on Layer 2 and Layer 1. For transport
582 network slicing, resources abstraction and management on Layer 3+
583 (e.g., IP routing table, etc.) may also be necessary but have not
584 been addressed by ACTN.
586 +-------+ +-------+ +-------+
587 | CNC-A | | CNC-B | | CNC-C |
588 +---+---+ +---+---+ +---+---+
589 | | |
590 +-------\ |CMI /------+
591 \ | /
592 +---------+----------+
593 | (Hierarchical)MDSC |
594 +---------+----------+
595 / | \
596 +-------+ |MPI +---------+
597 | | |
598 +---+---+ +-------+ +----+--+
599 | PNC | | PNC | | PNC |
600 +-------+ +-------+ +-------+
602 Figure 2: A Three-tier ACTN Control Hierarchy
604 5.3. Other Potential Solutions
606 5G Exchange (5GEx) [FGEx] is a 5G-PPP project which aims to enable
607 cross-domain orchestration of services over multiple administrations
608 or over multi-domain single administration networks. The main
609 infrastructure considered in 5GEx is the NFV/SDN compatible software
610 defined infrastructure, which limits the scope of network slicing to
611 SDN based architecture.
613 6. Network Slicing Performance Guarantee and Isolation
615 6.1. Description
617 Network slicing is expected to enable the deployment of various
618 services with diverse requirements, independently on a common
619 physical network. Each network slice is characterized by particular
620 service requirements, which usually are expressed using in the form
621 of several key performance indicators (KPIs) such as bandwidth,
622 latency, jitter, packet loss, etc., and different degrees of
623 isolation. Isolation requirements include performance isolation,
624 which means performance guarantee are maintained regardless of
625 activity in other slices, as well as secure isolation (e.g.,
626 including privacy), and management (or OAM) isolation. Additionally,
627 performance isolation in network slicing has to maintain while
628 scaling up or down computing capabilities of a slice (i.e., for
629 elastic scaling). Moreover, since IoT is also a use case for NS, and
630 since some IoT applications are sensitive to data plane or bits on
631 wire overheads, data path encapsulation in the form of labels, VLANs,
632 VxLANs should be optional, or minimized for those cases.
634 As we will discuss in the detailed sections below, each of these
635 technologies can address some but not all performance and isolation
636 requirements:
638 o RSVP-TE, Segment Routing (SR), DETNET, FlexE are mostly related to
639 performance guarantee and performance isolation requirements
641 o Virtual Private Networks (VPN), NVO3 are mostly related to
642 security and management isolation requirements
644 A Network Slicing solution, to support performance guarantee and
645 isolation requirements, will therefore need to merge in some way
646 characteristics from these two families of technologies, through the
647 combination of (possibly enhanced) existing technologies and/or
648 specifically developed ones. We can also consider the possibility
649 that multiple such technology stacks may be deployed in different
650 domains, and rely on cross-domain coordination, as described
651 inSection 5, to form a single abstracted network slice.
653 6.2. Related Work in IETF
655 6.2.1. Virtual Private Networks
657 VPN technologies such as L3VPN [RFC4364], L2VPN [RFC4664], EVPN
658 [RFC7432], etc. have been widely deployed to provide different
659 virtual networks on common service provider networks. Although VPNs
660 can provide logically separated routing/bridging domains between
661 different VPN customers, essentially it is an overlay network
662 technology with little control of the network resources, so it is
663 challenging for VPN to meet the performance and isolation requirement
664 of some emerging application scenarios such as industrial verticals.
665 VPNs essentially are private networks of enterprises by connecting
666 remote sites. The following two issues illustrate limitations of
667 VPNs for network slicing:
669 o An end-to-end VPN tunnel competes with other traffic in the
670 network and end-to-end network resource policies cannot be
671 guaranteed.
673 o The reachability and resource reservation protocols are not
674 tightly integrated and often solutions require centralized PCE-P
675 like methods.
677 6.2.2. NVO3
679 [NVO3-WG] defines several network encapsulations which support the
680 network virtualization and multi-tenancy in the data center networks.
681 Similar to the VPN technologies of service provider networks, NVO3 is
682 also an overlay network technology, which relies on the performance
683 characteristics provided by the IP-based underlay networks. Thus
684 NVO3 may not meet by itself the performance and isolation
685 requirements of network slicing.
687 6.2.3. RSVP-TE
689 RSVP-TE [RFC3209] is the signaling protocol to establish end-to-end
690 traffic-engineered Label Switched Paths (LSPs). It can reserve the
691 required link bandwidth along an end-to-end path for specific network
692 flows, which is suitable for services with particular requirement on
693 traffic bandwidth. RSVP-TE LSPs can be used as the underlay tunnels
694 of the VPN service connections. However, the requirement of some
695 emerging services is not only about traffic bandwidth, but also has
696 quite strict requirement on latency, jitter, etc. Such requirements
697 can hardly be met with existing RSVP-TE.
699 6.2.4. Segment Routing
701 [I-D.ietf-spring-segment-routing] provides the ability to specify a
702 traffic-engineered path by the source node of data packets. It can
703 provide traffic-engineering features comparable to RSVP-TE with
704 better scalability, by eliminating the per-path state in the transit
705 network nodes. It is therefore a candidate method of creating an
706 NSI, mapping a packet into an NSI and specifying the passage of the
707 packet through the resources dedicated to the NSI. Further study
708 will be required to determine if/how SR as designed today can be used
709 as a core technology for building an NSI. With respect to
710 performance guarantee and isolation, some further investigation may
711 be needed to understand whether SR can provide the same or better
712 performance characteristics as RSVP-TE. In addition, it is not clear
713 whether SR-based LSPs can provide the guaranteed latency and jitter
714 performance required by network slicing.
716 6.2.5. Deterministic Networking
718 [DETNET-WG] is working on the deterministic data paths over layer 2
719 and layer 3 network segments. Such deterministic paths can provide
720 identified flows with extremely low packet loss rates, low packet
721 delay variation (jitter) and assured maximum end-to-end delivery
722 latency. This is accomplished by dedicating network resources such
723 as link bandwidth and buffer space to DetNet flows and/or classes of
724 DetNet flows. DetNet also aims to provide high reliability by
725 replicating packets along multiple paths. It is a characteristic of
726 DetNet that it is concerned solely with worst-case values for the
727 end-to-end latency.
729 The primary target of DetNet is real-time systems and as such
730 average, mean, or typical latency values are not protected, because
731 they do not affect the ability of a real-time system to perform their
732 tasks. This contrasts with a normal priority-based queuing scheme
733 which will give better average latency to a data flow than DetNet,
734 but, on the other side, the worst-case latency can be essentially
735 unbounded. As such DetNet seems to be a useful technique that may be
736 applied to either a complete NSI, or to part of the traffic within an
737 NSI to address the emerging low latency requirement for real time
738 application.
740 DetNet can therefore address some of the requirements of NS. It was
741 however not designed with network slicing in mind, which means a
742 mapping between an NSI and a DetNet service may need to be defined.
744 6.2.6. Flexible Ethernet
746 [FLEXE-1.0] was initially defined by Optical Internetworking Forum
747 (OIF) as an interface technology which allows the complete decoupling
748 of the Media Access Control layer (MAC) data rates and the standard-
749 based Ethernet Physical layer (PHY) rates. The channelization
750 capability of FlexE can be used to partition a FlexE interface into
751 several independent sub-interfaces, which can be considered as a
752 useful component for the slicing of network interfaces. Currently
753 there is ongoing work in IETF to define the control plane framework
754 for FlexE [FlexE-FWK], which aims to identify the routing and
755 signaling extensions needed for establishing FlexE-based end-to-end
756 LSPs in IP/MPLS networks.
758 7. Network Slicing OAM with Customized Granularity
760 7.1. Description
762 In accordance with [RFC6291], OAM is used to denote the following:
764 o Operations: refer to activities that are undertaken to keep the
765 network and the services it deliver up and running. It includes
766 monitoring the underlying resources and identifying problems.
768 o Administration: refer to activities to keep track of resources
769 within the network and how they are used.
771 o Maintenance: refer to activities to facilitate repairs and
772 upgrades. Maintenance also involves corrective and preventive
773 measures to make the managed network run more effectively, e.g.,
774 adjusting configuration and parameters.
776 As per [RFC6291], network slicing provisioning operations are not
777 considered as part of OAM. Provisioning operations are discussed in
778 other sections.
780 Maintaining automatically-provisioned slices within a network raises
781 the following requirements:
783 o Ability to run OAM activities on a provider's customized
784 granularity level. In other words, ability to run OAM activities
785 at any level of granularity that a service provider see fit. In
786 particular:
788 * Per slice OAM: An operator must be able to execute OAM tasks on
789 a per slice basis.
791 * Per domain OAM: These tasks can cover the "whole" slice within
792 a domain or a portion of that slice (for troubleshooting
793 purposes, for example).
795 * Per service OAM: When a given slice is shared among multiple
796 services/customers, an operator must be able to execute (per-
797 slice) OAM tasks for a particular service or customer.
799 * For example, OAM tasks can consist in tracing resources that
800 are bound to a given slice, tracing resources that are invoked
801 when forwarding a given flow bound to a given network slice,
802 assessing whether flow isolation characteristics are in
803 conformance with the NS Resource Specification, or assessing
804 the compliance of the allocated slice resource against flow/
805 customer requirements.
807 * An operator must be able to enable differentiated failure
808 detect and repair features for a specific/subset of network
809 slices. For example, a given slice may require fast detect and
810 repair mechanisms (e.g., as a function of the nature of the
811 traffic (pattern) forwarded through the NS), while others may
812 not be engineered with such means.
814 o Ability to automatically discover the underlying service functions
815 and the slices they are involved in or they belong to.
817 o Ability to dynamically discover the set of network slicing that
818 are enabled within a network. Such dynamic discovery capability
819 facilitates the detection of any mismatch between the view
820 maintained by the control plane and the actual network
821 configuration. When mismatches are detected, corrective actions
822 must be undertaken accordingly.
824 o Ability to efficiently OAM on shared resources. If multiple
825 network slices share some resources, the same kind of OAM
826 operations from different network slices should be performed only
827 once for efficiency. For example, several network slices share a
828 link. We only need to execute once status query, and directly
829 return the queried result to other status query requests.
831 7.2. Related Work in IETF
833 7.2.1. Overview of OAM tools
835 The reader may refer to [RFC7276] for an overview about available OAM
836 tools. These technology-specific tools can be reused in the context
837 of network slicing. Providers that deploy network slicing
838 capabilities should be able to select whatever OAM technology-
839 specific feature that would be address their needs. No gap that
840 would legitimate specific requirements has been identified so far.
842 7.2.2. Overlay OAM
844 [I-D.ooamdt-rtgwg-ooam-header] specifies a generic OAM header that
845 can be used if overlay technologies are enabled. Obviously, this
846 effort can be reused in the context of network slicing when overlay
847 techniques are in use. Nevertheless, For slice designs that do not
848 assume an overlay technology, OAM packets must be able to fly over
849 the appropriate slice and for a given service/customer. This is
850 possible by reusing some existing tools if and only if no specific
851 fields are required (e.g., carry a slice identifier as Req. 5
852 stated).
854 7.2.3. Service Function Chaining
856 SFC WG [SFCWG] is chartered to describe data plane service
857 encapsulation, control and manageability aspects of service
858 functions. Extensions that will be specified by the SFC WG will be
859 reused in the context of network slicing. Nevertheless, The current
860 charter of the WG does not imply work on the automated discovery of
861 SF instances and their capabilities, nor the automatic discovery of
862 control elements. An additional specification effort is therefore
863 required in this area.
865 7.2.4. Slice Identification
867 A network slice data plane, may or may not follow traditional data
868 plane tagging/labeling. However, each network element (router/
869 switch) still has to classify an incoming packet and associated with
870 the slice instance for proper treatment. Network slice instance
871 identification is essential for network element to make local
872 decisions on forwarding policies, QoS mechanism and etc. The
873 performance requirements of a network slice instance can therefore
874 been met by making the correct decision. Meanwhile, it is also
875 important for OAM so that configuration and provisioning can be
876 delicately performed to particular network slice instances by their
877 identifications.
879 For flow identification, many existing technologies provide mature
880 solutions. These approaches might be able to be re-used in network
881 slicing by adding an additional layer of mapping to a network slice
882 instance ID. The network slice instance ID further maps to a group
883 of performance requirements and OAM profiles, based on which the
884 network elements within the slice can make local decisions. However,
885 per flow level identification could have adverse impact on the scale
886 of the forwarding entries in the routers.
888 With traditional IP/MPLS VPNs, the set of Route Targets configured
889 for the VPN can be used as some sort of identifier of the VPN in the
890 control plane, and in the data plane, the VPN service labels can be
891 used to identify the data packets belonging to a particular VPN.
892 NVO3 uses the Virtual Network Identifiers (VNIs) in the header of
893 data packets to identify different overlay network tenants. However,
894 It is not clear if the existing identifiers can meet the requirements
895 of network slicing in terms of making local decisions on forwarding
896 policy, QoS and OAM mechanisms, etc.
898 8. Summary
900 The following table is a summary of the identified gaps based on
901 previous analysis in this document.
903 +--------------------------------+---------------------------------------+
904 | Requirements | Gaps |
905 +--------------------------------+---------------------------------------+
906 | | |
907 |Req 1. Network Slicing | 1) A detailed specification of NSS |
908 | Specification | |
909 | (NSS) | 2) A companion YANG data model for |
910 | | NSS |
911 +--------------------------------+---------------------------------------+
912 | | |
913 |Req 2. Network Slicing Cross- | |
914 | Domain Coordination | 3) A companion data model for |
915 | (NS-CDC) | NS-CDC |
916 | | |
917 +--------------------------------+---------------------------------------+
918 | | |
919 |Req 3. Network Slicing | 4) Slicing specific extension on |
920 | Performance Guarantee and| existing technologies |
921 | Isolation (NS-PGI) | |
922 | | |
923 +--------------------------------+---------------------------------------+
924 | | |
925 | | 5) Mechanisms for dynamic discovery |
926 | | of service function instances and |
927 | | their capabilities. Mechanisms for|
928 |Req 4. Network Slicing OAM | dynamic discovery of instantiated |
929 | (NS-OAM) | network slices |
930 | | |
931 | | 6) non-overlay OAM solution |
932 | | |
933 | | 7) Mechanisms for customized |
934 | | granularity OAM |
935 | | |
936 +--------------------------------+---------------------------------------+
938 Table 2: Summary of Gaps
940 9. Security Considerations
942 This document analyzes the standardization work on network slicing in
943 different WGs. As no solution proposed in this document, no security
944 concern raised.
946 10. IANA Considerations
948 There is no IANA action required by this document.
950 11. Acknowledgements
952 The authors wish to thank Hannu Flinck, Akbar Rahman, Ravi Ravindran,
953 Xavier de Foy, Young Lee and Igor Bryskin for their detailed and
954 constructive reviews. Many thanks to Mohamed Boucadair, Christian
955 Jacquenet and Stewart Bryant for their valuable contributions and
956 comments.
958 12. References
960 12.1. Normative References
962 [NS-Framework]
963 "NS Framework", .
966 [NS-UseCase]
967 "NS Use Case", .
970 12.2. Informative References
972 [ANI] "A Reference Model for Autonomic Networking",
973 .
976 [ANIMA-GRASP]
977 "A Generic Autonomic Signaling Protocol (GRASP)",
978 .
981 [DETNET-WG]
982 "Deterministic Networking",
983 .
985 [FGEx] "5G Exchange (5GEx) - Multi-domain Orchestration for
986 Software Defined Infrastructures",
987 .
991 [FLEXE-1.0]
992 "Flexible Ethernet 1.0", .
995 [FlexE-FWK]
996 "FlexE-FWK", .
999 [I-D.boucadair-connectivity-provisioning-protocol]
1000 Boucadair, M., Jacquenet, C., Zhang, D., and P.
1001 Georgatsos, "Connectivity Provisioning Negotiation
1002 Protocol (CPNP)", draft-boucadair-connectivity-
1003 provisioning-protocol-14 (work in progress), May 2017.
1005 [I-D.ietf-spring-segment-routing]
1006 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
1007 and R. Shakir, "Segment Routing Architecture", draft-ietf-
1008 spring-segment-routing-12 (work in progress), June 2017.
1010 [I-D.ooamdt-rtgwg-ooam-header]
1011 Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L.,
1012 and D. Dolson, "OAM Header for use in Overlay Networks",
1013 draft-ooamdt-rtgwg-ooam-header-03 (work in progress),
1014 March 2017.
1016 [I-D.wu-opsawg-service-model-explained]
1017 Wu, Q., LIU, W., and A. Farrel, "Service Models
1018 Explained", draft-wu-opsawg-service-model-explained-06
1019 (work in progress), May 2017.
1021 [I2RS-Yang]
1022 "A Data Model for Network Topologies",
1023 .
1026 [IMT2020-2015]
1027 "Report on Gap Analysis", .
1030 [IMT2020-2016]
1031 "Draft Technical Report Application of network
1032 softwarization to IMT-2020 (O-041)",
1033 .
1036 [IMT2020-2016bis]
1037 "Draft Terms and definitions for IMT-2020 in ITU-T
1038 (O-040)", .
1041 [NGMN-2016]
1042 "Description of Network Slicing Concept",
1043 .
1046 [NMDA] "Network Management Datastore Architecture",
1047 .
1050 [NVO3-WG] "Network Virtualization Overlays".
1052 [ONF-2016]
1053 TS, "Applying SDN Architecture to 5G Slicing",
1054 .
1058 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
1059 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679,
1060 September 1999, .
1062 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
1063 Packet Loss Metric for IPPM", RFC 2680,
1064 DOI 10.17487/RFC2680, September 1999,
1065 .
1067 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
1068 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
1069 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
1070 .
1072 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
1073 Metric for IP Performance Metrics (IPPM)", RFC 3393,
1074 DOI 10.17487/RFC3393, November 2002,
1075 .
1077 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
1078 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
1079 2006, .
1081 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
1082 Element (PCE)-Based Architecture", RFC 4655,
1083 DOI 10.17487/RFC4655, August 2006,
1084 .
1086 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
1087 2 Virtual Private Networks (L2VPNs)", RFC 4664,
1088 DOI 10.17487/RFC4664, September 2006,
1089 .
1091 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
1092 Element (PCE) Communication Protocol (PCEP)", RFC 5440,
1093 DOI 10.17487/RFC5440, March 2009,
1094 .
1096 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
1097 D., and S. Mansfield, "Guidelines for the Use of the "OAM"
1098 Acronym in the IETF", BCP 161, RFC 6291,
1099 DOI 10.17487/RFC6291, June 2011,
1100 .
1102 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
1103 Weingarten, "An Overview of Operations, Administration,
1104 and Maintenance (OAM) Tools", RFC 7276,
1105 DOI 10.17487/RFC7276, June 2014,
1106 .
1108 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
1109 Connectivity Provisioning Profile (CPP)", RFC 7297,
1110 DOI 10.17487/RFC7297, July 2014,
1111 .
1113 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
1114 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
1115 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
1116 2015, .
1118 [SFCWG] "\Service Function Chaining (sfc)",
1119 .
1121 [SLA-Exchange]
1122 "Inter-domain SLA Exchange Attribute",
1123 .
1126 [TE-Yang] "YANG Data Model for TE Topologies",
1127 .
1130 [TEAS-ACTN]
1131 "Information Model for Abstraction and Control of TE
1132 Networks (ACTN)", .
1135 [TS23-501]
1136 "System Architecture for the 5G System",
1137 .
1140 Authors' Addresses
1142 Li Qiang (editor)
1143 Huawei
1145 Email: qiangli3@huawei.com
1147 Pedro Martinez-Julia
1148 NICT
1150 Email: pedro@nict.go.jp
1152 Liang Geng
1153 China Mobile
1155 Email: gengliang@chinamobile.com
1157 Jie Dong
1158 Huawei
1160 Email: jie.dong@huawei.com
1162 Kiran Makhijani
1163 Huawei
1165 Email: Kiran.Makhijani@huawei.com
1167 Alex Galis
1168 University College London
1170 Email: a.galis@ucl.ac.uk
1172 Susan Hares
1173 Hickory Hill Consulting
1175 Email: shares@ndzh.com
1177 Slawomir
1178 Orange
1180 Email: slawomir.kuklinski@orange.com