Project Name:
- Proposed name for the project:
CLAMP
- Proposed name for the repository: (org.onap.)
clamp
Project description:
CLAMP is a platform for designing and managing control loops. It is used to design a closed loop, configure it with specific parameters for a particular network service, then deploying and undeploying it. Once deployed, the user can also update the loop with new parameters during runtime, as well as suspending and restarting it.
It interacts with other systems to deploy and execute the closed loop. For example, it pushes the control loop design to the SDC catalog, associating it with the VF resource. It requests from DCAE the instantiation of microservices to manage the closed loop flow. Further, it creates and updates multiple policies in the Policy Engine that define the closed loop flow.
The OpenCLAMP platform abstracts the details of these systems under the concept of a control loop model. The design of a control loop and its management is represented by a workflow in which all relevant system interactions take place. This is essential for a self-service model of creating and managing control loops, where no low-level user interaction with other components is required.
Scope
Functionality:
- Designing the Control Loop:
- Model based (based on templates)
- Re-usable designs
- Configuring the Control Loop:
- VNF driven, future should be SERVICE driven
- Defining threshold values…
- Deploying the Control Loop:
- Sending template towards DCAE, Policy, …
- Lifecycle Management of the Control Loop:
- Stopping/re-starting/updating
- Monitoring (visualization of the Loop)(future not in R1)
- Trial mode, production mode, ….(future not in R1)
- Activation (manually and/or triggered by a policy(future not in R1) and/or tied to the vnf startup(future not in R1))
End to End Flows:
Since CLAMP is an end-to-end application, the project will, early on, develop documents describing detailed call-flows and message formats between ONAP components to support
...
These documents will be developed for the three use cases: vFW/vDNS, vVoLTE, and vCPE.
Use-cases:
CLAMP will support the vFW/vDNS ONAP Use case in R1.
...
- create the blueprint for DCAE to capture traffic level.
- create the policy that will define theshold signature that DCAE will use.
- DCAE team provides model to Policy team to built the Configuration policy
- create the policy that will trigger SO to spun up a new vDNS vm.
Interfaces:
The following interfaces will be implemented by other components but used for CLAMP. Therefore, CLAMP has these as dependencies:
- Query and update services in SDC
- Query and update control loop templates in SDC (future not in R1)
- Policy interfaces for creating/updating configuration and operational policies
- DCAE interfaces for deploying/undeploying control loops
- Runtime messaging interface between DCAE and Policy
Architecture Alignment
- SDC : Rest based interface exposed by the SDC
- DCAE: Rest based interface exposed by DCAE
- Policy: Rest based interface (the Policy team provide a "jar" to handle the communication).
- Design Time(Cockpit/UI to define the templates)
- Templates are pushed to SDC. The template format is TOSCA blueprint, those blueprints will be pushed/provisioned, by SDC, to DCAE orchestration engine.
- policies (configuration and operational policies) are pushed/provisioned towards the Policy Component of ONAP. (those policies will be triggered by DCAE during Closed Loop operations).
- The DCAE team needs to provide models to Policy team in order for the Configuration policy to be built.
- Run time(DCAE-Policy, grabbing events and triggering policies based actions)
- In the first release of CLAMP, the triggering to deploy(and then effectively start the closed loop) a blueprint will be manual (via CLAMP cockpit)
an automatic deployment based on an event will come in future release. - The CLAMP cockpit will support the following action at runtime:
- start (start the provisioned Closed Loop on DCAE)
- stop (stop a provisioned Closed loop on DCAE)
- In the first release of CLAMP, the triggering to deploy(and then effectively start the closed loop) a blueprint will be manual (via CLAMP cockpit)
...
CLAMP depends upon the following open source projects:
- AJSC 6.0 (container framework based on Spring and developed by "AT&T Common platform" Team)
- AJSC-Camunda 6.0 (Camunda Workflow integration to AJSC container developed by "AT&T Common platform" Team)
Resources
NGUEKO Gervais-Martial (AT&T - gn422w@intl.att.com)
Other Contact/Contributor Person:
- SHACHAM Ron (AT&T - rshacham@research.att.com)
- BHATNAGAR Aayush (Reliance Jio - aayush.bhatnagar@ril.com)
- NGUYEN Trung (Amdocs)
- MIAO Xin (Futurewei - xin.miao@huawei.com)
Committers/Maintainers:
- Christophe Closset (AT&T - cc697w@intl.att.com)
- Sebastien Determe (AT&T - sd378r@intl.att.com)
- Pierre Close (AT&T - pc457b@intl.att.com)
- Eddy Hautot (AT&T - eh552t@intl.att.com)
- Xue Gao (AT&T - xg353y@intl.att.com)
- SHACHAM Ron (AT&T - rshacham@research.att.com)
Other Information's
...