idnits 2.17.1 draft-galis-anima-autonomic-slice-networking-03.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 354 has weird spacing: '...sequent secti...' == Line 381 has weird spacing: '...ces for enter...' == Line 470 has weird spacing: '...mically co-or...' == Line 485 has weird spacing: '...cluding the d...' == Line 700 has weird spacing: '...tion in which...' == (2 more instances...) -- The document date (November 5, 2017) is 2363 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 896, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 901, but no explicit reference was found in the text == Unused Reference: 'I-D.strassner-anima-control-loops' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'NS1' is defined on line 980, but no explicit reference was found in the text == Unused Reference: 'NS2' is defined on line 985, but no explicit reference was found in the text == Unused Reference: '5GNS' is defined on line 1027, 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 (~~), 17 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Galis 3 Internet-Draft University College London 4 Intended Status: Standards Track K. Makhijani 5 Expires: May 5, 2018 D. Yu 6 B. Liu 7 Huawei Technologies 8 November 5, 2017 10 Autonomic Slice Networking 11 draft-galis-anima-autonomic-slice-networking-03 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 May 5, 2018. 45 Copyright Notice 46 Copyright (c) 2017 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 . . . . . . . . . . . . . 10 67 5. GRASP Resource Reservation / Release Messages flow . . . . . . 11 68 6. The Autonomic Network Slicing Element . . . . . . . . . . . . 12 69 7. The Autonomic Slice Networking Infrastructure . . . . . . . . 14 70 7.1. Signaling Between Autonomic Slice Element Managers . . . . 14 71 7.2. The Autonomic Control Plane . . . . . . . . . . . . . . . 16 72 7.3. Naming & Addressing . . . . . . . . . . . . . . . . . . . 16 73 7.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16 74 7.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8. Security and Trust Infrastructure . . . . . . . . . . . . . . 16 76 8.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 16 77 8.2. Domain Certificate . . . . . . . . . . . . . . . . . . . . 17 78 9. Cross-Domain Functionality . . . . . . . . . . . . . . . . . . 17 79 10. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 17 80 11. Management and Programmability . . . . . . . . . . . . . . . 17 81 11.1. How a Slice Network Is Managed . . . . . . . . . . . . . 17 82 11.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 11.3. Control Loops . . . . . . . . . . . . . . . . . . . . . . 18 84 11.4. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 11.4.1. Slice Control APIs . . . . . . . . . . . . . . . . . 18 86 11.4.2. Service Agent - Device APIs . . . . . . . . . . . . . 18 87 11.4.3. Service Agent - Port APIs . . . . . . . . . . . . . . 18 88 11.4.4. Service Agent - Link APIs . . . . . . . . . . . . . . 19 89 11.5. Relationship with MANO . . . . . . . . . . . . . . . . . 19 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 12.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 19 92 12.2. Security Mechanisms . . . . . . . . . . . . . . . . . . . 19 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 97 14.2. Informative References . . . . . . . . . . . . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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]. Such definitions converge 138 towards NS as group of components: Service Instance, Network Slice 139 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 require 252 different throughput, delay and mobility, and some businesses need 253 very high throughput or/and low delay. Transport network shall 254 provide QoS isolation, flexible network operation and management, and 255 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 3. Autonomic Slice Networking 352 This section describes the various elements in a network with 353 autonomic functions, and how these entities work together, on a high 354 level. Subsequent sections explain the detailed inside view for 355 each of the autonomic network elements, as well as the network 356 functions (or interfaces) between those elements. 358 One expected autonomic Slice Networking function is the capability 359 and resource Usability for a slice. Applications or services 360 requiring information of available slice capabilities and resources 361 are satisfied by abstracted resource view and control. Usability of 362 capabilities and resources can be enabled either by resource 363 publishing or by discovery. In the latter case, the service performs 364 resource collection directly from the provider of the slice by using 365 discovery mechanisms to get total information about the available 366 resources to be consumed. In the former, the network provider exposes 367 available resources to services (e.g., through a resource catalog) 368 reducing the amount of detail of the underlying network. 370 Slice Element Manager (SEM) is installed for each control domain. 371 Control domain is defined according to geographic location and 372 control functions. Each SEM converts requirements from orchestrator 373 into virtual resources and manages virtual resources of a slice. SEM 374 also exchanges information of virtual resources with other slice 375 element managers via a dedicated resource interface. SEM provides 376 also capability exposure facilities by allowing 3rd parties to access 377 / use via APIs information regarding services provided by the slice 378 (e.g. connectivity information, QoS, mobility, autonomicity, etc.) 379 and to dynamically customize the network characteristics for 380 different diverse use cases (e.g. ultra-low latency, ultra- 381 reliability, value-added services for enterprises, etc.) within the 382 limits set of functions by the operator. 384 Physical Element Manager (PEM) is installed for each control domain. 385 Control domain is defined according to geographic location and 386 control functions. PEM exchanges information of virtual resource with 387 SEM via virtual resource interface and interconverts between virtual 388 resource and physical resource. The PEM orders physical functions 389 (ex. switches) to allocate physical resource via physical resource 390 interface. 392 Figure 1 shows the high level view of an Autonomic Slice Networking. 393 It consists of a number of autonomic nodes resources, which interact 394 directly with each other. Those autonomic nodes resources provide a 395 common set of capabilities across a network slice, called the 396 "Autonomic Slice Networking Infrastructure" (ASNI). 398 The ASN provides functions like naming, addressing, negotiation, 399 synchronization, discovery and messaging. 401 Autonomic network functions typically span several slices in the 402 network. The atomic entities of an autonomic function are called the 403 Autonomic Service Agents" (ASA), which are instantiated on slices. 405 In a horizontal view, autonomic functions span across the network, as 406 well as the Autonomic Slice Networking Infrastructure. In a vertical 407 view, a slice always implements the ASNI, plus it may have one or 408 several Autonomic Service Agents as part of slice capability 409 exposure. The Autonomic Networking Infrastructure (ASNI) therefore is 410 the foundation for autonomic functions. The current charter of the 411 ANIMA WG includes the specification of the ASNI, using a few 412 autonomic functions as use cases. ASNI would represent a customized 413 and an approach [I-D.ietf-anima-reference-model] for implementing a 414 general purposed ASI. 416 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 417 : : Autonomic Slice Function 1 : : 418 : SSA 1 : SSA 1 : SSA 1 : SSA 1 : 419 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 420 : : : 421 : +- - - - - - - - - - - - - - + : 422 : : Autonomic Slice Function 2 : : 423 : : ASC 2 : ASC 2 : : 424 : +- - - - - - - - - - - - - - + : 425 : : : 426 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 427 : Autonomic Slice Networking Infrastructure : 429 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 430 + + 431 + +-----------------------------------------+ + 432 + | Autonomic Inter-Slice Orchestration | + 433 + +-----------------------------------------+ + 434 + | | | + 435 +----------+ +-----------+ +----------+ 436 |Slice 1 | |Slice 2 | | Slice N | 437 | SEM |-------| SEM |------ ... ---- | SEM | 438 | | | | | | 439 +----------+ +-----------+ +----------+ 440 | | | 441 +-------------------------------------------------------------+ 442 | | 443 | PEC1 PEC2 PECm | 444 | | ... | ... | | 445 | | 446 | Resources / Network Functions / ANI | 447 | | 448 +-------------------------------------------------------------+ 449 | | | | 450 +----------------------+ +------------+ +------------+ 451 +-------+ +---------+ + +-------+ + + +--------+ + 452 | Node1.1 --| Node1.N |------ |Node2.x|-...------ | NodeM.y| + 453 +-------+ +---------+ + +-------+ + + +--------+ + 454 +----------------------+ +------------+ +------------+ 455 Domain 1 Domain 2 Domain M 457 Figure 1: High level view of Autonomic Slice Networking 459 Additionally, at least 2 autonomous functions are envisioned - 460 Autonomous Slice control (ASC) and Slice Service agent (SSA). These 461 are explained in sections below. 463 4. Autonomic Inter-Slice Orchestration 465 This section describes an autonomic orchestration and its 466 functionality. 468 Orchestration refers to the system functions that: 470 * automated and autonomically co-ordination of network functions 471 in slices 473 * autonomically coordinate the slices lifecycle and all the 474 components that are part of the slice (i.e. Service Instances, 475 Network Slice Instances, Resources, Capabilities exposure) to 476 ensure an optimized allocation of the necessary resources across 477 the network. 479 * coordinate a number of interrelated resources, often distributed 480 across a number of subordinate domains, and to assure 481 transactional integrity as part of the process [TETT1]. 483 * autonomically control of slice life cycle management, including 484 concatenation of slices in each segment of the infrastructure 485 including the data pane, the control plane, and the management 486 plane. 488 * autonomically coordinate and trigger of slice elasticity and 489 placement of logical resources in slices. 491 * coordinates and (re)-configure logical resources in the slice by 492 taking over the control of all the virtualized network functions 493 assigned to the slice. 495 It is also the continuing process of allocating resources to satisfy 496 contending demands in an optimal manner [TETT2]. The idea of optimal 497 would include at least prioritized SLA commitments [SERMODEL], and 498 factors such as customer endpoint location, geographic or topological 499 proximity, delay, aggregate or fine-grained load, monetary cost, 500 fate- sharing or affinity. The word continuing incorporates 501 recognition that the environment and the service demands constantly 502 change over the course of time, so that orchestration is a 503 continuous, multi-dimensional optimization feedback loop [I- 504 D.strassner-anima-control-loops]. 506 It protects the infrastructure from instabilities and side effects 507 due to the presence of many slice components running in parallel. It 508 ensures the proper triggering sequence of slice functionality and 509 their stable operation. It defines conditions/constraints under 510 which service components will be activated, taking into account 511 operator service and network requirements (inclusive of optimize the 512 use of the available network & compute resources and avoid situations 513 that can lead to sub-par performance and even unstable and 514 oscillatory behaviors. 516 5. GRASP Resource Reservation / Release Messages flow 518 Inter Slice Physical 519 Slice Element Element Domain Physical 520 Orchestrator Manager Manager Manager Function 521 | | | | | 522 | GRASP Discovery |GRASP Discovery|GRASP Discovery |GRASP Discovery| 523 | -Response | -Response | -Response | -Response | 524 | <-------------->| <------------>| <-----------> | <-----------> | 525 | | | | | 526 | GRASP Request | | | | 527 |Slicing Objective | GRASP Request | | | 528 | -------------> | Slicing | | | 529 | | Objectives | GRASP Request | | 530 | | ------------> | Slicing |GRASP Request | 531 | | | Objectives |Slicing | 532 | | | -----------> |Objectives | 533 | | | |-----------> | 534 | | | GRASP | | 535 | | | Confirm-Waiting | | 536 | | | <--------- | | 537 | |GRASP | | | 538 | |Confirm-Waiting| |GRASP | 539 | | <----------- | |Negotiation | 540 | | | |Single/Multiple| 541 | | |GRASP Negotiation|Rounds | 542 | | |Single/Multiple |<-----------> | 543 | | |Rounds | | 544 | GRASP | | <-----------> | | 545 | Confirm-Waiting | | | | 546 |<--------------- |GRASP | | | 547 | |Negotiation | | | 548 | |Single/Multiple| | | 549 | |Rounds | | | 550 |GRASP Negotiation | <-----------> | | | 551 |Single/Multiple | | | | 552 |Rounds | | | | 553 | <------------> | | | | 554 Figure 2 - GRASP: Network Slice reservation / Release3 Messages Flow 556 The above message sequence figure shows the message flows of the 557 interactions between Inter-Slice Orchestrator, Slice Element Manager, 558 Physical Element Manager, Domain Manager and Physical Network 559 functions. 561 6. The Autonomic Network Slicing Element 563 This section describes an autonomic slice network element and its 564 internal architecture. The reference model explained in the document 565 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 566 the sources of information that an autonomic service agent can 567 leverage: Self-management, Self-knowledge, network knowledge (through 568 discovery), Intent [I-D.du-anima-an-intent], and feedback loops. 569 Fundamentally, there are two levels inside an autonomic node: the 570 level of Autonomic Service Agents, and the level of the Autonomic 571 Slice Networking Infrastructure, with the former using the services 572 of the latter. The self management functionality (self-configuration, 573 self-optimisation, self- healing) could be implemented across the 574 Inter Slice Orchestrator, Slice Element Manager and Physical Element 575 Manager. Such functionality deals with dynamic 577 * coordination the life cycle of slices 579 * allocation of resources to slice instances in an efficient way 580 that provides required slice instances performance, 582 * Service lifecycle, that is typically different than slice 583 instance lifecycle should also be managed in the autonomous way. 584 * self-configuration, self-optimization and self-healing of 585 services of each slice instance. Service lifecycle, that is 586 typically different than slice instance lifecycle should also be 587 managed in the autonomous way. 589 Figure 3 illustrates this concept. 591 +------------------------------------------------------------+ 592 | | 593 | +-----------+ +------------+ +------------+ | 594 | | Autonomic | | Autonomic | | Autonomic | | 595 | | Service | | Service | | Service | | 596 | | Agent 1 | | Agent 2 | | Agent 3 | | 597 | +-----------+ +------------+ +------------+ | 598 | ^ ^ ^ | 599 | - - -| - - API level - - | - - - - - - - - - - |- - - - - | 600 | V V V | 601 |------------------------------------------------------------| 602 | Autonomic Slice Networking Infrastructure | 603 | - Service characteristics (ultra-low latency, | 604 | ultra-reliability, etc) | 605 | - Autonomic Control Plane functions | 606 | - Autonomic Management Plane functions | 607 | - Self-x functions and related control loops elements | 608 | - Autonomic Slice Addressing | 609 | Discovery, negotiation and synchronisation functions | 610 | - Intent distribution | 611 | - Aggregated reporting and feedback loops | 612 | - Routing | 613 | - Security mechanisms | 614 |------------------------------------------------------------| 615 | Basic Operating System Functions | 616 +------------------------------------------------------------+ 617 Figure 3: Model of an autonomic element 619 The Autonomic Slice Networking Infrastructure (lower part of Figure 620 3) contains slice specific data structures, for example trust 621 information about itself and its peers, as well as a generic set of 622 functions, independent of a particular usage. This infrastructure 623 should be generic, and support a variety of Autonomic Service Agents 624 (upper part of Figure 3). The Autonomic Control Plane is the summary 625 of all interactions of the Autonomic Slice Networking Infrastructure 626 with other services. 628 The use cases of "Autonomics" such as self-management, self- 629 optimisation, etc, are implemented as Autonomic Service Agents. They 630 use the services and data structures of the underlying autonomic 631 networking infrastructure. The Autonomic Slice Networking 632 Infrastructure should itself be self-managing. 634 The "Basic Operating System Functions" include the "normal OS", 635 including the network stack, security functions, etc. Autonomic 636 Network Slicing Element is a composition of autonomic slice service 637 agents and autonomic slice control. Autonomic slice service agents 638 obtain specific network resources and provide self-managing and self- 639 controlling functions. An autonomic slice control is a higher-level 640 autonomic function that takes the role of life-cycle management of a 641 or many slice instances. There can be many slice control functions 642 based on different types or attributes of slice. 644 7. The Autonomic Slice Networking Infrastructure 646 The Autonomic Networking Infrastructure provides a layer of common 647 functionality across an Autonomic Network. It comprises "must 648 implement" functions and services, as well as extensions. The 649 Autonomic Slice Networking Infrastructure (ASNI) resides on top of an 650 abstraction layer of resource, network function and network 651 infrastructure as shown in figure 1. The document assumes 652 abstraction layer enables different autonomous service agents to 653 communicate with the underlying disaggregated and distributed network 654 infrastructure, which itself maybe an autonomous networking (AN) 655 domain or combination of multiple AN domain. The goal of ASNI is to 656 provide autonomic life-cycle management of network slices. 658 7.1. Signaling Between Autonomic Slice Element Managers 660 The basic network capabilities are autonomically or through 661 traditional techniques are learnt by slice agents. This depends on 662 the fact that physical infrastructure is an autonomic network or not. 663 The GASP extensions signaling [I-D.liu-anima-grasp-distribution] 664 [I-D.liu-anima-grasp-api] [I-D.ietf-anima-grasp] may be used for 666 * Discovery of SEMs - a process by which an one SEM discovers 667 peers according to a specific discovery objective. The 668 discovered SEMs peers may later be used as negotiation 669 counterparts or as sources of other coordination activities. 671 * Negotiation between SEMs - a process by which two SEMs interact 672 to agree on slice logical resource settings that best satisfies 673 the objectives of both SEMs. 675 * The Synchronization between SEMs - a process by which 676 Orchestrator and SEMs interact to receive the current state of 677 capability exposure values used at a given time in other SEM. 678 This is a special case of negotiation in which information is 679 sent but the SEM or Orchestrator do not request their peers to 680 change configuration settings. 682 * Self configuration of SEMs - a process by which Orchestrator and 683 SEMs interact to receive the current state of capability 684 exposure values used at a given time in other SEM. This is a 685 special case of synchronization in which information is sent and 686 the SEM is requesting their peers to change configuration 687 settings. 689 * Self optimization of SEMs - a process by which Orchestrator and 690 SEMs interact to receive the current state of capability 691 exposure values used at a given time in other SEMs. This is a 692 special case of configuration in which information is sent and 693 the SEM is requesting their peers to change logical resource 694 settings in a slice based on an optimisation criteria. 696 * Mediation for slice resources - a process by which two SEMs 697 interact to agree to logically move resources between slices 698 that best satisfy the objectives of both SEMs triggering of 699 slice elasticity and placement of logical resources in slices. 700 This is a special case of negotiation in which information is 701 sent Orchestrator do request SEMs to change logical resource 702 configuration settings. 704 * Triggering and governing of elasticity ? a process for autonomic 705 scaling intent configuration mechanisms and resources on the 706 slice level; it allows rapid provisioning, automatic scaling 707 out, or in, of resources. Scale in/out criteria might be used 708 for network autonomics in order the controller to react to a 709 certain set of variations in monitored slices. 711 * Providing on-demand a self-service network slicing. 713 Optionally, SSA capabilities are more interesting to slice control 714 autonomic functions for slice creation and install. The slice control 715 must have the independent intelligence to process and filter 716 capabilities to meet a network slice specification and have low level 717 resources allocated for a slice through SSAs. 719 7.2. The Autonomic Control Plane 721 TBD. 723 7.3. Naming & Addressing 725 A slice can be instantiated on demand, represents a logical network 726 and therefore, must be assigned a unique identifier. A Slice Service 727 Agent (SSA) may support functions of a single or multiple slices and 728 communicate with each other, using the addressing of the Autonomic or 729 traditional (non-autonomic) Networking Infrastructure reside on. An 730 SSA complies with ACP addressing mechanisms and in a domain, i.e., As 731 part of the enrolment process the registrar assigns a number to the 732 device, which is unique for slicing registrar and in ASNI domain. 734 7.4. Discovery 736 Slices themselves are not discovered but are instantiated through 737 slice control autonomic function. However, both slice service agents 738 and slice control functions must be discovered. Even though 739 autonomic control plane will support discovery of all the SSAs and 740 slice control, it may not be necessary. 742 7.5. Routing 744 Autonomic network slicing follows single routing protocol as 745 described in [I-D.ietf-anima-autonomic-control-plane]. 747 8. Security and Trust Infrastructure 749 An Autonomic Slice Network is self-protecting. All protocols are 750 secure by default, without the requirement for the administrator to 751 explicitly configure security. 753 TBD. 755 8.1. Public Key Infrastructure 757 An autonomic domain uses a PKI model. The root of trust is a 758 certification authority (CA). A registrar acts as a registration 759 authority (RA). 761 A minimum implementation of an autonomic domain contains one CA, one 762 Registrar, and network elements. 764 8.2. Domain Certificate 766 TBD. 768 9. Cross-Domain Functionality 770 TBD. 772 10. Autonomic Service Agents (ASA) 774 This section describes how autonomic services run on top of the 775 Autonomic Slice Networking Infrastructure. There are at least two 776 different types of autonomic functions are known: 778 1. Slice Service Agents are low level functions that learn 779 capabilities of underlying infrastructure in terms of interfaces 780 and available resources. They coordinate with Slice control to 781 associate these resources with specific slice instances in 782 effect performing full life cycle management of these resources. 783 2. Slice Control Autonomic Function: Slice control is responsible 784 for high-level life-cycle management of a slice itself. This 785 function will hold slice instances and their attributes related 786 data structures in autonomic network slice infrastructure. As 787 an example, a slice is defined for high bandwidth, highly secure 788 transactional application. A slice control must be capable of 789 negotiating resources required across different SSAs. 791 Out of scope are details of the mechanisms how the information is 792 represented and exchanged between the two autonomic functions. 794 11. Management and Programmability 796 This section describes how an Autonomic Network is managed, and 797 programmed. 799 11.1. How a Slice Network Is Managed 801 Slice autonomic management is driven by Slice Element Managers, 802 there are five categories operation: 804 1. Creating a network slice: Receive a network slice resource 805 description request, upon successful negotiation with SSA 806 allocate resource for it. 807 2. Shrink/Expand slice network: Dynamically alter resource 808 requirements for a running slice network according service load. 809 3. (Re-)Configure slice network: The slice management user deploys 810 a user level service into the slice. The slice control takes 811 over the control of all the virtualized network functions and 812 network programmability functions assigned to the slice, and 813 (re-)configure them as appropriate to provide the end-to-end 814 service. 815 5. Self-X slice operation: namely self-configuration, self- 816 composition, self-monitoring, self-optimisation, self-elasticity 817 would be carried out as part of new slice protocols. 819 11.2. Intent 821 TBD. 823 11.3. Control Loops 825 TBD. 827 11.4. APIs 829 The API model of for autonomic slicing semantically, is grouped into 830 the following APIs to be defined. 832 11.4.1. Slice Control APIs 834 1. Create a slice network on user request. The request includes 835 resource description. A unique identify a slice network, group 836 all the resource. 837 2. Destroy a slice network identified by it's uuid. 838 3. Query a slice network slicing state by its uuid. 839 4. Modify a slice network. 841 11.4.2. Service Agent - Device APIs 843 A service agent will interface with the physical infrastructure 844 either through an autonomic network or traditional infrastructure. 845 Depending upon which a device can either have autonomic or non- 846 autonomic addressing. Service agents are required to perform life 847 cycle management of network elements participating in a network slice 848 and the following APIs are needed for addition, removal or update of 849 a specific device. A device may be a logical or physical network 850 element. Optionally, it may be a network function. 852 11.4.3. Service Agent - Port APIs 853 A port may be a physical or logical network port in a slice depending 854 upon whether underlying infrastructure is an autonomic or traditional 855 network. Service agents must be able to control the operational 856 state of these ports. APIs are needed for addition, removal, update 857 and operational state retrieval of a specific port. 859 11.4.4. Service Agent - Link APIs 861 A link connects two or more ports of devices described in above 862 section. Service agents must be able to control the operational and 863 connection status of these links through APIs for addition, removal, 864 update and state retrieval for each link. 866 11.5. Relationship with MANO 868 Please refer to [MANO] for MANO introduction. 870 12. Security Considerations 872 12.1. Threat Analysis 874 TBD. 876 12.2. Security Mechanisms 878 TBD. 880 13. IANA Considerations 882 This document requests no action by IANA. 884 14. Acknowledgements 886 This document was produced using the xml2rfc tool [RFC2629]. 888 14. References 890 14.1. Normative References 892 [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A 893 Generic Autonomic Signaling Protocol (GRASP)", draft-ietf- 894 anima- grasp-10 (work in progress), March 2017. 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, DOI 898 10.17487/RFC2119, March 1997, . 901 [RFC7665] Halpern, J., Pignataro, C., "Service Function Chaining 902 (SFC) Architecture", October 2015 903 . 905 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 906 10.17487/RFC2629, June 1999, . 909 14.2. Informative References 911 [ChinaCom09] "A. Galis et all - "Management and Service-aware 912 Networking Architectures (MANA) for Future Internet" - 913 Invited paper IEEE 2009 Fourth International Conference on 914 Communications and Networking in China (ChinaCom09) 26-28 915 August 2009, Xi'an, China, 916 .". 918 [GENI] "GENI Key Concepts" - Global Environment for Network 919 Innovations (GENI) 920 .". 922 [I-D.du-anima-an-intent] Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., 923 and M. Behringer, "ANIMA Intent Policy and Format", draft- 924 du- anima-an-intent-04 (work in progress), July 2016. 926 [I-D.ietf-anima-autonomic-control-plane] Behringer, M., Eckert, T., 927 and S. Bjarnason, "An Autonomic Control Plane", draft- 928 ietf-anima-autonomic-control- plane-03 (work in progress), 929 July 2016. 931 [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., 932 Eckert, T., Ciavaglia, L., Pierre, P., Liu, B., Nobre, J., 933 and J. Strassner, "A Reference Model for Autonomic 934 Networking", draft-ietf- anima-reference-model-02 (work in 935 progress), July 2016. 937 [I-D.liu-anima-grasp-api] Carpenter, B., Liu, B., Wang, W., and X. 938 Gong, "Generic Autonomic Signaling Protocol Application 939 Program Interface (GRASP API)", draft-liu-anima-grasp-api- 940 02 (work in progress), September 2016. 942 [I-D.liu-anima-grasp-distribution] Liu, B. and S. Jiang, "Information 943 Distribution over GRASP", draft-liu-anima-grasp- 944 distribution-02 (work in progress), September 2016. 946 [I-D.strassner-anima-control-loops] Strassner, J., Halpern, J., and 947 M. Behringer, "The Use of Control Loops in Autonomic 948 Networking", draft-strassner- anima-control-loops-01 (work 949 in progress), April 2016. 951 [IMT2020] "ITU-T IMT2020 document "Report on Gap Analysis" - ITU-T 952 IMT2020 ITU- Dec 2015 Published by ITU-T IMT2020. 953 .". 956 [MANO] "ETSI European Telecommunications Standards Institute. 957 Network Functions Virtualisation (NFV); Management and 958 Orchestration v1.1.1. Website, December 2014. 959 .". 962 [NGMN] "Hedmar,P., Mschner, K., et all - NGMN Alliance document 963 "Description of Network Slicing Concept", January 2016. 964 .". 967 [NGS-3GPP] "Study on Architecture for Next Generation System" - 968 latest version v1.0.2 September 2016 969 .". 972 [ONF] "Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 973 M., Lopes, D., Kaippallimalit, J., - Open Network 974 Fundation document "Applying SDN Architecture to 5G 975 Slicing", April 2016. 976 .". 980 [NS1] "L. Geng, J. Dong, S. Bryant, K., Makhijani, A., Galis, X. 981 de Foy, S. Kuklinski, - Network Slicing Architecture, July 982 2017. .". 985 [NS2] "L. Geng, L. Wang, S. Kuklinski, L. Qiang, S. Matsushima, 986 A., Galis, L. Contreras - Problem Statement of Supervised 987 Heterogeneous Network Slicing - October 2017 988 .". 991 [ASN] "A., Galis, K., Makhijani, D. Yu, B. Liu - Autonomic Slice 992 Networking-Requirements and Reference Model - May 2017 < 993 https://datatracker.ietf.org/doc/draft-galis-anima- 994 autonomic-slice-networking/>.". 996 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 997 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 998 Networking: Definitions and Design Goals", RFC 7575, DOI 999 10.17487/RFC7575, June 2015, . 1002 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1003 Analysis for Autonomic Networking", RFC 7576, DOI 1004 10.17487/RFC7576, July 2016, . 1007 [TETT1] Guerzoni, R., Vaishnavi, I., Pares-Caparros, D., Galis, 1008 A., et all "Analysis of End-to-End Multi Domain Management 1009 and Orchestration Frameworks for Software Defined 1010 Infrastructures: an Architectural Survey", Transactions on 1011 Emerging Telecommunications Technologies, Wiley Online 1012 Library, DOI: 10.1002/ett.3103, June 2016, 1013 . 1015 [TETT2] Karl, H., Draxler, S., Peuster, M, Galis, A., et all 1016 "DevOps for Network Function Virtualization: An 1017 Architectural Approach", Transactions on Emerging 1018 Telecommunications Technologies Wiley Online Library, DOI: 1019 10.1002/ett.3084, July 2016, 1020 . 1022 [SERMODEL] C., Borman, B. Carpenter, B., Liu, "Service Models 1023 Explained draft-wu-opsawg-service-model-explained-05 1024 . 1027 [5GNS] Galis, A. (UCL), Chih-Lin I (China Mobile) - "Towards 5G 1028 Network Slicing - Motivations and Challenges" March 2017, 1029 < IEEE 5G Tech Focus, Volume 1, Number 1, March 2017- 1030 http://5g.ieee.org/tech-focus/march-2017#networkslicing>. 1032 Authors' Addresses 1034 Alex Galis (editor) 1035 University College London 1036 Department of Electronic and Electrical Engineering 1037 Torrington Place 1038 London WC1E 7JE 1039 United Kingdom 1041 Email: a.galis@ucl.ac.uk 1043 Kiran Makhijani 1044 Huawei Technologies 1045 2890, Central Expressway 1046 Santa Clara CA 95032 1047 USA 1049 Email: USA Email: kiran.makhijani@huawei.com 1051 Delei Yu 1052 Huawei Technologies 1053 Q22, Huawei Campus 1054 No.156 Beiqing Road 1055 Hai-Dian District, Beijing 100095 1056 P.R. China 1058 Email: yudelei@huawei.com 1060 Bing Liu 1061 Huawei Technologies Co., Ltd 1062 Q14, Huawei Campus 1063 No.156 Beiqing Road 1064 Hai-Dian District, Beijing 100095 1065 P.R. China 1067 Email: leo.liubing@huawei.com