idnits 2.17.1 draft-galis-anima-autonomic-slice-networking-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 2734 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 711, but no explicit reference was found in the text == Unused Reference: 'I-D.strassner-anima-control-loops' is defined on line 761, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-07 ** 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 (~~), 9 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-01 12 Abstract 14 This document describes the technical requirements and the related 15 reference model for the intercommunication and coordination among 16 devices in Autonomic Slicing Networking. The goal is to define how 17 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 [RFC7576] or for a group of slice 110 networks 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 [I-D.ietf-anima-autonomic-control-plane] to 219 retrieve slice status, and issuing slicing flow table, statistics 220 fetch etc. 222 Life cycle self-management: It includes creation, operations, re- 223 configuration, composition, decomposition, deletion of slices. It 224 would be performed automatically, without human intervention and 225 based on a governance configurable model of the operators. As such 226 protocols for slice set-up /operations /(de)composition / deletion 227 must also work completely automatically. Self-management (i.e. self- 228 configuration, self-composition, self-monitoring, self-optimisation, 229 self-elasticity) is carried as part of the slice protocol 230 characterization. 232 Extensibility: Since the Autonomic Slice Networking Infrastructure is 233 a relatively new concept, it is likely that changes in the way of 234 operation will happen over time. As such new networking functions 235 will be introduced later, which allow changes to the way the slices 236 operate. 238 Transport network shall provide QoS isolation, flexible network 239 operation and management, and improve network utilization among 240 different business. 242 The flexibility behind the slice concept needs to address QoS 243 guarantee on the transport network and enable network openness. 245 Other considerations and requirements: TBD. 247 2.3. Key Terms and Definitions 249 A number of slice definitions were used in the last 10 years in 250 distributed and federated testbed research [GENI], future internet 251 research [ChinaCom09] and more recently in the context of 5G research 252 [NGMN], [ONF], [IMT2020], [NGS-3GPP]. 254 A unified Slice definition usable in the context of Autonomic 255 Networking consist of 4 components: 257 o Service Instance component, 259 o Network Slice Instance component, 261 o Resources component and 263 o Slice Capability exposure component 265 The Service Instance component represents the end-user service or 266 business services which are to be supported. It is an instance of an 267 end-user service or a business service that is realized within or by 268 a Network Slice. Each service is represented by a Service Instance. 269 Services and service instances would be provided by the network 270 operator or by 3rd parties. 272 A Network Slice Instance component is represented by a set of network 273 functions, and resources to run these network functions, forming a 274 complete instantiated logical network to meet certain network 275 characteristics required by the Service Instance(s). It provides the 276 network characteristics which are required by a Service Instance. A 277 Network Slice Instance may also be shared across multiple Service 278 Instances provided by the network operator. The Network Slice 279 Instance may be composed by none, one or more Sub-network Instances, 280 which may be shared by another Network Slice Instance. 282 Slice Capability exposure component is allowing 3rd parties to access 283 / use via APIs information regarding services provided by the slice 284 (e.g. connectivity information, QoS, mobility, autonomicity, etc.) 285 and to dynamically customize the network characteristics for 286 different diverse use cases (e.g. ultra-low latency, ultra- 287 reliability, value-added services for enterprises, etc.) within the 288 limits set of functions by the operator. It includes a description 289 of the structure (and contained components) and configuration of the 290 slice instance. 292 Logical resource - An independently manageable partition of a 293 physical resource, which inherits the same characteristics as the 294 physical resource and whose capability is bound to the capability of 295 the physical resource. It is dedicated to a Network Function or 296 shared between a set of Network Functions. 298 Virtual resource - An abstraction of a physical or logical resource, 299 which may have different characteristics from that resource, and 300 whose capability may not be bound to the capability of that resource. 302 Network Function - It refers to processing functions in a network. 303 This includes but is not limited to telecom nodes functionality, as 304 well as switching functions e.g. switching function, IP routing 305 functions. 307 Virtual Network Function - One or more virtual machines running 308 different software and processes on top of high-volume servers, 309 switches and storage, or cloud computing infrastructure, and capable 310 of implementing network functions traditionally implemented via 311 custom hardware appliances and middleboxes (e.g. router, NAT, 312 firewall, load balancer, etc.). 314 3. Autonomic Slice Networking 316 This section describes the various elements in a network with 317 autonomic functions, and how these entities work together, on a high 318 level. Subsequent sections explain the detailed inside view for each 319 of the autonomic network elements, as well as the network functions 320 (or interfaces) between those elements. 322 Figure 1 shows the high level view of an Autonomic Slice Networking. 324 It consists of a number of autonomic nodes resources, which interact 325 directly with each other. Those autonomic nodes resources provide a 326 common set of capabilities across a network slice, called the 327 "Autonomic Slice Networking Infrastructure" (ASNI). The ASNI 328 provides functions like naming, addressing, negotiation, 329 synchronization, discovery and messaging. 331 Autonomic network functions typically span several slices in the 332 network. The atomic entities of an autonomic function are called the 333 "Autonomic Service Agents" (ASA), which are instantiated on slices. 335 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 336 : : Autonomic Slice Function 1 : : 337 : SSA 1 : SSA 1 : SSA 1 : SSA 1 : 338 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 339 : : : 340 : +- - - - - - - - - - - - - - + : 341 : : Autonomic Slice Function 2 : : 342 : : ASC 2 : ASC 2 : : 343 : +- - - - - - - - - - - - - - + : 344 : : : 345 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 346 : Autonomic Slice Networking Infrastructure : 347 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ 348 + + 349 + + --------------------------------+ + 350 + | Autonomic Orchestration | + 351 + +---------------------------------+ + 352 + | | | + 353 +----------+ +-----------+ +----------+ 354 |Slice 1 | |Slice 2 | | Slice N | 355 |Capability| ------|Capability | ------ ... ----|Capability| 356 |Exposure | |Exposure | |Exposure | 357 +----------+ +-----------+ +----------+ 358 | | | 359 +-------------------------------------------------------------+ 360 | | 361 | Resources / Network Functions / Network Infrastructure | 362 | | 363 +-------------------------------------------------------------+ 364 | | | | 365 +--------+ : +--------+ : +--------+ : +--------+ 366 | Node 1 |------| Node 2 |------| Node 3 |----...----| Node n | 367 +--------+ : +--------+ : +--------+ : +--------+ 369 Figure 1: High level view of Autonomic Slice Networking 371 In a horizontal view, autonomic functions span across the network, as 372 well as the Autonomic Slice Networking Infrastructure. In a vertical 373 view, a slice always implements the ASNI, plus it may have one or 374 several Autonomic Service Agents as part of slice capability 375 exposure. 377 The Autonomic Networking Infrastructure (ASNI) therefore is the 378 foundation for autonomic functions. The current charter of the ANIMA 379 WG includes the specification of the ASNI, using a few autonomic 380 functions as use cases. ASNI would represent a customized and an 381 approach [I-D.ietf-anima-reference-model] for implementing a general 382 purposed ASI. 384 Additionally, at least 2 autonomous functions are envisioned - 385 Autonomous Slice control (ASC) and Slice Service agent (SSA). These 386 are explained in sections below. 388 4. Autonomic Orchestration (*) 390 This section describes an autonomic orchestration and its 391 functionality. 393 Orchestration refers to the functions that autonomically coordinate 394 the slices lifecycle and all the components that are part of the 395 slice (i.e. Service Instances, Network Slice Instances, Resources, 396 Capabilities exposure) to ensure an optimized allocation of the 397 necessary resources across the network. It is expected to coordinate 398 a number of interrelated resources, often distributed across a number 399 of subordinate domains, and to assure transactional integrity as part 400 of the process [TETT1] . 402 It is also the continuing process of allocating resources to satisfy 403 contending demands in an optimal manner [TETT2] . The idea of optimal 404 would include at least prioritized SLA commitments, and factors such 405 as customer endpoint location, geographic or topological proximity, 406 delay, aggregate or fine-grained load, monetary cost, fate- sharing 407 or affinity. The word continuing incorporates recognition that the 408 environment and the service demands constantly change over the course 409 of time, so that orchestration is a continuous, multi-dimensional 410 optimization feedback loop. 412 It protects the infrastructure from instabilities and side effects 413 due to the presence of many slice components running in parallel. It 414 ensures the proper triggering sequence of slice functionality and 415 their stable operation. It defines conditions/constraints under 416 which service components will be activated, taking into account 417 operator service and network requirements (inclusive of optimize the 418 use of the available network & compute resources and avoid situations 419 that can lead to sub-par performance and even unstable and 420 oscillatory behaviors. 422 5. The Autonomic Network Slicing Element 424 This section describes an autonomic slice network element and its 425 internal architecture. The reference model explained in the document 426 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 427 the sources of information that an autonomic service agent can 428 leverage: Self-knowledge, network knowledge (through discovery), 429 Intent [I-D.du-anima-an-intent] , and feedback loops. Fundamentally, 430 there are two levels inside an autonomic node: the level of Autonomic 431 Service Agents, and the level of the Autonomic Slice Networking 432 Infrastructure, with the former using the services of the latter. 434 Figure 2 illustrates this concept. 436 +------------------------------------------------------------+ 437 | | 438 | +-----------+ +------------+ +------------+ | 439 | | Autonomic | | Autonomic | | Autonomic | | 440 | | Service | | Service | | Service | | 441 | | Agent 1 | | Agent 2 | | Agent 3 | | 442 | +-----------+ +------------+ +------------+ | 443 | ^ ^ ^ | 444 | - - -| - - API level - - | - - - - - - - - - - |- - - - - | 445 | V V V | 446 |------------------------------------------------------------| 447 | Autonomic Slice Networking Infrastructure | 448 | - Service characteristics (ultra-low latency, | 449 | ultra-reliability, etc) | 450 | - Autonomic Control Plane functions | 451 | - Autonomic Management Plane functions | 452 | - Self-x functions and related control loops elements | 453 | - Autonomic Slice Addressing | 454 | Discovery, negotiation and synchronisation functions | 455 | - Intent distribution | 456 | - Aggregated reporting and feedback loops | 457 | - Routing | 458 | - Security mechanisms | 459 |------------------------------------------------------------| 460 | Basic Operating System Functions | 461 +------------------------------------------------------------+ 463 Figure 2: Model of an autonomic element 465 The Autonomic Slice Networking Infrastructure (lower part of 466 Figure 2) contains slice specific data structures, for example trust 467 information about itself and its peers, as well as a generic set of 468 functions, independent of a particular usage. This infrastructure 469 should be generic, and support a variety of Autonomic Service Agents 470 (upper part of Figure 2). The Autonomic Control Plane is the summary 471 of all interactions of the Autonomic Slice Networking Infrastructure 472 with other services. 474 The use cases of "Autonomics" such as self-management, self- 475 optimisation, etc, are implemented as Autonomic Service Agents. They 476 use the services and data structures of the underlying autonomic 477 networking infrastructure. The Autonomic Slice Networking 478 Infrastructure should itself be self-managing. 480 The "Basic Operating System Functions" include the "normal OS", 481 including the network stack, security functions, etc. Autonomic 482 Network Slicing Element is a composition of autonomic slice service 483 agents and autonomic slice control. Autonomic slice service agents 484 obtain specific network resources and provide self-managing and self- 485 controlling functions. An autonomic slice control is a higher-level 486 autonomic function that takes the role of life-cycle management of a 487 or many slice instances. There can be many slice control functions 488 based on different types or attributes of slice. 490 6. The Autonomic Slice Networking Infrastructure 492 The Autonomic Networking Infrastructure provides a layer of common 493 functionality across an Autonomic Network. It comprises "must 494 implement" functions and services, as well as extensions. The 495 Autonomic Slice Networking Infrastructure (ASNI) resides on top of an 496 abstraction layer of resource, network function and network 497 infrastructure as shown in figure 1. The document assumes 498 abstraction layer enables different autonomous service agents to 499 communicate with the underlying disaggregated and distributed network 500 infrastructure, which itself maybe an autonomous networking (AN) 501 domain or combination of multiple AN domain. The goal of ASNI is to 502 provide autonomic life-cycle management of network slices. 504 6.1. Signaling Between Autonomic Slice Capability Exposures 506 The basic network capabilities are autonomically or through 507 traditional techniques are learnt by slice agents. This depends on 508 the fact that physical infrastructure is an autonomic network or not. 509 The GASP signaling [I-D.ietf-anima-grasp] 510 [I-D.liu-anima-grasp-distribution] [I-D.liu-anima-grasp-api] may be 511 used to expose capabilities among SSAs or slice control. Optionally, 512 SSA capabilities are more interesting to slice control autonomic 513 functions for slice creation and install. The slice control must 514 have the independent intelligence to process and filter capabilities 515 to meet a network slice specification and have low level resources 516 allocated for a slice through SSAs. 6.2 The Autonomic Control Plane. 518 6.2. The Autonomic Control Plane 520 TBD. 522 6.3. Naming & Addressing 524 A slice can be instantiated on demand, represents a logical network 525 and therefore, must be assigned a unique identifier. A Slice Service 526 Agent (SSA) may support functions of a single or multiple slices and 527 communicate with each other, using the addressing of the Autonomic or 528 traditional (non-autonomic) Networking Infrastructure reside on. An 529 SSA complies with ACP addressing mechanisms and in a domain, i.e., As 530 part of the enrolment process the registrar assigns a number to the 531 device, which is unique for slicing registrar and in ASNI domain. 533 6.4. Discovery 535 Slices themselves are not discovered but are instantiated through 536 slice control autonomic function. However, both slice service agents 537 and slice control functions must be discovered. Even though 538 autonomic control plane will support discovery of all the SSAs and 539 slice control, it may not be necessary. 541 6.5. Routing 543 Autonomic network slicing follows single routing protocol as 544 described in [I-D.ietf-anima-autonomic-control-plane]. 546 6.6. Intent 548 TBD. 550 7. Security and Trust Infrastructure 552 An Autonomic Slice Network is self-protecting. All protocols are 553 secure by default, without the requirement for the administrator to 554 explicitly configure security. 556 TBD. 558 7.1. Public Key Infrastructure 560 An autonomic domain uses a PKI model. The root of trust is a 561 certification authority (CA). A registrar acts as a registration 562 authority (RA). 564 A minimum implementation of an autonomic domain contains one CA, one 565 Registrar, and network elements. 567 7.2. Domain Certificate 569 TBD. 571 8. Cross-Domain Functionality 573 TBD. 575 9. Autonomic Service Agents (ASA) 577 This section describes how autonomic services run on top of the 578 Autonomic Slice Networking Infrastructure. There are at least two 579 different types of autonomic functions are known: 581 1. Slice Service Agents are low level functions that learn 582 capabilities of underlying infrastructure in terms of interfaces 583 and available resources. They coordinate with Slice control to 584 associate these resources with specific slice instances in effect 585 performing full life cycle management of these resources. 587 2. Slice Control Autonomic Function: Slice control is responsible 588 for high-level life-cycle management of a slice itself. This 589 function will hold slice instances and their attributes related 590 data structures in autonomic network slice infrastructure. As an 591 example, a slice is defined for high bandwidth, highly secure 592 transactional application. A slice control must be capable of 593 negotiating resources required across different SSAs. 595 Out of scope are details of the mechanisms how the information is 596 represented and exchanged between the two autonomic functions. 598 10. Management and Programmability 600 This section describes how an Autonomic Network is managed, and 601 programmed. 603 10.1. How a Slice Network Is Managed 605 Slice network management is driven by Slice control, there are four 606 categories operation: 608 1. Creating a network slice: Receive a network slice resource 609 description request, upon successful negotiation with SSA 610 allocate resource for it. 612 2. Shrink/Expand slice network: Dynamically alter resource 613 requirements for a running slice network according service load. 615 3. (Re-)Configure slice network: The slice management user deploys a 616 user level service into the slice. The slice control takes over 617 the control of all the virtualized network functions and network 618 programmability functions assigned to the slice, and 619 (re-)configure them as appropriate to provide the end-to-end 620 service. 622 4. Destroy slice network: Recycle all resource from the 623 infrastructure. 625 10.2. Intent 627 TBD. 629 10.3. Control Loops 631 TBD. 633 10.4. APIs 635 The API model of for autonomic slicing semantically, is grouped into 636 the following APIs to be defined. 638 10.4.1. Slice Control APIs 640 1. Create a slice network on user request. The request includes 641 resource description. A unique identify a slice network, group 642 all the resource. 644 2. Destroy a slice network identified by it's id. 646 3. Query a slice network slicing state by it's uuid. 648 4. Modify a slice network. 650 10.4.2. Service Agent - Device APIs 652 A service agent will interface with the physical infrastructure 653 either through an autonomic network or traditional infrastructure. 654 Depending upon which a device can either have autonomic or non- 655 autonomic addressing. Service agents are required to perform life 656 cycle management of network elements participating in a network slice 657 and the following APIs are needed for addition, removal or update of 658 a specific device. A device may be a logical or physical network 659 element. Optionally, it may be a network function. 661 10.4.3. Service Agent - Port APIs 663 A port may be a physical or logical network port in a slice depending 664 upon whether underlying infrastructure is an autonomic or traditional 665 network. Service agents must be able to control the operational 666 state of these ports. APIs are needed for addition, removal, update 667 and operational state retrieval of a specific port. 669 10.4.4. Service Agent - Link APIs 671 A link connects two or more ports of devices described in above 672 section. Service agents must be able to control the operational and 673 connection status of these links through APIs for addition, removal, 674 update and state retrieval for each link. 676 10.5. Relationship with MANO 678 Please refer to [MANO] for MANO introduction. 680 TBD. 682 11. Security Considerations 684 11.1. Threat Analysis 686 TBD. 688 11.2. Security Mechanisms 690 TBD. 692 12. IANA Considerations 694 This document requests no action by IANA. 696 13. Acknowledgements 698 Thanks Bing Liu for helping editing the draft. 700 This document was produced using the xml2rfc tool [RFC2629]. 702 14. References 704 14.1. Normative References 706 [I-D.ietf-anima-grasp] 707 Bormann, C., Carpenter, B., and B. Liu, "A Generic 708 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 709 grasp-07 (work in progress), September 2016. 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, 713 DOI 10.17487/RFC2119, March 1997, 714 . 716 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 717 DOI 10.17487/RFC2629, June 1999, 718 . 720 14.2. Informative References 722 [ChinaCom09] 723 "A. Galis et all - "Management and Service-aware 724 Networking Architectures (MANA) for Future Internet" - 725 Invited paper IEEE 2009 Fourth International Conference on 726 Communications and Networking in China (ChinaCom09) 26-28 727 August 2009, Xi'an, China, 728 .". 730 [GENI] ""GENI Key Concepts" - Global Environment for Network 731 Innovations (GENI) 732 .". 734 [I-D.du-anima-an-intent] 735 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 736 Behringer, "ANIMA Intent Policy and Format", draft-du- 737 anima-an-intent-04 (work in progress), July 2016. 739 [I-D.ietf-anima-autonomic-control-plane] 740 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 741 Control Plane", draft-ietf-anima-autonomic-control- 742 plane-03 (work in progress), July 2016. 744 [I-D.ietf-anima-reference-model] 745 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 746 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 747 Reference Model for Autonomic Networking", draft-ietf- 748 anima-reference-model-02 (work in progress), July 2016. 750 [I-D.liu-anima-grasp-api] 751 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 752 Autonomic Signaling Protocol Application Program Interface 753 (GRASP API)", draft-liu-anima-grasp-api-02 (work in 754 progress), September 2016. 756 [I-D.liu-anima-grasp-distribution] 757 Liu, B. and S. Jiang, "Information Distribution over 758 GRASP", draft-liu-anima-grasp-distribution-02 (work in 759 progress), September 2016. 761 [I-D.strassner-anima-control-loops] 762 Strassner, J., Halpern, J., and M. Behringer, "The Use of 763 Control Loops in Autonomic Networking", draft-strassner- 764 anima-control-loops-01 (work in progress), April 2016. 766 [IMT2020] "ITU-T IMT2020 document "Report on Gap Analysis" - ITU-T 767 IMT2020 ITU- Dec 2015 Published by ITU-T IMT2020. 768 .". 771 [MANO] "ETSI European Telecommunications Standards Institute. 772 Network Functions Virtualisation (NFV); Management and 773 Orchestration v1.1.1. Website, December 2014. 774 .". 777 [NGMN] "Hedmar,P., Mschner, K., et all - NGMN Alliance document 778 "Description of Network Slicing Concept", January 2016. 779 .". 782 [NGS-3GPP] 783 ""Study on Architecture for Next Generation System" - 784 latest version v1.0.2 September 2016 785 .". 788 [ONF] "Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, 789 M., Lopes, D., Kaippallimalit, J., - Open Network 790 Fundation document "Applying SDN Architecture to 5G 791 Slicing", April 2016. 792 .". 796 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 797 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 798 Networking: Definitions and Design Goals", RFC 7575, 799 DOI 10.17487/RFC7575, June 2015, 800 . 802 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 803 Analysis for Autonomic Networking", RFC 7576, 804 DOI 10.17487/RFC7576, June 2015, 805 . 807 [TETT1] "Guerzoni,R., Vaishnavi,I.,Perez-Caparros, D., Galis,A., 808 et all "Analysis of End-to-End Multi Domain Management and 809 Orchestration Frameworks for Software Defined 810 Infrastructures: an Architectural Survey", Transactions on 811 Emerging Telecommunications Technologies, Wiley Online 812 Library, DOI: 10.1002/ett.3103, June 2016, 813 .". 815 [TETT2] "Karl,H., Draexler,S., Peuster, M, Galis, A., et all 816 "DevOps for Network Function Virtualization: An 817 Architectural Approach", Transactions on Emerging 818 Telecommunications Technologies, Wiley Online Library, 819 DOI: 10.1002/ett.3084, July 2016, 820 .". 823 Authors' Addresses 825 Alex Galis 826 University College London 827 Department of Electronic and Electrical Engineering 828 Torrington Place 829 London WC1E 7JE 830 United Kingdom 832 Email: a.galis@ucl.ac.uk 834 Kiran Makhijani 835 Huawei Technologies 836 2890, Central Expressway 837 Santa Clara CA 95032 838 USA 840 Email: USA Email: kiran.makhijani@huawei.com 842 Delei Yu 843 Huawei Technologies 844 Q22, Huawei Campus 845 No.156 Beiqing Road 846 Hai-Dian District, Beijing 100095 847 P.R. China 849 Email: yudelei@huawei.com