...

The goal of the work is to extend and enhance the current ONAP Control Loop support to provide a complete open-source framework for Control Loops. This will enhance the current support to provide TOSCA based Control Loop definition and development, commissioning and run-time management. The participants that comprise a Control Loop and the metadata needed to link the participants together to create a Control Loop are specified in a standardized way using the OASIS TOSCA modelling language. The TOSCA description is then used to commission, instantiate, and manage the Control Loops in the run time system.

1 Terminology

This section describes the terminology used in the system.

...

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.

4.3 Sandboxing and API Gateway Support

API gateways such as Kong have emerged as a useful technology for sandboxing and controlling access for applications and services. For Control Loop instances, it makes sense to provide pass-through support for API gateway configuration.The diagram below shows the approach for configuring API Gateway access at Control Loop Instance and Control Loop Element level.

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.

At runtime, the CLAMP GUI is used to set the configuration for the API gateway at Control Loop Instance level (for all Control Loop Elements in an Control Loop Instance) and individually for each Control Loop Element. Once the Control Loop instance is instantiated on participants, the participants configure the API gateway with the Control Loop Instance level configuration and with the specific configuration for their Control Loop Element. Therefore, a Control Loop Element will only have access to the APIs that are available over the configured API gateway.

Monitoring of the use of the API gateway may also be provided. Information and statistics on API gateway use can be read from the API gateway and passed back in monitoring messages to the CLAMP runtime.

Sandboxing using an API gateway is implemented in the Participant Intermediary. In order to remove the possibility for Participant Implementations to access and configure the API gateway, the Participant intermediary handles interaction with the API gateway.

4.4 Security and Multi Tenancy

...