idnits 2.17.1 draft-galis-anima-autonomic-slice-networking-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2733 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: 'I-D.ietf-anima-grasp' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-reference-model' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-anima-grasp-api' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-anima-grasp-distribution' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'I-D.strassner-anima-control-loops' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC7576' is defined on line 799, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-08 ** 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 Summary: 1 error (**), 0 flaws (~~), 15 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 4, 2017 D. Yu 6 Huawei Technologies 7 October 31, 2016 9 Autonomic Slice Networking-Requirements and Reference Model 10 draft-galis-anima-autonomic-slice-networking-00 12 Abstract 14 This document describes the technical requirements and the related 15 reference model for the intercommunication and coordination among 16 devices in Slicing Autonomic Slicing Networking. The goal is to 17 define how the various elements in a network slicing context work and 18 orchestrate together, to describe their interfaces and relations. 19 While the document is written as generally as possible, the initial 20 solutions are limited to the chartered scope of the WG. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 4, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. The Network Slicing Overall View . . . . . . . . . . . . . . 3 58 2.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. High Level Requirements . . . . . . . . . . . . . . . . . 4 60 2.3. Key Terms and Definitions . . . . . . . . . . . . . . . . 6 61 3. Autonomic Slice Networking . . . . . . . . . . . . . . . . . 7 62 4. Autonomic Orchestration (*) . . . . . . . . . . . . . . . . . 9 63 5. The Autonomic Network Slicing Element . . . . . . . . . . . . 9 64 6. The Autonomic Slice Networking Infrastructure . . . . . . . . 11 65 6.1. Signaling Between Autonomic Slice Capability Exposures . 11 66 6.2. The Autonomic Control Plane . . . . . . . . . . . . . . . 11 67 6.3. Naming & Addressing . . . . . . . . . . . . . . . . . . . 11 68 6.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.6. Intent . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. Security and Trust Infrastructure . . . . . . . . . . . . . . 12 72 7.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 73 7.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 74 8. Cross-Domain Functionality . . . . . . . . . . . . . . . . . 12 75 9. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 13 76 10. Management and Programmability . . . . . . . . . . . . . . . 13 77 10.1. How a Slice Network Is Managed . . . . . . . . . . . . . 13 78 10.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.3. Control Loops . . . . . . . . . . . . . . . . . . . . . 14 80 10.4. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 10.4.1. Slice Control APIs . . . . . . . . . . . . . . . . . 14 82 10.4.2. Service Agent - Device APIs . . . . . . . . . . . . 14 83 10.4.3. Service Agent - Port APIs . . . . . . . . . . . . . 14 84 10.4.4. Service Agent - Link APIs . . . . . . . . . . . . . 15 85 10.5. Relationship with MANO . . . . . . . . . . . . . . . . . 15 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 11.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . 15 88 11.2. Security Mechanisms . . . . . . . . . . . . . . . . . . 15 89 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 14.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 The document "Autonomic Networking - Definitions and Design Goals" 99 [RFC7575] explains the fundamental concepts behind Autonomic 100 Networking, and defines the relevant terms in this space, as well as 101 a high level reference model. This document defines this reference 102 model with more detail, to allow for functional and protocol 103 specifications to be developed in an architecturally consistent, non- 104 overlapping manner. While the document is written as generally as 105 possible, the initial solutions are limited to the chartered scope of 106 the WG. 108 Most networks will run with some autonomic functions for the full 109 networks or for a group of nodes or for a group of slice networks 110 while the rest of the network is traditionally managed. 112 The goal of this document is to focus on the autonomic slicing 113 networking. [RFC7575] is focusing on fully or partially autonomic 114 nodes or networks. 116 The proposed revised ANIMA reference model allows for this hybrid 117 approach across all such capabilities. 119 This is a living document and will evolve with the technical 120 solutions developed in the ANIMA WG. Sections marked with (*) do not 121 represent current charter items. 123 While this document must give a long term architectural view, not all 124 functions will be standardized at the same time. 126 2. The Network Slicing Overall View 128 2.1. Context 130 Network Slicing is end-to-end concept covering the radio and non- 131 radio networks inclusive of access, core and edge / enterprise 132 networks. It enables the concurrent deployment of multiple logical, 133 self-contained and independent shared or partitioned networks on a 134 common infrastructure platform. 136 From a business point of view, a slice includes combination of all 137 relevant network resources / functions / assets required to fulfill a 138 specific business case or service, including OSS, BSS and DevOps 139 processes. 141 From the network infrastructure point of view, slicing instances 142 require the partitioning and assignment of a set of resources that 143 can be used in an isolated, disjunctive or non- disjunctive manner. 145 Examples of physical or virtual resources to be shared or partitioned 146 would include: bandwidth on a network link, forwarding tables in a 147 network element (switch, router), processing capacity of servers, 148 processing capacity of network or network clouds elements. As such 149 slice instances would contain: 151 (i) a combination/group of the above resources which can act as a 152 network, 154 (ii) appropriate resource abstractions, 156 (iii) exposure of abstract resources towards service and 157 management clients that are needed for the operation of slices 159 The establishment of slices is both business-driven (i.e. slices are 160 in support for different types and service characteristics and 161 business cases) and technology-driven as slice is a grouping of 162 physical or virtual) resources (network, compute, storage) which can 163 act as a sub network and/or a cloud. A slice can accommodate service 164 components and network functions (physical or virtual) in all network 165 segments: access, core and edge / enterprise networks. 167 A complete slice is composed of not only various network functions 168 which are based on virtual machines at C-RAN and C-Core, but also 169 transport network resources which can be assigned to the slice at 170 radio access/transport network. Different future businesses require 171 different throughput, delay and mobility, and some businesses need 172 very high throughput or/and low delay. 174 2.2. High Level Requirements 176 Slice creation: management plane create virtual or physical network 177 functions and connects them as appropriate and instantiate them in 178 the slice. 180 The instance of slice management then takes over the management and 181 operations of all the (virtualised) network functions and network 182 programmability functions assigned to the slice, and (re-)configure 183 them as appropriate to provide the end-to-end service. 185 A complete slice is composed of not only various network functions 186 which are based on virtual machines at C-RAN and C-Core, but also 187 transport network resources which can be assigned to the slice at 188 radio access/transport network. Different future businesses require 189 different throughput, delay and mobility, and some businesses need 190 very high throughput or/and low delay. Transport network shall 191 provide QoS isolation, flexible network operation and management, and 192 improve network utilization among different business. 194 QoS Isolation: Although traditional VPN technology can provide 195 physical network resource isolation across multiple network segments, 196 it is deemed far less capable of supporting QoS hard isolation, Which 197 means QoS isolation on forwarding plane requires better coordination 198 with management plane. 200 Independent Management Plane: Like above, network isolation is not 201 sufficient, a flexible and more importantly a management plane per 202 instance is required to operate on a slice independently and 203 autonomously within the constraints of resources allocated to the 204 slice. 206 Another flexibility requirement is that an operator can deploy their 207 new business application or a service in network slice with low cost 208 and high speed, and ensure that it does not affect existing of 209 business applications adversely. 211 Programmability: Operator not only can slice a common physical 212 infrastructure into different logical networks to meet all kinds of 213 new business requirements, but also can use SDN based technology to 214 improve the overall network utilization. By providing a flexible 215 programmable interface; the 3rd party can develop and deploy new 216 network business rapidly. Further, if a network slicing can run with 217 its own slice controller, this network slicing will get more granular 218 control capability to retrieve slice status, and issuing slicing flow 219 table, statistics fetch etc. 221 Life cycle self-management: It includes creation, operations, re- 222 configuration, composition, decomposition, deletion of slices. It 223 would be performed automatically, without human intervention and 224 based on a governance configurable model of the operators. As such 225 protocols for slice set-up /operations /(de)composition / deletion 226 must also work completely automatically. Self-management (i.e. self- 227 configuration, self-composition, self-monitoring, self-optimisation, 228 self-elasticity) is carried as part of the slice protocol 229 characterization. 231 Extensibility: Since the Autonomic Slice Networking Infrastructure is 232 a relatively new concept, it is likely that changes in the way of 233 operation will happen over time. As such new networking functions 234 will be introduced later, which allow changes to the way the slices 235 operate. 237 Transport network shall provide QoS isolation, flexible network 238 operation and management, and improve network utilization among 239 different business. 241 The flexibility behind the slice concept needs to address QoS 242 guarantee on the transport network and enable network openness. 244 Other considerations and requirements: TBD. 246 2.3. Key Terms and Definitions 248 A number of slice definitions were used in the last 10 years in 249 distributed and federated testbed research [GENI], future internet 250 research [ChinaCom09] and more recently in the context of 5G research 251 [NGMN], [ONF], [IMT2020], [NGS-3GPP]. 253 A unified Slice definition usable in the context of Autonomic 254 Networking consist of 4 components: 256 o Service Instance component, 258 o Network Slice Instance component, 260 o Resources component and 262 o Slice Capability exposure component 264 The Service Instance component represents the end-user service or 265 business services which are to be supported. It is an instance of an 266 end-user service or a business service that is realized within or by 267 a Network Slice. Each service is represented by a Service Instance. 268 Services and service instances would be provided by the network 269 operator or by 3rd parties. 271 A Network Slice Instance component is represented by a set of network 272 functions, and resources to run these network functions, forming a 273 complete instantiated logical network to meet certain network 274 characteristics required by the Service Instance(s). It provides the 275 network characteristics which are required by a Service Instance. A 276 Network Slice Instance may also be shared across multiple Service 277 Instances provided by the network operator. The Network Slice 278 Instance may be composed by none, one or more Sub-network Instances, 279 which may be shared by another Network Slice Instance. 281 Slice Capability exposure component is allowing 3rd parties to access 282 / use via APIs information regarding services provided by the slice 283 (e.g. connectivity information, QoS, mobility, autonomicity, etc.) 284 and to dynamically customize the network characteristics for 285 different diverse use cases (e.g. ultra-low latency, ultra- 286 reliability, value-added services for enterprises, etc.) within the 287 limits set of functions by the operator. It includes a description 288 of the structure (and contained components) and configuration of the 289 slice instance. 291 Logical resource - An independently manageable partition of a 292 physical resource, which inherits the same characteristics as the 293 physical resource and whose capability is bound to the capability of 294 the physical resource. It is dedicated to a Network Function or 295 shared between a set of Network Functions. 297 Virtual resource - An abstraction of a physical or logical resource, 298 which may have different characteristics from that resource, and 299 whose capability may not be bound to the capability of that resource. 301 Network Function - It refers to processing functions in a network. 302 This includes but is not limited to telecom nodes functionality, as 303 well as switching functions e.g. switching function, IP routing 304 functions. 306 Virtual Network Function - One or more virtual machines running 307 different software and processes on top of high-volume servers, 308 switches and storage, or cloud computing infrastructure, and capable 309 of implementing network functions traditionally implemented via 310 custom hardware appliances and middleboxes (e.g. router, NAT, 311 firewall, load balancer, etc.). 313 3. Autonomic Slice Networking 315 This section describes the various elements in a network with 316 autonomic functions, and how these entities work together, on a high 317 level. Subsequent sections explain the detailed inside view for each 318 of the autonomic network elements, as well as the network functions 319 (or interfaces) between those elements. 321 Figure 1 shows the high level view of an Autonomic Slice Networking. 323 It consists of a number of autonomic nodes resources, which interact 324 directly with each other. Those autonomic nodes resources provide a 325 common set of capabilities across a network slice, called the 326 "Autonomic Slice Networking Infrastructure" (ASNI). The ASNI 327 provides functions like naming, addressing, negotiation, 328 synchronization, discovery and messaging. 330 Autonomic network functions typically span several slices in the 331 network. The atomic entities of an autonomic function are called the 332 "Autonomic Service Agents" (ASA), which are instantiated on slices. 334 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 335 : : Autonomic Slice Function 1 : : 336 : SSA 1 : SSA 1 : SSA 1 : SSA 1 : 337 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 338 : : : 339 : +- - - - - - - - - - - - - - + : 340 : : Autonomic Slice Function 2 : : 341 : : ASC 2 : ASC 2 : : 342 : +- - - - - - - - - - - - - - + : 343 : : : 344 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 345 : Autonomic Slice Networking Infrastructure : 346 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 347 + + 348 + + --------------------------------+ + 349 + | Autonomic Orchestration | + 350 + +---------------------------------+ + 351 + | | | + 352 +----------+ +-----------+ +----------+ 353 |Slice 1 | |Slice 2 | | Slice N | 354 |Capability| ------|Capability | ------ ... ----|Capability| 355 |Exposure | |Exposure | |Exposure | 356 +----------+ +-----------+ +----------+ 357 | | | 358 +-------------------------------------------------------------+ 359 | | 360 | Resources / Network Functions / Network Infrastructure | 361 | | 362 +-------------------------------------------------------------+ 363 | | | | 364 +--------+ : +--------+ : +--------+ : +--------+ 365 | Node 1 |------| Node 2 |------| Node 3 |----...----| Node n | 366 +--------+ : +--------+ : +--------+ : +--------+ 368 Figure 1: High level view of Autonomic Slice Networking 370 In a horizontal view, autonomic functions span across the network, as 371 well as the Autonomic Slice Networking Infrastructure. In a vertical 372 view, a slice always implements the ASNI, plus it may have one or 373 several Autonomic Service Agents as part of slice capability 374 exposure. 376 The Autonomic Networking Infrastructure (ASNI) therefore is the 377 foundation for autonomic functions. The current charter of the ANIMA 378 WG includes the specification of the ASNI, using a few autonomic 379 functions as use cases. ASNI would represent a customized and an 380 approach for implementing a general purposed ASI. 382 Additionally, at least 2 autonomous functions are envisioned - 383 Autonomous Slice control (ASC) and Slice Service agent (SSA). These 384 are explained in sections below. 386 4. Autonomic Orchestration (*) 388 This section describes an autonomic orchestration and its 389 functionality. 391 Orchestration refers to the functions that autonomically coordinate 392 the slices lifecycle and all the components that are part of the 393 slice (i.e. Service Instances, Network Slice Instances, Resources, 394 Capabilities exposure) to ensure an optimized allocation of the 395 necessary resources across the network. It is expected to coordinate 396 a number of interrelated resources, often distributed across a number 397 of subordinate domains, and to assure transactional integrity as part 398 of the process. 400 It is also the continuing process of allocating resources to satisfy 401 contending demands in an optimal manner. The idea of optimal would 402 include at least prioritized SLA commitments, and factors such as 403 customer endpoint location, geographic or topological proximity, 404 delay, aggregate or fine-grained load, monetary cost, fate- sharing 405 or affinity. The word continuing incorporates recognition that the 406 environment and the service demands constantly change over the course 407 of time, so that orchestration is a continuous, multi-dimensional 408 optimization feedback loop. 410 It protects the infrastructure from instabilities and side effects 411 due to the presence of many slice components running in parallel. It 412 ensures the proper triggering sequence of slice functionality and 413 their stable operation. It defines conditions/constraints under 414 which service components will be activated, taking into account 415 operator service and network requirements (inclusive of optimize the 416 use of the available network & compute resources and avoid situations 417 that can lead to sub-par performance and even unstable and 418 oscillatory behaviors. 420 5. The Autonomic Network Slicing Element 422 This section describes an autonomic slice network element and its 423 internal architecture. The reference model explained in the document 424 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 425 the sources of information that an autonomic service agent can 426 leverage: Self-knowledge, network knowledge (through discovery), 427 Intent, and feedback loops. Fundamentally, there are two levels 428 inside an autonomic node: the level of Autonomic Service Agents, and 429 the level of the Autonomic Slice Networking Infrastructure, with the 430 former using the services of the latter. 432 Figure 2 illustrates this concept. 434 +------------------------------------------------------------+ 435 | | 436 | +-----------+ +------------+ +------------+ | 437 | | Autonomic | | Autonomic | | Autonomic | | 438 | | Service | | Service | | Service | | 439 | | Agent 1 | | Agent 2 | | Agent 3 | | 440 | +-----------+ +------------+ +------------+ | 441 | ^ ^ ^ | 442 | - - -| - - API level - - | - - - - - - - - - - |- - - - - | 443 | V V V | 444 |------------------------------------------------------------| 445 | Autonomic Slice Networking Infrastructure | 446 | - Service characteristics (ultra-low latency, | 447 | ultra-reliability, etc) | 448 | - Autonomic Control Plane functions | 449 | - Autonomic Management Plane functions | 450 | - Self-x functions and related control loops elements | 451 | - Autonomic Slice Addressing | 452 | Discovery, negotiation and synchronisation functions | 453 | - Intent distribution | 454 | - Aggregated reporting and feedback loops | 455 | - Routing | 456 | - Security mechanisms | 457 |------------------------------------------------------------| 458 | Basic Operating System Functions | 459 +------------------------------------------------------------+ 461 Figure 2: Model of an autonomic element 463 The Autonomic Slice Networking Infrastructure (lower part of 464 Figure 2) contains slice specific data structures, for example trust 465 information about itself and its peers, as well as a generic set of 466 functions, independent of a particular usage. This infrastructure 467 should be generic, and support a variety of Autonomic Service Agents 468 (upper part of Figure 2). The Autonomic Control Plane is the summary 469 of all interactions of the Autonomic Slice Networking Infrastructure 470 with other services. 472 The use cases of "Autonomics" such as self-management, self- 473 optimisation, etc, are implemented as Autonomic Service Agents. They 474 use the services and data structures of the underlying autonomic 475 networking infrastructure. The Autonomic Slice Networking 476 Infrastructure should itself be self-managing. 478 The "Basic Operating System Functions" include the "normal OS", 479 including the network stack, security functions, etc. Autonomic 480 Network Slicing Element is a composition of autonomic slice service 481 agents and autonomic slice control. Autonomic slice service agents 482 obtain specific network resources and provide self-managing and self- 483 controlling functions. An autonomic slice control is a higher-level 484 autonomic function that takes the role of life-cycle management of a 485 or many slice instances. There can be many slice control functions 486 based on different types or attributes of slice. 488 6. The Autonomic Slice Networking Infrastructure 490 The Autonomic Networking Infrastructure provides a layer of common 491 functionality across an Autonomic Network. It comprises "must 492 implement" functions and services, as well as extensions. The 493 Autonomic Slice Networking Infrastructure (ASNI) resides on top of an 494 abstraction layer of resource, network function and network 495 infrastructure as shown in figure 1. The document assumes 496 abstraction layer enables different autonomous service agents to 497 communicate with the underlying disaggregated and distributed network 498 infrastructure, which itself maybe an autonomous networking (AN) 499 domain or combination of multiple AN domain. The goal of ASNI is to 500 provide autonomic life-cycle management of network slices. 502 6.1. Signaling Between Autonomic Slice Capability Exposures 504 The basic network capabilities are autonomically or through 505 traditional techniques are learnt by slice agents. This depends on 506 the fact that physical infrastructure is an autonomic network or not. 507 The GASP signaling may be used to expose capabilities among SSAs or 508 slice control. Optionally, SSA capabilities are more interesting to 509 slice control autonomic functions for slice creation and install. 510 The slice control must have the independent intelligence to process 511 and filter capabilities to meet a network slice specification and 512 have low level resources allocated for a slice through SSAs. 6.2 The 513 Autonomic Control Plane. 515 6.2. The Autonomic Control Plane 517 TBD. 519 6.3. Naming & Addressing 521 A slice can be instantiated on demand, represents a logical network 522 and therefore, must be assigned a unique identifier. A Slice Service 523 Agent (SSA) may support functions of a single or multiple slices and 524 communicate with each other, using the addressing of the Autonomic or 525 traditional (non-autonomic) Networking Infrastructure reside on. An 526 SSA complies with ACP addressing mechanisms and in a domain, i.e., As 527 part of the enrolment process the registrar assigns a number to the 528 device, which is unique for slicing registrar and in ASNI domain. 530 6.4. Discovery 532 Slices themselves are not discovered but are instantiated through 533 slice control autonomic function. However, both slice service agents 534 and slice control functions must be discovered. Even though 535 autonomic control plane will support discovery of all the SSAs and 536 slice control, it may not be necessary. 538 6.5. Routing 540 Autonomic network slicing follows single routing protocol as 541 described in [I-D.ietf-anima-autonomic-control-plane]. 543 6.6. Intent 545 TBD. 547 7. Security and Trust Infrastructure 549 An Autonomic Slice Network is self-protecting. All protocols are 550 secure by default, without the requirement for the administrator to 551 explicitly configure security. 553 TBD. 555 7.1. Public Key Infrastructure 557 An autonomic domain uses a PKI model. The root of trust is a 558 certification authority (CA). A registrar acts as a registration 559 authority (RA). 561 A minimum implementation of an autonomic domain contains one CA, one 562 Registrar, and network elements. 564 7.2. Domain Certificate 566 TBD. 568 8. Cross-Domain Functionality 570 TBD. 572 9. Autonomic Service Agents (ASA) 574 This section describes how autonomic services run on top of the 575 Autonomic Slice Networking Infrastructure. There are at least two 576 different types of autonomic functions are known: 578 1. Slice Service Agents are low level functions that learn 579 capabilities of underlying infrastructure in terms of interfaces 580 and available resources. They coordinate with Slice control to 581 associate these resources with specific slice instances in effect 582 performing full life cycle management of these resources. 584 2. Slice Control Autonomic Function: Slice control is responsible 585 for high-level life-cycle management of a slice itself. This 586 function will hold slice instances and their attributes related 587 data structures in autonomic network slice infrastructure. As an 588 example, a slice is defined for high bandwidth, highly secure 589 transactional application. A slice control must be capable of 590 negotiating resources required across different SSAs. 592 Out of scope are details of the mechanisms how the information is 593 represented and exchanged between the two autonomic functions. 595 10. Management and Programmability 597 This section describes how an Autonomic Network is managed, and 598 programmed. 600 10.1. How a Slice Network Is Managed 602 Slice network management is driven by Slice control, there are four 603 categories operation: 605 1. Creating a network slice: Receive a network slice resource 606 description request, upon successful negotiation with SSA 607 allocate resource for it. 609 2. Shrink/Expand slice network: Dynamically alter resource 610 requirements for a running slice network according service load. 612 3. (Re-)Configure slice network: The slice management user deploys a 613 user level service into the slice. The slice control takes over 614 the control of all the virtualized network functions and network 615 programmability functions assigned to the slice, and 616 (re-)configure them as appropriate to provide the end-to-end 617 service. 619 4. Destroy slice network: Recycle all resource from the 620 infrastructure. 622 10.2. Intent 624 TBD. 626 10.3. Control Loops 628 TBD. 630 10.4. APIs 632 The API model of for autonomic slicing semantically, is grouped into 633 the following APIs to be defined. 635 10.4.1. Slice Control APIs 637 1. Create a slice network on user request. The request includes 638 resource description. A unique identify a slice network, group 639 all the resource. 641 2. Destroy a slice network identified by it's id. 643 3. Query a slice network slicing state by it's uuid. 645 4. Modify a slice network. 647 10.4.2. Service Agent - Device APIs 649 A service agent will interface with the physical infrastructure 650 either through an autonomic network or traditional infrastructure. 651 Depending upon which a device can either have autonomic or non- 652 autonomic addressing. Service agents are required to perform life 653 cycle management of network elements participating in a network slice 654 and the following APIs are needed for addition, removal or update of 655 a specific device. A device may be a logical or physical network 656 element. Optionally, it may be a network function. 658 10.4.3. Service Agent - Port APIs 660 A port may be a physical or logical network port in a slice depending 661 upon whether underlying infrastructure is an autonomic or traditional 662 network. Service agents must be able to control the operational 663 state of these ports. APIs are needed for addition, removal, update 664 and operational state retrieval of a specific port. 666 10.4.4. Service Agent - Link APIs 668 A link connects two or more ports of devices described in above 669 section. Service agents must be able to control the operational and 670 connection status of these links through APIs for addition, removal, 671 update and state retrieval for each link. 673 10.5. Relationship with MANO 675 Please refer to [MANO] for MANO introduction. 677 TBD. 679 11. Security Considerations 681 11.1. Threat Analysis 683 TBD. 685 11.2. Security Mechanisms 687 TBD. 689 12. IANA Considerations 691 This document requests no action by IANA. 693 13. Acknowledgements 695 Thanks Bing Liu for helping editing the draft. 697 This document was produced using the xml2rfc tool [RFC2629]. 699 14. References 701 14.1. Normative References 703 [I-D.ietf-anima-grasp] 704 Bormann, C., Carpenter, B., and B. Liu, "A Generic 705 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 706 grasp-08 (work in progress), October 2016. 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 714 DOI 10.17487/RFC2629, June 1999, 715 . 717 14.2. Informative References 719 [ChinaCom09] 720 "A. Galis et all - "Management and Service-aware 721 Networking Architectures (MANA) for Future Internet" - 722 Invited paper IEEE 2009 Fourth International Conference on 723 Communications and Networking in China (ChinaCom09) 26-28 724 August 2009, Xi'an, China, 725 .". 727 [GENI] ""GENI Key Concepts" - Global Environment for Network 728 Innovations (GENI) 729 .". 731 [I-D.du-anima-an-intent] 732 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 733 Behringer, "ANIMA Intent Policy and Format", draft-du- 734 anima-an-intent-04 (work in progress), July 2016. 736 [I-D.ietf-anima-autonomic-control-plane] 737 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 738 Control Plane", draft-ietf-anima-autonomic-control- 739 plane-03 (work in progress), July 2016. 741 [I-D.ietf-anima-reference-model] 742 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 743 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 744 Reference Model for Autonomic Networking", draft-ietf- 745 anima-reference-model-02 (work in progress), July 2016. 747 [I-D.liu-anima-grasp-api] 748 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 749 Autonomic Signaling Protocol Application Program Interface 750 (GRASP API)", draft-liu-anima-grasp-api-02 (work in 751 progress), September 2016. 753 [I-D.liu-anima-grasp-distribution] 754 Liu, B. and S. Jiang, "Information Distribution over 755 GRASP", draft-liu-anima-grasp-distribution-02 (work in 756 progress), September 2016. 758 [I-D.strassner-anima-control-loops] 759 Strassner, J., Halpern, J., and M. Behringer, "The Use of 760 Control Loops in Autonomic Networking", draft-strassner- 761 anima-control-loops-01 (work in progress), April 2016. 763 [IMT2020] "ITU-T IMT2020 document "Report on Gap Analysis" - ITU-T 764 IMT2020 ITU- Dec 2015 Published by ITU-T IMT2020. 765 .". 768 [MANO] "ETSI European Telecommunications Standards Institute. 769 Network Functions Virtualisation (NFV); Management and 770 Orchestration v1.1.1. Website, December 2014. 771 .". 774 [NGMN] "Hedmar,P., Mschner, K., et all - NGMN Alliance document 775 "Description of Network Slicing Concept", January 2016. 776 .". 779 [NGS-3GPP] 780 ""Study on Architecture for Next Generation System" - 781 latest version v1.0.2 September 2016 782 .". 785 [ONF] "Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 786 M., Lopes, D., Kaippallimalit, J., - Open Network 787 Fundation document "Applying SDN Architecture to 5G 788 Slicing", April 2016. 789 .". 793 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 794 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 795 Networking: Definitions and Design Goals", RFC 7575, 796 DOI 10.17487/RFC7575, June 2015, 797 . 799 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 800 Analysis for Autonomic Networking", RFC 7576, 801 DOI 10.17487/RFC7576, June 2015, 802 . 804 Authors' Addresses 806 Alex Galis 807 University College London 808 Department of Electronic and Electrical Engineering 809 Torrington Place 810 London WC1E 7JE 811 United Kingdom 813 Email: a.galis@ucl.ac.uk 815 Kiran Makhijani 816 Huawei Technologies 817 2890, Central Expressway 818 Santa Clara CA 95032 819 USA 821 Email: USA Email: kiran.makhijani@huawei.com 823 Delei Yu 824 Huawei Technologies 825 Q22, Huawei Campus 826 No.156 Beiqing Road 827 Hai-Dian District, Beijing 100095 828 P.R. China 830 Email: yudelei@huawei.com