rfc9222.original.xml   rfc9222.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<!-- You want a table of contents --> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes"?> <!ENTITY zwsp "&#8203;">
<!-- Use symbolic labels for references --> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<!-- This sorts the references --> ]>
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" number="9222" do
<?rfc compact="yes"?> cName="draft-ietf-anima-asa-guidelines-7" consensus="true" ipr="trust200902" obs
<!-- This defines the specific filename and version number of your draft (and in oletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRe
serts the appropriate IETF boilerplate --> fs="true" sortRefs="true" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-anima-asa-guidelines-07" ipr="trust200902" obsoletes="" updates="" submissio
nType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" vers
ion="3">
<!-- xml2rfc v2v3 conversion 2.37.3 -->
<front> <front>
<title abbrev="ASA Guidelines">Guidelines for Autonomic Service Agents</titl e> <title abbrev="ASA Guidelines">Guidelines for Autonomic Service Agents</titl e>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-asa-guidelines-07" /> <seriesInfo name="RFC" value="9222" />
<author fullname="Brian Carpenter" initials="B. E." surname="Carpenter"> <author fullname="Brian Carpenter" initials="B." surname="Carpenter">
<organization abbrev="Univ. of Auckland"/> <organization abbrev="Univ. of Auckland"/>
<address> <address>
<postal> <postal>
<street>School of Computer Science</street> <street>School of Computer Science</street>
<street>University of Auckland</street> <street>University of Auckland</street>
<street>PB 92019</street> <street>PB 92019</street>
<city>Auckland</city> <city>Auckland</city>
<region/> <region/>
<code>1142</code> <code>1142</code>
<country>NZ</country> <country>NZ</country>
skipping to change at line 74 skipping to change at line 71
<postal> <postal>
<street>Villarceaux</street> <street>Villarceaux</street>
<code>91460</code> <code>91460</code>
<city>Nozay</city> <city>Nozay</city>
<region/> <region/>
<country>FR</country> <country>FR</country>
</postal> </postal>
<email>pierre.peloso@nokia.com</email> <email>pierre.peloso@nokia.com</email>
</address> </address>
</author> </author>
<date year="2022"/> <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> <abstract>
<t>This document proposes guidelines for the design of Autonomic Service A <t>This document proposes guidelines for the design of Autonomic Service
gents Agents for autonomic networks. Autonomic Service Agents, together with
for autonomic networks. Autonomic Service Agents, together with the Autono the Autonomic Network Infrastructure, the Autonomic Control Plane, and
mic Network the GeneRic Autonomic Signaling Protocol, constitute base elements of an
Infrastructure, the Autonomic Control Plane and the Generic Autonomic Sign autonomic networking ecosystem.
aling Protocol
constitute base elements of an autonomic networking ecosystem.
</t> </t>
</abstract> </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/an
ima/">https://mailarchive.ietf.org/arch/browse/anima/</eref>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
This document proposes guidelines for the design of Autonomic Service Agen ts This document proposes guidelines for the design of Autonomic Service Agen ts
(ASAs) in the context of an Autonomic Network (AN) based on the Autonomic N etwork (ASAs) in the context of an Autonomic Network (AN) based on the Autonomic N etwork
Infrastructure (ANI) outlined in the autonomic networking reference model < xref target="RFC8993"/>. Infrastructure (ANI) outlined in the autonomic networking reference model < xref target="RFC8993"/>.
This infrastructure makes use of This infrastructure makes use of
the Autonomic Control Plane (ACP) <xref target="RFC8994"/> and the Autonomic Control Plane (ACP) <xref target="RFC8994"/> and
the Generic Autonomic Signaling Protocol (GRASP) <xref target="RFC8990"/>. the GeneRic Autonomic Signaling Protocol (GRASP) <xref target="RFC8990"/>.
A general introduction to this environment may be found at <xref target="IP J"/>, A general introduction to this environment may be found at <xref target="IP J"/>,
which also includes explanatory diagrams, which also includes explanatory diagrams,
and a summary of terminology is in <xref target="terminology"/>.</t> and a summary of terminology is in <xref target="terminology"/>.</t>
<t> <t>
This document is a contribution to the description of an autonomic networki This document is a contribution to the description of an autonomic
ng ecosystem, recognizing that networking ecosystem, recognizing that a deployable autonomic network
a deployable autonomic network needs more than just ACP and GRASP implement needs more than just ACP and GRASP implementations. Such an autonomic
ations. network must achieve management tasks that a Network Operations Center
Such an autonomic network must achieve management tasks that a Network Oper (NOC) cannot readily achieve manually, such as continuous resource
ations Center (NOC) cannot readily optimization or automated fault detection and repair. These tasks, and
achieve manually, such as continuous resource optimization or automated fau other management automation goals, are described at length in <xref
lt detection target="RFC7575"/>. The net result should be significant operational
and repair. These tasks, and other management automation goals, are describ improvement. To achieve this, the autonomic networking ecosystem must
ed at length include at least a library of ASAs and corresponding GRASP technical
in <xref target="RFC7575"/>. The net result should be significant operation objective definitions. A GRASP objective <xref target="RFC8990"/> is a
al improvement. data structure whose main contents are a name and a value. The value
To achieve this, the autonomic networking ecosystem must consists of a single configurable parameter or a set of parameters of
include at least a library of ASAs and corresponding GRASP technical object some kind.</t>
ive
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 paramet
er or
a set of parameters of some kind.</t>
<t>There must also be tools to deploy and oversee ASAs, and integration wit h <t>There must also be tools to deploy and oversee ASAs, and integration wit h
existing operational mechanisms <xref target="RFC8368"/>. However, this doc ument focuses existing operational mechanisms <xref target="RFC8368"/>. However, this doc ument focuses
on the design of ASAs, with some reference to implementation and operationa l aspects. on the design of ASAs, with some reference to implementation and operationa l aspects.
</t> </t>
<t>There is a considerable literature about autonomic agents with a variet y of <t>There is considerable literature about autonomic agents with a variety of
proposals about how they should be characterized. Some examples are proposals about how they should be characterized. Some examples are
<xref target="DeMola06"/>, <xref target="DEMOLA06"/>,
<xref target="Huebscher08"/>, <xref target="HUEBSCHER08"/>,
<xref target="Movahedi12"/> and <xref target="MOVAHEDI12"/>, and
<xref target="GANA13"/>. However, for the present document, <xref target="GANA13"/>. However, for the present document,
the basic definitions and goals for autonomic networking given in <xref targ et="RFC7575"/> the basic definitions and goals for autonomic networking given in <xref targ et="RFC7575"/>
apply. According to RFC 7575, an Autonomic Service Agent is apply. According to RFC 7575, an Autonomic Service Agent is
"An agent implemented "An agent implemented
on an autonomic node that implements an autonomic function, either in part on an autonomic node that implements an autonomic function, either in part
(in the case of a distributed function) or whole."</t> (in the case of a distributed function) or whole."</t>
<t>ASAs must be distinguished from other forms of software component. They <t>ASAs must be distinguished from other forms of software
are components. They are components of network or service management; they
components of network or service management; they do not in themselves provi do not in themselves provide services to end users. They do, however,
de provide management services to network operators and administrators.
services to end users. They do however provide management services to networ For example, the services envisaged for network function virtualization
k operators and administrators. For example, the services envisaged for network (NFV) <xref target="NFV"/> or for service function chaining (SFC) <xref
function virtualisation target="RFC7665"/> might be managed by an ASA rather than by traditional
<xref target="NFV"/> configuration tools.</t>
or for service function chaining <xref target="RFC7665"/> <t>Another example is that an existing script running within a router to
might be managed by an ASA rather than by traditional configuration tools.</ locally monitor or configure functions or services could be upgraded to an
t> ASA that could communicate with peer scripts on neighboring or remote
<t>Another example is that an existing script running within a router routers. A high-level API will allow such upgraded scripts to take full
to locally monitor or configure functions or services could be upgraded to a advantage of the secure ACP and the discovery, negotiation, and
n ASA synchronization features of GRASP. Familiar tasks such as configuring an
that could communicate with peer scripts on neighboring or remote routers. Interior Gateway Protocol (IGP) on neighboring routers or even exchanging
A high-level API will allow such upgraded scripts to take full IGP security keys could be performed securely in this way. This document
advantage of the secure ACP and the discovery, negotiation and synchronizati mainly addresses issues affecting quite complex ASAs, but initially, the
on features most useful ASAs may in fact be rather simple evolutions of existing
of GRASP. Familiar tasks such as configuring an Interior Gateway Protocol (I scripts.</t>
GP) on <t>The reference model <xref target="RFC8993"/> for autonomic networks
neighboring routers or even exchanging IGP security keys could be performed explains further the functionality of ASAs by adding the following:</t>
securely in <blockquote>
this way. This document mainly addresses issues affecting quite complex ASAs [An ASA is] a process that makes use of the features provided by the
, but ANI to achieve its own goals, usually including interaction with other
initially the most useful ASAs ASAs via GRASP <xref target="RFC8990"/> or otherwise. Of
may in fact be rather simple evolutions of existing scripts.</t> course, it also interacts with the specific targets of its function,
<t>The reference model <xref target="RFC8993"/> for autonomic networks exp using any suitable mechanism. Unless its function is very simple, the
lains ASA will need to handle overlapping asynchronous operations. It may
further the functionality of ASAs by adding therefore be a quite complex piece of software in its own right, forming
"[An ASA is] a process that makes use of the features provided part of the application layer above the ANI.
by the ANI to achieve its own goals, usually including interaction </blockquote>
with other ASAs via the GRASP protocol <xref target="RFC8990"/> or <t>As mentioned, there will certainly be simple ASAs that manage a
otherwise. Of course, it also interacts with the specific targets of single objective in a straightforward way and do not need asynchronous
its function, using any suitable mechanism. Unless its function is operations. In nodes where computing power and memory space are limited,
very simple, the ASA will need to handle overlapping asynchronous operation ASAs should run at a much lower frequency than the primary workload, so
s. CPU load should not be a big issue, but memory footprint in a
It may therefore be a quite complex piece of software in its own right, constrained node is certainly a concern. ASAs installed in constrained
forming part of the application layer above the ANI."</t> devices will have limited functionality. In such cases, many aspects of
<t>As mentioned, there will certainly be simple ASAs that manage a single the current document do not apply. However, in the general case, an ASA
objective in a straightforward way and do not need asynchronous operations. may be a relatively complex software component that will in many cases
In nodes where computing power and memory space are limited, control and monitor simpler entities in the same or remote host(s). For
ASAs should run at a much lower frequency than the primary example, a device controller that manages tens or hundreds of simple
workload, so CPU load should not be a big issue, but memory footprint devices might contain a single ASA. </t>
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 manage
s
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. <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 Some of the material may be familiar to those experienced in distributed
fault-tolerant and real-time control systems. Robustness and security fault-tolerant and real-time control systems. Robustness and security
are of particular importance in autonomic networks and are discussed are of particular importance in autonomic networks and are discussed
in <xref target="robust"/> and <xref target="security"/>.</t> in Sections <xref target="robust" format="counter"/> and <xref target="sec urity" format="counter"/>.</t>
</section> </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 direc
tly 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 <xref 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 <xref
target="RFC8990"/>.
</dd>
</dl>
</section>
<section anchor="structure" numbered="true" toc="default"> <section anchor="structure" numbered="true" toc="default">
<name>Logical Structure of an Autonomic Service Agent</name> <name>Logical Structure of an Autonomic Service Agent</name>
<t>As mentioned above, all but the simplest ASAs will need to support asyn <t>As mentioned above, all but the simplest ASAs will need to support
chronous operations. asynchronous operations. Different programming environments support
Different programming environments support asynchronicity in different way asynchronicity in different ways. In this document, we use an explicit
s. In this document, multi-threading model to describe operations. This is illustrative, and
we use an explicit multi-threading model to describe operations. This is i alternatives to multi-threading are discussed in detail in connection
llustrative, with the GRASP API (see <xref target="api"/>).
and alternatives to multi-threading are discussed in detail
in connection with the GRASP API (see <xref target="api"/>).
</t> </t>
<t>A typical ASA will have a main thread that performs various initial hou <t>A typical ASA will have a main thread that performs various initial
sekeeping actions such as: housekeeping actions such as:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Obtain authorization credentials, if needed.</li> <li>obtain authorization credentials, if needed</li>
<li>Register the ASA with GRASP.</li> <li>register the ASA with GRASP</li>
<li>Acquire relevant policy parameters.</li> <li>acquire relevant policy parameters</li>
<li>Declare data structures for relevant GRASP objectives.</li> <li>declare data structures for relevant GRASP objectives</li>
<li>Register with GRASP those objectives that it will actively manage.</ <li>register with GRASP those objectives that it will actively manage</l
li> i>
<li>Launch a self-monitoring thread.</li> <li>launch a self-monitoring thread</li>
<li>Enter its main loop.</li> <li>enter its main loop</li>
</ul> </ul>
<t>The logic of the main loop will depend on the details of the autonomic function concerned. <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 launc hed. Whenever asynchronous operations are required, extra threads may be launc hed.
Examples of such threads include: Examples of such threads include:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Repeatedly flood an objective to the AN, so that any ASA can receive <li>repeatedly flood an objective to the AN so that any ASA can
the objective's latest value.</li> receive the objective's latest value</li>
<li>Accept incoming synchronization requests for an objective managed by <li>accept incoming synchronization requests for an objective managed by
this ASA.</li> this ASA</li>
<li>Accept incoming negotiation requests for an objective managed by thi <li>accept incoming negotiation requests for an objective managed by thi
s ASA, s ASA,
and then conduct the resulting negotiation with the counterpart ASA.</li> and then conduct the resulting negotiation with the counterpart ASA</li>
<li>Manage subsidiary non-autonomic devices directly.</li> <li>manage subsidiary non-autonomic devices directly</li>
</ul> </ul>
<t>These threads should all either exit after their job is done, or <t>These threads should all either exit after their job is done or
enter a wait state for new work, to avoid enter a wait state for new work to avoid wasting system resources.</t>
wasting system resources.</t> <t>According to the degree of parallelism needed by the application,
<t>According to the degree of parallelism needed by the application, some some of these threads might be launched in multiple instances. In
of these threads might be particular, if negotiation sessions with other ASAs are expected to be
launched in multiple instances. In particular, if negotiation sessions with long or to involve wait states, the ASA designer might allow for
other ASAs are expected to multiple simultaneous negotiating threads, with appropriate use of
be long or to involve wait states, the ASA designer might allow for multiple queues and synchronization primitives to maintain consistency.</t>
simultaneous negotiating <t>The main loop itself could act as the initiator of synchronization
threads, with appropriate use of queues and synchronization primitives to ma requests or negotiation requests when the ASA needs data or resources
intain consistency.</t> from other ASAs. In particular, the main loop should watch for changes
<t>The main loop itself could act as the initiator of synchronization requ in policy parameters that affect its operation and, if appropriate,
ests or negotiation occasionally refresh authorization credentials. It should also do
requests, when the ASA needs data or resources from other ASAs. In particula whatever is required to avoid unnecessary resource consumption, for
r, the main loop should example, by limiting its frequency of execution.</t>
watch for changes in policy parameters that affect its operation, and if app <t>The self-monitoring thread is of considerable importance. Failure of
ropriate, occasionally autonomic service agents is highly undesirable. To a large extent, this
refresh authorization credentials. It should also do whatever is required depends on careful coding and testing, with no unhandled error returns
to avoid unnecessary resource consumption, for example by limiting its frequ or exceptions, but if there is nevertheless some sort of failure, the
ency of execution.</t> self-monitoring thread should detect it, fix it if possible, and, in the
<t>The self-monitoring thread is of considerable importance. Failure of au worst case, restart the entire ASA.</t>
tonomic service agents is
highly undesirable.
To a large extent this depends on careful coding and testing, with no unhand
led error returns or exceptions, but if
there is nevertheless some sort of failure, the self-monitoring thread shoul
d detect it, fix it
if possible, and in the worst case restart the entire ASA.</t>
<t><xref target="eg"/> presents some example logic flows in informal pseud ocode.</t> <t><xref target="eg"/> presents some example logic flows in informal pseud ocode.</t>
</section> </section>
<section anchor="interact" numbered="true" toc="default"> <section anchor="interact" numbered="true" toc="default">
<name>Interaction with the Autonomic Networking Infrastructure</name> <name>Interaction with the Autonomic Networking Infrastructure</name>
<section anchor="interacts" numbered="true" toc="default"> <section anchor="interacts" numbered="true" toc="default">
<name>Interaction with the security mechanisms</name> <name>Interaction with the Security Mechanisms</name>
<t>An ASA by definition runs in an autonomic node. Before any normal ASA <t>An ASA by definition runs in an autonomic node. Before any normal
s are started, such nodes must be ASAs are started, such nodes must be bootstrapped into the autonomic
bootstrapped into the autonomic network's secure key infrastructure, typica network's secure key infrastructure, typically in accordance with
lly in accordance with <xref target="RFC8995"/>. This key infrastructure will be used to
<xref target="RFC8995"/>. This key infrastructure will be used secure the ACP (next section) and may be used by ASAs to set up
to secure the ACP (next section) and may be used by ASAs to set up addition additional secure interactions with their peers, if needed.</t>
al secure interactions <t>Note that the secure bootstrap process itself incorporates simple
with their peers, if needed.</t> special-purpose ASAs that use a restricted mode of GRASP (<xref
<t>Note that the secure bootstrap process itself incorporates simple spe target="RFC8995" section="4" sectionFormat="of"/>).</t>
cial-purpose ASAs
that use a restricted mode of GRASP (Section 4 of <xref target="RFC8995"
/>).</t>
</section> </section>
<section anchor="interacta" numbered="true" toc="default"> <section anchor="interacta" numbered="true" toc="default">
<name>Interaction with the Autonomic Control Plane</name> <name>Interaction with the Autonomic Control Plane</name>
<t>In a normal autonomic network, ASAs will run as clients of the ACP, w <t>In a normal autonomic network, ASAs will run as clients of the ACP,
hich will provide a fully secured network which will provide a fully secured network environment for all
environment for all communication with other ASAs, in most cases mediated b communication with other ASAs, in most cases mediated by GRASP (next
y GRASP (next section).</t> section).</t>
<t>Note that the ACP formation process itself incorporates simple specia <t>Note that the ACP formation process itself incorporates simple
l-purpose ASAs special-purpose ASAs that use a restricted mode of GRASP (<xref
that use a restricted mode of GRASP (Section 6.4 of <xref target="RFC899 target="RFC8994" sectionFormat="of" section="6.4"/>).</t>
4"/>).</t>
</section> </section>
<section anchor="api" numbered="true" toc="default"> <section anchor="api" numbered="true" toc="default">
<name>Interaction with GRASP and its API</name> <name>Interaction with GRASP and its API</name>
<t>In a node where a significant number of ASAs are installed, <t>In a node where a significant number of ASAs are installed, GRASP
GRASP <xref target="RFC8990"/> is likely to run as a separate process <xref target="RFC8990"/> is likely to run as a separate process with
with its API <xref target="RFC8991"/> available in user space. Thus, ASAs m its API <xref target="RFC8991"/> available in user space. Thus, ASAs
ay operate without may operate without special privilege, unless they need it for other
special privilege, unless they need it for other reasons. The ASA's view of reasons. The ASA's view of GRASP is built around GRASP objectives
GRASP is built around GRASP (<xref target="objdes"/>), defined as data structures containing
objectives (<xref target="objdes"/>), defined as data structures containing administrative information such as the objective's unique name, and
administrative information its current value. The format and size of the value is not restricted
such as the objective's unique name, and its current value. The format and by the protocol, except that it must be possible to serialize it for
size of the value is not transmission in Concise Binary Object Representation (CBOR) <xref
restricted by the protocol, except that it must be possible to serialise it target="RFC8949"/>, subject only to GRASP's maximum message size as
for transmission in discussed in <xref target="objdes"/>.</t>
Concise Binary Object Representation (CBOR) <xref target="RFC8949"/>, subje
ct 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 pro <t>As discussed in <xref target="structure"/>, GRASP is an asynchronous
tocol, and this protocol, and this document uses a multi-threading model to describe
document uses a multi-threading model to describe operations. In many prog operations. In many programming environments, an "event loop" model is
ramming environments, used instead, in which case each thread would be implemented as an event
an 'event loop' model is used instead, in which case each thread would be handler called in turn by the main loop. For this case, the GRASP API
implemented as an event handler must provide non-blocking calls and possibly support callbacks. This
called in turn by the main loop. For this case, the GRASP API must provide topic is discussed in more detail in <xref target="RFC8991"/>, and other
non-blocking calls and possibly support callbacks. This topic is discussed asynchronicity models are also possible. Whenever necessary, the GRASP
in more detail session identifier will be used to distinguish simultaneous
in <xref target="RFC8991"/>, and other asynchronicity models are also poss operations.</t>
ible.
Whenever necessary, the GRASP session identifier will be used to distingui
sh
simultaneous operations.</t>
<t>The GRASP API should offer the following features: <t>The GRASP API should offer the following features:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Registration functions, so that an ASA can register itself and the <li>Registration functions, so that an ASA can register itself and
objectives that it manages.</li> the objectives that it manages.</li>
<li>A discovery function, by which an ASA can discover other ASAs supp <li>A discovery function, by which an ASA can discover other ASAs
orting a given objective.</li> supporting a given objective.</li>
<li>A negotiation request function, by which an ASA can start negotiat <li>A negotiation request function, by which an ASA can start
ion of an objective with a counterpart ASA. negotiation of an objective with a counterpart ASA. With this,
With this, there is a corresponding listening function for an ASA that wish there is a corresponding listening function for an ASA that wishes
es to respond to negotiation requests, to respond to negotiation requests and a set of functions to
and a set of functions to support negotiating steps. Once a negotiation sta support negotiating steps. Once a negotiation starts, it is a
rts, it is a symmetric process symmetric process with both sides sending successive objective
with both sides sending successive objective values to each other until agr values to each other until agreement is reached (or the negotiation
eement is reached (or the negotiation fails).</li> fails).</li>
<li>A synchronization function, by which an ASA can request the curren <li>A synchronization function, by which an ASA can request the
t value of an objective from a counterpart ASA. current value of an objective from a counterpart ASA. With this,
With this, there is a corresponding listening function for an ASA that wish there is a corresponding listening function for an ASA that wishes
es to respond to synchronization requests. to respond to synchronization requests. Unlike negotiation,
Unlike negotiation, synchronization is an asymmetric process in which the l synchronization is an asymmetric process in which the listener sends
istener sends a a single objective value to the requester.</li>
single objective value to the requester.</li> <li>A flood function, by which an ASA can cause the current value of
<li>A flood function, by which an ASA can cause the current value of a an objective to be flooded throughout the AN so that any ASA can
n objective to be flooded throughout the AN receive it.</li>
so that any ASA can receive it.</li>
</ul> </ul>
<t>For further details and some additional housekeeping functions, see < xref target="RFC8991"/>. <t>For further details and some additional housekeeping functions, see < xref target="RFC8991"/>.
</t> </t>
<t>The GRASP API is intended to support the various interactions expecte
d between <t>The GRASP API is intended to support the various interactions
most ASAs, such as the interactions outlined in <xref target="structure" expected between most ASAs, such as the interactions outlined in <xref
/>. However, target="structure"/>. However, if ASAs require additional
if ASAs require additional communication between themselves, they can do communication between themselves, they can do so directly over the ACP
so directly to benefit from its security. One option is to use GRASP discovery and
over the ACP to benefit from its security. One option is to use GRASP di synchronization as a rendezvous mechanism between two ASAs, passing
scovery communication parameters such as a TCP port number via GRASP. The use
and synchronization as a rendez-vous mechanism between two ASAs, passing of TLS over the ACP for such communications is advisable, as described
communication in <xref target="RFC8994" sectionFormat="of" section="6.9.2"/>.</t>
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 <xref targ
et="RFC8994"/>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Interaction with policy mechanisms</name> <name>Interaction with Policy Mechanisms</name>
<t> At the time of writing, the policy mechanisms for the ANI are und <t> At the time of writing, the policy mechanisms for the ANI are
efined. In particular, undefined. In particular, the use of declarative policies (aka
the use of declarative policies (aka Intents) for the definition and man Intents) for the definition and management of an ASA's behaviors remains
agement of ASA's a research topic <xref
behaviors remains a research topic <xref target="I-D.irtf-nmrg-ibn-conce target="I-D.irtf-nmrg-ibn-concepts-definitions"/>.</t>
pts-definitions"/>.</t> <t> In the cases where ASAs are defined as closed control
<t> In the cases where ASAs are defined as closed control loops, loops, the specifications defined in <xref target="ZSM009-1"/>
the specifications defined regarding imperative and declarative goal statements may be
in <xref target="ZSM009-1"/> regarding imperative and declarative applicable.</t>
goal statements may be applicable.</t> <t>In the ANI, policy dissemination is expected to operate by
<t>In the ANI, policy dissemination is expected to operate by an an information distribution mechanism (e.g., via GRASP <xref
information distribution target="RFC8990"/>) that can reach all autonomic nodes and
mechanism (e.g. via GRASP <xref target="RFC8990"/>) that can reach all auto therefore every ASA. However, each ASA must be capable of
nomic operating "out of the box" in the absence of locally defined
nodes, and therefore every ASA. However, each ASA must be capable of operat policy, so every ASA implementation must include carefully
ing "out of the box" in the chosen default values and settings for all policy
absence of locally defined policy, so every ASA implementation must include parameters.</t>
carefully chosen default values and settings for all policy parameters.</t>
</section> </section>
</section> </section>
<section anchor="nonauto" numbered="true" toc="default"> <section anchor="nonauto" numbered="true" toc="default">
<name>Interaction with Non-Autonomic Components and Systems</name> <name>Interaction with Non-autonomic Components and Systems</name>
<t>An ASA, to have any external effects, must also interact with non-auton <t>To have any external effects, an ASA must also interact with non-autono
omic mic
components of the node where it is installed. For example, an ASA whose purp ose components of the node where it is installed. For example, an ASA whose purp ose
is to manage a resource must interact with that resource. An ASA managing is to manage a resource must interact with that resource. An ASA managing
an entity that is also managed by local software must interact an entity that is also managed by local software must interact
with that software. For example, if such management is performed by NETCONF with that software. For example, if such management is performed by NETCONF
<xref target="RFC6241"/>, the ASA must interact with the NETCONF <xref target="RFC6241"/>, the ASA must interact with the NETCONF
server as an independent NETCONF client in the same node to avoid server as an independent NETCONF client in the same node to avoid
any inconsistency between configuration changes delivered any inconsistency between configuration changes delivered
via NETCONF and configuration changes made by the ASA.</t> via NETCONF and configuration changes made by the ASA.</t>
<t>In an environment where systems are virtualized and specialized using <t>In an environment where systems are virtualized and specialized using
techniques such as network function virtualization or network slicing, techniques such as network function virtualization or network slicing,
there will be a design choice whether ASAs are deployed once per physical no de there will be a design choice whether ASAs are deployed once per physical no de
or once per virtual context. A related issue is whether the ANI as a whole 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 is deployed once on a physical network or whether several virtual ANIs
are deployed. This aspect needs to be considered by the ASA designer.</t> are deployed. This aspect needs to be considered by the ASA designer.</t>
</section> </section>
<section anchor="objdes" numbered="true" toc="default"> <section anchor="objdes" numbered="true" toc="default">
<name>Design of GRASP Objectives</name> <name>Design of GRASP Objectives</name>
<t>The design of an ASA will often require the design of a new GRASP objec <t>The design of an ASA will often require the design of a new GRASP
tive. objective. The general rules for the format of GRASP objectives, their
The general rules for the format of GRASP objectives, their names, and IAN names, and IANA registration are given in <xref
A registration are target="RFC8990"/>. Additionally, that document discusses various
given in <xref target="RFC8990"/>. Additionally, that document discusses var general considerations for the design of objectives, which are not
ious general repeated here. However, note that GRASP, like HTTP, does
considerations for the design of objectives, which are not repeated here. Ho not provide transactional integrity. In particular, steps in a GRASP
wever, note that negotiation are not idempotent. The design of a GRASP objective and the
the GRASP protocol, like HTTP, does not provide transactional integrity. In logic flow of the ASA should take this into account. One approach, which
particular, steps should be used when possible, is to design objectives with idempotent
in a GRASP negotiation are not idempotent. The design of a GRASP objective a semantics. If this is not possible, typically if an ASA is allocating
nd the logic flow of the part of a shared resource to other ASAs, it needs to ensure that the
ASA should take this into account. One approach, which should be used when p same part of the resource is not allocated twice. The easiest way is to
ossible, run only one negotiation at a time. If an ASA is capable of overlapping
is to design objectives with idempotent semantics. If this is not possible, several negotiations, it must avoid interference between these
typically if an ASA is allocating negotiations.
part of a shared resource to other ASAs, it needs to ensure that the same pa
rt of the resource is
not allocated twice. The easiest way is to run only one negotiation at a tim
e. If an ASA is capable of
overlapping several negotiations, it must avoid interference between these n
egotiations.
</t> </t>
<t>Negotiations will always end, normally because one end or the other decla <t>Negotiations will always end, normally because one end or the other
res success or failure. declares success or failure. If this does not happen, either a timeout or
If this does not happen, either a timeout or exhaustion of the loop count wi exhaustion of the loop count will occur. The definition of a GRASP
ll occur. The objective should describe a specific negotiation policy if it is not self-ev
definition of a GRASP objective should describe a specific negotiation polic ident.</t>
y if it is <t>GRASP allows a "dry run" mode of negotiation, where a negotiation
not self-evident.</t> session follows its normal course but is not committed at either end
<t>GRASP allows a 'dry run' mode of negotiation, where a negotiation sessi until a subsequent live negotiation session. If dry run mode is
on follows its normal defined for the objective, its specification, and every implementation,
course but is not committed at either end until a subsequent live negotiat must consider what state needs to be saved following a dry run
ion session. negotiation, such that a subsequent live negotiation can be expected to
If 'dry run' mode is defined for the objective, its specification, and eve succeed. It must be clear how long this state is kept and what happens
ry if the live negotiation occurs after this state is deleted. An ASA that
implementation, must consider what state needs to be saved following a dry r requests a dry run negotiation must take account of the possibility that
un negotiation, such a successful dry run is followed by a failed live negotiation. Because
that a subsequent live negotiation can be expected to succeed. It must be cl of these complexities, the dry run mechanism should only be supported by
ear how long this objectives and ASAs where there is a significant benefit from it.</t>
state is kept, and what happens if the live negotiation occurs after this st <t>The actual value field of an objective is limited by the GRASP
ate is deleted. An ASA protocol definition to any data structure that can be expressed in
that requests a dry run negotiation must take account of the possibility tha Concise Binary Object Representation (CBOR) <xref
t a successful dry run target="RFC8949"/>. For some objectives, a single data item will
is followed by a failed live negotiation. Because of these complexities, the suffice, for example, an integer, a floating point
dry run mechanism number, a UTF-8 string, or an arbitrary byte string. For more complex
should only be supported by objectives and ASAs where there is a significant cases, a simple tuple structure such as [item1, item2, item3] could be
benefit from it.</t> used. Since CBOR is closely linked to JSON, it is also rather easy to
<t>The actual value field of an objective is limited by the GRASP protocol define an objective whose value is a JSON structure. The formats
definition to acceptable by the GRASP API will limit the options in practice. A
any data structure that can be expressed in Concise Binary Object Representa generic solution is for the API to accept and deliver the value field in
tion (CBOR) raw CBOR, with the ASA itself encoding and decoding it via a CBOR
<xref target="RFC8949"/>. For some objectives, a single data item library (<xref target="RFC8991" sectionFormat="of"
will suffice; for example an integer, a floating point number, a UTF-8 strin section="2.3.2.4"/>).</t>
g
or an arbitrary byte string.
For more complex cases, a simple tuple structure such as [item1, item2, item
3] could be used.
Since CBOR is closely linked to JSON, it is also rather easy to define an ob
jective whose
value is a JSON structure. The formats acceptable by the GRASP API will limi
t 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 l
ibrary
(section 2.3.2.4 of <xref target="RFC8991"/>).</t>
<t>The maximum size of the value field of an objective is limited by the GRA <t>The maximum size of the value field of an objective is limited by the
SP maximum message GRASP maximum message size. If the default maximum size specified as
size. If the default maximum size specified as GRASP_DEF_MAX_SIZE by <xref t GRASP_DEF_MAX_SIZE by <xref target="RFC8990"/> is not enough, the
arget="RFC8990"/> is not enough, specification of the objective must indicate the required maximum message
the specification of the objective must indicate the required maximum messag size for both unicast and multicast messages.</t>
e size, both
for unicast and multicast messages.</t>
<t>A mapping from YANG to CBOR is defined by <xref target="I-D.ietf-core-y ang-cbor"/>. Subject to <t>A mapping from YANG to CBOR is defined by <xref target="I-D.ietf-core-y ang-cbor"/>. Subject to
the size limit defined for GRASP messages, nothing prevents objectives trans porting YANG in this way.</t> the size limit defined for GRASP messages, nothing prevents objectives trans porting YANG in this way.</t>
<t>The flexibility of CBOR implies that the value field of many objectives c an be extended in service, <t>The flexibility of CBOR implies that the value field of many objectives c an be extended in service,
to add additional information or alternative content, especially if JSON-lik e structures are to add additional information or alternative content, especially if JSON-lik e structures are
used. This has consequences for the robustness of ASAs, as discussed in <xre f target="robust"/>.</t> used. This has consequences for the robustness of ASAs, as discussed in <xre f target="robust"/>.</t>
</section> </section>
<section anchor="life" numbered="true" toc="default"> <section anchor="life" numbered="true" toc="default">
<name>Life Cycle</name> <name>Life Cycle</name>
<t>The ASA life cycle was discussed in <xref target="I-D.peloso-anima-auto nomic-function"/>, <t>The ASA life cycle is discussed in <xref target="I-D.peloso-anima-auton omic-function"/>,
from which the following text was derived. It does not cover all details, and some 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 implementat ion.</t> of the terms used would require precise definitions in a given implementat ion.</t>
<t>In simple cases, Autonomic functions could be permanent, in the sense t <t>In simple cases, autonomic functions could be permanent, in the sense
hat ASAs are shipped as part of that ASAs are shipped as part of a product and persist throughout the
a product and persist throughout the product's life. However, in complex cas product's life. However, in complex cases, a more likely situation is
es, a more likely situation is that ASAs need to be installed or updated dynamically because of new
that ASAs need to be installed or updated dynamically, because of new requir requirements or bugs. This section describes one approach to the
ements or resulting life cycle of individual ASAs. It does not consider wider
bugs. This section describes one approach to the resulting life cycle issues such as updates of shared libraries.</t>
of individual ASAs. It does not consider wider issues such as updates of sha <t>Because continuity of service is fundamental to autonomic networking,
red libraries.</t> the process of seamlessly replacing a running instance of an ASA with a
<t>Because continuity of service is fundamental to autonomic networking, the new version needs to be part of the ASA's design. The implication of
process service continuity on the design of ASAs can be illustrated along the
of seamlessly replacing a running instance of an ASA with a new version need three main phases of the ASA life cycle, namely installation,
s to be instantiation, and operation.</t>
part of the ASA's design. The implication of service continuity on the desig
n of
ASAs can be illustrated along the three
main phases of the ASA life cycle, namely Installation, Instantiation a
nd Operation.</t>
<figure anchor="Fig_LC"> <figure anchor="Fig_LC">
<name>Life Cycle of an Autonomic Service Agent</name> <name>Life Cycle of an Autonomic Service Agent</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------------+ +--------------+
Undeployed ------>| |------> Undeployed Undeployed ------>| |------> Undeployed
| Installed | | Installed |
+-->| |---+ +-->| |---+
Mandate | +--------------+ | Receives a Mandate | +--------------+ | Receives a
is revoked | +--------------+ | Mandate is revoked | +--------------+ | Mandate
+---| |<--+ +---| |<--+
| Instantiated | | Instantiated |
+-->| |---+ +-->| |---+
set | +--------------+ | set set | +--------------+ | set
skipping to change at line 406 skipping to change at line 555
is revoked | +--------------+ | Mandate is revoked | +--------------+ | Mandate
+---| |<--+ +---| |<--+
| Instantiated | | Instantiated |
+-->| |---+ +-->| |---+
set | +--------------+ | set set | +--------------+ | set
down | +--------------+ | up down | +--------------+ | up
+---| |<--+ +---| |<--+
| Operational | | Operational |
| | | |
+--------------+ +--------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Installation phase</name> <name>Installation Phase</name>
<t>We define "installation" to mean that a piece of software is loaded i nto <t>We define "installation" to mean that a piece of software is loaded i nto
a device, along with any necessary libraries, but is not yet activated.< /t> 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 firs t provision the <t>Before being able to instantiate and run ASAs, the operator will firs t provision the
infrastructure with the sets of ASA software corresponding to its needs a nd objectives. infrastructure with the sets of ASA software corresponding to its needs a nd objectives.
Such software must be checked for integrity and authenticity before insta llation. Such software must be checked for integrity and authenticity before insta llation.
The provisioning of the infrastructure is realized in the installation ph ase and consists of The provisioning of the infrastructure is realized in the installation ph ase and consists of
installing (or checking the availability of) the pieces of software of th e different ASAs installing (or checking the availability of) the pieces of software of th e different ASAs
in a set of Installation Hosts within the autonomic network.</t> in a set of Installation Hosts within the autonomic network.</t>
<t>There are 3 properties applicable to the installation of ASAs: <t>There are three properties applicable to the installation of ASAs:
</t> </t>
<ul> <ul>
<li>The dynamic installation property <li>The dynamic installation property
allows installing an ASA on demand, on any hosts compatible with the A SA.</li> allows installing an ASA on demand, on any hosts compatible with the A SA.</li>
<li>The decoupling property <li>The decoupling property
allows an ASA on one machine to control resources in another machine allows an ASA on one machine to control resources in another machine
(known as "decoupled mode").</li> (known as "decoupled mode").</li>
<li>The multiplicity property <li>The multiplicity property
allows controlling multiple sets of resources from a single ASA.</li> allows controlling multiple sets of resources from a single ASA.</li>
</ul> </ul>
<t>These three properties are very important in the context of the insta llation <t>These three properties are very important in the context of the insta llation
phase as their variations condition how the ASA could be installed on th e infrastructure. </t> phase as their variations condition how the ASA could be installed on th e infrastructure. </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Installation phase inputs and outputs</name> <name>Installation Phase Inputs and Outputs</name>
<t>Inputs are: <t>Inputs are:
</t> </t>
<ul>
<li>[ASA_type] <ul>
specifies which ASA to install.</li>
<li>[Installation_target_infrastructure] <li>[ASA_type]: specifies which ASA to install.
specifies the candidate installation Hosts.</li> </li>
<li>[ASA_placement_function]
specifies how the installation phase will meet the operat <li>[Installation_target_infrastructure]: specifies the candi
or's needs and objectives for date installation Hosts.
the provision of the infrastructure. This function is onl </li>
y useful in the
decoupled mode. It can be as simple as an explicit list o <li>[ASA_placement_function]: specifies how the installation
f hosts phase will meet the operator's
on which the ASAs are to be installed, needs and objectives for the provision of the infrastructure. This
or it could consist of operator-defined criteria and cons function is only useful in the decoupled mode. It can be as simple
traints. </li> as an explicit list of hosts on which the ASAs are to be
</ul> installed, or it could consist of operator-defined criteria and
<t>The main output of the installation phase is a [List_of_ASAs] insta constraints.
lled on </li>
[List_of_hosts]. This output is also useful for the coordination </ul>
function where it acts as a static interaction map (see <xref target="
coordi"/>).</t> <t>The main output of the installation phase is a [List_of_ASAs] installed on
<t>The condition to validate in order to pass to next phase is to ensu [List_of_hosts]. This output is also useful for the coordination function
re where it acts as a static interaction map (see <xref target="coordi"/>).</t>
that [List_of_ASAs] are correctly installed on [List_of_hosts]. <t>The condition to validate in order to pass to next phase is to
A minimum set of primitives to support the installation of ensure that [List_of_ASAs] are correctly installed on
ASAs could be: [List_of_hosts]. A minimum set of primitives to support the
install(List_of_ASAs, Installation_target_infrastructure, A installation of ASAs could be the following: install (List_of_ASAs,
SA_placement_function), Installation_target_infrastructure, ASA_placement_function) and
and uninstall (List_of_ASAs).</t> uninstall (List_of_ASAs).</t>
</section> </section>
</section> </section>
<section anchor="Sec_Inst" numbered="true" toc="default"> <section anchor="Sec_Inst" numbered="true" toc="default">
<name>Instantiation phase</name> <name>Instantiation Phase</name>
<t>We define "instantiation" as the operation of creating a single ASA i nstance <t>We define "instantiation" as the operation of creating a single ASA i nstance
from the corresponding piece of installed software.</t> from the corresponding piece of installed software.</t>
<t>Once the ASAs are installed on the appropriate hosts in the network, <t>Once the ASAs are installed on the appropriate hosts in the
these ASAs may start to operate. network, these ASAs may start to operate. From the operator
From the operator viewpoint, an operating ASA means the ASA manages the n viewpoint, an operating ASA means the ASA manages the network
etwork resources as per the objectives given. resources as per the objectives given. At the ASA local level,
At the ASA local level, operating means executing their control loop algo operating means executing their control loop algorithm.</t>
rithm.</t> <t>There are two aspects to take into consideration. First, having a
<t>There are two apsects to take into consideration. piece of code installed and available to run on a host is not the same
First, having a piece of code installed and available to run on a as having an agent based on this piece of code running inside the
host is not host. Second, in a coupled case, determining which resources are
the same as having an agent based on this piece of code running i controlled by an ASA is straightforward (the ASA runs on the same
nside the host. autonomic node as the resources it is controlling). In a decoupled
Second, in a coupled case, determining which resources are contro mode, determining this is a bit more complex: a starting agent will
lled by an ASA is have to either discover the set of resources it ought to control, or
straightforward (the ASA runs on the same autonomic node as the such information has to be communicated to the ASA.</t>
resources it is controlling); in a decoupled mode determining thi <t>The instantiation phase of an ASA covers both these aspects:
s is starting the agent code (when this does not start automatically) and
a bit more complex: a starting agent will have to either discover determining which resources have to be controlled (when this is not
the set of straightforward).</t>
resources it ought to control, or such information has to be comm
unicated 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 re
sources have to be
controlled (when this is not straightforward).</t>
<section anchor="Sec_Inst_Goal" numbered="true" toc="default"> <section anchor="Sec_Inst_Goal" numbered="true" toc="default">
<name>Operator's goal</name> <name>Operator's Goal</name>
<t>Through this phase, the operator wants to control its autonomic net <t>Through this phase, the operator wants to control its autonomic
work regarding at least two aspects: network regarding at least two aspects:
</t> </t>
<ol spacing="normal" type="%d"> <ol spacing="normal">
<li>determine the scope of autonomic functions by instructing which network <li>determine the scope of autonomic functions by instructing which network
resources have to be managed by which autonomic function (and more p recisely resources have to be managed by which autonomic function (and more p recisely
by which release of the ASA software code, e.g., version number or p rovider),</li> by which release of the ASA software code, e.g., version number or p rovider).</li>
<li>determine how the autonomic functions are organized by instantia ting a set <li>determine how the autonomic functions are organized by instantia ting a set
of ASAs across one or more autonomic nodes and instructing them of ASAs across one or more autonomic nodes and instructing them
accordingly about the other ASAs in the set as necessary.</li> accordingly about the other ASAs in the set as necessary.</li>
</ol> </ol>
<t> <t>
In this phase, the operator may also want to set In this phase, the operator may also want to
goals for autonomic functions, e.g., by configuring GRASP objectives. set goals for autonomic functions, e.g., by
configuring GRASP objectives.
</t> </t>
<t>The operator's goal can be summarized in an instruction to the auto nomic ecosystem matching the following format, <t>The operator's goal can be summarized in an instruction to the auto nomic ecosystem matching the following format,
explained in detail in the next sub-section: explained in detail in the next sub-section:
</t> </t>
<ul empty="true" spacing="normal"> <t indent="3">[Instances_of_ASA_type] ready to control [Instantiation_
<li>[Instances_of_ASA_type] ready to control [Instantiation_target_i target_infrastructure] with [Instantiation_target_parameters]</t>
nfrastructure] with [Instantiation_target_parameters]</li>
</ul>
</section> </section>
<section anchor="Sec_Inst_InOut" numbered="true" toc="default"> <section anchor="Sec_Inst_InOut" numbered="true" toc="default">
<name>Instantiation phase inputs and outputs</name> <name>Instantiation Phase Inputs and Outputs</name>
<t>Inputs are: <t>Inputs are:
</t> </t>
<ul>
<li>[Instances_of_ASA_type] <ul>
that specifies which ASAs to instantiate</li> <li>[Instances_of_ASA_type]: specifies which ASAs to instantiate
<li>[Instantiation_target_infrastructure] </li>
that specifies which are the resources to be managed by the autonomi
c function; <li>[Instantiation_target_infrastructure]: specifies which
this can be the whole network or a subset of it like a domain, a phy resources are to be managed by the autonomic function; this can be
sical the whole network or a subset of it like a domain, a physical
segment or even a specific list of resources,</li> segment, or even a specific list of resources.
<li>[Instantiation_target_parameters] </li>
that specifies which are the GRASP objectives to be sent to ASAs (e.
g., an optimization target)</li> <li>[Instantiation_target_parameters]: specifies which GRASP
</ul> objectives are to be sent to ASAs (e.g., an optimization target)
</li>
</ul>
<t>Outputs are: <t>Outputs are:
</t> </t>
<ul>
<li>[Set_of_ASA_resources_relations] <ul>
describing which resources are managed by which ASA instances; <li>[Set_of_ASA_resources_relations]: describes which resources are managed by
this is not a formal message, but a resulting configuration log for which ASA instances; this is
a set of ASAs.</li> not a formal message but a resulting configuration log for a set of ASAs.
</ul> </li>
</ul>
</section> </section>
<section anchor="Sec_Inst_Reqs" numbered="true" toc="default"> <section anchor="Sec_Inst_Reqs" numbered="true" toc="default">
<name>Instantiation phase requirements</name> <name>Instantiation Phase Requirements</name>
<t>The instructions described in <xref target="Sec_Inst"/> could be ei <t>The instructions described in <xref target="Sec_Inst"/> could be
ther: either of the following:
</t> </t>
<ul>
<li>Sent to a targeted ASA.
In the case, the receiving Agent will have to manage the specified l
ist of [Instantiation_target_infrastructure], with the [Instantiation_target_par
ameters].</li>
<li>Broadcast to all ASAs.
In this case, the ASAs would determine from the list which ASAs woul
d handle which
[Instantiation_target_infrastructure], with the [Instantiation_targe
t_parameters].</li>
</ul>
<t>These instructions may be grouped as a specific data structure, ref
erred
to as an ASA Instance Mandate. The specification of such an ASA Instan
ce Mandate
is beyond the scope of this document.</t>
<t>The conclusion of this instantiation phase is a set of ASA instance <ul>
s ready to operate. <li>Sent to a targeted ASA. In this case, the receiving Agent will ha
These ASA instances are characterized by the resources they manage, th ve to manage the
e metrics being specified list of [Instantiation_target_infrastructure], with the
monitored and the actions that can be executed (like modifying certain [Instantiation_target_parameters].
parameters values). </li>
The description of the ASA instance may be defined in an ASA Instance
Manifest data structure. <li>Broadcast to all ASAs. In this case, the ASAs would determine fro
The specification of such an ASA Instance Manifest is beyond the scope m the list which
of this document.</t> ASAs would handle which [Instantiation_target_infrastructure],
with the [Instantiation_target_parameters].
</li>
</ul>
<t>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.</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 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.</t>
<t>The ASA Instance Manifest does not only serve informational <t>The ASA Instance Manifest does not only serve informational
purposes such as acknowledgement of successful instantiation to the purposes such as acknowledgement of successful instantiation to the
operator, but is also necessary for further autonomic operations with: operator but is also necessary for further autonomic operations with:
</t> </t>
<ul> <ul>
<li>coordinated entities (see <xref target="coordi"/>)</li> <li>coordinated entities (see <xref target="coordi"/>)</li>
<li>collaborative entities with purposes such as to establish knowle dge exchange <li>collaborative entities with purposes such as to establish knowle dge exchange
(some ASAs may produce knowledge or monitor metrics that would be us eful for other ASAs)</li> (some ASAs may produce knowledge or monitor metrics that would be us eful for other ASAs)</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="Sec_Operation" numbered="true" toc="default"> <section anchor="Sec_Operation" numbered="true" toc="default">
<name>Operation phase</name> <name>Operation Phase</name>
<t>During the Operation phase, the operator can: <t>During the operation phase, the operator can:
</t> </t>
<ul>
<li>Activate/Deactivate ASAs: enable/disable their autonomic loops.</l <ul>
i>
<li>Modify ASAs targets: set different technical objectives.</li> <li>activate/deactivate ASAs: enable/disable their autonomic loops
<li>Modify ASAs managed resources: update the instance mandate to </li>
specify a different set of resources to manage (only applicable to dec
oupled ASAs).</li> <li>modify ASA targets: set different technical objectives
</ul> </li>
<t>During the Operation phase, running ASAs can interact with other ASAs
: <li>modify ASAs managed resources: update the Instance Mandate to specify a di
fferent set of resources to
manage (only applicable to decoupled ASAs)
</li>
</ul>
<t>During the operation phase, running ASAs can interact with other ASAs
:
</t> </t>
<ul> <ul>
<li>in order to exchange knowledge (e.g. an ASA providing traffic pred <li>in order to exchange knowledge (e.g., an ASA providing traffic
ictions to a load balancing ASA)</li> predictions to a load balancing ASA)</li>
<li>in order to collaboratively reach an objective (e.g. ASAs pertaini <li>in order to collaboratively reach an objective (e.g., ASAs
ng to the same pertaining to the same autonomic function will collaborate, e.g., in
autonomic function will collaborate, e.g., the case of a load balancing function, by modifying link metrics
in the case of a load balancing function, by modifying link metrics
according to neighboring resource loads)</li> according to neighboring resource loads)</li>
</ul> </ul>
<t>During the Operation phase, running ASAs are expected to apply coordi <t>During the operation phase, running ASAs are expected to apply
nation schemes as per <xref target="coordi"/>. coordination schemes as per <xref target="coordi"/>.
</t> </t>
</section> </section>
<section anchor="Sec_Removal" numbered="true" toc="default"> <section anchor="Sec_Removal" numbered="true" toc="default">
<name>Removal phase</name> <name>Removal Phase</name>
<t>When an ASA is removed from service and uninstalled, the above steps <t>When an ASA is removed from service and uninstalled, the above steps
are reversed. It is important are reversed. It is important
that its data, especially any security key material, is purged.</t> that its data, especially any security key material, is purged.</t>
</section> </section>
</section> </section>
<section anchor="coordm" numbered="true" toc="default"> <section anchor="coordm" numbered="true" toc="default">
<name>Coordination and Data Models</name> <name>Coordination and Data Models</name>
<section anchor="coordi" numbered="true" toc="default"> <section anchor="coordi" numbered="true" toc="default">
<name>Coordination between Autonomic Functions</name> <name>Coordination between Autonomic Functions</name>
<t>Some autonomic functions will be completely independent of each other. <t>Some autonomic functions will be completely independent of each
However, others are other. However, others are at risk of interfering with each other; for
at risk of interfering with each other - for example, two different optimiza example, two different optimization functions might both attempt to
tion functions modify the same underlying parameter in different ways. In a complete
might both attempt to modify the same underlying parameter in different ways system, a method is needed for identifying ASAs that might
. In a complete interfere with each other and coordinating their actions when
system, a method is needed of identifying ASAs that might interfere with eac necessary.</t>
h other and
coordinating their actions when necessary. <!--This issue is considered in d
etail in
<xref target="I-D.ciavaglia-anima-coordination"/>.--></t>
</section> </section>
<section anchor="coordt" numbered="true" toc="default"> <section anchor="coordt" numbered="true" toc="default">
<name>Coordination with Traditional Management Functions</name> <name>Coordination with Traditional Management Functions</name>
<t>Some ASAs will have functions that overlap with existing configuration <t>Some ASAs will have functions that overlap with existing
tools configuration tools and network management mechanisms such as
and network management mechanisms such as command line interfaces, DHCP, DHC command-line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF.
Pv6, This is, of course, an existing problem whenever multiple configuration
SNMP, NETCONF, and RESTCONF. tools are in use by the NOC. Each ASA designer will need to consider
This is of course an existing problem whenever multiple configuration tools this issue and how to avoid clashes and inconsistencies in various
are deployment scenarios. Some specific considerations for interaction with
in use by the NOC. Each ASA designer will need to OAM tools are given in <xref target="RFC8368"/>. As another example,
consider this issue and how to avoid clashes and inconsistencies in various <xref target="RFC8992"/> describes how autonomic management of IPv6
deployment scenarios. Some specific prefixes can interact with prefix delegation via DHCPv6. The description
considerations for interaction with OAM tools are of a GRASP objective and of an ASA using it should include a discussion
given in <xref target="RFC8368"/>. of any such interactions.</t>
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 shou
ld include
a discussion of any such interactions.</t>
</section> </section>
<section anchor="datam" numbered="true" toc="default"> <section anchor="datam" numbered="true" toc="default">
<name>Data Models</name> <name>Data Models</name>
<t>Management functions often include a shared data model, quite likely to <t>Management functions often include a shared data model, quite likely
be expressed in a formal notation such as YANG. This aspect should not be an to be expressed in a formal notation such as YANG. This aspect should
afterthought not be an afterthought in the design of an ASA. To the contrary, the
in the design of an ASA. To the contrary, the design of the ASA and of its G design of the ASA and of its GRASP objectives should match the data
RASP objectives model; as noted in <xref target="objdes"/>, YANG serialized as CBOR may
should match the data model; as noted in <xref target="objdes"/>, YANG seria be used directly as the value of a GRASP objective.</t>
lized as CBOR may be used directly
as the value of a GRASP objective.</t>
</section> </section>
</section> </section>
<section anchor="robust" numbered="true" toc="default"> <section anchor="robust" numbered="true" toc="default">
<name>Robustness</name> <name>Robustness</name>
<t>It is of great importance that all components of an autonomic system ar <t>It is of great importance that all components of an autonomic system
e highly robust. are highly robust. Although ASA designers should aim for their
Although ASA designers should aim for their component to never fail, it is more important to design the ASA to
component to never fail, it is more important to design the ASA to assume that failures will happen and to gracefully recover from those
assume that failures will happen and to gracefully recover from those failures when they occur. Hence, this section lists various aspects of
failures when they occur. Hence, this section lists various aspects robustness that ASA designers should consider:
of robustness that ASA designers should consider:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>If despite all precautions, an ASA does encounter a fatal error, it <li>If despite all precautions, an ASA does encounter a fatal error,
should it should in any case restart automatically and try again. To
in any case restart automatically and try again. mitigate a loop in case of persistent failure, a suitable pause should
To mitigate a loop in case of persistent failure, a suitable pause be inserted before such a restart. The length of the pause depends on
should be inserted before such a restart. The length of the pause depends the use case; randomization and exponential backoff should be
on the use case; randomization and exponential backoff should be considered. considered.</li>
</li> <li>If a newly received or calculated value for a parameter falls out
<li>If a newly received or calculated value for a parameter falls out of of bounds, the corresponding parameter should be either left unchanged
bounds, the corresponding or restored to a value known to be safe in all configurations.</li>
parameter should be either left unchanged or restored to a value known to <li>If a GRASP synchronization or negotiation session fails for any
be safe in all configurations.</li> reason, it may be repeated after a suitable pause. The length of the
<li>If a GRASP synchronization or negotiation session fails for any reas pause depends on the use case; randomization and exponential backoff
on, should be considered.</li>
it may be repeated after a suitable pause. The length of the pause depends <li>If a session fails repeatedly, the ASA should consider that its
on the use case; randomization and exponential backoff should be considered. peer has failed, and it should cause GRASP to flush its discovery cache
</li> and
<li>If a session fails repeatedly, the ASA should consider that its peer repeat peer discovery. </li>
has failed, <li>In any case, it may be prudent to repeat discovery periodically,
and cause GRASP to flush its discovery cache and repeat peer discovery. </li depending on the use case.</li>
> <li>Any received GRASP message should be checked. If it is wrongly
<li>In any case, it may be prudent to repeat discovery periodically, dep formatted, it should be ignored. Within a unicast session, an Invalid
ending on the use case.</li> message (M_INVALID) may be sent. This function may be provided by the
<li>Any received GRASP message should be checked. If it is wrongly forma GRASP implementation itself.</li>
tted, <li>Any received GRASP objective should be checked. Basic formatting
it should be ignored. Within a unicast session, an Invalid message (M_INVALI errors like invalid CBOR will likely be detected by GRASP itself, but
D) the ASA is responsible for checking the precise syntax and semantics
may be sent. This function may be provided by the GRASP implementation itsel of a received objective. If it is wrongly formatted, it should be
f.</li> ignored. Within a negotiation session, a Negotiation End message
<li>Any received GRASP objective should be checked. Basic formatting err (M_END) with a Decline option (O_DECLINE) should be sent. An ASA may
ors log such events for diagnostic purposes.</li>
like invalid CBOR will likely be detected by GRASP itself, but the ASA i
s
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 <li>On the other hand, the definitions of GRASP objectives are very
likely to be extended, using the flexibility of CBOR or JSON. likely to be extended, using the flexibility of CBOR or JSON.
Therefore, ASAs should be able to deal gracefully with unknown component s Therefore, ASAs should be able to deal gracefully with unknown component s
within the values of objectives. The specification of an objective shoul d within the values of objectives. The specification of an objective shoul d
describe how unknown components are to be handled (ignored, logged and describe how unknown components are to be handled (ignored, logged and
ignored, or rejected as an error). ignored, or rejected as an error).
</li> </li>
<li>If an ASA receives either an Invalid message (M_INVALID) or a Negoti ation End <li>If an ASA receives either an Invalid message (M_INVALID) or a Negoti ation End
message (M_END) with a Decline option (O_DECLINE), one possible reason is th at message (M_END) with a Decline option (O_DECLINE), one possible reason is th at
the peer ASA does not support a new feature of either GRASP or of the object the peer ASA does not support a new feature of either GRASP or the objective
ive in question. In such a case, the ASA may choose to repeat the operation conc
in question. In such a case the ASA may choose to repeat the operation conce erned
rned
without using that new feature. without using that new feature.
</li> </li>
<li>All other possible exceptions should be handled in an orderly way. T <li>All other possible exceptions should be handled in an orderly
here should be no such way. There should be no such thing as an unhandled exception (but see
thing as an unhandled exception (but see point 1 above).</li> point 1 above).</li>
</ol> </ol>
<t>At a slightly more general level, <t>At a slightly more general level, ASAs are not services in themselves,
ASAs are not services in themselves, but they automate services. This has a but they automate services. This has a fundamental impact on how to design
fundamental robust ASAs. In general, when an ASA observes a particular state (1) of
impact on how to design robust ASAs. In general, when an ASA operations of the services/resources it controls, it typically aims to
observes a particular state (1) of operations of the services/resources it improve this state to a better state, say (2). Ideally, the ASA is built
controls, it typically aims to improve this state to a better state, say (2). so that it can ensure that any error encountered can still lead to
Ideally, the ASA is built so that it can ensure that any error encountered returning to (1) instead of a state (3), which is worse than (1). One
can still lead to returning to (1) instead of a state (3) which is worse example instance of this principle is "make-before-break" used in
than (1). One example instance of this principle is "make-before-break" reconfiguration of routing protocols in manual operations. This principle
used in reconfiguration of routing protocols in manual operations. This of operations can accordingly be coded into the operation of an ASA. The
principle of operations can accordingly be coded into the operation of an ASA. GRASP dry run option mentioned in <xref target="objdes"/> is another tool
The GRASP dry run option mentioned in <xref target="objdes"/> is another tool helpful for this ASA design goal of "test-before-make".
helpful for this ASA design goal of "test-before-make".
</t> </t>
</section> </section>
<section anchor="security" numbered="true" toc="default"> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>ASAs are intended to run in an environment that is protected by the Aut <t>ASAs are intended to run in an environment that is protected by the
onomic Control Plane Autonomic Control Plane <xref target="RFC8994"/>, admission to which
<xref target="RFC8994"/>, admission to which depends on an initial depends on an initial secure bootstrap process such as BRSKI <xref
secure bootstrap process such as BRSKI <xref target="RFC8995"/>. target="RFC8995"/>. Those documents describe security considerations
Those documents describe security considerations relating to the use of relating to the use of and properties provided by the ACP and BRSKI,
and properties provided by the ACP and BRSKI, respectively. respectively. Such an ACP can provide keying material for mutual
Such an ACP can provide keying material for mutual authentication between authentication between ASAs as well as confidential communication
ASAs as well channels for messages between ASAs. In some deployments, a secure
as confidential communication channels for messages between ASAs. partition of the link layer might be used instead. GRASP itself has
In some deployments, a secure partition of the link layer might be used significant security considerations <xref target="RFC8990"/>. However,
instead. GRASP itself has significant security considerations <xref target this does not relieve ASAs of responsibility for security. When ASAs
="RFC8990"/>. configure or manage network elements outside the ACP, potentially in a
However, this does not relieve ASAs of responsibility for security. different physical node, they must interact with other non-autonomic
When ASAs configure or manage network elements outside the ACP, software components to perform their management functions. The details
potentially in a different physical node, are specific to each case, but this has an important security
they must interact with other non-autonomic software components to perform implication. An ASA might act as a loophole by which the managed entity
their could penetrate the security boundary of the ANI. Thus, ASAs must be
management functions. The details are specific to each case, but this has designed to avoid loopholes such as passing on executable code or
an important security proxying unverified commands and should, if possible, operate in an
implication. An ASA might act as a loophole by which the managed entity co unprivileged mode. In particular, they must use secure coding
uld practices, e.g., carefully validate all incoming information and avoid
penetrate the security boundary of the ANI. Thus, ASAs must be designed to unnecessary elevation of privilege. This will apply in particular when
avoid an ASA interacts with a management component such as a NETCONF
loopholes such as passing on executable code or proxying unverified comman server.</t>
ds,
and should if possible operate in an unprivileged mode.
In particular, they must use secure coding practices, e.g., carefully vali
date
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 <t>A similar situation will arise if an ASA acts as a gateway between
separate autonomic networks, i.e. it has access to two separate ACPs. Such two separate autonomic networks, i.e., it has access to two separate
an ACPs. Such an ASA must also be designed to avoid loopholes and to
ASA must also be designed to avoid loopholes and to validate incoming validate incoming information from both sides.</t>
information from both sides.</t>
<t>As a reminder, GRASP does not intrinsically provide transactional integ <t>As a reminder, GRASP does not intrinsically provide transactional
rity (<xref target="objdes"/>).</t> integrity (<xref target="objdes"/>).</t>
<t>As appropriate to their specific functions, ASAs should take account of <t>As appropriate to their specific functions, ASAs should take account
relevant privacy of relevant privacy considerations <xref target="RFC6973"/>.
considerations <xref target="RFC6973"/>.
</t> </t>
<t>The initial version of the autonomic infrastructure assumes that all au <t>The initial version of the autonomic infrastructure assumes that all
tonomic autonomic nodes are trusted by virtue of their admission to the ACP.
nodes are trusted by virtue of their admission to the ACP. ASAs are therefore trusted to manipulate any GRASP objective simply
ASAs are therefore trusted to manipulate any GRASP objective, simply becau because they are installed on a node that has successfully joined the
se they ACP. In the general case, a node may have multiple roles, and a role may
are installed on a node that has successfully joined the ACP. In the gener use multiple ASAs, each using multiple GRASP objectives. Additional
al case, mechanisms for the fine-grained authorization of nodes and ASAs to
a node may have multiple roles and a role may use multiple ASAs, each usin manipulate specific GRASP objectives could be designed. Meanwhile, we
g multiple repeat that ASAs should run without special privilege if possible.
GRASP objectives. Additional mechanisms for the fine-grained authorization Independently of this, interfaces between ASAs and the router
of nodes and ASAs to manipulate specific GRASP objectives could be designe configuration and monitoring services of the node can be subject to
d. authentication that provides more fine-grained authorization for
Meanwhile, we repeat that ASAs should run without special privilege if pos specific services. These additional authentication parameters could be
sible. passed to an ASA during its instantiation phase.</t>
Independently of this, interfaces between ASAs and
the router configuration and monitoring services of the node can be subjec
t 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>
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no request of the IANA.</t> <t>This document has no IANA actions.</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>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-core-yang-cbor" to="CBOR-YANG"/>
<displayreference target="I-D.irtf-nmrg-ibn-concepts-definitions" to="IBN-CO
NCEPTS"/>
<displayreference target="I-D.peloso-anima-autonomic-function" to="AUTONOMIC
-FUNCTION"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8949.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen xml"/>
ce.RFC.8994.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8994.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen xml"/>
ce.RFC.8995.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8995.
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen xml"/>
ce.RFC.8990.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8990.
xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7575.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer C.7575.xml"/>
ence.RFC.6973.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer C.6973.xml"/>
ence.RFC.7665.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<!-- <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ C.7665.xml"/>
reference.RFC.8568.xml"/> --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer C.8368.xml"/>
ence.RFC.8368.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer C.6241.xml"/>
ence.RFC.6241.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen FC.8993.xml"/>
ce.RFC.8993.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe
rence.RFC.8991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe
rence.RFC.8992.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere nce.I-D.peloso-anima-autonomic-function.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere nce.I-D.peloso-anima-autonomic-function.xml"/>
<!-- <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/r
eference.I-D.ciavaglia-anima-coordination.xml"/>--> <reference anchor="I-D.ietf-core-yang-cbor">
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <front>
ce.RFC.8991.xml"/> <title>CBOR Encoding of Data Modeled with YANG</title>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <author initials='M' surname='Veillette' fullname='Michel Veillette' role='edito
nce.I-D.ietf-core-yang-cbor.xml"/> r'/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8992.xml"/> <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/refere nce.I-D.irtf-nmrg-ibn-concepts-definitions.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere nce.I-D.irtf-nmrg-ibn-concepts-definitions.xml"/>
<reference anchor="NFV" target="http://portal.etsi.org/NFV/NFV_White_Pap
er.pdf"> <reference anchor="NFV" target="https://portal.etsi.org/NFV/NFV_White_Pape
r.pdf">
<front> <front>
<title>Network Functions Virtualisation - Introductory White Paper</ <title>Network Functions Virtualisation</title>
title> <author>
<seriesInfo name="SDN and OpenFlow World Congress, Darmstadt, German <organization>ETSI</organization>
y" value="1-16"/> </author>
<author surname="ETSI"/>
<date month="October" year="2012"/> <date month="October" year="2012"/>
</front> </front>
<refcontent>SDN and OpenFlow World Congress</refcontent>
</reference> </reference>
<reference anchor="DeMola06">
<reference anchor="DEMOLA06">
<front> <front>
<title>Towards an Agent Model for Future Autonomic Communications</t itle> <title>Towards an Agent Model for Future Autonomic Communications</t itle>
<seriesInfo name="Proceedings of the 7th WOA 2006 Workshop From Obje cts to Agents" value="51-59"/> <seriesInfo name="Proceedings of the 7th WOA 2006 Workshop From Obje cts to Agents" value="51-59"/>
<author initials="F." surname="De Mola"/> <author initials="F." surname="De Mola" fullname=""/>
<author initials="R." surname="Quitadamo"/> <author initials="R." surname="Quitadamo"/>
<date month="September" year="2006"/> <date month="September" year="2006"/>
</front> </front>
</reference> </reference>
<reference anchor="Huebscher08">
<reference anchor="HUEBSCHER08">
<front> <front>
<title>A survey of autonomic computing - degrees, models, and applic ations</title> <title>A survey of autonomic computing - degrees, models, and applic ations</title>
<seriesInfo name="ACM Computing Surveys (CSUR)" value="Volume 40 Iss ue 3 DOI: 10.1145/1380584.1380585"/>
<author initials="M. C." surname="Huebscher"/> <author initials="M. C." surname="Huebscher"/>
<author initials="J. A." surname="McCann"/> <author initials="J. A." surname="McCann"/>
<date month="August" year="2008"/> <date month="August" year="2008"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/1380584.1380585"/>
<refcontent>ACM Computing Surveys (CSUR)</refcontent>
<refcontent>Volume 40, Issue 3</refcontent>
</reference> </reference>
<reference anchor="Movahedi12">
<reference anchor="MOVAHEDI12">
<front> <front>
<title>A Survey of Autonomic Network Architectures and Evaluation Cr iteria</title> <title>A Survey of Autonomic Network Architectures and Evaluation Cr iteria</title>
<seriesInfo name="IEEE Communications Surveys &amp; Tutorials" value ="Volume: 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, Page(s): 464 - 490" /> <seriesInfo name="DOI" value=" 10.1109/SURV.2011.042711.00078"/>
<author initials="Z." surname="Movahedi"/> <author initials="Z." surname="Movahedi"/>
<author initials="M." surname="Ayari"/> <author initials="M." surname="Ayari"/>
<author initials="R." surname="Langar"/> <author initials="R." surname="Langar"/>
<author initials="G." surname="Pujolle"/> <author initials="G." surname="Pujolle"/>
<date year="2012"/> <date year="2012"/>
</front> </front>
<refcontent>IEEE Communications Surveys &amp; Tutorials</refcontent>
<refcontent>Volume 14, Issue 2, Pages 464 - 490</refcontent>
</reference> </reference>
<reference anchor="GANA13" target="http://www.etsi.org/deliver/etsi_gs/A
FI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf"> <reference anchor="GANA13" target="https://www.etsi.org/deliver/etsi_gs/A
FI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf">
<front> <front>
<title>Autonomic network engineering for the self-managing Future In <title>Autonomic network engineering for the self-managing Future
ternet (AFI): GANA Architectural Reference Model for Autonomic Networking, Cogni Internet (AFI); Generic Autonomic Network Architecture (An
tive Networking and Self-Management. </title> Architectural Reference Model for Autonomic Networking, Cognitive
<author surname="ETSI GS AFI 002"/> Networking and Self-Management)</title>
<date month="April" year="2013"/> <author>
<organization>ETSI
</organization>
</author>
<date month="April" year="2013"/>
</front> </front>
</reference> <refcontent>GS AFI 002</refcontent>
<refcontent>V1.1.1</refcontent>
</reference>
<reference anchor="ZSM009-1" target="https://www.etsi.org/deliver/etsi_g s/ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf"> <reference anchor="ZSM009-1" target="https://www.etsi.org/deliver/etsi_g s/ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf">
<front> <front>
<title>Zero-touch network and Service Management (ZSM); Closed-Loop <title>Zero-touch network and Service Management (ZSM);
Automation; Part 1: Enablers </title> Closed-Loop Automation; Part 1: Enablers</title>
<author surname="ETSI GS ZSM 009-1"/>
<author>
<organization>ETSI
</organization>
</author>
<date month="June" year="2021"/> <date month="June" year="2021"/>
</front> </front>
<refcontent>GS ZSM 009-1</refcontent>
<refcontent>Version 1.1.1</refcontent>
</reference> </reference>
<reference anchor="IPJ" target="https://ipj.dreamhosters.com/wp-content/ uploads/2021/10/243-ipj.pdf"> <reference anchor="IPJ" target="https://ipj.dreamhosters.com/wp-content/ uploads/2021/10/243-ipj.pdf">
<front> <front>
<title>Autonomic Networking Gets Serious</title> <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="Behringer" initials="M."/>
<author surname="Bormann" initials="C."/> <author surname="Bormann" initials="C."/>
<author surname="Carpenter" initials="B. E."/> <author surname="Carpenter" initials="B. E."/>
<author surname="Eckert" initials="T."/> <author surname="Eckert" initials="T."/>
<author surname="Campos Nobre" initials="J."/> <author surname="Campos Nobre" initials="J."/>
<author surname="Jiang" initials="S."/> <author surname="Jiang" initials="S."/>
<author surname="Li" initials="Y."/> <author surname="Li" initials="Y."/>
<author surname="Richardson" initials="M. C."/> <author surname="Richardson" initials="M. C."/>
<date month="October" year="2021"/> <date month="October" year="2021"/>
</front> </front>
<refcontent>The Internet Protocol Journal</refcontent>
<refcontent>Volume 24, Issue 3, Page(s) 2 - 18</refcontent>
<refcontent>ISSN 1944-1134</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="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="inte
racts"/>, <xref target="interacta"/>).</li>
<li>Fixed indentation bug and added one statement to MAIN PROGRAM pseudoco
de.</li>
<li>Removed mention of software image servers in section 6.1, which confus
ed 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 &lt;CODE BEGINS&gt; 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 d
ocument. 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 environm
ent.</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 distrib
uted
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 conten
ts 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>
<section anchor="eg" numbered="true" toc="default"> <section anchor="eg" numbered="true" toc="default">
<name>Example Logic Flows</name> <name>Example Logic Flows</name>
<t>This appendix describes generic logic flows that combine to act as an A <t>This appendix describes generic logic flows that combine to act as an
utonomic Service Agent (ASA) for resource management. Note that these are illust Autonomic Service Agent (ASA) for resource management. Note that these
rative examples, and in no sense requirements. As long as the rules of GRASP are are illustrative examples and are in no sense requirements. As long as
followed, a real implementation could be different. The reader is assumed to be the rules of GRASP are followed, a real implementation could be
familiar with GRASP different. The reader is assumed to be familiar with GRASP <xref
<xref target="RFC8990"/> and its conceptual API <xref target="RFC8991"/>. target="RFC8990"/> and its conceptual API <xref target="RFC8991"/>.
</t> </t>
<t>A complete autonomic function for a distributed resource will consist o <t>A complete autonomic function for a distributed resource will consist
f a number of instances of the ASA placed at relevant points in a network. Speci of a number of instances of the ASA placed at relevant points in a
fic details will of course depend on the resource concerned. One example is IP a network. Specific details will, of course, depend on the resource
ddress prefix management, as specified in <xref target="RFC8992"/>. In this case concerned. One example is IP address prefix management, as specified in
, an instance of the ASA will exist in each delegating router. <xref target="RFC8992"/>. In this case, an instance of the ASA will
exist in each delegating router.
</t> </t>
<t> <t>
An underlying assumption is that there is an initial source of the resource in q An underlying assumption is that there is an initial source of the resource in
uestion, referred to here as an origin ASA. The other ASAs, known as delegators, question, referred to here as an origin ASA. The other ASAs, known as
obtain supplies of the resource from the origin, and then delegate quantities o delegators, obtain supplies of the resource from the origin, delegate
f the resource to consumers that request it, and recover it when no longer neede quantities of the resource to consumers that request it, and recover it when
d. no longer needed.
</t> </t>
<t> <t>
Another assumption is there is a set of network wide policy parameters, which th Another assumption is there is a set of network-wide policy parameters, which
e origin will provide to the delegators. These parameters will control how the d the origin will provide to the delegators. These parameters will control how
elegators decide how much resource to provide to consumers. the delegators decide how much resource to provide to consumers. Thus, the
Thus, the ASA logic has two operating modes: origin and delegator. When running ASA logic has two operating modes: origin and delegator. When running as an
as an origin, it starts by obtaining a quantity of the resource from the NOC, an origin, it starts by obtaining a quantity of the resource from the NOC, and it
d it acts as a source of policy parameters, via both GRASP flooding and GRASP sy acts as a source of policy parameters, via both GRASP flooding and GRASP
nchronization. (In some scenarios, flooding or synchronization alone might be su synchronization. (In some scenarios, flooding or synchronization alone might
fficient, but this example includes both.) be sufficient, but this example includes both.)
</t> </t>
<t> <t>
When running as a delegator, it starts with an empty resource pool, it acquires When running as a delegator, it starts with an empty resource pool,
the policy parameters by GRASP synchronization, and it delegates quantities of t acquires the policy parameters by GRASP synchronization, and delegates
he resource to consumers that request it. quantities of the resource to consumers that request it. Both as an origin and a
Both as an origin and as a delegator, when its pool is low it seeks quantities o s a delegator, when its pool is low,
f the resource by requesting GRASP negotiation with peer ASAs. When its pool is it seeks quantities of the resource by
sufficient, it hands out resource to peer ASAs in response to negotiation reques requesting GRASP negotiation with peer ASAs. When its pool is sufficient, it
ts. Thus, over time, the initial resource pool held by the origin will be shared hands out resource to peer ASAs in response to negotiation requests. Thus,
among all the delegators according to demand. over time, the initial resource pool held by the origin will be shared among
all the delegators according to demand.
</t> </t>
<t> <t>
In theory a network could include any number of origins and any number of delega In theory, a network could include any number of origins and any number of
tors, with the only condition being that each origin's initial resource pool is delegators, with the only condition being that each origin's initial resource
unique. A realistic scenario is to have exactly one origin and as many delegator pool is unique. A realistic scenario is to have exactly one origin and as many
s as you like. A scenario with no origin is useless. delegators as you like. A scenario with no origin is useless.
</t> </t>
<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 obtain ed 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 ps eudocode below, which focuses on communication between ASAs. Since GRASP operati ons are not intrinsically idempotent, data integrity during failure scenarios is the responsibility of the ASA designer. This is a complex topic in its own righ t that is not discussed in the present document. 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 obtain ed 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 ps eudocode below, which focuses on communication between ASAs. Since GRASP operati ons are not intrinsically idempotent, data integrity during failure scenarios is the responsibility of the ASA designer. This is a complex topic in its own righ t that is not discussed in the present document.
</t> </t>
<t> <t>
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 description below does not implement GRASP's dry run function. That would re quire temporarily marking any resource handed out in a dry run negotiation as re served, until either the peer obtains it in a live run, or a suitable timeout oc curs.
</t> </t>
<t> <t>
The main data structures used in each instance of the ASA are: The main data structures used in each instance of the ASA are:
</t> </t>
<ul spacing="normal">
<li>The resource_pool, for example an ordered list of available resource <ul>
s. Depending on the nature of the resource, units of resource are split when app <li>resource_pool: an ordered list of available resources, for example. Depend
ropriate, and a background garbage collector recombines split resources if they ing on the
are returned to the pool. nature of the resource, units of resource are split when appropriate, and a
</li> background garbage collector recombines split resources if they are returned
<li> to the pool.
The delegated_list, where a delegator stores the resources it has given to subsi </li>
diary devices.
</li> <li>delegated_list: where a delegator stores the resources it has given to sub
</ul> sidiary devices.
<t> </li>
Possible main logic flows are below, using a threaded implementation model. As n </ul>
oted above, alternative approaches to asynchronous operations are possible. The
transformation to an event loop model should be apparent - each thread would cor <t>
respond to one event in the event loop. Possible main logic flows are below, using a threaded implementation model. As n
oted above, alternative approaches to asynchronous operations are possible. The
transformation to an event loop model should be apparent; each thread would corr
espond to one event in the event loop.
</t> </t>
<t> <t>
The GRASP objectives are as follows: The GRASP objectives are as follows:
</t> </t>
<ul spacing="normal">
<li> <ul>
["EX1.Resource", flags, loop_count, value] <li>["EX1.Resource", flags, loop_count, value], where the value depends on the
where the value depends on the resource concerned, but will typically include it resource concerned but will typically include its size and
s size and identification. identification.
</li> </li>
<li>
["EX1.Params", flags, loop_count, value] <li>["EX1.Params", flags, loop_count, value], where the value will be, for examp
where the value will be, for example, a JSON object defining the applicable para le, a JSON object defining the applicable parameters.
meters.
</li> </li>
</ul>
<t> </ul>
<t>
In the outline logic flows below, these objectives are represented simply by the ir names. In the outline logic flows below, these objectives are represented simply by the ir names.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="pseudocode"><![CDATA[
MAIN PROGRAM: MAIN PROGRAM:
Create empty resource_pool (and an associated lock) Create empty resource_pool (and an associated lock)
Create empty delegated_list Create empty delegated_list
Determine whether to act as origin Determine whether to act as origin
if origin: if origin:
Obtain initial resource_pool contents from NOC Obtain initial resource_pool contents from NOC
Obtain value of EX1.Params from NOC Obtain value of EX1.Params from NOC
Register ASA with GRASP Register ASA with GRASP
Register GRASP objectives EX1.Resource and EX1.Params Register GRASP objectives EX1.Resource and EX1.Params
skipping to change at line 1088 skipping to change at line 1228
Wait for response (M_NEGOTIATE, M_END or M_WAIT) Wait for response (M_NEGOTIATE, M_END or M_WAIT)
if OK: if OK:
if offered amount of resource sufficient: if offered amount of resource sufficient:
Send M_END + O_ACCEPT #negotiation succeeded Send M_END + O_ACCEPT #negotiation succeeded
Add resource to pool Add resource to pool
good_peer = peer #remember this choice good_peer = peer #remember this choice
else: else:
Send M_END + O_DECLINE #negotiation failed Send M_END + O_DECLINE #negotiation failed
good_peer = none #forget this choice good_peer = none #forget this choice
sleep() #periodic timer suitable for application scenario sleep() #periodic timer suitable for application scenario
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="pseudocode"><![CDATA[
MAIN_NEGOTIATOR thread: MAIN_NEGOTIATOR thread:
do forever: do forever:
grasp.listen_negotiate("EX1.Resource") grasp.listen_negotiate("EX1.Resource")
#i.e., wait for negotiation request #i.e., wait for negotiation request
Start a separate new NEGOTIATOR thread for requested amount A Start a separate new NEGOTIATOR thread for requested amount A
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="pseudocode"><![CDATA[
NEGOTIATOR thread: NEGOTIATOR thread:
Request resource amount A from resource_pool Request resource amount A from resource_pool
if not OK: if not OK:
while not OK and A > Amin: while not OK and A > Amin:
A = A-1 A = A-1
Request resource amount A from resource_pool Request resource amount A from resource_pool
if OK: if OK:
Offer resource amount A to peer by GRASP M_NEGOTIATE Offer resource amount A to peer by GRASP M_NEGOTIATE
if received M_END + O_ACCEPT: if received M_END + O_ACCEPT:
#negotiation succeeded #negotiation succeeded
elif received M_END + O_DECLINE or other error: elif received M_END + O_DECLINE or other error:
#negotiation failed #negotiation failed
Return resource to resource_pool Return resource to resource_pool
else: else:
Send M_END + O_DECLINE #negotiation failed Send M_END + O_DECLINE #negotiation failed
#thread exits #thread exits
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="pseudocode"><![CDATA[
DELEGATOR thread: DELEGATOR thread:
do forever: do forever:
Wait for request or release for resource amount A Wait for request or release for resource amount A
if request: if request:
Get resource amount A from resource_pool Get resource amount A from resource_pool
if OK: if OK:
Delegate resource to consumer #atomic Delegate resource to consumer #atomic
Record in delegated_list #operation Record in delegated_list #operation
else: else:
Signal failure to consumer Signal failure to consumer
Signal main thread that resource_pool is low Signal main thread that resource_pool is low
else: else:
Delete resource from delegated_list Delete resource from delegated_list
Return resource amount A to resource_pool Return resource amount A to resource_pool
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
SYNCHRONIZER thread: SYNCHRONIZER thread:
do forever: do forever:
Wait for M_REQ_SYN message for EX1.Params Wait for M_REQ_SYN message for EX1.Params
Reply with M_SYNCH message for EX1.Params Reply with M_SYNCH message for EX1.Params
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
FLOODER thread: FLOODER thread:
do forever: do forever:
Send M_FLOOD message for EX1.Params Send M_FLOOD message for EX1.Params
sleep() #periodic timer suitable for application scenario sleep() #periodic timer suitable for application scenario
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
GARBAGE_COLLECTOR thread: GARBAGE_COLLECTOR thread:
do forever: do forever:
Search resource_pool for adjacent resources Search resource_pool for adjacent resources
Merge adjacent resources Merge adjacent resources
sleep() #periodic timer suitable for application scenario sleep() #periodic timer suitable for application scenario
]]></artwork> ]]></sourcecode>
</section> </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> </back>
</rfc> </rfc>
 End of changes. 119 change blocks. 
978 lines changed or deleted 873 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/