Guidelines for Autonomic Service Agents
Department of Computer Science
University of Auckland
PB 92019
Auckland
1142
New Zealand
brian.e.carpenter@gmail.com
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
jiangsheng@huawei.com
This document proposes guidelines for the design of Autonomic Service Agents
for autonomic networks. It is based on the Autonomic Network
Infrastructure outlined in the ANIMA reference model, making use of
the Autonomic Control Plane and the Generic Autonomic Signaling Protocol.
This document proposes guidelines for the design of Autonomic Service Agents
(ASAs) in the context of an Autonomic Network (AN) based on the Autonomic Network
Infrastructure (ANI) outlined in the ANIMA reference model .
This infrastructure makes use of
the Autonomic Control Plane (ACP) and
the Generic Autonomic Signaling Protocol (GRASP) .
There is a considerable literature about autonomic agents with a variety of
proposals about how they should be characterized. Some examples are
,
,
and
. However, for the present document,
the basic definitions and goals for autonomic networking given in
apply . According to RFC 7575, an Autonomic Service Agent is
"An agent implemented
on an autonomic node that implements an autonomic function, either in part
(in the case of a distributed function) or whole."
The reference model expands
this by adding that an ASA is
"a process that makes use of the features provided
by the ANI to achieve its own goals, usually including interaction
with other ASAs via the GRASP protocol or
otherwise. Of course it also interacts with the specific targets of
its function, using any suitable mechanism. Unless its function is
very simple, the ASA will need to be multi-threaded so that it can
handle overlapping asynchronous operations. It may therefore be a
quite complex piece of software in its own right, forming part of the
application layer above the ANI."
A basic property of an ASA is that it is a relatively complex software
component that will in many cases control and monitor simpler entities
in the same host or elsewhere. For example, a device controller that manages
tens or hundreds of simple devices might contain a single ASA.
The remainder of this document offers guidance on the design of ASAs.
As mentioned above, all but the simplest ASAs will be multi-threaded programs.
A typical ASA will have a main thread that performs various initial housekeeping actions such as:
Obtain authorization credentials.
Register the ASA with GRASP.
Acquire relevant policy Intent.
Define data structures for relevant GRASP objectives.
Register with GRASP those objectives that it will actively manage.
Launch a self-monitoring thread.
Enter its main loop.
The logic of the main loop will depend on the details of the autonomic function concerned.
Whenever asynchronous operations are required, extra threads will be launched. Examples of
such threads include:
A background thread to repeatedly flood an objective to the AN, so that any ASA can receive the objective's latest value.
A thread to accept incoming synchronization requests for an objective managed by this ASA.
A thread to accept incoming negotiation requests for an objective managed by this ASA,
and then to conduct the resulting negotiation with the counterpart ASA.
A thread to manage subsidiary non-autonomic devices directly.
These threads should all either exit after their job is done, or enter a wait state for new work, to avoid
blocking other threads unnecessarily.
Note: If the programming environment does not support multi-threading, an 'event loop' style of
implementation could be adopted, in which case each of the above threads would be implemented as an event handler
called in turn by the main loop. In this case, the GRASP API () must provide
non-blocking calls. If necessary, the GRASP session identifier will be used to distinguish simultaneous negotiations.
According to the degree of parallelism needed by the application, some of these threads might be
launched in multiple instances. In particular, if negotiation sessions with other ASAs are expected to
be long or to involve wait states, the ASA designer might allow for multiple simultaneous negotiating
threads, with appropriate use of queues and locks to maintain consistency.
The main loop itself could act as the initiator of synchronization requests or negotiation
requests, when the ASA needs data or resources from other ASAs. In particular, the main loop should
watch for changes in policy Intent that affect its operation. It should also do whatever is required
to avoid unnecessary resource consumption, such as including an arbitrary wait time in each cycle
of the main loop.
The self-monitoring thread is of considerable importance. Autonomic service agents must never fail.
To a large extent this depends on careful coding and testing, with no unhandled error returns or exceptions, but if
there is nevertheless some sort of failure, the self-monitoring thread should detect it, fix it
if possible, and in the worst case restart the entire ASA.
An ASA by definition runs in an autonomic node. Before any normal ASAs are started, such nodes must be
bootstrapped into the autonomic network's secure key infrastructure in accordance with
. This key infrastructure will be used
to secure the ACP (next section) and may be used by ASAs to set up additional secure interactions
with their peers, if needed.
Note that the secure bootstrap process itself may include special-purpose ASAs that run in a
constrained insecure mode.
In a normal autonomic network, ASAs will run as clients of the ACP. It will provide a fully secured network
environment for all communication with other ASAs, in most cases mediated by GRASP (next section).
Note that the ACP formation process itself may include special-purpose ASAs that run in a
constrained insecure mode.
GRASP is expected to run as a separate process
with its API available in user space. Thus ASAs may operate without
special privilege, unless they need it for other reasons. The ASA's view of GRASP is built around GRASP
objectives (), defined as data structures containing administrative information
such as the objective's unique name, and its current value. The format and size of the value is not
restricted by the protocol, except that it must be possible to serialise it for transmission in
CBOR , which is no restriction at all in practice.
The GRASP API offers the following features:
Registration functions, so that an ASA can register itself and the objectives that it manages.
A discovery function, by which an ASA can discover other ASAs supporting a given objective.
A negotiation request function, by which an ASA can start negotiation of an objective with a counterpart ASA.
With this, there is a corresponding listening function for an ASA that wishes to respond to negotiation requests,
and a set of functions to support negotiating steps.
A synchronization function, by which an ASA can request the current value of an objective from a counterpart ASA.
With this, there is a corresponding listening function for an ASA that wishes to respond to synchronization requests.
A flood function, by which an ASA can cause the current value of an objective to be flooded throughout the AN
so that any ASA can receive it.
For further details and some additional housekeeping functions, see .
This API is intended to support the various interactions expected between most ASAs, such as the
interactions outlined in . However, if ASAs
require additional communication between themselves, they can do so using any desired protocol. One option is
to use GRASP discovery and synchronization as a rendez-vous mechanism between two ASAs, passing communication
parameters such as a TCP port number as the value of a GRASP objective. As noted above, either the ACP or
in special cases the autonomic key infrastructure will be used to secure such communications.
At the time of writing, the Intent mechanism for the ANI is undefined.
It is expected to operate by an information distribution mechanism that can reach all autonomic
nodes, and therefore every ASA. However, each ASA must be capable of operating "out of the box" in the
absence of locally defined Intent, so every ASA implementation must include carefully chosen default values
and settings for all parameters and choices that might depend on Intent.
The general rules for the format of GRASP Objective options, their names, and IANA registration are
given in . Additionally that document discusses various general
considerations for the design of objectives, which are not repeated here. However, we emphasize that
the GRASP protocol does not provide transactional integrity. In other words, if an ASA is capable of
overlapping several negotiations for a given objective, then the ASA itself must use suitable locking
techniques to avoid interference between these negotiations. For example, if an ASA is allocating
part of a shared resource to other ASAs, it needs to ensure that the same part of the resource is
not allocated twice. This might impact the design of the objective as well as the logic flow of the
ASA.
In particular, if 'dry run' mode is defined for the objective, its specification, and every
implementation, must consider what state needs to be saved following a dry run negotiation, such
that a subsequent live negotiation can be expected to succeed. It must be clear how long this
state is kept, and what happens if the live negotiation occurs after this state is deleted. An ASA
that requests a dry run negotiation must take account of the possibility that a successful dry run
is followed by a failed live negotiation. Because of these complexities, the dry run mechanism
should only be supported by objectives and ASAs where there is a significant benefit from it.
The actual value field of an objective is limited by the GRASP protocol definition to
any data structure that can be expressed in Concise Binary Object Representation (CBOR)
. For some objectives, a single data item
will suffice; for example an integer, a floating point number or a UTF-8 string.
For more complex cases, a simple tuple structure such as [item1, item2, item3] could be used.
Nothing prevents using other formats such as JSON, but this requires the ASA to be capable
of parsing and generating JSON. The formats acceptable by the GRASP API will limit the
options in practice. A fallback solution is for the API to accept and deliver the value
field in raw CBOR, with the ASA itself encoding and decoding it via a CBOR library.
Autonomic functions could be permanent, in the sense that ASAs are shipped as part of
a product and persist throughout the product's life. However, a more likely situation is
that ASAs need to be installed or updated dynamically, because of new requirements or
bugs. Because continuity of service is fundamental to autonomic networking, the process
of seamlessly replacing a running instance of an ASA with a new version needs to be
part of the ASA's design. This topic is discussed in detail in
"A Day in the Life of an Autonomic Function" .
Some autonomic functions will be completely independent of each other. However, others are
at risk of interfering with each other - for example, two different optimization functions
might both attempt to modify the same underlying parameter in different ways. In a complete
system, a method is needed of identifying ASAs that might interfere with each other and
coordinating their actions when necessary. This issue is considered in
"Autonomic Functions Coordination" .
ASAs are intended to run in an environment that is protected by the Autonomic Control Plane
, admission to which depends on an initial
secure bootstrap process . However, this
does not relieve ASAs of responsibility for security. In particular, when ASAs configure or manage
network elements outside the ACP, they must use secure techniques and carefully validate any incoming
information. As appropriate to their specific functions, ASAs should take account of relevant privacy
considerations .
Authorization of ASAs is a subject for future study. At present, ASAs are trusted by virtue
of being installed on a node that has successfully joined the ACP.
This document makes no request of the IANA.
An Agent Model for Future Autonomic Communications
A survey of autonomic computing—degrees, models, and applications
A Survey of Autonomic Network Architectures and Evaluation Criteria
Autonomic network engineering for the self-managing Future Internet (AFI): GANA Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management.
draft-carpenter-anima-asa-guidelines-02, 2017-07-01:
Expanded description of event-loop case.
Added note about 'dry run' mode.
draft-carpenter-anima-asa-guidelines-01, 2017-01-06:
More sections filled in
draft-carpenter-anima-asa-guidelines-00, 2016-09-30:
Initial version