Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 3 Current »

This document provides an overview of DCAE functionality and APIs planned for ONAP R1.

DCAE Functionalities

The diagram above illustrates the ONAP R1 DCAE components and the external interfaces between DCAE and other ONAP components.


DCAE provides VNF and infrastructure measurement and fault data collection and analytics for the ONAP system.  For R1 the planned functionalities of DCAE target the support of control loops of the 3 approved use cases: vFW/vDNS, vCPE, and vVoLTE.  The planned functionalities are described below.

DCAE Instantiation

Platform instantiation 

DCAE platform components form the foundation of the DCAE.  They are deployed at the instantiation time of the ONAP/DCAE.  Some components are embodied as VMs, some are containers, or applications.  For R1, the platform components include the following VM or VM cluster components:

  • Cloudify Manager 
  • Consul HA cluster 
  • PostgreSQL as a service 
  • Platform Docker host
  • Component Docker host
  • CDAP analytics platform

Further, these Docker container platform components are deployed onto the Platform Docker host:

  • DCAE Inventory
  • Service Change Handler
  • Policy Handler
  • Deployment Handler
  • CDAP Broker
  • Configuration Binding Service
  • Registrator

and the following Docker container platform components are deployed onto the Component Docker host:

  • Registrator

Service Component Instantiation

DCAE service components are collection and analytics components that are needed for accomplishing data collection and analysis tasks for control loops.  For ONAP R1, there will be 4 control loops defined: for vFW, vDNS, vCPE, and vVoLTE.  The service components needed for each control loop are listed below.  (In ONAP R1, Holmes is used as DCAE analytics (correlation) for supporting the vVoLTE use case.  The details of its APIs can be found under the Holmes project:  Holmes Documentation.)

  • vFW
    • VES collector
    • TCA CDAP analytics
  • vDNS
    • VES collector
    • TCA CDAP analytics
  • vCPE
    • VES collector
    • TCA CDAP analytics
  • vVoLTE
    • VES collector
    • Holmes correlation analytics

The deployment of service components is based on control loop blueprint definition.


DCAE supports blueprint (TOSCA model) based deployment of all its R1 components, as well as providing APIs for health checking and other OAM operation on these components.

Service Component Configuration

DCAE supports two methods for configuring service components deployed by DCAE.  The first is via default (static) configurations that is provided as part of the service component on-boarding process.  The second is via Policy.  Configurations via either method will become available on Consul through DCAE platform, and for service components to fetch via service discovery mechanism.


DCAE APIs

Primary APIs

Primary APIs are the designed methods of interaction with DCAE Platform.  They are stable, and intended as the entry points into DCAE platform functionalities

C1 interface is the interface from SDC to DCAE.  It is used for injecting service component deployment blueprint into DCAE Inventory.

C2 interface is the interface from Policy to DCAE.  When there is any changes in control loop configuration policy, such change is fetched from Policy into DCAE, and eventually applied to DCAE service components.

C3 interface is the interface from CLAMP to DCAE.  When CLAMP performs lifecycle management on any control loop, it invoke the C3 API into DCAE to trigger corresponding workflows being executed on DCAE service components.

C4 is the interface that DCAE depends on for deploying its virtual resources to cloud infrastructure.  For R1 it is the standard Open Stack API, provided by either the cloud infrastructure or MultiVIM.


D1 is the FCAPS data ingestion API provided by DCAE service component (VES collector) for supporting all three approved use cases, i.e. vFW/vDNS, vCPE, vVoLTE. 

D2 and D3 are the publish and subscribe APIs of DMaaP Message Router.  Details will be provided by the DMaaP project.

D4 is the API for Holmes correlation analytics retrieving inventory information from A&AI.  Details of this interface will be provided by the Holmes and A&AI projects.


T1 is the testing interface for DCAE components.  It is provided by the Consul component.  This API provides APIs for health testing, status, and configurations of DCAE components, as well as additional API endpoints provided by individual components.

T2 is the testing interface for monitoring data being published to DMaaP message router.  It is provided by DMaaP Message Router as its subscription API.  However, because DCAE depends on DMaaP heavily for data transport, such API can be used for monitoring data coming out of DCAE and in between certain DCAE components.  Hence a valuable testing interface.


Secondary APIs

Secondary APIs are intended for testing and development purposes.  They may change, or closed with no explicit notifications.  Secondary APIs also include the native GUI of external open source components.

  1. Cloudify Manager GUI
  2. Consul GUI
  3. CDAP GUI


DCAE Test Cases

DCAE Test Cases

  1. Instantiation tests: deploying DCAE platform, then verifying component status via T1.  Deploying service components based on CLAMP blueprints from C3, then verifying component status via T1.
  2. Functional tests: injecting synthetic FCAPS data via D1, observing data being accepted and forwarded by VES via T2, observing any alerts generated by analytics (TCA or Holmes) via T2.


  • No labels