doc: Add RFC documents

1 files changed, 1275 insertions, 0 deletions

diff --git a/doc/rfc/rfc9222.txt b/doc/rfc/rfc9222.txt
new file mode 100644
index 0000000..eded0cc
--- /dev/null
+++ b/doc/rfc/rfc9222.txt
@@ -0,0 +1,1275 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      B. Carpenter
+Request for Comments: 9222                             Univ. of Auckland
+Category: Informational                                     L. Ciavaglia
+ISSN: 2070-1721                                           Rakuten Mobile
+                                                                S. Jiang
+                                            Huawei Technologies Co., Ltd
+                                                               P. Peloso
+                                                                   Nokia
+                                                              March 2022
+
+
+                Guidelines for Autonomic Service Agents
+
+Abstract
+
+   This document proposes guidelines for the design of Autonomic Service
+   Agents for autonomic networks.  Autonomic Service Agents, together
+   with the Autonomic Network Infrastructure, the Autonomic Control
+   Plane, and the GeneRic Autonomic Signaling Protocol, constitute base
+   elements of an autonomic networking ecosystem.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9222.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Logical Structure of an Autonomic Service Agent
+   4.  Interaction with the Autonomic Networking Infrastructure
+     4.1.  Interaction with the Security Mechanisms
+     4.2.  Interaction with the Autonomic Control Plane
+     4.3.  Interaction with GRASP and its API
+     4.4.  Interaction with Policy Mechanisms
+   5.  Interaction with Non-autonomic Components and Systems
+   6.  Design of GRASP Objectives
+   7.  Life Cycle
+     7.1.  Installation Phase
+       7.1.1.  Installation Phase Inputs and Outputs
+     7.2.  Instantiation Phase
+       7.2.1.  Operator's Goal
+       7.2.2.  Instantiation Phase Inputs and Outputs
+       7.2.3.  Instantiation Phase Requirements
+     7.3.  Operation Phase
+     7.4.  Removal Phase
+   8.  Coordination and Data Models
+     8.1.  Coordination between Autonomic Functions
+     8.2.  Coordination with Traditional Management Functions
+     8.3.  Data Models
+   9.  Robustness
+   10. Security Considerations
+   11. IANA Considerations
+   12. References
+     12.1.  Normative References
+     12.2.  Informative References
+   Appendix A.  Example Logic Flows
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document proposes guidelines for the design of Autonomic Service
+   Agents (ASAs) in the context of an Autonomic Network (AN) based on
+   the Autonomic Network Infrastructure (ANI) outlined in the autonomic
+   networking reference model [RFC8993].  This infrastructure makes use
+   of the Autonomic Control Plane (ACP) [RFC8994] and the GeneRic
+   Autonomic Signaling Protocol (GRASP) [RFC8990].  A general
+   introduction to this environment may be found at [IPJ], which also
+   includes explanatory diagrams, and a summary of terminology is in
+   Section 2.
+
+   This document is a contribution to the description of an autonomic
+   networking ecosystem, recognizing that a deployable autonomic network
+   needs more than just ACP and GRASP implementations.  Such an
+   autonomic network must achieve management tasks that a Network
+   Operations Center (NOC) cannot readily achieve manually, such as
+   continuous resource optimization or automated fault detection and
+   repair.  These tasks, and other management automation goals, are
+   described at length in [RFC7575].  The net result should be
+   significant operational improvement.  To achieve this, the autonomic
+   networking ecosystem must include at least a library of ASAs and
+   corresponding GRASP technical objective definitions.  A GRASP
+   objective [RFC8990] is a data structure whose main contents are a
+   name and a value.  The value consists of a single configurable
+   parameter or a set of parameters of some kind.
+
+   There must also be tools to deploy and oversee ASAs, and integration
+   with existing operational mechanisms [RFC8368].  However, this
+   document focuses on the design of ASAs, with some reference to
+   implementation and operational aspects.
+
+   There is considerable literature about autonomic agents with a
+   variety of proposals about how they should be characterized.  Some
+   examples are [DEMOLA06], [HUEBSCHER08], [MOVAHEDI12], and [GANA13].
+   However, for the present document, the basic definitions and goals
+   for autonomic networking given in [RFC7575] apply.  According to RFC
+   7575, an Autonomic Service Agent is "An agent implemented on an
+   autonomic node that implements an autonomic function, either in part
+   (in the case of a distributed function) or whole."
+
+   ASAs must be distinguished from other forms of software components.
+   They are components of network or service management; they do not in
+   themselves provide services to end users.  They do, however, provide
+   management services to network operators and administrators.  For
+   example, the services envisaged for network function virtualization
+   (NFV) [NFV] or for service function chaining (SFC) [RFC7665] might be
+   managed by an ASA rather than by traditional configuration tools.
+
+   Another example is that an existing script running within a router to
+   locally monitor or configure functions or services could be upgraded
+   to an ASA that could communicate with peer scripts on neighboring or
+   remote routers.  A high-level API will allow such upgraded scripts to
+   take full advantage of the secure ACP and the discovery, negotiation,
+   and synchronization features of GRASP.  Familiar tasks such as
+   configuring an Interior Gateway Protocol (IGP) on neighboring routers
+   or even exchanging IGP security keys could be performed securely in
+   this way.  This document mainly addresses issues affecting quite
+   complex ASAs, but initially, the most useful ASAs may in fact be
+   rather simple evolutions of existing scripts.
+
+   The reference model [RFC8993] for autonomic networks explains further
+   the functionality of ASAs by adding the following:
+
+   |  [An ASA is] a process that makes use of the features provided by
+   |  the ANI to achieve its own goals, usually including interaction
+   |  with other ASAs via GRASP [RFC8990] or otherwise.  Of course, it
+   |  also interacts with the specific targets of its function, using
+   |  any suitable mechanism.  Unless its function is very simple, the
+   |  ASA will need to handle overlapping asynchronous operations.  It
+   |  may therefore be a quite complex piece of software in its own
+   |  right, forming part of the application layer above the ANI.
+
+   As mentioned, there will certainly be simple ASAs that manage a
+   single objective in a straightforward way and do not need
+   asynchronous operations.  In nodes where computing power and memory
+   space are limited, ASAs should run at a much lower frequency than the
+   primary workload, so CPU load should not be a big issue, but memory
+   footprint in a constrained node is certainly a concern.  ASAs
+   installed in constrained devices will have limited functionality.  In
+   such cases, many aspects of the current document do not apply.
+   However, in the general case, an ASA may be a relatively complex
+   software component that will in many cases control and monitor
+   simpler entities in the same or remote host(s).  For example, a
+   device controller that manages tens or hundreds of simple devices
+   might contain a single ASA.
+
+   The remainder of this document offers guidance on the design of
+   complex ASAs.  Some of the material may be familiar to those
+   experienced in distributed fault-tolerant and real-time control
+   systems.  Robustness and security are of particular importance in
+   autonomic networks and are discussed in Sections 9 and 10.
+
+2.  Terminology
+
+   This section summarizes various acronyms and terminology used in the
+   document.  Where no other reference is given, please consult
+   [RFC8993] or [RFC7575].
+
+   Autonomic:  self-managing (self-configuring, self-protecting, self-
+      healing, self-optimizing), but allowing high-level guidance by a
+      central entity such as a NOC
+
+   Autonomic Function:  a function that adapts on its own to a changing
+      environment
+
+   Autonomic Node:  a node that employs autonomic functions
+
+   ACP:  Autonomic Control Plane [RFC8994]
+
+   AN:  Autonomic Network; a network of autonomic nodes, which interact
+      directly with each other
+
+   ANI:  Autonomic Network Infrastructure
+
+   ASA:  Autonomic Service Agent; an agent installed on an autonomic
+      node that implements an autonomic function, either partially (in
+      the case of a distributed function) or completely
+
+   BRSKI:  Bootstrapping Remote Secure Key Infrastructure [RFC8995]
+
+   CBOR:  Concise Binary Object Representation[RFC8949]
+
+   GRASP:  GeneRric Autonomic Signaling Protocol [RFC8990]
+
+   GRASP API:  GRASP Application Programming Interface [RFC8991]
+
+   NOC:  Network Operations Center [RFC8368]
+
+   Objective:  A GRASP technical objective is a data structure whose
+      main contents are a name and a value.  The value consists of a
+      single configurable parameter or a set of parameters of some kind
+      [RFC8990].
+
+3.  Logical Structure of an Autonomic Service Agent
+
+   As mentioned above, all but the simplest ASAs will need to support
+   asynchronous operations.  Different programming environments support
+   asynchronicity in different ways.  In this document, we use an
+   explicit multi-threading model to describe operations.  This is
+   illustrative, and alternatives to multi-threading are discussed in
+   detail in connection with the GRASP API (see Section 4.3).
+
+   A typical ASA will have a main thread that performs various initial
+   housekeeping actions such as:
+
+   *  obtain authorization credentials, if needed
+
+   *  register the ASA with GRASP
+
+   *  acquire relevant policy parameters
+
+   *  declare data structures for relevant GRASP objectives
+
+   *  register with GRASP those objectives that it will actively manage
+
+   *  launch a self-monitoring thread
+
+   *  enter its main loop
+
+   The logic of the main loop will depend on the details of the
+   autonomic function concerned.  Whenever asynchronous operations are
+   required, extra threads may be launched.  Examples of such threads
+   include:
+
+   *  repeatedly flood an objective to the AN so that any ASA can
+      receive the objective's latest value
+
+   *  accept incoming synchronization requests for an objective managed
+      by this ASA
+
+   *  accept incoming negotiation requests for an objective managed by
+      this ASA, and then conduct the resulting negotiation with the
+      counterpart ASA
+
+   *  manage subsidiary non-autonomic devices directly
+
+   These threads should all either exit after their job is done or enter
+   a wait state for new work to avoid wasting system resources.
+
+   According to the degree of parallelism needed by the application,
+   some of these threads might be launched in multiple instances.  In
+   particular, if negotiation sessions with other ASAs are expected to
+   be long or to involve wait states, the ASA designer might allow for
+   multiple simultaneous negotiating threads, with appropriate use of
+   queues and synchronization primitives to maintain consistency.
+
+   The main loop itself could act as the initiator of synchronization
+   requests or negotiation requests when the ASA needs data or resources
+   from other ASAs.  In particular, the main loop should watch for
+   changes in policy parameters that affect its operation and, if
+   appropriate, occasionally refresh authorization credentials.  It
+   should also do whatever is required to avoid unnecessary resource
+   consumption, for example, by limiting its frequency of execution.
+
+   The self-monitoring thread is of considerable importance.  Failure of
+   autonomic service agents is highly undesirable.  To a large extent,
+   this depends on careful coding and testing, with no unhandled error
+   returns or exceptions, but if there is nevertheless some sort of
+   failure, the self-monitoring thread should detect it, fix it if
+   possible, and, in the worst case, restart the entire ASA.
+
+   Appendix A presents some example logic flows in informal pseudocode.
+
+4.  Interaction with the Autonomic Networking Infrastructure
+
+4.1.  Interaction with the Security Mechanisms
+
+   An ASA by definition runs in an autonomic node.  Before any normal
+   ASAs are started, such nodes must be bootstrapped into the autonomic
+   network's secure key infrastructure, typically in accordance with
+   [RFC8995].  This key infrastructure will be used to secure the ACP
+   (next section) and may be used by ASAs to set up additional secure
+   interactions with their peers, if needed.
+
+   Note that the secure bootstrap process itself incorporates simple
+   special-purpose ASAs that use a restricted mode of GRASP (Section 4
+   of [RFC8995]).
+
+4.2.  Interaction with the Autonomic Control Plane
+
+   In a normal autonomic network, ASAs will run as clients of the ACP,
+   which will provide a fully secured network environment for all
+   communication with other ASAs, in most cases mediated by GRASP (next
+   section).
+
+   Note that the ACP formation process itself incorporates simple
+   special-purpose ASAs that use a restricted mode of GRASP (Section 6.4
+   of [RFC8994]).
+
+4.3.  Interaction with GRASP and its API
+
+   In a node where a significant number of ASAs are installed, GRASP
+   [RFC8990] is likely to run as a separate process with its API
+   [RFC8991] available in user space.  Thus, ASAs may operate without
+   special privilege, unless they need it for other reasons.  The ASA's
+   view of GRASP is built around GRASP objectives (Section 6), defined
+   as data structures containing administrative information such as the
+   objective's unique name, and its current value.  The format and size
+   of the value is not restricted by the protocol, except that it must
+   be possible to serialize it for transmission in Concise Binary Object
+   Representation (CBOR) [RFC8949], subject only to GRASP's maximum
+   message size as discussed in Section 6.
+
+   As discussed in Section 3, GRASP is an asynchronous protocol, and
+   this document uses a multi-threading model to describe operations.
+   In many programming environments, an "event loop" model is used
+   instead, in which case each thread would be implemented as an event
+   handler called in turn by the main loop.  For this case, the GRASP
+   API must provide non-blocking calls and possibly support callbacks.
+   This topic is discussed in more detail in [RFC8991], and other
+   asynchronicity models are also possible.  Whenever necessary, the
+   GRASP session identifier will be used to distinguish simultaneous
+   operations.
+
+   The GRASP API should offer the following features:
+
+   *  Registration functions, so that an ASA can register itself and the
+      objectives that it manages.
+
+   *  A discovery function, by which an ASA can discover other ASAs
+      supporting a given objective.
+
+   *  A negotiation request function, by which an ASA can start
+      negotiation of an objective with a counterpart ASA.  With this,
+      there is a corresponding listening function for an ASA that wishes
+      to respond to negotiation requests and a set of functions to
+      support negotiating steps.  Once a negotiation starts, it is a
+      symmetric process with both sides sending successive objective
+      values to each other until agreement is reached (or the
+      negotiation fails).
+
+   *  A synchronization function, by which an ASA can request the
+      current value of an objective from a counterpart ASA.  With this,
+      there is a corresponding listening function for an ASA that wishes
+      to respond to synchronization requests.  Unlike negotiation,
+      synchronization is an asymmetric process in which the listener
+      sends a single objective value to the requester.
+
+   *  A flood function, by which an ASA can cause the current value of
+      an objective to be flooded throughout the AN so that any ASA can
+      receive it.
+
+   For further details and some additional housekeeping functions, see
+   [RFC8991].
+
+   The GRASP API is intended to support the various interactions
+   expected between most ASAs, such as the interactions outlined in
+   Section 3.  However, if ASAs require additional communication between
+   themselves, they can do so directly over the ACP to benefit from its
+   security.  One option is to use GRASP discovery and synchronization
+   as a rendezvous mechanism between two ASAs, passing communication
+   parameters such as a TCP port number via GRASP.  The use of TLS over
+   the ACP for such communications is advisable, as described in
+   Section 6.9.2 of [RFC8994].
+
+4.4.  Interaction with Policy Mechanisms
+
+   At the time of writing, the policy mechanisms for the ANI are
+   undefined.  In particular, the use of declarative policies (aka
+   Intents) for the definition and management of an ASA's behaviors
+   remains a research topic [IBN-CONCEPTS].
+
+   In the cases where ASAs are defined as closed control loops, the
+   specifications defined in [ZSM009-1] regarding imperative and
+   declarative goal statements may be applicable.
+
+   In the ANI, policy dissemination is expected to operate by an
+   information distribution mechanism (e.g., via GRASP [RFC8990]) that
+   can reach all autonomic nodes and therefore every ASA.  However, each
+   ASA must be capable of operating "out of the box" in the absence of
+   locally defined policy, so every ASA implementation must include
+   carefully chosen default values and settings for all policy
+   parameters.
+
+5.  Interaction with Non-autonomic Components and Systems
+
+   To have any external effects, an ASA must also interact with non-
+   autonomic components of the node where it is installed.  For example,
+   an ASA whose purpose is to manage a resource must interact with that
+   resource.  An ASA managing an entity that is also managed by local
+   software must interact with that software.  For example, if such
+   management is performed by NETCONF [RFC6241], the ASA must interact
+   with the NETCONF server as an independent NETCONF client in the same
+   node to avoid any inconsistency between configuration changes
+   delivered via NETCONF and configuration changes made by the ASA.
+
+   In an environment where systems are virtualized and specialized using
+   techniques such as network function virtualization or network
+   slicing, there will be a design choice whether ASAs are deployed once
+   per physical node or once per virtual context.  A related issue is
+   whether the ANI as a whole is deployed once on a physical network or
+   whether several virtual ANIs are deployed.  This aspect needs to be
+   considered by the ASA designer.
+
+6.  Design of GRASP Objectives
+
+   The design of an ASA will often require the design of a new GRASP
+   objective.  The general rules for the format of GRASP objectives,
+   their names, and IANA registration are given in [RFC8990].
+   Additionally, that document discusses various general considerations
+   for the design of objectives, which are not repeated here.  However,
+   note that GRASP, like HTTP, does not provide transactional integrity.
+   In particular, steps in a GRASP negotiation are not idempotent.  The
+   design of a GRASP objective and the logic flow of the ASA should take
+   this into account.  One approach, which should be used when possible,
+   is to design objectives with idempotent semantics.  If this is not
+   possible, typically if an ASA is allocating part of a shared resource
+   to other ASAs, it needs to ensure that the same part of the resource
+   is not allocated twice.  The easiest way is to run only one
+   negotiation at a time.  If an ASA is capable of overlapping several
+   negotiations, it must avoid interference between these negotiations.
+
+   Negotiations will always end, normally because one end or the other
+   declares success or failure.  If this does not happen, either a
+   timeout or exhaustion of the loop count will occur.  The definition
+   of a GRASP objective should describe a specific negotiation policy if
+   it is not self-evident.
+
+   GRASP allows a "dry run" mode of negotiation, where a negotiation
+   session follows its normal course but is not committed at either end
+   until a subsequent live negotiation session.  If dry run mode is
+   defined for the objective, its specification, and every
+   implementation, must consider what state needs to be saved following
+   a dry run negotiation, such that a subsequent live negotiation can be
+   expected to succeed.  It must be clear how long this state is kept
+   and what happens if the live negotiation occurs after this state is
+   deleted.  An ASA that requests a dry run negotiation must take
+   account of the possibility that a successful dry run is followed by a
+   failed live negotiation.  Because of these complexities, the dry run
+   mechanism should only be supported by objectives and ASAs where there
+   is a significant benefit from it.
+
+   The actual value field of an objective is limited by the GRASP
+   protocol definition to any data structure that can be expressed in
+   Concise Binary Object Representation (CBOR) [RFC8949].  For some
+   objectives, a single data item will suffice, for example, an integer,
+   a floating point number, a UTF-8 string, or an arbitrary byte string.
+   For more complex cases, a simple tuple structure such as [item1,
+   item2, item3] could be used.  Since CBOR is closely linked to JSON,
+   it is also rather easy to define an objective whose value is a JSON
+   structure.  The formats acceptable by the GRASP API will limit the
+   options in practice.  A generic solution is for the API to accept and
+   deliver the value field in raw CBOR, with the ASA itself encoding and
+   decoding it via a CBOR library (Section 2.3.2.4 of [RFC8991]).
+
+   The maximum size of the value field of an objective is limited by the
+   GRASP maximum message size.  If the default maximum size specified as
+   GRASP_DEF_MAX_SIZE by [RFC8990] is not enough, the specification of
+   the objective must indicate the required maximum message size for
+   both unicast and multicast messages.
+
+   A mapping from YANG to CBOR is defined by [CBOR-YANG].  Subject to
+   the size limit defined for GRASP messages, nothing prevents
+   objectives transporting YANG in this way.
+
+   The flexibility of CBOR implies that the value field of many
+   objectives can be extended in service, to add additional information
+   or alternative content, especially if JSON-like structures are used.
+   This has consequences for the robustness of ASAs, as discussed in
+   Section 9.
+
+7.  Life Cycle
+
+   The ASA life cycle is discussed in [AUTONOMIC-FUNCTION], from which
+   the following text was derived.  It does not cover all details, and
+   some of the terms used would require precise definitions in a given
+   implementation.
+
+   In simple cases, autonomic functions could be permanent, in the sense
+   that ASAs are shipped as part of a product and persist throughout the
+   product's life.  However, in complex cases, a more likely situation
+   is that ASAs need to be installed or updated dynamically because of
+   new requirements or bugs.  This section describes one approach to the
+   resulting life cycle of individual ASAs.  It does not consider wider
+   issues such as updates of shared libraries.
+
+   Because continuity of service is fundamental to autonomic networking,
+   the process of seamlessly replacing a running instance of an ASA with
+   a new version needs to be part of the ASA's design.  The implication
+   of service continuity on the design of ASAs can be illustrated along
+   the three main phases of the ASA life cycle, namely installation,
+   instantiation, and operation.
+
+                     +--------------+
+   Undeployed ------>|              |------> Undeployed
+                     |  Installed   |
+                 +-->|              |---+
+        Mandate  |   +--------------+   | Receives a
+      is revoked |   +--------------+   |  Mandate
+                 +---|              |<--+
+                     | Instantiated |
+                 +-->|              |---+
+             set |   +--------------+   | set
+            down |   +--------------+   | up
+                 +---|              |<--+
+                     |  Operational |
+                     |              |
+                     +--------------+
+
+             Figure 1: Life Cycle of an Autonomic Service Agent
+
+7.1.  Installation Phase
+
+   We define "installation" to mean that a piece of software is loaded
+   into a device, along with any necessary libraries, but is not yet
+   activated.
+
+   Before being able to instantiate and run ASAs, the operator will
+   first provision the infrastructure with the sets of ASA software
+   corresponding to its needs and objectives.  Such software must be
+   checked for integrity and authenticity before installation.  The
+   provisioning of the infrastructure is realized in the installation
+   phase and consists of installing (or checking the availability of)
+   the pieces of software of the different ASAs in a set of Installation
+   Hosts within the autonomic network.
+
+   There are three properties applicable to the installation of ASAs:
+
+   *  The dynamic installation property allows installing an ASA on
+      demand, on any hosts compatible with the ASA.
+
+   *  The decoupling property allows an ASA on one machine to control
+      resources in another machine (known as "decoupled mode").
+
+   *  The multiplicity property allows controlling multiple sets of
+      resources from a single ASA.
+
+   These three properties are very important in the context of the
+   installation phase as their variations condition how the ASA could be
+   installed on the infrastructure.
+
+7.1.1.  Installation Phase Inputs and Outputs
+
+   Inputs are:
+
+   *  [ASA_type]: specifies which ASA to install.
+
+   *  [Installation_target_infrastructure]: specifies the candidate
+      installation Hosts.
+
+   *  [ASA_placement_function]: specifies how the installation phase
+      will meet the operator's needs and objectives for the provision of
+      the infrastructure.  This function is only useful in the decoupled
+      mode.  It can be as simple as an explicit list of hosts on which
+      the ASAs are to be installed, or it could consist of operator-
+      defined criteria and constraints.
+
+   The main output of the installation phase is a [List_of_ASAs]
+   installed on [List_of_hosts].  This output is also useful for the
+   coordination function where it acts as a static interaction map (see
+   Section 8.1).
+
+   The condition to validate in order to pass to next phase is to ensure
+   that [List_of_ASAs] are correctly installed on [List_of_hosts].  A
+   minimum set of primitives to support the installation of ASAs could
+   be the following: install (List_of_ASAs,
+   Installation_target_infrastructure, ASA_placement_function) and
+   uninstall (List_of_ASAs).
+
+7.2.  Instantiation Phase
+
+   We define "instantiation" as the operation of creating a single ASA
+   instance from the corresponding piece of installed software.
+
+   Once the ASAs are installed on the appropriate hosts in the network,
+   these ASAs may start to operate.  From the operator viewpoint, an
+   operating ASA means the ASA manages the network resources as per the
+   objectives given.  At the ASA local level, operating means executing
+   their control loop algorithm.
+
+   There are two aspects to take into consideration.  First, having a
+   piece of code installed and available to run on a host is not the
+   same as having an agent based on this piece of code running inside
+   the host.  Second, in a coupled case, determining which resources are
+   controlled by an ASA is straightforward (the ASA runs on the same
+   autonomic node as the resources it is controlling).  In a decoupled
+   mode, determining this is a bit more complex: a starting agent will
+   have to either discover the set of resources it ought to control, or
+   such information has to be communicated to the ASA.
+
+   The instantiation phase of an ASA covers both these aspects: starting
+   the agent code (when this does not start automatically) and
+   determining which resources have to be controlled (when this is not
+   straightforward).
+
+7.2.1.  Operator's Goal
+
+   Through this phase, the operator wants to control its autonomic
+   network regarding at least two aspects:
+
+   1.  determine the scope of autonomic functions by instructing which
+       network resources have to be managed by which autonomic function
+       (and more precisely by which release of the ASA software code,
+       e.g., version number or provider).
+
+   2.  determine how the autonomic functions are organized by
+       instantiating a set of ASAs across one or more autonomic nodes
+       and instructing them accordingly about the other ASAs in the set
+       as necessary.
+
+   In this phase, the operator may also want to set goals for autonomic
+   functions, e.g., by configuring GRASP objectives.
+
+   The operator's goal can be summarized in an instruction to the
+   autonomic ecosystem matching the following format, explained in
+   detail in the next sub-section:
+
+      [Instances_of_ASA_type] ready to control
+      [Instantiation_target_infrastructure] with
+      [Instantiation_target_parameters]
+
+7.2.2.  Instantiation Phase Inputs and Outputs
+
+   Inputs are:
+
+   *  [Instances_of_ASA_type]: specifies which ASAs to instantiate
+
+   *  [Instantiation_target_infrastructure]: specifies which resources
+      are to be managed by the autonomic function; this can be the whole
+      network or a subset of it like a domain, a physical segment, or
+      even a specific list of resources.
+
+   *  [Instantiation_target_parameters]: specifies which GRASP
+      objectives are to be sent to ASAs (e.g., an optimization target)
+
+   Outputs are:
+
+   *  [Set_of_ASA_resources_relations]: describes which resources are
+      managed by which ASA instances; this is not a formal message but a
+      resulting configuration log for a set of ASAs.
+
+7.2.3.  Instantiation Phase Requirements
+
+   The instructions described in Section 7.2 could be either of the
+   following:
+
+   *  Sent to a targeted ASA.  In this case, the receiving Agent will
+      have to manage the specified list of
+      [Instantiation_target_infrastructure], with the
+      [Instantiation_target_parameters].
+
+   *  Broadcast to all ASAs.  In this case, the ASAs would determine
+      from the list which ASAs would handle which
+      [Instantiation_target_infrastructure], with the
+      [Instantiation_target_parameters].
+
+   These instructions may be grouped as a specific data structure
+   referred to as an ASA Instance Mandate.  The specification of such an
+   ASA Instance Mandate is beyond the scope of this document.
+
+   The conclusion of this instantiation phase is a set of ASA instances
+   ready to operate.  These ASA instances are characterized by the
+   resources they manage, the metrics being monitored, and the actions
+   that can be executed (like modifying certain parameter values).  The
+   description of the ASA instance may be defined in an ASA Instance
+   Manifest data structure.  The specification of such an ASA Instance
+   Manifest is beyond the scope of this document.
+
+   The ASA Instance Manifest does not only serve informational purposes
+   such as acknowledgement of successful instantiation to the operator
+   but is also necessary for further autonomic operations with:
+
+   *  coordinated entities (see Section 8.1)
+
+   *  collaborative entities with purposes such as to establish
+      knowledge exchange (some ASAs may produce knowledge or monitor
+      metrics that would be useful for other ASAs)
+
+7.3.  Operation Phase
+
+   During the operation phase, the operator can:
+
+   *  activate/deactivate ASAs: enable/disable their autonomic loops
+
+   *  modify ASA targets: set different technical objectives
+
+   *  modify ASAs managed resources: update the Instance Mandate to
+      specify a different set of resources to manage (only applicable to
+      decoupled ASAs)
+
+   During the operation phase, running ASAs can interact with other
+   ASAs:
+
+   *  in order to exchange knowledge (e.g., an ASA providing traffic
+      predictions to a load balancing ASA)
+
+   *  in order to collaboratively reach an objective (e.g., ASAs
+      pertaining to the same autonomic function will collaborate, e.g.,
+      in the case of a load balancing function, by modifying link
+      metrics according to neighboring resource loads)
+
+   During the operation phase, running ASAs are expected to apply
+   coordination schemes as per Section 8.1.
+
+7.4.  Removal Phase
+
+   When an ASA is removed from service and uninstalled, the above steps
+   are reversed.  It is important that its data, especially any security
+   key material, is purged.
+
+8.  Coordination and Data Models
+
+8.1.  Coordination between Autonomic Functions
+
+   Some autonomic functions will be completely independent of each
+   other.  However, others are at risk of interfering with each other;
+   for example, two different optimization functions might both attempt
+   to modify the same underlying parameter in different ways.  In a
+   complete system, a method is needed for identifying ASAs that might
+   interfere with each other and coordinating their actions when
+   necessary.
+
+8.2.  Coordination with Traditional Management Functions
+
+   Some ASAs will have functions that overlap with existing
+   configuration tools and network management mechanisms such as
+   command-line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF.
+   This is, of course, an existing problem whenever multiple
+   configuration tools are in use by the NOC.  Each ASA designer will
+   need to consider this issue and how to avoid clashes and
+   inconsistencies in various deployment scenarios.  Some specific
+   considerations for interaction with OAM tools are given in [RFC8368].
+   As another example, [RFC8992] describes how autonomic management of
+   IPv6 prefixes can interact with prefix delegation via DHCPv6.  The
+   description of a GRASP objective and of an ASA using it should
+   include a discussion of any such interactions.
+
+8.3.  Data Models
+
+   Management functions often include a shared data model, quite likely
+   to be expressed in a formal notation such as YANG.  This aspect
+   should not be an afterthought in the design of an ASA.  To the
+   contrary, the design of the ASA and of its GRASP objectives should
+   match the data model; as noted in Section 6, YANG serialized as CBOR
+   may be used directly as the value of a GRASP objective.
+
+9.  Robustness
+
+   It is of great importance that all components of an autonomic system
+   are highly robust.  Although ASA designers should aim for their
+   component to never fail, it is more important to design the ASA to
+   assume that failures will happen and to gracefully recover from those
+   failures when they occur.  Hence, this section lists various aspects
+   of robustness that ASA designers should consider:
+
+   1.   If despite all precautions, an ASA does encounter a fatal error,
+        it should in any case restart automatically and try again.  To
+        mitigate a loop in case of persistent failure, a suitable pause
+        should be inserted before such a restart.  The length of the
+        pause depends on the use case; randomization and exponential
+        backoff should be considered.
+
+   2.   If a newly received or calculated value for a parameter falls
+        out of bounds, the corresponding parameter should be either left
+        unchanged or restored to a value known to be safe in all
+        configurations.
+
+   3.   If a GRASP synchronization or negotiation session fails for any
+        reason, it may be repeated after a suitable pause.  The length
+        of the pause depends on the use case; randomization and
+        exponential backoff should be considered.
+
+   4.   If a session fails repeatedly, the ASA should consider that its
+        peer has failed, and it should cause GRASP to flush its
+        discovery cache and repeat peer discovery.
+
+   5.   In any case, it may be prudent to repeat discovery periodically,
+        depending on the use case.
+
+   6.   Any received GRASP message should be checked.  If it is wrongly
+        formatted, it should be ignored.  Within a unicast session, an
+        Invalid message (M_INVALID) may be sent.  This function may be
+        provided by the GRASP implementation itself.
+
+   7.   Any received GRASP objective should be checked.  Basic
+        formatting errors like invalid CBOR will likely be detected by
+        GRASP itself, but the ASA is responsible for checking the
+        precise syntax and semantics of a received objective.  If it is
+        wrongly formatted, it should be ignored.  Within a negotiation
+        session, a Negotiation End message (M_END) with a Decline option
+        (O_DECLINE) should be sent.  An ASA may log such events for
+        diagnostic purposes.
+
+   8.   On the other hand, the definitions of GRASP objectives are very
+        likely to be extended, using the flexibility of CBOR or JSON.
+        Therefore, ASAs should be able to deal gracefully with unknown
+        components within the values of objectives.  The specification
+        of an objective should describe how unknown components are to be
+        handled (ignored, logged and ignored, or rejected as an error).
+
+   9.   If an ASA receives either an Invalid message (M_INVALID) or a
+        Negotiation End message (M_END) with a Decline option
+        (O_DECLINE), one possible reason is that the peer ASA does not
+        support a new feature of either GRASP or the objective in
+        question.  In such a case, the ASA may choose to repeat the
+        operation concerned without using that new feature.
+
+   10.  All other possible exceptions should be handled in an orderly
+        way.  There should be no such thing as an unhandled exception
+        (but see point 1 above).
+
+   At a slightly more general level, ASAs are not services in
+   themselves, but they automate services.  This has a fundamental
+   impact on how to design robust ASAs.  In general, when an ASA
+   observes a particular state (1) of operations of the services/
+   resources it controls, it typically aims to improve this state to a
+   better state, say (2).  Ideally, the ASA is built so that it can
+   ensure that any error encountered can still lead to returning to (1)
+   instead of a state (3), which is worse than (1).  One example
+   instance of this principle is "make-before-break" used in
+   reconfiguration of routing protocols in manual operations.  This
+   principle of operations can accordingly be coded into the operation
+   of an ASA.  The GRASP dry run option mentioned in Section 6 is
+   another tool helpful for this ASA design goal of "test-before-make".
+
+10.  Security Considerations
+
+   ASAs are intended to run in an environment that is protected by the
+   Autonomic Control Plane [RFC8994], admission to which depends on an
+   initial secure bootstrap process such as BRSKI [RFC8995].  Those
+   documents describe security considerations relating to the use of and
+   properties provided by the ACP and BRSKI, respectively.  Such an ACP
+   can provide keying material for mutual authentication between ASAs as
+   well as confidential communication channels for messages between
+   ASAs.  In some deployments, a secure partition of the link layer
+   might be used instead.  GRASP itself has significant security
+   considerations [RFC8990].  However, this does not relieve ASAs of
+   responsibility for security.  When ASAs configure or manage network
+   elements outside the ACP, potentially in a different physical node,
+   they must interact with other non-autonomic software components to
+   perform their management functions.  The details are specific to each
+   case, but this has an important security implication.  An ASA might
+   act as a loophole by which the managed entity could penetrate the
+   security boundary of the ANI.  Thus, ASAs must be designed to avoid
+   loopholes such as passing on executable code or proxying unverified
+   commands and should, if possible, operate in an unprivileged mode.
+   In particular, they must use secure coding practices, e.g., carefully
+   validate all incoming information and avoid unnecessary elevation of
+   privilege.  This will apply in particular when an ASA interacts with
+   a management component such as a NETCONF server.
+
+   A similar situation will arise if an ASA acts as a gateway between
+   two separate autonomic networks, i.e., it has access to two separate
+   ACPs.  Such an ASA must also be designed to avoid loopholes and to
+   validate incoming information from both sides.
+
+   As a reminder, GRASP does not intrinsically provide transactional
+   integrity (Section 6).
+
+   As appropriate to their specific functions, ASAs should take account
+   of relevant privacy considerations [RFC6973].
+
+   The initial version of the autonomic infrastructure assumes that all
+   autonomic nodes are trusted by virtue of their admission to the ACP.
+   ASAs are therefore trusted to manipulate any GRASP objective simply
+   because they are installed on a node that has successfully joined the
+   ACP.  In the general case, a node may have multiple roles, and a role
+   may use multiple ASAs, each using multiple GRASP objectives.
+   Additional mechanisms for the fine-grained authorization of nodes and
+   ASAs to manipulate specific GRASP objectives could be designed.
+   Meanwhile, we repeat that ASAs should run without special privilege
+   if possible.  Independently of this, interfaces between ASAs and the
+   router configuration and monitoring services of the node can be
+   subject to authentication that provides more fine-grained
+   authorization for specific services.  These additional authentication
+   parameters could be passed to an ASA during its instantiation phase.
+
+11.  IANA Considerations
+
+   This document has no IANA actions.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
+              Representation (CBOR)", STD 94, RFC 8949,
+              DOI 10.17487/RFC8949, December 2020,
+              <https://www.rfc-editor.org/info/rfc8949>.
+
+   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
+              Autonomic Signaling Protocol (GRASP)", RFC 8990,
+              DOI 10.17487/RFC8990, May 2021,
+              <https://www.rfc-editor.org/info/rfc8990>.
+
+   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
+              Autonomic Control Plane (ACP)", RFC 8994,
+              DOI 10.17487/RFC8994, May 2021,
+              <https://www.rfc-editor.org/info/rfc8994>.
+
+   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
+              and K. Watsen, "Bootstrapping Remote Secure Key
+              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
+              May 2021, <https://www.rfc-editor.org/info/rfc8995>.
+
+12.2.  Informative References
+
+   [AUTONOMIC-FUNCTION]
+              Pierre, P. and L. Ciavaglia, "A Day in the Life of an
+              Autonomic Function", Work in Progress, Internet-Draft,
+              draft-peloso-anima-autonomic-function-01, 21 March 2016,
+              <https://datatracker.ietf.org/doc/html/draft-peloso-anima-
+              autonomic-function-01>.
+
+   [CBOR-YANG]
+              Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
+              C., and M. Richardson, "CBOR Encoding of Data Modeled with
+              YANG", Work in Progress, Internet-Draft, draft-ietf-core-
+              yang-cbor-18, December 2021,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
+              yang-cbor-18>.
+
+   [DEMOLA06] De Mola, F. and R. Quitadamo, "Towards an Agent Model for
+              Future Autonomic Communications", Proceedings of the 7th
+              WOA 2006 Workshop From Objects to Agents 51-59, September
+              2006.
+
+   [GANA13]   ETSI, "Autonomic network engineering for the self-managing
+              Future Internet (AFI); Generic Autonomic Network
+              Architecture (An Architectural Reference Model for
+              Autonomic Networking, Cognitive Networking and Self-
+              Management)", GS AFI 002, V1.1.1, April 2013,
+              <https://www.etsi.org/deliver/etsi_gs/
+              AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.
+
+   [HUEBSCHER08]
+              Huebscher, M. C. and J. A. McCann, "A survey of autonomic
+              computing - degrees, models, and applications", ACM
+              Computing Surveys (CSUR), Volume 40, Issue 3,
+              DOI 10.1145/1380584.1380585, August 2008,
+              <https://doi.org/10.1145/1380584.1380585>.
+
+   [IBN-CONCEPTS]
+              Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
+              Tantsura, "Intent-Based Networking - Concepts and
+              Definitions", Work in Progress, Internet-Draft, draft-
+              irtf-nmrg-ibn-concepts-definitions-09, 24 March 2022,
+              <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
+              ibn-concepts-definitions-09>.
+
+   [IPJ]      Behringer, M., Bormann, C., Carpenter, B. E., Eckert, T.,
+              Campos Nobre, J., Jiang, S., Li, Y., and M. C. Richardson,
+              "Autonomic Networking Gets Serious", The Internet Protocol
+              Journal, Volume 24, Issue 3, Page(s) 2 - 18, ISSN
+              1944-1134, October 2021, <https://ipj.dreamhosters.com/wp-
+              content/uploads/2021/10/243-ipj.pdf>.
+
+   [MOVAHEDI12]
+              Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A
+              Survey of Autonomic Network Architectures and Evaluation
+              Criteria", IEEE Communications Surveys & Tutorials, Volume
+              14, Issue 2, Pages 464 - 490,
+              DOI 10.1109/SURV.2011.042711.00078, 2012,
+              <https://doi.org/10.1109/SURV.2011.042711.00078>.
+
+   [NFV]      ETSI, "Network Functions Virtualisation", SDN and OpenFlow
+              World Congress, October 2012,
+              <https://portal.etsi.org/NFV/NFV_White_Paper.pdf>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+              Morris, J., Hansen, M., and R. Smith, "Privacy
+              Considerations for Internet Protocols", RFC 6973,
+              DOI 10.17487/RFC6973, July 2013,
+              <https://www.rfc-editor.org/info/rfc6973>.
+
+   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
+              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
+              Networking: Definitions and Design Goals", RFC 7575,
+              DOI 10.17487/RFC7575, June 2015,
+              <https://www.rfc-editor.org/info/rfc7575>.
+
+   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
+              Chaining (SFC) Architecture", RFC 7665,
+              DOI 10.17487/RFC7665, October 2015,
+              <https://www.rfc-editor.org/info/rfc7665>.
+
+   [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
+              Control Plane for Stable Connectivity of Network
+              Operations, Administration, and Maintenance (OAM)",
+              RFC 8368, DOI 10.17487/RFC8368, May 2018,
+              <https://www.rfc-editor.org/info/rfc8368>.
+
+   [RFC8991]  Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong,
+              "GeneRic Autonomic Signaling Protocol Application Program
+              Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991,
+              May 2021, <https://www.rfc-editor.org/info/rfc8991>.
+
+   [RFC8992]  Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun,
+              "Autonomic IPv6 Edge Prefix Management in Large-Scale
+              Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021,
+              <https://www.rfc-editor.org/info/rfc8992>.
+
+   [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
+              L., and J. Nobre, "A Reference Model for Autonomic
+              Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
+              <https://www.rfc-editor.org/info/rfc8993>.
+
+   [ZSM009-1] ETSI, "Zero-touch network and Service Management (ZSM);
+              Closed-Loop Automation; Part 1: Enablers", GS ZSM 009-1,
+              Version 1.1.1, June 2021,
+              <https://www.etsi.org/deliver/etsi_gs/
+              ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf>.
+
+Appendix A.  Example Logic Flows
+
+   This appendix describes generic logic flows that combine to act as an
+   Autonomic Service Agent (ASA) for resource management.  Note that
+   these are illustrative examples and are in no sense requirements.  As
+   long as the rules of GRASP are followed, a real implementation could
+   be different.  The reader is assumed to be familiar with GRASP
+   [RFC8990] and its conceptual API [RFC8991].
+
+   A complete autonomic function for a distributed resource will consist
+   of a number of instances of the ASA placed at relevant points in a
+   network.  Specific details will, of course, depend on the resource
+   concerned.  One example is IP address prefix management, as specified
+   in [RFC8992].  In this case, an instance of the ASA will exist in
+   each delegating router.
+
+   An underlying assumption is that there is an initial source of the
+   resource in question, referred to here as an origin ASA.  The other
+   ASAs, known as delegators, obtain supplies of the resource from the
+   origin, delegate quantities of the resource to consumers that request
+   it, and recover it when no longer needed.
+
+   Another assumption is there is a set of network-wide policy
+   parameters, which the origin will provide to the delegators.  These
+   parameters will control how the delegators decide how much resource
+   to provide to consumers.  Thus, the ASA logic has two operating
+   modes: origin and delegator.  When running as an origin, it starts by
+   obtaining a quantity of the resource from the NOC, and it acts as a
+   source of policy parameters, via both GRASP flooding and GRASP
+   synchronization.  (In some scenarios, flooding or synchronization
+   alone might be sufficient, but this example includes both.)
+
+   When running as a delegator, it starts with an empty resource pool,
+   acquires the policy parameters by GRASP synchronization, and
+   delegates quantities of the resource to consumers that request it.
+   Both as an origin and as a delegator, when its pool is low, it seeks
+   quantities of the resource by requesting GRASP negotiation with peer
+   ASAs.  When its pool is sufficient, it hands out resource to peer
+   ASAs in response to negotiation requests.  Thus, over time, the
+   initial resource pool held by the origin will be shared among all the
+   delegators according to demand.
+
+   In theory, a network could include any number of origins and any
+   number of delegators, with the only condition being that each
+   origin's initial resource pool is unique.  A realistic scenario is to
+   have exactly one origin and as many delegators as you like.  A
+   scenario with no origin is useless.
+
+   An implementation requirement is that resource pools are kept in
+   stable storage.  Otherwise, if a delegator exits for any reason, all
+   the resources it has obtained or delegated are lost.  If an origin
+   exits, its entire spare pool is lost.  The logic for using stable
+   storage and for crash recovery is not included in the pseudocode
+   below, which focuses on communication between ASAs.  Since GRASP
+   operations are not intrinsically idempotent, data integrity during
+   failure scenarios is the responsibility of the ASA designer.  This is
+   a complex topic in its own right that is not discussed in the present
+   document.
+
+   The description below does not implement GRASP's dry run function.
+   That would require temporarily marking any resource handed out in a
+   dry run negotiation as reserved, until either the peer obtains it in
+   a live run, or a suitable timeout occurs.
+
+   The main data structures used in each instance of the ASA are:
+
+   *  resource_pool: an ordered list of available resources, for
+      example.  Depending on the nature of the resource, units of
+      resource are split when appropriate, and a background garbage
+      collector recombines split resources if they are returned to the
+      pool.
+
+   *  delegated_list: where a delegator stores the resources it has
+      given to subsidiary devices.
+
+   Possible main logic flows are below, using a threaded implementation
+   model.  As noted above, alternative approaches to asynchronous
+   operations are possible.  The transformation to an event loop model
+   should be apparent; each thread would correspond to one event in the
+   event loop.
+
+   The GRASP objectives are as follows:
+
+   *  ["EX1.Resource", flags, loop_count, value], where the value
+      depends on the resource concerned but will typically include its
+      size and identification.
+
+   *  ["EX1.Params", flags, loop_count, value], where the value will be,
+      for example, a JSON object defining the applicable parameters.
+
+   In the outline logic flows below, these objectives are represented
+   simply by their names.
+
+   MAIN PROGRAM:
+
+   Create empty resource_pool (and an associated lock)
+   Create empty delegated_list
+   Determine whether to act as origin
+   if origin:
+       Obtain initial resource_pool contents from NOC
+       Obtain value of EX1.Params from NOC
+   Register ASA with GRASP
+   Register GRASP objectives EX1.Resource and EX1.Params
+   if origin:
+       Start FLOODER thread to flood EX1.Params
+       Start SYNCHRONIZER listener for EX1.Params
+   Start MAIN_NEGOTIATOR thread for EX1.Resource
+   if not origin:
+       Obtain value of EX1.Params from GRASP flood or synchronization
+       Start DELEGATOR thread
+   Start GARBAGE_COLLECTOR thread
+   good_peer = none
+   do forever:
+       if resource_pool is low:
+           Calculate amount A of resource needed
+           Discover peers using GRASP M_DISCOVER / M_RESPONSE
+           if good_peer in peers:
+               peer = good_peer
+           else:
+               peer =  #any choice among peers
+           grasp.request_negotiate("EX1.Resource", peer)
+           #i.e., send negotiation request
+           Wait for response (M_NEGOTIATE, M_END or M_WAIT)
+           if OK:
+               if offered amount of resource sufficient:
+                   Send M_END + O_ACCEPT #negotiation succeeded
+                   Add resource to pool
+                   good_peer = peer      #remember this choice
+               else:
+                   Send M_END + O_DECLINE #negotiation failed
+                   good_peer = none       #forget this choice
+       sleep() #periodic timer suitable for application scenario
+
+   MAIN_NEGOTIATOR thread:
+
+   do forever:
+       grasp.listen_negotiate("EX1.Resource")
+       #i.e., wait for negotiation request
+       Start a separate new NEGOTIATOR thread for requested amount A
+
+   NEGOTIATOR thread:
+
+   Request resource amount A from resource_pool
+   if not OK:
+       while not OK and A > Amin:
+           A = A-1
+           Request resource amount A from resource_pool
+   if OK:
+       Offer resource amount A to peer by GRASP M_NEGOTIATE
+       if received M_END + O_ACCEPT:
+           #negotiation succeeded
+       elif received M_END + O_DECLINE or other error:
+           #negotiation failed
+           Return resource to resource_pool
+   else:
+       Send M_END + O_DECLINE #negotiation failed
+   #thread exits
+
+   DELEGATOR thread:
+
+   do forever:
+       Wait for request or release for resource amount A
+       if request:
+           Get resource amount A from resource_pool
+           if OK:
+               Delegate resource to consumer #atomic
+               Record in delegated_list      #operation
+           else:
+               Signal failure to consumer
+               Signal main thread that resource_pool is low
+       else:
+           Delete resource from delegated_list
+           Return resource amount A to resource_pool
+
+   SYNCHRONIZER thread:
+
+   do forever:
+       Wait for  M_REQ_SYN message for EX1.Params
+       Reply with M_SYNCH message for EX1.Params
+
+   FLOODER thread:
+
+   do forever:
+       Send M_FLOOD message for EX1.Params
+       sleep() #periodic timer suitable for application scenario
+
+   GARBAGE_COLLECTOR thread:
+
+   do forever:
+       Search resource_pool for adjacent resources
+       Merge adjacent resources
+       sleep() #periodic timer suitable for application scenario
+
+Acknowledgements
+
+   Valuable comments were received from Michael Behringer, Menachem
+   Dodge, Martin Dürst, Toerless Eckert, Thomas Fossati, Alex Galis,
+   Bing Liu, Benno Overeinder, Michael Richardson, Rob Wilton, and other
+   IESG members.
+
+Authors' Addresses
+
+   Brian Carpenter
+   School of Computer Science
+   University of Auckland
+   PB 92019
+   Auckland 1142
+   New Zealand
+   Email: brian.e.carpenter@gmail.com
+
+
+   Laurent Ciavaglia
+   Rakuten Mobile
+   Paris
+   France
+   Email: laurent.ciavaglia@rakuten.com
+
+
+   Sheng Jiang
+   Huawei Technologies Co., Ltd
+   Q14 Huawei Campus
+   156 Beiqing Road
+   Hai-Dian District
+   Beijing
+   100095
+   China
+   Email: jiangsheng@huawei.com
+
+
+   Pierre Peloso
+   Nokia
+   Villarceaux
+   91460 Nozay
+   France
+   Email: pierre.peloso@nokia.com