idnits 2.17.1 draft-ietf-anima-asa-guidelines-04.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 == Line 489 has weird spacing: '...roperty allow...' == Line 492 has weird spacing: '...roperty allow...' == Line 496 has weird spacing: '...roperty allow...' -- The document date (23 November 2021) is 878 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 778 -- Looks like a reference, but probably isn't: '2' on line 776 -- Looks like a reference, but probably isn't: '3' on line 778 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-17 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational L. Ciavaglia 5 Expires: 27 May 2022 Rakuten Mobile 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 P. Peloso 9 Nokia 10 23 November 2021 12 Guidelines for Autonomic Service Agents 13 draft-ietf-anima-asa-guidelines-04 15 Abstract 17 This document proposes guidelines for the design of Autonomic Service 18 Agents for autonomic networks. Autonomic Service Agents, together 19 with the Autonomic Network Infrastructure, the Autonomic Control 20 Plane and the Generic Autonomic Signaling Protocol constitute base 21 elements of a so-called autonomic networking ecosystem. 23 Discussion Venue 25 This note is to be removed before publishing as an RFC. 27 Discussion of this document takes place on the ANIMA mailing list 28 (anima@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/browse/anima/ 30 (https://mailarchive.ietf.org/arch/browse/anima/). 32 Status of This Memo 34 This Internet-Draft is submitted 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 https://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 27 May 2022. 49 Copyright Notice 51 Copyright (c) 2021 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 (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Logical Structure of an Autonomic Service Agent . . . . . . . 4 67 3. Interaction with the Autonomic Networking Infrastructure . . 6 68 3.1. Interaction with the security mechanisms . . . . . . . . 6 69 3.2. Interaction with the Autonomic Control Plane . . . . . . 6 70 3.3. Interaction with GRASP and its API . . . . . . . . . . . 6 71 3.4. Interaction with policy mechanisms . . . . . . . . . . . 8 72 4. Interaction with Non-Autonomic Components . . . . . . . . . . 8 73 5. Design of GRASP Objectives . . . . . . . . . . . . . . . . . 9 74 6. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Installation phase . . . . . . . . . . . . . . . . . . . 11 76 6.1.1. Installation phase inputs and outputs . . . . . . . . 12 77 6.2. Instantiation phase . . . . . . . . . . . . . . . . . . . 12 78 6.2.1. Operator's goal . . . . . . . . . . . . . . . . . . . 13 79 6.2.2. Instantiation phase inputs and outputs . . . . . . . 13 80 6.2.3. Instantiation phase requirements . . . . . . . . . . 14 81 6.3. Operation phase . . . . . . . . . . . . . . . . . . . . . 15 82 7. Coordination between Autonomic Functions . . . . . . . . . . 15 83 8. Coordination with Traditional Management Functions . . . . . 16 84 9. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 10. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 14.2. Informative References . . . . . . . . . . . . . . . . . 19 92 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 22 93 Appendix B. Terminology . . . . . . . . . . . . . . . . . . . . 24 94 Appendix C. Example Logic Flows . . . . . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 97 1. Introduction 99 This document proposes guidelines for the design of Autonomic Service 100 Agents (ASAs) in the context of an Autonomic Network (AN) based on 101 the Autonomic Network Infrastructure (ANI) outlined in the ANIMA 102 reference model [RFC8993]. This infrastructure makes use of the 103 Autonomic Control Plane (ACP) [RFC8994] and the Generic Autonomic 104 Signaling Protocol (GRASP) [RFC8990]. A general introduction to this 105 environment may be found at [IPJ], and a summary of terminology is in 106 Appendix B. 108 This document is a contribution to the description of an autonomic 109 networking ecosystem, recognizing that a deployable autonomic network 110 needs more than just ACP and GRASP implementations. Such an 111 autonomic network must achieve management tasks that a Network 112 Operations Center (NOC) cannot readily achieve manually, such as 113 continuous resource optimization or automated fault detection and 114 repair. These tasks, and other management automation goals, are 115 described at length in [RFC7575]. The net result should be 116 significant improvement of operational metrics. To achieve this, the 117 autonomic networking ecosystem must include at least a library of 118 ASAs and corresponding GRASP technical objective definitions. A 119 GRASP objective [RFC8990] is a data structure whose main contents are 120 a name and a value. The value consists of a single configurable 121 parameter or a set of parameters of some kind. 123 There must also be tools to deploy and oversee ASAs, and integration 124 with existing operational mechanisms [RFC8368]. However, this 125 document focuses on the design of ASAs, with some reference to 126 implementation and operational aspects. 128 There is a considerable literature about autonomic agents with a 129 variety of proposals about how they should be characterized. Some 130 examples are [DeMola06], [Huebscher08], [Movahedi12] and [GANA13]. 131 However, for the present document, the basic definitions and goals 132 for autonomic networking given in [RFC7575] apply. According to RFC 133 7575, an Autonomic Service Agent is "An agent implemented on an 134 autonomic node that implements an autonomic function, either in part 135 (in the case of a distributed function) or whole." 137 ASAs must be distinguished from other forms of software component. 138 They are components of network or service management; they do not in 139 themselves provide services to end users. They do however provide 140 management services to network operators and administrators. For 141 example, the services envisaged for network function virtualisation 142 [RFC8568] or for service function chaining [RFC7665] might be managed 143 by an ASA rather than by traditional configuration tools. 145 Another example is that an existing script running within a router to 146 locally monitor or configure functions or services could be upgraded 147 as an ASA that could communicate with peer scripts on neighboring or 148 remote routers. A high-level API will allow such upgraded scripts to 149 take full advantage of the secure ACP and the discovery, negotiation 150 and synchronization features of GRASP. Familiar tasks such as 151 configuring an Interior Gateway Protocol (IGP) on neighboring routers 152 or even exchanging IGP security keys could be performed securely in 153 this way. This document mainly addresses issues affecting quite 154 complex ASAs, but the most useful ones may in fact be rather simple 155 developments from existing scripts. 157 The reference model [RFC8993] for autonomic networks explains further 158 the functionality of ASAs by adding "[An ASA is] a process that makes 159 use of the features provided by the ANI to achieve its own goals, 160 usually including interaction with other ASAs via the GRASP protocol 161 [RFC8990] or otherwise. Of course, it also interacts with the 162 specific targets of its function, using any suitable mechanism. 163 Unless its function is very simple, the ASA will need to handle 164 overlapping asynchronous operations. It may therefore be a quite 165 complex piece of software in its own right, forming part of the 166 application layer above the ANI." 168 As mentioned, there will certainly be simple ASAs that manage a 169 single objective in a straightforward way and do not need 170 asynchronous operations. In such a case, many aspects of the current 171 document do not apply. However, in the general case, an ASA may be a 172 relatively complex software component that will in many cases control 173 and monitor simpler entities in the same or remote host(s). For 174 example, a device controller that manages tens or hundreds of simple 175 devices might contain a single ASA. 177 The remainder of this document offers guidance on the design of such 178 ASAs. 180 2. Logical Structure of an Autonomic Service Agent 182 As mentioned above, all but the simplest ASAs will need to support 183 asynchronous operations. Different programming environments support 184 asynchronicity in different ways. In this document, we use an 185 explicit multi-threading model to describe operations. Alternatives 186 are discussed in connection with the GRASP API in Section 3.3. 188 A typical ASA will have a main thread that performs various initial 189 housekeeping actions such as: 191 * Obtain authorization credentials, if needed. 193 * Register the ASA with GRASP. 195 * Acquire relevant policy parameters. 197 * Define data structures for relevant GRASP objectives. 199 * Register with GRASP those objectives that it will actively manage. 201 * Launch a self-monitoring thread. 203 * Enter its main loop. 205 The logic of the main loop will depend on the details of the 206 autonomic function concerned. Whenever asynchronous operations are 207 required, extra threads may be launched. Examples of such threads 208 include: 210 * Repeatedly flood an objective to the AN, so that any ASA can 211 receive the objective's latest value. 213 * Accept incoming synchronization requests for an objective managed 214 by this ASA. 216 * Accept incoming negotiation requests for an objective managed by 217 this ASA, and then conduct the resulting negotiation with the 218 counterpart ASA. 220 * Manage subsidiary non-autonomic devices directly. 222 These threads should all either exit after their job is done, or 223 enter a wait state for new work, to avoid blocking others 224 unnecessarily. 226 According to the degree of parallelism needed by the application, 227 some of these threads might be launched in multiple instances. In 228 particular, if negotiation sessions with other ASAs are expected to 229 be long or to involve wait states, the ASA designer might allow for 230 multiple simultaneous negotiating threads, with appropriate use of 231 queues and locks to maintain consistency. 233 The main loop itself could act as the initiator of synchronization 234 requests or negotiation requests, when the ASA needs data or 235 resources from other ASAs. In particular, the main loop should watch 236 for changes in policy parameters that affect its operation. It 237 should also do whatever is required to avoid unnecessary resource 238 consumption, such as including an arbitrary wait time in each cycle 239 of the main loop. 241 The self-monitoring thread is of considerable importance. Autonomic 242 service agents must never fail. To a large extent this depends on 243 careful coding and testing, with no unhandled error returns or 244 exceptions, but if there is nevertheless some sort of failure, the 245 self-monitoring thread should detect it, fix it if possible, and in 246 the worst case restart the entire ASA. 248 Appendix C presents some example logic flows in informal pseudocode. 250 3. Interaction with the Autonomic Networking Infrastructure 252 3.1. Interaction with the security mechanisms 254 An ASA by definition runs in an autonomic node. Before any normal 255 ASAs are started, such nodes must be bootstrapped into the autonomic 256 network's secure key infrastructure, typically in accordance with 257 [RFC8995]. This key infrastructure will be used to secure the ACP 258 (next section) and may be used by ASAs to set up additional secure 259 interactions with their peers, if needed. 261 Note that the secure bootstrap process itself may include special- 262 purpose ASAs that run in a constrained insecure mode. 264 3.2. Interaction with the Autonomic Control Plane 266 In a normal autonomic network, ASAs will run as clients of the ACP, 267 which will provide a fully secured network environment for all 268 communication with other ASAs, in most cases mediated by GRASP (next 269 section). 271 Note that the ACP formation process itself may include special- 272 purpose ASAs that run in a constrained insecure mode. 274 3.3. Interaction with GRASP and its API 276 GRASP [RFC8990] is likely to run as a separate process with its API 277 [RFC8991] available in user space. Thus, ASAs may operate without 278 special privilege, unless they need it for other reasons. The ASA's 279 view of GRASP is built around GRASP objectives (Section 5), defined 280 as data structures containing administrative information such as the 281 objective's unique name, and its current value. The format and size 282 of the value is not restricted by the protocol, except that it must 283 be possible to serialise it for transmission in CBOR [RFC8949], 284 subject only to GRASP's maximum message size as discussed in 285 Section 5. 287 As discussed in Section 2, GRASP is an asynchronous protocol, and 288 this document uses a multi-threading model to describe operations. 289 In many programming environments, an 'event loop' model is used 290 instead, in which case each thread would be implemented as an event 291 handler called in turn by the main loop. For this case, the GRASP 292 API must provide non-blocking calls and possibly support callbacks. 293 This topic is discussed in more detail in [RFC8991], and other 294 asynchronicity models are also possible. Whenever necessary, the 295 GRASP session identifier will be used to distinguish simultaneous 296 operations. 298 The GRASP API should offer the following features: 300 * Registration functions, so that an ASA can register itself and the 301 objectives that it manages. 303 * A discovery function, by which an ASA can discover other ASAs 304 supporting a given objective. 306 * A negotiation request function, by which an ASA can start 307 negotiation of an objective with a counterpart ASA. With this, 308 there is a corresponding listening function for an ASA that wishes 309 to respond to negotiation requests, and a set of functions to 310 support negotiating steps. Once a negotiation starts, it is a 311 symmetric process with both sides sending successive objective 312 values to each other until agreement is reached (or the 313 negotiation fails). 315 * A synchronization function, by which an ASA can request the 316 current value of an objective from a counterpart ASA. With this, 317 there is a corresponding listening function for an ASA that wishes 318 to respond to synchronization requests. Unlike negotiation, 319 synchronization is an asymmetric process in which the listener 320 sends a single objective value to the requester. 322 * A flood function, by which an ASA can cause the current value of 323 an objective to be flooded throughout the AN so that any ASA can 324 receive it. 326 For further details and some additional housekeeping functions, see 327 [RFC8991]. 329 This API is intended to support the various interactions expected 330 between most ASAs, such as the interactions outlined in Section 2. 331 However, if ASAs require additional communication between themselves, 332 they can do so using any desired protocol, even just a TLS session if 333 that meets their needs. One option is to use GRASP discovery and 334 synchronization as a rendez-vous mechanism between two ASAs, passing 335 communication parameters such as a TCP port number via GRASP. As 336 noted above, the ACP can secure such communications, unless there is 337 a good reason to do otherwise. 339 3.4. Interaction with policy mechanisms 341 At the time of writing, the policy mechanisms for the ANI are 342 undefined. In particular, the use of declarative policies (aka 343 Intents) for the definition and management of ASA's behaviors remains 344 a research topic [I-D.irtf-nmrg-ibn-concepts-definitions]. 346 In the cases where ASAs are defined as closed control loops, the 347 specifications defined in [ZSM009-1] regarding imperative and 348 declarative goal statements may be applicable. 350 In the ANI, policy dissemination is expected to operate by an 351 information distribution mechanism (e.g. via GRASP [RFC8990]) that 352 can reach all autonomic nodes, and therefore every ASA. However, 353 each ASA must be capable of operating "out of the box" in the absence 354 of locally defined policy, so every ASA implementation must include 355 carefully chosen default values and settings for all policy 356 parameters. 358 4. Interaction with Non-Autonomic Components 360 An ASA, to have any external effects, must also interact with non- 361 autonomic components of the node where it is installed. For example, 362 an ASA whose purpose is to manage a resource must interact with that 363 resource. An ASA whose purpose is to manage an entity that is 364 already managed by local software must interact with that software. 365 For example, if such management is performed by NETCONF [RFC6241], 366 the ASA must interact directly with the NETCONF server in the same 367 node, to avoid any inconsistency between configuration changes 368 delivered via NETCONF and configuration changes made by the ASA. 370 In an environment where systems are virtualized and specialized using 371 techniques such as network function virtualization or network 372 slicing, there will be a design choice whether ASAs are deployed once 373 per physical node or once per virtual context. A related issue is 374 whether the ANI as a whole is deployed once on a physical network, or 375 whether several virtual ANIs are deployed. This aspect needs to be 376 considered by the ASA designer. 378 5. Design of GRASP Objectives 380 The general rules for the format of GRASP objectives, their names, 381 and IANA registration are given in [RFC8990]. Additionally, that 382 document discusses various general considerations for the design of 383 objectives, which are not repeated here. However, note that the 384 GRASP protocol, like HTTP, does not provide transactional integrity. 385 In particular, steps in a GRASP negotiation are not idempotent. The 386 design of a GRASP objective and the logic flow of the ASA should take 387 this into account. One approach, which should be used when possible, 388 is to design objectives with idempotent semantics. If this is not 389 possible, typically if an ASA is allocating part of a shared resource 390 to other ASAs, it needs to ensure that the same part of the resource 391 is not allocated twice. The easiest way is to run only one 392 negotiation at a time. If an ASA is capable of overlapping several 393 negotiations, it must avoid interference between these negotiations. 395 Negotiations will always end, normally because one end or the other 396 declares success or failure. If this does not happen, either a 397 timeout or exhaustion of the loop count will occur. The definition 398 of a GRASP objective should describe a specific negotiation policy if 399 it is not self-evident. 401 GRASP allows a 'dry run' mode of negotiation, where a negotiation 402 session follows its normal course but is not committed at either end 403 until a subsequent live negotiation session. If 'dry run' mode is 404 defined for the objective, its specification, and every 405 implementation, must consider what state needs to be saved following 406 a dry run negotiation, such that a subsequent live negotiation can be 407 expected to succeed. It must be clear how long this state is kept, 408 and what happens if the live negotiation occurs after this state is 409 deleted. An ASA that requests a dry run negotiation must take 410 account of the possibility that a successful dry run is followed by a 411 failed live negotiation. Because of these complexities, the dry run 412 mechanism should only be supported by objectives and ASAs where there 413 is a significant benefit from it. 415 The actual value field of an objective is limited by the GRASP 416 protocol definition to any data structure that can be expressed in 417 Concise Binary Object Representation (CBOR) [RFC8949]. For some 418 objectives, a single data item will suffice; for example an integer, 419 a floating point number or a UTF-8 string. For more complex cases, a 420 simple tuple structure such as [item1, item2, item3] could be used. 421 Since CBOR is closely linked to JSON, it is also rather easy to 422 define an objective whose value is a JSON structure. The formats 423 acceptable by the GRASP API will limit the options in practice. A 424 generic solution is for the API to accept and deliver the value field 425 in raw CBOR, with the ASA itself encoding and decoding it via a CBOR 426 library. 428 The maximum size of the value field of an objective is limited by the 429 GRASP maximum message size. If the default maximum size specified by 430 [RFC8990] is not enough, the specification of the objective must 431 indicate the required maximum message size, both for unicast and 432 multicast messages. 434 A mapping from YANG to CBOR is defined by [I-D.ietf-core-yang-cbor]. 435 Subject to the size limit defined for GRASP messages, nothing 436 prevents objectives using YANG in this way. 438 6. Life Cycle 440 In simple cases, Autonomic functions could be permanent, in the sense 441 that ASAs are shipped as part of a product and persist throughout the 442 product's life. However, in complex cases, a more likely situation 443 is that ASAs need to be installed or updated dynamically, because of 444 new requirements or bugs. This section describes one approach to the 445 resulting life cycle. 447 Because continuity of service is fundamental to autonomic networking, 448 the process of seamlessly replacing a running instance of an ASA with 449 a new version needs to be part of the ASA's design. The implication 450 of service continuity on the design of ASAs can be illustrated along 451 the three main phases of the ASA life-cycle, namely Installation, 452 Instantiation and Operation. 454 +--------------+ 455 Undeployed ------>| |------> Undeployed 456 | Installed | 457 +-->| |---+ 458 Mandate | +--------------+ | Receives a 459 is revoked | +--------------+ | Mandate 460 +---| |<--+ 461 | Instantiated | 462 +-->| |---+ 463 set | +--------------+ | set 464 down | +--------------+ | up 465 +---| |<--+ 466 | Operational | 467 | | 468 +--------------+ 470 Figure 1: Life cycle of an Autonomic Service Agent 472 6.1. Installation phase 474 We define "installation" to mean that a piece of software is loaded 475 into a device, along with any necessary libraries, but is not yet 476 activated. 478 Before being able to instantiate and run ASAs, the operator will 479 first provision the infrastructure with the sets of ASA software 480 corresponding to its needs and objectives. The provisioning of the 481 infrastructure is realized in the installation phase and consists in 482 installing (or checking the availability of) the pieces of software 483 of the different ASAs in a set of Installation Hosts. Installation 484 Hosts may be nodes of an autonomic network, or servers dedicated to 485 storing the software images of the different ASAs. 487 There are 3 properties applicable to the installation of ASAs: 489 The dynamic installation property allows installing an ASA on 490 demand, on any hosts compatible with the ASA. 492 The decoupling property allows controlling resources of an autonomic 493 node from a remote ASA, i.e. an ASA installed on a host machine 494 different from the autonomic node resources. 496 The multiplicity property allows controlling multiple sets of 497 resources from a single ASA. 499 These three properties are very important in the context of the 500 installation phase as their variations condition how the ASA could be 501 installed on the infrastructure. 503 6.1.1. Installation phase inputs and outputs 505 Inputs are: 507 [ASA of a given type] specifies which ASAs to install, 509 [Installation_target_Infrastructure] specifies the candidate 510 Installation Hosts, 512 [ASA placement function, e.g. under which criteria/constraints as 513 defined by the operator] specifies how the installation phase shall 514 meet the operator's needs and objectives for the provision of the 515 infrastructure. In the coupled mode, the placement function is 516 not necessary as in that case, ASA can only be installed together 517 with the autonomic nodes; whereas in the decoupled mode, the 518 placement function is mandatory, even though it can be as simple 519 as an explicit list of Installation Hosts. 521 The main output of the installation phase is an up-to-date list of 522 installed ASAs which corresponds to [list of ASAs] installed on [list 523 of Installation Hosts]. This output is also useful for the 524 coordination function and corresponds to the static interaction map 525 (see Section 7). 527 The condition to validate in order to pass to next phase is to ensure 528 that [list of ASAs] are well installed on [list of Installation 529 Hosts]. The state of the ASAs at the end of the installation phase 530 is: installed. (not instantiated). The following minimum set of 531 primitives to support the installation of ASAs could be: install(list 532 of ASAs, Installation_target_Infrastructure, ASA placement function), 533 and uninstall (list of ASAs). 535 6.2. Instantiation phase 537 We define "instantiation" as the operation of creating a single ASA 538 instance from the corresponding piece of installed software. 540 Once the ASAs are installed on the appropriate hosts in the network, 541 these ASAs may start to operate. From the operator viewpoint, an 542 operating ASA means the ASA manages the network resources as per the 543 objectives given. At the ASA local level, operating means executing 544 their control loop/algorithm. 546 But right before that, there are two things to take into 547 consideration. First, there is a difference between (1) having a 548 piece of code available to run on a host and (2) having an agent 549 based on this piece of code running inside the host. Second, in a 550 coupled case, determining which resources are controlled by an ASA is 551 straightforward (the ASA runs on the same autonomic node and 552 resources it is controlling); in a decoupled mode determining this is 553 a bit more complex: a starting agent will have to either discover the 554 set of resources it ought to control, or such information has to be 555 communicated to the ASA. 557 The instantiation phase of an ASA covers both these aspects: starting 558 the agent piece of code (when this does not start automatically) and 559 determining which resources have to be controlled (when this is not 560 straightforward). 562 6.2.1. Operator's goal 564 Through this phase, the operator wants to control its autonomic 565 network regarding at least two aspects: 567 1 determine the scope of autonomic functions by instructing which of 568 the network resources have to be managed by which autonomic 569 function (and more precisely by which release of the ASA software 570 code, e.g., version number or provider), 572 2 determine how the autonomic functions are organized by 573 instantiating a set of ASA across one or more autonomic nodes and 574 instructing them accordingly about the other ASAs in the set as 575 necessary. 577 In this phase, the operator may also want to set goals for autonomic 578 functions, e.g., by configuring GRASP objectives. 580 The operator's goal can be summarized in an instruction to the ANIMA 581 ecosystem matching the following format: 583 [instances of ASAs of a given type] ready to control 584 [Instantiation_target_Infrastructure] with 585 [Instantiation_target_parameters] 587 6.2.2. Instantiation phase inputs and outputs 589 Inputs are: 591 [instances of ASAs of a given type] that specifies which ASAs to 592 instantiate 594 [Instantiation_target_Infrastructure] that specifies which are the 595 resources to be managed by the autonomic function, this can be the 596 whole network or a subset of it like a domain a technology segment 597 or even a specific list of resources, 599 [Instantiation_target_parameters] that specifies which are the GRASP 600 objectives to be sent to ASAs (e.g., an optimization target) 602 Outputs are: 604 [Set of ASAs - Resources relations] describing which resources are 605 managed by which ASA instances, this is not a formal message, but 606 a resulting configuration of a set of ASAs. 608 6.2.3. Instantiation phase requirements 610 The instructions described in Section 6.2 could be either: 612 {sent to a targeted ASA} In which case, the receiving Agent will 613 have to manage the specified list of 614 [Instantiation_target_Infrastructure], with the 615 [Instantiation_target_parameters]. 617 {broadcast to all ASAs} In which case, the ASAs would collectively 618 determine from the list which Agent(s) would handle which 619 [Instantiation_target_Infrastructure], with the 620 [Instantiation_target_parameters]. 622 These instructions may be grouped in an ASA Instance Mandate as a 623 specific data structure. The specification of such an ASA Instance 624 Mandate is beyond the scope of this document. 626 The conclusion of this instantiation phase is a set of ASA instances 627 ready to operate. These ASA instances are characterized by the 628 resources they manage, the metrics being monitored and the actions 629 that can be executed (like modifying certain parameters values). The 630 description of the ASA instance may be defined in an ASA Instance 631 Manifest data structure. The specification of such an ASA Instance 632 Manifest is beyond the scope of this document. 634 The ASA Instance Manifest does not only serve informational purposes 635 such as acknowledgement of successful instantiation to the operator, 636 but is also necessary for further autonomous operations with: 638 * the coordination entities (see [I-D.ciavaglia-anima-coordination]) 639 * collaborative entities with purposes such as to establish 640 knowledge exchange (some ASAs may produce knowledge or monitor 641 metrics that would be useful for other ASAs) 643 6.3. Operation phase 645 Note: This section is to be further developed in future revisions of 646 the document, especially the implications on the design of ASAs. 648 During the Operation phase, the operator can: 650 Activate/Deactivate ASA: meaning enabling those to execute their 651 autonomic loop or not. 653 Modify ASAs targets: meaning setting them different objectives. 655 Modify ASAs managed resources: by updating the instance mandate 656 which would specify different set of resources to manage (only 657 applicable to decoupled ASAs). 659 During the Operation phase, running ASAs can interact with other 660 ASAs: 662 in order to exchange knowledge (e.g. an ASA providing traffic 663 predictions to a load balancing ASA) 665 in order to collaboratively reach an objective (e.g. ASAs 666 pertaining to the same autonomic function targeted to manage a 667 network domain will collaborate - in the case of a load balancing 668 function, by modifying the link metrics according to the 669 neighboring resource loads) 671 During the Operation phase, running ASAs are expected to apply 672 coordination schemes as per Section 7. 674 The ASA life-cycle is discussed in more detail in "A Day in the Life 675 of an Autonomic Function" [I-D.peloso-anima-autonomic-function]. 677 7. Coordination between Autonomic Functions 679 Some autonomic functions will be completely independent of each 680 other. However, others are at risk of interfering with each other - 681 for example, two different optimization functions might both attempt 682 to modify the same underlying parameter in different ways. In a 683 complete system, a method is needed of identifying ASAs that might 684 interfere with each other and coordinating their actions when 685 necessary. This issue is considered in "Autonomic Functions 686 Coordination" [I-D.ciavaglia-anima-coordination]. 688 8. Coordination with Traditional Management Functions 690 Some ASAs will have functions that overlap with existing 691 configuration tools and network management mechanisms such as command 692 line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF. This is 693 of course an existing problem whenever multiple configuration tools 694 are in use by the NOC. Each ASA designer will need to consider this 695 issue and how to avoid clashes and inconsistencies. Some specific 696 considerations for interaction with OAM tools are given in [RFC8368]. 697 As another example, [RFC8992] describes how autonomic management of 698 IPv6 prefixes can interact with prefix delegation via DHCPv6. The 699 description of a GRASP objective and of an ASA using it should 700 include a discussion of any such interactions. 702 9. Data Models 704 Management functions often include a data model, quite likely to be 705 expressed in a formal notation such as YANG. This aspect should not 706 be an afterthought in the design of an ASA. To the contrary, the 707 design of the ASA and of its GRASP objectives should match the data 708 model; as noted in Section 5, YANG serialized as CBOR may be used 709 directly as the value of a GRASP objective. 711 10. Robustness 713 It is of great importance that all components of an autonomic system 714 are highly robust. Although ASA designers should aim for their 715 component to never fail, it is more important to design the ASA to 716 assume that failures will happen and to gracefully recover from those 717 failures when they occur. Hence, this section lists various aspects 718 of robustness that ASA designers should consider 720 1. If despite all precautions, an ASA does encounter a fatal error, 721 it should in any case restart automatically and try again. To 722 mitigate a hard loop in case of persistent failure, a suitable 723 pause should be inserted before such a restart. The length of 724 the pause depends on the use case. 726 2. If a newly received or calculated value for a parameter falls 727 out of bounds, the corresponding parameter should be either left 728 unchanged or restored to a safe value. 730 3. If a GRASP synchronization or negotiation session fails for any 731 reason, it may be repeated after a suitable pause. The length 732 of the pause depends on the use case. 734 4. If a session fails repeatedly, the ASA should consider that its 735 peer has failed, and cause GRASP to flush its discovery cache 736 and repeat peer discovery. 738 5. In any case, it may be prudent to repeat discovery periodically, 739 depending on the use case. 741 6. Any received GRASP message should be checked. If it is wrongly 742 formatted, it should be ignored. Within a unicast session, an 743 Invalid message (M_INVALID) may be sent. This function may be 744 provided by the GRASP implementation itself. 746 7. Any received GRASP objective should be checked. Basic 747 formatting errors like invalid CBOR will likely be detected by 748 GRASP itself, but the ASA is responsible for checking the 749 precise syntax and semantics of a received objective. If it is 750 wrongly formatted, it should be ignored. Within a negotiation 751 session, a Negotiation End message (M_END) with a Decline option 752 (O_DECLINE) should be sent. An ASA may log such events for 753 diagnostic purposes. 755 8. On the other hand, the definitions of GRASP objectives are very 756 likely to be extended, using the flexibility of CBOR or JSON. 757 Therefore, ASAs should be able to deal gracefully with unknown 758 components within the values of objectives. 760 9. If an ASA receives either an Invalid message (M_INVALID) or a 761 Negotiation End message (M_END) with a Decline option 762 (O_DECLINE), one possible reason is that the peer ASA does not 763 support a new feature of either GRASP or of the objective in 764 question. In such a case the ASA may choose to repeat the 765 operation concerned without using that new feature. 767 10. All other possible exceptions should be handled in an orderly 768 way. There should be no such thing as an unhandled exception 769 (but see point 1 above). 771 At a slightly more general level, ASAs are not services in 772 themselves, but they automate services. This has a fundamental 773 impact on how to design robust ASAs. In general, when an ASA 774 observes a particular state [1] of operations of the services/ 775 resources it controls, it typically aims to improve this state to a 776 better state, say [2]. Ideally, the ASA is built so that it can 777 ensure that any error encountered can still lead to returning to [1] 778 instead of a state [3] which is worse than [1]. One example instance 779 of this principle is "make-before-break" used in reconfiguration of 780 routing protocols in manual operations. This principle of operations 781 can accordingly be coded into the operation of an ASA. The GRASP dry 782 run option mentioned in Section 5 is another tool helpful for this 783 ASA design goal of "test-before-make". 785 11. Security Considerations 787 ASAs are intended to run in an environment that is protected by the 788 Autonomic Control Plane [RFC8994], admission to which depends on an 789 initial secure bootstrap process such as [RFC8995]. Such an ACP can 790 provide keying material for mutual authentication between ASAs as 791 well as confidential communication channels for messages between 792 ASAs. In some deployments, a secure partition of the link layer 793 might be used instead. However, this does not relieve ASAs of 794 responsibility for security. When ASAs configure or manage network 795 elements outside the ACP, potentially in a different physical node, 796 they must interact with other non-autonomic software components to 797 perform their management functions. The details are specific to each 798 case, but this has an important security implication. An ASA might 799 act as a loophole by which the managed entity could penetrate the 800 security boundary of the ANI. Thus, ASAs must be designed to avoid 801 such loopholes, and should if possible operate in an unprivileged 802 mode. In particular, they must use secure techniques and carefully 803 validate any incoming information. This will apply in particular 804 when an ASA interacts with a management component such as a NETCONF 805 server. 807 A similar situation will arise if an ASA acts as a gateway between 808 two separate autonomic networks, i.e. it has access to two separate 809 ACPs. Such an ASA must also be designed to avoid loopholes and to 810 validate incoming information from both sides. 812 As appropriate to their specific functions, ASAs should take account 813 of relevant privacy considerations [RFC6973]. 815 The initial version of the autonomic infrastructure assumes that all 816 autonomic nodes are trusted by virtue of their admission to the ACP. 817 ASAs are therefore trusted to manipulate any GRASP objective, simply 818 because they are installed on a node that has successfully joined the 819 ACP. In the general case, a node may have multiple roles and a role 820 may use multiple ASAs, each using multiple GRASP objectives. 821 Additional mechanisms for the fine-grained authorization of nodes and 822 ASAs to manipulate specific GRASP objectives could be designed. 823 Independently of this, interfaces between ASAs and the router 824 configuration and monitoring services of the node can be subject to 825 authentication that provides more fine-grained authorization for 826 specific services. These additional authentication parameters could 827 be passed to an ASA during its instantiation phase. 829 12. IANA Considerations 831 This document makes no request of the IANA. 833 13. Acknowledgements 835 Useful comments were received from Michael Behringer, Toerless 836 Eckert, Alex Galis, Bing Liu, Michael Richardson, and other members 837 of the ANIMA WG. 839 14. References 841 14.1. Normative References 843 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 844 Representation (CBOR)", STD 94, RFC 8949, 845 DOI 10.17487/RFC8949, December 2020, 846 . 848 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 849 Autonomic Signaling Protocol (GRASP)", RFC 8990, 850 DOI 10.17487/RFC8990, May 2021, 851 . 853 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 854 Autonomic Control Plane (ACP)", RFC 8994, 855 DOI 10.17487/RFC8994, May 2021, 856 . 858 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 859 and K. Watsen, "Bootstrapping Remote Secure Key 860 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 861 May 2021, . 863 14.2. Informative References 865 [DeMola06] De Mola, F. and R. Quitadamo, "An Agent Model for Future 866 Autonomic Communications", Proceedings of the 7th WOA 2006 867 Workshop From Objects to Agents 51-59, September 2006. 869 [GANA13] "Autonomic network engineering for the self-managing 870 Future Internet (AFI): GANA Architectural Reference Model 871 for Autonomic Networking, Cognitive Networking and Self- 872 Management.", April 2013, 873 . 876 [Huebscher08] 877 Huebscher, M. C. and J. A. McCann, "A survey of autonomic 878 computing--degrees, models, and applications", ACM 879 Computing Surveys (CSUR) Volume 40 Issue 3 DOI: 880 10.1145/1380584.1380585, August 2008. 882 [I-D.ciavaglia-anima-coordination] 883 Ciavaglia, L. and P. Pierre, "Autonomic Functions 884 Coordination", Work in Progress, Internet-Draft, draft- 885 ciavaglia-anima-coordination-01, 21 March 2016, 886 . 889 [I-D.ietf-core-yang-cbor] 890 Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M. 891 Richardson, "CBOR Encoding of Data Modeled with YANG", 892 Work in Progress, Internet-Draft, draft-ietf-core-yang- 893 cbor-17, 25 October 2021, 894 . 897 [I-D.irtf-nmrg-ibn-concepts-definitions] 898 Clemm, A., Ciavaglia, L., Granville, L. Z., and J. 899 Tantsura, "Intent-Based Networking - Concepts and 900 Definitions", Work in Progress, Internet-Draft, draft- 901 irtf-nmrg-ibn-concepts-definitions-05, 2 September 2021, 902 . 905 [I-D.peloso-anima-autonomic-function] 906 Pierre, P. and L. Ciavaglia, "A Day in the Life of an 907 Autonomic Function", Work in Progress, Internet-Draft, 908 draft-peloso-anima-autonomic-function-01, 21 March 2016, 909 . 912 [IPJ] Behringer, M., Bormann, C., Carpenter, B. E., Eckert, T., 913 Campos Nobre, J., Jiang, S., Li, Y., and M. C. Richardson, 914 "Autonomic Networking Gets Serious", The Internet Protocol 915 Journal Volume: 24 , Issue: 3, ISSN 1944-1134, Page(s): 2 916 - 18, October 2021, . 919 [Movahedi12] 920 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 921 Survey of Autonomic Network Architectures and Evaluation 922 Criteria", IEEE Communications Surveys & Tutorials Volume: 923 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 924 Page(s): 464 - 490, 2012. 926 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 927 and A. Bierman, Ed., "Network Configuration Protocol 928 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 929 . 931 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 932 Morris, J., Hansen, M., and R. Smith, "Privacy 933 Considerations for Internet Protocols", RFC 6973, 934 DOI 10.17487/RFC6973, July 2013, 935 . 937 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 938 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 939 Networking: Definitions and Design Goals", RFC 7575, 940 DOI 10.17487/RFC7575, June 2015, 941 . 943 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 944 Chaining (SFC) Architecture", RFC 7665, 945 DOI 10.17487/RFC7665, October 2015, 946 . 948 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 949 Control Plane for Stable Connectivity of Network 950 Operations, Administration, and Maintenance (OAM)", 951 RFC 8368, DOI 10.17487/RFC8368, May 2018, 952 . 954 [RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., 955 Aranda, P., and P. Lynch, "Network Virtualization Research 956 Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, 957 . 959 [RFC8991] Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong, 960 "GeneRic Autonomic Signaling Protocol Application Program 961 Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991, 962 May 2021, . 964 [RFC8992] Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun, 965 "Autonomic IPv6 Edge Prefix Management in Large-Scale 966 Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021, 967 . 969 [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, 970 L., and J. Nobre, "A Reference Model for Autonomic 971 Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, 972 . 974 [ZSM009-1] "Zero-touch network and Service Management (ZSM); Closed- 975 Loop Automation; Part 1: Enablers", June 2021, 976 . 979 Appendix A. Change log 981 This section is to be removed before publishing as an RFC. 983 draft-ietf-anima-asa-guidelines-04, 2021-11-20: 985 * Added terminology appendix 986 * Further clarified discussion of asynch operations 987 * Other editorial improvements from AD review 989 draft-ietf-anima-asa-guidelines-03, 2021-11-07: 991 * Added security consideration for gateway ASAs 992 * Cite IPJ article 994 draft-ietf-anima-asa-guidelines-02, 2021-09-13: 996 * Added note on maximum message size. 997 * Editorial fixes 999 draft-ietf-anima-asa-guidelines-01, 2021-06-27: 1001 * Incorporated shepherd's review comments 1002 * Editorial fixes 1004 draft-ietf-anima-asa-guidelines-00, 2020-11-14: 1006 * Adopted by WG 1007 * Editorial fixes 1009 draft-carpenter-anima-asa-guidelines-09, 2020-07-25: 1011 * Additional text on future authorization. 1012 * Editorial fixes 1014 draft-carpenter-anima-asa-guidelines-08, 2020-01-10: 1016 * Introduced notion of autonomic ecosystem. 1017 * Minor technical clarifications. 1018 * Converted to v3 format. 1020 draft-carpenter-anima-asa-guidelines-07, 2019-07-17: 1022 * Improved explanation of threading vs event-loop 1023 * Other editorial improvements. 1025 draft-carpenter-anima-asa-guidelines-06, 2018-01-07: 1027 * Expanded and improved example logic flow. 1028 * Editorial corrections. 1030 draft-carpenter-anima-asa-guidelines-05, 2018-06-30: 1032 * Added section on relationshp with non-autonomic components. 1033 * Editorial corrections. 1035 draft-carpenter-anima-asa-guidelines-04, 2018-03-03: 1037 * Added note about simple ASAs. 1038 * Added note about NFV/SFC services. 1039 * Improved text about threading v event loop model 1040 * Added section about coordination with traditional tools. 1041 * Added appendix with example logic flow. 1043 draft-carpenter-anima-asa-guidelines-03, 2017-10-25: 1045 * Added details on life cycle. 1046 * Added details on robustness. 1047 * Added co-authors. 1049 draft-carpenter-anima-asa-guidelines-02, 2017-07-01: 1051 * Expanded description of event-loop case. 1052 * Added note about 'dry run' mode. 1054 draft-carpenter-anima-asa-guidelines-01, 2017-01-06: 1056 * More sections filled in. 1058 draft-carpenter-anima-asa-guidelines-00, 2016-09-30: 1060 * Initial version 1062 Appendix B. Terminology 1064 This appendix summarises various acronyms and terminology used in the 1065 document. Where no other reference is given, please consult 1066 [RFC8993] or [RFC7575]. 1068 * Autonomic: Self-managing (self-configuring, self-protecting, self- 1069 healing, self-optimizing), but allowing high-level guidance by a 1070 central entity such as a NOC. 1071 * Autonomic Function: A function that adapts on its own to a 1072 changing environment. 1073 * Autonomic Node: A node that employs autonomic functions. 1074 * Autonomic Domain: A collection of autonomic nodes that 1075 collaborate. 1076 * ACP: Autonomic Control Plane [RFC8994]. 1077 * AN: Autonomic Network, which underlies an autonomic domain. 1078 * ANI: Autonomic Network Infrastructure. 1079 * ASA: Autonomic Service Agent. An agent implemented on an 1080 autonomic node that implements an autonomic function, either in 1081 part (in the case of a distributed function) or whole. 1082 * CBOR: Concise Binary Object Representation [RFC8949]. 1083 * GRASP: Generic Autonomic Signaling Protocol [RFC8990]. 1084 * GRASP API: GRASP Application Programming Interface [RFC8991]. 1085 * NOC: Network Operations Center [RFC8368]. 1086 * Objective: A GRASP technical objective is a data structure whose 1087 main contents are a name and a value. The value consists of a 1088 single configurable parameter or a set of parameters of some kind. 1089 [RFC8990]. 1091 Appendix C. Example Logic Flows 1093 This appendix describes generic logic flows for an Autonomic Service 1094 Agent (ASA) for resource management. Note that these are 1095 illustrative examples, and in no sense requirements. As long as the 1096 rules of GRASP are followed, a real implementation could be 1097 different. The reader is assumed to be familiar with GRASP [RFC8990] 1098 and its conceptual API [RFC8991]. 1100 A complete autonomic function for a resource would consist of a 1101 number of instances of the ASA placed at relevant points in a 1102 network. Specific details will of course depend on the resource 1103 concerned. One example is IP address prefix management, as specified 1104 in [RFC8992]. In this case, an instance of the ASA would exist in 1105 each delegating router. 1107 An underlying assumption is that there is an initial source of the 1108 resource in question, referred to here as an origin ASA. The other 1109 ASAs, known as delegators, obtain supplies of the resource from the 1110 origin, and then delegate quantities of the resource to consumers 1111 that request it, and recover it when no longer needed. 1113 Another assumption is there is a set of network wide policy 1114 parameters, which the origin will provide to the delegators. These 1115 parameters will control how the delegators decide how much resource 1116 to provide to consumers. Thus, the ASA logic has two operating 1117 modes: origin and delegator. When running as an origin, it starts by 1118 obtaining a quantity of the resource from the NOC, and it acts as a 1119 source of policy parameters, via both GRASP flooding and GRASP 1120 synchronization. (In some scenarios, flooding or synchronization 1121 alone might be sufficient, but this example includes both.) 1123 When running as a delegator, it starts with an empty resource pool, 1124 it acquires the policy parameters by GRASP synchronization, and it 1125 delegates quantities of the resource to consumers that request it. 1126 Both as an origin and as a delegator, when its pool is low it seeks 1127 quantities of the resource by requesting GRASP negotiation with peer 1128 ASAs. When its pool is sufficient, it hands out resource to peer 1129 ASAs in response to negotiation requests. Thus, over time, the 1130 initial resource pool held by the origin will be shared among all the 1131 delegators according to demand. 1133 In theory a network could include any number of origins and any 1134 number of delegators, with the only condition being that each 1135 origin's initial resource pool is unique. A realistic scenario is to 1136 have exactly one origin and as many delegators as you like. A 1137 scenario with no origin is useless. 1139 An implementation requirement is that resource pools are kept in 1140 stable storage. Otherwise, if a delegator exits for any reason, all 1141 the resources it has obtained or delegated are lost. If an origin 1142 exits, its entire spare pool is lost. The logic for using stable 1143 storage and for crash recovery is not included in the pseudocode 1144 below. 1146 The description below does not implement GRASP's 'dry run' function. 1147 That would require temporarily marking any resource handed out in a 1148 dry run negotiation as reserved, until either the peer obtains it in 1149 a live run, or a suitable timeout expires. 1151 The main data structures used in each instance of the ASA are: 1153 * The resource_pool, for example an ordered list of available 1154 resources. Depending on the nature of the resource, units of 1155 resource are split when appropriate, and a background garbage 1156 collector recombines split resources if they are returned to the 1157 pool. 1159 * The delegated_list, where a delegator stores the resources it has 1160 given to consumers routers. 1162 Possible main logic flows are below, using a threaded implementation 1163 model. The transformation to an event loop model should be apparent 1164 - each thread would correspond to one event in the event loop. 1166 The GRASP objectives are as follows: 1168 * ["EX1.Resource", flags, loop_count, value] where the value depends 1169 on the resource concerned, but will typically include its size and 1170 identification. 1172 * ["EX1.Params", flags, loop_count, value] where the value will be, 1173 for example, a JSON object defining the applicable parameters. 1175 In the outline logic flows below, these objectives are represented 1176 simply by their names. 1178 1180 MAIN PROGRAM: 1182 Create empty resource_pool (and an associated lock) 1183 Create empty delegated_list 1184 Determine whether to act as origin 1185 if origin: 1186 Obtain initial resource_pool contents from NOC 1187 Obtain value of EX1.Params from NOC 1188 Register ASA with GRASP 1189 Register GRASP objectives EX1.Resource and EX1.Params 1190 if origin: 1191 Start FLOODER thread to flood EX1.Params 1192 Start SYNCHRONIZER listener for EX1.Params 1193 Start MAIN_NEGOTIATOR thread for EX1.Resource 1194 if not origin: 1195 Obtain value of EX1.Params from GRASP flood or synchronization 1196 Start DELEGATOR thread 1197 Start GARBAGE_COLLECTOR thread 1198 do forever: 1199 good_peer = none 1200 if resource_pool is low: 1201 Calculate amount A of resource needed 1202 Discover peers using GRASP M_DISCOVER / M_RESPONSE 1203 if good_peer in peers: 1204 peer = good_peer 1205 else: 1206 peer = #any choice among peers 1207 grasp.request_negotiate("EX1.Resource", peer) 1208 i.e., send M_REQ_NEG 1209 Wait for response (M_NEGOTIATE, M_END or M_WAIT) 1210 if OK: 1211 if offered amount of resource sufficient: 1212 Send M_END + O_ACCEPT #negotiation succeeded 1213 Add resource to pool 1214 good_peer = peer 1215 else: 1216 Send M_END + O_DECLINE #negotiation failed 1217 sleep() #or periodic timer, depending on application scenario 1219 MAIN_NEGOTIATOR thread: 1221 do forever: 1222 grasp.listen_negotiate("EX1.Resource") 1223 i.e., wait for M_REQ_NEG 1224 Start a separate new NEGOTIATOR thread for requested amount A 1226 NEGOTIATOR thread: 1228 Request resource amount A from resource_pool 1229 if not OK: 1230 while not OK and A > Amin: 1231 A = A-1 1232 Request resource amount A from resource_pool 1233 if OK: 1234 Offer resource amount A to peer by GRASP M_NEGOTIATE 1235 if received M_END + O_ACCEPT: 1236 #negotiation succeeded 1237 elif received M_END + O_DECLINE or other error: 1238 #negotiation failed 1239 else: 1240 Send M_END + O_DECLINE #negotiation failed 1241 #thread exits 1243 DELEGATOR thread: 1245 do forever: 1246 Wait for request or release for resource amount A 1247 if request: 1248 Get resource amount A from resource_pool 1249 if OK: 1250 Delegate resource to consumer 1251 Record in delegated_list 1252 else: 1253 Signal failure to consumer 1254 Signal main thread that resource_pool is low 1255 else: 1256 Delete resource from delegated_list 1257 Return resource amount A to resource_pool 1259 SYNCHRONIZER thread: 1261 do forever: 1262 Wait for M_REQ_SYN message for EX1.Params 1263 Reply with M_SYNCH message for EX1.Params 1265 FLOODER thread: 1267 do forever: 1268 Send M_FLOOD message for EX1.Params 1269 sleep() #or periodic timer, depending on application scenario 1271 GARBAGE_COLLECTOR thread: 1273 do forever: 1274 Search resource_pool for adjacent resources 1275 Merge adjacent resources 1276 sleep() #or periodic timer, depending on application scenario 1278 1280 Authors' Addresses 1282 Brian Carpenter 1283 School of Computer Science 1284 University of Auckland 1285 PB 92019 1286 Auckland 1142 1287 New Zealand 1289 Email: brian.e.carpenter@gmail.com 1291 Laurent Ciavaglia 1292 Rakuten Mobile 1293 Paris 1294 France 1296 Email: laurent.ciavaglia@rakuten.com 1298 Sheng Jiang 1299 Huawei Technologies Co., Ltd 1300 Q14 Huawei Campus 1301 156 Beiqing Road 1302 Hai-Dian District 1303 Beijing 1304 100095 1305 China 1307 Email: jiangsheng@huawei.com 1309 Pierre Peloso 1310 Nokia 1311 Villarceaux 1312 91460 Nozay 1313 France 1315 Email: pierre.peloso@nokia.com