CLAMP Control Loop Flow for ONAP vVoLTE
Use Case, Release 1
Ron Shacham [email protected]
Gervais-Martial Ngueko [email protected]
Introduction
This document is a description of how CLAMP (Control Loop Automation Management Platform)
capabilities will be applied to the vVoLTE Use Case in ONAP. That Use Case describes control
automation as one of the essential functions of supporting the vVoLTE service in ONAP. Specifically, the
project proposal mentions the following control loop requirements:




Auto-scaling, both vertical and horizontal
Fault detection
Correlation
Auto-healing

Open loop to create tickets
We provide here a detailed description of the control loop use case for the vVoLTE service, based on
current capabilities of CLAMP.
The intention is to define a set of flows that can be implemented in ONAP Release 1, while also
suggesting longer-term goals for broadening the control loop part of the use case.
Runtime Flow of Control Loop
Assumptions





The VES Collector may be shared across VNFs. A single instance will be installed in an edge
location.
The flow will support multiple instances of the VNF
A String matcher will be instantiated once for a given service/VNF pair. For example, there will
be an instance to support vVoLTE/vSBC.
The VNF used in the use-case will be capable of emitting fault events natively in VES format.
There will likely be one VNF component that will be used for the use-case implementation
initially, in Release 1 of ONAP. Other components or other VNFs will follow.





The VNF owner will identify a single VES fault event, by its alarm identifier and severity level,
which indicates a condition that can be remediated with a single automated action on the
troubled VM.
The VNF owner will identify an associated abatement event which will indicate that the fault
event above has been remediated, and no further action is needed, until which time as the fault
is repeated.
No correlation will be done between multiple fault events. Only a single onset event and a
single abatement event will indicate the onset and abatement of the condition, respectively.
Messaging between DCAE and Policy will follow the format specified within AT&T and
implemented as part of DCAE and Policy seed code.
An action will be executed on the VM to remediate the condition. This action will only require
Application Controller, and no other ONAP components.
Components





VNF VM component supporting VES fault output: The VNF will natively support VES.
VES Collector: The VES collector receives input from multiple VNFs in native VES format and
outputs the events on a DMaaP topic in DCAE.
String Matching Microservice: A DCAE microservice which matches fields on incoming fault
events and outputs a signature based on specific conditions. This microservice is configured by
a policy.
Policy Drools PDP: The component of the Policy Engine which decides on actions based on
incoming signatures from DCAE. The policies that specify these actions are defined in Drools.
See below for more details.
Application Controller (App-C): ECOMP component responsible for management and control of
VNFs including actions such as restart, rebuild and migrate.
Flow
1. VNF emits VES format for fault
2. VES Collector outputs trap on DMaaP topic A
3. String matcher matches the message, based on specific fields in the VES format, and outputs a
signature based on specified message format over a separate DMaaP topic B. Describe the
association between signature and control loop id
4. Policy matches the signature message to stored operational policies, and invokes App-C
accordingly, over DMaaP topic C
5. App-C takes action on VM which has emitted the fault
6. VNF emits Abate Event in VES format
7. VES Collector outputs trap on DMaaP topic A
8. String matcher matches the message, based on specific fields in the VES format, and outputs an
abatement signature based on specified message format over a separate DMaaP topic B.
Describe the association between signature and control loop id. Policy receives the message,
which indicates that it can terminate its remediation of the fault condition.
Questions
Which VNF should be prioritized?
Ticketing?
We will require supplemental data from A&AI that is not provided in the trap. Who will be responsible
for getting this data?
Future Enhancements
Design of Control Loop
Summary
Design is the process of creating a control loop template. This template provides enough details for
CLAMP to:



Present the control loop to the user so that he can configure it
Allow CLAMP to create a blueprint and upload it to ASDC, for distribution to DCAE. This
blueprint will be used to deploy any necessary DCAE microservices and databus resources.
Allow CLAMP to create a configuration policy for any DCAE microservice that is part of the
control loop.
Initially, the control loop in DCAE will consist of one static component, the VES collector, and a dynamic
component, the stringmatcher microservice.
The template will be created outside of the CLAMP tool, and provided to CLAMP so that the template
can be configured and distributed to ASDC and DCAE.
Configuration and Distribution of Control Loop
Summary
This flow begins with a control loop design, based on a template as discussed above, which defines the
elements involved in the control loop flow. Through this flow, the control loop becomes associated in
the ASDC catalog with a VNF instance within a service. The control loop is also certified and distributed
to DCAE for storage in its inventory and later instantiation (see next section). There are also policies
created for supporting the control loop instances.
Interfaces Used




ASDC Catalog API
ASDC Distribution API
DCAE Inventory API
Policy API
Control Loop Template
The template consists of:



VES Collector
String Match Microservice
Operational Policy
Configuration
The figure above shows the configuration of control loop logic. The configuration is distributed across
DCAE and Policy. This example shows the configuration of two control loops. To achieve this, two
instances of a string matcher microservice are deployed in DCAE. In general, a separate string matcher
is deployed for every Service/VNF pair in a specific location, so that there is a dedicated string matcher
for that Service/VNF.
Every string matcher configuration defines a set of rules, where each rule defines:


