...

1 Terminology

This section describes the terminology used in the system.

...

Following the ONAP Reference Architecture, the architecture has a Design Time part and a Runtime part.

The Design Time part of the archtiecture architecture allows a user to specify metadata for participants. It also allows users to compose control loops. The Design Time Catalogue contains the metadata primitives and control loop definition primitives for composition of control loops. As shown in the figure above, the Design Time component provides a system where Control Loops can be designed and defined in metadata. This means that a Control Loop can have any arbitrary structure and the Control Loop developers can use whatever analytic, policy, or control participants they like to implement their Control Loop. At composition time, the user parameterises the Control Loop and stores it in the design time catalogue. This catalogue contains the primitive metadata for any participants that can be used to compose a Control Loop. A Control Loop SDK is used to compose a Control Loop by aggregating the metadata for the participants chosen to be used in a Control Loop and by constructing the references between the participants. The architecture of the Control Loop Design Time part will be elaborated in future releases.

...

In the figure above, five participants are shown. A Configuration Perisistence Persistence 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.

...

At runtime, interaction between ONAP platform services and application microservices are relatively unconstrained, so interactions between Control Loop Elements for a given Control Loop Instance remain relatively unconstrained. A proposal to support access-controlled access to and between ONAP services will improve this. This can be complemented by intercepting and controlling services accesses between Control Loop Elements for Control Loop Instances for some/all Control Loop types.

...

At design time, the Control Loop type definition specifies the type of API gateway configuration that should be supported at Control Loop and Control Loop Element levels.

...

Additional isolation and execution-environment sandboxing can be supported depending on the Control Loop Element Type. For example: ONAP policies for given Control Loop Instances/Types can be executed in a dedicated PDP engine instances; DCAE or K8S-hosted services can executed in isolated namespaces or in dedicated workers/clusters; etc..

...

.

...

...

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 LoopsAutomation Composition
4. The CLAMP Control Loop Automation Composition Participant Protocol

6 Design and Implementation

...