idnits 2.17.1 draft-galis-netslices-revised-problem-statement-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 448: '...: Network slices MUST support multi-te...' RFC 2119 keyword, line 453: '... A network slice SHOULD provide a guar...' RFC 2119 keyword, line 456: '... * Slices MUST be isolated at ser...' RFC 2119 keyword, line 459: '... * Slices MUST be isolated at dat...' RFC 2119 keyword, line 462: '... A network slice SHOULD be provided wi...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 888 has weird spacing: '...managed by di...' -- The document date (July 3, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1958' is mentioned on line 1152, but not defined == Missing Reference: 'RFC3439' is mentioned on line 1155, but not defined == Missing Reference: 'RFC3234' is mentioned on line 1159, but not defined == Missing Reference: 'RFC7665' is mentioned on line 1102, but not defined == Missing Reference: 'SFC WG' is mentioned on line 126, but not defined == Missing Reference: 'RFC7149' is mentioned on line 1162, but not defined == Missing Reference: 'I-D.geng-netslices-architecture' is mentioned on line 167, but not defined == Missing Reference: 'I-D.leeking-actn-problem-statement 03' is mentioned on line 1106, but not defined == Missing Reference: 'I-D.teas-actn-requirements-04' is mentioned on line 1111, but not defined == Missing Reference: 'IETF-Slicing1' is mentioned on line 1116, but not defined == Missing Reference: 'IETF-Slicing2' is mentioned on line 1122, but not defined == Missing Reference: 'IETF-Slicing3' is mentioned on line 1127, but not defined == Missing Reference: 'IETF-Slicing4' is mentioned on line 1132, but not defined == Missing Reference: 'IETF-Slicing5' is mentioned on line 1138, but not defined == Missing Reference: 'IETF-Mobility' is mentioned on line 1174, but not defined == Missing Reference: 'IETF-Coding' is mentioned on line 1184, but not defined == Missing Reference: 'IETF-Anchoring' is mentioned on line 1189, but not defined == Missing Reference: 'RFC2119' is mentioned on line 1143, but not defined == Missing Reference: 'RFC4364' is mentioned on line 1148, but not defined == Missing Reference: 'CPP' is mentioned on line 1170, but not defined == Missing Reference: 'RFC6291' is mentioned on line 1194, but not defined == Missing Reference: 'I-D.dong-network-slicing-problem-statement' is mentioned on line 1092, but not defined == Missing Reference: 'I-D.galis-anima-autonomic-slice-networking' is mentioned on line 1097, but not defined == Missing Reference: 'SFG WG' is mentioned on line 1167, but not defined == Missing Reference: 'IETF-Virtualization' is mentioned on line 1179, but not defined == Unused Reference: 'GAL' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'GAPS' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'NS ARCH' is defined on line 1285, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 30 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Working Group A. Galis (editor) 3 Internet-Draft University College London 4 Intended Status: Informational et al. 5 Expires: January 3, 2018 July 3, 2017 7 Network Slicing - Revised Problem Statement 8 draft-galis-netslices-revised-problem-statement-01 10 Abstract 12 This document introduces Network Slicing problems and the motivation 13 for new work areas. It represents an initial revision of the Network 14 Slicing problem statement derived from the analysis of the technical 15 gaps in IETF protocols ecosystem. It complements and brings together 16 the efforts being carried out in several other IETF working groups to 17 achieve certain aspects of Network Slicing functions and operations. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 2, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Network Slicing Value Characteristics . . . . . . . . . . . 4 55 1.2 Network Slicing Work Scope . . . . . . . . . . . . . . . . . 5 56 1.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2. Network Slicing - Selected Problems and Work Areas . . . . . . 7 58 2.1 Global Issues - Problems (GP) . . . . . . . . . . . . . . . 7 59 2.1.1 Problem GI1: Uniform Reference Model (***) . . . . . . . 7 60 2.1.2 Problem GI2: Requirements for operations and 61 interactions (**) . . . . . . . . . . . . . . . . . . . 8 62 2.1.3 Problem GI3: Slice Templates (***) . . . . . . . . . . . 9 63 2.2 Network Slice Capabilities - Problems (NSC) . . . . . . . . 10 64 2.2.1 Problem NSC1: Guarantees for isolation (***) . . . . . 10 65 2.2.2 Problem NSC2: Fulfilling diverse requirements (*) . . . 10 66 2.2.3 Problem NSC3: Efficiency in slicing (*) . . . . . . . . 11 67 2.2.4 Problem NSC4: Slice Recursion (**) . . . . . . . . . . . 11 68 2.2.5 Problem NSC5: Customized security mechanisms per slice 69 (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 2.2.6 Problem NSC6: flexibility and efficiency trade-offs 71 (*) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 2.2.7 Problem NSC7: Optimisation (**) . . . . . . . . . . . . 12 73 2.2.8 Problem NSC8: Monitoring and Discovery (**) . . . . . . 13 74 2.2.9 Problem NSC9: Capability exposure and APIs (***) . . . . 13 75 2.2.10 Problem NSC10: Programmability of Operations of 76 Network Slices (**) . . . . . . . . . . . . . . . . . . 14 77 2.3 Network Slice Operations - Problems (NSO) . . . . . . . . . 15 78 2.3.1 Problem NSO1: Slice life cycle management (***) . . . . 15 79 2.3.2 Problem NSO2: Autonomic slice management and operation 80 (**) . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 2.3.3 Problem NSO3 - Slice stitching / composition (***) . . . 16 82 2.3.4 Problem NSO4: E2E Network Orchestration (***) . . . . . 17 83 2.3.5 Problem NSO5: Service Mapping in a single domain and 84 Cross-Domain Coordination (***) . . . . . . . . . . . . 18 85 2.3.6 Problem NSO6: Roles in Network Slicing (*) . . . . . . . 18 86 2.3.7 Problem NSO7: Efficient enablers and methods for 87 integration (*) . . . . . . . . . . . . . . . . . . . . 19 88 2.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 3. OAM Operation with Customized Granularity . . . . . . . . . . . 21 90 4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 92 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 93 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 94 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 7.1 IETF References . . . . . . . . . . . . . . . . . . . . . . 23 96 7.2 Informative References . . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 100 1 Introduction 102 Network slicing (NS) is an approach of flexible isolation and 103 allocation of network resources and network functions for a network 104 instance, providing high level of customization and quality service 105 guarantee. It transform the networking perspective by abstracting, 106 isolating, orchestrating, softwarizing, and separating logical 107 network components from the underlying physical network supporting 108 the introduction of new network architectures ([RFC1958], [RFC3439], 109 [RFC3234]) and new service delivery [5G-ICN]. In general, a 110 particular network slice consists of a union of subsets of 111 (connectivity, storage, computing) resources & (Virtual) Network 112 Functions & Service functions [RFC7665] at the data & control & 113 management planes at a given time that are managed together to 114 provide a logical networking infrastructure in support of a variety 115 of services. 117 Network slicing enables at a given time the dynamic creation of 118 multiple, parallel sub-networks of different features by flexible 119 isolation of allocated to a slice network resources and network 120 functions and providing high level of customization and quality 121 guarantee. 123 The management plane allocates the grouping of network resources 124 (whereby network resources can be physical, virtual or a combination 125 thereof), it connects with the physical and virtual network and 126 service functions ([SFC WG]) as appropriate, and it instantiates all 127 of the network and service functions assigned to the slice. On the 128 other hand, for slice operations, the slice control plane 129 functionality that may be operated by slice tenant, takes over the 130 control and governing of all the network resources, network 131 functions, and service functions assigned to the slice. It (re-) 132 configures them as appropriate and as per elasticity needs, in order 133 to provide an end-to-end service. In particular, slice ingress 134 routers are configured so that appropriate traffic is bound to the 135 relevant slice. 137 Allocation of traffic flows to slices as may be based on simple rules 138 (relying on a subset of the transport coordinate, DSCP/traffic class, 139 or flow label), or may be a more sophisticated one (to be further 140 defined) such as enabling new slice specific constructs in the data 141 plane. Also, the flows to slice allocation rules that are specified 142 for a slice can be changed dynamically, based on some events (e.g. 143 triggered by a service request). The slice control plane is 144 responsible for instructing the involved elements to honor such 145 needs. 147 Network operators can use NS to enable different services to receive 148 different treatment and to allow the allocation and release of 149 network resources according to the context and contention policy of 150 the operators. Such an approach using NS would allow significant 151 reduction of the operations expenditure. In addition, there is a 152 enabling link between NS and softwarization. On one hand NS makes 153 possible softwarization, programmability ([RFC7149]), and the 154 innovation necessary to enrich the offered services. On the other 155 hand Network softwarization techniques [IMT2020-2015], [IMT2020-2016] 156 may be used to realise and manage [MANO-2014] network slicing. NS 157 provides the means for the network operators to provide network 158 programmable capabilities to both service providers and other market 159 players without changing their physical infrastructure. NS enables 160 the concurrent deployment of multiple logical, self-contained and 161 independent, shared or partitioned networks on a common 162 infrastructure. Slices may support dynamic multiple services, multi- 163 tenancy, and the integration means for vertical market players (e.g. 164 automotive industry, energy industry, healthcare industry, media and 165 entertainment industry, etc.) 167 Please refer to [I-D.geng-netslices-architecture] for related 168 terminologies and definitions. 170 1.1 Network Slicing Value Characteristics 172 As a differentiation from non-partition networks and those with 173 simple partitions of connectivity resources (e.g. VPNs)/ Virtual 174 Networks/Other abstractions of the data traffic layer, the following 175 key value-added characteristics of Network Slicing and corresponding 176 usage are identified: 178 * Network Slice is a dedicated network that is build on an 179 infrastructure mainly composed of, but not limited to, 180 connectivity, storage and computing. 181 * Each network slice has the ability to dynamically expose and 182 possibly negotiate the parameters that characterize an NS. 183 * Each network slice will have its own operator that sees it as a 184 complete network infrastructure (i.e. router instances, 185 programmability, using any appropriate communication protocol, 186 caches, provide dynamic placement of virtual network functions 187 according to traffic patterns, to use its own controller, 188 finally it can manage its network as its own). 189 * Network slicing support tenants that are strongly independent on 190 infrastructure. 191 * A Network Slicing aware infrastructure allows operators to use 192 part of the network resources to meet stringent resource 193 requirements 194 * Network slicing introduces an additional layer of abstraction by 195 the creation of logically or physically isolated groups of 196 network resources and network function/virtual network functions 197 configurations separating its behavior from the underlying 198 physical network. 199 * Network slicing covers the full life cycle of slices that are 200 managed groups of infrastructure resources, network functions 201 and services (e.g. the network slice components are: service 202 instance, a network functions instance, resources, slice manager 203 and capability exposure). 204 * Network slices are dynamically and non-disruptively 205 reprovisioned 206 * Network slices will need to be self-managed by automated, 207 autonomic and autonomous, systems in order to cope with dynamic 208 requirements, such as scalability or extensibility of an 209 infrastructure (organically growing/shrinking of resources to 210 meet the size of their organizations) 211 * Network slices are configurable and programmable and they have 212 the ability to expose their capabilities and characteristics. 213 The slice protocols and functions are selected according to 214 slice required features. The behaviour of the network slice 215 realized via network slice instance(s). 216 * Network slices are concurrently deployed as multiple logical, 217 self-contained and independent, partitioned network functions 218 and resources on a common physical infrastructure. 219 * Network slicing supports dynamic multi-services, multi-tenancy 220 and the means for backing vertical market players. 221 * Network slicing simplifies the provisioning of services 222 manageability of networks and integration and operational 223 challenges especially for supporting. communication services. 224 * Network slicing offers native service customization enabled by 225 the selection and configuration of network functions for 226 coordinating/orchestration and control of network resource. 227 * Network slicing considerably transforms the networking 228 perspective by abstracting, isolating, orchestrating and 229 separating logical network behaviors from the underlying 230 physical network resources 232 1.2 Network Slicing Work Scope 234 The purpose of the NS work in IETF is to develop a set of protocols 235 and/or protocol extensions that enable efficient slice creation, 236 activation / deactivation, composition, elasticity, 237 coordination/orchestration, management, isolation, guaranteed SLA, 238 and safe and secure operations within a connectivity network or 239 network cloud / data centre environment that assumes an IP and/or 240 MPLS-based underlay. 242 While there are isolated efforts being carried out in several IETF 243 working groups Network WG [I-D.leeking-actn-problem-statement 03], 244 TEAS WG [I-D.teas-actn-requirements-04], [I-D.dong-network-slicing- 245 problem-statement], ANIMA WG [I-D.galis-anima-autonomic-slice- 246 networking], [IETF-Slicing1], [IETF-Slicing2], [IETF-Slicing3], 247 [IETF-Slicing4], [IETF-Slicing5], [IETF-Mobility], [IETF- 248 Virtualization], [IETF-Coding], [IETF-Anchoring] to achieve certain 249 aspects of network slice functions and operations, there is a clear 250 need to look at the complete life-cycle management characteristics of 251 Network Slicing solutions though the discussions based on the 252 following architectural tenets: 254 * Underlay tenet: support for an IP/MPLS-based underlay data 255 plane. 256 * Governance tenet: a logically centralized authority for network 257 slices in a domain. 258 * Separation tenet: slices may be virtually or physically 259 independent of each other and have an appropriate degree of 260 isolation (note 1) from each other. 261 * Capability exposure tenet: each slice allows third parties to 262 access via dedicated interfaces and /or APIs and /or programming 263 methods information regarding services provided by the slice 264 (e.g., connectivity information, mobility, autonomicity, etc.) 265 within the limits set by the operator or the slice owner. 267 NS approaches that do not adhere to these tenets are explicitly 268 outside of the scope of the proposed work at IETF. 270 In pursuit of the solutions described above, there is a need to 271 document an architecture for network slicing within both wide area 272 network and edge/central data center environments. 274 Elicitation of requirements (examples are [RFC2119], [RFC4364]) for 275 both Network Slice control and management planes will be needed, 276 Facilitating the selection, extension, and/or development of the 277 protocols for each of the functional interfaces identified to support 278 the architecture. 280 Additionally, documentation on the common use-cases for slice 281 validation for 5G is needed, such as mission-critical ultra-low 282 latency communication services; massive-connectivity machine 283 communication services (e.g. smart metering, smart grid and sensor 284 networks); extreme QoS; independent operations and management; 285 independent cost and/or energy optimisation; independent multi- 286 topology routing; multi-tenant operations; new network architecture 287 enablement, etc. 289 The proposed NS work would be coordinated with other IETF WGs (e.g. 290 TEAS WG, DETNET WG, ANIMA WG, SFC WG, NETCONF WG, SUPA WG, NVO3 WG, 291 DMM WG, Routing Area WG (RTGWG), Network Management Research Group 292 (NMRG) and NFV Research Group (NFVRG)) to ensure that the 293 commonalities and differences in solutions are properly considered. 294 Where suitable protocols, models or methods exist, they will be 295 preferred over creating new ones. 297 1.3 Notes 299 (1) This issue requires efficient interaction between an upper 300 layer in the hierarchy and a lower layer for QoS guarantees 301 and for most of the operations on slicing. 303 2. Network Slicing - Selected Problems and Work Areas 305 The goal of this proposed work is to develop one or more protocol 306 specifications (or extensions to existing protocols) to address 307 specific slicing problems that are not met by the existing tools. The 308 following problems were selected according to the analysis of the 309 technical gaps in IETF protocols ecosystem. Each problem is 310 associated with one identified IETF gap (draft-qiang-netslices-gap- 311 analysis-01). In addition an initial priority level is attached to 312 each problem. [(***) high priority, (**) medium priority and (*) low 313 priority]. The proposed WG charter would include at least the high 314 priority problems. 316 2.1 Global Issues - Problems (GP) 318 2.1.1 Problem GI1: Uniform Reference Model (***) 320 Related Identified IETF Gap: "A detailed specification of Network 321 Slicing Specification". 323 Uniform Reference Model for Network Slicing (Architecture document): 325 * Description of all of the functional elements required for 326 network slicing. 327 * Description of shared non-sliced network parts. Establishes the 328 boundaries to the basic network slice operations (creation, 329 management, exposure, consumption). 330 * Describes the minimum functional roles derived from basic 331 network slice operations including infrastructure owner 332 (creation, exposure, management), slice operator (exposure, 333 management, consumption), slice customer (management, 334 consumption). Describe the interactions between infrastructure 335 owner <-> slice operator, slice operator <-> slice operator, 336 slice operator <-> slice customer. 338 * Additionally, this working area will normalize nomenclature and 339 definitions for Network Slicing. 341 Short explanation: A uniform definition and architecture of Network 342 slicing is presented in the NS Architecture draft. A Network slice is 343 a managed group of subsets of resources, network functions/network 344 virtual functions at the data, control, management/orchestration 345 planes and services at a given time. Network slice is programmable 346 and has the ability to expose its capabilities. The behaviour of the 347 network slice realized via network slice instance(s). 349 (1) The Service Instance Component represents the end-user service 350 or business services. An instance of an end-user service or a 351 business service that is realized within or by a NS. Would be 352 provided by the network operator or by 3rd parties. 353 (2) A Network Slice Instance component 354 a. Represented by a set of network functions, virtual network 355 functions and resources at a given time 356 b. Forms a complete instantiated logical network to meet 357 certain network characteristics required by the Service 358 Instance(s). 359 c. Provides network characteristics which are required by a 360 Service Instance. 361 d. May also be shared across multiple Service Instances 362 (3) Resources component - it includes: Physical, Logical & Virtual 363 resources 364 a. Physical & Logical resources - An independently manageable 365 partition of a physical resource, which inherits the same 366 characteristics as the physical resource and whose 367 capability is bound to the capability of the physical 368 resource. It is dedicated to a Network Function or shared 369 between a set of Network Functions. 370 b. Virtual resources - An abstraction of a physical or logical 371 resource, which may have different characteristics from 372 that resource, and whose capability may not be bound to the 373 capability of that resource. 374 (4) Slice Element Manager (SEM) and Capability exposure component 375 a. Slice Element Manager (SEM) is instantiated in each Network 376 Slice and it manages all access permissions and all 377 interaction between a Network Slice and external functions 378 (i.e. other Network Slices, Orchestrators, etc). Each SEM 379 converts requirements from orchestrator into virtual 380 resources and manages 381 Consolidation and versification of the above definition is required. 382 New protocols are needed for the creation, for discovery and for 383 orchestrating network slicing. 385 2.1.2 Problem GI2: Requirements for operations and interactions (**) 386 Related Identified IETF Gap: "A detailed specification of Network 387 Slicing Specification". 389 Review common scenarios from the requirements for operations and 390 interactions point of view. Describes the roles (owner, operator, 391 user) which are played by entities with single /multiple entities 392 playing different roles. 394 Short explanation: Review of the functional and non- functional NS 395 requirements is needed to ensure that resource utilization is 396 maximized and infrastructure costs are minimized as services will 397 need to operate over a union of shared network infrastructures, as 398 against the traditional monolithic model operated either as dedicated 399 network or as an overlay. 401 2.1.3 Problem GI3: Slice Templates (***) 403 Related Identified IETF Gap: "A detailed specification of Network 404 Slicing Specification". 406 Design the slices to different scenarios [ChinaCom-2009], [GENI- 407 2009], [IMT2020-2016bis], [NGMN-2016], [NGS-3GPP-2016], [ONF-2016]); 408 Outlines an appropriate slice template definition that may include 409 capability exposure of managed partitions of network resources (i.e. 410 connectivity ([CPP]), compute and storage resources), physical and/or 411 virtual network and service functions that can act as an independent 412 connectivity network and/or as a network cloud. 414 Short explanation: A network slice template based on uniform 415 reference model would enable the creation of a network slice 416 instance. A template defines an abstraction of the overall network 417 resources and functions requirement for a particular network slice 418 instance. Different templates can also be regarded as definitions of 419 individual network slice types. Besides the reference model for 420 network resources and functions, each template has a complete 421 description of the structure, configuration and the plans/work flows 422 for how a certain type of network slice instance should be 423 instantiated and managed during its life cycle. 425 There should be a clear definition of the level of abstraction of the 426 network slice template according to the arrangement and specification 427 of network slice life cycle management system. A valid network slice 428 instance profile created based on specific network slice template is 429 going to be decomposed into configuration profiles to certain OAM 430 domains for the purpose of network slice instance creation. 432 The creation of a specific network slice template strictly relies on 433 the exposed network capabilities. The network slice life cycle 434 management system should not allow a template with parameters 435 exceeding the capabilities to be created. 437 2.2 Network Slice Capabilities - Problems (NSC) 439 2.2.1 Problem NSC1: Guarantees for isolation (***) 441 Related Identified IETF Gap: "Slicing specific extension on 442 Isolation". 444 Four-dimensional efficient slice creation with guarantees for 445 isolation in each of the Data /Control /Management /Service planes. 446 Enablers for safe, secure and efficient multi-tenancy in slices. 448 Short explanation: Network slices MUST support multi-tenancy, 449 ensuring that isolation and performance guarantees are provided at 450 the data, control, management and service planes. This involves the 451 following: 453 * A network slice SHOULD provide a guaranteed level of service, 454 according to a negotiated SLA between the customer and the slice 455 provider 456 * Slices MUST be isolated at service level (e.g., one slice must 457 not impact on the level of service of the other slides, even if 458 sharing resources). 459 * Slices MUST be isolated at data level, even if sharing 460 resources. Security and privacy mechanisms should be in place to 461 ensure this. 462 * A network slice SHOULD be provided with exclusive control and/or 463 management interfaces (depending on the type of network slice), 464 enabling the deployment of different logical network slices over 465 shared resources. 467 2.2.2 Problem NSC2: Fulfilling diverse requirements (*) 469 Related Identified IETF Gap: "A detailed specification of Network 470 Slicing Specification". 472 Methods to enable diverse requirements for NS including guarantee for 473 the end-to-end QoS of service in a slice. 475 Short explanation: The main goal of fulfilling NS requirements is to 476 ensure that service operators can utilize or benefit from Network 477 Slicing through multi-tenancy, enabling different customized 478 infrastructures for different group of services across different 479 network segments and operating them independently. It includes the 480 tasks that go into determining the needs or conditions to meet for NS 481 systems, taking account of the possibly conflicting requirements of 482 the various stakeholders and a prioritisation of requirements. New 483 protocols are needed for interoperability between diverse type of 484 network slices which are fulfilling diverse requirements 486 2.2.3 Problem NSC3: Efficiency in slicing (*) 488 Related Identified IETF Gap: "A detailed specification of Network 489 Slicing Specification". 491 Specifying policies and methods to realize diverse requirements 492 without re-engineering the infrastructure. 494 Short explanation: This item is deployment-specific and cannot be 495 promised as a problem to be solved entirely by protocols. An 496 underlying infrastructure will always be needed to be reengineered 497 and maintained to support up-to-date technologies and emerging 498 requirements (including instantiating new service functions or 499 withdrawing service functions, adding new nodes to absorb for 500 traffic, ...). It is a local decision to figure out whether many 501 services will be bound to the same slice, how many slices are to be 502 instantiated and so on. Exposing standard interfaces to capture 503 requirements will help to rationale the use of resources and how the 504 requirements are fulfilled, however it is a challenge to guarantee in 505 an absolute manner that slicing allows "diverse requirements without 506 re-engineering the infrastructure". 508 2.2.4 Problem NSC4: Slice Recursion (**) 510 Related Identified IETF Gap: "A detailed specification of Network 511 Slicing Specification". 513 Short explanation: Recursion is a property of some functional blocks: 514 a larger functional block can be created by aggregating a number of a 515 smaller functional block and interconnecting them with a specific 516 topology. As such recursive network slice definition is defined as 517 the ability to build a new network slice out of existing network 518 slice (s). A certain resource or network function /virtual network 519 function could scale recursively, meaning that a certain pattern 520 could replace part of itself. This leads to a more elastic network 521 slice definition, where a network slice template, describing the 522 functionality, can be filled by a specific pattern or implementation, 523 depending on the required performance, required QoS or available 524 infrastructure. 526 New protocols are needed for use of network slice template 527 segmentation allowing a slicing hierarchy with parent - child 528 relationships. 530 2.2.5 Problem NSC5: Customized security mechanisms per slice (*) 532 Related Identified IETF Gap: "Mechanisms for customized granularity 533 OAM (Operations, Administration, and Maintenance)". 535 Short explanation: Customized securing mechanisms will be needed on a 536 per slice basis. This may be provided by enabling dedicated service 537 functions. For such cases, SFC techniques can be used here. 538 Soliciting distinct SFs per slice can be provided with existing 539 tools. I don't see a new problem out there. 541 This may be provided by configuring dedicated policies in a given 542 security service function. In such case, I2NSF techniques can be used 543 to interact with a given service function. 545 Traffic isolation may be needed for some services. Legacy tools can 546 be used. I'm not sure if there is specific work specific to slicing 547 other than making sure that appropriate flows are grafted to the 548 appropriate slice and no data leaking between slices is to happen. 550 2.2.6 Problem NSC6: flexibility and efficiency trade-offs (*) 552 Related Identified IETF Gap: "A detailed specification of Network 553 Slicing Specification". 555 Methods and policies to manage the trade-offs between flexibility and 556 efficiency in slicing. 558 Short explanation: Mechanisms SHOULD be in place to allow different 559 levels of flexibility when providing network slices: from the ones 560 that provided greater levels of flexibility in the provided resources 561 and services that compound the slice, allowing to dynamically 562 change/scale/migrate it over time within a negotiated range, to the 563 ones that ensure the efficiency of the use of the resources at the 564 cost of a smaller degree of flexibility. 566 2.2.7 Problem NSC7: Optimisation (**) 568 Related Identified IETF Gap: "non-overlay OAM solution". 570 Methods for network resources automatic selection for NS; global 571 resource view formed; global energy view formed; Network Slice 572 deployed based on global resource and energy efficiency; Mapping 573 protocols. 575 Short explanation: NS optimization includes methods which enable that 576 resources utilization is monitored and maximize, that infrastructure 577 operational costs are minimized and that QoS are managed and 578 maximized at the time of creation of network slice instance and well 579 as during NS operation. 581 2.2.8 Problem NSC8: Monitoring and Discovery (**) 583 Related Identified IETF Gap: "Mechanisms for dynamic discovery of 584 service with function instances and their capabilities". 586 Monitoring status and behaviour of NS in a single and/or muti-domain 587 environment; NS interconnection. 589 Short explanation: A Network slice is a managed group of subsets of 590 resources, network functions / network virtual functions at the data, 591 control, management/orchestration planes and services at a given 592 time. Monitoring of slices interacts with and it is part of the NS 593 Lifecycle management to aiming at reporting the performance of the 594 running NS. As input, the Monitoring Subsystem receives the detailed 595 service monitoring requests with references to resource allocation 596 and Network functions instances in a NS. The Monitoring Subsystem is 597 responsible for the monitoring continuously the state all 4 598 components of a NS (Service Instance component, Network Slice 599 Instance component, Resources component). New protocols are needed 600 for discovery and monitoring probes of all NS components and NS 601 itself itself and for dynamic discovery of service with function 602 instances and their capability. 604 2.2.9 Problem NSC9: Capability exposure and APIs (***) 606 Related Identified IETF Gap: "A detailed specification of Network 607 Slicing Specification". 609 Capability exposure for NS; plus APIs for slices 611 Short explanation: To exploit the flexibility offered by network 612 slices their users (customers, overlying operators) would need to 613 know the features offered by both individual resources and complete 614 slices. This means that there must be interfaces to deliver such 615 information to the entity that needs it, but that will be also 616 transitively delivered to the following chains of the slicing 617 structure towards the final users. 619 To this sense, there are two specific interfaces that must be defined 620 to address such function: 621 * The bottom-up interface, offered by underlying resource 622 providers to resource consumers (operators) of any layer. 623 * The top-down interface, offered by overlying operators to lower 624 level providers. 626 On the one hand, the first interface will, obviously, enable slice 627 operators to access the slices owned by underlying providers and 628 manage the resources they have been assigned in them. On the other 629 hand, the second interface will enable lower layers to know details 630 about the resources managed by overlying operators and the 631 requirements they impose to the overlying network slices. 633 In this respect, both interfaces will emphasize the relation among 634 the original resources, as well as the links from them to the 635 resulting resources. This forms the main key of their management 636 operations. 638 2.2.10 Problem NSC10: Programmability of Operations of Network Slices 639 (**) 641 Related Identified IETF Gap: "Mechanisms for customized granularity 642 OAM (Operations, Administration, and Maintenance)". 644 Short explanation: Network slice operations consist of all operations 645 related to life cycle management of a slice and its optimized 646 operation. Slice instance lifecycle management includes all 647 operations related to slice instance creation, activation, update and 648 deactivation. All these operations are automated and driven by 649 appropriate policies. A slice instance is created according to a 650 slice template and related policies. A unique identifier is assigned 651 to each slice after its creation and a list of active slice instances 652 are stored in slice repository. Several slice types are predefined 653 which describe their functions as access, core, transport, data 654 center and edge cloud slices. As example to each slice instance a 655 Slice Priority parameter is assigned which describe the way of 656 handling of slice degradation in case of lack of resources that can 657 be allocated to slices. The parameter is also used in emergency 658 situations in which there is a need to release resources from 659 existing slices and to allocate them to newly created slices that are 660 used for emergency situation handling. 662 The end-to-end slice can be a composition of per administrative or 663 technological domain slices that are created according to their local 664 templates. The process of slice creation can be recursive. The slice 665 level are split between slice operator and slice tenant. The slice 666 tenant obtains information about slices related KPIs and is 667 expressing his reconfiguration wills as intents (high level 668 policies), which are implemented in an automated manner by slice 669 control and management planes. The slice operator is responsible for 670 slice lifecycle and slice FCAPS handling. During operations of slice 671 the slice resources are allocated in a dynamic way in order to 672 provide required performance but in an economical way. 674 Each network slice exhibits following features: protection (note 2), 675 elasticity (note 3), extensibility (note 4) and safety (note 5). 677 2.3 Network Slice Operations - Problems (NSO) 679 2.3.1 Problem NSO1: Slice life cycle management (***) 681 Related Identified IETF Gap: "non-overlay OAM solution". 683 Slice life cycle management including creation, activation / 684 deactivation, protection (note 2), elasticity (note 3), extensibility 685 (note 4), safety (note 5), sizing and scalability of the slicing 686 model per network and per network cloud: slices in access, core and 687 transport networks; slices in data centres, slices in edge clouds. 689 Short explanation: Network slicing enables the operator to create 690 logically partitioned networks at a given time customized to provide 691 optimized services for different market scenarios. These scenarios 692 demand diverse requirements in terms of service characteristics, 693 required customized network and virtual network functionality (at the 694 data, control, management planes), required network resources, 695 performance, isolation, elasticity and QoS issues. A network slice is 696 created only with the necessary network functions and network 697 resources at a given time. They are gathered from a complete set of 698 resources and network /virtual network functions and orchestrated for 699 the particular services and purposes. 701 New protocols are needed for realising full Slice life cycle 702 management at two distinct levels: 703 (1) "network slice life-cycle management level" (i.e. the series of 704 state of functional activities through which a network slice 705 passes: creation, operation, deletion) and 706 (2) "network slice instances level" (activated network slice 707 level). 709 Functions for creating and managing network slice instances and the 710 functions instantiated in the network slice instance are mapped to 711 respective framework level. 713 2.3.2 Problem NSO2: Autonomic slice management and operation (**) 715 Related Identified IETF Gap: "non-overlay OAM solution". 717 It incudes self-configuration, self-composition, self-monitoring, 718 self-optimisation, self-elasticity are carried as part of the slice 719 protocols. 721 Short explanation: Network slice is a dynamic entity which lifecycle 722 and operations should be automated. There are 3 main reasons of this 723 automation: 724 (1) There is an expectation that the number of slice instances can 725 be huge what rises the problem of management scalability if it 726 is performed in a classical, manual way. 727 (2) Network slice instances can be created on demand by the end- 728 users or verticals. They may play a role of slice instance 729 administrator (making some reconfigurations or monitoring slice 730 performance. It is however not expected that such administrator 731 will have required experience and tools related to slice 732 instance management. They can express some high-level requests 733 that has to be translated into low level operations 734 (3) Multiple network slice instances have to share common resources 735 in economical way but with preserving required performance 736 indicators. The problem of allocation of resources between 737 slices combined with real-time optimization of slice operations 738 can be only solved by continuous monitoring of slice performance 739 and making continuous adaptations of resources allocated to 740 them. 742 The mentioned reasons call for autonomic management which part should 743 be autonomic management of each slice and autonomic management of 744 resources that are allocated to slices. The autonomic operations at 745 the slice instance level comprise of self-configuration, self- 746 composition, efficient self-monitoring, self-healing and real-time 747 optimization (self-optimisation) as a part of the autonomic 748 management framework. 750 2.3.3 Problem NSO3 - Slice stitching / composition (***) 752 Related Identified IETF Gap: "non-overlay OAM solution". 754 Having enablers and methods for efficient stitching /composition/ 755 decomposition of slices: 756 * vertically (service + management + control planes) and/or 757 * horizontally (between different domains part of access, core, 758 edge segments) and /or 759 * vertically + horizontally. 761 Short explanation: Slice stitching. The network slice has to provide 762 end-to-end communication and services. In some cases such end-to-end 763 network slice instance can be created directly but in multi-domain 764 environment the end-to slice will be a composition of slices of 765 different domains in the each network segments (i.e. access, core, 766 edge, transport, etc.). In such a case the domain slices will be 767 created and maintained using domain specific slice templates and use 768 domain specific operations and all the domain slicing will be 769 stitched together horizontally. The operation is supported by 770 appropriate descriptions of domain slices, exchange of slice related 771 policies between domains. Slice stitching operations are supported by 772 uniform slice descriptors and appropriate matching of them. Each 773 slices has appropriate set of mechanisms (slice border control 774 functions) that support horizontal stitching of slices. 776 The vertical stitching of slices is an operation that modifies 777 functionality of existing slice by adding and merging of functions of 778 another slice (i.e. enhancing control plane properties be functions 779 defined in another slice template). In general the vertical stitching 780 of slices is used to enrich slice services. 782 Slices will be recursively used as components in software 783 architectures. This means that several slices will be able to be used 784 together to build a "composite network service" that inherits the 785 capabilities of the original slices. The recursive property means 786 that both slices and derived composite services can be again "split" 787 into pieces to form new slices. The straight result of this aspect is 788 that complex services are highly simplified by "stitching" slices 789 and/or part of them, achieving the actual complexity by exploiting 790 layering, which is the de-facto standard composition capability 791 typically mapped into network architectures, but also by exploiting 792 the abstraction levels offered by network service composability. 794 However, to hide such complexity and thus achieve the intended 795 abstraction, the network architecture (and slicing reference model) 796 must include, adopt, and promote the deployment of the necessary 797 mechanisms and functions that support slice stitching and network 798 service composability. 800 2.3.4 Problem NSO4: E2E Network Orchestration (***) 802 Related Identified IETF Gap: "non-overlay OAM solution (Operations, 803 Administration, and Maintenance) solution". 805 End-to-end network segments orchestration of slices ([GUERZONI-2016], 806 [KARL-2016]). 808 Short explanation: Network service composition has demonstrated to be 809 highly beneficial for both operators and final users [GRAMMATIKOU- 810 2012]. It allows the formation of large number of different services, 811 which will be specialized to the particular needs of a user or a 812 specific situation. However, the current network architecture is far 813 for being ideal to implement such function. 815 One of the keys of network slicing is the flexibility it adds to the 816 network and the resulting "de-ossification" of network resources. 817 Thus, this environment is much more optimal to allow the 818 proliferation of network service composition, but it means that some 819 sort of specific requirements must be pushed towards the architecture 820 that supports the general slicing. 822 First, a proper composable network service model needs network 823 resources to be compatible, regardless of the domain to which they 824 pertain. Then they must be homogeneously described, so a user can 825 actually understand their individual capabilities and "draw" the 826 service they want to build by combining them. Finally, the resources 827 living among separated network slices must be "connectable" to each 828 other. This means that they must cross the domain of their 829 providers/owners in order to reach their destination. 831 New protocols are needed for full end to end orchestration between 832 the layers, from the IP layer and up. 834 2.3.5 Problem NSO5: Service Mapping in a single domain and Cross-Domain 835 Coordination (***) 837 Related Identified IETF Gap: "Companion YANG data model for network 838 slicing - single domain and Cross-Domain Coordination". 840 Having dynamic and Automatic Mapping of Services to slices; YANG 841 models for slices. 843 Short Description: The main goal of the service mapping framework is 844 to enable on-demand processing anywhere in the physically distributed 845 network, with dynamic and fine granular service (re-)provisioning, 846 which can hide significant part of the resource management complexity 847 from service providers and users, hence allowing them to focus on 848 service and application innovation. It include a slice-aware YANG 849 information model based on necessary connectivity, storage, compute 850 resources, network functions, capabilities exposed and service 851 elements in a single domain as well as Cross-Domain Coordination. As 852 such the service mapping participates in management of the network 853 slices. 855 2.3.6 Problem NSO6: Roles in Network Slicing (*) 857 Related Identified IETF Gap: "Detailed specification of Network 858 Slicing Specification". 860 Enablers and methods for the above mentioned capabilities and 861 operations from different viewpoints on slices (note 6). 863 Short explanation: Several viewpoints emerge from the global and 864 wide interaction among the Network Infrastructure Owner (NIO), 865 Network Slice Provider (NSP), and Network Slice Tenant(NST), and they 866 must be treated by network slicing to ensure their use cases are 867 correctly covered. They are: 869 - NIO <=> NSP: 870 + NIO offers the physical infrastructure to NSP, and NSP 871 creates and manages the "slice" of network resources. 872 + NSP interacts vertically to request and instantiate (embed) 873 composite network services onto the underlying physical 874 infrastructures. 875 + NSP can possibly act as NIO. 877 - NSP <=> NST: 878 + NSP offers the individual objects/resources obtained after 879 slicing the physical infrastructure to the NST. 880 + NST requests to the NSP the necessary CRUD (Create, 881 Retrieve, Update, Delete) operations on its own Network 882 Slices. 884 - NSP <=> NSP: 885 + Allows inter-provider tasks (e.g. migration of resources or 886 whole slices among providers. 887 + Organizes the interoperability levels among Network Slices 888 managed by different providers. 889 + Facilitates the recursive slicing, so a new NSP slices the 890 resources offered by other NSP. 892 - NIO <=> NIO: 893 + Horizontal communication between owners to coordinate the 894 required interactions among physical infrastructure 895 resources, and/or the migration of whole slices among 896 different NIOs. 897 + It may be common for NIO to provide network infrastructures 898 to NSP in an old-fashion way where no network slicing is 899 concerned. 901 However, a NIO may become a double role of NIO+NSP once it provides 902 NSaaS. 904 Any NSP can become a NST if it uses specific network slice instance 905 for a particular service, or it purchase NSaaS from another NSP. 907 2.3.7 Problem NSO7: Efficient enablers and methods for integration (*) 909 Related Identified IETF Gap: "non-overlay OAM solution". 911 Efficient enablers and methods for integration of above capabilities 912 and operations. 914 Short explanation: In order to enable the above required capabilities 915 and operation for network slicing, well defined reference points 916 among the involved actors and entities are required, as well as the 917 proper interface definitions ensuring interoperability of all 918 involved pieces. Some examples of the required reference 919 points/interfaces include: 921 Customer/Vertical (user of the slice) - Network Slice Provider. The 922 user of the slice SHOULD be able to specify the characteristics of 923 the slide and provide it in a suitable/understandable format to the 924 NSP. A proper information model is needed to convey the customer 925 slice requirements. And the model might need to support different 926 levels of abstraction, to support different use cases. 928 Network Slice Provider - Network Slice Provider / Network Slice 929 Operator / Network Service Provider. The slice provider MUST be able 930 to request resources to compose a slice to other slice providers, 931 slice operator or service operators. The interface needs to support 932 recursiveness and different levels of abstraction (the request might 933 involve resources or services). 935 Inter-domain interactions at different levels. Another way of 936 composing a slice is by interaction of players at the same level 937 (peering, instead of recursive), by delegating the request to other 938 provides/operators. This type of interaction can take place at 939 different levels (resource, network service, etc), and therefore 940 would impose different requirements. In all cases, security issues 941 are key due to the inter-operator nature. 943 2.4 Notes 945 (1) Protection refers to the related mechanisms so that events 946 within one slice, such as congestion, do not have a negative 947 impact on another slice. 949 (2) Elasticity refers to the mechanisms and triggers for the 950 growth/shrinkage of network resources, and/or network and 951 service functions. 953 (3) Extensibility refers to the ability to expand a NS with 954 additional functionality and/or characteristics, or through 955 the modification of existing functionality/characteristics, 956 while minimizing impact to existing functions. 958 (4) Safety refers to the conditions of being protected against 959 different types and the consequences of failure, error harm or 960 any other event, which could be considered non-desirable. 962 (5) Multiple viewpoints on slices: I) viewpoint of the slice's 963 owner towards user: from this viewpoint a slice is defined as 964 a means to "split" physical or virtual infrastructure elements 965 to "service" smaller portions. This action would be 966 recursively done from the owner of the initial and physical 967 infrastructure element to the users. II) viewpoint of from the 968 user towards the physical infrastructure owner. From this 969 viewpoint a slice is viewed just as a set of resources that 970 must be managed (requests to a provider, listed, changed, 971 returned to the provider, etc.). This viewpoint emphasizes 972 those issues that would be used in the SLA definition of a 973 slice. 975 3. OAM Operation with Customized Granularity 977 In accordance with [RFC6291], OAM is used to denote the following: 979 * Operations: refer to activities that are undertaken to keep the 980 network and the services it deliver up and running. It includes 981 monitoring the underlying resources and identifying problems. 982 * Administration: refer to activities to keep track of resources 983 within the network and how they are used. 984 * Maintenance: refer to activities to facilitate repairs and 985 upgrades. Maintenance also involves corrective and preventive 986 measures to make the managed network run more effectively, e.g., 987 adjusting configuration and parameters. 989 As per [RFC6291], NetSlices provisioning operations are not 990 considered as part of OAM. Provisioning operations are discussed in 991 other sections. Maintaining automatically-provisioned slices within a 992 network raises the following requirements: 994 * Ability to run OAM activities on a provider's customized 995 granularity level. In other words, ability to run OAM activities 996 at any level of granularity that a service provider see fit. In 997 particular: 998 - An operator must be able to execute OAM tasks on a per slice 999 basis. 1000 - These tasks can cover the "whole" slice within a domain or 1001 portion of that slice (for troubleshooting purposes, for 1002 example). 1003 - For example, OAM tasks can consist in tracing resources that 1004 are bound to a given slice, tracing resources that are 1005 invoked when forwarding a given flow bound to a given 1006 network slice, assessing whether flow isolation 1007 characteristics are in conformance with the NS Resource 1008 Specification, or assessing the compliance of the allocated 1009 slice resource against flow/customer requirements. 1010 - An operator must be able to enable differentiated failure 1011 detect and repair features for a specific/subset of network. 1012 For example, a given slice may require fast detect and 1013 repair mechanisms (e.g., as a function of the nature of the 1014 traffic (pattern) forwarded through the NS), while others 1015 may not be engineered with such means. 1016 - When a given slice is shared among multiple 1017 services/customers, an operator must be able to execute 1018 (per-slice) OAM tasks for a particular service or customer. 1019 * Ability to automatically discover the underlying service 1020 functions and the slices they are involved in or they belong 1021 to. 1022 * Ability to dynamically discover the set of NetSlices that are 1023 enabled within a network. Such dynamic discovery capability 1024 facilitates the detection of any mismatch between the view 1025 maintained by the control plane and the actual network 1026 configuration. When mismatches are detected, corrective 1027 actions must be undertaken accordingly. 1029 4 Summary 1031 The following is a summary of the selected higher priority problems 1032 based on previous analysis in this document: 1034 (I) Identified IETF Gap: "A detailed specification of Network Slicing 1035 Specification"; Requirement: Network Slicing Specification. 1037 * Problem GI1: Uniform Reference Model 1038 * Problem GI3: Slice Templates 1039 * Problem NSC9: Capability exposure and APIs 1041 (II) Identified IETF Gap: "A companion YANG data model for Network 1042 Slicing"; Requirement: Network Slicing Specification. 1044 * Problem NSO5: Service Mapping in a single domain and Cross- 1045 Domain Coordination. 1047 (III) Identified IETF Gap: "Slicing specific extension on Isolation 1048 (Performance Guarantee and Isolation-PGI"; Requirement: Performance 1049 Guarantee and Isolation. 1051 * Problem NSC1: Guarantees for isolation. 1053 (IV) Identified IETF Gap: "Mechanisms for dynamic discovery of 1054 service with function instances and their capabilities"; Requirement: 1055 Network Slicing OAM. 1057 * Problem NSC8: Monitoring and Discovery 1059 (V) Identified IETF Gap: "non-overlay OAM (Operations, 1060 Administration, and Maintenance) solution"; Requirement: Network 1061 Slicing OAM. 1063 * Problem NSO1: Slice life cycle management 1064 * Problem NSO4: E2E Network Orchestration 1066 (VI) Identified IETF Gap: "Mechanisms for customized granularity OAM 1067 (Operations, Administration, and Maintenance)"; Requirement: Network 1068 Slicing OAM. 1070 * Problem NSO2: Autonomic slice management and operation 1071 * Problem NSO3: Slice stitching / composition 1073 5 Security Considerations 1075 Security will be a major part of the design of network slicing. 1077 6 IANA Considerations 1079 This document requests no IANA actions. 1081 7 Acknowledgements 1083 Thanks to Sheng Jiang (Huawei Technologies), Kevin Smith (Vodafone), 1084 Satoru Matsushima (SoftBank), Christian Jacquenet (Orange), Mohamed 1085 Boucadair (Orange) for reviewing this draft. Thanks to Stuart Clayman 1086 (UCL) for creating the nroff markup for this document. 1088 8 References 1090 7.1 IETF References 1092 [I-D.dong-network-slicing-problem-statement] Dong, J. and S. Bryant, 1093 "Problem Statement of Network Slicing in IP/MPLS 1094 Networks", draft-dong-network-slicing-problem-statement-00 1095 (work in progress), October 2016. 1097 [I-D.galis-anima-autonomic-slice-networking] Galis, A., Makhijani, 1098 K., and D. Yu, "Autonomic Slice Networking-Requirements 1099 and Reference Model", draft-galis-anima-autonomic-slice- 1100 networking-01 (work in progress), October 2016. 1102 [RFC7665] Halpern, J., Pignataro, C., "Service Function Chaining 1103 (SFC) Architecture", https://tools.ietf.org/html/rfc7665, 1104 October 2015. 1106 [I-D.leeking-actn-problem-statement 03] Ceccarelli, D., Lee, Y., 1107 "Framework for Abstraction and Control of Traffic 1108 Engineered Networks", draft-leeking-actn-problem- 1109 statement-03 (work in progress), September 2014. 1111 [I-D.teas-actn-requirements-04] Lee, Y., Dhody, D., Belotti, S., 1112 Pithewan, K., Ceccarelli, D., "Requirements for 1113 Abstraction and Control of TE Networks", draft-ietf-teas- 1114 actn-requirements-04.txt, January 2017. 1116 [IETF-Slicing1] "Presentations - Network Slicing meeting at IETF 97 1117 of 15th November 2016", n.d., 1118 . 1122 [IETF-Slicing2] "Presentations - Network Slicing meeting at IETF 97 1123 of 15th November 2016", n.d., 1124 . 1127 [IETF-Slicing3] "Presentations - Network Slicing meeting at IETF 97 1128 of 15th November 2016", n.d., 1129 . 1132 [IETF-Slicing4] "Presentations - Network Slicing meeting at IETF 97 1133 of 15th November 2016", n.d., 1134 . 1138 [IETF-Slicing5] "Presentations - Network Slicing meeting at IETF 97 1139 of 15th November 2016", n.d., 1140 . 1143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1144 Requirement Levels", BCP 14, RFC 2119, DOI 1145 10.17487/RFC2119, March 1997, . 1148 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1149 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1150 2006, . 1152 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1153 RFC 1958, . 1155 [RFC3439] Bush, R., Meyer, D., "Some Internet Architectural 1156 Guidelines and Philosophy", RFC3439, 1157 . 1159 [RFC3234] Carpenter, B., Brim S., "Middleboxes: Taxonomy and Issues", 1160 RFC3439, . 1162 [RFC7149] Boucadair, M., Jacquenet, C. , " Software-Defined 1163 Networking: A Perspective from within a Service Provider 1164 Environment", RFC 7149, March 2014 1165 . 1167 [SFG WG] "Service Function Chaining WG" 1168 . 1170 [CPP] Boucadair M., Jacquenet, C., Wang, N., "IP Connectivity 1171 Provisioning Profile (CPP)" 1172 https://tools.ietf.org/html/rfc7297 1174 [IETF-Mobility] Truong-Xuan Do, Young-Han Kim, "Architecture for 1175 delivering multicast mobility services using network 1176 slicing" 2016-10-31 1179 [IETF-Virtualization] Carlos Bernardos, Akbar Rahman, Juan Zuniga, 1180 Luis Contreras, Pedro Aranda, " Network Virtualization 1181 Research Challenges" 2016-10-31 1184 [IETF-Coding] M.A. Vazquez-Castro, Tan Do-Duy, Paresh Saxena, Magnus 1185 Vikstrom, "Network Coding Function Virtualization" 2016- 1186 11-14 1189 [IETF-Anchoring] Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil 1190 Jeon, Alexandre Petrescu, Fred Templin "Distributed 1191 Mobility Anchoring" 2016-12-15 1194 [RFC6291] L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. 1195 Mansfield "Guidelines for the Use of the "OAM" Acronym in 1196 the IETF" - June 2011 https://tools.ietf.org/html/rfc6291 1198 7.2 Informative References 1200 [ChinaCom-2009] "A. Galis et al - Management and Service-aware 1201 Networking Architectures (MANA) for Future Internet - 1202 Invited paper IEEE 2009 Fourth International Conference on 1203 Communications and Networking in China (ChinaCom09) 26-28 1204 August 2009, Xi'an, China", n.d., 1205 . 1207 [GENI-2009] "GENI Key Concepts - Global Environment for Network 1208 Innovations (GENI)", n.d., 1209 . 1211 [GUERZONI-2016] "Guerzoni, R., Vaishnavi, I., Perez-Caparros, D., 1212 Galis, A., et al Analysis of End-to-End Multi Domain 1213 Management and Orchestration Frameworks for Software 1214 Defined Infrastructures - an Architectural Survey", June 1215 2016, . 1217 [IMT2020-2015] "Report on Gap Analysis", ITU-T FG IMT2020, December 1218 2015, . 1221 [IMT2020-2016] "Draft Technical Report Application of network 1222 softwarization to IMT-2020 (O-041)", ITU-T FG IMT2020, 1223 December 2016, . 1226 [IMT2020-2016bis] "Draft Terms and definitions for IMT-2020 in ITU-T 1227 (O-040)", ITU-T FG IMT2020, December 2016, 1228 . 1231 [KARL-2016] "Karl, H., Peuster, M, Galis, A., et al DevOps for 1232 Network Function Virtualization - An Architectural 1233 Approach", July 2016, . 1236 [MANO-2014] "Network Functions Virtualisation (NFV); Management and 1237 Orchestration v1.1.1.", ETSI European Telecommunications 1238 Standards Institute., December 2014, 1239 . 1242 [NGMN-2016] "Hedmar,P., Mschner, K., et al - Description of Network 1243 Slicing Concept", NGMN Alliance NGS-3GPP-2016, January 1244 2016, . 1247 [NGS-3GPP-2016] "Study on Architecture for Next Generation System - 1248 latest version v1.0.2", September 2016, 1249 . 1252 [ONF-2016] Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 1253 M., Lopes, D., Kaippallimalit, J., - Open Network 1254 Fundation document "Applying SDN Architecture to 5G 1255 Slicing", Open Network Fundation, April 2016, 1256 . 1260 [5G-ICN] Ravi Ravindran, Asit Chakraborti, Syed Obaid Amin, Aytac 1261 Azgin, G.Q.Wang, "5G-ICN: Delivering ICN Services in 5G 1262 using Network Slicing", IEEE Communication Magazine, May, 1263 2017. 1265 [GRAMMATIKOU-2012] Grammatikou, M; Marinos, C; Martinez-Julia, P; 1266 Jofre, J; Gheorghiu, S; et al. Proceedings of the 1267 International Conference on Parallel and Distributed 1268 Processing Techniques and Applications (PDPTA); Athens: 1- 1269 5. Athens: The Steering Committee of The World Congress in 1270 Computer Science, Computer Engineering and Applied 1271 Computing (WorldComp). (2012) 1273 [GAL] A. Galis, Chih-Lin I" Towards 5G Network Slicing - Motivation 1274 and Challenges" IEEE 5G Tech Focus, Volume 1, Number 1, 1275 March 2017 - http://5g.ieee.org/tech-focus/march- 1276 2017#networkslicing 1278 [GAPS] Gap Analysis for Network Slicing draft-qiang-netslices-gap- 1279 analysis-01 1281 [NS UseCases] Network Slicing Use Cases: Network Customization for 1282 different services draft-makhijani-netslices-usecase- 1283 customization-03 1285 [NS ARCH] Network Slicing Architecture draft-geng-netslices- 1286 architecture-02 1288 Authors' Addresses 1289 Alex Galis 1290 University College London 1291 Email: a.galis@ucl.ac.uk 1293 Slawomir Kuklinski 1294 Orange 1295 Email: slawomir.kuklinski@orange.com 1297 Jie Dong 1298 Huawei Technologies 1299 Email: jie.dong@huawei.com 1301 Liang Geng 1302 China Mobile 1303 Email: gengliang@chinamobile.com 1305 Kiran Makhijani 1306 Huawei Technologies 1307 Email: kiran.makhijani@huawei.com 1309 Hannu Flinck 1310 Nokia 1311 Email: hannu.flinck@nokia-bell-labs.com 1313 Ravi Ravindran 1314 Huawei Technologies 1315 Email: ravi.ravindran@huawei.com 1317 Luis Miguel Contreras Murillo 1318 Telefonica 1319 Email: luismiguel.contrerasmurillo@telefonica.com 1321 Stewart Bryant 1322 Huawei Technologies 1323 Email: stewart.bryant@gmail.com 1325 Pedro Martinez-Julia 1326 National Institute of Information and Communications Technology 1327 (NICT) 1328 Email: pedro@nict.go.jp 1330 Susan Hares 1331 Huawei Technologies 1332 Email: shares@ndzh.com 1334 Carlos Jesus Bernardos Cano 1335 University Carlos III Madrid 1336 Email: cjbc@it.uc3m.es