You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Under Construction

This page is a high level proposal for modeling control loops. This tries to give an option how to achieve the aims of the Metadata Driven Control Loops as understood by the author.


The Shortest Version

Onboard types (of policy, DCAE service component, related data type) and topology templates (of DCAE service component, possibly policy for more a complex PDP). Design topology templates using those the onboarded material in service context. Control loop templates and lower level templates and types get packaged to service CSAR and distributed similarly as VNFs and other entities. 

TOSCA Modeling




Orchestration

As a control loop is modeled with TOSCA, it can be orchestrated by a TOSCA orchestrator with suitable support for control loop specific node types. It also can and should be included in a common orchestration hierarchy with the rest of the service. This enables also full ONAP service model including control loops, or just the control loop part, to be executed by a third-party orchestrator. This would be great as there are many non-ONAP orchestrators in the field but they could still share ONAP-style modeling. 

In terms of current ONAP architecture this would mean that the whole service can be instantiated using SO API which delegates control loop typed templates to CLAMP which further delegates policies to Policy and dcae entities to DCAE. 

There is not much point in For orchestration the current CLAMP runtime functionality would become a plugin 




  • No labels