idnits 2.17.1 draft-galis-anima-autonomic-slice-networking-04.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 36 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 360 has weird spacing: '...sequent secti...' == Line 416 has weird spacing: '...ces for enter...' == Line 506 has weird spacing: '...mically co-or...' == Line 521 has weird spacing: '...cluding the d...' == Line 738 has weird spacing: '...tion in which...' == (2 more instances...) -- The document date (March 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SLICING' is mentioned on line 207, but not defined == Unused Reference: 'RFC2119' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'I-D.strassner-anima-control-loops' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'NS1' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'NS2' is defined on line 1030, but no explicit reference was found in the text -- No information found for draft-ietf-anima- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-anima-grasp' ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) -- No information found for draft-du- - is the name correct? -- No information found for draft-ietf-anima-autonomic-control- - is the name correct? -- No information found for draft-ietf- - is the name correct? == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-02 == Outdated reference: A later version (-13) exists of draft-liu-anima-grasp-distribution-02 -- No information found for draft-strassner- - is the name correct? == Outdated reference: A later version (-06) exists of draft-wu-opsawg-service-model-explained-05 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Working Group A. Galis 3 Internet-Draft University College London 4 Intended Status: Standards Track K. Makhijani 5 Expires: September 6, 2018 D. Yu 6 B. Liu 7 Huawei Technologies 8 March 5, 2018 10 Autonomic Slice Networking 11 draft-galis-anima-autonomic-slice-networking-04 13 Abstract 15 This document describes the technical requirements and the related 16 reference model for the intercommunication and coordination among 17 devices in Autonomic Slicing Networking. The goal is to define how 18 the various elements in a network slicing context work and 19 orchestrate together, to describe their interfaces and relations. 20 While the document is written as generally as possible, the initial 21 solutions are limited to the chartered scope of the WG. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that other 30 groups may also distribute working documents as Internet-Drafts. 32 The list of current Internet-Drafts can be accessed at 33 https://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 https://www.ietf.org/shadow.html 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2017. 45 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. The Network Slicing Overall View . . . . . . . . . . . . . . . 3 63 2.1. Key Terms and Context . . . . . . . . . . . . . . . . . . 3 64 2.2. High Level Requirements . . . . . . . . . . . . . . . . . 6 65 3. Autonomic Slice Networking . . . . . . . . . . . . . . . . . . 8 66 4. Autonomic Inter-Slice Orchestration . . . . . . . . . . . . . 11 67 5. GRASP Resource Reservation / Release Messages flow . . . . . . 12 68 6. The Autonomic Network Slicing Element . . . . . . . . . . . . 13 69 7. The Autonomic Slice Networking Ianfrastructure . . . . . . . . 15 70 7.1. Signaling Between Autonomic Slice Element Managers . . . . 15 71 7.2. The Autonomic Control Plane . . . . . . . . . . . . . . . 17 72 7.3. Naming & Addressing . . . . . . . . . . . . . . . . . . . 17 73 7.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 74 7.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 8. Security and Trust Infrastructure . . . . . . . . . . . . . . 17 76 8.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 17 77 8.2. Domain Certificate . . . . . . . . . . . . . . . . . . . . 17 78 9. Cross-Domain Functionality . . . . . . . . . . . . . . . . . . 18 79 10. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 18 80 11. Management and Programmability . . . . . . . . . . . . . . . 18 81 11.1. How a Slice Network Is Managed . . . . . . . . . . . . . 18 82 11.2. Autonomic Resource Information Model . . . . . . . . . . 19 83 11.3. Control Loops . . . . . . . . . . . . . . . . . . . . . . 19 84 11.4. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 11.4.1. Slice Control APIs . . . . . . . . . . . . . . . . . 19 86 11.4.2. Service Agent - Device APIs . . . . . . . . . . . . . 19 87 11.4.3. Service Agent - Port APIs . . . . . . . . . . . . . . 19 88 11.4.4. Service Agent - Link APIs . . . . . . . . . . . . . . 20 89 11.5. Relationship with MANO . . . . . . . . . . . . . . . . . 20 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 12.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 20 92 12.2. Security Mechanisms . . . . . . . . . . . . . . . . . . . 20 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 97 14.2. Informative References . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 100 1 Introduction 102 The document "Autonomic Networking - Definitions and Design Goals" 103 [RFC7575] explains the fundamental concepts behind Autonomic 104 Networking, and defines the relevant terms in this space, as well as 105 a high level reference model. This document defines this reference 106 model with more detail, to allow for functional and protocol 107 specifications to be developed in an architecturally consistent, non- 108 overlapping manner. While the document is written as generally as 109 possible, the initial solutions are limited to the chartered scope of 110 the WG. 112 Most networks will run with some autonomic functions for the full 113 networks or for a group of nodes [RFC7576] or for a group of slice 114 networks while the rest of the network is traditionally managed. 116 The goal of this document is to focus on the autonomic slicing 117 networking. [RFC7575] is focusing on fully or partially autonomic 118 nodes or networks. 120 The proposed revised ANIMA reference model allows for this hybrid 121 approach across all such capabilities. It enhances [ASN]. 123 This is a living document and will evolve with the technical 124 solutions developed in the ANIMA WG. Sections marked with (*) do not 125 represent current charter items. 127 While this document must give a long term architectural view, not all 128 functions will be standardized at the same time. 130 2. The Network Slicing Overall View 132 2.1. Key Terms and Context 134 A number of slice definitions were used in the last 10 years in 135 distributed and federated testbed research [GENI], future internet 136 research [ChinaCom09] and more recently in the context of 5G research 137 [NGMN], [ONF], [IMT2020], [NGS-3GPP], [NS-ETSI]. Such definitions 138 converge towards NS as group of components: Service Instance, Network 139 Slice Instance, Resources and Slice Element Manager 140 In this draft we are using the following terms: 142 Logical resource - An independently manageable partition of a 143 physical resource, which inherits the same characteristics as the 144 physical resource and whose capability is bound to the capability of 145 the physical resource. It is dedicated to a Network Function or 146 shared between a set of Network Functions. 148 Virtual resource - An abstraction of a physical or logical resource, 149 which may have different characteristics from that resource, and 150 whose capability may not be bound to the capability of that resource 152 Network Function (NF) - A processing function in a network. It 153 includes but is not limited to network nodes functionality, e.g. 154 session management, mobility management, switching, routing 155 functions, which has defined functional behaviour and interfaces. 156 Network functions can be implemented as a network node on a dedicated 157 hardware or as a virtualized software functions. Data, Control, 158 Management, Orchestration planes functions are Network Functions. 160 Virtual Network Function (VNF) - A network function whose functional 161 software is decoupled from hardware. One or more virtual machines 162 running different software and processes on top of industry-standard 163 high-volume servers, switches and storage, or cloud computing 164 infrastructure, and capable of implementing network functions 165 traditionally implemented via custom hardware appliances and middle. 166 boxes (e.g. router, NAT, firewall, load balancer, etc.) Network 167 Slicing (NS) refers to a managed group of subsets of resources, 168 network functions / network virtual functions at the data, control, 169 management/orchestration planes and services at a given time. Network 170 slice is programmable and has the ability to expose its capabilities. 171 The behaviour of the network slice realized via network slice 172 instance(s). Network resources include connectivity, compute, and 173 storage resources. 175 Network Slicing is end-to-end concept covering the radio and non- 176 radio networks inclusive of access, core and edge / enterprise 177 networks. It enables the concurrent deployment of multiple logical, 178 self-contained and independent shared or partitioned networks on a 179 common infrastructure platform 181 Network slicing represents logically or physically isolated groups of 182 network resources and network function/virtual network functions 183 configurations separating its behavior from the underlying physical 184 network. 186 Network Slice Instance - An activated network slice. It is created 187 based on network template. A set of managed run-time network 188 functions, and resources to run these network functions, forming a 189 complete instantiated logical network to meet certain network 190 characteristics required by the service instance(s). It provides the 191 network characteristics that are required by a service instance. A 192 network slice instance may also be shared across multiple service 193 instances provided by the network operator. 195 From a business point of view, a slice includes combination of all 196 relevant network resources / functions / assets required to fulfill a 197 specific business case or service, including OSS, BSS and DevOps 198 processes. 200 From the network infrastructure point of view, slicing instances 201 require the partitioning and assignment of a set of resources that 202 can be used in an isolated, disjunctive or non- disjunctive manner. 204 Examples of physical or virtual resources to be shared or partitioned 205 would include: bandwidth on a network link, forwarding tables in a 206 network element (switch, router), processing capacity of servers, 207 processing capacity of network or network clouds elements [SLICING]. 208 As such slice instances would contain: 210 (i) a combination/group of the above resources which can act as a 211 network, 212 (ii) appropriate resource abstractions, 213 (iii) capability exposure of abstract resources towards service and 214 management clients that are needed for the operation of slices 216 The capability exposure creates an abstraction of physical network 217 devices that would provide information and information models 218 allowing operators to manipulate the network resources. By utilizing 219 open programmable network interfaces, it would enable access to 220 control layer by customer interfaces and applications. 222 The establishment of slices is both business-driven (i.e. slices are 223 in support for different types and service characteristics and 224 business cases) and technology-driven as slice is a grouping of 225 physical or virtual) resources (network, compute, storage) which can 226 act as a sub network and/or a cloud. A slice can accommodate service 227 components and network functions (physical or virtual) in all network 228 segments: access, core and edge / enterprise networks. 230 A complete slice is composed of not only various network functions 231 which are based on virtual machines at C-RAN and C-Core, but also 232 transport network resources that can be assigned to the slice at 233 radio access/transport network. Different future businesses require 234 different throughput, delay and mobility, and some businesses need 235 very high throughput or/and low delay. 237 2.2. High Level Requirements 239 Slice creation: management plane create virtual or physical network 240 functions and connects them as appropriate and instantiate them in 241 the slice, which is a subnetworks. 243 The instance of slice management then takes over the management and 244 operations of all the (virtualised) network functions and network 245 programmability functions assigned to the slice, and (re-)configure 246 them as appropriate to provide the end-to-end service. 248 A complete slice is composed of not only various network functions 249 which are based on virtual machines at C-RAN and C-Core, but also 250 transport network resources that can be assigned to the slice at 251 radio access/transport network. Different future businesses [5GNS], 252 [PER-NS] require different throughput, delay and mobility, and some 253 businesses need very high throughput or/and low delay. Transport 254 network shall provide QoS isolation, flexible network operation and 255 management, and improve network utilization among different business. 257 (1) Separation from partition of the physical network: Network 258 slicing represents logically or physically isolated groups of 259 network resources and network function/virtual network functions 260 configurations separating its behavior from the underlying 261 physical network. 263 (2) QoS Isolation: Although traditional VPN technology can provide 264 physical network resource isolation across multiple network 265 segments, it is deemed far less capable of supporting QoS hard 266 isolation, Which means QoS isolation on forwarding plane 267 requires better coordination with management plane. 269 (3) Independent Management Plane: Like above, network isolation is 270 not sufficient, a flexible and more importantly a management 271 plane per instance is required to operate on a slice 272 independently and autonomously within the constraints of 273 resources allocated to the slice. 275 (4) Another flexibility requirement is that an operator can deploy 276 their new business application or a service in network slice 277 with low cost and high speed, and ensure that it does not affect 278 existing of business applications adversely. 280 (5) Stringent Resource Characteristics: A Network Slicing aware 281 infrastructure allows operators to use part of the network 282 resources to meet stringent resource characteristics. 284 (6) Type of resources: Network Slice instance is a dedicated network 285 that is build and activated on an infrastructure mainly composed 286 of, but not limited to, connectivity, storage and computing. 288 (7) Programmability: Operator not only can slice a common physical 289 infrastructure into different logical networks to meet all kinds 290 of new business requirements, but also can use SDN based 291 technology to improve the overall network utilization. By 292 providing a flexible programmable interface; the 3rd party can 293 develop and deploy new network business rapidly. Further, if a 294 network slicing can run with its own slice controller, this 295 network slicing will get more granular control capability [I- 296 D.ietf-anima-autonomic-control-plane] to retrieve slice status, 297 and issuing slicing flow table, statistics fetch etc. 299 (8) Life cycle self-management: It includes creation, operations, 300 re- configuration, composition, decomposition, deletion of 301 slices. It would be performed automatically, without human 302 intervention and based on a governance configurable model of the 303 operators. As such protocols for slice set-up /operations 304 /(de)composition / deletion must also work completely 305 automatically. Self-management (i.e. self- configuration, self- 306 composition, self-monitoring, self-optimisation, self- 307 elasticity) is carried as part of the slice protocol 308 characterization. 310 (9) Network slice Self-management: Network slices will need to be 311 self-managed by automated, autonomic and autonomous systems in 312 order to cope with dynamic requirements, such as flexible 313 scalability, extensibility, elasticity, residency and 314 reliability of an infrastructure. Network slices will need to be 315 self-managed by automated, autonomic and autonomous systems in 316 order to cope with dynamic requirements, such as scalability or 317 extensibility of an infrastructure. A common information model 318 describing uniformly the NS in a single and/or multiple domain 319 would support such self-managed. 321 (10) Extensibility: Since the Autonomic Slice Networking 322 Infrastructure is a relatively new concept, it is likely that 323 changes in the way of operation will happen over time. As such 324 new networking functions will be introduced later, which allow 325 changes to the way the slices operate. 327 (11) Network Slice elasticity: A Network Slice instance has the 328 mechanisms and triggers for the growth/shrinkage of all 329 resources, and/or network and service functions as enabled by a 330 common information model that explicitly provides for elasticity 331 policies for scaling up/down resources. 333 (12) Multiple domains activation: Network slice instances are 334 concurrently activated as multiple logical, self-contained and 335 independent, partitioned network functions and resources on a 336 specific infrastructure domain. 338 (13) Resource Exposure: Each network slice has the ability to 339 dynamically expose and possibly negotiate the parameters that 340 characterize an NS as enabled by a common information model that 341 explicitly provides monitoring policies for all model 342 descriptors. 344 (14) Network Tenants: Network slicing support tenants that are 345 strongly independent on infrastructure as enabled by a common 346 information model that explicitly provides for a level of 347 tenants management for the resources dedicated to an instance of 348 network slice. 350 (15) End-to-end Orchestration of Network Slicing: Coordinating 351 underlay network infrastructure and service function resources. 352 In the process of orchestration of network slice, resource 353 registration and templates for network slice repository are 354 needed. 356 3. Autonomic Slice Networking 358 This section describes the various elements in a network with 359 autonomic functions, and how these entities work together, on a high 360 level. Subsequent sections explain the detailed inside view for 361 each of the autonomic network elements, as well as the network 362 functions (or interfaces) between those elements. 364 From a business point of view, a slice includes a combination of all 365 the relevant network resources, functions, and assets required to 366 fulfill a specific business case or service, including OSS, BSS and 367 DevOps processes. 369 From the network infrastructure point of view, network slice requires 370 the partitioning and assignment of a set of resources that can be 371 used in an isolated, disjunctive or non- disjunctive manner for that 372 slice. 374 From the tenant point of view, network slice provides different 375 capabilities, specifically in terms of their management and control 376 capabilities, and how much of them the network service provider hands 377 over to the slice tenant. As such there are two kinds of slices: (A) 378 Inner slices, understood as the partitions used for internal services 379 of the provider, retaining full control and management of them. (B) 380 Outer slices, being those partitions hosting customer services, 381 appearing to the customer as dedicated networks. 383 Network Slicing lifecycle includes the management plane selecting a 384 group of network resources (whereby network resources can be 385 physical, virtual or a combination thereof); it connects with the 386 physical and virtual network and service functions as appropriate, 387 and it instantiates all of the network and service functions assigned 388 to the slice. For slice operations, the control plane takes over 389 governing of all the network resources, network and service functions 390 assigned to the slice. It (re-) configures them as appropriate and as 391 per elasticity needs, in order to provide an end-to-end service. 393 One expected autonomic Slice Networking function is the capability 394 and resource Usability for a slice. Applications or services 395 requiring information of available slice capabilities and resources 396 are satisfied by abstracted resource view and control. Usability of 397 capabilities and resources can be enabled either by resource 398 publishing or by discovery. In the latter case, the service performs 399 resource collection directly from the provider of the slice by using 400 discovery mechanisms to get total information about the available 401 resources to be consumed. In the former, the network provider exposes 402 available resources to services (e.g., through a resource catalog) 403 reducing the amount of detail of the underlying network. 405 Slice Element Manager (SEM) is installed for each control domain. 406 Control domain is defined according to geographic location and 407 control functions. Each SEM converts requirements from orchestrator 408 into virtual resources and manages virtual resources of a slice. SEM 409 also exchanges information of virtual resources with other slice 410 element managers via a dedicated resource interface. SEM provides 411 also capability exposure facilities by allowing 3rd parties to access 412 / use via APIs information regarding services provided by the slice 413 (e.g. connectivity information, QoS, mobility, autonomicity, etc.) 414 and to dynamically customize the network characteristics for 415 different diverse use cases (e.g. ultra-low latency, ultra- 416 reliability, value-added services for enterprises, etc.) within the 417 limits set of functions by the operator. 419 Physical Element Manager (PEM) is installed for each control domain. 420 Control domain is defined according to geographic location and 421 control functions. PEM exchanges information of virtual resource with 422 SEM via virtual resource interface and interconverts between virtual 423 resource and physical resource. The PEM orders physical functions 424 (ex. switches) to allocate physical resource via physical resource 425 interface. 427 Figure 1 shows the high level view of an Autonomic Slice Networking. 429 It consists of a number of autonomic nodes resources, which interact 430 directly with each other. Those autonomic nodes resources provide a 431 common set of capabilities across a network slice, called the 432 "Autonomic Slice Networking Infrastructure" (ASNI). 434 The ASN provides functions like naming, addressing, negotiation, 435 synchronization, discovery and messaging. 437 Autonomic network functions typically span several slices in the 438 network. The atomic entities of an autonomic function are called the 439 "Autonomic Service Agents" (ASA), which are instantiated on slices. 441 In a horizontal view, autonomic functions span across the network, as 442 well as the Autonomic Slice Networking Infrastructure. In a vertical 443 view, a slice always implements the ASNI, plus it may have one or 444 several Autonomic Service Agents as part of slice capability 445 exposure. The Autonomic Networking Infrastructure (ASNI) therefore is 446 the foundation for autonomic functions. The current charter of the 447 ANIMA WG includes the specification of the ASNI, using a few 448 autonomic functions as use cases. ASNI would represent a customized 449 and an approach [I-D.ietf-anima-reference-model] for implementing a 450 general purposed ASI. 452 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 453 : : Autonomic Slice Function 1 : : 454 : SSA 1 : SSA 1 : SSA 1 : SSA 1 : 455 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 456 : : : 457 : +- - - - - - - - - - - - - - + : 458 : : Autonomic Slice Function 2 : : 459 : : ASC 2 : ASC 2 : : 460 : +- - - - - - - - - - - - - - + : 461 : : : 462 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 463 : Autonomic Slice Networking Infrastructure : 464 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 465 + + 466 + +-----------------------------------------+ + 467 + | Autonomic Inter-Slice Orchestration | + 468 + +-----------------------------------------+ + 469 + | | | + 470 +----------+ +-----------+ +----------+ 471 |Slice 1 | |Slice 2 | | Slice N | 472 | SEM |-------| SEM |------ ... ---- | SEM | 473 | | | | | | 474 +----------+ +-----------+ +----------+ 475 | | | 477 +-------------------------------------------------------------+ 478 | | 479 | PEC1 PEC2 PECm | 480 | | ... | ... | | 481 | | 482 | Resources / Network Functions / ANI | 483 | | 484 +-------------------------------------------------------------+ 485 | | | | 486 +----------------------+ +------------+ +------------+ 487 +-------+ +---------+ + +-------+ + + +--------+ + 488 | Node1.1 --| Node1.N |------ |Node2.x|-...------ | NodeM.y| + 489 +-------+ +---------+ + +-------+ + + +--------+ + 490 +----------------------+ +------------+ +------------+ 491 Domain 1 Domain 2 Domain M 493 Figure 1: High level view of Autonomic Slice Networking 495 Additionally, at least 2 autonomous functions are envisioned - 496 Autonomous Slice control (ASC) and Slice Service agent (SSA). These 497 are explained in sections below. 499 4. Autonomic Inter-Slice Orchestration 501 This section describes an autonomic orchestration and its 502 functionality. 504 Orchestration refers to the system functions that: 506 * automated and autonomically co-ordination of network functions 507 in slices 509 * autonomically coordinate the slices lifecycle and all the 510 components that are part of the slice (i.e. Service Instances, 511 Network Slice Instances, Resources, Capabilities exposure) to 512 ensure an optimized allocation of the necessary resources across 513 the network. 515 * coordinate a number of interrelated resources, often distributed 516 across a number of subordinate domains, and to assure 517 transactional integrity as part of the process [TETT1]. 519 * autonomically control of slice life cycle management, including 520 concatenation of slices in each segment of the infrastructure 521 including the data pane, the control plane, and the management 522 plane. 524 * autonomically coordinate and trigger of slice elasticity and 525 placement of logical resources in slices. 527 * coordinates and (re)-configure logical resources in the slice by 528 taking over the control of all the virtualized network functions 529 assigned to the slice. 531 It is also the continuing process of allocating resources to satisfy 532 contending demands in an optimal manner [TETT2]. The idea of optimal 533 would include at least prioritized SLA commitments [SERMODEL], and 534 factors such as customer endpoint location, geographic or topological 535 proximity, delay, aggregate or fine-grained load, monetary cost, 536 fate- sharing or affinity. The word continuing incorporates 537 recognition that the environment and the service demands constantly 538 change over the course of time, so that orchestration is a 539 continuous, multi-dimensional optimization feedback loop [I- 540 D.strassner-anima-control-loops]. 542 It protects the infrastructure from instabilities and side effects 543 due to the presence of many slice components running in parallel. It 544 ensures the proper triggering sequence of slice functionality and 545 their stable operation. It defines conditions/constraints under 546 which service components will be activated, taking into account 547 operator service and network requirements (inclusive of optimize the 548 use of the available network & compute resources and avoid situations 549 that can lead to sub-par performance and even unstable and 550 oscillatory behaviors. 552 5. GRASP Resource Reservation / Release Messages flow 554 Inter Slice Physical 555 Slice Element Element Domain Physical 556 Orchestrator Manager Manager Manager Function 558 | | | | | 559 | GRASP Discovery |GRASP Discovery|GRASP Discovery |GRASP Discovery| 560 | -Response | -Response | -Response | -Response | 561 | <-------------->| <------------>| <-----------> | <-----------> | 562 | | | | | 563 | GRASP Request | | | | 564 |Slicing Objective | GRASP Request | | | 565 | -------------> | Slicing | | | 566 | | Objectives | GRASP Request | | 567 | | ------------> | Slicing |GRASP Request | 568 | | | Objectives |Slicing | 569 | | | -----------> |Objectives | 570 | | | |-----------> | 571 | | | GRASP | | 572 | | | Confirm-Waiting | | 573 | | | <--------- | | 574 | |GRASP | | | 575 | |Confirm-Waiting| |GRASP | 576 | | <----------- | |Negotiation | 577 | | | |Single/Multiple| 578 | | |GRASP Negotiation|Rounds | 579 | | |Single/Multiple |<-----------> | 580 | | |Rounds | | 581 | GRASP | | <-----------> | | 582 | Confirm-Waiting | | | | 583 |<--------------- |GRASP | | | 584 | |Negotiation | | | 585 | |Single/Multiple| | | 586 | |Rounds | | | 587 |GRASP Negotiation | <-----------> | | | 588 |Single/Multiple | | | | 589 |Rounds | | | | 590 | <------------> | | | | 591 Figure 2 - GRASP: Network Slice reservation / Release3 Messages Flow 593 The above message sequence figure shows the message flows of the 594 interactions between Inter-Slice Orchestrator, Slice Element Manager, 595 Physical Element Manager, Domain Manager and Physical Network 596 functions. 598 6. The Autonomic Network Slicing Element 600 This section describes an autonomic slice network element and its 601 internal architecture. The reference model explained in the document 602 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 603 the sources of information that an autonomic service agent can 604 leverage: Self-management, Self-knowledge, network knowledge (through 605 discovery), Intent [I-D.du-anima-an-intent], and feedback loops. 606 Fundamentally, there are two levels inside an autonomic node: the 607 level of Autonomic Service Agents, and the level of the Autonomic 608 Slice Networking Infrastructure, with the former using the services 609 of the latter. The self management functionality (self-configuration, 610 self-optimisation, self- healing) could be implemented across the 611 Inter Slice Orchestrator, Slice Element Manager and Physical Element 612 Manager. Such functionality deals with dynamic 614 * coordination the life cycle of slices 615 * allocation of resources to slice instances in an efficient way 616 that provides required slice instances performance, 618 * self-configuration, self-optimization and self-healing of slice 619 instances during their lifecycle management including deployment 620 and operations 622 * self-configuration, self-optimization and self-healing of 623 services of each slice instance. Service lifecycle, that is 624 typically different than slice instance lifecycle should also be 625 managed in the autonomous way. 627 Figure 3 illustrates this concept. 629 +------------------------------------------------------------+ 630 | | 631 | +-----------+ +------------+ +------------+ | 632 | | Autonomic | | Autonomic | | Autonomic | | 633 | | Service | | Service | | Service | | 634 | | Agent 1 | | Agent 2 | | Agent 3 | | 635 | +-----------+ +------------+ +------------+ | 636 | ^ ^ ^ | 637 | - - -| - - API level - - | - - - - - - - - - - |- - - - - | 638 | V V V | 639 |------------------------------------------------------------| 640 | Autonomic Slice Networking Infrastructure | 641 | - Service characteristics (ultra-low latency, | 642 | ultra-reliability, etc) | 643 | - Autonomic Control Plane functions | 644 | - Autonomic Management Plane functions | 645 | - Self-x functions and related control loops elements | 646 | - Autonomic Slice Addressing | 647 | Discovery, negotiation and synchronisation functions | 648 | - Intent distribution | 649 | - Aggregated reporting and feedback loops | 650 | - Routing | 651 | - Security mechanisms | 652 |------------------------------------------------------------| 653 | Basic Operating System Functions | 654 +------------------------------------------------------------+ 655 Figure 3: Model of an autonomic element 657 The Autonomic Slice Networking Infrastructure (lower part of Figure 658 2) contains slice specific data structures, for example trust 659 information about itself and its peers, as well as a generic set of 660 functions, independent of a particular usage. This infrastructure 661 should be generic, and support a variety of Autonomic Service Agents 662 (upper part of Figure 2). The Autonomic Control Plane is the summary 663 of all interactions of the Autonomic Slice Networking Infrastructure 664 with other services. 666 The use cases of "Autonomics" such as self-management, self- 667 optimisation, etc, are implemented as Autonomic Service Agents. They 668 use the services and data structures of the underlying autonomic 669 networking infrastructure. The Autonomic Slice Networking 670 Infrastructure should itself be self-managing. 672 The "Basic Operating System Functions" include the "normal OS", 673 including the network stack, security functions, etc. Autonomic 674 Network Slicing Element is a composition of autonomic slice service 675 agents and autonomic slice control. Autonomic slice service agents 676 obtain specific network resources and provide self-managing and self- 677 controlling functions. An autonomic slice control is a higher-level 678 autonomic function that takes the role of life-cycle management of a 679 or many slice instances. There can be many slice control functions 680 based on different types or attributes of slice. 682 7. The Autonomic Slice Networking Ianfrastructure 684 The Autonomic Networking Infrastructure provides a layer of common 685 functionality across an Autonomic Network. It comprises "must 686 implement" functions and services, as well as extensions. The 687 Autonomic Slice Networking Infrastructure (ASNI) resides on top of an 688 abstraction layer of resource, network function and network 689 infrastructure as shown in figure 1. The document assumes 690 abstraction layer enables different autonomous service agents to 691 communicate with the underlying disaggregated and distributed network 692 infrastructure, which itself maybe an autonomous networking (AN) 693 domain or combination of multiple AN domain. The goal of ASNI is to 694 provide autonomic life-cycle management of network slices. 696 7.1. Signaling Between Autonomic Slice Element Managers 698 The basic network capabilities are autonomically or through 699 traditional techniques are learnt by slice agents. This depends on 700 the fact that physical infrastructure is an autonomic network or not. 701 The GASP extensions signaling [I-D.liu-anima-grasp-distribution] 702 [I-D.liu-anima-grasp-api] [I-D.ietf-anima-grasp] may be used for 704 * Discovery of SEMs - a process by which an one SEM discovers 705 peers according to a specific discovery objective. The 706 discovered SEMs peers may later be used as negotiation 707 counterparts or as sources of other coordination activities. 709 * Negotiation between SEMs - a process by which two SEMs interact 710 to agree on slice logical resource settings that best satisfy 711 the objectives of both SEMs. 713 * The Synchronization between SEMs - a process by which 714 Orchestrator and SEMs interact to receive the current state of 715 capability exposure values used at a given time in other SEM. 716 This is a special case of negotiation in which information is 717 sent but the SEM or Orchestrator do not request their peers to 718 change configuration settings. 720 * Self configuration of SEMs - a process by which Orchestrator and 721 SEMs interact to receive the current state of capability 722 exposure values used at a given time in other SEM. This is a 723 special case of synchronization in which information is sent and 724 the SEM is requesting their peers to change configuration 725 settings. 727 * Self optimization of SEMs - a process by which Orchestrator and 728 SEMs interact to receive the current state of capability 729 exposure values used at a given time in other SEMs. This is a 730 special case of configuration in which information is sent and 731 the SEM is requesting their peers to change logical resource 732 settings in a slice based on an optimisation criteria. 734 * Mediation for slice resources - a process by which two SEMs 735 interact to agree to logically move resources between slices 736 that best satisfy the objectives of both SEMs triggering of 737 slice elasticity and placement of logical resources in slices. 738 Th???is is a special case of negotiation in which information 739 is sent Orchestrator do request SEMs to change logical resource 740 configuration settings. 742 * Triggering and governing of elasticity ? a process for autonomic 743 scaling intent configuration mechanisms and resources on the 744 slice level; it allows rapid provisioning, automatic scaling 745 out, or in, of resources. Scale in/out criteria might be used 746 for network autonomics in order the controller to react to a 747 certain set of variations in monitored slices. 749 * Providing on-demand a self-service network slicing. 751 Optionally, SSA capabilities are more interesting to slice control 752 autonomic functions for slice creation and install. The slice control 753 must have the independent intelligence to process and filter 754 capabilities to meet a network slice specification and have low level 755 resources allocated for a slice through SSAs. 757 7.2. The Autonomic Control Plane 759 TBD. 761 7.3. Naming & Addressing 763 A slice can be instantiated on demand, represents a logical network 764 and therefore, must be assigned a unique identifier. A Slice Service 765 Agent (SSA) may support functions of a single or multiple slices and 766 communicate with each other, using the addressing of the Autonomic or 767 traditional (non-autonomic) Networking Infrastructure reside on. An 769 SSA complies with ACP addressing mechanisms and in a domain, i.e., As 770 part of the enrolment process the registrar assigns a number to the 771 device, which is unique for slicing registrar and in ASNI domain. 773 7.4. Discovery 775 Slices themselves are not discovered but are instantiated through 776 slice control autonomic function. However, both slice service agents 777 and slice control functions must be discovered. Even though 778 autonomic control plane will support discovery of all the SSAs and 779 slice control, it may not be necessary. 781 7.5. Routing 783 Autonomic network slicing follows single routing protocol as 784 described in [I-D.ietf-anima-autonomic-control-plane]. 786 8. Security and Trust Infrastructure 788 An Autonomic Slice Network is self-protecting. All protocols are 789 secure by default, without the requirement for the administrator to 790 explicitly configure security. 792 TBD. 794 8.1. Public Key Infrastructure 796 An autonomic domain uses a PKI model. The root of trust is a 797 certification authority (CA). A registrar acts as a registration 798 authority (RA). 800 A minimum implementation of an autonomic domain contains one CA, one 801 Registrar, and network elements. 803 8.2. Domain Certificate 804 TBD. 806 9. Cross-Domain Functionality 808 TBD. 810 10. Autonomic Service Agents (ASA) 812 This section describes how autonomic services run on top of the 813 Autonomic Slice Networking Infrastructure. There are at least two 814 different types of autonomic functions are known: 816 1. Slice Service Agents are low level functions that learn 817 capabilities of underlying infrastructure in terms of interfaces 818 and available resources. They coordinate with Slice control to 819 associate these resources with specific slice instances in 820 effect performing full life cycle management of these resources. 821 2. Slice Control Autonomic Function: Slice control is responsible 822 for high-level life-cycle management of a slice itself. This 823 function will hold slice instances and their attributes related 824 data structures in autonomic network slice infrastructure. As 825 an example, a slice is defined for high bandwidth, highly secure 826 transactional application. A slice control must be capable of 827 negotiating resources required across different SSAs. 829 Out of scope are details of the mechanisms how the information is 830 represented and exchanged between the two autonomic functions. 832 11. Management and Programmability 834 This section describes how an Autonomic Network is managed, and 835 programmed. 837 11.1. How a Slice Network Is Managed 839 Slice autonomic management is driven by Slice Element Managers, 840 there are five categories operation: 842 1. Creating a network slice: Receive a network slice resource 843 description request, upon successful negotiation with SSA 844 allocate resource for it. 845 2. Shrink/Expand slice network: Dynamically alter resource 846 requirements for a running slice network according service load. 847 3. (Re-)Configure slice network: The slice management user deploys 848 a user level service into the slice. The slice control takes 849 over the control of all the virtualized network functions and 850 network programmability functions assigned to the slice, and 851 (re-)configure them as appropriate to provide the end-to-end 852 service. 853 5. Self-X slice operation: namely self-configuration, self- 854 composition, self-monitoring, self-optimisation, self-elasticity 855 would be carried out as part of new slice protocols. 857 11.2. Autonomic Resource Information Model 859 TBD. 861 The proposed autonomic resource information model is presented as a 862 tree structure of attributes including the following elements: 863 connectivity resources, storage resources, compute resources, service 864 instances, network slice level attributes, etc. The Yang language 865 would be used to represent the autonomic resource information model. 867 11.3. Control Loops 869 TBD. 871 11.4. APIs 873 The API model of for autonomic slicing semantically, is grouped into 874 the following APIs to be defined. 876 11.4.1. Slice Control APIs 878 1. Create a slice network on user request. The request includes 879 resource description. A unique identify a slice network, group 880 all the resource. 881 2. Destroy a slice network identified by it's id. 882 3. Query a slice network slicing state by it's uuid. 883 4. Modify a slice network. 885 11.4.2. Service Agent - Device APIs 887 A service agent will interface with the physical infrastructure 888 either through an autonomic network or traditional infrastructure. 889 Depending upon which a device can either have autonomic or non- 890 autonomic addressing. Service agents are required to perform life 891 cycle management of network elements participating in a network slice 892 and the following APIs are needed for addition, removal or update of 893 a specific device. A device may be a logical or physical network 894 element. Optionally, it may be a network function. 896 11.4.3. Service Agent - Port APIs 897 A port may be a physical or logical network port in a slice depending 898 upon whether underlying infrastructure is an autonomic or traditional 899 network. Service agents must be able to control the operational 900 state of these ports. APIs are needed for addition, removal, update 901 and operational state retrieval of a specific port. 903 11.4.4. Service Agent - Link APIs 905 A link connects two or more ports of devices described in above 906 section. Service agents must be able to control the operational and 907 connection status of these links through APIs for addition, removal, 908 update and state retrieval for each link. 910 11.5. Relationship with MANO 912 Please refer to [MANO] for MANO introduction. 914 12. Security Considerations 916 12.1. Threat Analysis 918 TBD. 920 12.2. Security Mechanisms 922 TBD. 924 13. IANA Considerations 926 This document requests no action by IANA. 928 14. Acknowledgements 930 This document was converted to nroff by Stuart Clayman (UCL) to 931 comply with RFC format [RFC2629]. 933 14. References 935 14.1. Normative References 937 [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A 938 Generic Autonomic Signaling Protocol (GRASP)", draft-ietf- 939 anima- grasp-10 (work in progress), March 2017. 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, DOI 943 10.17487/RFC2119, March 1997, . 946 [RFC7665] Halpern, J., Pignataro, C., "Service Function Chaining 947 (SFC) Architecture", October 2015 948 . 950 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 951 10.17487/RFC2629, June 1999, . 954 14.2. Informative References 956 [ChinaCom09] A. Galis et all - "Management and Service-aware 957 Networking Architectures (MANA) for Future Internet" - 958 Invited paper IEEE 2009 Fourth International Conference on 959 Communications and Networking in China (ChinaCom09) 26-28 960 August 2009, Xi'an, China, 961 . 963 [GENI] "GENI Key Concepts - Global Environment for Network 964 Innovations (GENI)" 965 . 967 [I-D.du-anima-an-intent] Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., 968 and M. Behringer, "ANIMA Intent Policy and Format", draft- 969 du- anima-an-intent-04 (work in progress), July 2016. 971 [I-D.ietf-anima-autonomic-control-plane] Behringer, M., Eckert, T., 972 and S. Bjarnason, "An Autonomic Control Plane", draft- 973 ietf-anima-autonomic-control- plane-03 (work in progress), 974 July 2016. 976 [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., 977 Eckert, T., Ciavaglia, L., Pierre, P., Liu, B., Nobre, J., 978 and J. Strassner, "A Reference Model for Autonomic 979 Networking", draft-ietf- anima-reference-model-02 (work in 980 progress), July 2016. 982 [I-D.liu-anima-grasp-api] Carpenter, B., Liu, B., Wang, W., and X. 983 Gong, "Generic Autonomic Signaling Protocol Application 984 Program Interface (GRASP API)", draft-liu-anima-grasp-api- 985 02 (work in progress), September 2016. 987 [I-D.liu-anima-grasp-distribution] Liu, B. and S. Jiang, "Information 988 Distribution over GRASP", draft-liu-anima-grasp- 989 distribution-02 (work in progress), September 2016. 991 [I-D.strassner-anima-control-loops] Strassner, J., Halpern, J., and 992 M. Behringer, "The Use of Control Loops in Autonomic 993 Networking", draft-strassner- anima-control-loops-01 (work 994 in progress), April 2016. 996 [IMT2020] ITU-T IMT2020 document "Report on Gap Analysis" - ITU-T 997 IMT2020 ITU- Dec 2015 Published by ITU-T IMT2020. 998 . 1001 [MANO] "ETSI European Telecommunications Standards Institute. 1002 Network Functions Virtualisation (NFV); Management and 1003 Orchestration v1.1.1." Website, December 2014. 1004 . 1007 [NGMN] Hedmar,P., Mschner, K., et all - NGMN Alliance document 1008 "Description of Network Slicing Concept", January 2016. 1009 . 1012 [NGS-3GPP] "Study on Architecture for Next Generation System" - 1013 latest version v1.0.2 September 2016 1014 . 1017 [ONF] Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 1018 M., Lopes, D., Kaippallimalit, J., - Open Network 1019 Fundation document "Applying SDN Architecture to 5G 1020 Slicing", April 2016. 1021 . 1025 [NS1] L. Geng, J. Dong, S. Bryant, K., Makhijani, A., Galis, X. 1026 de Foy, S. Kuklinski, - "Network Slicing Architecture", 1027 July 2017. . 1030 [NS2] L. Geng, L. Wang, S. Kuklinski, L. Qiang, S. Matsushima, 1031 A., Galis, L. Contreras - "Problem Statement of Supervised 1032 Heterogeneous Network Slicing", October 2017 1033 . 1036 [ASN] A., Galis, K., Makhijani, D. Yu, B. Liu - "Autonomic Slice 1037 Networking-Requirements and Reference Model" - May 2017 < 1038 https://datatracker.ietf.org/doc/draft-galis-anima- 1039 autonomic-slice-networking/>. 1041 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1042 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1043 Networking: Definitions and Design Goals", RFC 7575, DOI 1044 10.17487/RFC7575, June 2015, . 1047 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1048 Analysis for Autonomic Networking", RFC 7576, DOI 1049 10.17487/RFC7576, July 2016, . 1052 [TETT1] Guerzoni, R., Vaishnavi, I., Pares-Caparros, D., Galis, 1053 A., et al, "Analysis of End-to-End Multi Domain Management 1054 and Orchestration Frameworks for Software Defined 1055 Infrastructures: an Architectural Survey", Transactions on 1056 Emerging Telecommunications Technologies, Wiley Online 1057 Library, DOI: 10.1002/ett.3103, June 2016, 1058 . 1060 [TETT2] Karl, H., Draxler, S., Peuster, M, Galis, A., et all 1061 "DevOps for Network Function Virtualization: An 1062 Architectural Approach", Transactions on Emerging 1063 Telecommunications Technologies Wiley Online Library, DOI: 1064 10.1002/ett.3084, July 2016, 1065 . 1067 [SERMODEL] C., Borman, B. Carpenter, B., Liu, "Service Models 1068 Explained " draft-wu-opsawg-service-model-explained-05 1069 . 1072 [5GNS] Galis, A. (UCL), Chih-Lin I (China Mobile) - "Towards 5G 1073 Network Slicing - Motivations and Challenges" March 2017, 1074 IEEE 5G Tech Focus, Volume 1, Number 1, March 2017- 1075 . 1077 [PER-NS] Galis, A. - " Perspectives on Network Slicing - Towards the 1078 New 'Bread and Butter' of Networking and Servicing", IEEE 1079 SDN Initiative - January 2018 1080 . 1084 [NS-ETSI] "Network Functions Virtualisation (NFV) Release 3; 1085 Evolution and Ecosystem; Report on Network Slicing Support 1086 with ETSI NFV Architecture Framework- ETSI GR NFV-EVE 012 1087 V3.1.1 (2017-12)" 1088 1091 Authors' Addresses 1093 Alex Galis (editor) 1094 University College London 1095 Department of Electronic and Electrical Engineering 1096 Torrington Place 1097 London WC1E 7JE 1098 United Kingdom 1100 Email: a.galis@ucl.ac.uk 1102 Kiran Makhijani 1103 Huawei Technologies 1104 2890, Central Expressway 1105 Santa Clara CA 95032 1106 USA 1108 Email: USA Email: kiran.makhijani@huawei.com 1110 Delei Yu 1111 Huawei Technologies 1112 Q22, Huawei Campus 1113 No.156 Beiqing Road 1114 Hai-Dian District, Beijing 100095 1115 P.R. China 1117 Email: yudelei@huawei.com 1119 Bing Liu 1120 Huawei Technologies Co., Ltd 1121 Q14, Huawei Campus 1122 No.156 Beiqing Road 1123 Hai-Dian District, Beijing 100095 1124 P.R. China 1126 Email: leo.liubing@huawei.com