idnits 2.17.1 draft-peloso-anima-autonomic-function-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 121 has weird spacing: '...roperty allow...' == Line 124 has weird spacing: '...roperty allow...' == Line 128 has weird spacing: '...roperty allow...' == Line 432 has weird spacing: '...roperty allow...' == Line 435 has weird spacing: '...roperty allow...' == (1 more instance...) -- The document date (March 21, 2016) is 2951 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Observation' is mentioned on line 334, but not defined == Unused Reference: 'RFC7575' is defined on line 1036, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ciavaglia-anima-coordination-00 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA P. Peloso 3 Internet-Draft L. Ciavaglia 4 Intended status: Standards Track Nokia 5 Expires: September 22, 2016 March 21, 2016 7 A Day in the Life of an Autonomic Function 8 draft-peloso-anima-autonomic-function-01.txt 10 Abstract 12 While autonomic functions are often pre-installed and integrated with 13 the network elements they manage, this is not a mandatory condition. 14 Allowing autonomic functions to be dynamically installed and to 15 control resources remotely enables more versatile deployment 16 approaches and enlarges the application scope to virtually any legacy 17 equipment. The analysis of autonomic functions deployment schemes 18 through the installation, instantiation and operation phases allows 19 constructing a unified life-cycle and identifying new required 20 functionality. Thus, the introduction of autonomic technologies will 21 be facilitated, the adoption much more rapid and broad. Operators 22 will benefit from multi-vendor, inter-operable autonomic functions 23 with homogeneous operations and superior quality, and will have more 24 freedom in their deployment scenarios. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 22, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. 61 This document may not be modified, and derivative works of it may not 62 be created, except to format it for publication as an RFC or to 63 translate it into languages other than English. 65 Table of Contents 67 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Motivations from an operator viewpoint . . . . . . . . . . . 4 69 2.1. Illustration of increasingly constraining operator's 70 objectives . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Deployment scenarios of autonomic functions . . . . . . . 5 72 2.3. Operator's requirements with regards to autonomic 73 functions . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3. Installation phase . . . . . . . . . . . . . . . . . . . . . 10 75 3.1. Operator's goal . . . . . . . . . . . . . . . . . . . . . 10 76 3.2. Installation phase inputs and outputs . . . . . . . . . . 11 77 4. Instantiation phase . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. Operator's goal . . . . . . . . . . . . . . . . . . . . . 12 79 4.2. Instantiation phase inputs and outputs . . . . . . . . . 13 80 4.3. Instantiation phase requirements . . . . . . . . . . . . 13 81 5. Operation phase . . . . . . . . . . . . . . . . . . . . . . . 14 82 6. Autonomic Function Agent specifications . . . . . . . . . . . 15 83 6.1. Life-cycle . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.2. ASA Class Manifest . . . . . . . . . . . . . . . . . . . 16 85 6.3. ASA Instance Mandate . . . . . . . . . . . . . . . . . . 17 86 6.4. ASA Instance Manifest . . . . . . . . . . . . . . . . . . 18 87 7. Implication for other ANIMA components . . . . . . . . . . . 19 88 7.1. Additional entities for ANIMA ecosystem . . . . . . . . . 19 89 7.2. Requirements for GRASP and ACP messages . . . . . . . . . 20 90 7.2.1. Control when an ASA runs . . . . . . . . . . . . . . 21 91 7.2.2. Know what an ASA does to the network . . . . . . . . 21 92 7.2.3. Decide which ASA control which equipment . . . . . . 22 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 98 11.2. Informative References . . . . . . . . . . . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Problem statement 103 While autonomic functions are often pre-installed and integrated with 104 the network elements they manage, this is not a mandatory condition. 105 Allowing autonomic functions to be dynamically installed and to 106 control resources remotely enables more versatile deployment 107 approaches and enlarges the application scope to virtually any legacy 108 equipment. The analysis of autonomic functions deployment schemes 109 through the installation, instantiation and operation phases allows 110 constructing a unified life-cycle and identifying new required 111 functionality. 113 An Autonomic Service Agent (ASA) controls resources of one or 114 multiple Network Elements (NE), e.g. the interfaces of a router for a 115 Load Balancing ASA. An ASA is a software, thus an ASA need first to 116 be installed and to execute on a host machine in order to control 117 resources. 119 There are 3 properties applicable to the installation of ASAs: 121 The dynamic installation property allows installing an ASA on 122 demand, on any hosts compatible with the ASA. 124 The decoupling property allows controlling resources of a NE from a 125 remote ASA, i.e. an ASA installed on a host machine different from 126 the resources' NE. 128 The multiplicity property allows controlling multiple sets of 129 resources from a single ASA. 131 These three properties provide the operator a great variety of ASA 132 deployment schemes as they decorrelate the evolution of the 133 infrastructure layer from the evolution of the autonomic function 134 layer. Depending on the capabilities (and constraints) of the 135 infrastructure and of the autonomic functions, the operator can 136 devise the schemes that will better fit to its deployment objectives 137 and practices. 139 Based on the above definitions, the ASA deployment process can be 140 formulated as a multi-level/criteria matching problem. 142 The primary level, present in the three phases, consists in matching 143 the objectives of the operator and the capabilities of the 144 infrastructure. The secondary level criteria may vary from phase to 145 phase. One goal of the document is thus to identify the specific and 146 common functionality among these three phases. 148 This draft will explore the implications of these properties along 149 each of the 3 phases namely Installation, Instantiation and 150 Operation. This draft will then provide a synthesis of these 151 implications in requirements for functionalities and life-cycle of 152 ASAs. Beforehand, the following section will deal with the network 153 operator's point of view with regards of autonomic networks. 155 2. Motivations from an operator viewpoint 157 Only few operators would dare relying on a pure autonomic network, 158 without setting objectives to it. From an operator to the other, the 159 strategy of network management vary, as much for historical reasons 160 (experience, best-practice, tools in-place, organization), as much 161 for differences in the operators goals (business, trade agreements, 162 politics, risk policy). Additionally, network operators do not 163 necessarily perform a uniform network management across the different 164 domains composing their network infrastructure. Hence their 165 objectives in terms of availability, load, and dynamics vary 166 depending on the nature of the domains and of the types of services 167 running over each of those domains. 169 To manage the networks according to the above variations, ASAs need 170 to capture the underlying objectives implied by the operators. The 171 instantiation phase is the step in-between installation and 172 operation, where the network operator determine the initial ASA 173 behavior according to its objectives. This step allows the network 174 operator to determine which ASAs should execute on which domains of 175 its network, with appropriate settings. At this stage, thanks to the 176 intent-policy setting objectives to groups of ASAs, the network 177 management should become far simpler (and less error-prone) than 178 setting low-level configurations for each individual network 179 resources. 181 2.1. Illustration of increasingly constraining operator's objectives 183 This paragraph describes the following example of operator intents 184 with regards to deployments of autonomic functions. The autonomic 185 function involved is a load balancing function, which uses monitoring 186 results of links load to autonomously modify the links metrics in 187 order to balance the load over the network. The example is divided 188 into steps corresponding to an increasing implication of the operator 189 in the definition of objectives/intents to the deployment of 190 autonomic functions: 192 Step 1 The operator operates its network and benefits from the 193 autonomic function on the nodes which have the installed ASAs. 195 Step 2 Then the operator, specifies to the autonomic function an 196 objective which is to achieve the maximum number of links with a 197 load below 6O%. 199 Step 3 The network is composed of five domains, a core transport 200 network and four metropolitan networks, each interconnected 201 through the core network, the operator sets a different objective 202 to the autonomic function for each of the five domain. 204 Step 4 As inside metropolitan domains the traffic variations are 205 steeper and happen in a periodic fashion contrary to the traffic 206 in the core domain, the network operators installs an additional 207 autonomic function inside each of these domains. This autonomic 208 function is learning the traffic demands in order to predict 209 traffic variations. The operators instructs the load balancing 210 function to augment its monitored input with the traffic 211 predictions issued by the newly installed autonomic function. 213 Step 5 As the algorithm of the load balancing autonomic function is 214 relying on interactions between autonomic function agents, the 215 operator expects the interactions to happen in-between ASAs of 216 each domain, hence the load will be balanced inside each of the 217 domain, while previously it would have been balanced over the 218 whole network uniformly. 220 Step 6 Finally, the network operator has purchased a new piece of 221 software corresponding to an autonomic function achieving load 222 balancing with a more powerful algorithm. For trial sake, he 223 decides to deploy this new load balancing function instead of the 224 previous one on one of its four metropolitan domains. 226 This short example illustrates some specificities of deployment 227 scenarios, the sub-section below sets itself at providing a more 228 exhaustive view of the different deployment scenarios. 230 2.2. Deployment scenarios of autonomic functions 232 The following scenarios illustrate the different ways the autonomic 233 functions could be deployed in an ANIMA context. Subsequently, 234 requirements for the autonomic functions and requirements these 235 autonomic functions impose on other components of the ANIMA ecosystem 236 are listed. 238 These various deployment scenarios are better understood by referring 239 to the High level view of an Autonomic Network, Figure 1 of 241 [I-D.behringer-anima-reference-model]. The figure is slightly 242 extended for the purpose of the demonstration as follows: 244 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 245 | : Autonomic Function 1 : | 247 | ASA 1.1 : ASA 1.2 : ASA 1.3 : ASA 1.4 | 248 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 249 : : : 250 : + - - - - - - - - - - - - - + : 251 : | Autonomic Function 2 | : 253 : | ASA 2.2 : ASA 2.3 | : 254 : + - - - - - - - - - - - - - + : 255 : : : 256 + - - - - - - - - - - - - - + : + - - - - - - - - - - - - - + 257 | Autonomic Function 3 | : | Autonomic Function 4 | 259 | ASA 3.1 : ASA 3.2 | : | ASA 4.3 : ASA 4.4 | 260 + - - - - - - - - - - - - - + : + - - - - - - - - - - - - - + 261 : : : 262 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 263 | Autonomic Networking Infrastructure | 264 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 265 +--------+ : +--------+ : +--------+ : +--------+ 266 | Node 1 |-------| Node 2 |-------| Node 3 |-------| Node 4 | 267 +--------+ : +--------+ : +--------+ : +--------+ 269 Figure 1: High level view of an Autonomic Network 271 Figure 1 depicts 4 Nodes, 4 Autonomic Functions and 10 Autonomic 272 Service Agents. Let's list assumptions with regards of these 273 elements. 275 Starting with nodes, 277 each may be either an Unconstrained Autonomic Node, a Constrained 278 Autonomic Node (or even a legacy one?), 280 they may well be of different models (or having different software 281 versions), 283 they may well be of different equipment vendors, 285 they may well be of different technologies (some may be IP 286 routers, some may be Ethernet switches or OTN switches...). 288 Pursuing with Autonomic Functions, 290 they may well have different objectives (one could target 291 automatic configuration of OSPF-TE, while another one is 292 optimizing traffic load), but they may well have identical 293 objectives as two could optimize energy consumption (possibly on 294 different areas as function 3 and function 4), 296 each may be composed of no more than one ASA (either because the 297 function is responsible for a single node or because the function 298 relies on a centralized implementation), 300 each may well be composed of different sort of ASAs, meaning the 301 software is different (either because their version number is 302 different, or because the software provider is different, or 303 because their respective nodes/equipments differ or because the 304 role of each agent is different), 306 [Observation] Depending on the implementation the same piece of 307 software may fulfill different roles or each role may come from a 308 different from a different piece of code, 310 each has reached a given organization, meaning an organized set of 311 ASAs in charge of a set of nodes ()whether formalized or not), 312 this organization may either come from the piece of software 313 itself (e.g. embedding a self-organization process) or come from 314 directions of the network operator (e.g. through intents/policies, 315 or through deployment instructions) 317 each may work internally in a peer to peer fashion (where every 318 agents have the same prerogatives) or in hierarchical fashion 319 (where some agents have some prerogatives over other) [this option 320 is a good example of role differences], 322 each having its scope of work in terms of objective to reach and 323 area/space/part of the network to manage. 325 Completing with individual Autonomic Service Agents, those are pieces 326 of software: 328 embedded inside the node/equipment OS (hence present since the 329 bootstrap or OS update of the equipment), 331 running in a machine different than the node (this could be a node 332 controller or any other host or virtual machine) 334 [Observation] In the latter case, the ASA would likely require 335 external credentials to interact with the node, 336 directly monitoring and configuring the equipment (likely requires 337 the ASA to be embedded) or through a management interface of the 338 equipment (e.g. SNMP, TL1, Q3, NetConf) or through an equipment 339 controller (e.g. SDN paradigm) or through a network manager (e.g. 340 using the north interface of the manager) 342 either activated at start-up or as the result of a management 343 action, 345 may be installed (either inside the equipment or on a different 346 machine) when requested by an operator from a software origin 347 (e.g. a repository in the ACP, a media) 349 provided by the same vendor as the equipment it manages or by any 350 third party (like another equipment vendor, a management software 351 vendor, an open-source initiative or the operator software team), 353 sharing a technical objective with the other ASAs of the Autonomic 354 Function they belong, (or at least a similar one)? 356 can it contains multiple technical objective? 358 must the technical objective be intrinsic or can it be set by a 359 managing entity (a network operator or a management system)? 361 The last three points being largely questionable are marked as 362 questions. 364 The figure below illustrates how an ASA interacts with a node that 365 the ASA manages. The left side depicts external interactions, 366 through exchange of commands towards interfaces either to the node OS 367 (e.g. via SNMP or NetConf), or to the controller (e.g. (G)MPLS, SDN, 368 ...), or to the NMS. The right side depicts the case of the ASA 369 embedded inside the Node OS. 371 + - - - + +-------------+ 372 | ASA |------>| NMS *<--* 373 + - - - + +------^------+ | 374 | | | | 375 | | +------V------+ | 376 | +-------->| Controller | | 377 | +------^------+ | +---------------------+ 378 | | | | + - - - + | 379 | +------V------+ | | | ASA | Node OS | 380 +------------>| Node OS *<--* | + - - - + | 381 +------^------+ +--------------*------+ 382 | | 383 +------V------+ +-----*------+ 384 | Node | | Node | 385 +-------------+ +------------+ 387 Figure 2: Interaction possibilities between ASA and Resources 389 2.3. Operator's requirements with regards to autonomic functions 391 Regarding the operators, at this point we can try to list few 392 requirements they may have with regards with the Autonomic Functions 393 and their management... 395 Being capable to set those functions a scope of work in term of 396 area of duty, 398 Being capable to monitor the actions taken by the autonomic 399 functions, and which are its results (performance with regards to 400 the function KPIs) 402 Being capable to halt/suspend the execution of an Autonomic 403 function (either because the function is untrusted, or because an 404 operation on the network is to be conducted without interference 405 from the autonomic functions, etc...) 407 Being capable to configure the autonomic functions by adjusting 408 the parameters of the function (e.g. a Traffic Engineering 409 autonomic function may achieve a trade-off between congestion 410 avoidance and electrical power consumption, hence this function 411 may be more or less aggressive on the link load ratio, and the 412 network operator certainly has his word to say in setting this 413 cursor. 415 3. Installation phase 417 Before being able to instantiate and run ASAs, the operator must 418 first provision the infrastructure with the sets of ASA software 419 corresponding to its needs and objectives. The provisioning of the 420 infrastructure is realized in the installation phase and consists in 421 installing (or checking the availability of) the pieces of software 422 of the different ASA classes in a set of Installation Hosts. 424 As mentioned in the Problem statement section, an Autonomic Function 425 Agent (ASA) controls resources of one or multiple Network Elements 426 (NE), e.g. the interfaces of a router for a Load Balancing ASA. An 427 ASA is a software, thus an ASA need first to be installed and to 428 execute on a host machine in order to control resources. 430 There are 3 properties applicable to the installation of ASAs: 432 The dynamic installation property allows installing an ASA on 433 demand, on any hosts compatible with the ASA. 435 The decoupling property allows controlling resources of a NE from a 436 remote ASA, i.e. an ASA installed on a host machine different from 437 the resources' NE. 439 The multiplicity property allows controlling multiple sets of 440 resources from a single ASA. 442 These three properties are very important in the context of the 443 installation phase as their variations condition how the ASA class 444 could be installed on the infrastructure. 446 3.1. Operator's goal 448 In the installation phase, the operator's goal is to install ASA 449 classes on Installation Hosts such that, at the moment of 450 instantiation, the corresponding ASAs can control the sets of target 451 resources. The complexity of the installation phase come from the 452 number of possible configurations for the matching between the ASA 453 classes capabilities (e.g. what types of resources it can control, 454 what types of hosts it can be installed on...), the Installation 455 Hosts capabilities (e.g. support dynamic installation, location and 456 reachability...) and the operator's needs (what deployment schemes 457 are favored, functionality coverage vs. cost trade-off...). 459 For example, in the coupled mode, the ASA host machine and the 460 network element are the same. The ASA is installed on the network 461 element and control the resources via interfaces and mechanisms 462 internal to the network element. An ASA MUST be installed on the 463 network element of every resource controlled by the ASA. The 464 identification of the resources controlled by an ASA is 465 straightforward: the resources are the ones of the network element. 467 In the decoupled mode, the ASA host machine is different from the 468 network element. The ASA is installed on the host machine and 469 control the resources via interfaces and mechanisms external to the 470 network element. An ASA can be installed on an arbitrary set of 471 candidate Installation hosts, which can be defined explicitly by the 472 network operator or according to a cost function. A key benefit of 473 the decoupled mode is to allow an easier introduction of autonomic 474 functions on existing (legacy) infrastructure. The decoupled mode 475 also allows de-correlating the installation requirements (compatible 476 host machines) from the infrastructure evolution (NEs addition and 477 removal, change of NE technology/version...). 479 The operator's goal may be defined as a special type of intent, 480 called the Installation phase intent. The details of the content and 481 format of this proposed intent are left open and for further study. 483 3.2. Installation phase inputs and outputs 485 Inputs are: 487 [ASA class of type_x] that specifies which classes ASAs to install, 489 [Installation_target_Infrastructure] that specifies the candidate 490 Installation Hosts, 492 [ASA class placement function, e.g. under which criteria/constraints 493 as defined by the operator] 494 that specifies how the installation phase shall meet the 495 operator's needs and objectives for the provision of the 496 infrastructure. In the coupled mode, the placement function is 497 not necessary, whereas in the decoupled mode, the placement 498 function is mandatory, even though it can be as simple as an 499 explicit list of Installation hosts. 501 The main output of the installation phase is an up-to-date directory 502 of installed ASAs which corresponds to [list of ASA classes] 503 installed on [list of installation Hosts]. This output is also 504 useful for the coordination function and corresponds to the static 505 interaction map. 507 The condition to validate in order to pass to next phase is to ensure 508 that [list of ASA classes] are well installed on [list of 509 installation Hosts]. The state of the ASA at the end of the 510 installation phase is: installed. (not instantiated). The following 511 commands or messages are foreseen: install(list of ASA classes, 512 Installation_target_Infrastructure, ASA class placement function), 513 and un-install (list of ASA classes). 515 4. Instantiation phase 517 Once the ASAs are installed on the appropriate hosts in the network, 518 these ASA may start to operate. From the operator viewpoint, an 519 operating ASA means the ASA manages the network resources as per the 520 objectives given. At the ASA local level, operating means executing 521 their control loop/algorithm. 523 But right before that, there are two things to take into 524 consideration. First, there is a difference between 1. having a 525 piece of code available to run on a host and 2. having an agent based 526 on this piece of code running inside the host. Second, in a coupled 527 case, determining which resources are controlled by an ASA is 528 straightforward (the determination is embedded), in a decoupled mode 529 determining this is a bit more complex (hence a starting agent will 530 have to either discover or be taught it). 532 The instantiation phase of an ASA covers both these aspects: starting 533 the agent piece of code (when this does not start automatically) and 534 determining which resources have to be controlled (when this is not 535 obvious). 537 4.1. Operator's goal 539 Through this phase, the operator wants to control its autonomic 540 network in two things: 542 1 determine the scope of autonomic functions by instructing which of 543 the network resources have to be managed by which autonomic 544 function (and more precisely which class e.g. 1. version X or 545 version Y or 2. provider A or provider B), 547 2 determine how the autonomic functions are organized by instructing 548 which ASAs have to interact with which other ASAs (or more 549 precisely which set of network resources have to be handled as an 550 autonomous group by their managing ASAs). 552 Additionally in this phase, the operator may want to set objectives 553 to autonomic functions, by configuring the ASAs technical objectives. 555 The operator's goal can be summarized in an instruction to the ANIMA 556 ecosystem matching the following pattern: 558 [ASA of type_x instances] ready to control 559 [Instantiation_target_Infrastructure] with 560 [Instantiation_target_parameters] 562 4.2. Instantiation phase inputs and outputs 564 Inputs are: 566 [ASA of type_x instances] that specifies which are the ASAs to be 567 targeted (and more precisely which class e.g. 1. version X or 568 version Y or 2. provider A or provider B), 570 [Instantiation_target_Infrastructure] that specifies which are the 571 resources to be managed by the autonomic function, this can be the 572 whole network or a subset of it like a domain a technology segment 573 or even a specific list of resources, 575 [Instantiation_target_parameters] that specifies which are the 576 technical objectives to be set to ASAs (e.g. an optimization 577 target) 579 Outputs are: 581 [Set of ASAs - Resources relations] describing which resources are 582 managed by which ASA instances, this is not a formal message, but 583 a resulting configuration of a set of ASAs, 585 4.3. Instantiation phase requirements 587 The instructions described in section 4.2 could be either: 589 sent to a targeted ASA In which case, the receiving Agent will have 590 to manage the specified list of 591 [Instantiation_target_Infrastructure], with the 592 [Instantiation_target_parameters]. 594 broadcast to all ASAs In which case, the ASAs would collectively 595 determine from the list which Agent(s) would handle which 596 [Instantiation_target_Infrastructure], with the 597 [Instantiation_target_parameters]. 599 This set of instructions can be materialized through a message that 600 is named an Instance Mandate. Instance Mandates are described in the 601 requirements part of this document, which lists the needed fields of 602 such a message (see Section 6.3 - ASA Instance Mandate). 604 The conclusion of this instantiation phase is a ready to operate ASA 605 (or interacting set of ASAs), then this (or those) ASA(s) can 606 describe themselves by depicting which are the resources they manage 607 and what this means in terms of metrics being monitored and in terms 608 of actions that can be executed (like modifying the parameters 609 values). A message conveying such a self description is named an 610 Instance Manifest. Instance Manifests are described in the 611 requirements part of this document, which lists the needed fields of 612 such a message (see Section 6.4 - ASA Instance Manifest). 614 Though the operator may well use such a self-description "per se", 615 the final goal of such a description is to be shared with other ANIMA 616 entities like: 618 o the coordination entities (see [I-D.ciavaglia-anima-coordination] 619 - Autonomic Functions Coordination) 621 o collaborative entities in the purpose of establishing knowledge 622 exchanges (some ASAs may produce knowledge or even monitor metrics 623 that other ASAs cannot make by themselves why those would be 624 useful for their execution) (see knowledge exchange items in 625 Section 5 - Operation phase) 627 5. Operation phase 629 Note: This section is to be further developed in future revisions of 630 the document. 632 During the Operation phase, the operator can: 634 Activate/Deactivate ASA: meaning enabling those to execute their 635 autonomic loop or not. 637 Modify ASAs targets: meaning setting them different objectives. 639 Modify ASAs managed resources: by updating the instance mandate 640 which would specify different set of resources to manage (only 641 applicable to decouples ASAs). 643 During the Operation phase, running ASAs can interact the one with 644 the other: 646 in order to exchange knowledge (e.g. an ASA providing traffic 647 predictions to load balancing ASA) 649 in order to collaboratively reach an objective (e.g. ASAs 650 pertaining to the same autonomic function targeted to manage a 651 network domain, these ASA will collaborate - in the case of a load 652 balancing one, by modifying the links metrics according to the 653 neighboring resources loads) 655 During the Operation phase, running ASAs are expected to apply 656 coordination schemes 658 then execute their control loop under coordination supervision/ 659 instructions 661 6. Autonomic Function Agent specifications 663 6.1. Life-cycle 665 Based on the phases described above, this section defines formally 666 the different states experienced by Autonomic Function Agents during 667 their complete life-cycle. 669 The drawing of the life-cycle presented below shows both the states 670 and the events/messages triggering the state changes. For 671 simplification purposes, this sketch does not display the transitory 672 states which correspond to the handling of the messages. 674 The installation and Instantiation phase will be concluded by ASA 675 reaching respectively Installed and Instantiated states. 677 +--------------+ 678 Undeployed ------>| |------> Undeployed 679 | Installed | 680 +-->| |---+ 681 Mandate | +--------------+ | Receives a 682 is revoked | +--------------+ | Mandate 683 +---| |<--+ 684 | Instantiated | 685 +-->| |---+ 686 set | +--------------+ | set 687 down | +--------------+ | up 688 +---| |<--+ 689 | Operational | 690 | | 691 +--------------+ 693 Figure 3: Life cycle of an Autonomic Function Agent 695 Here are described the successive states of ASA. 697 Undeployed - In this "state", the Autonomic Function Agent is a 698 mere piece of software, which may not even be available on any 699 host. 701 Installed - In this state, the Autonomic Function Agent is 702 available on a (/multiple) host(s), and after having shared its 703 ASA class Manifest (which describes in a generic way independently 704 of the deployment how the ASA would work). In this state the ASA 705 is waiting for an ASA Instance Mandate, to determine which 706 resources ti manage (when the ASA is strictly coupled to resources 707 [e.g. part of a Node OS], there is no need to wait for an instance 708 mandate, the target resources being intrinsically known). 710 Instantiated - In this state the Autonomic Function Agent has the 711 knowledge of which resources it is meant to manage. In this state 712 the ASA is expecting a set Up message in order to start executing 713 its autonomic loop. From this state on the ASA can share an 714 Instance Manifest (which describes how the ASA instance is going 715 to work). 717 Operational - In this state, ASAs are executing their autonomic 718 loop, hence acting on network, by modifying resources parameters. 719 A set down message will turn back the ASA in an Instantiated 720 state. 722 The messages are described in the following sections. 724 6.2. ASA Class Manifest 726 An ASA class is a piece of software that contains the computer 727 program of an Autonomic Function Agent. 729 In order to install and instantiate appropriately an autonomic 730 function in its network, the operator needs to know which are the 731 characteristics of this piece of software. 733 This section details a format for an ASA class manifest, which is (a 734 machine-readable) description of both the autonomic function and the 735 piece of code that executes the function. 737 +--------------+---------------+------------------------------------+ 738 | Field Name | Type | Description | 739 +--------------+---------------+------------------------------------+ 740 | ID | Struct | A unique identifier made out of at | 741 | | | least a Function Name, Version and | 742 | | | Provider Name (and Release Date). | 743 | Description | Struct | A multi-field description of the | 744 | | | function performed by the ASA, it | 745 | | | is meant to be read by the | 746 | | | operator and can point to URLs, | 747 | | | user-guides, feature descriptions. | 748 | Installation | 3 Booleans | Whether the ASA is dynamically | 749 | properties | | installable, can be decoupled from | 750 | | | the NE and can manage multiple | 751 | | | resources from a single instance | 752 | | | (see Section 1 - Problem | 753 | | | statement). | 754 | Possible | OS... | Lists the OS/Machines on which the | 755 | Hosts | | ASA can be executed. [Only if ASA | 756 | | | is dynamically installable] | 757 | Network | NetSegment... | Lists the network segments on | 758 | Segment | | which the autonomic function is | 759 | | | applicable (e.g. IP backbone | 760 | | | versus RAN). | 761 | Manageable | Equipments... | Lists the nodes/resources that | 762 | Equipments | | this piece of code can manage | 763 | | | (e.g. ALU 77x routers, Cisco CRS-x | 764 | | | routers, Huawei NEXE routers). | 765 | Autonomic | Enum | States what is the type of loop | 766 | Loop Type | | MAPE-K and whether this loop can | 767 | | | be halted in the course of its | 768 | | | execution. | 769 | Acquired | Raw | Lists the nature of information | 770 | Inputs | InfoSpec... | that an ASA agent may acquire from | 771 | | | the managed resource(s) (e.g. the | 772 | | | links load). | 773 | External | Raw | Lists the nature of information | 774 | Inputs | InfoSpec... | that an ASA agent may require/wish | 775 | | | from other ASA in the ecosystem | 776 | | | that could provide such | 777 | | | information/knowledge. | 778 | Possible | Raw | Lists the nature of actions that | 779 | Actions | ActionSpec | an ASA agent may enforce on ASA | 780 | | | the managed resource(s) (e.g. | 781 | | | modify the links metrics). | 782 | Technical | Technical | Lists the type of technical | 783 | Objectives | Objective | objectives that can be | 784 | Description | Spec... | handled/received by the ASA (e.g. | 785 | | | a max load of links). | 786 +--------------+---------------+------------------------------------+ 788 Table 1: Fields of ASA class manifest 790 6.3. ASA Instance Mandate 792 An ASA instance is the ASA agent: a running piece of software of an 793 ASA class. A software agent is a persistent, goal-oriented computer 794 program that reacts to its environment and interacts with other 795 elements of the network. 797 In order to install and instantiate appropriately an autonomic 798 function in its network, the operator may specify to ASA instances 799 what they are supposed to do: in term of which resources to manage 800 and which objective to reach. 802 This section details a format for an ASA Instance Mandate, which is 803 (a machine-readable) set of instructions sent to create autonomic 804 functions out of ASA. 806 +-----------+----------------+--------------------------------------+ 807 | Field | Type | Description | 808 | Name | | | 809 +-----------+----------------+--------------------------------------+ 810 | ASA class | Struct | A pattern matching the ID (or part | 811 | Pattern | | of it) of ASAs being the target of | 812 | | | the Mandate. This field makes sense | 813 | | | only for broadcast mandates (see end | 814 | | | of this section). | 815 | Managed | ResourcesId... | The list of resources to be managed | 816 | Resources | | by the ASA (e.g. their IP@ or MAC@ | 817 | | | or any other relevant ID). | 818 | ID of | Interface Id | The interface to the coordination | 819 | Coord | | system in charge of this autonomic | 820 | | | function. | 821 | Reporting | Policy | A policy describing which entities | 822 | Policy | | expect report from ASA, and which | 823 | | | are the conditions of these reports | 824 | | | (e.g. time wise and content wise) | 825 +-----------+----------------+--------------------------------------+ 827 Table 2: Fields of ASA instance mandate 829 An ASA instance mandate could be either: 831 sent to a targeted ASA In which case, the receiving Agent will have 832 to manage the specified list of resources, 834 broadcast to all ASA In which case, the ASAs would collectively 835 determine which agent would handle which resources from the list, 836 and if needed (and feasible) this could also trigger the dynamic 837 installation/instantiation of new agents (ACP should be capable of 838 bearing such scenarios). 840 6.4. ASA Instance Manifest 842 Once the ASAs are properly instantiated, the operator and its 843 managing system need to know which are the characteristics of these 844 ASAs. 846 This section details a format for an ASA instance manifest, which is 847 (a machine-readable) description of either an ASA or a set of ASAs 848 gathered into an autonomic function. 850 +-----------+----------------+--------------------------------------+ 851 | Field | Type | Description | 852 | Name | | | 853 +-----------+----------------+--------------------------------------+ 854 | ASA Class | Struct | A unique identifier made out of at | 855 | ID | | least a Function Name, Version and | 856 | | | Provider Name (and Release Date). | 857 | ASA | Long | A unique Id of the ASA instance (if | 858 | Instance | | the ASA instance manifest gathers | 859 | ID | | multiple ASAs working together, this | 860 | | | would be a list). | 861 | Hosts | Resource ID | ID of the Machines on which the ASA | 862 | | | executes. | 863 | Managed | ResourcesId... | The list of resources effectively | 864 | Resources | | managed by the ASA (e.g. their IP@ | 865 | | | or MAC@ or any other relevant ID). | 866 | Acquired | Instance | Lists information that this ASA | 867 | Inputs | InfoSpec... | agent may acquire from the managed | 868 | | | resource(s) (e.g. the links load | 869 | | | over links with ID x and y). | 870 | External | Instance | Lists information that this ASA | 871 | Inputs | InfoSpec... | agent requires from the ecosystem | 872 | | | (e.g. the links load prediction over | 873 | | | links with ID x and y). | 874 | Possible | Instance | Lists actions that this ASA agent | 875 | Actions | ActionSpec | may enforce on its managed | 876 | | | resource(s) (e.g. modify the links | 877 | | | metrics over links x and y). | 878 +-----------+----------------+--------------------------------------+ 880 Table 3: Fields of ASA instance manifest 882 7. Implication for other ANIMA components 884 7.1. Additional entities for ANIMA ecosystem 886 In the previous parts of this document, we have seen successive 887 operations pertaining to the management of autonomic functions. 888 These phases involve different entities such as the ASAs, the ASA 889 Hosts and the ASA Management function. This function serves as the 890 interface between the network operator and its managed infrastructure 891 (i.e. the autonomic network). The ASA management function 892 distributes instructions to the ASAs such as the ASA Instance 893 Mandate, ASA set up/set down commands and also trigger the ASA 894 installation inside ASA Hosts. This function is likely to be co- 895 located or integrated with the function responsible for the 896 management of the Intents. 898 In this first version, we do not prescribe any requirements on the 899 way the ASA Management function should be implemented, neither the 900 various deployment options of such a function and neither on the way 901 ACP or GRASP could be extended to interact with this function. We 902 believe these design and specifications work should be first 903 discussed and analyzed by the working group. 905 7.2. Requirements for GRASP and ACP messages 907 GRASP and ACP seems to be the best (and currently only) candidates to 908 convey the following messages between the ASA Management function and 909 the ASAs: 911 ASA Class Manifest 913 ASA Instance Mandate (and Revoke Mandate) 915 ASA Instance Manifest 917 Set Up and Set Down messages 919 These section concludes with requests to GRASP protocol designers in 920 order to handle the 3 last messages of the list above. These 3 921 messages form the minimal set of features needed to guarantee some 922 control on the behavior of ASAs to network operators. 924 A mechanism similar to the bootstrapping one would usefully achieve 925 discovery of pre-installed ASAs, and possibly provide those with a 926 default Instance Mandate. 928 A mechanism to achieve dynamic installation of ASAs compatible with 929 ACP and GRASP remains to be identified. 931 In the case of decoupled ASAs, even more for the ones supporting 932 multiplicity, when a Mandate is broadcast (i.e. requesting the 933 Instantiation of an autonomic function to manage a bunch of 934 resources), these ASAs require synchronization to determine which 935 agent(s) will manage which resources. Proper ACP/GRASP messages 936 supporting such a mechanism have to be identified together with 937 protocol authors. 939 7.2.1. Control when an ASA runs 941 To control when an ASA runs (and possibly how it runs), the operator 942 needs the capacity to start and stop ASAs. That is why an imperative 943 command type of message is requested from GRASP. 945 Additionally this type of message could also be used to specify how 946 the ASA is meant to run, e.g. whether its control loop is subdued to 947 some constraints in terms of pace of execution or rhythm of execution 948 (once a second, once a minute, once a day...) 950 Below a suggestion for GRASP: 952 In fragmentary CDDL, an Imperative message follows the pattern: 954 imperative-message = [M_IMPERATIVE, session-id, initiator, objective] 956 ... 958 7.2.2. Know what an ASA does to the network 960 To know what an ASA does to the network, the operator needs to have 961 the information of the elements either monitored or modified by the 962 ASA, hence this ASA should disclose those. 964 The disclosing should take the form of a ASA Instance Manifest (see 965 Section 6.4 - ASA Instance Manifest), which could be conveyed inside 966 a GRASP discovery message, hence the fields of the ASA Instance 967 Manifest would be conveyed inside the objective. 969 At this stage there are two options: 971 The whole manifest is conveyed as an objective. 973 Each field of the manifest is conveyed as an individual objective, 974 more precisely, the acquired inputs would appear as discovery 975 only, and the modifiable parameters would appear as negotiation 976 objective. The unclear part is the expression of requested fields 977 (when the ASA claims being a client for such objective). Could 978 one of the already existing objective options a good match or 979 should a new one be created. 981 ... 983 7.2.3. Decide which ASA control which equipment 985 To determine which ASA controls which equipment (or vice-versa which 986 equipments are controlled by which ASAs), the operators needs to be 987 able to instruct ASA before the end of their bootstrap procedure. 989 These instructions sent to ASA during bootstrapping should take the 990 format of an ASA Instance Mandate (see Section 6.3 - 991 ASA Instance Mandate). This ASA Instance Mandate are sorts of 992 Intents, and as GRASP is meant to handle Intents in a near future, it 993 would be beneficial to already identify which sort of GRASP message 994 are meant to be used by Intent in order to already define those. An 995 option could be to reuse the Imperative messages defined above. 997 ... 999 8. Acknowledgments 1001 This draft was written using the xml2rfc project. 1003 This draft content builds upon work achieved during UniverSelf FP7 EU 1004 project. 1006 9. IANA Considerations 1008 This memo includes no request to IANA. 1010 10. Security Considerations 1012 TBD 1014 11. References 1016 11.1. Normative References 1018 [I-D.ciavaglia-anima-coordination] 1019 Ciavaglia, L. and P. Peloso, "Autonomic Functions 1020 Coordination", draft-ciavaglia-anima-coordination-00 (work 1021 in progress), July 2015. 1023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, 1025 DOI 10.17487/RFC2119, March 1997, 1026 . 1028 11.2. Informative References 1030 [I-D.behringer-anima-reference-model] 1031 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 1032 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 1033 for Autonomic Networking", draft-behringer-anima- 1034 reference-model-04 (work in progress), October 2015. 1036 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1037 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1038 Networking: Definitions and Design Goals", RFC 7575, 1039 DOI 10.17487/RFC7575, June 2015, 1040 . 1042 Authors' Addresses 1044 Peloso Pierre 1045 Nokia 1046 Villarceaux 1047 Nozay 91460 1048 FR 1050 Email: pierre.peloso@nokia.com 1052 Laurent Ciavaglia 1053 Nokia 1054 Villarceaux 1055 Nozay 91460 1056 FR 1058 Email: laurent.ciavaglia@nokia.com