| Network Working Group | B. Carpenter |
| Internet-Draft | Univ. of Auckland |
| Intended status: Informational | L. Ciavaglia |
| Expires: September 4, 2018 | Nokia |
| S. Jiang | |
| Huawei Technologies Co., Ltd | |
| P. Peloso | |
| Nokia | |
| March 3, 2018 |
Guidelines for Autonomic Service Agents
draft-carpenter-anima-asa-guidelines-04
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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [I-D.ietf-anima-reference-model]. This infrastructure makes use of the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane] and the Generic Autonomic Signaling Protocol (GRASP) [I-D.ietf-anima-grasp].
There is a considerable literature about autonomic agents with a variety of proposals about how they should be characterized. Some examples are [DeMola06], [Huebscher08], [Movahedi12] and [GANA13]. However, for the present document, the basic definitions and goals for autonomic networking given in [RFC7575] apply . According to RFC 7575, an Autonomic Service Agent is "An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole."
ASAs must be distinguished from other forms of software component. They are components of network or service management; they do not in themselves provide services. For example, the services envisaged for network function virtualisation [reference needed] or for service function chaining [RFC7665] might be managed by an ASA rather than by traditional configuration tools.
The reference model [I-D.ietf-anima-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 [I-D.ietf-anima-grasp] or otherwise. Of course it also interacts with the specific targets of its function, using any suitable mechanism. Unless its function is very simple, the ASA will need to handle overlapping asynchronous operations. It may therefore be a quite complex piece of software in its own right, forming part of the application layer above the ANI."
There will certainly be very simple ASAs that manage a single objective in a straightforward way and do not asynchronous operations. In such a case, many aspects of the current document do not apply. However, in general 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 such 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:
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:
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.
Not all programming environments explicitly support multi-threading. In such cases, 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 (Section 3.3) must provide non-blocking calls. If necessary, the GRASP session identifier will be used to distinguish simultaneous operations.
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.
Appendix B presents some example logic flows in informal pseudocode.
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 [I-D.ietf-anima-bootstrapping-keyinfra]. 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 [I-D.ietf-anima-grasp] is expected to run as a separate process with its API [I-D.liu-anima-grasp-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 (Section 4), 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 [RFC7049], which is no restriction at all in practice.
The GRASP API should offer the following features:
For further details and some additional housekeeping functions, see [I-D.liu-anima-grasp-api].
This API is intended to support the various interactions expected between most ASAs, such as the interactions outlined in Section 2. 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 via GRASP. 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 [I-D.ietf-anima-grasp]. 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) [RFC7049]. 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.
Note that a mapping from YANG to CBOR is defined by [I-D.ietf-core-yang-cbor]. Subject to the size limit defined for GRASP messages, nothing prevents objectives using YANG in this way.
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.
The implication of service continuity on the design of ASAs can be illustrated along the three main phases of the ASA life-cycle, namely Installation, Instantiation and Operation.
+--------------+
Undeployed ------>| |------> Undeployed
| Installed |
+-->| |---+
Mandate | +--------------+ | Receives a
is revoked | +--------------+ | Mandate
+---| |<--+
| Instantiated |
+-->| |---+
set | +--------------+ | set
down | +--------------+ | up
+---| |<--+
| Operational |
| |
+--------------+
Figure 1: Life cycle of an Autonomic Service Agent
Before being able to instantiate and run ASAs, the operator must first provision the infrastructure with the sets of ASA software corresponding to its needs and objectives. The provisioning of the infrastructure is realized in the installation phase and consists in installing (or checking the availability of) the pieces of software of the different ASA classes in a set of Installation Hosts.
There are 3 properties applicable to the installation of ASAs:
These three properties are very important in the context of the installation phase as their variations condition how the ASA class could be installed on the infrastructure.
Inputs are:
The main output of the installation phase is an up-to-date directory of installed ASAs which corresponds to [list of ASA classes] installed on [list of installation Hosts]. This output is also useful for the coordination function and corresponds to the static interaction map (see next section).
The condition to validate in order to pass to next phase is to ensure that [list of ASA classes] are well installed on [list of installation Hosts]. The state of the ASA at the end of the installation phase is: installed. (not instantiated). The following commands or messages are foreseen: install(list of ASA classes, Installation_target_Infrastructure, ASA class placement function), and un-install (list of ASA classes).
Once the ASAs are installed on the appropriate hosts in the network, these ASA may start to operate. From the operator viewpoint, an operating ASA means the ASA manages the network resources as per the objectives given. At the ASA local level, operating means executing their control loop/algorithm.
But right before that, there are two things to take into consideration. First, there is a difference between 1. having a piece of code available to run on a host and 2. having an agent based on this piece of code running inside the host. Second, in a coupled case, determining which resources are controlled by an ASA is straightforward (the determination is embedded), in a decoupled mode determining this is a bit more complex (hence a starting agent will have to either discover or be taught it).
The instantiation phase of an ASA covers both these aspects: starting the agent piece of code (when this does not start automatically) and determining which resources have to be controlled (when this is not obvious).
Through this phase, the operator wants to control its autonomic network in two things:
Additionally in this phase, the operator may want to set objectives to autonomic functions, by configuring the ASAs technical objectives.
The operator's goal can be summarized in an instruction to the ANIMA ecosystem matching the following pattern:
Inputs are:
Outputs are:
The instructions described in section 4.2 could be either:
This set of instructions can be materialized through a message that is named an Instance Mandate (description TBD).
The conclusion of this instantiation phase is a ready to operate ASA (or interacting set of ASAs), then this (or those) ASA(s) can describe themselves by depicting which are the resources they manage and what this means in terms of metrics being monitored and in terms of actions that can be executed (like modifying the parameters values). A message conveying such a self description is named an Instance Manifest (description TBD).
Though the operator may well use such a self-description "per se", the final goal of such a description is to be shared with other ANIMA entities like:
Note: This section is to be further developed in future revisions of the document, especially the implications on the design of ASAs.
During the Operation phase, the operator can:
During the Operation phase, running ASAs can interact the one with the other:
During the Operation phase, running ASAs are expected to apply coordination schemes
The ASA life-cycle is discussed in more detail in "A Day in the Life of an Autonomic Function" [I-D.peloso-anima-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" [I-D.ciavaglia-anima-coordination].
Some ASAs will have functions that overlap with existing configuration tools and network management mechanisms such as command line interfaces, DHCP, DHCPv6, SNMP, NETCONF, RESTCONF and YANG-based solutions. Each ASA designer will need to consider this issue and how to avoid clashes and inconsistencies. Some specific considerations for interaction with OAM tools are given in [I-D.ietf-anima-stable-connectivity]. As another example, [I-D.ietf-anima-prefix-management] describes how autonomic management of IPv6 prefixes can interact with prefix delegation via DHCPv6. The description of a GRASP objective and of an ASA using it should include a discussion of any such interactions.
A related aspect is that management functions often include a data model, quite likely to be expressed in a formal notation such as YANG. This aspect should not be an afterthought in the design of an ASA. To the contrary, the design of the ASA and of its GRASP objectives should match the data model; as noted above, YANG serialized as CBOR may be used directly as the value of a GRASP objective.
It is of great importance that all components of an autonomic system are highly robust. In principle they must never fail. This section lists various aspects of robustness that ASA designers should consider.
ASAs are intended to run in an environment that is protected by the Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], admission to which depends on an initial secure bootstrap process [I-D.ietf-anima-bootstrapping-keyinfra]. 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 [RFC6973].
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.
Useful comments were received from Toerless Eckert, Bing Liu, and other members of the ANIMA WG.
| [I-D.ietf-anima-autonomic-control-plane] | Eckert, T., Behringer, M. and S. Bjarnason, "An Autonomic Control Plane (ACP)", Internet-Draft draft-ietf-anima-autonomic-control-plane-13, December 2017. |
| [I-D.ietf-anima-bootstrapping-keyinfra] | Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S. and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Internet-Draft draft-ietf-anima-bootstrapping-keyinfra-11, February 2018. |
| [I-D.ietf-anima-grasp] | Bormann, C., Carpenter, B. and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", Internet-Draft draft-ietf-anima-grasp-15, July 2017. |
| [RFC7049] | Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013. |
| [DeMola06] | De Mola, F. and R. Quitadamo, "An Agent Model for Future Autonomic Communications", Proceedings of the 7th WOA 2006 Workshop From Objects to Agents 51-59, September 2006. |
| [GANA13] | ETSI GS AFI 002, "Autonomic network engineering for the self-managing Future Internet (AFI): GANA Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management.", April 2013. |
| [Huebscher08] | Huebscher, M. and J. McCann, "A survey of autonomic computing—degrees, models, and applications", ACM Computing Surveys (CSUR) Volume 40 Issue 3 DOI: 10.1145/1380584.1380585, August 2008. |
| [I-D.ciavaglia-anima-coordination] | Ciavaglia, L. and P. Peloso, "Autonomic Functions Coordination", Internet-Draft draft-ciavaglia-anima-coordination-01, March 2016. |
| [I-D.ietf-anima-prefix-management] | Jiang, S., Du, Z., Carpenter, B. and Q. Sun, "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", Internet-Draft draft-ietf-anima-prefix-management-07, December 2017. |
| [I-D.ietf-anima-reference-model] | Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L. and J. Nobre, "A Reference Model for Autonomic Networking", Internet-Draft draft-ietf-anima-reference-model-06, February 2018. |
| [I-D.ietf-anima-stable-connectivity] | Eckert, T. and M. Behringer, "Using Autonomic Control Plane for Stable Connectivity of Network OAM", Internet-Draft draft-ietf-anima-stable-connectivity-10, February 2018. |
| [I-D.ietf-core-yang-cbor] | Veillette, M., Pelov, A., Somaraju, A., Turner, R. and A. Minaburo, "CBOR Encoding of Data Modeled with YANG", Internet-Draft draft-ietf-core-yang-cbor-06, February 2018. |
| [I-D.liu-anima-grasp-api] | Carpenter, B., Liu, B., Wang, W. and X. Gong, "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", Internet-Draft draft-liu-anima-grasp-api-06, November 2017. |
| [I-D.peloso-anima-autonomic-function] | Pierre, P. and L. Ciavaglia, "A Day in the Life of an Autonomic Function", Internet-Draft draft-peloso-anima-autonomic-function-01, March 2016. |
| [Movahedi12] | Movahedi, Z., Ayari, M., Langar, R. and G. Pujolle, "A Survey of Autonomic Network Architectures and Evaluation Criteria", IEEE Communications Surveys & Tutorials Volume: 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, Page(s): 464 – 490, 2012. |
| [RFC6973] | Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013. |
| [RFC7575] | Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S. and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015. |
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |
draft-carpenter-anima-asa-guidelines-04, 2018-03-03:
Added note about simple ASAs.
Added note about NFV/SFC services.
Improved text about threading v event loop model
Added section about coordination with traditional tools.
Added appendix with example logic flow.
draft-carpenter-anima-asa-guidelines-03, 2017-10-25:
Added details on life cycle.
Added details on robustness.
Added co-authors.
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
This appendix outlines logic flows for a general purpose resource management ASA. It is assumed that all ASA instances managing this resource use the same logic. However, one instance acts as a master, initialised with a resource pool and a set of policy parameters. The ASA uses a notional objective EX1 and an associated policy parameters objective EX1.Params.
MAIN Thread:
Create empty resource pool
Decide whether to act as master
if master:
Obtain initial resources from NOC and add to pool
Obtain EX1.Params values from NOC, or use default values
Register ASA with GRASP
Register objectives EX1 and EX1.Params
if master:
Start FLOODER thread to flood EX1.Params
Start SYNCHRONIZER listener thread for EX1.Params
Start MAIN_NEGOTIATOR and GARBAGE_COLLECTOR threads
if not master:
Obtain value of EX1.Params (from flood cache or via M_SYN message)
Start ASSIGN thread
while True:
if resource pool is low:
Calculate needed amount of resource
Discover peers (M_DISCOVER / M_RESPONSE)
Choose a peer (prefer good_peer if available)
Send M_REQ_NEG("EX1", peer)
Wait for response (M_NEGOTIATE, M_END or M_WAIT)
if OK:
if offered resource is sufficient:
Negotiation succeeded: Send M_END + O_ACCEPT
Add resource to pool
good_peer = peer
else:
Fail negotiation: Send M_END + O_DECLINE
sleep(10s)
MAIN_NEGOTIATOR Thread :
while True:
Wait for M_REQ_NEG for EX1
start a separate new NEGOTIATOR thread
(allows simultaneous negotiations)
NEGOTIATOR Thread:
Fetch available resource from pool
if OK:
Offer resource to peer: Send M_NEGOTIATE for EX1 objective
if OK:
Received M_END + O_ACCEPT
Negotiation succeeded
else:
Received M_END + O_DECLINE or other error
Return resource to pool
else:
Fail negotiation: Send M_END + O_DECLINE
ASSIGN Thread:
while True:
wait for resource request from managed entity
get resource from pool
if OK:
assign resource to managed entity
else:
signal main thread that pool is low
GARBAGE_COLLECTOR Thread:
while True:
return unused resources to pool
sleep(5s)
SYNCHRONIZER Thread:
while True:
wait for M_REQ_SYN message for EX1.Params
reply with M_SYNCH message for EX1.Params
FLOODER Thread:
while True:
send M_FLOOD message for EX1.Params
sleep(60s)
TBD