idnits 2.17.1 draft-galis-anima-autonomic-slice-networking-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 6) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 125 instances of too long lines in the document, the longest one being 119 characters 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 432 has weird spacing: '...mically co-or...' == Line 626 has weird spacing: '...f slice elast...' == Line 631 has weird spacing: '...uration mecha...' == Line 726 has weird spacing: '...tonomic manag...' -- The document date (March 30, 2017) is 2576 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) == Unused Reference: 'RFC2119' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-reference-model' is defined on line 870, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-10 ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-05) exists of draft-du-anima-an-intent-04 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-03 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-02 == 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 == Outdated reference: A later version (-06) exists of draft-wu-opsawg-service-model-explained-05 Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). 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 17, 2017 D. Yu 6 B. Liu 7 Huawei Technologies 8 March 30, 2017 10 Autonomic Slice Networking-Requirements and Reference Model 11 draft-galis-anima-autonomic-slice-networking-02 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 18 define how 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 17, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The Network Slicing Overall View . . . . . . . . . . . . . . 3 59 2.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. High Level Requirements . . . . . . . . . . . . . . . . . 4 61 2.3. Key Terms and Definitions . . . . . . . . . . . . . . . . 6 62 3. Autonomic Slice Networking . . . . . . . . . . . . . . . . . 7 63 4. Autonomic Inter-Slices Orchestration. . . . . . . . . . . . . 9 64 5. Resource Reservation / Release Messages flow . . . . . . . . 10 65 6. The Autonomic Network Slicing Element . . . . . . . . . . . . 10 66 7. The Autonomic Slice Networking Infrastructure . . . . . . . . 12 67 7.1. Signaling Between Autonomic Slice Capability Exposures . 12 68 7.2. The Autonomic Control Plane . . . . . . . . . . . . . . . 13 69 7.3. Naming & Addressing . . . . . . . . . . . . . . . . . . . 13 70 7.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.6. Intent . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. Security and Trust Infrastructure . . . . . . . . . . . . . . 14 74 8.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 14 75 8.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 14 76 9. Cross-Domain Functionality . . . . . . . . . . . . . . . . . 14 77 10. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 14 78 11. Management and Programmability . . . . . . . . . . . . . . . 14 79 11.1. How a Slice Network Is Managed . . . . . . . . . . . . . 14 80 11.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 11.3. Control Loops . . . . . . . . . . . . . . . . . . . . . 15 82 11.4. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 11.4.1. Slice Control APIs . . . . . . . . . . . . . . . . . 15 84 11.4.2. Service Agent - Device APIs . . . . . . . . . . . . 15 85 11.4.3. Service Agent - Port APIs . . . . . . . . . . . . . 16 86 11.4.4. Service Agent - Link APIs . . . . . . . . . . . . . 16 87 11.5. Relationship with MANO . . . . . . . . . . . . . . . . . 16 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 12.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . 16 90 12.2. Security Mechanisms . . . . . . . . . . . . . . . . . . 16 91 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 15.2. Informative References . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 The document "Autonomic Networking - Definitions and Design Goals" 101 [RFC7575] explains the fundamental concepts behind Autonomic 102 Networking, and defines the relevant terms in this space, as well as 103 a high level reference model. This document defines this reference 104 model with more detail, to allow for functional and protocol 105 specifications to be developed in an architecturally consistent, non- 106 overlapping manner. While the document is written as generally as 107 possible, the initial solutions are limited to the chartered scope of 108 the WG. 110 Most networks will run with some autonomic functions for the full 111 networks or for a group of nodes [RFC7576] or for a group of slice 112 networks while the rest of the network is traditionally managed. 114 The goal of this document is to focus on the autonomic slicing 115 networking. [RFC7575] is focusing on fully or partially autonomic 116 nodes or networks. 118 The proposed revised ANIMA reference model allows for this hybrid 119 approach across all such capabilities. 121 This is a living document and will evolve with the technical 122 solutions developed in the ANIMA WG. Sections marked with (*) do not 123 represent current charter items. 125 While this document must give a long term architectural view, not all 126 functions will be standardized at the same time. 128 2. The Network Slicing Overall View 130 2.1. Context 132 Network Slicing is end-to-end concept covering the radio and non- 133 radio networks inclusive of access, core and edge / enterprise 134 networks. It enables the concurrent deployment of multiple logical, 135 self-contained and independent shared or partitioned networks on a 136 common infrastructure platform. 138 Network Slicing (NS) refers to the managed partitions of physical and/or 139 virtual network resources, network physical/virtual and service functions 140 [RFC7665] that can act as an independent instance of a connectivity network 141 and/or as a network cloud. Network resources include connectivity, compute, 142 and storage resources. 144 From a business point of view, a slice includes combination of all relevant 145 network resources / functions / assets required to fulfill a specific 146 business case or service, including OSS, BSS and DevOpsprocesses. 148 From the network infrastructure point of view, slicing instances 149 require the partitioning and assignment of a set of resources that 150 can be used in an isolated, disjunctive or non- disjunctive manner. 152 Examples of physical or virtual resources to be shared or partitioned 153 would include: bandwidth on a network link, forwarding tables in a 154 network element (switch, router), processing capacity of servers, 155 processing capacity of network or network clouds elements [SLICING]. 156 As such slice instances would contain: 158 (i) a combination/group of the above resources which can act as a 159 network, 161 (ii) appropriate resource abstractions, 163 (iii) capability exposure of abstract resources towards service and 164 management clients that are needed for the operation of slices 166 The capability exposure creates an abstraction of physical network 167 devices that would provide information and information models allowing 168 operators to manipulate the network resources. By utilizing open 169 programmable network interfaces, it would enable access to control layer 170 by customer interfaces and applications. 172 The establishment of slices is both business-driven (i.e. slices are 173 in support for different types and service characteristics and 174 business cases) and technology-driven as slice is a grouping of 175 physical or virtual) resources (network, compute, storage) which can 176 act as a sub network and/or a cloud. A slice can accommodate service 177 components and network functions (physical or virtual) in all network 178 segments: access, core and edge / enterprise networks. 180 A complete slice is composed of not only various network functions 181 which are based on virtual machines at C-RAN and C-Core, but also 182 transport network resources which can be assigned to the slice at 183 radio access/transport network. Different future businesses require 184 different throughput, delay and mobility, and some businesses need 185 very high throughput or/and low delay. 187 2.2. High Level Requirements 189 Slice creation: management plane create virtual or physical network 190 functions and connects them as appropriate and instantiate them in 191 the slice, which is a subnetworks. 193 The instance of slice management then takes over the management and 194 operations of all the (virtualised) network functions and network 195 programmability functions assigned to the slice, and (re-)configure 196 them as appropriate to provide the end-to-end service. 198 A complete slice is composed of not only various network functions 199 which are based on virtual machines at C-RAN and C-Core, but also 200 transport network resources which can be assigned to the slice at 201 radio access/transport network. Different future businesses require 202 different throughput, delay and mobility, and some businesses need 203 very high throughput or/and low delay. Transport network shall 204 provide QoS isolation, flexible network operation and management, and 205 improve network utilization among different business. 207 QoS Isolation: Although traditional VPN technology can provide 208 physical network resource isolation across multiple network segments, 209 it is deemed far less capable of supporting QoS hard isolation, Which 210 means QoS isolation on forwarding plane requires better coordination 211 with management plane. 213 Independent Management Plane: Like above, network isolation is not 214 sufficient, a flexible and more importantly a management plane per 215 instance is required to operate on a slice independently and 216 autonomously within the constraints of resources allocated to the 217 slice. 219 Another flexibility requirement is that an operator can deploy their 220 new business application or a service in network slice with low cost 221 and high speed, and ensure that it does not affect existing of 222 business applications adversely. 224 Programmability: Operator not only can slice a common physical 225 infrastructure into different logical networks to meet all kinds of 226 new business requirements, but also can use SDN based technology to 227 improve the overall network utilization. By providing a flexible 228 programmable interface; the 3rd party can develop and deploy new 229 network business rapidly. Further, if a network slicing can run with 230 its own slice controller, this network slicing will get more granular 231 control capability [I-D.ietf-anima-autonomic-control-plane] to retrieve 232 slice status, and issuing slicing flow table, statistics fetch etc. 234 Life cycle self-management: It includes creation, operations, re- 235 configuration, composition, decomposition, deletion of slices. It 236 would be performed automatically, without human intervention and 237 based on a governance configurable model of the operators. As such 238 protocols for slice set-up /operations /(de)composition / deletion 239 must also work completely automatically. Self-management (i.e. self- 240 configuration, self-composition, self-monitoring, self-optimisation, 241 self-elasticity) is carried as part of the slice protocol 242 characterization. 244 Extensibility: Since the Autonomic Slice Networking Infrastructure is 245 a relatively new concept, it is likely that changes in the way of 246 operation will happen over time. As such new networking functions 247 will be introduced later, which allow changes to the way the slices 248 operate. 250 Transport network shall provide QoS isolation, flexible network 251 operation and management, and improve network utilization among 252 different business. 254 The flexibility behind the slice concept needs to address QoS 255 guarantee on the transport network and enable network openness. 257 Other considerations and requirements: TBD. 259 2.3. Key Terms and Definitions 261 A number of slice definitions were used in the last 10 years in 262 distributed and federated testbed research [GENI], future internet 263 research [ChinaCom09] and more recently in the context of 5G research 264 [NGMN], [ONF], [IMT2020], [NGS-3GPP].A unified Slice definition usable 265 in the context of Autonomic Networking consist of 4 components: 267 o Service Instance component, 269 o Network Slice Instance component, 271 o Resources component and 273 o Slice Element Manager component 275 The Service Instance component represents the end-user service or 276 business services which are to be supported. It is an instance of an 277 end-user service or a business service that is realized within or by 278 a Network Slice. Each service is represented by a Service Instance. 279 Services and service instances would be provided by the network 280 operator or by 3rd parties. 282 A Network Slice Instance component is represented by a set of network 283 functions, and resources to run these network functions, forming a 284 complete instantiated logical network to meet certain network 285 characteristics required by the Service Instance(s). It provides the 286 network characteristics which are required by a Service Instance. A 287 Network Slice Instance may also be shared across multiple Service 288 Instances provided by the network operator. The Network Slice 289 Instance may be composed by none, one or more Sub-network Instances, 290 which may be shared by another Network Slice Instance. 292 The ability to partition of network resources and functions would be 293 beneficial to Network and Service providers. It would improve the 294 efficiency of network resource & functions and provides a mechanism 295 and an approach for Network and Service Providers to offer resource 296 flexibility for services. 298 Slice Element Manager (SEM) is installed for each control domain. 299 Control domain is defined according to geographic location and control 300 functions. Each SEM converts requirements from orchestrator into virtual 301 resources and manages virtual resources of a slice. SEM also exchanges 302 information of virtual resources with other slice element managers via 303 a dedicated resource interface. SEM provides also capability exposure 304 facilities by allowing 3rd parties to access / use via APIs information 305 regarding services provided by the slice (e.g. connectivity information, 306 QoS, mobility, autonomicity, etc.) and to dynamically customize the network 307 characteristics for different diverse use cases (e.g. ultra-low latency, 308 ultra- reliability, value-added services forenterprises, etc.) within the 309 limits set of functions by the operator. 311 It includes a description of the structure (and contained components) and 312 configuration of the slice instance. Physical Element Manager (PEM) is 313 installed for each control domain. Control domain is defined according to 314 geographic location and control functions. PEM exchanges information of 315 virtual resource with SEM via virtual resource interface and interconverts 316 between virtual resource and physical resource. The PEM orders physical 317 functions (ex. switches) to allocate physical resource via physical 318 resource interface. 320 Logical resource - An independently manageable partition of a 321 physical resource, which inherits the same characteristics as the 322 physical resource and whose capability is bound to the capability of 323 the physical resource. It is dedicated to a Network Function or 324 shared between a set of Network Functions. 326 Virtual resource - An abstraction of a physical or logical resource, 327 which may have different characteristics from that resource, and 328 whose capability may not be bound to the capability of that resource. 330 Network Function - It refers to processing functions in a network. 331 This includes but is not limited to telecom nodes functionality, as 332 well as switching functions e.g. switching function, IP routing 333 functions. 335 Virtual Network Function - One or more virtual machines running 336 different software and processes on top of high-volume servers, 337 switches and storage, or cloud computing infrastructure, and capable 338 of implementing network functions traditionally implemented via 339 custom hardware appliances and middleboxes (e.g. router, NAT, 340 firewall, load balancer, etc.). 342 3. Autonomic Slice Networking 344 This section describes the various elements in a network with 345 autonomic functions, and how these entities work together, on a high 346 level. Subsequent sections explain the detailed inside view for each 347 of the autonomic network elements, as well as the network functions 348 (or interfaces) between those elements. 350 One expected autonomic Slice Networking function is the capability and 351 resource Usability for a slice. Applications or services requiring 352 information of available slice capabilities and resources are satisfied 353 by abstracted resource view and control. Usability of capabilities and 354 resources can be enabled either by resource publishing or by discovery. 355 In the latter case, the service performs resource collection directly 356 from the provider of the slice by using discovery mechanisms to get total 357 information about the available resources to be consumed. In the former, 358 the network provider exposes available resources to services (e.g., through 359 a resource catalog) reducing the amount of detail of the underlying network. 361 Figure 1 shows the high level view of an Autonomic Slice Networking. 362 It consists of a number of autonomic nodes resources, which interact 363 directly with each other. Those autonomic nodes resources provide a 364 common set of capabilities across a network slice, called the 365 "Autonomic Slice Networking Infrastructure" (ASNI). The ASNI 366 provides functions like naming, addressing, negotiation, synchronization, 367 discovery and messaging. 369 Autonomic network functions typically span several slices in the 370 network. The atomic entities of an autonomic function are called the 371 "Autonomic Service Agents" (ASA), which are instantiated on slices. 372 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 373 : : Autonomic Slice Function 1 : : 374 : SSA 1 : SSA 1 : SSA 1 : SSA 1 : 375 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 376 : : : 377 : +- - - - - - - - - - - - - - + : 378 : : Autonomic Slice Function 2 : : 379 : : ASC 2 : ASC 2 : : 380 : +- - - - - - - - - - - - - - + : 381 : : : 382 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 383 : Autonomic Slice Networking Infrastructure : 384 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 385 + + 386 + + -----------------------------------+ + 387 + | Autonomic Inter-Slice Orchestration| + 388 + +------------------------------------+ + 389 + | | | + 390 +----------+ +-----------+ +----------+ 391 |Slice 1 | |Slice 2 | | Slice N | 392 | SEM |-------| SEM |------ ... ---- | SEM | 393 | | | | | | 394 +----------+ +-----------+ +----------+ 395 | | | 396 +-------------------------------------------------------------+ 397 | | 398 | PEC1 PEC2 PECm | 399 | | ... | ... | | 400 | | 401 | Resources / Network Functions / ANI | 402 | | 403 +-------------------------------------------------------------+ 404 | | | | 405 +--------+ : +--------+ : +--------+ : +--------+ 406 | Node 1 |------| Node 2 |------| Node 3 |----...----| Node n | 407 +--------+ : +--------+ : +--------+ : +--------+ 409 Figure 1: High level view of Autonomic Slice Networking 411 In a horizontal view, autonomic functions span across the network, as 412 well as the Autonomic Slice Networking Infrastructure. In a vertical 413 view, a slice always implements the ASNI, plus it may have one or 414 several Autonomic Service Agents as part of slice capability 415 exposure. The Autonomic Networking Infrastructure (ASNI) therefore is the 416 foundation for autonomic functions. The current charter of the ANIMA 417 WG includes the specification of the ASNI, using a few autonomic 418 functions as use cases. ASNI would represent a customized and an 419 approach [I-D.ietf-anima-reference-model]for implementing a general 420 purposed ASI . 422 Additionally, at least 2 autonomous functions are envisioned - 423 Autonomous Slice control (ASC) and Slice Service agent (SSA). These 424 are explained in sections below. 426 4. Autonomic Inter-Slice Orchestration 428 This section describes an autonomic orchestration and its functionality. 430 Orchestration refers to the system functions that 432 * automated and autonomically co-ordination of network functions in slices 434 * autonomically coordinate the slices lifecycle and all the components that 435 are part of the slice (i.e. Service Instances, Network Slice Instances, Resources, 436 Capabilities exposure) to ensure an optimized allocation of the necessary resources 437 across the network. 439 * coordinate a number of interrelated resources, often distributed across a number of 440 subordinate domains, and to assure transactional integrity as part of the process 441 [TETT1]. 443 * autonomically control of slice life cycle management, including concatenation of 444 slices in each segment of the infrastructure including the data pane, the control 445 plane, and the management plane. 447 * autonomically coordinate and trigger of slice elasticity and placement of 448 logical resources in slices. 450 * coordinates and (re)-configure logical resources in the slice by taking over 451 the control of all the virtualized network functions assigned to the slice. 453 It is also the continuing process of allocating resources to satisfy 454 contending demands in an optimal manner [TETT2]. The idea of optimal would 455 include at least prioritized SLA commitments [SERMODEL],and factors such as 456 customer endpoint location, geographic or topological proximity, 457 delay, aggregate or fine-grained load, monetary cost, fate- sharing 458 or affinity. The word continuing incorporates recognition that the 459 environment and the service demands constantly change over the course 460 of time, so that orchestration is a continuous, multi-dimensional 461 optimization feedback loop [I-D.strassner-anima-control-loops]. 463 It protects the infrastructure from instabilities and side effects 464 due to the presence of many slice components running in parallel. It 465 ensures the proper triggering sequence of slice functionality and 466 their stable operation. It defines conditions/constraints under 467 which service components will be activated, taking into account 468 operator service and network requirements (inclusive of optimize the 469 use of the available network & compute resources and avoid situations 470 that can lead to sub-par performance and even unstable and 471 oscillatory behaviors. 473 5. Resource Reservation / Release Messages flow 475 Inter Slice Slice Element Physical Element Physical 476 Orchestrator Manager Manager Function 478 | | | | 479 | GRASP Discovery | GRASP Discovery | GRASP Discovery | 480 | -Response | -Response | -Response | 481 | <--------------> | <---------------> | <---------------> | 482 | | | | 483 | | | | 484 | GRASP Request | | | 485 |Slicing Objective | | | 486 | ----------------> | GRASP Request | | 487 | | Slicing Objective | | 488 | | --------------> | GRASP Request | 489 | | | Slicing Objective | 490 | | GRASP | --------------> | 491 | | Confirm-Waiting | | 492 | | <--------------- | | 493 | | | GRASP Negotiation | 494 | | |(Single/Multiple Rounds)| 495 | GRASP | | <---------------> | 496 | Confirm-Waiting | | | 497 |<----------------- | | | 498 | | GRASP Negotiation | | 499 | |Single/Multiple Rounds| | 500 |GRASP Negotiation | <---------------> | | 501 |Single/Multiple Rounds| | | 502 |<----------------> | | | 504 The above message sequence figure shows the message flows of the interactions between Inter-Slice Orchestrator, Slice Element Manager, Physical Element Manager and Physical Network functions. 506 6. The Autonomic Network Slicing Element 508 This section describes an autonomic slice network element and its 509 internal architecture. The reference model explained in the document 510 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 511 the sources of information that an autonomic service agent can 512 leverage: Self-knowledge, network knowledge (through discovery), 513 Intent [I-D.du-anima-an-intent], and feedback loops. Fundamentally, 514 there are two levels inside an autonomic node: the level of 515 Autonomic Service Agents, and the level of the Autonomic Slice 516 Networking Infrastructure, with the former using the services of 517 the latter. 519 Figure 2 illustrates this concept. 521 +------------------------------------------------------------+ 522 | | 523 | +-----------+ +------------+ +------------+ | 524 | | Autonomic | | Autonomic | | Autonomic | | 525 | | Service | | Service | | Service | | 526 | | Agent 1 | | Agent 2 | | Agent 3 | | 527 | +-----------+ +------------+ +------------+ | 528 | ^ ^ ^ | 529 | - - -| - - API level - - | - - - - - - - - - - |- - - - - | 530 | V V V | 531 |------------------------------------------------------------| 532 | Autonomic Slice Networking Infrastructure | 533 | - Service characteristics (ultra-low latency, | 534 | ultra-reliability, etc) | 535 | - Autonomic Control Plane functions | 536 | - Autonomic Management Plane functions | 537 | - Self-x functions and related control loops elements | 538 | - Autonomic Slice Addressing | 539 | Discovery, negotiation and synchronisation functions | 540 | - Intent distribution | 541 | - Aggregated reporting and feedback loops | 542 | - Routing | 543 | - Security mechanisms | 544 |------------------------------------------------------------| 545 | Basic Operating System Functions | 546 +------------------------------------------------------------+ 548 Figure 2: Model of an autonomic element 550 The Autonomic Slice Networking Infrastructure (lower part of 551 Figure 2) contains slice specific data structures, for example trust 552 information about itself and its peers, as well as a generic set of 553 functions, independent of a particular usage. This infrastructure 554 should be generic, and support a variety of Autonomic Service Agents 555 (upper part of Figure 2). The Autonomic Control Plane is the summary 556 of all interactions of the Autonomic Slice Networking Infrastructure 557 with other services. 559 The use cases of "Autonomics" such as self-management, self-optimisation, 560 etc, are implemented as Autonomic Service Agents. They 561 use the services and data structures of the underlying autonomic 562 networking infrastructure. The Autonomic Slice Networking 563 Infrastructure should itself be self-managing. 565 The "Basic Operating System Functions" include the "normal OS", 566 including the network stack, security functions, etc. Autonomic 567 Network Slicing Element is a composition of autonomic slice service 568 agents and autonomic slice control. Autonomic slice service agents 569 obtain specific network resources and provide self-managing and self- 570 controlling functions. An autonomic slice control is a higher-level 571 autonomic function that takes the role of life-cycle management of a 572 or many slice instances. There can be many slice control functions 573 based on different types or attributes of slice. 575 7. The Autonomic Slice Networking Infrastructure 577 The Autonomic Networking Infrastructure provides a layer of common 578 functionality across an Autonomic Network. It comprises "must 579 implement" functions and services, as well as extensions. The 580 Autonomic Slice Networking Infrastructure (ASNI) resides on top of an 581 abstraction layer of resource, network function and network 582 infrastructure as shown in figure 1. The document assumes 583 abstraction layer enables different autonomous service agents to 584 communicate with the underlying disaggregated and distributed network 585 infrastructure, which itself maybe an autonomous networking (AN) 586 domain or combination of multiple AN domain. The goal of ASNI is to 587 provide autonomic life-cycle management of network slices. 589 7.1. Signaling Between Autonomic Slice Element Managers 591 The basic network capabilities are autonomically or through 592 traditional techniques are learnt by slice agents. This depends on 593 the fact that physical infrastructure is an autonomic network or not. 594 The GASP extensions signaling [I-D.liu-anima-grasp-distribution] 595 [I-D.liu-anima-grasp-api] [I-D.ietf-anima-grasp] may be used to 597 GRASP Use Case Requirements: 599 * Discovery of SEMs - a process by which an one SEM discovers peers according to a 600 specific discovery objective. The discovered SEMs peers may later be used as 601 negotiation counterparts or as sources of other coordination activities. 603 * Negotiation between SEMs - a process by which two SEMs interact to agree on slice 604 logical resource settings that best satisfy the objectives of both SEMs. 606 * Synchronization between SEMs - a process by which Orchestrator and SEMs interact to 607 receive the current state of capability exposure values used at a given time in other 608 SEM. This is a special case of negotiation in which information is sent but the SEM 609 or Orchestrator do not request their peers to change configuration settings. 611 * Self configuration of SEMs - a process by which Orchestrator and SEMs interact to 612 receive the current state of capability exposure values used at a given time in other 613 SEM. This is a special case of synchronization in which information is sent and the 614 SEM is requesting their peers to change configuration settings. 616 GASP Extensions Use Case Requirements: 618 * Self optimization of SEMs - a process by which Orchestrator and SEMs interact to 619 receive the current state of capability exposure values used at a given time in other 620 SEMs. This is a special case of configuration in which information is sent and the SEM 621 is requesting their peers to change logical resource settings in a slice based on an 622 optimisation criteria. 624 * Mediation for slice resources - a process by which two SEMs interact to agree to 625 logically move resources between slices that best satisfy the objectives of both SEMs 626 triggering of slice elasticity and placement of logical resources in slices. This is a 627 special case of negotiation in which information is sent Orchestrator do request SEMs to 628 change logical resource configuration settings. 630 * Triggering and governing of elasticity ?a process for autonomic scaling intent 631 configuration mechanism and resources on the slice level; it allows rapid provisioning, 632 automatic scaling out, or in, of resources. Scale in/out criteria might be used for network 633 autonomics in order the controller to react to a certain set of variations in monitored slices. 635 * Providing on-demand a self-service network slicing. Optionally, SSA capabilities are more 636 interesting to slice control autonomic functions for slice creation and install. 637 The slice control must have the independent intelligence to process and filter capabilities 638 to meet a network slice specification and have low level resources allocated for a slice 639 through SSAs. 641 7.2. The Autonomic Control Plane 643 TBD. 644 7.3. Naming & Addressing 646 A slice can be instantiated on demand, represents a logical network 647 and therefore, must be assigned a unique identifier. A Slice Service 648 Agent (SSA) may support functions of a single or multiple slices and 649 communicate with each other, using the addressing of the Autonomic or 650 traditional (non-autonomic) Networking Infrastructure reside on. An 652 SSA complies with ACP addressing mechanisms and in a domain, i.e., As 653 part of the enrolment process the registrar assigns a number to the 654 device, which is unique for slicing registrar and in ASNI domain. 656 7.4. Discovery 658 Slices themselves are not discovered but are instantiated through 659 slice control autonomic function. However, both slice service agents 660 and slice control functions must be discovered. Even though 661 autonomic control plane will support discovery of all the SSAs and 662 slice control, it may not be necessary. 664 7.5. Routing 666 Autonomic network slicing follows single routing protocol as 667 described in [I-D.ietf-anima-autonomic-control-plane]. 669 7.6. Intent 671 TBD. 673 8. Security and Trust Infrastructure 675 An Autonomic Slice Network is self-protecting. All protocols are 676 secure by default, without the requirement for the administrator to 677 explicitly configure security. 679 TBD. 680 8.1. Public Key Infrastructure 682 An autonomic domain uses a PKI model. The root of trust is a 683 certification authority (CA). A registrar acts as a registration 684 authority (RA). 686 A minimum implementation of an autonomic domain contains one CA, one 687 Registrar, and network elements. 689 8.2. Domain Certificate 691 TBD. 692 9. Cross-Domain Functionality 694 TBD. 696 10. Autonomic Service Agents (ASA) 698 This section describes how autonomic services run on top of the 699 Autonomic Slice Networking Infrastructure. There are at least two 700 different types of autonomic functions are known: 702 1. Slice Service Agents are low level functions that learn 703 capabilities of underlying infrastructure in terms of interfaces 704 and available resources. They coordinate with Slice control to 705 associate these resources with specific slice instances in effect 706 performing full life cycle management of these resources. 708 2. Slice Control Autonomic Function: Slice control is responsible 709 for high-level life-cycle management of a slice itself. This 710 function will hold slice instances and their attributes related 711 data structures in autonomic network slice infrastructure. As an 712 example, a slice is defined for high bandwidth, highly secure 713 transactional application. A slice control must be capable of 714 negotiating resources required across different SSAs. 716 Out of scope are details of the mechanisms how the information is 717 represented and exchanged between the two autonomic functions. 719 11. Management and Programmability 721 This section describes how an Autonomic Network is managed, and 722 programmed. 724 11.1. How a Slice Network Is Managed 726 Slice autonomic management is driven by Slice Element Managers, there are 727 five categories operation: 729 1. Creating a network slice: Receive a network slice resource 730 description request, upon successful negotiation with SSA 731 allocate resource for it. 733 2. Shrink/Expand slice network: Dynamically alter resource 734 requirements for a running slice network according service load. 736 3. (Re-)Configure slice network: The slice management user deploys a 737 user level service into the slice. The slice control takes over 738 the control of all the virtualized network functions and network 739 programmability functions assigned to the slice, and 740 (re-)configure them as appropriate to provide the end-to-end 741 service. 743 5. Self-X slice operation: namely self-configuration, self-composition, 744 self-monitoring, self-optimisation, self-elasticity would be carried out 745 as part of new slice protocols. 747 11.2. Intent 749 TBD. 751 11.3. Control Loops 753 TBD. 755 11.4. APIs 757 The API model of for autonomic slicing semantically, is grouped into 758 the following APIs to be defined. 760 11.4.1. Slice Control APIs 762 1. Create a slice network on user request. The request includes 763 resource description. A unique identify a slice network, group 764 all the resource. 766 2. Destroy a slice network identified by it's id. 768 3. Query a slice network slicing state by it's uuid. 770 4. Modify a slice network. 772 11.4.2. Service Agent - Device APIs 774 A service agent will interface with the physical infrastructure 775 either through an autonomic network or traditional infrastructure. 776 Depending upon which a device can either have autonomic or non- 777 autonomic addressing. 779 Service agents are required to perform life 780 cycle management of network elements participating in a network slice 781 and the following APIs are needed for addition, removal or update of 782 a specific device. A device may be a logical or physical network 783 element. Optionally, it may be a network function. 785 11.4.3. Service Agent - Port APIs 787 A port may be a physical or logical network port in a slice depending 788 upon whether underlying infrastructure is an autonomic or traditional 789 network. Service agents must be able to control the operational 790 state of these ports. APIs are needed for addition, removal, update 791 and operational state retrieval of a specific port. 793 11.4.4. Service Agent - Link APIs 795 A link connects two or more ports of devices described in above 796 section. Service agents must be able to control the operational and 797 connection status of these links through APIs for addition, removal, 798 update and state retrieval for each link. 800 11.5. Relationship with MANO 802 Please refer to [MANO] for MANO introduction. 804 TBD. 806 12. Security Considerations 808 12.1. Threat Analysis 810 TBD. 812 12.2. Security Mechanisms 814 TBD. 816 13. IANA Considerations 818 This document requests no action by IANA. 820 14. Acknowledgements 822 This document was produced using the xml2rfc tool [RFC2629]. 824 14. References 826 14.1. Normative References 828 [I-D.ietf-anima-grasp] 829 Bormann, C., Carpenter, B., and B. Liu, "A Generic 830 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 831 grasp-10 (work in progress), March 2017. 833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, 835 DOI 10.17487/RFC2119, March 1997, 836 . 838 [RFC7665] Halpern, J., Pignataro, C., "Service Function Chaining (SFC) 839 Architecture", October 2015 840 . 842 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 843 DOI 10.17487/RFC2629, June 1999, 844 . 846 14.2. Informative References 848 [ChinaCom09] 849 "A. Galis et all - "Management and Service-aware 850 Networking Architectures (MANA) for Future Internet" - 851 Invited paper IEEE 2009 Fourth International Conference on 852 Communications and Networking in China (ChinaCom09) 26-28 853 August 2009, Xi'an, China, 854 .". 856 [GENI] ""GENI Key Concepts" - Global Environment for Network 857 Innovations (GENI) 858 .". 860 [I-D.du-anima-an-intent] 861 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 862 Behringer, "ANIMA Intent Policy and Format", draft-du- 863 anima-an-intent-04 (work in progress), July 2016. 865 [I-D.ietf-anima-autonomic-control-plane] 866 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 867 Control Plane", draft-ietf-anima-autonomic-control- 868 plane-03 (work in progress), July 2016. 870 [I-D.ietf-anima-reference-model] 871 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 872 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 873 Reference Model for Autonomic Networking", draft-ietf- 874 anima-reference-model-02 (work in progress), July 2016. 876 [I-D.liu-anima-grasp-api] 877 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 878 Autonomic Signaling Protocol Application Program Interface 879 (GRASP API)", draft-liu-anima-grasp-api-02 (work in 880 progress), September 2016. 882 [I-D.liu-anima-grasp-distribution] 883 Liu, B. and S. Jiang, "Information Distribution over 884 GRASP", draft-liu-anima-grasp-distribution-02 (work in 885 progress), September 2016. 887 [I-D.strassner-anima-control-loops] 888 Strassner, J., Halpern, J., and M. Behringer, "The Use of 889 Control Loops in Autonomic Networking", draft-strassner- 890 anima-control-loops-01 (work in progress), April 2016. 892 [IMT2020] "ITU-T IMT2020 document "Report on Gap Analysis" - ITU-T 893 IMT2020 ITU- Dec 2015 Published by ITU-T IMT2020. 894 .". 897 [MANO] "ETSI European Telecommunications Standards Institute. 898 Network Functions Virtualisation (NFV); Management and 899 Orchestration v1.1.1. Website, December 2014. 900 .". 903 [NGMN] "Hedmar,P., Mschner, K., et all - NGMN Alliance document 904 "Description of Network Slicing Concept", January 2016. 905 .". 908 [NGS-3GPP] 909 ""Study on Architecture for Next Generation System" - 910 latest version v1.0.2 September 2016 911 .". 914 [ONF] "Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 915 M., Lopes, D., Kaippallimalit, J., - Open Network 916 Fundation document "Applying SDN Architecture to 5G 917 Slicing", April 2016. 918 .". 922 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 923 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 924 Networking: Definitions and Design Goals", RFC 7575, 925 DOI 10.17487/RFC7575, June 2015, 926 . 928 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 929 Analysis for Autonomic Networking", RFC 7576, 930 DOI 10.17487/RFC7576, July 2016, 931 . 933 [TETT1] Guerzoni, R., Vaishnavi, I., Pez-Caparros, D., Galis, A., et all 934 "Analysis of End-to-End Multi Domain Management and Orchestration 935 Frameworks for Software Defined Infrastructures: an Architectural 936 Survey", Transactions on Emerging Telecommunications Technologies, 937 Wiley Online Library, DOI: 10.1002/ett.3103, June 2016, 938 . 940 [TETT2] Karl, H., Draxler, S., Peuster, M, Galis, A., et all "DevOps for 941 Network Function Virtualization: An Architectural Approach", 942 Transactions on Emerging Telecommunications Technologies, 943 Wiley Online Library, DOI: 10.1002/ett.3084, July 2016, 944 . 946 [SERMODEL] C., Borman, B. Carpenter, B., Liu, "Service Models Explained 947 draft-wu-opsawg-service-model-explained-05 948 . 950 [SLICING] A., Galis, J., Dong, K., Makhijani, M., Boucadair, P. Martinez-Julia, 951 Network Slicing - Introductory Document and Revised Problem Statement - 952 February 2017, draft-gdmb-netslices-intro-and-ps-02 953 955 Authors' Addresses 957 Alex Galis (editor) 958 University College London 959 Department of Electronic and Electrical Engineering 960 Torrington Place 961 London WC1E 7JE 962 United Kingdom 964 Email: a.galis@ucl.ac.uk 966 Kiran Makhijani 967 Huawei Technologies 968 2890, Central Expressway 969 Santa Clara CA 95032 970 USA 972 Email: USA Email: kiran.makhijani@huawei.com 974 Delei Yu 975 Huawei Technologies 976 Q22, Huawei Campus 977 No.156 Beiqing Road 978 Hai-Dian District, Beijing 100095 979 P.R. China 981 Email: yudelei@huawei.com 983 Bing Liu (editor) 984 Huawei Technologies Co., Ltd 985 Q14, Huawei Campus 986 No.156 Beiqing Road 987 Hai-Dian District, Beijing 100095 988 P.R. China 990 Email: leo.liubing@huawei.com