idnits 2.17.1 draft-qiang-netslices-gap-analysis-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 : ---------------------------------------------------------------------------- ** There are 2 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 (June 2, 2017) is 2520 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'X1' is mentioned on line 428, but not defined == Missing Reference: 'X2' is mentioned on line 432, but not defined == Missing Reference: 'X3' is mentioned on line 432, but not defined == Missing Reference: 'Y1' is mentioned on line 439, but not defined == Missing Reference: 'Y2' is mentioned on line 439, but not defined == Missing Reference: 'Z1' is mentioned on line 446, but not defined == Missing Reference: 'Z2' is mentioned on line 446, but not defined == Missing Reference: 'Z3' is mentioned on line 450, but not defined == Unused Reference: 'I-D.ooamdt-rtgwg-ooam-header' is defined on line 1184, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 1279, 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-11 == 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 (~~), 15 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: December 4, 2017 NICT 6 L. Geng 7 China Mobile 8 J. Dong 9 K. Makhijan 10 Huawei 11 A. Galis 12 University College London 13 S. Hares 14 Hickory Hill Consulting 15 S. Kuklinski 16 Orange 17 June 2, 2017 19 Gap Analysis for Network Slicing 20 draft-qiang-netslices-gap-analysis-00 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 15 standardization gaps related to 6 key requirements for 27 network slicing. It also presents an analysis of existing related 28 work and other potential solutions on network slicing. 30 This gap analysis document aims to provide a basis for future works 31 in network slicing. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 4, 2017. 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 . . . . . . . . . . . 5 70 4. Network Slicing Resource Specification . . . . . . . . . . . 8 71 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 8 73 4.2.1. NSRS Templates . . . . . . . . . . . . . . . . . . . 8 74 4.2.2. Building NSRS from Protocol Independent Traffic 75 Engineering Models . . . . . . . . . . . . . . . . . 9 76 5. Cross-Network Segment & Cross-Domain Negotiation . . . . . . 11 77 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 11 78 5.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 12 79 5.2.1. Autonomic Networking Integrated Model and Approach 80 (ANIMA) . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.2.2. Abstraction and Control of Traffic Engineered 82 Networks (ACTN) . . . . . . . . . . . . . . . . . . . 13 83 5.2.3. Connectivity Provisioning Negotiation Protocol (CPNP) 15 84 5.3. Other Potential Solutions . . . . . . . . . . . . . . . . 15 85 6. Guaranteed Slice Performance and Isolation . . . . . . . . . 15 86 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 15 87 6.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 16 88 6.2.1. Virtual Private Networks . . . . . . . . . . . . . . 16 89 6.2.2. NVO3 . . . . . . . . . . . . . . . . . . . . . . . . 16 90 6.2.3. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 17 91 6.2.4. Segment Routing . . . . . . . . . . . . . . . . . . . 17 92 6.2.5. Deterministic Networking . . . . . . . . . . . . . . 17 93 6.2.6. Flexible Ethernet . . . . . . . . . . . . . . . . . . 18 94 7. Network Slicing-Domain Abstraction . . . . . . . . . . . . . 18 95 7.1. Traditional Network Abstraction Technologies . . . . . . 18 96 7.2. Decoupling of Control Planes . . . . . . . . . . . . . . 19 97 7.3. Abstraction of Network in Network . . . . . . . . . . . . 19 98 7.4. Forwarding/Data-plane Abstraction . . . . . . . . . . . . 20 99 7.5. Notion of QoS in Network Slices . . . . . . . . . . . . . 21 100 8. Slice Identification . . . . . . . . . . . . . . . . . . . . 21 101 8.1. Description . . . . . . . . . . . . . . . . . . . . . . . 21 102 8.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 21 103 9. OAM Operation with Customized Granularity . . . . . . . . . . 22 104 9.1. Description . . . . . . . . . . . . . . . . . . . . . . . 22 105 9.2. Related Work in IETF . . . . . . . . . . . . . . . . . . 23 106 9.2.1. Overview of OAM tools . . . . . . . . . . . . . . . . 23 107 9.2.2. Overlay OAM . . . . . . . . . . . . . . . . . . . . . 23 108 9.2.3. Service Function Chaining . . . . . . . . . . . . . . 23 109 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 111 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 112 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 113 14. Informative References . . . . . . . . . . . . . . . . . . . 25 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 116 1. Introduction 118 Network slicing is an approach of flexible isolation of network 119 resources and functions for dedicated services, providing certain 120 level of customization and quality guarantee. It establishes 121 customized dedicated network upon a common infrastructure for 122 vertical industries with flexible design of functions, different 123 performance requirements, system isolation and OAM tools. 125 Several SDOs have investigated the network slicing. Open Network 126 Foundation (ONF) has developed a recommendation on applying SDN 127 architecture to Network Slicing [ONF-2016]. 3GPP is studying the 128 network slicing focusing on radio networks and core networks and it 129 issued an architecture for Next Generation System [NGS-3GPP-2016] 130 September 2016. ITU-T IMT 2020 and ITU-T SG13 is studying network 131 softwarization inclusive of network slicing and it has issues a 132 number of recommendations: Gap Analysis [IMT2020-2015], Network 133 Softwarization [IMT2020-2016], Terms [IMT2020-2016bis]. NGMN is 134 studying the network slicing from the mobile network point of view 135 [NGMN-2016]. Although other SDOs have done a lot of work, potential 136 requirements especially in the transmission network and end-to-end 137 enabling need to be investigated in order to elicit and identify the 138 technical gaps in IETF for network-slice enabled networks. 140 In order to establish a network slice that meets various customer's 141 demands, the infrastructure owner needs to understand how these 142 demands map with the available network resources and accessible 143 capabilities. This also requires end-to-end coverage and inter- 144 domain operation or negotiation between different network segments. 146 Different levels of system abstraction are essential enablers for 147 network slicing. For instance, the infrastructure owner needs to 148 understand performance metrics such as bandwidth, latency, isolation 149 requirements, and traffic forwarding restrictions from slice tenants. 150 Furthermore, these requirements are expected to map with the 151 capabilities of a specific network slice with the nature of 152 flexibility, agility and certain level of customization. Slice 153 tenants do not have to worry about what techniques the slice provider 154 has adopted to meet their specific requirements. Meanwhile, the 155 slice provider provides customized OAM to the tenants under 156 provisioning. Slicing OAM approach is a fundamental capability to 157 guarantee stable, effective and reliable services for the vertical 158 industries. It is also expected to be capable of operations with 159 customized granularity levels that provides robust management 160 flexibilities. 162 This document presents the identified key requirements and 163 investigate potential technical gaps accordingly. To assist 164 understanding of this document, Section 2 outlines the terminology. 165 Section 3 introduces overall requirements of network slicing. 166 Section 4~9 illustrates end-to-end considerations, performance 167 guarantee, system level abstractions and OAM concerns. Section 10 168 summarizes the identified gaps. 170 2. Terminology and Abbreviation 172 o CNC: customer network controller 174 o MDSC: multi-domain service coordinator, could be a hierarchical 175 one 177 o PNC: physical network controller, each transport network domain 178 has a PNC 180 o VN: virtual network 182 o PCC: path computation client, the physical device (normally is the 183 ingress device of an LSP) which requests for a path computation 184 service 186 o TN domain: transmission network domain 188 o NSI: network slice instance 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119. 194 All of the network slicing related words used in this document are to 195 interpreted as described in [NS-Framework]. 197 3. Overall Requirements in Network Slicing 199 This section introduces 6 key requirements of network slicing devried 200 from [NS-UseCase] as shown in Table 1. These 6 requirements are 201 organized according to a general network slice working process as 202 shown in Figure 1: specify the network slicing resource (Req.1); 203 construct a performance guaranteed end-to-end network slice (Req.2 204 and Req.3); necessary abstraction for the constructed end-to-end 205 network slice (Req. 4); Identify the network slice (Req. 5); and 206 provide OAM operations (Req. 6). 208 +----------------------------------------------------------+ 209 | network slice management and orchestration <-----+ 210 +----------------------^-------^---------------------------+ | 211 | | resource 212 | OAM | specification 213 | | | 214 +------------------------v-------+------------------------------+ | 215 | abstracted network slice instance 1 | | 216 +--------------------------------+------------------------------+ | 217 | | 218 +--------------------------------v------------------------------+ | 219 | abstracted network slice instance 2 | | 220 +---------------------------------------------------------------+ | 221 | 222 | 223 +---------+ +---------+ +---------+ | 224 |NS-Domain| cross-domain |NS-Domain| cross-domain |NS-Domain<-----+ 225 | Manager <--------------> Manager <--------------> Manager | 226 +---------+ negotiation +---------+ negotiation +---------+ 228 +---------+ +---------+ +---------+ 229 | | | | | | 230 +-+---------+--------------+---------+--------------+---------+-+ 231 | network slice instance 1 <---+ 232 +-+---------+--------------+---------+--------------+---------+-+ | 233 | Domain 1| | Domain 2| | Domain 3| isolation 234 +-+---------+--------------+---------+--------------+---------+-+ | 235 | network slice instance 2 <---+ 236 +-+---------+--------------+---------+--------------+---------+-+ 237 | | | | | | 238 +---------+ +---------+ +---------+ 240 Figure 1: Illustration of Key Requirements 242 +-------------------------------------------+-----------------------+ 243 | Requirements Illustrated in NS UseCase | Extracted KEY | 244 | | Requirements | 245 +-------------------------------------------+-----------------------+ 246 | 1) Resource Reservation; 2) Transparency; | Req 1. Network | 247 | 3) Multi-Access Knowledge; 4) Multi- | Slicing Resource | 248 | Dimensional Service Vertical | Specification | 249 +-------------------------------------------+-----------------------+ 250 | 5) Multi-Domain Coordination; 6) | Req.2 Cross-Network | 251 | Automated Network Slice Management; 7) | Segment & Cross- | 252 | Resource Assurance | Domain Negotiation | 253 +-------------------------------------------+-----------------------+ 254 | 8) Performance Isolation; 9) Secure | Req.3 Guaranteed | 255 | Isolation; 10) Operation Isolation; 11) | Slice Performance and | 256 | Reliability | Isolation | 257 +-------------------------------------------+-----------------------+ 258 | 12) Abstraction; 13) Subnet Concept; 14) | Req.4 Network Slicing | 259 | Virtualization of Network Functions | Domain-Abstraction | 260 +-------------------------------------------+-----------------------+ 261 | 15) Agile Resource Adjustment; 16) | Req.5 Slice | 262 | Function Sharing; 17) Slice | Identification | 263 | Identification | | 264 +-------------------------------------------+-----------------------+ 265 | 18) Independent per slice management | Req.6 OAM Operations | 266 | plane | with Customized | 267 | | Granularity | 268 +-------------------------------------------+-----------------------+ 270 Table 1: Requirement Association 272 o Req.1 Network Slicing Resource Specification: The management 273 system of both underlying resources/network functions and 274 overlying resource/network functions provided by operator, 275 regardless of being automated, human-guided, or human-operated, 276 needs to manage the description of the resources/network functions 277 it has "in stock" and "under its control". The objective for 278 those systems to have such information is that the resources will 279 form an important part of their business, and thus they must know 280 "what they have" at every moment, so that, for instance, they are 281 able to "deliver" the requests without incurring into any 282 overutilization of their resources. Since the technology-specific 283 actions will be taken accordingly for delivered requests, the way 284 resources are described and specified must be homogeneous and 285 compatible, even among separated domains, providers, and "slicing" 286 platforms. 288 o Req.2 Cross-Network Segment & Cross-Domain Negotiation: Network 289 users in relation to network slicing are entities that operate 290 some set of physical, logical, virtual, or, in general, abstracted 291 resources that are not owned directly by them but provided by 292 operators. From terminal to server (or other terminal), an end- 293 to-end network slice may involve several network segments (e.g., 294 RAN, TN, and CN) that owned by different operators. Each segment 295 may be further divided into different administrative domains. 296 That is an end-to-end slice is a logical entity composed by 297 multiple separated components, and the cross-network segment & 298 cross-domain negotiation is a way to integrate compoments. 300 o Req.3 Guaranteed Slice Performance and Isolation: In order to 301 enable the safe, secure, performance guaranteed service for multi- 302 tenancy on the common physical networks, the isolation in each of 303 the Data /Control /Management /Service planes are needed in 304 network slicing. In general, there are two tiers isolations: Soft 305 and hard isolations. VPN, NVO3, etc. are typical soft isolation 306 technologies, slices isolated through these technologies still may 307 compete for underlying resources in extremes. For some critical 308 services, hard isolation such as FlexE, OTN, etc. are necessary. 310 o Req.4 Network Slicing Domain-Abstraction: To complement the 311 previous requirement (i.e.,Req.3), it is important for network 312 slices to be aware but independent of the domain to which they 313 belong. This implies that they are abstracted from any specific 314 domain, so operators can change their behavior without requiring 315 to reconfigure all individual parts and pieces of the overall 316 system. 318 o Req.5 Slice Identification: Identify the network slices and 319 discovery the corresponding slice. This requirement is associated 320 with privacy and security characteristics of network slicing. The 321 major functionalities may include identifier (ID) assignment, ID 322 certification, ID resolution, etc. In order to implement slice 323 discovery and identification, the negotiation, monitoring and 324 other end-to-end orchestration operations are also required. 326 o Req.6 OAM Operations with Customized Granularity: Different 327 network slice users (operators, customers) will have different 328 requirements. On one end of the spectrum we have those operators 329 that will require a finalized service that they will simply 330 commercialize. On the other end we have those operators that need 331 (or want) to fine-tune all the low-level aspects of the network 332 resources that form their system or service. Moreover, in the 333 middle there is plenty of room for variations. Therefore, the 334 underlying network layers must offer different levels of 335 granularity for the management of their resources, that the upper 336 layer operators can choose according to their needs and 337 objectives. 339 4. Network Slicing Resource Specification 341 4.1. Description 343 Network Slicing Resource Specification (NSRS) is meant to specify the 344 network slicing resources and capture requirements of services, 345 customers, and peer networks to characterize the service expected to 346 be delivered by a network. These requirements include (non- 347 exhaustive): reachability scope (e.g., limited scope, Internet-wide), 348 direction, bandwidth requirements, performance metrics (e.g., one-way 349 delay [RFC2679], loss [RFC2680], or one-way delay variation 350 [RFC3393]), protection and high-availability guidelines (e.g., 351 restoration in less than 50 ms, 100 ms, or 1 second), traffic 352 isolation constraints, and flow identification. NSRS is used by a 353 network provider to decide whether existing network slices can be 354 reused or (some of them) even combined, or if another network slice 355 instance is needed for a given service. 357 Technology-specific actions are then derived from the technology- 358 agnostic requirements depicted in an NSRS. Such actions include 359 configuration tasks and operational procedures. 361 A standard definition of NSRS is needed to facilitate the dynamic/ 362 automated negotiation procedure of NSRS parameters, but also to 363 homogenize the processing of service requirements. 365 4.2. Related Work in IETF 367 4.2.1. NSRS Templates 369 As rightfully discussed in [I-D.wu-opsawg-service-model-explained], 370 the IETF has already published several YANG data models that are used 371 to model monolithic functions as well as very few services (e.g., 372 L2SM, L3SM, EVPN). These models may be used in the context of 373 network slicing if corresponding technologies are required for a 374 given network slice, but none of them can be used to model an NSRS. 376 [RFC7297] describes the Connectivity Provisioning Profile (CPP) and 377 proposes a CPP template to capture connectivity requirements to be 378 met within a service delivery context . Such a generic CPP template 379 is meant to 381 o facilitate the automation of the service negotiation and 382 activation procedures, thus accelerating service provisioning; 384 o set (traffic) objectives of Traffic Engineering functions and 385 service management functions; 387 o improve service and network management systems with 'decision- 388 making' capabilities based upon negotiated/offered CPPs. 390 [RFC7297] may be considered as a candidate specification for NSRS. 391 Releasing a RFC7297-bis to take into account specific requirements 392 from network slicing is needed. Since [RFC7297] may not be 393 implemented by all providers, the [SLA-Exchange] can be used to 394 negotiate the SLAs and report on SLA events. Further analysis is 395 needed to provide a complete package. 397 4.2.2. Building NSRS from Protocol Independent Traffic Engineering 398 Models 400 The NSRS requirement for reachability, direction, bandwidth 401 requirements, performance metrics, traffic isolation constraints, and 402 flow identification can be built utilizing protocol which can perform 403 operations (read, write, notification, actions (aka rpcs)) on a yang 404 service layer that supports these traffic engineer and resource 405 definition at the service layers. The network slicing service data 406 model can extend existing work in the TEAS and I2RS working group for 407 protocol-independent topology models. These models support 408 configuration or the dynamic datastores defined in [NMDA] which will 409 be abbreviated as NMDA in this section. This section provides the 410 detail on how the NSRS can be built from these models and the 411 RESTCONF protocol. 413 4.2.2.1. Basic Topology Model 415 The basic topology model is defined in [I2RS-Yang] in the service 416 layer as shown in Figure 2. This topology model is protocol 417 independent and can be utilized as a configuration data model or a 418 dynamic datastores model. The configuration data model must abide by 419 the configuration persistence and referential requirements. The 420 dynamic datastores do not need to abide by the same requirements. 421 I2RS is defining a dynamic datastores reference model for a data 422 store which ephemeral. The network slices may want to use 423 configuration, ephemeral datastores, or define a third type of 424 dynamic datastores. The I2RS WG provides a place to collaborate this 425 work on the dynamic datastores. 427 +-------------------------------+ 428 / [X1] "Service" / 429 / / * \ TEAS / 430 / / * \ / 431 / / * \ / 432 / [X2] * [X3] / 433 +----------*----------*---*-----+ 434 * * * 435 * * * 436 +-----*-------------**----------+ 437 / * * "L3" / 438 / * * / 439 / [Y1] [Y2] / 440 / * * / 441 / * ** / 442 +-----------*------------*-*----+ 443 * * * 444 * * * 445 +------*---------*----*---------+ 446 / [Z1] * [Z2] / 447 / * / 448 / * / 449 / * / 450 / [Z3] "Optical" / 451 +-------------------------------+ 453 Figure 2: Topology Hierarchy (Stack) Example 455 4.2.2.2. TEAS Model Utilization of Basic Topology Model 457 The TEAS topology model [TE-Yang] provides a general description of a 458 Traffic engineering model that provides: 460 o abstract topologies with TE constraints (bandwidth, delay metrics, 461 links to lower layers, some traffic isolation constraints, and 462 some link identifiers); 464 o templates for links or resources; 466 o functionality to read, write, notification, and rpcs. 468 Options that need to be consider are: 470 Augmenting TEAS - The TEAS models provide substantial traffic 471 engineering. It was envisioned in the early topology model that a 472 service resource model would be part of the service layer. This 473 work was delayed until the maturation of the service requirements 474 from L2VPN, L3VPN, and EVPN plus the maturation of resource 475 requirements from 5G. Network slicing provides a good application 476 use case for this work. 478 Why not Augment TEAS - If the TEAS models make a fundamental 479 assumption that prohibits the use of the model within the network- 480 slicing. [Research and discussion are needed with TEAS on this 481 subject] 483 Dynamic models to combine TEAS models for network-slicing - The 484 network slicing controller operating across domains may wish to 485 create a multiple-domain data model based on the service layer 486 data models exposed by different providers. These service models 487 would not need to be configured, but only learned as providers 488 exchange data with one another. The rules for combining these 489 models could be defined as part of the dynamic datastore for 490 network-slicing. 492 Protocol within a domain - The RESTCONF and NETCONf protocol can 493 support read, write, notification and actions (rpcs) within a 494 domain. 496 Protocol across domains: The RESTCONF protocol currently supports 497 Configuration protocols and 90% of the dynamic datastores. The 498 RESTCONF protocol is being enhanced to support the push of 499 telemetry messages. The RESTCONF protocol could be used to 500 exchange a specific Yang network-slicing service-layer topology 501 (TE and Resources) and for the I2NSF security capabilities between 502 domains. 504 If a multicast of telemetry data is required between domains, then 505 the push model for telemetry information or the IPFIX protocol may 506 be utilized. [More details are needed on the multicast need] 508 5. Cross-Network Segment & Cross-Domain Negotiation 510 5.1. Description 512 The cross-network segment & cross-domain negotiation requirement 513 includes the following aspects: 515 o Network slice resource/functions negotiation: for example, a 516 tenant requests for a network slice with at most 10 ms latency 517 from terminal to server. Different network segments/domains 518 should negotiate to reach an agreement such as RAN provides at 519 most 2 ms service, TN domain I provides at most 4ms service, TN 520 domain II provides at most 2 ms service and CN provides at most 2 521 ms service; 523 o Configuration information negotiation: for example, for a given TN 524 domain, the configuration information such as VLAN ID, remote IP 525 address, physical port ID, etc. need to be negotiated with other 526 TN domains; 528 o Other negotiations: for example, RAN (or other access network) 529 needs to notify TN about the information of new attachment point 530 when user moves. 532 From terminal to server, an end-to-end network slice will involve 533 different network segments (e.g., RAN, TN and CN). Even within the 534 same network segment, there will always involve multiple domains due 535 to geographic isolation, administrative isolation and other reasons. 536 There are two ways to enable an end-to-end network slice: based on a 537 common platform or based on cross-network segment & cross-domain 538 negotiation. 540 If all of the involved network segments and domains belong to the 541 same operator or the same operator union, the common platform 542 solution may be work. In this case, all of the network segments and 543 domains only need to communicate with the common platform, and follow 544 the coordination management of this common platform. Whilst the most 545 common case is that the involved network segments and domains belong 546 to different operators/administrative regions, making it difficult to 547 realize such a common platform. Consequently, the cross-network 548 segment & cross-domain negotiation will be essential throughout the 549 whole lifecycle of an end-to-end network slice. 551 5.2. Related Work in IETF 553 There are some related works studies the inter-operation/negotiation 554 between different entities. This subsection will briefly review 555 these related work to provide a basis for the gap analysis. 557 5.2.1. Autonomic Networking Integrated Model and Approach (ANIMA) 559 Autonomic Networking Integrated Model and Approach (ANIMA) WG 560 provides a series of tools for distributed and automatic management, 561 which includes: Generic Autonomic Signaling Protocol (GRASP) , 562 Autonomic Networking Infrastructure (ANI), etc. 564 GRASP [ANIMA-GRASP] is a protocol for the negotiation between ASAs 565 (Autonomic Service Agent). In GRASP, ASAs could be considered as 566 "APPs" installed on a device. Different ASAs fulfill different 567 management tasks such as parameter configuration, service delivery, 568 etc. Based on GRASP, the same purpose ASAs that installed on 569 different devices are able to inter-operate and negotiate with each 570 other. Network slicing could make use of GRASP for the coordination 571 among devices in the underlying infrastructure layer, as well as the 572 negotiation among different domain (or different network segment) 573 managers. However, the security issue incurred by cross-network 574 segment & cross-domain usage should be fixed in GRASP. 576 ANI [ANI] is a technical packet consisting of BootStrap (for 577 authentication, domain certification distribution, etc.), ACP (a 578 separate control plane), and GRASP (for control message 579 coordination). ANI could be used to construct the management tunnel 580 among devices in underlying infrastructure layer within a single 581 domain. While the network slicing and cross-domain oriented 582 extensions are necessary. 584 5.2.2. Abstraction and Control of Traffic Engineered Networks (ACTN) 586 ACTN [TEAS-ACTN] is an information model proposed by TEAS WG, which 587 enables the multi-domain coordination in transport network. In order 588 to enable the network slicing in transport network, portion of 589 transport domain will need to be engineered. In particular about 590 building a TE entity and stitching service for this entity, that is 591 within the scope of ACTN. As an end-to-end network slicing solution, 592 ACTN is able to provide the cross-network segment negotiation. In 593 ACTN, each physical transport network domain is under the control of 594 a PNC as shown in Figure 3. Based on a MDSC, multiple PNCs 595 coordinate with each other. Although the MDSC may be a hierarchical 596 structure, the hierarchical MDSC still could be regarded as a logical 597 common platform. As Section 5.1 discussed, such common platform 598 solution has a strict presumption. Thus, ACTN is not a clear E2E 599 model. It is a multi-tier multi-service provider abstraction that 600 heavily relies on centralization using SDN methods. 602 ACTN does carry out some network slicing-related work, some proposed 603 concepts are even close to the concepts of today's network slicing, 604 like virtual network (VN, similar concept of slice instance). ACTN 605 enables VN based on LSP technique, different LSP tunnels correspond 606 to different VNs. From the isolation perspective, LSP belongs to the 607 soft-isolation category. For those critical services that have very 608 strict isolation requirement, the soft-isolation is not enough since 609 different VNs/network slices (i.e, LSP tunnels in ACTN) still may 610 compete for underlying resources. 612 The biggest factor that prevents ACTN from being directly applied to 613 network slicing is that, ACTN and network slicing have totally 614 different management modes. ACTN is path-oriented (i.e., TE tunnel 615 based), whilst network slicing is resource-oriented. Take the 616 scenario shown in Figure 4 as an example, there are two LSPs: LSP1 617 (A->C->D, 20G) and LSP2 (B->C->D, 20G). If the data-rate from node A 618 changes from 20G to 10G and B changes from 20G to 30G, both LSP1 and 619 LSP2 have to be reconfigured, even through path from C->D has no 620 change. In summary, 622 +-------+ +-------+ +-------+ 623 | CNC-A | | CNC-B | | CNC-C | 624 +---+---+ +---+---+ +---+---+ 625 | | | 626 +-------\ |CMI /------+ 627 \ | / 628 +---------+----------+ 629 | (Hierarchical)MDSC | 630 +---------+----------+ 631 / | \ 632 +-------+ |MPI +---------+ 633 | | | 634 +---+---+ +-------+ +----+--+ 635 | PNC | | PNC | | PNC | 636 +-------+ +-------+ +-------+ 638 Figure 3: A Three-tier ACTN Control Hierarchy 640 o In-segment resource: ACTN only abstracts the topology and link 641 features, it neither supports standard resource capability 642 exposure nor facilitates distributed resource changes. 644 o L2 resource negotiation: ACTN does not provide the L2 resource 645 negotiation among devices. 647 o Network perspective coordination: any change in a single tunnel 648 requires re-computation of path on MDSC, which is expensive and 649 not well coordinated. I.e. there is no notion of distributed 650 negotiation of resources among different TE tunnels. 652 20G->10G +---+ 653 ---------->+ A +----+20G->10G 654 +---+ | 655 +--->+---+ 40G +---+ 656 | C +----->+ D | 657 +--->+---+ +---+ 658 20G->30G +---+ | 659 ---------->+ B +----+20G->30G 660 +---+ 662 Figure 4: An Illustration Example for Path-Oriented Management 664 5.2.3. Connectivity Provisioning Negotiation Protocol (CPNP) 666 [I-D.boucadair-connectivity-provisioning-protocol] defines the 667 Connectivity Provisioning Negotiation Protocol (CPNP) that is meant 668 to dynamically exchange and negotiate connectivity provisioning 669 parameters, and other service-specific parameters, between a Customer 670 and a Provider. CPNP is a tool that introduces automation in the 671 service negotiation and activation procedures, thus fostering the 672 overall service provisioning process. 674 CPNP runs between a Customer and a Provider carrying service orders 675 from the Customer and respective responses from the Provider to the 676 end of reaching a connectivity service provisioning agreement. As 677 the services offered by the Provider are well-described, by means of 678 the CPP template, the negotiation process is essentially a value- 679 settlement process, where an agreement is pursued on the values of 680 the commonly understood information items (service parameters) 681 included in the service description template. 683 The protocol is transparent to the content that it carries and to the 684 negotiation logic, at Customer and Provider sides, that manipulates 685 the content. 687 The protocol aims at facilitating the execution of the negotiation 688 logic by providing the required generic communication primitives. 690 CPNP can be used in the context of network slicing to request for 691 network resources together with a set of requirements that need to be 692 satisfied by the Provider. Such requirements are not restricted to 693 basic IP forwarding capabilities, but may also include a 694 characterization of a set of service functions that may be invoked. 696 5.3. Other Potential Solutions 698 5G Exchange (5GEx) [FGEx] is a 5G-PPP project which aims to enable 699 cross-domain orchestration of services over multiple administrations 700 or over multi-domain single administration networks. The main 701 infrastructure considered in 5GEx is the NFV/SDN compatible software 702 defined infrastructure, which limits the scope of network slicing to 703 SDN based architecture. 705 6. Guaranteed Slice Performance and Isolation 707 6.1. Description 709 With network slicing, it is expected to enable the deployment of 710 various services with diverse requirements independently on the 711 common physical networks. Each network slice is characterized with 712 particular service requirements, which usually are expressed in the 713 form of several key performance indicators (KPIs) such as bandwidth, 714 latency, jitter, packet loss, etc., and different degrees of 715 isolation. It should be noted that the requirement on isolation is 716 not just related to guaranteed performance, for some services it is 717 also critical to achieve the isolation in terms of network privacy, 718 security, management and operation, etc. 720 It is important that the performance and isolation requirements of 721 each network slice can always be met regardless of what is happening 722 in any other network slices. Otherwise it is likely that some of the 723 services would still be deployed in their dedicated networks rather 724 than in a shared network infrastructure using network slicing. The 725 requirements on guaranteed performance and isolation cannot simply be 726 met with the creation of separate virtual networks, more importantly 727 it depends on how to instantiate these virtual networks properly on 728 the shared physical network infrastructure with appropriate resource 729 allocation policy and mechanisms, so that the diversified performance 730 and isolation requirements of network slices can be guaranteed in a 731 flexible and efficient way. 733 6.2. Related Work in IETF 735 6.2.1. Virtual Private Networks 737 Virtual Private Networks (VPN) technologies such as L3VPN [RFC4364], 738 L2VPN [RFC4664], EVPN [RFC7432], etc. have been widely deployed to 739 provide different virtual networks on the common service provider 740 networks. Although VPNs can provide logically separated routing/ 741 bridging domains between different VPN customers, essentially it is 742 an overlay network technology with little control of the network 743 resources, so it is challenging for VPN to meet the performance and 744 isolation requirement of some emerging application scenarios such as 745 industrial verticals. 747 6.2.2. NVO3 749 [NVO3-WG] defines several network encapsulations which support the 750 network virtualization and multi-tenancy in the data center networks. 751 Similar to the VPN technologies of service provider networks, NVO3 is 752 also an overlay network technology, which relies on the performance 753 characteristics provided by the IP-based underlay networks. Thus 754 NVO3 may not meet the performance and isolation requirements of 755 network slicing. 757 6.2.3. RSVP-TE 759 RSVP-TE [RFC3209] is the signaling protocol to establish end-to-end 760 traffic-engineered Label Switched Paths (LSPs). It can reserve the 761 required link bandwidth along an end-to-end path for specific network 762 flows, which is suitable for services with particular requirement on 763 traffic bandwidth. RSVP-TE LSPs can be used as the underlay tunnels 764 of the VPN service connections. However, the requirement of some 765 emerging services is not only about traffic bandwidth, but also has 766 quite strict requirement on latency, jitter, etc. Such requirements 767 can hardly be met with existing RSVP-TE. 769 6.2.4. Segment Routing 771 [I-D.ietf-spring-segment-routing] provides the ability to specify a 772 traffic-engineered path by the source node of data packets, which is 773 also known as a approach for source routing. It can provide 774 comparable traffic-engineering features as RSVP-TE with better 775 scalability, by eliminating the per-path state in the transit network 776 nodes. It is therefore a candidate method of creating an NSI, 777 mapping a packet into an NSI and specifying the passage of the packet 778 through the resources dedicated to the NSI. Segment Routing as 779 designed today could be used within an NSI without further 780 modification, but its use as a method providing an NSI requires 781 further study. With respect to performance guarantee and isolation, 782 some further investigation may be needed to understand whether SR can 783 provide the same or better performance characteristics as RSVP-TE 784 without the flow state in the transit node. In addition, it is not 785 clear whether SR-based LSPs can provide the guaranteed latency and 786 jitter performance required by network slicing. 788 6.2.5. Deterministic Networking 790 [DETNET-WG] is working on the deterministic data paths over layer 2 791 and layer 3 network segments, such deterministic paths can provide 792 identified flows with extremely low packet loss rates, low packet 793 delay variation (jitter) and assured maximum end-to-end delivery 794 latency. This is accomplished by dedicating network resources such 795 as link bandwidth and buffer space to DetNet flows and/or classes of 796 DetNet flows. DetNet also aims to provide high reliability by 797 replicating packets along multiple paths. It is a characteristic of 798 DetNet that it is concerned solely with worst-case values for the 799 end-to-end latency. 801 The primary target of DetNet is real-time systems and as such 802 average, mean, or typical latency values are of not protected, 803 because they do not affect the ability of a real-time system to 804 perform their tasks. This contrasts with a normal priority-based 805 queuing scheme which will give better average latency to a data flow 806 than DetNet, but of course, the worst-case latency can be essentially 807 unbounded. As such DetNet seems to be a useful technique that may be 808 applied to either a complete NSI, or to components of the traffic 809 within an NSI to address the emerging low latency requirement for 810 real time application. 812 Where an NSI is created recursively, there must be a mapping between 813 the latency requirements of the child NSI onto the latency SLA 814 provided by the parent, which in turn must trace back to the SLA 815 provided by the underlay. 817 DetNet is not currently designed with network slicing in mind. As 818 such the mapping between an NSI and a DetNet service needs to be 819 defined. 821 6.2.6. Flexible Ethernet 823 [FLEXE-1.0] is initially defined by Optical Internetworking Forum 824 (OIF) as an interface technology which allows the complete decoupling 825 of the Media Access Control layer (MAC) data rates and the standard- 826 based Ethernet Physical layer (PHY) rates. The channelization 827 capability of FlexE can be used to partition a FlexE interface into 828 several independent sub-interfaces, which can be considered as a 829 useful component for the slicing of network interfaces. Currently 830 there is ongoing work in IETF to define the control plane framework 831 for FlexE, which aims to identify the routing and signaling 832 extensions needed for establishing FlexE-based end-to-end LSPs in IP/ 833 MPLS networks. 835 7. Network Slicing-Domain Abstraction 837 7.1. Traditional Network Abstraction Technologies 839 It is important for a network slice to be isolated from other slices 840 and is traditionally achieved through network abstraction 841 technologies such as virtual private networks (VPN [RFC4364]) and 842 other overlays (VLANs, NVO3 [NVO3-WG]). VPNs essentially are private 843 networks of enterprises by connecting remote sites. It is only the 844 partial goal of network slice domain that determines reachability. 845 There are two issues with VPNs: 847 o An end-to-end VPN tunnel competes with other traffic in the 848 network and end-to-end network resource policies cannot be 849 guaranteed. 851 o The reachability and resource reservation protocols are not 852 tightly integrated and often solutions require centralized PCE-P 853 like methods. 855 Network slices partition the infrastructure across multiple domains. 856 They may also share databases from provider or other slices (e.g. 857 subscriber information). 859 In regards to VPN or network virtualization following gaps are 860 identified, 862 o The resources allocated to a slice shall not compete with other 863 traffic, yet have the elasticity scale on-demand. 865 o New service verticals in IoT or mMTC arena are sensitive to data 866 plane or bits on wire overheads. Therefore, encapsulation in the 867 form of labels, VLANs, VxLANs shall be optional in data path (In 868 VPNs etc., some form of tagging is always carried). 870 7.2. Decoupling of Control Planes 872 One of the attributes of abstraction is decoupling of hardware from 873 software for higher flexibility and support for multiple 874 functionalities. In the context of slices the functionality may need 875 to run different control plane protocols than in other slices. As an 876 example, it may be just a layer 3 topology and corresponding routing 877 resource descriptions while another slice, may be an entirely non-IP 878 control plane. The notion of abstraction in slicing shall allow both 880 o Decoupling of control plane of physical network and a sliced 881 network. 883 o Between two slice network instances. 885 Although, care must be taken in the handling of this requirement as 886 excessive control packet processing will lead to a network node's 887 performance degradation and it may need to speak/enable multiple 888 control protocols. 890 7.3. Abstraction of Network in Network 892 To compose a slice across multiple domains, the details of network 893 topology of that domain shall not be exposed at the network slice 894 level. Furthermore, 896 o Inter-play of multiple technologies shall be considered and a 897 common representation for a slice across these domains is 898 required. 900 To explain by example, what this means is that a segment in a network 901 domain can be 903 o A cloud deployed, NFV enabled, chain of network functions in a 904 virtualized 5G core. 906 o A segment routing [I-D.ietf-spring-segment-routing] based IGP 907 network transport/aggregation or slice-specific application 908 functions. 910 o A PCE [RFC4655] monitored TE-tunnel with ingress and egress 911 points. 913 o Optical, carrier Ethernet or cellular networks. 915 A slice instance will be a combination of some of the above 916 technologies. It creates a compelling need for a common resource 917 centric interface across these domains over which resources can be 918 negotiated/allocated for end-to-end slice realization. 920 The network slice operator shall be able to build/visualize own 921 forwarding graph or service chain among these segments. Inside in 922 its network each segment assures resource association with the slice. 924 It is even more efficient to not expose those details to slice 925 orchestrator in order to minimize fine-grained centralized 926 repositories for a large scale multi-domain network. 928 This gap/requirement is tied to resource specification, as well as 929 cross-domain negotiation. Each domain, processes/negotiates the 930 resource spec with respect to a slice, coordinates with the 931 orchestrator and returns an abstract managed object to be used by 932 slice operator. 934 7.4. Forwarding/Data-plane Abstraction 936 A network slice data plane, may or may not follow traditional data 937 plane tagging/labeling. However, each network element (router/ 938 switch) still has to classify an incoming packet and associated with 939 the slice instance for proper treatment. The corresponding 940 forwarding rules shall not have to be programmed at per flow level as 941 this could have adverse impact on scale of the forwarding entries in 942 the routers. NS resource specification shall provide a uniform 943 mapping for a vast set of virtual/logical network entry points from 944 radio, optical, wireless and fixed networks such as ports, 945 interfaces, labels, IP address, MAC address, wavelength lambda etc. 947 7.5. Notion of QoS in Network Slices 949 This sub-section is not meant to argue that there is a gap in QoS 950 abstraction, but indicates that QoS abstraction is not required in 951 network slicing. End-to-end resource awareness is a key 952 differentiating aspect of network slicing. In traditional networks 953 differentiated services, QoS markings, IP precedence or FEC are used 954 to label a group or provide preferential packet treatment. It is 955 expected that a slice has already been engineered for the service 956 with pre-allocation of network resources. Therefore, it can be 957 argued that these parameters have no meaning. A packet or flow in 958 the network slice need not be marked and does not belong to a class. 960 8. Slice Identification 962 8.1. Description 964 Network slice instance identification is essential for network 965 element to make local decisions on forwarding policies, QoS mechanism 966 and etc. The performance requirements of a network slice instance 967 can therefore been met by making the correct decision. Meanwhile, it 968 is also important for OAM so that configuration and provisioning can 969 be delicately performed to particular network slice instances by 970 their identifications. 972 For flow identification, many existing technologies provide mature 973 solutions. These approaches might be able to be re-used in network 974 slicing by adding an additional layer of mapping to a network slice 975 instance ID. The network slice instance ID further maps to a group 976 of performance requirements and OAM profiles, based on which the 977 network elements within the slice can make local decisions. 979 8.2. Related Work in IETF 981 With traditional IP/MPLS VPNs, the set of Route Targets configured 982 for the VPN can be used as some sort of identifier of the VPN in the 983 control plane, and in the data plane, the VPN service labels can be 984 used to identify the data packets belonging to a particular VPN. 985 NVO3 uses the Virtual Network Identifiers (VNIs) in the header of 986 data packets to identify different overlay network tenants. However, 987 It is not clear if the existing identifiers can meet the requirements 988 of network slicing in terms of making local decisions on forwarding 989 policy, QoS and OAM mechanisms, etc. 991 9. OAM Operation with Customized Granularity 993 9.1. Description 995 In accordance with [RFC6291], OAM is used to denote the following: 997 o Operations: refer to activities that are undertaken to keep the 998 network and the services it deliver up and running. It includes 999 monitoring the underlying resources and identifying problems. 1001 o Administration: refer to activities to keep track of resources 1002 within the network and how they are used. 1004 o Maintenance: refer to activities to facilitate repairs and 1005 upgrades. Maintenance also involves corrective and preventive 1006 measures to make the managed network run more effectively, e.g., 1007 adjusting configuration and parameters. 1009 As per [RFC6291], network slicing provisioning operations are not 1010 considered as part of OAM. Provisioning operations are discussed in 1011 other sections. 1013 Maintaining automatically-provisioned slices within a network raises 1014 the following requirements: 1016 o Ability to run OAM activities on a provider's customized 1017 granularity level. In other words, ability to run OAM activities 1018 at any level of granularity that a service provider see fit. In 1019 particular: 1021 * An operator must be able to execute OAM tasks on a per slice 1022 basis. 1024 * These tasks can cover the "whole" slice within a domain or a 1025 portion of that slice (for troubleshooting purposes, for 1026 example). 1028 * For example, OAM tasks can consist in tracing resources that 1029 are bound to a given slice, tracing resources that are invoked 1030 when forwarding a given flow bound to a given network slice, 1031 assessing whether flow isolation characteristics are in 1032 conformance with the NS Resource Specification, or assessing 1033 the compliance of the allocated slice resource against flow/ 1034 customer requirements. 1036 * An operator must be able to enable differentiated failure 1037 detect and repair features for a specific/subset of network 1038 slices. For example, a given slice may require fast detect and 1039 repair mechanisms (e.g., as a function of the nature of the 1040 traffic (pattern) forwarded through the NS), while others may 1041 not be engineered with such means. 1043 * When a given slice is shared among multiple services/customers, 1044 an operator must be able to execute (per-slice) OAM tasks for a 1045 particular service or customer. 1047 o Ability to automatically discover the underlying service functions 1048 and the slices they are involved in or they belong to. 1050 o Ability to dynamically discover the set of network slicing that 1051 are enabled within a network. Such dynamic discovery capability 1052 facilitates the detection of any mismatch between the view 1053 maintained by the control plane and the actual network 1054 configuration. When mismatches are detected, corrective actions 1055 must be undertaken accordingly. 1057 9.2. Related Work in IETF 1059 9.2.1. Overview of OAM tools 1061 The reader may refer to [RFC7276] for an overview about available OAM 1062 tools. These technology-specific tools can be reused in the context 1063 of network slicing. Providers that deploy network slicing 1064 capabilities should be able to select whatever OAM technology- 1065 specific feature that would be address their needs. No gap that 1066 would legitimate specific requirements has been identified so far. 1068 9.2.2. Overlay OAM 1070 [I-D.ooamdt-rtgwg-ooam-header]specifies a generic OAM header that can 1071 be used if overlay technologies are enabled. Obviously, this effort 1072 can be reused in the context of network slicing when overlay 1073 techniques are in use. Nevertheless, For slice designs that do not 1074 assume an overlay technology, OAM packets must be able to fly over 1075 the appropriate slice and for a given service/customer. This is 1076 possible by reusing some existing tools if and only if no specific 1077 fields are required (e.g., carry a slice identifier as Req. 5 1078 stated). 1080 9.2.3. Service Function Chaining 1082 SFC WG [SFCWG] is chartered to define SFC-specific OAM. Extensions 1083 that will be specified by the SFC WG will be reused in the context of 1084 network slicing. Nevertheless, The current charter of the WG does 1085 not imply work on the automated discovery of SF instances and their 1086 capabilities, nor the automatic discovery of control elements. An 1087 additional specification effort is therefore required in this area. 1089 10. Summary 1091 The following table is a summary of the identified gaps based on 1092 previous analysis in this document. 1094 +----------------+--------------------------------------------------+ 1095 | Requirements | Gaps | 1096 +----------------+--------------------------------------------------+ 1097 | Network | 1) A detailed specification of NSRS; 2) A | 1098 | Slicing | companion YANG data model for NSRS; 3) | 1099 | Resource | Mechanisms/protocols for capability exposure; 4) | 1100 | Specification | Mechanism/protocols for NS state monitoring; | 1101 +----------------+--------------------------------------------------+ 1102 | Cross-Network | 5) Mechanisms for secure cross-network segment | 1103 | Segment & | and cross-domain negotiation/inter-operation; 6) | 1104 | Cross-Domain | Information model for network slicing related | 1105 | Negotiation | message exchange; 7) Mechanisms/protocols for | 1106 | | E2E NS composition/decomposition; | 1107 +----------------+--------------------------------------------------+ 1108 | Guaranteed | 8) Mechanisms for on-demand, isolated, elastic | 1109 | Slice | and efficient network slice instantiation and | 1110 | Performance | resource association; | 1111 | and Isolation | | 1112 +----------------+--------------------------------------------------+ 1113 | Network | 9) Common representation mechanism for network | 1114 | Slicing-Domain | slices across multi-domain; 10) Mechanisms for | 1115 | Abstraction | customized network slices; | 1116 +----------------+--------------------------------------------------+ 1117 | Slice | 11) Mechanisms and framework for network slice | 1118 | Identification | identification;12) Mechanisms for dynamic | 1119 | | discovery of instantiated network slices; 13) | 1120 | | Mechanisms for network slicing E2E repository; | 1121 +----------------+--------------------------------------------------+ 1122 | OAM Operation | 14) Mechanisms for dynamic discovery of service | 1123 | with | with function instances and their capabilities; | 1124 | Customized | 15) Mechanisms for customized network slices OAM | 1125 | Granularity | when overlay techniques are not in use. | 1126 +----------------+--------------------------------------------------+ 1128 Table 2: Summary of Gaps 1130 11. Security Considerations 1132 This document analyzes the standardization work on network slicing in 1133 different WGs. As no solution proposed in this document, no security 1134 concern raised. 1136 12. IANA Considerations 1138 There is no IANA action required by this document. 1140 13. Acknowledgements 1142 The authors wish to thank Hannu Flinck, Akbar Rahman and Ravi 1143 Ravindran for their detailed and constructive reviews. Many thanks 1144 to Susan Hares, Mohamed Boucadair, Christian Jacquenet and Stewart 1145 Bryant for their valuable contributions and comments. 1147 14. Informative References 1149 [ANI] "A Reference Model for Autonomic Networking", 1150 . 1153 [ANIMA-GRASP] 1154 "A Generic Autonomic Signaling Protocol (GRASP)", 1155 . 1158 [DETNET-WG] 1159 "Deterministic Networking", 1160 . 1162 [FGEx] "5G Exchange (5GEx) - Multi-domain Orchestration for 1163 Software Defined Infrastructures", 1164 . 1168 [FLEXE-1.0] 1169 "Flexible Ethernet 1.0", . 1172 [I-D.boucadair-connectivity-provisioning-protocol] 1173 Boucadair, M., Jacquenet, C., Zhang, D., and P. 1174 Georgatsos, "Connectivity Provisioning Negotiation 1175 Protocol (CPNP)", draft-boucadair-connectivity- 1176 provisioning-protocol-14 (work in progress), May 2017. 1178 [I-D.ietf-spring-segment-routing] 1179 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1180 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1181 spring-segment-routing-11 (work in progress), February 1182 2017. 1184 [I-D.ooamdt-rtgwg-ooam-header] 1185 Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L., 1186 and D. Dolson, "OAM Header for use in Overlay Networks", 1187 draft-ooamdt-rtgwg-ooam-header-03 (work in progress), 1188 March 2017. 1190 [I-D.wu-opsawg-service-model-explained] 1191 Wu, Q., LIU, W., and A. Farrel, "Service Models 1192 Explained", draft-wu-opsawg-service-model-explained-06 1193 (work in progress), May 2017. 1195 [I2RS-Yang] 1196 "A Data Model for Network Topologies", 1197 . 1200 [IMT2020-2015] 1201 "Report on Gap Analysis", . 1204 [IMT2020-2016] 1205 "Draft Technical Report Application of network 1206 softwarization to IMT-2020 (O-041)", 1207 . 1210 [IMT2020-2016bis] 1211 "Draft Terms and definitions for IMT-2020 in ITU-T 1212 (O-040)", . 1215 [NGMN-2016] 1216 "Description of Network Slicing Concept", 1217 . 1220 [NGS-3GPP-2016] 1221 "Study on Architecture for Next Generation System-latest 1222 version v1.0.2", 1223 . 1226 [NMDA] "Network Management Datastore Architecture", 1227 . 1230 [NS-Framework] 1231 "NS Framework", . 1234 [NS-UseCase] 1235 "NS Use Case", . 1238 [NVO3-WG] "Network Virtualization Overlays". 1240 [ONF-2016] 1241 "Applying SDN Architecture to 5G Slicing", 1242 . 1246 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1247 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1248 September 1999, . 1250 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1251 Packet Loss Metric for IPPM", RFC 2680, 1252 DOI 10.17487/RFC2680, September 1999, 1253 . 1255 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1256 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1257 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1258 . 1260 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1261 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1262 DOI 10.17487/RFC3393, November 2002, 1263 . 1265 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1266 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1267 2006, . 1269 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1270 Element (PCE)-Based Architecture", RFC 4655, 1271 DOI 10.17487/RFC4655, August 2006, 1272 . 1274 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1275 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1276 DOI 10.17487/RFC4664, September 2006, 1277 . 1279 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1280 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1281 DOI 10.17487/RFC5440, March 2009, 1282 . 1284 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1285 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1286 Acronym in the IETF", BCP 161, RFC 6291, 1287 DOI 10.17487/RFC6291, June 2011, 1288 . 1290 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1291 Weingarten, "An Overview of Operations, Administration, 1292 and Maintenance (OAM) Tools", RFC 7276, 1293 DOI 10.17487/RFC7276, June 2014, 1294 . 1296 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1297 Connectivity Provisioning Profile (CPP)", RFC 7297, 1298 DOI 10.17487/RFC7297, July 2014, 1299 . 1301 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1302 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1303 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1304 2015, . 1306 [SFCWG] "\Service Function Chaining (sfc)", 1307 . 1309 [SLA-Exchange] 1310 "Inter-domain SLA Exchange Attribute", 1311 . 1314 [TE-Yang] "YANG Data Model for TE Topologies", 1315 . 1318 [TEAS-ACTN] 1319 "Information Model for Abstraction and Control of TE 1320 Networks (ACTN)", . 1323 Authors' Addresses 1325 Li Qiang (editor) 1326 Huawei 1328 Email: qiangli3@huawei.com 1330 Pedro Martinez-Julia 1331 NICT 1333 Email: pedro@nict.go.jp 1335 Liang Geng 1336 China Mobile 1338 Email: gengliang@chinamobile.com 1340 Jie Dong 1341 Huawei 1343 Email: jie.dong@huawei.com 1345 Kiran Makhijani 1346 Huawei 1348 Email: Kiran.Makhijani@huawei.com 1350 Alex Galis 1351 University College London 1353 Email: a.galis@ucl.ac.uk 1355 Susan Hares 1356 Hickory Hill Consulting 1358 Email: shares@ndzh.com 1360 Slawomir 1361 Orange 1363 Email: slawomir.kuklinski@orange.com