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. NOTE: This is an early version of this document. It is expected to grow considerably.

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. 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.

TBD

TBD

GRASP is expected to run as an operating system kernel module 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.

TBD

TBD

TBD, citing "A Day in the Life of an Autonomic Function" .

TBD, citing "Autonomic Functions Coordination" .

TBD. Authorization of ASAs is a subject for future study.

This document makes no request of the IANA.

TBD.

draft-carpenter-anima-asa-guidelines-00, 2016-09-30: Initial version