...

1 Terminology

Control Loop Type: A definition of a Control Loop in the TOSCA language. This definition describes a certain type of a control loop. The life cycle of instances of a Control Loop Type are managed by CLAMP.

...

2 Capabilities

We consider the capabilities of Control Loops at Design Time and Run Time.

...

1. Participant Registration. This capability allows participants to register and deregister with CLAMP. The post condition for an execution of this capability is that a participant is available for participation in a control loop. Participants can explicitly register with CLAMP at any point after they start, or they can implicitly register when they respond to a control loop initiation request.
2. Control Loop Commissioning. This capability allows version controlled Control Loop Type definitions to be taken from the Control Loop Design Time Catalogue and be placed in the Control Loop Run Time Inventory. It also allows the values of Common Property Types that apply to all instances of a Control Loop Type to be set. The post condition for an execution of this capability is that the Control Loop definition is in the Control Loop Run Time Inventory.
3. Control Loop Priming on Participants. A participant is primed to support a Control Loop Type. The definition of a control loop and the values of Common Property Types that apply to all instances of a control loop type on a participant is sent to a participant. The participant can then take whatever actions it need to do to support the control loop type in question. Control Loop Priming can take place explicitly as a separate operation on participants or can be done implicitly in the instantiation message for the first instance of a Control Loop Type. The post condition for an execution of this capability is that all participants in this control loop type are commissioned, that is they are prepared to run instances of this control loop type.
4. Control Loop Life Cycle Management. This capability allows a Control Loop Instance to be created. The Control Loop Type definition is read from the Control Loop Run Time Inventory and values are assigned to the Instance Specific Property Types defined for instances of the Control Loop Type in the same manner as the existing CLAMP client does. A Control Loop Instance that has been created but has not yet been instantiated on participants is in state UNINITIALIZED. In this state, the Instance Specific Property Type values can be revised and updated as often as the user requires. Once the user is happy with the property values, the Control Loop Instance is instantiated on participants and the Control Loop Elements for this Control Loop Instance are started by participants using the control loop metadata. Once the Control Loop Instance is instantiated on each participant, the Control Loop Instance is set as being in state PASSIVE in the Control Loop Run Time Inventory. The user can now order the participants to change the state of the Control Loop Instance to state RUNNING. Each participant begins accepting and processing control loop events and the Control Loop Instance is set to state RUNNING in the control loop inventory. The post condition for an execution of this capability is that the Control Loop instance is running on participants and is processing events.
5. Control Loop Monitoring. This capability allows Control Loop Instances to be monitored. Users can check the status of Participants, Control Loop Instances, and Control Loop Elements. Participants report their overall status and the status of Control Loop Elements they are running periodically to CLAMP. Clamp aggregates these status reports into an aggregated Control Loop Instance status record, which is available for monitoring. The post condition for an execution of this capability is that Control Loop Instances are being monitored.

2.1 Control Loop Instance States

When a control loop definition has been commissioned, instances of the control loop can be created, updated, and deleted. The system manages the lifecycle of control loops and control loop elements following the state transition diagram below.

3 Overall Target Architecture

The diagram below shows an overview of the architecture of TOSCA based Control Loop Management in CLAMP.

...

In the figure above, five participants are shown. A Configuration Perisistence Participant manages Control Loop Elements that interact with the ONAP Configuration Persistence Service to store common data. The DCAE Participant runs Control Loop Elements that manage DCAE microservices. The Kubernetes Participant hosts the Control Loop Elements that are managing the life cycle of microservices in control loops that are in a Kubernetes ecosystem. The Policy Participant handles the Control Loop Elements that interact with the Policy Framework to manage policies for control loops. A Controller Participant such as the CDS Participant runs Control Loop Elements that load metadata and configure controllers so that they can partake in control loops. Any third party Existing System Participant can be developed to run Control Loop Elements that interact with any existing system (such as an operator's analytic, machine learning, or artificial intelligence system) so that those systems can partake in control loops.

4. Life Cycle Management Operations

4.1 Control Loop Version Management

Performing a hot change of a Control Loop Instance at run time is a particularly challenging issue because a change must handle the following cases without tearing down the Control Loop:

...

1. A Control Loop or Control Loop Element in state RUNNING can be changed to a higher patch level or rolled back to a lower patch level. This means that hot changes that do not impact the structure of a Control Loop or its elements can be executed.
2. A Control Loop or Control Loop Element in state PASSIVE can be changed to a higher minor/patch level or rolled back to a lower minor/patch level. This means that structural changes to Control Loop Elements that do not impact the Control Loop as a whole can be executed by taking the control loop to state PASSIVE.
3. A Control Loop or Control Loop Element in state UNINITIALIZED can be changed to a higher major/minor/patch level or rolled back to a lower major/minor/patch level. This means that where the structure of the entire control loop is changed, the control loop must be uninitialized and reinitialized.
4. If a Control Loop Element has a minor version change, then its Control Loop Instance must have at least a minor version change.
5. If a Control Loop Element has a major version change, then its Control Loop Instance must have a major version change.

4.2 Scalability

The system is designed to be inherently scalable. The CLAMP runtime is stateless, all state is preserved in the run time inventory in the database. When the user requests an operation such as an instantiation, activation, passivation, or an uninitialization on a Control Loop Instance, the CLAMP runtime broadcasts the request to participants over DMaaP and saves details of the request to the database. The CLAMP runtime does not directly wait for responses to requests.

...

This approach makes it easy to scale Control Loop life cycle management. As Control Loop Instance counts increase, more than one CLAMP runtime can be deployed and REST/supervision operations on Control Loop Instances can run in parallel. The number of participants can scale because an asynchronous broadcast mechanism is used for runtime-participant communication and there is no direct connection or communication channel between participants and CLAMP runtime servers. Participant state, Control Loop Instance state, and Control Loop Element state is held in the database, so any CLAMP runtime server can handle operations for any participant. Because many participants of a particular type can be deployed and participant instances can load balance control loop element instances for different Control Loop Instances of many types across themselves using a mechanism such as a Kubernetes cluster.

5 APIs and Protocols

The APIs and Protocols used by CLAMP for Control Loops are described on the pages below:

1. System Level Dialogues
2. Defining Control Loops in TOSCA for CLAMP
3. REST APIs for CLAMP Control Loops
4. The CLAMP Control Loop Participant Protocol

6 Design and Implementation

The design and implementation of TOSCA Control Loops in CLAMP is described for each executable entity on the pages below:

...