<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE rfcSYSTEM "rfc2629-xhtml.ent"> <?rfc toc="yes"?> <!-- You want a table of contents --> <?rfc symrefs="yes"?> <!-- Use symbolic labels for references --> <?rfc sortrefs="yes"?> <!-- This sorts the references --> <?rfc iprnotified="no" ?> <!-- Change to "yes" if someone has disclosed IPR for the draft --> <?rfc compact="yes"?> <!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"docName="draft-ietf-anima-asa-guidelines-07"number="9222" docName="draft-ietf-anima-asa-guidelines-7" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"><!-- xml2rfc v2v3 conversion 2.37.3 --><front> <title abbrev="ASA Guidelines">Guidelines for Autonomic Service Agents</title> <seriesInfoname="Internet-Draft" value="draft-ietf-anima-asa-guidelines-07"/>name="RFC" value="9222" /> <author fullname="Brian Carpenter"initials="B. E."initials="B." surname="Carpenter"> <organization abbrev="Univ. of Auckland"/> <address> <postal> <street>School of Computer Science</street> <street>University of Auckland</street> <street>PB 92019</street> <city>Auckland</city> <region/> <code>1142</code> <country>NZ</country> </postal> <email>brian.e.carpenter@gmail.com</email> </address> </author> <author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia"> <organization>Rakuten Mobile</organization> <address> <postal> <street/> <code/> <city>Paris</city> <region/> <country>FR</country> </postal> <email>laurent.ciavaglia@rakuten.com</email> </address> </author> <author fullname="Sheng Jiang" initials="S." surname="Jiang"> <organization>Huawei Technologies Co., Ltd</organization> <address> <postal> <street>Q14 Huawei Campus</street> <street>156 Beiqing Road</street> <street>Hai-Dian District</street> <city>Beijing</city> <code>100095</code> <country>CN</country> </postal> <email>jiangsheng@huawei.com</email> </address> </author> <author fullname="Pierre Peloso" initials="P." surname="Peloso"> <organization>Nokia</organization> <address> <postal> <street>Villarceaux</street> <code>91460</code> <city>Nozay</city> <region/> <country>FR</country> </postal> <email>pierre.peloso@nokia.com</email> </address> </author> <date month="March" year="2022"/> <keyword>GRASP</keyword> <keyword>autonomous</keyword> <keyword>autonomic function</keyword> <keyword>self-management</keyword> <keyword>autonomic networking</keyword> <keyword>autonomous operation</keyword> <keyword>self-management</keyword> <keyword>infrastructure</keyword> <keyword>intent</keyword> <keyword>autonomic control plane</keyword> <abstract> <t>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 ControlPlanePlane, and theGenericGeneRic Autonomic SignalingProtocolProtocol, constitute base elements of an autonomic networking ecosystem. </t> </abstract><note removeInRFC="true"> <name>Discussion Venue</name> <t>Discussion of this document takes place on the ANIMA mailing list (anima@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/anima/">https://mailarchive.ietf.org/arch/browse/anima/</eref>.</t> </note></front> <middle> <section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t> 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 <xref target="RFC8993"/>. This infrastructure makes use of the Autonomic Control Plane (ACP) <xref target="RFC8994"/> and theGenericGeneRic Autonomic Signaling Protocol (GRASP) <xref target="RFC8990"/>. A general introduction to this environment may be found at <xref target="IPJ"/>, which also includes explanatory diagrams, and a summary of terminology is in <xref target="terminology"/>.</t> <t> 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 <xref target="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 <xref target="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.</t> <t>There must also be tools to deploy and oversee ASAs, and integration with existing operational mechanisms <xref target="RFC8368"/>. However, this document focuses on the design of ASAs, with some reference to implementation and operational aspects. </t> <t>There isaconsiderable literature about autonomic agents with a variety of proposals about how they should be characterized. Some examples are <xreftarget="DeMola06"/>,target="DEMOLA06"/>, <xreftarget="Huebscher08"/>,target="HUEBSCHER08"/>, <xreftarget="Movahedi12"/>target="MOVAHEDI12"/>, and <xref target="GANA13"/>. However, for the present document, the basic definitions and goals for autonomic networking given in <xref target="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."</t> <t>ASAs must be distinguished from other forms of softwarecomponent.components. They are components of network or service management; they do not in themselves provide services to end users. Theydo howeverdo, however, provide management services to network operators and administrators. For example, the services envisaged for network functionvirtualisationvirtualization (NFV) <xref target="NFV"/> or for service function chaining (SFC) <xref target="RFC7665"/> might be managed by an ASA rather than by traditional configuration tools.</t> <t>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,negotiationnegotiation, 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, butinitiallyinitially, the most useful ASAs may in fact be rather simple evolutions of existing scripts.</t> <t>The reference model <xref target="RFC8993"/> for autonomic networks explains further the functionality of ASAs by adding"[Anthe following:</t> <blockquote> [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 viatheGRASPprotocol<xref target="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 theANI."</t>ANI. </blockquote> <t>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. </t> <t>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 <xref target="robust" format="counter"/> and <xref target="security" format="counter"/>.</t> </section> <section anchor="terminology" numbered="true" toc="default"> <name>Terminology</name> <t>This section summarizes various acronyms and terminology used in the document. Where no other reference is given, please consult <xref target="RFC8993"/> or <xref target="RFC7575"/>.</t> <dl> <dt>Autonomic: </dt> <dd>self-managing (self-configuring, self-protecting, self- healing, self-optimizing), but allowing high-level guidance by a central entity such as a NOC </dd> <dt>Autonomic Function: </dt> <dd>a function that adapts on its own to a changing environment </dd> <dt>Autonomic Node: </dt> <dd>a node that employs autonomic functions </dd> <dt>ACP: </dt> <dd>Autonomic Control Plane <xref target="RFC8994"/> </dd> <dt>AN: </dt> <dd>Autonomic Network; a network of autonomic nodes, which interact directly with each other </dd> <dt>ANI: </dt> <dd>Autonomic Network Infrastructure </dd> <dt>ASA: </dt> <dd>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 </dd> <dt>BRSKI: </dt> <dd>Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995"/> </dd> <dt>CBOR: </dt> <dd>Concise Binary Object Representation<xref target="RFC8949"/> </dd> <dt>GRASP: </dt> <dd>GeneRric Autonomic Signaling Protocol <xref target="RFC8990"/> </dd> <dt>GRASP API: </dt> <dd>GRASP Application Programming Interface <xref target="RFC8991"/> </dd> <dt>NOC: </dt> <dd>Network Operations Center <xreftarget="robust"/>target="RFC8368"/> </dd> <dt>Objective: </dt> <dd>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 <xreftarget="security"/>.</t>target="RFC8990"/>. </dd> </dl> </section> <section anchor="structure" numbered="true" toc="default"> <name>Logical Structure of an Autonomic Service Agent</name> <t>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 <xref target="api"/>). </t> <t>A typical ASA will have a main thread that performs various initial housekeeping actions such as: </t> <ul spacing="normal"><li>Obtain<li>obtain authorization credentials, ifneeded.</li> <li>Registerneeded</li> <li>register the ASA withGRASP.</li> <li>AcquireGRASP</li> <li>acquire relevant policyparameters.</li> <li>Declareparameters</li> <li>declare data structures for relevant GRASPobjectives.</li> <li>Registerobjectives</li> <li>register with GRASP those objectives that it will activelymanage.</li> <li>Launchmanage</li> <li>launch a self-monitoringthread.</li> <li>Enterthread</li> <li>enter its mainloop.</li>loop</li> </ul> <t>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: </t> <ul spacing="normal"><li>Repeatedly<li>repeatedly flood an objective to theAN,AN so that any ASA can receive the objective's latestvalue.</li> <li>Acceptvalue</li> <li>accept incoming synchronization requests for an objective managed by thisASA.</li> <li>AcceptASA</li> <li>accept incoming negotiation requests for an objective managed by this ASA, and then conduct the resulting negotiation with the counterpartASA.</li> <li>ManageASA</li> <li>manage subsidiary non-autonomic devicesdirectly.</li>directly</li> </ul> <t>These threads should all either exit after their job isdone,done or enter a wait state for newwork,work to avoid wasting system resources.</t> <t>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.</t> <t>The main loop itself could act as the initiator of synchronization requests or negotiationrequests,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 itsoperation, andoperation and, if appropriate, occasionally refresh authorization credentials. It should also do whatever is required to avoid unnecessary resource consumption, forexampleexample, by limiting its frequency of execution.</t> <t>The self-monitoring thread is of considerable importance. Failure of autonomic service agents is highly undesirable. To a largeextentextent, 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,andand, in the worstcasecase, restart the entire ASA.</t> <t><xref target="eg"/> presents some example logic flows in informal pseudocode.</t> </section> <section anchor="interact" numbered="true" toc="default"> <name>Interaction with the Autonomic Networking Infrastructure</name> <section anchor="interacts" numbered="true" toc="default"> <name>Interaction with thesecurity mechanisms</name>Security Mechanisms</name> <t>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 <xref target="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.</t> <t>Note that the secure bootstrap process itself incorporates simple special-purpose ASAs that use a restricted mode of GRASP(Section 4 of <xref target="RFC8995"/>).</t>(<xref target="RFC8995" section="4" sectionFormat="of"/>).</t> </section> <section anchor="interacta" numbered="true" toc="default"> <name>Interaction with the Autonomic Control Plane</name> <t>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).</t> <t>Note that the ACP formation process itself incorporates simple special-purpose ASAs that use a restricted mode of GRASP(Section 6.4 of <xref target="RFC8994"/>).</t>(<xref target="RFC8994" sectionFormat="of" section="6.4"/>).</t> </section> <section anchor="api" numbered="true" toc="default"> <name>Interaction with GRASP and its API</name> <t>In a node where a significant number of ASAs are installed, GRASP <xref target="RFC8990"/> is likely to run as a separate process with its API <xref target="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 (<xref target="objdes"/>), 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 toserialiseserialize it for transmission in Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>, subject only to GRASP's maximum message size as discussed in <xref target="objdes"/>.</t> <t>As discussed in <xref target="structure"/>, GRASP is an asynchronous protocol, and this document uses a multi-threading model to describe operations. In many programming environments, an'event loop'"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 <xref target="RFC8991"/>, and other asynchronicity models are also possible. Whenever necessary, the GRASP session identifier will be used to distinguish simultaneous operations.</t> <t>The GRASP API should offer the following features: </t> <ul spacing="normal"> <li>Registration functions, so that an ASA can register itself and the objectives that it manages.</li> <li>A discovery function, by which an ASA can discover other ASAs supporting a given objective.</li> <li>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 negotiationrequests,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).</li> <li>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.</li> <li>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.</li> </ul> <t>For further details and some additional housekeeping functions, see <xref target="RFC8991"/>. </t> <t>The GRASP API is intended to support the various interactions expected between most ASAs, such as the interactions outlined in <xref target="structure"/>. 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 arendez-vousrendezvous 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 inSection 6.9.2 of<xreftarget="RFC8994"/>.</t>target="RFC8994" sectionFormat="of" section="6.9.2"/>.</t> </section> <section numbered="true" toc="default"> <name>Interaction withpolicy mechanisms</name>Policy Mechanisms</name> <t> 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 <xref target="I-D.irtf-nmrg-ibn-concepts-definitions"/>.</t> <t> In the cases where ASAs are defined as closed control loops, the specifications defined in <xref target="ZSM009-1"/> regarding imperative and declarative goal statements may be applicable.</t> <t>In the ANI, policy dissemination is expected to operate by an information distribution mechanism(e.g.(e.g., via GRASP <xref target="RFC8990"/>) that can reach all autonomicnodes,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.</t> </section> </section> <section anchor="nonauto" numbered="true" toc="default"> <name>Interaction withNon-AutonomicNon-autonomic Components and Systems</name><t>An ASA, to<t>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 <xref target="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.</t> <t>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 physicalnetwork,network or whether several virtual ANIs are deployed. This aspect needs to be considered by the ASA designer.</t> </section> <section anchor="objdes" numbered="true" toc="default"> <name>Design of GRASP Objectives</name> <t>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 <xref target="RFC8990"/>. Additionally, that document discusses various general considerations for the design of objectives, which are not repeated here. However, note thatthe GRASP protocol,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. </t> <t>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.</t> <t>GRASP allows a'dry run'"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'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 iskept,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.</t> <t>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) <xref target="RFC8949"/>. For some objectives, a single data item willsuffice;suffice, forexampleexample, an integer, a floating point number, a UTF-8stringstring, 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 <xref target="RFC8991"/>).</t>(<xref target="RFC8991" sectionFormat="of" section="2.3.2.4"/>).</t> <t>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 <xref target="RFC8990"/> is not enough, the specification of the objective must indicate the required maximum messagesize, bothsize for both unicast and multicast messages.</t> <t>A mapping from YANG to CBOR is defined by <xref target="I-D.ietf-core-yang-cbor"/>. Subject to the size limit defined for GRASP messages, nothing prevents objectives transporting YANG in this way.</t> <t>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 <xref target="robust"/>.</t> </section> <section anchor="life" numbered="true" toc="default"> <name>Life Cycle</name> <t>The ASA life cyclewasis discussed in <xref target="I-D.peloso-anima-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.</t> <t>In simple cases,Autonomicautonomic 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 updateddynamically,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.</t> <t>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, namelyInstallation, Instantiationinstallation, instantiation, andOperation.</t>operation.</t> <figure anchor="Fig_LC"> <name>Life Cycle of an Autonomic Service Agent</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------------+ Undeployed ------>| |------> Undeployed | Installed | +-->| |---+ Mandate | +--------------+ | Receives a is revoked | +--------------+ | Mandate +---| |<--+ | Instantiated | +-->| |---+ set | +--------------+ | set down | +--------------+ | up +---| |<--+ | Operational | | | +--------------+ ]]></artwork> </figure> <section numbered="true" toc="default"> <name>Installationphase</name>Phase</name> <t>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.</t> <t>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.</t> <t>There are3three properties applicable to the installation of ASAs: </t> <ul> <li>The dynamic installation property allows installing an ASA on demand, on any hosts compatible with the ASA.</li> <li>The decoupling property allows an ASA on one machine to control resources in another machine (known as "decoupled mode").</li> <li>The multiplicity property allows controlling multiple sets of resources from a single ASA.</li> </ul> <t>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. </t> <section numbered="true" toc="default"> <name>Installationphase inputsPhase Inputs andoutputs</name>Outputs</name> <t>Inputs are: </t> <ul><li>[ASA_type]<li>[ASA_type]: specifies which ASA toinstall.</li> <li>[Installation_target_infrastructure]install. </li> <li>[Installation_target_infrastructure]: specifies the candidate installationHosts.</li> <li>[ASA_placement_function]Hosts. </li> <li>[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. </li> </ul> <t>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 <xref target="coordi"/>).</t> <t>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 couldbe: install(List_of_ASAs,be the following: install (List_of_ASAs, Installation_target_infrastructure,ASA_placement_function),ASA_placement_function) and uninstall (List_of_ASAs).</t> </section> </section> <section anchor="Sec_Inst" numbered="true" toc="default"> <name>Instantiationphase</name>Phase</name> <t>We define "instantiation" as the operation of creating a single ASA instance from the corresponding piece of installed software.</t> <t>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.</t> <t>There are twoapsectsaspects 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 iscontrolling); incontrolling). In a decoupledmodemode, 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.</t> <t>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).</t> <section anchor="Sec_Inst_Goal" numbered="true" toc="default"> <name>Operator'sgoal</name>Goal</name> <t>Through this phase, the operator wants to control its autonomic network regarding at least two aspects: </t> <olspacing="normal" type="%d">spacing="normal"> <li>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 orprovider),</li>provider).</li> <li>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.</li> </ol> <t> In this phase, the operator may also want to set goals for autonomic functions, e.g., by configuring GRASP objectives. </t> <t>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: </t><ul empty="true" spacing="normal"> <li>[Instances_of_ASA_type]<t indent="3">[Instances_of_ASA_type] ready to control [Instantiation_target_infrastructure] with[Instantiation_target_parameters]</li> </ul>[Instantiation_target_parameters]</t> </section> <section anchor="Sec_Inst_InOut" numbered="true" toc="default"> <name>Instantiationphase inputsPhase Inputs andoutputs</name>Outputs</name> <t>Inputs are: </t> <ul><li>[Instances_of_ASA_type] that<li>[Instances_of_ASA_type]: specifies which ASAs toinstantiate</li> <li>[Instantiation_target_infrastructure] thatinstantiate </li> <li>[Instantiation_target_infrastructure]: specifies whichare theresources are to be managed by the autonomic function; this can be the whole network or a subset of it like a domain, a physicalsegmentsegment, or even a specific list ofresources,</li> <li>[Instantiation_target_parameters] thatresources. </li> <li>[Instantiation_target_parameters]: specifies whichare theGRASP objectives are to be sent to ASAs (e.g., an optimizationtarget)</li>target) </li> </ul> <t>Outputs are: </t> <ul><li>[Set_of_ASA_resources_relations] describing<li>[Set_of_ASA_resources_relations]: describes which resources are managed by which ASA instances; this is not a formalmessage,message but a resulting configuration log for a set ofASAs.</li>ASAs. </li> </ul> </section> <section anchor="Sec_Inst_Reqs" numbered="true" toc="default"> <name>Instantiationphase requirements</name>Phase Requirements</name> <t>The instructions described in <xref target="Sec_Inst"/> could beeither:either of the following: </t> <ul> <li>Sent to a targeted ASA. Inthethis case, the receiving Agent will have to manage the specified list of [Instantiation_target_infrastructure], with the[Instantiation_target_parameters].</li>[Instantiation_target_parameters]. </li> <li>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].</li>[Instantiation_target_parameters]. </li> </ul> <t>These instructions may be grouped as a specific datastructure,structure referred to as an ASA Instance Mandate. The specification of such an ASA Instance Mandate is beyond the scope of this document.</t> <t>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 beingmonitoredmonitored, and the actions that can be executed (like modifying certainparametersparameter 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.</t> <t>The ASA Instance Manifest does not only serve informational purposes such as acknowledgement of successful instantiation to theoperator,operator but is also necessary for further autonomic operations with: </t> <ul> <li>coordinated entities (see <xref target="coordi"/>)</li> <li>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)</li> </ul> </section> </section> <section anchor="Sec_Operation" numbered="true" toc="default"> <name>Operationphase</name>Phase</name> <t>During theOperationoperation phase, the operator can: </t> <ul><li>Activate/Deactivate<li>activate/deactivate ASAs: enable/disable their autonomicloops.</li> <li>Modify ASAsloops </li> <li>modify ASA targets: set different technicalobjectives.</li> <li>Modifyobjectives </li> <li>modify ASAs managed resources: update theinstance mandateInstance Mandate to specify a different set of resources to manage (only applicable to decoupledASAs).</li>ASAs) </li> </ul> <t>During theOperationoperation phase, running ASAs can interact with other ASAs: </t> <ul> <li>in order to exchange knowledge(e.g.(e.g., an ASA providing traffic predictions to a load balancing ASA)</li> <li>in order to collaboratively reach an objective(e.g.(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)</li> </ul> <t>During theOperationoperation phase, running ASAs are expected to apply coordination schemes as per <xref target="coordi"/>. </t> </section> <section anchor="Sec_Removal" numbered="true" toc="default"> <name>Removalphase</name>Phase</name> <t>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.</t> </section> </section> <section anchor="coordm" numbered="true" toc="default"> <name>Coordination and Data Models</name> <section anchor="coordi" numbered="true" toc="default"> <name>Coordination between Autonomic Functions</name> <t>Some autonomic functions will be completely independent of each other. However, others are at risk of interfering with eachother -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 neededoffor identifying ASAs that might interfere with each other and coordinating their actions whennecessary. <!--This issue is considered in detail in <xref target="I-D.ciavaglia-anima-coordination"/>.--></t>necessary.</t> </section> <section anchor="coordt" numbered="true" toc="default"> <name>Coordination with Traditional Management Functions</name> <t>Some ASAs will have functions that overlap with existing configuration tools and network management mechanisms such ascommand linecommand-line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF. Thisisis, ofcoursecourse, 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 <xref target="RFC8368"/>. As another example, <xref target="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.</t> </section> <section anchor="datam" numbered="true" toc="default"> <name>Data Models</name> <t>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 <xref target="objdes"/>, YANG serialized as CBOR may be used directly as the value of a GRASP objective.</t> </section> </section> <section anchor="robust" numbered="true" toc="default"> <name>Robustness</name> <t>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: </t> <ol spacing="normal" type="1"> <li>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.</li> <li>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.</li> <li>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.</li> <li>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. </li> <li>In any case, it may be prudent to repeat discovery periodically, depending on the use case.</li> <li>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.</li> <li>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.</li> <li>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). </li> <li>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 orofthe objective in question. In such acasecase, the ASA may choose to repeat the operation concerned without using that new feature. </li> <li>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).</li> </ol> <t>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)(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 <xref target="objdes"/> is another tool helpful for this ASA design goal of "test-before-make". </t> </section> <section anchor="security" numbered="true" toc="default"> <name>Security Considerations</name> <t>ASAs are intended to run in an environment that is protected by the Autonomic Control Plane <xref target="RFC8994"/>, admission to which depends on an initial secure bootstrap process such as BRSKI <xref target="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 <xref target="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 unverifiedcommands,commands andshouldshould, ifpossiblepossible, 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.</t> <t>A similar situation will arise if an ASA acts as a gateway between two separate autonomic networks,i.e.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.</t> <t>As a reminder, GRASP does not intrinsically provide transactional integrity (<xref target="objdes"/>).</t> <t>As appropriate to their specific functions, ASAs should take account of relevant privacy considerations <xref target="RFC6973"/>. </t> <t>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 GRASPobjective,objective simply because they are installed on a node that has successfully joined the ACP. In the general case, a node may have multiplerolesroles, 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.</t> </section> <section anchor="iana" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentmakeshas norequest of the IANA.</t> <t/> </section> <section anchor="ack" numbered="true" toc="default"> <name>Acknowledgements</name> <t>Valuable comments were received from Michael Behringer, Menachem Dodge, <contact fullname="Martin Dürst"/>, Toerless Eckert, Thomas Fossati, Alex Galis, Bing Liu, Benno Overeinder, Michael Richardson, Rob Wilton and other IESG members.</t>IANA actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-core-yang-cbor" to="CBOR-YANG"/> <displayreference target="I-D.irtf-nmrg-ibn-concepts-definitions" to="IBN-CONCEPTS"/> <displayreference target="I-D.peloso-anima-autonomic-function" to="AUTONOMIC-FUNCTION"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8990.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8990.xml"/> </references> <references> <name>Informative References</name> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/> <!--href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8568.xml"/> -->href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8993.xml"/>href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8993.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.peloso-anima-autonomic-function.xml"/> <!--href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8991.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ciavaglia-anima-coordination.xml"/>-->href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8992.xml"/> <xi:includehref="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8991.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-yang-cbor.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8992.xml"/>href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.peloso-anima-autonomic-function.xml"/> <reference anchor="I-D.ietf-core-yang-cbor"> <front> <title>CBOR Encoding of Data Modeled with YANG</title> <author initials='M' surname='Veillette' fullname='Michel Veillette' role='editor'/> <author initials='I' surname='Petrov' fullname='Ivaylo Petrov' role='editor' /> <author initials='A' surname='Pelov' fullname='Alexander Pelov' /> <author initials='C' surname='Bormann' fullname='Carsten Bormann' /> <author initials='M' surname='Richardson' fullname='Michael Richardson' /> <date month='December' year='2021'/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-core-yang-cbor-18"/> </reference> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-nmrg-ibn-concepts-definitions.xml"/> <reference anchor="NFV"target="http://portal.etsi.org/NFV/NFV_White_Paper.pdf">target="https://portal.etsi.org/NFV/NFV_White_Paper.pdf"> <front> <title>Network FunctionsVirtualisation - Introductory White Paper</title> <seriesInfo name="SDN and OpenFlow World Congress, Darmstadt, Germany" value="1-16"/> <author surname="ETSI"/>Virtualisation</title> <author> <organization>ETSI</organization> </author> <date month="October" year="2012"/> </front> <refcontent>SDN and OpenFlow World Congress</refcontent> </reference> <referenceanchor="DeMola06">anchor="DEMOLA06"> <front> <title>Towards an Agent Model for Future Autonomic Communications</title> <seriesInfo name="Proceedings of the 7th WOA 2006 Workshop From Objects to Agents" value="51-59"/> <author initials="F." surname="DeMola"/>Mola" fullname=""/> <author initials="R." surname="Quitadamo"/> <date month="September" year="2006"/> </front> </reference> <referenceanchor="Huebscher08">anchor="HUEBSCHER08"> <front> <title>A survey of autonomic computing - degrees, models, and applications</title><seriesInfo name="ACM Computing Surveys (CSUR)" value="Volume 40 Issue 3 DOI: 10.1145/1380584.1380585"/><author initials="M. C." surname="Huebscher"/> <author initials="J. A." surname="McCann"/> <date month="August" year="2008"/> </front> <seriesInfo name="DOI" value="10.1145/1380584.1380585"/> <refcontent>ACM Computing Surveys (CSUR)</refcontent> <refcontent>Volume 40, Issue 3</refcontent> </reference> <referenceanchor="Movahedi12">anchor="MOVAHEDI12"> <front> <title>A Survey of Autonomic Network Architectures and Evaluation Criteria</title> <seriesInfoname="IEEE Communications Surveys & Tutorials" value="Volume: 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, Page(s): 464 - 490"/>name="DOI" value=" 10.1109/SURV.2011.042711.00078"/> <author initials="Z." surname="Movahedi"/> <author initials="M." surname="Ayari"/> <author initials="R." surname="Langar"/> <author initials="G." surname="Pujolle"/> <date year="2012"/> </front> <refcontent>IEEE Communications Surveys & Tutorials</refcontent> <refcontent>Volume 14, Issue 2, Pages 464 - 490</refcontent> </reference> <reference anchor="GANA13"target="http://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf">target="https://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf"> <front> <title>Autonomic network engineering for the self-managing Future Internet(AFI): GANA(AFI); Generic Autonomic Network Architecture (An Architectural Reference Model for Autonomic Networking, Cognitive Networking andSelf-Management. </title> <author surname="ETSI GS AFI 002"/>Self-Management)</title> <author> <organization>ETSI </organization> </author> <date month="April" year="2013"/> </front> <refcontent>GS AFI 002</refcontent> <refcontent>V1.1.1</refcontent> </reference> <reference anchor="ZSM009-1" target="https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf"> <front> <title>Zero-touch network and Service Management (ZSM); Closed-Loop Automation; Part 1:Enablers </title> <author surname="ETSI GS ZSM 009-1"/>Enablers</title> <author> <organization>ETSI </organization> </author> <date month="June" year="2021"/> </front> <refcontent>GS ZSM 009-1</refcontent> <refcontent>Version 1.1.1</refcontent> </reference> <reference anchor="IPJ" target="https://ipj.dreamhosters.com/wp-content/uploads/2021/10/243-ipj.pdf"> <front> <title>Autonomic Networking Gets Serious</title><seriesInfo name="The Internet Protocol Journal" value="Volume: 24 , Issue: 3, ISSN 1944-1134, Page(s): 2 - 18"/><author surname="Behringer" initials="M."/> <author surname="Bormann" initials="C."/> <author surname="Carpenter" initials="B. E."/> <author surname="Eckert" initials="T."/> <author surname="Campos Nobre" initials="J."/> <author surname="Jiang" initials="S."/> <author surname="Li" initials="Y."/> <author surname="Richardson" initials="M. C."/> <date month="October" year="2021"/> </front> <refcontent>The Internet Protocol Journal</refcontent> <refcontent>Volume 24, Issue 3, Page(s) 2 - 18</refcontent> <refcontent>ISSN 1944-1134</refcontent> </reference> </references> </references> <sectionanchor="changes" numbered="true" toc="default" removeInRFC="true"> <name>Change log</name> <t>draft-ietf-anima-asa-guidelines-07, 2022-02-01:</t> <ul spacing="compact"> <li>Editorial</li> </ul> <t>draft-ietf-anima-asa-guidelines-06, 2022-01-27:</t> <ul spacing="compact"> <li>Clarified two sentences about special-purpose ASAs (<xref target="interacts"/>, <xref target="interacta"/>).</li> <li>Fixed indentation bug and added one statement to MAIN PROGRAM pseudocode.</li> <li>Removed mention of software image servers in section 6.1, which confused the reader.</li> <li>Other improvements from IESG reviews.</li> </ul> <t>draft-ietf-anima-asa-guidelines-05, 2021-12-20:</t> <ul spacing="compact"> <li>Clarified NETCONF wording.</li> <li>Removed <CODE BEGINS> on advice from IETF Trust</li> <li>Noted resource limits in constrained nodes</li> <li>Strengthened text on data integrity in resource management example</li> <li>Strengthen discussion of extensibility of GRASP objectives.</li> <li>Other editorial improvements from IETF Last Call reviews</li> </ul> <t>draft-ietf-anima-asa-guidelines-04, 2021-11-20:</t> <ul spacing="compact"> <li>Added terminology appendix</li> <li>Further clarified discussion of asynch operations</li> <li>Other editorial improvements from AD review</li> </ul> <t>draft-ietf-anima-asa-guidelines-03, 2021-11-07:</t> <ul spacing="compact"> <li>Added security consideration for gateway ASAs</li> <li>Cite IPJ article</li> </ul> <t>draft-ietf-anima-asa-guidelines-02, 2021-09-13:</t> <ul spacing="compact"> <li>Added note on maximum message size.</li> <li>Editorial fixes</li> </ul> <t>draft-ietf-anima-asa-guidelines-01, 2021-06-27:</t> <ul spacing="compact"> <li>Incorporated shepherd's review comments</li> <li>Editorial fixes</li> </ul> <t>draft-ietf-anima-asa-guidelines-00, 2020-11-14:</t> <ul spacing="compact"> <li>Adopted by WG</li> <li>Editorial fixes</li> </ul> <t>draft-carpenter-anima-asa-guidelines-09, 2020-07-25:</t> <ul spacing="compact"> <li>Additional text on future authorization.</li> <li>Editorial fixes</li> </ul> <t>draft-carpenter-anima-asa-guidelines-08, 2020-01-10:</t> <ul spacing="compact"> <li>Introduced notion of autonomic ecosystem.</li> <li>Minor technical clarifications.</li> <li>Converted to v3 format.</li> </ul> <t>draft-carpenter-anima-asa-guidelines-07, 2019-07-17:</t> <ul spacing="compact"> <li>Improved explanation of threading vs event-loop</li> <li>Other editorial improvements.</li></ul> <t>draft-carpenter-anima-asa-guidelines-06, 2018-01-07:</t> <ul spacing="compact"> <li>Expanded and improved example logic flow.</li> <li>Editorial corrections.</li></ul> <t>draft-carpenter-anima-asa-guidelines-05, 2018-06-30:</t> <ul spacing="compact"> <li>Added section on relationshp with non-autonomic components.</li> <li>Editorial corrections.</li></ul> <t>draft-carpenter-anima-asa-guidelines-04, 2018-03-03:</t> <ul spacing="compact"> <li>Added note about simple ASAs.</li> <li>Added note about NFV/SFC services.</li> <li>Improved text about threading v event loop model</li> <li>Added section about coordination with traditional tools.</li> <li>Added appendix with example logic flow.</li></ul> <t>draft-carpenter-anima-asa-guidelines-03, 2017-10-25:</t> <ul spacing="compact"> <li>Added details on life cycle.</li> <li>Added details on robustness.</li> <li>Added co-authors.</li></ul> <t>draft-carpenter-anima-asa-guidelines-02, 2017-07-01:</t> <ul spacing="compact"> <li>Expanded description of event-loop case.</li> <li>Added note about 'dry run' mode.</li></ul> <t>draft-carpenter-anima-asa-guidelines-01, 2017-01-06:</t> <ul spacing="compact"> <li>More sections filled in.</li></ul> <t>draft-carpenter-anima-asa-guidelines-00, 2016-09-30:</t> <ul spacing="compact"> <li>Initial version</li></ul> </section> <section anchor="terminology" numbered="true" toc="default"> <name>Terminology</name> <t>This appendix summarises various acronyms and terminology used in the document. Where no other reference is given, please consult <xref target="RFC8993"/> or <xref target="RFC7575"/>.</t> <ul spacing="compact"> <li>Autonomic: Self-managing (self-configuring, self-protecting, self- healing, self-optimizing), but allowing high-level guidance by a central entity such as a NOC. </li> <li>Autonomic Function: A function that adapts on its own to a changing environment.</li> <li>Autonomic Node: A node that employs autonomic functions.</li> <li>ACP: Autonomic Control Plane <xref target="RFC8994"/>.</li> <li>AN: Autonomic Network: A network of autonomic nodes, which interact directly with each other.</li> <li>ANI: Autonomic Network Infrastructure.</li> <li>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.</li> <li>BRSKI: Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995"/>.</li> <li>CBOR: Concise Binary Object Representation <xref target="RFC8949"/>.</li> <li>GRASP: Generic Autonomic Signaling Protocol <xref target="RFC8990"/>.</li> <li>GRASP API: GRASP Application Programming Interface <xref target="RFC8991"/>.</li> <li>NOC: Network Operations Center <xref target="RFC8368"/>.</li> <li>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. <xref target="RFC8990"/>.</li> </ul> </section> <sectionanchor="eg" numbered="true" toc="default"> <name>Example Logic Flows</name> <t>This appendix describes generic logic flows that combine to act as an Autonomic Service Agent (ASA) for resource management. Note that these are illustrativeexamples,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 <xref target="RFC8990"/> and its conceptual API <xref target="RFC8991"/>. </t> <t>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 detailswillwill, ofcoursecourse, depend on the resource concerned. One example is IP address prefix management, as specified in <xref target="RFC8992"/>. In this case, an instance of the ASA will exist in each delegating router. </t> <t> 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,and thendelegate quantities of the resource to consumers that request it, and recover it when no longer needed. </t> <t> Another assumption is there is a set ofnetwork widenetwork-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.) </t> <t> When running as a delegator, it starts with an empty resource pool,itacquires the policy parameters by GRASP synchronization, anditdelegates quantities of the resource to consumers that request it. Both as an origin and as a delegator, when its pool islowlow, 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. </t> <t> Intheorytheory, 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. </t> <t> 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. </t> <t> The description below does not implement GRASP's'dry run'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. </t> <t> The main data structures used in each instance of the ASA are: </t><ul spacing="normal"> <li>The resource_pool, for example<ul> <li>resource_pool: an ordered list of availableresources.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. </li><li> The delegated_list,<li>delegated_list: where a delegator stores the resources it has given to subsidiary devices. </li> </ul> <t> 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 beapparent -apparent; each thread would correspond to one event in the event loop. </t> <t> The GRASP objectives are as follows: </t><ul spacing="normal"> <li> ["EX1.Resource",<ul> <li>["EX1.Resource", flags, loop_count,value]value], where the value depends on the resourceconcerned,concerned but will typically include its size and identification. </li><li> ["EX1.Params",<li>["EX1.Params", flags, loop_count,value]value], where the value will be, for example, a JSON object defining the applicable parameters. </li> </ul> <t> In the outline logic flows below, these objectives are represented simply by their names. </t><artwork name="" type="" align="left" alt=""><![CDATA[<sourcecode type="pseudocode"><![CDATA[ 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]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[]]></sourcecode> <sourcecode type="pseudocode"><![CDATA[ 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]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[]]></sourcecode> <sourcecode type="pseudocode"><![CDATA[ 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]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[]]></sourcecode> <sourcecode type="pseudocode"><![CDATA[ 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]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[]]></sourcecode> <sourcecode type="pseudocode"><![CDATA[ SYNCHRONIZER thread: do forever: Wait for M_REQ_SYN message for EX1.Params Reply with M_SYNCH message for EX1.Params]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[]]></sourcecode> <sourcecode type="pseudocode"><![CDATA[ FLOODER thread: do forever: Send M_FLOOD message for EX1.Params sleep() #periodic timer suitable for application scenario]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[]]></sourcecode> <sourcecode type="pseudocode"><![CDATA[ GARBAGE_COLLECTOR thread: do forever: Search resource_pool for adjacent resources Merge adjacent resources sleep() #periodic timer suitable for application scenario]]></artwork>]]></sourcecode> </section> <section anchor="ack" numbered="false" toc="default"> <name>Acknowledgements</name> <t>Valuable comments were received from <contact fullname="Michael Behringer"/>, <contact fullname="Menachem Dodge"/>, <contact fullname="Martin Dürst"/>, <contact fullname="Toerless Eckert"/>, <contact fullname="Thomas Fossati"/>, <contact fullname="Alex Galis"/>, <contact fullname="Bing Liu"/>, <contact fullname="Benno Overeinder"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Rob Wilton"/>, and other IESG members.</t> </section> </back> </rfc>