A set of fault conditions: Match on a number fields in the incoming fault event
A Control Loop Policy ID: Associated with an Operational Policy
Through this configuration, the DCAE microservice will attempt to match rules on all incoming trap
messages. Once it matches all fault conditions of a particular rule, it will output a signature with the
source of the fault, details of the fault, and the Control Loop Policy ID.
Policy receives this signature on its input topic and executes the Operational policy associated with the
Policy ID.
Step by Step Flow
•
Step 1: User creates new CL, using template created earlier. Currently, the template must be
created manually; in the future this will be available from ASDC.
•
Step 2: CLAMP uses API to query ASDC for services and resources available in the catalog.
•
Step 3: User chooses Service and VNF for which the control loop will apply
•
Step 4: CLAMP downloads alarm CSV file for VNF type that the user has chosen. This file will be
used to configure the signatures of the control loop.
•
Step 5: User goes to Operational Policy box, clicks, and creates a new Operational policy.
Chooses chain of actions to execute. Saves the policy as Signature1_OpsPolicy
•
Step 6: User goes to String matcher box, clicks and creates one or more associated signature
rules. He associates them with the operational policy created earlier, Signature1_OpsPolicy
•
Steps 5 and 6 are repeated, creating a different Operational Policy and associated signature
rules
•
Step 7: CLAMP invokes Policy API to create separate policies
•
Drools policy A: ClosedLoopControlName 11111
•
Drools policy B: ClosedLoopControlName 22222
•
String Matcher Microservice policy referring to ClosedLoopControlName 11111 and
ClosedLoopControlName 22222
•
Step 8: CLAMP generates blueprint, based on template
•
Step 9: CLAMP uploads blueprint to ASDC
•
Step 10: ASDC Service is checked in, tested, certified and distributed
•
Step 11: Distribution event is sent by ASDC over DMaaP and handled by SCH.
•
Step 12: The control loop design is entered into DCAE Inventory
•
Step 13: CLAMP continually queries for distribution information about control loop design.
Once the design is found, the status of control loop is shown as “Distributed”.
Instantiation of Control Loop
Summary
In this flow, the control loop resources are instantiated.
Interfaces Used

DCAE Northbound API
Full Call Flow
Question: Should we leave out the detailed flow south of DCAE NB Interface?
•
Step 15: User chooses to deploy
•
Step 16: CLAMP invokes DCAE Northbound API to request the instantiation of a control loop for
this VM
•
Create unique deployment ID = depid
•
PUT /dcae-deployments/depid
•
Body: {“serviceTypeName” : “dcaeTypeId”}
•
Response contains “status” link. This points to a link exposed by the Dispatcher API:
•
•
•
/dcae-deployments/depid/operation/operid999
CLAMP keep status link and associates it with closed loop model
Step 17: Dispatcher searches Inventory
•
DCAE Service Types for Type with the specified ID for blueprint to deploy
•
DCAE Services with specified ID to determine of there are running instances
•
Step 18: Dispatcher pushes blueprint to Cloudify
•
Step 19: DCAE Dispatcher returns a successful response to CLAMP with Deployment ID
•
•
CLAMP stores deployment ID associated with closed loop model
Step 20: CLAMP begins polling status link
•
“status” is now “processing” (“status” in response can be “processing”, “succeeded” or
“failed”)
•
(At this point, there are several interactions between Cloudify and other DCAE components.
These interactions are specified by the Common Controller Framework for deploying a CDAP
Microservice. We omit them here, and assume that there has been a successful deployment.)
•
Step 21: CLAMP polls again at a later point, after successful deployment, and gets instantiated
status information from DCAE Dispatcher status link
Questions:
•
“status” is set to “succeeded”
•
CLAMP now shows the control loop status as “Active”
Is it instantiated in local dcae or central?
How does user get options about where to instantiate control loop
Management of Control Loop
Summary
Once the control loop is instantiated, CLAMP allows for operations to be performed on the control loop.
Specifically, the following operations:



Stop the control loop from operating
Restart the operation of the control loop
Update any configuration of the control loop
Here we show how these operations are carried out.
Interfaces Used



DCAE Northbound API
Policy API
DCAE/Policy Interface
•
Step 1: An operational user chooses to change configurations settings for the control loop.
CLAMP updates configuration policy of string matcher
•
Step 2: Updated configuration is received by DCAE/Policy Interface
•
Step 3: String matcher receives updated configuration. (This is a dotted line to indicate that the
policy is received by the String matcher, but the details of how this is done and through which
components is not specified here)
•
Step 4: User requests suspending closed loop, and CLAMP executes this through operational
policy
•
Step 5: User requests restarting closed loop, and CLAMP executes this through operational
policy
•
Step 6: User requests undeployment of closed loop
•
CLAMP makes a request to DCAE Northboound interface to delete an existing
deployment
•
Step 7: Northbound Interface sends to Cloudify
•
Step 8: Northbound interface responds and provides a “status” link for the undeployment
•
CLAMP starts polling for undeployment status
•
(At this point, there are several interactions between Cloudify and other DCAE components.
These interactions are specified by the Common Controller Framework for undeploying a CDAP
Microservice. We omit them here, and assume that there has been a successful undeployment.)
•
At a later point, after successful undeployment CLAMP gets “status” :“success” in response to its
polling
Monitoring of Control Loop
Will the CLAMP Cockpit do its own monitoring and visualization? Can the dashboard be put into ONAP?
Monitor such information as:



Where are control loops deployed
What VNFs are supported by these control loops
KPIs related to specific control loops
o Number of actions
o
References
VES