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